# Network forensics with flow data: Investigating incidents with traffic history By: Shynu 17-18 minutes Last updated: August 28, 2026 Network forensics is the practice of collecting and analyzing historical network traffic data to reconstruct a security incident, including when it began, which systems were involved, how it moved, and what left the environment. Flow-based network forensics does this using conversation metadata, meaning addresses, ports, protocols, timestamps, byte counts, and TCP flags, instead of full packet payloads. Every incident investigation runs into the same wall. Someone asks how long the attacker was inside and what left the building, and the answer depends on evidence that was either retained or lost weeks before anyone knew there was an incident. Endpoint logs roll over, attackers clear event logs, and firewall logs are frequently kept for days. Retained flow records can provide one of the few continuous historical accounts of network communication still available after discovery, at a storage cost that makes long retention practical. This page covers how to use them, and what to do beforehand so they are there when you need them. ## Key takeaways - Flow records establish endpoints, timing, direction, volume, and communication relationships across your full retention window. - Given one confirmed malicious destination, retained flow immediately produces every internal host that ever contacted it, which is the query that most often changes an incident's scope. - Flow records carry no payload, so they measure how much data left and cannot identify which files. - Retention determines how far back an investigation can reach. Mandiant's M-Trends 2026 report put the 2025 global median dwell time at 14 days, and at 25 days where an outside party gave the notification. - Preservation decisions, including legal hold, have to be made in the first hours of an incident or the earliest evidence ages out mid-investigation. - Flow forensics works alongside endpoint, identity, firewall, and packet telemetry. It covers the space between hosts that endpoint tools cannot see. ## In this guide - The six questions every network investigation has to answer, and which flow fields answer each. - A pivot sequence that takes you from one indicator to a full incident timeline, plus the false leads that sequence tends to produce. - Retention math, preservation steps, evidentiary handling, and the boundaries of flow-based conclusions. ## Why flow survives when other evidence does not Flow records are generated by network infrastructure and exported off-device immediately, which places them outside the control of a compromised host. Three properties make them useful in the days after discovery. **Continuity:** Flow export runs constantly. There is no decision about what to log, which means evidence of an attack path exists before anyone knew to look for it. **Compression:** A conversation that moved 4 GB becomes a record of a few dozen bytes. The compact representation makes months of network history practical to retain, where the equivalent period of full packet capture generally is not. **Independence:** Flow is recorded by a device that is neither the attacker's target nor the target's own logging subsystem. Records already exported to a collector cannot be retracted by touching the compromised host. That independence has a boundary. An attacker cannot easily remove exported records, and can avoid generating them, either by disabling export on a device they control or by moving along paths that were never instrumented. Both leave a gap in the record instead of an alteration to it, which is why exporter health monitoring belongs in forensic readiness rather than in operations alone. ## Six questions a network forensics investigation has to answer A network forensics investigation typically needs to establish when the activity began, which systems were involved, how it spread, what data left the environment, whether the activity is ongoing, and what other systems interacted with the same infrastructure. | Question | Flow fields that answer it | What flow can establish | |---|---|---| | When did this start? | First observed flow between the indicator and any internal host, timestamps | Earliest observed communication within the retention window, which is a floor rather than a true start date | | Which hosts are involved? | Source and destination IPs across the full conversation graph | The set of internal hosts that communicated with the indicator | | How did it spread? | Internal flows on 445, 3389, 5985, 5986, 135, and 22, ordered by time | The communication path, and nothing about the technique used along it | | What was taken? | Outbound byte counts by direction, destination, and time window | Transfer volume as an upper bound, and nothing about payload content | | Is it still active? | Recent flows matching the same pattern or destination | Whether matching communication continues | | What else touched that infrastructure? | All internal hosts with flows to the same external IP or subnet | Full scope of contact with the known infrastructure, across retention | The last row is the one that changes investigations. Given one confirmed malicious destination, retained flow immediately produces every internal host that ever contacted it, across the entire retention window. That query typically expands a single-host incident into its real scope, or confirms containment. These six questions define the evidence you need. The pivot sequence below shows how an analyst moves from a single indicator to that evidence. ## The pivot sequence A pivot sequence is the ordered set of queries that takes an investigation from one indicator to a full incident timeline. Investigations start from an EDR alert, a threat intel hit, a user report, or an external notification. **Step 1:** Anchor the indicator. Query all flows involving the indicator IP or the affected host, across full retention. Note the earliest and latest timestamps. The earliest is your provisional start of activity, bounded by how far back your data goes. **Step 2:** Expand horizontally. Find every other internal host that communicated with the same external infrastructure. Include the surrounding /24 and the ASN, since operators rotate addresses within blocks they control. **Step 3:** Rebuild the internal path. For each involved host, pull internal flows on lateral movement ports, ordered by time. Chains emerge here. That sequence reveals the communication path associated with the suspected intrusion, which is evidence of connectivity rather than proof of technique. **Step 4:** Look for the staging point. Before exfiltration, data is usually collected onto one host. The signature is unusually large internal transfers from file servers or databases toward a single internal address, followed by that address pushing outbound. **Step 5:** Quantify the outbound. Sum outbound bytes from every involved host, by destination and time window, and compare against each host's own baseline. **Step 6:** Check for persistence. Search recent flow for the same beacon interval, the same destination, or the same behavioral shape from any host. Reinfection after cleanup is common and shows up here first. ## Reading flow records like an investigator A few patterns are worth recognizing on sight. Each is an investigation signal rather than standalone proof, and each should be evaluated against the asset's role, its history, and other available telemetry. **Beacon regularity:** Plot connection timestamps between one internal host and one external destination. Human-driven traffic clusters irregularly. Automated check-ins produce near-uniform intervals. Jitter complicates this: modern command and control frameworks support jitter percentages high enough to defeat naive interval analysis, and sleep intervals measured in hours or days push check-ins below most detection windows entirely. Absence of a regular interval is not absence of a beacon. **Byte asymmetry:** Normal client browsing downloads far more than it uploads. A workstation sending significantly more than it receives, over a sustained period, is the exfiltration shape. **Short flows at scale:** Hundreds of flows with tiny packet counts and no completed sessions indicate scanning. TCP flag distribution separates connection attempts from established sessions. **First-seen destinations:** A destination with no history in your retention window, receiving sustained traffic, is more interesting than a high-volume destination the network has always talked to. Off-hours activity from user devices. Workstations have working hours. Servers do not. Applying the same anomaly logic to both produces noise, which is why baselines need to be built per device role. ## False leads that look like findings Every investigation produces them, and a clean six-step sequence makes over-reading easier. Four are common enough to check before escalating. **NAT and proxy collapse:** On a NATed segment, or behind a forward proxy, flow records show the translated address. Attributing that traffic to a single host is wrong, and it is the most common way flow-based attribution fails. Resolve through NAT translation logs, proxy logs, or DHCP records before naming a host in a report. **Vulnerability scanners look exactly like discovery:** Authorized scanning produces textbook fan-out. Check the scan schedule before treating it as reconnaissance. **Backup jobs look exactly like staging:** Large internal transfers from file servers and databases to a single destination on a nightly schedule is the backup pattern and the staging pattern. The shape alone will not separate them. The schedule and the destination's role will. **Update services look exactly like beaconing:** Software update agents, telemetry clients, and monitoring agents check in at regular intervals to fixed external destinations. Build an allowlist before running interval analysis, or the results will be dominated by them. ## Retention Retention is the single decision that determines whether an investigation succeeds. Two numbers drive it. **Discovery lag:** Mandiant's M-Trends 2026 report placed the global median dwell time at 14 days for 2025, up from 11 days the year before. That median splits sharply by who noticed. Organizations that found the intrusion themselves did so in a median of about nine days, while cases where an outside party gave the notification ran to a median of 25 days. Medians also hide the tail, and the same dataset attributes the overall increase partly to long-dwell espionage activity measured in months. If retention is shorter than dwell time, the beginning of the incident is gone, and the investigation starts in the middle of the story. **Regulatory obligations:** Where specific regulatory or contractual retention requirements apply, align flow retention with those obligations. PCI DSS v4.0.1 Requirement 10.5.1 is one example, calling for at least 12 months of audit log history with the most recent three months immediately available for analysis, for environments in its scope. Other frameworks set their own expectations, covered in network traffic analysis for compliance. Practical guidance, offered as a starting position rather than a universal standard: - 90 days of searchable per-conversation data as a working floor. - 12 months where discovery may be delayed, where regulatory obligations apply, or where the estate holds high-value data. - Tiered storage is fine, provided you know which tier keeps conversation-level detail. Hourly rollups support trending and cannot answer "which host contacted this IP at 02:14." When budgeting, test the query instead of trusting the retention number. Ask for a specific IP pair on a specific day near the end of the window and see what comes back. **What short retention costs:** An investigation that cannot establish scope defaults to the conservative assumption. In practice that means notifying a larger affected population, engaging outside forensics for longer, and negotiating with an insurer from a weaker evidentiary position. Those costs land in the same fiscal year as the storage you declined to buy. ## Preserving flow evidence before you need it Forensic readiness is the set of decisions made before an incident that determine what evidence exists afterward. Five items, none of which can be arranged during the incident itself. **Legal hold on retention aging:** When an incident is declared, normal retention aging has to be suspended for the relevant window, or evidence rolls off mid-investigation. Decide now who can authorize that, how quickly, and what the technical mechanism is. This is an unassigned responsibility in most organizations until the first incident makes it urgent. **Exporter coverage audit:** Know which segments export flow before you need them. Investigations discover coverage gaps at the worst possible moment, and the answer "that path was never instrumented" is far more expensive in an incident room than in a planning meeting. **Exporter health monitoring:** A device that silently stops exporting produces a gap indistinguishable from a quiet period. Alert on export cessation per exporter. **Collector integrity:** Flow's evidentiary value rests on living apart from the compromised host, which makes the collector the concentration point. Restrict access, log administrative actions on it, and back it up on a schedule that survives a ransomware event affecting the same network. **Time synchronization, verified:** Every exporter running NTP against a common source, with drift monitored rather than assumed. Correlating across devices with drifting clocks produces sequences that are wrong in ways nobody notices until counsel asks. ## Evidentiary handling Evidentiary handling is the set of practices that make an investigative finding defensible to a third party. If findings may support legal action, insurance claims, or regulatory notification, handling matters as much as analysis. NIST SP 800-61 Revision 3, published in April 2025, reframes incident response around the CSF 2.0 functions and treats analysis as a continuous activity, which is the framing retained network telemetry supports. - **Export the raw records:** Preserve the underlying flow records. A report or dashboard screenshot is an interpretation of them. - **Document the query:** Record exactly what filter produced each finding, so it can be reproduced. - **Preserve chain of custody:** Note who extracted the data, when, and where it is stored. - **State confidence honestly:** Volume transferred is measured. Content of that volume is inferred. Keep those separated in the report. ## What flow forensics cannot establish Flow tells you a conversation happened, its size, its timing, and its endpoints. It does not tell you what was said. - **No payload content:** You cannot determine which files left, only how many bytes did, and that figure is an upper bound. - **No process attribution:** Flow identifies the host. Process and user attribution require enrichment from DHCP, Active Directory, or NAC. - **No host-local activity:** Encryption of local files, credential theft from memory, and privilege escalation produce no flows. - **Bounded by retention:** Activity older than your window did not stop happening. It stopped being visible. - **Sampled data undercounts:** On sampled exporters, small flows may not appear at all, which matters most for exactly the low-volume beaconing you want to find. The working answer is layering. Endpoint telemetry covers the interior of hosts. Flow covers the space between them, which endpoint tools do not see and attackers must cross. ## Forensics, threat hunting, and traffic analysis Three related practices, distinguished by what triggers them. | Practice | Trigger | Question it answers | |---|---|---| | [Network traffic analysis](https://www.manageengine.com/products/netflow/network-traffic-analysis.html) | Continuous | What is the traffic doing, and is it normal? | | Network forensics | An indicator, alert, or incident already exists | What happened, when, how far did it reach, and what left? | | Threat hunting | A hypothesis, with no alert | Is there activity here that nothing has flagged? | All three read the same flow records. Forensics is retrospective and scoped to a known event. Hunting is proactive and scoped to a hypothesis. ## Flow forensics with NetFlow Analyzer Mapping the product to the six questions above. **Anchor an indicator:** Search retained flow by IP, subnet, port, protocol, interface, and time range, to establish earliest and latest observed communication. **Expand the scope:** Identify every other internal host that communicated with the same external destination or subnet, which is the query that resolves single-host versus wider incident. **Rebuild the path:** Full peer lists per host with byte and packet counts by direction, ordered in time, to reconstruct internal communication chains. **Quantify the outbound:** Directional byte totals per host, per destination, per window, comparable against that host's learned baseline. **Preserve findings:** Export the underlying records and reports for evidentiary handling and external review. **Collect from what you already run:** NetFlow, IPFIX, sFlow, J-Flow, and NetStream from routers, switches, and firewalls already deployed, with no additional capture hardware required for this workflow. ## Frequently Asked Questions ### What is network forensics? The practice of collecting and analyzing historical network traffic data to reconstruct a security incident after it has been discovered, establishing when activity began, which systems were involved, how it spread, and what data left the environment. Flow-based network forensics does this with conversation metadata instead of full packet payloads, which allows far longer retention at far lower storage cost. ![Author](https://cdn.manageengine.com/itom/images/author/shynu.webp) By Shynu, ManageEngine Team Lead product marketer for ManageEngine's FSO suite who breaks down network monitoring, bandwidth management, and the expanding role of flow data in network detection and response, with an emphasis on making technical concepts usable for the practitioners implementing them.