Trusted Design
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.(Citation: Docker Overview)
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.(Citation: Docker Bind Mounts)(Citation: Trend Micro Privileged Container)(Citation: Intezer Doki July 20)(Citation: Container Escape)(Citation: Crowdstrike Kubernetes Container Escape)(Citation: Keyctl-unmask)
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.(Citation: Container Escape) 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.(Citation: Windows Server Containers Are Open)
In ESXi environments, an adversary may exploit a vulnerability in order to escape from a virtual machine into the hypervisor.(Citation: Broadcom VMSA-2025-004)
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.
T1611は「Escape to Host（ホストへのエスケープ）」として定義されている、クラウドやコンテナ環境（Docker、Kubernetes、各種仮想化ハイパーバイザーなど）において最も深刻かつ警戒すべき「特権昇格（Privilege Escalation）」および「横展開（Lateral Movement）」のテクニックです。
隔離された環境であるはずの「コンテナ（または仮想マシン：VM）」の内部に侵入した攻撃者が、その境界線を物理的に突破し、コンテナを動かしている土台である「ホストOS（物理サーバーやノード）」の制御権（root）を奪取する手法、いわゆる「コンテナエスケープ」を指します。
この手法で攻撃者は、「1つのアプリの檻から脱出し、同じサーバー上で動く他のすべてのコンテナや、クラウドインフラ全体の支配権を一網打尽に奪うこと」を実現します。
コンテナによる分離（隔離）の完全な無効化:
本来、コンテナは万が一ハッキングされても、被害がそのコンテナ1つ（単一のWebアプリなど）だけに閉じるようにOSレベルで隔離されています。T1611はこの「安全神話」を根本から破壊します。
ホストOSの完全掌握:
ホストOSのroot権限を奪うことで、攻撃者は同じ物理サーバー上で稼働している他の全く関係のない他部署・他顧客のコンテナ内のデータを盗み見たり、ホストOSに設定されている強力なクラウド認証情報（AWSのIAMロール、Kubernetesのサービスアカウントトークンなど）を盗んで、クラウド全体へ被害を拡大（ラテラルムーブメント）させたりすることが可能になります。
コンテナエスケープは、主に「コンテナの設定ミス（過剰な特権）」または「Linuxカーネルの脆弱性」を突いて実行されます。ここでは、実戦で最も頻出する不適切な特権コンテナ（Privileged Container）の設定ミスを突いたエスケープの流れを解説します。
初期侵入:
コンテナ上で動作しているWebアプリケーションの脆弱性（RCEなど）を突き、コンテナの内部に一般ユーザーまたはrootとして侵入します。
環境調査（特権の確認）:
攻撃者は自分がいるコンテナが、ホストのデバイスに直接アクセスできる「--privileged（特権モード）」で起動されていないか調査します。
エクスプロイト・脱出コマンドの実行（トリガー）:
特権コンテナである場合、コンテナ内からホストOSの物理ディスクドライブ（/dev/sda1 など）が直接見えています。攻撃者はこれを利用し、ホストOSのハードディスクをコンテナ内の適当なフォルダに強引にマウント（接続）します。
mkdir /mnt/hostmount /dev/sda1 /mnt/hostホストOSの書き換え:
マウントしたことで、コンテナ内にいながらにしてホストOSの核心部（/etc/shadow パスワードファイルや、ホスト側の cron ジョブスケジュールなど）を自由に変更できるようになります。攻撃者はホスト側の自動起動ジョブ（/mnt/host/etc/cron.d/malware）に、自身のC2サーバーへ接続するリバースシェルを書き込みます。
ホストの掌握（目的達成）:
数分後、ホストOS側でリバースシェル（cron）が実行され、攻撃者はコンテナの壁を完全に越えて、ホストOSの最高権限（root）の奪取に成功します。
コンテナ環境の安全は、「過剰な権限を与えない設定（堅牢化）」がすべてと言っても過言ではありません。
特権コンテナ（--privileged）の原則禁止（最重要）:
コンテナを起動する際、特別な理由がない限り --privileged フラグの使用を絶対に禁止します。Kubernetes環境であれば、Admission Controller（Pod Security StandardsやKyverno、OPA/Gatekeeperなど）を用いて、特権モードやホストのネットワーク/ポッドの共有（hostNetwork: true, hostPID: true）を要求する不審なポッドのデプロイを自動的に拒否（ブロック）します。
Linuxカーネルおよびコンテナランタイムの迅速なアップデート:
後述するような、Linuxカーネルやコンテナのエンジン（containerd、runc）自体の脆弱性を突くエスケープを防ぐため、ホストOSおよびコンテナ環境のパッチ管理を徹底します。
ユーザー名前空間（User Namespaces）の有効化:
DockerやKubernetesにおいてユーザー名前空間を有効化します。これにより、万が一コンテナの内部でハッカーが root（UID 0） 権限を持って暴れたとしても、ホストOSの視点からは「ただの無権限の一般ユーザー（UID 100000など）」として処理されるため、エスケープの難易度が飛躍的に向上します。
ランタイム挙動監視（Runtime Security）の導入:
Falco や 各種クラウドEDRなどのコンテナ専用セキュリティ製品を導入し、コンテナ内での不審な mount コマンドの実行や、予期せぬカーネルモジュールのロードといったエスケープの予兆をリアルタイムで検知・遮断します。
CWE-693: Protection Mechanism Failure（保護メカニズムの失敗）
コンテナやサンドボックスが提供すべき「隔離・分離（Isolation）」という保護メカニズムが、設定ミスや脆弱性によって破綻し、外部（ホスト環境）への干渉を許してしまう問題。
CWE-250: Execution with Unnecessary Privileges（不要な特権を伴う実行）
コンテナに対して、アプリケーションの動作に本来必要のない「ホストのハードウェアやカーネルへの直接アクセス権（特権モード）」を過剰に付与してしまっている設計・運用の不備。
T1611（Escape to Host）を極めて凶悪なものにする、コンテナの歴史の分岐点となった超有名な脆弱性（既知のエクスプロイト）です。
CVE-2019-5736 (runc の脆弱性):
DockerやKubernetesの標準コンテナランタイムである runc に存在した、コンテナ環境の歴史上最も深刻な脆弱性の一つです。コンテナ内に侵入した攻撃者が、このバグを突くことで、ホスト側にある本物の runc バイナリをコンテナ内から上書き・改ざんすることが可能でした。これにより、次にホスト側でコンテナが起動・操作された瞬間に、マルウェアがホストOSのroot権限で自動実行され、いとも簡単にエスケープが成立しました。
CVE-2022-0185 (Linuxカーネルのファイルシステムコンテキストの脆弱性):
Linuxカーネル（5.1〜）に存在したヒープバッファオーバーフローのバグです。コンテナ内の一般ユーザー（非特権アカウント）であっても、このカーネルの不備を突くことでメモリを破壊し、コンテナの隔離の壁を突き破ってホストOSの完全なroot権限へ一撃で昇格・エスケープできるエクスプロイトとして、多くのKubernetesクラスターを恐怖に陥れました。
クラウド/コンテナ運用の現場やペネトレーションテストにおいて、「Webサーバーの入ったコンテナ1台が踏み台にされた」という報告を受けた際、「まあコンテナの中だし、機密データはそこにはないから大丈夫だろう」と楽観視するのは極めて危険です。
攻撃者がこの T1611 を使って数秒でホストノードにエスケープしていた場合、そのノード上で動く他のお客様のWebサイトや、背後の認証トークン経由でAWS / Azureの全インフラがすでに陥落している可能性があります。
コンテナのインシデント対応では、「エスケープされた形跡（ホスト側ログでの不審なプロセス起動など）がないか」を直ちに確認することが、被害を最小限に食い止めるための最大のブレイクスルーとなります。
この攻撃手法を利用する脅威アクターは登録されていません。