After the Token Is Stolen: The Full AiTM and BEC Cleanup Runbook

The call usually starts the same way: a client's vendor received a strange payment request, or a user mentions their account "did something weird," and twenty minutes later you are staring at a sign-in from an IP nobody recognizes. Token theft has become one of the fastest growing attack methods, and at the current pace, we hear from roughly one customer or MSP per week dealing with a breach that started this way and extended into business email compromise.

What follows is our recommended incident response runbook for returning an environment to a healthy state after a token theft breach. It is organized across the NIST CSF functions, Detect, Respond, Recover, and works for BEC incidents generally, not just the AiTM variant. The proactive side, the policies that prevent these attacks outright, is covered in our proactive protections playbook.

If you want this runbook as a template your technicians and analysts can fold into an SOP and incident documentation, there is a downloadable copy here (opens in new tab).

How the attack unfolds before you see it#

There are multiple ways token theft can occur. This runbook follows one of the most common: a phishing email carries a link to a legitimate-looking Microsoft login page, the attacker harvests the session token as the user signs in, and then uses that token to run a campaign that typically involves business email compromise.

What triggers the runbook#

You might be pulled in at any point along that kill chain. An inbox rule alert and a strange sign-in report are different entry points into the same incident. The common triggers:

• A user reports suspicious or malicious behavior. Less common, but a user may report odd account activity or an email link they clicked. Other users may report suspicious messages from a continuing BEC campaign.
• Entra ID and sign-in alerts. Whether you use first-party Microsoft solutions or third-party tooling, sign-in logs are one of the best sources for spotting the suspicious sign-ins these attacks produce.
• Defender and email alerts. Defender can fire on several incident-related events: inbox rule creation, extreme email volume from a single user, a potentially malicious URL click, and more.

Before the incident: point Defender alerts at your PSA#

Alerts that nobody receives are decorations. In the Defender admin center, go to Settings > Microsoft Defender XDR.

Click Email notifications, then modify the existing rule or create a new one.

Make sure the tenant name is attached to notifications and the right alert services are selected. Severity is the awkward part: including low and informational generates a flood of noise, but inbox rule creation, a key BEC indicator, is informational by default. The workaround is to go to Email and Collaboration > Policies and Rules > Alert Policies and create your own rules at a higher severity for the events you care about.

Phase 1: Confirm the compromise#

One licensing note before the workflow: without Entra P2, the built-in detection for suspicious and malicious sign-ins is limited. Everything below assumes at least a P1 license in the tenant.

Check for unfamiliar sign-in properties#

Start with the Risk Detections report (Entra admin center > Protection > Risky Activities > Risk Detections), which comes with P1. Look for detections that seem suspicious. The initial token theft event registers as a successful sign-in on the end user's device, but in most cases from an abnormal location or IP.

Then pull the user's recent sign-in logs (Entra admin center > Users > select the user > Sign-In Logs). A filter combination worth memorizing: Status = Success and Application = OfficeHome. OfficeHome is the Office login page typically used in AiTM attacks built with tools like Evilginx for the initial token theft. Spot the anomaly?

For faster work than scrolling sign-in logs, use Advanced Hunting in the Defender admin center. This query aggregates all sign-ins by location for a user:

AADSignInEventsBeta
| where ErrorCode == "0" // Successful sign-in
| where AccountUpn == "nross@cloudcapsule.io"
| where ApplicationId == "4765445b-32c6-49b0-83e6-1d93765276ca"
| where isnotempty(City) and isnotempty(State) and isnotempty(IPAddress) // Filter out empty locations
| summarize Count = count(), DistinctCities = dcount(City), DistinctStates = dcount(State), DistinctIP = dcount(IPAddress) by AccountUpn, City, State, IPAddress
| where Count > 1 // Lowered this to 1 for testing
| project AccountUpn, Count, DistinctCities, DistinctStates, DistinctIP, City, State, IPAddress

The result:

Make the compromise call, then contain#

Findings like impossible travel or sign-ins from outside the country may be enough to confirm compromise on their own. Do not lean on geography too hard, though: attackers can spin up infrastructure anywhere or obfuscate their location. In our test, the Evilginx server presented an IP in Austin, comfortably inside the country.

The steps to perform here:

• Reach out to the user to confirm the sign-in is legitimate, if necessary
• If the sign-in is legitimate and no indicators signal compromise, move on to the next step
• If compromise is confirmed: reset the user's password, revoke all sessions, and block user sign-in until the breach is contained and the investigation is complete

Phase 2: Scope the blast radius#

How much can this account do?#

Check the user's permissions to learn whether they hold any admin rights, and understand their title and role to gauge whether they are a "sensitive" user, someone with authority to wire funds, the CEO, and so on. If the account has admin rights, the risk is much higher and additional steps apply, covered later in this runbook.

Did anyone else sign in from that IP?#

The attacker may have phished multiple users. In the Entra admin center, go to Monitoring & Health > Sign-In Logs and filter both interactive and non-interactive sign-ins for the suspect IP.

Advanced Hunting can sweep for the IP across far more tables at once:

let ip = "143.198.130.152";
search in (IdentityLogonEvents,IdentityQueryEvents,IdentityDirectoryEvents,EmailEvents,UrlClickEvents,DeviceNetworkEvents,DeviceFileEvents,DeviceLogonEvents,DeviceEvents,BehaviorEntities,CloudAppEvents,AADSpnSignInEventsBeta,AADSignInEventsBeta)
Timestamp between (ago(30d) .. now())
and (// Events initiated by this IP
LocalIP == ip
or FileOriginIP == ip
or RequestSourceIP == ip
or SenderIPv4 == ip
or SenderIPv6 == ip
or IPAddress == ip
// Events affecting this IP
or RemoteIP == ip
or DestinationIPAddress == ip
)
| take 100

Find the phishing email#

Next, identify the phishing email that started everything and check whether it reached other users. Defender for Office 365 may have already done this work, so start in the Defender portal.

First, check active incidents and alerts. In the example below, Defender built the incident for us: email delivered, link clicked, then the email removed by zero-hour auto purge (ZAP).

Defender aggregates the evidence, including the malicious email and the clicked URL:

The incident should also correlate additional data: which other users received the email, who else clicked links, and so on. If no alerts were generated, move to the next check.

Second, query the detection tools directly. Check Real-Time Detections (Defender for Office 365 Plan 1) or Explorer (Plan 2) for captured phishing emails. Use the phishing tab, filter the timeframe and set the recipient to the compromised user. To narrow further, filter original delivery location = Inbox and latest delivery location = Quarantine. The email in this example was removed by ZAP:

This view exposes header information and whether the same message went to other mailboxes:

Third, fall back to message trace. If Microsoft detected nothing and the message was never flagged as phishing, go to the Exchange admin center > Mail Flow > Message Trace.

Narrow by time range, the user as recipient, and potentially the originating IP. Look for suspicious senders with suspicious subject lines, and investigate further with View Message in Explorer.

This shows whether the same email reached others in the organization. Searching message trace by subject line works for that too.

Pull the phish out of every mailbox#

If ZAP did not remove the emails, remove them from all user mailboxes yourself. Exchange PowerShell handles it:

Search-Mailbox -Identity "April Stewart" -SearchQuery 'Subject:"Your bank statement"' -DeleteContent

Phase 3: Evict the attacker#

Scope is established. Now remove every piece of persistence the attacker set up, and claw back anything they sent as part of a broader BEC campaign.

Audit and remove consented applications#

With the breach timeframe established, use the audit log to find applications the user may have consented to. A consented application acts as its own identity with permissions to do things like send mail on behalf of users, which makes it a perfect backdoor. Audit for the activity "Consent to application."

Also check Enterprise applications and App registrations in Entra, sorted by created date:

Audit and remove added MFA methods#

An attacker who ran the AiTM play has the user's password. Their next move is registering or changing an MFA method to keep access. Audit for the activity "Update user" with Target = the breached user.

Look for a Modified Properties value that alters MFA. In the example below, the attacker added an email method pointing at a third-party address:

Remove illegitimate methods at Users > select the user > Authentication Methods.

Audit and remove registered devices#

Attackers sometimes register or join devices into Entra to appear trusted on the network. Audit for the activity "Register device."

If you find a device that should not exist, grab the device ID from the audit log, go to Devices in Entra, and delete it from inventory.

Shortcut for all three checks: there is a PowerShell script that automates these persistence findings (opens in new tab), returning all of the relevant logs for the user you specify:

Repeat all of the steps above for every user found to be involved in the attack. And if the compromised account was an admin, widen the lens: investigate all audit logs for any other potentially malicious actions, including group updates, other users' password resets, and Conditional Access policy changes.

Find anything the attacker sent#

With persistence removed, confirm the attacker did not send emails or campaigns of their own, the classic BEC move of phishing more users or steering payments to fraudulent bank accounts. Run message trace again over the breach timeframe, this time with the compromised account as the sender. Investigate anything suspicious and remove malicious mail from recipients' inboxes using the same Search-Mailbox approach from earlier.

Sweep the Purview audit log#

In the Purview portal, run an audit log search for remaining activities that need remediation. You can audit nearly anything, but these four filters are our starting set:

• Inbox rule creation (New-InboxRule)
• Messages moved to the Deleted Items folder
• File downloads
• Mailbox permissions added

If an admin was compromised, audit every activity performed, full stop. Based on results, take these actions:

• Remove any inbox rules the attacker created: Remove-InboxRule reference (opens in new tab)
• Email moved to Deleted Items was likely the attacker covering their tracks; restore anything legitimate
• Document any downloaded files and review them with the client in the post-incident summary so the sensitivity of the data is understood
• Remove any added mailbox permissions

Phase 4: Return to service#

Re-enable the account#

With the breach contained and persistence removed, re-enable sign-in for the user and let them know what happened and what changed.

Block the attacker's infrastructure#

In the Defender portal, block the relevant domains, senders, IPs, and URLs from the incident under Email and Collaboration > Policies and Rules > Threat Policies > Tenant Allow/Block List.

If you need to block sign-ins from a specific IP, a Conditional Access policy using Named Locations can hold the block list. Depending on the attack, the better long-term play may be a geo-restriction policy by country.

Harden before the next one#

The retro matters as much as the cleanup. Review the tenant's existing policies and identify hardening that would have stopped this incident, then implement it. Our proactive protections playbook for token theft walks through those recommendations policy by policy.

Put the findings in front of the client#

Share an incident report with the customer. It demonstrates why the protections you recommend exist, reinforces end-user training, and turns a bad week into the business case for the security work that prevents the next one.

Automating the investigation#

Several of the checks in this runbook, risky sign-ins, persistence indicators, policy gaps, can be surfaced automatically rather than queried by hand per tenant. CloudCapsule's Token Theft playbook pulls those IOCs together and pairs them with the preventive recommendations for each tenant: