Flamingo Raises $4.5M Seed Round · Led by Vertex Ventures, bringing total funding to $6.7M to build the open, AI-native layer for IT and security.
Dmytro Koval
A rootkit scanner asks the operating system questions a rootkit has learned to answer. This guide maps the four floors a rootkit can hide on, why a scan from inside Windows can be lied to, what Secure Boot, memory integrity and the driver blocklist stop, which scanners still reach which floor in 2026, how to run a boot-time scan, and when a technician should skip the scan and rebuild.
Updated: October 2026
A machine comes back from the scan clean, and the odd behavior that opened the ticket carries on. Something is answering the scanner's questions on the operating system's behalf, and the answer is always "nothing here". This guide covers what a rootkit scanner can see, which layers sit below its reach, and how a technician decides between another scan, a boot-time scan and a rebuild.
The name is two old Unix words. "Root" is the all-powerful account, and a "kit" is the bundle of tools an intruder left behind to keep that access. The modern meaning is narrower: a rootkit is the hiding part of malware. It may carry a payload, such as a keylogger, a backdoor or a miner. Its own job is to make sure that payload never shows up in Task Manager, in a directory listing or in a scan result.
It does that by sitting between the program asking a question and the part of Windows that holds the answer. Ask Explorer to list a folder, and the rootkit removes its own files from the reply. Ask the kernel for the list of running processes, and the rootkit has already unlinked itself from that list. The operating system is not broken. It is answering truthfully from data that has been edited. If the words "kernel" and "driver" are new, our kernel explainer is the right ten-minute read first.
That is also why a rootkit is a different problem from a trojan or a worm. Those are delivery mechanisms. A rootkit is a persistence mechanism, and it is usually installed by one of them after the initial compromise is already done.
Rootkits are classified by how deep they sit, and depth decides both what they can hide and what it takes to find them.
User mode. The rootkit patches functions inside ordinary programs, such as the Windows API calls that list files or processes. It needs no special privilege and no driver, which makes it easy to write and easy to find: a tool that reads the raw file system instead of asking the API sees the difference at once. Linux has the same class in LD_PRELOAD rootkits, which Intezer traced through four years of OrBit forks in May 2026.
Kernel mode. A driver runs with the same authority as Windows itself. From there a rootkit can edit kernel data structures directly, unhook a security product's callbacks and remove its process from the active list. Modern Windows refuses to load an unsigned driver, so attackers found another way in: they ship a legitimate, signed driver that has a known bug, load it, and use the bug. The industry calls that bring your own vulnerable driver, or BYOVD. ESET's March 2026 count put the technique at the center of the ransomware toolkit: of roughly 90 "EDR killer" tools it tracked, 54 used BYOVD, between them abusing 35 signed drivers that Windows trusts by default.
The boot chain. A bootkit replaces or patches the files that load Windows, so it runs before the kernel exists and gets to decide what that kernel looks like. BlackLotus, analyzed by ESET in March 2023, was the first one seen in the wild that got past UEFI Secure Boot on a fully patched Windows 11 machine. It did that by bringing along old, validly signed Windows boot binaries with a known flaw (CVE-2022-21894) that Microsoft had patched but never revoked, and it sold on underground forums for $5,000. Once running, it switched off memory integrity by zeroing a registry value, suspended BitLocker and patched Defender's drivers so they returned without doing anything. In September 2025 ESET found HybridPetya, a Petya-style encryptor with a bootkit that bypassed Secure Boot through a different signed loader (CVE-2024-7344, fixed in January 2025). ESET saw no victims and read it as a proof of concept. The point stands: the technique is reproducible from public research.
Firmware. Below the boot chain sits the UEFI firmware on the motherboard. An implant there survives a disk wipe and a Windows reinstall, because neither touches it. LoJax, ESET's 2018 find, was the first UEFI rootkit confirmed in the wild. Bootkitty, published by ESET in November 2024, showed the same idea aimed at Linux, and ESET's line on it bears repeating: UEFI bootkits are no longer confined to Windows systems alone.
The floor a rootkit lives on sets the ceiling for any scanner that runs above it. That is the whole problem with scanning from inside.
Every scanner that runs on a live Windows machine depends on Windows to tell it what is there. It asks for the list of files, the list of processes, the registry keys under a service, the drivers in memory. A kernel-mode rootkit answers all of those questions. Mark Russinovich wrote the sharpest version of this in the RootkitRevealer documentation back in 2006: is there a sure-fire way to know a rootkit is present? "In general, not from within a running system."
The classic countermeasure is the cross-view scan. The scanner asks the Windows API for a directory listing, then reads the raw NTFS structures off the disk itself and compares the two. A file that exists on disk but is missing from the API's reply is a discrepancy, and a discrepancy is where a rootkit is standing. RootkitRevealer worked that way, and it is still the principle behind the rootkit option in modern scanners. The limit is also in Russinovich's text: a kernel rootkit can intercept the raw reads too. Nothing that runs inside the compromised kernel is above suspicion.
The replies in that thread say the same thing in practitioner language: catch the system lying about something, and treat any detector that runs on the infected OS as a false sense of security. The only scan that does not ask the suspect is one that runs when the suspect is not running. That is what a boot-time scan is: a small trusted environment that starts instead of Windows, reads the disk and the boot files directly, and reports what it finds before the rootkit gets a chance to load. It is not perfect either. A bootkit that runs before the recovery environment can lie to it, and a firmware implant sits below everything a disk scan can touch.
The reason rootkits moved from a common nuisance in 2010 to a specialist tool in 2026 is a stack of platform defenses, each guarding one floor. Knowing which switch guards which floor tells you what a given machine is exposed to.
Secure Boot guards the boot chain. Firmware checks the signature of every boot component against a trust list in the firmware, and refuses to start anything unsigned or revoked. It is only as good as the revocation list. BlackLotus worked because the vulnerable boot manager was signed and had not been revoked, and Microsoft's fix (KB5025885) is a revocation that, in Microsoft's words, cannot be reverted once applied, even by reformatting the disk. The enforcement phase was still listed as "date to be announced" on the page's September 2026 update. Checking the state of the switch on a fleet is covered in our Secure Boot check guide.
Secure Boot is also mid-way through a certificate change that every technician should know about this quarter. The 2011 Microsoft certificates that sign boot components started expiring in June 2026, and the Windows Production PCA 2011 that signs the boot loader expires on October 19, 2026. Microsoft's guidance is plain: devices without the 2023 replacements keep booting and keep installing standard updates, but stop receiving new boot-level protections, including revocation list updates. A fleet that misses the certificate rollout is a fleet whose Secure Boot cannot learn about the next BlackLotus. The r/sysadmin thread below is one administrator's May 2026 account of pushing that rollout across a mixed fleet, with the registry trigger and the check script in the comments.
Memory integrity, which Microsoft also calls hypervisor-protected code integrity or HVCI, guards the kernel. It runs the check that decides whether kernel code may execute inside a small virtual machine that the kernel itself cannot reach, so an attacker who has already won kernel privileges still cannot inject unsigned code. Microsoft's memory integrity page describes the model as a root of trust "that assumes the kernel can be compromised". It is on by default on new Windows 11 hardware, off on a lot of older machines because of driver compatibility, and the first thing BlackLotus turned off.
The vulnerable driver blocklist guards against BYOVD specifically. Since Windows 11 22H2 it is on by default, it is enforced whenever memory integrity, Smart App Control or S mode is active, and Microsoft updates it quarterly with deliveries through monthly updates. The same Microsoft page says plainly that it "isn't guaranteed to block every driver found to have vulnerabilities", and recommends pairing it with the Defender attack surface reduction rule that stops an application writing a vulnerable signed driver to disk in the first place. If you run App Control, the full blocklist can be applied as a policy, which the WDAC guide walks through.
The sequence matters. Each defense assumes the one below it held: memory integrity trusts the boot chain, the boot chain trusts the firmware's certificate store, and the driver blocklist is only enforced when memory integrity is on. A machine with Secure Boot off, memory integrity off and no driver blocklist is a 2012 machine in every way an attacker cares about.
The rootkit scanner market thinned out when platform defenses did the heavy lifting, and several tools that still rank for the search are no longer maintained. The useful question for each one is which floor it runs from and which floor it can reach.
| Tool | Runs from | Reaches | Status, October 2026 |
|---|---|---|---|
| Microsoft Defender Offline | Trusted environment outside the Windows kernel, after a reboot | Disk and boot sector, including MBR-level bootkits | Built into Windows 10 and 11, maintained; not on Arm or Server SKUs |
| Malwarebytes, "Scan for rootkits" option | Inside the running OS | User-mode and known kernel rootkits via cross-view | Maintained as a setting in the main product; the standalone Anti-Rootkit beta stopped at version 1.09 in 2015 |
| Kaspersky Virus Removal Tool | Inside the running OS, portable | Known rootkits by signature and heuristics | Maintained; replaced TDSSKiller, which Kaspersky retired and which LockBit affiliates later abused to shut down EDR |
| ESET SysRescue Live, Kaspersky Rescue Disk | Bootable USB, Windows not running | Disk, including files a kernel rootkit would hide | Maintained; the right tool when the machine will not boot cleanly |
| GMER | Inside the running OS | Kernel hooks, hidden drivers and services | Version 2.2.19882 is the latest; the site lists Windows XP through 10 only, with no release in years |
| Sysinternals RootkitRevealer | Inside the running OS | Cross-view of files and registry | Published 2006 for 32-bit XP and Server 2003; a reference, not a tool for 2026 |
| chkrootkit, rkhunter | Inside a running Linux host | Known Linux rootkits, modified binaries, LD_PRELOAD entries | Maintained, with the same inside-the-OS limit as everything above the line |
Two patterns fall out of the table. First, anything that runs inside the OS reaches the user-mode floor well, the kernel floor partly, and the boot and firmware floors not at all. Second, the tools people remember from the TDSS era are mostly gone or frozen, and a frozen scanner carries risk of its own. TDSSKiller is the cautionary case: Kaspersky retired it, copies stayed in circulation, and ransomware affiliates used its ability to stop protected services as a way to switch off EDR before encrypting.
So the practical kit for a Windows fleet in 2026 is short. Defender's regular scan plus the Malwarebytes rootkit option for the user-mode floor. Microsoft Defender Offline, or a bootable rescue disk, for the kernel and boot floors. And for the firmware floor, nothing you download: Secure Boot state, memory integrity state and the Secure Boot certificate status on the machine, read through Windows Security or a script, plus the OEM's firmware update. The Windows Security app exposes the first three in one place.
Microsoft Defender Offline is the boot-time scanner every Windows 10 and 11 machine already has, and Microsoft's documentation describes its job in one sentence: it runs "from outside the normal Windows kernel so it can target malware that attempts to bypass the Windows shell, such as viruses and rootkits that infect or overwrite the master boot record".
Three things have to be true before it will run. The user needs local administrator rights. The Windows Recovery Environment has to be enabled, and if it is not, Microsoft notes that the scan silently does nothing, so check with reagentc /info and enable with reagentc /enable first. And BitLocker should be suspended on the system drive, or the reboot into the scan environment prompts for the recovery key. It does not run on Arm devices or on Windows Server.
From the desktop: Windows Security, Virus and threat protection, Scan options, Microsoft Defender Offline scan, Scan now. Save work first, because the machine signs out and reboots within a minute. From PowerShell, one cmdlet does the same:
powershellStart-MpWDOScan
The scan takes about 15 minutes, the machine reboots back into Windows, and the results land in Windows Security under Protection history. Event ID 2030 in the Windows Defender operational log confirms the offline scan was scheduled, which is the line to look for when a user reports that "nothing happened". On a fleet, the same cmdlet goes out as a script. On OpenFrame that is a script run across a client's devices with the output collected, so the technician sees which machines scheduled the scan and which ones reported WinRE disabled.
One limit to keep in view. Defender Offline runs from the recovery environment on the same disk. A bootkit that has already replaced the boot manager runs before that environment does. For a machine where boot-chain tampering is on the table, a rescue disk written on a clean machine is the better tool, and the better answer is usually the next section.
For the floors a scanner cannot reach, the tells are in the places a bootkit has to touch to work. Microsoft's hunting guidance after BlackLotus, and ESET's analysis, point at the same handful.
The EFI System Partition is the first place to look. It is hidden from Explorer by default, but mountvol S: /S from an elevated prompt mounts it. Recently created or modified files under EFI\Microsoft\Boot, a boot manager that does not match the one Windows Update shipped, extra .efi files you did not put there, or a staging folder with recent timestamps are all out of place. BlackLotus also locked its files so the OS could not remove them, which shows up as access errors on files that should be deletable.
Then the registry and the drivers. A memory integrity value flipped to zero at HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity on a machine where policy sets it to one. Defender's early-launch driver failing to load, or the Windows Security app reporting that protection is off while the service claims to be running. BitLocker suspended with no record of anyone suspending it. Any of these on their own is a configuration ticket. Two together are an investigation.
Finally, the network. A bootkit's payload has to talk to somebody, and outbound connections from winlogon.exe or another system process to an address you do not recognize are the kind of signal our guide to indicators of compromise walks through. None of this requires a scanner. It requires knowing what a clean machine looks like, which is the strongest argument for a standard build and a baseline you can compare against.
The decision follows the floors. The evidence tells you which floor is in play, and the floor tells you what has a chance of working.
Unexplained behavior with nothing specific pointing at the kernel gets the ordinary path: a full Defender scan, a second opinion from a scanner with the rootkit option on, and a look at persistence points. Our malware removal guide covers that order, and it closes the ordinary ticket.
Signs that point at the kernel, such as a process that is visible in a raw tool and absent from Task Manager, a driver nobody installed, or a security product that keeps switching itself off, get a boot-time scan. If the offline scan finds and removes something, treat the machine as untrusted anyway and plan the rebuild, because a kernel rootkit that was there has had the run of the credentials on that machine. Rotate what it could have seen.
Signs that point at the boot chain or firmware skip the scan. Russinovich's 2006 advice still holds for this floor: if you are unsure how to remove a rootkit, reformat and reinstall. In 2026 that means a little more than a reimage. Wipe every partition, including the EFI System Partition, not only the Windows volume. Apply the OEM firmware update and confirm Secure Boot is on with the 2023 certificates in place before the new image goes on. And remember that Secure Boot revocations survive a reformat by design, so a machine that already had the BlackLotus mitigation applied keeps it. For a suspected firmware implant, a disk rebuild proves nothing. The board is the question, and replacing it is sometimes cheaper than the hours spent proving it clean.
A rebuild feels expensive next to a scan that says clean. The scan said clean because that is what the rootkit is for.
A rootkit scanner is a tool that asks the operating system questions a rootkit has learned to answer. It catches the user-mode floor, reaches part of the kernel floor, and cannot see the boot chain or the firmware from inside a running Windows. Boot-time scans fix the first half of that by reading the disk when Windows is not running. The platform defenses fix the rest in advance: Secure Boot with a current revocation list and the 2023 certificates, memory integrity on, and the driver blocklist enforced. Keep those three switched on across the fleet, and the scanner becomes the second opinion it was always meant to be.
For the floor where attackers now spend their effort, the drivers, the next read is how fileless malware lives in memory and signed binaries without touching the disk at all.
Head of Product Engineering
Hi! My name is Dmytro, but everyone calls me Dima. I’m a Software Developer and together with the development team, I help bring Flamingo to life — putting it on its feet from a technical perspective. Originally from Lviv, Ukraine 🇺🇦, but currently based in Spain, where I’ve been enjoying the blend of great weather, culture, and nature. I’m passionate about the mountains and love traveling — exploring new places and cultures really inspires me. These experiences constantly recharge me and give me a fresh perspective, both personally and professionally.
Still deciding?
Ask Mingo answers from our docs and customer stories.
Still deciding?
Ask Mingo answers from our docs and customer stories.