skip to content

Digital Forensics Fundamentals

The evidence discipline behind an intrusion investigation: capturing in order of volatility, proving a copy is the original, reading Windows artefacts, and defending what you claim from them.

on this pageshow

explore

questions

page 1 of 2

What does the hash you record when imaging a suspect disk actually prove?

level: juniorimportance: must knowfreq 78%

answer

  1. a copy claim, not a provenance claim
  2. integrity runs forward from capture
  3. equal digests mean no drift since
  4. says nothing about who wrote it
  5. authenticity comes from other artefacts

basics

~20 s

It proves the image is a bit-for-bit copy of what the drive returned at capture, and has not drifted since. It says nothing about who wrote the data, when, or what happened before you arrived.

solid answer

~50 s

The digest is computed over the bit stream read from the source device at capture, so it anchors one narrow claim: the bits I am showing you are the bits that came off that drive at that moment, unchanged since. Integrity runs *forward* from the timestamp of the first hash and cannot reach backwards. On a server where someone installed a cryptominer, the hash does not show the miner binary predates my arrival, does not identify who planted it, and does not certify the disk is otherwise untouched — the intruder's own changes are part of what I copied. Those claims come from elsewhere: filesystem timestamps, the Windows event records for the service and scheduled task that launched it, process telemetry, and corroboration between them. Confusing "the copy is faithful" with "the content is genuine" is the classic inversion.

go deeper

for a junior

Be ready to state in one sentence what an evidence image's hash proves: the copy matches what the drive returned at capture. Do not stretch that into any claim about who put the data there.

for a middle

Explain the mechanics: the digest covers the whole bit stream including unallocated space, and equality only demonstrates the absence of drift since the first digest was recorded.

for a senior

Show how you build the claims a hash cannot make — filesystem timestamps, service-creation events, execution telemetry — and how you argue from several artefacts converging rather than one.

for a principal

Own the standard your team works to: which digests get recorded, which artefacts carry their own file-level hash, and how the lab answers a challenger who suggests the responder planted what was found.

## What is actually being hashed A cryptographic hash function takes an input of any length and returns a fixed-length digest; changing a single bit of input changes the digest unrecognisably, and you cannot practically construct a different input that produces a chosen digest. During acquisition the digest is computed over the **bit stream read from the source device** — every sector the drive returned, not just the files. That includes unallocated space, slack, and any deleted-but-not-overwritten remnants of the intruder's staging directory. If the acquisition covered a physical drive rather than one volume, it also covers partition structures and anything hiding between partitions. The number is written down at the moment of capture. Later, anyone can recompute it and compare. ## The claim a matching digest supports Exactly one: *the data being examined now is bit-identical to the data read from that device at the recorded time.* This is an **integrity** claim, and it has a direction — it runs forward from the instant the first digest was computed. Everything before that instant is outside its reach. That single claim is worth a great deal. It means an examiner months later, or the other side's expert, can be handed the same image and satisfy themselves that nobody has quietly edited the copy in the interim. It moves the argument off the bits and onto interpretation, which is where the argument belongs. ## The claims it does not support, and this is what interviews probe - **Provenance.** The hash says nothing about *who* wrote the cryptominer to the file server, or from where. - **Time.** It is not a timestamp for the content. It timestamps only your act of copying. - **Retroactive integrity.** If someone modified the disk an hour before you attached it, the modification is faithfully preserved in your image and the hash verifies perfectly. A verifying hash is entirely compatible with a thoroughly tampered-with disk. - **Cleanliness.** "The hash matched" does not mean "the system was unaltered". The intruder's edits are precisely what you came to copy. - **Completeness.** Sectors the drive refused to return are not in the copy as they existed; a well-behaved acquisition process substitutes a defined fill pattern and logs the failed ranges. The digest covers what was read, including those substitutions. - **Admissibility or sound handling.** A number proves nothing about how the drive was treated before and after. ## Where the other claims come from If the finding is "a cryptominer ran on this file server for six weeks", the hash is the least of the evidence. The load-bearing artefacts are the binary's creation and modification timestamps, the registry and event-log records showing a service or scheduled task being created, execution telemetry from the endpoint agent, and network records showing sustained outbound sessions to a mining pool — remembering that a flow record proves bytes moved and never what they contained. Each of those is individually forgeable; the argument is built on several independent artefacts converging on the same story. The hash's job is only to guarantee that all of them are being read from an unmodified copy. ## Practical habits that make the hash more useful - **Hash the artefacts, not only the image.** Recording the digest of the miner binary itself lets a third party verify that one object, compare it against threat-intelligence records of the same sample, and cite it without touching the whole image. - **Record the digest at the moment of capture, not later.** A digest computed after the drive has been on an analyst's bench for a day is a baseline for a period nobody cares about. - **Say which algorithm.** Many labs record both a legacy and a modern digest. Published collision work on older algorithms concerns *crafting two files that collide*, not altering a stored copy so it matches a digest recorded earlier — but recording a modern digest removes the argument from the table entirely, which is cheaper than winning it. ## The sentence to have ready "The hash proves the copy is faithful to what the device gave me at capture. It does not prove the content is genuine, and I have never claimed it does — that comes from these other artefacts." Candidates who cannot separate those two ideas will over-claim under pressure, and over-claiming is how an otherwise sound finding gets thrown out.

  • If the hash cannot show when the cryptominer binary reached the server, what can?
    Filesystem creation and modification timestamps on the binary, the event records for the service or scheduled task that launched it, endpoint telemetry showing it executing, and network records of sustained sessions to a mining pool. Each is individually forgeable, so the argument rests on several independent artefacts agreeing on the same window rather than on one.
  • Does a matching hash prove the disk was not tampered with before acquisition?
    No, and this is the most common inversion. If someone altered the disk an hour before you attached it, your image faithfully preserves the altered state and verifies perfectly. The hash certifies your copy, not the history of the original.
  • What does hashing individual files inside the image add over hashing the whole image?
    It lets you cite one artefact by its own digest. A third party can verify that specific binary without handling the entire image, you can match it against known-sample records, and if part of the image later becomes unverifiable the artefact-level digest can still stand on its own.

It is the tamper seal applied to a box at the loading dock. An intact seal proves nothing was swapped in transit; it says nothing about what was put in the box before the seal went on.

saying these in an interview costs you the question

  • Says the hash proves the file was never tampered with
  • Claims a matching digest authenticates who created the data
  • Treats the hash as a timestamp for the content
  • Confuses a faithful copy with genuine content
  • Assumes a verifying image means the host was clean

context

open as a page

What can a live capture of a running host give you that an offline disk image cannot?

level: juniorimportance: must knowfreq 68%

basics

~20 s

Only a running host still holds decryption keys, decrypted mounted volumes, running processes and network state in memory. Power it off and an image of the same disk is ciphertext, or silent, for all of it.

open as a page

What is a forensic triage artefact set, and how does it differ from a full disk image?

level: juniorimportance: must knowfreq 70%

basics

~20 s

A triage artefact set copies a chosen list of high-value host artefacts - event logs, execution and persistence records, scheduled tasks - instead of every sector of the disk. Minutes and megabytes per host rather than hours and terabytes, so it scales to hundreds of machines.

open as a page

What does the order of volatility rank on a compromised host, and why does it set capture order?

level: juniorimportance: must knowfreq 74%

basics

~20 s

It ranks evidence by how fast it disappears, not by how useful it is. CPU registers and cache decay first, then RAM, then network state such as socket and ARP tables, then disk, then archived logs. Collect shortest-lived first.

open as a page

You collect a backdoored vendor installer from an infected host — what must each chain-of-custody entry record?

level: juniorimportance: must knowfreq 66%

basics

~20 s

Each entry names the item by a unique identifier, the date and time of the move, who released it, who received it, why it moved and where it went, signed by both parties. The point is that the item is never unaccounted for.

open as a page

A SaaS product's audit log shows a customer record was viewed — what does that row prove?

level: juniorimportance: must knowfreq 68%

basics

~20 s

It proves the application returned that record to a session authenticated as that account. It does not prove a human read it, which human held the credential, or that the data was copied or kept.

open as a page

In NTFS, what does a file whose $STANDARD_INFORMATION times predate its $FILE_NAME times suggest?

level: juniorimportance: must knowfreq 62%

basics

~20 s

Backdating. $STANDARD_INFORMATION times are settable through a documented Windows API; $FILE_NAME times are written by the NTFS driver on create, rename and move. $SI older than $FN points to timestomping, though a legitimate rename or restore can also diverge.

open as a page

On NTFS, what actually happens to a deleted file's data, and why can an examiner sometimes recover it?

level: juniorimportance: must knowfreq 66%

basics

~20 s

Deleting on NTFS only rewrites bookkeeping. The MFT record is flagged not-in-use, the directory index entry is removed, and the file's clusters are marked free in the volume bitmap. The bytes themselves stay on disk until something reuses those clusters.

open as a page

Does a Shimcache entry for a binary prove that the binary executed on that host?

level: juniorimportance: must knowfreq 72%

basics

~20 s

No. A Shimcache (AppCompatCache) entry records that Windows' application-compatibility engine saw that file at that path with that last-modified time. Windows 8 and later store no execution flag at all, so an entry is evidence of existence, not of a run.

open as a page

What evidence exists only in a Windows memory image and never in a disk image?

level: juniorimportance: must knowfreq 70%

basics

~20 s

Only RAM holds running state: code that never touched disk, full process command lines, live network endpoints with their owning process id, decrypted data, and credential material such as hashes, Kerberos tickets and session keys held by lsass.

open as a page

In NTFS forensics, what do the M, A, C and B timestamps each record?

level: juniorimportance: must knowfreq 72%

basics

~20 s

M is when the file's data was last written, A when it was last read, C when its MFT record's metadata last changed, and B (birth) when the file first appeared on that volume. C is not the creation time.

open as a page

Why use a write blocker when hashing an evidence disk would reveal any change anyway?

level: middleimportance: must knowfreq 66%

basics

~20 s

Hashing detects change only against an earlier trusted digest, and the acquisition hash is the first one there is. A write blocker is preventive: it keeps the source untouched so that first digest describes the disk as the intruder left it.

open as a page

Which artefacts prove that a Run key, service or scheduled task you found actually executed?

level: middleimportance: must knowfreq 60%

basics

~20 s

A persistence entry is configuration — an instruction to run later — so it proves nothing ran. Execution proof comes from a separate artefact: a Task Scheduler action-start record, a service state-change record, a Prefetch file for the payload, or a process-creation event.

open as a page

An intruder is logged in on an unlocked, encrypted laptop with a container mounted, and a non-forensic technician is standing at it - what do you tell them?

level: seniorimportance: must knowfreq 45%

basics

~20 s

Change nothing about power or session state: no lid, no lock, no logoff, no reboot. The mounted container's plaintext exists only while the machine stays as it is, so capture from external media first and log every step.

open as a page

How do you show from a memory image that code was injected into a signed running process?

level: seniorimportance: must knowfreq 58%

basics

~10 s

Read the address space, not the process list. Look for private committed regions marked executable with no file backing them, a PE header in anonymous memory, and threads starting outside every loaded module.

open as a page

How do you build one UTC timeline from NTFS MACB times, a local-time app log and UTC proxy records?

level: seniorimportance: must knowfreq 56%

basics

~20 s

Convert every source to UTC, establishing each source's offset rather than assuming one. Keep every row's original value, source and applied offset, and derive those offsets from an anchor event two independent sources both captured.

open as a page

Why does forensic analysis run on a verified duplicate instead of the original disk?

level: middleimportance: should knowfreq 45%

basics

~20 s

Analysis writes: tools mount, index, carve and cache. The original is sealed so it can be re-read later, and work runs on a copy whose digest you matched to the acquisition digest. Verified is an act, not a label.

open as a page

What footprint does running a live collection tool leave on the host you are collecting from?

level: middleimportance: should knowfreq 48%

basics

~20 s

It leaves execution artefacts and consumes memory: a process-creation record, a Prefetch entry, a service installation, removable-media device records, loaded modules, and allocated pages that overwrite free memory. The goal is never a zero footprint, only a documented one.

open as a page

When would you pull the power on a compromised host instead of shutting it down cleanly?

level: middleimportance: should knowfreq 55%

basics

~20 s

When you believe the host is still under an intruder's control. A clean shutdown runs shutdown handlers and cleanup tasks - an execution opportunity for destructive code. A hard power cut freezes the stored state, at the cost of an unclean filesystem.

open as a page

Why does an incident-response team agree its triage collection profile before any case exists?

level: middleimportance: should knowfreq 55%

basics

~20 s

Because at 03:00 there is no time to design one. A standing profile has already been sized, tested against the estate and cleared with legal and privacy, so it can be pushed to hundreds of hosts immediately and every host returns a comparable set.

open as a page

What can a live host's socket table prove that a disk image of the same host never can?

level: middleimportance: should knowfreq 56%

basics

~20 s

It proves which peer address a running process was connected to at the moment of capture, and in which direction the connection opened. A disk image never holds the kernel's connection table, which dies with the kernel.

open as a page

What belongs in examiner notes so a second examiner could reproduce your work on a backdoored installer?

level: middleimportance: should knowfreq 44%

basics

~20 s

Notes must name which copy you worked on, the tool and version, the exact steps and search terms, the time of each step, and every result including the ones that found nothing. Write them as you go, and keep observations separate from conclusions.

open as a page

A support account viewed 11,000 customer records in one afternoon — which innocent explanations must you eliminate?

level: middleimportance: should knowfreq 57%

basics

~10 s

List the benign hypotheses first — a shared credential, an automation using the account's token, a mis-scoped report, a UI that prefetches every result — then find the observation that rules each one out.

open as a page

A disk image shows gigabytes of zero-filled unallocated space. What can you actually conclude?

level: middleimportance: should knowfreq 45%

basics

~20 s

Only that nothing is recoverable from those clusters. Free space carries no timestamps and no ownership, so it cannot say when it was overwritten, by whom, or whether anything was there. Restores and fresh virtual disks look identical.

open as a page

What does a file carved from unallocated space lack that a file recovered through its MFT record keeps?

level: middleimportance: should knowfreq 54%

basics

~20 s

A carved file is content with no context: no filename, no path, no owner, no filesystem timestamps. An intact MFT record keeps all of those bound to the data, so you can say where the file lived and when.

open as a page

What does an NTFS $UsnJrnl entry recording a file's deletion prove, and what can it never show?

level: middleimportance: should knowfreq 47%

basics

~20 s

A $UsnJrnl entry proves a file with that name, under that parent directory, was created, written to or deleted at that time. It carries no content, no size, and no identity of whoever did it.

open as a page

Why might a Windows host hold no Prefetch file for a program you know executed?

level: middleimportance: should knowfreq 45%

basics

~20 s

Prefetch is not universal. It is off by default on Windows Server, can be switched off by the EnablePrefetcher setting, has a fixed capacity that evicts old entries, and names files by executable name plus a path hash.

open as a page

Why can two process lists built from one memory image disagree about which processes existed?

level: middleimportance: should knowfreq 48%

basics

~20 s

One list walks the kernel's doubly-linked list of process structures; the other scans physical memory for those structures directly. Scanning also finds processes unlinked from the list and remnants of processes that already exited, so it usually returns more.

open as a page

showing 1–30 of 47