Reconstructing a Network Timeline from Multiple Sources

Before any correlation work begins, the analyst must identify every log source that could contain relevant evidence and determine which of those sources still hold data covering the period of interest. Log retention policies vary widely: a consumer-grade router may overwrite its log every 24 hours; an enterprise SIEM may retain 12 months; a cloud provider may hold access logs for 90 days by default. The first investigative action after receiving a mandate is to issue preservation requests or legal holds for all in-scope log sources, because delay is the primary cause of evidence loss.

Common log sources and the evidence each provides: firewall and router logs record connection state (allowed or denied), source and destination addresses, ports, and byte counts, but generally not payload content. DNS server logs record query and response pairs with timestamps, revealing what hostnames a device resolved and when. DHCP server logs map IP addresses to MAC addresses within lease windows. Web proxy and HTTP logs capture URL-level detail for web traffic. VPN and authentication logs record session start and end times keyed to user credentials. Intrusion detection and prevention system (IDS/IPS) logs record signature-matched events. Where available, full packet captures (PCAP files) contain the complete traffic record and are the highest-fidelity source, though also the largest.

Each collected log file must be hashed (SHA-256 is the current standard) immediately after collection and the hash recorded in a chain-of-custody document alongside the collection time, the identity of the collector, and the source system's details. Log files are often collected from third parties, including ISPs, cloud providers, and enterprise administrators, and those parties must sign attestation statements confirming that the logs provided are complete for the specified period and have not been modified. Without such attestation, the completeness and authenticity of the logs may be challenged during proceedings.

Every device that generates log entries has a clock. That clock may be synchronised to an NTP server, manually set, or simply left running from the factory default. Over time, hardware clocks drift; cheap embedded devices in routers and switches can drift by several seconds per day. When two logs from different devices are correlated without correcting for this drift, events appear in the wrong sequence, or events that should overlap appear separated in time.

Normalisation begins by establishing the offset for each log source. The preferred method is to identify an anchor event: an event recorded in two or more log sources that can be matched with certainty (such as a login success that appears in both a web server access log and a firewall connection log). The difference between the timestamps for the same event in two different logs is the clock offset between those two devices at that moment. If the firewall records a connection at 14:23:05 UTC and the web server records the corresponding request at 14:23:12 UTC, the web server's clock is seven seconds ahead. All web server timestamps are then adjusted by subtracting seven seconds before building the combined timeline.

Where multiple anchor events are available across the period under investigation, the analyst can check whether the offset was stable or drifted. If offset measurements at two different times differ by more than a second, the clocks were drifting relative to each other. In that case, linear interpolation between the two measured offsets is the standard approach: each timestamp is corrected by the interpolated offset for its position in the time range. The uncertainty introduced by drift should be documented and reflected in the timeline, for example by treating events within the uncertainty window as having an indeterminate sequence.

After normalising timestamps, the analyst correlates entries across sources using three primary anchoring mechanisms: IP-address matching, session tuple matching, and application-layer identifier matching. Each mechanism works at a different layer of the network stack and provides a different degree of confidence.

IP-address matching links entries by source or destination IP. A DHCP log shows that 192.168.1.45 was assigned to MAC address AA:BB:CC:DD:EE:FF from 09:00 to 17:00. A firewall log shows connections from 192.168.1.45 to an external address at 11:32. The DHCP record identifies the physical device that held that IP during the connection window. This is the fundamental chain that converts a network address in a log to a device, and from a device to a person through asset ownership records.

Session tuple matching is more precise. A firewall log entry showing source 192.168.1.45:54231, destination 93.184.216.34:443 can be matched to a TLS session in a PCAP file with the same four-tuple and to a web proxy log entry that recorded the corresponding HTTPS URL. All three entries refer to the same TCP session, even though each source describes it differently. Session tuples are ephemeral: port numbers are reused after sessions close, so a tuple match is only valid within the session lifetime, confirmed by checking connection-start and connection-end entries across the sources.

Application-layer identifiers include HTTP cookies and session tokens, VPN session IDs, RADIUS accounting identifiers, and TLS certificate fingerprints. These identifiers persist across multiple IP-level connections and survive NAT changes, making them useful when a session crosses network boundaries or when a mobile device switches between Wi-Fi and cellular. An analyst correlating mobile network logs with enterprise Wi-Fi logs benefits from application-layer identifiers that cross both environments.

NAT is the most common source of attribution failure in network timeline reconstruction. When a router performs source NAT, it replaces the private source IP and port with its own public IP and a translated port number, records the translation in its state table, and forwards the packet. External systems see only the public IP. Unless the NAT gateway's translation log is obtained, the analyst cannot determine which internal host initiated the connection.

The translation log entry must include the private IP, the private port, the public IP, the public port, the destination IP, the destination port, and the session start and end times. With that record, the analyst can unambiguously match a firewall or ISP log entry (which shows only the public-side tuple) to the internal host. Without it, the best available evidence is the DHCP lease log, which narrows the pool of possible sources to every device that held a private address on the NAT network during the connection window, but cannot identify which specific device was responsible.

Carrier-grade NAT (CGNAT) introduced by ISPs since the depletion of IPv4 addresses adds a second translation layer: thousands of residential subscribers share a single public IP, with the ISP's CGNAT gateway performing the translation between the subscriber's assigned address and the shared public address. Investigators who receive a public IP address from an external service provider must subpoena both the external service provider (to confirm the IP and timestamp) and the ISP that holds the CGNAT translation logs, which are often retained for only a short period. Several European jurisdictions require ISPs to retain these records for six months to one year; retention periods in other jurisdictions vary.

A network timeline is almost never complete. Log rotation deletes old entries; logs from some devices were never collected; devices without logging enabled left no record at all. Documenting what is absent is as important as documenting what is present. A timeline that implicitly claims completeness when it is not may survive initial scrutiny but collapse under cross-examination when gaps are exposed.

The gap analysis begins with the expected source inventory: every device that was in the network path between the suspect activity and the target should have generated logs. For each expected source, the analyst records: whether logs were obtained, the date range covered by those logs, any discontinuities within that range (such as a two-hour gap where the log file shows no entries), and what the absence of a source implies for events that could have occurred in that window. A firewall with no log entries between 02:00 and 04:00 on the night in question may indicate log rotation, a firewall restart, or a deliberate log deletion, each of which carries different investigative weight.

When presenting a timeline in legal proceedings, the analyst must be precise about the epistemological status of each entry. An entry confirmed by three independent log sources carries more weight than one appearing in a single source. An entry in a period with high clock-skew uncertainty should be presented with its uncertainty range. Events not covered by any log source should be listed as unknown rather than simply absent from the timeline. Legal frameworks that govern electronic evidence, including the Bharatiya Sakshya Adhiniyam 2023 in India, the Federal Rules of Evidence in the United States, and the Police and Criminal Evidence Act 1984 in the United Kingdom, all require that digital evidence be accurate, reliable, and complete or that limitations on completeness be disclosed.

Mobile devices contribute a distinct class of log evidence that intersects network and device forensics. Cellular network logs, held by the mobile operator, record which cell tower or sector served the device at each point in time and which IP address was assigned to the device's data session. These records allow an analyst to place a device at a geographic location at a time that matches a network event, extending the timeline from the network layer into the physical world.

On the device itself, iOS and Android both maintain connection logs in system databases and diagnostic files. Wi-Fi connection history (SSIDs, BSSIDs, and connection timestamps) is recoverable from standard logical acquisitions and from the device's known networks database. These on-device records can be correlated with Wi-Fi controller logs from enterprise environments to confirm whether a device was associated with a specific access point at the time of an event. The methodology is described in more detail in Location History and Geolocation Artifacts; the key point for timeline reconstruction is that mobile logs must be clock-normalised just as server logs are, since device clocks can be manually set and may not be synchronised to a reliable NTP source.

Cloud backup and synchronisation logs add a further layer. When a mobile device synchronises with iCloud, Google Drive, or a corporate MDM platform, the sync event is timestamped on the cloud server side using the server's clock, which is typically far more reliable than the device clock. A sync event in a cloud log can anchor the device's local clock to a trusted reference even if the device's own NTP synchronisation history is unavailable. This technique is particularly useful when the device was seized and its clock manipulated after the incident but before seizure.