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:

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 for the PCAP summarizer and beaconing detector.
• Wireshark and Zeek documentation (linked in frontmatter).