Live Active security incident? Get immediate response
MITRE ATT&CK® Analytic

AN1422: Analytic 1422

Detects container breakout behavior via exploitation (e.g., DirtyPipe, CVE-2022-0847), followed by host OS interaction or escalated capability assignment.

EnterpriseAN1422AnalyticObject v1.0 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence Medium

This analytic matters because container breakout changes the risk boundary from an isolated workload to the underlying host. If a breakout is successful, a container issue can become a broader infrastructure incident involving host OS interaction or escalated capabilities. For leaders, the key decision is whether container security monitoring can prove when isolation assumptions fail, especially around exploitation-driven escape behavior such as the DirtyPipe example referenced by MITRE.

Executive priority

Prioritize this as a container resilience and incident-readiness validation item. Executives and security leaders should ask whether the organization can detect and investigate container-to-host interaction, whether container runtime and host telemetry are retained, and whether vulnerability management can rapidly identify container hosts exposed to relevant kernel or host-level flaws. Because MITRE provides no detection logic or relationship context for this analytic, teams should treat it as a coverage gap assessment rather than evidence of existing detection coverage.

Technical view

For SOC, detection engineering, and IR teams, validate visibility across container workloads, the container runtime, and the host OS. The analytic scope is Containers and focuses on breakout behavior via exploitation followed by host OS interaction or escalated capability assignment. Since ATT&CK does not provide a detection implementation, teams should define local hypotheses around unexpected container processes interacting with host resources, suspicious changes in container capabilities or privileges, and host-level activity that originates from container context. Tactics are not specified, so mapping to local alert triage and response playbooks will require environment-specific interpretation.

Likely telemetry

  • Container runtime events and audit records
  • Container start, exec, privilege, and capability assignment metadata
  • Host OS process execution and parent-child process context
  • Host audit logs showing file, device, namespace, or privilege-related activity
  • Kernel, system, or security logs relevant to exploitation symptoms

Detection direction

  • Confirm whether telemetry can distinguish normal container activity from interaction with the host OS.
  • Baseline expected container privileges and capabilities so escalated or unusual assignments can be reviewed.
  • Correlate container runtime events with host process and audit telemetry; either source alone may miss the breakout context.
  • Tune for legitimate privileged containers, administrative debugging, CI/CD jobs, and platform maintenance to reduce false positives.
  • Review whether detections depend on CVE-specific indicators only; breakout behavior may need behavior-based monitoring as well.

Mitigation priorities

  • Maintain an accurate inventory of container hosts, runtimes, workloads, and kernel versions.
  • Prioritize remediation of relevant host and kernel vulnerabilities on container infrastructure, including CVE-2022-0847 where applicable to the environment.
  • Minimize privileged containers and unnecessary capability assignments.
  • Enforce least privilege for container workloads and restrict host resource access where operationally feasible.
  • Ensure incident response playbooks cover container-to-host escalation scenarios, including host isolation and workload containment decisions.
Analyst notes and limits

AN1422 is a detection analytic object for container breakout behavior via exploitation, with DirtyPipe/CVE-2022-0847 given as an example. The supplied object has no ATT&CK tactic, no official detection text, and no relationship context, so the most defensible use is to drive visibility validation, vulnerability prioritization, and IR readiness for container isolation failure scenarios.

This take is limited to the supplied ATT&CK fields and external reference. It does not assert active exploitation, actor attribution, impact, or detection coverage. Local platform architecture, runtime configuration, logging depth, and vulnerability exposure are required to determine practical risk and implement detections.

Official MITRE ATT&CK definition

Analytic 1422

Detects container breakout behavior via exploitation (e.g., DirtyPipe, CVE-2022-0847), followed by host OS interaction or escalated capability assignment.

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

Relationship explorer

All related ATT&CK context

No relationships are available in the current normalized data for this object.

Change history

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 .

ATT&CK release
19.1
Object version
1.0
Created
Modified
Raw hash
bf58887f70f63fdb...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.0 Current bundle bf58887f70f6…
Raw source

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.

Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    mitre-attack AN1422
    Open source URL
Source and licensing

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.