How to Use God Mode in Windows

How to Use God Mode in Windows

Speakers: James Spicer, Hacker, Trenchant

Conference: Kawaiicon

YouTube: https://www.youtube.com/watch?v=7jhNHJ6xMkI

Overview

In the realm of advanced Windows exploitation, achieving kernel read/write primitives (often referred to as "god mode" by the speaker) is frequently considered a definitive victory. However, as James Spicer, a hacker from Trenchant, meticulously details in his Kawaiicon talk, "How to Use God Mode in Windows," even this elevated level of access doesn't automatically grant unfettered control. The talk delves into the nuanced challenges of privilege escalation from a highly restricted process—such as a sandboxed browser renderer—even when armed with kernel-level capabilities.

Spicer's research focuses on overcoming seemingly insurmountable "Access Denied" errors that arise when a lockdown process, despite its kernel read/write power, attempts to perform actions like opening handles to other processes. This isn't a quest for a new 0-day vulnerability; rather, it's an exploration of how to systematically dismantle existing Windows security models, specifically restricted tokens and App Container processes, that are designed to contain even compromised processes. The core premise is that while kernel access grants immense power, the intricate layers of Windows security require a deep understanding and targeted manipulation to fully exploit.

The significance of Spicer's work lies in its demonstration that modern Windows security, even when faced with a compromised kernel, still presents formidable barriers. His talk highlights the often-overlooked complexities of post-exploitation scenarios where traditional methods fail, forcing attackers to understand and bypass sophisticated authorization mechanisms. For defenders, this research underscores the importance of a multi-layered security approach, emphasizing that even if the kernel is breached, subsequent actions can still be monitored and potentially thwarted if not executed with extreme precision and a thorough understanding of Windows internals.

Background

▶ Watch: Introduction and the 'Access Denied' Paradox (0:00)

The premise of this research begins with a seemingly paradoxical situation: an attacker has achieved Remote Code Execution (RCE) within a highly lockdown process (e.g., a browser renderer) and further possesses read/write primitives in the kernel. This level of access is what Spicer refers to as "god mode." One would assume that with kernel read/write capabilities, any operation, such as opening a handle to another process for injection, would be trivial. However, as Spicer demonstrates, attempts to call OpenProcess often result in an "Access Denied" error, even from this privileged state. This unexpected roadblock necessitates a deep dive into Windows' authorization mechanisms.

At the heart of Windows authorization are Access Tokens and Security Descriptors (DACLS). An Access Token defines the security context of a process or thread, containing information about the user, groups, and privileges associated with it. These tokens are evaluated by the Security Reference Monitor, specifically through functions like SeAccessCheck and SePrivilegeCheck, whenever an object is requested. A Security Descriptor is attached to an object (like a process or file) and contains a Discretionary Access Control List (DACL), which lists Access Control Entries (ACEs) that specify who is allowed or denied access, and what types of access. These ACEs refer to users or groups by their Security Identifiers (SIDs). For instance, a process DACL might allow access for the SYSTEM SID and Administrators SID.

The primary hurdle identified in Spicer’s scenario is the nature of the restricted token. Restricted tokens are a security feature designed to limit the privileges of a process, even if its primary token has higher privileges. They are subject to two distinct access checks: a primary check against the token's User and Groups array and a secondary check specific to its Restricted SIDs array. Critically, these tokens often contain "deny only" SIDs, which explicitly forbid access, and the "No One" SID, which, by its nature, can never match an allowed SID in an object's DACL, making secondary access checks nearly impossible to pass.

Spicer also reviewed prior research into Windows privilege escalation and token manipulation:

• Tarjei Mandt's 2011 Black Hat talk detailed manipulating the PreviousMode variable in the KTHREAD structure. By changing this value, the Security Reference Monitor would interpret the previous context as Ring 0, effectively bypassing further access checks. This technique worked on Windows 10 but caused a Blue Screen of Death (BSOD) on Windows 11.
• James Forshaw of Google Chrome discovered a regression that broke the relationship between parent, child, and sibling access tokens. However, this required a bug in the Chrome GPU process, which typically has more privileges than a lockdown renderer process, and was subsequently patched.
• Yan Shafir's work on exploiting a simple vulnerability involved using SeDebugPrivilege to gain access to any process. Her technique involved creating a restricted token, manipulating its User and Groups array to point to a high-integrity SID, and then impersonating it. The critical limitation for Spicer's scenario was that from a lockdown process with an existing restricted token, the necessary APIs to create or modify tokens were unavailable.
• Spicer's own initial thought of finding the SYSTEM process token and directly pointing his thread's token field to it was quickly dismissed. While technically possible with kernel read/write, it creates an immediate EDR (Endpoint Detection and Response) red flag, as the lockdown process would suddenly appear to run as NT AUTHORITY\SYSTEM with an inappropriate set of privileges. Moreover, this technique was already publicly known, rendering it non-novel for research purposes.

Faced with these challenges and the limitations of previous methods, Spicer was compelled to explore novel approaches, focusing on the intricate details of how restricted tokens are evaluated and enforced at the kernel level.

Key Findings

▶ Watch: Prior Research and Its Limitations (5:00)

James Spicer's research yielded two significant, novel bypasses for Windows security mitigations, both stemming from a deep understanding of kernel token structures and their evaluation:

1. Bypass of Restricted Token Primary Access Checks (Deny Only SID Manipulation): The first key finding addressed the immediate problem of "deny only" SIDs within a token's User and Groups array. Spicer discovered that these SIDs, when present, explicitly override any "access allowed" entries in an object's DACL, leading to an access denied outcome. By using his kernel read/write primitives, he was able to locate the attributes value associated with these SIDs (specifically, hex 10 for "deny only") and modify it to an "enabled" state. This effectively disarmed the explicit denial, allowing the primary access check to proceed based on other allowed SIDs.

1. Novel Bypass of Restricted Token Secondary Access Checks (TokenFlags Manipulation): This was the most challenging and significant contribution. Restricted tokens are unique because they undergo a secondary access check against their Restricted SIDs array. This array often contains the "No One" SID, which can never legitimately match an allowed SID in a DACL, making it an impassable barrier. Spicer's breakthrough involved identifying a specific bit within the TokenFlags field of the token object itself. Through analysis of the ReactOS source code, he discovered the SeTokenIsRestricted function, which checks if a token has the TOKEN_IS_RESTRICTED bit (defined as hex 10) set in its TokenFlags. By flipping this single bit from set to unset using kernel read/write, the system was deceived into believing the token was not restricted. Consequently, the entire secondary access check was skipped, granting access where it would otherwise be denied. This elegant solution bypassed a fundamental aspect of restricted token enforcement without directly manipulating the immutable Restricted SIDs array or its count.

1. Novel Bypass of App Container Mitigations (Further TokenFlags Manipulation): Building on the success of the restricted token bypass, Spicer extended his research to App Container processes, which represent an even more stringent sandboxing mechanism used by modern Metro apps and components like the Edge renderer. These processes introduce additional access checks handled by a separate entity, the Runtime Broker, and their tokens possess even more complex structures. Spicer hypothesized that, similar to restricted tokens, there might be another specific bit within the TokenFlags field that identifies an App Container process. Leveraging his established methodology, he successfully identified and flipped this specific bit. This second TokenFlags manipulation effectively bypassed the additional sandbox checks enforced by the Runtime Broker, granting broader access within the App Container context. This demonstrated a pattern of mitigation that could be overcome by directly manipulating the token's internal state flags.

Together, these findings represent a comprehensive strategy for overcoming Windows' layered authorization mechanisms from a kernel-privileged, but application-restricted, context. They reveal that even highly sophisticated sandboxing can be circumvented by understanding and directly manipulating the underlying kernel objects that govern security decisions.

Technical Deep Dive

▶ Watch: Novel Restricted Token Bypass Breakthrough (12:00)

The core challenge Spicer addressed was the inability to perform seemingly basic operations, such as OpenProcess, despite having Remote Code Execution (RCE) in a sandboxed process and kernel read/write primitives. This "god mode" capability was initially thwarted by the intricacies of Windows Access Tokens and Security Descriptors.

The first step in understanding the problem involved examining the structure of a restricted token. A token, represented by the _TOKEN structure in the kernel, contains several critical fields. Of particular interest are the UserAndGroups array and the RestrictedSids array. Each entry in the UserAndGroups array consists of an 8-byte pointer to a SID object and an unsigned long attributes value. Spicer observed that in restricted tokens, many SIDs had their attributes value set to hex 10, which corresponds to "deny only." This attribute is highly problematic because if a "deny only" SID matches any SID in the target object's DACL, it immediately results in an "Access Denied" outcome, regardless of other "access allowed" entries.

The initial technical bypass involved manipulating these attributes values. With kernel read/write access, Spicer could enumerate the UserAndGroups array within his process's token. For any SID found with the hex 10 "deny only" attribute, he could use his kernel primitive to flip this bit, effectively changing the attribute to "enabled." This modification removes the explicit denial, allowing the primary access check to proceed based on other SIDs that might grant access. While a crucial first step, this only addressed the primary access checks.

The more significant technical hurdle was bypassing the secondary access checks specific to restricted tokens. The RestrictedSids array, often containing the "No One" SID, proved to be an insurmountable barrier for direct matching against a target object's DACL. Attempts to simply null out the RestrictedSids array pointer or the RestrictedSidCount were met with failure, likely due to internal integrity checks or hashes that would detect such blatant manipulation. Furthermore, from a lockdown process, standard Windows APIs to create or modify tokens were unavailable.

Spicer's breakthrough came from a less conventional source: the ReactOS kernel source code. ReactOS, an open-source alternative to Windows, often mirrors Windows' internal structures and logic. While extensively reviewing SeAccessCheck and SePrivilegeCheck functions in Windows Internals and using a custom GDRA plugin with a local LLM yielded no direct clues, ReactOS provided a critical insight. Spicer discovered a function named SeTokenIsRestricted within the ReactOS source. This function's implementation revealed that it determined if a token was restricted by checking a specific bit in the token's TokenFlags field. The TOKEN_IS_RESTRICTED constant was defined as hex 10.

This was the "aha!" moment. The TokenFlags field is a bitmask within the _TOKEN structure that controls various token behaviors. Spicer's analysis of his restricted token in WinDbg confirmed that the hex 10 bit was indeed set in its TokenFlags. The elegant solution was to use his kernel read/write primitive to locate the TokenFlags field in his process's _TOKEN structure and simply flip this hex 10 bit off. By doing so, the SeTokenIsRestricted function (and its Windows equivalent) would evaluate the token as not restricted, thereby skipping the entire secondary access check. This allowed OpenProcess to succeed, granting access based solely on the (now-modified) primary SIDs.

The final technical deep dive extended this principle to App Container processes. Modern Metro applications and components like the Edge browser renderer operate within App Containers, which enforce an even stricter sandbox, often involving a Runtime Broker process for additional access control. App Container tokens are considerably more complex, with many additional fields. However, Spicer hypothesized that similar to the restricted token bypass, a specific flag within the TokenFlags field might indicate an App Container context. By applying the same methodology—identifying and flipping this specific bit within the TokenFlags—he was able to bypass the App Container-specific mitigations. While the exact bit for App Containers wasn't explicitly stated, the methodology mirrored the restricted token bypass, demonstrating a recurring pattern in Windows' internal security flag mechanisms.

In essence, Spicer's work showed that Windows' complex layered security, while robust, relies on specific flags and attributes within kernel objects. By understanding these internal representations and having the ability to directly manipulate them, even the most stringent sandboxes can be circumvented, turning "Access Denied" into "Access Granted."

Demo / Proof of Concept

▶ Watch: Bypassing App Container Programs (14:30)

While James Spicer's talk provided a comprehensive and detailed explanation of the technical mechanisms behind his bypasses, it did not feature a live, step-by-step demonstration or a publicly released proof-of-concept tool. Instead, he walked the audience through the logical progression of his research, showing WinDbg output to illustrate token structures, attributes values, Restricted SIDs, and the critical TokenFlags field before and after manipulation. He described the outcome of his bypasses—specifically, that after flipping the relevant bits in TokenFlags and adjusting deny only SIDs, operations that previously resulted in "Access Denied" were now successfully granted. The success of these techniques was presented as the culmination of extensive reverse engineering and kernel-level manipulation using the assumed kernel read/write primitives.

Defensive Implications

▶ Watch: Talk Summary and God Mode Impact (16:30)

James Spicer's research, while demonstrating powerful offensive techniques, also carries significant implications for Windows defenders. The core takeaway is that even with kernel read/write primitives—often considered the ultimate compromise—Windows' layered security model still presents challenges that require targeted bypasses. This underscores the principle of defense in depth.

Firstly, the talk highlights the importance of preventing initial kernel compromise. If an attacker gains kernel read/write, the game is largely over, but these bypasses show that post-exploitation is still a complex dance. Defenders should focus heavily on securing the kernel from vulnerabilities (e.g., driver exploits, memory corruption) and ensuring robust patching cycles.

Secondly, the research provides insights into EDR (Endpoint Detection and Response) evasion. Spicer explicitly notes that simply swapping a process's token to point to the SYSTEM token is an "absolute red flag" for any EDR product, easily detected by anomalies in process privileges. His described techniques, while still involving kernel modification, are more surgical: they alter specific bits within an existing token rather than wholesale replacement. This suggests that EDRs need to evolve beyond simple token integrity checks to detect subtle modifications to TokenFlags or attributes values within _TOKEN structures. Monitoring for direct kernel memory writes to these critical security-related fields could be a valuable defensive capability.

Thirdly, for organizations deploying App Container processes (e.g., using modern Metro apps or relying on Edge's sandboxing), this research demonstrates that even these advanced isolation mechanisms are not foolproof if the underlying kernel is compromised. Defenders should understand that the Runtime Broker and other App Container-specific checks can be circumvented through direct kernel object manipulation. This reinforces the need for strong integrity checks on the kernel itself and its critical data structures.

Finally, Spicer's observation that Microsoft is unlikely to patch these types of bypasses (as they assume kernel read/write is already a catastrophic failure) means defenders cannot rely on vendor patches for these specific issues. Instead, the focus must shift to proactive threat hunting for the underlying kernel-level read/write primitives, runtime integrity monitoring of critical kernel structures, and behavioral analysis that can detect the outcome of these bypasses (e.g., a sandboxed process suddenly gaining access to resources it shouldn't, even if its token appears superficially "normal"). Implementing Control Flow Integrity (CFI) and other memory safety mitigations at the kernel level can also make it harder for attackers to achieve the initial read/write primitives necessary for these types of token manipulations.

Key Takeaways

• Even with kernel read/write primitives ("god mode"), Windows' layered security, particularly restricted tokens and App Container processes, presents significant obstacles to privilege escalation.
• Directly swapping a process's token for a SYSTEM token is an easily detectable EDR red flag and not a viable stealth technique.
• Bypassing restricted token primary access checks involves using kernel read/write to change the attributes value of "deny only" SIDs (e.g., hex 10) to "enabled."
• The novel bypass for restricted token secondary access checks involves locating the TokenFlags field in the _TOKEN structure and flipping the TOKEN_IS_RESTRICTED bit (hex 10) off, effectively tricking the system into skipping these checks.
• App Container mitigations can also be bypassed by identifying and flipping a specific bit within the TokenFlags field, demonstrating a pattern in Windows' internal security flag mechanisms.
• ReactOS kernel source code proved to be an invaluable resource for understanding Windows internals and discovering critical implementation details like SeTokenIsRestricted.

About the Speaker(s)

James Spicer is a hacker at Trenchant, a cybersecurity company that focuses on challenging platforms and complex security problems. He presented his research on Windows privilege escalation and token manipulation at Kawaiicon. Spicer is active on Twitter under the handle _bluecreen, and his company, Trenchant, can be found at Trenchant_AR. His work exemplifies deep technical research into Windows internals and advanced post-exploitation techniques.