Containment should start by assuming the exposed key and any related IAM users are compromised. Revoke or deactivate the long-term keys, reset console passwords, and remove newly created users and access keys. Then review CloudTrail for privilege escalation, policy attachment, and quota changes. The goal is to stop persistence first, then reconstruct the attacker’s path before restoring normal access.
Containment First When an AWS Console Login Came From a Stolen Key
The immediate containment priority is to assume the access key and any IAM user tied to it are no longer trustworthy. Stop the active access path first, then remove any persistence the attacker created, and only then move into investigation and restoration. Because console access usually implies the key was converted into broader account access, containment should include both credential invalidation and account-level cleanup.
That means deactivating or deleting the abused long-term key, resetting any console password the attacker may have used or set, and removing any new IAM users, access keys, or policy changes created during the incident. If the key was tied to automated workflows, treat those dependent paths as suspect until they are rebuilt on fresh credentials.
For AWS incidents of this kind, the first objective is to collapse the attacker’s ability to return, not to prove every action immediately. A useful containment sequence is to revoke the compromised access, quarantine related IAM principals, and preserve the timeline in CloudTrail so later review is not contaminated by rushed cleanup.
Reconstruct the Attacker Path Before Restoring Trust
After the active access path is cut off, use CloudTrail to reconstruct what the attacker did with the console session. The most important checkpoints are privilege escalation, policy attachment or modification, creation of new access paths, and quota or security setting changes that could support persistence or resource abuse.
Look specifically for new admin-level permissions, inline policy edits, access key creation, password changes, MFA resets, and any changes to trust relationships or federation settings. Those are the common steps that turn a single stolen key into durable account control, even if the original key is later revoked.
A useful discipline here is to separate containment evidence from remediation evidence. Containment evidence proves the hostile path is closed. Remediation evidence proves the environment has been cleaned of attacker-created access and is safe to re-enable. If those two are mixed together too early, teams often miss a surviving backdoor.
Risk and Threat Considerations
Long-term access keys are high-impact compromise points because console access can expose both interactive control and the ability to create new persistence mechanisms. The key risk is not just the stolen secret itself, but the attacker’s ability to pivot into privilege escalation, policy abuse, and hidden replacement credentials before defenders react.
Failure mechanism: A valid key is used to sign in, the attacker creates or modifies IAM permissions, adds new keys or users, and then retains access through alternate credentials or elevated policies even after the original key is revoked.
Impact: The account can remain exposed after the obvious credential is disabled, which extends dwell time, complicates restoration, and can turn a single compromise into broader cloud abuse, data access, or service disruption.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | Abused long-term AWS keys are secrets that must be revoked and rotated after compromise. |
| NHI-03 — Privilege and Permissions | Console abuse commonly escalates through permissions and policy changes that extend attacker control. | |
| NHI-06 — Detection and Response | CloudTrail review and attacker-path reconstruction are core incident response actions for compromised non-human access. | |
| Recommendation — Revoke compromised access keys and rotate any related secrets immediately. Review and remove excessive permissions created or exposed during the incident. Use cloud audit logs to trace abuse, persistence, and post-compromise changes. | ||
| NIST CSF 2.0 | PR.AC — Access Control | Containment requires disabling compromised access and restoring trusted access paths. |
| DE.CM — Continuous Monitoring | CloudTrail analysis supports monitoring for privilege escalation and suspicious account changes. | |
| RS.AN — Incident Analysis | The answer depends on reconstructing attacker actions before normal access is restored. | |
| Recommendation — Disable compromised access paths and re-establish trusted authentication and authorization. Monitor audit logs for privilege escalation, new credentials, and persistence changes. Analyze the attack path before returning the environment to normal operation. | ||
| CIS Controls v8 | 5 — Account Management | Compromised IAM users and new access paths must be removed during containment. |
| 8 — Audit Log Management | CloudTrail review is required to identify privilege escalation and changes made by the attacker. | |
| Recommendation — Remove unauthorized accounts and credentials created during the incident. Review and preserve audit logs to trace attacker activity and changes. | ||
| MITRE ATT&CK | T1098 — Account Manipulation | Attackers often create users, keys, or policy changes to maintain access after initial compromise. |
| T1078 — Valid Accounts | A stolen AWS key is a valid account access path used to gain console control. | |
| Recommendation — Hunt for account manipulation and remove attacker-created persistence mechanisms. Assume valid-account abuse and invalidate compromised credentials quickly. | ||
Practitioner Guidance
What to prioritise: Treat every console-capable long-term key as a potential full-account compromise until CloudTrail shows otherwise. The fastest safe move is to disable the key and then search for attacker-created persistence, not to spend time debating whether the key was “only” used once.
What to verify: Confirm whether the attacker changed trust policies, added IAM users or access keys, modified password policy settings, or altered quota limits. Those changes matter because they often indicate the attacker was preparing for return access or larger-scale abuse, not merely browsing.
Decision rule: If the compromised principal could reach production resources, rebuild trust from a known-clean identity baseline before restoring normal access. If you cannot show that no new privileged access path survives, the incident is not fully contained.
Practitioner takeaway: In AWS, containment is complete only when the stolen key is dead and every attacker-created fallback path is gone, because a revoked secret does not matter if the adversary already installed a better one.
Related resources from NHI Mgmt Group
- What do security teams get wrong about AWS access-key exposure?
- How should security teams investigate a leaked AWS access key before rotating it?
- What should security teams do first when an AWS access key is found exposed online?
- How should security teams implement trust on first use for tailnet access without relying on the control plane as the long-term trust anchor?
