analyzing-command-and-control-communication

name	analyzing-command-and-control-communication
description	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.
domain	cybersecurity
subdomain	malware-analysis
tags	["malware","C2","command-and-control","beacon","protocol-analysis"]
version	1.0.0
author	mahipal
license	Apache-2.0
nist_csf	["DE.AE-02","RS.AN-03","ID.RA-01","DE.CM-01"]

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:

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.all  rdpcap, IP, TCP
 collections  defaultdict
 statistics
 json

packets = rdpcap()


connections = defaultdict()
 pkt  packets:
     IP  pkt  TCP  pkt  (pkt[TCP].flags & ):
        key = 
        connections[key].append((pkt.time))


 dst, times  (connections.items()):
     (times) < :
        

    intervals = [times[i+] - times[i]  i  ((times)-)]
    avg_interval = statistics.mean(intervals)
    stdev = statistics.stdev(intervals)  (intervals) >   
    jitter_pct = (stdev / avg_interval * )  avg_interval >   
    duration = times[-] - times[]

    beacon_data = {
        : dst,
        : (times),
        : (duration, ),
        : (avg_interval, ),
        : (stdev, ),
        : (jitter_pct, ),
        :  < avg_interval <   jitter_pct < ,
    }

     beacon_data[]:
        ()
        ()
        ()