It’s Monday morning. A colleague reports that something happened on the network late on Friday. A system behaved strangely, an unfamiliar device appeared, or data may have been accessed when nobody was watching. The immediate questions are straightforward: what happened, when did it happen, and how far did it spread?
For the IT team, finding the answers may be less than straightforward. The incident wasn’t necessarily detected as soon as it happened. Packet captures may have been overwritten, logs may have expired and the devices involved may have returned to normal operation. The evidence needed to reconstruct events might already be gone.
This is the challenge at the heart of network forensics.
Investigations depend on what you can recover after an incident, but the available evidence depends largely on what your organisation recorded and retained beforehand. For teams managing networks and wider IT infrastructure, preparing for that possibility is a crucial part of operating effectively.
What is network forensics?
Network forensics is the capture, preservation and analysis of network traffic and related records to establish what happened during a security or operational incident. It’s a branch of digital forensics that examines communications between devices, helping investigators reconstruct events, identify suspicious activity and understand the scope of a problem.
Unlike some forms of digital evidence, network traffic can be unusually short lived. Once data has passed through a network, it may not be available again unless it was captured or recorded.
Network forensics vs computer forensics
Computer forensics examines evidence held on an individual device, including its storage, files and memory. Network forensics examines evidence of communications between devices, such as traffic records, connection details and network events.
The two approaches often complement each other. A computer might reveal that a file was accessed, for example, while network evidence could help establish whether information was transferred elsewhere and which systems were involved. Together, they can provide a more complete account of an incident.
The evidence network forensics relies on
An investigation is only as useful as the evidence available to support it. Different data sources reveal different aspects of network activity, and each involves a trade off between detail, storage requirements and how long information can be retained.
Full packet capture
Packet capture records network traffic at the packet level, potentially preserving detailed information about communications between systems. Tools such as Wireshark and tcpdump can help analysts inspect captured traffic and investigate particular connections or protocols.
This level of detail can be valuable when an investigation requires close examination of what was transmitted. However, capturing and storing large volumes of traffic requires significant resources. You may therefore only retain full packet captures for limited periods, or capture traffic only at selected points or during specific investigations.
That means that if you discover an incident after the relevant capture has been overwritten, that detailed evidence may no longer be available.
Flow records
Flow records provide summaries of network conversations rather than a complete record of every packet. Technologies such as NetFlow, sFlow and IPFIX can describe aspects of communications, including source and destination addresses, traffic volumes and timing.
These records can help establish which systems communicated, when connections occurred and how much data moved between endpoints. They’re often more practical to retain over longer periods than full packet captures, although the information available depends on the records collected and the configuration of the systems producing them.
Flow records may not reveal the precise content of a communication, but they can help investigators identify patterns, narrow the scope of an incident and decide where more detailed analysis is needed.
Logs from firewalls, DNS, proxies and devices
Logs provide records of events and activity within particular systems.
- Firewall logs may show connections that were allowed or blocked.
- DNS logs can help establish which domain names a device attempted to resolve.
- Proxy records may show web requests, while device logs can reveal errors, authentication events or configuration changes.
The challenge is that logs are distributed across different systems and vary in detail, format and retention period. Some may record only selected events, while others may be incomplete or difficult to correlate with records from elsewhere.
Accurate timestamps and consistent retention policies make these sources more useful when investigators need to reconstruct a sequence of events.
Monitoring history, device state and configuration changes
Monitoring data provides another important source of evidence, particularly when an incident is discovered well after it began.
Historical performance measurements can show how a device behaved before, during and after an incident. Event records can help establish when a fault or other change occurred. Configuration history can reveal whether a setting, route or other part of the network was altered around the same time.
This information may not establish precisely what was transmitted across the network. However, it can provide the timeline and context needed to interpret other evidence. Longer retention is particularly valuable when an issue develops gradually, affects several connected systems or is only recognised after its initial symptoms have disappeared. It can help teams compare suspicious activity with a baseline of normal behaviour and identify changes that might otherwise be missed.
How a network forensic investigation works
The National Institute of Standards and Technology (NIST) describes four broad phases of digital forensic work in its Special Publication 800-86, Guide to Integrating Forensic Techniques into Incident Response. These provide a useful framework for understanding the process.
1. Collection
Investigators identify and collect relevant evidence from available sources. Depending on the incident, this might include packet captures, flow records, logs, monitoring history and device configuration records.
The priority is to identify what evidence exists before it disappears or changes. Collection should be planned carefully, with appropriate records of where evidence came from and how it was obtained.
2. Examination
The collected material is processed and examined to identify information relevant to the incident. This may involve filtering traffic records, extracting events from logs, comparing configuration files or narrowing a large dataset to a particular period. The aim is to make the available evidence manageable without losing information that may prove important later.
3. Analysis
Investigators examine the evidence to establish what happened and how different events relate to one another. They may build a timeline, compare activity against normal behaviour, identify systems involved and investigate possible causes.
Findings should distinguish between what the evidence establishes and what’s still uncertain. A connection record, for example, may show that two devices communicated without proving what information was exchanged.
4. Reporting
The findings are documented so that others can understand the investigation, the evidence examined and the conclusions reached. A useful report explains the sequence of events, identifies limitations and records any remaining uncertainties.
Evidence may need to support internal decisions, incident response or a formal process. Organisations should follow appropriate procedures and obtain specialist advice where necessary to ensure evidence is handled and documented correctly.
Network forensics tools
Network forensics tools serve different purposes, and no single category necessarily provides everything an investigation requires. Here are the main ones.
- Packet analysers: Tools such as Wireshark and tcpdump capture or inspect network packets, helping analysts examine communications in detail.
- Network analysis frameworks: Tools such as Zeek analyse network activity and generate structured records that can support security investigations and traffic analysis.
- Flow collectors: These collect and analyse flow data, helping teams understand communications, traffic patterns and connections between systems.
- Security information and event management platforms: SIEM platforms bring together security events and logs from multiple sources to support correlation, alerting and investigation.
- Monitoring and observability platforms: These provide visibility into infrastructure behaviour, device state, events and historical performance. They can supply the wider timeline and operational context that helps investigators understand an incident.
These categories are complementary rather than interchangeable. A packet analyser can reveal details about captured traffic, for example, while a monitoring platform may help establish whether a device’s behaviour changed several weeks before an incident was identified.
LiveTrace supports this wider evidence picture by retaining monitoring history, device state, configuration context and correlated event timelines across the infrastructure estate. It doesn’t capture network packets or replace specialist forensic investigation tools. Its role is to help ensure that useful historical context remains available when an incident needs investigating.
Why network forensic investigations stall
One of the most frustrating situations for an IT team is knowing that something happened but being unable to establish exactly what. Often, the difficulty is a lack of retained evidence.
An incident may go unnoticed for days or weeks. By the time someone identifies the problem, packet captures may have rolled over, logs may have expired and monitoring history may no longer cover the relevant period.
Even where records are still available, gaps can make the timeline difficult to reconstruct. Devices may use unsynchronised clocks, configuration changes may not be recorded consistently, or different systems may hold onto information for different lengths of time.
Fragmented visibility creates another obstacle. If the network team, service desk and security team each hold separate pieces of the picture, establishing the sequence of events can require time consuming manual investigation.
The consequences can extend beyond the investigation itself. If teams can’t establish the cause of an incident, they may struggle to confirm its scope, decide whether a system can be trusted or determine what corrective action is needed. Understanding whether a device can still be trusted after a compromise is one example of why historical evidence and context are so important.
What to have in place before you need it
Preparing for network forensics needn’t mean capturing every packet indefinitely. It just means deciding what evidence your organisation needs, how long it should be available and how the different sources will support an investigation. Start by reviewing six areas:
- Retention: Keep relevant network and infrastructure history long enough to cover the period in which an incident might go unnoticed. The right duration depends on risk, operational needs and any applicable regulatory requirements.
- Time synchronisation: Ensure clocks across network devices, servers and other relevant systems are accurate and synchronised. Consistent timestamps make it easier to reconstruct events in the correct order.
- Configuration records: Maintain a record of important configuration changes so investigators can establish what changed and when.
- Normal behaviour: Establish a baseline of expected activity and performance. This gives teams something to compare against when investigating unusual events.
- Evidence protection: Store important records away from the devices they describe where practical, with appropriate access controls and protection against alteration or deletion. This helps preserve evidence if a device is compromised or becomes unavailable.
- Estate-wide visibility: Consider whether the available records cover the full environment, including operational technology, IoT equipment and building systems where these form part of your organisation’s infrastructure.
The objective is to make evidence available and usable when it is needed. The appropriate tools and retention periods will differ from one organisation to another, so your approach should reflect your environment, the risks you face and any relevant regulatory obligations.
The investigation starts before the incident
Let’s come back to that Monday morning call. Something happened on Friday night, and the team needs to establish what, when and how far it spread.
The answer will depend partly on the tools available today, but also on decisions made weeks or months earlier. Which records were collected? How long were they retained? Were device changes recorded? Can events from different parts of the estate be placed on one reliable timeline?
Network forensics is about analysing evidence after an incident, but just as importantly, it’s about making sure the evidence survives long enough to be analysed. For IT teams, that means treating historical monitoring data, configuration records and network visibility as part of incident preparedness.
Frequently asked questions
What is network forensics?
Network forensics is the process of collecting, preserving and analysing network traffic and related records to establish what happened during an incident. It can help identify communications between systems, reconstruct event timelines and investigate suspicious activity. The evidence available depends on what was captured or recorded and retained before the incident was discovered.
What is the difference between network forensics and computer forensics?
Network forensics examines communications between devices, using sources such as packet captures, flow records and network logs. Computer forensics examines evidence held on individual devices, including files, storage and memory. Investigations often use both approaches to understand what happened on a system and how it communicated with other devices.
What tools are used in network forensics?
Tools include packet analysers such as Wireshark and tcpdump, network analysis frameworks such as Zeek, flow collectors, SIEM platforms and infrastructure monitoring systems. Each provides different evidence. The appropriate combination depends on the incident, the systems involved and whether investigators need detailed packet contents, communication summaries, event records or historical infrastructure context.
What are the steps in a network forensic investigation?
A commonly used framework, described in NIST Special Publication 800-86, has four phases: collection, examination, analysis and reporting. Investigators first gather relevant evidence, then process and examine it, analyse the findings to reconstruct events, and document the conclusions and limitations. Evidence should be handled carefully throughout the process.
How long should network data be kept for forensic purposes?
There’s no single retention period that suits every organisation. Requirements depend on the environment, potential risks, operational needs and applicable regulations. Retention should comfortably cover the time an incident might go unnoticed, allowing teams to investigate events retrospectively. Organisations should also consider the different storage demands and investigative value of packet captures, flow records, logs and monitoring history.