How to Detect AiTM Session Cookie Theft in Entra ID Sign In Logs

Adversary in the middle (AiTM) phishing kits sit between the user and the real Microsoft sign in page, pass the MFA prompt through and keep the session cookie that comes back. The attacker then replays that cookie and never needs the password or the second factor again. This guide is for detection engineers and senior analysts in financial services who need reliable signals in Entra ID logs before a stolen session turns into a fraudulent payment.

Understand what an AiTM attack leaves behind

In a classic credential phish the attacker steals a password and must then beat MFA. In an AiTM phish the kit proxies the whole conversation with Entra ID, so the user authenticates for real and the attacker captures the authenticated session. MITRE ATT&CK tracks the pieces separately: T1557 Adversary-in-the-Middle for the proxy, T1539 Steal Web Session Cookie for the theft and T1550.004 Use Alternate Authentication Material: Web Session Cookie for the replay.

That last step is your best detection point. The replayed cookie carries the same session, so the SessionId column in SigninLogs and AADNonInteractiveUserSignInLogs links the victim's genuine sign in to the attacker's later activity, usually from a different autonomous system (ASN) such as a hosting or VPS provider.

Hunt for one session used from many networks

This query unions interactive and non interactive sign ins, because replayed cookies often surface as non interactive token refreshes. It groups by session and user, then keeps sessions that appear from more than one ASN.

let lookback = 1d;
union SigninLogs, AADNonInteractiveUserSignInLogs
| where TimeGenerated > ago(lookback)
| where ResultType == "0"
| where isnotempty(SessionId)
| summarize FirstSeen = min(TimeGenerated),
    LastSeen = max(TimeGenerated),
    DistinctASNs = dcount(AutonomousSystemNumber),
    ASNs = make_set(AutonomousSystemNumber, 10),
    IPs = make_set(IPAddress, 10),
    Apps = make_set(AppDisplayName, 10),
    UserAgents = make_set(UserAgent, 5)
    by SessionId, UserPrincipalName
| where DistinctASNs > 1
| extend MinutesSpan = datetime_diff('minute', LastSeen, FirstSeen)
| sort by FirstSeen desc

Expect noise. Phones moving between Wi-Fi and mobile data, split tunnel VPNs and secure web gateways all change the ASN legitimately. Tune it in stages rather than raising the threshold blindly:

• Build a watchlist of your corporate egress, VPN and gateway ASNs and remove them from the comparison, so a session counts as suspicious only when a new ASN is outside that list.
• Add a prevalence check: an ASN that none of your users signed in from in the last 30 days is far more interesting than a major mobile carrier.
• Score higher when one of the ASNs belongs to a hosting provider, or when the second network appears within minutes of the first.

Flag scripted sign ins to OfficeHome

Several phishing as a service kits, including Tycoon 2FA, have been observed completing the relayed sign in against the OfficeHome application (app ID 4765445b-32c6-49b0-83e6-1d93765276ca) with a non browser user agent from libraries such as axios, node or undici. Elastic ships a prebuilt rule built on this pattern, and it translates directly to Sentinel.

SigninLogs
| where TimeGenerated > ago(7d)
| where AppId == "4765445b-32c6-49b0-83e6-1d93765276ca"
| where UserAgent has_any ("axios", "node", "undici")
| project TimeGenerated, UserPrincipalName, IPAddress, AutonomousSystemNumber,
    UserAgent, ResultType, ConditionalAccessStatus, SessionId
| sort by TimeGenerated desc

This is a high precision, low coverage rule. Kits change their user agents, so treat it as one signal that raises confidence, not your only AiTM detection. Keep the SessionId from any hit, because it is the key you use to scope everything that follows.

Correlate with Microsoft's own token signals

Entra ID Protection and Defender XDR already look for this behaviour. Pull their output into the same investigation so your custom detections and the vendor's agree or disagree in one place. Identity Protection writes risk detections to AADUserRiskEvents, and the AiTM detection uses the risk event type attackerinTheMiddle (note the lower case "in").

AADUserRiskEvents
| where TimeGenerated > ago(7d)
| where RiskEventType in ("attackerinTheMiddle", "anomalousToken", "tokenIssuerAnomaly", "attemptedPrtAccess")
| project TimeGenerated, UserPrincipalName, RiskEventType, RiskLevel,
    DetectionTimingType, IpAddress, Location
| sort by TimeGenerated desc

Know the licence and timing limits before you rely on these. Full detail on most risk detections needs Entra ID P2, and Microsoft lists the Attacker in the Middle detection as requiring Microsoft 365 E5 with EMS E5. It is also an offline detection, so it can arrive after the attacker has already acted. In Defender XDR, alerts titled "Stolen session cookie was used" and "Authentication request from AiTM-related phishing page" cover the same ground from the endpoint and cloud app side.

Trace what the stolen session did

Once you have a suspect session, follow it into the mailbox. Microsoft's own guidance uses the session ID inside RawEventData in CloudAppEvents to link Exchange actions back to the sign in. In a bank or payments business, the actions that matter most are the ones that hide or redirect conversations about money.

let SuspectSessions = dynamic(["8f2c1d4e-6a7b-4c3d-9e0f-1a2b3c4d5e6f"]);
CloudAppEvents
| where Timestamp > ago(7d)
| extend SessionId = tostring(RawEventData.SessionId)
| where SessionId in (SuspectSessions)
| project Timestamp, AccountDisplayName, ActionType, IPAddress,
    CountryCode, ISP, ObjectName
| sort by Timestamp asc

Read the timeline in order and look for the business email compromise pattern: new inbox rules (New-InboxRule, Set-InboxRule), searches for words such as invoice, remittance or SWIFT, mail sent to external finance contacts, and new MFA methods registered to keep access after a password reset. A previous article on this site covers inbox rule investigation in depth, so here focus on linking each action to the stolen session.

Contain the session and meet reporting duties

A password reset alone does not end an AiTM compromise, because the attacker holds a session, not a password. Work through containment as one action set:

• Revoke the user's sessions and refresh tokens (in the Entra admin centre, or with Revoke-MgUserSignInSession in Microsoft Graph PowerShell), then reset the password.
• Remove any MFA methods or devices the attacker registered.
• Mark the user as compromised in Identity Protection so risk based policies apply.
• Remove malicious inbox rules and forwarding, and block the phishing domain and the attacker's IP addresses.
• Tell payment operations and relationship managers which clients and payments may be affected.
• Preserve the sign in, risk and CloudAppEvents records before retention runs out.

For EU financial entities in scope of DORA, the clock matters as much as the containment. If the incident is classified as major, the initial notification is due within four hours of classification and no later than 24 hours after you became aware of it, with an intermediate report within 72 hours of the initial notification and a final report within one month. UK firms should check their FCA and PRA incident notification obligations in the same way. Your detection notes, timeline and scoping queries become the evidence for those reports, so record them as you go.

1. L0
   Single weak signalOne session across two ASNs that matches a known mobile or VPN pattern. Document and close with the reason.
   Close
2. L1
   Suspicious sessionNew hosting ASN or scripted user agent, no mailbox activity yet. Revoke sessions and contact the user.
   Contain
3. L2
   Confirmed replayMailbox rules, MFA changes or data access from the stolen session. Open a major incident and scope other recipients of the lure.
   Incident
4. L3
   Financial impactFraudulent payment instructions sent or funds moved. Engage fraud, legal and compliance, and start regulatory classification.
   Report

Reduce the attack surface

Detection buys time, but the stronger fix is making stolen sessions less useful. Phishing resistant methods such as passkeys, FIDO2 security keys and Windows Hello for Business bind authentication to the real sign in domain, so a proxy cannot complete it. Conditional Access that requires a compliant or hybrid joined device stops a cookie replayed from an attacker's machine for many workloads. Token protection in Conditional Access adds binding for supported clients, but check Microsoft's current documentation for which applications and platforms it covers before you count on it. Prioritise treasury, payments and executive users first, since they are the accounts BEC crews target.

Key takeaways

---

Run the session query over the last 30 days in your tenant this week and label every result as explained or unexplained. The explained ones become your tuning list, and any unexplained session from a hosting provider is worth an immediate conversation with the user and your payments team.

Written by Riz, Senior Cybersecurity Consultant, Finance