Token Theft and 800 GB Out the Door at 02:40
At 02:14 UTC on a Tuesday, EDR alerts on a developer laptop for LSASS access by an unsigned binary; the analyst isolates the host at 02:26. At 02:40, cloud detection fires: a service principal authenticates from an ASN in a country where the company has no staff, MFA was satisfied, and Graph calls enumerate storage accounts. By 02:52, 800 GB has egressed from three production storage accounts holding support ticket attachments - 12,000 files with names, emails and masked PANs, and roughly 300 with full PANs. The developer is travelling and unreachable, and their laptop holds a live console session. The SOC has five analysts and no retainer; the IR plan was last tested two years ago; legal counsel is unavailable until 08:00. The support portal drives 40% of revenue and 340 agents are mid-shift. GDPR and card-brand contract clocks are in play.
1. Set the containment order between 02:52 and 06:00. What do you do, what do you accept as collateral damage, and what must you not do?
Read the worked answer
A confirmed compromised credential outranks convenience. Sequence:
- 02:52-03:00, revoke the service principal: remove credentials and secrets, disable the app registration, but capture its configuration, owners and permission grants first so you know what it can reach. Do not delete the object - deletion destroys the audit trail you need for scoping.
- 03:00-03:10, invalidate sessions and refresh tokens tenant-wide. This logs out 340 support agents mid-shift. Accept it: a live adversary holding a valid token is worse than a short support outage. Tell the support floor lead before you do it, not after.
- 03:10-03:30, block the source ASN and IPs at the edge and add deny rules on the storage accounts for non-corporate networks. Preserve read access for the business where the traffic is legitimate; the activity observed is reads, not ransomware.
- 03:30-04:00, do not power off or reimage the developer laptop. Capture memory, then image the disk. Disable the user account and revoke console sessions, leaving the isolated host running for forensics.
- 04:00-06:00, export activity logs to write-once storage before retention windows or attacker cleanup touch them, and snapshot storage access logs.
Do not attempt full eradication before scoping. The 800 GB has already left; the goals now are stopping a second transfer and learning what else the principal could reach.
2. How do you scope the compromise and preserve evidence given five analysts and no retainer?
Read the worked answer
Scoping answers three questions: how the credential was obtained, what the adversary touched, and whose data was in the objects.
- Credential origin: on the laptop, examine browser history, clipboard contents, shell history, recently modified files and any process that read browser credential stores. Correlate with the LSASS alert timing. Determine whether the token came from a session cookie, a config file or a CI secret - each implies a different wider exposure.
- Cloud: pull all activity for the principal and the tenant from 30 days before the first anomaly. Query by IP, ASN, user agent and object ID, not just the known IPs. Look for new app registrations, consent grants, mailbox rules, key vault access and role assignments, because persistence usually hides in identity rather than storage.
- Data: storage access logs give object lists. Classify by content: 12,000 files with names, emails and masked PANs; about 300 with full PANs. Full PANs escalate everything - card-brand notification, a PCI forensic investigation and possibly acquirer involvement.
- Preserve: write-once copies, hashes, chain of custody. A forensic firm engaged later will want raw logs, not dashboard screenshots.
Assume the credential was not the only asset taken and hunt for any principal created after the first anomalous access. With five analysts, assign two to identity, two to data, one to the endpoint and timeline.
3. At 08:00 legal and the DPO are available. What is your notification recommendation and how do you justify it?
Read the worked answer
Decide with counsel, but decide today.
- The GDPR 72-hour clock starts at awareness of a personal data breach, not at completion of scoping. Awareness is defensible from around 02:40-03:30. Waiting for a complete picture is not a valid reason to miss the deadline; a notification can be updated later.
- Test the threshold: is there a risk to data subjects? Names, emails and card data in 12,000 files plus 300 full PANs says yes. The 'unlikely to result in a risk' exemption does not apply. If you are a processor for any of these records, notify the controller without undue delay rather than the regulator directly.
- Card data: the acquirer contract almost certainly sets a notification window, often 24-72 hours, and requires a PCI forensic investigator. Read that clause at 08:00, not at 17:00.
- Sequence: brief legal and the DPO with the facts you have, the gaps and a recommendation; draft the regulator notification in parallel with scoping; prepare a customer statement; brief the CEO before the first external call.
Document every decision with time, decision-maker and rationale. Regulators and courts assess whether you acted reasonably under uncertainty, not whether your first assessment was perfect - and the decision log is the artefact that shows it.