What I Learned from Reverse Engineering Windows Containers
Summary: Unit 42 researchers reverse engineered the Windows kernel to document how Microsoft implements containers, finding that job objects serve the role Linux cgroups fill, server silo objects replace namespaces, and the kernel filters system calls in kernel space to stop a container process from escalating privileges or escaping. The post traces the path from CreateFile through NtCreateFile and IopCreateFile, where PsGetCurrentSilo returns a pointer to the ESILO object that determines which root directory object resolves a path, and notes that IopLoadDriverImage simply returns whether the calling thread is inside a silo.
Bottom line: The user inside a Windows container is usually an administrator with no limit on the system calls it can execute, so the only thing standing between a malicious container and a kernel driver load is a check implemented per system call - each one a place where a mishandling could open an escape.
Read the original at Unit 42 Palo Alto Networks ↗
- Topics
- Malware
- Related
- ARTEX and beyond: AI-enabled penetration testing platforms Cyber Risks · Nov 13, 2026Fake GTA 6 download goes after Steam logins and crypto wallet data Cyber Risks · Nov 13, 2026Operation Endgame Takes Down Gootloader, CastleRAT and StealC Servers, Seizes 6.4M Stolen Logins Cyber Risks · Nov 13, 2026