Unit 5: Dark Web, Email, and Web Attacks

I. Orientation — Principles of Digital Evidence Analysis

Digital evidence analysis is the identification, preservation, examination, interpretation, and presentation of information stored or transmitted in digital form. Dark-web activity, email offences, and web attacks must be investigated without altering source evidence and with sufficient documentation to make findings reproducible.

• Core characteristics:
  • Fragility: Opening a file, accessing a mailbox, or starting a system can change timestamps, logs, and temporary data.
  • Integrity: Cryptographic hashes such as SHA-256 demonstrate whether acquired data has changed.
  • Attribution limits: An IP address, email address, or account identifies a technical endpoint, not automatically the human operator.
  • Correlation: Reliable conclusions commonly combine headers, server logs, packet captures, browser artefacts, and provider records.
• Forensic principles:
  • Preservation: Capture volatile data where justified, isolate affected systems, and create forensic images or exports.
  • Chain of custody: Record who collected, transferred, stored, examined, and presented each item.
  • Repeatability: Document tool names, versions, time zones, filters, commands, and hash values.
  • Legality: Obtain proper authority and respect jurisdiction, privacy, scope, retention, and disclosure requirements.
• Basic integrity model:

H = SHA-256(E)

• E is the collected evidence and H is its hash value.
• Matching hashes before and after examination support integrity; they do not prove that the original source was truthful.

II. Dark Web — Hidden Services and Anonymous Activity

A. Dark Web

The Dark Web is the intentionally concealed part of the internet that generally requires specialised software or configuration, such as the Tor network, to access services whose locations are obscured.

• Web layers:
  • Surface web: Publicly reachable and normally indexed pages.
  • Deep web: Unindexed or access-controlled resources, including webmail, databases, and private portals.
  • Dark web: Hidden services accessed through anonymity networks; Tor onion services commonly use .onion addresses.
• Tor operation: Traffic is relayed through multiple nodes, typically an entry guard, middle relay, and exit relay for ordinary internet destinations; layered encryption gives Tor its “onion routing” name.
• Legitimate uses: Journalists, whistle-blowers, researchers, and citizens under censorship may use anonymity to reduce surveillance risks.
• Criminal uses: Markets may advertise stolen credentials, malware, counterfeit documents, illicit goods, or ransomware leak data, often using cryptocurrency and escrow.
• Evidence sources: Investigators may preserve pages, forum posts, usernames, PGP public keys, cryptocurrency addresses, timestamps, downloaded files, and network or endpoint artefacts.
• Collection controls: A capture should record the full onion address, UTC time, session context, screenshots, page source, and file hashes; merely taking a screenshot may omit metadata and linked content.
• Attribution limits: Reused usernames, wallet transactions, operational-security mistakes, seized servers, and endpoint evidence can support attribution, but no single indicator is normally conclusive.

B. Applications and Limitations

Dark-web analysis supports intelligence and criminal investigation, but anonymity, volatility, and legal boundaries restrict collection.

• Volatility: Services frequently disappear, migrate, or change addresses, making timely preservation important.
• Deception: Vendor claims, identity documents, and leaked datasets may be fabricated or repackaged.
• Legal scope: Passive observation differs from purchasing illegal material, interacting undercover, or deploying technical exploits; each may require separate authority.
• Safety: Investigators use isolated environments, controlled identities, disabled active content, and secure evidence storage to reduce malware and exposure risks.

III. Email — Architecture, Protocols, and Evidence

A. Email Basics

Email is a store-and-forward messaging system in which clients and servers exchange message content and routing metadata through standard protocols.

• Participants:
  • MUA: A Mail User Agent, such as a desktop or webmail client, composes and reads messages.
  • MTA: A Mail Transfer Agent relays messages between servers.
  • MDA: A Mail Delivery Agent places a message into the recipient’s mailbox.
• Protocols:
  • SMTP: Sends or relays mail, commonly using ports 25, 587, or 465 depending on role and encryption.
  • IMAP: Synchronises server-hosted mail, commonly on ports 143 or 993.
  • POP3: Downloads messages, commonly on ports 110 or 995.
• Message structure: An email contains headers, a blank line, and a body; MIME enables HTML, alternative text, attachments, and content encodings.
• Important headers:
  • From and Reply-To: Displayed identities that may be spoofed.
  • Received: Added by mail servers and read from bottom to top to reconstruct the route.
  • Message-ID: A nominally unique identifier useful for correlation.
  • Date: Sender-supplied time, which must be checked against server timestamps and time zones.
• Authentication:
  • SPF checks whether a sending host is authorised for a domain.
  • DKIM validates a domain-associated cryptographic signature.
  • DMARC defines policy and reporting based on aligned SPF or DKIM results.

Received: from host.example by mail.example; 12 Mar 2025 10:15:00 +0000
Message-ID: <identifier@example>

• Forensic value: Full raw headers preserve routing evidence that forwarding, screenshots, or copied message text may lose.

B. Evidential Limitations

Email metadata must be corroborated because user-controlled fields and compromised accounts can create misleading identities.

• Spoofing: The visible From field alone does not prove origin.
• Compromise: A correctly authenticated message may still be malicious if an authorised account or server was taken over.
• Time interpretation: Analysts normalise timestamps to UTC while retaining original offsets.
• Attachments: Files are hashed and examined in isolation; macros, links, archives, and filename extensions require separate validation.

IV. Email Crime Investigation — Forensic Workflow

A. Email Crime Investigation and Its Steps

Email crime investigation systematically preserves and correlates message, account, device, and server evidence in cases such as phishing, fraud, harassment, malware delivery, and business email compromise.

1. Obtain authority and define scope:
   • Identify relevant accounts, devices, providers, dates, offences, and permitted collection methods.
   • Issue preservation requests promptly where provider records may have short retention periods.
2. Secure and preserve evidence:
   • Isolate affected devices where necessary and record system time, login state, and network status.
   • Export messages in a metadata-preserving format such as EML, MSG, MBOX, or provider-native output.
   • Hash exports and forensic images; preserve originals as read-only evidence.
3. Document chain of custody:
   • Assign an evidence identifier and record collector, date, time, location, transfer, storage, and hash.
4. Examine headers:
   • Trace Received lines, compare From, Return-Path, and Reply-To, and inspect SPF, DKIM, and DMARC results.
   • Treat private IP addresses and unauthenticated headers cautiously.
5. Analyse content and attachments:
   • Extract URLs, domains, phone numbers, payment instructions, cryptocurrency addresses, and linguistic indicators.
   • Calculate attachment hashes, identify actual file types by signatures, and use controlled static or sandbox analysis.
6. Correlate external records:
   • Compare email timestamps with authentication logs, IP assignments, DNS data, proxy logs, browser history, financial transactions, and provider records.
7. Build a timeline and assess attribution:
   • Normalise times to UTC and distinguish creation, sending, receipt, opening, forwarding, and account-login events.
   • Separate facts from inferences; a shared IP address may represent NAT, VPN use, or multiple users.
8. Report and present findings:
   • Describe methods, tools, hashes, limitations, and conclusions in reproducible terms.
   • Include relevant header fields and timeline entries without exposing unrelated private data.

B. Significance and Constraints

A defensible email investigation depends more on preserved metadata and corroboration than on message appearance.

• Provider dependence: Subscriber and login data may require formal legal process and may be stored in another jurisdiction.
• Encryption: Transport encryption protects transmission but does not necessarily protect messages stored on an unlocked endpoint.
• False positives: URL scanners and malware tools provide indicators, not final proof; analyst validation remains necessary.

V. Intrusion Detection System — Monitoring and Alerting

A. Intrusion Detection System

An Intrusion Detection System (IDS) monitors host or network activity and generates alerts when it detects suspicious behaviour, policy violations, or known attack patterns.

• Types:
  • NIDS: A Network IDS examines packets or flows at network monitoring points.
  • HIDS: A Host IDS examines operating-system logs, processes, registry changes, and file integrity.
• Detection methods:
  1. Signature-based detection matches known patterns, such as a malware byte sequence; it is precise for known threats but weak against novel variants.
  2. Anomaly-based detection compares activity with a baseline; it may detect unknown attacks but often creates more false positives.
• Evidence generated: Alerts may contain source and destination IP addresses, ports, protocol, timestamp, rule identifier, and packet excerpt.
• Placement: Sensors may monitor an internet gateway, server segment, cloud traffic mirror, or critical host.
• Limitation: An IDS is primarily detective; unless integrated with another control, it alerts rather than automatically blocking traffic.

B. Analytical Use

IDS alerts guide investigation but require validation against original logs and contextual evidence.

• Triage: Analysts compare alert severity with asset value, vulnerability status, and repeated behaviour.
• Encrypted traffic: TLS can conceal payloads, leaving metadata such as destination, certificate, timing, and volume.
• Retention: Accurate clock synchronisation and preserved packet or flow data improve timeline reconstruction.

VI. Intrusion Prevention System — Active Traffic Control

A. Intrusion Prevention System

An Intrusion Prevention System (IPS) detects malicious activity and acts inline to stop it before the traffic reaches its target.

• Actions: An IPS may drop packets, terminate sessions, rate-limit traffic, quarantine a host, or temporarily block an address.
• Inline operation: Unlike a passive IDS sensor, an IPS sits in the traffic path, giving it enforcement power but also making availability important.
• Detection basis: IPS products use signatures, protocol validation, reputation data, and behavioural thresholds.
• Tuning: Rules are tested and adjusted because a false positive can block legitimate business traffic.
• Fail modes:
  • Fail-open preserves connectivity if the IPS fails but reduces protection.
  • Fail-closed blocks traffic during failure but can cause service disruption.

B. IDS–IPS Distinction

IDS and IPS may use similar detection logic, but their responses and operational risks differ.

• IDS: Out-of-band visibility, alerts, lower risk of disrupting traffic, and greater dependence on human response.
• IPS: Inline prevention, faster containment, and greater risk from incorrect rules or device failure.
• Forensic value: Both produce alerts and logs, but investigators should preserve configuration, rule version, action taken, and packet context.

VII. Web Application Firewall — Application-Layer Filtering

A. Web Application Firewall

A Web Application Firewall (WAF) inspects HTTP or HTTPS traffic and applies rules intended to protect web applications from malicious requests and responses.

• Deployment: A WAF may operate as a reverse proxy, appliance, host module, or cloud service in front of the application.
• Inspection targets: It evaluates URLs, methods, headers, cookies, query strings, request bodies, and sometimes responses.
• Controls: Rules can block injection patterns, restrict request size, rate-limit clients, challenge bots, and enforce allowed methods.
• Positive and negative security:
  1. Allow-listing permits only defined input formats and is restrictive but maintenance-intensive.
  2. Block-listing rejects known malicious patterns but may be bypassed through new encodings or variants.
• Evidence: WAF logs typically record client address, requested path, rule identifier, action, timestamp, and request details.

B. Applications and Limitations

A WAF provides compensating protection and visibility, but it does not replace secure application design.

• Strengths: Rapid virtual patching can reduce exposure while developers repair vulnerable code.
• Limitations: Business-logic abuse, stolen sessions, and authorised misuse may appear syntactically valid.
• Trust boundaries: Proxy chains complicate client-IP interpretation; headers such as X-Forwarded-For are trustworthy only when inserted by controlled infrastructure.
• Forensic practice: Correlate WAF events with web-server, application, database, identity, and load-balancer logs.

VIII. Web Application Attacks — Exploitation and Evidence

A. Attacks on Web Applications

Attacks on web applications exploit weaknesses in input handling, authentication, authorisation, configuration, session management, or business logic.

• Injection: Untrusted input changes a command or query; SQL injection may alter a statement such as SELECT ... WHERE id = input. Parameterised queries keep data separate from executable syntax.
• Cross-site scripting: Stored, reflected, or DOM-based XSS causes attacker-controlled script to execute in a user’s browser; output encoding and Content Security Policy reduce risk.
• Cross-site request forgery: CSRF induces an authenticated browser to submit an unwanted request; anti-CSRF tokens and SameSite cookies provide protection.
• Broken access control: Changing /account/1001 to /account/1002 may expose another user’s record if the server fails to recheck authorisation.
• Authentication attacks: Credential stuffing reuses breached username-password pairs, while brute force systematically guesses credentials; MFA and rate limits reduce impact.
• Path traversal and file inclusion: Inputs such as ../ attempt to reach files outside an intended directory; canonicalisation and strict allow-lists are required.
• Server-side request forgery: SSRF makes the server request an attacker-selected internal or external resource, potentially reaching cloud metadata or internal services.
• File-upload attacks: Malicious scripts, polyglot files, oversized archives, or misleading extensions can defeat weak validation.
• Denial of service: High request rates or computationally expensive operations exhaust bandwidth, threads, memory, or database capacity.
• Investigation evidence: Preserve HTTP requests, response codes, session identifiers, user-agent strings, application errors, database logs, deployed files, and relevant memory or process data.

B. Analysis and Mitigation

Web-attack analysis reconstructs the request path, determines whether exploitation succeeded, and identifies affected data or systems.

• Success indicators: A 200 response alone is inconclusive; database changes, spawned processes, new files, unusual outbound traffic, or unauthorised records provide stronger evidence.
• Secure development: Parameterised queries, contextual output encoding, server-side authorisation, secure session handling, dependency updates, and least privilege address root causes.
• Incident response: Contain affected services, preserve volatile and log evidence, rotate exposed secrets, remove persistence, patch the weakness, and monitor for recurrence.