T1036.010: Masquerade Account Name
Adversaries may match or approximate the names of legitimate accounts to make newly created ones appear benign. This will typically occur during Create Account, although accounts may also be renamed at a later date. This may also coincide with Account Access Removal if the actor first deletes an account before re-creating one with the same name.[1]
Often, adversaries will attempt to masquerade as service accounts, such as those associated with legitimate software, data backups, or container cluster management.[2][3] They may also give accounts generic, trustworthy names, such as “admin”, “help”, or “root.”[4] Sometimes adversaries may model account names off of those already existing in the system, as a follow-on behavior to Account Discovery.
Note that this is distinct from Impersonation, which describes impersonating specific trusted individuals or organizations, rather than user or service account names.
Security context for executives and security teams
T1036.010: Masquerade Account Name describes Adversaries may match or approximate the names of legitimate accounts to make newly created ones appear benign. This will typically occur during [Create Account](https://attack.mitre.org/techniques/T1136), although accounts may also be renamed at a later date. This may also coincide with [Account Access Removal](https://attack.mitre.org/techniques/T1531) if the actor first deletes an account before re-creating one with the same name.(Citation: Huntress MOVEit 2023) Often, adversaries will attempt to masquerade as s...
Executive priority
T1036.010: Masquerade Account Name is an official MITRE ATT&CK technique. Glexia treats it as defensive behavior context for prioritizing monitoring, control validation, and response planning without using the object by itself as an attribution claim.
Technical view
Security teams should validate T1036.010: Masquerade Account Name by reviewing the official ATT&CK relationships, mapped tactics (stealth), supported platforms (Containers, IaaS, Identity Provider, Linux), and available local telemetry before making detection or mitigation decisions.
Likely telemetry
- Official ATT&CK relationships and object metadata
- Cloud control-plane, SaaS audit, and container platform logs
- Network, endpoint, and security-tool telemetry
Detection direction
- Validate whether T1036.010: Masquerade Account Name appears in your detection coverage and tabletop scenarios.
- Use the object to align executive risk language with SOC, incident response, and detection engineering work.
- Do not treat ATT&CK relationship context as attribution without corroborating evidence.
Mitigation priorities
- Map the object to existing controls and identify missing telemetry or response ownership.
- Prioritize mitigations that reduce exposure on the listed platforms and tactics.
- Review adjacent ATT&CK relationships before changing policy, detections, or reporting language.
Additional notes and limits
Baseline Glexia take generated from the official MITRE ATT&CK STIX object, source hash, tactics, platforms, and detection fields. It is safe to replace with a richer model-generated take for the same source hash later.
This baseline take is source-grounded and schema-validated, but it does not include environment-specific telemetry, incident evidence, or threat-intelligence corroboration.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Masquerade Account Name
Adversaries may match or approximate the names of legitimate accounts to make newly created ones appear benign. This will typically occur during Create Account, although accounts may also be renamed at a later date. This may also coincide with Account Access Removal if the actor first deletes an account before re-creating one with the same name.[1]
Often, adversaries will attempt to masquerade as service accounts, such as those associated with legitimate software, data backups, or container cluster management.[2][3] They may also give accounts generic, trustworthy names, such as “admin”, “help”, or “root.”[4] Sometimes adversaries may model account names off of those already existing in the system, as a follow-on behavior to Account Discovery.
Note that this is distinct from Impersonation, which describes impersonating specific trusted individuals or organizations, rather than user or service account names.
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.
Related techniques
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1036 | Masquerading | This object subtechnique of Masquerading. |
Groups, software, and campaigns
G0022: APT3
APT3 is a China-based threat group that researchers have attributed to China's Ministry of State Security.[1][2] This group is responsible for the campaigns known as Operation Clandestine Fox, Operation Clandestine Wolf, and Operation Double Tap.[1][3] As of June 2015, the group appears to have shifted from targeting primarily US victims to primarily political organizations in Hong Kong.[4]
G0035: Dragonfly
Dragonfly is a cyber espionage group that has been attributed to Russia's Federal Security Service (FSB) Center 16.[1][2] Active since at least 2010, Dragonfly has targeted defense and aviation companies, government entities, companies related to industrial control systems, and critical infrastructure sectors worldwide through supply chain, spearphishing, and drive-by compromise attacks.[3][4][5][6][7][8][9]
G1046: Storm-1811
Storm-1811 is a financially-motivated entity linked to Black Basta ransomware deployment. Storm-1811 is notable for unique phishing and social engineering mechanisms for initial access, such as overloading victim email inboxes with non-malicious spam to prompt a fake "help desk" interaction leading to the deployment of adversary tools and capabilities.[1][2][3][4]
G0059: Magic Hound
Magic Hound is an Iranian-sponsored threat group that conducts long term, resource-intensive cyber espionage operations, likely on behalf of the Islamic Revolutionary Guard Corps. They have targeted European, U.S., and Middle Eastern government and military personnel, academics, journalists, and organizations such as the World Health Organization (WHO), via complex social engineering campaigns since at least 2014.[1][2][3][4][5]
S0382: ServHelper
ServHelper is a backdoor first observed in late 2018. The backdoor is written in Delphi and is typically delivered as a DLL file.[1]
S0143: Flame
C0025: 2016 Ukraine Electric Power Attack
2016 Ukraine Electric Power Attack was a Sandworm Team campaign during which they used Industroyer malware to target and disrupt distribution substations within the Ukrainian power grid. This campaign was the second major public attack conducted against Ukraine by Sandworm Team.[1][2]
All related ATT&CK context
Mitigation direction
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(2)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.2 | 2.0 | Current bundle | ca475477e5c5… | ||
| 19.1 | 2.0 | Older bundle | ca475477e5c5… |
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]Huntress MOVEit 2023
John Hammond. (2023, June 1). MOVEit Transfer Critical Vulnerability CVE-2023-34362 Rapid Response. Retrieved August 5, 2024.
Open source URL - [2]Elastic CUBA Ransomware 2022
Daniel Stepanic, Derek Ditch, Seth Goodwin, Salim Bitam, Andrew Pease. (2022, September 7). CUBA Ransomware Campaign Analysis. Retrieved August 5, 2024.
Open source URL - [3]Aquasec Kubernetes Attack 2023
Michael Katchinskiy, Assaf Morag. (2023, April 21). First-Ever Attack Leveraging Kubernetes RBAC to Backdoor Clusters. Retrieved July 14, 2023.
Open source URL - [4]Invictus IR Cloud Ransomware 2024
Invictus IR. (2024, January 11). Ransomware in the cloud. Retrieved August 5, 2024.
Open source URL - [5]mitre-attackT1036.010Open 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.
