Network Evidence Sources and Their Forensic Value

Routers and firewalls generate the broadest category of network log data. Every packet that traverses a router can potentially be logged, though in practice only access control list (ACL) hits, routing events, interface state changes, and administrative actions are recorded by default. Full per-packet logging on a busy router would overwhelm both the device's CPU and the receiving log server.

Firewall logs are more selective and more forensically useful than raw router logs. A stateful firewall records each connection it permits or denies: the source IP and port, destination IP and port, protocol, direction, rule that matched, bytes transferred, and duration. This connection-level record can establish that a specific external host initiated a connection to an internal server on a specific port at a specific time. In a data exfiltration investigation, outbound firewall logs showing large volumes of data leaving an internal IP to an unfamiliar external destination are a primary indicator.

The principal reliability concern with router and firewall logs is clock accuracy. Syslog messages carry only the timestamp generated by the device itself. If that device's clock has not been synchronised via NTP, the timestamp can be wrong by minutes or hours, making cross-source correlation unreliable. A firewall log showing a connection at 14:23:07 has limited value if the firewall clock was 47 minutes ahead of UTC, and that offset was not recorded. Investigators must establish the clock offset of each logging device at the time the logs were generated, typically by querying NTP server records or comparing logged events against events whose time is independently known.

A DHCP server assigns IP addresses from a pool on request. When a device joins the network, it broadcasts a DHCP discovery, the server responds with an offer, and the result is an IP-to-MAC binding for the duration of the lease, typically between 8 and 24 hours on most enterprise configurations. The server records this binding in its lease database, which is the primary evidence source for the question: which device had this IP address at this time?

DHCP lease logs provide device-level attribution, not user-level attribution. A MAC address identifies a network interface, not a person. On a shared device such as a library workstation or a lab computer, knowing the MAC address does not identify the user. On a personal laptop or mobile device, the MAC address is a closer proxy for a person, but it is not conclusive. The association between MAC address and a person requires corroborating evidence from another source such as physical access logs, CCTV, or user account login records.

A common investigative weakness is the DHCP lease database being reset or recycled before it is imaged. Unlike syslog files, DHCP lease databases are often stored in binary formats specific to the server software (ISC DHCP, Windows DHCP, Cisco IOS DHCP) and may not be exported to text automatically. Forensic preservation of DHCP evidence requires imaging the server's lease database file, not just exporting current leases, because current exports show only active assignments and discard expired ones.

NetFlow, and its vendor-neutral equivalents IPFIX (RFC 7011) and sFlow, record traffic conversation metadata rather than content. A flow is a sequence of packets sharing the same source IP, destination IP, source port, destination port, and protocol. The exporter (typically a router or a dedicated probe) aggregates packets into flows and sends flow records to a collector. Each record includes byte and packet counts, timing, and protocol flags such as TCP SYN and FIN indicators.

For network forensics, NetFlow data supports several investigative tasks that full packet capture cannot practically support at scale. An analyst can query a NetFlow collector for all flows involving a suspect IP over the past 90 days in seconds. The same query against stored PCAP would require parsing terabytes of data. NetFlow data therefore serves as the index: it identifies which sessions are relevant, after which targeted PCAP may be sought for those sessions specifically.

The limitation is the absence of payload. NetFlow cannot confirm what data was transferred in a session, only that a session occurred and how large it was. An investigator can use NetFlow to identify that a host sent 4.3 GB of data to an external IP over a six-hour window, but cannot use NetFlow alone to establish what those bytes contained. In jurisdictions where the distinction between traffic data and content data carries legal weight (such as under the EU ePrivacy Directive or the US Electronic Communications Privacy Act), this distinction also affects which lawful authority is required to collect and use the evidence.

RADIUS is the standard protocol for centralised authentication in enterprise networks. When a user connects to a Wi-Fi access point, a VPN gateway, or a wired 802.1X port, the access device forwards the authentication request to a RADIUS server. The server validates the credentials against a directory (typically Active Directory or LDAP) and returns an accept or reject. The RADIUS accounting component logs the result: the username, the client device MAC address, the access device address, the timestamp, and in accounting packets the session duration and bytes transferred.

From a forensic standpoint, RADIUS logs are the closest thing to a named-account audit trail for network access. A DHCP log can tell you that MAC address aa:bb:cc:dd:ee:ff held IP 10.0.1.47 from 09:14 to 17:31. A RADIUS log can tell you that user account jsmith authenticated from device aa:bb:cc:dd:ee:ff at access point AP-Floor3-East at 09:11, correlating that MAC to a named account three minutes before the DHCP lease was issued. Combined, these two records place a named account at a specific IP address and access point at a specific time.

RADIUS logs can also show failed authentication attempts. A sequence of failed attempts followed by a successful one on the same account from a different MAC address, or from an access point in a different physical location from the preceding session, is a pattern consistent with credential theft or account takeover. This pattern analysis is a standard technique in insider threat and account compromise investigations.

The reliability weakness in RADIUS logs is the same as in any authentication-based system: the log records that credentials were presented and accepted, not that the legitimate account owner presented them. A stolen password or a session token replayed by an attacker will produce a successful RADIUS authentication log entry in the victim's name. Corroborating the RADIUS record with physical access records, device forensics, or behavioural analysis is necessary to distinguish legitimate from fraudulent use.

A network IDS such as Snort or Suricata monitors traffic at a span or tap point, matching packet content and flow behaviour against a rule set. When traffic matches a rule, the system generates an alert containing the rule identifier, rule description, matched packet header fields, a timestamp, and often the triggering payload bytes. Anomaly-based systems generate alerts when traffic deviates statistically from a learned baseline, without requiring a specific signature match.

IDS alert logs are high-value investigative leads but require careful interpretation. Signature-based systems generate false positives when legitimate traffic resembles a known attack pattern. A web application that accepts binary file uploads may trigger buffer-overflow signatures on the upload content. An alert must be evaluated by examining the full packet context, not just the alert metadata. The rule that fired, the payload that triggered it, and the source and destination context all bear on whether the alert represents a genuine threat action.

In legal proceedings, IDS alerts have been accepted as evidence of suspicious activity in cases across the US, UK, and EU, but courts have distinguished between an alert establishing that certain traffic was observed and an alert establishing that an attack succeeded. An alert for a SQL injection attempt establishes that a crafted request was sent; it does not by itself establish that the database responded to the injection. Application logs or database audit trails are needed to establish the downstream effect.

No single network evidence source answers all investigative questions. The practical approach in network forensics is to use each source for the questions it is well-suited to answer, then correlate across sources to build a complete picture. Typically, IDS alerts or anomalous NetFlow patterns identify a suspicious event. DHCP logs identify the device at the source IP. RADIUS logs link that device to a named account. Firewall logs confirm the connection and its volume. PCAP, if available, provides payload context for the critical sessions.

Correlation requires a common time reference. All network logs must be normalised to the same timezone and checked against a known good time source before timestamps from different systems can be sequenced. The standard practice is to record the NTP synchronisation status and offset of each logging device at the time of evidence collection, document this in the chain of custody record, and apply the offset when constructing event timelines. Tools such as Zeek (formerly Bro) and commercial SIEM platforms automate this normalisation across ingested log types.

Chain of custody for network logs follows the same principles as for any digital evidence: the original source must be preserved with a cryptographic hash, access must be documented, and the process used to extract and analyse the logs must be reproducible. For live network devices, this typically means capturing the log data to a write-once medium or a SIEM with immutable storage, computing and recording the hash, and documenting the collection method. The Mobile and Network Forensics scope overview discusses these preservation requirements in the broader discipline context.