Virtualization and containers are the foundations of cloud services. Containers should be isolated from the real host’s settings to ensure the security of the host. In this talk we’ll answer these questions: “Are Windows process-isolated containers really isolated?” and “What can an attacker achieve by breaking the isolation?” Before we jump into the vulnerabilities, we’ll explain how Windows isolates the container’s processes, filesystem and how the host prevents the container from executing syscalls which can impact the host. Specifically, we’ll focus on the isolation implementation of Ntoskrnl using server silos and job objects. We’ll compare Windows containers to Linux containers and describe the differences between their security architectural designs. We’ll follow the scenario of an attacker-crafted container running with low privileges. We'll show in multiple ways how to gain privilege escalation inside the container to NT/System. After gaining NT/System permissions, we'll talk about how we escaped the isolation of the container and easily achieved a dump of the entire host’s kernel memory from within the container. If the host is configured with a kernel debugger, we can even dump the host’s Admin credentials. We’ll finish by demonstrating how an attacker-crafted container with low privileges can read UEFI settings and then set them. Using this technique an attacker can communicate between containers and cause a permanent Denial-of-Service (DoS) to a host with default settings, through the UEFI interface.