Why CrowdStrike Can't See Your Firmware
CrowdStrike Falcon is a good product. It dominates the EDR market for a reason. It catches malware, detects lateral movement, and its threat intelligence feed is world-class. This is not a hit piece.
But there are things it cannot see. Not because of a bug or a misconfiguration, but because of where it sits in the system stack. And the things it cannot see are exactly what the most sophisticated attackers exploit.
The protection ring model
Modern x86 systems operate in a hierarchy of privilege levels. Understanding these levels is key to understanding what any security tool can and cannot see:
CrowdStrike's kernel sensor operates at Ring 0 with some Ring 3 components. That gives it visibility into processes, files, network connections, and some kernel events. It is a powerful position. But anything below Ring 0 is invisible to it.
Six things CrowdStrike cannot see
1. Firmware tampering (Ring -2)
Bootkits like BlackLotus and LoJax live in UEFI firmware. They execute before the operating system loads, before any kernel driver starts, and before any EDR agent initializes. CrowdStrike's sensor starts at boot time, which means the firmware has already been running for hundreds of milliseconds. A compromised firmware can hide processes, intercept disk reads, and feed clean data to any Ring 0 or Ring 3 inspector.
Inner Warden monitors firmware integrity through six mechanisms: Secure Boot chain validation, TPM PCR measurement verification, EFI System Partition hashing, UEFI variable tracking, ACPI table scanning, and boot timing anomaly detection. These checks run continuously, not just at boot.
2. Hypervisor manipulation (Ring -1)
A hypervisor rootkit (sometimes called a blue pill attack) inserts a thin virtualization layer beneath the OS. The entire operating system, including all security tools, now runs inside a virtual machine controlled by the attacker. From Ring 0, everything looks normal. The attacker intercepts any memory read, disk access, or hardware query before it reaches the real hardware.
Inner Warden detects hypervisor anomalies by monitoring MSR writes to critical registers (LSTAR, SMRR, FEATURE_CONTROL) via kprobe on native_write_msr. An unexpected change to the LSTAR register (which controls the syscall entry point) is a strong indicator of hypervisor insertion.
3. MSR writes
Model-Specific Registers control fundamental CPU behavior. Writing to LSTAR changes where syscalls go. Writing to SMRR controls System Management RAM access. Writing to IA32_FEATURE_CONTROL can disable hardware security features. These writes happen below the kernel's normal visibility and are not captured by standard EDR telemetry.
Inner Warden's kprobe on native_write_msr intercepts every MSR write and validates it against a known-good list. Writes to LSTAR, SMRR, or FEATURE_CONTROL trigger immediate alerts with the old value, the new value, and the process that attempted the write.
4. ACPI rootkits
ACPI (Advanced Configuration and Power Interface) tables contain executable bytecode that the kernel runs during power management events, device enumeration, and thermal management. A modified ACPI table can execute arbitrary code in response to hardware events like closing a laptop lid or plugging in a USB device. This code runs at Ring 0 privilege but is loaded from firmware-provided tables, making it invisible to file-based scanning.
Inner Warden's kprobe on acpi_evaluate_object monitors every ACPI method execution. It tracks which methods run, how often, and whether new methods appear that were not present at boot. An ACPI method executing a suspicious operation (network access, memory manipulation) triggers an alert.
5. TPM measurement failures
The Trusted Platform Module creates a chain of measurements during boot. Each component measures the next before handing off control. If a measurement does not match the expected value, it means something in the boot chain was modified. EDR tools typically do not read TPM PCR values because their focus is runtime behavior, not boot integrity.
Inner Warden reads TPM PCR registers and compares them against known-good baselines. A PCR mismatch in registers 0-7 (firmware, bootloader, OS kernel) indicates a boot-level compromise. The alert includes which register changed and the measured value for forensic analysis.
6. eBPF weaponization
eBPF programs run inside the kernel. An attacker with root access can load an eBPF program that hides processes, intercepts network traffic, or modifies system call results. This is sometimes called VoidLink. The eBPF program runs at Ring 0, is invisible to userspace process listings, and can selectively hide itself from tools that enumerate loaded BPF programs.
Inner Warden's LSM hook on bpf intercepts every eBPF program load. It checks the program type, the attach point, and the loading process. Unexpected eBPF programs (wrong type, wrong attach point, loaded by an unknown process) are blocked before they execute. This is not detection after the fact. It is prevention at load time.
The full stack comparison
Here is what each tool sees, side by side. This is not about which tool is "better." It is about coverage gaps.
CrowdStrike covers userspace, some kernel, and network. That is three layers, and it does them well. Falco adds deep kernel syscall visibility. Suricata handles network intrusion detection. Each tool has its lane.
Inner Warden covers all of those plus firmware, hypervisor, eBPF weaponization, AI agent protection, honeypot intelligence, and cross-layer correlation. In one binary. No fleet of agents. No cloud console required.
Why cross-layer correlation matters
Seeing individual layers is useful. Correlating across layers is where real detection happens. Here is an example CrowdStrike would miss:
Each event in isolation might be benign. An ACPI method fires during thermal management. An MSR write happens during a kernel update. A new process spawns from a service manager. But all three within a 500ms window, in that sequence? That is a firmware-initiated attack chain. You need visibility across all layers to see it.
The cost equation
CrowdStrike Falcon is priced per endpoint per year. Published estimates range from $8 to $25 per endpoint per month depending on the tier. For a 100-server deployment, that is $10,000 to $30,000 per year. For 1,000 servers, six figures.
Inner Warden is a single binary you deploy yourself. It runs on your hardware, stores data locally, and does not phone home. The sensor and agent together use about 25MB of RAM. You get firmware visibility, kernel monitoring, userspace detection, network analysis, AI agent protection, and a honeypot. All in one process.
They are great at what they do. We see what they cannot.
CrowdStrike built a category-defining product. Their threat intelligence, managed hunting, and incident response capabilities are among the best in the industry. If you are an enterprise with a SOC team and a seven-figure security budget, Falcon is a strong choice for EDR.
But EDR is not full-stack visibility. Ring 3 and Ring 0 are not the entire computer. Firmware, hypervisors, MSR registers, ACPI tables, eBPF programs, and AI agents are all attack surfaces that exist below or beside the EDR layer. If your threat model includes nation-state actors, supply chain attacks, or AI agent compromise, you need visibility into those layers too.
Inner Warden is not a replacement for CrowdStrike. It is the visibility layer underneath it.
What to do next
- Firmware Integrity Monitoring - deep dive into the six firmware checks Inner Warden performs.
- 22 Kernel Hooks: Kill Chain Detection in eBPF - the complete eBPF subsystem with all 30 programs.
- Cross-Layer Correlation Engine - 23 rules connecting firmware, kernel, userspace, network, and honeypot events.