ESET researchers recognized 11 outdated and forgotten UEFI shim bootloaders at variations 0.9<\/span> and beneath that can be utilized to bypass UEFI Safe Boot on any UEFI-based machine that trusts Microsoft\u2019s Microsoft Company UEFI CA 2011<\/span> third-party UEFI certificates authority (CA) certificates, whatever the put in working system (OS). Reported shims might be exploited to execute untrusted code throughout system boot, enabling attackers to deploy malicious UEFI bootkits (comparable to Bootkitty<\/a>, HybridPetya<\/a>, or BlackLotus<\/a>) even on methods with UEFI Safe Boot enabled. We reported our findings to CERT\/CC in February 2026, and the weak UEFI purposes had been revoked on Microsoft\u2019s June 9th<\/sup>, 2026 Patch Tuesday.<\/p>\n Whereas two CVE IDs had been assigned to this case to cowl the reported shims, CVE-2026-8863<\/a> and CVE-2026-10797<\/a>, exploitation of every reported shim is not only a few single bug or two that may be present in these outdated shims immediately. The truth is, the assault floor is prolonged by the shims\u2019 trusted, second-stage bootloaders (largely GRUB\u00a02<\/a>), which \u2013 just like the shims themselves \u2013 might embody outdated variations with recognized vulnerabilities. The found shims come from numerous instruments or software program packages, together with PC-diagnostics software program, Linux distributions, and different UEFI-based utilities. Importantly, exploitation is just not restricted to methods with the affected software program or OS put in, as attackers can carry their very own copy of the weak shims to any UEFI system with the Microsoft third-party UEFI certificates enrolled.<\/p>\n The total checklist of the software program merchandise counting on the reported shims together with their affected variations is accessible in CERT\/CC\u2019s Vulnerability Observe<\/a>. In response to ESET researchers\u2019 report, UEFI shim bootloaders with the next PE Authenticode<\/a> hashes had been revoked within the dbx<\/span> replace that was a part of Microsoft\u2019s June 9th<\/sup> Patch Tuesday<\/a>:<\/p>\n Key factors of this blogpost:<\/strong><\/p>\n Following is the coordinated disclosure timeline. We\u2019d wish to thank CERT\/CC for its assist in coordinating the vulnerability disclosure course of, and the affected distributors for easy and clear communication and cooperation in the course of the vulnerability disclosure and remediation course of. To guard your methods in opposition to this menace, set up the most recent Microsoft dbx<\/span> updates. Directions on find out how to do that may be discovered within the Safety and detection<\/a><\/em> part.<\/p>\n Coordinated disclosure timeline:<\/strong><\/p>\n To know the influence that such weak shims can have on UEFI Safe Boot-protected methods, we have to perceive how UEFI Safe Boot works, and the way signed UEFI shim bootloaders lengthen the Safe Boot belief chain. On this part we\u2019ll take a look at UEFI Safe Boot fundamentals, how UEFI shims lengthen the UEFI Safe Boot belief chain, and two shim-related options: Machine Proprietor Key (MOK) and Safe Boot Superior Focusing on (SBAT). For anybody already conversant in the speculation, we advocate leaping on to the part Bypassing UEFI Safe Boot utilizing outdated shims<\/em><\/a>.<\/p>\n As proven in Determine 1, when UEFI firmware masses a boot utility \u2013 like Home windows Boot Supervisor or a UEFI shim \u2013 it verifies the binary in opposition to two Safe Boot databases:<\/p>\n The picture have to be trusted by db<\/span> and never listed in dbx<\/span> \u2013 in any other case, the boot supervisor triggers a safety violation as an alternative of executing it. To make this work out of the field on newly bought gadgets with UEFI Safe Boot enabled, most OEMs enroll a set of Microsoft UEFI certificates within the db<\/span> database, particularly:<\/p>\n Which means that anybody wanting their boot-time software program to be UEFI Safe Boot-compatible by default can submit their binaries to Microsoft for signing via the Home windows {Hardware} Dev Heart, and as soon as authorized, the signed information turn out to be trusted on the overwhelming majority of UEFI methods. In consequence, Microsoft performs a central function in securing most UEFI-based gadgets, successfully deciding what’s, and what’s not, allowed to run throughout boot.<\/p>\n UEFI Safe Boot\u2019s revocation design is simple: when a beforehand trusted boot utility \u2013 one whose PE authenticode hash, or the certificates that signed it, is current in db<\/span> \u2013 seems to be weak, its PE authenticode hash is added to dbx<\/span>, the Microsoft-managed forbidden-signatures database (with the most recent dbx<\/span> contents usually revealed in Microsoft\u2019s GitHub repository<\/a>). Certificates themselves are revoked solely often.<\/p>\n Whereas the unique concept of revoking particular person weak binaries by hash may need been cheap on the time Safe Boot was launched, circumstances comparable to BootHole<\/a> and BlackLotus<\/a> reveal that this method is way from superb. The basic difficulty is scale, and it’s effectively captured within the Purple Hat Bootloader Workforce\u2019s SBAT<\/a> proposal\/specification:<\/p>\n As a part of the latest “BootHole” safety incident CVE-2020-10713<\/a>, 3 certificates and 150 picture hashes had been added to the UEFI Safe Boot revocation database dbx on the favored x64 structure. This single revocation occasion consumes 10kB of the 32kB, or roughly one third, of revocation storage usually obtainable on UEFI platforms. As a result of approach that UEFI merges revocation lists, this plus prior revocation occasions can lead to a dbx that’s virtually 15kB in dimension, approaching 50% capability.<\/em><\/p>\n The identical stress on dbx<\/span> capability surfaced once more with the BlackLotus-related revocations of weak Home windows Boot Supervisor binaries. Each of those prompted Microsoft, along with its companions, to introduce further, version-based revocation mechanisms, every tied to one of many two broadly deployed Safe Boot-compatible bootloaders:<\/p>\n Briefly, the place dbx<\/span> revokes binaries<\/em>, SBAT and Microsoft\u2019s Safe Boot SVN revoke variations<\/em>. When a vulnerability is present in a UEFI utility supporting one in all these version-based revocation mechanisms, what actually must be stored out is each construct as much as and together with the damaged one<\/em> \u2013 and that<\/em> might be captured by a model quantity a lot simpler than by an extended checklist of hashes. We clarify extra about SBAT within the Safe Boot Superior Focusing on (SBAT)<\/a><\/em> part.<\/p>\n With Linux distributions supporting UEFI Safe Boot, the above-described Safe Boot mechanism constructed round Microsoft keys introduces some challenges. Each Linux distribution generates its personal bootloader binaries, and every of them has a special hash. Getting each Linux bootloader signed immediately by Microsoft could be sluggish, bureaucratic, and impractical (if not not possible) to take care of throughout all Linux distributions.<\/p>\n The answer to this downside is a shim: a small, minimal first-stage bootloader that Microsoft can vet and signal as soon as, and which then creates a secondary belief anchor for the remainder of the Linux distribution-specific boot stack \u2013 often GRUB\u00a02 and the Linux kernel. This belief anchor is one other certificates, known as a vendor certificates (managed by the distribution vendor), added to the shim binary earlier than it’s signed by Microsoft.<\/p>\n A simplified boot sequence on a Safe Boot-enabled Linux system utilizing a shim is depicted in Determine 2.<\/p>\n The UEFI firmware masses the shim and validates its signature in opposition to the Microsoft CA saved within the firmware (the db<\/span> variable). The shim then takes over and validates the second-stage bootloader (usually GRUB\u00a02) in opposition to its personal embedded vendor certificates \u2013 for instance, Debian\u2019s UEFI key for Debian, Canonical\u2019s UEFI key for Ubuntu, or Purple Hat\u2019s key for RHEL and Fedora. GRUB\u00a02, in flip, validates the kernel utilizing the identical vendor certificates earlier than handing over management. Each step is cryptographically vouched for by the step earlier than it.<\/p>\n This indirection implies that a Linux distribution can launch bootloader and kernel updates quickly, signing them with its personal vendor key, with no need to return to Microsoft for each replace. Solely the shim itself requires Microsoft\u2019s signature \u2013 and it modifications sometimes.<\/p>\n Along with the seller certificates, the shim usually comprises one other built-in certificates related solely with the precise shim construct\/binary. This certificates is sometimes called a shim certificates and is used to signal and confirm integrity of the shim\u2019s utilities that may be generated in the course of the shim\u2019s construct time, comparable to MokManager (used for managing MOKs and defined in additional element beneath) or the shim\u2019s fallback<\/a>.<\/p>\n When speaking about shims, we can’t skip one other necessary mechanism that permits a shim to make use of exterior keys managed by the person, often called Machine Proprietor Keys<\/a> (MOKs). A MOK allowlist (consider it as a shim-specific \u201cextension\u201d of the UEFI db<\/span> database) is saved in a boot-only NVRAM variable named MokList<\/span>, and a forbidden checklist (the shim-specific \u201cextension\u201d of the UEFI dbx<\/span> database) is saved in a boot-only NVRAM variable named MokListX<\/span>; bodily entry is required to change each variables on a system with UEFI Safe Boot enabled (boot-only variables can solely be modified throughout boot, earlier than the OS loader calls the UEFI boot providers operate ExitBootServices<\/a>). To handle the lists, the shim makes use of the MokManager UEFI utility. A information on find out how to handle MOKs might be discovered right here<\/a>. Determine 3 illustrates how a MOK extends the shim\u2019s UEFI Safe Boot belief chain.<\/p>\n As we described in our BlackLotus<\/a> and Bootkitty<\/a> discoveries, because of the non-authenticated nature of the boot-only NVRAM variables utilized by the MOK mechanism, bootkits are inclined to misuse MOKs for persistence as soon as they efficiently bypass UEFI Safe Boot.<\/p>\n Every UEFI utility (part) that helps SBAT<\/a> carries a small piece of metadata in a devoted .sbat<\/span> part of its PE file, protected by the identical signature because the binary itself. The metadata names the part (for instance, shim<\/span> or grub<\/span>) and assigns it a era quantity that’s incremented each time a safety repair ships.<\/p>\n What turns these numbers right into a revocation mechanism is an identical coverage on the UEFI system itself: a boot-only UEFI variable named SbatLevel<\/span> that information the minimal acceptable era quantity for every recognized part. Crucially, this variable is managed and enforced by the shim, not the firmware, which permits sooner revocation updates in comparison with a dbx<\/span> replace. The shim embeds the coverage, so enforcement doesn’t rely solely on the exterior variable and incorporates any newer coverage supplied by way of SbatLevel<\/span>. At each boot, the shim first verifies its personal SBAT metadata in opposition to the coverage \u2013 so an outdated shim might be made to reject itself \u2013 after which applies the identical take a look at to each binary it masses, refusing something whose era quantity falls beneath the minimal that the coverage calls for.<\/p>\n Examples of SBAT revocations are proven in Determine 4. These are taken from the SbatLevel_Variable.txt<\/a> file positioned within the shim repository, which serves as the only supply for SBAT revocations.<\/p>\n The enforced degree isn\u2019t hidden from the OS \u2013 the shim publishes a read-only copy of SbatLevel<\/span> in a runtime variable, SbatLevelRT<\/span>. The OS can examine which revocation coverage is at present in pressure, however can’t modify it. On Home windows the identical data can also be obtainable via the registry worth HKLMSYSTEMCurrentControlSetControlSecureBootSBATSbatLevel<\/span>.<\/p>\n With the speculation a few shim\u2019s Safe Boot belief chain defined within the earlier part, we are able to now deal with the sensible influence that forgotten and outdated, although trusted, UEFI binaries can have on UEFI system safety.<\/p>\n We illustrate this by inspecting just a few particular points within the reported shims \u2013 points which might be simply exploitable and spotlight the breadth of the assault floor they expose.<\/p>\n Every of the reported shims embeds each a vendor-managed and a built-in shim certificates that function a belief anchor for the shim\u2019s second-stage bootloaders or utilities: GRUB\u00a02 binaries, MokManager, fallback loaders, and infrequently different vendor-signed shims that reach the belief chain even additional. The variety of binaries trusted by a given shim varies: from fewer than ten within the case of devoted, specialised software program to shut to 100 within the case of well-known Linux distributions.<\/p>\n Signing and compilation timestamps of the purposes trusted by the shims we reported span from 2013 to 2025 \u2013 sufficient to verify that a good portion of those binaries had been outdated and sure affected by quite a few publicly recognized vulnerabilities, together with the already talked about BootHole<\/a> within the case of GRUB\u00a02. Whereas most of those trusted parts are sufficiently old to hold some safety threat, GRUB\u00a02 appears to be the weakest hyperlink. It’s a complicated piece of software program, and older variations accumulate vulnerabilities accordingly.<\/p>\n Contemplate the shim from Oracle Linux, which is amongst these we reported. It trusts binaries signed by a certificates issued to Oracle Company<\/span> (SHA\u20111 thumbprint: 2E434A724B4759C981E4189AA5AD3D635096DD2F<\/span>). One of many binaries signed by that certificates is a GRUB\u00a02 binary discovered within the Oracle Linux 7.1 set up ISO (V74844-01.iso<\/span>). This binary is affected by CVE-2015-5281<\/a>, which \u2013 quoting the vulnerability notice \u2013 \u201cwhen used on UEFI methods, permits native customers to bypass meant Safe Boot restrictions and execute non-verified code by way of a crafted (1) multiboot or (2) multiboot2 module<\/em>\u201d. Each talked about modules, multiboot<\/span> and multiboot2<\/span>, permit loading of unsigned code throughout system startup utilizing the identically named instructions, and needs to be forbidden in signed UEFI Safe Boot-compatible GRUB\u00a02 binaries, as they bypass UEFI Safe Boot by design.<\/p>\n The exploit is easy: there are not any reminiscence corruption bugs to set off, no ROP chains to assemble, and no complicated reverse engineering required. The one prerequisite is constructing a customized, unsigned multiboot2-compliant<\/a> kernel picture \u2013 in observe, little greater than an ELF binary containing the required headers and a handful of different specifics. As soon as an attacker builds this binary and copies it to the EFI System Partition (ESP) together with the weak shim and GRUB\u00a02, a single GRUB\u00a02 multiboot2<\/span> command can be utilized to load and execute it throughout boot, Safe Boot enabled or not. A proof of idea demonstrating exploitation of CVE-2015-5281 by way of the outdated, reported Oracle Linux shim on a system with UEFI Safe Boot enabled (with out the most recent Microsoft patches utilized) is proven within the video beneath:<\/p>\n Through the years, the UEFI shim bootloader has naturally advanced, with new enhancements and safety features launched in successive releases of the upstream UEFI shim repository<\/a>. On the similar time, many third-party distributors have taken obtainable variations of the shim supply code to construct their very own binaries, which they subsequently submitted to Microsoft for signing. This conduct is anticipated and aligns with the unique design of shims. Nevertheless, inadequate consideration has been given to revoking outdated Microsoft-signed shims, lots of which may, by design, be leveraged to bypass newer safety mechanisms. We illustrate this hole with just a few concrete examples.<\/p>\n The MokList<\/span> (MOK-based allowlisting) has been supported by the upstream UEFI shim since virtually the very starting<\/a> (model 0.3<\/span>). MOK revocations (MokListX<\/span>), nevertheless, solely began to be enforced<\/a> in model 0.9<\/span>. Why is that an issue? Contemplate the next state of affairs…<\/p>\n An enterprise has enrolled its personal MOK to signal customized UEFI instruments and bootloaders that it deploys throughout its community. A vulnerability surfaces in a number of of these binaries, and in response, the directors revoke the outdated signing certificates by enrolling it into the MOK denylist (MokListX<\/span>). Then, they enroll a contemporary MOK, and re-sign patched variations of the affected binaries with the brand new key. The outdated, weak binaries at the moment are rejected by the shim, whereas the newly signed ones load correctly, so the enterprise\u2019s gadgets look safe. The outdated certificates stays current and trusted within the MokList<\/span>, however is revoked in MokListX<\/span>, the place it’s enforced as a higher-priority rule.<\/p>\n On this state of affairs, an attacker may substitute the sufferer\u2019s up-to-date shim with an older Microsoft-signed UEFI shim from our report \u2013 for instance, model 0.8<\/span> from the Abitti 1 software program, signed by Microsoft for Finland\u2019s Matriculation Examination Board. This shim nonetheless trusts the certificates saved within the sufferer\u2019s MokList<\/span> variable, the place the outdated MOK certificates stays legitimate, nevertheless it ignores MokListX<\/span>, because it was constructed previous to the introduction of MOK denylist enforcement<\/a>. In consequence, the attacker\u2019s shim may very well be used to load weak binaries with out restriction, permitting arbitrary code execution or the set up of a malicious UEFI bootkit.<\/p>\n The identical difficulty applies to SBAT. Help for it was launched upstream in shim model 15.3<\/a>, so any earlier shim is unaware of the mechanism: it doesn’t learn the SbatLevel<\/span> revocation coverage or examine the .sbat<\/span> part of the second-stage bootloader it masses. In consequence, it ignores any later SBAT revocations meant to dam weak parts.<\/p>\n On this case, an assault state of affairs could be the next: an attacker takes a Microsoft-signed pre-v15.3 shim \u2013 such because the model 0.9<\/span> shim from Purple Hat Enterprise Linux 7.2<\/span> that was a part of our report \u2013 pairs it with one of many a number of GRUB\u00a02 binaries that the shim nonetheless trusts however that SBAT has already revoked, after which copies each to the ESP. Throughout system boot, the shim validates the GRUB\u00a02 binary in opposition to its personal embedded certificates, by no means consults SBAT, and masses the weak binary with out criticism \u2013 leaving the attacker free to take advantage of any vulnerability in that GRUB\u00a02 binary.<\/p>\n Lastly, outdated shims are merely outdated code, and far outdated code carries recognized vulnerabilities. For example this, we use an instance of an outdated difficulty affecting shims at model 0.9<\/span> and beneath. This vulnerability had no CVE ID assigned till our report \u2013 regardless that it was fastened and effectively described virtually precisely a decade in the past within the message of one of many shim repository\u2019s upstream commits, d241bbb<\/a>. It’s now tracked as CVE-2026-10797<\/a>.<\/p>\n The problem is that an Authenticode-signed PE binary information its signature\u2019s size in two impartial places:<\/p>\n Within the affected shims, the revocation verify and the signature verification capabilities diverged on which dimension worth they need to belief. The revocation verify used the worth from the signature header, whereas the signature verification operate used the worth from the PE header.<\/p>\n It’s thus attainable to bypass the revocation mechanism by tampering with the second-stage bootloader\u2019s WIN_CERTIFICATE<\/span> construction in order that the revocation operate compares dbx<\/span> and MokListX<\/span> in opposition to bogus knowledge as an alternative of the bootloader\u2019s precise signature.<\/p>\n Merely put, even when the second-stage bootloader\u2019s certificates had been revoked in dbx<\/span> or MokListX<\/span>, the shim wouldn’t discover out. Two necessary feedback right here:<\/p>\n These limitations come from the truth that hash-based revocations and non-embedded certificates (from MokList<\/span> and db<\/span>) are checked elsewhere within the code and should not affected by this difficulty.<\/p>\n With the present Microsoft UEFI certificates expirations<\/a> in thoughts (as proven in Determine 5, Microsoft Company UEFI CA 2011<\/span> expired on June 27th<\/sup> 2026), one would possibly wonder if reporting weak UEFI purposes signed by this expired certificates is simply inflicting pointless noise.<\/p>\n The reality is that the UEFI certificates\u2019s expiration date has no impact on the Safe Boot verification course of. If the Microsoft Company UEFI CA 2011<\/span> certificates stays in db<\/span>, and isn’t revoked in dbx<\/span>, all bootloaders validly signed with this expired certificates keep trusted if not explicitly revoked by hash. That is the explanation why Microsoft stored signing<\/a> new submissions with the outdated certificates up till its expiration date.<\/p>\n These weak shims might be blocked by making use of the most recent UEFI revocations from Microsoft. Home windows methods needs to be up to date mechanically. Determine 6 shows PowerShell instructions (to be run with elevated permissions) to verify whether or not the required revocations are put in in your Home windows system.<\/p>\n Determine 6. PowerShell instructions to verify UEFI revocations<\/em><\/p>\n For Linux methods, updates needs to be obtainable via the Linux Vendor Firmware Service<\/a>, and the revocation standing might be checked utilizing the uefi-dbx-audit<\/a> script.<\/p>\n For extra common suggestions concerning find out how to shield in opposition to (or not less than detect) exploitation of unknown weak signed UEFI bootloaders and deployment of UEFI bootkits, see our blogpost Beneath the cloak of UEFI Safe Boot: Introducing CVE-2024-7344<\/a>.<\/p>\n What makes these outdated shims harmful is just not a novel vulnerability, it\u2019s that no new vulnerability is required to bypass UEFI Safe Boot. An attacker wants no sophisticated exploitation primitives \u2013 solely a duplicate of an outdated, still-trusted, however unrevoked<\/em> shim binary and a primary understanding of how UEFI shims work. That is sufficient to bypass such a necessary safety function as UEFI Safe Boot.<\/p>\n Whereas revoking these 11 shims addressed the instant difficulty, a deeper difficulty stays: visibility. The shim signing course of grew to become considerably extra clear in 2017 with the introduction of the shim-review<\/a> repository, the place vendor submissions are vetted by maintainers earlier than Microsoft indicators them. Each shim authorized since then is documented \u2013 however these signed earlier should not, and nobody can reliably say what number of of these outdated, still-trusted shims stay. What has not been totally and transparently catalogued can’t be successfully retired.<\/p>\n On a optimistic notice, we consider that the development is shifting in the proper course. Every disclosure like this one shrinks the pool of forgotten shims, and with improved shim-signing transparency and mechanisms comparable to SBAT, preserving monitor of what must be revoked, and successfully revoking it, might be dealt with much more effectively than prior to now. The following step is to increase this degree of transparency in Microsoft\u2019s third-party UEFI signing<\/a> ecosystem to non-shim third-party UEFI purposes, which, as repeatedly demonstrated (e.g., CVE-2022-34302<\/a>, CVE-2023-28005<\/a>, CVE-2024-7344<\/a>, CVE-2026-25250<\/a>, \u2026), may function an easy supply of UEFI Safe Boot bypasses.<\/p>\n Because the weak shims are a part of professional software program packages which might be probably current on 1000’s of methods which have by no means been compromised by way of these loaders, we’re not offering indicators of compromise to keep away from large misidentification. As an alternative, defenders ought to observe the recommendation within the Safety and detection<\/a><\/em> part.<\/p>\n\n
\n
\n
\n
\n
UEFI shim bootloader and UEFI Safe Boot<\/h2>\n
UEFI Safe Boot<\/h3>\n
\n
![\"Figure](\"https:\/\/web-assets.esetstatic.com\/wls\/2026\/07-26\/uefi-shims\/figure-1.png\" "\\"Figure")
\n
UEFI revocation (dbx)<\/h4>\n
\n
UEFI shim bootloader and Safe Boot<\/h3>\n
![\"Figure](\"https:\/\/web-assets.esetstatic.com\/wls\/2026\/07-26\/uefi-shims\/figure-2.png\" "\\"Figure")
Machine Proprietor Key (MOK)<\/h4>\n
![\"Figure](\"https:\/\/web-assets.esetstatic.com\/wls\/2026\/07-26\/uefi-shims\/figure-3.png\" "\\"Figure")
Safe Boot Superior Focusing on (SBAT)<\/h4>\n
![\"Figure](\"https:\/\/web-assets.esetstatic.com\/wls\/2026\/07-26\/uefi-shims\/figure-4.png\" "\\"Figure")
Bypassing UEFI Safe Boot utilizing outdated shims<\/h2>\n
Susceptible second-stage bootloaders<\/h3>\n
Absence of newer options<\/h3>\n
MOK denylist enforcement<\/h3>\n
SBAT enforcement<\/h3>\n
Identified shim vulnerabilities<\/h3>\n
\n
\n
Received\u2019t expiring Microsoft UEFI certificates resolve this?<\/h2>\n
![\"Figure](\"https:\/\/web-assets.esetstatic.com\/wls\/2026\/07-26\/uefi-shims\/figure-5.png\" "\\"\\"")
Safety and detection<\/h2>\n
$hashes=\"AE75F0D82BA3DF824FBFC69340CC3B4D66C598373B1AB54CDB6C8BFD83A6B961\",\n'7B2A3F5C96F95BD8086CE54B0825E300F9C8F11FE3401BB631B3215C8DE9EB10',\n'EB86FA1386FE6E4533B8B938DCC1250616D2F1C14C15E2FCF80834A161018A0A',\n'FD23D6E57DE6F4E1F9D7118DA1C5F31A8AF6BE5E5D9E8170F9493447268D50C5',\n'A0DE9333442C1BF9349A460141AE5E80F911955C6506040FA3D021BF6C1AE3E4',\n'95B6D71FC0C0F8C5E1533A37AEF92CF6B0C961E2CC612A97117FA6759CE5FC06',\n'236A9CB0D71951C36398A32EB660CE2CD4A52CCFA7CF751CC6A35D9DE549E19B',\n'5E594C448760A3135B1A3A83E07A4F2E6FBE49414EF2C7CAB1CBA77F284FA63B',\n'8A964D5F8373948D20A1D4296FB92E545DAD4617A0C810F3B934B53D98AE8963',\n'410260B1B6F5AF5FBEEB9EA3220658435E876CB3247126EE907A437F312DB373',\n'96275DFD6282A522B011177EE049296952AC794832091F937FBBF92869028629' \n$dbx = [BitConverter]::ToString((Get-SecureBootUEFI dbx).Bytes) -replace '-'\n$notRevoked = $hashes | The place-Object { $dbx -notmatch $_ }\nif ($notRevoked) {\n $notRevoked | ForEach-Object { \"Hash not revoked: $_\" }\n} else {\n \"All hashes revoked in dbx!\"\n}<\/code><\/pre>\nConclusion<\/h2>\n
IoCs<\/h2>\n
\n