Chapter 3 — Authorized practice and evidence handling | Professional Digital forensics and malware analysis

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 3 — Authorized practice and evidence handling

Lesson map

Lesson 03 published. Map, example, EX011.

flowchart TD
  N0["Learning outcomes"]
  N1["3.1 Authority"]
  N2["3.2 Order of volatility"]
  N3["3.3 What to preserve"]
  N4["3.4 Hashing exports"]
  N5["3.5 Chain of custody"]
  N6["3.6 Preserve before fixing"]
  N7["3.7 Retention awareness"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX011"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["3.1 Authority"]
  N2["3.2 Order of volatility"]
  N3["3.3 What to preserve"]
  N4["3.4 Hashing exports"]
  N5["3.5 Chain of custody"]
  N6["3.6 Preserve before fixing"]
  N7["3.7 Retention awareness"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX011"]

[Learning outcomes]
    |
    v
[3.1 Authority]
    |
    v
[3.2 Order of volatility]
    |
    v
[3.3 What to preserve]
    |
    v
[3.4 Hashing exports]
    |
    v
[3.5 Chain of custody]
    |
    v
[3.6 Preserve before fixing]
    |
    v
[3.7 Retention awareness]
    |
    v
[Worked example] --> [Exercise EX011]

Learning outcomes

You will (1) confirm authority before collecting; (2) apply order of volatility to cloud and endpoint data; (3) preserve exports with hashes; (4) keep a chain of custody.

3.1 Authority

Marlow's acceptable use policy allows security staff to examine company accounts during incidents with manager approval. Dev's approval at 10:02 names Joy's mailbox and sign-in logs. Lena does not look at other mailboxes until scope is widened in writing. The approval is specific: one mailbox, its sign-in logs and the period from 1 to 3 March. When message trace later shows the phishing email reached six Marlow mailboxes, Lena asks Dev to widen scope, and he does so in writing at 11:10. Until then she knows only that other copies exist; she does not open those mailboxes or their logs.

3.2 Order of volatility

RFC 3227 advises collecting the most short-lived data first. In cloud services, that means audit records with short retention and active sessions; on Joy's PC, browser history before it is cleared or overwritten. For Marlow, Lena exports the sign-in log and mailbox audit records first, because some audit records are kept only 30 days and the session details are what tie the 09:14 sign-in to the rule. The inbox rule list comes next, before IT removes 'fwd'. Proxy records and the phishing email itself change more slowly, so they follow once the short-lived records are safe.

3.3 What to preserve

Sign-in logs, mailbox audit records, inbox rules, message trace, the phishing email itself and proxy records for Joy's PC. Lena exports each from the admin console with her own named admin account. Each item answers a question Lena has already written: the sign-in log shows who signed in and from where, audit records show what the session changed, message trace shows what left the mailbox, and proxy records show Joy's visit to the look-alike page. By the 12:00 ticket update the manifest lists six items, each with its source and export time.

3.4 Hashing exports

Each export is hashed with SHA-256 on download and listed in a manifest. Working copies are made for analysis; originals are stored read-only. Hashing at download fixes what was collected, so any later change to a file can be detected by recomputing the hash. Lena's analysis happens only on working copies; the originals in the read-only evidence share /IR-0303 are opened again only to make a fresh copy. The manifest check later catches a real problem in this case, when a spreadsheet edit changes the working copy of message_trace.csv and its hash no longer matches. Because the original was untouched, the fix takes minutes rather than a new export.

3.5 Chain of custody

The custody log records item, source, who exported it, when, hash and storage location, plus each later transfer. For Joy's inbox rules the entry names the item, the account j.okafor, Lena as collector, the 10:12 export time, the hash in the manifest and the share /IR-0303. If Dev or a peer takes a copy to reproduce a step, that transfer is added with time and recipient. A gap in the log, such as a copy whose origin nobody recorded, would make it hard to show the item was not altered. The log is kept beside the manifest, so integrity and handling can be checked together.

3.6 Preserve before fixing

IT reset Joy's password at 10:05, which was right; but deleting the forwarding rule was held until Lena exported the rule list at 10:12, so the rule's details were kept. The order matters because IT's instinct is to clean up at once. Resetting the password and revoking sessions stops further access without destroying anything, so it can go first. Deleting a rule removes its name, action, target and creation details from the live mailbox, and Lena's export at 10:12 is what keeps them. Three minutes later, at 10:15, IT removes the rule and the time goes into the custody entry.

3.7 Retention awareness

Some audit logs are kept only 30 days by default. Exporting early avoids losing them. For a case reported on 3 March, records from 1 March would fall out of a 30-day window at the start of April, well before any later review or dispute. Lena checks the retention of each source as she exports it and notes it in the manifest. Proxy records follow their own retention settings, so she asks the proxy owner rather than assuming. Once exported and hashed, the copies on the evidence share follow Marlow's case retention instead of the provider's default.

Your own account

Exports are made with Lena's named admin account, never a shared one, so the provider's own audit log shows exactly who collected what. That audit entry is itself part of the custody trail.

Worked example

Custody entry: "Item 3: inbox rules export, j.okafor. Exported by L. Hart 10:12 via admin console. SHA-256 recorded in manifest. Stored: evidence share /IR-0303, read-only. Rule deleted by IT 10:15 after export."

Synthetic case. All entries are invented.

Errors and limits

Exports reflect what the provider logs; missing fields cannot be recovered later.

Exercises

EX011 — Authority check. What authorised Lena's collection, and what limited it? Rubric: 3 = policy plus Dev's approval; limited to Joy's mailbox and sign-ins; 2 = partial; 1 = none needed; 0 = none.
EX012 — Volatility. Which cloud data is collected first, and why? Rubric: 3 = short-retention audit records and sessions; lost soonest; 2 = partial; 1 = any order; 0 = none.
EX013 — Preservation list. List five items preserved. Rubric: 3 = five of sign-ins, audit, rules, trace, phishing email, proxy; 2 = three; 1 = one; 0 = none.
EX014 — Rule timing. Why was rule deletion held until after export? Rubric: 3 = keep rule details as evidence before remediation; 2 = partial; 1 = no reason; 0 = none.
EX015 — Custody entry. Name five fields in the custody entry. Rubric: 3 = item, source/account, collector, time, hash, location; 2 = three; 1 = one; 0 = none.

Synthesis

Collect within authority, most volatile first, hash and log everything, and preserve before remediating.

Continue studying — chapter 03 of 12

← Chapter 02 (draft) · Course chapter index · Chapter 04 (draft) →