Detecting C2 Beaconing in CrowdStrike Falcon Telemetry

Why this matters

Endpoint telemetry from CrowdStrike Falcon already does a lot of detection work for you, but raw NetworkConnectIPv4 and DnsRequest events still need correlation against current threat intelligence to separate “process made an outbound connection” from “process is talking to a known Cobalt Strike, VShell, or Remcos command-and-control server right now.” That correlation is what turns a mountain of benign-looking connection events into a small number of confirmed incidents.

Indicators to look for in Falcon telemetry

• event_simpleName: NetworkConnectIPv4 records to destination IPs that aren’t part of any known SaaS or CDN range
• A process making outbound connections at a suspiciously regular interval — classic beacon cadence rather than human-driven traffic
• ProcessRollup events showing a parent/child process chain inconsistent with the binary’s normal behavior (e.g. a document viewer spawning a shell)
• DNS requests resolving to recently-registered or algorithmically-generated domains
• Detections (event_simpleName: DetectionSummaryEvent) that were generated but not yet escalated or actioned

How LogTriage detects this

This is the same enrichment logic that powers LogTriage’s IP-based threat intelligence checks across every format: every destination IP a Falcon event touches is checked against ThreatFox, AbuseIPDB, OTX, and GreyNoise. A confirmed ThreatFox IOC match — a known Cobalt Strike, VShell, or Remcos C2 node, for example — is treated as strong standalone evidence: a single source independently confirming “this is malicious infrastructure” floors that event’s risk score to 75 regardless of what the additive signals alone would have produced, and pushes the event past the threshold where this system escalates to a full Claude-generated incident report instead of a routine summary.

Detection / evidence checklist

• List every distinct destination IP/domain contacted by the suspected process, with timestamps
• Cross-reference each destination against current threat intelligence feeds, not a stale internal blocklist
• Identify the full process tree — what spawned the beaconing process, and what it spawned afterward
• Check whether any data was sent outbound before containment (connection volume/duration is a reasonable proxy when payload inspection isn’t available)
• Isolate the host and rotate any credentials that were active in a session on that machine during the beacon window