In the last couple of weeks, many researchers warns of a new large-scale phishing campaign that is using the adversary-in-the-middle (AiTM) techniques to bypass multi-factor authentication. Following Zscaler researchers Sudeep Singh and Jangadeeswar Ramanukolanu the campaign is designed to reach end users in enterprises focussing on Microsoft services. Last month Microsoft Threat Intelligence Center (MSTIC) shared more information about this new method and upcoming phishing method.

Blog tip: The 2023 edition of the AiTM/ MFA phishing protection guide is released. See: AiTM/ MFA phishing attacks in combination with “new” Microsoft protections (2023 edition)

Recommended read:

Blog information:

Blog is written based on my own opinion.

Blog published: August 8, 2022
Blog latest updated: February 4, 2023

What is AiTM phishing?

Adversary-in-the-middle (AiTM) phishing is not new; and available for some years. Phishing is still the most common type of attack. MFA provides an added security layer against credential theft. Unfortunately, attackers are also finding new ways to bypass the additional security layer (MFA, 2FA).

Based on our threat data, the AiTM phishing campaign attempted to target more than 10,000 organizations since September 2021.

@Microsoft MSTIC

Traditional credential phishing sites collect the user’s credentials and never complete the authentication process. When MFA is enabled for the user it prevents the attacker from logging into the account with the stolen credentials.

Adversary-in-the-middle (AiTM) phishing attacks are used for bypassing multi-factor. AiTM attacks complete the authentication process and captured the token. Currently, there are three main open-source AiTM phishing kits available that are widely known:

AiTM works as a proxy between the victim and target site. Every modern web service implements a session with a user after successful authentication so that re-authentication is not needed for every new page. The session functionality is part of the session cookie provided by the authentication services. The web server with the AiTM phishing kit proxies HTTP packets, based on this technique the website is identical to the original website. Only the URL is the only visible difference between the phishing site and the actual Microsoft sign-in site.

The below image explains the AiTM phishing process (credits: Microsoft)

Evilginx2

NOTE: Configuration of Evilginx2 is not part of this blog post. Multiple online resources described the installation/ configuration of Evilginx2. The official projects site gives more information and details.

Evilginx2 is one of the most popular AiTM phishing kits. Evilginx2 does not serve its own HTML look-alike pages like in traditional phishing attacks. Evilginx2 is a man-in-the-middle attack framework used for phishing login credentials and session cookies. Part of Evilginx2 is a pre-created HTTP and DNS server, which makes it extremely easy to configure – the SSL certificate is part of Lets Encrypt, and is automatically generated.

Demo configuration

For the Evilginx2 demo, the environment is configured based on the following information;

  • IP: 20.25.240.232
  • Domain: logincyberdemo.com
  • Server location: Nort Central US
  • Server OS: Linux Debian 11

Evilginx2 is configured based on a blacklist to avoid automatic crawling and blocking. The Office 365 phishlet redirects to the official portal.office.com URL. To avoid being blacklisted the phishing site can be visited using the authentication key. Cmdlet lures get-url <id> can be used to view the complete URL path. cmdlet Lures shows all enabled phishlets and the ID.

After configuration the phishlet is active on the domain + path; https://login.logincyberdemo.com/acBAlkzp

Sign-in page

The sign-in page captures the default login.microsoftonline.com styling. When signing in with customer credentials the customer tenant branding is applied – which makes the awareness around customer branding useless.

Default Microsoft:

Tenant branded sign-in:

Capture session tokens

Capturing MFA-protected sessions is quite easy. After entering the phishing URL, the user is provided with the Office 365 Sign-in screen. When the username is entered the company branding is directly collected from AzureAD. After providing the password and MFA the session token and credentials are captured.

Cmdlet Sessions<Id> shows the additional information and token.

Import stolen token

Token replay is possible using browsers or applications. For example, use the plugin; Cookie editor for importing the session token.

Protect against AiTM phishing

With the growing enablement/adoption of MFA it is expected that AiTM phishing is growing in the upcoming next years (attackers using new techniques). Protecting against AiTM phishing is important.

Protecting is possible based on various configurations:

  • Phish-resistant MFA solutions (FIDO/ Certificate based authentication)
  • Protect attacks using Conditional Access
  • Monitoring/ protecting using Microsoft 365 Defender/ Azure AD Identity Protection
  • Build-in alerting rules

Let’s start with an overview based on phish-resistant solutions, Protected 2FA/MFA methods, protection part of Conditional Access, and Microsoft security products/ features. Which feature/setting is protecting against AiTM?

✅ = Protected against AiTM ❌ = Not protected against AiTM

Phish-resistant MFA solutions (FIDO/ Certificate based authentication)

Microsoft offers a large set of options for using as a primary authentication method; currently, the following methods are available:

  • FIDO2 security keys
  • Windows Hello for Business
  • Certificate-based authentication
  • Passwordless phone sign-in
  • Phone number and SMS
  • Username and password

Conditional Access can be used to protect the accounts more in-depth. Without additional Conditional Access protection the following methods are protected/ not protected against AiTM:

MethodProtected against AiTM
FIDO2 security keys✅
Windows Hello for Business✅
Certificate-based authentication✅
Passwordless phone sign-in❌
Phone number and SMS
❌
Username and password❌

Only FIDO2, Windows Hello for Business, and Certificate-based authentication are protected against AiTM phishing. Username and password can be enriched with additional Conditional Access protection.

Protected 2FA/MFA methods

When checking the different 2FA/MFA methods; the following is protected against AiTM attacks on top of the non-passwordless methods.

✅ = Protected against AiTM ❌ = Not protected against AiTM

MethodProtected against AiTM
SMS❌
Phone-call❌
Microsoft Authentication App❌
Microsoft Authentication App + Number matching❌
Microsoft Authentication App + Additional context❌
Microsoft Authentication App + Number matching + additional context❌

Protected Conditional Access and additional controls

The answer is simple; there is no protection with only 2FA or MFA; only when enriched with additional conditional access there is protection. The following conditional access controls give protection against AiTM.

✅ = Protected against AiTM ❌ = Not protected against AiTM

MethodProtected against AiTM
Require device to be marked as compliant✅
Require device to be marked as Hybrid Azure AD joined device✅
Conditional Access Session Controls❌ ( limit time window)
Conditional Access Trusted Locations✅
Continuous Access evaluation CAE❌ ( only revokes access in real time when changes in user conditions

Additional protection

AzureAD and additional protecting services part of Microsoft Security give no direct protection against AiTM. Since Evilginx2 Custom Tenant branding is supported.

MethodProtected against AiTM
Custom Tenant branding❌
Azure AD Identity Protection❌ (only alerting)
Microsoft Defender for Endpoint ❌
Microsoft Defender for Cloud Apps ❌ (only alerting)
Microsoft Defender for Office 365❌ (only removing emails including phishing links)

Revoke session and MFA registration

A session can be revoked for all active sessions via portal.azure.com. When the session is revoked the attacker can no longer use the already stolen phished cookie. Always important to check newly added authentication options and change the password directly.

Revoke sessions removes the current authentication; it is NOT prevention after an attempt. Always perform more steps during the analysis. What if the attackers registered other MFA methods?

The attacker can easily go to aka.ms/mysecurityinfo and register a FIDO2 security key as a new method. The next time the attacker can use the FIDO2 security key which is counted as a strong method. Always check of new authentication factors are registered for the specific user.

Passwordless phone sign-in

Passwordless phone sign-in sounds safe right? Evilginx2 supports capturing tokens from passwordless configured users. Passwordless phone sign-in is not protected against AiTM. Evilginx is not capturing the password – the token is captured and can be used easily.

Result in Evilginx; password empty – token visible.

Prevention using Conditional Access

As already explained above, Conditional Access blocks the AiTM phishing attempt (plain text password still captured)

The following Conditional Access policies are important and are successful in blocking/ preventing AiTM. Those access controls rely on additional telemetry, which is not available during the proxy sign-in.

Access Controls

  • Require device to be marked as compliant
  • Require device to be marked as Hybrid Azure AD joined device

Condition

  • Conditional Access Trusted Locations

Result using Conditional Access – Compliant device or AzureAD joined device

Video shows the behavior when using Conditional Access compliant device or AzureAD joined.

The password is still captured (only no additional session/MFA tokens are captured ). Tip; don’t limit conditional access based on specific apps.

Result using Conditional Access – IP location filter

The video shows the behavior when using the Conditional Access IP block. Block access except for trusted IP locations.

The password is still captured (only no additional session/MFA tokens are captured ). Tip; don’t limit conditional access based on specific apps.

Protected using (PIM) Privileged Identity Management?

Common question; Privileged Identity Management (PIM) is enabled with additional MFA for each admin role configured; is this behavior protected by MFA? The answer is; NO

After using the stolen token the MFA is already included – which gives no extra MFA verification for Global Admin roles or other privileged roles.

The below video shows the following:

  1. Import session cookie using Cookie Editor
  2. Sign-in using cookie
  3. Activate PIM role (Additional MFA required)

Microsoft Defender alerts and detection?

Part of Microsoft 365 Defender is additional protection against AiTM phishing. Defender uses cross-signal capabilities for detecting stolen session cookies. The alert with the name; Stolen session cookie was used is generated during the following situation; Cookie stolen using Microsoft Edge browser and attacker attempts to reply the stolen session cookie to access Exchange Online.

The following alerts are important in detecting AiTM phishing:

  • Microsoft 365 Defender
    • Stolen session cookie was used
  • Defender for Cloud Apps
    • Suspicious inbox manipulation rule
    • Impossible travel activity
    • Activity from infrequent country
  • Azure AD Identity Protection
    • Anomalous Token
    • Unfamiliar sign-in properties
    • Unfamiliar sign-in properties for session cookies
    • Anonymous IP address
  • Defender for Office 365
    • Email messages containing malicious file removed after delivery​
    • Email messages from a campaign removed after delivery
    • Creation of forwarding/redirect rule
  • Defender for Endpoint
    • Potential phishing website

After 4/5 days domain which is used for testing is visible in the “Potential phishing website” alert.

Credits to Microsoft; below Advanced Hunting queries can be used for detecting stolen session cookies. More information can be found here. 

let OfficeHomeSessionIds = 
AADSignInEventsBeta
| where Timestamp > ago(1d)
| where ErrorCode == 0
| where ApplicationId == "4765445b-32c6-49b0-83e6-1d93765276ca" //OfficeHome application 
| where ClientAppUsed == "Browser" 
| where LogonType has "interactiveUser" 
| summarize arg_min(Timestamp, Country) by SessionId;
AADSignInEventsBeta
| where Timestamp > ago(1d)
| where ApplicationId != "4765445b-32c6-49b0-83e6-1d93765276ca"
| where ClientAppUsed == "Browser" 
| project OtherTimestamp = Timestamp, Application, ApplicationId, AccountObjectId, AccountDisplayName, OtherCountry = Country, SessionId
| join OfficeHomeSessionIds on SessionId
| where OtherTimestamp > Timestamp and OtherCountry != Country
AADSignInEventsBeta 
| where Timestamp > ago(7d) 
| where ApplicationId == "4765445b-32c6-49b0-83e6-1d93765276ca" //OfficeHome application 
| where ClientAppUsed == "Browser" 
| where LogonType has "interactiveUser" 
| summarize Countries = make_set(Country) by AccountObjectId, AccountDisplayName

Community resources

Elli Shlomo did some excellent work in explaining the complete Pass the Cookie flow and cookie usage flow. Pass The Cookie That Crumbles The Cloud (eshlomo.us)

Fabian Brader did some excellent work in explaining multiple methods which can bypass the MFA authentication. Why using a FIDO2 security key is important – Cloudbrothers

Jan Bakker explains the set-up/ configuration of Evilginx. How to set up Evilginx to phish Office 365 credentials – Janbakker.tech

Other resources

Microsoft: From cookie theft to BEC: Attackers use AiTM phishing sites as entry point to further financial fraud
Zscaler Research: Large-Scale AiTM Attack targeting enterprise users of Microsoft email services