A common warning pattern is a tight sequence of IAM actions: user creation, login profile creation with password reset disabled, policy attachment or group membership changes, and deletion of the original access key. Generic usernames such as system or backup, or SES-themed names, add further confidence. When these signals cluster, the activity is rarely routine administration.
How attacker automation changes the shape of AWS persistence
Automation usually leaves a more rigid and repeatable pattern than a human operator. In AWS, that often means a small set of IAM steps executed in quick succession, with little sign of exploration between actions. The sequence matters more than any single event: when creation, privilege change, and cleanup occur back to back, it suggests a script or workflow is being used to establish durable access.
Two details are especially telling. First, the actor often creates a fresh principal or login path before modifying permissions, which reduces the chance of losing access mid-operation. Second, the original access key is frequently deleted after the new path is in place, which is a classic sign of deliberate persistence rather than routine account maintenance. Pattern recognition is stronger than any isolated alert.
Generic naming can add another clue, but it should be treated as supporting evidence, not proof on its own. Names such as system, backup, or SES-themed variants are often chosen to look operationally normal, blend into logs, or signal a utility account. When those names appear alongside permission escalation and key cleanup, the probability of automation rises sharply.
Signals that matter most in the IAM trail
The clearest indicator is a compressed chain of actions that would normally be separated by review or ticketing in a legitimate admin workflow. That includes user creation, login profile creation, password reset disabled, policy attachment, group membership changes, and then deletion of the prior key. The tighter the time window, the less likely the sequence is a manual, deliberative change.
Context also matters. If the new account immediately receives enough privilege to act as a persistence foothold, that is more consistent with an attacker than with standard provisioning. The goal is usually not just access, but access that survives password rotation, account recovery, or superficial cleanup. For that reason, privilege assignment and credential replacement should be reviewed together, not separately.
Where the trail is noisy, focus on whether the actions are internally consistent. Automated persistence often shows a predictable order, little or no delay, and few unrelated changes outside the access path itself. A human administrator is more likely to leave surrounding indicators such as ticket references, broader configuration work, or a change set that touches more than one purpose.
Risk and Threat Considerations
Automated persistence is dangerous because it compresses compromise into a few high-value actions and can create durable access before defenders notice. Once an attacker can create or modify IAM paths at speed, the same pattern can be repeated across accounts, making cleanup harder and increasing the odds that one hidden credential or login profile remains active.
Failure mechanism: A script or playbook uses valid AWS access to create a fresh foothold, attach privileges, and remove the original access path before normal monitoring or manual review interrupts the sequence.
Impact: The attacker keeps stable access even if one credential is revoked, and the organisation may miss the persistence chain because each step looks administrative when viewed in isolation.
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 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 | AWS persistence often depends on creating or replacing credentials and access paths. |
| NHI-02 — Privilege and Permission Management | The warning pattern includes policy attachment and group changes that raise privilege. | |
| NHI-05 — Lifecycle and Offboarding | Deleting the original key after creating a new path is a lifecycle manipulation signal. | |
| Recommendation — Review credential creation, replacement, and revocation events as one persistence chain. Audit new principals for least-privilege violations and unexpected privilege inheritance. Verify that access removal and offboarding actions are intentional, authorised, and complete. | ||
| CIS Controls v8 | 5 — Account Management | The subject is suspicious account creation and account-path modification in AWS. |
| 6 — Access Control Management | Policy attachment and group membership changes are access-control actions. | |
| Recommendation — Track account creation, privilege changes, and deletion as correlated account-management events. Enforce approval and review for every privilege-increasing IAM change. | ||
| MITRE ATT&CK | T1136 — Create Account | Creating a new user or login path is a classic persistence technique. |
| T1098 — Account Manipulation | Changing policies, groups, and login properties is direct account manipulation. | |
| T1078 — Valid Accounts | The attacker is preserving legitimate-looking access rather than exploiting malware. | |
| Recommendation — Hunt for account creation followed by immediate privilege assignment. Correlate account setting changes with subsequent access continuity and persistence. Inspect how valid AWS access is retained after the original credential is removed. | ||
Practitioner Guidance
What to prioritise: Treat tightly clustered IAM changes as a single event, not as separate low-severity alerts. A fast sequence of create, attach, and delete actions deserves immediate review of the actor, source IP, and whether the new principal can still authenticate after the original key is removed.
What to verify: Check whether the account was created from an approved change, whether the username aligns with a known naming standard, and whether the new permissions are broader than the stated business need. If the pattern includes disabled password resets or immediate privilege attachment, assume persistence intent until proven otherwise.
Practitioner takeaway: The key judgment is not whether any one IAM event is suspicious, but whether the full sequence creates a durable access path faster than a human operator would normally work.
Related resources from NHI Mgmt Group
- What happens when AWS IAM activity appears without a preceding pull request merge in the deployment pipeline?
- What are the signs that cloud account takeover activity is being driven by automation rather than normal user behavior?
- How should security teams validate whether an AWS compromised-key quarantine policy actually blocks attacker follow-on activity?
- What are the signs that an AWS account has been used for privilege escalation and persistence in EKS?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
