The Lifecycle of a Breach:
From First Foothold to Lessons Learned

Picture a company with a few dozen AWS accounts and a platform team that ships daily. On a Tuesday afternoon, an engineer pushes a debugging script to a public repository. The script contains a long-term access key for an IAM user, because the key was the quickest way to make it run. The user can read most of S3 and create IAM objects. Nobody thinks about the script again.

Within minutes, someone else is using the key. They list the Regions, the users, the buckets. They create a second access key on the user, so that rotating the first won't end their visit. A few days later, having given themselves broader rights, they share a snapshot of a customer database with an account they own and copy it there. Weeks after that, a customer writes in to say their data is for sale.

The company's incident response starts on that last day. The breach started weeks earlier.

This is a composite scenario, not one client's incident. A breach is not an event. It is two lifecycles running at once, and the gap between them is where most of the damage accumulates.

This guide follows one breach from the attacker's first foothold to the lessons-learned meeting. It is written for a CTO or head of security at a company on AWS. It is not legal advice, and where a legal question comes up it says so and points you to counsel. For a realistic timeline of one breach, from the first alert to containment declared, read An AWS Breach, Answered in 30 Minutes.

Two Lifecycles at Once

The attacker has one lifecycle and the defender has another. They start at different times, and for a long stretch only one of them knows it is running.

The attacker's lifecycle

The attacker's side is described by MITRE ATT&CK, which lists tactics in the order an intrusion usually moves through them. The cloud (IaaS) matrix has no columns for Reconnaissance, Resource Development, or Command and Control, which tells you something: for a cloud breach, the preparation usually happens somewhere other than your account.

A note on names. In its current version (v20 when we read it on 10/30/2026), ATT&CK splits the older "Defense Evasion" tactic into Stealth and Defense Impairment. GuardDuty names findings by its own threat purposes (its CloudTrail finding is Stealth:IAMUser/CloudTrailLoggingDisabled, while others still begin DefenseEvasion:), and the AWS threat technique catalog still uses old IDs such as T1562.008, where the current matrix lists "Disable or Modify Cloud Log" as T1685.002. If two sources disagree on an ID, this is probably why.

The defender's lifecycle

NIST SP 800-61 Revision 2 (2012) is the familiar four phases: Preparation; Detection and Analysis; Containment, Eradication, and Recovery; and Post-Incident Activity. NIST SP 800-61 Revision 3, final in April 2025, supersedes it and re-expresses incident response through the six functions of the Cybersecurity Framework 2.0. In NIST's model, Detect, Respond, and Recover are the incident response activities. Govern, Identify, and Protect are the broader risk management activities that support them. A third piece, the Improvement category (ID.IM) inside Identify, takes lessons from every function. Revision 3 is a loop, not a line.

The AWS Security Incident Response Guide says it follows Revision 2. It has three aspects: Preparation, Operations, and Post-Incident Activity. Operations has five phases: detection, analysis, containment, eradication, and recovery. AWS is explicit that the phases "do not necessarily happen sequentially": after containment you may need to go back to analysis, and you will.

AWS also separates incidents by domain: service (accounts, IAM, billing, handled by API calls), infrastructure (instances, networks, disks), and application. Our scenario is a service-domain incident, and AWS's own example is the same: a leaked long-term IAM key used to read S3 objects.

Putting the two side by side

The table lines them up, with two cautions. The rows are not a clock: a stage can take minutes or months. And the defender's column only starts when somebody notices. Detection can happen at any row, and in the scenario above it happened at the last one.

The defender's response does not begin at Initial Access. It begins at whichever row detection happens. The earlier that row, the cheaper everything after it.

Dwell Time, and Why Detection Is the Long Pole

Dwell time is the time between the attacker getting in and the defender finding out. Every other stage of the defender's lifecycle is work you do once you know. This one is waiting for a signal while the attacker works.

What the reports measure

Vendor reports publish dwell and detection figures, and they do not measure the same thing. Treat each as that report's figure, not as an industry fact.

• Mandiant M-Trends 2025 (Google Cloud, published 04/23/2025, investigations from calendar year 2024) reports a global median dwell time of 11 days, up from 10 the year before. It splits the median by who found the intrusion: 26 days when an external party notified the victim, 10 days when the organization found it itself, and 5 days when the attacker announced it, which is typical of ransomware. The sample is clients who hired Mandiant, so it is not all breaches. M-Trends 2026 has since reported a 14-day median for 2025. We have seen that figure only in a press summary (Help Net Security, 03/24/2026), so confirm it in the report before you quote it.
• IBM Cost of a Data Breach Report 2025 (Ponemon Institute, sponsored and analyzed by IBM) reports a mean of 241 days to identify and contain a breach, 17 days fewer than the year before. It covers 600 organizations and breaches from March 2024 through February 2025. The same report puts the global average cost at $4.44 million and the U.S. average at $10.22 million. IBM publishes yearly, so check for a newer edition.

The numbers do not conflict. IBM measures identification plus containment, as a mean, across a broad set of breaches. Mandiant measures time to detection, as a median, across its engagements. Neither is specific to AWS, and we found no cloud-only figure in a source we trust, so we offer none.

The Verizon 2025 Data Breach Investigations Report gives credential abuse as the initial access in 22% of breaches and exploitation of vulnerabilities in 20%. The 2026 edition puts exploitation first: Verizon says nearly a third (31%) of breaches start with it, the first time in 19 years it has passed stolen credentials. Say which edition you quote. For a cloud account the credential is the whole door. A GitGuardian write-up of the same report says the median time to remediate a secret leaked to public GitHub was 94 days. We have not verified that in the DBIR itself, so treat it as GitGuardian's reading.

Why the attacker's clock is so much faster

Two published honeypot studies show how short the attacker's side can be when a key is public.

• Comparitech published AWS keys in public GitHub repositories (page updated 07/10/2022) and logged what happened with CloudTrail. The first abuse came after one minute, the vast majority of attacks came within an hour, and the first attacker ran DescribeInstances and GetAccountAuthorizationDetails in under four minutes.
• Palo Alto Networks' Unit 42, in "CloudKeys in the Air" (10/30/2023), committed keys to random public repositories and watched a campaign use them within about five minutes. The first reconnaissance call in its CloudTrail timeline was DescribeRegions, followed by more than 400 API calls in about seven minutes across Regions, and then large EC2 instances started mining Monero. The mining was configured through EC2 user data, which CloudTrail redacts from the RunInstances event.

Both studies are three or four years old and leak keys on GitHub, so they describe one path. They support one modest conclusion: treat a key that has sat in a public repository as already used.

In the second study AWS also reacted. GitHub's secret scanning told AWS, and AWS attached its quarantine policy, now AWSCompromisedKeyQuarantineV3, to the exposed user. It denies many actions, including launching instances and creating access keys. As we read the page on 10/30/2026, it does not list sts:AssumeRole, ec2:CreateSnapshot, ec2:ModifySnapshotAttribute, or the CloudTrail StopLogging and DeleteTrail actions. Read it as a brake on billing fraud, not containment, and re-read the page, because it changes. AWS says not to remove it.

Why the defender's clock is slow

On the defender's side, every step between an attacker action and a human decision adds time, and AWS publishes little about how much.

• CloudTrail. AWS says CloudTrail typically delivers logs within an average of about 5 minutes of an API call, and that this time is not guaranteed. Event history gives you the last 90 days of management events per Region without any trail, but it does not include data events such as S3 object reads.
• EventBridge. CloudTrail events reach EventBridge only if a trail with logging is on. AWS documents the event types and rule states and publishes no latency figure, so we do not give one.
• GuardDuty. AWS describes its analysis as "near real time" and says that the time before you start receiving findings depends on activity in the account. It publishes no number of minutes. Its anomaly findings, the AnomalousBehavior family, depend on a model that learns each user's usual API calls, locations, and callers. A user with no history gives that model little to compare against, so a clear first-use finding is not guaranteed.
• People. An alert reaches a mailbox or a pager, and someone has to decide it is real.

Add them up and the honest statement is that nobody can promise a detection in the first 30 minutes of an attack; the 30-minute guide shows an alert that came 11 days after the first malicious call. Detection is the long pole because it has the most unknowns, the least AWS-published timing, and the most dependence on work done before the breach. That is where preparation pays back most.

The First Hours, Days, and Weeks

This is the defender's side in the order it usually happens. The time boxes are our planning guidance, not AWS timings, and real incidents move back and forth between them.

The first hour: contain, and preserve at the same time

Name an incident lead, start a timestamped log in UTC, call counsel, and decide who may take destructive actions. Then:

1. Identify the principal. A key beginning AKIA is a long-term key for an IAM user or the root user. One beginning ASIA is a temporary credential issued by STS, and it cannot be seen or managed in the console. aws sts get-access-key-info returns only the owning account ID.
2. Pull what it did. Search CloudTrail by access key ID in every Region, not only the one you use. For an ASIA key, find the event that minted it (AssumeRole, GetSessionToken, GetFederationToken, or AssumeRoleWithSAML or AssumeRoleWithWebIdentity), where responseElements lists the key ID. A cross-account AssumeRole appears in both accounts.
3. Preserve what the attacker can change. Copy trail log files to a bucket in a separate response account, take a point-in-time copy of trail events into a CloudTrail Lake event data store, and save the IAM state with aws iam get-account-authorization-details and the credential report. AWS's design goal is a centralized account dedicated to response, and it warns that cloud resources are ephemeral: what you investigate may have changed or vanished.
4. Deactivate the key; do not delete it. A deactivated key can be reactivated, and AWS's compromised credentials playbook says to disable, not delete.
5. Cut the sessions the key already created. Temporary credentials stay valid until they expire (the AWS threat catalog gives 900 to 129,600 seconds for GetSessionToken), so cut them through permissions, not the key.
6. Wall off the account. A service control policy on the affected account or organizational unit can deny destructive and tamper actions. It does not affect the management account or service-linked roles.
7. Hunt persistence before calling it contained. Look for new users, second access keys, login profiles, trust policy changes, new roles, EC2 key pairs, Lambda functions, and instances in Regions you never use.

These steps conflict. Terminating an instance contains it and destroys its memory. Cutting one path may reveal that you know. Turn on termination protection, capture memory where you can, snapshot the volumes, and isolate the instance (a network ACL deny cuts connections a security group change leaves open). If data is still leaving, isolate first: it does not touch the disk. Write down who authorized each destructive step.

The first day: scope, in every Region and every account

Containment is not scope. By the end of the first day you should know the earliest event you have observed (not "the start"), every principal the actor used, every Region and account it touched, and what data was reachable from each. Treat the earliest-event time as provisional: log latency, and logs that were off, mean it can move earlier as the investigation continues.

Two checks belong here. First, was logging tampered with? StopLogging, DeleteTrail, UpdateTrail, PutEventSelectors, lifecycle rules or a changed policy on the log bucket, a disabled trail KMS key, and a deleted GuardDuty detector all blind the investigation. Second, what could the logs never show? S3 object reads unless data events were on, and anything done through EC2 user data.

Move coordination off any channel the attacker could read, including email and chat if the identity provider or root mailbox is the compromised piece.

The first days: investigation, eradication, and recovery

AWS defines eradication as removing unauthorized resources and artifacts and putting in place mitigations for the root cause. Deleting the mining instances without finding how the key leaked is the common half-measure.

Before you remove anything unfamiliar, back it up if it matters to the investigation. Then rebuild from known good where you can; AWS lists redeployment among its design goals, and a rebuilt system is easier to trust than a cleaned one. Rotate production secrets after you have found the persistence and closed the access path, not before, or the new key may be readable from the same exposed place.

Recovery, in AWS's words, restores systems to a known safe state and monitors them to verify the threat does not return. Teams drop the monitoring first. Add detections for every technique you observed, and watch them.

The first weeks: notification, reporting, and lessons learned

Many legal notification clocks run from the organization's discovery or determination, and some from when it should have known, not from the attacker's first API call. That makes the engineer's job to produce dated facts: the earliest malicious event time (CloudTrail eventTime, in UTC), the time of detection, the time of containment, and which data types were reachable. Counsel decides what they mean.

These examples show why counsel asks the questions it does. They are a survey, not a list of what applies to you, and none of it is a legal conclusion. Consult counsel.

CIRCIA, the federal critical infrastructure reporting law, is not in force: CISA's own page said on 10/29/2026 that organizations are not required to submit reports until the final rule takes effect. Do not plan around proposed terms.

Keep two products separate. Counsel may commission a privileged investigation report. The lessons-learned is a factual operational record, which you should write as if others could read it unless counsel directs otherwise.

AWS's guide asks the lessons-learned framework to settle when it is held, who takes part, and how improvements are tracked and implemented. Its questions include how the incident was first identified, what alerted, what worked and what did not, what would have found it sooner, and who owns the improvement plan and how it will be tested. AWS gives no number of days for when to hold it on the page we read, so we won't either. Pick a date at the start and put it on a calendar.

A useful exercise at this stage: map every action the attacker took to an ATT&CK technique ID, and mark whether a detection existed for it. The gaps become the backlog. ATT&CK now publishes detection strategies for many techniques, for example for snapshot sharing and for disabling cloud logs.

Where Each AWS Log or Service Shows Up

No single AWS source covers the lifecycle. Each shows part of it, on its own schedule, with its own gaps.

Common Mistakes at Each Stage

We have organized these by stage because the same team makes different mistakes at different times. Several come directly from AWS's own incident response guidance. The ones we reason to rather than read are marked.

Before the breach.

• Keeping logs in the same account the attacker will own, where they can stop the trail or alter the rules.
• Leaving data events off for the buckets that matter, so scoping becomes a guess.
• No Alternate Security Contact on each account, so AWS's notice goes to someone who has left. AWS's playbook says to check it.

Between the foothold and detection.

• Treating GuardDuty as the whole detection plan. Without a baseline it may not fire on a new key, and an alert nobody is on call for does nothing.
• Suppression rules so loose that real activity is archived. AWS notes that findings archived by suppression rules are not sent to EventBridge.
• Assuming a leaked key was not used because the repository was taken down.

Analysis.

• Looking in one Region. The Unit 42 actor operated across Regions, and AWS's playbook says to check all of them.
• Chasing only the key in the alert. It may not be the key the attacker is using; match the accessKeyId in CloudTrail to the principal.
• Trusting a log that may be late or gone. Event history is management events only, and data events are off by default.
• Running discovery commands with the stolen key. It adds noise to your evidence and tells the actor someone is looking.

Containment.

• Deleting the key instead of deactivating it. A deleted key cannot be reactivated.
• Deactivating the long-term key and forgetting the sessions it already created. They stay valid until they expire.
• Cutting one path and leaving a second. This is our reasoning, not a measured result: an actor who sees one route close may delete, encrypt, or copy faster through another. Cut every known path together.
• Removing AWS's quarantine policy to get an application running. AWS says not to.
• Assuming a service control policy covers everything. It skips the management account and service-linked roles.

Preservation, eradication, and recovery.

• Destroying evidence while cleaning up: terminating instances, deleting snapshots, users, or roles before copying them. AWS's playbook says to back up what you need for the investigation before removing unfamiliar resources.
• Fixing the symptom. Deleting the crypto-mining instances while the leaked key is still active.
• Rotating production keys before persistence is found.
• Declaring recovery without monitoring. AWS's recovery phase includes monitoring to verify the threat does not return.

Lessons learned.

• Skipping the meeting, or holding it without a date, an owner, and a test.
• Fixing the exact attack, not the class: closing one leaked key without removing long-term keys.
• Adding a detection and never proving it fires.

How to Shorten Each Stage Before It Happens

You cannot make the attacker slower. You can shorten your side of each stage, and nearly all of it is ordinary work.

Initial access. Remove long-term IAM user keys where a role will do. Where a key must exist, scope it narrowly and rotate it. Turn on secret scanning and push protection in your repositories. Require IMDSv2 on EC2, which AWS introduced in 2019 because it needs a token that makes simple server-side request forgery much less useful for reading role credentials.

Persistence and privilege escalation. Alert on CreateAccessKey, CreateLoginProfile, GetSessionToken and GetFederationToken for users, AttachUserPolicy, PutUserPolicy, and AssumeRole from a new address. Least privilege gives escalation fewer places to go.

Defense impairment. Send CloudTrail to an organization trail whose logs live in a separate, locked-down account. Turn on log file integrity validation. Use a service control policy to deny StopLogging, DeleteTrail, UpdateTrail, PutEventSelectors, and disabling the trail's KMS key to everyone but a break-glass role. It protects member-account trails; the organization trail lives in the management account, which an SCP does not reach, so keep that account's access short. Alert on any attempt.

Detection. Enable GuardDuty in every account and Region, including the ones you do not use. Route its findings through EventBridge to a place a person is on call for. Put cost alarms on compute. Prove each detection with an emulation, such as Stratus Red Team, which has AWS techniques for CloudTrail tampering and snapshot sharing.

Analysis. Turn on data events for the buckets that hold what you could not lose, accepting the cost. Keep a CloudTrail Lake event data store at the organization level so a query across accounts is quick. Practice the key lookup across Regions before you need it.

Containment. Write the runbook ahead of time, with the commands. Pre-build the deny-list service control policy and the quarantine security group, and test them at an organizational unit, not the root, as AWS advises. Pre-approve who may take destructive steps, and keep a tested break-glass role the attacker cannot reach.

Preservation. Create the response account before you need it, with a write-once evidence bucket, a short access list, and a tested way to copy snapshots into it. Put the hashing step in the runbook.

Eradication and recovery. Keep infrastructure as code so you can rebuild rather than clean. Keep backups in an account the production credentials cannot touch. Rehearse a restore.

Notification. Have counsel keep a current list of the regimes that apply to you, and know the data types in each account, so "what data is in that account" takes minutes, not days.

Lessons learned. Keep a review template. Give every action an owner and a test date before the meeting ends, and run the next tabletop against the gaps.

None of this is exciting, and it is much cheaper on a calm Tuesday than during the incident.

What This Looks Like in an Engagement

Vantalect's incident engagements, AWS Incident Response with its Retainer and AWS Breach Forensics & Recovery, are Not yet offered. We describe them on the site so you can see how we would work, but you cannot buy them today. You can see what the reports would look like, by stage and by week, in the Wrenfield sample. Wrenfield Bancorp is a fictional regional bank, and every name, finding, and number in the sample is invented to show the format.

Related Reading

• An AWS Breach, Answered in 30 Minutes: a composite breach, from the first alert to containment declared.
• Wrenfield sample engagement reports: a fictional incident, by stage and week.

Sources were retrieved on 10/30/2026 (CDT). Vendor statistics are each named report's figures and use different definitions. AWS documentation changes, so check the linked pages before relying on a detail.