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

Analyzing Command and Control Communication When to Use 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: Step 2: Analyze Beacon Pattern Characterize the periodic communication pattern: Step 3: Decode C2 Protocol Structure Reverse engineer the message format from captured traffic: Step 4: Identify C2 Framework Match observed patterns to known C2 frameworks: Step 5: Map C2 Infrastructure Document the full C2 infrastructure and failover mechanisms: Step 6: Create Network Detection Signatures Build detection rules based on analyzed C2 characteristics: Key Concepts Term Definition Beaconing Periodic check in communication from malware to C2 server at regular intervals, often with jitter to avoid pattern detection Jitter Randomization applied to beacon interval (e.g., 60s +/ 15%) to make the timing pattern less predictable and harder to detect Malleable C2 Cobalt Strike feature allowing operators to customize all aspects of C2 traffic (URIs, headers, encoding) to mimic legitimate services Dead Drop Intermediate location (paste site, cloud storage, social media) where C2 commands are posted for the malware to retrieve Domain Fronting Using a trusted CDN domain in the TLS SNI while routing to a different backend, making C2 traffic appear to go to a legitimate service Fast Flux Rapidly changing DNS records for C2 domains to distribute across many IPs and resist takedown efforts C2 Framework Software toolkit providing C2 server, implant generator, and operator interface (Cobalt Strike, Metasploit, Sliver, Covenant) Tools & Systems 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 : 1. Filter PCAP for TCP port 8443 conversations and extract the TCP streams 2. Analyze the first few exchanges to identify the handshake/authentication mechanism 3. Map the message structure (length prefix, type field, payload encoding) 4. Cross reference with Ghidra disassembly of the send/receive functions in the malware 5. Identify the command dispatcher and document each command code's function 6. Build a protocol decoder in Python for ongoing traffic analysis 7. 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 Output Format

analyzing-command-and-control-communication