AN1078: Analytic 1078
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.
Analyst context for executives and security teams
This analytic matters because lookalike Linux account names can let unauthorized or inappropriate accounts hide in plain sight beside trusted service, root, or admin naming patterns. For leaders, the value is not just detecting a new user: it is validating whether identity governance, SOC monitoring, and incident response can quickly distinguish legitimate administrative change from suspicious account manipulation.
Executive priority
Prioritize this where Linux systems support critical business services or regulated workloads. Ask whether account creation and rename activity is centrally logged, reviewed, and tied to approved change processes. This behavior is material for audit evidence, privileged access governance, and incident decision-making because a deceptive account name can delay triage and weaken confidence in identity control effectiveness.
Technical view
For Linux environments, validate monitoring for account creation and account rename events, especially names that closely resemble known service, root, or admin accounts. Because the ATT&CK object provides no official detection logic or relationships, teams should treat AN1078 as a detection objective: compare new or renamed account names against an approved inventory of privileged, service, and administrative accounts; review surrounding activity for prior account discovery or deletion when available; and tune against legitimate provisioning or migration workflows.
Likely telemetry
- Linux local account creation records
- Linux account rename or user modification records
- Authentication and authorization logs
- Privileged command execution logs related to user management
- Configuration or change-management records for approved account activity
Detection direction
- Validate that Linux account lifecycle events are collected centrally and retained long enough for investigation.
- Tune for close-name matches to trusted service, root, or admin account conventions rather than only exact matches.
- Correlate suspicious account names with authorized change tickets or provisioning workflows to reduce false positives.
- Review nearby account discovery or account deletion evidence when available, since the official description notes this behavior often follows those actions.
- Identify blind spots on unmanaged Linux hosts, systems without audit-quality account logging, and environments lacking an authoritative inventory of approved administrative or service accounts.
Mitigation priorities
- Maintain an authoritative inventory of approved Linux service, root-equivalent, and administrative accounts.
- Require documented approval for privileged or service account creation and renaming.
- Restrict account management permissions to authorized administrators and processes.
- Periodically review Linux local accounts for deceptive or unauthorized names.
- Ensure incident response playbooks include rapid validation of suspicious account changes against change records and account ownership.
Analyst notes and limits
AN1078 is a detection analytic in the enterprise ATT&CK domain for Linux. It describes detection of account creation or renaming where the account name closely matches trusted service, root, or admin account names. No tactics, relationships, or official detection query were supplied, so the strongest use is as a validation target for identity monitoring and Linux account-change visibility.
The supplied ATT&CK fields do not include specific detection logic, mapped techniques, tactics, data sources, or relationship context. Local naming standards, account inventories, logging configuration, and change-management data are required to make this analytic operational and to assess coverage.
Analytic 1078
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.
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 | 830be3a8d843… |
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 AN1078Open 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.