AI
Why BIOS Is a Target for Nation-State Malware
BIOS malware is overkill for attackers targeting ordinary companies. For nation-state operations, it is the right layer. BIOS executes before any hypervisor, so compromising it can affect every virtual machine on a cloud server. It is present during hardware manufacturing when no OS exists. Leaked documents from espionage agencies, Vault 7 among them, confirm BIOS-layer persistence appears in real operational planning.
“And EFI threats are not just a theory.” — Kazuki Matsuo
About nine EFI bootkits exist in the wild. That small number reflects how poorly understood BIOS-layer capabilities are, not how rarely they are used.
The OS and Hardware Dependency Dilemma
Every existing BIOS bootkit faces the same trap. LoJax disables driver signature enforcement. CosmicStrand disables PatchGuard. Both still depend on OS-layer execution, so an antivirus driver the attacker missed can catch them. Staying inside pure BIOS avoids that detection risk but forces device-specific code: Dirty Bounce works only on Dell PowerEdge servers, Iron Chef only on specific HP ProLiant firmware.
UEFI boot services, memory allocators and device protocols among them, are destroyed when the OS loads. Without them, post-boot BIOS code cannot manage memory or reach hardware without writing a full driver stack from scratch.
Retaining BIOS in Memory After OS Boot
UEFI BIOS has its own memory manager and device drivers. Matsuo’s insight: hook the GetMemoryMap boot service and reclassify UEFI boot-services memory regions as runtime-services regions. The OS loader reads that modified map, concludes those pages must be preserved, and leaves them alone. BIOS code, including all protocol tables and drivers, survives the handoff.
“And therefore, we made Shade BIOS.” — Kazuki Matsuo
With the BIOS retained, malware can call UEFI HTTP and disk I/O protocols after the OS is fully running, with no OS driver involvement.
Five Engineering Problems That Make Retained BIOS Work
Five engineering problems must be solved before retained BIOS code runs correctly. Memory management: hook GetMemoryMap twice, preserving BIOS regions and carving out heap pages invisible to the OS loader. Address virtualization uses partial identity mapping so physical-address pointers stay valid. Boot-time resources and UEFI variables are copied or cloned before handoff. Device conflicts are resolved by calling disconnect-controller then reconnect-controller, reinitializing hardware with no device-specific register code. OS drivers self-repair in under 3 minutes. For exclusive control, CR8 replaces CLI/STI because retained code already contains STI instructions that would re-enable OS interrupts.
Demo: Bypassing Windows Defender Firewall from BIOS
Matsuo ran the same network connection twice. First, a kernel driver sent data to a C2 server on port 3333. Then a Windows Defender Firewall rule blocked that port. The driver returned an empty status: access denied. He walked through the Shade BIOS firewall bypass demo (30:26) next: Shade BIOS used retained UEFI network drivers to send process memory to the same C2 server. The firewall saw no OS traffic to block.
“Okay, I received the secret data.” — Kazuki Matsuo
The C2 server received the stolen data. Windows Defender logged nothing.
Detecting and Blocking Pure BIOS Malware
Shade BIOS cannot be observed while it operates. Detection happens before or after, not during. Runtime DXE modules reside in kernel memory after OS boot, so they can be dumped and analyzed statically. Matsuo demonstrated the CraDDinner detection demo (34:53): the open-source tool by Satoshi Tanda dumped resident modules, and a strings search confirmed the Shade BIOS module by name. For SMM-based variants, SMM isolation blocks them entirely. For government-procured systems, static memory inspection before deployment is the practical defense.
Notable Quotes
And EFI threats are not just a theory. Kazuki Matsuo · ▶ 2:13
And therefore, we made Shade BIOS. Kazuki Matsuo · ▶ 12:12
Okay, I received the secret data. Kazuki Matsuo · ▶ 31:01
Key Takeaways
- Existing BIOS bootkits depend on OS or hardware-specific code, limiting their stealth and portability.
- Shade BIOS retains UEFI drivers in memory post-boot, enabling C2 communication that bypasses OS security entirely.
- Runtime DXE modules live in kernel memory and can be found with CraDDinner; SMM isolation blocks SMM-based variants.