PCAP-driven incident response: investigating suspicious traffic when you don't have an EDR

Most modern IR guides assume you have EDR. CrowdStrike Falcon, Defender for Endpoint, SentinelOne — they tell you what processes ran, what files were created, what network connections were made, all neatly correlated. But what happens when you don't? Plenty of real environments don't: OT networks, Linux servers that the EDR licence didn't cover, embedded devices, development environments, third-party-managed infrastructure. When the alert comes from a SOC and the only artefact you have is a PCAP from a network tap, you need a different workflow.

This guide is that workflow. It assumes you have one or more PCAP files (or live capture) and no endpoint visibility, and walks the full investigation from raw packets to attack-chain reconstruction and IOC extraction.

What PCAP can and can't tell you

PCAP captures network traffic at the time the capture ran. It gives you a strong view of:

• Source and destination IPs, ports, protocols, timing, byte counts, and packet-level patterns.
• Unencrypted application-layer content (HTTP without TLS, plaintext DNS, SMB file transfers, FTP, Telnet, etc.).
• TLS metadata: SNI, certificate details, JA3/JA4 fingerprints, session timing. The encrypted content stays encrypted, but the metadata says a lot.
• Wireless protocol-layer details if the capture is in monitor mode (802.11 frames, EAPOL handshakes, deauth attacks).

PCAP doesn't tell you:

• What process originated the traffic on the source host. You see the IP and port, not the binary.
• What was inside encrypted traffic (TLS, SSH, WireGuard) without prior keylog or MITM.
• What happened on disk or in memory. PCAP only sees what touched the wire.

That means PCAP-driven IR is necessarily about inferring host behaviour from network behaviour. The good news: a surprising amount of attacker activity has a distinct network signature.

Step 1: Verify the capture and establish scope

Before you analyse, sanity-check the capture itself:

• File integrity — magic-byte check (capinfos, pcap-ng validation). A truncated or corrupt PCAP misleads you about timestamps and packet ordering.
• Link type — Ethernet, Wi-Fi (radiotap), Linux SLL, PPP, raw IP, etc. Many open-source tools assume Ethernet and silently misparse other link types. Confirm with capinfos -t.
• Time range — does the capture window actually cover the incident? Misaligned clocks are a common cause of false negatives.
• Capture point — where in the network was the tap? Inside the firewall (you see internal-internal traffic), outside (you only see north-south), at a SPAN port (you may be missing one direction).

Step 2: Triage the protocol mix

Get a top-down view before you dive in. tshark -z io,phs gives you a protocol hierarchy — what percentages of packets and bytes are HTTP, DNS, TLS, SMB, etc. This is your sense-check. A network that's normally 80% HTTPS and is suddenly 60% SMB is interesting. A network with 5% DNS that suddenly has 40% DNS is signalling DNS exfil or DGA.

What stands out in attacker traffic:

• Unexpectedly high DNS volume → DNS exfil or DGA C2.
• Long-tail of one specific TLS SNI being contacted repeatedly with small, periodic byte counts → C2 beaconing pattern.
• SMB to internal hosts the source has no business talking to → lateral movement or share enumeration.
• ICMP with unusually large payload → ICMP tunnelling.
• Outbound traffic at odd hours when the host should be idle.

Step 3: Identify command-and-control candidates

C2 has identifiable network behaviour even when the channel is encrypted. The signals:

• Beaconing — periodic outbound connections at regular intervals (every 30s, every 5 min, jittered around a base). The jitter pattern alone identifies most off-the-shelf C2 frameworks. RITA, Zeek-based pipelines, and CICADA's PCAP analyser all flag this.
• Domain age — the SNI / DNS query targets a domain registered in the last 90 days, no historical resolution, no benign reputation.
• TLS fingerprint — JA3/JA4 client hashes that don't match the host's usual browser or system clients. Cobalt Strike, Sliver, Mythic, and Brute Ratel all have characteristic JA3 fingerprints.
• Certificate quirks — self-signed, very short validity, generic CN like www.example.com, or default-value subject fields.
• DNS over HTTPS / DoH — a host suddenly resolving via 1.1.1.1 or 8.8.8.8 over TLS to bypass internal DNS logging.

Step 4: Extract IOCs from the wire

Every attacker observation should leave at least one IOC. From a PCAP you can extract:

• IPs — remote endpoints contacted. Differentiate routable public IPs from RFC1918 (lateral movement signals).
• Domains — DNS query names, TLS SNI values, HTTP Host headers. Watch for sandwich techniques where a malicious domain CNAMEs to a legitimate one.
• URLs / paths — from unencrypted HTTP. URI patterns identify specific tooling.
• File hashes — SHA256 of any payload transferred over unencrypted protocols (HTTP, FTP, SMB). Pivot to VirusTotal / MalwareBazaar.
• JA3/JA4 fingerprints — client TLS fingerprints. These are evergreen IOCs because they tie to the client software, not just the campaign.
• User agents — from HTTP. Default-value UAs from frameworks (python-requests/2.x on a Windows workstation; default curl on a server that doesn't run scripted HTTP) are tells.
• SSH banners — OpenSSH version strings, libssh banners. Identify which client software is being used.

Step 5: Reconstruct file transfers

Unencrypted file transfers are a goldmine. SMB, FTP, HTTP, and even some plaintext SMB-over-NFS still happen. Tools that extract files from PCAP: tshark --export-objects, tcpflow, NetworkMiner, foremost.

For SMB specifically, smb.file_data captures the binary payload. You can reconstruct an attacker's tools-as-deployed and hash them. This is often the difference between “suspicious traffic to file server” and “attacker dropped Mimikatz on file server, here's the SHA256”.

Step 6: Wireless-specific analysis

If the capture is in radiotap or 802.11 monitor mode, additional signals:

• Deauthentication frames in volume from a single source — deauth attack, often preceding a captive-portal phish or evil-twin AP.
• EAPOL handshakes — if the attacker captured a 4-way handshake, they have material for offline cracking.
• Beacon frames advertising duplicate SSIDs from MAC addresses that don't match the legitimate AP — evil twin.
• Probe requests with directed SSIDs not part of your network — can profile attacker devices via their preferred-network lists.

Step 7: Timeline and report

PCAP doesn't come with a built-in timeline view the way EDR does. Build it manually:

1. For each suspect IP / domain / hash, find the earliest contact in the capture.
2. Group activity by source host and chronological order.
3. Map to ATT&CK techniques where the network pattern is diagnostic: T1071.001 Web Protocols, T1041 Exfiltration over C2,T1568.002 Domain Generation Algorithms, T1572 Protocol Tunneling, etc.
4. The report has the same structure as any IR report: executive summary, timeline, evidence inventory (PCAP hash, capture metadata, extracted artefacts), affected hosts, IOCs for blocklisting, recommendations.

The chain-of-custody trap with PCAP

PCAPs are particularly susceptible to chain-of-custody disputes. Two things to get right at capture time:

• Hash the file immediately after capture stops. SHA-256. Record who captured, from what tap point, at what time, with what tool.
• Don't edit the file. Filtering or merging produces new derivative files — keep the original immutable and operate on copies. Hash every derivative.

See the chain-of-custody guide for the full evidence-handling workflow.

Doing this with tooling

Wireshark and tshark do most of this manually. They're excellent tools, but the analyst time per PCAP is significant. For a busy SOC investigating an incident with multiple PCAPs (perimeter, internal segment, wireless tap), the manual approach struggles.

CICADA IR's PCAP analyser handles all 9 common link types (Ethernet, Null, Loop, PPP, Raw IP, 802.11, radiotap, SLL, SLL2), automatically extracts IOCs, identifies beaconing patterns, flags JA3/JA4 fingerprints, and surfaces wireless attack signatures — producing a structured investigation entry that cross-correlates with any identity or endpoint telemetry you have. See Getting Started.