Analyzes malware C2 communication over HTTP, HTTPS, DNS, and custom protocols to reverse-engineer beacon patterns, command structures, data encoding, and infrastructure (primary servers, fallback domains, dead drops). Use after reverse engineering reveals network traffic needing protocol analysis or when building detection signatures for a framework like Cobalt Strike, Metasploit, or Sliver.
Analyzes malware C2 communication over HTTP, HTTPS, DNS, and custom protocols to reverse-engineer beacon patterns, command structures, data encoding, and infrastructure (primary servers, fallback domains, dead drops). Use after reverse engineering reveals network traffic needing protocol analysis or when building detection signatures for a framework like Cobalt Strike, Metasploit, or Sliver.
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.
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
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
