An EDR alert fires on a finance laptop at 2 a.m. It names a process and its parent. It doesn't say where the traffic went, what came back, or whether a second host got the same treatment. Answering that takes packets, logs, and endpoint telemetry together. Packets see the wire but not the process. Logs see events, but only what the source chose to write. Endpoints see the process until an attacker kills the agent. This post covers how to get full packet capture running and how to join it to the other two.
What Full Packet Capture Records
Full packet capture stores every packet crossing a monitored link, headers and payload both. Months later you can replay a session and read what was actually sent. Flow records can't do that. They only note that a conversation happened.
Analysts reach for packets when a question needs a literal answer, like which command an attacker typed over an unencrypted channel, or whether a service account password crossed the network in cleartext. Logs sometimes cover this, but an attacker with admin rights can edit or clear them. A packet already captured stays put.
Why Metadata Isn't Enough
Metadata is the set of fields pulled from each session: addresses, ports, protocol, byte counts, DNS names, TLS certificate details. It's compact, so you can keep months of it and search in seconds.
It can't show content. A workstation connecting to an unfamiliar IP over port 443 is a lead, and metadata finds it fast. Whether that session downloaded a payload or just checked for updates takes the packets. So you search metadata first and open packets second, which means both need to come from the same traffic.
Where to Place Capture Points
You can't record everywhere, so start with the places traffic has to cross:
- Internet ingress and egress
- The data center core
- Links between user networks and server segments
- Cloud VPCs and virtual networks
- Remote site gateways that reach sensitive systems
Most teams cover the perimeter and skip internal links. Lateral movement happens on internal links, so they deserve budget.
Choosing a capture method
| Method | Best for | Watch out for |
|---|---|---|
| Network TAP | Critical links | Cost, physical install |
| SPAN or mirror port | Fast rollout | Dropped packets under load |
| Virtual TAP or host agent | VMs and containers | Host overhead |
| Cloud traffic mirroring | AWS, Azure, GCP | Service limits, egress cost |
A passive TAP never touches production traffic, which is why it suits links you can't afford to get wrong. SPAN ports are fine on lower-risk segments, but a busy switch drops mirrored packets without telling anyone. You find out during an investigation, which is the worst time.
Planning Packet Storage and Retention
A fully saturated 1 Gbps link writes about 10.8 TB per day. Real links run lighter, but at 30 percent average use you still store over 3 TB daily on a single link. Several segments later, the storage bill gets attention.
Most teams settle on a split. Full packets stay for a few days to a few weeks, depending on budget. Metadata stays for months because it takes a small fraction of the space. Bulk backups and video streams get filtered or truncated, and high-risk segments get longer packet retention. The metadata index is what makes a long lookback affordable, since you only pull packets for the sessions that matter.
How to Correlate Packets with Logs and Endpoint Telemetry
Start with time. Every capture appliance, log source, and endpoint should sync to one NTP source. A drift of a few seconds can separate events that belong together or join ones that don't. Fix this before touching anything else.
Next, find the fields your sources share.
| Field | Packets | Logs | Endpoint |
|---|---|---|---|
| IP address | Source, destination | Firewall, proxy, DHCP | Host connections |
| Hostname | DNS, protocol fields | AD, DNS, servers | Device name |
| Username | Kerberos, NTLM | Windows, identity logs | Logged-in user |
| File hash | Extracted files | Email gateway, sandbox | File and process events |
| Domain | DNS, HTTP, TLS SNI | Proxy, DNS logs | Process activity |
IP address is the least reliable of these. DHCP leases, VPN sessions, and NAT keep changing who holds what. Tie every IP to a host and user at a specific timestamp before you rely on it.
Then normalize. One source writes src_ip, another SourceAddress, a third client. Without a common schema, analysts translate in their heads on every case. Pick one field name per concept, convert timestamps to UTC, resolve IPs to hosts and users, and tag each record with where it came from.
Pivot Workflow For Investigations
- Take the alert from whichever tool raised it.
- Pull the host, user, IP, and time.
- Search network metadata for that host around the event window.
- Check authentication, DNS, and proxy logs for the same window.
- Find the endpoint process behind the connection.
- Open the full packets for sessions that look wrong, then extract files, commands, or credentials.
Each step cuts the search space. By step six you know which sessions to open.
Example: A suspicious PowerShell alert
Say the EDR flags PowerShell spawning from a Word document on a finance workstation. The endpoint record gives you the host, the user, and the process tree.
You take that host and time window into network metadata and find an outbound HTTPS session to a domain registered four days earlier. Proxy logs show two requests to the same domain, then a block on the third. The packets from the first session contain the payload that came down. A later session shows roughly 40 MB leaving the host.
Now you have the entry point, the payload, the command channel, and the exfiltration, each tied to a specific source. Any one data set would have given you a piece of that and a guess about the rest.
Common Visibility Gaps
Encryption comes up first. Without decryption, packets won't expose payloads. Certificate fields, JA3 fingerprints, timing, and volume still carry signal, so decrypt where policy allows and lean on metadata where it doesn't.
Cloud is next. Traffic mirroring doesn't reach every managed service, so flow logs fill in where it falls short.
Last, watch the drop counters on your capture interfaces. A gap in the packets can look like a gap in the attack, and you'll waste hours chasing it.
How NetWitness Fits
Running capture, log analysis, and endpoint tools separately means analysts rebuild context by hand across consoles. That's usually where investigations stall.
NetWitness captures traffic at the packet level and generates metadata as it goes. It also ingests logs and endpoint data, so all three land in one investigation workflow under a shared schema. An analyst can start from an alert, pivot on a host or user, and move from metadata into the raw packets without changing tools. For teams that already capture traffic but can't connect it to logs and endpoints, this is typically the piece they're missing.
Conclusion
If you're starting from scratch, pick one egress link, sync the clocks, and run a single test. Take a real alert from your EDR and see how long it takes to reach the matching packets. If it takes more than ten minutes, the gap is in your correlation, and that's where to spend the next quarter.