The Shadow in the Stream: Hunting Adversary-in-the-Middle Phishing Attacks with KQL

Adversary-in-the-Middle (AiTM) phishing poses a significant threat to business operations, particularly in cloud-based environments such as Microsoft 365. This technique involves attackers positioning themselves between users and legitimate services to intercept credentials and session tokens, often bypassing multifactor authentication (MFA). Enterprises face heightened risks due to the integration of AiTM with business email compromise (BEC) campaigns, where attackers exploit trusted vendor relationships or internal communications to gain access.

Historical Evolution of AiTM Phishing

AiTM phishing traces its roots to traditional man-in-the-middle attacks but adapted for modern authentication protocols around 2021. Early instances involved basic proxy tools to capture session data during login attempts. By September 2021, large-scale campaigns emerged, targeting over 10,000 organizations through cookie theft and subsequent BEC activities.

The technique gained prominence in 2022 with the expansion of frameworks like Evilginx, enabling attackers to relay authentication in real-time. In 2023, multi-stage AiTM attacks originated from compromised vendors, transitioning to BEC for financial fraud.

By 2024–2025, AiTM phishing incorporated AI for advanced lure generation and evasion tactics, such as impersonating sender identities and integrating real-time events.

Key Characteristics of AiTM Phishing in Business Contexts

AiTM attacks typically begin with phishing emails containing links to proxy sites mimicking legitimate portals, such as Microsoft login pages. Attackers capture passwords and MFA tokens, then replay them to access resources such as email, Outlook, and SharePoint. AiTM frequently targets Microsoft 365 users, with evolving tactics including QR code phishing and OAuth consent abuse to maintain persistence.

Defenses involve phishing-resistant MFA like passkeys and risk-based Conditional Access policies. Detection relies on monitoring for anomalous sign-ins, such as those from untrusted devices or high-risk applications.

Implementing KQL for AiTM Detection in Microsoft Defender XDR

Kusto Query Language (KQL) in Microsoft Defender XDS enables enterprises to query logs for AiTM indicators, correlating email events, URL clicks, and risky sign-ins. The following query focuses on inbound emails, allowed clicks, and high-risk browser-based sign-ins within a 30-minute window, utilizing tables such as EmailEvents and AADSignInEventsBeta. It targets patterns common in business AiTM attacks.

let TimeRange = 30d; // Define time range  
let PhishingEmails =  
    EmailEvents 
    | where Timestamp > ago(TimeRange) 
    | where EmailDirection == "Inbound" 
    | project EmailTimestamp = Timestamp, NetworkMessageId, RecipientEmailAddress, SenderFromAddress, Subject; 
//Identify URL clicks with minimal columns 
let ClickedURLs =  
UrlClickEvents 
    | where Timestamp > ago(TimeRange) 
    | where Workload == "Email" and ActionType == "ClickAllowed" // Stricter click filter 
    | project ClickTimestamp = Timestamp, NetworkMessageId, AccountUpn, Url; 
//Join phishing emails with URL clicks 
let PhishingClicks =  
    PhishingEmails 
    | join kind=inner hint.strategy=shuffle ClickedURLs on NetworkMessageId 
    | project EmailTimestamp, ClickTimestamp, RecipientEmailAddress, AccountUpn, SenderFromAddress, Subject, Url; 
//Correlate with risky sign-ins 
let RiskySignIns =  
AADSignInEventsBeta 
| where Timestamp > ago(TimeRange) 
| where RiskLevelDuringSignIn in ( 50, 100) // Medium or High risk 
| where ApplicationId in ("72782ba9-4490-4f03-8d82-562370ea3566", "4765445b-32c6-49b0-83e6-1d93765276ca") // AiTM apps 
| where isempty(DeviceTrustType) and ClientAppUsed == "Browser" and ErrorCode == 0 // Combine filters 
| where isnotempty(AccountUpn) and isnotempty(IPAddress) 
| project SignInTimestamp = Timestamp, AccountUpn, Application, ApplicationId, IPAddress, UserAgent, RiskLevelDuringSignIn; 
//Join clicked URLs with risky sign-ins and finalize 
PhishingClicks 
| join kind=inner hint.strategy=shuffle RiskySignIns on AccountUpn 
| where SignInTimestamp >= ClickTimestamp and SignInTimestamp <= ClickTimestamp + 30m // Sign-in within 30 minutes 
| project EmailTimestamp, ClickTimestamp, SignInTimestamp, AccountUpn, SenderFromAddress, Subject, Url, Application, ApplicationId, IPAddress, UserAgent, RiskLevelDuringSignIn 
| summarize count() by EmailTimestamp, ClickTimestamp, SignInTimestamp, AccountUpn, SenderFromAddress, Subject, Url, Application,ApplicationId, IPAddress, UserAgent, RiskLevelDuringSignIn 
| sort by SignInTimestamp desc 
| take 100 // Limit output

Query Breakdown

TimeRange Definition: Sets a 30-day scope for log analysis.

PhishingEmails: Filters inbound emails from EmailEvents, projecting key fields for correlation.

ClickedURLs: Identifies allowed URL clicks in emails from UrlClickEvents.

PhishingClicks: Joins emails and clicks on NetworkMessageId to link lures to user actions.

RiskySignIns: Queries AADSignInEventsBeta for medium/high-risk sign-ins tied to suspect apps, untrusted devices, and successful browser logins.

Final Join and Filtering: Correlates clicks with sign-ins within 30 minutes, summarizes results, and limits output for efficiency.

Response and Containment Checklist

• Revoke Active Sessions and Tokens
• Identify Affected Users and Scope
• Block Attacker Infrastructure
• Reset Passwords (with MFA Enforcement)
• Investigate Token Replay and App Consent

Post-Incident Actions

• Review Microsoft Defender for Cloud Apps (MCAS) Activity Logs
• Investigate Email Activity (Read, Sync, Forwarding Rules)
• Audit SharePoint and OneDrive File Access and Downloads

Mitigation

Enterprises should enforce phishing-resistant authentication and monitor OAuth consents to counter AiTM. With 72% of organizations noting increased cyber risks in 2025, including phishing-driven fraud, proactive hunting via KQL is essential. Regular audits and employee training can reduce incident rates by addressing 80% of breaches linked to phishing.

References

1. https://www.microsoft.com/en-us/security/blog/2025/05/29/defending-against-evolving-identity-attack-techniques/
2. https://www.sentinelone.com/cybersecurity-101/threat-intelligence/what-is-an-adversary-in-the-middle-aitm-attack/
3. https://www.proofpoint.com/us/blog/email-and-cloud-threats/aitm-phishing-attacks-evolving-threat-microsoft-365
4. https://blog.sekoia.io/global-analysis-of-adversary-in-the-middle-phishing-threats/

#AiTM #phishing