Command and Control (C2) Traffic Investigation

When You See This

1. 1

   IDS/IPS alert matching known C2 framework signatures (Cobalt Strike, Metasploit, Sliver)

2. 2

   Firewall logs show regular outbound connections to a single external IP at consistent intervals

3. 3

   DNS analytics detect high-entropy domain queries or beaconing patterns to recently registered domains

4. 4

   Network traffic analysis shows encrypted connections with unusual JA3/JA3S fingerprints

5. 5

   Proxy logs show repeated connections to URLs not matching any known business application

Investigation Steps

1. 1

   Characterize the suspicious traffic pattern

   Analyze the network connections to identify C2 behavioral indicators: regularity (beaconing), data size patterns, protocol anomalies, and destination reputation. Calculate the time interval between connections; C2 beacons typically have a base interval with jitter. SUNBURST used a 12-24 hour delay between DNS queries to appear as normal update checks.

   FirewallSIEM

   Splunk SPLMicrosoft KQLElastic Lucene

   index=firewall dest_ip="suspect_ip" | sort _time | delta _time AS interval | stats avg(interval) as avg_interval_sec, stdev(interval) as jitter, count, sum(bytes_out) as total_out, sum(bytes_in) as total_in by src_ip, dest_ip, dest_port

   index=dns query="*.suspect-domain.com" | timechart span=1h count | where count > 0

2. 2

   Research the destination infrastructure

   Check the destination IP/domain against multiple threat intelligence sources. Review WHOIS for recent registration, hosting provider reputation, and associated domains. Check TLS certificates for self-signed or recently issued certificates. In the SolarWinds case, the C2 domain avsvmcloud.com was registered years before the attack, demonstrating that domain age alone is not a reliable indicator.

   SIEMFirewall

   Splunk SPLMicrosoft KQLElastic Lucene

   index=proxy dest_domain="suspect-domain.com" | stats count, values(url) as urls, values(http_user_agent) as agents by src_ip | sort -count

   Decision Point

   If: Destination matches known C2 infrastructure in threat intelligence

   Yes → Confirmed C2. Immediately identify all internal hosts communicating with this infrastructure and begin containment.

   No → Unknown destination; not in threat intel does not mean safe. Continue behavioral analysis and endpoint investigation.

3. 3

   Identify the process responsible on the endpoint

   Correlate the network connections with endpoint process data to identify which process is generating the C2 traffic. Check if it is a legitimate process being abused (living-off-the-land) or a dropped binary. Examine the process tree to understand how the C2 implant was delivered.

   XDR

   Splunk SPLMicrosoft KQLElastic Lucene

   index=endpoint dest_ip="suspect_c2_ip" | stats count by dest_host, process_name, process_path, process_hash, parent_process_name | sort -count

4. 4

   Map all affected hosts

   Search for any other internal host communicating with the same C2 infrastructure. Also search for the same process hash, named pipes, or other IOCs across the entire endpoint fleet. In sophisticated attacks, the attacker deploys different C2 channels to different hosts as redundancy.

   SIEMFirewallXDR

   Splunk SPLMicrosoft KQLElastic Lucene

   index=firewall dest_ip IN ("c2_ip_1","c2_ip_2") OR dest_domain IN ("c2_domain_1","c2_domain_2") | stats count by src_ip | sort -count

   index=endpoint process_hash="c2_process_hash" | stats count by dest_host, process_path

5. 5

   Sever the C2 channel and contain

   Block the C2 destination at the firewall and DNS sinkhole level. Isolate all hosts with confirmed C2 communication. Important: block simultaneously; if you block the domain first, the attacker may receive an alert and accelerate their operations or switch to a backup channel. Coordinate with incident response for full containment.

   FirewallXDR

Common Mistakes

1. 1

   Blocking the C2 domain immediately without first identifying all affected hosts; you lose visibility into the full scope

2. 2

   Assuming C2 uses only one protocol; sophisticated attackers often have HTTP, DNS, and SMB-based backup channels

3. 3

   Not checking for the same C2 indicators across the entire network; one beacon typically means more

4. 4

   Treating the C2 as the primary threat rather than investigating what the attacker has already done through the C2 channel

Escalation Criteria

• Any confirmed C2 communication; indicates active compromise

• C2 traffic has been occurring for days or weeks (indicating undetected long-term access)

• Multiple hosts communicating with the same C2 infrastructure

Frequently Asked Questions

How did SolarWinds SUNBURST hide its C2 communications?

SUNBURST encoded data in DNS CNAME queries to avsvmcloud.com, mimicking legitimate SolarWinds update checks. It used a 12-24 hour delay between queries, stayed dormant for 2 weeks after installation, and checked for security tools before activating. The domain was registered years in advance. This made it nearly invisible to standard network monitoring.

What is beaconing and how do I detect it?

Beaconing is regular, periodic communication between a compromised host and an attacker C2 server. Detect it by analyzing outbound connection intervals; calculate the standard deviation of time between connections to each external destination. Low standard deviation (consistent timing) with jitter is a strong C2 indicator.

How do I practice C2 detection?

SOCSimulator includes scenarios with realistic C2 beaconing patterns across HTTP, DNS, and encrypted channels. Practice detecting and investigating C2 traffic in firewall and SIEM logs. Start free forever.