Seeing Through the Fog: Interpreting Entra ID Signals During AiTM Attacks

Seeing Through the Fog: Interpreting Entra ID Signals During AiTM Attacks

Speakers: Pierre Audonnet, Solution Engineer, Microsoft

Conference: FIRSTCON

YouTube: https://www.youtube.com/watch?v=HU2U3tBErp0

Overview

In this insightful FIRSTCON presentation, Pierre Audonnet, a Solution Engineer at Microsoft, delves into the escalating threat of Adversary-in-the-Middle (AiTM) attacks targeting Microsoft Entra ID (formerly Azure Active Directory). The talk, titled "Seeing Through the Fog: Interpreting Entra ID Signals During AiTM Attacks," aims to equip security professionals with the knowledge and tools to detect and respond to these sophisticated attacks that bypass traditional multi-factor authentication (MFA). Audonnet emphasizes the critical need to move beyond relying solely on MFA as a silver bullet and instead leverage deep telemetry analysis to uncover the subtle indicators of compromise that these attacks leave behind.

Audonnet begins by illustrating the pervasive nature of AiTM with a relatable personal anecdote involving a pizza order, demonstrating how easily even security professionals can fall victim to well-crafted phishing attempts. He then pivots to the enterprise context, explaining how attackers use similar proxying techniques to harvest credentials and session cookies, thereby gaining unauthorized access to corporate resources. The core of the talk focuses on dissecting the technical mechanisms of AiTM, the telemetry signals generated within Entra ID during such attacks, and practical Kusto Query Language (KQL) strategies for threat hunting and detection.

The presentation is particularly crucial for organizations heavily invested in the Microsoft ecosystem, as it exposes the limitations of common defensive controls like basic MFA, geo-fencing, and even misconfigured Entra ID Protection policies. Audonnet advocates for a proactive, analytical approach, urging defenders to understand the nuances of Entra ID logging, correlate seemingly disparate events, and implement robust, fish-resistant MFA alongside intelligent Conditional Access policies to fortify their identity infrastructure against these advanced threats.

Background

▶ Watch: Introduction and personal AiTM pizza ordering story (0:00)

The landscape of identity-based attacks is constantly evolving, with attackers perpetually seeking new ways to circumvent security controls. For years, multi-factor authentication (MFA) has been hailed as a critical defense, significantly reducing the risk of credential theft. However, the rise of Adversary-in-the-Middle (AiTM) attacks has challenged this paradigm, demonstrating that not all MFA is created equal and that even robust MFA implementations can be bypassed.

An AiTM attack fundamentally works by placing a proxy server between the victim and the legitimate service (e.g., Microsoft Entra ID). When a victim clicks a malicious link, they are redirected to the attacker's proxy, which then relays traffic to the real service. The victim interacts with what appears to be the legitimate login page, entering their username, password, and even completing MFA challenges. The proxy intercepts these credentials and, critically, the resulting session cookies. This allows the attacker to replay the stolen cookies and gain authenticated access to the victim's account without ever needing to know the password or bypass the MFA challenge directly. The user experience is often seamless, making detection extremely difficult for the average user, as demonstrated by Audonnet's personal pizza ordering mishap where a sponsored link led him to a malicious site that redacted payment options to force credit card entry.

While password spray and brute force attacks remain the most prevalent threats against identities (accounting for 97% of attacks due to their ease of execution and global applicability), AiTM, though representing a smaller fraction (0.23%), is highly impactful. These attacks are particularly insidious because they effectively neutralize standard MFA and can operate with relatively low infrastructure cost for the attacker, often leveraging readily available phishing kits like Evilginx, Tycoon, and Caffeine. The problem is exacerbated when users are on personal devices (Bring Your Own Device - BYOD), as defenders often lack the endpoint telemetry (proxy logs, EDR insights) that might otherwise flag suspicious activity. This leaves Entra ID telemetry as the primary, and often only, source of detection for the initial compromise.

Key Findings

▶ Watch: MFA bypass and fish-resistant MFA obfuscation demonstrated (9:00)

The talk uncovers several critical findings regarding AiTM attacks against Entra ID:

• MFA Bypass: Standard MFA, while valuable, is insufficient against AiTM. Attackers use proxying to intercept session cookies after successful MFA, effectively bypassing the security control. This is achieved by presenting a legitimate-looking login page and relaying the MFA challenge, then stealing the authenticated session.
• Redaction of Fish-Resistant MFA Options: AiTM tools are designed to adapt the authentication flow. If a user is configured for fish-resistant MFA (e.g., passkeys, FIDO2 keys, Windows Hello for Business), the attacker's proxy will often "redact" or hide these options, forcing the user to use a less secure, proxyable method like the Authenticator app's number match.
• Stealthy Post-Compromise Automation: Once session cookies are stolen, attackers frequently automate subsequent actions, such as registering new MFA methods on the compromised account, creating inbox redirection rules (e.g., to hide payment-related emails), or accessing sensitive data. This automation can occur rapidly and at scale, making manual detection challenging.
• False Negatives from Entra ID Protection: Critically, misconfigured Entra ID Protection policies can lead to automated alert closure. If a policy dictates that a user remediate a "risky sign-in" by performing MFA, and the attacker successfully proxies this MFA, Entra ID Protection may interpret this as a successful user remediation and close the associated alerts, preventing them from reaching the Security Operations Center (SOC). This also applies to "offline detections" that might trigger later.
• Limitations of Traditional Defenses: Microsoft Defender for Office 365 Safe Links can be bypassed by newly spun-up attacker infrastructure that lacks immediate threat intelligence. Similarly, geo-fencing policies, while useful, are often insufficient as attackers can use VPNs or cloud services to originate connections from expected regions or even gather prior intelligence to avoid triggering such policies.
• Telemetry Stitching is Key: Effective detection requires correlating multiple data points across various Entra ID logs. Individual events might seem innocuous, but when chained together (e.g., suspicious sign-in followed by MFA registration, then an inbox rule creation), they reveal a clear attack pattern.

Technical Deep Dive

▶ Watch: Analyzing telemetry: user agent, location, and automation (16:30)

The technical core of AiTM attacks against Entra ID revolves around the interception and manipulation of the authentication flow. Audonnet highlights that these attacks fundamentally rely on two distinct TLS sessions: one between the victim and the attacker's proxy, and another between the attacker's proxy and the legitimate Entra ID service. This double-proxy mechanism breaks security features that rely on a direct, cryptographically bound connection, such as fish-resistant MFA.

Attackers leverage sophisticated phishing kits, such as Evilginx, Tycoon, and Caffeine, which act as reverse proxies. These kits are designed to dynamically adapt the content served to the victim, including redacting or obfuscating specific elements. For instance, in the demo, the attacker's proxy modified the Entra ID login page to remove the option for passkeys, forcing the user to select the more vulnerable Authenticator app. This was achieved by making Entra ID believe the client was an unsupported device (e.g., a Blackberry), causing it to serve compatible MFA options.

Upon successful authentication and MFA completion, the attacker's proxy intercepts the resulting session cookies. These cookies represent an authenticated session and can be replayed by the attacker to gain full access to the user's account without needing the password or MFA again. To scale this, attackers often automate post-compromise activities. Audonnet demonstrated this by uploading stolen cookies to an Azure storage account, then using a worker script with the Python module Playwright (a tool for automating headless browsers) to perform actions like creating new MFA methods and setting up inbox redirection rules. This automation significantly reduces the time an attacker needs to exploit an account and obfuscates their manual interaction.

Detecting these attacks requires a deep understanding of Entra ID telemetry and the ability to stitch together disparate log entries. Audonnet emphasizes several key fields for correlation:

• Session ID: A crucial identifier that remains consistent across all token requests and access attempts for a single user session. An attacker cannot change the session ID without initiating a completely new authentication flow, making it invaluable for tracing an attack.
• Unique Token ID: This links a specific token request to subsequent calls made to backend services like Microsoft Graph API or Office activity logs. By tracing the Unique Token ID, defenders can identify what actions were performed with a compromised token.
• Correlation ID: Set by the client application, this ID can sometimes reveal patterns. While it's supposed to be random, some tools or clients might hardcode or reuse Correlation IDs, which can be an indicator of widespread automated attacks like password sprays.

Beyond these identifiers, specific behavioral anomalies in Entra ID sign-in logs are critical indicators:

• User Agent Switches: A sudden change in the user agent string mid-session (e.g., from a standard browser to a headless browser framework like Axios) is a strong indicator of automation.
• Rapid Location Changes: Unlikely geographical shifts between consecutive token requests (e.g., Wyoming to Cologne, Germany, within minutes) suggest a proxying or session hijacking attack.
• Consistent Token Refresh Intervals: Legitimate user interactions with public clients like Outlook typically result in varied token refresh intervals. Highly consistent, automated intervals (e.g., exactly every 15 minutes) are suspicious.
• "Office Home" Application: Attackers often target the default /login.microsoftonline.com endpoint without specifying an application. This defaults to the "Office Home" application in Entra ID telemetry, making it a common starting point for hunting.
• createdDateTime vs. TimeGenerated: Audonnet warns that TimeGenerated reflects when the log entry was ingested, not when the event occurred. Using createdDateTime is essential for accurate temporal analysis, as ingestion latency can otherwise lead to logical inconsistencies (e.g., MFA registration appearing before a sign-in event).

Audonnet demonstrates the power of KQL for advanced hunting, particularly using the union operator to combine multiple data sources and the scan operator to chain consecutive events within specific timeframes. An example query could look for a suspicious sign-in, followed by an MFA registration within five minutes, and then an inbox rule creation within an hour – a strong indicator of a successful AiTM attack and post-compromise activity.

Demo / Proof of Concept

▶ Watch: KQL hunting strategies for suspicious sign-ins and actions (26:00)

Pierre Audonnet presented a compelling recorded demonstration of an AiTM attack, illustrating the victim's experience and the attacker's actions side-by-side.

The demo began with the victim, "Jesse," receiving a spear phishing email designed to look like a legitimate account update notification. The email contained a link that, upon hovering, revealed a typo squatting domain (sentinelabs.xyz instead of sentinelab.xyz), a subtle but common trick.

When Jesse clicked the link, the attack flow unfolded:

1. Safe Links Bypass: The initial click was first routed through Microsoft Defender for Office 365 Safe Links. However, because the attacker's server was newly provisioned and lacked existing threat intelligence, Safe Links deemed it "safe," passing the connection through.
2. Credential Harvesting: Jesse was redirected to the attacker's proxy, which presented a near-perfect replica of the legitimate Entra ID login page. Jesse entered her password.
3. MFA Proxying and Redaction: Jesse was then prompted for MFA. Crucially, the attacker's proxy had "redacted" the fish-resistant MFA options like passkeys, forcing Jesse to use her Authenticator app. During this MFA challenge, the telemetry showed a suspicious location change (from Wyoming to Cologne, Germany), which users are often desensitized to due to VPNs or other legitimate network anomalies. Jesse approved the MFA prompt.
4. Session Cookie Interception: Upon successful authentication, the attacker's proxy intercepted Jesse's authenticated session cookies. A small, on-screen message confirmed the cookie interception.
5. Automated Post-Compromise: To demonstrate scalability, Audonnet showed how these stolen cookies were uploaded to an Azure storage account. A Playwright automation script then consumed these cookies, automatically performing actions like registering a new MFA method for the attacker and creating an inbox redirection rule to hide future suspicious emails from Jesse.

Audonnet further reinforced these concepts with a real-world customer case study. In this scenario, the initial phishing email never reached the corporate mailbox but landed in the user's personal Gmail account. The user clicked the malicious link on their personal device. This meant the defender had no telemetry from the endpoint, proxy, or email gateway for the initial stages of the attack. The first zone of observability for the defender was when the attacker, using the stolen credentials and session, authenticated against Entra ID. Even worse, the user had not even set up MFA, allowing the attacker to force MFA enrollment during the compromise, making subsequent access easier. The only detection in this case occurred much later, when the attacker created an inbox redirection rule, highlighting the critical delay in detection when relying on post-compromise activity.

Defensive Implications

▶ Watch: Key takeaways: fish-resistant MFA enforcement and logging (34:00)

Defending against AiTM attacks requires a multi-layered approach that goes beyond traditional MFA and leverages deep telemetry analysis. Audonnet outlines several key strategies for defenders:

1. Send Logs to an Analytic Platform: The foundational step is to centralize all relevant logs into a Security Information and Event Management (SIEM) or data analytics platform (e.g., Microsoft Sentinel, Splunk). This allows for correlation across different data sources, which is essential for detecting chained events.
2. Enable and Enforce Fish-Resistant MFA: This is the most critical technical control.

• Implement: Encourage or mandate Windows Hello for Business for Windows users, Platform SSO for Mac users, FIDO2 security keys, or device-bound passkeys within the Microsoft Authenticator app.
• Enforce: Crucially, simply enabling these options is not enough. Use Conditional Access policies to enforce fish-resistant MFA for all users, especially administrators, and for high-risk scenarios. For example, a policy could require fish-resistant MFA if a sign-in is deemed risky by Entra ID Protection, preventing attackers from bypassing MFA during self-remediation.

1. Strengthen Conditional Access Policies:

• Device Requirements: Implement policies that require devices to be Entra ID Joined or Intune compliant. While the password might still be stolen, this policy would block the attacker's unmanaged device from accessing resources.
• Geo-fencing: Although a "super weak defense," it's better than nothing and cheap to implement. Be aware that sophisticated attackers can bypass it, but it can deter opportunistic attacks.

1. Restrict MFA Enrollment Conditions: Tightly control where and how users can register new MFA methods. Attackers, once they have initial access, will often try to register their own MFA method to maintain persistence. Restricting this to managed devices or specific network locations can prevent this.
2. Proactive Threat Hunting:

• Review Closed Alerts: Do not ignore automatically closed alerts from Entra ID Protection. As Audonnet highlighted, a remediated risk might actually be a successfully proxied attack where the attacker completed the MFA challenge. Regularly review these alerts for patterns that indicate AiTM.
• Hunt for Failed AiTM Attempts: Even if an attack is blocked (e.g., by Conditional Access), the password was likely compromised. Investigate these failed attempts to identify compromised credentials and force password resets.
• Look for Behavioral Anomalies: Utilize KQL (or your SIEM's query language) to hunt for specific patterns:
• User agent switches within a session.
• Rapid session travel distances or unlikely location changes.
• Consistent token refresh intervals (e.g., every 15 minutes for public clients).
• Suspicious chains of events: suspicious sign-in -> MFA registration -> inbox rule creation within short timeframes.
• Sign-ins to the "Office Home" application that don't fit typical user behavior.

1. Assume Password Compromise: If an AiTM attack is attempted, always assume the user's password has been compromised, even if the session was blocked. Force a password reset and investigate other accounts where the user might have reused that password.
2. Understand Token Validity and CAE: Be aware of token validity periods (roughly one hour for Entra ID bearer tokens). While Continuous Access Evaluation (CAE) helps revoke sessions faster for applications that support it, attackers might target applications that do not. Identify such "token blast radius" applications and assess the risk of prolonged access post-revocation.

Key Takeaways

• Fish-resistant MFA is paramount: Traditional MFA is vulnerable to AiTM; implement and enforce Windows Hello for Business, FIDO2, Platform SSO, or device-bound passkeys.
• Deep telemetry analysis is essential: Consolidate all Entra ID logs into an analytic platform and leverage KQL (or equivalent) to correlate Session ID, Unique Token ID, and Correlation ID for comprehensive attack tracing.
• Hunt for behavioral anomalies: Look for suspicious patterns like user agent changes, rapid location shifts, consistent automated token refresh intervals, and sign-ins to the "Office Home" application.
• Conditional Access needs careful tuning: Configure policies to enforce device compliance and fish-resistant MFA, and critically, review how Entra ID Protection handles "remediated" risks to prevent automated alert closure that hides actual compromises.
• Control MFA enrollment: Restrict the conditions under which new MFA methods can be registered to prevent attackers from establishing persistence.
• Always assume password compromise: If an AiTM attack occurs, reset the user's password and investigate potential reuse, even if the attack was ultimately blocked.

About the Speaker(s)

Pierre Audonnet is a Solution Engineer at Microsoft with an impressive 17 years of experience working directly with customers in the field. His current role focuses on identity threat detection and response, where he dedicates a significant portion of his time assisting threat hunters and detection engineering teams. Audonnet's expertise lies in helping organizations make sense of Microsoft product telemetry to improve their overall security posture. His practical, customer-centric approach, coupled with his deep technical knowledge, makes him a valuable resource in the cybersecurity community, particularly concerning advanced identity-based threats.