Windows Downdate: Downgrade Attacks Using Windows Updates

Windows Downdate: Downgrade Attacks Using Windows Updates

Speakers: Alon Leviev

Conference: DEF CON 32

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

Overview

In this compelling DEF CON 32 presentation, security researcher Alon Leviev unveiled a novel and deeply concerning class of downgrade attacks targeting the very core of Windows' security mechanisms: its update system. Titled "Windows Downdate," the talk meticulously details how an attacker, with administrator privileges, can weaponize Windows Updates to revert critical system components to old, vulnerable versions, all while remaining completely undetected by conventional security tools. This research fundamentally challenges existing assumptions about Windows' platform security, demonstrating that the process designed to keep systems secure can be repurposed to introduce severe vulnerabilities.

Leviev, a self-taught security researcher at SafeReach, embarked on this journey inspired by the sophisticated tactics of the Black Lotus UEFI bootkit. His work expands upon the concept of "bring your own vulnerable driver" attacks, elevating it to a "bring your own vulnerable Windows" paradigm by targeting first-party entities, including components operating at a lower level than the kernel, and even those protected by advanced security features like Virtualization-Based Security (VBS). The implications are profound, suggesting a pathway for attackers to bypass modern Windows security mitigations by exploiting a trusted, legitimate system process.

The talk not only dissects the intricate flaws within the Windows Update architecture that enable such attacks but also presents a practical proof-of-concept. Leviev demonstrates how a vulnerable kernel driver (afd.sys) can be "downdated" to an exploitable version, leading to successful privilege escalation to NT AUTHORITY\SYSTEM. This research underscores a critical oversight in how system integrity is maintained and validated, revealing that even components assumed to be secure post-verification can be tampered with, paving the way for persistent, invisible, and irreversible compromise.

Background

▶ Watch: Introduction to downgrade attacks and speaker (0:00)

The concept of a downgrade attack is not new to the cybersecurity landscape. It refers to the malicious act of reverting a fully updated software component to an older, known-vulnerable version. This technique allows attackers to bypass patches and exploit existing, previously fixed vulnerabilities, effectively nullifying the efforts of vendors to secure their products. A prominent example that catalyzed Leviev's research was the Black Lotus UEFI bootkit. This sophisticated threat garnered significant attention for its ability to bypass Secure Boot on fully updated Windows 11 systems. Crucially, Black Lotus did not rely on a zero-day vulnerability; instead, it achieved its objective by downgrading the Windows boot manager to a signed but vulnerable iteration. Once the vulnerable boot manager was in place, an exploit targeting its known flaws could then successfully bypass Secure Boot, demonstrating the potent impact of such attacks.

Microsoft's response to the Black Lotus incident and similar secure boot downgrades involved implementing mitigations, primarily the revocation of vulnerable boot managers and boot applications. Revoked images are explicitly prevented from loading, theoretically closing this specific attack vector. However, Leviev's research posed a critical question: are there other components, beyond the secure boot chain, that might be susceptible to similar downgrade attacks, and have they been overlooked?

Inspired by the success of Black Lotus and the prevalence of "bring your own vulnerable driver" attacks that typically target third-party drivers, Leviev set an ambitious goal. He aimed to evaluate the broader state of downgrade attacks on Windows, specifically seeking to target first-party entities—core Windows components, not just drivers, and even those residing at a lower level than the kernel. His vision was to establish a new category of attack: "bring your own vulnerable Windows." To achieve this, he first defined the characteristics of a "perfect downgrade attack," which would serve as the benchmark for his research:

1. Fully Undetectable: The downgrade must be performed in the most legitimate way possible, avoiding actions that would trigger alerts from Endpoint Detection and Response (EDR) solutions.
2. Invisible: The downgraded components should still appear up-to-date to the system, even though they are technically running an older version.
3. Persistent: Future software updates should not overwrite or repair the downgraded components, ensuring the vulnerability remains active.
4. Irreversible: Scanning and repairing tools should be unable to detect or remediate the corruptions introduced by the downgrade.

With these stringent requirements in mind, Leviev embarked on identifying a suitable target component within Windows. His ultimate choice, and perhaps the least expected one, was the Windows Update mechanism itself. The irony of using the system designed for security to introduce vulnerabilities became the central theme of his groundbreaking findings.

Key Findings

▶ Watch: Defining the research goal: "Bring Your Own Vulnerable Windows" (2:20)

Alon Leviev's research uncovered a critical design flaw and several implementation weaknesses within the Windows Update architecture that enable a sophisticated, multi-faceted downgrade attack. The primary discovery is that Windows Updates can be completely taken over by an attacker with administrative privileges to perform undetectable, invisible, persistent, and irreversible downgrades of critical system components. This transforms a trusted security mechanism into a powerful vector for compromise, fulfilling all criteria for a "perfect downgrade attack."

The initial design problem identified lies in the security boundary, or lack thereof, between an Administrator and the Trusted Installer account. While Windows Update attempts to secure system files by making them exclusively modifiable by Trusted Installer, preventing even administrators or NT AUTHORITY\SYSTEM from direct manipulation, this protection is largely rendered ineffective. As Leviev highlights, the transition from Administrator to Trusted Installer is not considered a security boundary in Windows, and numerous public Proof-of-Concepts (PoCs) demonstrate how an administrator can elevate privileges to Trusted Installer. While such direct elevation is often flagged as malicious by EDRs, contradicting the "undetectable" principle, this observation laid the groundwork for finding a more subtle bypass.

The pivotal finding, however, revolved around the action list used by Windows Update, specifically the pending.xml file, which dictates the update actions to be performed during a system reboot. While pending.xml itself is stored in a server-controlled folder inaccessible to the client, Leviev discovered a critical vulnerability in how this action list is processed. He found a specific registry key, PQexcmdline, which holds the executable path for the parser responsible for processing the pending.xml list. Crucially, this PQexcmdline registry key is not Trusted Installer enforced. This means an administrator can modify this key to point to a custom, malicious action list or, more powerfully, to a custom parser.

This discovery is the lynchpin of the attack:

• Bypassed Integrity Verifications: Since the action list is assumed to be verified post-creation by the legitimate Windows Update server, modifying the PQexcmdline key allows an attacker to inject a custom action list after all integrity checks have theoretically occurred. Windows Update then, unknowingly, executes the attacker's commands during the next reboot.
• No Malicious Elevation Needed: The attacker doesn't need to perform an overt Administrator-to-Trusted Installer elevation that EDRs might detect. Instead, Windows Update itself, operating under its legitimate Trusted Installer context, performs the malicious downgrade, making the attack inherently undetectable. This constitutes a "complete Windows Update takeover."

Beyond the core downgrade mechanism, Leviev addressed the persistence and irreversibility requirements:

• Persistence: He found that the action list parser itself is not digitally signed. This enabled him to patch the legitimate parser to install "empty updates." Consequently, even when new, legitimate updates become available, the patched parser will falsely report them as installed, preventing the system from ever truly updating the downgraded components.
• Irreversibility: Similarly, the integrity and repair utility (e.g., sfc.exe or related components) is also not digitally signed. This allowed him to patch this utility as part of the downgrade process. The modified repair utility would then no longer detect any corruptions, effectively rendering the downgrade irreversible by standard system tools.

In summary, the key findings reveal a profound vulnerability where the trusted Windows Update mechanism, through the manipulation of the PQexcmdline registry key and the patching of unsigned update and repair utilities, can be weaponized to achieve fully undetectable, invisible, persistent, and irreversible system downgrades.

Technical Deep Dive

▶ Watch: Unveiling Windows Updates as the attack target (3:50)

The technical foundation of the "Windows Downdate" attack exploits several intricate details of the Windows Update architecture and its security assumptions. Leviev began by dissecting the standard Windows Update architecture, which consists of an update client and an update server communicating via COM (Component Object Model), an interprocess communication method in Windows. A key observation is that while administrative privileges are typically required on the client side to initiate updates, the server side—which handles the actual modification of system files—operates under the highly privileged Trusted Installer account. Crucially, system files, once owned and updated by Windows Updates, are only accessible to Trusted Installer, theoretically preventing even administrators from direct modification.

However, Leviev quickly identified a critical flaw in this design: the assumption that Administrator to Trusted Installer is not considered a security boundary. This means that while direct elevation from an administrator to Trusted Installer is possible (and often blocked by EDRs as malicious), the system inherently trusts that processes running under Trusted Installer are legitimate. This trust forms the basis of the entire attack.

To understand how the attack bypasses integrity checks, it's essential to trace the simplified flow of the Windows Update process:

1. Client Request: The client asks the server to perform an update, providing an update folder containing the necessary files.
2. Integrity Validation: The server validates the integrity of the provided update folder.
3. File Finalization: Following validation, the server operates on the update folder to finalize the update files. These files are then saved to a server-controlled folder, which is inaccessible to the client. At this point, the client cannot directly modify the finalized update files.
4. Action List Creation: The server then saves an action list, named pending.xml, to another server-controlled folder. This pending.xml contains the specific update actions, such as which files to update, their source and destination paths, and which installers to execute.
5. Reboot Execution: Finally, upon the next operating system reboot, the pending.xml action list is parsed and its specified update actions are performed.

Leviev initially investigated the integrity checks performed on the client-supplied update folder. This folder contains various components:

• MUM files (Microsoft Update Metadata): Contain metadata like component dependencies and installation order.
• Manifest files: Specify installation data, file paths, registry keys, and installers to execute.
• Differential files: Represent deltas from base files, which are combined with base files to form the full final update file.
• Catalog files: These are the digital signatures for the MUM and manifest files. They allow signing multiple files simultaneously and are themselves digitally signed, making their modification impossible without invalidating the signature.

A critical observation was that while differential files control the final update file content and are not explicitly signed, their integrity is indirectly protected. The expected hash of the final update file is hardcoded within the manifest file. Since the manifest file is signed by the catalog, any alteration to the differential file that would result in a different final hash would break the manifest's signature, thus failing the integrity check. This path, therefore, proved to be a dead end for direct manipulation.

The breakthrough came when Leviev turned his attention to the pending.xml action list. While the action list itself is stored in a Trusted Installer-enforced location (meaning an administrator cannot directly modify it), he hypothesized that its state or processing mechanism might be vulnerable. He searched the registry for paths related to the action list and discovered the PQexcmdline key. This key is located within the registry and specifically holds the path to the executable responsible for parsing the pending.xml list, along with the path to the list itself.

The crucial vulnerability: the **PQexcmdline registry key's security attributes revealed it was not Trusted Installer enforced.** This meant an administrator could modify its value. By changing PQexcmdline, an attacker could:

1. Point to a custom pending.xml: The attacker could craft their own pending.xml file, specifying a downgrade of a system component, and then modify PQexcmdline to point to this malicious file.
2. Point to a custom parser: Even more powerfully, the attacker could modify PQexcmdline to point to a custom executable that mimics the legitimate action list parser but executes arbitrary code or a pre-defined malicious action list.

This direct modification of PQexcmdline effectively bypasses all integrity verifications. The Windows Update process, when it reboots, assumes the pending.xml (or whatever PQexcmdline points to) has already been verified by the legitimate server. Consequently, it executes the instructions within, leading to a complete Windows Update takeover. The system, operating under Trusted Installer privileges during boot, then performs the attacker-defined downgrade.

To ensure the downgrade was persistent and irreversible, Leviev identified two more critical components that were not digitally signed:

• The action list parser executable itself. By patching this executable, he could modify its behavior to install "empty updates," effectively preventing legitimate future updates from overwriting the downgraded components.
• The integrity and repair utility (e.g., sfc.exe or related components). By patching this utility, he could ensure that it would no longer detect any corruptions introduced by the downgrade, making the attack virtually invisible to standard system repair mechanisms.

In essence, the attack leverages a series of trust assumptions and missing integrity checks: trust in the PQexcmdline key's integrity, trust in the pending.xml's origin post-creation, and the lack of digital signatures on critical executables involved in the update and repair processes. This allows an attacker to subvert the entire update pipeline, turning it into a tool for system compromise.

Demo / Proof of Concept

▶ Watch: Windows Update design flaw: Admin to Trusted Installer (4:30)

Alon Leviev's talk included a live demonstration of the "Windows Downdate" attack, showcasing its practical efficacy in achieving privilege escalation by downgrading a critical kernel driver. The demonstration focused on targeting the afd.sys kernel driver, a component of the Ancillary Function Driver for WinSock.

The demo began by establishing the baseline state of the target machine:

• The system was running a fully updated version of Windows, with no pending updates.
• Using the sigcheck utility, the current version of afd.sys was confirmed to be version 3672, which was patched against the specific vulnerability Leviev intended to exploit.
• An attempt to execute a known Local Privilege Escalation (LPE) exploit targeting afd.sys was made. As expected, given the patched driver version, the exploit failed, confirming the system's security posture.

Next, Leviev initiated the "Windows Downdate" attack. He executed a custom tool, also named "Windows Downdate," which took a configuration file as input. This configuration file specified the target driver (afd.sys) and instructed the tool to downgrade it to an old, vulnerable version. The tool successfully manipulated the PQexcmdline registry key and set up the necessary components for the downgrade.

Following the successful setup, the system required a restart for the "update" (which was actually a downgrade) to take effect. After the machine rebooted and Leviev logged back in, he proceeded to verify the outcome:

• He again used sigcheck to inspect the version of afd.sys. This time, the utility reported that the driver had been reverted to its base (vulnerable) version, despite the system having just "updated." This visibly confirmed the successful downgrade.
• Crucially, the system still appeared to be fully up-to-date in the Windows Update settings, demonstrating the "invisibility" principle of the attack.
• Finally, the LPE exploit targeting afd.sys was re-executed. This time, the exploit succeeded, elevating the command prompt to NT AUTHORITY\SYSTEM. This unequivocally proved that the downgrade had introduced the vulnerability and allowed for full system compromise.

The demonstration underscored several critical implications:

• Bypass of UEFI Locks and Defeat of VBS: Leviev mentioned that this approach could bypass UEFI locks (similar to Black Lotus) and, more significantly, "defeat VBS." Virtualization-Based Security (VBS) is a core Windows security feature that uses hardware virtualization to create isolated memory regions (Virtual Trust Levels, VTLs). In Windows, VTL0 (normal mode) contains the original OS, while VTL1 (secure mode) hosts critical security features and mitigations, along with key isolation technologies. The fundamental security boundary of VBS dictates that no VTL0 code, even the kernel, should be able to access or compromise higher VTLs. By achieving NT AUTHORITY\SYSTEM on the VTL0 kernel through a downgraded driver, this attack lays the groundwork for potential VBS compromise, as the integrity of the VTL0 kernel, which VBS relies on, has been subverted. While the demo itself showed LPE, the broader implication is that if a component critical to VBS operation (residing in VTL0) can be downgraded, VBS's protections could be severely weakened or bypassed.

The demo conclusively validated the feasibility and impact of Leviev's "Windows Downdate" attack, showcasing how a legitimate system process can be weaponized to achieve deep system compromise with high stealth and persistence.

Defensive Implications

▶ Watch: Analysis of update folder integrity checks and file types (6:40)

Alon Leviev's "Windows Downdate" research presents a significant challenge for defenders, as it leverages trusted system mechanisms to achieve compromise. The inherent stealth and persistence of this attack mean that traditional EDRs, which often focus on detecting known malicious processes or suspicious privilege elevations, are unlikely to flag the initial downgrade activity. Since Windows Update itself is performing the malicious actions, it appears legitimate to most monitoring tools.

Here are the critical defensive implications and recommended actions:

1. Monitor the PQexcmdline Registry Key: This is the single most critical point of vulnerability. Defenders must implement robust monitoring for any unauthorized modifications to the PQexcmdline registry key. Any change to its value, especially if it points to an unusual path or executable, should trigger an immediate high-priority alert. This key is located within the Windows Update-related registry paths.
2. Harden PQexcmdline Permissions: Microsoft should consider hardening the permissions on the PQexcmdline registry key, ideally restricting write access to only the Trusted Installer account. While this might require careful implementation to avoid breaking legitimate update processes, it would significantly raise the bar for attackers.
3. Implement Stronger Integrity Checks on Update and Repair Executables: The fact that the action list parser and the integrity/repair utility are not digitally signed is a severe oversight. Microsoft should implement digital signing for these critical executables. Defenders should also maintain a baseline of these executables and monitor for any unauthorized modifications or hash mismatches. External, trusted integrity checkers (e.g., from an immutable boot environment or a separate, secured system) would be necessary to detect a patched local repair utility.
4. Rethink Administrator to Trusted Installer as a Non-Security Boundary: This research highlights that the assumption of Administrator-to-Trusted Installer not being a security boundary has critical implications when Trusted Installer is used to manage core system integrity. A re-evaluation of this assumption, particularly in the context of sensitive operations like system updates, is warranted.
5. Enhanced Monitoring of Update Processes: Beyond PQexcmdline, organizations should enhance their monitoring of the entire Windows Update process. This includes tracking the creation and modification of pending.xml (even though it's in a controlled folder, anomalous access patterns or unexpected content might be visible), and observing unusual system reboots followed by unexpected changes to critical system file versions.
6. Secure Boot and VBS Integrity: While the attack primarily targets the VTL0 kernel, the potential to "defeat VBS" means that defenders cannot solely rely on these hardware-backed security features if the underlying operating system components they protect can be silently downgraded. Continuous integrity verification of core boot chain components and critical VTL0 kernel drivers, perhaps through attestation mechanisms, becomes even more important.
7. Supply Chain Security for Updates: The attack leverages the legitimate update mechanism. This underscores the need for robust supply chain security for all software updates. While this attack doesn't involve malicious updates from Microsoft, it shows how the update mechanism itself can be co-opted.
8. Regular and Independent System Integrity Scans: Since the attack can patch local integrity repair tools, relying solely on built-in Windows tools for integrity checks after a suspected compromise might be insufficient. Implementing regular, independent system integrity scans using trusted, external tools or by booting into a secure recovery environment is crucial.

In summary, the "Windows Downdate" attack necessitates a shift in defensive strategies, moving beyond signature-based detection and focusing on comprehensive integrity monitoring, hardening critical configuration points, and re-evaluating security boundaries within the operating system.

Key Takeaways

• Windows Update is a Critical Attack Vector: The research demonstrates that the Windows Update mechanism, designed for security, can be weaponized to perform undetectable, invisible, persistent, and irreversible downgrade attacks on critical system components.
• PQexcmdline is the Linchpin: The PQexcmdline registry key, which controls the execution of the update action list, is not Trusted Installer enforced. This allows an attacker with administrative privileges to hijack the entire Windows Update process.
• Administrator to Trusted Installer Trust Model is Flawed: The assumption that Administrator-to-Trusted Installer is not a security boundary enables attackers to leverage the highly privileged Trusted Installer context for malicious purposes without triggering typical EDR alerts.
• Bypassing Modern Security Features: The attack can bypass Secure Boot mitigations and has the potential to defeat Virtualization-Based Security (VBS) by subverting the integrity of the VTL0 kernel.
• Unsigned Executables are a Weakness: The lack of digital signatures on the action list parser and the integrity/repair utility allows attackers to patch these executables, ensuring persistence and preventing detection/remediation.
• Defenders Need Enhanced Monitoring: Organizations must implement robust monitoring for unauthorized modifications to the PQexcmdline registry key and enhance integrity checks on critical update-related executables, moving beyond conventional EDR solutions.

About the Speaker(s)

Alon Leviev is a security researcher at SafeReach. At 23 years old, he is primarily self-taught, with a strong focus on operating system internals, reverse engineering, and vulnerability research. Before dedicating his career to cybersecurity, Alon was a professional Brazilian Jiu-Jitsu athlete, where he achieved notable success by winning several world and European titles. His background in disciplined and strategic combat appears to translate effectively into his methodical and persistent approach to uncovering complex system vulnerabilities.