reverse-skills-max/vendor-new/analyst-ai-pack/skills/capturing-and-analyzing-malware-network-traffic/SKILL.md

name, description, domain, subdomain, tags, version, author, license, mitre_attack, d3fend, references

name	description	domain	subdomain	tags	version	author	license	mitre_attack	d3fend	references
capturing-and-analyzing-malware-network-traffic	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.	cybersecurity	malware-analysis	malware network-analysis pcap c2 dns beaconing	1.0.0	analyst-ai-pack	Apache-2.0	T1071.001 T1071.004 T1571 T1095	D3-NTA D3-NTPA	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).