{
	"id": "3974fcbe-0580-4a82-9eaf-61fb1d71e1f5",
	"created_at": "2026-04-06T01:32:26.004753Z",
	"updated_at": "2026-04-10T03:20:24.954307Z",
	"deleted_at": null,
	"sha1_hash": "f3c8bcb422d61b692f438271a0ebb8da8b15830b",
	"title": "Downgrade Attacks Using Windows Updates | SafeBreach",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 3109367,
	"plain_text": "Downgrade Attacks Using Windows Updates | SafeBreach\r\nBy Author:  Alon Leviev\r\nArchived: 2026-04-06 01:19:17 UTC\r\nDowngrade 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\r\nvulnerabilities to compromise systems and gain unauthorized access. \r\nIn 2023, for example, the BlackLotus UEFI Bootkit employed a downgrade attack. The malware downgraded the Windows\r\nboot manager to a version vulnerable to CVE-2022-21894 to bypass Secure Boot. BlackLotus was then able to disable other\r\nOS security mechanisms and gain persistence in impacted systems. The BlackLotus UEFI Bootkit sent shock waves through\r\nthe cybersecurity community, as it was capable of running on fully patched and up-to-date Windows 11 systems with Secure\r\nBoot enabled. While Microsoft patched Secure Boot extensively against downgrade attacks, I couldn’t help but wonder\r\nwhether downgrade protection was added anywhere else in the Windows OS. \r\nMy most recent research project—which I first presented at Black Hat USA 2024 and DEF CON 32 (2024)—set out to\r\nexplore the state of downgrade attacks on Windows. I found several vulnerabilities that I used to develop Windows\r\nDowndate—a tool to take over the Windows Update process to craft fully undetectable, invisible, persistent, and irreversible\r\ndowngrades on critical OS components—that allowed me to elevate privileges and bypass security features. As a result, I\r\nwas able to make a fully patched Windows machine susceptible to thousands of past vulnerabilities, turning fixed\r\nvulnerabilities into zero-days and making the term “fully patched” meaningless on any Windows machine in the world.\r\nBelow, I’ll first provide a high-level overview of the key findings and takeaways from this research. Next, I’ll provide some\r\nbackground information about the Windows Update architecture. Then, I will dive into the research process that led me to\r\ndevelop the Windows Downdate downgrade flow. I will also explain how I was able to downgrade key OS components,\r\nbypass Windows Virtualization-Based Security (VBS) UEFI locks, and expose past elevation-of-privilege vulnerabilities in\r\nthe virtualization stack. Finally, I will highlight the vendor response and explain how we are sharing this information with\r\nthe broader security community to help organizations protect themselves.\r\nOverview\r\nKey Findings\r\nWith a research goal of developing an undetectable downgrade flow for Microsoft Windows, the Windows Update process\r\nseemed like the least-suspicious entity through which I might execute such an attack. As I explored the intricacies of the\r\nWindows Update process, I discovered a significant flaw that allowed me to take full control of the process. As a result, I\r\nwas able to create Windows Downdate, a tool that implemented downgrading updates and bypassed all verification steps,\r\nincluding integrity verification and Trusted Installer enforcement.\r\nArmed with these capabilities, I then managed to downgrade critical OS components, including dynamic link libraries\r\n(DLLs), drivers, and even the NT kernel. After these downgrades, the OS reported that it was fully updated and was unable\r\nto install future updates, while recovery and scanning tools were unable to detect issues. \r\nI then aimed higher and found that the entire virtualization stack was at risk as well. I successfully downgraded Credential\r\nGuard’s Isolated User Mode Process, Secure Kernel, and Hyper-V’s hypervisor to expose past privilege escalation\r\nvulnerabilities.\r\nFinally, I discovered multiple ways to disable Windows virtualization-based security (VBS), including its features such as\r\nCredential Guard and Hypervisor-Protected Code integrity (HVCI), even when enforced with UEFI locks. To my\r\nknowledge, this is the first time VBS’s UEFI locks have been bypassed without physical access.\r\nAs a result, I was able to make a fully patched Windows machine susceptible to thousands of past vulnerabilities, turning\r\nfixed vulnerabilities into zero-days and making the term “fully patched” meaningless on any Windows machine in the world.\r\nTakeaways\r\nThe implications of this research are significant not only to Microsoft Windows—which is the world’s most widely used\r\ndesktop OS—but also to other OS vendors that may potentially be susceptible to downgrade attacks. We believe the findings\r\nsuggest several important takeaways:\r\nThere is a need for increased awareness of and research into OS-based downgrade attacks. During this process, I\r\nfound no mitigations preventing the downgrade of critical OS components in Microsoft Windows. We believe other\r\nOSs may be equally susceptible to similar attack vectors and that all OS vendors must be vigilant against the dangers\r\nthey pose. \r\nhttps://www.safebreach.com/blog/downgrade-attacks-using-windows-updates/\r\nPage 1 of 14\n\nDesign features within an OS should always be reviewed and regarded as a relevant attack surface, regardless of how\r\nold the feature may be. The downgrade attack I was able to achieve on the virtualization stack within Windows was\r\npossible due to a design flaw that permitted less privileged virtual trust levels/rings to update components residing in\r\nmore privileged virtual trust levels/rings. This was very surprising, given Microsoft’s VBS features were announced\r\nin 2015, meaning the downgrade attack surface I discovered has existed for almost a decade. While VBS has become\r\na more popular topic among security researchers in recent years and several great research papers have been\r\npublished, more research specifically focused on the design of the virtualization stack is needed.\r\nWe believe in-the-wild attacks should be thoroughly examined and expanded upon by researchers whenever possible.\r\nThe BlackLotus UEFI Bootkit brought the concept of downgrade attacks to the cybersecurity community’s attention.\r\nThankfully with this research, we were able to expand on this type of attack before malicious actors did. However,\r\nthis is not always guaranteed, emphasizing the importance of studying in-the-wild attacks and using them to consider\r\nother components or areas that could also be affected.\r\nThe Research Process\r\nTo kick off my research, I needed to define what the success criteria would be for a “perfect” downgrade attack: \r\nFirst, the downgrade must be fully undetectable, so that endpoint detection and response (EDR) solutions cannot\r\nblock the downgrade. Thus, I aimed to perform the downgrade in the most legitimate way possible.\r\nSecond, the downgrade must be invisible. The downgraded components should appear up-to-date, even if they have\r\ntechnically been downgraded. \r\nThird, the downgrade must be persistent, so that future software updates do not overwrite it.\r\nFinally, the downgrade must be irreversible, so that scanning and repairing tools will not be able to detect or repair\r\nthe downgrade.\r\nWith the downgrade requirements well-defined, I then began considering a suitable component to target. What would be the\r\nleast expected component to perform downgrades? I set my sights on the Windows Update process. \r\nWindows Update\r\nWindows Update Architecture \r\nThe Windows Update architecture includes an update client and an update server that communicate over COM, an inter-process communication method on Windows. Administrator is usually enforced on the client side, and Trusted Installer is\r\nalways enforced on the server side, meaning system files owned by Windows Update are only accessible to the Trusted\r\nInstaller. As a result, even Administrators and NT SYSTEM are unable to directly modify system files.\r\nThis is where I found the first design problem in Windows Update. Administrator to Trusted Installer is not a security\r\nboundary, and there are multiple, working public proof-of-concepts of such an elevation. The Windows Update team\r\nattempted to secure the update process by enforcing Trusted Installer. However, since updates are only accessible to\r\nAdministrators, Trusted Installer is rendered completely ineffective in enforcing access to system files, as one can elevate to\r\nTrusted Installer and perform the changes. \r\nUnfortunately for me, Administrator-to-Trusted-Installer elevations are considered malicious and blocked by EDRs,\r\nmeaning it contradicts my first downgrade principle of being fully undetected. I considered trying to bypass the elevation\r\ndetection; however, I would have to implement the update process myself, which could still be seen as malicious. The best\r\noption would be to find a flaw in the update process that would solve all those problems.\r\nWindows Update Flow\r\nThe Windows Update flow includes the following steps: \r\nhttps://www.safebreach.com/blog/downgrade-attacks-using-windows-updates/\r\nPage 2 of 14\n\n1. First, the client asks the server to perform the update contained in an update folder it provides.\r\n2. The server then validates the integrity of the update folder.\r\n3. Following the verification, the server operates on the update folder to finalize the update files. These are saved to a\r\nserver-controlled folder, one that is not accessible to the client.\r\n4. The server saves an action list to the server-controlled folder, not accessible to the client. The action list is named\r\nPending.xml and it contains the update actions to perform. For example, it specifies which files to update, the source\r\nand destination files, etc.\r\n5. Finally, when the OS is rebooted, the action list is operated on, and the update actions are performed during the\r\nreboot. \r\nThe client only controls the initial update folder. So, I decided to look at this folder first, and see if I could modify it,\r\nresulting in custom downgrading update files. As we already know, integrity checks are performed on the update folder.\r\nLet’s see how well they are implemented. \r\nInvestigating the Update Folder \r\nThe update folder contains update components, and each update component contains MUM, manifest, differential, and\r\ncatalog files, as shown below.\r\nThe MUM files are Microsoft Update metadata and contain metadata information, component dependencies,\r\ninstallation order, etc.\r\nThe manifest files contain installation-specific information like file paths, registry keys, which installers to execute as\r\npart of the installation, and more.\r\nThe differential files are delta files from base files. A base file plus a delta file would result in the full update file. \r\nThe catalog files are the digital signatures of the MUM and manifest files. Catalogs allow multiple files to be signed\r\nat once, instead of having the file we want to sign embed its digital signature. In addition, the catalog files are\r\ndigitally signed themselves, which makes it impossible to modify them and the files that they sign.\r\nAgain, to summarize: \r\nOnly the catalog files are digitally signed. \r\nThe Manifest and MUMs are not explicitly signed, but are signed by the catalogs.\r\nhttps://www.safebreach.com/blog/downgrade-attacks-using-windows-updates/\r\nPage 3 of 14\n\nDifferential files are not signed. They also control the final update file content.\nTargeting Differential Files\nI found the last fact interesting, and wondered if there was any chance differential files were left behind in terms of\nvalidation. But, I had no luck there, because the expected update file hash is hardcoded in the manifest. And the manifest\ncannot be changed, since that would break its signature in the catalog.\nTargeting the Action List\nNext, I decided to explore the action list. I knew that I wouldn’t be able to change its contents, because it is Trusted Installer\nenforced. But I also knew that the update process is performed over multiple reboots, so I could assume the state of the list\nwas saved somewhere.\nI searched the action list path in the registry and found an interesting key named PoqexecCmdline. It holds the executable\nthat parses the list and the list path.\nI then looked at the security attributes of this key and noticed that it is not Trusted Installer enforced! This would allow me\nto control all the update actions.\nThe action list—pending.xml— is an XML file that provides the functionality of creating files, deleting files, moving files,\nhard-linking files, creating registry keys and values, deleting keys and values, and much more!\nIn order to downgrade, I could use the hard-link file action and the source would replace the destination.\nIntroducing an Update\nTo initiate an update, all I needed to do was:\nhttps://www.safebreach.com/blog/downgrade-attacks-using-windows-updates/\nPage 4 of 14\n\nThe identifier is a dynamic number that is compared with the action list’s identifier for integrity purposes. None of the three\r\nactions above are Trusted Installer enforced. This allowed me to update the system with a custom, downgrading action list.\r\nAll of the integrity verifications were bypassed, since the action list is assumed verified because it is created post-verification. \r\nAs a result, there is no need to perform the malicious Trusted-Installer elevation. Instead, Windows Updates did all of the\r\nwork for me! I was able to achieve a complete Windows Update takeover with a downgrade attack that is: \r\nFully undetectable. Since it was performed in a legitimate way, no malicious activity is detected.\r\nInvisible. Because I technically “updated” the system, it will appear fully up-to-date.\r\nPersistent. I discovered that the action list parser poqexec.exe is not digitally signed. As a result, I was able to patch\r\nit to install empty updates, meaning any newly available updates will be falsely installed. \r\nIrreversible. I also discovered that the integrity and repair utility SFC.exe is not digitally signed. I was able to patch\r\nit as well, meaning it will no longer detect any corruptions. I also found DISM.exe, but it detects corruptions in the\r\ncomponent store, which there is no reason to modify.\r\nDemo\r\nTo see these capabilities in action, the following demo shows how I was able to downgrade a kernel driver named AFD.sys\r\nto an old and vulnerable version. Next, it shows how I exploited that same kernel driver to achieve kernel code execution.\r\nhttps://www.safebreach.com/blog/downgrade-attacks-using-windows-updates/\r\nPage 5 of 14\n\nSo far, I’ve developed a perfect downgrade ability and gained kernel code execution. Since my starting point was\r\nAdministrator, this was an Administrator-to kernel elevation. \r\nAdministrator-to-kernel is not considered a security boundary on Windows. Although not a boundary, Administrator-to-kernel is still a threat and a serious one. Nowadays, many users are still running as Administrators, and running as\r\nAdministrator is also default on Windows. As a result, many users could easily compromise the kernel, and this is an issue\r\nthat Microsoft aimed to solve.\r\n0:00 / 1:30\r\nhttps://www.safebreach.com/blog/downgrade-attacks-using-windows-updates/\r\nPage 6 of 14\n\nMicrosoft’s solution to this was to deprivilege the kernel to make kernel access less valuable. This de-privileging was done\r\nby introducing a feature called virtualization-based security (VBS).\r\nWindows VBS \r\nVBS provides a secure and isolated virtual environment—powered by the Hyper-V hypervisor. The reason that VBS was\r\ncreated is because the kernel is assumed compromised, and there was a need for a secure place to implement security\r\nfeatures and store secret keys. \r\nVBS features include Credential Guard, HVCI, System Guard Secure Launch, Shielded VMs, and more security features\r\nthat really improved the security of Windows.\r\nVBS Architecture\r\nBefore VBS, the Windows architecture included User Mode in ring 3, the kernel in ring 0, and the hypervisor in ring -1.\r\nWith VBS, the hypervisor introduces virtual trust levels (VTLs), which are essentially like virtual machines. The higher the\r\nVTL, the more privileged it is. Lower VTLs should not be able to access memory or compromise higher VTLs. Currently on\r\nWindows, only two VTLs exist.    \r\nVTL0 is known as Normal Mode and contains the original OS. VTL1 is known as Secure Mode, and contains security\r\nfeatures and mitigations, as well as key isolation technologies.\r\nVBS Remote Disablement Protection\r\nAs I explored VBS security features and mitigations, I wondered if VBS features could be easily turned off. Allowing VBS\r\nconfiguration modifications by Administrators would be ineffective, since attackers would just turn VBS off instead of\r\ndealing with it. \r\nVBS protects against disablements by implementing a feature called UEFI lock. The lock is a UEFI Boot Service variable\r\nthat holds the VBS configuration. If VBS is configured with a lock, the lock is the source of configuration instead of the\r\nWindows Registry. So, changing the registry configuration will have no effect. The UEFI variable is the source of truth. And\r\nof course the Boot Service variable can only be accessed during boot, not in runtime from the OS. This is a very simple and\r\nreliable protection.\r\nhttps://www.safebreach.com/blog/downgrade-attacks-using-windows-updates/\r\nPage 7 of 14\n\nIf the user really wants to disable VBS, they must load an EFI application signed by Microsoft. This EFI would then ask the\r\nuser during boot to physically approve the disablement—only then is VBS is disabled. The key element here is that this is\r\nperformed during boot, and the assumption is that only signed code is allowed to run because of Secure Boot. The only\r\nsigned code that touches the variable requires physical approval. So without physical access to the target machine, it should\r\nnot be possible to disable VBS.\r\nBypassing VBS UEFI Lock\r\nNow that I had the ability to control any file on the OS, I wondered what would happen if I tried to replace the Secure\r\nKernel or the hypervisor powering VBS with invalid files that, for example, are not digitally signed and are attacker-controlled. I assumed the machine would boot into the recovery environment, since invalid files are a sign of compromise.\r\nInstead, I was extremely surprised to find that the OS loader booted normally, abandoning VBS if it failed to validate one of\r\nVBS’s files. This process allowed me to disable VBS, discovering what I believe to be the first bypass of VBS’s UEFI lock! \r\nBy combining the downgrade flow I developed and the UEFI lock bypass, I was able to achieve credential extraction against\r\nthe most restrictive settings: \r\nPPL was enabled for LSASS with UEFI lock, protecting LSASS dumps. \r\nCredential Guard was enabled with UEFI lock, protecting secrets in VTL1. \r\nWindows Defender was up and running. \r\nI bypassed these settings by first reverting the PPLFault patch to allow PPL bypass. Second, I disabled Credential Guard,\r\nbypassing the UEFI locks by invalidating the Secure Kernel. Finally, I made Windows Defender non-functional by\r\ninvalidating MsMpEng, the main Defender executable.\r\nIt is important to understand that Credential Guard and PPL for LSASS are complimentary. If only Credential Guard is\r\nbypassed, LSASS cannot be dumped.\r\nAnd if only PPL is bypassed, credentials are encrypted and not usable.\r\nhttps://www.safebreach.com/blog/downgrade-attacks-using-windows-updates/\r\nPage 8 of 14\n\nDemo\r\nTo see these capabilities in action, the following demo shows how I was able to bypass Credential Guard, PPL, and\r\nWindows Defender all at once by utilizing my downgrade flow and the UEFI lock bypass. \r\nVBS Security Boundaries\r\nNow that I bypassed the UEFI locks and disabled VBS, it was time to investigate real security boundaries of VBS. \r\nThe security boundaries VBS introduces are that any VTL0-to-VTL1 transition is considered an elevation of privilege. No\r\nVTL0 code should be able to compromise VTL1 code. Another boundary is that ring 3 to ring -1 or ring 0 to ring -1 (i.e.,\r\nany user mode or kernel to hypervisor) are also considered an elevation of privilege. Due to the way VBS is implemented,\r\ncompromising the hypervisor gives control over all VTLs.\r\n0:00 / 2:55\r\nhttps://www.safebreach.com/blog/downgrade-attacks-using-windows-updates/\r\nPage 9 of 14\n\nWhen considering VBS downgrades, my main goal was to understand if there was a downgrade mitigation—like versioning\r\nchecks or a revocation mechanism—in the virtualization stack. If no downgrade mitigation was found, I would attempt to\r\ndowngrade to vulnerable code. Regardless of how far I could go with the downgrade now, I would consider this a\r\nvulnerability. That is because it would make exploitation much easier if a new vulnerability was found and patched in the\r\ntarget component at some point in the future. And even if not immediately exploitable, it is something that needs to be\r\naddressed.\r\nTargeting Secure Mode’s Isolated User Mode Processes\r\nTo begin, I set my sights on Secure Mode’s isolated user mode processes. I decided to target the most well-known isolated\r\nuser mode process: Credential Guard. \r\nCredential Guard is implemented in Ring3-VTL1 as an isolated user-mode process named LsaIso.exe, which stands for Lsa\r\nIsolated. With Credential Guard running, secrets are stored in LsaIso.exe in VTL1, instead of in the original LSASS process.\r\nThis is why dumping LSASS is no longer valuable, because LSASS only contains encrypted blobs. The real secrets are not\r\naccessible to any VTL0 code.\r\nI targeted the downgrade with CVE-2022-34709, which is a fixed elevation of privilege in Credential Guard. I found both\r\nthe vulnerable module, KerbClientShared, and the vulnerable version 10.0.22000.856. Downgrading the vulnerable module\r\nusing the Windows Update takeover worked on a fully patched machine! \r\nThis allowed me to escalate privileges from Ring3-VTL0 to Ring3-VTL1, compromising Credential Guard and the secrets it\r\nprotects. There was no downgrade detection on VTL1 isolated user mode!\r\nTargeting Secure Mode’s Kernel\r\nIsolated User Mode privileges are great, but I wanted to gain higher privileges like those found in Secure Mode’s kernel. \r\nhttps://www.safebreach.com/blog/downgrade-attacks-using-windows-updates/\r\nPage 10 of 14\n\nThe kernel of Secure Mode is called Secure Kernel, and it is a minimal kernel that only implements security features such as\r\nHVCI, HyperGuard, and more.\r\nI targeted the downgrade with CVE-2021-27090, which is a fixed elevation of privilege in Secure Kernel. The vulnerable\r\nmodule here could only be Secure Kernel (SecureKernel.exe) and the vulnerable version 10.0.19041.207. \r\nHowever, in this case, downgrading only Secure Kernel was not enough. I also had to downgrade dependency modules—\r\nlike SKCI.dll and CI.dll—and then the Windows Update takeover worked on a fully patched machine! \r\nThis allowed me to escalate privileges from Ring3-VTL0 to Ring0-VTL1, compromising the entire VTL and any of its\r\nmitigations, including HVCI, HyperGuard, and more. There was no downgrade detection on VTL1 Secure Kernel\r\neither!\r\nTargeting Hyper-V’s Hypervisor\r\nSecure kernel privilege is awesome, but I wanted to set my sights even higher. So, I moved on to target the most privileged\r\nentity of VBS: the Hyper-V hypervisor. \r\nThe hypervisor is Hvix64.exe on Intel systems and Hvax64.exe on AMD systems. The hypervisor is a standalone micro-kernel, which makes it a valuable target for downgrade. \r\nUnlike the isolated user mode process and the secure kernel, it was more challenging to target the hypervisor downgrade\r\nwith a specific vulnerability. While there were many vulnerabilities titled Hyper-V Elevation of Privilege that had been fixed\r\nover the last two years, Hyper-V is a large component. In relevant CVE descriptions, Microsoft doesn’t share which\r\ncomponent in the Hyper-V stack is vulnerable, so it could be user mode elevated process, kernel driver, or the hypervisor\r\nitself, which is the component I am targeting.\r\nSo, I decided to downgrade Hyper-V to a version from two years ago, which seemed like enough time that I could be\r\nconfident there was at least one hypervisor elevation-of-privilege vulnerability that would be unfixed in the version I\r\nselected.\r\nAgain, I was able to successfully downgrade the hypervisor and the hypervisor loader using the Windows Update takeover! \r\nhttps://www.safebreach.com/blog/downgrade-attacks-using-windows-updates/\r\nPage 11 of 14\n\nThis allowed me to escalate privileges from Ring3-VTL0 to Ring -1, potentially compromising the entire virtualization\r\nstack. I found no downgrade mitigation in any component of the virtualization stack—the entire stack was vulnerable\r\nto downgrades. \r\nDemo\r\nTo see these capabilities in action, the following demo shows how I was able to utilize my downgrade flow to successfully\r\ndowngrade the hypervisor. \r\nhttps://www.safebreach.com/blog/downgrade-attacks-using-windows-updates/\r\nPage 12 of 14\n\nVendor Response \r\nWhen it comes to our original research, SafeBreach is deeply committed to responsible disclosure. In line with that\r\ncommitment, we notified Microsoft of our research findings in February 2024. Microsoft issued two CVEs—CVE-2024-\r\n21302 and CVE-2024-38202—and sent the following official response: \r\n“We appreciate the work of SafeBreach in identifying and responsibly reporting this vulnerability through a coordinated\r\nvulnerability disclosure. We are actively developing mitigations to protect against these risks while following an extensive\r\nprocess involving a thorough investigation, update development across all affected versions, and compatibility testing, to\r\nensure maximized customer protection with minimized operational disruption.”\r\nMicrosoft provided additional guidance via Security Update Guide ADV24216903 and has asked that we direct anyone with\r\nfurther questions about their response plan to reach out to the Microsoft communications team directly at\r\nrapidresponse@we-worldwide.com. \r\n0:00 / 1:12\r\nhttps://www.safebreach.com/blog/downgrade-attacks-using-windows-updates/\r\nPage 13 of 14\n\nConclusion \r\nThis research set out to explore the Windows Update process to identify how it might be manipulated to enable a downgrade\r\nattack. I was able to show how it was possible to make a fully patched Windows machine susceptible to thousands of past\r\nvulnerabilities, turning fixed vulnerabilities into zero-days and making the term “fully patched” meaningless on any\r\nWindows machine in the world. We believe the implications are significant not only to Microsoft Windows, which is the\r\nworld’s most widely used desktop OS, but also to other OS vendors that may potentially be susceptible to downgrade\r\nattacks. To help mitigate the potential impact of the vulnerabilities identified by this research, we: \r\nResponsibly disclosed our research findings to Microsoft in February 2024, as noted above.\r\nShared my research openly with the broader security community here and at my Black Hat USA 2024 and DEF CON\r\n32 (2024) presentations to enable the organizations and end-users leveraging the Windows OS to better understand\r\nthe risks associated with these vulnerabilities.\r\nProvided a research repository that includes tools that enable the verification and exploitation of these vulnerabilities\r\nto serve as a basis for further research and development. \r\nAdded the following attack content to the SafeBreach platform that enables our customers to validate their\r\nenvironment against the vulnerabilities and techniques outlined in this research to significantly mitigate their risk.\r\nThese attacks allow an attacker to potentially take over the Windows Update process, downgrade Windows to an\r\nolder version, and make it vulnerable to any known one-day vulnerability.\r\n#10341 – Windows Downdate – Windows update takeover\r\n#10342 – Windows Downdate – TrustedInstaller elevation\r\nFor more in-depth information about this research, please: \r\nContact your customer success representative if you are a current SafeBreach customer\r\nSchedule a one-on-one discussion with a SafeBreach expert\r\nContact Kesselring PR for media inquiries \r\nCredits\r\nI would also like to give credit to the talented individuals below for their work: \r\nJames Forsahw (@tiraniddo) – CVE-2022-34709\r\nSaar Amar (@AmarSaar) – CVE-2021-27090\r\nGabriel Landau (@GabrielLandau) – PPLFault\r\nValentina Palmiotti (@chompie1337), Ruben Boonen (@FuzzySec) – CVE-2023-21768 Exploit \r\nBenjamin Delphi (@gentilkiwi) – Mimikatz\r\nAbout Our Researcher\r\nAlon Leviev (@_0xDeku) is self-taught security researcher with a diverse background. Alon started his professional career\r\nas a blue team operator, where he focused on the defensive side of cyber security. As his passion grew towards research,\r\nAlon joined SafeBreach as a security researcher. His main focus included operating system internals, reverse engineering,\r\nand vulnerability research. Alon has spoken at various security conferences like Black Hat Europe 2023, CanSecWest 2024,\r\nand CONFidence 2024. Before joining the cyber security field, Alon was a professional Brazilian jiu-jitsu athlete, where he\r\nwon several world and European titles.\r\nSource: https://www.safebreach.com/blog/downgrade-attacks-using-windows-updates/\r\nhttps://www.safebreach.com/blog/downgrade-attacks-using-windows-updates/\r\nPage 14 of 14",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://www.safebreach.com/blog/downgrade-attacks-using-windows-updates/"
	],
	"report_names": [
		"downgrade-attacks-using-windows-updates"
	],
	"threat_actors": [],
	"ts_created_at": 1775439146,
	"ts_updated_at": 1775791224,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/f3c8bcb422d61b692f438271a0ebb8da8b15830b.pdf",
		"text": "https://archive.orkl.eu/f3c8bcb422d61b692f438271a0ebb8da8b15830b.txt",
		"img": "https://archive.orkl.eu/f3c8bcb422d61b692f438271a0ebb8da8b15830b.jpg"
	}
}