Masquerade Account Name is ATT&CK T1036.010. It is a Stealth technique, and its platform list is one of the widest in this family: Containers, IaaS, Identity Provider, Linux, macOS, Office Suite, SaaS and Windows.
The attacker matches or approximates the names of legitimate accounts so that a newly created one looks harmless in a user list.
How attackers use it
MITRE explains that this usually happens when an account is created, though an account may also be renamed later. It can coincide with account access removal, where an actor deletes an account and then creates a new one with the same name.
Common choices described on the page:
- Names that look like service accounts for legitimate software, data backups or container cluster management.
- Generic trustworthy names such as admin, help or root.
- Names modeled on accounts that already exist, often after account discovery has shown what is there.
MITRE notes that this is different from impersonating specific people or organizations. It is about account names, not identities.
The procedure examples are plain. One actor created accounts named admin and a Cyrillic word meaning system. Another created accounts such as support_388945a0. Others used names like help and DefaultAccount, a backdoor account called HelpAssistant, or an account named supportaccount. One group used Microsoft Teams accounts that spoof IT support.
How to detect it
The MITRE analytics look for new or renamed accounts that closely resemble existing service or administrator accounts. Patterns include prefix and suffix changes, homoglyphs, and names such as admin1, adm1n or backup_help. By platform:
- Windows and Linux or macOS: account creation or renaming that mimics known service, root or admin names, often after account discovery or deletion.
- Cloud and identity providers: creation of accounts whose names resemble existing privileged or service accounts, which may signal preparation for privilege escalation.
- Containers: creation of accounts inside containers using names that resemble legitimate orchestrator or backup identities.
Data to collect: account creation and rename events in each system. On Windows, event 4720 records a user account being created and event 4781 records a name change. Cloud audit logs and identity provider logs record the same activity in their own formats. Feed new account names to a similarity check against your list of existing privileged and service accounts.
How to reduce the risk
MITRE lists two mitigations:
- Audit. Make sure each account has a defined purpose.
- User account management. Define and enforce a naming convention for accounts, so generic names that do not fit the schema are easy to spot.
Pair them: the naming convention gives you something to compare against, and the audit gives you an owner for every account.
Check your own environment
Windows PowerShell, list local users and when each last logged on:
Get-LocalUser | Select-Object Name, Enabled, LastLogon, Description
Linux, list accounts with a login shell and accounts with UID 0:
awk -F: '$7 !~ /(nologin|false)$/ {print $1, $3, $7}' /etc/passwd
awk -F: '$3==0 {print $1}' /etc/passwd
Then work through a short checklist:
- Does every account have a named owner and a stated purpose?
- Are there any names that follow no convention, such as admin1 or help?
- Are service accounts named for a system you actually run?
- Have any accounts been created in the past month that nobody can explain?
Click through it at your own pace, or open it full screen.
Quick check
Why is an account named backup_help worth a look even though it sounds routine?
Attackers pick names that resemble service accounts. The question is whether the account has a defined owner and purpose and fits your naming convention.
Which two MITRE mitigations apply here?
Audit, to make sure every account has a purpose, and user account management, to enforce a naming convention.
