On the Red Team project last year, the task sounded the following task: to prove persistence below the OS level on the host with Windows 11 and included Secure Boot. SYSTEM received through Kerberoasting, reaching the workstation reached the field movement. Trying to put a modified downloader in the EFI System Partition ended predictably - Secure Boot rejected an unsigned binary when rebooted. The question is: is it Secure Boot via BIOS? It is possible, but leaves traces in the firmware magazine - for Red Team it is a failure of the OPSEC. The task was different: to bypass the verification of the loader, while maintaining the appearance of the staff. Below - three techniques of bypass Secure Boot, which actually work on a pentest, with a specific attack path and a parity of CVE-2024-7344.
Loading trust chain and failure point
Secure Boot verifies each link: UEFI firmware checks the OS bootloader, the OS bootloader checks the kernel drivers. When enabled, UEFI Boot Manager checks the boot app - bootmgfw.efi for Windows, shimx64.efi or grubx64.efi for GNU\Linux - on two databases:
• db (Signature Database) - list of trusted certificates and PE Authenticcode-hesha
• dbx (Forbidden Signatures Database) - blacklist of revoked hashes and certificates
Binary is executed only if its signature is valid on db and at the same time does not belong to dbx. On most devices - laptops, desktops, servers - in db by default, two Microsoft certificates are written:
1. Microsoft Windows Production PCA 2011 - signature of its own Windows downloaders
2. Microsoft Corporation UEFI CA 2011 - signature of third-party software (Linux shim-bloaders, recovery utilities, encryption disk)
The second certificate is our attack surface. Any vendor can send the Microsoft UEFI binary to signature via Windows Hardware Dev Center. After the audit, the binary receives the signature of UEFI CA 2011 and is accepted by Secure Boot on the vast majority of devices. According to the ESET study, the procedure of review is opaque - and among the signed binaries, specimens with critical vulnerabilities regularly pop up. For the pentester, the output is simple: it is not necessary to break cryptography. It is necessary to find among the thousands of signed binarya the one that contains the operated bug.
Place of bypass Secure Boot in kill chain
Attacks on UEFI-loader - not initial access or FILE escalation. By MITRE ATT&CK is Bootkit (T1542.003) and System Firmware (T1542.001) -centence and stealth in the final stages of the chain.
What needs to happen before the Securo Boot is bypassing:
1. Initial access - initial intrusion into the network
2. Privilege escalation - increase to local admin (Windows) or root (GNU\Linux)
3. Access to ESP - EFI System Partition mounting ( mountvol S: /son Windows, standard mountGNU\Linux)
What gives a successful bypass of the loader verification:
• The code is executed before the start of the OS, before the initialization of any EDR agent
• Persistence is undergoing a complete reinstallation of the OS
• Kernel-level control from the moment of transferring control of the kernel - you can download C2-beacon before the start CrowdStrike Falcon, SentinelOne, Elastic EDR or Kaspersky EDR Expert
• Copying files in ESP does not leave the logs in the standard Windows Event Logs - for the FAT32-section ESP there is no analogue of Sysmon FileCreate (here is the real blind zone)
Scenario of application: internal pentest or Red Team engagement with the task of persistent access. In practice, this is one of the final steps: after the detection and elimination of the lateral movement vector, the attacker demonstrates to the customer that access is stored through the boot kit. It hurts and painful at the same time.
Techniques of Secure Boot: the choice of vector
The choice of equipment depends on the level of access, the target OS and the availability of Measured Boot with TPM attestation.
CVE-2024-7344: bypassing the signature of the loader through a vulnerable binary
The most practical technique of bypassing Secure Boot for a retractable date and admin/root rights. The essence of the “bring your own boot freeloader” approach (BYOVB): the attacker delivers a legitimate, signed Microsoft UEFI binary with a known vulnerability and through it executes unsigned code. Through such a vector, you can deploy full UEFI-butcites - BlackLotus or Bootkitty - even with the Secure Boot on.
CVE-2024-7344, discovered by the researcher ESET Martin Smolár, touches on the UEFI-application Reloader - a component of several recovery utilities: Howyar SysReturn, Greenware GreenGuard, Radix SmartRecovery, Sanfong EZ-back System, CES NeoImpact. According to ESET, WASAY eRecoveryRX and SignalComputer HDD King are also affected.
• Tools: Chipsec (GitHub: chipsec/chipsec, active project), UEFITool (GitHub: LongSoft/UEFITool), efifibootgr
• Privileges: root (GNU\Linux) or admin + TestSigning (Windows)
• Wednesday: test stand. Chipsec downloads kernel driver with direct access to hardware resources - on production system it is the risk of freeze or damage
Checking the status of Secure Boot and the contents of the databases:
According to MITRE ATT&CK, it is both Bootkit (T1542.003) persistence and Code Signing Policy Modification (T1553.006) for defense evasion - Secure Boot is formally included, but in fact managed to bypass it.
Works if: The target system uses Microsoft third-party UEFI-certificate (most devices) and dbx does not contain the hash of a vulnerable reloader.efi. Does not work if: Windows 11 Secured-core PC - trust in the third-party UEFI-certificate is disabled by default; systems with current UEFI revocations after January 2025.
Time limit: On January 14, 2025, Microsoft recalled vulnerable binaries through the dbx update as part of the Patch Tuesday. EPSS-estimation - 0.004 (0.4%), percentile 0.61: the probability of mass exploitation is low, but for targeted attacks on systems with outdated dbx vector working. On the pentest, the first step after fingerprinting will be to check the relevance of dbx on the target host.
Attack via shim-loader and MOK keys
On GNU\Linux-systems with a shim-loader (Ubuntu, Fedora, RHEL) have an additional layer of key management - Machine Owner Key (MOK). Shim is a Microsoft-signed intermediate downloader that trusts both standard db keys and the owner’s own MOK keys.
The attacker with root rights registers its own MOK-key through mokutil --import custom_key.der, then sign the arbitrary boot boot user with the utility sbsign. At the next reboot, the shim manager will request an interactive confirmation of registration - this is the only step that requires the presence of the screen or KVM / IPMI-access.
Works if: root-privileges on GNU\Linux with shim, the ability to initiate a reboot and pass an interactive confirmation. Does not work if: no interactive access during reboot; infrastructure with centralized control of the MOK-set.
Context of Applicability: internal pentest with KVM-access to GNU\Linux servers. On the external pentest, it is not applicable because of an interactive step. The advantage before BYOVB: own MOK keys do not fall into the dbx update of Microsoft - the technique does not rotate over time.
Modification of SPI-flash with physical access
For the Red Team scenario with physical access to the device (server, workstation in the office), bypassing Secure Boot is possible at the firmware level. SPI-flash - chip on the motherboard, storing the entire UEFI image, including db/dbx and Seture Boot settings.
Through the programmer CH341A (costs about 500 rubles on marketplaces) and the utility flashrom can be considered a full dam of SPI flash, modify the variables db/dbx - by adding your key to the trusted or remove dbx - and write down the altered image back.
Works if: legacy servers without Intel Boot Guard and AMD PSB; industrial equipment with UEFI without TPM; systems without SPI protection. Does not work if: Intel with Boot Guard or AMD with Platform Secure Boot - the hardware verification of the Initial Boot Block will reject the modified image and the device will not boot.
The most radical and risky method: an error when recording can turn the device into a brick. I use it only on test stands or when the customer clearly agreed on a physical vector and understands the consequences.
Intelligence UEFI-configurations before attack
Fingerprinting UEFI configuration determines the choice of technique: whether Secure Boot is included, what certificates in db, whether dbx is relevant, whether SPI-record is protected.
Adjustments to the environment
• OS: GNU\Linux (full support for Chipsec) or Windows (limited, requires TestSigning mode)
• RAM: minimum 4 GB
According to MITRE ATT&CK, it is both Bootkit (T1542.003) persistence and Code Signing Policy Modification (T1553.006) for defense evasion - Secure Boot is formally included, but in fact managed to bypass it.
Works if: The target system uses Microsoft third-party UEFI-certificate (most devices) and dbx does not contain the hash of a vulnerable reloader.efi. Does not work if: Windows 11 Secured-core PC - trust in the third-party UEFI-certificate is disabled by default; systems with current UEFI revocations after January 2025.
Time limit: On January 14, 2025, Microsoft recalled vulnerable binaries through the dbx update as part of the Patch Tuesday. EPSS-estimation - 0.004 (0.4%), percentile 0.61: the probability of mass exploitation is low, but for targeted attacks on systems with outdated dbx vector working. On the pentest, the first step after fingerprinting will be to check the relevance of dbx on the target host.
Attack via shim-loader and MOK keys
On GNU\Linux-systems with a shim-loader (Ubuntu, Fedora, RHEL) have an additional layer of key management - Machine Owner Key (MOK). Shim is a Microsoft-signed intermediate downloader that trusts both standard db keys and the owner’s own MOK keys.
The attacker with root rights registers its own MOK-key through mokutil --import custom_key.der, then sign the arbitrary boot boot user with the utility sbsign. At the next reboot, the shim manager will request an interactive confirmation of registration - this is the only step that requires the presence of the screen or KVM / IPMI-access.
Works if: root-privileges on GNU\Linux with shim, the ability to initiate a reboot and pass an interactive confirmation. Does not work if: no interactive access during reboot; infrastructure with centralized control of the MOK-set.
Context of Applicability: internal pentest with KVM-access to GNU\Linux servers. On the external pentest, it is not applicable because of an interactive step. The advantage before BYOVB: own MOK keys do not fall into the dbx update of Microsoft - the technique does not rotate over time.
Modification of SPI-flash with physical access
For the Red Team scenario with physical access to the device (server, workstation in the office), bypassing Secure Boot is possible at the firmware level. SPI-flash - chip on the motherboard, storing the entire UEFI image, including db/dbx and Seture Boot settings.
Through the programmer CH341A (costs about 500 rubles on marketplaces) and the utility flashrom can be considered a full dam of SPI flash, modify the variables db/dbx - by adding your key to the trusted or remove dbx - and write down the altered image back.
Works if: legacy servers without Intel Boot Guard and AMD PSB; industrial equipment with UEFI without TPM; systems without SPI protection. Does not work if: Intel with Boot Guard or AMD with Platform Secure Boot - the hardware verification of the Initial Boot Block will reject the modified image and the device will not boot.
The most radical and risky method: an error when recording can turn the device into a brick. I use it only on test stands or when the customer clearly agreed on a physical vector and understands the consequences.
Intelligence UEFI-configurations before attack
Fingerprinting UEFI configuration determines the choice of technique: whether Secure Boot is included, what certificates in db, whether dbx is relevant, whether SPI-record is protected.
Adjustments to the environment
• OS: GNU\Linux (full support for Chipsec) or Windows (limited, requires TestSigning mode)
• RAM: minimum 4 GB
• Tools: Chipsec (GitHub: chipsec/chipsec, active project), UEFITool (GitHub: LongSoft/UEFITool), efifibootgr
• Privileges: root (GNU\Linux) or admin + TestSigning (Windows)
• Wednesday: test stand. Chipsec downloads kernel driver with direct access to hardware resources - on production system it is the risk of freeze or damage
Checking the status of Secure Boot and the contents of the databases:
The result will indicate whether Secure Boot is enabled (SecureBoot variable), the operating mode (SetupMode, AuditMode), and the state of db/dbx/KEK. The common.bios_wp module assesses the risk of a physical attack: [PASS] – SPI recording is blocked by hardware, [FAIL] – SPI flash is open to modification.
Dumping the firmware image and searching for vulnerable binaries:
Restrictions of Techniques and Blind Protection Zones
Measurid Boot with TPM - separate line of defense, operating in parallel with Secure Boot. TPM records the hashes of each component in the boot chain in PCR registers. Even if Secure Boot is bypassed and the bootloader is replaced, the PCR values will change. Systems with remote attestation (Microsoft Intune, corporate management modes) will find a discrepancy in the next report. On the BYOVB pentest, the BYOVB technology can give persistence, but on systems with TP attestation, the window narrows before the first verification cycle.
DISA STIG For Windows 10 and Windows 11, contain Configuration requirements for Secure Boot and firmware integrity verification. In mature infrastructures where STIG-baseline is used, dbx is updated centrally, the third UEFI certificate can be turned off - the space for the maneuver is minimal.
The main gap in the defense is a temporary window between detecting a vulnerable signed binary and its revocation via dbx. CVE-2024-7344 was discovered in July 2024, revocation - January 2025. Six months during which the signed binary was a worker. Martin Smolár of ESET calls this “a good result compared to similar cases” – which in itself indicates typical timing in the industry.
Most UEFI Secure Boot reports end with the conclusion of “renew dbx”. Correct? Yes. Useful? Not really. The real problem is in the trust architecture: Microsoft signs third-party UEFI binaries through an opaque revue process, and an application with a custom PE-boot that bypasses LoadImage/StartImage, passes it without question.
On Red Team projects, the picture repeats itself: the defense teams are confident that Secure Boot is a solved task, because the tick in the BIOS is worth it. Between "Secure Boot is included" and "loading chain verified end-to-end" - a chasm. Without TPM attestation, without centralized dbx management, without monitoring the contents of ESP - bypass of the Secureu Boot is the choice of the correct signed binary from the public dbx list.
A signed vulnerable bootloader delivered to ESP with admin rights will not cause any aerta to the SIEM until the time when the remote attestation records the PCR change. And if attestation is not set up, it will never cause.
The number of detected vulnerable signed UEFI-binary trees will grow - researchers from ESET and BINARLY are purposefully engaged in this. For pentesters, this expands the arsenal. For the defenders, the only working answer is TPM remote attestation and Secured-core configuration with disabling trust in third-party UEFI-certificate. Check your park: chipsec_main.py -m common.secureboot.variables will show whether you have a tick or real protection.
Loading trust chain and failure point
Secure Boot verifies each link: UEFI firmware checks the OS bootloader, the OS bootloader checks the kernel drivers. When enabled, UEFI Boot Manager checks the boot app - bootmgfw.efi for Windows, shimx64.efi or grubx64.efi for GNU\Linux - on two databases:
• db (Signature Database) - list of trusted certificates and PE Authenticcode-hesha
• dbx (Forbidden Signatures Database) - blacklist of revoked hashes and certificates
Binary is executed only if its signature is valid on db and at the same time does not belong to dbx. On most devices - laptops, desktops, servers - in db by default, two Microsoft certificates are written:
1. Microsoft Windows Production PCA 2011 - signature of its own Windows downloaders
2. Microsoft Corporation UEFI CA 2011 - signature of third-party software (Linux shim-bloaders, recovery utilities, encryption disk)
The second certificate is our attack surface. Any vendor can send the Microsoft UEFI binary to signature via Windows Hardware Dev Center. After the audit, the binary receives the signature of UEFI CA 2011 and is accepted by Secure Boot on the vast majority of devices. According to the ESET study, the procedure of review is opaque - and among the signed binaries, specimens with critical vulnerabilities regularly pop up. For the pentester, the output is simple: it is not necessary to break cryptography. It is necessary to find among the thousands of signed binarya the one that contains the operated bug.
Place of bypass Secure Boot in kill chain
Attacks on UEFI-loader - not initial access or FILE escalation. By MITRE ATT&CK is Bootkit (T1542.003) and System Firmware (T1542.001) -centence and stealth in the final stages of the chain.
What needs to happen before the Securo Boot is bypassing:
1. Initial access - initial intrusion into the network
2. Privilege escalation - increase to local admin (Windows) or root (GNU\Linux)
3. Access to ESP - EFI System Partition mounting ( mountvol S: /son Windows, standard mountGNU\Linux)
What gives a successful bypass of the loader verification:
• The code is executed before the start of the OS, before the initialization of any EDR agent
• Persistence is undergoing a complete reinstallation of the OS
• Kernel-level control from the moment of transferring control of the kernel - you can download C2-beacon before the start CrowdStrike Falcon, SentinelOne, Elastic EDR or Kaspersky EDR Expert
• Copying files in ESP does not leave the logs in the standard Windows Event Logs - for the FAT32-section ESP there is no analogue of Sysmon FileCreate (here is the real blind zone)
Scenario of application: internal pentest or Red Team engagement with the task of persistent access. In practice, this is one of the final steps: after the detection and elimination of the lateral movement vector, the attacker demonstrates to the customer that access is stored through the boot kit. It hurts and painful at the same time.
Techniques of Secure Boot: the choice of vector
The choice of equipment depends on the level of access, the target OS and the availability of Measured Boot with TPM attestation.
CVE-2024-7344: bypassing the signature of the loader through a vulnerable binary
The most practical technique of bypassing Secure Boot for a retractable date and admin/root rights. The essence of the “bring your own boot freeloader” approach (BYOVB): the attacker delivers a legitimate, signed Microsoft UEFI binary with a known vulnerability and through it executes unsigned code. Through such a vector, you can deploy full UEFI-butcites - BlackLotus or Bootkitty - even with the Secure Boot on.
CVE-2024-7344, discovered by the researcher ESET Martin Smolár, touches on the UEFI-application Reloader - a component of several recovery utilities: Howyar SysReturn, Greenware GreenGuard, Radix SmartRecovery, Sanfong EZ-back System, CES NeoImpact. According to ESET, WASAY eRecoveryRX and SignalComputer HDD King are also affected.
• Tools: Chipsec (GitHub: chipsec/chipsec, active project), UEFITool (GitHub: LongSoft/UEFITool), efifibootgr
• Privileges: root (GNU\Linux) or admin + TestSigning (Windows)
• Wednesday: test stand. Chipsec downloads kernel driver with direct access to hardware resources - on production system it is the risk of freeze or damage
Checking the status of Secure Boot and the contents of the databases:
According to MITRE ATT&CK, it is both Bootkit (T1542.003) persistence and Code Signing Policy Modification (T1553.006) for defense evasion - Secure Boot is formally included, but in fact managed to bypass it.
Works if: The target system uses Microsoft third-party UEFI-certificate (most devices) and dbx does not contain the hash of a vulnerable reloader.efi. Does not work if: Windows 11 Secured-core PC - trust in the third-party UEFI-certificate is disabled by default; systems with current UEFI revocations after January 2025.
Time limit: On January 14, 2025, Microsoft recalled vulnerable binaries through the dbx update as part of the Patch Tuesday. EPSS-estimation - 0.004 (0.4%), percentile 0.61: the probability of mass exploitation is low, but for targeted attacks on systems with outdated dbx vector working. On the pentest, the first step after fingerprinting will be to check the relevance of dbx on the target host.
Attack via shim-loader and MOK keys
On GNU\Linux-systems with a shim-loader (Ubuntu, Fedora, RHEL) have an additional layer of key management - Machine Owner Key (MOK). Shim is a Microsoft-signed intermediate downloader that trusts both standard db keys and the owner’s own MOK keys.
The attacker with root rights registers its own MOK-key through mokutil --import custom_key.der, then sign the arbitrary boot boot user with the utility sbsign. At the next reboot, the shim manager will request an interactive confirmation of registration - this is the only step that requires the presence of the screen or KVM / IPMI-access.
Works if: root-privileges on GNU\Linux with shim, the ability to initiate a reboot and pass an interactive confirmation. Does not work if: no interactive access during reboot; infrastructure with centralized control of the MOK-set.
Context of Applicability: internal pentest with KVM-access to GNU\Linux servers. On the external pentest, it is not applicable because of an interactive step. The advantage before BYOVB: own MOK keys do not fall into the dbx update of Microsoft - the technique does not rotate over time.
Modification of SPI-flash with physical access
For the Red Team scenario with physical access to the device (server, workstation in the office), bypassing Secure Boot is possible at the firmware level. SPI-flash - chip on the motherboard, storing the entire UEFI image, including db/dbx and Seture Boot settings.
Through the programmer CH341A (costs about 500 rubles on marketplaces) and the utility flashrom can be considered a full dam of SPI flash, modify the variables db/dbx - by adding your key to the trusted or remove dbx - and write down the altered image back.
Works if: legacy servers without Intel Boot Guard and AMD PSB; industrial equipment with UEFI without TPM; systems without SPI protection. Does not work if: Intel with Boot Guard or AMD with Platform Secure Boot - the hardware verification of the Initial Boot Block will reject the modified image and the device will not boot.
The most radical and risky method: an error when recording can turn the device into a brick. I use it only on test stands or when the customer clearly agreed on a physical vector and understands the consequences.
Intelligence UEFI-configurations before attack
Fingerprinting UEFI configuration determines the choice of technique: whether Secure Boot is included, what certificates in db, whether dbx is relevant, whether SPI-record is protected.
Adjustments to the environment
• OS: GNU\Linux (full support for Chipsec) or Windows (limited, requires TestSigning mode)
• RAM: minimum 4 GB
According to MITRE ATT&CK, it is both Bootkit (T1542.003) persistence and Code Signing Policy Modification (T1553.006) for defense evasion - Secure Boot is formally included, but in fact managed to bypass it.
Works if: The target system uses Microsoft third-party UEFI-certificate (most devices) and dbx does not contain the hash of a vulnerable reloader.efi. Does not work if: Windows 11 Secured-core PC - trust in the third-party UEFI-certificate is disabled by default; systems with current UEFI revocations after January 2025.
Time limit: On January 14, 2025, Microsoft recalled vulnerable binaries through the dbx update as part of the Patch Tuesday. EPSS-estimation - 0.004 (0.4%), percentile 0.61: the probability of mass exploitation is low, but for targeted attacks on systems with outdated dbx vector working. On the pentest, the first step after fingerprinting will be to check the relevance of dbx on the target host.
Attack via shim-loader and MOK keys
On GNU\Linux-systems with a shim-loader (Ubuntu, Fedora, RHEL) have an additional layer of key management - Machine Owner Key (MOK). Shim is a Microsoft-signed intermediate downloader that trusts both standard db keys and the owner’s own MOK keys.
The attacker with root rights registers its own MOK-key through mokutil --import custom_key.der, then sign the arbitrary boot boot user with the utility sbsign. At the next reboot, the shim manager will request an interactive confirmation of registration - this is the only step that requires the presence of the screen or KVM / IPMI-access.
Works if: root-privileges on GNU\Linux with shim, the ability to initiate a reboot and pass an interactive confirmation. Does not work if: no interactive access during reboot; infrastructure with centralized control of the MOK-set.
Context of Applicability: internal pentest with KVM-access to GNU\Linux servers. On the external pentest, it is not applicable because of an interactive step. The advantage before BYOVB: own MOK keys do not fall into the dbx update of Microsoft - the technique does not rotate over time.
Modification of SPI-flash with physical access
For the Red Team scenario with physical access to the device (server, workstation in the office), bypassing Secure Boot is possible at the firmware level. SPI-flash - chip on the motherboard, storing the entire UEFI image, including db/dbx and Seture Boot settings.
Through the programmer CH341A (costs about 500 rubles on marketplaces) and the utility flashrom can be considered a full dam of SPI flash, modify the variables db/dbx - by adding your key to the trusted or remove dbx - and write down the altered image back.
Works if: legacy servers without Intel Boot Guard and AMD PSB; industrial equipment with UEFI without TPM; systems without SPI protection. Does not work if: Intel with Boot Guard or AMD with Platform Secure Boot - the hardware verification of the Initial Boot Block will reject the modified image and the device will not boot.
The most radical and risky method: an error when recording can turn the device into a brick. I use it only on test stands or when the customer clearly agreed on a physical vector and understands the consequences.
Intelligence UEFI-configurations before attack
Fingerprinting UEFI configuration determines the choice of technique: whether Secure Boot is included, what certificates in db, whether dbx is relevant, whether SPI-record is protected.
Adjustments to the environment
• OS: GNU\Linux (full support for Chipsec) or Windows (limited, requires TestSigning mode)
• RAM: minimum 4 GB
• Tools: Chipsec (GitHub: chipsec/chipsec, active project), UEFITool (GitHub: LongSoft/UEFITool), efifibootgr
• Privileges: root (GNU\Linux) or admin + TestSigning (Windows)
• Wednesday: test stand. Chipsec downloads kernel driver with direct access to hardware resources - on production system it is the risk of freeze or damage
Checking the status of Secure Boot and the contents of the databases:
The result will indicate whether Secure Boot is enabled (SecureBoot variable), the operating mode (SetupMode, AuditMode), and the state of db/dbx/KEK. The common.bios_wp module assesses the risk of a physical attack: [PASS] – SPI recording is blocked by hardware, [FAIL] – SPI flash is open to modification.
Dumping the firmware image and searching for vulnerable binaries:
Received bios_dump.bin opens in UEFITool - he analyzes the image of the UEFI-file tree. It is worth looking for signed third-party DXE-drivers (candidates for BYOVB), built-in recovery utilities, old versions of bootloaders. Everyone .efi-File is exported and checked - the hash is compared to the public dbx list of the UEFI Forum to understand whether the binary is withdrawn or not.
Restrictions of Techniques and Blind Protection Zones
Measurid Boot with TPM - separate line of defense, operating in parallel with Secure Boot. TPM records the hashes of each component in the boot chain in PCR registers. Even if Secure Boot is bypassed and the bootloader is replaced, the PCR values will change. Systems with remote attestation (Microsoft Intune, corporate management modes) will find a discrepancy in the next report. On the BYOVB pentest, the BYOVB technology can give persistence, but on systems with TP attestation, the window narrows before the first verification cycle.
DISA STIG For Windows 10 and Windows 11, contain Configuration requirements for Secure Boot and firmware integrity verification. In mature infrastructures where STIG-baseline is used, dbx is updated centrally, the third UEFI certificate can be turned off - the space for the maneuver is minimal.
The main gap in the defense is a temporary window between detecting a vulnerable signed binary and its revocation via dbx. CVE-2024-7344 was discovered in July 2024, revocation - January 2025. Six months during which the signed binary was a worker. Martin Smolár of ESET calls this “a good result compared to similar cases” – which in itself indicates typical timing in the industry.
Most UEFI Secure Boot reports end with the conclusion of “renew dbx”. Correct? Yes. Useful? Not really. The real problem is in the trust architecture: Microsoft signs third-party UEFI binaries through an opaque revue process, and an application with a custom PE-boot that bypasses LoadImage/StartImage, passes it without question.
On Red Team projects, the picture repeats itself: the defense teams are confident that Secure Boot is a solved task, because the tick in the BIOS is worth it. Between "Secure Boot is included" and "loading chain verified end-to-end" - a chasm. Without TPM attestation, without centralized dbx management, without monitoring the contents of ESP - bypass of the Secureu Boot is the choice of the correct signed binary from the public dbx list.
A signed vulnerable bootloader delivered to ESP with admin rights will not cause any aerta to the SIEM until the time when the remote attestation records the PCR change. And if attestation is not set up, it will never cause.
The number of detected vulnerable signed UEFI-binary trees will grow - researchers from ESET and BINARLY are purposefully engaged in this. For pentesters, this expands the arsenal. For the defenders, the only working answer is TPM remote attestation and Secured-core configuration with disabling trust in third-party UEFI-certificate. Check your park: chipsec_main.py -m common.secureboot.variables will show whether you have a tick or real protection.
