Evilginx, a tool based on the legitimate (and widely used) open-source nginx web server, can be used to steal usernames, passwords, and session tokens, allowing an attacker to potentially bypass multifactor authentication (MFA). In this post, we’ll demonstrate how evilginx works and what information it is able to acquire; we also have advice for detecting this tool in use, as well as potential mitigations against its use.
How it works
Evilginx at its core makes use of the legitimate and popular web server nginx to proxy web traffic through malicious sites, created by the threat actor to mimic real services such as Microsoft 365 — an Adversary-in-the-Middle (AitM) attack. To demonstrate, we configured a malicious domain; as shown in Figure 1, we have a Microsoft phishlet in place with its own subdomain of that domain. (All relevant IP addresses, usernames, passwords, and domains used in this post were decommissioned prior to publication.) The phishlet includes a lure, and that lure is what the targeted user sees as the attacker attempts to grab their username and password.
Figure 1: Evilginx in action, showing the malicious domain, the phishlet, and the lure to be used against the target
It’s useful to note that the forms and images the user sees really do come from Microsoft itself; they are relayed from the legitimate company through the evilginx server and onward to the user. On the back end, evilginx gives the attacker options for configuring the experience. In our testing, we mimicked a user account protected by MFA… and promptly got around it. The user is presented with a “normal” login experience; it’s only when they click on one of the apps along the left-hand side of the screen that a canny user might notice something is odd, as they will be asked to login again.
A look at our evilginx server shows what’s happening.
Figure 2: An evilginx server displays captured information and adds it to its database for later abuse
In addition to intercepting the user’s username and password, the session token was also gathered as it was passed from the Keep Me Signed In functionality selected by the attacker when the Microsoft prompt appeared. Evilginx stashes this data in a database that collects the information on each session, also including the public IP address used to access the server, the user agent in play – and, crucially, the cookie. With this in hand, the attacker need only open a window to the legitimate login page and import the cookie to be signed in as the legitimate user.
From here, the threat actor has full access to the user’s mailbox account. Typical actions can include adding mailbox rules. If access is available, the threat actor can also reset MFA devices, change passwords, and perform a number of other actions to give themselves additional persistence to the account.
Detection avenues
There are various ways defenders might discover activity of this type. First, in Azure and Microsoft 365, there are two main locations that keep track of logs and events that can be reviewed for unusual activity. The first are the Entra ID (previously known as Azure AD) sign in and Audit logs. The two examples in Figure 3 show our users’ authentications originating from our evilginx server (54.225.206.84), and then from the Tor exit node that we used for our demonstration (45.80.158.27). The audit logs show that after this login, our attacker added a new authenticator app to “their” account.
Figure 3: There is definitely nothing suspicious about an inbox rule named Completely Legitimate Forwarder
Second, the Microsoft 365 logs, also called the unified audit log or UAL, show that during the session our illegitimate user added a new inbox rule called Completely Legit Forwarder. (To assist with reviewing these logs, Microsoft 365 also offers an advanced hunting area inside of the security center that allows you to use the Kusto query language to filter and find suspicious activity using different criteria.)
Security alerts and incidents are also generated when suspicious activity is detected. As an example, we can see in Figure 4 that the sophos_mfa account attempted to sign in from a suspicious IP address, and that an anomalous token was used during one of those sessions.
Figure 4: The anomalous token, the anonymous IP address, and the suspicious redirect rule are all flagged
For Sophos customers, integrations exist for importing events and alerts from Azure and Microsoft 365 into Sophos Central. Depending on the specific XDR integration pack, custom identity-related detections are part of the package; for MDR customers, those detections are triaged by the MDR team as part of the service.
Potential mitigations and concerns
Potential mitigations can be sorted into two categories, preemptive and reactive. A full list of potential mitigations is well beyond the scope of this article, but as ever, a thought-out and layered approach is best when it comes to defending any kind of applications or services that are publicly available and of high value in your environment.
Still, it’s time we as an industry look to stronger measures, migrating off token-based or push MFA and toward robust, phishing-resistant, FIDO2-based authentication methods.
The good news is that good options are available in many forms – Yubikey-type hardware keys, Apple Touch ID on modern hardware, Windows Hello for business, even options that incorporate iPhone and Android. (For further thoughts on better directions in MFA, please see Chester Wisniewski’s recent essay on passkeys.)
Conditional access policies are another potential step for securing your Azure and Microsoft 365 environments. In theory of course one could take the old-fashioned, hand-crafted whitelist route – blocking any IP address that’s not trusted – but practically speaking it’s the devices one would manage, allowing only enterprise-trusted devices to log into enterprise systems. (Sophos and other vendors of course do keep constant watch for, and block, known-malicious sites as part of our services — a never-ending task, and blocklisting is arguably easier to manage than whitelisting.)
That said, we cannot ultimately rely on user awareness. Humans are fallible, and literally everyone will sooner or later be phished. The path forward lies with architectures that are resilient when humans fail.
For reactive mitigations, the first step should be to close the door on the threat actor. In this case, there are a number of steps that should be taken to make sure the door is fully closed. To start, revoke all sessions and tokens via Entra ID and Microsoft 365, to remove access that has been gained. These actions can be performed in the user’s account in both Entra ID and Microsoft 365 using the “Revoke sessions” and “Sign out of all sessions” buttons.
Next, reset the user’s passwords and MFA devices. As we saw in the logs, our threat actor added a new MFA device to the user’s account. Depending on the type of MFA device added, this can allow passwordless access to the account, removing the efficacy of changing passwords and removing sessions. Use Microsoft 365’s logs to examine all activity undertaken by the attacker. Spotting stealth changes, such as the addition of new inbox rules, is important to make sure no additional information is able to leave the user’s account. Administrators may find it useful to refer also to Microsoft’s own investigation guidance concerning token theft.
Conclusion
Evilginx is a formidable method of MFA-bypassing credential compromise — and it makes a complex attack technique workable, which in turn can lead to widespread use of the technique. The good news is that the mitigations and practices you should already be following are powerful deterrents to the success of attackers attempting to deploy this tool against your infrastructure.
