DET0383: Detection Strategy for Masquerading via Account Name Similarity
DET0383 is a detection strategy for spotting accounts that are named to look like legitimate accounts. The business risk is that a newly created or renamed...
Analyst context for executives and security teams
DET0383 is a detection strategy for spotting accounts that are named to look like legitimate accounts. The business risk is that a newly created or renamed account can blend into normal identity inventories long enough to support stealthy access, especially where identity, cloud, container, or Linux account governance is weak.
Executive priority
Treat this as an identity governance and SOC readiness question: can the organization prove when accounts are created or renamed, who approved them, and whether their names are deceptively similar to privileged, service, or business-critical accounts? This matters for incident decision-making, audit evidence, and operational resilience because masqueraded accounts can undermine trust in access reviews and delay containment.
Technical view
This strategy is linked to ATT&CK technique T1036.010, Masquerade Account Name, under stealth, with related platforms of Containers, IaaS, Identity Provider, and Linux. SOC and detection teams should validate whether account lifecycle events are collected and normalized across those environments, then compare new or modified account names against known legitimate users, service accounts, administrative accounts, and naming standards. Because the official object does not provide a detection analytic, local logic must be built and tuned using account creation, rename, deletion, and access-removal context.
Likely telemetry
- Account creation events
- Account rename or profile modification events
- Account deletion and re-creation records
- Identity provider audit logs
- IaaS identity and access management audit logs
Detection direction
- Validate visibility into account lifecycle events across Identity Provider, IaaS, Linux, and container environments where applicable.
- Compare newly created or renamed account names against approved naming conventions and existing high-value account names for close similarity.
- Correlate suspiciously similar names with recent account deletion or access removal activity, where logs support that context.
- Tune for legitimate naming patterns such as standardized service accounts, test accounts, migrations, and HR-driven name changes to reduce false positives.
- Prioritize alerts involving similarity to privileged, service, break-glass, or operationally critical accounts.
Mitigation priorities
- Maintain authoritative inventories for users, service accounts, privileged accounts, and expected naming conventions.
- Require approval and review for account creation, renaming, and privileged role assignment.
- Centralize and retain identity audit logs from supported identity, cloud, container, and Linux environments.
- Include account-name similarity checks in access reviews and identity governance workflows.
- Use incident response playbooks that verify ownership, approval, privileges, and recent activity for suspicious newly created or renamed accounts.
Analyst notes and limits
The supplied ATT&CK object is a detection strategy with no official description or detection text. Its useful context comes from the relationship to T1036.010, which describes adversaries matching or approximating legitimate account names, often during account creation and sometimes after deletion or renaming. Detection value depends heavily on local account inventories, naming standards, and identity telemetry quality.
Platforms and tactics are not specified on DET0383 itself; platform and tactic context comes only from the related technique. No vendor-specific data sources, analytic logic, thresholds, or detection guarantees are supplied. Local validation is required before claiming coverage.
Detection Strategy for Masquerading via Account Name Similarity
No official description is available in the imported ATT&CK source object.
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.
Techniques used
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.010 | Masquerade Account Name Sub-technique | This object detects Masquerade Account Name. |
All related ATT&CK context
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 (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | 34ab263fdcab… |
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]
mitre-attack DET0383Open 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.