How to analyze network incidents with PCAP?

NetFlow, retrospective PCAP and packet analysis in practice for SOC teams

Network incident analysis often starts with an alert, but it very rarely ends there.

In SOC (Security Operations Center) and NOC (Network Operations Center) environments, an alert is only a signal that something potentially dangerous has happened in the infrastructure. A SOC is a team of specialists responsible for monitoring, detecting and analyzing security incidents, while a NOC focuses mainly on maintaining the stability and availability of network infrastructure.

An alert therefore indicates only a symptom of the problem. Only the next stages of analysis make it possible to understand what exactly happened in the network, what communication between systems looked like and whether a security incident actually occurred.

In many cases, the first source of information is NetFlow, a network traffic monitoring technology that collects metadata about connections between hosts — such as IP addresses, ports, protocols or the volume of data transferred.

However, in more complex scenarios — especially when analyzing attacks, data exfiltration or communication with command-and-control infrastructure — metadata turns out to be insufficient.

This is when it becomes crucial to reach for the full packet record, i.e. PCAP (Packet Capture). PCAP is a network traffic recording format that enables the storage of raw packets transmitted in the network, together with information about protocol headers and — in the case of unencrypted traffic or traffic that can be decrypted — the content of communication. As a result, an analyst can accurately reconstruct the course of a network session: from the first packet to the end of the communication.

It is worth remembering, however, that in the case of encrypted traffic, especially TLS 1.3, analysis of application content is not possible without the appropriate keys or a decryption mechanism. In such a scenario, PCAP still provides valuable information about the structure of the connection, the direction of communication, session duration, data volume or protocol behavior, but it does not reveal the application payload itself.

In this article, we organize the approach to working with PCAP — from anomaly detection, through traffic analysis, to documenting the incident and handling it in security team processes.

From this article, you will learn:

• when NetFlow stops being enough in incident analysis,
• how retrospective PCAP works and why it is used,
• what NetFlow and PCAP correlation looks like in incident analysis,
• how PCAP packet analysis supports documentation and audits,
• what the SOC workflow looks like — from incident detection to handling it in Jira,
• what limitations need to be considered when analyzing PCAP — including TLS 1.3 encryption, QUIC/HTTP/3, limited retention window and NetFlow sampling.

Security alert as the starting point of incident analysis

In most organizations, network incident analysis begins with an alert generated by a monitoring system or security platform.

This may include, among others:

• detection of communication with a suspicious IP address,
• unusual volume of outbound traffic,
• anomalies in DNS traffic,
• a sudden increase in the number of TCP connections,
• an attempt to communicate with command-and-control infrastructure.

An alert indicates a symptom of an event, but it does not always explain its actual cause.

That is why the first step for a SOC analyst usually involves:

• identifying the source of the alert,
• analyzing the context of the communication,
• checking the traffic history between hosts,
• verifying whether similar events occurred before.

At this stage, NetFlow data is very often used, as it allows analysts to quickly understand who communicated with whom, when and with what volume of data.

Limitations of metadata and NetFlow in the context of security

NetFlow provides valuable information about network traffic, but it operates only on metadata.

In practice, this means that we can see, among others:

• source and destination IP address,
• communication ports,
• protocol,
• volume of data transferred,
• session duration.

Such information makes it possible to quickly detect anomalies in network traffic. However, it is worth remembering that NetFlow does not contain the content of the communication, but only its summary in the form of so-called network flows.

An additional limitation may be NetFlow sampling. In high-traffic environments, flow data is often collected with sampling, e.g. 1:1000. This means that not every packet is included in the analysis, and very short sessions may not be recorded by the collector at all. In practice, NetFlow works very well for detecting trends, volumes and anomalies, but when analyzing short, fast or low-volume connections, the risk of incomplete visibility must be taken into account.

This is precisely why, in many situations, a key question arises:

Was this a real security incident or merely unusual but legitimate network traffic?

Typical scenarios in which NetFlow stops being sufficient include, among others:

• analysis of potential data exfiltration,
• investigation of communication with command-and-control servers,
• analysis of unusual application protocols,
• checking what data was actually transferred between systems.

In such cases, PCAP packet analysis becomes necessary — although the scope of that analysis depends on the type of traffic. In the case of unencrypted traffic, PCAP may allow insight into the content of the communication. In the case of encrypted traffic, such as TLS 1.3, payload analysis requires access to keys or the use of a decryption mechanism.

NetFlow vs PCAP — comparison of data sources in incident analysis

Both NetFlow and PCAP play an important role in network incident analysis, but they provide different levels of data granularity.

NetFlow allows analysts to quickly identify anomalies in network traffic and analyze communication between hosts at the metadata level. PCAP, on the other hand, enables detailed tracing of the communication flow and analysis of packet content — provided that the traffic is not encrypted or can be decrypted.

That is why, in practice, NetFlow and PCAP are technologies that complement each other in network incident analysis.

However, PCAP should not be treated as an unlimited history of all network traffic. In practice, full packet recording most often works as a buffer or selective retention, whose length depends on the bandwidth of the monitored links and the available disk capacity.

Retrospective PCAP — operating principle and practical use cases

One of the biggest challenges in incident analysis is the fact that an alert appears only after an event has occurred.

If packet recording was not running at that moment, the analyst loses the ability to accurately reconstruct the communication.

This is exactly why retrospective PCAP is becoming increasingly important.

This mechanism is based on:

• continuous buffering of network traffic,
• storing packets for a specified period of time, limited by available disk space, the bandwidth of the monitored traffic and the capture scope,
• enabling the retrieval of PCAP from the moment when the incident occurred.

As a result, the analyst can go back to the moment of the event and analyze communication between hosts even if the incident was detected only after the fact.

However, it is important to remember that retrospective PCAP does not mean unlimited access to the full history of traffic. The retention window is directly determined by the equation: bandwidth of monitored traffic × available storage space. For example, with continuous recording of 10 Gbps traffic and 10 TB of disk space, the full packet buffer may cover only about 2 hours of history. That is why, in practice, selective capture, filtering, ring buffering or retention only for selected network segments are used.

In practice, retrospective PCAP enables:

• reconstruction of the full communication session,
• analysis of packet payload — provided that the traffic is not encrypted or that it can be decrypted,
• identification of transferred files in unencrypted traffic or after successful session decryption,
• accurate tracing of the course of the incident.

Correlation of NetFlow and packets in incident analysis

The most effective incident analysis is achieved by combining two data sources:

• NetFlow,
• PCAP.

Both types of data provide different information about network traffic, which is why their correlation makes it possible to obtain a more complete picture of the event.

NetFlow provides broad visibility into network communication. It allows analysts to quickly identify:

• which hosts communicated,
• when the connection started,
• how long the communication lasted,
• what the volume of transferred data was.

Thanks to this, a SOC analyst can quickly detect anomalies such as:

• a sudden increase in outbound traffic,
• cyclic connections to the same IP address,
• communication with rarely seen domains,
• unusual use of ports.

However, only PCAP makes it possible to move from the metadata level to the packet level and verify the details of communication. In the case of unencrypted traffic or traffic that can be decrypted, this may also include payload analysis. With TLS 1.3 and no access to keys, the analysis primarily concerns the structure of the session, connection parameters, volume, timings and protocol behavior, rather than application content.

In practice, incident analysis often looks as follows:

1. NetFlow indicates a suspicious network flow — for example, a specific source address, destination address, port, protocol, start time and data volume.
2. The analyst identifies a specific session or group of sessions, narrowing the analysis down to the so-called 5-tuple: source IP, destination IP, source port, destination port and protocol.
3. The system uses the time index and flow metadata to find the appropriate fragment of the PCAP buffer.
4. Then a filter is generated, e.g. BPF, which makes it possible to extract from the packet recording only the traffic corresponding to a given flow or set of flows.
5. Only such a narrowed-down PCAP is passed on for detailed analysis in a tool such as Wireshark.

This approach significantly reduces the volume of data to be analyzed. Instead of reviewing huge packet collections, the analyst can focus on specific fragments of traffic indicated by NetFlow.

That is why, in modern network monitoring platforms, correlation of NetFlow and PCAP forms the basis of network incident analysis.

Step-by-step incident analysis scenario

To better understand the practical use of this data, it is worth going through a typical network incident analysis scenario.

1. Detecting an anomaly

The monitoring system generates an alert indicating unusual network traffic — for example, an increased number of DNS queries or a large volume of outbound traffic from one host.

2. Analysis of NetFlow metadata

The analyst checks NetFlow data:

• IP addresses of communicating hosts,
• ports and protocols,
• number of connections,
• volume of data transferred,
• duration of communication.

If NetFlow is collected with sampling, the analyst should take into account that the picture of communication may be incomplete. With a high sampling rate, e.g. 1:1000, some short sessions may not appear in flow data at all.

3. Identification of suspicious communication

Based on NetFlow analysis, it is possible to determine whether the traffic is one-off or recurring — for example, cyclic communication with the same IP address.

4. Retrieving PCAP

If the traffic looks suspicious, the analyst retrieves a PCAP file covering the analyzed communication. In practice, this does not mean downloading the entire packet buffer, but extracting a specific traffic fragment based on the event time, IP addresses, ports and protocol. Such a scope can be narrowed down with a BPF filter, so that only packets corresponding to the selected flow or group of flows are passed on for analysis.

5. Packet analysis

Packets are analyzed in a tool such as Wireshark, a popular network protocol analyzer that enables detailed analysis of packets saved in PCAP format.

The analyst can check, among others:

• DNS queries,
• HTTP communication or other application protocols — if they are not encrypted or can be decrypted,
• transferred files — in unencrypted traffic or after decryption,
• packet payload content — with the reservation that with TLS 1.3 and no keys, application content remains unavailable.

In the case of encrypted traffic, packet analysis can still provide important information, even if the content of the communication is not available. The analyst can then examine, among others, session duration, data volume, communication direction, connection recurrence, handshake parameters, retransmissions, protocol errors or unusual client or server behavior.

6. Incident classification

Based on the analysis, it is possible to determine whether the event is:

• a false positive,
• suspicious activity,
• an actual security incident.

7. Documentation and remediation actions

The final stage is incident documentation and remediation actions — for example, blocking IP addresses or isolating a host.

Packet analysis and working with PCAP in tools such as Wireshark

After retrieving the PCAP file, the analyst can proceed to detailed analysis of network packets.

One of the most commonly used tools for this purpose is Wireshark — a network protocol analyzer that enables detailed examination of communication saved in PCAP format.

Wireshark allows network traffic to be analyzed across many layers of the network model, including:

• data link layer (Ethernet),
• network layer (IP),
• transport layer (TCP, UDP),
• application layer (HTTP, DNS, SMTP, FTP).

However, the scope of analysis depends on the type of traffic. In the case of unencrypted protocols, Wireshark may allow analysis of application headers, request content or reconstruction of transferred objects. In the case of TLS 1.3 without session keys, the analysis is mainly limited to lower layers, connection parameters, timings, data volume and metadata available in the handshake.

As a result, the analyst can accurately trace the entire course of communication between hosts — within the scope allowed by the nature of the traffic and the availability of data for decryption.

In practice, PCAP analysis in Wireshark often includes:

• filtering traffic by IP addresses or protocols,
• analysis of TCP sessions and retransmissions,
• identification of DNS queries,
• analysis of HTTP headers — for unencrypted traffic or after decryption,
• reconstruction of transferred files — if the protocol and encryption allow it.

SOC analysts very often use filters that make it possible to quickly narrow down the analyzed traffic. Example filters include, among others:

• filtering DNS traffic,
• analysis of HTTP communication,
• identification of SYN packets initiating TCP connections,
• searching for communication with a specific IP address.

This approach significantly speeds up incident analysis, especially when PCAP files contain millions of packets.

Thanks to detailed packet analysis, it is also possible to:

• detect malware transfer — in unencrypted traffic or after decryption,
• identify communication with command-and-control servers,
• detect data exfiltration attempts,
• reconstruct the course of an incident.

In the case of encrypted traffic, reconstructing the course of an incident does not have to mean reading the content of the communication. It may involve reconstructing the sequence of connections, times, volumes, traffic directions, session characteristics and relationships between hosts. Such data is often sufficient to confirm unusual activity, detect beaconing, assess the scale of communication or indicate the segment requiring further analysis.

Automation of alert response and incident handling in Jira

In modern security environments, incident analysis is increasingly supported by automation of response processes.

Manual handling of every alert can be time-consuming, especially in organizations that generate thousands of security events per day. That is why many SOC teams use integrations with ticketing systems such as Jira to structure the incident handling process.

In practice, a network monitoring system can automatically:

• create an incident ticket in Jira,
• attach analytical context,
• assign the incident to the appropriate team,
• attach NetFlow data and PCAP files.

Thanks to this, SOC analysts receive the full incident context already at the reporting stage.

Automation may also include additional actions, such as:

• enriching alerts with data from threat intelligence systems,
• checking the reputation of IP addresses,
• correlating events with system logs,
• automatically assigning incident priority.

This approach helps shorten response time and streamline the SOC workflow, i.e. the process of handling security incidents from the moment they are detected until the case is closed.

Integration of notifications and team collaboration

Security incident analysis is a process that usually requires collaboration between many teams in the organization.

In practice, the following may participate in incident handling:

• SOC analysts,
• network administrators,
• IT infrastructure teams,
• application security teams.

That is why network monitoring systems increasingly integrate with team communication tools, such as:

• Microsoft Teams,
• Slack,
• ticketing systems,
• security automation platforms (SOAR).

Integration with communication tools allows information about incidents to be quickly shared and improves team collaboration.

An alert can be automatically sent to the security team’s channel, where analysts can immediately begin analyzing the event. In many organizations, the same place also provides access to:

• links to NetFlow data,
• PCAP files,
• traffic analysis reports.

This approach significantly reduces the time needed to coordinate actions and enables faster decision-making regarding incident response.

Challenges of PCAP packet analysis in production environments

Although PCAP packet analysis provides very detailed information about network traffic, in practice it also involves many challenges.

One of the most important problems is the scale of data generated by modern networks. In corporate and operator environments, full packet recording can generate enormous volumes of information that require appropriate infrastructure for storage and analysis.

The most common challenges of PCAP analysis include:

Traffic encryption

An increasing part of network traffic uses TLS encryption, including TLS 1.3. In such cases, PCAP still allows analysis of the connection structure, addresses, ports, data volume, session times, retransmissions or protocol behavior, but it does not allow application content to be read without the appropriate keys or a decryption mechanism. This means that payload analysis, reconstruction of transferred files or detailed inspection of HTTP requests in HTTPS traffic requires prior access to decrypted communication.

Large PCAP files

In high-traffic environments, individual PCAP files can reach sizes counted in gigabytes. Analysis of such data requires the use of filters and specialized tools for traffic processing.

Limited PCAP retention window

Full packet recording generates very large volumes of data, which is why the retrospective PCAP retention window is always limited. Its length depends on the bandwidth of monitored traffic, available storage space, capture scope and applied filters. With continuous recording of 10 Gbps traffic and 10 TB of disk space, the buffer may cover around 2 hours of history. For this reason, in practice, it is particularly important to precisely indicate the network segments for which full PCAP is actually needed.

New transport protocols

Modern protocols such as QUIC, used in HTTP/3, are more difficult for traditional packet analysis than classic HTTP over TCP/TLS. QUIC runs over UDP, integrates transport and cryptographic mechanisms, encrypts a larger portion of connection control information, uses Connection ID instead of a simple session association based only on the IP/port pair and supports connection migration between addresses. An additional challenge is 0-RTT, which makes it possible to speed up session resumption, but makes the analysis of the beginning of communication more difficult. As a result, the classic approach based on tracking TCP sessions and analyzing the handshake is not always sufficient.

Fragmentation and retransmissions

Packet fragmentation and TCP retransmissions often occur in network traffic. Their presence can make session reconstruction and communication analysis more difficult.

NetFlow sampling

Correlation of NetFlow with PCAP depends on the quality and completeness of flow data. If NetFlow is collected with sampling, e.g. 1:1000, some short sessions may not be recorded. This can make it more difficult to indicate the exact PCAP fragment for analysis, especially in the case of short-lived connections, scanning, low-volume beaconing or very fast burst-type communication. That is why, in security environments, it is worth consciously selecting the sampling level according to the goal of the analysis.

Incident context

PCAP itself does not always provide the full picture of an event. That is why packet analysis should always be supplemented with data from other sources, such as NetFlow, system logs or SIEM systems.

Impact of passive monitoring on SOC/NOC effectiveness and audits

More and more organizations use passive network monitoring as the basis for incident analysis and security monitoring.

Passive monitoring involves analyzing a copy of network traffic — for example from SPAN ports or network TAP devices — without interfering with the operation of the infrastructure.

This approach provides broad visibility into network communication, while at the same time not affecting application performance or the operation of production systems.

Thanks to passive monitoring, it is possible to:

• continuously collect NetFlow data,
• record network packets,
• conduct detailed incident analysis,
• reconstruct the course of security events.

This is particularly important in the context of security audits and compliance processes.

The ability to reconstruct the actual course of network communication allows organizations not only to analyze incidents faster, but also to document their course in a way that is consistent with audit requirements.

However, it is important to remember that the scope of such reconstruction depends on the available data. In the case of encrypted traffic, it may include metadata, session structure, communication direction, volume and timing, but not necessarily application content. In the case of retrospective PCAP, it also depends on the length of the available retention buffer.

As a result, passive monitoring becomes one of the key elements of security infrastructure in modern SOC and NOC environments.

Summary

Effective network incident analysis today requires combining many data sources.

NetFlow enables fast anomaly detection, while PCAP makes it possible to conduct detailed packet analysis and reconstruct the course of an incident at the level of available data. In the case of unencrypted traffic or traffic that can be decrypted, this may also include payload analysis and reconstruction of transferred objects. With TLS 1.3 or QUIC without decryption, PCAP still provides very valuable technical context, but it does not provide access to application content.

Retrospective PCAP plays a particularly important role, as it allows network traffic to be analyzed even when an incident was detected only after the fact.

Its effectiveness, however, depends on a properly designed retention buffer — bandwidth, storage, capture scope and traffic filtering method.

In practice, only the correlation of NetFlow and PCAP gives SOC teams broad visibility into what happened in the network — from the first alert to detailed packet analysis and closing the incident in SOC workflow processes.