Speed matters more than certainty. Containment steps are cheap and reversible; an
attacker with a live session is not.
Containment, in order
- Revoke sign-in sessions. This is the step that actually ends the intrusion.
Modern attacks steal a session token, not a password — a stolen token keeps
working after a password change until it is revoked.
- Reset the password, and deliver the temporary password through a channel the
attacker cannot read. Not to the compromised mailbox.
- Review and clear authentication methods. Attackers add their own phone number
or authenticator so they can come back through self-service password reset. Any
method the user does not recognise must be removed, not merely noted.
- Remove malicious inbox rules and forwarding. See below.
- Block sign-in if you cannot reach the user quickly and the account is
actively being used.
Steps 1 and 2 belong together. Either alone leaves a way in.
Where attackers hide
Inbox rules. The classic is a rule with a one-character name — . or a single
space — that moves anything containing bank, invoice, payment, remittance or
IBAN to RSS Subscriptions or Deleted Items and marks it read. Its purpose is to
stop the real user seeing the replies to the fraud being sent in their name. Check
every rule and its creation date, not just the enabled ones.
Forwarding. Both mailbox-level ForwardingSmtpAddress and rule-level forwards.
Sent Items. Often emptied. An empty Sent Items on a busy mailbox is itself
evidence, not an absence of it.
Mailbox permissions and delegates. Check whether anything was granted recently.
App consents. An OAuth grant to a malicious application survives a password
reset and a session revocation. Review consented applications for the user.
Investigation, in parallel
- Sign-in logs: find the first unfamiliar successful sign-in. Look for the same
session token used from two locations minutes apart — the signature of an
adversary-in-the-middle proxy, which defeats ordinary MFA because the user
genuinely approves the prompt.
- Message trace, outbound: who has been contacted from this mailbox. Everyone on
that list needs warning, and if the mail concerns payments they need warning
by phone, today, before any payment run.
- Audit log: what else was attempted. Failed privilege escalation attempts tell
you what the attacker was after.
Communication
- Warn recipients through a channel the attacker does not control.
- Tell finance before a payment run executes, not after.
- Tell the user plainly what happened and what not to do — specifically, not to
approve any further authentication prompts.
- Suppliers who received fraudulent mail should be called, not emailed from the
affected mailbox.
Do not
- Do not release anything from quarantine during an active compromise. Some of it is
the attacker's own outbound mail that the security stack successfully stopped.
- Do not close on "password changed."
- Do not hand a new credential to whoever phoned you, without verifying they are the
account holder — the attacker calls the service desk too.
Related
- Verifying a caller's identity
- Triaging a reported phishing message
- Reading sign-in failure codes (AADSTS)