Catching the Phish – Detecting Evilginx & AiTM

Introduction & Background

Multifactor authentication (MFA) methods have become the gold standard in account security in recent years, with most enterprise accounts requiring it in order to login to any corporate resource. This has worked well in preventing unauthorized access when a password is leaked, stolen, brute-forced, or simply guessed. Even with a freshly-stolen password in hand, an adversary is still unable to login without access to a phone number, authentication app, or, in some cases a biometric authentication mechanism. 

This additional requirement to possess a third piece of information in addition to the standard username and password makes it incredibly difficult to compromise MFA-protected accounts. Threat actors face further difficulties due to most multifactor codes only being valid for 30-60 seconds before they change, adding another time-based requirement to the list of defense mechanisms. While MFA is now the standard for account protection and represents a groundbreaking advancement in defense, attackers have also developed sophisticated techniques to bypass these measures. These include SIM swapping (to intercept text-based MFA codes), social engineering helpdesks (to reset MFA), MFA fatigue (bombarding users with prompts until they approve), and most notably, AiTM (Adversary in the Middle), which is particularly relevant to this blog post.

Adversary in the Middle is an especially dangerous threat because it does not require the time investment and research that is involved with exploiting human-based vulnerabilities, such as calling a phone provider and convincing them to SIM swap or calling a company’s help desk impersonating an employee requesting an MFA reset. These human-based scenarios often require an actual person to conduct basic Open Source Intelligence (OSINT) and spend time attempting to convince another human to perform the bypass. 

Adversary in the Middle tools are easily-accessible on Github, are free to use, and can even be automated to operate 24/7 to intercept logins without any OSINT or human operators. Through mass-emailing of lures or Search Engine Optimization (SEO) poisoning, opportunistic threat actors are able to target thousands of organizations within minutes, requiring only one single user to fall for the complex attack in order for the threat actor to gain access to confidential documents, emails, messages, code repositories, and any other sensitive data.

For those unfamiliar with AiTM attacks, the general flow is:

1. Attacker configures a “reverse proxy” to serve a legitimate login page for a platform such as Microsoft.
   • This reverse proxy is often hosted on a domain that looks like Microsoft at first glance such as portal[.]microsoftauth[.]zip
   • This malicious reverse proxy sits between the victim and the legitimate login portal, earning its name: “Adversary In The Middle”.

2. The user inputs their credentials (username, password, MFA code) and the reverse proxy relays them to the real login portal (Microsoft) while simultaneously intercepting the credentials.
   • Arrival at the malicious reverse-proxied login page often occurs when the victim receives an email containing a link/QR code sending them either to the lure directly or a relay site that prevents security email gateways (SEGs) from scanning the end lure while also hampering tools that perform scanning and reputation analysis on the open internet. This complex usage of traffic filtering prevents a substantial amount of automated and manual analysis which generally leads to AiTM servers not being flagged by OSINT tools such as VirusTotal.

3. After the user’s credentials and MFA information are intercepted, the user may either continue to use the destination resource in the context of the reverse proxy or may be redirected to the legitimate service to avoid suspicion.
   • While AiTM tools capture the credentials and MFA code, this is not the goal as the provided MFA code is only valid for a short time before changing. The real target is the session token that is issued to the victim after providing the correct login information. Given that the user is interacting with the legitimate login portal through the threat actor’s reverse proxy, the threat actor is able to intercept this session token.

4. With the session token in hand, the adversary can then use a browser plugin to load the session token and enter the user’s account without supplying the login information again and/or being subject to conditional access policies enforced at logon.
   • This provides them with access to the contents of the account (and linked accounts) and the opportunity to add an additional MFA app/device of their own so they can login when the stolen session expires or is revoked.
   • It is also possible to leverage AiTM tools that automatically perform interaction with the victim accounts using the stolen session token to perform automated actions such as:
     • Sharepoint downloads (files of interest)
     • Sending internal spear phishing emails from the victim account to attempt to compromise more users internally, possibly with more access
     • Setting up inbox rules to automatically forward sensitive information or hide security-related alerts in obscure folders

With the basic flow of the attack out of the way, it’s worth calling out a few things that stick out from a blue team/defense perspective:

1. When the user signs into the lure page, they are not signing in directly to Microsoft (or whatever the destination platform is), they are entering credentials into the threat actor’s reverse proxy which is then submitting the information to Microsoft on their behalf.
   • In simple terms, this means the actual “login” is not occurring from the victim’s IP, rather the IP of the reverse proxy hosting the lure.

2. AiTM tools are adept at cloning the victim’s user agent and general browser fingerprint which prevents red flags related to new/rare devices signing in compared to the user’s historical baseline
   • While the threat actor who then takes the stolen session and pastes it into their browser may not take the same steps to replicate the user’s browser/device type, the initial session theft is not likely to fire detections watching for anomalous logins based on browser type or user agent.

3. Most “impossible travel” alerts are examining the geographical distance between the locations of two actual logins and flagging pairs where the speed of travel is not likely to be physically possible. In the case of AiTM, there is only a single logon event from the reverse proxy and subsequent threat actor activity is then carried out in the context of that same session without another login.
   • This means that unless the victim logged in from their real IP shortly before falling for the AiTM lure, there would not be a first logon to compare against the second from the reverse proxy.
   • In order for impossible travel alerts to catch this activity they must also consider sessions spanning multiple geographical locations instead of just full logons (something that can be noisy and not easy to investigate).

The above data points make it very difficult to detect AiTM if the adversary is skilled and ensures the login comes from an egress point nearby the victim’s physical location (AiTM servers can leverage proxies and VPN’s themselves to change their egress point to be less anomalous/suspicious). Threat actors of lower caliber may allow the logons to occur from countries like Russia or China in data-hosting subnets that are likely to raise alerts in that regard but true, skilled AiTM typically flies well-under the radar of traditional alerting.

While geographically anomalous logon, impossible travel (actual logon or session activity), and rare device/useragent alerts may catch general activity around AiTM, detection capabilities surrounding specific AiTM tools is not something that has been heavily reported on. General authentication abnormality alerts can be noisy and difficult to process but identifying specific attributes about a specific tool (especially those that are free and open source) is a worthwhile endeavor and provides a glimpse into where an adversary might slip up while using the tool’s default configurations and accidentally provide high fidelity detection opportunities capable of identifying and thwarting the attack.

Evilginx is a popular open source AiTM tool for creating “phishlets” (phishing pages) by type (i.e. Microsoft, Okta, LinkedIn) to act as dynamic lures serving the user the legitimate content in the role of a reverse proxy. This creates an Adversary in the Middle (AiTM) setup capable of stealing victims’ sessions. Evilginx is a heavily modular platform allowing for custom phishlets, embedded configurations, custom evasion mechanisms, etc. This variety in freely-available phishlet configuration files leads to many different phishing lures of varying complexity and technical ability at evading detection. The rest of this article will focus on several attributes of either Evilginx itself or freely-available phishlets where usage of the tool leaves telltale indications of attack in many common enterprise telemetry sources. 

Gone Phishing – Lab Walkthrough & Findings

Using the publicly available Evilginx3 framework, the Deepwatch Threat Detection Research team conducted lab-based testing to simulate threat actor usage of the tool and AiTM frameworks in general. Using the organic intelligence created from the lab and in-house data, a core set of detection logic was created to identify Evilginx activity and even activity related to more advanced closed-source frameworks.

Evilginx Server OSINT – The Lack Thereof

When investigating the discovered Evilginx servers in VirusTotal, it quickly became apparent that they were not tracked as malicious unless other VirusTotal users submitted the lure links they received in emails. By design, Evilginx’s lures are not easy to find without the lure URL and there is no content at webroot, let alone a list of pages to crawl. This ensures that sandboxes and web scanners are unable to find the malicious content in order to classify the domain as malicious. The vast majority of discovered Evilginx servers were also hosted on newly-registered domains, sometimes conducting attacks just hours after registration.

Figures 11, 12, & 13: Examples of known Evilginx domains marked clean on VirusTotal (similar VT scores can be seen on the specific subdomains with the exception of when users upload a specific lure URL)

“One Phish, Two Phish, Red (team) Phish, Blue (team) Phish” – Detection Opportunities

Detection via MFA Change Auditing

After the user enters the username, password, and MFA code, the threat actor’s access is then based on that specific session, and is still unable to authenticate to the victim account on their own. This creates the risk of losing access if/when the stolen session is terminated or revoked. With this in mind, threat actors will typically add an additional MFA device or app to the user’s account in order to maintain persistence. Threat actors will often add this additional MFA factor without removing any legitimate factors in order to avoid detection by not impeding legitimate logins.

Detection via Evilginx Subdomain and Lure URL

Reference Figures 1-4

Evilginx has several identifiable characteristics in its lure URL syntax, though certain phishlets and tiers of the platform allow threat actors to customize the configuration. Despite this possibility, the most likely scenario will be using the out of the box defaults, especially for campaigns targeting thousands of organizations and low-hanging-fruit where there is no need to spend time on complex or custom setups for such opportunistic attacks.

• Evilginx phishlets tend to prepend specific subdomains to the attacker’s domain depending on the phishlet type (target platform). For example, Microsoft phishlets commonly add a “login.” subdomain. It is also worth noting that these domains will often use LetsEncrypt certificates that are automatically acquired during the Evilginx deployment.
• By default, Evilginx also uses an eight letter URI string following the domain for the lure URL. This eight character string consists of random letters, sometimes in mixed casing depending on the web proxy solution that logs it.
  • The domain + eight character URI either makes up the entire URL or can be followed by “?*”, but will not be directly followed by a further path structure (i.e. “domain/<8char>/next_path”) or other normal URL parameters.

The most commonly observed scenario is threat actors registering a new domain to be used for the phishing campaign (typically immediately before use, such as the same day). This can provide additional detection capabilities by monitoring for email links or web proxy logs relating to newly-registered domains and/or suspicious or absent web proxy categorization, no domain reputation/popularity ranking, etc.

Detection via Unexpected Domains Serving Login Portal URI Paths and/or Login Portal Resources being Called by Rare HTTP Referrers

Reference Figures 5-7

Another detection method for Evilginx and even AiTM in general is a byproduct of the dynamic phishing pages used to perform AiTM attacks. With a static phishing site, the resources for the target page can be loaded and served by the phishing server, however it is only the surface-level page that is typically functional. This is identifiable via live interaction when the “Forgot Password” link does not function and random usernames/passwords get accepted because no validation is being performed.

Conversely, dynamic phishing pages act as a reverse proxy, needing to continuously load content from the legitimate destination service as the user interacts with the lure in various stages of supplying credentials. This can either be done by rewriting the content URL’s to load resources through the reverse proxy, or by leaving them as-is and allowing the victim’s browser to directly load Microsoft elements not needing to be proxied for the attack to function (logo images, backgrounds, etc).

• If the AiTM server allows the victim’s browser to directly load certain resources from Microsoft:
  • The page code still refers to dependency resources in the destination platform’s infrastructure (i.e. O365 logos for the sign in page). 
  • When the page is served to the user, the victim’s browser will generate web requests to obtain those resources on Microsoft servers.
  • Because the content is being loaded from Microsoft directly and being referred by the phishing domain/site, this can “leak” the phishing domain in the HTTP referrer (see Figure 7)
• If the AiTM server proxies all resources during the page rendering process:
  • The domain the resource is hosted on will be rewritten to that of the AiTM server but the URI and resource name will often remain untouched.
  • This can provide a detection opportunity by monitoring for unique URI paths used by authentication portals, such as the O365 login page dependencies mentioned above, being served on a domain that is not the legitimate domain.

Detection via Authentication/Access

Another notable attribute of AiTM attacks (specifically the reverse proxy nature) is that the user’s input is relayed through the attacker’s server. This means the authentication to the target cloud environment will be seen with the source IP of the phishing server unless the threat actor has set up alternate egress routes. This leads to the following detection opportunities:

• Authentication events originating from the same subnet as the known AiTM server
• Authentication events originating from cloud hosting subnets such as Hostinger/OVH
• Authentication events originating from VPN egress nodes used with services such as ProtonVPN

Hunting & Detection Recap

• Web Proxy Data
  • Outbound traffic to known URI structures relating to login pages on rare domains
  • Microsoft, etc resources being loaded by rare HTTP referrers (such as Microsoft logo present on the login page)
  • Web requests matching <subdomain>.<domain>/<8 Letters> (Evilginx lure URL syntax)
• Email Data
  • Links matching <subdomain>.<domain>/<8 Letters> (Evilginx lure URL syntax)
  • Rare forwarding or inbox rules to exfiltrate data and/or hide security-related emails
• Authentication Data
  • Geographically anomalous logon or session activity
  • Authentication from data hosting subnets or VPN/proxy nodes
  • Above activity followed by MFA modification

Indicators of Compromise

• Lure URL’s
  • login[.]webchainmail[.]xyz/kgwAVHGL
  • login[.]palmbeachbrowardfloridahomes[.]info/SThCPPlj
  • login[.]speedyalmanac[.]cloud/SBxyUYZz
  • login[.]redwoodrancharizona[.]org/IUpGZCZx
  • login[.]a6c2tion[.]info/staqghte
  • login[.]di7rect8r[.]info/xoldxwlr
  • login[.]gen8rat9e[.]info/neyhxwlk
  • adfs[.]consultantchain[.]pro/udleqohr
  • adfs[.]aretestaffinginstitute[.]online/brkulwwe
  • tekj2[.]talcopur[.]com/wTv4/
  • 6zb3b[.]modiveran[.]com/8NEA/?g
  • mukf2[.]odyearth[.]com
  • 6zb3b.modiveran[.]com
  • 0f01.larbawrys[.]com
  • bruwk.abducke[.]com
  • qzgq.abducke[.]com
• Email Senders
  • krikjoe@ankership[.]online
  • apache@ankership[.]online
  • arialaler@gmtradings[.]biz
• Servers hosting content referenced in phishing emails
  • 91.121.237[.]230
• Sites used to relay/embed lure content
  • groathouse[.]ac-page[.]com
• Egress nodes used for routing authentication attempts (commercial proxies)
  • 185.143.223[.]30
  • 185.143.223[.]34

References

• https://help.evilginx.com/docs/guides/phishlets
• https://help.evilginx.com/docs/phishlet-format
• https://help.evilginx.com/docs/guides/lures
• https://github.com/An0nUD4Y/Evilginx2-Phishlets/blob/master/microsoft.yaml
• https://breakdev.org/evilginx-pro-reveal/
• https://www.linkedin.com/pulse/detecting-mitm-attacks-microsoft-sentinel-haakon-baglo-cq7rf
• https://www.eye.security/blog/how-eye-security-can-defend-you-against-evilproxies
• https://blog.sekoia.io/tycoon-2fa-an-in-depth-analysis-of-the-latest-version-of-the-aitm-phishing-kit
• https://www.okta.com/blog/2022/09/mfa-fatigue-growing-security-concern/#:~:text=What%20is%20MFA%20fatigue%2C%20and%20how%20do%20adversaries%20use%20it%20for%20attacks%3F

Bigger Phish – Sneak Peek at What Lurks Below

While investigating activity related to Evilginx and AiTM in general, a different type of infrastructure became visible that did not fit the known attributes of Evilginx (at least the free, out-of-the-box configuration). This infrastructure was immediately discernible as a higher-caliber framework that was built specifically, intentionally, and with great care to fly under the radar and prevent investigation/research. The initial findings relating to this infrastructure are below but will be covered in full detail in a future post.

It can be observed below that all the resources required for the lure page are loaded directly from the AiTM server with unique identifier strings for each (within a general length pattern). This ensures that:

1. No traffic escapes to Microsoft servers and discloses the AiTM server via referrer
2. Names/paths of resources that may be identifiable to the Microsoft login page in web proxy data are changed and randomized to unique strings

In addition to the above defense mechanisms, the POST’ed credentials appear to be sent to a secondary server and not the lure itself (preventing traffic correlation on a single site, see below).

Finally, the site also loads IP lookup tools within the victim’s browser, presumably to collect additional telemetry on the source of the browser.

In addition to the evasion mechanisms shown above, it was observed that logon attempts from the AiTM server (and second layer server that received the POST’ed credentials) originated from a domestic server that had no relation to the first two servers (lure site and server responsible for receiving POST’ed credentials). The attempted logons instead originated from 185.143.223[.]30 and 185.143.223[.]34 which are hosted by “Global Connectivity Solutions Llp” in the USA. This reinforces the hypothesis that these more advanced threat actors leverage custom relays/proxies to route logon activity through domestic nodes closer to the victim’s geolocation.  

After the initial investigation into this infrastructure, it became apparent that this AiTM setup shared various characteristics of “Tycoon 2FA”, an AiTM kit reported on by Sekoia in March of 2024. The following data points shared between the servers seen internally and those shown by Sekoia leads to a high-confidence assessment that they are the same infrastructure or another sharing a significant number of characteristics:

1. Usage of Cloudflare to prevent scanning (see Figure 16)
2. Usage of httpbin for external IP lookups (Figure 20)
3. Similar URL structure
4. Usage of commercial proxies to prevent logon attempts from egressing directly from the AiTM server
5. Hex-based obfuscation (see Figure 21 below)
   • From Sequoia: “The JavaScript code interacts with the HTML of the previous stage to build and display the Microsoft 2FA page.The code is obfuscated using numerous variable renaming with hexadecimal patterns (e.g. “_0x40e211”, “_0x2db5”, “_0x5e1add”), string manipulation (e.g. split, extraction, concatenation), functions overlay, and other code transformations. TDR analysts assess that the Tycoon 2FA developer likely used the open-source tool javascript-obfuscator available on GitHub to obfuscate this stage.”

6. Turnstile C2 Boolean Check (see Figures 22 and 23 below)
   • From Sequoia: “A script attribute that requests an alleged central Command & Control (C2) server and receives either a “0” or a “1”: If the request returns “0”, the script deobfuscates and writes a second HTML code, which is the page embedding the Cloudflare Turnstile challenge; If the request returns “1”, the script proceeds to the next step, which is the fake Microsoft phishing page prompting for email address.“

This more advanced infrastructure demonstrates the complex feature sets available in for-profit AiTM platforms and the threats they pose to organizations without mature detection capabilities. This infrastructure will be covered in full detail in a future post…stay tuned.

↑