# CrowdStrike Falcon
CrowdStrike Falcon is a cloud-native endpoint detection and response (EDR) platform built to identify, investigate, and stop adversary activity across enterprise endpoints in real time. It exists because traditional antivirus, which relies on static signatures and periodic scanning, cannot detect attackers who operate through legitimate system tools, inject code into memory, or move laterally before a signature ever exists. Falcon consolidates antivirus replacement, behavioral threat detection, threat intelligence, and managed hunting into a single sensor architecture, removing the need for multiple competing agents on a single host. Organizations deploy it when they need continuous visibility into what is executing on every endpoint, correlated against global adversary intelligence, with the capacity to respond remotely before damage spreads.
---
CrowdStrike Falcon is a Software-as-a-Service (SaaS) security platform delivered through a lightweight kernel-level sensor installed on endpoint devices. Its core function is endpoint detection and response, a category defined by continuous monitoring, behavioral analysis, alert triage, and active response capability on managed devices. Falcon extends beyond pure EDR into a broader platform that encompasses next-generation antivirus (NGAV), managed detection and response (MDR) through its OverWatch service, identity threat detection, cloud workload protection, and IT asset hygiene.
Falcon is not a traditional security information and event management (SIEM) system. It does not ingest arbitrary log sources from network devices, databases, or applications. It is also not a network detection and response (NDR) tool; it does not passively monitor packet flows or span ports. Its visibility is endpoint-centric, meaning it sees what happens on the host: process trees, file operations, registry changes, and network connections initiated from that host. Organizations that need full network coverage must pair Falcon with a dedicated network visibility tool.
Falcon exists in several commercial tiers. Falcon Go and Falcon Pro focus on NGAV and basic device control. Falcon Enterprise and Falcon Elite add full EDR (Falcon Insight), threat intelligence (Falcon Intelligence), and OverWatch managed hunting. Falcon Complete is a fully managed service where CrowdStrike personnel operate the platform on the customer's behalf. Each tier uses the same sensor; features are unlocked through licensing rather than separate agent installations. This is an important architectural distinction: one sensor, one console, one data stream, regardless of which modules are active.
Falcon should not be confused with cloud security posture management (CSPM) tools, which audit cloud infrastructure configurations. Falcon Horizon provides CSPM capabilities, but this is a module within Falcon, not the platform's primary identity.
---
Sensor Deployment and Data Collection
The Falcon sensor is a single binary that installs on Windows, macOS, and Linux endpoints. On Windows, it operates as a kernel-level driver, giving it visibility into system calls before they complete. This placement is critical because user-space processes, including malware, cannot hide activity from a kernel driver that intercepts system call events directly. On Linux, Falcon uses eBPF (extended Berkeley Packet Filter) on supported kernels as an alternative to a kernel module, reducing the risk of kernel panics while preserving visibility depth.
Once installed, the sensor continuously collects telemetry across six primary categories: process execution events (with full command-line arguments and parent-child relationships), file system writes and deletions, Windows Registry modifications, network connection attempts (including DNS resolution events), user logon and authentication activity, and inter-process communication including memory injection attempts. This telemetry is timestamped and streamed, not batch-uploaded, to the Threat Graph in near real time.
The Threat Graph
The Threat Graph is CrowdStrike's proprietary cloud-based graph database. It stores security events as nodes and relationships rather than flat log rows. A process is a node; the file it reads is another node; the network connection it opens is a third. The graph structure makes it computationally efficient to ask questions like "show me every process across all customers that has read a credential-related file, then made an outbound connection to an IP not seen before in this organization within the past 30 days." Because all Falcon customers contribute telemetry to the same Threat Graph (with tenant isolation preserving data boundaries), a detection pattern observed against one organization immediately becomes a detection signal for all others. This is the functional meaning of CrowdStrike's claim of processing over two trillion events per week: the scale of the dataset drives the accuracy of detection models.
Detection Layers
Falcon applies detection through four stacked mechanisms. First, signature matching applies against known malware hashes and indicators of compromise (IOCs), addressing commodity malware quickly. Second, machine learning models, trained on billions of file samples and behavioral sequences, score executables and process behaviors for probability of malicious intent. These models run both in the cloud and partially on the sensor itself, enabling offline detection without cloud connectivity. Third, behavioral Indicators of Attack (IOAs) identify attack techniques regardless of which specific tool is performing them. For example, an IOA fires when any process performs a sequence of actions consistent with credential dumping (reading the LSASS process memory, for instance) whether the tool involved is Mimikatz, a custom-built binary, or a living-off-the-land technique using comsvcs.dll. This IOA layer is the primary defense against fileless and zero-day attacks. Fourth, custom IOC rules allow security teams to add organization-specific detection logic: specific file hashes, IP addresses, domain names, or registry key patterns relevant to their threat model.
A Concrete Scenario: Detecting a BEC-Adjacent Credential Theft
Consider an attacker who has obtained valid VPN credentials through phishing. They authenticate to a corporate endpoint using the stolen credentials, open a PowerShell session, and attempt to dump credentials from memory using a renamed version of a known tool. Here is how Falcon's layers respond. The renamed binary does not match known hashes, so signature detection does not fire. The machine learning model scores the binary at moderate risk based on import table characteristics and code entropy but does not block it automatically (configured at the organization's chosen prevention level). The IOA layer, however, detects the behavioral sequence: a PowerShell process spawning a child process, that child process opening a handle to the LSASS process with memory-read permissions, followed by a write to a temporary file. This sequence matches the credential-access IOA pattern. Falcon blocks the operation, kills the offending process, and generates a detection alert. The OverWatch team simultaneously flags the session for human review because the logon originated from an unusual geographic location relative to the user's baseline. The security team receives a prioritized alert with the full process tree, the command-line arguments used, the parent process chain, the network telemetry associated with the session, and a one-click option to contain the host by isolating it from all network traffic except the Falcon management channel.
Response Capabilities
Falcon Insight's Real Time Response (RTR) shell allows security analysts to connect directly to a compromised endpoint through an encrypted, audited channel without requiring a VPN or RDP session. From RTR, analysts can run scripts, retrieve files for forensic analysis, terminate processes, delete malicious files, and modify registry keys. All RTR commands are logged and available for audit purposes, which matters for compliance and incident documentation.
---
Business and Security Impact
The fundamental business problem Falcon addresses is dwell time: the number of days an attacker remains undetected inside an environment. Industry reporting consistently places average dwell times between 16 and 21 days for organizations without mature detection capabilities. During that window, attackers map the network, escalate privileges, establish persistence mechanisms, and position for data exfiltration or ransomware deployment. Falcon's continuous telemetry collection and behavioral detection are designed to reduce dwell time to hours or minutes, changing the economic calculation for attackers who depend on extended access to complete their objectives.
For compliance-driven organizations, Falcon also addresses audit requirements. NIST SP 800-137 (Information Security Continuous Monitoring) requires that organizations maintain ongoing awareness of information security, vulnerabilities, and threats. Falcon's continuous telemetry collection and automated alerting satisfy this requirement operationally rather than through periodic assessments.
What Goes Wrong Without It
Organizations relying on traditional antivirus and periodic vulnerability scans create detection gaps that sophisticated actors deliberately exploit. The 2020 SolarWinds supply chain compromise is the clearest large-scale example. Attackers inserted a backdoor into a legitimate software update, which was then installed by thousands of organizations. The malicious code was signed, matched no existing signatures, and executed through legitimate processes. Traditional antivirus produced no alerts. Organizations with behavior-based detection tools capable of identifying anomalous process activity and unusual outbound network connections had a higher probability of detecting the associated lateral movement, even if the initial compromise was silent. CrowdStrike's threat intelligence team was among the first commercial vendors to publish detailed technical analysis of the SUNBURST implant's behavioral patterns, which then became detection content for Falcon customers.
A Common Misconception
Many organizations assume that deploying Falcon means they no longer need to patch systems or control user privileges. This is incorrect. Falcon detects and responds to attacks; it does not prevent vulnerabilities from existing or eliminate the damage that an attacker with legitimate administrative credentials can do before behavioral patterns become statistically anomalous. Falcon is one layer in a defense-in-depth architecture, not a replacement for vulnerability management, identity governance, or network segmentation.
---
CrowdStrike Falcon sits within the CDA Planetary Defense Model under two domains: Threat Intelligence and Detection (TID) and Situational Protection and Hardening (SPH). The TID domain is primary because Falcon's core value proposition is adversary-focused: it detects attacker behavior, correlates it against known threat actor profiles, and enables response before an operation completes. The SPH domain is secondary, addressed through Falcon's device policy enforcement, USB device control, firewall management, and vulnerability assessment modules.
CDA's methodology for TID is Predictive Defense Intelligence (PDI), summarized as "See the threat before it sees you." This phrase has operational meaning in the context of Falcon. PDI requires that organizations not wait for a file to be written to disk or an alert to fire before they understand what adversaries are targeting them. In CDA's application of Falcon, the platform is configured not as a passive alerting system but as an active intelligence feed. Falcon Intelligence module data, specifically adversary profiles tied to detected IOAs, is ingested into the organization's threat intelligence platform and mapped against the organization's crown-jewel assets. If Falcon identifies behavioral patterns consistent with a specific named adversary group targeting the financial sector, CDA analysts cross-reference that group's known TTPs from MITRE ATT&CK, identify which of those TTPs are not yet covered by existing Falcon prevention policies, and proactively tighten those policies or deploy compensating controls before the campaign reaches its next phase.
CDA also differs from standard Falcon deployments in how it handles OverWatch integration. Most organizations treat OverWatch alerts as escalation events. CDA treats every OverWatch notification as a threat intelligence input. Each hunting lead is documented, mapped to a MITRE technique, assessed for coverage gaps, and fed back into the detection engineering cycle. This creates a closed loop: the threat hunt finding today becomes the custom IOA or prevention policy refinement tomorrow.
Finally, CDA emphasizes sensor coverage completeness as a prerequisite to trusting Falcon's absence of alerts as meaningful signal. A Falcon deployment covering 70% of endpoints provides incomplete visibility; the 30% gap is where attackers will operate if they can identify it. CDA establishes sensor coverage reporting as a primary operational metric, targeting 98% or higher coverage with documented exception handling for devices that cannot run the sensor.
---
---
---