Update: Microsoft has issued detailed guidance on how to fix it.
Microsoft puts in several guards to make Windows as secure as it can. It pushes monthly Patch Tuesday updates which, as the name suggests, are meant to patch security flaws. Not just Windows, Microsoft also made Secure Boot a mandatory requirement on Windows 11 to ensure, as best as possible, secure firmware updates.
However, despite all these measures, threat actors and cybercriminals are always on the prowl to find ways to bypass them. In March of last year, the BlackLotus UEFI Secure Boot vulnerability, which has since been patched, surfaced that could bypass Secure Boot, VBS (Virtualization-based Security), HVCI (Hypervisor-Protected Code Integrity), and more, on fully updated systems.
A security researcher Alon Leviev decided to test whether similar protections against such downgrade attacks were put in place for the Windows Update process. Unfortunately for Microsoft and Windows users, Leviev found that such was not the case at all.
As such, Leviev developed Windows Downdate, a "tool to take over the Windows Update process to craft fully undetectable, invisible, persistent, and irreversible downgrades on critical OS components" including the DLLs, drivers, and even the Windows kernel.
Using this, the researcher demonstrated, at Black Hat and DEF CON, how even after a downgrade attack, Windows would report that it was fully updated and was unable to install future updates; and recovery tools were unable to detect any issues.
This essentially leaves the user of such a compromised PC clueless about what is happening, although the bright spot is that this is a local attack which means the threat actor would need physical access to your system.
In the video below, the Ancillary Function kernel driver (AFD.SYS) is downgraded to an older version on a Windows 11 23H2 system.
Anton Leviev has provided a summary of how Windows Downdate worked:
First, the downgrade must be fully undetectable, so that endpoint detection and response (EDR) solutions cannot block the downgrade. Thus, I aimed to perform the downgrade in the most legitimate way possible.
Second, the downgrade must be invisible. The downgraded components should appear up-to-date, even if they have technically been downgraded.
Third, the downgrade must be persistent, so that future software updates do not overwrite it.
Finally, the downgrade must be irreversible, so that scanning and repairing tools will not be able to detect or repair the downgrade.
You can find more technical details about it at the source links below.
In a bit of good news, Microsoft was notified about this vulnerability before the public demonstration and the company is tracking the flaw under IDs "CVE-2024-21302" and "CVE-2024-38202" on its MSRC website.
Source: SafeBreach, DEF CON, Black Hat