AN1608: Analytic 1608
Account creation via cloud service APIs or CLI, often associated with key generation. Monitored via CloudTrail or equivalent audit logs.
Analyst context for executives and security teams
This analytic is about noticing new account creation in cloud infrastructure environments through service APIs or command-line tools, especially when it occurs alongside key generation. For leaders, the value is identity and cloud control assurance: if new cloud accounts and access keys are not reliably logged, reviewed, and investigated, teams may miss unauthorized access setup or improper administrative activity.
Executive priority
Prioritize this as a cloud identity governance and audit-readiness question: can the organization prove who created cloud accounts, when, by what interface, and whether credentials or keys were generated at the same time? This matters for incident response scoping, privileged access oversight, and compliance evidence around account lifecycle controls in IaaS environments.
Technical view
For SOC and detection teams, validate that CloudTrail or equivalent cloud audit logs capture account creation events initiated through cloud service APIs and CLI activity. Since ATT&CK provides no specific detection logic for this analytic, teams should define local baselines for expected account provisioning paths, authorized automation, administrative users, and key-generation patterns. IR teams should be able to pivot from a new account event to the creating identity, source context, related key activity, and subsequent use of the new account.
Likely telemetry
- CloudTrail or equivalent cloud control-plane audit logs
- Cloud service API activity records
- Cloud CLI-originated activity indicators where available
- Account creation events
- Access key or credential generation events
Detection direction
- Confirm that account creation through both APIs and CLI is logged, retained, and searchable for IaaS environments.
- Correlate new account creation with nearby key generation or credential creation events.
- Tune for known provisioning workflows and approved automation to reduce false positives.
- Flag account creation by unexpected identities, outside normal change windows, or from unusual source context when local baselines support that judgment.
- Validate alert triage playbooks include reviewing the creator identity, generated keys, and immediate activity performed by the new account.
Mitigation priorities
- Ensure cloud audit logging such as CloudTrail or equivalent is enabled and retained for relevant IaaS accounts and regions.
- Restrict who can create accounts and generate keys using least-privilege identity controls.
- Use approved provisioning workflows so legitimate account creation is attributable and reviewable.
- Review account and key creation activity as part of cloud identity governance and compliance evidence.
- Prepare IR procedures for rapid validation, containment, and key revocation when account creation appears unauthorized.
Analyst notes and limits
The supplied ATT&CK object is a detection analytic for IaaS focused on cloud account creation through APIs or CLI, often associated with key generation. No tactics, related techniques, groups, software, mitigations, or formal detection logic were supplied, so this take is intentionally centered on telemetry validation and control assurance rather than a specific adversary behavior chain.
MITRE did not provide official detection logic, relationship context, or tactic mapping for this object. Local cloud provider configuration, identity architecture, logging scope, and provisioning processes are required to determine detection fidelity and operational priority.
Analytic 1608
Account creation via cloud service APIs or CLI, often associated with key generation. Monitored via CloudTrail or equivalent audit logs.
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 | a6b01c94ead9… |
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 AN1608Open 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.