C2 And Network Analysis

Prerequisites

• Target system, dependencies and environment configured.

Usage

Purpose

Most malware phones home — to receive commands, exfiltrate data, or pull the next stage. Understanding that command-and-control (C2) channel tells you how the malware operates, what an attacker can do through it, and — crucially for defence — how to detect it on the network. This skill covers analysing malware's C2 communication: the protocol, the beaconing pattern, and the encoding, turning it into network indicators and detections.

When to use it

When a sample communicates over the network (most do) and you need to understand or detect that channel. It combines dynamic analysis (observing the traffic), code analysis (understanding the protocol), and detection output (network signatures) — and it feeds threat-hunting's beaconing detection directly.

Procedure

1. Capture the C2 traffic in the isolated lab. Detonate with network capture running and INetSim (or a controlled internet gateway) answering, so you observe the callbacks safely. The dynamic-analysis and packet-capture skills provide the setup:

   # detonate in lab; Wireshark/tcpdump capturing; INetSim answering the callbacks
   

2. Identify the protocol and destination. What does it talk — HTTP(S), DNS, raw TCP, a custom protocol? To where (domain/IP, and how it's resolved — hardcoded, DGA, or fetched)? HTTPS C2 hides content but still shows metadata (destination, timing, TLS fingerprint).
3. Characterise the beaconing. C2 typically beacons — connecting to the C2 at intervals to check for commands. Note the interval, jitter (randomisation to evade detection), and the request pattern. Regular beaconing is a strong, detectable signature (feeds the threat-hunting beaconing skill):

   # regular-interval connections to one destination = beaconing (the key detection signal)
   

4. Decode the communication. C2 data is usually encoded/encrypted — base64, XOR, custom encoding, or TLS. From dynamic capture you see the wire format; from code analysis (disassembly skill) you can recover the encoding/encryption scheme and keys, letting you decode what's actually being sent (commands, exfil, config). Reversing the protocol is what reveals the channel's real capability.
5. Understand the capability — what commands the C2 supports (shell, download/upload, persistence, lateral movement) tells you what an attacker can do through this malware, which shapes IR and impact assessment.
6. Produce network detections — the destination indicators (domains/IPs/URLs), the beaconing pattern, TLS/JA3 fingerprints, and any distinctive request signatures become network IoCs and detection rules (Sigma/Suricata, YARA for the protocol handler). Behavioural signatures (beacon pattern, request structure) are more durable than the IP/domain (which rotates).

Cheatsheet

capture in the LAB (dynamic-analysis + packet-capture setup)
  detonate + Wireshark/tcpdump + INetSim answering -> observe callbacks safely

characterise the channel
  protocol      HTTP(S) | DNS | raw TCP | custom  (HTTPS hides content, shows metadata)
  destination   domain/IP, resolution (hardcoded / DGA / fetched)
  BEACONING     interval + jitter + request pattern   <- key detectable signature
  encoding      base64 / XOR / custom / TLS
                (code analysis recovers the scheme+keys -> decode the real traffic)

understand capability: shell? download/upload? persistence? lateral movement?
  -> shapes IR + impact

produce NETWORK detections
  destination IoCs (domain/IP/URL) — rotate, low durability
  BEACON pattern + request structure + JA3/TLS fingerprint — durable, invest here
  -> Sigma/Suricata rules, feeds threat-hunting beaconing detection

Reading the C2

• Regular-interval beaconing to one destination = the classic, detectable C2 signature; the interval-and-jitter pattern is a durable network detection even when the destination IP rotates. The highest-value observation for defence.
• HTTPS C2 = content is encrypted, but destination, timing/beacon pattern, and TLS/JA3 fingerprint are still visible and detectable — don't assume encrypted means undetectable.
• A recovered encoding/encryption scheme (from code analysis) = you can decode the actual commands and exfil, revealing the channel's real capability and content — worth the reversing effort for a significant threat.
• DGA or fetched C2 resolution = the destination changes, so blocking one domain is futile; the behavioural signature (beaconing, request structure) is what to detect instead.
• The command set (shell, file transfer, lateral movement) = the attacker's capability through this malware; critical for IR impact and scoping.
• Behavioural network signatures + destination IoCs fed to detection and hunting = analysis turned into network defence.

Pitfalls

• Capturing C2 without lab isolation. Letting the malware actually reach its real C2 tips off the attacker and may pull live payloads; use INetSim/controlled gateway in the isolated lab.
• Assuming HTTPS C2 is undetectable. Encrypted content still leaves destination, beacon timing, and TLS fingerprints — detectable metadata. Don't give up at "it's encrypted".
• Relying only on IP/domain indicators. C2 infrastructure rotates (DGA, fast flux); a domain/IP block is short-lived. Extract the durable behavioural signature (beacon pattern, request structure) too.
• Not reversing the protocol when it matters. For a significant threat, recovering the encoding/keys reveals the actual commands and exfil — the channel's real capability — which surface analysis misses.
• Stopping at observation. The goal is detection and impact understanding; feed the beacon pattern and command capability into detection-engineering, threat-hunting, and IR.

References

• Practical Malware Analysis (network/C2 chapters)
• Wireshark, INetSim documentation; JA3/JA3S TLS fingerprinting
• The dynamic-analysis-sandboxing, packet-capture-analysis, and threat-hunting (beaconing) skills
• MITRE ATT&CK — TA0011 (Command and Control), T1071, T1568 (DGA)

Inputs

• Relevant source code, logs, network traces, or system specifications.

Outputs

• Analysis findings, security audit report, or generated code artifacts.