AN1077: Analytic 1077
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'.
Analyst context for executives and security teams
This analytic matters because lookalike account names can let a newly created or renamed account hide in plain sight next to legitimate administrator or service accounts. For leaders, the risk is not the name itself; it is that weak identity governance and account review processes may allow privileged or operationally sensitive access to persist without timely scrutiny.
Executive priority
Prioritize this as an identity assurance and audit-readiness check for Windows environments. Security leaders should ask whether account creation and rename events are reviewed against existing administrator and service account naming patterns, whether exceptions are explainable, and whether SOC and IAM teams can quickly determine who created or changed an account and what privileges it received.
Technical view
For SOC, detection engineering, and IR teams, validate whether Windows account creation and rename activity can be compared against known service and administrator account names for close similarity. The supplied ATT&CK object highlights patterns such as prefix or suffix changes, homoglyph-style substitutions, and names resembling examples like admin1, adm1n, or backup_help. Because no official detection logic is provided, teams should treat this as a detection design requirement rather than a ready rule.
Likely telemetry
- Windows account creation events
- Windows account rename or user attribute change events
- Directory or local user account inventory
- Administrator and service account baselines
- Privilege/group membership changes associated with new or renamed accounts
Detection direction
- Baseline legitimate administrator and service account naming conventions before alerting on similarity alone.
- Compare new or renamed accounts to existing privileged or service accounts using conservative similarity matching, including common prefix/suffix changes and character substitutions.
- Correlate suspicious names with privilege assignment, group membership changes, account enablement, and the creator account to reduce false positives.
- Tune for expected administrative workflows such as helpdesk-created accounts, migration activity, or approved service account naming changes.
- Identify blind spots where local Windows accounts, disabled accounts, or directory changes are not centrally logged.
Mitigation priorities
- Maintain an authoritative inventory of administrator and service accounts with approved naming standards.
- Require change control or IAM approval for new privileged, service, or similarly named accounts.
- Review and restrict who can create or rename accounts in Windows environments.
- Audit privileged group membership soon after account creation or rename events.
- Use periodic identity governance reviews to confirm that lookalike accounts are legitimate and still required.
Analyst notes and limits
This is a detection analytic object for Windows in ATT&CK enterprise, external ID AN1077. The ATT&CK fields provide a clear behavioral concept but do not include tactics, relationships, or official detection logic. The most useful local validation is whether identity telemetry, account inventory, and privileged account baselines are complete enough to support similarity-based review.
No relationship context, tactic mapping, or official detection implementation was supplied. This take does not assert active exploitation, attribution, business impact, or existing detection coverage. Environment-specific account naming conventions and approved administrative processes are required to determine severity and tune alerts.
Analytic 1077
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'.
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.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
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 | 957d568456eb… |
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 AN1077Open 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.