How do I distinguish genuine C2 beaconing from background application traffic?

Three signals in combination: regularity (C2 beacons often fire on a fixed interval whereas legitimate traffic is irregular), destination IP threat intelligence (a known C2 IP with a ThreatFox match is strong standalone evidence), and process lineage (a document viewer making outbound connections to a non-CDN IP is unusual). Any single one could be a false positive; the combination is what confirms the behavior.

Does LogTriage connect directly to the CrowdStrike API?

Not in the current version. LogTriage analyzes CrowdStrike Falcon Data Replicator (FDR) exports — the NDJSON files that Falcon produces for external analysis. You export from CrowdStrike, upload to LogTriage, and receive the analysis.

Which C2 frameworks does ThreatFox track?

ThreatFox tracks hundreds of malware families, including Cobalt Strike, VShell, Remcos, Sliver, Brute Ratel, and many commodity RATs. A ThreatFox IOC match with high confidence against a destination IP is treated as standalone strong evidence by LogTriage's floor-rule scoring — it floors the event score to 75 regardless of the additive base.

What should I do if C2 beaconing is confirmed?

Isolate the affected host immediately to stop active exfiltration, then investigate the full process tree to find the initial infection vector. Rotate all credentials accessible from that host's session, and review network logs for any data transferred outbound during the beacon window to scope what may have left.

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

Frequently Asked Questions

How do I distinguish genuine C2 beaconing from background application traffic?: Three signals in combination: regularity (C2 beacons often fire on a fixed interval whereas legitimate traffic is irregular), destination IP threat intelligence (a known C2 IP with a ThreatFox match is strong standalone evidence), and process lineage (a document viewer making outbound connections to a non-CDN IP is unusual). Any single one could be a false positive; the combination is what confirms the behavior.
Does LogTriage connect directly to the CrowdStrike API?: Not in the current version. LogTriage analyzes CrowdStrike Falcon Data Replicator (FDR) exports — the NDJSON files that Falcon produces for external analysis. You export from CrowdStrike, upload to LogTriage, and receive the analysis.
Which C2 frameworks does ThreatFox track?: ThreatFox tracks hundreds of malware families, including Cobalt Strike, VShell, Remcos, Sliver, Brute Ratel, and many commodity RATs. A ThreatFox IOC match with high confidence against a destination IP is treated as standalone strong evidence by LogTriage's floor-rule scoring — it floors the event score to 75 regardless of the additive base.
What should I do if C2 beaconing is confirmed?: Isolate the affected host immediately to stop active exfiltration, then investigate the full process tree to find the initial infection vector. Rotate all credentials accessible from that host's session, and review network logs for any data transferred outbound during the beacon window to scope what may have left.

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.

Try Live Demo → Analyze Your Own Logs