In August, I shared a blog on my most recent research project called Windows Downdate, which I first presented at Black Hat USA 2024 and DEF CON 32 (2024). In it, I explained how I was able to develop a tool to take over the Windows Update process to craft custom downgrades on critical OS components to expose previously fixed vulnerabilities. By using this downgrade ability, I discovered CVE-2024-21302, a privilege escalation vulnerability affecting the entire Windows virtualization stack. 

While CVE-2024-21302 was patched because it crossed a defined security boundary, the Windows Update takeover which was reported to Microsoft as well, has remained unpatched, as it did not cross a defined security boundary. Gaining kernel code execution as an Administrator is not considered as crossing a security boundary (not a vulnerability). That said, in recent years, significant enhancements have been implemented to strengthen the security of the kernel, even under the assumption that it could be compromised with Administrator privileges. These enhancements aim to make compromising the kernel more challenging, raising the bar for attackers. However, the ability to downgrade components that reside in the kernel makes things much simpler for attackers, unfortunately. One of the kernel’s security enhancements is the Driver Signature Enforcement (DSE) feature. In my follow-on research presented here, I will show how the Windows Update takeover capability still presents a significant threat to organizations by using it to revive the “ItsNotASecurityBoundary” DSE bypass. This bypass allows loading unsigned kernel drivers, enabling attackers to deploy custom rootkits that can neutralize security controls, hide processes and network activity, maintain stealth and much more.

Below, I’ll first provide a high-level overview of my original Windows Downdate research. Next, I will show how I was able to downgrade the “ItsNotASecurityBoundary” DSE bypass patch on a fully updated Windows 11 system, effectively bringing the bypass back to life. Finally, I will highlight the importance of monitoring and detecting downgrade procedures that—while not crossing defined security boundaries—still pose significant threats to organizations.

Windows Downdate Background

This is a background section of the original Windows Downdate publication, readers familiar with it can skip to the next section.

Downgrade attacks—also known as version-rollback attacks—are a type of attack designed to revert an immune, fully up-to-date software back to an older version. They allow malicious actors to expose and exploit previously fixed/patched vulnerabilities to compromise systems and gain unauthorized access. 

In 2023, for example, the BlackLotus UEFI Bootkit employed a downgrade attack. The malware downgraded the Windows boot manager to a version vulnerable to CVE-2022-21894 to bypass Secure Boot. BlackLotus was then able to disable other OS security mechanisms and gain persistence in impacted systems. The BlackLotus UEFI Bootkit sent shock waves through the cybersecurity community, as it was capable of running on fully patched and up-to-date Windows 11 systems with Secure Boot enabled. While Microsoft patched Secure Boot against downgrade attacks, I couldn’t help but wonder whether downgrade protection was added anywhere else in the Windows OS. 

So, I set out with a research goal of developing an undetectable downgrade flow for Microsoft Windows. The Windows Update process seemed like the least-suspicious entity through which I might execute such an attack. As I explored the intricacies of the Windows Update process, I discovered a flaw that allowed me to take full control of the update process. As a result, I was able to create Windows Downdate, a tool that implemented downgrading updates and bypassed all verification steps, including integrity verification and Trusted Installer enforcement.

Armed with these capabilities, I then managed to downgrade critical OS components, including dynamic link libraries (DLLs), drivers, and even the NT kernel. After these downgrades, the OS reported that it was fully updated and was unable to install future updates, while recovery and scanning tools were unable to detect issues. 

I then aimed higher and found that the entire virtualization stack was at risk as well. I successfully downgraded Credential Guard’s Isolated User Mode Process, Secure Kernel, and Hyper-V’s hypervisor to expose past privilege escalation vulnerabilities.

Finally, I discovered multiple ways to disable Windows virtualization-based security (VBS), including its features such as Credential Guard and Hypervisor-Protected Code integrity (HVCI), even when enforced with UEFI locks. To my knowledge, this is the first time VBS’s UEFI locks have been bypassed without physical access.

As a result, I was able to make a fully patched Windows machine susceptible to past vulnerabilities, turning fixed vulnerabilities unfixed and making the term “fully patched” meaningless on any Windows machine in the world.

In line with SafeBreach’s commitment to responsible disclosure, we notified Microsoft of our research findings in February 2024. Microsoft issued two CVEs—CVE-2024-21302 and CVE-2024-38202—and provided additional guidance via Security Update Guide ADV24216903. 

As noted above, CVE-2024-21302 was patched because it crossed a defined security boundary. The Windows Update takeover, however, was not since it did not cross a defined security boundary. In my follow-on research project, I set out to explore how I might revive the “ItsNotASecurityBoundary” DSE bypass using my Windows Downdate tool.

“ItsNotASecurityBoundary” Overview

The “ItsNotASecurityBoundary” DSE bypass belongs to a new class of flaws known as False File Immutability (FFI). This class exploits incorrect assumptions about file immutability — specifically, that blocking write access sharing makes a file immutable. However, these “immutable” files can still be modified by clearing the system’s working set, which triggers page faults when the file is accessed in memory, causing it to be re-read and potentially altered. The page fault handler, which doesn’t account for access sharing, allows such modifications, bypassing the assumed immutability.  

These double-read conditions inherently lead to a Time-of-Check to Time-of-Use (TOCTOU) race condition. In the case of the “ItsNotASecurityBoundary” DSE bypass, the double-read occurs with a security catalog. During the race window, an attacker can replace a verified catalog with a malicious version containing the authenticode for an unsigned kernel driver. Consequently, when the system parses the catalog, it recognizes the unsigned driver’s authenticode as valid, allowing the unsigned driver to be loaded.

This is just a brief overview of FFI and “ItsNotASecurityBoundary”; for a deeper understanding, refer to the original publication by Gabriel Landau from Elastic.

Reverting the Patch

When dealing with downgrade attacks, the key information we need to gather is the module where the patch we would like to revert was applied and the version of the module that contains the unpatched flaw. The patch is located in ci.dll, so this is the module we will try to downgrade. The unpatched version of the DLL is 10.0.22621.1376. Luckily for us, there are no additional dependencies. Downgrading only ci.dll to its unpatched version works well against a fully patched Windows 11 23h2 machine.

Demo

To see these capabilities in action, the following demo shows how I was able to revert the “ItsNotASecurityBoundary” DSE bypass patch to then exploit it against a fully patched Windows 11 23h2 machine.

What about Secure Kernel Code Integrity?

If Virtualization-Based Security (VBS) is running, the catalog parsing is deferred to the Secure Kernel Code Integrity DLL (skci.dll), which parses the catalog securely in contrast to ci.dll.

But how big of an obstacle is VBS? Could it be easily disabled? To answer these questions, we need to understand what modes VBS can be enabled in.

The enablement modes that concern us are the following: 

1. VBS without UEFI lock
2. VBS with UEFI lock
3. VBS with UEFI lock & “Mandatory” flag

Let’s explore the modes and understand whether we can circumvent them.

VBS without UEFI Lock

This mode is the default and does not add any additional protection on VBS. Thus, in this mode, VBS can be turned off by modifying a few registry keys. The registry keys to modify vary depending on whether VBS was manually enabled or left in its default state, as well as which VBS features are enabled. Generally, the following steps can be taken: 

1. Delete “EnableVirtualizationBasedSecurity” and “RequirePlatformSecurityFeatures” under HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard
2. Zero out the following:
   1. HKLM\SYSTEM\CurrentControlSet\Control\Lsa\LsaCfgFlags
   2. HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\CredentialGuard\Enabled
   3. HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity\Enabled
   4. HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\SystemGuard\Enabled

The exploitation steps are:

1. Turning off VBS in the registry.
2. Downgrading ci.dll to the unpatched version.
3. Restarting the machine.
4. Exploiting “ItsNotASecurityBoundary”.

VBS with UEFI Lock

This mode is enabled through either the Local Group Policy Editor or the registry. From the documentation, it appears that this mode ensures that VBS cannot be disabled remotely. In practice though, the UEFI lock alone only protects the VBS configuration from modification.

When this mode is first enabled, the VBS configuration is copied from the registry to a UEFI NV|BS variable named VbsPolicy. From that point onwards, the VBS configuration is taken from that UEFI variable only. In case the registry configuration does not align with the UEFI variable, the registry is overwritten with the variable’s configuration.

So, disabling VBS in the registry will not work in this case. With that said, the UEFI lock bypass I mentioned in my original publication can be used to disable VBS. Replacing one of VBS’s files (e.g., SecureKernel.exe) with invalid files will cause VBS to not load, regardless of the UEFI lock configuration protection.

The exploitation steps are:

1. Invalidating SecureKernel.exe.
2. Downgrading ci.dll to the unpatched version.
3. Restarting the machine.
4. Exploiting “ItsNotASecurityBoundary”.

VBS with UEFI Lock & “Mandatory” Flag

This mode is enabled through the registry. Apparently, there is a “Mandatory” flag, which causes boot failure if one of VBS’s files is corrupted. The flag is part of the VBS configuration of course and thus, if the lock is configured, the flag is represented in the VbsPolicy UEFI variable. 

I have not found a way around this. The VbsPolicy UEFI variable cannot be controlled without executing unsigned code during boot, and overwriting the “Mandatory” setting in the registry will have no effect since configuration is taken from the UEFI variable. 

That being said, the “Mandatory” flag isn’t automatically set when the UEFI lock is enabled; it has to be set manually. Furthermore, it was only officially documented in September 2024, following my findings. Because of this, I expect that very few machines have this flag enabled.

Mitigation

To fully mitigate the attack, VBS needs to be enabled with UEFI lock and the “Mandatory” flag. Otherwise, it would be possible for an attacker to disable VBS, downgrade ci.dll, and successfully exploit the flaw. 

The UEFI lock can be enabled using the following command:

The “Mandatory” flag can be enabled using the following command: 

After the UEFI lock is enabled and the “Mandatory” flag added, the machine must be restarted in order for the configuration change to be respected. 

NOTE: If the UEFI lock is already configured, the VBS configuration cannot be modified. The lock must first be deleted by using SecConfig.efi, the flag set, and then the lock re-enabled.

Keep in mind that special caution should be taken when using the “Mandatory” flag. Official Microsoft documentation about this flag can be found here.

Windows Downdate Usage Example

The usage example of downgrading the “ItsNotASecurityBoundary” DSE bypass patch can be found here.

Conclusion

This research set out to explore how Windows downgrade attacks could bring a patched DSE bypass back to life. Unlike traditional Administrator-to-Kernel attacks that rely on third-party drivers in a bring-your-own-vulnerable-driver (BYOVD)-style exploit, downgrade attacks offer more flexibility by allowing the downgrade of first-party components, including the OS kernel itself.

While significant enhancements have been made to strengthen kernel security against compromise by Administrator privileges, the ability to downgrade kernel components unfortunately makes compromising the kernel much simpler. Thus, it remains crucial for endpoint security solutions to monitor and detect downgrade procedures, even those that do not cross defined security boundaries.

For more in-depth information about this research, please: 

• Contact your customer success representative if you are a current SafeBreach customer
• Schedule a one-on-one discussion with a SafeBreach expert
• Contact Kesselring PR for media inquiries 

Credits

I would like to give credit to Gabriel Landau for his work on the “ItsNotASecurityBoundary” DSE bypass. 

About the Researcher

Alon Leviev (@_0xDeku) is self-taught security researcher with a diverse background. Alon started his professional career as a blue team operator, where he focused on the defensive side of cyber security. As his passion grew towards research, Alon joined SafeBreach as a security researcher. His main focus included operating system internals, reverse engineering, and vulnerability research. Alon has spoken at various security conferences like DEFCON 32, Black Hat USA 2024, Black Hat Europe 2023, CanSecWest 2024, and CONFidence 2024. Before joining the cyber security field, Alon was a professional Brazilian jiu-jitsu athlete, where he won several world and European titles.