Detect this by monitoring IAM access key creation events and alerting when a user creates or updates keys for another identity outside approved automation. Review the actor, the target user, and whether the new key bypasses normal provisioning. Treat unexplained key creation as potential persistence, then check for immediate use, credential sharing, or privilege escalation.
What makes backdoor IAM key creation detectable
Backdoor key creation is easiest to spot when you treat IAM access key events as an access-control change, not just a configuration event. The key question is whether the actor is creating, updating, or reactivating credentials for a different identity outside the expected provisioning path. That pattern matters because it turns a routine IAM action into a possible persistence mechanism.
The strongest detections correlate the actor, the target principal, and the surrounding context. A legitimate workflow usually has a known automation source, a ticket, or a repeatable change pattern. A suspicious one often looks like an out-of-band key being created for a user who should not be receiving new long-lived credentials, especially if the actor lacks ordinary admin responsibility for that user.
For AWS environments, this is a practical case for baselining identity operations and watching for exceptions. The best signal is not the key event alone, but the mismatch between who performed the action and who should have had authority to provision that access. That is why IAM hygiene and lifecycle visibility matter, especially where access keys are still part of the operating model. NHI Lifecycle Management Guide
How to separate normal provisioning from suspicious key creation
Start by comparing each access key event against the approved identity workflow. If a service desk, CI/CD pipeline, or provisioning system normally creates credentials, then an unexpected human actor, unusual automation role, or unfamiliar source IP becomes a useful discriminator. The key is to ask whether the action fits the normal joiner, mover, leaver path, or whether it bypasses it entirely.
Also check whether the target user already has an assigned role-based path for access. If the user is supposed to use temporary credentials, federation, or an assumed role, then the sudden creation of a static access key is a governance exception worth investigating. This is especially important where the target account has broader privileges than its day-to-day use suggests. AWS IAM Policies and Roles Guide
A useful detection rule should therefore combine event type, actor identity, target identity, and change velocity. If a key is created and then used quickly, or if a key is created for a user that has not been part of recent provisioning activity, the event deserves immediate review. In practice, the suspiciousness rises when the action is isolated from normal administration and accompanied by no matching change record.
What to check after an unexpected key event
Once you find an unexplained key creation, assume it may have been used for persistence until you prove otherwise. Review CloudTrail or equivalent audit records for immediate authentication with the new key, unusual API calls, privilege changes, or attempts to create additional credentials. If the actor created the key for another user, also inspect whether that user account had been compromised first or whether the new key was used to maintain access after an initial intrusion.
You should also assess blast radius. If the key belongs to a user with access to production systems, automation pipelines, or sensitive data, the incident may extend beyond IAM into broader compromise. Credentials that appear to be “just access keys” can be the bridge to lateral movement, data access, or destructive actions once an attacker has a stable foothold. Cloud Credential Compromise Playbook
If the event pattern resembles known persistence tradecraft, review it alongside broader adversary techniques rather than as a one-off IAM anomaly. Key creation for another identity can be part of a larger persistence chain, especially when paired with privilege escalation or credential abuse. MITRE ATT&CK Enterprise Matrix
Risk and Threat Considerations
Backdoor IAM key creation matters because it can create a durable access path that survives password resets, session revocation, or ordinary account review. The event is especially risky when the target user is privileged, when keys are long-lived, or when provisioning controls do not clearly separate approved automation from manual administrative action.
Failure mechanism: An attacker or rogue administrator creates a new access key for a different AWS user, then uses that key to preserve access, hide in normal IAM noise, or pivot into higher-value resources.
Impact: The organisation may miss the persistence channel, fail to attribute the action correctly, and leave an attacker with repeatable access to sensitive AWS services, data, or automation paths.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST SP 800-53 Rev 5 and CSA Cloud Controls Matrix set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-5 — Account Management | Access key creation is an account-management control issue requiring review and alerting. |
| Recommendation — Monitor account changes and flag credential creation outside approved workflows. | ||
| NIST SP 800-53 Rev 5 | AU-2 — Audit Events | Key creation detection depends on logging IAM credential events for review. |
| AC-2 — Account Management | Backdoor key creation is a direct account-management and lifecycle abuse scenario. | |
| IA-5 — Authenticator Management | IAM access keys are authenticators whose issuance and rotation must be controlled. | |
| Recommendation — Audit IAM key creation events and correlate them with authorised change records. Restrict who can create credentials for other identities and review exceptions. Control issuance and rotation of access keys and investigate unexpected authenticator creation. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Cloud IAM governance directly covers credential creation, review, and exception handling. |
| Recommendation — Apply cloud IAM controls to detect and investigate unauthorised key provisioning. | ||
Practitioner Guidance
What to verify: Confirm whether the key creation came from an approved automation path, and verify the actor was authorised to provision credentials for that exact target identity. Treat any mismatch as an investigation trigger, not a documentation problem.
What to measure: Track how many access key events occur outside the expected provisioning workflow, and how many of those are followed by immediate use. That pairing is often more informative than raw event volume.
Decision rule: If the key was created for a user that should not receive static credentials, disable or rotate it first, then investigate provenance and usage. If the user is privileged or production-facing, escalate before assuming the event is benign.
Practitioner takeaway: The critical signal is not “a key was created”, but “a key was created for the wrong identity through the wrong path”, because that combination often marks persistence rather than routine administration.
Related resources from NHI Mgmt Group
- Guide: Persistence Techniques Guide
- How do you detect S3 Browser being used to create IAM users, keys or bucket policies in AWS?
- What happens when an attacker can move from an AWS IAM user to creating new users and admin access keys?
- What is the difference between AWS SSO based access and relying on separate IAM users for each account?
- How should security teams detect cloud account abuse when attackers use valid AWS access keys to create persistence?