Adversary-in-the-middle phishing attacks are still more common in use. Since the removal of basic authentication from Exchange Online more and more attackers are using more modern attacks like adversary-in-the-middle phishing, cookie theft, QR code phishing, and other used attacks.

Last year I blogged about several modern attacks and explained MFA fatigue, AiTM, MFA Fatigue, PRT, OAuth attacks, and more. Time for a new update focussed on adversary-in-the-middle phishing.

Tips for preventing against new modern identity attacks (AiTM, MFA Fatigue, PRT, OAuth)

How to mitigate MFA fatigue and learn from the Uber breach for additional protection 

Protect against AiTM/ MFA phishing attacks using Microsoft technology

With all the recent new features and additional mitigations from Microsoft, it is time for a new in-depth 2023 update on what we can do against AiTM/ MFA phishing with the recently announced features. Recently Microsoft announced a new feature that “require token protection for sign-in session (preview)” – the most asked question; is token protection able to mitigate the AiTM risk? and what can we do extra against AiTM? Recently Microsoft releases Automatic attack disruption in Microsoft 365 Defender with support for adversary-in-the-middle attacks (AiTM) attacks.

MFA is not the end all solution to identity security challenges. With only MFA there is still a risk for more modern attacks (MFA fatique, AiTM, PRT, OAuth Attacks and more). Recommended is to follow the new attacks/ techniques and improve the security protection with new controls.

Jeffreyappel.nl

Blog information:

Blog Published: July 3, 2023
Blog updated: February 7, 2024

AiTM still a risk?

AiTM attacks are still actively used. Recently Microsoft Defender Experts uncovered a multi-stage adversary-in-the-middle (AiTM) phishing and business email compromise (BEC) attack against the backing and financial services organizations. The attack originated from a compromised trusted vendor and transitioned into a series of AiTM attacks and follow-on BEC activity spanning multiple organizations.

Recommended/ must read Detecting and mitigating a multi-stage AiTM phishing and BEC campaign | Microsoft Security

Microsoft Threat Intelligence

In a stolen session cookie replay attack, the attacker used the valid stolen cookie to impersonate the user. Both techniques are commonly used during attacks. With the stolen session cookie, it is possible to generate a new access token, to allow longer access in the environment, commonly the attacker registers a new MFA method to make sure there is a new registered MFA method.

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).

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 the 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)

What is new in the mitigation/ prevention?

Recently Microsoft announced new technologies for additional mitigation/ prevention:

Token protection

One of the recently announced features is the Token Protection for Sign-in Sessions. During the Microsoft secure event, Microsoft announced a new feature called Token Protection for sign-in sessions. This feature is designed to combat token thefts and known replay attacks.

With the use of Token Protection (public preview) the token can only be used on the intended device. When enforced via Conditional Access, tokens authenticating against resources must come from the device where the user originally signed the device. Now the question is – how protects token protection tokens stolen via the AiTM technique, or is there no additional protection against the stolen token?

Defender Threat intelligence/ Defender TI

With the use of Defender TI there is the option to investigate websites based on collected threat intelligence data. In this blog, we will deep-dived into the capabilities of Defender TI and its combination with AiTM/ MFA phishing attacks. What is visible when websites are detected/ crawled in Defender TI?

Alerting in Microsoft 365 Defender

Microsoft improves the detection when users have potentially opened AiTM websites from multiple sources. In this blog, we will check the alerting and additional hunting options more in-depth.

Single portal

Last year there was still a migration ongoing to integrate Defender for Cloud Apps/ Azure AD Identity Protection in the Microsoft 365 Defender portal. Currently, the products are integrated and all data is available directly in the Microsoft 365 Defender portal – really useful for viewing the complete XDR timeline in Defender.

Automatic attack disruption in Microsoft 365 defender

Automatic attack disruption supports the AiTM flow. Automatic attack disruption is designed to contain attacks in progress, limit the impact on an organization’s assets, and provide more time for the SOC to remediate the attack fully. More information:

Defender TI/ Defender Threat Intelligence

Previously, my test website for AiTM was with the domain; logincyberdemo(dot).com. Defender TI has detected the reputation score with a max of 100 and detected it as part of the Microsoft Blocklist watchlist/ emerging threat actor Storm-0563. Previously known as DEV-0563

Now the question is; can we hunt and detect websites using AiTM with the use of Defender TI? The answer is yes. All not for all websites – of course; Defender TI needs to detect the components from the crawlers and logic for scanning websites.

With the host pairs and child hostname logincdn.msauth.net it is possible to detect websites where the child hostname is used. When checking in Defender TI my test AiTM website is detecting the following host pairs:

Interesting is the logincdn.msauth.net/aadcdn.msftauth.net child hostname. When checking the host pair the relation can be detected between the child hostname and the cause. img.src is used via child hostname res.cdn.office.com/ aadcdn.msftauth.net. Of course; the CDN is different and can be changed.

When opening the website: login(dot)logincyberdemo(dot)com in the developer/ code view the following data is visible. It is using aadcdn.msauth.net and aadcdn.msftauth.net DNS-prefetch. When looking more in-depth there are components used as part of the aadcdn.msauth.net.

When checking the domain aadcdn.msauth.net in Defender TI and checking the complete dataset, we can see there are 433k host pairs detected.

When filtering on the cause and child hostname we can view all websites using the components. The following filters are commonly used for AiTM phishing websites:

  • Child hostname: aadcdn.msauth.net
  • cause: div.style

Or

  • Child hostname: aadcdn.msauth.net
  • cause: img.src

Or

  • Child hostname: aadcdn.msauthimages.net
  • cause: div.style

It detects websites like:

  • microsoftonline-outlook(dot)com
  • login.microsoftonlline(dot)de

For domains where the registrant is not Microsoft, most commonly malicious websites are privacy protected – the domains are sometimes flagged with the max reputation of 100 and severity rule: This site hosts a phishing attack, which is impersonating brand: Microsoft

Another interesting view is the cause div.style and hostname res.dcn.office.com. The result is websites like:

  • o365.sign-in(dot)UK
  • ms-office-admin(dot)com
  • mircosoftonline(dot)net

Detonation analysis

when searching the domain with the http:// value in Defender TI. The result is the detonation analysis. The detonation analysis shows the screenshots/ HTTP response code and final URL/ including resolved IP address. In this case, the following domain is targeted as score 100 with the rule: Indicator related to a known Phishing campaign.

Detonation analysis shows the full image where the Microsoft login site is visible.

In the above example, the website is using the host pair img.src from the child hostname logincdn.msauth.net

Storm-0928

The activity group tracked by Microsoft as Storm-0928 (DEV-0928) is a cluster of threat actor activities using the adversary-in-the-middle phishing campaign that MSTIC monitored since September 2022. in Defender TI the EvilProxy intel explorer article is visible including AiTM proliferation through EvilProxy and the flow from initial access to Cookie replay.

Storm-1101

Storm-1101 offers an open-source kit that automates setting up and launching phishing activity and provides support services to attackers.

More information: DEV-1101 enables high-volume AiTM campaigns with open-source phishing kit

Evilginx 3.0

Evilginx3.0 was recently launched. The release contains a couple of new features and fixes. Again big thanks to the creator Kuba Gretzk for the release of the Evilginx3 toolkit. Evilginx is a man-in-the-middle attack framework used for phishing session cookies/ credentials. With the use of Evilginx, we are able to simulate the AiTM phishing techniques and capture tokens and passwords.

The new version of Evilginx includes a couple of new features. One of the main improvements is the improved TLS certificate management/ and session token extraction from the response body or HTTP header. View the below sources for all new features part of the Evilginx3 release.

Interested in how to install Evilginx3? View all online documentation created by Kuba Gretzky.

For testing purposes, I configured Evilginx on a simple Debian 11 server and configured the domain: logincyberdemo.com, and performed the following commands for configuring Evilginx for the first time. 

config domain <domain>
config ipv4 <IP>

When the IP and domain are configured we are able to configure and enable the phishlets. Since version 3.0 is not delivered with any pre-created phishlets I modified the o365 phishlets with a couple of small tweaks to make it work for version 3.0.

With the commands the phishlets are enabled on the domain logincyberdemo.com and the phishlet is enabled. 

phishlets hostname o365 logincyberdemo.com
phishlets enable o365

With the phishlet up and running, you can now create a lure, which will become a phishing link. View all lures with the command:

lures create o365
lures

With the lures get-url command, it is possible to grab the complete URL link:

lures get-url 0

Now it is time to open the URL and paste it into the web browser for simulating the phishing attack.

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 in the prevention capabilities.

Default Microsoft styling:

Tenant branded sign-in:

Evilginx 3.0 Evilginx Mastery course

With the release of Evilginx 3.0 there is a new Evilginx Mastery course published by the Evilginx creator Kuba Gretzky.

The Evilginx Mastery course is recommended where you will learn about building phishlets/phishing methods/remote server deployment and more. This course is developed with a strong red-teamers focus from the attacker’s point of view.

You can find/ buy the course here. (No affiliate link)

Protections/ mitigations against AiTM phishing

With the growing enablement/adoption of MFA, AiTM phishing is expected to grow in the upcoming years (attackers using new techniques). Additional mitigations against AiTM phishing are important.

Protection/ mitigation 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, the protection part of Conditional Access, and Microsoft security products/ features. Which feature/setting is protecting against AiTM?

✅ = Protected against AiTM ❌ = Not protected against AiTM

❗️IMPORTANT: Below explains the protected against AiTM value. Keep in mind there is no direct protection; it is mitigating the risk when some of the controls are used. Simple reason: When a Windows Hello for Business user gets to the AiTM phishing page, there is a prompt for a non-phishing resistance authentication method. Limiting the available methods is important or using authentication strengths to only enforce phish-resistant MFA methods.

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

Microsoft offers a large set of options for the 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 (mitigation) 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, all the access is blocked due to the Conditional Access restrictions.

Windows 11 with Windows Hello for Business and the TPM are FIDO2-certified authenticators. This means you don’t need any “Extra” hardware to use industry-wide phish-resistant standards.

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 (mitigation) 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 (mitigation) 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 when the attacker can use the session cookie)
Conditional Access Trusted Locations✅
Continuous Access Evaluation CAE❌ (only revokes access in real-time when changes in user conditions)
Entra Global Secure Access✅

Tip: Enable Continuous Access Evaluation CAE; when the user conditions are changed (user/sign-in risk level) the access is real-time revoked based on the configured actions. Recommended is to read this blog from Fabian Bader with some in-depth explanation of Continuous access evaluation. Continuous access evaluation | Cloudbrothers.info

Additional protection

AzureAD and additional protecting services part of Microsoft Security give no direct protection against AiTM. Since Evilginx3 Custom Tenant branding is supported for taking the complete branding of the original website. The other products are in general not blocking the initial token theft, it helps with mitigating the risk. Atack Disruption capabilities are mitigating the risk of further damage to the environment.

✅ = Protected against AiTM ❌ = Not protected against AiTM ❗️= additional controls/ mitigations/ insights all not preventing the direct token from being captured.

MethodProtected (mitigation) against AiTM
Custom Tenant branding❌
Azure AD Identity Protection❌ (only alerting)*
Microsoft Defender for Endpoint ❗️ (only alerting + blocking known AiTM websites)*
Microsoft Defender SmartScreen❗️(blocking known AiTM websites)*
Microsoft 365 Defender❗️(Attack Disruption capabilities)*
Microsoft Defender for Cloud Apps ❌ (only alerting)*
Microsoft Defender for Office 365❌ (only removing emails including phishing links)*

* The method does not protect against the initial capturing flow. The product can help with additional protections/ signals/ alerts and detect potential other signals related to AiTM attacks.

❗️Automatic attack disruption is powered with the Microsoft 365 XDR correlation of events and is able to leverage Microsoft-based XDR response actions (Device contain/ Disable user). Attack disruption is not protecting the initial token flow – it can be prevented when the alerts are detected based on collected signals. The tool will automatically take necessary actions to disrupt the attack, including blocking the compromised account or revoking stolen session cookies to limit the potential risk.

❗️Microsoft Defender for Endpoint is able to block known websites via the Network Protection/ SmartScreen component. It is not protected against the AiTM token flow; it can prevent initial access to the phishing site. The same is for the other components part of the Defender 365 ecosystem; there is no direct protection for stolen tokens – it can prevent the initial access via websites/ mail or other methods or detect other alerts and change the risk of the user

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. Malicious attackers register new devices as part of the authentication methods; with this, there is a new “trusted” devices for future sign-ins.

Revoke sremove 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 if new authentication factors are registered for the specific user in the timeframe.

Token protection (preview)

Microsoft released a couple of months ago the new Token protection capabilities. Token protection attempts to reduce attacks using token theft by ensuring a token is usable only from the intended devices. Token protections create a cryptographically secure tie between the token and the device. Without the client’s secret, the bound token is completely useless for attackers.

✅ = Protected against AiTM ❌ = Not protected against AiTM

MethodProtected (mitigation) against AiTM
Token protection for Outlook app❌
Token protection for Exchange Online❌
Token protection for SharePoint Online❌

Token protection is part of Conditional Access Policy Session Control.

Now the question is – how works Token protection in combination with AiTM attacks?

The future is currently in preview and is limited to the following systems:

  • Windows 10 or newer devices
  • Azure AD joined, hybrid Azure AD joined, or Azure AD registered.
  • Onedrive sync client 22.217 or later
  • Teams native client version 1.6.00.1331 or later
  • Office Perpetual clients aren’t currently supported.

See current known limitations for situations where the token is not protected.

Token protection is currently only supported for Exchange and SharePoint including desktop applications and SharePoint Online / Exchange Online. When enabling the Conditional Access rule the following situation is the experience:

Managed devices

Outlook/ Sharepoint online is available since token binding is applicable for devices where the Azure AD, hybrid Azure AD object, and Azure AD registered object is in-place. Token protection for managed devices is not preventing AiTM toolkits from running or capturing tokens.

Unamanged devices

Sign-in via portal.office.com works fine. When opening SharePoint/ Teams online or Exchange the application is not available since token protection is preventing the application from running.

AzureAD shows the Conditional Access policy audit logging:

With token protection enabled, there is no additional prevention – the token can still be stolen via AiTM toolkits, when the token is used it is preventing access to the apps since the token is not protected. Hopefully, in the close future – Microsoft will support more in-depth token protection for other applications and adds support for the initial sign-in. During my test the conditional access controls; Require device to be marked as compliant & Require device to be marked as Hybrid Azure AD joined device are way more effective in terms of preventing the token to be stolen.

More information: Conditional Access: Token protection (preview) | Microsoft Learn

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.

This image has an empty alt attribute; its file name is image-11-1024x180.png

Prevention using Azure AD 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

The 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 and include all cloud apps.

The 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 and include all cloud apps.

Automatic attack disruption

Last year Microsoft announced a new feature called; Automatic attack disruption which uses correlated insights from the Microsoft 365 ecosystem and powerful AI models to stop sophisticated attack techniques while the attack is in progress. Automatic attack disruption supports the adversary-in-the-middle (AiTM) attacks.

Since May 17, 2023 Microsoft supports automatic attack disruption for adversary-in-the-middle attacks (AiTM) attacks on top of the included BEC and human-operated ransomware attacks.

Automatic attack disruption is part of the Microsoft XDR capabilities and is currently generally available and enable by default for all tenants. (the use depends on the configuration)

The goal of Automatic attack disruption is to detect and contain the attack in the earliest state to reduce the impact and potential damage. AiTM attack disruption works in the following logic:

Step 1: Identification of high-confidence AiTM attack: Based on Defender XDR it correlates signals from different sources into a single, high-confidence incident with insights from all the supported XDR tools (Email, Endpoints, Identities, Collaboration, SaaS)

Step 2: Automatic response: Disables the user account in Active Directory and Azure Active Directory

Step 3: A stolen session cookie will be automatically revoked: The stolen session cookie will be automatically revoked via the disabled user action, preventing the attacker from using it for further malicious activity.

Attack disruption overview

Based on the incident Microsoft calculates the incident and knows the “impact”. When multiple products are correlating alerts Microsoft is able to validate the real attacks with confidence to avoid running automation as a false positive.

Simplified overview of the flow (not official Microsoft)

Automated response actions

Microsoft is leveraging the Microsoft XDR response actions which are part of the product. Example of available actions:

Endpoint (Microsoft Defender for Endpoint)

  • Contain device
  • Isolate device
  • Contain unmanaged devices

With the leverage of Defender for Endpoint device discovery and containment, it is possible to detect unmanaged devices and block incoming/outgoing communication with the suspected device. With this approach the contain action is way more powerful, since attackers can use unmanaged devices as part of the network.

Attackers leverage mostly unmanaged devices for performing advanced attacks. With the use of contain it is possible to contain the unmanaged devices, even when the machine is not onboarded to Defender.

Identity (Microsoft Defender for Identity)

  • Disable user

With the leverage of Defender for Identity is it possible to block users in AD/ Azure AD. The actions will be performed via Defender for Identity.

Supported attacks

Currently, Microsoft supports a couple of attacks where attack disruption will take place. The following attacks are currently supported by attack disruption:

  • Human Operator Ransomware (HumOR)
  • Business email compromise (BEC)
  • Adversary in the middle (AiTM)

Prerequisites

See the prerequisites for automatic attack disruption in Microsoft 365 Defender. For AiTM the following is important:

  • Configure Microsoft 365 Defender
  • Connect Microsoft Defender for Cloud Apps to Microsoft 365 and Azure
  • Deploy Defefender for Endpoint in active mode
  • Deploy Microsoft Defender for Identity

Configure automatic attack disruption capabilities in Microsoft 365 Defender | Microsoft Learn

Defender for Identity

The disabled user activity is based on the Microsoft Defender Identity capability. As part of the integration, the attack disruption flow will automatically block the compromised account to prevent additional damage.

Manage action accounts

To get this feature up and running it is needed to configure the action account in Defender for Identity. Currently, there are two options for configuring the action account:

  • Automatically use the sensor’s local system account
  • Manually configure your management accounts

When selecting manual it is possible to configure a gMSA account. When using the automatic option the local system account of the sensor is used.

More information: Microsoft Defender for Identity action accounts

The disable user action relies on the on-premises Active Directory. When the account is not found/ or detected the following error is visible in M365D Action Center:

Attack disruption is explained in a separate published blog. The separate blog includes all features related to Attack disruption. View the blog here: How to use Automatic Attack Disruption in Microsoft 365 Defender (BEC, AiTM & HumOR)

Attack disruption in action during AiTM attacks

et’s simulate the attack disruption flow to see how M365D collects all data and correlated events. Since the events are high fidelity it is not easy to generate test alerts with the use of test domains. In my situation, I was able to generate the attack disruption response during the AiTM attack.

Alerts

The following alerts were visible in M365D:

  • User compromised in AiTM phishing attack
  • Connection to adversary-in-the-middle (AiTM) phishing site

As you can see the User compromised in AiTM phishing attack alert is flagged with the tags Attack Disruption/ AiTM attack.

Incident

All alerts were mapped in one single incident; the incident is performed via the flow:

  1. Send an e-mail to test user with the AiTM phishing link
  2. The user clicks on the link and sign-in via AiTM link
  3. Attackers receive the tokens and used the token to get access

The incident is classified as high with the following tags:

AiTM attack: This tag identifies the incident detected as AiTM attack

Attack Disruption: This tag identified the incident as part of the attack disruption flow

At the top there is the following information visible:

“Important! A potentially compromised account was disabled automatically by attack disruption in Microsoft 365 Defender. For more details, select the Users tab or go to the Action Center.”

This notification notifies the compromised account was disabled automatically by attack disruption in Microsoft 365 Defender. When searching for the ActionType: Disable user we can see the action is performed automatically by MDI.

Part of the incident is the threat analytics detection – during the performed simulation the alert is flagged with the threat insights Storm-1101.

View Attack disruption events

Each alert/ incident part of Attack disruption is tagged with the tag Attack disruption. Via the alerts/ incident view, it is possible to filter by the tag “AiTM attack”

Performed automated response actions can be reviewed via Action Center. In Action Center click on history and filter for a specific action type. All Attack disruption actions can be viewed when using the decided by “Attack disruption” filter.

Always investigate alerts!!

Important: Attack disruption is no ultimate protection (detect and forget) – it is critically important to make sure the analyst is investigating the full attack. When the assets are contained/ blocked – the attacker will always try to bypass and find more ways to launch the attack again.

When the attack is ‘stopped’ by attack disruption it is important to review the alerts/ incidents. Attack disruption will not resolve the full attack; it will give additional time for the SOC team and stop the growing count of infected assets. Since the attack is under control the SOC team can focus fully on the investigation and further remediation of the attack.

Attack disruption is explained in a separate published blog. The separate blog includes all features related to Attack disruption. View the blog here: How to use Automatic Attack Disruption in Microsoft 365 Defender (BEC, AiTM & HumOR)

Protected using (PIM) Privileged Identity Management?

Common question; Privileged Identity Management (PIM) is enabled with an additional MFA request 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)

Defender SmartScreen

In the past months, I did a lot of research on AiTM/ phishing websites and the detection of new websites. Interesting to see the additional benefit of Defender SmartScreen. With the use of SmartScreen, there is an additional filter enabled for accessing malicious websites. Based on my experience AiTM websites are quite frequently flagged. When checking recently registered domains via Defender TI; a large set of websites is detected as part of the SmartScreen layer – where Defender for Endpoint without SmartScreen is not blocking the website in some situations where Network Protection is enabled.

Recommended is to enable Defender SmartScreen and configure the prevent bypass.

AiTM website flagged in Defender SmartScreen:

Without SmartScreen, there is a block by the Defender for Endpoint/ Defender network protection engine. (This is not for all websites). The alert: Suspicious connection blocked by network protection is triggered in Defender for Endpoint

SmartScreen Phishing protection (only available for Windows 11) gives additional benefits against malicious websites in the following situations:

– Into a reported phishing site
– into a Microsoft login URL with an invalid certificate
– into an application connecting to either a reported phishing site or a Microsoft login URL with an invalid certificate

Long story short; Defender SmartScreen gives additional protection and can be successful in terms of blocking AiTM websites.

More information including the configuration and detailed explanation of Defender SmartScreen is available in the following blog: Microsoft Defender SmartScreen – how to use SmartScreen and Phishing protection | Jeffreyappel.nl

Defender for Endpoint web content filtering

Attackers use multiple domains when the domain is flagged as malicious. Mostly AiTM domains are recently registered/ short-lived and not used for months – with the use of web content filtering in MDE there is the option for blocking newly registered domains.

In the category uncategorized it is possible to block the following categories:

  • Parked domains: Sites that have no content or are parked for later use.
  • Newly Registered Domains: Newly registered domains are domains that have been newly registered in the past 30 days and have not yet been moved to another category.

You can deploy a policy without selecting any category on a device group. This will create an audit-only policy to view the potential blocked events. Recommended with the uncategorized categories is to run the audit mode for a couple of weeks before enabling the category. With the use of custom indicators, it is possible to allow specific websites when needed.

Network Protection must be enabled in block mode.

Defender for Office

Most of the AiTM attempts starts with sending messages (Outlook/ Teams) including a phishing link. Tested with a brand-new Google Gmail account and included the AiTM phishing URL.

It is flagged with the threat type (Phish, Spam) and detected by the URL detonation, advanced filter.

Typical spam attempt mail (-:

When releasing the Defender for Office filter it is blocked/ prevented by safe links with the value: This website is classified as malicious

My logincyberdemo(dot)com domain was already flagged as malicious. Now let’s test with a brand new domain and send the same mail. This domain is today 3 July 2023 registered and never used. The new domain is flagged as malicious.

Important to make sure all the protection is in place – review the Defender security analyzer for improving the policy and secure score for checking if there are potential mitigations not applied.

Audit data

AzureAD

The IP of the sign-in via the evilginx2 server is based on the hosted location. During my test activity, the IP used for Evilginx2 is 172.190.122.138. In the sign-in logs of the user the IP of the Evilginx2 server is visible – and the original IP for the OfficeHome and other apps when the site is redirecting to the original URL.

This behavior with rapid switching of IP/ locations will potentially trigger events in Defender for Cloud Apps and Azure AD Identity Protection.

Microsoft Defender

Identity suspicious logon behavior/ sign-in from multiple countries in a short timestamp. Source Microsoft 

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

Alerts

Microsoft improved recently the alert experience in the Microsoft 365 Defender stack. Microsoft added the following detections in Microsoft 365 Defender:

  • Storm-0928 (DEV-0928) activity group
  • Stolen session cookie was used
  • Suspicious network connection to AiTM phishing site
  • Possible AiTM phishing attempt
  • Connection to adversary-in-the-middle (AiTM) phishing site
  • Threat Intelligence Session (provided by AAD Identity Protection)
  • User compromised in AiTM phishing attack

Microsoft 365 Defender

Microsoft 365 Defender uses its cross-domain visibility to detect malicious activities related to AiTM, such as session cookie theft and attempts to use the earlier stolen cookies for signing in.

User compromised in AiTM phishing attack (Attack disruption): This alert is triggered when the user is compromised in AiTM phishing attack.

Stolen session cookie was used: This alert is triggered for Azure AD customers using Microsoft Edge and using Defender for Cloud Apps. It is needed to configure Office 365 and Azure in Defender for Cloud Apps. When Defender for Cloud Apps is connected and the replay session token is used to access cloud applications the alert is triggered.

The alert is detected as part of the Microsoft 365 Defender – XDR source and is visible when the token is used via Microsoft Exchange Online.

Possible AiTM phishing attempt: When Defender for Cloud Apps connectors are enabled and Defender for Endpoint network protection capabilities are enabled the alert will be triggered. This alert works together with data from Defender for Cloud Apps and Defender for Endpoint with all collected cloud telemetry.

Possible AiTM phishing attempt in Okta: When Okta is connected with Defender for Cloud Apps and Defender for Endpoint is enabled – it will detect AiTM attacks on Okta accounts.

Connection to AiTM adversary-in-the-middle (AiTM) phishing site: When MDE is onboarded and network protection is enabled MDE checks the network connection event against the known indicators. Microsoft tracks numerous activity groups associated with adversary-in-the-middle (AiTM) phishing. This alert indicates that the user has connected to AiTM phishing infrastructure.

Alert is detected via the EDR component with the detection behavior/ network detection technology.

Attack story: Defender detects automatically the recommendation for the phishing incident response playbook.

Threat Intelligence Session: This alert is created when the risk detection indicates sign-in activity that is unusual for the given user or is consistent with known attack patterns based on Microsoft intelligence sources. In the example below the phishing site is detected as threat intelligence session.

The following alerts can lead to potential related AiTM activity:

Defender for Endpoint

  • Suspicious network connection to AiTM phishing site
  • Storm-0928 (DEV-0928) activity group
  • BEC-related credential harvesting attack
  • Suspicious phishing emails sent by BEC-related user

Azure AD Identity Protection

  • Anomalous Token
  • Unfamiliar sign-in properties
  • Unfamiliar sign-in properties for session cookies
  • Threat Intelligence Session

Microsoft Defender for Cloud Apps

  • Suspicious inbox manipulation rule
  • Impossible travel activity
  • Activity from infrequent country
  • Suspicious email deletion activity

Microsoft Defender for Office 365

  • Email messages containing malicious file removed after delivery​
  • Email messages from a campaign removed after delivery​
  • A potentially malicious URL click was detected
  • A user clicked through to a potentially malicious URL​
  • Suspicious email-sending patterns detected

Microsoft created a playbook for session cookie theft alerts. The article contains information about alert grading for AiTM-related alerts and advanced hunting steps against malicious activity. View the playbook here: Alert grading for session cookie theft alert

Conclusion

Since my last blog last year, there has been a lot of improvement visible. Microsoft integrated more products under the Microsoft 365 Defender XDR umbrella and shared more insights/ signals between the products.

There is currently no new block option for preventing token replay/ token stealing via AiTM toolkits. All there is an improvement with the token protection capabilities and the powerful attack disruption capabilities to make sure the attack disrupts before it can continue to spread.

Interesting to see is the rapid response from domain name providers; my test domain loginmsfonline(dot)com is flagged within hours. (Registered 3PM CET, blocked 6PM CET). Good to see providers are blocking domains really fast without starting initial phishing campaigns.

Stay tuned for the next blog with a more focus on the attack disruption capabilities.

If you’ve reached the end – thanks for reading this really really long post. Stay tuned for the next part with more deep-dive into the data/ hunting and attack disruption capabilities.

@jeffreyappel.nl

Sources

Microsoft

Microsoft: Detecting and mitigating a multi-stage AiTM phishing and BEC campaign

Microsoft: From cookie theft to BEC: Attackers use AiTM phishing sites as entry point to further financial fraud

Microsoft: Automatic attack disruption in Microsoft 365 Defender

Microsoft: Alert grading for session cookie theft alert | Playbook

Microsoft: DEV-1101 enables high-volume AiTM campaigns with open-source phishing kit

Microsoft Attack Disruption

Microsoft: Automatic attack disruption in Microsoft 365 Defender

Microsoft: Configure automatic attack disruption capabilities in Microsoft 365 Defender

Microsoft NinjaShow: Attack Disruption | Virtual Ninja Training with Heike Ritter

Microsoft Ignite: Microsoft 365 Defender: Stop attacks with automated cross-domain (XDR) security | LRN201

Microsoft: Automatic disruption of Ransomware and BEC attacks with Microsoft 365 Defender

Evilginx

Evilginx 3.0: evilginx2 GitHub

Evilginx/ Kuba Gretzky: Evilginx 3.0 + Evilginx Mastery

Janbakker.tech: Evilginx resources for Microsoft 365

Community resources

Fabian Brader did some excellent work in explaining multiple methods that 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