AN1236: Analytic 1236
Local user accounts are created via binaries like 'useradd', 'adduser', or by editing passwd/shadow. Behavior chain includes execution of user management binaries or modification of user database files.
Analyst context for executives and security teams
This analytic concerns creation of local Linux user accounts, either through common account-management binaries such as useradd/adduser or by modification of account database files such as passwd and shadow. For leaders, the business issue is not the command itself; legitimate administration creates accounts every day. The risk is whether the organization can distinguish approved account lifecycle activity from unexpected persistence or access expansion on Linux systems that support critical services.
Executive priority
Prioritize this as an identity and incident-response readiness question for Linux estates: who is allowed to create local accounts, where should local accounts exist at all, and can the SOC produce evidence quickly when a new account appears on a server? This matters for operational resilience, audit evidence, and containment decisions because unmanaged local accounts can outlive centralized identity controls and complicate recovery.
Technical view
SOC and detection teams should validate monitoring for Linux local account creation through both process execution and file-change evidence. The supplied analytic identifies executions of useradd/adduser and edits to passwd/shadow as the relevant behavior chain. Because no official detection logic or ATT&CK tactic is provided, teams should treat this as a coverage-validation item: confirm visibility, establish normal administrative patterns, and correlate account creation with approved change activity, privileged session context, and host role.
Likely telemetry
- Linux process execution telemetry for user-management binaries such as useradd and adduser
- File integrity or audit telemetry for changes to /etc/passwd and /etc/shadow
- Privilege and session context associated with the account creation activity
- Host inventory and role context to determine whether local account creation is expected
- Change-management or administrative approval records for correlation
Detection direction
- Validate that Linux endpoints and servers generate reliable process and file modification events for local account creation paths identified by the analytic.
- Tune alerts around unauthorized or unusual account creation rather than every legitimate administrative event, since normal system administration can generate expected activity.
- Correlate new local accounts with privileged user activity, maintenance windows, system role, and approved change records.
- Watch for blind spots where only command execution is monitored; direct modification of passwd/shadow may require separate file audit or integrity monitoring.
- Because the official detection field is not provided and there are no relationships supplied, avoid assuming a specific ATT&CK tactic or adversary objective without local incident context.
Mitigation priorities
- Define and enforce policy for where local Linux accounts are permitted and who can create them.
- Prefer centralized identity and access governance where appropriate, while maintaining emergency access controls with review and logging.
- Restrict and monitor privileged access required to create or modify local accounts.
- Implement file auditing or integrity monitoring for Linux account database files on systems where the risk justifies it.
- Review newly created local accounts during routine access reviews and after security incidents.
Analyst notes and limits
This object is a detection analytic for Linux local user account creation. Its value is strongest when used as a control validation and SOC readiness check: can the organization prove when, where, and by whom local accounts were created? Relationship context is not supplied, so this take does not map the behavior to a specific technique, tactic, campaign, or actor.
The official ATT&CK object provides a description but no official detection logic, no tactics, and no relationship context. Local baselines, host criticality, identity architecture, and administrative procedures are required to decide alert severity and response actions.
Analytic 1236
Local user accounts are created via binaries like 'useradd', 'adduser', or by editing passwd/shadow. Behavior chain includes execution of user management binaries or modification of user database files.
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 | 5b9a931fca6b… |
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 AN1236Open 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.