An AWS Breach, Answered in 30 Minutes:
A Realistic Timeline

Larkspur Freight Software is fictional. So is everything that happens to it below: the people, the accounts, the CI system, and the attacker. This is a composite scenario, built from published research on leaked AWS keys and from how Vantalect's incident engagement is designed to work. No client lived it.

One caution before the clock starts. The "30 minutes" in the title runs from counsel's call to Vantalect, not from the first alert. Larkspur's own team spends about 38 minutes before outside counsel calls Vantalect, which is realistic, and the next 30 are fast because Larkspur prepared. Without a Retainer there is no response-time commitment.

The Company and What It Had in Place

Larkspur (larkspurfreight.example.com) runs a freight-matching platform: 1,100 employees, 26 AWS accounts in one organization, and shipper manifests, rate contracts, and scanned driver identity documents in S3. On the night in question these things were already true:

• An organization trail collects management events from every account into a log-archive account. Member accounts can see it but cannot change it.
• S3 data events are on for two of the nine buckets that matter: manifests and contracts. The other seven have none.
• GuardDuty is on in every account and every Region, including the ones Larkspur never uses, with S3 Protection off. Only High-severity findings reach the on-call pager, through an EventBridge rule in each Region; Medium and Low findings wait in a queue reviewed weekly.
• The AWS Security Incident Response service is enabled.
• Larkspur signed a Vantalect Retainer 19 days before the page. The incident role is already in every account, with every call denied by a policy Larkspur's approver owns. It has a call sheet, a guardrail pack of containment policies stored detached in its own repository, and a half-day tabletop behind it. The log-readiness check named the seven buckets without data events and the monthly cost of each fix, and the watch's forwarding rules were scheduled for the following week. Neither was in place yet.
• Its broker asked the insurer, before any incident, to list Vantalect as a named non-panel provider.
• Counsel has read Vantalect's draft incident forms, which bind no one.

The people: Priya Nandakumar is the on-call platform engineer. Marcus Doyle is the CISO and incident lead. Janelle Ortiz, VP of cloud operations, is the named approver. Elena Whitcomb is general counsel, Tomas Reyes is outside counsel, and Harborline Risk Advisors is the broker. Charles is Vantalect's responder. He directs software agents (AI tools) under his supervision and reviews every deliverable.

What Had Already Happened (Nobody Knew)

The Investigation later reconstructed this from the trail. At the first alert Larkspur knew none of it.

A debug flag in a CI job printed its environment, including the long-term access key of an IAM user named ci-deploy, into a build log. A contractor pasted a link to that log into a public forum thread. The key was three years old, never rotated, and broader than a deploy pipeline needs.

Published studies show how short the gap can be. Comparitech (2022) saw a key published on GitHub abused within a minute. Palo Alto Networks Unit 42 (2023) saw an actor use leaked keys within five minutes and mine Monero on large instances. Treat a key in a public place as used.

From there the attacker did the ordinary things in the ordinary order:

1. Discovery. Eleven days before the page, calls from an outside address, 203.0.113.41, asked who the key belonged to, what it could do, and which buckets existed.
2. Persistence. Nine days before, the attacker created a second IAM user, aws-health-sync, with a key and an administrator policy, and kept asking for temporary sessions with the original key, most recently the evening before the page. Those sessions outlive the key.
3. Role chaining. The pipeline user could assume a deploy role in the production data account. The attacker did too.
4. Theft from S3. Over four nights, roughly 1,900,000 GetObject calls hit the manifests bucket from the outside address, each recorded by the data events. What left in full is a question for the Investigation.
5. Tamper. The attacker stopped logging on one account-level trail. The organization trail kept recording. GuardDuty raised a Low-severity Stealth:IAMUser/CloudTrailLoggingDisabled finding, which did not page, and the weekly queue had not been read.
6. Monetizing. Two hours before the page, the attacker launched large instances in four Regions Larkspur never uses, with a mining script in the user data.

That last step trips the alarm. A first alert is almost never the first event.

The Master Timeline

Two clocks run here. "Alert" is time since the first alert. "V" is minutes since counsel's call to Vantalect (V+0). All times are Central Daylight Time (CDT), on a Tuesday, and all are invented.

Phase 1: The First Alert to the Lawyer (Alert +0:00 to +0:38)

None of this is Vantalect's. It is Larkspur's runbook. Priya's job is to learn what is happening without making it worse or erasing anything, and to get the right people on the phone.

She opens the finding, then CloudTrail event history, which keeps 90 days of management events for each Region. Event history is per Region, so she searches by the access key's ID in each. In eight minutes she has the caller (ci-deploy), launches in four Regions, and a user she has never heard of. The pager said "cryptocurrency." The log says someone holds the CI key.

Here is what she does not do:

• She does not terminate the instances. They are evidence. Disk contents, user data, and network state vanish with them.
• She does not delete the key. A deleted key cannot be reactivated. A deactivated one can.
• She does not delete the strange IAM user. It is persistence, and persistence is evidence.
• She does not run discovery with the stolen key. That adds noise to the record and tells the attacker someone is looking.
• She does not rotate the production key in place. If the attacker found where it is stored, the new key goes to the same place.
• She does not check one Region. The actor used four.

She starts a UTC log with the source of every entry, then calls Marcus. He does three things: declares an incident; names himself lead and Janelle the single approver for any change to AWS, so nobody guesses whose "go" counts; and moves the response to a phone bridge.

The call to counsel is the most consequential call of the hour and the one most often delayed. Elena phones Tomas at 02:36. The broker hears at 02:41, because cyber policies commonly require prompt notice and consent to a vendor is better asked for early. Whether any notice is required is a question for the broker and coverage counsel.

Priya also opens an AWS case through the Security Incident Response service, which gives Larkspur case tracking with AWS's incident response team. AWS's documentation says the service does not do forensic disk or endpoint analysis, legal or regulatory guidance, or attribution, so the work below sits beside it. Nothing here depends on how quickly AWS answers.

At 02:45 Tomas is on the call. He asks his questions and decides that the response goes through counsel. He directs the preservation holds, and nothing is said to anyone outside the bridge without his advice. Nobody asks Vantalect whether anything is reportable.

Phase 2: Counsel Calls, and the Bridge Is Staffed 30 Minutes Later (V+0 to V+30)

At 02:52 counsel phones the number on Larkspur's call sheet. Everything after that was rehearsed, which is why it fits in half an hour.

V+0 to V+5, the call-back. Charles calls back and joins Tomas, Marcus, and Elena. A Retainer holder has a written 30-minute call-back commitment. A client without a Retainer has no commitment, because one responder cannot promise a response time while he may be on another client's bridge.

V+5 to V+10, intake. What do you know, and how? What have you touched? Is the role deployed? Who approves? Which log sources exist? Charles reads the answers back and asks what breaks if the pipeline key goes off, because that is Janelle's decision.

V+10 to V+15, the paper. Tomas signs a Counsel Engagement Letter and an incident statement of work, both written new for this incident. Counsel retains Vantalect to help counsel give legal advice, and the work bills to counsel's matter, not to engineering. The letter, which Larkspur also signs as the account owner, grants written authority to access the accounts and take each containment action it names. Marcus sets the not-to-exceed figure with Tomas (the default is 80 hours). Vantalect warns at 80% of it and, at the figure, finishes the action in progress, says in writing what is left unprotected, and waits for a written extension.

Signing new papers is the point. A pre-incident services agreement, or a bill in engineering's budget, can undercut the claim that the work was done for counsel. Whether it does is for counsel to say.

V+15, one call. Janelle removes the deny policy on the incident role in every account. Until then the role can be assumed but every action is denied. Activation is a single act by Larkspur's approver, and the trail records it.

V+18, the first read. Charles assumes the role, which is read-only in workload accounts. Interceptor, an Acumen Defensive tool that Vantalect licenses and operates, already has a case database in Larkspur's audit account, set up under the Retainer. The forwarders that would feed it were scheduled for the following week, so Charles loads it from the organization trail. It holds no write credential. It follows a principal across the organization and rebuilds its sessions.

V+23, the first tree. Charles gives Interceptor the access key as a seed. In minutes it answers the responder's first questions: who this is, where the credentials came from, what else they hold now, and what they created that will outlive the credentials about to be switched off.

V+30, the bridge. Charles, Marcus, Janelle, Priya, and Tomas are on it. Charles reads a one-page plan: what is known, what is not, what he proposes and in what order, and what each step costs the business.

Stage 0, activation, is done: the role works and the bridge is staffed. Larkspur's incident is 68 minutes old, the miners are still running, and no attacker credential has been touched. That is deliberate: everything is captured before it is changed.

Phase 3: Following the Sessions, Then Containing Them (V+23 to V+1:59)

This is Stage 1, stop the bleeding. It ends when the attacker's credentials show no successful write for 60 minutes.

What Interceptor shows

For ci-deploy, Interceptor returns a tree. Each link records the key that joined two sessions and the events that hold it:

• The original key, used from the outside address.
• Two temporary sessions the key requested. People miss these. Deactivating the key does not end them, because a GetSessionToken credential works until it expires, up to 36 hours later.
• A role session in the production data account, chained from the pipeline user.
• The new user, aws-health-sync, and its key, both marked tainted because a followed session created them. A taint starts at the creating event and does not reach back before it.
• The four Regions of RunInstances, tied to the same sessions.

Interceptor's alerts flag trail tampering, IAM persistence, and "any action by a tainted principal." Three kinds of credential are live, not one, so Decisions 1 and 2 go to Janelle as one package: she signs the first at 03:41 and the second at 03:47, and Priya runs both together at 03:47. Cutting the key first and the sessions later would warn the attacker and leave a path open. Interceptor's containment is propose-only: it writes each change as a runbook with an approval step and never runs it.

Capture before change

From V+33, Charles captures what each step is about to change: credential reports, access-key last-used data, IAM policies, active sessions, and the resource settings the steps touch. Each item is hashed, saved to a locked location, and entered in the custody log. This slows the first minutes and saves the next weeks, because a responder who changes settings first cannot later show what they were.

Four decisions

Charles proposes each decision, Janelle approves it in the approval step, Priya runs it with Larkspur's own access, and it is logged with its rollback. She hears the business cost before she signs.

Why these four are shaped this way:

• Decision 2. A policy that checks token issue time denies sessions created before it, takes a few minutes to spread, and also hits Larkspur's own staff on that role.
• Decision 3. Service control policies do not apply to the management account or service-linked roles, and AWS advises testing on an organizational unit before the root. Larkspur's pack was validated at the tabletop, so Charles is attaching a tested policy, not writing one at 3 a.m.
• Decision 4. CloudTrail will not show what an instance was told to run, so Charles asks for the user data first. Vantalect's footprint is read-only in workload accounts, so Priya runs its runbook to take the disk and, where the image allows, memory from one miner. Snapshots are copied into the forensic account under a key it owns, because a snapshot encrypted under a key the attacker could disable is not safe evidence. One under the default aws/ebs key cannot be shared, so Priya first copies it under a customer managed key the forensic account may use. The custody entry records each snapshot ID and the hash of the image taken from a volume restored in the forensic account. Terminating comes later and needs its own signature.

At 03:51 the last successful write lands, one more launch from a session whose deny had not yet taken effect, because IAM changes take a few minutes to spread. After Decision 3 the attacker's attempts are denied, and the denials appear in the trail, which is useful in itself. The 60-minute clock runs from 03:51 and expires at 04:51 with no successful write. Stage 1 ends 1 hour and 59 minutes after V+0.

The attacker is out of the access path and has not been told how. A responder who cuts one credential and leaves another teaches the attacker to hurry.

Phase 4: Evidence Under Object Lock (V+33 Onward, in Parallel)

Stage 2, preserve, begins while Stage 1 continues. Charles asks for a new AWS account for evidence in its own locked-down OU, and Priya builds it from his template. The evidence bucket is versioned, with S3 Object Lock in compliance mode. In that mode no user, including the account's root user, can overwrite or delete a protected version until its retention date. A lock cannot be shortened, so the retention period is a legal decision as well as a technical one, and it is Tomas's call.

The period is 90 days before the first alert, widened to the earliest observed attacker event. Into the bucket go:

• The organization trail's log files for that period, copied from the log-archive account.
• (Beside the bucket, not in it) A CloudTrail Lake event data store in the forensic account, imported from the same trail files and queryable with SQL. The locked files stay the evidence.
• GuardDuty findings (AWS keeps them 90 days), VPC Flow Logs where they existed (none in the four unused Regions), and the captured IAM state from before each change.
• The miners' snapshots and user data.
• The CI build log and access log, which Priya exports from the vendor. They sit outside AWS, enter as a named source with a custody entry, and the vendor-side copy stays until counsel agrees.

Every item is hashed when collected and again after each transfer. The custody log records who collected it, from which resource, when, how it was hashed, and every transfer, so counsel can authenticate it. AWS says CloudTrail delivers logs within an average of about five minutes of an API call and that this is not guaranteed, so Charles copies the period now and again after the lag.

The Stage 2 test is that the log covers every source named at activation. That does not make the sources complete. Only two of nine buckets had data events on. For the other seven, the IAM and bucket policies show who could reach them, but no log shows what was read. Charles reports that as a gap, without guessing.

Phase 5: Day by Day

Day 0, Tuesday

The first situation report goes out at V+1:30, then every 12 hours (more often in Stage 1): confirmed facts, labeled hypotheses, actions, decisions needed, clocks running, and what is not yet known.

At 08:52, six hours after counsel's call and inside the six-hour commitment from activation, the first notification-clock worksheet goes to counsel. It lists deadlines that may run from Larkspur's own determinations, computed from the times Larkspur enters, with the facts each one needs. It is a worksheet for counsel, not legal advice. Which clocks apply, and when they started, is for counsel to decide. It records dated facts: the earliest event observed so far, detection, containment, and the data types reachable. "Earliest observed so far" is the honest phrase, because logs arrive late and the date can move.

Stage 3, protect and recover, asks whether any data is at risk of disappearing: an expiring key, a deleting lifecycle rule, a scheduled key deletion. The attacker did none of those things, so there is no vault account in this story. The report says why.

Day 1, Wednesday

Stage 2 closes: every source named at activation is copied, hashed, and logged. Stage 4, eradicate, follows the rule that persistence is preserved before it is removed.

• Janelle signs the removal of aws-health-sync (key, policies, user), already preserved.
• Janelle signs the deletion of the preserved ci-deploy key. The pipeline resumes on a narrowly scoped credential Larkspur's engineers issue.
• The initial access path is closed: the CI project's logs are restricted and the debug flag is off.
• Janelle signs the termination of the miners after Tomas confirms in writing that preservation is complete.
• The account-level trail the attacker stopped is restarted with StartLogging, after its stopped state is preserved.
• The deny-list SCP stays.

Stage 4 ends when following every attacker credential shows none alive. Charles runs Interceptor's follow again from the original seed and from the new user. Nothing is live, and no tainted principal has made a successful call since 03:51.

Rotating every secret in the estate and rebuilding the pipeline on federated credentials belong to the Recovery, not the Response.

Day 2, Thursday

Marcus declares containment in writing; an email is enough. The Response delivers six reports in three groups:

• Containment and Eradication Actions, operational: every action, who approved it, what it changed, what was preserved first, and how to undo it.
• Situation Reports, Executive Brief at Containment, Notification-Clock Worksheet (updated), and Chain-of-Custody Log, counsel only.
• Interim Factual Statement, releasable through counsel: facts only, with no analysis or opinion, for the auditor, insurer, a regulator, or the board.

The hours were logged in six-minute increments in a log Larkspur could read all along. The Response is billed by the hour, at the Response rate, through counsel's matter, with no premium for nights, weekends, or holidays.

The Hand-Off: Investigation and Recovery

Containment answers one question: is the attacker locked out? It does not say how they got in, what they reached, or whether they left anything behind. That is the next engagement, AWS Breach Forensics & Recovery.

• The Investigation runs two fixed weeks. Week one preserves and maps the estate and records log gaps. Week two traces every attacker session across accounts and role chains and produces the timeline, the compromise inventory, indicators, causes, and a legal-considerations draft and clock worksheets for counsel.
• The Recovery runs four weeks. It includes the Investigation, then removes and verifies every confirmed item, fixes critical root causes as code through Larkspur's own repositories, attaches guardrails that would have stopped this attack, and ends with a closure sweep.

Preservation and tracing hours the Response already spent are credited, up to a cap, against the signature invoice of an Investigation or Recovery.

For Larkspur, the Investigation would list the GetObject calls on the two buckets with data events: prefixes, counts, and times. It would say which of the other seven the attacker's roles could reach, not what was read there, because no log recorded it. A missing log is a finding with a fix and a monthly cost, not a guess.

Whether any of that triggers a notice, to whom, and by when is counsel's decision. Many clocks run from when the company discovers or determines something, and some from when it should have known, not from the attacker's first call. That is why dated facts matter. Which clock applies is for counsel to decide.

What This Scenario Does Not Claim

• Thirty minutes is not a promise. It is what a rehearsed team can do on a good day. The written Retainer commitments are a 30-minute call-back after a page and a two-hour hands-on window after counsel signs, with service credits when missed. Without a Retainer there is no response-time commitment.
• Not every step is fast. AWS publishes no latency for CloudTrail to EventBridge or for how soon GuardDuty produces a finding, so this guide gives none. GuardDuty's anomaly findings depend on a model of normal behavior, so a first-use finding on a new key is not guaranteed. Larkspur's alert came from mining; another company's might not come at all.
• Containment covers AWS. Laptops and the CI vendor are outside AWS and outside the Response's evidence unless named.
• It does not say what the law requires. Nothing here says an incident is reportable, material, or not a breach. Notification clocks are "counsel decides."
• It does not involve the attacker. Vantalect never contacts, negotiates with, or advises on paying an attacker, and never hacks back.
• AWS's quarantine policy is not containment. If AWS had found the key, it would have attached AWSCompromisedKeyQuarantineV3; AWS says to leave it in place. As we read the page on 10/30/2026, it does not list role assumption or snapshot-sharing actions. Read the current page before relying on it.

Who Does What

What Larkspur Could Have Done Earlier

Larkspur was well prepared and still had an attacker in its accounts for 11 days. Each item below would have shortened that or shrunk the damage.

1. No long-term keys in CI. The breach began with an IAM user key that lived three years. Short-lived federated credentials leave nothing long-lived to leak; one printed in a log expires within the hour. This one change would most likely have ended the story at step one.
2. Secret scanning on build logs and repositories, with push protection. A secret that reaches a public place should be treated as used, and scanning catches it before the first abuse, not after the page.
3. A pre-provisioned incident role, denied by default. It is why V+15 was one call, not an hour of troubleshooting at 3 a.m.
4. Logs that exist before the incident. An organization trail, data events on the buckets that matter (not two of nine), CloudTrail Lake, VPC Flow Logs, and an evidence bucket under Object Lock. Missing logs cannot be created afterward.
5. Guardrails tested in advance. A validated deny-list SCP makes Decision 3 an attachment, not an authoring job.
6. Detection of the first steps, not the last. Alerts on CreateUser, CreateAccessKey, StopLogging, and GetSessionToken by a pipeline user would have fired nine days before the mining did.
7. Paper in advance. Draft forms counsel has read, a second contact who can sign, and a broker who has listed the vendor.
8. A tabletop. A half-day exercise for the incident team and counsel finds the missing number and the unanswered question in a room, not at 2 a.m.

The Retainer covers items 3, 5, 7, and 8, checks item 4 and prices each fix, and adds an alerting watch. Its prepaid hours pay for that readiness work and not for an incident, which is billed separately, through counsel, by the hour, at the Response rate. The Retainer is Not yet offered, and its terms are under counsel review, so treat the list as a checklist you can run yourself or with any firm.

If you want to see how a breach unfolds from the attacker's side first, read The Lifecycle of a Breach. For the engagement this guide illustrates, see AWS Incident Response. For the next step after containment, see AWS Breach Forensics & Recovery. For a deeper worked case with every report, read Wrenfield.