Network and Email Forensics

Introduction

Network and email forensics is the disciplined examination of communications data to determine what happened, when it happened, which systems and accounts were involved, and how confidently the findings can be supported. It combines packet capture, network-flow analysis, DNS and web investigation, firewall and VPN review, authentication analysis, and email examination.

Unlike a conventional disk investigation, network and email evidence is often distributed across many systems and may be short-lived. A packet capture can be overwritten, a DNS record can change, a cloud mailbox can be subject to retention policies, and a log timestamp can be misleading if systems use different time zones. The investigator must therefore preserve evidence quickly, understand the limitations of each source, and correlate independent artefacts rather than relying on a single log entry.

The central forensic question is not merely “What does this log say?” but “What event, or sequence of events, best explains all reliable observations?” This chapter develops that approach for professional investigations.

Learning Objectives

By the end of this chapter, the learner should be able to:

1. Distinguish packets, flows, sessions, logs, and reconstructed application activity.
2. Explain how DNS, HTTP(S), firewall, VPN, authentication, and email artefacts support an investigation.
3. Preserve network and email evidence using defensible forensic procedures.
4. Reconstruct a timeline and correlate evidence across multiple systems.
5. Identify common anomalies, false positives, and investigative limitations.
6. Evaluate legal, privacy, governance, and evidential issues.
7. Produce a concise, reproducible forensic conclusion.

1. The Network Evidence Environment

A network event may leave evidence at several layers. A packet capture records individual packets and their headers. A flow record summarises a conversation, commonly by source and destination addresses, ports, protocol, start and end times, and byte counts. A firewall records policy decisions. A DNS resolver records name queries and responses. A VPN gateway records tunnel establishment and user authentication. An identity provider records login attempts and token use. An email platform records message metadata, delivery, authentication, and mailbox activity.

These sources have different evidential strengths. A full packet capture may reveal protocol content, but it is expensive to retain and may be encrypted. A flow record is efficient and scalable, but normally cannot establish the precise content of a conversation. A firewall log can show that traffic was allowed or denied, but not necessarily that an application transaction succeeded. Correlation is therefore essential.

1.1 Important terminology

An IP address identifies a network interface at a particular time; it does not automatically identify a person. Dynamic addressing, carrier-grade NAT, proxies, virtual machines, and shared devices can create ambiguity. Attribution requires corroboration from address-allocation records, authentication logs, endpoint evidence, and other context.

1.2 Time as a forensic control

Timeline reconstruction depends on consistent clocks. Investigators should record the time zone, clock source, clock drift, timestamp precision, and whether daylight-saving changes apply. Coordinated Universal Time (UTC) is normally preferred for correlation. A timestamp from an email header may represent the sending host’s claimed local time, whereas a provider’s delivery log may use UTC. These values must not be treated as interchangeable without conversion and validation.

A useful normalisation model is:

Here, t_UTC is UTC time, t_local is the recorded local time, and offset is the local offset from UTC at that date. The relationship assumes the recorded offset is correct and that daylight-saving rules have been correctly applied. If the source clock is unreliable, the conversion does not make the event precise; it only provides a comparison basis.

2. A Forensic Workflow for Network and Email Investigations

A defensible workflow normally contains the following stages:

1. Authority and scope – Confirm legal authority, investigative purpose, systems in scope, time period, and handling restrictions.
2. Preservation – Prevent overwriting or alteration of PCAP, logs, mailbox data, cloud audit records, and relevant configurations.
3. Collection – Acquire original or provider-exported data, record collection methods, and calculate integrity hashes where applicable.
4. Validation – Check completeness, time settings, parser accuracy, retention gaps, and whether the source was generated by a trusted system.
5. Examination – Extract conversations, DNS relationships, authentication sequences, email metadata, and suspicious artefacts.
6. Correlation – Compare independent sources and construct competing explanations.
7. Analysis – Assess behaviour, intent indicators, scope, impact, and confidence.
8. Reporting – Explain methods, findings, limitations, evidence references, and reproducible reasoning.

Hashing supports integrity verification. For a file, a cryptographic digest such as SHA-256 is calculated at acquisition and checked later. A matching digest supports the conclusion that the file has not changed since hashing; it does not prove that the source was accurate or that the file was lawfully obtained.

3. Packet and Flow Forensics

3.1 Packet examination

A packet investigator may examine Ethernet or wireless metadata, IP headers, TCP flags and sequence behaviour, UDP exchanges, application protocols, and payloads. Useful observations include:

• repeated connection attempts with no completed handshake;
• unusual destination ports or protocols;
• large outbound transfers;
• periodic beacon-like connections;
• protocol violations or malformed fields;
• DNS requests immediately preceding connections;
• traffic between a workstation and an unusual external host.

TCP analysis requires care. A SYN indicates an attempted connection, not a successful application session. A SYN followed by SYN-ACK and ACK indicates a completed TCP handshake, but it does not prove that the intended application transaction succeeded. Resets, retransmissions, asymmetric capture, packet loss, and middleboxes can produce misleading patterns.

Encrypted traffic still exposes valuable metadata: endpoints, ports, timing, packet sizes, certificate information where visible, and sometimes domain information. Encryption normally prevents content interpretation without appropriate keys or endpoint evidence. Investigators must avoid claiming that encrypted traffic proves a particular action when only metadata is available.

3.2 Flow analysis

Flow records are especially useful for large-scale triage. They can identify new external relationships, unusual volume, lateral movement, scanning, and data-transfer timing. A basic rate calculation is:

The rate is measured in bytes per second when bytes are divided by seconds. It is meaningful only when the flow duration and byte counter definitions are known. Some systems count both directions; others report inbound and outbound bytes separately. A high rate alone is not evidence of exfiltration: backups, software updates, video meetings, and cloud synchronisation may create similar patterns.

A flow should be interpreted with direction, protocol, asset role, historical baseline, and user context. A database server communicating with a backup provider may be normal; the same communication from a point-of-sale terminal may be anomalous.

3.3 Reconstructing a network event

A practical reconstruction asks:

• Which internal asset initiated the communication?
• Was the address static, dynamic, translated, or shared?
• Was the destination resolved by DNS, embedded in an application, or contacted by IP only?
• Was the connection allowed by a security control?
• Was authentication required and successful?
• What bytes, commands, or objects can be established?
• What endpoint or identity evidence confirms the actor?

A single packet rarely answers all these questions. The strength of a conclusion increases when unrelated systems independently support the same sequence.

4. DNS Forensics

DNS links names to addresses and often provides the earliest indication of malicious infrastructure. Relevant evidence includes recursive-resolver logs, authoritative-server logs, passive DNS data, endpoint caches, DNS-over-HTTPS records where available, and registration information.

Investigators should examine:

• newly observed or recently registered domains;
• high volumes of random-looking subdomains;
• unusually short time-to-live values;
• frequent changes of address;
• queries from systems that should not use external DNS;
• lookups followed by network connections;
• NXDOMAIN spikes, which may indicate failed lookups or algorithmic domain generation.

DNS evidence has limitations. A query does not prove that a connection occurred, and a connection to an address does not prove that the queried domain was used. Shared hosting, content-delivery networks, resolvers, caching, split-horizon DNS, and malware using hard-coded addresses complicate interpretation. DNS records are time-dependent and should be preserved with collection time and source.

5. Web and Application Forensics

Web investigations may involve proxy logs, web-server access logs, browser history, cookies, cache records, endpoint telemetry, TLS metadata, and application audit trails. A web-server entry can show request time, source address, method, URI, status code, response size, and user-agent. It does not necessarily identify the human user, because proxies, NAT, shared accounts, and automated clients may intervene.

Important distinctions include:

• Request versus success: a request with status 200 suggests a response was returned, but business logic may still have rejected the operation.
• Authentication versus authorisation: a valid login does not establish that the user was authorised to perform every action.
• Browser activity versus malware activity: a user-agent can be forged and is weak evidence alone.
• Download versus execution: a file being downloaded does not prove it was opened or executed.

Forensic analysis should preserve relevant request and response metadata while minimising unnecessary collection of personal content. When content is encrypted, endpoint logs or server-side audit records may be more informative than packet data.

6. Firewall, VPN, and Authentication Evidence

6.1 Firewall logs

Firewall records commonly contain timestamp, interface, source and destination, port, protocol, action, rule identifier, translated addresses, and session information. Investigators should determine whether the record describes the first packet, a session summary, or a policy decision. An “allow” event generally means that traffic matched a permitted rule; it does not demonstrate that the destination accepted the connection or that a user completed an action.

NAT is a major attribution issue. To map a public address and source port to an internal host, investigators may need the translation timestamp, protocol, port, and device logs. Approximate time or address alone may map to multiple devices.

6.2 VPN evidence

VPN logs may show tunnel creation, user identity, assigned address, multifactor authentication, device posture, connection duration, and disconnection. A VPN login establishes use of an account or credential, not necessarily the physical identity of the person. Investigators should correlate VPN assignment with endpoint identity, MFA events, impossible-travel indicators, device certificates, and activity after tunnel creation.

6.3 Authentication analysis

Authentication evidence includes successful and failed logins, password resets, token issuance, MFA challenges, conditional-access decisions, service-account use, and privilege changes. A useful sequence is:

1. Identify the account and authentication method.
2. Compare source address, device, location, and time with normal behaviour.
3. Determine whether MFA was completed, bypassed, or approved unexpectedly.
4. Examine token creation and subsequent resource access.
5. Check for mailbox rules, privilege changes, or persistence mechanisms.

“Impossible travel” is a triage signal, not proof of account compromise. Mobile networks, VPNs, cloud egress points, and inaccurate geolocation can produce false positives.

7. Email Forensics

Email evidence exists at several levels: message headers, message bodies and attachments, transport logs, mailbox audit logs, identity-provider records, endpoint artefacts, and security gateways.

7.1 Header interpretation

Important header fields include:

• From: displayed author identity; easily spoofed in many contexts.
• Reply-To: address used for replies; may differ from From.
• To/Cc: declared recipients, not necessarily the complete delivery path.
• Date: sender-provided timestamp and therefore not always reliable.
• Message-ID: message identifier generated by a sending system; useful for correlation but not proof of authorship.
• Received: server-added trace entries, read from the bottom upward to follow the apparent path.
• Return-Path: envelope sender recorded by the receiving system.
• Authentication-Results: receiving system’s results for SPF, DKIM, DMARC, and related checks.

Received headers are valuable but must be interpreted in context. A trusted receiving server may add a reliable entry, while earlier entries could have been inserted or altered by an untrusted sender. Header order, provider documentation, message trace records, and mailbox data should be compared.

7.2 SPF, DKIM, and DMARC

Sender Policy Framework (SPF) evaluates whether the sending IP is authorised for the envelope domain. DomainKeys Identified Mail (DKIM) uses a cryptographic signature to cover selected message headers and body content. Domain-based Message Authentication, Reporting, and Conformance (DMARC) evaluates alignment between authenticated domains and visible From identity and applies a policy such as monitor, quarantine, or reject.

A passing SPF result does not prove that the visible sender is legitimate. DKIM may pass for a legitimate intermediate service while the visible identity is deceptive. DMARC alignment and the provider’s enforcement decision are therefore important. Forwarding and mailing lists can affect authentication results.

7.3 Mailbox compromise and business email compromise

A business email compromise investigation should examine:

• suspicious sign-ins and MFA events;
• newly created forwarding rules or inbox rules;
• delegated mailbox access;
• OAuth application consent;
• changes to recovery information;
• message deletion or search activity;
• unusual sending patterns;
• altered payment instructions;
• related endpoint and browser evidence.

Message content must be handled carefully because it may contain privileged, personal, or confidential information. Investigators should collect the minimum necessary material under approved authority.

8. Correlation and Timeline Reconstruction

Correlation joins observations that share a reliable key: timestamp, IP and port, hostname, user identity, message ID, device identifier, VPN-assigned address, or file hash. The investigator should document clock conversions and uncertainty rather than silently adjusting data.

A timeline should distinguish:

• Observed events: directly recorded, such as a successful login.
• Inferred events: supported by several observations, such as probable mailbox access.
• Hypotheses: possible explanations requiring further testing.

A confidence assessment can be qualitative—high, moderate, or low—provided the criteria are defined. High confidence might require multiple independent, consistent sources with no material contradiction. Moderate confidence may reflect strong but incomplete evidence. Low confidence is appropriate where evidence is indirect, ambiguous, or affected by major gaps.

Figure: Independent network and email observations can be correlated along a normalised timeline.

A useful analytical technique is the event matrix. Each row is an event; columns identify source, time, actor or asset, action, reliability, and related evidence. Contradictions should be recorded, not hidden. For example, a mailbox audit record may indicate access at 10:03, while a client log is absent because the user accessed webmail from an unmanaged device.

9. Applied Case: Illustrative Payroll-Redirection Investigation

Background

A finance employee reported that a supplier’s bank details had changed after an email exchange. The organisation suspected either account compromise or spoofed email.

Problem

The investigator had to determine whether the supplier’s mailbox was compromised, whether the employee’s account was involved, and whether the payment instruction originated from an authenticated source.

Analysis

The team preserved the relevant messages in their original format, mail gateway logs, identity-provider records, VPN logs, endpoint telemetry, and DNS data. The visible From address matched the supplier, but the Reply-To address differed. SPF passed for the envelope domain, while DKIM passed for a third-party sending service; DMARC alignment with the visible From domain failed.

Mailbox audit records showed a new forwarding rule created shortly before the suspicious exchange. Identity logs recorded a successful login from an unfamiliar device, followed by an MFA approval. The assigned address was correlated with VPN and provider records. Network-flow data showed access to the mailbox service but did not reveal message content because the session was encrypted.

The team tested alternative explanations. A simple spoofing scenario could explain the message headers but not the forwarding rule and mailbox audit event. A compromised supplier account explained the rule and the message sequence, but the evidence did not establish who controlled the device that approved MFA. Endpoint evidence from the employee’s computer showed no corresponding account access.

Approach and solution

The organisation disabled the forwarding rule, revoked active sessions and tokens, reset credentials, required phishing-resistant MFA, contacted the supplier through an independently verified channel, and delayed payment. Investigators preserved provider exports and documented each action so remediation did not overwrite evidence.

Outcome

The evidence supported a conclusion of probable compromise of the supplier mailbox or its identity environment, with moderate-to-high confidence. It did not support attributing the activity to a named individual. The email alone was insufficient; the conclusion depended on correlation between authentication, mailbox audit, header, and payment-process evidence.

Learning points

1. A displayed sender address is not reliable proof of origin.
2. Authentication results must be interpreted as separate tests and in alignment.
3. Mailbox rules and token events may be more probative than message content.
4. Network metadata can establish access context even when payloads are encrypted.
5. Forensic conclusions must distinguish compromise from human attribution.

10. Legal, Ethical, and Governance Considerations

Network and email investigations may involve interception laws, privacy legislation, employment rules, contractual restrictions, cross-border transfer requirements, and sector-specific retention duties. Authority should be confirmed before collecting content or monitoring communications. The scope should specify systems, users, dates, data types, and permitted analytical purposes.

Investigators should apply data minimisation, access control, segregation of privileged material, and retention limits. Sensitive data may include health information, legal correspondence, personal communications, credentials, and commercially confidential content. A forensic copy should be protected as carefully as the original.

Reports should be factual and reproducible. They should identify tools and versions, collection dates, time standards, filtering criteria, known gaps, and alternative interpretations. Investigators must not overstate attribution, intent, or certainty. Automated threat-intelligence scores and AI-generated classifications are leads, not independent proof. Any AI-assisted analysis should be validated against original evidence, documented, and reviewed by a qualified investigator.

11. Challenges and Limitations

Major limitations include encryption, incomplete packet capture, log rotation, clock drift, NAT, cloud-provider opacity, shared accounts, spoofed headers, forwarding, deleted messages, inconsistent retention, and malware that avoids standard DNS or proxy paths. Traffic may traverse several jurisdictions and providers, making lawful access and preservation slow.

False positives arise from legitimate cloud services, automated scanners, travel, VPN use, compromised infrastructure, and shared hosting. False negatives arise when telemetry is disabled, traffic is encrypted, logs are altered, or an attacker uses legitimate credentials. No single tool detects all activity.

Best practice is to preserve raw sources, use multiple independent artefacts, validate parser output, maintain a documented hypothesis log, and state uncertainty explicitly.

12. Best-Practice Checklist

• Obtain and record authority before collection.
• Preserve volatile logs and packet captures promptly.
• Record source, collector, method, time zone, and integrity hash.
• Normalise times to UTC while retaining original timestamps.
• Separate observation from inference and attribution.
• Correlate DNS, flow, firewall, VPN, identity, endpoint, and email evidence.
• Interpret NAT, proxies, and cloud egress carefully.
• Examine mailbox rules, OAuth grants, tokens, and audit activity.
• Treat SPF, DKIM, and DMARC as distinct and contextual controls.
• Minimise exposure of personal and privileged information.
• Test alternative explanations and document contradictions.
• Report limitations, confidence, and reproducible methods.

Chapter Summary

Network and email forensics reconstructs communication events by combining packet captures, flows, DNS, web records, firewall decisions, VPN activity, authentication data, mailbox audits, and email headers. Packets provide detail but may be unavailable or encrypted; flows scale well but provide less content. DNS links names and infrastructure but does not prove a subsequent connection. Firewall and VPN logs establish policy and access context, while authentication and mailbox records help evaluate account compromise.

Reliable investigation depends on preservation, time normalisation, evidence validation, correlation, and careful distinction between observed facts and inferred explanations. Email headers and authentication mechanisms are useful but can be misleading when examined alone. Legal authority, privacy, chain of custody, data minimisation, and transparent reporting are essential. The strongest conclusions arise from independent, consistent evidence and explicitly acknowledge uncertainty.

Key Terms

Packet: A formatted unit of network transmission.

Flow: A summary of related network traffic.

PCAP: A file containing captured network packets.

DNS: The naming system that resolves domain names to network addresses.

NAT: Translation between address or port spaces, often obscuring the original internal host.

Firewall log: A record of traffic evaluated against security policy.

VPN: An encrypted or logically isolated connection to a private network.

Authentication: Verification of an account or entity’s claimed identity.

Authorisation: Determination of what an authenticated identity may do.

SPF: A mechanism for checking authorised sending hosts for an envelope domain.

DKIM: A cryptographic email-signing mechanism.

DMARC: A policy and reporting framework using domain alignment and authentication results.

Message-ID: An identifier associated with an email message.

Mailbox audit log: A record of mailbox access and administrative actions.

IOC: An indicator associated with potentially malicious activity.

Chain of custody: Documentation of evidence possession and handling.

Correlation: Linking observations across sources using common attributes.

NAT: Network address translation that maps one address space to another.

SIEM: A platform for collecting, searching, and correlating security events.

Data minimisation: Collecting and retaining only data necessary for the defined purpose.

Review Questions

Short Answer Questions

1. Why does a successful TCP handshake not prove that an application transaction succeeded?
2. What is the forensic significance of a mailbox forwarding rule created shortly before suspicious email activity?
3. Why should an IP address not automatically be treated as the identity of a person?
4. What are the distinct purposes of SPF, DKIM, and DMARC?
5. Why is UTC commonly used in forensic timeline correlation?

Long Answer Questions

1. Explain a complete workflow for investigating a suspected data exfiltration event using network and endpoint evidence.
2. Compare the evidential strengths and limitations of packet captures, flow records, firewall logs, and DNS logs.
3. Describe how an investigator should analyse a suspected business email compromise.
4. Explain how NAT, VPNs, proxies, and cloud services complicate attribution.
5. Discuss the legal, ethical, and governance requirements for collecting and analysing email evidence.

Analytical / Application Questions

1. A user logs in successfully from a foreign IP address, passes MFA, creates a mailbox rule, and later sends an unusual message. Construct an investigation plan and identify at least three alternative explanations.
2. A flow record shows a large outbound transfer to a cloud provider, but no packet payload is available. What additional evidence would you seek before concluding that data exfiltration occurred?
3. An email passes SPF and DKIM but fails DMARC alignment. Explain what can and cannot be concluded, and identify the evidence required for attribution.

Multiple Choice Questions with Answers

Question 1

Which evidence source normally provides the greatest detail about packet headers and available payloads?

A. A full packet capture

B. A NetFlow summary

C. A firewall rule inventory

D. A DNS zone file

Correct Answer: A. A full packet capture

Question 2

What does a successful firewall “allow” event establish most directly?

A. The user completed the intended application action

B. Traffic matched a permitted policy decision

C. The destination server stored the data

D. The source account was legitimate

Correct Answer: B. Traffic matched a permitted policy decision

Question 3

Which email field is most easily manipulated by a sender and should not alone establish authorship?

A. The visible From field

B. A provider-generated mailbox audit record

C. A receiving server’s authenticated log

D. A cryptographic file hash

Correct Answer: A. The visible From field

Question 4

What is the primary purpose of DMARC alignment?

A. To encrypt the email body

B. To assign a mailbox password

C. To relate authenticated domains to the visible From identity

D. To identify the physical sender

Correct Answer: C. To relate authenticated domains to the visible From identity

Question 5

A flow transferred 600,000,000 bytes in 120 seconds. What was the average rate?

A. 500,000 bytes per second

B. 5,000,000 bytes per second

C. 50,000,000 bytes per second

D. 72,000,000,000 bytes per second

Correct Answer: B. 5,000,000 bytes per second

Question 6

Which statement about a DNS query is most accurate?

A. It proves that the queried service was successfully contacted

B. It proves that a particular person made the request

C. It can provide evidence of name-resolution activity but does not alone prove a connection

D. It always identifies the final destination server

Correct Answer: C. It can provide evidence of name-resolution activity but does not alone prove a connection

Question 7

Why is a successful VPN login insufficient by itself to identify the human actor?

A. VPNs never record timestamps

B. Credentials or MFA approvals may have been used by another person or device

C. VPNs cannot assign network addresses

D. VPN traffic is always unencrypted

Correct Answer: B. Credentials or MFA approvals may have been used by another person or device

Question 8

Which practice most directly supports evidence integrity?

A. Editing logs into a shorter narrative

B. Calculating and documenting a cryptographic hash at acquisition

C. Deleting irrelevant original records

D. Relying only on memory of the collection process

Correct Answer: B. Calculating and documenting a cryptographic hash at acquisition

Question 9

In a forensic timeline, what is an inferred event?

A. An event directly recorded by a source system

B. An event supported by analysis of multiple observations

C. An event invented to fill every time gap

D. An event that has no relationship to the investigation

Correct Answer: B. An event supported by analysis of multiple observations

Question 10

Which conclusion is most defensible when encrypted traffic shows a connection to a suspicious host but no payload is available?

A. The exact stolen files are proven

B. The person who operated the device is proven

C. Communication metadata supports contact, but content and attribution remain unproven

D. The traffic must be harmless because it was encrypted

Correct Answer: C. Communication metadata supports contact, but content and attribution remain unproven