The COW (Container On Windows) Who Escaped the Silo

Overview: Eran Segal of SafeBreach Labs investigates the security posture and isolation architecture of process-isolated Windows containers. The presentation examines the underlying kernel constructs—Job Objects, Silos, and Server Silos—that separate Windows containers from the host operating system. Segal demonstrates techniques for elevating privileges to NT AUTHORITY\SYSTEM inside a container by manipulating image filesystems, followed by systematically identifying unvalidated kernel system calls to escape container boundaries.

Key Topics: - Windows container isolation models: Hyper-V isolation versus process isolation - Kernel isolation primitives: Job Objects, Silos, and Server Silos in EPROCESS/ETHREAD - In-container privilege escalation to NT AUTHORITY\SYSTEM via container image manipulation - Kernel syscall auditing methodology targeting missing Server Silo boundary validations

Technical Details: Windows provides two distinct container deployment models: Hyper-V isolated containers, which execute within lightweight virtual machines with dedicated kernels, and process-isolated containers, which share the host NT kernel directly. Unlike monolithic Linux kernels where minimal container environments run without user-mode system processes, Windows relies heavily on user-mode system infrastructure. Consequently, process-isolated Windows containers run dedicated instances of system services such as svchost.exe alongside user applications, managed via Job Objects that have been converted into Silos and Server Silos.

Server Silos extend standard Silos by supporting resource redirection for the object manager namespace, filesystem, networking stack, and registry. To enforce container boundaries, the Windows kernel (ntoskrnl.exe) inspects Job Objects linked to the EPROCESS and ETHREAD structures during system call execution, blocking restricted actions such as loading kernel drivers or enumerating processes outside the Silo. However, starting a container with --user ContainerUser does not ensure privilege containment: because background services run as NT AUTHORITY\SYSTEM and are loaded directly from the container image filesystem, an attacker can modify container images via DLL sideloading, registry alterations, or replacing binaries in System32 to execute arbitrary commands as SYSTEM inside the container.

Once SYSTEM privileges are established within the container, escaping requires identifying kernel system calls that lack Server Silo context checks. Segal developed a targeted auditing methodology across the 500+ Windows kernel system calls, filtering for syscalls requiring administrative privileges that lacked Server Silo boundary validation. This analysis revealed multiple vulnerable interfaces, prominently including NtQuerySystemInformation, which processes system information classes through a massive switch statement spanning approximately 200 enums. By invoking system calls where Microsoft omitted Silo checks, containerized processes can query sensitive host kernel state, manipulate host resources, and break out of the container silo.

Key Takeaways: Process-isolated Windows containers do not provide strong security boundaries against determined attackers who control the container filesystem or achieve SYSTEM privileges. For multi-tenant or untrusted workloads, organizations must deploy Hyper-V isolated containers to ensure hypervisor-enforced kernel separation. Windows kernel engineers and security auditors must systematically verify that all administrative system calls and NtQuerySystemInformation information classes enforce strict Server Silo context checks.

(AI summary — Gemini Flash)