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

T1611: Escape to Host

Adversaries may break out of a container or virtualized environment to gain access to the underlying host. This can allow an adversary access to other containerized or virtualized resources from the host level or to the host itself. In principle, containerized / virtualized resources should provide a clear separation of application functionality and be isolated from the host environment.[1]

There are multiple ways an adversary may escape from a container to a host environment. Examples include creating a container configured to mount the host’s filesystem using the bind parameter, which allows the adversary to drop payloads and execute control utilities such as cron on the host; utilizing a privileged container to run commands or load a malicious kernel module on the underlying host; or abusing system calls such as `unshare` and `keyctl` to escalate privileges and steal secrets.[2][3][4][5][6][7]

Additionally, an adversary may be able to exploit a compromised container with a mounted container management socket, such as `docker.sock`, to break out of the container via a Container Administration Command.[5] Adversaries may also escape via Exploitation for Privilege Escalation, such as exploiting vulnerabilities in global symbolic links in order to access the root directory of a host machine.[8]

In ESXi environments, an adversary may exploit a vulnerability in order to escape from a virtual machine into the hypervisor.[9]

Gaining access to the host may provide the adversary with the opportunity to achieve follow-on objectives, such as establishing persistence, moving laterally within the environment, accessing other containers or virtual machines running on the host, or setting up a command and control channel on the host.

EnterpriseT1611TechniqueObject v1.6 Modified
Discuss defensive coverage Back to ATT&CK
Glexia's Take

Analyst context for executives and security teams

Analyst confidence High

Escape to Host matters because it turns the security boundary of a container, virtual machine, or ESXi environment into a business-continuity issue. A compromise that should be confined to one workload can become host-level access, creating risk to other containers or virtual machines on the same host and enabling follow-on activity such as persistence, lateral movement, or command and control.

Executive priority

Prioritize this technique anywhere critical services rely on containers, Kubernetes-style platforms, Windows or Linux container hosts, or ESXi virtualization. Leaders should ask whether privileged containers, host filesystem mounts, mounted management sockets such as docker.sock, and hypervisor or kernel patch exposure are inventoried and governed. This is also useful audit evidence: teams should be able to show isolation controls, privileged access controls, patch status, and monitoring for host-level activity originating from virtualized or containerized contexts.

Technical view

ATT&CK maps T1611 to privilege escalation across Windows, Linux, Containers, and ESXi. Defenders should validate whether telemetry can connect container or VM context to host-level effects: privileged container use, bind mounts to host filesystems, mounted container management sockets, suspicious use of host control utilities, system-call abuse such as unshare or keyctl where observable, kernel or hypervisor vulnerability exposure, and host process or file changes that originate from containerized workloads. Relationship context includes DET0219 as a detection strategy, but the supplied ATT&CK object does not provide detection details, so local detection engineering must define and test the actual analytics.

Likely telemetry

  • Container runtime configuration and audit logs showing privileged mode, bind mounts, and mounted management sockets
  • Container orchestration audit events for workload creation, permission changes, and administrative commands
  • Host OS process, command, file, and scheduled task or cron activity logs tied to container-originated activity
  • Linux syscall or kernel telemetry where available for relevant escape-related behavior such as unshare or keyctl
  • Windows container host telemetry for host filesystem or privilege boundary abuse

Detection direction

  • Start by proving visibility: can the SOC identify which containers or VMs run on which host and correlate workload activity to host-level events?
  • Tune detections around high-risk configuration plus behavior, such as privileged containers, host filesystem mounts, management socket exposure, and unexpected host process or file changes from container context.
  • Use relationship-driven context carefully: TeamTNT, Doki, Hildegard, Siloscape, and Peirates are associated with this technique in ATT&CK, but their presence should not be assumed without local evidence.
  • Separate expected administrative and CI/CD activity from suspicious escape patterns; privileged maintenance jobs, backup agents, and platform operations can create false positives.
  • For ESXi, include vulnerability and patch posture in triage because the official description includes VM-to-hypervisor escape via vulnerability exploitation.

Mitigation priorities

  • Apply Application Isolation and Sandboxing principles first: maintain strong separation between workloads and hosts, and avoid unnecessary host resource exposure.
  • Enforce Privileged Account Management and least privilege for container, orchestration, host, and hypervisor administration.
  • Disable or remove unnecessary features, services, mounts, and exposed management interfaces that increase escape paths, including unnecessary container management socket access.
  • Keep host operating systems, container runtimes, kernels, and ESXi/hypervisor software updated to reduce known escape vulnerability exposure.
  • Use execution prevention controls where applicable to limit unauthorized code or control utilities from running on hosts after a boundary break.
Analyst notes and limits

The supplied relationships show mitigations M1026, M1038, M1042, M1048, and M1051, plus ATT&CK associations with TeamTNT and several software entries focused on container or Kubernetes-related activity. Treat those as prioritization context, not proof of current exploitation in any environment.

Official ATT&CK detection text for T1611 is not provided in the supplied object. DET0219 is referenced by name only, without analytic detail. Any coverage statement requires local validation of runtime, orchestration, host, and hypervisor telemetry.

Official MITRE ATT&CK definition

Escape to Host

Adversaries may break out of a container or virtualized environment to gain access to the underlying host. This can allow an adversary access to other containerized or virtualized resources from the host level or to the host itself. In principle, containerized / virtualized resources should provide a clear separation of application functionality and be isolated from the host environment.[1]

There are multiple ways an adversary may escape from a container to a host environment. Examples include creating a container configured to mount the host’s filesystem using the bind parameter, which allows the adversary to drop payloads and execute control utilities such as cron on the host; utilizing a privileged container to run commands or load a malicious kernel module on the underlying host; or abusing system calls such as `unshare` and `keyctl` to escalate privileges and steal secrets.[2][3][4][5][6][7]

Additionally, an adversary may be able to exploit a compromised container with a mounted container management socket, such as `docker.sock`, to break out of the container via a Container Administration Command.[5] Adversaries may also escape via Exploitation for Privilege Escalation, such as exploiting vulnerabilities in global symbolic links in order to access the root directory of a host machine.[8]

In ESXi environments, an adversary may exploit a vulnerability in order to escape from a virtual machine into the hypervisor.[9]

Gaining access to the host may provide the adversary with the opportunity to achieve follow-on objectives, such as establishing persistence, moving laterally within the environment, accessing other containers or virtual machines running on the host, or setting up a command and control channel on the host.

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.

Associated objects

Groups, software, and campaigns

Group Enterprise

G0139: TeamTNT

TeamTNT is a threat group that has primarily targeted cloud and containerized environments. The group as been active since at least October 2019 and has mainly focused its efforts on leveraging cloud and container resources to deploy cryptocurrency miners in victim environments.[1][2][3][4][5][6][7][8][9]

Tool Enterprise

S0683: Peirates

Peirates is a post-exploitation Kubernetes exploitation framework with a focus on gathering service account tokens for lateral movement and privilege escalation. The tool is written in GoLang and publicly available on GitHub.[1]

Containers
Malware Enterprise

S0600: Doki

Doki is a backdoor that uses a unique Dogecoin-based Domain Generation Algorithm and was first observed in July 2020. Doki was used in conjunction with the ngrok Mining Botnet in a campaign that targeted Docker servers in cloud platforms. [1]

LinuxContainers
Malware Enterprise

S0601: Hildegard

Hildegard is malware that targets misconfigured kubelets for initial access and runs cryptocurrency miner operations. The malware was first observed in January 2021. The TeamTNT activity group is believed to be behind Hildegard. [1]

LinuxContainersIaaS
Relationship explorer

All related ATT&CK context

uses · Tool S0683: Peirates Enterprise mitigates · Mitigation M1051: Update Software Enterprise mitigates · Mitigation M1038: Execution Prevention Enterprise mitigates · Mitigation M1048: Application Isolation and Sandboxing Enterprise uses · Malware S0600: Doki Enterprise mitigates · Mitigation M1026: Privileged Account Management Enterprise uses · Malware S0623: Siloscape Enterprise uses · Group G0139: TeamTNT Enterprise detects · Detection Strategy DET0219: Detection Strategy for Escape to Host Enterprise uses · Malware S0601: Hildegard Enterprise mitigates · Mitigation M1042: Disable or Remove Feature or Program Enterprise
Mitigations

Mitigation direction

Mitigation Enterprise

M1051: Update Software

Software updates ensure systems are protected against known vulnerabilities by applying patches and upgrades provided by vendors. Regular updates reduce the attack surface and prevent adversaries from exploiting known security gaps. This includes patching operating systems, applications, drivers, and firmware. This mitigation can be implemented through the following measures:

Regular Operating System Updates

- Implementation: Apply the latest Windows security updates monthly using WSUS (Windows Server Update Services) or a similar patch management solution. Configure systems to check for updates automatically and schedule reboots during maintenance windows. - Use Case: Prevents exploitation of OS vulnerabilities such as privilege escalation or remote code execution.

Application Patching

- Implementation: Monitor Apache's update release notes for security patches addressing vulnerabilities. Schedule updates for off-peak hours to avoid downtime while maintaining security compliance. - Use Case: Prevents exploitation of web application vulnerabilities, such as those leading to unauthorized access or data breaches.

Firmware Updates

- Implementation: Regularly check the vendor’s website for firmware updates addressing vulnerabilities. Plan for update deployment during scheduled maintenance to minimize business disruption. - Use Case: Protects against vulnerabilities that adversaries could exploit to gain access to network devices or inject malicious traffic.

Emergency Patch Deployment

- Implementation: Use the emergency patch deployment feature of the organization's patch management tool to apply updates to all affected Exchange servers within 24 hours. - Use Case: Reduces the risk of exploitation by rapidly addressing critical vulnerabilities.

Centralized Patch Management

- Implementation: Implement a centralized patch management system, such as SCCM or ManageEngine, to automate and track patch deployment across all environments. Generate regular compliance reports to ensure all systems are updated. - Use Case: Streamlines patching processes and ensures no critical systems are missed.

*Tools for Implementation*

Patch Management Tools:

- WSUS: Manage and deploy Microsoft updates across the organization. - ManageEngine Patch Manager Plus: Automate patch deployment for OS and third-party apps. - Ansible: Automate updates across multiple platforms, including Linux and Windows.

Vulnerability Scanning Tools:

- OpenVAS: Open-source vulnerability scanning to identify missing patches.

Mitigation Enterprise

M1038: Execution Prevention

Prevent the execution of unauthorized or malicious code on systems by implementing application control, script blocking, and other execution prevention mechanisms. This ensures that only trusted and authorized code is executed, reducing the risk of malware and unauthorized actions. This mitigation can be implemented through the following measures:

Application Control:

- Use Case: Use tools like AppLocker or Windows Defender Application Control (WDAC) to create whitelists of authorized applications and block unauthorized ones. On Linux, use tools like SELinux or AppArmor to define mandatory access control policies for application execution. - Implementation: Allow only digitally signed or pre-approved applications to execute on servers and endpoints. (e.g., `New-AppLockerPolicy -PolicyType Enforced -FilePath "C:\Policies\AppLocker.xml"`)

Script Blocking:

- Use Case: Use script control mechanisms to block unauthorized execution of scripts, such as PowerShell or JavaScript. Web Browsers: Use browser extensions or settings to block JavaScript execution from untrusted sources. - Implementation: Configure PowerShell to enforce Constrained Language Mode for non-administrator users. (e.g., `Set-ExecutionPolicy AllSigned`)

Executable Blocking:

- Use Case: Prevent execution of binaries from suspicious locations, such as `%TEMP%` or `%APPDATA%` directories. - Implementation: Block execution of `.exe`, `.bat`, or `.ps1` files from user-writable directories.

Dynamic Analysis Prevention: - Use Case: Use behavior-based execution prevention tools to identify and block malicious activity in real time. - Implemenation: Employ EDR solutions that analyze runtime behavior and block suspicious code execution.

Mitigation Enterprise

M1048: Application Isolation and Sandboxing

Application Isolation and Sandboxing refers to the technique of restricting the execution of code to a controlled and isolated environment (e.g., a virtual environment, container, or sandbox). This method prevents potentially malicious code from affecting the rest of the system or network by limiting access to sensitive resources and critical operations. The goal is to contain threats and minimize their impact. This mitigation can be implemented through the following measures:

Browser Sandboxing:

- Use Case: Implement browser sandboxing to isolate untrusted web content and prevent malicious web pages or scripts from accessing sensitive system resources or initiating unauthorized downloads. - Implementation: Use browsers with built-in sandboxing features (e.g., Google Chrome, Microsoft Edge) or deploy enhanced browser security frameworks that limit the execution scope of active content. Consider controls that monitor or restrict script-based file generation and downloads commonly abused in evasion techniques like HTML smuggling.

Application Virtualization:

- Use Case: Deploy critical or high-risk applications in a virtualized environment to ensure any compromise does not affect the host system. - Implementation: Use application virtualization platforms to run applications in isolated environments.

Email Attachment Sandboxing:

- Use Case: Route email attachments to a sandbox environment to detect and block malware before delivering emails to end-users. - Implementation: Integrate security solutions with sandbox capabilities to analyze email attachments.

Endpoint Sandboxing:

- Use Case: Run all downloaded files and applications in a restricted environment to monitor their behavior for malicious activity. - Implementation: Use endpoint protection tools for sandboxing at the endpoint level.

Mitigation Enterprise

M1026: Privileged Account Management

Privileged Account Management focuses on implementing policies, controls, and tools to securely manage privileged accounts (e.g., SYSTEM, root, or administrative accounts). This includes restricting access, limiting the scope of permissions, monitoring privileged account usage, and ensuring accountability through logging and auditing.This mitigation can be implemented through the following measures:

Account Permissions and Roles:

- Implement RBAC and least privilege principles to allocate permissions securely. - Use tools like Active Directory Group Policies to enforce access restrictions.

Credential Security:

- Deploy password vaulting tools like CyberArk, HashiCorp Vault, or KeePass for secure storage and rotation of credentials. - Enforce password policies for complexity, uniqueness, and expiration using tools like Microsoft Group Policy Objects (GPO).

Multi-Factor Authentication (MFA):

- Enforce MFA for all privileged accounts using Duo Security, Okta, or Microsoft Azure AD MFA.

Privileged Access Management (PAM):

- Use PAM solutions like CyberArk, BeyondTrust, or Thycotic to manage, monitor, and audit privileged access.

Auditing and Monitoring:

- Integrate activity monitoring into your SIEM (e.g., Splunk or QRadar) to detect and alert on anomalous privileged account usage.

Just-In-Time Access:

- Deploy JIT solutions like Azure Privileged Identity Management (PIM) or configure ephemeral roles in AWS and GCP to grant time-limited elevated permissions.

*Tools for Implementation*

Privileged Access Management (PAM):

- CyberArk, BeyondTrust, Thycotic, HashiCorp Vault.

Credential Management:

- Microsoft LAPS (Local Admin Password Solution), Password Safe, HashiCorp Vault, KeePass.

Multi-Factor Authentication:

- Duo Security, Okta, Microsoft Azure MFA, Google Authenticator.

Linux Privilege Management:

- sudo configuration, SELinux, AppArmor.

Just-In-Time Access:

- Azure Privileged Identity Management (PIM), AWS IAM Roles with session constraints, GCP Identity-Aware Proxy.

Mitigation Enterprise

M1042: Disable or Remove Feature or Program

Disable or remove unnecessary and potentially vulnerable software, features, or services to reduce the attack surface and prevent abuse by adversaries. This involves identifying software or features that are no longer needed or that could be exploited and ensuring they are either removed or properly disabled. This mitigation can be implemented through the following measures:

Remove Legacy Software:

- Use Case: Disable or remove older versions of software that no longer receive updates or security patches (e.g., legacy Java, Adobe Flash). - Implementation: A company removes Flash Player from all employee systems after it has reached its end-of-life date.

Disable Unused Features:

- Use Case: Turn off unnecessary operating system features like SMBv1, Telnet, or RDP if they are not required. - Implementation: Disable SMBv1 in a Windows environment to mitigate vulnerabilities like EternalBlue.

Control Applications Installed by Users:

- Use Case: Prevent users from installing unauthorized software via group policies or other management tools. - Implementation: Block user installations of unauthorized file-sharing applications (e.g., BitTorrent clients) in an enterprise environment.

Remove Unnecessary Services:

- Use Case: Identify and disable unnecessary default services running on endpoints, servers, or network devices. - Implementation: Disable unused administrative shares (e.g., C$, ADMIN$) on workstations.

Restrict Add-ons and Plugins:

- Use Case: Remove or disable browser plugins and add-ons that are not needed for business purposes. - Implementation: Disable Java and ActiveX plugins in web browsers to prevent drive-by attacks.

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.6
Created
Modified
Raw hash
d34ba45e6c0930a5...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.6 Current bundle d34ba45e6c09…
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.

Open mirrored raw JSON Open MITRE-hosted copy
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]
    Docker Overview

    Docker. (n.d.). Docker Overview. Retrieved March 30, 2021.

    Open source URL
  2. [2]
    Docker Bind Mounts

    Docker. (n.d.). Use Bind Mounts. Retrieved March 30, 2021.

    Open source URL
  3. [3]
    Trend Micro Privileged Container

    Fiser, D., Oliveira, A.. (2019, December 20). Why a Privileged Container in Docker is a Bad Idea. Retrieved March 30, 2021.

    Open source URL
  4. [4]
    Intezer Doki July 20

    Fishbein, N., Kajiloti, M.. (2020, July 28). Watch Your Containers: Doki Infecting Docker Servers in the Cloud. Retrieved March 30, 2021.

    Open source URL
  5. [5]
    Container Escape

    0xn3va. (n.d.). Escaping. Retrieved May 27, 2022.

    Open source URL
  6. [6]
    Crowdstrike Kubernetes Container Escape

    Manoj Ahuje. (2022, January 31). CVE-2022-0185: Kubernetes Container Escape Using Linux Kernel Exploit. Retrieved July 6, 2022.

    Open source URL
  7. [7]
    Keyctl-unmask

    Mark Manning. (2020, July 23). Keyctl-unmask: "Going Florida" on The State Of Containerizing Linux Keyrings. Retrieved July 6, 2022.

    Open source URL
  8. [8]
    Windows Server Containers Are Open

    Daniel Prizmant. (2020, July 15). Windows Server Containers Are Open, and Here's How You Can Break Out. Retrieved October 1, 2021.

    Open source URL
  9. [9]
    Broadcom VMSA-2025-004

    Broadcom. (2025, March 6). VMSA-2025-0004: Questions & Answers. Retrieved March 26, 2025.

    Open source URL
  10. [10]
    mitre-attack T1611
    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.

Official MITRE ATT&CK site Official STIX data repository MITRE ATT&CK terms of use