Capturing And Analyzing Malware Network Traffic

---
name: capturing-and-analyzing-malware-network-traffic
description: 'Captures and analyzes malware network traffic from a detonation: extracting C2
  endpoints, HTTP/DNS patterns, TLS metadata (JA3/SNI), and beaconing from a PCAP to build
  network IOCs and detection. Activates for requests to analyze malware PCAP, extract C2 from
  traffic, or study network behavior.'
domain: cybersecurity
subdomain: malware-analysis
tags:
  - malware
  - network-analysis
  - pcap
  - c2
  - dns
  - beaconing
version: 1.0.0
author: analyst-ai-pack
license: Apache-2.0
mitre_attack:
  - T1071.001
  - T1071.004
  - T1571
  - T1095
d3fend:
  - D3-NTA
  - D3-NTPA
references:
  - 'Wireshark User Guide — https://www.wireshark.org/docs/wsug_html_chunked/'
  - 'Zeek documentation — https://docs.zeek.org/'
---

# Capturing and Analyzing Malware Network Traffic

## When to Use

- You detonated a sample and captured a PCAP on the services guest, and need to extract its
  network behavior.
- You want C2 endpoints, HTTP/DNS patterns, TLS SNI/JA3, and beaconing intervals.
- You are turning traffic observations into network IOCs and detection signatures.

**Do not use** a single capture as the full C2 picture — staged samples reveal more on longer
runs or with the right context. Combine with binary config extraction.

## Prerequisites

- A PCAP captured from the isolated lab (capture on the analysis guest, not the victim).
- `tshark`/Wireshark, or Zeek for connection logs, or the bundled PCAP summarizer.
- The lab's simulated-internet IP so you can separate sample traffic from noise.

## Safety & Handling

- Capture from the services/analysis guest so the victim never hosts a sniffer.
- Defang all extracted domains/IPs/URLs before sharing.

## Workflow

### Step 1: Get a connection overview

Summarize conversations and protocols to see who talks to whom and how often:

```bash
python scripts/analyst.py summarize capture.pcap
```

### Step 2: Analyze DNS

List queried domains and resolved IPs. Look for DGA-like randomness, repeated NXDOMAIN, and
long TXT records (possible tunneling).

### Step 3: Inspect HTTP/HTTPS

For HTTP, examine URIs, methods, User-Agent (often unique/odd), and POST bodies. For HTTPS,
extract SNI and JA3/JA3S fingerprints since payloads are encrypted.

### Step 4: Detect beaconing

Compute inter-arrival times to the same destination. Regular intervals (with jitter) to one
host indicate C2 check-ins.

### Step 5: Build IOCs and detection

Produce a network IOC set (domains, IPs, URIs, JA3, User-Agent) and hand candidate signatures
to the Suricata/Zeek detection workflow.

## Validation

- Beaconing intervals are consistent and tied to a specific destination, not random browsing.
- Extracted SNI/JA3 reproduce across runs of the same sample.
- DNS and HTTP observations corroborate the C2 endpoints found in the binary's config.

## Pitfalls

- Mistaking simulated-internet responses for real C2 behavior; know your lab's IPs.
- Ignoring HTTPS because it is encrypted — SNI, JA3, and timing are still strong signals.
- Treating one short capture as complete; some C2 only beacons periodically.

## References

- See [`references/api-reference.md`](references/api-reference.md) for the PCAP summarizer and
  beaconing detector.
- Wireshark and Zeek documentation (linked in frontmatter).