Skip to content

Module 06 — Dynamic Analysis — Network

Type 5 · Detonate & Detect — run a benign beacon simulator against a local sink, capture the HTTP C2 traffic, and write a Suricata/Snort signature for it, deliverable a suricata -T-validated rule that fires on the beacon (Cobalt Strike / Sliver URI patterns) but not on benign traffic. (Secondary: Eval Harness — the fire-on-beacon-not-benign framing is a small corpus test.) Go to the hands-on lab →

Last reviewed: 2026-06

Malware Analysis — the network is where malware reports home — and where analysts catch it in the act.

Difficulty: Intermediate  ·  Estimated time: ~4–6 hrs (study + lab)  ·  Prerequisites: Foundations

In 60 seconds

The network is where malware reports home — and where the analyst catches it in the act. C2 traffic is, at the protocol level, almost always normal traffic; the detection lives in the pattern, not the protocol. Beacons are regular (fixed interval, synthetic user-agent, freshly registered domain) where real traffic is irregular. The durable signature reads the request's invariants — URI structure, headers — not its reshapeable content. You run a benign beacon simulator against a sink, capture the traffic, and write a suricata -T-validated rule.

Why this matters

Most modern malware is not self-contained. It beacons for instructions, exfiltrates data, downloads payloads, or at minimum confirms it has reached an infected host. The network layer is both the malware's communication channel and the analyst's observation point. Understanding what a sample's network traffic looks like — the protocol, the timing, the user-agent, the request structure — is what allows you to write a network detection that fires on the next victim before the malware completes its mission. Cobalt Strike is the C2 framework you will see more than any other: a commercial adversary-simulation tool whose cracked copies are the post-exploitation backbone of countless real intrusions (it was the second-stage C2 in many Emotet and TrickBot campaigns). Its Beacon talks HTTP/HTTPS/DNS with operator-configurable callback intervals and jitter, and its malleable C2 profiles let an operator reshape the request to mimic a legitimate site — which is exactly why reading the invariant parts of the request, not its content, is the skill that produces a durable signature. (Cobalt Strike — MITRE ATT&CK S0154 documents the HTTP/HTTPS/DNS channels, the arbitrary callback timing, and the signature-modification features.)

Objective

Run a benign beacon simulator against a local network sink, capture the HTTP traffic, interpret the request structure, and write a network detection signature. Understand the categories of C2 protocol (HTTP, DNS, HTTPS) and why each presents a different detection challenge.

The core idea

The mental model

C2 traffic is, at the protocol level, almost always normal traffic — HTTP requests, DNS queries, HTTPS handshakes. The detection challenge is not the protocol; it is the pattern. Legitimate web traffic is irregular: it follows user interaction, varies in timing, uses realistic user-agents, real URLs. Beacon traffic is regular: fixed interval, consistent request size, synthetic user-agent, a domain registered last week with no reputation. The differences are visible — if you know what to look at.

FakeNet-NG and INetSim (which we approximate in this lab) serve the same function on the analyst's side as they do for the malware: they answer every protocol request with a plausible response so the sample continues executing and the analyst can observe the full protocol exchange.

mermaid sequenceDiagram participant M as Sample (beacon) participant D as DNS sink participant C as Fake C2 (HTTP) M->>D: resolve c2.example D-->>M: A 10.x.x.x (sink IP) M->>C: GET /jquery.min.js (check in) C-->>M: 200 OK — tasking Note over M,C: repeats every interval + jitter — the pattern is the tell The critical insight is that the content of the C2 response rarely matters for analysis — what matters is the structure of the request: the URI pattern, the User-Agent string, the HTTP headers, the beacon interval, and any encoding of the payload (Base64, XOR, JSON structure).

The gotcha

Don't anchor a signature on content the operator can reshape. Cobalt Strike's malleable C2 profiles let an operator change the body, the URI, even the user-agent with one config line, so a rule built on those collides with benign traffic and dies the moment the profile rotates. Read the request's invariants — the structural pieces that appear in every beacon from this implant — not the parts an operator tunes to mimic a real site.

Go deeper: DNS C2 is its own class

DNS C2 (T1071.004) uses the queries themselves as the channel — data encoded in the hostname (<base64-payload>.attacker.com) or in TXT responses. It is harder to detect because DNS is ubiquitous and high-volume, but it has tells: unusually long hostnames, high query rate to a single second-level domain, NX-domain-then-retry patterns, or suspiciously regular intervals. The Module 01 sink's DNS log is where you see this.

Learn (~3 hrs)

C2 protocol fundamentals - MITRE ATT&CK — T1071 Application Layer Protocol — read the technique and all subtechniques (HTTP, SMTP, DNS, Web Protocols). The sub-technique pages list real-world procedure examples from named groups. - The C2 Matrix (c2matrix.com) — a community-maintained comparison of C2 frameworks (protocol, evasion features, detection difficulty). Use it to understand the attack-side design decisions.

Traffic analysis - Malware Traffic Analysis — PCAP exercises — download one free exercise PCAP and analyse the C2 traffic. Read the associated blog post answer key after your analysis. - Brad Duncan — Identifying Malware via Network Traffic (SANS ISC) — a short practitioner piece on what to look for in a PCAP. (~15 min.)

FakeNet-NG - FakeNet-NG GitHub — Usage and Configuration — read the README and the configuration reference. Understand how FakeNet-NG differs from INetSim.

The dominant real-world C2 (~15 min) - Cobalt Strike — MITRE ATT&CK S0154 — read the overview and the C2-related techniques (T1071 application-layer protocol, T1571 encrypted channel, callback timing) to understand the framework whose default and malleable profiles your signatures most often have to catch.

Key concepts

  • Beacon interval and jitter: timing-based C2 detection
  • User-Agent anomalies: synthetic vs. real browser UAs
  • URI patterns as family identifiers
  • DNS C2: hostname encoding, TXT record exfiltration (T1071.004)
  • HTTP vs. HTTPS C2 detection: content vs. metadata
  • Suricata/Snort rule anatomy for HTTP C2
  • MITRE ATT&CK T1071.001 (HTTP), T1071.004 (DNS), T1132 (Data Encoding)
  • Real worked framework: Cobalt Strike (commercial C2, widely abused) — its Beacon over HTTP/HTTPS/DNS with malleable profiles is the C2 your network signatures most often target; read the request invariants, not the reshapeable content

AI acceleration

AI can generate a Suricata rule from a traffic description, but it frequently gets the field syntax wrong (wrong keyword for the HTTP header, wrong content modifier). Generate the rule, then validate it with suricata -T (test mode) — a rule that fails to compile is worse than no rule because it silently drops detections. If Suricata isn't available, use the OISF documentation to manually verify each keyword.

AI caveat

A model gets Suricata field syntax wrong often — wrong header keyword, wrong content modifier — and a rule that silently fails to compile is worse than no rule. Always gate AI-drafted rules through suricata -T before trusting them.

Check yourself

  • C2 traffic uses ordinary protocols. So what is it that a network detection actually keys on?
  • Why is a rule on Cobalt Strike's URI body fragile, while one on its named pipe or JARM is durable?
  • Why does the content of the C2 server's response usually not matter for writing your signature?

Comments

Sign in with GitHub to comment. Choose the type: Feedback (errors or suggestions on this page) · Hints (help for fellow learners — no spoilers) · General (anything else).