Capstone A: The Evidence Lab — Hash, Image and Examine
Where you are: Capstone · C.1 · About 90 minutes (paper track) or 2–3 hours (hands-on track). This capstone applies Parts I to V of Dr. Al-Doori's IT Forensics Essentials: the four stages, hashing, hexadecimal and file signatures, storage and deleted data, FTK Imager and Autopsy.
Everything in this capstone is either yours or fictional. The hands-on track uses only your own spare USB stick with test files you created, and NIST's public, fictional "Hacking Case" training data. The paper track uses an invented evidence packet; every name, value and file in it was made up for this exercise. Only examine devices, accounts and systems you own or are explicitly authorized to work with.
What you'll be able to do
You will work through an evidence lab from acquisition to an evidence log.
- Verify the integrity of forensic images, and explain a hash mismatch correctly.
- Identify file signature mismatches, renamed files and deleted files.
- Keep a professional evidence log, and state what the evidence does not show.
Choose Your Track
- Hands-on track. You need a Windows computer you own, FTK Imager, Autopsy, a spare USB stick and enough disk space for the Hacking Case image. Do Parts H1 to H3, then read the paper track's model solution to compare your reasoning.
- Paper track. No software needed. Work through the evidence packet and Tasks 1 to 6, then compare with the model solution.
Both tracks end with the same deliverable: an evidence log, using this template.
EVIDENCE LOG
Case number: Examiner: Date (UTC):
Item ID | Description | Source | Action taken | Tool + version |
Hash algorithm + value | Result | Time (UTC) | Notes / limits
Hands-On Track
H1 — Hash behavior (15 minutes). On your own computer, create three test files. Record the SHA-256 of each (Lesson 2.1). Rename one, edit one by a single character and leave one alone, then hash all three again. Log each result, and explain each change, or lack of change, in one sentence.
H2 — Image and verify your USB stick (45 minutes). Following Lesson 2.6, put three test files on your spare USB stick and delete one. Create an E01 image with FTK Imager, with verification on. Log the source and verification hashes, the tool version and the times. Then add the image as an evidence item and find the deleted file. Log where it appears and whether it looks recoverable.
H3 — Examine the Hacking Case (60–90 minutes). Download the NIST CFReDS "Hacking Case" image, checking the size first. Create a new case in Autopsy (Lesson 5.4), add the image and run the default ingest modules. Answer NIST's first six questions:
- What is the image hash? Do the acquisition and verification hashes match?
- What operating system was used on the computer?
- When was it installed?
- What is the time zone setting?
- Who is the registered owner?
- What is the computer account name?
Two cautions for H3. First, the Hacking Case dates from 2004, so its own records may give hashes in older algorithms such as MD5 (32 hexadecimal characters) rather than SHA-256 (64). Record which algorithm each value uses and compare like with like: an MD5 value can only be checked against another MD5 value. For your own new acquisitions, as in H2, use SHA-256. Second, questions 5 and 6 ask about different things. Keep the computer's name, the user account names and the registered owner apart in your log: they are separate settings and often hold different values.
For each answer, log where you found it (the artifact and its path in Autopsy) and how confident you are. Answers with no source do not count, however likely they seem. Tip: Autopsy's results tree groups operating system details, and the registry hives of a Windows image hold the installation, time zone and owner settings (Lesson 2.5).
Paper Track: The Evidence Packet
A fictional company, Larkspur Design, suspects that confidential files left the office on a USB stick. With written authority from the company, an examiner imaged two USB sticks found in a shared office: EV-07 and EV-08. Here is what you have.
Item 1: Acquisition summaries
EV-07 · 16 GB USB flash drive · imaged 2026-05-12, 09:14–09:31 UTC
Image format: E01 · Write-blocker: hardware, tested 08:55 UTC (pass)
Source data SHA-256: 74870562e3beefad4c1f06f9a268fdcd3a26682ed26954f4582cd39fcf7f6a34
Verified image SHA-256: 74870562e3beefad4c1f06f9a268fdcd3a26682ed26954f4582cd39fcf7f6a34
Verification: MATCH
EV-08 · 8 GB USB flash drive · imaged 2026-05-12, 10:02–10:11 UTC
Image format: E01 · Write-blocker: hardware, tested 08:55 UTC (pass)
Source data SHA-256: f5a27cf0c9274fc065f240915b288c7b9c4ebb8e12f1817a509bfa61b772b345
Verified image SHA-256: f5a27cf0c9274fc065f240915b288c7b9c4ebb8e12f1817a509bfa61b772b345
Verification: MATCH
A colleague's note, added on 19 May:
Ran Get-FileHash on EV-08.E01 today:
18ca5a3c5a3029ade31802bbcef2e24c472777d921d1cf5a5486f3cb43e01a73
DOES NOT MATCH the acquisition hash! Evidence tampered with?
Item 2: File listing from the EV-07 image
Name Size (bytes) Modified (UTC) Deleted First bytes (hex)
budget_q2.xlsx 48,211 2026-05-02 16:40:12 no 50 4B 03 04
team_photo.jpg 2,301,554 2026-04-28 11:02:55 no FF D8 FF E0
notes.txt 918,402 2026-05-09 22:13:40 no FF D8 FF E1 .. .. 45 78 69 66
contract_draft.pdf 201,334 2026-05-10 08:55:01 yes 25 50 44 46
_ARRIE~1.DOC 36,864 2026-05-11 23:58:12 yes D0 CF 11 E0
File system: FAT32
Item 3: Hash-set comparison
Larkspur gave the examiner SHA-256 values of its confidential files. One file on EV-07 matched:
Confidential set entry: Q3_pricing_model.xlsx
2f7d849dda1496efa35fbdcbd8eb210377e7d02a41bc8f6c38ef1840dfecbe0e
EV-07 file with the same SHA-256: budget_q2.xlsx
No other file on EV-07 or EV-08 matched the confidential set.
Paper Track: Your Tasks
- Integrity. Is the integrity of EV-07 and EV-08 established? Respond to the colleague's note on EV-08.
- Signatures. Which files' signatures match their extensions, and which do not?
- Hash set. What does the match in Item 3 show, and what does it not show?
- Deleted files. Which files are deleted, and what does the name
_ARRIE~1.DOCtell you? - Evidence log. Write log entries for EV-07's acquisition and for your findings in Tasks 2–4.
- Limits. List at least four things this evidence does not establish.
Check Your Work
This capstone is self-assessed: nothing you produce here is submitted to or graded by the Academy. Finish your evidence log and your answers before you read the model solution. Then rate your work against each criterion in the rubric below, and only then compare it with the model solution.
Integrity
Meets the standard: Every image has a source hash and a verification hash, with the algorithm named. The EV-08 mismatch is explained as a container hash compared with a data hash, and the fix is to re-verify with the forensic tool.
Not yet: Hash values without an algorithm, or the mismatch treated as tampering or ignored.
Signatures
Meets the standard: Each file is judged by its signature, every mismatch names the file's real type, and a shared container signature such as OLE2 is reported as consistent with the extension, not as proof of it.
Not yet: Files judged by name or extension, or a container signature treated as proof of one format.
Hash set
Meets the standard: A match is reported as identical content, with no claim about who copied it or when.
Not yet: The match used to say who or when.
Deleted files
Meets the standard: Deleted entries identified, the short name explained, and recovery described as possible but still to be checked.
Not yet: Recovery assumed complete or certain.
Evidence log
Meets the standard: Every entry has item ID, description, source, action, tool and version, algorithm and hash, result, time in UTC and limits.
Not yet: Missing fields, times without a time zone, or no tool versions.
Limits
Meets the standard: At least four things the evidence does not establish.
Not yet: Conclusions that go beyond the data.
Hands-on track, also check: every H3 answer names the artifact and where you found it in Autopsy, and every hash in your log names its algorithm.
Model Solution
Compare your work with the model below. Your wording will differ; what matters is the reasoning.
Task 1 — Integrity
Both acquisitions are verified: the source data hash and the verified image hash match for each item, the write-blocker was tested the same morning and the times are recorded.
The colleague's note compares the wrong things. Get-FileHash on EV-08.E01 hashes the E01 container file, which includes the format's own metadata and compression, so it will never equal the hash of the data inside it (Lesson 2.1). A large image may also be split into several segment files (.E01, .E02 and so on), so hashing one file would not cover the whole image anyway. The correct check is to re-verify the image with the forensic tool, which recalculates the hash of the stored data and compares it with the acquisition value. If that matches, nothing has changed. The note's conclusion, "tampered with?", is unsupported and should be corrected in writing, not silently deleted.
Task 2 — Signatures
| File | Signature | Matches? |
|---|---|---|
| budget_q2.xlsx | 50 4B 03 04 (ZIP) | Yes: modern .xlsx files are ZIP containers |
| team_photo.jpg | FF D8 FF E0 (JPEG) | Yes |
| notes.txt | FF D8 FF E1 … "Exif" (JPEG with camera metadata) | No: a photo renamed as a text file. Its size of 918 KB is also unusual for a text note |
| contract_draft.pdf | 25 50 44 46 (%PDF) | Yes |
| _ARRIE~1.DOC | D0 CF 11 E0 (OLE2) | Consistent, but not proof: see below |
Two of these signatures belong to containers that several formats share. 50 4B 03 04 is ZIP, used by modern .xlsx, .docx and .pptx files; the hash match in Task 3 shows that budget_q2.xlsx is a copy of a spreadsheet. D0 CF 11 E0 marks an OLE2 compound file, the container used by legacy Word, Excel and PowerPoint files and by Outlook .msg items. It fits the .DOC extension but does not prove it: confirming a Word document needs a look inside, for example for a WordDocument stream.
Task 3 — Hash set
budget_q2.xlsx has exactly the same SHA-256 as the confidential Q3_pricing_model.xlsx, so it is an identical copy under a different name. That is a significant finding. It does not show who copied it, when it was copied to the stick (the modified time is carried over from the original and may predate the copy, as Lesson 3.6 explained), or whether it left the company.
Task 4 — Deleted files
contract_draft.pdf and _ARRIE~1.DOC are marked deleted. On FAT file systems, deleting a file overwrites the first character of its directory entry, so tools often show it as an underscore. The original name began with an unknown character followed by "ARRIE", and "~1" shows a Windows-generated short (8.3) name, so the long name was longer. Both still start with a recognizable signature, so recovery looks promising, but their content must be checked: recovered data can be incomplete (Lesson 3.5). For _ARRIE~1.DOC, the OLE2 signature fits several legacy Office formats, so only its internal structure can confirm that it is a Word document.
Task 5 — Evidence log (example entries)
EV-07 | 16 GB USB flash drive | Shared office | Imaged via tested
hardware write-blocker | [imaging tool + version] | SHA-256 7487...6a34
(source and image) | MATCH | 09:14-09:31 | -
EV-07/F-01 | budget_q2.xlsx | EV-07 image, root folder | Hash-set comparison |
[tool + version] | SHA-256 2f7d...be0e | Matches confidential
Q3_pricing_model.xlsx | 11:20 | Identical content; copier and copy time unknown
EV-07/F-02 | notes.txt | EV-07 image, root folder | Signature analysis |
[tool + version] | (record file hash) | JPEG with Exif despite .txt
extension | 11:32 | Renamed or mislabeled image; purpose unknown
Task 6 — What this evidence does not establish
- Who copied the confidential file to EV-07, or who renamed it.
- When it was copied: the modified time may come from the original file.
- That the file ever left the company or was given to anyone.
- Who owns EV-07: it was found in a shared office.
- That the renamed photo
notes.txtis relevant to the case at all. - That anyone tampered with EV-08: the mismatch came from comparing a container hash with a data hash.
Key Takeaways
- Verify integrity correctly: compare the data hash from acquisition with a re-verified data hash, not with the hash of the image container file.
- Signatures reveal renamed files; hash sets reveal identical copies under new names.
- Deleted entries on FAT show a replaced first character; recovered files need content checks.
- A good evidence log records item, source, action, tool and version, hash, result, time and limits, and every answer has a source.
Sources
- Dr. Tahseen Al-Doori — IT Forensics Essentials: Concepts, Tools, and the Practice of Digital Investigation, Chapters 2, 5 and 10
- NIST CFReDS archive — Hacking Case
- NIST — Computer Forensic Reference Data Sets (CFReDS)
- Exterro — FTK Imager
- Autopsy — Sleuth Kit Labs
- Microsoft Learn — Get-FileHash
- GCK's File Signatures Table (Gary Kessler, hosted by SEARCH)
- Library of Congress — Microsoft Compound File Binary File Format, Version 3