Security teams should look for behavior, not just isolated indicators. In this pattern, attackers use long lived access keys to create a new IAM user, set a password without requiring reset, grant AdministratorAccess, and then delete the original key. Combining those steps into a single detection is far more resilient than alerting on any one action alone.
Why this pattern is dangerous in cloud environments
Valid AWS access keys are valuable to attackers because they bypass password resets, MFA prompts, and many user-facing alerting paths. Once an attacker can authenticate as a trusted principal, they can turn a one-time compromise into durable access by changing the account state, not just using the stolen key.
The core detection challenge is that each step can look ordinary in isolation: user creation, password setting, permission assignment, and key deletion are all legitimate AWS actions. The abuse signal emerges when those actions happen in a tightly coupled sequence, especially when the new user is immediately made highly privileged and the original credential is removed to reduce traceability.
What behavior to correlate in AWS logs
Security teams should build a sequence-based rule around the attacker workflow rather than single-event alerts. The strongest pattern is a short time window in which one principal creates a new IAM user, sets or resets console access without a forced password change, attaches or inherits broad permissions such as AdministratorAccess, and then deletes the original access key or otherwise breaks the link to the initial identity.
That correlation becomes much stronger when it is paired with context such as unusual source IPs, first-time regions, API activity from a rarely used key, or a user that has no established administrative history. In practice, the goal is to detect persistence creation, not just credential use. For lifecycle and offboarding patterns that map to this problem, NHIMG’s NHI Lifecycle Management Guide is a useful reference, and the broader Ultimate Guide to NHIs covers visibility gaps, rotation, and overprivilege.
High-value detection logic should also watch for post-compromise cleanup, because deleting the source access key is a common way to hide how access was obtained. NHIMG’s The 52 NHI breaches Report provides real-world patterns of credential abuse and persistence, while the AI LLM hijack breach case shows how stolen AWS keys can be used for broader cloud abuse after initial access.
Practitioner guidance for building a resilient detection rule
What to verify: Confirm that the alert joins actions across the same actor, not just the same account. A useful rule should tie together the caller identity, the target IAM user, the console password event, the privilege change, and the access key deletion so that an attacker cannot evade detection by spacing the steps apart.
What to measure: Tune for low false positives by baselining which principals legitimately create users or attach admin policies. The strongest signal is an administrative sequence performed by a principal that does not normally manage IAM or by a key that has little historical activity.
Common mistake: Alerting only on access-key creation or only on policy attachment leaves a gap that attackers can step through. Persistence often appears as routine administration unless the sequence is joined into one behavior-based detection.
Practitioner takeaway: Treat stolen AWS keys as the start of a persistence chain, not the end of the incident. The best detections look for how the attacker converts temporary authentication into a new durable administrative identity.
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 | Valid AWS key abuse centers on secret theft and reuse to create persistence. |
| NHI-03 — Privilege and Access Governance | The attack depends on granting excessive permissions to the newly created IAM user. | |
| NHI-05 — Lifecycle and Offboarding | Deleting the original key is a lifecycle evasion step that hides the compromise path. | |
| Recommendation — Rotate exposed cloud keys quickly and detect reuse patterns tied to persistence creation. Enforce least privilege and alert when new cloud users gain administrative access. Monitor credential revocation and key deletion as part of compromise and cleanup detection. | ||
| NIST CSF 2.0 | DE.CM — Continuous Monitoring | Behavior-based cloud abuse detection requires correlated monitoring across IAM events. |
| PR.AC — Access Control | The scenario abuses authenticated access to create unauthorized privileged persistence. | |
| DE.AE — Anomalies and Events | Suspicious IAM sequencing is an anomalous event pattern rather than a single indicator. | |
| Recommendation — Correlate identity and privilege events to detect persistence chains in cloud logs. Apply strong access controls to limit who can create users and attach admin policies. Flag unusual IAM action sequences that indicate account abuse and persistence. | ||
| MITRE ATT&CK | T1078 — Valid Accounts | Attackers use valid AWS keys to operate as trusted principals. |
| T1136 — Create Account | Creating a new IAM user is the persistence mechanism described in the question. | |
| Recommendation — Map detections to valid-account abuse and investigate privileged actions taken with stolen keys. Alert on account creation followed by privilege escalation and source-key removal. | ||
| CIS Controls v8 | CIS 5 — Account Management | Cloud account abuse is best detected through account and privilege lifecycle controls. |
| CIS 8 — Audit Log Management | The detection depends on joined audit evidence from IAM and access-key events. | |
| Recommendation — Review cloud account creation, privilege assignment, and deprovisioning events together. Centralize and retain cloud audit logs for sequence-based abuse detection. | ||
Related resources from NHI Mgmt Group
- How should security teams detect and stop OAuth application abuse before attackers use it for persistence in Microsoft 365 and Azure?
- How should security teams detect API abuse when attackers use valid credentials and legitimate endpoints?
- How should security teams handle exposed cloud keys before attackers use them?
- How should security teams detect abuse when attackers use legitimate identities?
