The alert chain looked like every business email compromise: an unfamiliar sign-in, then within the hour a flurry of Defender alerts — suspicious inbox rule, mass mail, sending-limit exceeded, phishing sent by the user. By the time it fired, the attacker had already blasted well over a thousand phishing emails from the mailbox under a tax-document lure.
But the detail that made the whole timeline click — and that tells you this was token theft, not a guessed password — was an MFA device. When we called the user, she said something you learn to listen for: "I've only ever used a Samsung. I've never owned an iPhone." An "iPhone" had been registered to her account as a strong-auth method weeks earlier. That single line reframed the entire incident.
01The timeline, and what each step really means
Read in order, the sequence is a textbook adversary-in-the-middle takeover.
# reconstructed from Entra sign-in logs + Defender alerts 11:14 interrupted sign-in, then repeated SUCCESSFUL sign-ins # same bad-rep IP from one IP, hitting OfficeHome / Exchange Online 12:50 attacker DELETES the user's Authenticator profile # kicks off the real device 12:50 attacker re-adds a device to strong-auth # persistence on their terms 12:53 hidden inbox rule created: move senders → "! Outside Info" # hide the replies 13:39 ~1,200+ phishing emails sent under a tax-doc subject # the payday
The repeated successful sign-ins with no failed-password storm is the tell: the attacker wasn't guessing credentials, they were replaying a stolen session — the hallmark of an adversary-in-the-middle phishing kit that captures the token after the user legitimately completes MFA. From there, everything they did was about keeping access and hiding activity.
02Why the MFA tampering is the fingerprint
An attacker who owns the session immediately makes the session theirs.
Once inside, the attacker did three things to the user's authentication methods, and each one is a classic post-takeover move:
| Attacker action | What it's for | Why it's evidence |
|---|---|---|
| Deleted the Authenticator profile | Disrupt the real owner's push approvals | User suddenly can't approve logins |
| Registered a new device ("iPhone") | Persistent MFA the attacker controls | User doesn't recognize the device |
| Re-added the user's own device later | Reduce suspicion / restore normal look | Churn in method history around the sign-in |
The question that cracks these fast
Every registered authentication method has an owner who can confirm or deny it. "Do you recognize this device / phone number as one you added?" is the cheapest, highest-signal question in an ATO investigation. A device the user disowns is near-proof of takeover — far more decisive than a foreign IP, which travel or VPNs can explain away. Pull the method-registration audit early and read it against what the user actually owns.
03Containment — in the right order
Do these in sequence. Get the order wrong and you leave a door open.
The instinct is to reset the password first. That's not enough on its own and, done alone, can even tip the attacker off while leaving their access intact. The token and the attacker's MFA method are what actually hold the door open, so the sequence matters:
# 1. kill the live access FIRST — revoke tokens, not just the password Revoke-AzureADUserAllRefreshToken -ObjectId <user-object-id> # (or the Graph/Entra equivalent) — invalidates the stolen session # 2. reset the password (forces re-auth on the now-dead session) # 3. REMOVE the attacker's MFA method, restore the user's own # a password reset alone does NOT remove a rogue registered device # 4. rip out persistence in the mailbox Get-InboxRule -Mailbox user@contoso.com | Format-Table Name, Description, Enabled Remove-InboxRule -Mailbox user@contoso.com -Identity "! Outside Info Emails" Get-Mailbox user@contoso.com | Format-List ForwardingSMTPAddress, DeliverToMailboxAndForward # 5. scope the blast — who received the phishing, purge it, notify # 6. full endpoint health check on the user's real device
A password reset does not evict a token thief
The stolen session token and the attacker's registered MFA device survive a password change. You must revoke sessions and remove the rogue auth method explicitly. Skip either and the attacker can still be inside after the "fix" — reset-only is the single most common incomplete containment in ATO response.
04The hidden inbox rule
Small, quiet, and the reason the user never noticed.
The rule the attacker created — moving mail from specific senders into an innocuously named folder like ! Outside Info Emails — is the classic BEC concealment move. When the phishing blast goes out and recipients reply "is this really you?", the rule sweeps those replies out of the inbox so the real owner never sees the alarm. Any inbox rule that hides or diverts incoming mail, created around the time of a suspicious sign-in, should be treated as attacker persistence until proven otherwise — and you check for forwarding at the same time, since that's the other quiet exfiltration path.
The lesson
In an account takeover, read the authentication methods, not just the sign-in logs. A device the user disowns is the fingerprint that turns "suspicious login" into "confirmed compromise." And contain in the right order — revoke sessions, reset password, remove rogue MFA, then clear inbox rules — because the token and the attacker's device, not the password, are what actually hold the door open.
Further reading
- Compromised email account playbook — Microsoftthe canonical ATO response steps
- Manage a user's authentication methods — Microsoft Learnreviewing and removing registered methods
- Respond to a compromised account — Microsoft Defendertoken revocation and rule cleanup
This write-up is anonymized from a real incident; names, addresses, and numbers have been changed.
Comments
Questions or corrections welcome. Sign in with GitHub to join the thread.