One Click, One Login, Two Hours to Wire Release
Monday, 9:14 a.m. A finance user, Priya, reports a fake DocuSign email. Two colleagues clicked the link; one typed credentials into a lookalike Microsoft 365 page. At 9:20 the SIEM flags a successful sign-in to Priya's mailbox from an unfamiliar foreign IP, and at 9:18 an MFA push was approved that Priya says she did not send. A mailbox rule forwarding her mail to an external address is already in place. The tenant has 400 users, no conditional access policies, and no sign-in risk policy. Priya has wire authority, and month-end payments are scheduled to release at 2:00 p.m. today. Four service desk agents are on shift and there is no written phishing playbook.
1. Sequence your first 30 minutes. Justify the order using blast radius and reversibility.
Read the worked answer
Order by irreversibility and by what is actively bleeding.
Minutes 0 to 10: stop the exfiltration and lock the identity.
- Revoke all refresh tokens and active sessions for Priya's account. A password reset alone leaves the attacker's session alive.
- Reset the password and require re-registration of MFA methods; the approved push means an attacker may hold a valid factor.
- Delete the external forwarding rule, but export it and the sign-in logs first. The rule is the active data leak; its configuration is evidence.
- Block sign-in or restrict the account until the reset and MFA re-enrollment are verified with Priya on a known phone number.
Minutes 10 to 20: stop money from leaving. 5. Call accounts payable and the bank relationship owner by phone, not email, and hold the 2:00 p.m. release. Out-of-band verification is essential because mail is compromised.
Minutes 20 to 30: scope it. 6. Check the two colleagues who clicked and reset any credential entered; search message trace for the same sender and subject tenant-wide; check for new inbox rules, OAuth grants, and mailbox delegation on other accounts.
Reasoning: the forward rule and the live session are ongoing losses measured in minutes. The wire release is a large loss measured in hours. Both beat the slower forensic work of full scoping, which happens next.
2. Should you delete Priya's account to be safe? Defend your answer.
Read the worked answer
No. Disable sign-in; do not delete the account.
Why deletion is the wrong tool here:
- Deleting the mailbox destroys the attacker's sent items, inbox rules, and message trace evidence you need to determine what was read and which other accounts were targeted.
- Deletion can break downstream dependencies, mail flow, and the user's ability to recover her own work.
- Deleting an account does not undo what the attacker already did. Containment, not erasure, is the goal.
What to do instead:
- Block sign-in and revoke sessions and tokens.
- Reset credentials and force MFA re-registration.
- Place the mailbox on hold and preserve logs before any cleanup.
- Restore access once you have verified Priya's identity out of band and confirmed no lingering rules, grants, or delegates.
The one exception: if the account is a shared or service account with no investigative value and active abuse, disabling and rebuilding may be reasonable. Even then, preserve logs first.
Principle: in incident response, preserve evidence and contain access. Deleting things early is how investigations become guesswork.
3. What do you communicate to finance leadership before 2:00 p.m., and how?
Read the worked answer
Channel first: phone or in person, not email, because the mailbox is compromised and the attacker may be reading it. Follow up in writing once the account is contained.
Content, in plain language:
- What happened: a phishing email led to a credential compromise on one finance account; the attacker had mailbox access and a forwarding rule.
- What is already done: sessions revoked, password reset, MFA re-enrolled, forwarding rule removed, account restricted.
- What you are asking them to do: hold the 2:00 p.m. payment release and verify any payment change requests by phone with a known contact, not by replying to an email.
- What is still unknown: how much mail was read and whether any payment instructions were altered. Say this explicitly rather than implying all is well.
- Next update time and who owns it.
Tone: factual, no blame of Priya, and no speculation about the attacker's identity.
Also notify: security leadership and privacy or compliance if personal data was in the mailbox, per policy.
Do not: send a company-wide email about the incident before containment, and do not name the affected user in any broad channel.