Active Attacker, 210 Customers, and a GC Who Wants Ten Days
On a Friday at 21:00, Kestrel Software's IR retainer confirms an attacker had access to a build server for 6 days and exfiltrated 40 GB to an unknown IP. Kestrel is a B2B SaaS vendor; its enterprise contracts carry a 72-hour breach notification clause. The affected data appears to be source code and CI logs; those logs contain 12 customer API tokens printed by a debug flag. 210 enterprise customers are affected, 3 of them in the EU. The attacker still has an active session on a secondary host. The CEO wants a status-page note published tonight; the General Counsel wants silence until forensics completes in 10 days; the head of sales wants to call the 3 EU customers on Monday because 'they'll find out anyway.'
1. The attacker is still active and notifications are pending. What is the order of operations for the next 72 hours?
Read the worked answer
These are parallel tracks, not a sequence. The trap is treating 'contain, then investigate, then notify' as a queue - that is how the 72-hour window expires.
Track 1 - contain, tonight. The active session is the only item that gets worse by waiting. Isolate the secondary host at the network layer, but capture memory and volatile state first if you can do both; you need to know what tooling was used and whether persistence exists elsewhere. If isolation risks destroying evidence, isolate and preserve in the same action rather than choosing.
Track 2 - revoke credentials independently of notification. The 12 API tokens in CI logs are compromised the moment they were printed. Revocation is a technical action, not a communications decision, and nobody needs to approve it.
Track 3 - scope to a defensible standard, not a perfect one. 'What data, whose, how many' needs to be good enough to notify, not forensic-grade. Six days of build-server access with 40 GB egress means you must assume source code and CI secrets are gone.
Track 4 - legal and comms, in parallel. Awareness of a breach has already occurred; the analysis clock and the notification clock are different clocks. Do not let tracks 1-3 gate track 4.
2. Who must be notified, and what specifically is the General Counsel getting wrong?
Read the worked answer
The GC's position inverts the order of operations. Waiting 10 days for forensics makes the notification accurate and makes it late. Notification obligations are generally triggered by awareness of a breach, not by completion of the investigation, and most regimes accommodate phased notice: an initial report with confirmed facts and a commitment to update. The initial notice does not need to be the final report.
Specifics to press on:
- The EU customers. Under GDPR, the 72-hour clock to the supervisory authority runs from awareness and is not suspended pending forensics. Whether Kestrel notifies a regulator or notifies its customers as a processor depends on its role in each relationship, and the answer may differ per contract. That is a question for counsel - but 'we will decide in 10 days' is not one of the available answers.
- The contract is a separate clock. The 72-hour clause is a private obligation owed to 210 customers regardless of what any regulator requires. Breaching it to improve the wording of a notice trades a legal risk for a commercial one.
- The CEO's status page note is fine if it is factual - unauthorized access to a build system, containment underway, next update at a stated time - and harmful if it speculates about customer impact before notice has gone to those customers, or if it discloses detail that helps the attacker.
- Sales calling three customers on Monday ahead of formal notice creates an inconsistent record and invites the question of why the other 207 were not told.
Notification is not a substitute for remediation; both proceed.
3. Twelve customer API tokens were printed to CI logs. What is the correct action, and what is the risk of simply rotating them?
Read the worked answer
Revoke, but export the evidence first. Check the token audit logs and authentication records, export them, then revoke. If log retention is short, revoking without capturing use deletes the only way to answer 'were these used, from where, against what.' Sequence matters here in a way it does not for the build server host, where containment comes first.
Risks of rotating and stopping there:
- Rotation does not evict derived access. If a token could create keys, roles, or service principals, the attacker may have made their own credentials. Hunt for identities, keys, and permissions created during the six-day window and since. Rotating the original leaves the copies working.
- The logs may not be the only copy. Tokens printed to CI logs are frequently also shipped to a log aggregator, an APM vendor, or a support ticket. Rotation is incomplete if the value remains readable in three other systems.
- Uncoordinated rotation breaks customers silently. Twelve integrations failing at once produces support load and, worse, customers disabling the check that would tell them something is wrong. Coordinate the cutover with a stated deadline and a fallback.
- Rotation is containment, not eradication. The build server was accessed for six days; assume the CI pipeline itself is untrusted. Rebuild from known-good, and treat anything the pipeline produced in that window as suspect.
Tell customers what was exposed, when it was revoked, and what they should check - that is the part that determines whether this becomes a trust incident.