It’s 2024 — Anybody who has ever worked in a corporate role at some point understands what phishing is at a basic level. It starts with receiving an inconspicuous email, clicking the link, entering your credentials, and immediately the security team is calling you to assign multiple hours of phishing training. For those who don’t work in security or a related IT function, the understanding typically doesn’t have to expand further beyond that. However, for those of us who are responsible for managing these threats, there is an ever-evolving landscape of techniques and tactics that threat actors can use to take over user accounts.
Through my experience as an analyst in a security operations center (SOC) that primarily handled clients heavily invested in the Microsoft tech stack, most of the environments I worked in were fully onboarded to Azure and Defender products, with a few exceptions. During my last year in this role, I was deeply involved in a specific environment, which required me to learn and become familiar with common attack patterns and incidents targeting these products, one of the most frequent being adversary-in-the-middle (AiTM) style phishing.
What is Adversary-in-the-Middle phishing?
AiTM phishing is a style of scam where the attacker aims to capture a user’s session token through a sophisticated phishing page(expand on what sophisticated means?). The phishing page then presents a falsified login portal for the specific type of credentials the attacker is looking for (O365, Okta, etc.). The user is intended to believe this is a legitimate login page and enters their credentials. In the past, the average phishing page simply allowed for input of the user’s email and password, which led to these types of compromise being thwarted by multi-factor authentication being in place. Over time, we have seen attackers evolve and now through threat actors utilizing new tools that can conquer the protection MFA offers through advanced tooling.
To understand how an attacker can compromise a user even when they are using a second factor of authentication, we have to first understand how the AiTM phishing infrastructure is set up. Traditional phishing tools aim to collect username and password combinations that threat actors would then attempt logins from at a later point. New tooling that has seen a rise in popularity works from a different angle — they are now forwarding requests from a fake phishing page to a real login page in an attempt to capture the user’s session token in addition to the user’s credentials. With both a web session token and credentials the threat actor can implant the session token into their own login and act out actions as if they performed the authentication themselves. Here is a diagram that helps illustrate how the infrastructure is set up:
Looking at this, we can begin to understand how attackers bypass multi-factor authentication requests. The server that is between the user and the legitimate login page (in this case Instagram) is replaying the requests. It will capture any verification details related to the MFA additionally, showing you almost exactly what you would be seeing if you were legitimately authenticating.
Evilginx and other related tools have the capability to spoof login pages, including but not limited to Office 365, Salesforce, Okta, and more. As an analyst investigating potential phishing incidents, it needs to be understood that a motivated threat actor can likely create a phishing kit for any modern login page.
Several different types of authenticator methods are susceptible to AiTM phishing, including but not limited to:
- Push notifications
- One-time password (OTP)
- Time-based one-time password (TOTP)
- Push notification with number matching verification
It's important to understand as an analyst reviewing alerts which MFA types can be replayed so you can begin to spot patterns in a broader context to recognize compromise. There are different avenues of building detection logic to create alerts and correlation rules that will provide visibility, but ultimately if the analysts fail to understand how the attack works, it can lead to details being missed. In order to better visualize the various steps attackers take in a successful compromise of this manner, the next section will map different actions that they tend to take.
Adapting the Cyber Kill Chain
For those unaware, the cyber kill chain is a security framework that is designed to break down sophisticated cyber attacks into multiple stages by purpose and tooling of each individual step. Originating from defense contractor Lockheed Martin, the kill chain was adapted from a military setting to information security, using it to model intrusions of computer systems.
Here are the 7 steps commonly associated with the kill chain, for better understanding here is a description of each of the steps:
- Reconnaissance
- At this stage, a threat actor chooses their target. They conduct research on their target, whether that be an individual, organization, or a specific application. The goal is to attempt to identify vulnerabilities or entry points to exploit for access.
- Weaponization
- Here the intruder decides which tooling they will use to conduct their attack. Creating tooling is rarely done by most threat actors, as the technical prowess and resources required to develop capabilities that surpass available tools are typically reserved for APTs and the like. Typically we observe that most attacks utilize known tooling that with preexisting signatures and detections.
- Delivery
- The attacker transmits the weapon to their target. Many unique paths of sending data exist, but again there are many tried-and-true methods of delivering a file to a user.
- Exploitation
- Having delivered the weapon, this step details the method by which the malware takes advantage of a vulnerability or misconfiguration to perform unintended actions on a target.
- Installation
- Here the malware installs a point of access, also called a "backdoor", onto the system. This typically involves malware reaching back out to an external resource with the goal of confirming access.
- Command and Control
- Following the installation of initial access, the threat actor then creates a point of persistence on the machine, allowing for 'hands on the keyboard' access.
- Actions on Objective
- The final step of the attack, here the threat actor performs actions to achieve their goals. This includes but is certainly not limited to data exfiltration, data destruction, and encrypting files for ransom.
With an understanding that there are several distinct steps that intruders tend to take, we can then work on applying our understanding of adversary-in-the-middle attack paths to this model.
Reconnaissance 🔍
Attacks are going to perform initial research on their target. This will involve information such as organizational structure, employees, suppliers, and partners. It is common for data to be scraped from social media or company-related websites to identify potential victims for phishing, as well as details like email formats, job roles, and more. A common vector threat actors use is CEO phishing, where new position posts from LinkedIn are scraped and the threat actor sends a text pretending to be their CEO or boss
There are several distinct types of phishing that an attacker can use such as spear phishing, smishing, larger campaigns, and more that are beyond the scope of this article. Thinking from the actor's point of view, it will typically trigger alarms in anti-phishing or other security tooling if a large amount of users begin receiving emails from someone new, so you will often see phishing emails being sent to a small group of users at once. Another common pattern is attackers targeting privileged users within an organization with the hopes of gaining access to sensitive information.
Weaponization ⚔️
In this stage, the attacker creates a convincing phishing email to impersonate an entity that is potentially trusted by the target. The email includes a link that eventually leads to an adversary-controlled phishing page that mimics a legitimate login portal that they know the target uses. This fake login page will intercept and replay credentials, tokens, session cookies, and more.
Typically attackers will not build their own AiTM tooling, instead deciding to use one of several available tools such as Evilginx, Modlishka, Muraena, and even GoPhish when combined with additional modules. I will touch on these tools more in-depth later, for now just understand that there are often indicators we can create detections for that can spot some of the mentioned tools.
Delivery 🚚
Phishing emails are sent to their target. There is little in this step that differentiates non-AiTM phishing and AiTM phishing from each other. Some common patterns include urgency or pressuring statements that encourage clicking, impersonating trusted contacts or brands, and intimidation tactics to worry a user into clicking a link.
Exploitation 🌡️
When the victim clicks the link, they are taken to the fake login page. This login page is often secured via HTTPS, helping it appear authentic to the user. This page can often include company logos or imagery in addition, leaving some users unable to tell the difference between a real login page and a crafted fake one. The user is tricked into entering their login credentials and authenticating via a second factor, which the attack can then capture in real-time.
Installation 💿
The attacker, instead of installing malware, creates their foothold by stealing the session token. Passing this token to their own browser allows the attacker to bypass MFA and login without needing the user to authenticate. The attacker effectively takes over the session, impersonating the legitimate user.
Command and Control (C2) ⚙️
After passing the stolen session token to their own authenticated login, the attacker has full access to the victim's account. This allows them to build persistence in the form of controlling communication of the user. We often see common patterns after a user is compromised that can help detect beyond the initial login when something is wrong.
Although compromising an email or user account doesn't inherently give the attacker access to a host, they could install malware-based persistence people usually think of when they hear the phrase 'command and control', but it is often done in a different manner. Whenever a user is compromised you often see multiple events of different operations at once. Typically they set up new inbox rules that can control the flow of communication to the compromised user. These rules often serve multiple purposes:
- Prevent the user from noticing that they've been compromised. If the threat actor is performing actions on the user’s account that results in an email being sent, such as a password change or verification email, you will see the intruder create inbox rules to automatically move them to the trash. Other common rules include marking important emails as read and redirecting specific keywords.
- Forward all emails from the compromised account to an attacker-controlled external email. This is a form of establishing persistence that also results in potential sensitive data exfiltration. If these rules are not cleaned up during the incident response process it's likely the threat actor will find a trusted source to impersonate to re-compromise the user.
- In some cases, attackers set up an auto-reply rule to send additional phishing messages to those who email the compromised account, continuing the attack across a broader network.
Actions on Objectives🖥️
In the final stage, the attacker moves on to their objectives. Barring APT or hacktivist activity, most threat actors are financially motivated and it helps to work to understand where their targets lie. There are many different ways to profit from cybercrime, but some of the most common include:
- Demanding ransom for an encryption fee
- Fraudulent financial transactions (e.g., invoice redirection or payroll fraud)
- Selling compromised account access to initial access brokers
- Selling sensitive data dumps on the dark web
These actions typically involve further steps that are again outside of the scope of this article, but it is always important to think from the perspective of the intruder in hopes of better anticipating and being ready to respond correctly.
Common AiTM Tooling
Evilginx
Evilginx is a popular phishing tool that proxies legitimate login pages, capturing credentials and session cookies during the authentication. This is one of the most common tools used and as a result has been adapted to work with many different login pages through 'phishlets', essentially a small configuration file that enables Evilginx to target specific websites.
It's normal to see many cybercriminal organizations utilizing Evilginx-powered phishing to target cloud services like Microsoft 365 and Google Workspace. A prominent example is threat actor APT29, also referred to as Cozy Bear and Midnight Blizzard, who have been known to use Evilginx in attacks aimed at high-value targets including government entities.
Modlishka
Modlishka is another AiTM phishing proxy tool that automates the interception of credentials and session tokens during login flows. It's known for its ease of deployment and the ability to seamlessly proxy login sessions. Primarily used by penetration testers and red teamers, it has been linked to threat actors focused on credential harvesting.
Muraena
Similarly to the other tools already mentioned, Muraena operates as an AiTM phishing proxy passing credentials and tokens. It works alongside the tool Necrobrowser, which automates the interaction with the session tokens. The combination of these two tools allows attackers to automate post-compromise actions within the victim's account, oftentimes many that were covered in the kill chain previously.
GoPhish
GoPhish is more commonly used by penetration testers and red teams for phishing simulations but has been adapted by some lower-tier threat actor groups. Groups involved in mass credential phishing campaigns, such as "Silent Librarian (TA407)", have been observed using modified versions of GoPhish to collect credentials from targeted sectors.
Detecting AiTM Phishing and Related Compromise
Creating high-confidence detections for adversary-in-the-middle phishing compromise can be difficult. Every organization has different logging infrastructure, different security tooling, and so much more that makes detecting specific indicators unique to each environment. While certainly not an exhaustive list, there are resources to help understand where one can implement detection rules to provide greater visibility into these styles of attacks.
First and foremost, most SIEMs or tooling that ingests identity and authorization events should allow for coverage of unusual sign-on alerts. This includes unfamiliar location alerts, impossible land speed travel alerts, unusual sign-on property alerts, and more. Detections similar to these, while not specific to AiTM phishing, should indicate that a user potentially has been compromised and you can begin the triage process to determine the scope. These alerts, when correlated with other indicators, can help unravel the attack chain and paint a picture of how the attacker gained access.
There are plenty of vendor articles about AiTM phishing that can include detections and attack breakdowns to better understand what to look out for in your environment. I have a few bookmarked myself that are helpful:
Arjun Trivedi (MSECR)
Ben Nichols, Threat Detection Researcher & Jesse Shreve, Threat Detection Researcher
Justin Safa
Threat researchers are going to do a better job and I could ever about breaking down detection opportunities, but there are some common events to look out for that I have come across:
- Empty device details upon passed AiTM login
- Whenever the authentication token is passed to the attacker, there are typically authentication events created in the identity provider. Due to the way that the AiTM tools work, in the events related to the threat actor you will often see no device associated with the logins. In many environments, users' devices are included in the authentication events, such as Intune registered devices or Okta FastPass. Creating an alert for authentication events without device details present and correlating that alert with unusual sign-on activity can be a great starting point.
- Specific applications are commonly used for AiTM compromise
- While only pertaining to EntraID authentication, it's very common to see specific target applications when an attacker first gains access to a user account. The AiTM tools often pass the session to the attack in a similar manner, and you will see applications that can help point towards this style of attack. One such example is noticing the 'OfficeHome' application in EntraID, while common in normal sign-ons if correlated with other detections is a common indicator of AiTM phishing compromise. There are various public articles with detections present relating to this, including this AiTM threat hunting article from Microsoft.
- New MFA registered to user's account
- Whenever a user is compromised via AiTM, the attacker is passed a session token to use to authenticate. In order to maintain persistence if their session is revoked and to access the account potentially down the road, attackers often register new authenticator methods to the compromised account. This occurs often enough that it is worthwhile to correlate new MFA-registered events with other phishing indicators.
- Session token reuse
- As obvious as it sounds, detections can be created to determine if a session token has been used with multiple different authentication properties. For example, if a user first successfully authenticates from their normal work location, then you later see an event utilizing this session token to perform activities from a completely new location, you can hypothesize that the user has had their session token hijacked.
In this section, I've talked about several different indicators that can help point towards detecting a compromised account. We've built a model of what these attacks usually look like earlier with the cyber kill chain, using that same knowledge we can begin building a threat model that helps correlate all these lower-confidence indicators into a high-fidelity detection. In various security tooling, this can be done in different ways, so I will begin by laying out some case management terminology:
- An alert is a preliminary indicator of a potential problem.
- This can be a deviation from normal user behavior, risky actions that need to be monitored, a threshold reached for a certain rate of actions, or so many other occurrences that you would want to have some watch over.
- Alerts don't require actions on their own, but correlated into an incident they can become issues that need to be dealt with.
- An incident is an undesired cyber security event that has occurred and needs a solution.
- Incidents occur all the time in normal business operations and are not specific to cybersecurity, but certainly relate. They often disrupt the operations, services, or functions of an organization and as a result, need to be remediated with some sense of urgency.
- In our case, alerts can tell the story of an incident. To illustrate, say you have an incident where a user executed malware on their machine and had their credentials stolen. In this case, there would potentially be alerts for visiting the website the malware was hosted on, downloading the malware, executing the malware, and any actions the malware performed on the machine. These are all separate detections that can be created and then correlated to provide analysts with a larger-picture understanding of an incident.
Now that there is an understanding of the distinction between an alert and an incident, we can build on that and apply it to our AiTM phishing case. In an ideal world, a security team can create and tune detections in place for some of the indicators mentioned above including:
- Unfamiliar Sign-On Locations
- Impossible Travel/Land Speed Violation for a User
- Visits to domain with high confidence for phishing
- Email security product alerts
- MFA Prompt Failures
- New Inbox Rule Creation
- Session Token Reuse
- New MFA Registration
- Spike in outbound emails
These indicators just scrape the surface on what is possible to detect and alert on relating to business email compromise.
With all of these alerts present in an environment, we can then begin to build out a rule that checks for a certain threshold of indicators that can be configured. For example, a high-priority incident could be triggered if alerts for unfamiliar sign-on, session token reuse, and new inbox rule are present for a specific user within a short timeframe. This creates a very high-value detection that also reduces the analyst's burden of triaging and timelining each isolated alert.
Prevention Methods for AiTM Phishing
As threat actor capabilities mature, the need for blue team practitioners to adapt and develop responses to help ward off new methods increases. Thankfully there are many bright minds out there solving these issues for us, and they are so gracious as to share their findings for us to mooch from and bolster our own detection landscape.
It is important to share multi-factor methods that are not susceptible to AiTM phishing methods mentioned so many times already. These phishing methods rely on client-side secrets being stored and passed in mediums that can be interacted with - in this case session tokens and cookies. In order to prevent this from being possible we must consider alternative methods that work in other ways.
Hardware-based Multifactor Authentication
Most security-focused professionals will have at least heard of a YubiKey by now, but if not it is a hardware authentication key that plugs into a machine's USB-port to provide physical proof of a second factor for authentication. This type of authentication uses FIDO (Fast Identity Online) to provide the second factor of authentication, while beyond the scope of this article essentially FIDO uses public-key cryptography to make user authentication more secure and convenient. The private key in this scenario is stored on the user's physical device, which is where the phishing-resistant mechanism comes into place.
An attacker cannot access this key through a phishing page like they can a normal number or approve/deny an MFA challenge. As such, if the hardware authenticator is a required method to authenticate, the attacker cannot relay the MFA challenge through their AiTM phishing infrastructure as they normally would. Hardware-based keys are becoming increasingly inexpensive, and it is best practice for at least privileged accounts with sensitive access to utilize a physical factor in their authentication suite.
Conditional Access
Another protection that can be applied is enabling conditional access policies for user authentications. Identity providers such as Microsoft often have policies that can be configured and applied to restrict successful authentication events to be within specific parameters. For example, one such policy could be only allowing a user to login from a specific subnet range. Conditional access policies are a cornerstone of modern identity protection strategies and can work to protect against AiTM compromise.
Microsoft Partner and CEO of Patriot Consulting Joe Stocker wrote about his findings looking into various conditional access policies from Microsoft and the effect EvilGinx2 had when they were enabled. In his article linked here, Joe's research revealed that 7 of his 13 tested policies prevented successful MFA bypass, highlighting how important it is to have a layered defense.
Wrapping Up
AiTM phishing highlights just how quickly adversaries can adjust to outpace traditional defenses. As SOC analysts, we face the challenge of staying informed on these evolving techniques and adapting our response strategies. AiTM attacks are particularly concerning because they leverage stolen session tokens to bypass multi-factor authentication, a security measure many users rely on. Understanding the nuances of these attacks enables us to respond more effectively, from setting up meaningful detections to layering protective measures like hardware-based MFA and conditional access policies. As we keep refining our defenses and learning from real-world threats, the role of the SOC is increasingly about preempting the next move of sophisticated attackers. By taking a proactive approach, we’re not just mitigating threats—we’re working to stay a step ahead in a game that’s constantly changing.
Follow me on twitter/X @tresscrossnet
Connect with me on LinkedIn @jasonwalker777
