Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Um comando direto ignora o prompt de revisão. Verifique a origem antes de executá-lo.
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.
Kill Chain Phase
Privilege Escalation (TA0004)
Platforms: Windows, Linux, Containers, ESXi
What to Check
Identify if Escape to Host technique is applicable to target environment
Check Windows systems for indicators of Escape to Host
Check Linux systems for indicators of Escape to Host
Check Containers systems for indicators of Escape to Host
Verify mitigations are bypassed or absent (5 known mitigations)
The following tests are from Atomic Red Team and provide actionable ways to test this technique:
Atomic Test 1: Deploy 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.
Atomic Test 2: Mount 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.
Atomic Test 3: Privilege 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"
Dependencies:
Docker
Docker Privileged User
Manual Testing
If Atomic Red Team tests are not applicable, manually verify the technique by:
Identify Attack Surface: Determine if the target environment is susceptible to Escape to Host by examining the target platforms (Windows, Linux, Containers).
Assess Existing Defenses: Review whether mitigations for T1611 are in place. If defenses are absent or misconfigured, this technique may be exploitable.
Execute Test: Use tools and methods described in the MITRE ATT&CK page and external references below.
Remediation Guide
M1051 Update Software
Ensure that hosts are kept up-to-date with security patches.
M1038 Execution Prevention
Use read-only containers, read-only file systems, and minimal images when possible to prevent the running of commands. Where possible, also consider using application control and software restriction tools (such as those provided by SELinux) to restrict access to files, processes, and system calls in containers.
M1048 Application Isolation and Sandboxing
Consider utilizing seccomp, seccomp-bpf, or a similar solution that restricts certain system calls such as mount. In Kubernetes environments, consider defining Pod Security Standards that limit container access to host process namespaces, the host network, and the host file system.
M1026 Privileged Account Management
Ensure containers are not running as root by default and do not use unnecessary privileges or mounted components. In Kubernetes environments, consider defining Pod Security Standards that prevent pods from running privileged containers.
M1042 Disable or Remove Feature or Program
Remove unnecessary tools and software from containers.
