AN0900: Analytic 0900
Adversaries use cloud API, CLI, or console to create IAM users or roles. Initial CreateUser is followed by policy/role attachment. Detection monitors temporal chains involving IAM:CreateUser, AttachUserPolicy, and credential generation, especially from automation or foreign IP ranges.
Analyst context for executives and security teams
This analytic is about spotting suspicious creation of cloud IAM users or roles followed quickly by policy attachment and credential generation. For leaders, the business issue is control of cloud identity: a newly created privileged or externally operated identity can become a path to persistent access, data exposure, or cloud resource misuse if it is not detected and reviewed quickly.
Executive priority
Prioritize this as a cloud identity governance and SOC readiness question: can the organization prove who created new IAM identities, from where, by what method, and whether permissions or credentials were added shortly afterward? This matters for incident decision-making, audit evidence, and reducing business continuity risk from unauthorized or poorly governed IaaS access.
Technical view
For IaaS environments, validate monitoring for temporal chains involving IAM CreateUser, AttachUserPolicy, and credential generation events. SOC and detection teams should focus on sequence, timing, source context, and actor context rather than a single event alone. The supplied analytic highlights automation and foreign IP ranges as notable context, so detection logic should distinguish expected provisioning workflows from unusual sources or unexpected automation paths.
Likely telemetry
- Cloud control-plane audit logs for IAM user and role creation
- IAM policy or role attachment events, including AttachUserPolicy
- Credential generation or access key creation events
- Source IP, geolocation, user agent, API/CLI/console access method, and calling identity
- Automation account, service account, or pipeline execution logs where cloud identities are normally provisioned
Detection direction
- Correlate CreateUser with subsequent policy or role attachment and credential generation within a defined time window.
- Baseline approved IAM provisioning paths so legitimate automation does not create excessive false positives.
- Alert more strongly when the sequence originates from unusual automation, unexpected administrators, or foreign IP ranges, as noted in the analytic description.
- Review whether console, CLI, and API activity are all logged and normalized; gaps in any one path can hide the full chain.
- Because no ATT&CK tactic or relationship context is supplied, avoid over-mapping this analytic without local validation.
Mitigation priorities
- Enforce least privilege and tightly restrict who or what can create IAM users, roles, policies, and credentials.
- Require change control or approved automation for IAM identity provisioning.
- Use alert review and periodic access governance to confirm new identities and attached permissions are authorized.
- Reduce standing privilege for human and automation identities that can perform IAM administration.
- Preserve cloud audit logs long enough to support incident response, compliance review, and reconstruction of IAM changes.
Analyst notes and limits
The object is a detection analytic, not a technique description. Its value is strongest when used to test cloud IAM monitoring coverage and identity governance controls. Local baselines are essential because legitimate infrastructure automation may perform the same event sequence.
Official detection text and relationship context were not supplied. Tactics are not specified. The only supported platform is IaaS, so conclusions should not be extended to SaaS, endpoint, or on-premises identity systems without additional evidence.
Analytic 0900
Adversaries use cloud API, CLI, or console to create IAM users or roles. Initial CreateUser is followed by policy/role attachment. Detection monitors temporal chains involving IAM:CreateUser, AttachUserPolicy, and credential generation, especially from automation or foreign IP ranges.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | 0d591d5502b6… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack AN0900Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.