A Deep Dive Into Two (Windows) Exploits Demonstrated At Pwn2Own
Thomas Imbert (Security Engineer · Synacktiv)
HITBSecConf2023 - Phuket · Day 2 · Track 1
Overview
In this highly technical talk from HITB Phuket, Thomas Imbert, a Security Engineer at Synacktiv, meticulously details two distinct Windows kernel local privilege escalation (LPE) exploits he developed and successfully demonstrated at the prestigious Pwn2Own Vancouver 2023 competition. The presentation offers a rare glimpse into the process of identifying, analyzing, and exploiting critical vulnerabilities in Windows kernel drivers, ultimately achieving SYSTEM privileges from an unprivileged user context.

Key moments
- 0:00 Introduction and Pwn2Own competition overview
- 15:00 First exploit: Cloud Filter driver use-after-free root cause
- 24:00 Bypassing Control Flow Guard (CFG) using function chaining
- 31:00 Analysis of Windows kernel mitigation trends and outlook
- 38:00 Second exploit: MSKSRV driver missing probe vulnerability
- 42:00 Arbitrary kernel read/write via mapping and live demo
- 49:30 Q&A: How to leak kernel pointers (KASLR bypass)
A Deep Dive Into Two (Windows) Exploits Demonstrated At Pwn2Own
Speakers: Thomas Imbert, Security Engineer, Synacktiv
Conference: HITB Phuket
YouTube: https://www.youtube.com/watch?v=d0I-UOQHCVs
Overview
In this highly technical talk from HITB Phuket, Thomas Imbert, a Security Engineer at Synacktiv, meticulously details two distinct Windows kernel local privilege escalation (LPE) exploits he developed and successfully demonstrated at the prestigious Pwn2Own Vancouver 2023 competition. The presentation offers a rare glimpse into the process of identifying, analyzing, and exploiting critical vulnerabilities in Windows kernel drivers, ultimately achieving SYSTEM privileges from an unprivileged user context.
Imbert's work not only highlights specific weaknesses in Microsoft's ecosystem but also provides a comprehensive analysis of current Windows kernel security mitigations and the sophisticated techniques required to bypass them. The talk covers two contrasting bug classes: a complex use-after-free vulnerability in the Cloud Filter Driver (CFDv2.sys) and a more straightforward yet devastating missing probe issue in the Microsoft Streaming Service Component (MsKSRV.sys).
The insights shared are invaluable for both offensive and defensive security practitioners, showcasing the practical realities of kernel exploitation in a modern, hardened operating system. It underscores why competitions like Pwn2Own are crucial for driving security research and ensuring the timely patching of zero-day vulnerabilities.
Background
▶ Watch: Introduction and Pwn2Own competition overview (0:00)
Pwn2Own is an annual ethical hacking contest organized by the Zero Day Initiative (ZDI) and Trend Micro. It challenges security researchers to find and exploit zero-day vulnerabilities in widely used software and operating systems, with vendors present to receive the exploit details for patching. The Vancouver 2023 edition targeted various platforms, including operating systems, virtualization software, browsers, and even automotive systems like Tesla. Participants are given several months to develop exploits for zero-day vulnerabilities, which must run on the latest updated software. Successful exploits are awarded prize money, with significant payouts for chaining vulnerabilities. Thomas Imbert and his company, Synacktiv, achieved substantial success, winning over half a million dollars by targeting Windows, Ubuntu, VirtualBox, and Tesla.
Imbert's focus for Pwn2Own was on Windows kernel-mode exploits, a mandatory requirement for OS targets in the competition. Recognizing the generous 10-minute time limit per attempt, he aimed for bugs that, while potentially less reliable or time-consuming to trigger, could still be viable. His initial strategy involved seeking interfaces beyond classic IOCTLs (Input/Output Control), hoping these less-frequented paths might be less scrutinized by Microsoft and other researchers. He gravitated towards Filter Communication Ports, a mechanism for user-mode applications to interact with kernel-mode mini-filter drivers. Although he later discovered this mechanism is ultimately implemented using IOCTLs abstracted by the Filter Manager, the abstraction itself meant the specific IOCTLs were not directly visible for review, aligning with his initial goal.
After reviewing various drivers utilizing Filter Communication Ports, Imbert identified the Cloud Filter Driver (CFDv2.sys) as a promising target. This driver, integral to OneDrive and cloud file system functionality, presented significant complexity with approximately 20 different message types and asynchronous operations, suggesting a higher likelihood of race conditions. Furthermore, the driver had previously been the subject of logical vulnerability research by James Forshaw of Project Zero, indicating a history of security issues, albeit not memory corruption. The Cloud Filter Driver operates as a file system mini-filter, intercepting file operations (open, read, write) and forwarding these callbacks to a user-mode sync provider. This sync provider then handles interactions with cloud storage, allowing for the creation and hydration of "placeholder" files.
For his second exploit, Imbert sought a more reliable and faster bug to chain with a VirtualBox escape. He adopted a rapid review strategy, quickly inspecting file system drivers for simple IOCTL issues. This led him to MsKSRV.sys, the Microsoft Streaming Service Component. This driver, not loaded by default, was found to be loaded on demand by the Plug and Play component when an unprivileged user attempted to open a handle to it, circumventing the need for administrative privileges to load drivers. MsKSRV.sys facilitates memory sharing between processes, even across different privilege levels, making it an interesting target for privilege escalation.
Key Findings
▶ Watch: Bypassing Control Flow Guard (CFG) using function chaining (24:00)
The talk presented two distinct zero-day vulnerabilities and their exploitation:
1. Use-After-Free in Cloud Filter Driver (CFDv2.sys)
- Vulnerability Type: Use-After-Free (UAF).
- Discovery Method: Discovered through fuzzing with a custom harness that interacted with the Cloud Filter API, combined with special pool configuration in Windows Driver Verifier. Special pool helps detect memory corruption by placing allocations at page boundaries and freeing pages upon deallocation, causing immediate crashes on out-of-bounds or use-after-free access. The initial crash manifested as a write access on garbage data, occurring in
Explorer.exe, indicating a broader system impact. - Root Cause: The Cloud Filter Driver maintains a global list of pending I/O operations, storing IRP (I/O Request Packet) control objects for asynchronous file accesses. If a sync provider fails to respond within a minute, the driver attempts to cancel the associated IRP. The UAF occurs because if the user-mode sync provider process is terminated, the
IRP_CONTROL_OBJECTis freed. However, the global list inCFDv2.syscontinues to hold a pointer to this freed object. After the 60-second timeout, the driver attempts to dereference theIRPpointer from this now-freed object, leading to a controlled write if the memory has been reallocated with attacker-controlled data. - Exploitation Primitive: Control of an
IRPpointer, which is then passed toIoCancelIrp. This function takes a lock, performs a write of the value1, and then calls a function pointer located within theIRPstructure. This provides a powerful primitive: an arbitrary write (of1) and a controlled function call. - Complexity: Triggering the bug is complex, requiring precise timing across three processes: a sync provider that never acknowledges a file operation (e.g., file deletion), a client process to initiate the file operation, and a third process to terminate both the sync provider and client at specific moments. After the
IRP_CONTROL_OBJECTis freed, a minute-long wait is necessary before the UAF is triggered by querying process information.
2. Missing Probe in Microsoft Streaming Service Component (MsKSRV.sys)
- Vulnerability Type: Improper input validation (missing probe).
- Discovery Method: Found through quick manual review of IOCTL handlers in file system drivers. The speaker targeted
MsKSRV.syswhich, although not loaded by default, could be loaded on demand by an unprivileged user simply by attempting to open a handle to its device path. - Root Cause: Within an IOCTL handler (specifically
0x222048), theMmProbeAndLockPagesfunction was called with theAccessModeparameter set to0(indicatingKernelMode) even though the underlying buffer pointer was supplied by a user-mode process. This bypasses the critical security check that ensures user-mode pointers do not point into kernel memory. Consequently, an attacker could supply a kernel-mode address, which the driver would then treat as a valid user-mode buffer. - Exploitation Primitive: Arbitrary kernel read and write. The
MsKSRV.sysdriver uses MDLs (Memory Descriptor Lists) to map memory for sharing between processes. By providing a kernel-mode address to the vulnerable IOCTL, an attacker can create an MDL that describes a kernel memory region. The driver then maps this kernel MDL into a user-mode process's virtual address space, effectively granting the user-mode process direct read/write access to arbitrary kernel memory. - Stability: This bug is 100% stable and extremely fast to exploit, making it ideal for chaining with other vulnerabilities.
Technical Deep Dive
▶ Watch: Analysis of Windows kernel mitigation trends and outlook (31:00)
Exploiting the Cloud Filter Driver (CFDv2.sys) Use-After-Free
The UAF in CFDv2.sys provides an attacker with control over an IRP pointer, which is then passed to IoCancelIrp. The key to exploiting this is to spray the kernel heap with attacker-controlled data to reclaim the freed IRP_CONTROL_OBJECT chunk. Common techniques for kernel heap spraying include using named pipe data or TREE objects, which allow for precise control over the size and content of kernel allocations.
Upon successful heap spray, the attacker-controlled IRP pointer can be crafted to point to arbitrary data in user-mode memory. IoCancelIrp then performs two critical actions: it acquires a lock, and then, crucially, it calls a function pointer (IRP->CancelRoutine) from within the IRP structure. This function call is the primary primitive for exploitation.
The ultimate goal for a Windows LPE is to elevate the current process's privileges to SYSTEM. This is typically achieved by corrupting the process's token object in kernel memory, specifically modifying its privilege bitfield. To do this, two things are needed: an arbitrary write primitive and the kernel address of the target token object.
Information Leak (KASLR Bypass): For Pwn2Own, the speaker operated outside of a sandbox, allowing the use of the NtQuerySystemInformation API with the SystemExtendedHandleInformation class. This API, while seemingly benign, reveals the kernel addresses of various objects, including process token objects and system modules. This effectively bypasses KASLR (Kernel Address Space Layout Randomization) for critical targets, providing the necessary addresses to target for corruption.
Mitigation Bypasses:
- MAP/NX (Memory Access Protection / No-Execute): Windows kernel often does not have SMAP (Supervisor Mode Access Prevention) or strict NX policies widely enabled for all kernel code paths. This means that the kernel can, in many contexts, read from and write to user-mode memory. This is a critical advantage for the attacker, as it allows them to forge fake kernel objects (like the
IRPstructure and its related data) entirely in user-mode memory, then direct the kernel to operate on them. - CFG (Control Flow Guard): Kernel CFG is less restrictive than its user-mode counterpart. It primarily ensures that indirect calls jump to the beginning of valid functions, rather than arbitrary code gadgets. To bypass this, the speaker devised a function chaining technique:
- Release Lock: The first function called from the controlled
IRP->CancelRoutinemust be one that releases the lock taken byIoCancelIrp. This prevents a system deadlock. A suitable function,_cancel_routine, was identified. This function, after releasing the lock, then performs another indirect call using a pointer from a controlled structure. - Parameter Control: The subsequent function in the chain is chosen to gain control over more parameters. By carefully crafting the fake objects in user-mode, the attacker can manipulate register values to control arguments for the next function call.
- Arbitrary Write: The final function in the chain is
RtlCopyUnicodeString. This function is ideal for an arbitrary write because its parameters (source buffer, destination buffer, and length) can be fully controlled. The destination is set to the kernel address of the current process's token object, the source to a user-mode buffer containing the desired privilege bits, and the length to the size of the privilege bitfield.
Full Exploit Chain for UAF:
- Forge fake
IRPand associated structures in user-mode memory. - Trigger the UAF vulnerability by orchestrating the three processes and the specific timing.
- Spray the kernel heap with attacker-controlled data (e.g., named pipe data) to reclaim the freed
IRP_CONTROL_OBJECTchunk with the fakeIRPpointer. - Wait for approximately one minute for the internal timer to expire.
- Trigger the use-after-free by calling the
NtQueryProcessAPI (or a similar one that interacts with theCL_FILTER_DRIVER). - The
IoCancelIrpfunction is called with the attacker-controlledIRPpointer. - The function chain is executed, leading to
RtlCopyUnicodeStringwriting new privileges to the process token. - The process now has
SYSTEMprivileges. A shell can then be spawned by leveraging the new debug privileges to inject into a system process likewinlogon.exe.
The speaker noted that the reliability of this exploit was hindered by the kernel's lookaside list for IRP_CONTROL_OBJECT allocations. The object is only truly freed to the general heap if the lookaside list is full. This means the UAF allocation might not be immediately available for reuse, requiring multiple attempts or a specific system state for optimal reliability.
Exploiting the MsKSRV.sys Missing Probe
The missing probe vulnerability in MsKSRV.sys is significantly more straightforward and powerful. The core issue is the driver's failure to validate that user-supplied pointers actually reside in user-mode memory before using them to create an MDL.
MDLs (Memory Descriptor Lists): An MDL is a kernel-mode structure that describes a virtual memory range and its corresponding physical pages. They are crucial for I/O operations and direct memory access (DMA), allowing the kernel to lock and map memory efficiently.
Exploitation Primitive: By calling the vulnerable IOCTL (0x222048) and supplying a kernel-mode address as the target buffer, MsKSRV.sys creates an MDL for that kernel memory region. The driver's intended functionality is to then map this MDL into another process's user-mode address space for shared memory. Because the initial check was bypassed, the driver unknowingly maps a portion of kernel memory directly into the attacker's user-mode process. This provides an arbitrary kernel read/write primitive, as the attacker can now directly access and modify the mapped kernel memory from user mode.
Full Exploit Chain for Missing Probe:
- Use
NtQuerySystemInformation(SystemExtendedHandleInformation) to leak the kernel address of the current process's token object, similar to the first exploit. - Call the vulnerable
MsKSRV.sysIOCTL, supplying the leaked token address as the "user-mode" buffer. - The driver creates an MDL for the token object's kernel memory and maps it into the attacker's process.
- The attacker's process now has a user-mode virtual address that points directly to the kernel token object.
- Modify the mapped token memory to grant
SYSTEMprivileges. - Spawn a shell.
This exploit is remarkably efficient, often requiring only a few lines of code after the initial address leak and driver interaction setup. Its 100% stability and speed make it an ideal choice for complex exploit chains.
Demo / Proof of Concept
▶ Watch: Arbitrary kernel read/write via mapping and live demo (42:00)
Thomas Imbert provided a live demonstration of the MsKSRV.sys exploit during his talk. The demo started with a command prompt running as an unprivileged user, confirming limited access to system resources. Upon executing the exploit, a new command prompt immediately appeared, running with SYSTEM privileges. The speaker highlighted that while the new window sometimes popped up on a different screen (a common issue with demo setups), the underlying privilege escalation was successful and consistently reproducible. He emphasized the exploit's 100% stability and very fast execution time, making it a robust and reliable primitive for achieving LPE. The simplicity and effectiveness of the demo underscored the power of the missing probe vulnerability.
Defensive Implications
▶ Watch: Q&A: How to leak kernel pointers (KASLR bypass) (49:30)
Imbert's talk provided a critical assessment of the current state of Windows kernel security and its mitigations, particularly concerning Local Privilege Escalation (LPE) from unprivileged users.
For Exploit 1 (Cloud Filter Driver UAF):
- KASLR Bypass: The reliance on
NtQuerySystemInformation(SystemExtendedHandleInformation) to leak kernel addresses (e.g., token, module base addresses) is a known weak point. Imbert noted that Microsoft is actively working to remove or mitigate this specific information leak in Insider builds, which, if fully implemented, would significantly complicate future LPEs by requiring a separate KASLR bypass or information leak bug. - SMAP (Supervisor Mode Access Prevention): While SMAP is a powerful mitigation that prevents kernel code from accessing user-mode memory, it is not widely enabled across the entire Windows kernel due to potential compatibility issues with legacy code and third-party drivers. If SMAP were universally enforced, it would prevent attackers from forging fake kernel objects in user-mode memory, rendering techniques like the UAF exploitation much harder. The UAF in
CFDv2.sysoccurred at an IRQL (Interrupt Request Level) that typically should not access user-mode memory, suggesting an opportunity for more targeted SMAP enforcement. - CFG (Control Flow Guard): Kernel CFG, as implemented, is less robust than its user-mode counterpart. It allows many valid function entry points as targets, which permitted the function chaining technique used in the exploit. Improving kernel CFG would be challenging due to the vast and diverse codebase, including numerous third-party drivers.
- Hardware Mitigations (CET, HVCI): Imbert briefly touched upon Control-flow Enforcement Technology (CET) (Shadow Stacks) and Hypervisor-protected Code Integrity (HVCI). He noted that these hardware-assisted mitigations primarily protect against corruption of return addresses or jumps to arbitrary code within functions. They do not prevent calling valid kernel functions, which was the basis of his CFG bypass, and therefore would not prevent this class of exploit.
- Microsoft's Priorities: Imbert concluded that while Microsoft invests heavily in high-impact scenarios like reducing attack surface and hardening sandboxes, LPE from an unprivileged user might not be their top priority. He believes that LPEs will remain possible, though potentially requiring more sophisticated bugs or additional information leaks, especially if KASLR bypasses become harder.
For Exploit 2 (MsKSRV.sys Missing Probe):
- Input Validation: This exploit serves as a stark reminder of the critical importance of rigorous input validation, specifically probing user-supplied pointers, in all kernel drivers. Any failure to validate that user-mode buffers are indeed within user-mode boundaries can lead to immediate and devastating arbitrary kernel read/write primitives.
- On-Demand Driver Loading: The fact that
MsKSRV.syscould be loaded on demand by an unprivileged user, despite not being loaded by default, highlights a subtle but significant attack surface. Defenders should be aware that drivers not explicitly loaded might still be reachable and exploitable if they can be dynamically loaded by the OS without elevated privileges. Regular auditing of driver loading mechanisms and permissions is crucial.
General Implications:
- Patching Velocity: Microsoft patched both vulnerabilities relatively quickly, between March (Pwn2Own) and June. This demonstrates the effectiveness of competitions like Pwn2Own in identifying and resolving critical zero-day vulnerabilities.
- Windows vs. Other OS: Imbert contrasted Windows kernel exploitation with other operating systems, suggesting that Windows, while improving, still allows for LPEs with "limited means" (e.g., one person, one bug), whereas other OS might require more extensive effort and multiple chained bugs. This underscores the need for continued investment in Windows kernel security.
Defenders should prioritize patching these specific vulnerabilities (now fixed), but also apply the lessons learned: implement stricter input validation for all kernel-user mode interactions, understand dynamic driver loading behaviors, and stay informed about the evolving landscape of kernel mitigations and their bypasses.
Key Takeaways
- Pwn2Own Value: Pwn2Own is an excellent platform for security researchers to challenge themselves, learn, and contribute to the security ecosystem by responsibly disclosing zero-day vulnerabilities.
- Windows LPE is Achievable: Despite ongoing mitigation efforts, Windows kernel LPEs from an unprivileged user remain achievable with a single, well-understood vulnerability, even if it's complex or requires precise timing.
- Mitigation Gaps: Current Windows kernel mitigations like KASLR, SMAP, and CFG have limitations or are not universally applied, creating windows of opportunity for attackers. The impending removal of
NtQuerySystemInformationas a KASLR bypass will increase future LPE complexity. - Input Validation is Paramount: The
MsKSRV.sysexploit powerfully demonstrates that fundamental security errors, such as missing input validation (probes), can lead to immediate and complete compromise with arbitrary kernel read/write capabilities. - Dynamic Driver Loading: Drivers not loaded by default can still pose a significant risk if they can be loaded on demand by unprivileged users, effectively expanding the attack surface.
- Exploit Reliability vs. Contest Rules: Even less reliable bugs with complex timing requirements can be viable for contests like Pwn2Own, given the generous time limits and multiple attempts.
About the Speaker(s)
Thomas Imbert is a Security Engineer at Synacktiv, a French offensive security company. Synacktiv specializes in a range of security services, including penetration testing, reverse engineering, security development, and incident response. Imbert's participation in Pwn2Own was made possible through his work at Synacktiv, demonstrating the company's commitment to advanced security research and expertise in vulnerability exploitation. He has successfully contributed to identifying and exploiting critical zero-day vulnerabilities in Windows kernel drivers.
Reviews
Dr. Zero (Offensive Security Researcher) — MUST SEE
This is what Pwn2Own talks should be. Two distinct kernel LPEs, one complex UAF with a real CFG bypass chain, one trivially devastating missing-probe bug, both walked through with enough detail to actually learn something. Imbert doesn't just show what he did — he shows why current mitigations fail and what would have stopped him.
Heather Calloway (CISO) — STRONG ACCEPT
Two clean Windows kernel LPE chains demonstrated at Pwn2Own — one a complex UAF requiring precise timing, the other a trivially exploitable missing probe that grants arbitrary kernel read/write. Both now patched. Any CISO running Windows endpoints needs to understand what this says about the state of kernel hardening.