Analyzes malware command-and-control (C2) communication protocols to understand beacon patterns, command structures, data encoding, and infrastructure. Covers HTTP, HTTPS, DNS, and custom protocol C2 analysis for detection development and threat intelligence. Activates for requests involving C2 analysis, beacon detection, C2 protocol reverse engineering, or command-and-control infrastructure mapping.
Analyzes malware command-and-control (C2) communication protocols to understand beacon patterns, command structures, data encoding, and infrastructure. Covers HTTP, HTTPS, DNS, and custom protocol C2 analysis for detection development and threat intelligence. Activates for requests involving C2 analysis, beacon detection, C2 protocol reverse engineering, or command-and-control infrastructure mapping.
Reverse engineering a malware sample has revealed network communication that needs protocol analysis
Building network-level detection signatures for a specific C2 framework (Cobalt Strike, Metasploit, Sliver)
Mapping C2 infrastructure including primary servers, fallback domains, and dead drops
Analyzing encrypted or encoded C2 traffic to understand the command set and data format
Attributing malware to a threat actor based on C2 infrastructure patterns and tooling
Do not use for general network anomaly detection; this is specifically for understanding known or suspected C2 protocols from malware analysis.
Detection Gaps & Validation
Encryption hides the command set. Over TLS you see timing and endpoints but not the commands; recover the protocol by reversing the send/recv functions in Ghidra/dnSpy or by MITM with a planted key, not from the PCAP alone.
Fronting and CDNs mask the real destination. Domain fronting and use of legitimate services (Telegram, Discord, GitHub, CloudFront) make the SNI/Host look benign. Check the TLS SNI vs Host header mismatch and JA3/JA3S rather than trusting the destination domain.
Low-and-slow evades thresholds. Long sleep with high jitter and low-volume DNS TXT tunneling stay under beacon-count/entropy thresholds; widen the observation window and use RITA-style analysis over hours, not minutes.
Sandbox misses fallback channels. Secondary DNS/ICMP/dead-drop channels activate only when the primary is unreachable; a short detonation may never reveal them.
Confirm a hit: match JA3/JA3S and, for Cobalt Strike, extract the beacon config with 1768.py/CobaltStrikeParser, then verify extracted sleep/jitter match the measured beacon cadence and resolve infrastructure via passive DNS/Shodan before attributing.
False positives: software update checks, telemetry, NTP, and CDN keep-alives all beacon at regular intervals. Confirm destination reputation and process lineage before calling periodic traffic C2.
Prerequisites
PCAP capture of malware network traffic (from sandbox, network tap, or full packet capture)
Wireshark/tshark for packet-level analysis
Reverse engineering tools (Ghidra, dnSpy) for understanding C2 code in the malware binary
Python 3.8+ with scapy, dpkt, and requests for protocol analysis and replay
Threat intelligence databases for C2 infrastructure correlation (VirusTotal, Shodan, Censys)
JA3/JA3S fingerprint databases for TLS-based C2 identification
Workflow
Step 1: Identify the C2 Channel
Determine the protocol and transport used for C2 communication:
C2 Communication Channels:
━━━━━━━━━━━━━━━━━━━━━━━━━
HTTP/HTTPS: Most common; uses standard web traffic to blend in
Indicators: Regular POST/GET requests, specific URI patterns, custom headers
DNS: Tunneling data through DNS queries and responses
Indicators: High-volume TXT queries, long subdomain names, high entropy
Custom TCP/UDP: Proprietary binary protocol on non-standard port
Indicators: Non-HTTP traffic on high ports, unknown protocol
ICMP: Data encoded in ICMP echo/reply payloads
Indicators: ICMP packets with large or non-standard payloads
WebSocket: Persistent bidirectional connection for real-time C2
Indicators: WebSocket upgrade followed by binary frames
Cloud Services: Using legitimate APIs (Telegram, Discord, Slack, GitHub)
Indicators: API calls to cloud services from unexpected processes
Email: SMTP/IMAP for C2 commands and data exfiltration
Indicators: Automated email operations from non-email processes
Step 2: Analyze Beacon Pattern
Characterize the periodic communication pattern:
from scapy.allimport rdpcap, IP, TCP
from collections import defaultdict
import statistics
import json
packets = rdpcap("c2_traffic.pcap")
# Group TCP SYN packets by destination
connections = defaultdict(list)
for pkt in packets:
if IP in pkt and TCP in pkt and (pkt[TCP].flags & 0x02):
key = f"{pkt[IP].dst}:{pkt[TCP].dport}"
connections[key].append(float(pkt.time))
# Analyze each destination for beaconingfor dst, times insorted(connections.items()):
iflen(times) < 3:
continue
intervals = [times[i+1] - times[i] for i inrange(len(times)-1)]
avg_interval = statistics.mean(intervals)
stdev = statistics.stdev(intervals) iflen(intervals) > 1else0
jitter_pct = (stdev / avg_interval * 100) if avg_interval > 0else0
duration = times[-1] - times[0]
beacon_data = {
"destination": dst,
"connections": len(times),
"duration_seconds": round(duration, 1),
"avg_interval_seconds": round(avg_interval, 1),
"stdev_seconds": round(stdev, 1),
"jitter_percent": round(jitter_pct, 1),
"is_beacon": 5 < avg_interval < 7200and jitter_pct < 25,
}
if beacon_data["is_beacon"]:
print(f"[!] BEACON DETECTED: {dst}")
print(f" Interval: {avg_interval:.0f}s +/- {stdev:.0f}s ({jitter_pct:.0f}% jitter)")
print(f" Sessions: {len(times)} over {duration:.0f}s")
Step 3: Decode C2 Protocol Structure
Reverse engineer the message format from captured traffic:
Wireshark: Packet analyzer for detailed C2 protocol analysis at the packet level
RITA (Real Intelligence Threat Analytics): Open-source tool analyzing Zeek logs for beacon detection and DNS tunneling
CobaltStrikeParser: Tool extracting Cobalt Strike beacon configuration from samples and memory dumps
JA3/JA3S: TLS fingerprinting method for identifying C2 frameworks by their TLS implementation characteristics
Shodan/Censys: Internet scanning platforms for mapping C2 infrastructure and identifying related servers
Common Scenarios
Scenario: Reverse Engineering a Custom C2 Protocol
Context: A malware sample communicates with its C2 server using an unknown binary protocol over TCP port 8443. The protocol needs to be decoded to understand the command set and build detection signatures.
Approach:
Filter PCAP for TCP port 8443 conversations and extract the TCP streams
Analyze the first few exchanges to identify the handshake/authentication mechanism
Map the message structure (length prefix, type field, payload encoding)
Cross-reference with Ghidra disassembly of the send/receive functions in the malware
Identify the command dispatcher and document each command code's function
Build a protocol decoder in Python for ongoing traffic analysis
Create Suricata rules matching the protocol handshake or static header bytes
Pitfalls:
Assuming the protocol is static; some C2 frameworks negotiate encryption during the handshake
Not capturing enough traffic to see all command types (some commands are rare)
Missing fallback C2 channels (DNS, ICMP) that activate when the primary channel fails
Confusing encrypted payload data with the protocol framing structure
