T1036.010: Masquerade Account Name
MITRE ATT&CK T1036.010: Masquerade Account Name Technique details for Containers, IaaS, Identity Provider, with detection guidance, relationships and mapped CVEs.
Security context for executives and security teams
Masquerade Account Name is a stealth behavior where an adversary-created or renamed account is made to look routine, such as a service, backup, cluster-management, admin, help, or root-style account. The business issue is not just account creation; it is that a malicious identity may blend into normal operations across endpoints, cloud, SaaS, identity providers, containers, and office environments. If teams cannot explain which accounts should exist, who approved them, and when they changed, incident responders may miss persistence and auditors may lack evidence of account lifecycle control.
Executive priority
Prioritize this where identity governance, privileged access, cloud administration, or operational technology dependencies make account misuse a resilience risk. Leaders should ask whether account creation, renaming, deletion, and re-creation are centrally logged and reviewed across Windows, Linux, macOS, SaaS, IaaS, identity providers, containers, and office suites. This technique is also relevant to cyber-physical risk because ATT&CK relates it to the 2016 Ukraine Electric Power Attack campaign and groups associated with critical infrastructure targeting, but local exposure must be validated before drawing risk conclusions.
Technical view
ATT&CK lists this as a stealth sub-technique of Masquerading. It commonly occurs with Create Account, may follow Account Discovery, and may coincide with Account Access Removal when an account is deleted and re-created with the same or similar name. Since no official detection text is provided, SOC and detection teams should validate coverage around account lifecycle events and similarity-based review, consistent with the related detection strategy DET0383, Detection Strategy for Masquerading via Account Name Similarity. Focus on new or renamed accounts that resemble known service accounts, backup accounts, container cluster management accounts, or generic trusted names such as admin, help, and root, especially when timing, privilege, owner, or source system does not match normal account management processes.
Likely telemetry
- Identity provider account creation, rename, deletion, and re-creation events
- Windows, Linux, and macOS local account and group management logs
- SaaS, office suite, and IaaS audit logs for user and service account lifecycle changes
- Container and Kubernetes-style account, role, and cluster-management audit events where available
- Privileged group membership and permission assignment changes
Detection direction
- Validate that account lifecycle telemetry is collected across all ATT&CK-listed platforms in use, not only the primary identity provider.
- Tune for name similarity and name reuse, including accounts that approximate legitimate service, backup, cluster-management, admin, help, or root-style names.
- Correlate account creation or rename events with Account Discovery indicators and account deletion/re-creation patterns where telemetry supports it.
- Use allowlists carefully: legitimate service account creation and platform automation can create false positives, so detections should compare name, creator, approval path, privilege, source system, and timing.
- Review whether detections cover renamed accounts as well as newly created accounts; many programs monitor creation but miss later name changes.
Mitigation priorities
- Implement and enforce User Account Management controls for the full account lifecycle: creation, modification, privilege assignment, deactivation, deletion, and re-creation.
- Require clear ownership, approval, naming standards, and documented purpose for user, service, cloud, SaaS, and container-related accounts.
- Apply least privilege to reduce the impact of a masqueraded account that is successfully created or renamed.
- Audit account inventories and lifecycle logs regularly, including similarity checks against known legitimate account names.
- Preserve audit evidence for compliance readiness and incident response, especially around privileged and service accounts.
Additional notes and limits
The supplied ATT&CK relationships show use by multiple groups, software, and a campaign, and mitigations M1018 User Account Management and M1047 Audit. Those relationships support prioritizing identity lifecycle governance and audit validation, but they do not prove current activity in any specific environment. The broad platform list means this should be assessed as an enterprise identity and cloud control issue, not only an endpoint logging issue.
MITRE provides no official detection text for this sub-technique in the supplied object. Specific event IDs, log schemas, thresholds, and naming-pattern logic must be derived from the organization’s identity providers, operating systems, SaaS platforms, IaaS platforms, container platforms, and account management processes. External references are provided by ATT&CK, but this take does not infer details beyond the supplied fields and relationships.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Masquerade Account Name
No official description is available in the imported ATT&CK source object.
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.
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.
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.