What a CrowdStrike Falcon Teardown Reveals About the Limits of Endpoint Detection

Endpoint detection vendors do not publish their architecture. Occasionally somebody reads the binary and publishes it for them.

That is what happened on 1 August, when a researcher publishing as 0xDbgMan released Inside the Falcon: How CrowdStrike Catches You, a function-by-function teardown of the Falcon sensor. It is careful work, it names addresses and function signatures, and its final section collects every structural seam the author found in one table.

That table is the interesting part, and it is worth being precise about why. These are not vulnerabilities and the author does not present them as exploits. They are architectural consequences. Any vendor building an endpoint agent on the Windows kernel notification model arrives at most of the same ones. Read that way, the teardown stops being about CrowdStrike and becomes a fairly complete statement of what endpoint telemetry can and cannot do.

What the sensor actually is

The shape is worth understanding before the gaps make sense.

csagent.sys registers six kernel notification sources: process creation and exit, thread creation, image and driver loads, object handle opens, registry operations, and file operations through a minifilter. A Windows Filtering Platform layer watches connections. A user-mode service handles what the kernel cannot easily reach: DNS resolution, script inspection through AMSI, browser credential monitoring, device posture, and identity traffic such as Kerberos, NTLM and LDAP.

All of it funnels into one event object, and that object is handed to a matcher.

That design is correct, and it is the same conclusion we reached independently. Detection logic changes weekly. Kernel drivers should not. Decoupling them is the right call.

It is also, precisely, what took down a large part of the internet in July 2024. Content that loads into a running engine is code in every way that matters, and it had reached production without the validation a binary would have received.

The seams that matter

Twelve are listed. Three groups carry most of the weight.

1. The sensor can be installed, running, and not detecting

Several of the seams describe the same failure: detection silently does not run, and nothing records that it did not run.

If the engine pointer is null during early boot before content loads, dispatch passes everything unmatched. If configuration is still loading, the same. If a file hash or signature cannot be resolved, because the image is locked or unreadable or the process is racing start-up, the full rule match is skipped. Several detectors are gated behind configuration flags that are clear until policy lands.

In each case the agent is installed, the service is running, the console is green, and the rules are not being consulted. There is a window, and it is not visible from the endpoint.

2. The trust boundary is user mode

The object and registry callbacks check the previous processor mode and only fully act on user-mode callers. A kernel-mode actor, another driver or code running through an in-kernel exploit, is largely unfiltered.

The author calls this the single biggest structural assumption in the driver, and that seems right. It is also the reason bring-your-own-vulnerable-driver remains such a durable technique. Get to kernel and much of the endpoint's own observation stops applying to you.

3. The network view has hard limits

Four seams are about the network, and they are candid.

Connection tracking has a ceiling of 10,000 flows. Past it, new connections are not tracked, and an untracked flow cannot be reset-killed. Termination works by injecting a TCP reset after a verdict, so a short-lived beacon can finish before the reset lands: that is mitigation after detection, not prevention. Deep inspection operates on a cloned copy of the stream, which is subject to the usual segmentation and ordering evasions. And encrypted command and control is simply opaque. Only metadata survives.

The pattern underneath

Line the seams up and they resolve into one sentence.

This is not a criticism of the product. Depth on the endpoint is exactly what an EDR is for, and Falcon has more of it than most. But it does explain why the seams cluster where they do, and it is a clean argument for what belongs beside an EDR rather than inside it.

There is an obvious objection to all of this, and it is a fair one. Covering an endpoint agent's blind spots means collecting more, not less: full network flow records, driver and service creation, identity traffic, and the telemetry that proves a sensor is still reporting. That is precisely the data most teams drop first, because in a traditional SIEM it is the data that sets the bill.

The seams are only worth chasing if you can afford to keep the evidence.

Three of the categories above are answerable only from outside the endpoint:

• The blind windows are invisible locally by definition. They are visible externally as an absence: a host that reliably sends telemetry stopped sending it.
• The kernel trust boundary is best watched through driver and service creation telemetry correlated across a fleet, not from inside the boundary being crossed.
• The network limits are answered by network telemetry that has no flow ceiling and no reliance on payload inspection.

Answering them also means collecting from places an endpoint agent does not reach. Our collector takes network flow records, Windows event logs, journald and macOS unified logs, Kubernetes audit streams, OpenTelemetry over OTLP, SNMP device polling, and the industrial protocols that matter in utility and plant environments: Modbus, DNP3, IEC 104, BACnet, EtherNet/IP and S7comm. A compromised PLC does not run an EDR agent, and neither does the switch in front of it.

What we are building against them

We build Caver, a SIEM and detection platform, so we read this teardown as a checklist. Here is each seam, what the research found, and how we answer it.

The seam	What the teardown found in Falcon	How Caver answers it
Encrypted command and control	Deep inspection runs on a cloned copy of the stream, so segmentation and ordering evasions apply. Encrypted payload is opaque; only metadata survives.	Flow telemetry with JA3 and JA4 TLS fingerprinting, so a client stays identifiable even when its payload never will be.
Where detection rules live	Not in the driver. The engine arrives as an object loaded at runtime from cloud channel files and is called through a vtable.	The same architecture. Detection content ships and versions independently of the engine binary, so rules move at the speed of rules.
Making mixed sources comparable	Six kernel callbacks plus the user-mode service funnel into one internal event object, private to the sensor.	Normalisation to OCSF at ingest, so endpoint, network and identity events share one schema and one query.
A rule that silently does not run	A null engine, an unresolved hash or signature, or a config flag still clear all cause dispatch to pass unmatched. Nothing records that it happened.	A detection health surface answering which rules did not run in the last interval and why: skipped, errored, missing index, missing field, stale lookup.
Installed, running, not detecting	Early boot before content loads, the minifilter's registering state, raised IRQL, and config-gated detectors all open windows that are invisible locally.	Per-host, per-sourcetype cadence baselines that raise a notable when a host that reliably reports goes quiet.
What the endpoint cannot reach	Kernel-mode callers are largely unfiltered, flow tracking stops at 10,000, reset-based termination is racy, and the sensor's own fingerprints are enumerable.	Detection content aimed squarely at those gaps, including reconnaissance of the security stack itself, which is enumerable and therefore catchable before the attack.
Getting content to production	Content reached production without the validation a binary would receive. July 2024 is the consequence.	Validation, staged rollout, single-action rollback, and a loud signal when content fails to load rather than quietly matching nothing.

The one the market undervalues

Of everything in that table, detection health is the one we would point at first.

Every security platform on the market sells detection content. Very few of them can tell you whether the content actually executed. The failure is quiet by construction: a rule that does not run produces no alerts, and no alerts is indistinguishable from a quiet week. Teams discover it during an incident review, months later, when they find the rule that should have fired was referencing a field that stopped being populated in April.

The Falcon teardown documents the same class of failure at the kernel level. It is not a vendor problem. It is a category problem, and it is worth more attention than it gets.

If you run an EDR today

Practical takeaways that do not require buying anything:

• Alert on sensor silence. If a host that normally reports stops, that is a detection, not a monitoring gap. Most teams have the data required and no rule that uses it.
• Watch for enumeration of your security stack. Filter altitudes, callout identifiers and driver names are all discoverable by design. Someone listing them is a strong, early, low-noise signal.
• Treat driver loads as high value. The kernel trust boundary is real and durable.
• Do not rely on payload inspection for encrypted traffic. Build around flow metadata and TLS fingerprints instead, because that is what will still be there.
• Ask your vendors how detection content is validated and rolled out. July 2024 was not an anomaly. It was the predictable consequence of shipping code as data.

Credit

The research is 0xDbgMan's, not ours. The original is Inside the Falcon: How CrowdStrike Catches You, and it is worth reading in full: it is far more detailed than the summary here, and the function rename map at the end is a genuine contribution to anyone doing this kind of work. We have quoted its conclusions and added our own engineering response. Any errors of interpretation are ours.

One caveat we would apply to our own reading as much as anyone else's. This is one researcher's analysis of one sensor version. The seams are well argued and consistent with the disassembly presented, but they are hypotheses about behaviour rather than vendor documentation, and they should be verified before anyone builds a control or a purchasing decision on them.