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

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.