Responding to Adversary in the Middle attacks

Adversary in the Middle Attacks

With Microsoft disabling basic authentication by default and more organizations using Multi-Factor Authentication (MFA), Adversary-in-the-Middle (AiTM) phishing attacks have seen a rise. While AiTM isn't a new tactic, its frequency is growing as traditional methods of compromising M365 accounts, like simple username and password phishing, become less effective. As MFA becomes more widespread, threat actors are evolving their approaches. We’ve observed this shift in our own Business Email Compromise (BEC) cases, with many of the incidents we investigate nowadays involve AiTM. In this blog, we’ll explore what AiTM is, how to detect it using available logs, how to respond when it’s identified, and most importantly, how to prevent it from occurring in the first place. This blog focuses on incident response.

What is an Adversary-in-the-Middle Attack?

An AiTM attack is a type of phishing where the attacker positions themselves between the victim and a legitimate service to intercept or even manipulate communication. This usually occurs between the user and trusted platforms, such as corporate email systems or cloud services. AiTM essentially acts as a middleman between the user and the target service. Modern web services typically establish a session after you log in, saving you the hassle of re-entering credentials each time you interact with a site. While this convenience benefits users, it also creates an opportunity for attackers.

The attack usually begins with a phishing email that lures the target to click on a malicious link. Instead of reaching Microsoft's real authentication page, the user is redirected to the attacker’s proxy server. This server then forwards the login requests to Microsoft while simultaneously capturing sensitive information, like login credentials and authentication tokens. The user sees what seems to be a normal login process, including MFA, unaware that their login details and session tokens are being harvested. The attacker can then use these stolen credentials and tokens to bypass traditional MFA protections, gaining unauthorized access.

The figure below is a well-known illustration created by Microsoft that illustrates the AiTM phishing process.

‍

Microsoft recently released the Microsoft Digital Defense Report 2024, which is a pretty long (but good) read at 114 pages. In the report, Microsoft mentions that over the past year, they've seen a huge 146% increase in AiTM phishing attacks, with their detections showing about 39,000 incidents every day. This matches what we've been seeing in our own cases, which is why we decided to share some insights on the topic in this blog.

Attacker toolkit

The most well-known and widely used phishing kit remains Evilginx. However, there are other open-source tools that are also commonly used, including:

• EvilProxy
• Modlishka
• EvilnoVNC

In addition to open-source tools, two active non-open-source tools recently seen in the wild are:

• Mamba 2FA 
• Tycoon 2FA

Sekoia.io has published excellent write-ups on both of these(Mamba,Tycoon) , which we recommend reading if you're interested in this topic. For this blog, we used Evilginx in combination with real incident data to demonstrate the different detections available when conducting incident response for an AiTM attack.

Detection

Detecting AiTM attacks in M365 and Azure environments can be challenging, as these attacks often involve techniques to bypass traditional security measures like MFA. However, there are specific logs and indicators that can help detect such attacks. Here's how you can approach detection during incident response using M365 and Azure logging.

Sign-In logs

Sign-In Logs are the primary source for detecting AiTM attacks, as they capture all authentication events within Microsoft Entra ID (formerly Azure AD).

‍Common Indicators in AiTM Detection
During incident response engagements, we often observe specific patterns in Sign-In Logs that are indicative of AiTM phishing attacks. One common indicator is the presence of _OfficeHome as the application in the logs. This is the main portal where most users access Microsoft 365 services like Outlook, Word, Excel, and Teams, which makes it a frequent target for attackers.

Phishing tools, especially EvilProxy, commonly use office.com to trick users into submitting their credentials. As a result, when an attack is successful, OfficeHome appears as the application through which a user has logged in. However, looking for OfficeHome alone is not sufficient for reliable detection. This method often generates a large number of false positives, making it difficult to spot suspicious activity effectively.

For example, in a recent case, a search for successful logins through the OfficeHome application resulted in 1,204 events, too many to efficiently identify potential threats.

Device ID
Another indicator to analyze the _{Device ID} field, when this field is empty it means that it's not a device registered or joined to Entra ID. So searching for empty Device ID fields, will get less results. To drill down even further, analyse the results for unusual IP addresses. Since the attacker is coming from a different IP address than the real user.

Risk Detail

If you want to make it into a continuous monitoring detection rule, we recommend incorporating the _{Risk Detail} field. Specifically, focus on results where the value is not none as this indicates Microsoft deemed it to be of a certain risk.

Using a combination of these fields, we were able to identify several users that were compromised.

‍

Sample Detection Query for AiTM in Sign-In Logs

The following query can be used to detect suspicious behavior related to AiTM phishing attempts in the Sign-In Logs:

_SigninLogs

_{| where Status.errorCode == 0}

_{| where ResourceDisplayName == "OfficeHome"}

_{| where RiskDetail != "none"}

_{| where UserPrincipalName has "@"}

_{| extend DeviceId = tostring(DeviceDetail.deviceId)}

_{| where DeviceId == ""}

_{| extend Browser = tostring(DeviceDetail.browser)}

_{| extend OS = tostring(DeviceDetail.operatingSystem)}

_{| project CreatedDateTime,}

        _{UserPrincipalName,}

        _IPAddress,

        _{AppDisplayName,}

        _{AuthenticationProtocol,}

        _{ResourceDisplayName,}

        _DeviceId,

        _UserAgent,

        _Browser,

        _OS,

        _{AutonomousSystemNumber,}

        _RiskDetail,

        _RiskState‍

This query filters the log for the following key factors:

• Successful logins (errorCode = 0)
• OfficeHome application
• RiskDetail is not set to "none" 
• Missing Device IDs 

Identifying multiple IP addresses with the same Session ID

Another thing we often observe when investigating AiTM incidents is that the same _{Session ID} appears across multiple IP addresses. Normally, when a new device or IP address authenticates, a new Session ID is generated. However, when AiTM occurs, the attacker uses the same Session ID as the compromised user because the session is hijacked.

‍

This gives us detection opportunities by looking for instances where the OfficeHome application has a session with multiple IP addresses. We can do this by running the following query, where the uniqueIPs field contains the number of IP addresses found in the session:

_SigninLogs

_{| where Status.errorCode == 0}

_{| where ResourceDisplayName == "OfficeHome"}

_{| extend statuscode = tostring(Status.errorCode)}

_{| extend userPrincipalName = tostring(UserPrincipalName)}

_{| extend clientIP = tostring(IPAddress)}

_{| extend appDisplayName = tostring(AppDisplayName)}

_{| extend createdDateTime = todatetime(CreatedDateTime)}

_{| extend MinuteWindow = bin(createdDateTime, 15m)}

_{| extend Browser = tostring(DeviceDetail.browser)}

_{| extend OS = tostring(DeviceDetail.operatingSystem)}

_{| summarize uniqueIPs = dcount(clientIP),} 

          _{ips = makeset(clientIP),} 

          _{minTime = min(createdDateTime),} 

          _{maxTime = max(createdDateTime),}

          _{arg_max(createdDateTime, *)} 

          _{by userPrincipalName,} 

          _{MinuteWindow,} 

          _{appDisplayName,} 

          _statuscode

_{| where uniqueIPs > 1}  

_{| project createdDateTime,}

          _{userPrincipalName,}

          _{ipAddress = clientIP,}

          _{appDisplayName,}

          _{AuthenticationProtocol,}

          _{ResourceDisplayName,}

          _UserAgent,

          _Browser,

          _OS,

          _{MinuteWindow,}

          _uniqueIPs,

          _minTime,

          _statuscode

_{| order by minTime asc}

This query performs the following:

• Identifies sessions with multiple unique IP addresses during a 15-minute window.
• Summarizes the session activity to highlight unusual patterns of IP usage.
• Filters for instances where unique IPs > 1, suggesting that the same session was accessed from multiple locations (likely indicative of session hijacking).

Identity Protection

Microsoft Entra ID Protection helps organizations detect, investigate, and remediate identity-based risks. It uses advanced machine learning to identify sign-in risks and unusual user behavior to block, challenge, limit, or allow access. We recently blogged about using Identity Protection events for incident response, check it out here.

‍Challenges in AiTM Detection with Identity Protection

While Identity Protection is a powerful tool, its performance in detecting AiTM (Adversary-in-the-Middle) phishing attacks can be inconsistent. These attacks often bypass multi-factor authentication (MFA) by stealing session tokens, making real-time detection difficult. In our recent testing, Identity Protection failed to detect an AiTM attack in real-time when a VPN was used from a foreign location. However, it 12 hours later flagged the session with an offline detection due to an anomalous token detection, which according to Microsoft indicated:

There are abnormal characteristics in the token, such as an unusual token lifetime or a token played from an unfamiliar location.

‍

Real life case

During an AiTM phishing wave, four unique users were compromised, through the Mamba 2FA AiTM phishing kit. While writing this blog we found out that this IP address was also mentioned in the blog we shared earlier by Sekoia. We were able to identify this quickly because Microsoft had flagged these events as risky detections.

This highlights the importance of checking Risky Sign-Ins, Risky Users, and Risk Detections when performing incident response. The detections can provide an excellent starting point by showing compromised users and suspicious IP addresses.

‍

Unified Audit Log

The Unified Audit Log (UAL) in M365 is a crucial resource during investigations. The UAL can be used for detecting AiTM phishing attacks. It contains similar data as the Sign-In logs since the UAL contains events for the AzureActiveDirectory workload. 

Application Identification Using App ID
The application name is not directly logged in UAL like within the Sign-In logs, but its corresponding App ID can be used to identify it. For the OfficeHome application, the relevant App ID is:

• OfficeHome App ID: 4765445b-32c6-49b0-83e6-1d93765276ca

Session ID Anomalies
The Session ID field is crucial in identifying session hijacking attempts. During AiTM attacks, attackers reuse the victim's Session ID across different IP addresses, which is unusual in legitimate scenarios. Steps for analysis just like with the Sign-In logs include:

• Look for multiple IPs linked to the same Session ID within a short time window.
• Check for geographic anomalies, such as login attempts from different countries using the same Session ID.

Device ID
The Device ID can be a useful indicator when investigating AiTM activity. In most cases, AiTM attacks result in logins where the Device ID is empty. In the Sign-In logs this field is always present, however, in the UAL it’s only there if it exists. If the DeviceProperties field is present, the Id attribute will contain the Device ID, like this:

"DeviceProperties": [

    {

        "Name": "Id",

        "Value": "35e661eb-ea45-4445-a6fa-95c0b57fd8a0"

    }

]‍

Remediation

Remediating an AiTM  attack involves a series of steps to disrupt the threat actor's access.

Revoke Active Sessions

One of the most important steps in remediating an AiTM attack is revoking all active sessions for compromised users. Since attackers often steal session tokens, simply resetting passwords is not enough. Session revocation ensures both the legitimate user and the attacker are forced to re-authenticate.

You can either revoke all active sessions via the Microsoft Entra ID or Microsoft 365 Admin Center.

It’s important to note that applications can cache tokens locally. This can allow attackers limited access even after session revocation or password resets. The reason those applications store tokens/credentials locally is allowing users to remain signed in even when they temporarily lose internet connectivity. Otherwise you would get logged-out every time your system can’t validate the token/credentials against Microsoft servers.

Reset Passwords and MFA Sessions

When the token is stolen during the AiTM attack the password is also stolen by the threat actor since they were in the middle of your authentication attempt with the Microsoft systems. Therefore it is recommended to reset the passwords, and even on all other applications/websites where this password is re-used.

Additionally, resetting MFA sessions ensures the user must complete a fresh MFA challenge.

‍Identity Rogue Authenticators

Threat actors may attempt to add rogue authenticators to maintain persistence access to compromised accounts. These rogue authenticators exploit stolen credentials to bypass future MFA challenges, allowing attackers to regain access even after session revocations.

Incident Response

Based on your incident response investigation, you might identify actions performed by the threat actor that need to be remediated, such as forwarding rules being created, new applications being registered, etc.

Prevention

To prevent AiTM attacks, it’s important to implement strategies that strengthen authentication and limit the attacker's ability to bypass security measures. By using Conditional Access policies and multi-factor authentication (MFA) methods that are resistant to these types of phishing attacks, organizations can significantly reduce the risk. Below are some important prevention measures:

‍Conditional Access Policies

To help prevent AiTM attacks, a great tool to implement are Conditional Access policies. These policies ensure that security measures, like Multi-Factor Authentication (MFA), are applied in high-risk scenarios, making it more difficult for attackers to bypass authentication. Below are some strategies you can use to improve the security:

‍

• Location-Based or Device-Based Policies
  Set up location-based or device-based Conditional Access policies that enforce MFA when users access sensitive resources from unfamiliar networks or devices. For example, if a user logs in from a country or device that they don't typically use, MFA would be required to proceed.
  

• Enforce MFA for High-Risk Activities
  Apply Multi-Factor Authentication when users engage in high-risk activities such as logging in from new or unfamiliar devices, accessing accounts from foreign locations, or performing sensitive actions like changing passwords. This provides an additional layer of security during critical operations.
  ‍
• Device Compliance Checks
  Use Conditional Access to ensure that only hybrid-joined devices (i.e., devices that are managed through Microsoft Entra or Intune) and that have passed compliance checks can access critical resources. This ensures that only trusted, well-managed devices are granted access.
  
  
• Require Strong Authentication Methods
  Implement Conditional Access policies that require strong, phishing-resistant authentication methods, such as Windows Hello for Business, FIDO2 security keys. This strengthens the authentication process by leveraging methods that are difficult for attackers to bypass.
  
  
• Restrict Token Use to Issued Devices
  Enable the feature that restricts the use of authentication tokens to the devices from which they were originally issued. This feature is currently in preview and available for Office 365 Exchange Online and SharePoint Online. This additional measure ensures that even if attackers intercept a token, it cannot be used on unauthorized devices.

‍

Phishing Resistant MFA

Microsoft Multi-Factor Authentication (MFA) is a security measure designed to protect users from identity theft and unauthorized access, such as Account Takeover and AITM attacks. With AiTM increasingly being used, more and more traditional MFA methods (like SMS-based verification) are no longer enough to protect you. To combat this, Microsoft implements more advanced phishing-resistant authentication methods:

‍

• FIDO2 Security Keys:
  FIDO2 security keys offer a form of phishing-resistant authentication. These keys use public key cryptography, where the private key is stored securely on the device and never transmitted over the network. This design prevents interception of sensitive information. During authentication, the key directly communicates with the server, ensuring that attackers cannot trick users into revealing credentials or bypassing multi-factor authentication (MFA).
  
  
• Certificate-Based Authentication:
  Certificate-based authentication uses digital certificates to verify a user or device’s identity. Unlike password-based authentication, which can be targeted by phishing attacks, this method relies on cryptographic keys. The certificate contains a public and private key pair, with the private key securely stored on the user’s device. For successful authentication, the device must present the correct certificate, which the server verifies.
  
  
• Windows Hello for Business:
  Windows Hello for Business is an authentication method that replaces traditional passwords with biometric or PIN-based authentication. It uses a public-private key pair stored locally on the user’s device, ensuring that no credentials are transmitted over the network. By leveraging biometric features like facial recognition or fingerprint scanning, Windows Hello simplifies authentication while improving security.

‍

Detect AiTM phishing on the Microsoft Login Page

Our friends at Zolder have conducted some interesting research on using custom CSS on the Microsoft login page, you can try it yourself at didsomeoneclone.me. This CSS implementation alerts users when they visit an AiTM phishing site. It’s an effective method not only for detecting phishing attempts but also for preventing successful attacks by warning the victim in real-time. This proactive approach helps mitigate the impact of phishing before the attacker can gain unauthorized access.

Conclusion

Adversary-in-the-Middle attacks are a growing threat and will most likely continue to be a top threat in 2025. In this blog we showed how you can leverage logs like the Entra Sign-In Logs, Identity Protection logs and the Unified Audit Log to identify AiTM activity. Once you have uncovered an attack, make sure to investigate the period for which the threat actor had access to the environment. From a remediation perspective, make sure to perform session and token revocation to block current access. After that perform password and MFA resets to prevent future access. From a prevention perspective the most effective method is to implement conditional access policies that include phishing-resistant MFA methods such as passkeys and hardware tokens. Another good one is to prevent logins that are deemed risky by Entra Identity Protection.

Want to know more about incident response in Microsoft cloud environments, take our training at your own pace via our OnDemand offering or join one of our live events.

‍About Invictus Incident Response

We are an incident response company and we ❤️ the cloud and specialize in supporting organizations facing a cyber attack. We help our clients stay undefeated!

🆘 Incident Response support reach out to cert@invictus-ir.com or go to https://www.invictus-ir.com/24-7

🔐 Want to know if your Microsoft Cloud environment is incident ready, book your Cloud Insights assessment, go to https://www.invictus-ir.com/services/cloud-insights

📘 You can support our work by signing up for our cloud incident response trainings, go to https://academy.invictus-ir.com/

‍