Imaging a workstation starts talking to internal servers it has never touched before. It does this well outside business hours, and shortly afterwards it opens an encrypted session to an external IP address nobody recognizes.
This does not generate any malware alert. Nothing from the endpoint tool. The protocols are all ordinary ones, so the traffic looks fine at a glance.
A good hunter would still want to look. The sequence doesn’t prove an attack, but it raises questions that conventional detection tools often leave unanswered. The hard part is finding those few connections among millions of routine sessions, then working out what really happened.
The most practical way to hunt threats using packet capture and metadata is to use network metadata to spot suspicious behavior, pull the relevant packet captures for a closer look, and check what you find against other security evidence.
That gives analysts what they need most in an investigation: enough visibility to find the activity worth chasing, and enough detail to examine it properly. It also speaks to something most SOCs will recognize. You can have plenty of alerts and logs and still struggle to explain how an attacker moved through the network or what went on in one suspicious session.
Starting with raw packets is rarely the best approach
Full packet capture earns its keep during an investigation. Opening packet files with no lead, though, is a slow way to hunt. Even a modest enterprise network produces a huge amount of traffic once you add cloud applications, internal services, remote access, and everyday admin work. Finding one suspicious conversation in that pile can eat an afternoon.
Metadata lets you shrink the haystack first. At its simplest, it records who talked to whom, when, over which protocol, and how much data moved. Richer network monitoring goes further and pulls out DNS queries, TLS characteristics, HTTP activity, and other protocol-specific detail.
The gap between basic flow records and richer protocol metadata matters more than people tend to assume. A flow record might tell you a workstation exchanged data with an internal server on TCP port 445. Richer metadata may tell you something about the SMB session itself, depending on what your tooling can see and analyse. Neither proves malice, but the extra context helps you decide which connections deserve your time.
Take command-and-control hunting. If you only search for known bad IP addresses, you will miss infrastructure that hasn’t made it onto a threat intelligence feed yet. Behaviour gives you another way in. An internal system that keeps contacting an uncommon external destination at near-identical intervals is worth a look. So is a server that suddenly reaches out to a new set of destinations after an odd login. You can check how often the connections happen, whether other systems talk to the same destination, and whether any of it departs from the device’s normal pattern.
None of this makes every oddity suspicious. Software updates, monitoring agents, and scheduled jobs can look a lot like beaconing. Experienced hunters know that “unusual” is where an investigation starts, not where it ends.
Where packet capture changes the investigation
Metadata helps you find a suspicious session. Understanding what happened inside it is a different problem.
Say an internal application server sends several gigabytes to an external system. Metadata gives you the source, destination, timing, protocol, and rough volume, and history might show the server has never contacted that destination before. That’s enough to justify a closer look, but it leaves the question open. It could be an approved backup, an application process, or someone moving data they shouldn’t.
Packet capture lets you examine the conversation itself. If full packets were collected and retained, analysts can walk through the sequence of exchanges, inspect the protocol operations they can observe, and rebuild parts of the session. With unencrypted traffic, the capture may even show the requests, responses or files that passed between systems.
Lateral movement is where this really pays off. An attacker using legitimate credentials can generate traffic that looks a lot like authorised administration, and SMB, RDP and similar protocols aren’t suspicious on their own. What matters is how they’re used. Packet analysis can help show whether an SMB connection went beyond negotiation, which operations took place, and whether the behaviour fits the technique you suspect. How much you can see depends on the protocol, the encryption and how complete the capture is. In a possible exploitation case, analysts can also look at protocol errors, strange requests, or traffic exchanged just before a system started acting differently.
There are limits, and it’s worth being upfront about them. Packet capture can’t reveal what was never collected, and encrypted application payloads stay closed without a way to decrypt them. Still, when the packets are there, you get to look at the real network exchanges instead of leaning on summaries.
That is why we think combining full packet capture and metadata for network detection and response matters. Bringing the two sources together lets you carry an investigation well past the first detection.
Platforms such as NetWitness combine network metadata analysis with full packet capture, allowing analysts to move from identifying suspicious communication patterns to examining the underlying network sessions. This helps preserve investigative context when an initial detection does not provide enough evidence to explain what happened.
Following a suspected lateral movement attempt
It’s easier to see how this works in a concrete hunt, so here’s a hypothetical.
An employee workstation begins connecting to several internal file servers. The lead comes from network metadata: a run of SMB connections in the early morning, including to servers that aren’t in the workstation’s usual communication history.
There might be an innocent reason. A newly deployed management tool or an authorised maintenance job could produce the same thing. So the analyst looks at the wider picture before pulling any packets. Historical metadata shows when the connections first appeared and whether this has happened before. The destination list shows the workstation reached several servers in a short window. Then the analyst spots something else: around the same time, the workstation started making recurring outbound connections to an external destination.
The two observations might be connected, but that still has to be shown. At this point the hunt has stopped being a general trawl for odd connections. There’s a specific sequence to chase.
The analyst retrieves packet captures for the relevant internal and external sessions. For the SMB connections, the packets can help show how the sessions developed, whether they completed, and which protocol operations were visible. For the external traffic, packet analysis may add detail on session setup, timing and transport behaviour.
Suppose the internal connections succeeded and the external communication began soon afterwards, with the external traffic encrypted so the payload can’t be read. That supports more digging. It doesn’t yet show the workstation was compromised or that any data left.
So the analyst moves to endpoint telemetry to find which processes started the connections. Authentication records show which accounts were used against the internal servers. File access logs, if they exist, may show whether sensitive files were opened or copied. If the network activity lines up with suspicious process execution and unusual authentication behaviour, the lateral movement hypothesis gets a lot stronger. If the records point to an approved admin process, the analyst can close the line of inquiry with evidence to back it up.
That’s the combination doing its job. Metadata finds the connections and how they relate. Packet capture gives a closer look at the traffic. Other security records tell you whether you’re looking at normal operations or a compromise. And a hunt doesn’t need to end in a confirmed incident to be worth the effort, because ruling out an attack with solid evidence is a perfectly good result.
Encrypted traffic still leaves evidence
Encryption changed what analysts can inspect. It didn’t make network analysis pointless.
A capture of an encrypted session won’t necessarily show the commands or application data inside. But plenty is often still visible. Connection timing, session duration, destination addresses, traffic direction and data volumes can all point somewhere, and depending on the protocol, configuration and monitoring point, TLS handshake characteristics or DNS information may add more.
Picture a server that normally talks to a predictable set of business applications and suddenly starts sending far more encrypted traffic to an unfamiliar external service. That’s worth examining. Calling it exfiltration at that stage would be premature, though, since a software deployment, an authorised sync job or a backup could produce the same pattern. The analyst needs to know what the server is for, which process started the communication, and whether the activity fits how the business runs. Some network characteristics can help separate suspicious connections from routine ones, but a single observation rarely settles it.
Modern encryption protocols also hide some fields analysts used to rely on. As those protections spread, checking network observations against endpoint and application evidence matters more and more. Unreadable payloads are a limitation, but they don’t mean there’s no useful network evidence.
Historical visibility matters as much as live detection
Attacks aren’t always caught while they’re happening. A team might start hunting after a threat intelligence report names previously unknown infrastructure, or after a compromised account turns up during some unrelated investigation. The question then becomes whether you kept enough history to reconstruct what came before.
Metadata is especially handy here. Analysts can search past communications, find when a suspicious destination first appeared, and see which systems touched it. Packet captures can add evidence from selected sessions.
There’s a practical catch. Full packet capture needs far more storage than metadata, particularly on high-throughput networks, and keeping every packet forever isn’t realistic for most organisations. So retention should follow the questions your team is likely to ask. One sensible approach is to keep searchable metadata across a wide part of the environment and hold deeper packet evidence at the critical network locations. Retention periods will vary with risk, infrastructure, incident response requirements and any privacy obligations.
Coverage deserves just as much attention. A capture system sitting at the internet perimeter won’t automatically record lateral movement between internal servers, and the same goes for cloud workloads or other important segments it can’t see. Hybrid environments sharpen this, because one investigation might span on-premises systems, cloud services and remote endpoints. You can’t rebuild a conversation from packets you never captured, and you can’t search metadata that was never generated. For threat hunting, decisions about collection and retention can matter as much as the analysis tools.
The tools should support the investigation, not complicate it
Teams have plenty of ways to analyse network traffic. Zeek produces detailed network and protocol logs, Wireshark lets analysts inspect captured packets, packet collection systems hold the underlying traffic, and SIEM and endpoint platforms add other context. They do different jobs, and most organisations use several together.
Trouble starts when related evidence lives in systems that don’t share context. An analyst spots a suspicious connection in one tool, hunts for the matching packet capture in another, then checks endpoint or authentication logs to understand it. It’s doable, but every hop means another search or another round of manual correlation.
Network detection and response (NDR) platforms can take some of that friction out by pulling network analytics and investigation into one workflow. Some also support full packet capture, detailed metadata analysis and integrations with other security systems, though capabilities differ between vendors and deployments.
For a hunting team, the better test is whether the tools can carry an investigation from start to finish. Can analysts spot an unusual communication pattern? Can they trace related sessions across systems and time periods? Is packet evidence there when they need a closer look? Can they check network observations against endpoint and identity activity? Those are operational questions, not feature-list questions. A platform might be great at flagging abnormal behaviour and thin on history. Another might collect packets extensively and make sessions painful to search and correlate. Judge neither strength on its own. What counts is whether you can get from a first observation to enough evidence to say what happened.
Threat hunting works best when the evidence drives the investigation
It’s tempting to judge network security by how much traffic it collects or how many detections it fires. For hunting, those numbers tell you very little. A huge packet repository doesn’t help if analysts can’t find the right sessions quickly, and rich metadata can flag suspicious behaviour without giving enough detail to explain an incident.
The stronger approach uses both. Metadata lets analysts search broadly, compare against history and pick out the communications worth a closer look. Packet capture then gives a deeper view of selected sessions, showing what happened within the limits of what was collected. Endpoint records, authentication events and threat intelligence place those findings in context.
The aim isn’t to label every unusual connection malicious. It’s to follow the evidence far enough to tell a real threat from legitimate activity. That’s why we see metadata-led hunting supported by packet-level investigation as the practical choice for teams facing sophisticated threats, incomplete alerts and ever more complicated enterprise networks.
Contributed content: this article was written by a third-party contributor and does not necessarily reflect the views of News Anyway. Editorial and Advertising Policy