From Packets to Pictures: 7 Network Visualizations for DFIR

A visualization is useful only if it helps an analyst prove or reject a hypothesis. A PCAP is still the evidence. The graph is a way to see structure faster: who talked to whom, when, over which protocol, how often, and how much data moved.

In DFIR, this matters because raw packet lists are too flat. A compromised workstation might generate DNS lookups, TLS sessions, Kerberos traffic, SMB authentication, and outbound transfers in the same five-minute window. Looking at those packets one by one hides the shape of the event. A good visualization exposes that shape without replacing packet-level validation.

This article covers seven visualizations that are worth using during PCAP analysis. For each one, the important question is the same: what does the suspicious pattern look like in the actual capture?

TL;DR

• Topology graphs expose host relationships, fan-out, and lateral movement paths.
• Flow diagrams show where most bytes moved and whether data left the expected boundary.
• Protocol treemaps reveal protocol mix changes, weak protocols, and tunneling candidates.
• Heatmaps expose timing patterns such as C2 beaconing, scans, bursts, and off-hours activity.
• Packet-size histograms help separate human activity from repetitive automation.
• GeoIP and ASN maps add external context, but must be verified against DNS, SNI, certificates, and business logic.
• IP-space maps make subnet sweeps and reconnaissance visible at scale.

1. Node-Link Connection Graphs

A node-link graph turns hosts into nodes and conversations into edges. Edge color can represent protocol. Edge weight can represent bytes, packets, or session count. For incident response, this is the fastest way to see whether a host is acting like a client, server, scanner, relay, or staging point.

What It Shows in the PCAP

In packet terms, the graph is built from 5-tuples and protocol metadata: source IP, destination IP, source port, destination port, protocol, timestamps, packet counts, and byte counts. For SMB or Kerberos, the graph becomes more useful when authentication context is available. A single workstation creating new SMB sessions to multiple servers is a different signal from a workstation making normal HTTPS requests to SaaS providers.

DFIR Example: Lateral Movement

A capture from a user VLAN shows 10.20.14.37 opening SMB sessions to 10.20.1.10, 10.20.1.11, 10.20.2.20, and 10.20.2.21 within two minutes. In the PCAP, the evidence is TCP/445 fan-out, SMB2 session setup, NTLMSSP authentication, tree connects, and DCE/RPC traffic. The graph makes the fan-out obvious; the packet details confirm whether it was admin activity, vulnerability scanning, or adversary movement.

2. Conversation Flow Diagrams

Flow diagrams show how traffic volume moves between sources and destinations. The width of the line usually represents bytes or packets. This view is useful when the question is not "who connected?" but "where did the data go?"

What It Shows in the PCAP

A flow diagram is backed by byte counters, session direction, timestamps, and sometimes protocol labels. If an internal host sends 800 MB to an external IP over TLS, the visual line should map back to TCP sessions with matching byte counts. If the same host first pulled files from SMB and then sent data outside, the sequence matters.

DFIR Example: Exfiltration Through a Staging Host

A PCAP shows 10.30.8.12 reading large files from 10.30.2.50 over SMB, then sending a long TLS stream to 203.0.113.77. The flow diagram highlights the path: file server to workstation, workstation to external endpoint. In the packets, you should see SMB read activity, a later TCP/TLS session, high outbound byte count, and timing that links the two stages. Without the timing and byte counters, "exfiltration" is only a hypothesis.

3. Protocol Distribution Treemaps

A protocol treemap shows how much of the capture belongs to each protocol. It is a coarse view, but a useful one. You can see when a capture is mostly HTTPS, when DNS dominates, or when a weak protocol appears where it should not.

What It Shows in the PCAP

The treemap is a summary of parser output: DNS, HTTP, TLS, SMB, LDAP, Kerberos, FTP, Telnet, RDP, SIP, SSDP, and unknown traffic. The useful part is not the rectangle itself. The useful part is the delta from expectation. Telnet in a production network, FTP credentials in cleartext, or a large "unknown" bucket over TCP/443 should trigger deeper review.

DFIR Example: Tunneling Candidate

A branch-office capture shows DNS consuming far more traffic than normal. In the PCAP, the suspicious pattern is not just "many DNS packets." Look for long high-entropy subdomains, repeated TXT queries, high NXDOMAIN ratios, unusual resolver destinations, and stable request timing. The treemap tells you where to look. The DNS records decide whether the hypothesis survives.

4. Activity Heatmaps (Time-Based)

A time heatmap places activity on a time axis. The second axis can be source IP, destination IP, port, protocol, or subnet. Color intensity represents packet count, byte count, session count, or alert count.

What It Shows in the PCAP

Heatmaps are good at exposing periodic behavior. In the capture, that means repeated connections with similar intervals, similar packet counts, similar byte counts, and stable destinations. Beaconing is one example. Scheduled backup, monitoring, telemetry, and update checks can create similar patterns, so the destination and payload context still matter.

DFIR Example: C2 Beaconing

A workstation at 10.40.6.18 opens TLS sessions to 198.51.100.44 every 60 seconds for 30 minutes. Each session contains a small client-to-server payload and a small server response. The PCAP evidence is the interval, destination stability, DNS or SNI context, TLS certificate metadata, and low but consistent byte counts. The heatmap makes the rhythm visible. Packet inspection determines whether it is C2 or a legitimate agent.

DFIR Example: DDoS Start Time

During a volumetric event, a heatmap can show the first spike, peak window, and recovery point. In the PCAP, validate source distribution, destination ports, SYN/ACK ratios, UDP payload similarity, and whether the traffic was reflected from services such as DNS, NTP, SSDP, or CLDAP.

5. Packet Length Frequency Histograms

A packet-length histogram plots packet size against frequency. It looks simple. It is useful because many automated tools generate repetitive packet structures.

What It Shows in the PCAP

Human-driven browsing, file access, and interactive sessions usually produce varied packet sizes. Scanners, brute-force tools, worms, and simple bots often produce tight spikes because they repeat the same request or handshake. The histogram should be tied back to a protocol and a source host. A spike without context is just a spike.

DFIR Example: SSH Brute Force

A capture from a bastion host shows thousands of short TCP sessions to port 22. The histogram has a narrow spike because the same SSH negotiation and failed authentication pattern repeats. Validate with timestamps, source IP spread, TCP resets or FINs, server banners, and whether the same username pattern appears in related logs. The PCAP may show the structure of the attempt even when the encrypted credentials are not visible.

6. GeoIP & ASN Map Overlays

GeoIP and ASN views map external IPs to countries, regions, and network owners. They are context tools, not proof. IP geolocation can be wrong, VPNs and CDNs distort location, and cloud providers host both legitimate services and adversary infrastructure.

What It Shows in the PCAP

The map is built from external destination IPs, sometimes enriched with ASN and reverse DNS. To make it useful, correlate the map with DNS queries, TLS SNI, certificate subject names, JA3 or TLS fingerprints if available, HTTP Host headers, and byte counts. A single packet to an unexpected country is weak evidence. A long outbound TLS stream to an unknown ASN after local file access is stronger.

DFIR Example: Suspicious Cloud Destination

An engineering workstation sends 300 MB over TLS to an IP in a hosting ASN that the company does not use. In the PCAP, the case improves if DNS shows a random-looking domain, SNI does not match an approved SaaS provider, the certificate is newly issued or self-signed, and the transfer follows SMB reads from an internal repository. The map raises the question. The packet timeline answers it.

DFIR Example: Device Calling Home

An appliance or IoT device communicates with an external IP that is not documented by the vendor. The PCAP evidence should include the device MAC address, DHCP hostname if present, DNS name, destination ASN, protocol, interval, and payload size. This is often where "suspicious" becomes "needs vendor confirmation," not "confirmed compromise."

7. Hilbert Maps (IP Space Visualization)

Hilbert maps project IP address space into a 2D square while keeping nearby IP ranges near each other. For network defenders, the value is simple: scans and sweeps create organized patterns that are difficult to see in raw logs.

What It Shows in the PCAP

A sweep appears as many connection attempts across adjacent IPs or ports. In the PCAP, validate SYN packets, unanswered SYNs, RST responses, ICMP unreachable messages, repeated destination ports, and source consistency. The map can show the scan shape. Packet details show the scan type.

DFIR Example: Internal Reconnaissance

A host at 10.50.9.44 sends SYN packets to port 445 across 10.50.0.0/16. Most targets respond with RST or do not respond. A few complete the TCP handshake. On an IP-space map, the /16 lights up as a structured block. In the packets, the evidence is sequential destination coverage, consistent source, short timing gaps, and minimal payload. That pattern is reconnaissance unless a known scanner or asset inventory job explains it.

How to Use These Views in an Investigation

Do not start by admiring the graph. Start with a question.

1. What changed? Use a protocol treemap and topology graph to identify unusual services, hosts, or edges.
2. When did it happen? Use a heatmap to isolate the first event, peak activity, and end time.
3. Which hosts are involved? Use the node-link graph to separate source, destination, relay, and service roles.
4. How much data moved? Use a flow diagram to quantify bytes and direction.
5. Is the external destination expected? Use GeoIP and ASN as context, then verify DNS, SNI, certificates, and payload metadata.
6. Is the traffic automated? Use packet-size histograms and timing regularity to test that hypothesis.
7. Is this reconnaissance? Use IP-space maps to identify subnet coverage and scan shape.

The output should be a timeline and a set of packet-backed facts: host, timestamp, protocol, destination, byte count, payload indicator, and confidence level.

Comparison Table

Common Mistakes to Avoid

Visualizations reduce cognitive load, but they also make it easy to overstate findings.

• No baseline: a busy topology graph is not automatically suspicious. Compare against a known-good capture from the same segment, day, and business cycle.
• Over-filtering: removing DNS, DHCP, ARP, or Kerberos too early can hide the start of the incident. Filter iteratively and preserve the original capture.
• Confusing anomaly with compromise: unusual traffic is a lead. It becomes a finding only when packet evidence supports it.
• Ignoring direction and volume: one connection to an odd IP is weaker than a long outbound transfer after internal file access.
• Trusting GeoIP too much: geolocation is context, not evidence. CDN, VPN, and cloud routing can mislead.

Bottom Line

A good PCAP visualization does not tell you what happened by itself. It tells you where to look. The finding still has to be backed by packets: timestamps, flows, protocols, payload indicators, and host relationships.

Use topology to find relationships. Use flow views to quantify movement. Use treemaps to spot protocol shifts. Use heatmaps and histograms to test automation. Use GeoIP and IP-space maps to add external and subnet context. Then go back to the packet details and write only what the evidence supports.

At apackets.com, the goal is to make that workflow faster: upload a PCAP, inspect the visual shape of the traffic, pivot into protocol details, and keep the final conclusion tied to observable network evidence.