Loading AttackTrace...
Loading AttackTrace...
Masquerade Account Name (T1036.010) is a MITRE ATT&CK technique associated with Stealth . Adversaries may match or approximate the names of legitimate accounts to make newly created ones appear benign.
Masquerade Account Name (T1036.010) is a MITRE ATT&CK technique associated with Stealth. Adversaries may match or approximate the names of legitimate accounts to make newly created ones appear benign.
Attackers use Masquerade Account Name because it provides a reliable way to advance their objective within the Stealth tactic, often with a favorable balance of impact versus detectability on Containers, IaaS, Identity Provider, Linux, macOS, Office Suite, SaaS, Windows environments. Defenders should assess this behavior in the context of the affected platform and adjacent activity rather than treating it as a standalone indicator.
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.(Citation: Huntress MOVEit 2023)
Often, adversaries will attempt to masquerade as service accounts, such as those associated with legitimate software, data backups, or container cluster management.(Citation: Elastic CUBA Ransomware 2022)(Citation: Aquasec Kubernetes Attack 2023) They may also give accounts generic, trustworthy names, such as “adminâ€, “helpâ€, or “root.â€(Citation: Invictus IR Cloud Ransomware 2024) 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.
No universal command represents Masquerade Account Name. Capture the exact command line, arguments, parent process, account, host, and execution time from the investigated environment; do not operationalize unverified examples.
| Event ID | Log Channel | What It Indicates |
|---|---|---|
| Environment-specific | Relevant Windows channel(s) | Correlate authentication, process, object-access, and configuration events with the observed execution context. |
| Sysmon Event ID | Name | Why It's Relevant Here |
|---|---|---|
| Environment-specific | Validate configured telemetry | Use process, network, file, registry, DNS, or image-load telemetry only when relevant and enabled. |
No MITRE detection guidance published for this technique.
Relevant ATT&CK Data Sources: N/A
A universal Sigma rule would create unreliable results because this technique has no single guaranteed observable. Build detection logic from a documented behavior and supported data source, scope it to the affected platform, and validate it against benign administrative activity before deployment.
Start with the data sources named in the detection section. Scope searches by asset, identity, and time window; correlate the primary behavior with preceding access and subsequent actions. A portable query is intentionally not provided where the technique lacks a universal schema or observable.