A spoofed "IT Helpdesk" password-expiry email goes out to eight mailboxes. By the end of the window one attacker is sitting in a corporate mailbox with an external forwarding rule quietly copying every new message out of the organisation.
The interesting part of an incident like this isn't the timeline — it's the triage. Eight recipients produce five materially different outcomes, and the difference between them isn't who was careless. It's which control happened to be in place at the moment each one made a decision, and which of those decisions left a log behind.
What the logs can and can't tell you
Three of the five stages below are covered by a catalogue rule. One isn't, and that gap is the
whole lesson: credential submission happens on attacker-controlled infrastructure. No internal
log source sees the password. The best available signal is a POST to the phishing URL
immediately after the GET that loaded the page — which is why the "who clicked" versus "who
entered credentials" split in the table below isn't asserted from the narrative. It's correlated
out of a web proxy log, and a test in
DetectionAuditTool fails if the two ever
disagree.
One recipient has no proxy or EDR telemetry at all — the mail was opened on an unmanaged personal
device. She stays Unknown no matter what plan you build, because a containment cap tells you
nothing about a user you cannot see. That row is the honest one.
Work the kill chain
Expand any stage for its detection rule, its MITRE technique, and the response actions available at that point. Check a response action and the impact panel recomputes: checking one assumes that control existed before the campaign started, capping how far every recipient could get.
Stages flagged amber have either no detection rule or no response action in your plan yet. The
goal isn't to check every box — it's to find the cheapest set of controls that moves the most
people out of Compromised.