This is a constructed example of an XDR incident that joins signals from email, identity and an endpoint, then moves to containment and lessons learned. The company, people and times are invented to show the reasoning. It is not a real incident.
XDR, extended detection and response, correlates signals across sources. This story shows why that matters: three modest alerts become one clear incident.
The setting
A logistics software company with 120 staff uses an email suite, a single sign-on provider and an endpoint agent on laptops, all feeding one XDR console. A two-person security team shares an on-call rota with a managed service that covers nights.
09:02: Three small signals
The console shows three alerts, separate in the raw feeds.
- Email: a message with a link to a credential page was delivered to six staff and flagged low confidence.
- Identity: a sign-in for an accountant, Dana, came from a new device and an unusual country, passing the password step.
- Endpoint: on a different laptop, a browser spawned a script interpreter, which the rules mark as unusual but common in developer work.
On their own, an on-call analyst might snooze each. The XDR correlation groups the first two into one incident because the accountant was one of the six recipients and the sign-in came within an hour of delivery.
09:10: Triage
The analyst opens the grouped incident. She asks three questions. Did the user click? The email log shows a click from Dana's address at 08:41. Did the sign-in succeed beyond the password? It did, which suggests either no multi-factor sign-in on that path or a stolen session. What did the account do afterward? The identity log shows a new mail forwarding rule and a download of a customer invoice export.
This looks like credential theft followed by data access. NIST SP 800-61 Rev. 3 frames response as a cycle where detection and analysis lead into containment and recovery, and she moves to contain.
09:18: Contain
Her response guide allows these actions without approval: revoke active sessions, reset the password and disable the forwarding rule. She does all three. She also blocks the link's domain in email filtering, and pulls the same message out of the other five inboxes.
She leaves the account enabled but locked behind a reset, since disabling it entirely would cut off month-end work and she can confirm with Dana by phone.
09:30: Check the third alert
The endpoint alert from another laptop is checked on its own merits. It belongs to a developer who runs build scripts, and the process tree matches a known build job. The analyst records it as benign with a note, and creates a narrow tuning request instead of a broad exclusion. Correlation helped here too, since the lack of any link to the phishing message made it low priority.
10:15: Scope
She calls Dana, who confirms she entered her password on the page and did not approve any prompt. The sign-in provider's log shows the attacker's session lasted twelve minutes. The invoice export held customer names and amounts. She hands the facts to the managing director and the privacy contact, who decide whether to notify customers. That is their decision, not an analyst's.
She searches for the same sender and link across other mailboxes and finds no other clicks. She asks the identity team to list accounts that sign in without a second factor.
Next day: Root cause and fixes
The root cause was a sign-in route that did not require a second factor for a legacy mail protocol. Fixes: block that protocol, require multi-factor sign-in for all finance accounts, and add a rule alerting on new forwarding rules after an unusual sign-in. NIST SP 800-53 control IR-4 includes incorporating lessons learned into procedures, training and testing, and the team schedules a short phishing exercise for finance.
What the example shows
Correlation turned noise into an incident. The strongest actions were quick, reversible and within pre-agreed authority. The second part of the work was fixing the sign-in gap. And one of the three alerts was benign, a reminder that XDR groups signals but people judge them.
What to do
- Write a response guide that lists actions on-call may take alone.
- Require multi-factor sign-in on every path, including legacy ones.
- Alert on new mail forwarding rules after unusual sign-ins.
- Record benign findings with a narrow tuning request.
- Hand notification decisions to the right owners.
- Turn each incident into a rule or setting change.
Quick check
Is this a real incident?
No. It is constructed for illustration. All names, systems and times are invented.
Why not disable Dana's account entirely?
Revoking sessions and forcing a reset stopped the attacker while keeping month-end work possible. Choose the narrowest effective action.
Sources
Last reviewed: 18 October 2026.
