AN1079: Analytic 1079
Detects adversary creation of cloud or IdP accounts whose names resemble existing privileged or service accounts. May indicate preparation for privilege escalation or defense evasion.
Analyst context for executives and security teams
This analytic is about spotting newly created cloud or identity-provider accounts with names that closely resemble existing privileged or service accounts. For leaders, the value is early warning: look-alike identity creation can be a staging signal before privilege escalation or defense evasion, especially where account naming conventions are trusted by humans, workflows, or access review processes.
Executive priority
Prioritize this as an identity governance and SOC readiness question: can the organization prove who can create IdP/cloud accounts, whether new accounts are reviewed quickly, and whether privileged or service-account naming patterns are protected from impersonation? This matters for audit evidence, incident triage, and reducing the chance that a suspicious account blends into normal administration.
Technical view
Validate coverage in the Identity Provider platform for new account creation events and compare newly created account names against known privileged and service-account inventories. Because ATT&CK does not provide detection logic for AN1079, detection teams should define local similarity rules, expected naming patterns, and exception handling. IR teams should treat matches as triage leads requiring confirmation of creator, approval path, assigned privileges, group memberships, and subsequent authentication or administrative activity.
Likely telemetry
- Identity Provider account creation logs
- Cloud or IdP user inventory snapshots
- Privileged account and service-account inventories
- Account creator or provisioning workflow metadata
- Group, role, and privilege assignment events
Detection direction
- Confirm that account creation events are centrally collected from the Identity Provider platform.
- Build or validate comparison logic between new account names and existing privileged or service accounts, including common local naming conventions.
- Tune for false positives from legitimate onboarding, service migration, break-glass account creation, or automated provisioning workflows.
- Correlate suspicious names with creator identity, approval evidence, privilege assignment, and early login behavior before escalating severity.
- Review blind spots where service accounts are undocumented, privileged account inventories are stale, or naming conventions are inconsistent across cloud and IdP environments.
Mitigation priorities
- Maintain an authoritative inventory of privileged and service accounts, including approved naming standards.
- Restrict and monitor who can create cloud or IdP accounts, especially accounts resembling privileged or service identities.
- Require approval and review for new privileged, service, or look-alike accounts.
- Use periodic access reviews to identify newly created accounts that mimic sensitive identities.
- Ensure SOC and IR runbooks include validation steps for suspicious account creation in the IdP.
Analyst notes and limits
AN1079 is a detection analytic, not a full technique description. The supplied object identifies the behavior and platform but does not include ATT&CK tactics, detection logic, relationships, or procedure examples. Its practical value depends on local identity inventory quality and the organization’s ability to correlate account creation with provisioning and approval records.
Official detection content is not provided, and no relationship context is supplied. This take should therefore be used as defensive planning guidance rather than a claim of specific ATT&CK coverage or guaranteed detection efficacy. Local environment data is required to define similarity thresholds, privileged-account scope, and acceptable exceptions.
Analytic 1079
Detects adversary creation of cloud or IdP accounts whose names resemble existing privileged or service accounts. May indicate preparation for privilege escalation or defense evasion.
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 | 300b591a5d90… |
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 AN1079Open 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.