Live Active security incident? Get immediate response
MITRE ATT&CK® Technique

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.

EnterpriseT1036.010Sub-techniqueObject v2.0 Modified
Discuss defensive coverage Back to ATT&CK
Glexia's Take

Analyst context for executives and security teams

Analyst confidence High

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.
Analyst 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.

Official MITRE ATT&CK definition

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.

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

ATT&CK relationship table

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.

1 rows
Domain ID Name Relationship / procedure
Enterprise T1036 Masquerading This object subtechnique of Masquerading.
Associated objects

Groups, software, and campaigns

Group Enterprise

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]

Group Enterprise

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]

Group Enterprise

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]

Group Enterprise

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]

Malware Enterprise

S0143: Flame

Flame is a sophisticated toolkit that has been used to collect information since at least 2010, largely targeting Middle East countries. [1]

Windows
Relationship explorer

All related ATT&CK context

uses · Malware S0143: Flame Enterprise uses · Group G1046: Storm-1811 Enterprise uses · Group G0059: Magic Hound Enterprise detects · Detection Strategy DET0383: Detection Strategy for Masquerading via Account Name Similarity Enterprise subtechnique of · Technique T1036: Masquerading Enterprise uses · Group G0035: Dragonfly Enterprise uses · Malware S0382: ServHelper Enterprise uses · Campaign C0025: 2016 Ukraine Electric Power Attack Enterprise mitigates · Mitigation M1047: Audit Enterprise mitigates · Mitigation M1018: User Account Management Enterprise uses · Group G0022: APT3 Enterprise
Mitigations

Mitigation direction

Mitigation Enterprise

M1047: Audit

Auditing is the process of recording activity and systematically reviewing and analyzing the activity and system configurations. The primary purpose of auditing is to detect anomalies and identify potential threats or weaknesses in the environment. Proper auditing configurations can also help to meet compliance requirements. The process of auditing encompasses regular analysis of user behaviors and system logs in support of proactive security measures.

Auditing is applicable to all systems used within an organization, from the front door of a building to accessing a file on a fileserver. It is considered more critical for regulated industries such as, healthcare, finance and government where compliance requirements demand stringent tracking of user and system activates.This mitigation can be implemented through the following measures:

System Audit:

- Use Case: Regularly assess system configurations to ensure compliance with organizational security policies. - Implementation: Use tools to scan for deviations from established benchmarks.

Permission Audits:

- Use Case: Review file and folder permissions to minimize the risk of unauthorized access or privilege escalation. - Implementation: Run access reviews to identify users or groups with excessive permissions.

Software Audits:

- Use Case: Identify outdated, unsupported, or insecure software that could serve as an attack vector. - Implementation: Use inventory and vulnerability scanning tools to detect outdated versions and recommend secure alternatives.

Configuration Audits:

- Use Case: Evaluate system and network configurations to ensure secure settings (e.g., disabled SMBv1, enabled MFA). - Implementation: Implement automated configuration scanning tools like SCAP (Security Content Automation Protocol) to identify non-compliant systems.

Network Audits:

- Use Case: Examine network traffic, firewall rules, and endpoint communications to identify unauthorized or insecure connections. - Implementation: Utilize tools such as Wireshark, or Zeek to monitor and log suspicious network behavior.

Mitigation Enterprise

M1018: User Account Management

User Account Management involves implementing and enforcing policies for the lifecycle of user accounts, including creation, modification, and deactivation. Proper account management reduces the attack surface by limiting unauthorized access, managing account privileges, and ensuring accounts are used according to organizational policies. This mitigation can be implemented through the following measures:

Enforcing the Principle of Least Privilege

- Implementation: Assign users only the minimum permissions required to perform their job functions. Regularly audit accounts to ensure no excess permissions are granted. - Use Case: Reduces the risk of privilege escalation by ensuring accounts cannot perform unauthorized actions.

Implementing Strong Password Policies

- Implementation: Enforce password complexity requirements (e.g., length, character types). Require password expiration every 90 days and disallow password reuse. - Use Case: Prevents adversaries from gaining unauthorized access through password guessing or brute force attacks.

Managing Dormant and Orphaned Accounts

- Implementation: Implement automated workflows to disable accounts after a set period of inactivity (e.g., 30 days). Remove orphaned accounts (e.g., accounts without an assigned owner) during regular account audits. - Use Case: Eliminates dormant accounts that could be exploited by attackers.

Account Lockout Policies

- Implementation: Configure account lockout thresholds (e.g., lock accounts after five failed login attempts). Set lockout durations to a minimum of 15 minutes. - Use Case: Mitigates automated attack techniques that rely on repeated login attempts.

Multi-Factor Authentication (MFA) for High-Risk Accounts

- Implementation: Require MFA for all administrative accounts and high-risk users. Use MFA mechanisms like hardware tokens, authenticator apps, or biometrics. - Use Case: Prevents unauthorized access, even if credentials are stolen.

Restricting Interactive Logins

- Implementation: Restrict interactive logins for privileged accounts to specific secure systems or management consoles. Use group policies to enforce logon restrictions. - Use Case: Protects sensitive accounts from misuse or exploitation.

*Tools for Implementation*

Built-in Tools:

- Microsoft Active Directory (AD): Centralized account management and RBAC enforcement. - Group Policy Object (GPO): Enforce password policies, logon restrictions, and account lockout policies.

Identity and Access Management (IAM) Tools:

- Okta: Centralized user provisioning, MFA, and SSO integration. - Microsoft Azure Active Directory: Provides advanced account lifecycle management, role-based access, and conditional access policies.

Privileged Account Management (PAM): - CyberArk, BeyondTrust, Thycotic: Manage and monitor privileged account usage, enforce session recording, and JIT access.

Change history

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 .

ATT&CK release
19.1
Object version
2.0
Created
Modified
Raw hash
ca475477e5c5014b...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 2.0 Current bundle ca475477e5c5…
Raw source

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.

Open mirrored raw JSON Open MITRE-hosted copy
Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [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. [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. [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. [4]
    Invictus IR Cloud Ransomware 2024

    Invictus IR. (2024, January 11). Ransomware in the cloud. Retrieved August 5, 2024.

    Open source URL
  5. [5]
    mitre-attack T1036.010
    Open source URL
Source and licensing

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.

Official MITRE ATT&CK site Official STIX data repository MITRE ATT&CK terms of use