CVE-2024-21302

NT Kernel -- secure kernel version downgrade bypass via unvalidated version state

Summary

Field	Value
Driver	ntoskrnl.exe
Vulnerability Class	State Hardening
Vulnerable Build	10.0.22621.3958 (KB5040527)
Fixed Build	10.0.22621.4169 (KB5043076)
Exploited ITW	No

Affected Functions

• VslCheckVersion
• SepValidateSecureKernelVersion

Root Cause

Windows Virtualization-Based Security (VBS) is supposed to create an immutable trust boundary: once the secure kernel boots, the normal kernel should not be able to downgrade VBS-protected components to older, potentially vulnerable versions. This is enforced through version checks in VslCheckVersion and SepValidateSecureKernelVersion, which validate that loaded kernel components meet a minimum version threshold.

SafeBreach researcher Alon Leviev discovered that these version checks did not properly validate the version state used for comparison. The version information was stored in a location or format that an administrator-privileged process could manipulate through the Windows Update servicing stack. By interfering with the version state before the check runs, an attacker could make VslCheckVersion accept a downgraded binary as meeting the version requirement.

The practical impact is devastating: an attacker with admin privileges can replace patched kernel binaries (ntoskrnl.exe, securekernel.exe, skci.dll) with older, validly-signed versions that contain known vulnerabilities. After a reboot, the system runs the downgraded binaries. Windows Update reports the system as fully patched because the servicing stack's own state was manipulated, but the actual running kernel has been rolled back to a version containing exploitable bugs like CVE-2024-21338.

This technique was dubbed "Windows Downdate" by SafeBreach.

AutoPiff categorizes this as state_hardening with detection rules:

• interlocked_refcount_added

Exploitation

The attack requires administrator privileges and proceeds through the Windows Update servicing stack. The attacker manipulates the component store and version state to replace current kernel binaries with older, validly-signed copies. These older binaries pass Authenticode and code integrity checks because they carry legitimate Microsoft signatures. The manipulated version state causes VslCheckVersion to accept them as meeting the minimum version requirement.

After a reboot, the system runs the downgraded kernel. The attacker then exploits a known vulnerability in the rolled-back binary. For example, rolling back to a version vulnerable to CVE-2024-21338 (the AppLocker IOCTL admin-to-kernel bug) provides a direct kernel read/write primitive, which was used by Lazarus Group in the wild.

The attack chain is: admin -> downgrade kernel -> reboot -> exploit known kernel bug -> kernel code execution. The downgrade itself is invisible to Windows Update and standard patch-level queries, making it a potent persistence mechanism.

Patch Analysis

The fix in KB5043076 hardens the version validation logic in VslCheckVersion and SepValidateSecureKernelVersion. The version state is now stored and compared using interlocked operations that prevent tampering between the state read and the version comparison. The servicing stack's version records are also validated for consistency with the actual loaded binary versions.

AutoPiff detects this via the interlocked_refcount_added rule, which flags the introduction of atomic operations around state values that were previously read without synchronization.

Detection

YARA Rule

rule CVE_2024_21302_ntoskrnl {
    meta:
        description = "Detects vulnerable version of ntoskrnl.exe (pre-patch)"
        cve = "CVE-2024-21302"
        author = "KernelSight"
        severity = "high"
    strings:
        $mz = { 4D 5A }
        $driver_name = "ntoskrnl.exe" wide ascii nocase
        $version = "10.0.22621.3958" wide ascii
        $vsl_check = "VslCheckVersion" ascii
        $sep_validate = "SepValidateSecureKernelVersion" ascii
    condition:
        $mz at 0 and $driver_name and $version and ($vsl_check or $sep_validate)
}

ETW Indicators

Provider	Event / Signal	Relevance
Microsoft-Windows-Security-Auditing	Event 4688 -- Process creation	Execution of Windows Update tools or binaries that initiate the downgrade flow
Microsoft-Windows-Kernel-Audit	Secure kernel version validation events	Calls to VslCheckVersion and SepValidateSecureKernelVersion with version state inconsistencies
Microsoft-Windows-Security-Auditing	Event 4672 -- Special privileges assigned	Acquisition of SeRestorePrivilege, SeTakeOwnershipPrivilege, or other privileges needed to replace protected system files
Microsoft-Windows-CodeIntegrity	Code integrity validation events	Loading of older, validly-signed but vulnerable kernel binaries after rollback
Microsoft-Windows-Kernel-Process	Secure kernel module load events	Secure kernel or VBS components loaded with version numbers predating the current patch level

Behavioral Indicators

• Admin-privileged process manipulates the Windows Update servicing stack or component store to replace patched system binaries (ntoskrnl.exe, securekernel.exe, skci.dll) with older, validly-signed versions, bypassing VBS version enforcement
• VslCheckVersion accepts a downgraded version number because the version state was not properly validated or atomically compared, allowing the secure kernel to load a rolled-back binary
• System files in %SystemRoot%\System32 replaced with older versions that still carry valid Authenticode signatures, passing code integrity checks
• After reboot, the system runs older kernel binaries that reintroduce previously patched vulnerabilities (e.g. CVE-2024-21338 or other kernel EoP bugs)
• Windows Update reports the system as fully patched while kernel and secure kernel components have been downgraded

Broader Significance

CVE-2024-21302 challenges a fundamental assumption in Windows security: that patching is a one-way ratchet. The entire VBS and Credential Guard architecture depends on the guarantee that an attacker cannot roll back security-critical components. Windows Downdate shows that with admin privileges and a flaw in the version checking logic, that guarantee collapses. The attack is particularly dangerous because it is invisible to patch management tools and turns the entire CVE history of the Windows kernel into a menu of exploitable bugs. It also highlights that VBS is not a silver bullet: if the version enforcement that protects VBS itself is flawed, the entire trust chain unravels.

References

• MSRC Advisory
• Writeup
• PoC