Has created Microsoft Teams accounts that spoof IT support and helpdesk members for use in application and voice phishing.1
- Tactic
- Stealth
- Platforms
- Containers, IaaS, Identity Provider, Linux, macOS, Office Suite, SaaS, Windows
- Version
- 2.0
- Created
- 05 August 2024
- Last modified
- 12 May 2026
- Contributor
- Menachem Goldstein
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]
Masquerade Account Name MITRE reference T1036.010
4 groups have been recorded using this technique. Newest first; each entry carries MITRE’s procedure text and a link to the group’s full record. Click a name to filter the rules below.
Has created local accounts named help and DefaultAccount on compromised machines.12
Has created accounts disguised as legitimate backup and service accounts as well as an email administration account.1
Has been known to create or enable accounts, such as support_388945a0.1
All 4 groups for this technique
1 campaign has been recorded using this technique. Listed newest first; dates are year-granularity and attribution is MITRE’s.
During the 2016 Ukraine Electric Power Attack, Sandworm Team created two new accounts, “admin” and “система” (System).1
All 1 campaigns for this technique
2 software entries are documented implementing this technique. MITRE files each as a tool or as malware; newest first, then by how many groups carry them.
Has created a new user named supportaccount.1
Can create backdoor accounts with login HelpAssistant on domain connected systems if appropriate rights are available.12
All 2 software entries for this technique
Offense vs defense T1036.010
Is defensive coverage keeping up with adversary use? Eight counts, each ranked against all 697 ATT&CK techniques. Attack sits left, defense right, so a shape leaning left means adversaries are better documented here than defenders are equipped. Hover any spoke for its percentile and the share of techniques that have more. The timeline below shows when each side arrived.
Masquerade Account Name detection strategy DET0383
MITRE names one behaviour worth catching for this technique and breaks it into 4 analytics, one per platform. Each carries the log sources it needs and the fields you tune per environment.
Detection Strategy for Masquerading via Account Name Similarity
AN1077 · Windows
Detects adversary behavior where a newly created or renamed user account closely resembles existing service or administrator accounts to blend in and avoid detection. Common patterns include prefix/suffix modifications, homoglyphs, or use of names like 'admin1', 'adm1n', or 'backup_help'.
Log sources
The data this analytic draws on. You do not need every component — each one you already collect covers part of it. Each links to its ATT&CK record.
| Data component | Name | Channel |
|---|---|---|
| User Account MetadataDC0013 | windows:osquery | User enumeration with creation/last modified timestamps |
| User Account CreationDC0014 | WinEventLog:Security | EventCode=4720 |
Tunable fields
MITRE calls these the analytic’s mutable elements: the thresholds and filters you set for your own environment.
| Field | What you tune |
|---|---|
| SimilarityThreshold | Defines how close in Levenshtein or visual distance an account name must be to a legitimate one to raise an alert. |
| MonitoredAccountList | Set of known legitimate accounts to compare new account names against. |
| TimeWindow | Period within which anomalous account creation or renaming is evaluated in relation to discovery or deletion activity. |
AN1078 · Linux
Detects creation or renaming of accounts with names that closely match known service, root, or admin accounts. Behavior often follows account discovery or deletion, attempting to blend into system activity logs using trusted name conventions.
Log sources
The data this analytic draws on. You do not need every component — each one you already collect covers part of it. Each links to its ATT&CK record.
| Data component | Name | Channel |
|---|---|---|
| User Account ModificationDC0010 | auditd:SYSCALL | usermod, or account rename system calls |
| User Account MetadataDC0013 | linux:osquery | Listing of /etc/passwd and /etc/shadow metadata |
| User Account CreationDC0014 | auditd:SYSCALL | adduser |
Tunable fields
MITRE calls these the analytic’s mutable elements: the thresholds and filters you set for your own environment.
| Field | What you tune |
|---|---|
| AllowedSystemAccounts | Whitelist of legitimate service accounts used for validation. |
| LevenshteinThreshold | Edit distance sensitivity between created account and existing account names. |
| ScriptInitiatorDetection | Whether to flag account creation events triggered from suspicious scripts or shell histories. |
AN1079 · Identity Provider
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.
Log sources
The data this analytic draws on. You do not need every component — each one you already collect covers part of it. Each links to its ATT&CK record.
| Data component | Name | Channel |
|---|---|---|
| User Account ModificationDC0010 | azure:audit | Rename user |
| User Account MetadataDC0013 | saas:okta | User lifecycle events |
| User Account CreationDC0014 | azure:audit | Add user |
Tunable fields
MITRE calls these the analytic’s mutable elements: the thresholds and filters you set for your own environment.
| Field | What you tune |
|---|---|
| RoleScope | Whether created users have privileged or scoped roles assigned at creation. |
| NamingHeuristics | Regex patterns or heuristics for detecting suspicious naming conventions (e.g., helpdesk_support_, root-admin). |
AN1080 · Containers
Monitors for the creation of accounts inside containers using names that resemble legitimate orchestrator or backup identities to mask adversary persistence.
Log sources
The data this analytic draws on. You do not need every component — each one you already collect covers part of it. Each links to its ATT&CK record.
| Data component | Name | Channel |
|---|---|---|
| User Account CreationDC0014 | docker:daemon | ExecCreate + usermod or useradd |
Tunable fields
MITRE calls these the analytic’s mutable elements: the thresholds and filters you set for your own environment.
| Field | What you tune |
|---|---|
| ContainerContextScope | Limit detection to containers with persistent volumes or specific workloads |
| MasqueradePatternList | Custom list of commonly abused names to blend into container environments (e.g., kubelet, cronjob_sync) |
Audit user accounts to ensure that each one has a defined purpose.
Consider defining and enforcing a naming convention for user accounts to more easily spot generic account names that do not fit the typical schema.