Analyze UEFI malware cheaply by working from a firmware image rather than a live machine: extract and inspect its modules statically, then run dynamic tests in an emulator or a disposable test board with a known good image to restore. Open tools cover most of this, and the discipline matters more than the budget.
Why is UEFI malware different?
UEFI is the firmware that starts a computer before the operating system loads. MITRE ATT&CK lists system firmware modification, technique T1542.001, as a way for adversaries to persist: BIOS and UEFI underlie the computer's operation and can be modified. Code placed there can survive a reinstall of the operating system, and it runs before most security software starts.
NIST SP 800-193 explains why this matters. A successful attack on platform firmware could leave a system inoperable, perhaps permanently, or require reprogramming by the original manufacturer. The document frames defense in three parts: protect against unauthorized changes, detect them, and recover quickly and securely. Analysis supports the second and third.
What is the cheapest safe first step?
Do not boot the suspect machine to study it. Acquire the firmware image instead. Open source tools such as CHIPSEC, a platform security assessment framework, can read the contents of the SPI flash where firmware is stored and run checks on the platform's protections. Acquisition methods vary by hardware, and a hardware programmer clipped to the flash chip avoids trusting the software on the compromised machine.
Keep the original dump read only, hash it, and work on copies. That chain of custody costs nothing and protects every later conclusion.
How do you do static analysis?
Firmware images are structured volumes holding many modules. Parse the image to list them, then compare against a known good image of the same board and version from the vendor. A module that is present in the suspect image and absent in the reference is the first lead. So is one whose hash differs.
Then look at each suspect module as you would any executable. Check its imports, strings and what it hooks. UEFI modules often register handlers for boot services, so look for code that modifies how the next stage loads.
How do you do dynamic analysis on a budget?
You have two inexpensive routes.
Emulation. Open source emulators can run UEFI firmware images in a virtual machine, with snapshots and logging. Emulation is cheap and repeatable, but some malware checks for virtual hardware, and emulated chipsets differ from real ones.
A dedicated test machine. Buy a few identical used boards, flash the suspect image onto one, and watch what it does on the serial console, on the network and in the boot chain. Keep the reference image and a programmer ready so you can restore the board in minutes. Put the board on an isolated network segment.
A constructed example: an administrator finds that a laptop keeps reinstalling a rogue service after a clean OS install. They dump the firmware, hash it, and see it differs from the vendor image. Static comparison reveals one extra module. They flash the image onto a spare identical board, watch it drop a file on the first boot, then restore the board to the known good image.
What should you record?
Record the board and firmware version, the hash of every dump, tool versions, and what you saw at each stage. Report the finding to the hardware vendor so they can check for a signed update, and check whether Secure Boot settings and update controls were in place.
How to check or apply this
- Acquire the firmware image without booting the suspect system, and hash it.
- Fetch the vendor's reference image for the same board and version.
- Parse both and list modules that differ or are new.
- Inspect suspect modules statically before executing anything.
- Run dynamic tests in an emulator first, then on an isolated spare board.
- Keep a restore image and a programmer on hand, and log every step.
Quick check
Can reinstalling Windows remove UEFI malware?
Generally not. Firmware lives outside the operating system disk, which is why persistence there matters. Reflashing the firmware from a trusted image is the usual remedy, and sometimes board replacement.
Sources
- MITRE ATT&CK T1542.001, Pre-OS Boot: System Firmware
- NIST SP 800-193, Platform Firmware Resiliency Guidelines
- CHIPSEC, platform security assessment framework
Last reviewed: 18 October 2026.
