Evilginx, a tool based on the authentic (and widely utilized) open-source nginx web server, can be utilized to grab usernames, passwords, and session tokens, enabling an attacker to potentially bypass multifactor authentication (MFA). In this article, we will exhibit how evilginx operates and what data it is capable of obtaining; we also provide guidance on identifying this tool in action, along with possible measures against its usage.
Working Mechanism
Evilginx fundamentally leverages the legitimate and favored web server nginx to route web traffic through malevolent sites, established by the threat actor to imitate genuine services like Microsoft 365 — an Adversary-in-the-Middle (AitM) assault. To exemplify, we set up a malevolent domain; as depicted in Figure 1, there exists a Microsoft phishlet in position with its individual subdomain of that domain. (All pertinent IP addresses, usernames, passwords, and domains employed in this article were decommissioned before publishing.) The phishlet incorporates a decoy, and that decoy is what the targeted user perceives as the attacker endeavors to seize their username and password.
Figure 1: Evilginx in operation, showing the malevolent domain, the phishlet, and the decoy to be utilized against the target
It is worth noting that the forms and images displayed to the user truly come from Microsoft itself; they are relayed from the lawful company through the evilginx server and onwards to the user. On the backend, evilginx provides the attacker with choices for configuring the encounter. In our evaluation, we simulated a user account safeguarded by MFA… and swiftly circumvented it. The user is presented with a “regular” login experience; it is only upon clicking on one of the apps along the left-hand side of the screen that a discerning user might perceive something is peculiar, as they will be prompted to log in again.
An overview of our evilginx server unveils what is transpiring.
Figure 2: An evilginx server showcases collected information and appends it to its database for later misuse
Aside from grabbing the user’s username and password, the session token was also acquired as it was transmitted through the Keep Me Signed In functionality chosen by the attacker when the Microsoft prompt showed up. Evilginx stores this data in a database that accumulates the details on each session, also encompassing the public IP address used to approach the server, the user agent in operation – and, crucially, the cookie. Armed with this information, the attacker simply needs to launch a tab to the legitimate login page and import the cookie to be logged in as the genuine user.
Subsequently, the threat actor gains complete entry to the user’s mailbox account. Usual actions may involve appending mailbox rules. If access is granted, the threat actor can also reset MFA devices, alter passwords, and execute several other actions to furnish themselves with supplementary persistence to the account.
Detection Paths
There are diverse means by which defenders could unearth activity of this nature. Initially, in Azure and Microsoft 365, there exist two primary locations that maintain logs and events that can be scrutinized for uncommon activity. The first are the Entra ID (previously called Azure AD) sign in and Audit logs. The two illustrations in Figure 3 exhibit our users’ authentications originating from our evilginx server (54.225.206.84), and then from the Tor exit node that we employed for our demonstration (45.80.158.27). The audit logs demonstrate that following this login, our attacker added a new authenticator app to “their” account.
Figure 3: Nothing suspicious at all about an inbox rule titled Fully Legal Forwarder
Secondly, the Microsoft 365 logs, also known as the unified audit log or UAL, reveal that during the session our unauthorized user introduced a new inbox rule named Completely Legit Forwarder. (To aid in reviewing these logs, Microsoft 365 also furnishes an advanced hunting area within the security center that permits you to use the Kusto query language to sift and locate dubious activity using varied criteria.)
Security notifications and incidents are also triggered upon spotting suspicious activity. As an illustration, we can discern in Figure 4 that the sophos_mfa account attempted to sign in from a doubtful IP address, and that an irregular token was utilized during one of those sessions.
Figure 4: The anomalous token, the unidentified IP address, and the dubious redirect rule are all marked
For Sophos clients, integrations are present for bringing in events and alerts from Azure and Microsoft 365 into Sophos Central. Depending on the particular XDR integration pack, tailored identity-related detections are part of the bundle; for MDR customers, those detections are assessed by the MDR team
as element of the assistance.
Possible precautions and worries
Potential precautions can be categorized into preemptive and responsive ones. While an exhaustive list of possible precautions is outside the bounds of this article, a well-thought-out and multi-layered strategy is most effective in safeguarding any kind of applications or services that are publicly accessible and of great value in your setup.
It’s time for the industry to consider stronger measures, transitioning away from token-based or push MFA towards resilient, phishing-resistant, FIDO2-based authentication techniques.
The positive news is that there are excellent options available in various forms – such as Yubikey-style hardware keys, Apple Touch ID on contemporary hardware, Windows Hello for business, and even solutions that integrate iPhone and Android. (For further insights on superior directions in MFA, please refer to Chester Wisniewski’s recent piece on passkeys.)
Conditional access regulations are another potential strategy for reinforcing security in your Azure and Microsoft 365 environments. The traditional whitelist approach may theoretically be taken – where any untrusted IP address is barred – but in practical terms, it is the devices that you would govern, permitting only trusted enterprise devices to access enterprise systems. (Providers like Sophos constantly monitor and obstruct known malicious websites as part of our services — an ongoing responsibility, and blacklisting is arguably simpler to manage than whitelisting.)
Nonetheless, we should not solely depend on user consciousness. Humans are fallible, and virtually everyone will sooner or later fall for phishing. The way ahead lies in architectures that are robust even when humans lapse.
For responsive precautions, the initial move should be to seal off the threat actor’s entry. Several steps should be taken to ensure the door is completely closed in this scenario. Initially, invalidate all sessions and tokens via Entra ID and Microsoft 365 to eliminate gained access. These actions can be executed in the user’s account in both Entra ID and Microsoft 365 using the “Revoke sessions” and “Sign out of all sessions” functions.
Subsequently, reset the user’s passwords and MFA devices. As observed in the logs, the threat actor appended a new MFA device to the user’s account. Depending on the type of MFA device added, this could permit access to the account without a password, undermining the efficacy of changing passwords and revoking sessions. Utilize Microsoft 365’s logs to review all actions carried out by the attacker. Identifying surreptitious alterations, like the addition of new inbox rules, is crucial to prevent any further data from leaving the user’s account. Administrators might discover Microsoft’s own investigation advice on token theft beneficial.
Wrap-up
Evilginx presents a formidable means of circumventing MFA for credential breaches — making a sophisticated attack technique feasible, which could result in widespread usage of this technique. The optimistic aspect is that the precautions and protocols you should already be implementing act as robust deterrents to impede attackers from employing this tool against your infrastructure.
About Author
