CrowdStrike Falcon

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

  1. DetectionSummaryEvent records that haven’t been escalated. Falcon already did detection work — the question is whether a human or automated workflow acted on it.
  2. NetworkConnectIPv4 destinations that aren’t known-good. Cross-reference against current threat intelligence rather than a static internal allowlist, since C2 infrastructure changes constantly.
  3. 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.
  4. Beacon-like timing in repeated NetworkConnectIPv4 events from the same process. Regular intervals are a stronger signal than any single connection.
  5. DnsRequest events resolving to recently-registered or algorithmically-generated domains.

Common patterns and what they mean

PatternLikely meaning
Regular-interval outbound connections from one processC2 beaconing
Unusual parent/child process chainLiving-off-the-land execution or initial compromise
Connection to a ThreatFox/AbuseIPDB-flagged IPConfirmed malicious infrastructure contact
Detection generated, no further action loggedProcess gap — detection without response
DNS requests to newly-registered domainsPossible 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.