Skip to main content
root@rebel:~$ cd /news/threats/evilginx-operations-exposed-misconfigured-server-leaks-m365-phishing-kits_
[TIMESTAMP: 2026-07-13 11:18 UTC] [AUTHOR: Runtime Rebel Intel] [SEVERITY: HIGH]

Evilginx Operations Exposed: Misconfigured Server Leaks M365 Phishing Kits

HIGH Threat Intel #Microsoft 365#Phishing#AitM
AI-generated analysis
READ_TIME: 4 min read
Primary source: thehackernews.com

This article was written by a language model from the source above and was not reviewed by a human before publication. Verify anything operational against the original. Editorial policy

// executive briefing tl;dr
  • [01] Attackers are actively targeting Microsoft 365 accounts using Evilginx to bypass multi-factor authentication and steal session cookies.
  • [02] Impacted systems include any Microsoft 365 environment where users are susceptible to adversary-in-the-middle phishing attacks.
  • [03] Defenders must implement FIDO2-based authentication and monitor for suspicious session cookie usage to mitigate session hijacking risks.

Lexfo researchers recently uncovered three distinct phishing operations after an attacker inadvertently exposed their infrastructure. According to The Hacker News, the exposure occurred when an operator left a Python web server running with directory listing enabled on a public-facing port. The command python3 -m http.server 8080 was discovered in the .bash_history file, allowing researchers to download the attacker’s entire toolkit and analyze the active campaigns.

The Mechanics of Adversary-in-the-Middle Attacks

The campaigns leveraged Evilginx, a well-known framework for conducting Adversary-in-the-Middle (AiTM) attacks. Unlike traditional Phishing that merely clones a login page to steal credentials, AiTM frameworks proxy the actual login session between the victim and the legitimate service provider, such as Microsoft 365. This allows the APT or cybercriminal to bypass multi-factor authentication (MFA) by capturing the session token (cookie) after the victim successfully authenticates.

To understand the scale of the threat, organizations must understand how to detect Evilginx phishing campaigns within their own network traffic. These attacks often utilize lookalike domains and transparent proxies that are difficult for standard security filters to identify at the perimeter. The Lexfo discovery highlights that even sophisticated actors can fall victim to basic operational security (OPSEC) failures, providing a rare window into their TTP.

Technical Analysis of the Infrastructure Leak

The exposed server acted as a C2 node for managing multiple “phishlets”—custom configuration files used by Evilginx to target specific services. By analyzing the leaked files, researchers could see how the attacker organized their infrastructure to target Microsoft 365 accounts globally. The leak included session logs, which contained captured cookies for victims who had already been compromised. This demonstrates that the attack was not theoretical but was actively harvesting access to corporate environments.

A significant portion of the technical analysis focused on Microsoft 365 MFA bypass mitigation strategies. Since the attacker was essentially stealing an active session, standard SMS or push-based MFA provided no protection once the session cookie was exfiltrated. The presence of the .bash_history file also revealed the sequence of commands used to set up the server, including the installation of dependencies and the manual modification of the Evilginx source code to avoid detection by automated scanners and EDR solutions monitoring for known signatures.

Detection and Remediation: Strengthening the SOC

Security teams should prioritize Adversary-in-the-Middle attack detection by monitoring for unusual sign-in patterns. Because the stolen session cookies can be used from different geographic locations, “impossible travel” alerts in the SIEM are a critical IoC for the SOC to track.

To mitigate these risks, organizations should consider the following actions:

  • Adopt Phishing-Resistant MFA: Transition from legacy MFA methods to FIDO2-compliant hardware keys or Windows Hello for Business. These methods bind the authentication to the specific domain, preventing AiTM proxies from successfully intercepting the handshake because the domain in the proxy (e.g., micros0ft-login.com) will not match the domain on the security key’s credential.
  • Monitor Session Tokens: Use cloud identity tools to flag session tokens that are used from IP addresses or browsers that do not match the initial login context. Any sudden change in user agent or IP reputation during an active session should trigger an automated revocation of that session.
  • Conditional Access Policies: Implement strict policies that require compliant, managed devices for access to sensitive Microsoft 365 resources. This reduces the risk of a successful Privilege Escalation or Lateral Movement after an initial account compromise, as the attacker’s proxy server is unlikely to meet the device compliance requirements.

This incident serves as a reminder that while offensive tools are becoming more automated and capable of bypassing legacy security, the human element—and simple configuration errors—remain a vulnerability for both the victim and the attacker. Regular audits of internet-facing infrastructure are essential to ensure that developers or administrators have not inadvertently exposed internal tools or history files that could provide a map for defenders or rival threat actors.

Advertisement

Advertisement