Post-breach network forensics reconstructs an intrusion after it has already happened by correlating the evidence the network left behind—full packet capture, NetFlow/IPFIX records, firewall, proxy and DNS logs, EDR telemetry, and cloud flow logs. Examiners stitch these sources into a single timeline that shows initial access, lateral movement, command-and-control, and exfiltration, then scope exactly what was accessed versus taken to support breach-notification and litigation decisions.
By the time most organizations know they have been breached, the attacker has been inside for weeks or months and the intrusion is over. The pressing questions are no longer “are we under attack?” but “how did they get in, how long were they here, what did they touch, and what actually left the building?” Those answers drive regulatory notification, insurance recovery, and litigation exposure—and they cannot be guessed. They must be reconstructed from network evidence that is scattered across a dozen systems, overwritten by the hour, and meaningful only when correlated. For general counsel, CISOs, and cyber-insurers, this guide explains where post-breach network evidence lives, how elite examiners rebuild the attacker’s timeline, and what separates a defensible scoping opinion from a costly overstatement.
What network evidence actually survives a breach?
Network forensics is the discipline of reconstructing events from the traffic and telemetry an intrusion generated, rather than from the endpoints alone. The hard truth is that no organization retains everything, and the richest sources are the shortest-lived. A competent investigation begins by inventorying what evidence exists on this network, in what fidelity, and for how long—before the retention clock erases the very records that would answer the question.
The sources fall along a spectrum of resolution. Full packet capture (PCAP) is the highest-fidelity record—every byte of a conversation, including payloads—but it is expensive to store and rarely retained beyond days, if it is captured at all. NetFlow and IPFIX record the metadata of every conversation (who talked to whom, when, on what port, how many bytes) without payloads, making them cheap to keep for months and ideal for spotting beaconing and bulk transfers. Firewall, proxy, and DNS logs capture connection attempts, web requests, and name resolutions—often the only surviving trace of command-and-control or staging domains. EDR telemetry ties network connections back to the specific process and user on the endpoint that made them. And in cloud estates, VPC/VNet flow logs, load-balancer logs, and control-plane audit logs (CloudTrail, Azure Activity, GCP Audit) are frequently the only network-layer evidence that exists at all. The examiner’s craft is knowing which of these is present and reconciling their different vantage points into one account.
Which evidence source proves what—and what are its limits?
Each source answers a different question, and none is sufficient alone. Full packet capture can prove what was transmitted but is almost never retained long enough to cover the dwell period. Flow data proves that a large transfer occurred and to where, but not the contents. Logs prove intent and destination but are trivially incomplete where logging was misconfigured. The discipline is triangulation: an assertion supported by three independent sources of differing type is defensible; one supported by a single log line is an invitation to cross-examination. The table below is how experienced examiners frame the trade-offs before they ever open a case file.
| Evidence source | What it proves | Typical retention | Key limitation |
|---|---|---|---|
| Full packet capture (PCAP) | Exact content of a conversation, payloads, credentials, files in transit | Hours to days (storage-limited) | Rarely retained across the dwell window; TLS hides payloads without decryption |
| NetFlow / IPFIX | Who talked to whom, when, ports, byte counts—transfers and beaconing | Weeks to months | Metadata only; no payload; sampling can miss short flows |
| Firewall logs | Allowed/blocked connections at the perimeter and between zones | Days to months | Often logs blocks, not allows; internal (east-west) traffic frequently unlogged |
| Proxy / web logs | Outbound URLs, user-agents, data volumes to C2 and cloud-storage staging | Weeks to months | Only covers proxied traffic; attackers bypass the proxy |
| DNS logs | Name resolutions—C2 domains, DGA patterns, DNS-tunneling exfiltration | Days to weeks | Resolution is not connection; frequently not logged at all |
| EDR telemetry | Process, user, and command tied to each network connection on the host | Days to months (vendor-dependent) | Only where the agent is deployed; attacker may disable or evade it |
| Cloud flow / audit logs | VPC/VNet flows and API control-plane actions in cloud estates | Configurable; often 90 days default | Off by default in many accounts; flow logs lack payload |
How do you reconstruct the attacker timeline and dwell time?
Dwell time—the interval between initial compromise and detection—is the single most consequential figure in a breach investigation. It defines the window of exposure regulators and insurers will scrutinize, and it is almost always longer than the client’s first estimate. Reconstructing it means finding the earliest credible indicator of compromise, not the point at which someone noticed, and that requires reaching back further than most log retention windows comfortably allow.
The timeline is assembled by normalizing every source to a common, verified time base—reconciling clock skew, time zones, and UTC offsets across firewalls, proxies, DNS resolvers, EDR, and cloud logs—so that events from different systems can be ordered against one another. An examiner then anchors known indicators (a malicious domain, a compromised account, a beacon interval) and works outward, pushing the origin backward each time an earlier trace of the same infrastructure or behavior surfaces. Beaconing analysis is central here: command-and-control traffic tends to poll at regular intervals, and finding the first beacon in flow or proxy data often re-dates the intrusion to well before the incident that triggered the call. The output is a defensible chronology that states, for each phase, what evidence supports it and with what confidence—never a tidy narrative that outruns the data.
How do you trace initial access, lateral movement, C2, and exfiltration?
A modern intrusion moves through recognizable phases, and each leaves a characteristic signature in network evidence. Mapping the activity to a framework such as MITRE ATT&CK lets an examiner both structure the findings and identify the gaps where a phase must have occurred but the evidence has aged out. The following sequence is how the reconstruction typically proceeds.
- Initial access. Identify the entry vector—an exposed VPN or RDP service, an exploited edge appliance, a phishing payload calling home, or valid stolen credentials. Perimeter firewall and proxy logs, plus authentication records, usually hold the first foothold, though a single successful login can look mundane until correlated with what followed.
- Establishing command-and-control. Look for the beacon: periodic, low-volume outbound connections to attacker infrastructure, often over HTTPS, DNS, or a domain-fronted service. NetFlow reveals the rhythm; proxy and DNS logs reveal the destination; packet capture, if it survives, reveals the channel itself.
- Lateral movement. Trace east-west traffic between internal hosts—SMB, RDP, WMI, and remote-service creation—that indicates the attacker pivoting from the beachhead toward high-value systems. This is the phase most often invisible, because internal traffic is the least logged; EDR telemetry frequently carries the only record.
- Privilege escalation and credential access. Correlate authentication anomalies, service-account misuse, and directory-service queries that map the environment and harvest credentials for broader reach.
- Collection and staging. Detect data being gathered and compressed into archives on an internal staging host before it leaves—often visible as an internal spike in flows toward a single system.
- Exfiltration. Quantify the outbound transfer: bulk uploads to cloud storage, encrypted channels to attacker servers, or slow DNS tunneling. Flow byte-counts and proxy upload volumes are the workhorses here, establishing both destination and magnitude.
Not every phase will be evidenced on every network. A rigorous report is explicit about which phases are proven by direct evidence, which are inferred from surrounding activity, and which cannot be assessed because the relevant logs no longer exist—rather than papering over the gaps with assumption.
How do you scope the compromise—what was accessed versus taken?
Scoping is where network forensics translates into legal and financial consequence, and it turns on a distinction that opposing counsel and regulators will press hard: the difference between data an attacker could access and data that was demonstrably exfiltrated. Confusing the two overstates the breach and inflates notification obligations; ignoring the possibility of access understates it and invites liability. Elite examiners hold this line precisely.
Evidence of access comes from authentication logs, EDR file-interaction records, database query logs, and lateral-movement traces showing which systems the attacker reached. Evidence of exfiltration is narrower and harder: it requires showing data actually crossed the boundary, quantified by flow byte-counts, proxy upload volumes, or—rarely and most powerfully—packet capture of the transfer itself. Where direct exfiltration evidence is absent but access is proven, the honest finding is that data was exposed and exfiltration cannot be excluded, which is materially different from asserting it occurred. Many breach-notification regimes turn on exactly this reasonable-basis assessment, and a well-scoped opinion that distinguishes confirmed exfiltration from unverifiable access is what allows counsel to make a defensible notification decision rather than a fearful or negligent one.
Why does log volatility and retention decide the case?
The central adversary in post-breach network forensics is not the attacker—it is time. Network evidence is the most perishable class of digital evidence there is. Packet capture buffers overwrite in hours. Flow collectors and firewall logs roll on fixed windows. DNS query logs, where they exist, are often kept for days. Cloud flow logs may be disabled entirely or capped at a default retention that expires before the dwell period is even understood. Every hour between suspicion and preservation destroys evidence that cannot be recreated.
This is why the first and most valuable action in any suspected breach is not analysis but preservation. The moment an intrusion is suspected, retention windows must be extended, logs exported and hash-verified, packet buffers frozen, cloud log deletion suspended, and EDR data pulled before the vendor’s rolling window closes. A frequent and expensive failure is a client that spends its first week deliberating internally while the flow records that would have proven—or disproven—exfiltration silently age out. Once gone, those records are gone; no amount of expert skill recovers evidence that no longer exists. Disciplined, immediate preservation is what preserves the organization’s options, and it is the difference between a scoping opinion built on data and one built on speculation.
How do network findings support notification and litigation?
A network-forensic reconstruction is not an internal curiosity; it is a decision instrument. Its findings feed directly into breach-notification determinations under state, federal, and sector-specific regimes, into insurance claims where the carrier will test causation and quantum, and into litigation where every inference will be challenged. To carry that weight, the work must be built to an evidentiary standard from the first minute, not retrofitted afterward.
- Defensible preservation. Log exports, packet captures, and telemetry acquired and hashed under a documented process, with deletion suspended across all relevant systems.
- Continuous chain of custody. A complete record of who handled each dataset and export, from preservation through the final report.
- Validated, repeatable methodology. Parsing and correlation performed with accepted, court-tested tooling so the interpretation survives a reliability challenge.
- Confidence-rated findings. Each conclusion labeled as directly evidenced, reasonably inferred, or indeterminate—never a single narrative asserted as uniform fact.
- Clear access-versus-exfiltration separation. Notification-relevant conclusions that distinguish what was exposed from what demonstrably left, so counsel can act on a reasonable basis.
- Testimony-ready reporting. A report a qualified examiner can defend under cross-examination, explaining both what the evidence shows and the limits of what it can show.
The providers who separate world-class work from a log dump are those who state the boundaries of their own evidence. “Flow records show 4.2 GB transferred to an attacker-controlled host over this window, and EDR ties the process to a compromised service account” is a finding that survives. “The attacker stole everything” is a headline that collapses under the first competent deposition.
Representative scenario: the beacon that re-dated the breach
Consider a representative matter. A mid-market company detected suspicious activity after an employee reported a ransom-style message and engaged counsel, who retained a forensic team. IT’s initial assumption was that the intrusion began the week it was noticed. Preservation was the first move: flow records, proxy and DNS logs, EDR data, and cloud audit logs were exported and hash-verified before any retention window closed. Normalizing the sources to a common time base, examiners found periodic low-volume outbound beacons in the NetFlow data reaching back nearly three months—well before the noticed event—matched in the proxy logs to a domain that DNS records showed the environment resolving on a fixed cadence. EDR telemetry tied the beacon to a service account and traced east-west movement toward a file server. Flow byte-counts then showed a several-gigabyte outbound transfer to a cloud-storage endpoint during a single overnight window. Access was proven to several systems; exfiltration was confirmed for one dataset and could not be excluded for others. That distinction—not a blanket claim—let counsel scope notification defensibly. No single log told the story; reconciled together, with hashes and chain of custody intact, they reconstructed the intrusion with a confidence internal speculation never could. This is an illustrative scenario, not a named client or claimed outcome.
Do you handle post-breach network forensics nationwide?
Yes. Digital forensics and cybersecurity are delivered from our Arizona home command across all U.S. jurisdictions and internationally, because log acquisition, packet and flow analysis, and cloud-evidence examination are in-house and remote-by-design. Whether the matter sits in Phoenix, another state, or abroad, the same standards apply—hash-verified acquisitions, continuous chain of custody, and court-ready reporting that separates proven fact from reasoned inference.
Frequently asked questions
Can you investigate a breach if we didn’t have full packet capture?
Almost always, yes. Full packet capture is the highest-fidelity source but the rarest to survive the dwell period, so most investigations rely on longer-lived metadata: NetFlow/IPFIX records, firewall, proxy, and DNS logs, EDR telemetry, and cloud flow and audit logs. Correlated across a common timeline, these reconstruct initial access, command-and-control, lateral movement, and the volume and destination of exfiltrated data. The critical factor is not whether you captured every packet but whether the surviving logs were preserved before their retention windows closed.
How do you determine how long the attacker was inside (dwell time)?
Dwell time is established by finding the earliest credible indicator of compromise, not the moment detection occurred. Examiners normalize every log source to a verified common time base, anchor known indicators such as a command-and-control domain or beacon interval, and work backward each time an earlier trace of the same infrastructure or behavior appears. Beaconing analysis in flow and proxy data frequently re-dates an intrusion to weeks or months before the triggering event, which is why dwell time is usually longer than a client’s first estimate and why early log preservation is decisive.
What is the difference between data that was accessed and data that was exfiltrated?
Access means the attacker could reach a system or dataset—shown by authentication logs, EDR file-interaction records, database queries, and lateral-movement traces. Exfiltration means data demonstrably crossed the network boundary—shown by flow byte-counts, proxy upload volumes, or packet capture of the transfer. The distinction is legally decisive: where access is proven but exfiltration evidence is absent, the defensible finding is that data was exposed and exfiltration cannot be excluded, which differs materially from asserting theft occurred. Many notification regimes turn on exactly this reasonable-basis assessment.
How fast do we need to act to preserve network evidence?
Immediately—network evidence is the most perishable digital evidence there is. Packet buffers overwrite in hours, and flow, firewall, DNS, and cloud logs roll on fixed windows measured in days to weeks. The moment a breach is suspected, retention should be extended, logs exported and hash-verified, packet buffers frozen, cloud log deletion suspended, and EDR data pulled before the vendor’s rolling window closes. Time spent deliberating internally destroys evidence that cannot be recreated, so early preservation—before analysis even begins—is what preserves your options.
About Honeybadger Solutions
Honeybadger Solutions is an Arizona-licensed security and investigations firm providing digital forensics, cybersecurity, and full-spectrum investigations to organizations, counsel, insurers, and principals nationwide and internationally. Our forensics, cybersecurity, financial-investigations, and background-intelligence capabilities are in-house and remote-by-design, conducted under recognized methodologies with hash-verified acquisitions, continuous chain of custody, and board- and court-ready reporting. We operate three Arizona offices—Casa Grande (headquarters), Phoenix, and Oro Valley—and support engagements across every Arizona venue, all U.S. jurisdictions, and abroad.
Suspect a breach and need to know how they got in and what left? Call 602-725-2818 to brief a digital-forensics lead and preserve your network logs before their retention windows close. Confidential. Defensible. Nationwide.
Authoritative references: NIST SP 800-61r2, Computer Security Incident Handling Guide, NIST SP 800-86, Guide to Integrating Forensic Techniques into Incident Response, and the MITRE ATT&CK framework.