We reimaged the disk, so the rootkit is gone - when is that claim wrong?

## The claim being made `We reimaged, so it is gone` is a statement about **coverage**: everything the adversary left is inside the region the image overwrote. That is often true. It is worth being precise about when it is not, because both failure directions are expensive - believing it when it is false leaves an operator resident on a rebuilt machine, and disbelieving it by default turns every rebuild into a hardware write-off. ## What a reimage actually rewrites A typical rebuild lays a fresh operating system onto the system volume. That covers: - **User-mode implants** - hooked libraries, injected code, anything living in a process or in files on that volume. Gone. - **Kernel drivers** - the driver binary and the service registration that loads it both live on the rewritten volume. Gone. What it does not necessarily cover: - **The EFI System Partition.** This is a small separate partition holding boot loaders. Many reinstall paths reformat only the operating system partition and reuse the existing boot partition. A boot component planted there runs *before* the freshly installed kernel and can compromise it on every boot, so the rebuilt machine is compromised from its first second. - **Platform firmware in SPI flash.** Not on the disk at all. Replacing the drive changes nothing. - **A peripheral's option ROM.** Firmware on an expansion card or a controller, which gets execution during platform initialisation. It travels with the card, not the disk. ## The mapping, stated once Match the remedy to the level, and read the table as a *correction* to the procedure-shaped claim rather than as a list to memorise. ## The preconditions that decide the real answer Rather than guessing, the honest form is a set of questions about what was possible on that hardware: 1. **What is the lowest level the operator demonstrably reached?** Administrative rights and a kernel driver is a very different finding from evidence that the boot component changed. The implant does not grant the level it hides at, so kernel presence is not evidence of firmware presence. 2. **Was the platform's flash write-protected?** Modern platforms can lock the flash so that runtime writes are refused, and a signed-update path is the only way in. If those protections were applied and the platform's update chain was not abused, a firmware implant was not reachable from software - which is exactly the sort of statement worth being able to make in advance. 3. **Was the boot partition rewritten, or reused?** This is a procedural detail nobody thinks about until it matters, and it is the single most common gap between `we reimaged` and `we removed it`. 4. **Was a verified-boot chain enforced?** If each stage refuses to run a successor whose signature it does not accept, a doctored boot component has to defeat that first. ## Two different claims about the boot stack Candidates routinely blur these, and the distinction decides what a rebuild is worth: - **Verified boot** is a *refusal*. Each stage checks the next against trusted keys and stops if it fails. It is preventive, it happens on the machine itself, and it cannot judge the layer that implements it - firmware validating the boot loader says nothing about the firmware. - **Measured boot** is a *record*. Each stage hashes the next into hardware registers before executing it. Nothing is refused; instead the hardware can later report a signed summary of what actually ran, which a separate party evaluates. It is the only claim in this area that a compromised kernel cannot compose, because the values were sealed by layers beneath it. One prevents, one testifies. A fleet with neither has no way to say a rebuilt machine booted the code it shipped with. ## The environment that makes this concrete The hardware layer of a fleet is where this decision actually bites: machines that get reimaged routinely as a matter of course, and hardware that gets redeployed between owners or departments. A rebuild-on-suspicion policy is cheap and sensible, and it is sufficient for the overwhelming majority of intrusions. But it silently assumes the implant level is above the image, and if a platform's flash was left unlocked or its boot partition is never rewritten, that assumption has no support behind it. The fix is not to distrust every rebuild - it is to make the assumption *true* in advance: flash write protection applied and verified, boot partitions rewritten as part of the standard rebuild, and a hardware-rooted measurement that lets the machine be asked what it booted rather than asked to describe itself. ## The other direction of the error Overreacting has a cost too. Declaring hardware unusable because an operator held administrative rights, with nothing to suggest anything below the kernel was touched, converts an ordinary rebuild into a procurement problem. The defensible position states its own basis: what level the operator reached, which protections were in place, and therefore what the rebuild covers.