8. Network, Web, Email and Identity Forensics

Introduction and Context

Modern intrusions rarely leave evidence in a single system. A phishing message may be preserved in a mail gateway, resolved through DNS, opened through a browser, authenticated against an identity provider, and followed by network connections to an external service. The investigation therefore depends on correlating evidence across networks, applications, endpoints, cloud platforms, and identity systems.

Network, web, email, and identity forensics is the disciplined examination of communications and authentication records to reconstruct events, establish timelines, identify affected accounts and systems, and support defensible conclusions. It differs from simple log review. The investigator must understand how records are created, what they actually prove, what they omit, and how apparently conflicting timestamps or identifiers can be reconciled.

This chapter focuses on packet and flow evidence, DNS, proxies, firewalls, VPNs, web applications, email systems, and authentication records. It also considers the investigation of phishing, account compromise, lateral movement, exfiltration, and online fraud. The emphasis is analytical: evidence should be interpreted in context rather than treated as automatically conclusive.

Learning Objectives

After studying this chapter, the learner should be able to:

1. Distinguish packets, flows, sessions, and application logs as forensic evidence.

2. Interpret DNS, firewall, proxy, VPN, web, email, and identity records.

3. Construct a reliable incident timeline across systems using different clocks and identifiers.

4. Analyse phishing, credential compromise, lateral movement, exfiltration, and online fraud.

5. Evaluate the strengths, weaknesses, and evidential limits of network and identity data.

6. Apply a defensible workflow for collection, preservation, correlation, and reporting.

7. Explain the governance, privacy, and legal issues involved in communications forensics.

The Evidence Landscape

A packet is an individual network unit containing protocol headers and, where available, payload data. Packet capture can reveal addresses, ports, flags, sequence behaviour, protocol negotiation, and sometimes application content. Full-packet evidence is valuable for questions such as whether a connection was established, whether a protocol was encrypted, and what data was exchanged. It is nevertheless expensive to store and may be unavailable because of encryption, collection gaps, or network architecture.

A flow record is a summary of communication between endpoints during a period. Typical fields include source and destination addresses, ports, start and end times, packet and byte counts, and transport protocol. Flow data is less detailed than packet capture but often remains available for longer periods. It can identify unusual outbound volumes, beaconing patterns, or communication with an unfamiliar host, but normally cannot prove the precise content of a transaction.

A session represents an application-level interaction, such as an HTTP request sequence, a VPN login, or an authenticated web session. Session identifiers, cookies, request paths, user agents, and authentication context can connect activity that would otherwise appear as separate network events. Investigators must remember that identifiers may be shared, renewed, stolen, or deliberately manipulated.

Logs are records produced by security controls and business systems. Their evidential value depends on the source, configuration, retention, time synchronisation, completeness, and integrity of the record. A firewall deny event establishes that a device recorded a denied connection; it does not necessarily prove that the remote host attempted the connection if the event was generated from a malformed or spoofed packet. Similarly, a successful login shows that authentication was accepted, not automatically that the legitimate user was present.

Important Terminology

DNS translates names into addresses and other resource records. A resolver query log may show the requesting client, queried name, response, and time. DNS evidence can expose command-and-control lookups, newly registered infrastructure, algorithmically generated names, or data encoded in subdomain labels. However, caching, encrypted DNS, shared resolvers, and incomplete logging complicate attribution.

A proxy mediates web access and may record the client, destination, URL, method, response code, bytes, user identity, and policy action. A forward proxy represents internal users accessing external services; a reverse proxy represents an organisation’s web service to external users. A web application firewall (WAF) evaluates application requests and may record attack signatures, matched rules, and request details.

Firewalls enforce network policy. Their records commonly distinguish allowed and denied traffic, but fields vary considerably. VPN systems provide remote access and usually log connection time, assigned address, account, authentication method, device information, and disconnection time. VPN logs are especially important when an internal address is later associated with a remote user.

Email evidence includes message headers, envelope information, body content, attachments, mail-transfer-agent logs, mailbox audit logs, and gateway verdicts. The visible From field is not sufficient for attribution. Relevant header fields include Received lines, Message-ID, Reply-To, Return-Path, authentication results, and originating client information. Header chains must be interpreted from the receiving organisation backwards, because each mail server adds its own Received entry.

Identity evidence includes directory logs, single sign-on records, multifactor authentication events, password changes, token issuance, privilege changes, group membership, and cloud audit activity. Important attributes include account identifier, source address, device or browser information, authentication method, result, risk score, and session or token identifier.

A Forensic Model for Correlation

A useful analytical model separates four questions: who or what initiated an event, when it occurred, what resource was accessed, and what evidence demonstrates the action. The answers should be expressed with appropriate confidence. For example, a record may strongly show that account A authenticated successfully from address X at time T, while only moderately supporting the conclusion that a particular person controlled the session.

The investigation can be organised as a chain of linked observations:

• Identity: account, role, device, certificate, token, or mailbox.
• Location: source address, VPN-assigned address, autonomous system, geolocation, or internal segment.
• Time: event time, collection time, server time zone, and clock offset.
• Action: query, connection, login, message submission, file request, privilege change, or transfer.
• Object: domain, URL, mailbox, host, application, file, transaction, or cloud resource.
• Outcome: allowed, denied, successful, failed, transferred, modified, or deleted.

Correlation is strongest when independent systems agree. A suspicious mailbox login becomes more persuasive when an identity provider records a new device, a VPN system records a connection, DNS shows resolution of a known malicious domain, and proxy logs show access to a credential-harvesting page. The investigator should preserve both supporting and contradictory evidence rather than selecting only records that confirm an initial theory.

Time Normalisation and Identity Resolution

Time is a frequent source of error. Systems may use UTC, local time, daylight-saving time, or unsynchronised clocks. A professional timeline records the original timestamp, source time zone, normalised timestamp, and known clock offset. Precision should not exceed the precision of the source. A log showing only minutes cannot support a conclusion at the level of seconds.

Addresses also require careful interpretation. Network Address Translation may cause many users to appear behind one public address. Dynamic addressing can associate different users with the same address at different times. IPv6 privacy addresses, carrier-grade NAT, cloud proxies, and shared VPN gateways further weaken address-only attribution. DHCP, VPN, identity, endpoint, and network records should therefore be correlated using time and additional identifiers.

Investigation Workflows by Evidence Type

Packet and Flow Analysis

Begin by defining the investigative question and the relevant time window. Preserve the original capture or export, record its hash, and work from a verified copy. Establish normal traffic patterns before labelling activity anomalous. Useful questions include whether a TCP connection completed, which side initiated it, whether the traffic was encrypted, whether the volume was unusual, and whether a sequence of connections suggests beaconing or bulk transfer.

Packet analysis may reveal protocol misuse, unusual ports, malformed requests, certificate negotiation, DNS tunnelling characteristics, or clear-text credentials. Flow analysis supports broader questions: periodic low-volume traffic may indicate command-and-control polling, while a sudden outbound transfer to a rare destination may indicate exfiltration. Neither pattern is conclusive by itself. Software updates, backups, video conferencing, and cloud synchronisation can produce similar traffic.

DNS, Firewall, Proxy, and VPN Correlation

DNS analysis should connect query time, requesting host, resolver, answer, and subsequent connection. A query without a later connection may result from prefetching or an application check; a connection without a visible query may reflect caching or hard-coded addresses. Investigators should examine query frequency, record changes, unusual labels, and relationships among domains and addresses.

Firewall and proxy records provide complementary perspectives. A firewall may show that traffic was permitted while a proxy records the URL and authenticated user. Conversely, an unsuccessful proxy request may still produce a permitted network connection. Policy actions, TLS inspection status, response codes, and byte counts are important when determining whether a user merely reached a service or successfully downloaded content.

VPN analysis begins with the account and connection interval. The assigned internal address must be mapped to the user at the relevant time. Multifactor events, device posture, concurrent sessions, and subsequent internal access should then be examined. A VPN login from a familiar account does not eliminate the possibility of stolen credentials or token abuse.

Web Forensics

Web investigations cover both client browsing and attacks against web applications. Client-side evidence may include browser history, cache records, cookies, downloads, proxy logs, DNS queries, and endpoint telemetry. Server-side evidence includes access logs, application logs, WAF events, authentication records, database audit trails, and cloud load-balancer records.

The investigator should reconstruct requests in sequence rather than focusing on one URL. A typical attack may involve reconnaissance, authentication, exploitation, privilege escalation, data access, and deletion of traces. Important fields include method, URI, query parameters, status code, response size, referrer, user agent, source address, session identifier, and authenticated principal. A 200 response does not necessarily mean that the intended business operation succeeded, and a 500 response does not prove that exploitation failed.

For online fraud, technical reconstruction should be joined to business evidence. Login records, device fingerprints, payment events, account changes, beneficiary additions, and customer-service interactions may show how an attacker moved from access to financial impact. Risk engines and anomaly scores are leads rather than final proof.

Email and Phishing Investigations

Email analysis should distinguish message creation, transmission, delivery, opening, link selection, and subsequent authentication. Gateway logs may establish delivery; mailbox audit data may establish access; proxy or endpoint records may show link navigation. These are different events and must not be conflated.

Header examination begins with the receiving system’s Received line and proceeds through the chain. Investigators compare sender-domain authentication results, alignment, routing, timestamps, Message-ID patterns, and attachment metadata. SPF, DKIM, and DMARC results provide useful authentication context, but a passing result does not prove that a message is trustworthy: a compromised legitimate domain can pass all three.

A phishing investigation should identify the lure, the destination, the credentials or tokens requested, affected recipients, and any post-click activity. Similar messages should be clustered by subject, sender infrastructure, URLs, attachment hashes, and delivery times. Mailbox rules, forwarding settings, deleted items, and OAuth grants are especially important in business email compromise.

Identity and Authentication Forensics

Identity investigation examines the complete authentication lifecycle: attempted login, primary authentication, multifactor challenge, token issuance, session use, privilege change, and termination or revocation. Failed logins can indicate password spraying, while a successful login after many failures may indicate compromise or a legitimate user finally entering the correct password. Risk-based authentication decisions should be interpreted alongside the underlying events.

Particular attention is required for legacy protocols, service accounts, API keys, refresh tokens, delegated permissions, and single sign-on assertions. These mechanisms may permit access without a conventional interactive login. A password reset after suspicious activity may remove one access path while leaving active sessions or tokens valid.

Lateral movement is reconstructed by linking identity events with host and network records. Examples include remote-service authentication, administrative share access, remote management sessions, directory queries, and privilege-group changes. The analysis should distinguish a user’s normal administrative activity from unusual access involving new hosts, unusual hours, or excessive privileges.

An Applied Case: The Compromised Finance Mailbox

Background

The following is an illustrative case. Meridian Components, a manufacturing company, received a report that a supplier had been sent altered bank details. The finance manager denied sending the message and reported that several legitimate conversations appeared to have been deleted.

Situation and Analysis

The mail gateway preserved the message submitted from the manager’s mailbox. The message was internally addressed, passed normal domain authentication, and contained no malware. Mailbox audit records showed a successful sign-in from an unfamiliar address followed by the creation of an inbox rule forwarding messages containing words such as “invoice” and “payment.” Identity logs recorded a successful password authentication but no multifactor challenge because the access used a legacy protocol that was exempt from the organisation’s normal policy.

Proxy records showed that, shortly after the sign-in, the account accessed a cloud storage service and a webmail interface. DNS records showed resolution of a newly observed domain associated with the phishing page previously sent to the manager. The manager had clicked the link earlier that morning, and endpoint history showed a browser submission to the page. The evidence supported a sequence in which credentials were harvested, the mailbox was accessed through a legacy path, correspondence was monitored, and a fraudulent payment instruction was sent during an active supplier conversation.

Response Strategy and Outcome

The response team preserved mailbox, identity, proxy, DNS, and gateway records; revoked active sessions and tokens; disabled the legacy protocol; reset credentials; removed the malicious rule; and searched for similar messages and forwarding rules across the organisation. They contacted the supplier through a trusted channel and initiated financial fraud procedures. Review of audit records identified two additional targeted accounts, but no evidence that the attacker obtained administrative privileges.

The investigation report separated established facts from inferences. It could establish successful account access and message activity, but it could not identify the individual behind the external address without additional provider evidence. The organisation subsequently required phishing-resistant multifactor authentication for high-risk users, monitored mailbox-rule creation, and introduced dual verification for changes to payment instructions.

Learning Points

The case demonstrates that email, web, and identity evidence must be combined. A malicious message need not contain malware; a legitimate account can be abused; and a successful authentication record does not prove legitimate use. Legacy authentication, mailbox rules, token revocation, and business-process controls are central to preventing recurrence.

Challenges, Limitations, and Common Errors

Encryption reduces payload visibility, although metadata, certificate information, endpoints, and server logs may remain useful. Log loss is another major limitation: short retention periods, disabled auditing, overwritten captures, and undocumented filtering can create false gaps in the timeline. Centralisation improves correlation but creates a valuable target and requires strict access control.

Common analytical errors include treating an IP address as a person, assuming a phishing link was opened because an email was delivered, interpreting a successful login as proof of user presence, ignoring NAT and proxy infrastructure, and relying on a single vendor’s risk score. Investigators may also confuse event time with ingestion time, overlook clock drift, or alter original evidence while exporting it.

False positives are unavoidable. Automated detections should be tested against baselines and corroborated with independent records. False negatives arise when attackers use legitimate credentials, encrypted channels, cloud services, or compromised infrastructure. Absence of a log is not necessarily evidence that an event did not occur.

Governance, Ethics, and Professional Practice

Communications records often contain personal information, confidential business content, and legally privileged material. Collection should be authorised, proportionate, purpose-limited, and consistent with applicable law, employment rules, contracts, and organisational policy. Investigators should minimise unrelated content, restrict access, document approvals, and maintain a chain of custody.

Reports should distinguish observation, interpretation, and conclusion. Where attribution is uncertain, confidence levels and alternative explanations should be recorded. Evidence must be retained in a form that permits independent review. Investigators should avoid unnecessary disclosure of private communications and should coordinate with legal, privacy, human resources, compliance, and law-enforcement functions where appropriate.

Automation, Analytics, and Emerging Developments

Security information and event management platforms can normalise records, enrich addresses and domains, and correlate events across identity, network, and cloud sources. User and entity behaviour analytics can identify unusual access patterns, but models are sensitive to incomplete baselines and changing work practices. Machine-learning systems should support, not replace, human validation.

Encrypted DNS, HTTP/3, cloud-native architectures, passwordless authentication, and identity-centric security are changing the evidence environment. Endpoint and identity telemetry increasingly become more important than perimeter logs. Attackers also exploit legitimate cloud storage, collaboration platforms, OAuth grants, and session tokens. Consequently, organisations should design logging around investigative questions rather than collecting isolated technical events.

Best Practices for Practitioners

1. Define the investigative question, scope, authority, and time window before collection.

2. Preserve original records, hashes, metadata, export settings, and chain-of-custody information.

3. Normalise timestamps while retaining original values and clock information.

4. Correlate identity, address, device, session, DNS, network, and application identifiers.

5. Establish normal organisational behaviour before interpreting anomalies.

6. Treat authentication, delivery, access, and action as separate events.

7. Validate important conclusions with independent evidence.

8. Record uncertainty, missing data, alternative explanations, and confidence levels.

9. Revoke credentials, sessions, tokens, rules, and delegated permissions during containment.

10. Feed investigative findings into durable controls such as phishing-resistant MFA, logging, segmentation, and business-process verification.

Chapter Summary

Network, web, email, and identity forensics reconstructs incidents by correlating communications, application, and authentication evidence. Packets provide detail, flows provide durable summaries, and logs reveal decisions and actions made by security and business systems. DNS, firewall, proxy, VPN, web, email, and identity records each answer different questions and must be interpreted within their technical limitations.

Reliable investigations depend on time normalisation, identity resolution, evidence preservation, independent corroboration, and explicit treatment of uncertainty. Phishing and account compromise often involve a chain from message delivery to link use, credential or token capture, authentication, mailbox or application access, and fraudulent action. Encryption, NAT, cloud services, incomplete logging, and shared infrastructure limit attribution. Ethical and professional practice requires lawful collection, privacy protection, defensible reporting, and careful separation of fact from inference.

Key Terms

Packet: A discrete unit of data transmitted across a network.

Flow record: A summary of communication between network endpoints over a period.

Session: An application-level interaction maintained through state or identifiers.

DNS: A naming system that maps domain names to addresses and other records.

Forward proxy: An intermediary through which internal clients access external services.

VPN: An encrypted or authenticated connection providing access to a remote network.

WAF: A control that filters and records web-application requests.

NAT: Translation that maps private network addresses to other address representations.

SPF: A mail-domain policy identifying authorised sending hosts.

DKIM: A mechanism using a digital signature to protect aspects of an email message.

DMARC: A policy framework using domain alignment and authentication results for email handling.

Message-ID: An identifier intended to distinguish an email message.

Identity provider: A service that authenticates users and issues identity assertions or tokens.

Multifactor authentication: Authentication requiring two or more independent factor types.

Session token: A value used to maintain authenticated application access.

Lateral movement: An attacker’s progression from one internal system or account to another.

Exfiltration: Unauthorised removal or transfer of data from an environment.

Chain of custody: Documentation showing how evidence was collected, handled, stored, and transferred.

Clock drift: The difference between a system clock and a trusted reference time.

Review Questions

Short Answer Questions

1. How does a flow record differ from a packet capture?

2. Why is an IP address insufficient by itself for user attribution?

3. What types of evidence are useful in analysing phishing?

4. Why must original and normalised timestamps both be retained?

5. What is the forensic significance of a mailbox forwarding rule?

Long Answer Questions

1. Explain a defensible workflow for correlating DNS, firewall, proxy, VPN, and identity records.

2. Discuss how email headers, gateway logs, mailbox audits, and browser records can reconstruct a phishing incident.

3. Analyse the strengths and limitations of packet, flow, and application-level evidence.

4. Explain how identity records can be used to investigate account compromise and lateral movement.

5. Discuss ethical, legal, and governance considerations in communications forensics.

Analytical / Application Questions

1. A user account records a successful login from a familiar public address, followed by access to a new cloud service and creation of a mailbox forwarding rule. What additional evidence would you collect, and how would you distinguish legitimate remote work from compromise?

2. DNS logs show repeated queries to a suspicious domain, but proxy logs show no successful web request. Identify several explanations and describe the evidence needed to evaluate them.

3. A fraud complaint involves an altered payment instruction sent from a legitimate mailbox. Construct an evidence timeline from phishing delivery through account access and fraudulent communication, noting where attribution remains uncertain.

22. Multiple Choice Questions with Answers

Question 1

Which conclusion is most directly supported by a flow record showing a large outbound transfer to an external address?

A. The exact files transferred have been identified

B. A communication involving substantial outbound data occurred

C. The account owner intentionally exfiltrated data

D. The destination server was controlled by an attacker

Correct Answer: B. A communication involving substantial outbound data occurred

Question 2

Why should an investigator correlate a VPN-assigned address with VPN and identity logs?

A. Because public addresses always identify individuals

B. Because VPN addresses may be reused or assigned dynamically

C. Because VPN logs contain the contents of all user traffic

D. Because identity logs replace the need for timestamps

Correct Answer: B. Because VPN addresses may be reused or assigned dynamically

Question 3

What does successful SPF, DKIM, or DMARC authentication establish most accurately?

A. That the message is harmless

B. That the sender is the legitimate human user

C. That specified domain-authentication conditions were satisfied

D. That the recipient opened the message

Correct Answer: C. That specified domain-authentication conditions were satisfied

Question 4

A mailbox audit records a successful login, but no multifactor event occurred because a legacy protocol was used. What is the most relevant investigative implication?

A. The login must have been a false positive

B. The account may have been accessed without the normal multifactor control

C. The mailbox cannot have been compromised

D. The source address must belong to the user

Correct Answer: B. The account may have been accessed without the normal multifactor control

Question 5

Which combination provides the strongest basis for linking a phishing email to later account compromise?

A. Email delivery alone

B. A suspicious subject line and a foreign domain

C. Delivery, link navigation, credential submission, and subsequent unusual authentication

D. A message that passed domain authentication

Correct Answer: C. Delivery, link navigation, credential submission, and subsequent unusual authentication

Question 6

Why can a DNS query without a corresponding proxy request be misleading?

A. DNS never records client information

B. The query may result from caching, prefetching, or an application check

C. Proxy systems always delete DNS records

D. DNS queries prove that a file was downloaded

Correct Answer: B. The query may result from caching, prefetching, or an application check

Question 7

Which statement best describes a successful authentication event?

A. It proves the legitimate account owner was present

B. It proves that the endpoint was malware-free

C. It shows that the authentication system accepted the presented credentials or factors

D. It proves that all later actions were authorised

Correct Answer: C. It shows that the authentication system accepted the presented credentials or factors

Question 8

In a web investigation, why should request status codes be interpreted with application logs?

A. A 200 response always means a business operation succeeded

B. Status codes alone may not show the application-level result

C. Application logs cannot contain user identifiers

D. Status codes are unrelated to web requests

Correct Answer: B. Status codes alone may not show the application-level result

Question 9

Which practice best supports defensible forensic reporting?

A. Reporting only evidence that confirms the initial hypothesis

B. Converting all timestamps without retaining originals

C. Separating observed facts, interpretations, conclusions, and uncertainty

D. Treating automated risk scores as final attribution

Correct Answer: C. Separating observed facts, interpretations, conclusions, and uncertainty

Question 10

What is a major reason that an IP address should not be treated as a person’s identity?

A. IP addresses never appear in logs

B. NAT, proxies, dynamic assignment, and shared infrastructure can obscure the user

C. IP addresses identify only email content

D. IP addresses are always encrypted

Correct Answer: B. NAT, proxies, dynamic assignment, and shared infrastructure can obscure the user