The standard incident response workflow assumes the operating system is the lowest layer you need to reach. Boot the forensic image, run Volatility against the memory dump, pull the disk artefacts, run the EDR timeline. It is a complete picture of everything above ring 0 and it tells you nothing about what is below it.
UEFI firmware runs before the bootloader, before the kernel, before any driver the OS ever loads. A rootkit that lives there is not in any file system an imaging tool touches. It is not in any memory region Volatility walks. It is not visible to the EDR agent because the EDR agent had not started yet when the rootkit ran. Three confirmed cases - LoJax in 2018, CosmicStrand in 2022, BlackLotus in 2023 - established that this class of threat is not theoretical. Each one persisted across OS reinstalls and disk replacements because neither of those actions touches the SPI flash chip where UEFI firmware lives.
This is an analysis of all three cases and the detection tools that actually reach the right layer.
//Why Firmware Persistence Is a Different Problem
A modern x86 system boots in layers. UEFI firmware initialises the hardware, then hands control to the bootloader, which loads the OS kernel, which then loads drivers and user-space processes. Security controls sit at and above the OS layer: Secure Boot validates the bootloader signature, the kernel enforces driver signing, EDR agents run as privileged processes or kernel drivers.
Firmware lives in SPI flash - a separate chip on the motherboard, independent of the hard drive. Writing to it requires either a vendor update tool running with platform-level privilege, or direct hardware access to the chip. Reading it back out for inspection requires either the same elevated access or physical extraction. It is not mounted as a volume, does not appear in file system enumeration, and is not included in a standard disk image.
That is the structural property all three of these implants exploit. Not a specific vulnerability, not a single missed patch - the gap between where forensic tools look and where firmware lives.
//LoJax - APT28 Writes the First Chapter (2018)
ESET published the LoJax paper on 27 September 2018. The title was direct: LoJax: First UEFI rootkit found in the wild, courtesy of the Sednit group. Sednit is APT28 - also known as Fancy Bear, Sofacy, Strontium. The victims were government organisations in the Balkans and Central and Eastern Europe.
The implant itself is a trojaned version of LoJack, Absolute Software's legitimate laptop anti-theft product. LoJack is specifically designed to survive OS reinstalls - its whole value proposition is that it persists even if a thief wipes the drive and reinstalls Windows. It does this by placing an agent into the system firmware. APT28 modified this mechanism, replacing the Absolute Software callback with one that dropped SedUploader (a first-stage backdoor), XAgent, and Xtunnel, the network proxy tool.
The attack flow involved three custom tools. The first read the system firmware image from SPI flash. The second patched the image to include the malicious UEFI module. The third flashed the modified image back. On systems where SPI write protection was enabled, APT28 attempted to exploit a vulnerability in the BIOS write-protection mechanism that had been publicly known since 2015 - a configuration weakness allowing platform flash to be written from the OS when the protection bits were set incorrectly.
LoJax established two things. First, that nation-state actors had moved beyond OS-level persistence into firmware, and were doing so with tools sophisticated enough to handle SPI write protection. Second, that the legitimate firmware update ecosystem - BIOS update utilities, vendor-signed modules, OS-level flash access - provided exactly the capability an attacker needed if they could gain sufficient privilege.
//CosmicStrand - Five Years Undetected (2022)
Kaspersky published the CosmicStrand analysis in July 2022. The malware had been spotted earlier by Qihoo360, who named it Spy Shadow Trojan - Kaspersky's analysis was the first complete technical breakdown. The earliest samples dated to the end of 2016, meaning the implant had been in use for roughly five and a half years before a detailed public disclosure.
The infected firmware was found in images for ASUS and Gigabyte motherboards using the H81 chipset, a consumer-grade platform popular from around 2013 to 2016. The attribution is to an unknown Chinese-speaking threat actor. Victims were private individuals in China, Vietnam, Iran, and Russia - not the government or enterprise targets typical of APT campaigns, which makes the targeting rationale unclear.
The technical execution is more sophisticated than LoJax. Rather than replacing a single firmware module, CosmicStrand hooks into an existing DXE (Driver Execution Environment) driver - a standard component of the UEFI boot sequence. The hook patches the DXE runtime services table to insert malicious code that executes each time a specific UEFI boot service is called.
During the Windows boot process, this code sets up a further hook in the OS loader, which injects shellcode into the kernel as it starts. That shellcode makes an HTTP request to a hardcoded C2 server and executes whatever payload it receives. By the time Windows hands control to user-space processes - before any AV or EDR agent has started - the implant has already loaded and made its first callback. The C2 server was offline by the time Kaspersky published.
How the firmware images were modified is not established in the Kaspersky report. Two possibilities: supply chain compromise (boards shipped with modified firmware), or an initial access tool that gained sufficient privilege to write to SPI flash. The H81 chipset's write-protection configuration is not discussed in the paper. Given that the victims were private individuals, a supply chain route - modified boards sold through secondary markets - is plausible.
//BlackLotus - Secure Boot Bypass at $5,000 (2023)
ESET published “BlackLotus UEFI bootkit: Myth confirmed” in March 2023. The myth being confirmed was that a UEFI bootkit bypassing UEFI Secure Boot on a fully patched Windows 11 system was possible. It was not previously known to exist in the wild.
BlackLotus is not a firmware implant in the same sense as LoJax or CosmicStrand - it does not modify SPI flash. Instead it exploits CVE-2022-21894, a vulnerability known as “baton drop,” to install a bootkit that runs before the OS at each boot while bypassing Secure Boot's signature verification. CVE-2022-21894 was patched in Microsoft's January 2022 update, but the affected signed binaries were never added to the UEFI revocation list (dbx). BlackLotus brings its own copies of the vulnerable signed binaries to the system and uses them to exploit the vulnerability even on a fully patched machine.
ESET discovered six BlackLotus installers through code pattern analysis. The kit had been sold on hacking forums for USD$5,000 since at least October 2022 - a crimeware-grade capability, not a tool restricted to nation-state operators. The installer runs with admin privilege and stages the attack in multiple passes before the bootkit is in place.
What it disables and what it deploys
Once the bootkit is established, the payload has two components. The first is a kernel driver whose primary job is to prevent removal - it protects the bootkit files from deletion or modification. The second is an HTTP downloader that communicates with the C2 infrastructure and executes received payloads.
Before those run, the bootkit disables three OS security mechanisms specifically: BitLocker (full-disk encryption, preventing offline analysis), HVCI (Hypervisor-Protected Code Integrity, which would otherwise prevent the unsigned kernel driver from loading), and Windows Defender. Disabling HVCI is significant - HVCI is the control that prevents the kind of kernel driver abuse BlackLotus relies on. The bootkit switches it off before the OS has a chance to enforce it.
Microsoft's revocation response came in May 2023, adding the vulnerable signed binaries to the UEFI dbx revocation list. The update was rolled out cautiously - adding bootloader signatures to the revocation database can break dual-boot configurations and custom boot setups, so Microsoft staged the deployment rather than pushing it universally.
The BlackLotus source code was subsequently leaked to GitHub in mid-2023, making the underlying technique available for adaptation by any actor with the capability to weaponise it.
//The Detection Stack That Actually Works
The gap in standard IR tooling is not a failure of any individual product. Volatility is excellent at what it does. EDR platforms provide strong OS-level visibility. The gap is structural: all of these tools operate at or above the OS layer, and firmware implants operate below it. Detecting them requires tools that reach the same layer the implants occupy.
CHIPSEC
CHIPSEC is Intel's open-source platform security assessment framework. It reads SPI flash content directly, checks hardware write-protection configuration, audits UEFI variable store settings, and can compare a dumped firmware image against a known-good baseline. It runs as a kernel-level module and requires root or SYSTEM access.
For LoJax-style implants that modify SPI flash, CHIPSEC is the primary detection path. A firmware dump from a suspected system, compared against a clean dump from the same model at the same vendor revision, will show any added or modified UEFI modules. CHIPSEC also reports write-protection status - a system where SPI flash is not write-protected is inherently more vulnerable to this class of attack, and CHIPSEC will flag the misconfiguration directly.
The practical limitation: CHIPSEC requires physical or privileged access to the target, and the comparison requires a known-good baseline image. Motherboard vendors publish firmware update packages that contain the expected image; extracting and comparing against those is the standard workflow.
UEFITool
UEFITool is an open-source parser and editor for UEFI firmware images. Given a firmware dump - obtained via CHIPSEC, a vendor update package, or physical flash chip extraction - UEFITool parses the DXE volume, enumerates every module present, and allows inspection of individual module content. It is the right tool for answering “is there something in this firmware that should not be there.”
CosmicStrand's modification - a hook in an existing DXE driver rather than an additional module - illustrates the limitation. Diffing the module list may not catch a patched-in-place modification. Full binary comparison of each module against a reference image is the thorough path. For LoJax, which adds a module, the module list diff is sufficient.
TPM PCR Attestation
The Trusted Platform Module measures every component of the boot chain and stores the measurements in Platform Configuration Registers (PCRs). PCR[0] covers the firmware itself. PCR[7] covers the Secure Boot policy and the key databases (db, dbx, KEK, PK). Each measurement is a cryptographic hash of the component being recorded; if any component changes, the PCR value changes.
Remote attestation - where a remote party requests a signed quote of the TPM's PCR values - provides a mechanism to verify that a system booted with the expected firmware, expected Secure Boot configuration, and expected boot chain, without physical access to the machine. Azure Attestation, the TCG attestation protocol, and tools like tpm2-tools all implement this.
For BlackLotus, which modifies the Secure Boot policy to whitelist its own code, PCR[7] should reflect the change. A reference PCR[7] value from a clean system, compared against an attested value from a suspect system, will differ if the Secure Boot database has been modified. This is the detection path that requires the least physical access and is most compatible with remote enterprise management - but it requires that clean reference values were established before the compromise.
//The Detection Matrix
| Tool | LoJax | CosmicStrand | BlackLotus |
|---|---|---|---|
| EDR / AV (OS-level) | ✗ not in scope | ✗ not in scope | ✗ bootkit runs first |
| Disk image / file forensics | ✗ not in scope | ✗ not in scope | partial - bootloader files on EFI partition |
| Memory forensics (Volatility) | ✗ not in scope | ✗ not in scope | partial - kernel driver artefacts |
| CHIPSEC | ✓ SPI flash diff | ✓ DXE module inspection | ✗ does not modify SPI flash |
| UEFITool | ✓ module list diff | ✓ binary diff of DXE drivers | partial - EFI partition, not SPI |
| TPM PCR attestation | partial - PCR[0] if baseline exists | partial - PCR[0] if baseline exists | ✓ PCR[7] if baseline exists |
| BIOS event logs / UEFI variables | partial - flash write events on some platforms | ✗ | ✓ disabled HVCI/Defender events in Windows logs |
//The HVCI Signal in BlackLotus
BlackLotus turns off HVCI before deploying its kernel driver. That disablement - logged in Windows Event Viewer, observable through registry changes to the Device Guard configuration, and reflected in PCR[7] - is one of the stronger detection signals available at the OS level. Not because OS-level logs catch the bootkit itself, but because disabling a security control that is on by default is a significant event that should trigger investigation.
The same applies to BitLocker suspension and Windows Defender deactivation occurring together in sequence without a legitimate change-management explanation. Each individually has legitimate explanations. All three together, unexplained, is a pattern worth treating as compromise until proven otherwise.
//Paired with DDRop
The DDRop paper (DDR5 write-dropping via interposer, CCS 2026) and this class of firmware implant share the same structural property: both exploit the gap between where platform integrity checks operate and where the actual hardware state lives. DDRop showed that memory encryption attestation cannot detect dropped writes because the freshness guarantee is absent from the protocol. LoJax, CosmicStrand and BlackLotus show the same for boot chain attestation when the attacker acts before the measurement boundary.
The common lesson across both attack classes is that attestation and integrity guarantees are only as good as the layer they measure from. If the trust anchor is compromised before the measurement starts, the measurement is honest and meaningless.
Both also share the same detection requirement: you need tooling that operates at the same layer as the attack. For DDRop that means ECC error monitoring. For UEFI persistence that means CHIPSEC, UEFITool, and pre-compromise TPM baselines.