A supply-chain failure in Secure Boot key management allowed attackers to rebuild the firmware trust chain and install UEFI bootkits on real, production systems.
- Our DEF CON 33 Talk on UEFI Bootkit Development
- A Real-World Secure Boot Disaster
- What Went Wrong?
- References
- Emulation
At DEF CON 33 we delivered a talk on UEFI Bootkit Development and Kernel-Mode Rootkit Development. During the final part of that session, the audience saw how we used the PKfail flaw to install our UEFI bootkit on a physical device that was vulnerable because its Secure Boot trust chain relied on a Platform Key that should never have shipped in production systems.
We are publishing this project so that anyone can clearly understand what the PKfail flaw is and why it exists. The name refers to a real-world situation in which Platform Keys originally intended only for testing were accidentally reused by multiple vendors in production firmware. Even worse, the private key corresponding to one of those Platform Keys was later leaked in a public GitHub repository.
On affected devices, this meant that anyone with the leaked private key could sign arbitrary UEFI components, such as malicious UEFI applications (UEFI bootkits), and have them executed by the firmware as trusted elements. With control over the Platform Key, an attacker can rebuild the Secure Boot trust chain from the very root.
This repository collects our notes to help others understand the PKfail flaw, how Secure Boot actually works in practice, and how the different key databases (PK, KEK, db, dbx) interact. We also provide guidance on generating your own keys and certificates, modifying Secure Boot variables, and studying the trust chain from a defensive or offensive research perspective.
Additionally, we include references to related projects that allow you to replace Secure Boot keys inside a virtual machine (VMware Workstation / QEMU). Using them, you can create a controlled environment that emulates a PKfail-affected system and explore UEFI behaviour, bootloaders, and bootkits without needing vulnerable physical hardware.
PKfail is the name given by the well known security firm Binarly to a critical and widespread vulnerability in the Secure Boot ecosystem, caused by the long-term misuse of platform keys (PKs) that were reused across production devices. Many of these keys were explicitly marked as "DO NOT TRUST" or "DO NOT SHIP" and were originally intended only for internal testing.
The root cause traces back to American Megatrends Inc. (AMI), one of the most prominent UEFI firmware vendors (also known as an IBV, or Independent BIOS Vendor). AMI provided example PKs as part of their firmware development kits, which were never meant to be used in shipping products. However, these sample keys ended up being widely adopted by OEMs and board manufacturers without proper replacement.
As a result, at least 215 device models from manufacturers such as Acer, Dell, Gigabyte, Intel, Supermicro, Fujitsu, HP, Lenovo, and others have firmware that accepts these Platform Keys.
In December 2022, the Platform Key that had been improperly used across production devices was exposed in the public GitHub repository github.com/raywu-aaeon/Ryzen2000_4000. Although the repository was later deleted, it remains accessible through the following archives:
- Web Wayback Machine: Github raywu-aaeon/Ryzen2000_4000 Snapshot
- Web Wayback Machine: Github raywu-aaeon/Ryzen2000_4000 Download Zip file
Inside the archive, under "Keys/FW/AmiTest/", is the file "FW_priKey.pfx", an encrypted Platform Key explicitly marked "DO NOT TRUST", yet used in production firmware. The .pfx file is password-protected, but the password is just four characters long, abcd, making it trivial to crack.
This leak effectively grants anyone access to the root of trust on affected devices. A malicious actor can use the key to sign untrusted bootloaders or UEFI applications, allowing the installation of persistent and stealthy UEFI bootkits.
- Official Research & Primary Sources
- AMI Key Leak Evidence (Wayback)
- Vendor/Industry Documentation
- Impact & News Coverage
- Conference Talks
- Youtube Video: DEF CON 33 - Infecting the Boot to Own the Kernel (Exploiting PKfail to install a UEFI Bootkit)
- Youtube Video: Dave's Garage - Secure Boot Compromised! What You Need to Know by a Microsoft Engineer
- Youtube Video: LABScon24 Replay - Supply-Chain Failures in SecureBoot Management, Matrosov & Pagani
- Youtube Video: Binarly - Combining a Secure Boot Bypass with a Bootkit on Windows 11
- Youtube Video: Binarly - Critical Disclosure: PKfail - Undermine UEFI Secure Boot
- Youtube Video: Binarly - Proof of Concept for PKfail (Windows version)
- Youtube Video: Binarly - Proof of Concept for PKfail (Linux version)
Although PKfail is a real-world Secure Boot disaster that affected hundreds of production devices, the vulnerability can be safely reproduced in a controlled laboratory environment. By modifying the Secure Boot key databases inside a virtual machine, you can emulate the same conditions that allowed attackers to bypass the trust chain on affected hardware.
Using either of the following two projects, you can generate your own Platform Key (PK), replace the original firmware trust anchors, and reproduce a PKfail-like scenario where arbitrary UEFI binaries become trusted by the firmware:
📌 TheMalwareGuardian: VMware Workstation Secure Boot Custom Keys