03:12 Exfiltration Alert on a Finance Workstation
At 03:12 on a Tuesday, Redwood Logistics' SIEM raises a single alert: 41 GB outbound from FIN-WS-114, a finance analyst's workstation, to an unfamiliar IP address over 443. The analyst is on leave until Monday.
EDR telemetry shows a remote-management agent installed three days earlier from an MSI in a temp folder; the analyst had opened an invoice-themed email with an ISO attachment the day before. Microsoft 365 audit logs show two inbox rules created at 02:58 that forward messages containing "remittance" and "invoice" to an external address.
FIN-WS-114 has a mapped drive to a file server holding six years of customs documentation and driver personal data. The nightly backup writes to a NAS that is domain-joined and reachable from the same workstation. It is now 03:55. The on-call analyst has isolated the workstation at the switch port and is asking whether to reimage it now so the user can work on Monday, and whether this is a reportable incident.
1. Set out the order of operations for the next hour, with the reasoning for each step.
Read the worked answer
The alert is 43 minutes old, the transfer was 41 GB, and the attacker has had three days of access. Assume the workstation is not the boundary of the incident.
1. Preserve before touching (first, because it is irreversible). Capture volatile state from FIN-WS-114 - running processes, network connections, logged-on sessions, the MSI and its installer artefacts, browser history, the remote-management agent's configuration and logs - then take a forensic image. Everything downstream depends on being able to say what was taken and when.
2. Contain the identity, not just the host. The workstation was already isolated at the switch port, but the inbox rules were created in the cloud and will keep forwarding after the host is off. Reset the analyst's credentials, revoke sessions and refresh tokens, remove the forwarding rules after exporting them as evidence, and check for other consent grants or application registrations added to the account.
3. Protect the backups, which is the highest-impact action available. A domain-joined NAS reachable from a compromised workstation is a ransomware and destruction target. Isolate it, verify snapshots and immutability status, and check whether the backup service account was used from unusual sources. Losing backups converts a data theft into an existential event.
4. Scope. Fleet-wide EDR query on the agent binary hash, the MSI hash and the destination IP; file server access logs for FIN-WS-114's session; mail trace for the ISO attachment reaching other users. Kill the identity of the original phishing sender only after the trace has been captured.
5. Escalate. Wake the incident commander, legal and communications on a documented timeline. Nothing here should be decided by the on-call analyst alone.
2. Was isolating at the switch port the right call, and would you have chosen to monitor instead to gather more intelligence?
Read the worked answer
Isolation was correct. Monitoring-in-place is defensible when the harm is contained and observation would yield materially better intelligence. Neither condition holds: 41 GB of customs and driver personal data has already left, and every additional minute risks more extraction and possible lateral movement toward the backups. The cost of isolation is one analyst unable to work for a few days; the cost of continued exfiltration is a notification event with a rising record count.
But isolation at the switch port is an incomplete containment, and that is the teachable point. It severed the network path while leaving two things live: the remote-management agent's ability to reconnect if the host has any other path (wireless, cellular, a second NIC), and the mail-forwarding rules in the cloud. Containment must cover the host, the identity and the cloud tenant as separate planes, because the attacker uses whichever one is still reachable.
Where a monitoring decision would have been right: if the alert had been a low-confidence detection of a known commodity tool with no data movement, and the affected host were already isolated at the network layer with the identity reset, watching to enumerate the operator's infrastructure would be reasonable. Set an explicit time box for that, and an exit condition - a second detection, a data-volume threshold, or any privileged account activity ends the observation immediately.
Practical improvement: rehearse host containment through the EDR platform (network containment, which preserves telemetry) rather than at the switch, so the responder keeps visibility while cutting connectivity. And write the decision rule into the playbook so the next on-call analyst does not have to invent it at 04:00.
3. How do you handle the reimage request and the reportability question?
Read the worked answer
Reimage: no, not yet - and the request contains a false constraint. The analyst's need is a working laptop on Monday; the answer is a loaner, not the destruction of evidence. Reimaging destroys the malware artefacts, persistence mechanism, browser and mail traces, and any data staging that shows what was collected. Wait until the image is taken and the scope is established, then rebuild from a known-good baseline with the affected user's credentials reissued rather than restored.
Reportability: the on-call analyst does not decide it - but the analyst starts the clock assessment and preserves the facts the decision rests on.
- Establish whether personal data was in the 41 GB. Transfer volume proves a transfer, not content. Pull file server access logs for the workstation's session, the DLP or proxy logs if they exist, and the file system timeline from the image, to determine whether the customs documentation and driver data were among the files read.
- Fix the awareness timestamp. Many regimes - GDPR-style controller notification at 72 hours is the familiar example - run from when the organisation became aware, not from when the investigation finishes. Document the moment the alert was validated, because that timestamp will be scrutinised.
- Route to the decision-makers with the facts: incident commander, legal counsel, privacy officer, and the contractual owners for the driver data. Reportability is a legal and management judgement applying multiple regimes and contracts; the technical team's job is to supply an accurate account of what data was involved and when.
- Do not delay containment while debating notification. Those are parallel tracks.
Also add the vector to the follow-up list: ISO attachments arriving by mail, and mail rules creating external forwards, should both generate alerts by default.