Investigating adversary-in-the-middle (AiTM) token theft
Adversary-in-the-middle (AiTM) attacks steal a session token after the user has passed MFA, so the sign-in looks legitimate. That makes these among the hardest alerts to triage by eye. Here is how OwlSOC investigates an AiTM token-theft alert from Microsoft Defender or Sentinel — what it correlates, the verdict it returns, and how containment stays human-approved.
Why AiTM alerts are hard to triage
In an AiTM attack, a phishing proxy sits between the user and the real sign-in page, captures the session token after MFA succeeds, and replays it. Because MFA was satisfied, the resulting sign-in can look ordinary: valid user, valid token, sometimes a familiar-looking client. The tell is in the correlation — an unfamiliar IP or ASN, an impossible-travel pattern, a new mail rule created moments later, an OAuth grant, or a token used from two places at once.
That is exactly the kind of cross-signal reasoning that gets skipped when an analyst has nine seconds and a full queue. It is also exactly what an AI SOC is for.
What OwlSOC checks
When an AiTM-style alert fires, OwlSOC pulls the sign-in and the signals around it and reasons across them rather than judging the sign-in alone.
- The sign-in itself: IP, ASN, location, device and client, against the account's baseline.
- Token behaviour: reuse from a second location, unusual session lifetime, or replay indicators.
- What happened next: new inbox or forwarding rules, OAuth consent grants, mailbox access, or privilege changes.
- Identity context: the user's normal pattern, and whether other accounts show the same signature.
The verdict, and the evidence behind it
OwlSOC returns a hedged verdict — likely true positive, likely false positive, or uncertain and needs review — with a calibrated confidence and an evidence-linked timeline. Every claim cites the source log or pivot ID, so your analyst can open any step and check it against the original record in Defender or Sentinel, and disagree if the evidence does not hold. It maps the activity to MITRE ATT&CK so the technique is named, not guessed.
It never returns "confirmed". For a token-theft pattern where a real user's context is ambiguous, that hedge is the point: a calibrated maybe with the working shown beats a false certainty.
Containment stays human-approved
For a likely AiTM compromise, OwlSOC will recommend an action — commonly revoking the active sessions and reviewing any new mail rules or OAuth grants — but it does not act on its own. The recommendation waits for a human on your team to approve the specific action, and it only executes on the write scopes you have granted. By default the connection is read-only. Every action is logged, and revoking a session is reversible.
This is a synthetic scenario for illustration; the alerts, identities and IPs here are not real customer data. Connected to your tenant, the investigation runs on your own Defender and Sentinel signals.
Frequently asked
What is an adversary-in-the-middle (AiTM) attack?
AiTM is a phishing technique where a proxy sits between the user and the real sign-in page, captures the session token after MFA succeeds, and replays it to access the account. Because MFA was passed, the sign-in can look legitimate, which is why these alerts need cross-signal correlation to triage.
How does OwlSOC investigate an AiTM token-theft alert?
It correlates the sign-in with token behaviour, subsequent actions like new mail rules or OAuth grants, and the account's baseline, then returns a hedged verdict with an evidence-linked timeline and a MITRE ATT&CK mapping. Every claim traces back to the source log in Defender or Sentinel.
Will OwlSOC revoke the session automatically?
No. It recommends an action such as revoking the sessions, but a human on your team approves it before anything runs, and only on the write scopes you have granted. By default OwlSOC is read-only. Session revocation is reversible and every action is logged.
Does OwlSOC work with Microsoft Defender and Sentinel for these alerts?
Yes. OwlSOC connects read-only to Microsoft Defender (Endpoint and Office) and Microsoft Sentinel, which is where AiTM and token-theft signals surface, and also to AWS Security Hub. It investigates the alerts those tools raise rather than replacing them.
Start with a 30-day refundable pilot. £495, one environment, every alert investigated, a full report at week four. Read-only, live within 48 hours of access.