Teams should treat new identity creation after credential compromise as active persistence, not routine administration. The immediate response is to revoke the exposed credential, disable the abused identities, review recent policy changes, and inspect for reconnaissance or compute abuse. It is also essential to search for similar naming patterns, since attackers often create backup or service accounts to blend in.
How credential theft turns into identity sprawl
When a cloud credential is stolen and used to create new identities, the important signal is not just unauthorized login, it is that the attacker has begun converting access into persistence. New users, keys, roles, or service principals can survive password resets on the original account, so teams need to think in terms of identity chains, not single-account compromise.
That usually means the attacker is trying to build alternate access paths, distribute privileges, or prepare for later abuse. The strongest clue is often a burst of account or role creation followed by policy edits, token minting, or the addition of permissions that make the new identity look routine.
In cloud environments, that kind of activity is especially dangerous because identity creation is often low-friction and can be hidden inside normal administration workflows. A stolen credential can therefore become a bridge from initial compromise to durable control, reconnaissance, compute abuse, or lateral movement across subscriptions and tenants.
Why the response has to focus on persistence, not cleanup alone
The first response should be to revoke the exposed credential, but teams should not stop there. Once an attacker has created new identities, those identities become the active persistence layer and must be treated as hostile until proven otherwise. Review the account creation trail, the timestamps of the associated policy changes, and any unusual privilege grants tied to those identities.
Search for related artifacts across the same window, especially similar naming patterns, duplicated role names, or backup accounts that may have been created to blend into normal operations. Attackers frequently choose names that resemble service accounts or administrative helpers so the new identity is less likely to trigger immediate suspicion.
It is also worth checking whether the abused identity was used to access compute, storage, logging, or directory services after creation. Once a new identity exists, the question is not only whether it was created, but what it touched before defenders noticed it.
Risk and Threat Considerations
New identity creation after credential compromise is a persistence event with immediate blast-radius implications. The main risk is that the attacker has already moved beyond credential theft and now has an access path that can outlive the original compromise, complicate eradication, and expand into privilege escalation or cloud abuse.
Failure mechanism: The stolen credential is used to mint additional users, roles, access keys, or service principals, then the attacker adjusts permissions, hides in naming conventions, or uses the new identities to continue activity after the original credential is rotated.
Impact: Defenders may remove the first foothold while leaving the attacker’s alternate identities intact, which can preserve access, delay detection, and allow further reconnaissance, resource consumption, data access, or destructive action.
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 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 | New identities often depend on exposed cloud credentials and secret handling. |
| NHI-02 — Identity Lifecycle and Offboarding | Created attacker identities must be discovered and removed during cleanup. | |
| NHI-05 — Least Privilege and Access Governance | Attackers exploit excessive permissions to create and persist new identities. | |
| Recommendation — Revoke exposed secrets, rotate credentials, and eliminate long-lived access paths. Inventory created identities and offboard any unauthorized accounts or service principals. Reduce creation and admin permissions to the minimum required and review recent grants. | ||
| MITRE ATT&CK | T1136 — Create Account | The scenario is attacker-driven account or identity creation for persistence. |
| T1098 — Account Manipulation | Post-compromise policy edits and privilege changes often accompany new identities. | |
| T1078 — Valid Accounts | Stolen cloud credentials and spawned identities are used as legitimate access paths. | |
| Recommendation — Hunt for unauthorized account creation and map each created identity to activity. Review and revert account and permission changes made during the compromise window. Detect and contain misuse of valid accounts before rotating only the initial credential. | ||
| NIST CSF 2.0 | DE.CM — Continuous Monitoring | Identity creation and follow-on activity require monitoring and alerting. |
| RS.AN — Analysis | Teams must analyze the sequence of identity creation and post-compromise activity. | |
| RS.MI — Mitigation | Containment requires disabling abused identities and revoking access paths. | |
| Recommendation — Monitor identity creation, privilege changes, and unusual access patterns continuously. Analyze the compromise timeline to identify every created identity and related action. Disable malicious identities and revoke the access they used to persist. | ||
Practitioner Guidance
What to prioritise: Treat every newly created identity as evidence of active attacker tradecraft until it is tied to a legitimate change request and owner. Your first pass should be containment, identity enumeration, and permission review, not a narrow credential rotation exercise.
What to verify: Confirm whether the new identities were created with inherited trust, attached policies, or federated permissions that allow immediate reuse. Also verify whether logging was altered, disabled, or made less useful after identity creation, because that often indicates an attempt to delay response.
Common mistake: Teams often delete the obviously abused account and assume the incident is closed. The more reliable judgment is whether any newly created identity can still authenticate, assume privilege, or reach a production workload; if yes, eradication is incomplete.
Practitioner takeaway: In cloud credential compromise, account creation is usually the attacker’s move from intrusion to persistence, so response quality depends on finding and removing every identity the attacker can still use, not just the credential that started the incident.
Related resources from NHI Mgmt Group
- How should security teams respond when a stolen laptop still has active cloud sessions?
- How should security teams respond when phishing-as-a-service kits scale credential theft across cloud email environments?
- How should security teams respond when a Python dependency or scanner is weaponised in CI/CD and used to steal cloud credentials?
- How should security teams respond when a widely used GitHub Action is compromised with a credential stealer?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
