AN1239: Analytic 1239
Account created in a running container (e.g., via 'useradd' or by modifying /etc/passwd directly). Detectable via runtime telemetry (e.g., Falco or eBPF hooks).
Analyst context for executives and security teams
This analytic highlights a high-signal container runtime behavior: a user account being created inside an already running container. For leaders, the practical issue is not the command itself but what it may reveal about container governance and runtime integrity. Containers are normally expected to be built from controlled images and run predictably; account creation at runtime can indicate drift from approved images, emergency administrative activity, or potentially unauthorized persistence inside a workload.
Executive priority
Prioritize this as a container security and operational resilience validation point. Security leaders should ask whether production containers are expected to allow local account changes, whether runtime telemetry exists to prove or disprove that behavior, and whether SOC and incident response teams can distinguish approved administrative maintenance from suspicious container modification. This is especially relevant for cloud/container security assurance, compliance evidence around change control, and incident triage in containerized environments.
Technical view
The supplied ATT&CK analytic applies to Containers and describes detecting account creation in a running container, such as use of account-management utilities or direct modification of account files. Because no official detection logic or relationships are provided, teams should treat this as a validation requirement rather than a ready-to-deploy rule. SOC and detection engineering should confirm whether container runtime telemetry, eBPF-based events, or tools such as Falco can observe process execution and file modification activity inside containers, particularly changes to account databases such as /etc/passwd. IR teams should be prepared to correlate the container event with image provenance, deployment history, orchestrator metadata, and authorized administrative activity.
Likely telemetry
- Container runtime process execution events
- eBPF or kernel-level runtime telemetry from container hosts
- Falco-style container security events, where deployed
- File modification telemetry for account-related files inside containers, such as /etc/passwd
- Container metadata including image, container ID, pod/workload name, namespace, and host
Detection direction
- Validate whether runtime telemetry is collected from container workloads, not only from images or orchestrator audit logs.
- Alert on account creation or account database modification inside running containers where that behavior is not expected for the workload.
- Tune for legitimate administrative or initialization patterns to reduce false positives, especially in development, troubleshooting, or break-glass scenarios.
- Correlate detections with container image build history and deployment events; runtime account creation may represent configuration drift even when not malicious.
- Identify blind spots where ephemeral containers terminate before telemetry is collected or where host-level sensors lack container context.
Mitigation priorities
- Prefer immutable container practices where user accounts are defined at build time rather than created during runtime.
- Restrict interactive administrative access to running containers and require documented approval for exceptions.
- Ensure runtime security monitoring is deployed where container workloads create meaningful business or compliance risk.
- Use change control and image governance to make expected account state verifiable before deployment.
- During incidents, preserve container, host, and runtime telemetry quickly because container evidence can be short-lived.
Analyst notes and limits
This Glexia take is based only on the supplied ATT&CK analytic AN1239. The object provides a concise behavior description, the Containers platform, and examples of runtime telemetry sources, but it does not provide official detection logic, tactics, techniques, or relationship context. Treat it as a control validation and detection engineering prompt rather than a complete analytic package.
No official detection content, ATT&CK tactics, related techniques, adversary relationships, or mitigation mappings were supplied. Local environment context is required to determine whether runtime account creation is normal, suspicious, or prohibited for a given container workload.
Analytic 1239
Account created in a running container (e.g., via 'useradd' or by modifying /etc/passwd directly). Detectable via runtime telemetry (e.g., Falco or eBPF hooks).
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 | e627658d9717… |
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 AN1239Open 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.