How to Analyze CrowdStrike Falcon Detections
What’s in Falcon telemetry
The Falcon Data Replicator (FDR) stream exports endpoint telemetry as event_simpleName-tagged NDJSON — ProcessRollup2 for process execution, NetworkConnectIPv4 for outbound connections, DnsRequest for resolution events, UserLogon for authentication, and DetectionSummaryEvent for Falcon’s own detections. Each event carries cid (customer ID) and aid (agent ID), plus epoch-millisecond timestamps.
What to look at first
DetectionSummaryEventrecords that haven’t been escalated. Falcon already did detection work — the question is whether a human or automated workflow acted on it.NetworkConnectIPv4destinations that aren’t known-good. Cross-reference against current threat intelligence rather than a static internal allowlist, since C2 infrastructure changes constantly.- Process lineage in
ProcessRollup2. A parent/child relationship that doesn’t make sense for the binary (e.g., an office document application spawning a command shell) is one of the highest-value signals in endpoint telemetry. - Beacon-like timing in repeated
NetworkConnectIPv4events from the same process. Regular intervals are a stronger signal than any single connection. DnsRequestevents resolving to recently-registered or algorithmically-generated domains.
Common patterns and what they mean
| Pattern | Likely meaning |
|---|---|
| Regular-interval outbound connections from one process | C2 beaconing |
| Unusual parent/child process chain | Living-off-the-land execution or initial compromise |
| Connection to a ThreatFox/AbuseIPDB-flagged IP | Confirmed malicious infrastructure contact |
| Detection generated, no further action logged | Process gap — detection without response |
| DNS requests to newly-registered domains | Possible C2 domain generation algorithm (DGA) activity |
Where manual log review breaks down
Falcon generates an enormous volume of telemetry by design — that’s what makes it useful for incident response after the fact. But that same volume makes “scroll through NetworkConnectIPv4 events looking for something bad” an unrealistic manual workflow; the useful signal is almost always in correlating a destination IP against live threat intelligence, not in the raw connection event itself.
LogTriage checks every destination IP from Falcon telemetry against ThreatFox, AbuseIPDB, OTX, and GreyNoise. A single confirmed-malicious verdict from any one source is treated as strong standalone evidence — enough to floor that event’s risk score into the range that triggers a full AI-reviewed incident report, not just a routine summary line.
Frequently Asked Questions
- What's the difference between a CrowdStrike detection alert and a Falcon FDR event?
- Detection alerts (event_simpleName: DetectionSummaryEvent) are Falcon's own verdicts — the endpoint agent evaluated the behavior and flagged it. FDR (Falcon Data Replicator) events are raw telemetry: every process creation, network connection, DNS request, and file write, whether Falcon's prevention engine acted on it or not. For threat hunting and post-incident investigation, FDR gives you the full picture even where no alert was generated.
- Does LogTriage connect to the CrowdStrike API or require an FDR export?
- LogTriage analyzes FDR NDJSON exports — the raw telemetry files CrowdStrike produces for external analysis. You export from CrowdStrike (or from an S3 bucket if FDR is configured to deliver there), upload to LogTriage, and receive the analysis. Direct API integration is not required.
- Which FDR event types are most useful for detecting lateral movement?
- NetworkConnectIPv4/IPv6 (outbound connections for C2 detection), ProcessRollup2 (full process tree with parent lineage), DnsRequest (domain lookups for DGA or C2), and UserLogon/UserLogonFailed (internal lateral movement). The combination of process lineage and network destination is what distinguishes a C2 beacon from legitimate application traffic.
- What's the best way to scope a CrowdStrike FDR export for an incident window?
- Filter by timestamp on the affected host's aid (agent ID) for the suspected window, plus 30 minutes before the first suspicious event. The process tree context that explains an event often arrives before the event itself — a credential theft tool spawned five minutes before the first outbound C2 connection is the difference between a suspicious and a confirmed finding.
Related Resources
See this detection run on a real report
Try the live demo with a pre-loaded malicious log set — no signup required — or upload your own log file and get a full AI-reviewed threat report in minutes.