IT International Academy
🔍 Empowering Future Tech Professionals
Reading the Evidence Machines Leave Behind
Sit down for a moment before we touch a single tool. I want you to picture something first.
Somewhere, right now, a company just discovered its network was breached three weeks ago. A phone sits in an evidence bag, its owner accused of something they say they didn't do. A hard drive was "wiped clean" by someone who was certain that meant the data was gone forever. In every one of these situations, there is one kind of professional the room is waiting for: someone who can read what the machine actually remembers, and prove it.
That is what this module begins to teach you. Not theory for its own sake — a working skill you will use the very first week you start practicing it, on your own phone, for free.
Every action taken on a computer, a phone, or a network leaves a mark somewhere — a timestamp, a log entry, a fragment of deleted data sitting quietly in a corner of the disk nobody thought to check. Most people never think about this. Digital forensics is the discipline built entirely around noticing it, preserving it correctly, and turning it into proof a court, an employer, or an investigator can trust.
It sits at a rare intersection of three worlds: the technical precision of computer science, the procedural discipline of law, and the pattern-reading instinct of a detective. You don't need to be an expert in all three coming in. You need curiosity, patience, and a willingness to document everything you do — the rest is what this module is here to build.
This module assumes no prior background in digital forensics, law, or investigative work. If you're a first-year cybersecurity student who has never opened a terminal for anything more serious than a school assignment, you are exactly who this was written for.
What you do need is a smartphone with Chrome, a willingness to type real commands rather than just read about them, and enough discipline to actually complete each practical exercise instead of skimming past it. Everything else — the vocabulary, the tools, the mindset — is built from zero, one unit at a time.
Every unit in this module follows the exact same rhythm, deliberately, so you always know what to expect:
This structure is intentional: 80% of your time in this module should be spent doing, not reading. Reading builds vocabulary. Doing builds skill. Only one of those gets you hired.
Here is everything ahead of you in this module, in order:
Real digital forensics investigators use tools like FTK Imager, Autopsy, Volatility, and Wireshark. All four are free. All four are industry-standard — the same software used by law enforcement, corporate security teams, and independent examiners around the world.
Where this module differs from a traditional classroom is simple: you are going to practice the underlying logic of every one of these tools using nothing but your phone's browser and Google Cloud Shell — a full, free Linux terminal that runs entirely online. Every hashing command, every imaging command, every network command you'll run in this module works exactly the same way it would on a $2,000 forensic workstation. The tool is free. The terminal is free. The only thing this course asks you to invest is your attention.
Three habits will decide whether this module actually sticks with you, or fades in a week:
Everything in this module is taught for one purpose: to prepare you to investigate honestly, lawfully, and defensibly. The same skills that recover a deleted file or capture a memory dump can be misused if applied without authorization. Every exercise in this module works only on data you created yourself, on systems you have every right to access. As you move further into this field — and especially in Module 2 and beyond — that boundary of lawful authorization is not a technicality. It is the single thing that separates an investigator from an intruder.
By the time you close Unit 1.7, you will have personally hashed evidence, built a chain of custody log, imaged and verified a file, recovered a deleted file conceptually through Autopsy, reasoned through a live-memory incident, read a real network exchange, and written a short forensic report — all from a smartphone, all using free tools, all without ever setting foot in a physical lab.
That is not a theoretical understanding of digital forensics. That is the actual starting toolkit of a working investigator. Let's begin.
Let me start the way I start every first lecture of this course: with a question. If I handed you a laptop that belonged to someone accused of fraud, and told you to "find the proof," what would you actually do?
Most people's instinct is to open the laptop, click around, look at recent files, maybe check the browser history. That instinct, understandable as it is, would destroy your case before it even started. Why? Because the moment you touch a live system carelessly, you change timestamps, overwrite memory, and give a defense lawyer every reason to say "how do we know you didn't plant that evidence?"
This is the gap that digital forensics exists to close. It is not simply "IT skills applied to crime." It is a discipline built entirely around one demand: prove that what you found is real, and prove it in a way a court will accept.
Let's define our vocabulary before we go further — precision of language matters here the way it matters in a courtroom.
Digital Forensics is the scientific process of identifying, preserving, analyzing, and presenting digital evidence in a way that is legally admissible. Notice the word scientific. In science, a result only counts if someone else can repeat your method and get the same answer. That is exactly the standard digital forensics holds itself to — every action must be documented well enough that another examiner, using your notes alone, could redo your work and reach the same conclusion.
Evidence is any piece of data — a file, a deleted email, a log entry, a snapshot of memory — that can prove or disprove a fact in an investigation.
Chain of Custody is the unbroken, documented record of everyone who touched a piece of evidence, when, and what they did with it. We will spend an entire unit on this next, because breaking it is the single most common reason strong evidence gets thrown out of court.
A Hash Value is a unique digital fingerprint generated from a file's exact contents, typically using an algorithm called SHA-256. Change even a single character inside that file, and the entire hash changes, unrecognizably. This is how an investigator proves, mathematically, that a file was never altered.
A Forensic Image is an exact, bit-for-bit copy of a storage device — not just the visible files, but every sector, including ones marked "empty." Investigators never work on the original device; they always work on a verified image of it.
A Write Blocker is hardware or software that lets you read a device with zero possibility of accidentally writing to it, guaranteeing the original stays untouched.
Now that you have the vocabulary, here is the bigger picture. Every crime, every breach, every workplace dispute today leaves a digital trace somewhere — a browser history, a router log, a phone's location cache, a deleted photo that isn't actually gone. Digital forensics is the discipline that turns that trace into proof.
It sits at the intersection of computer science, criminal law, and detective work — you need all three instincts at once. The field breaks into four main branches, and this module gives you one unit on each:
As a cybersecurity student, this is the skill that turns "we got hacked" into "here is exactly how, when, and by whom, and here is proof strong enough to hold up in court."
Picture a mid-size company that notices money missing from an account only it and one employee could access. The employee denies everything. Investigators image the employee's work laptop, and inside a folder that had been emptied weeks earlier, they recover spreadsheets showing the exact transfers, along with browser history showing searches for "how to permanently delete files." The employee's own attempt to hide the evidence is what makes the case airtight — because the recovered files were hashed, logged, and imaged following the exact process you are about to learn in this module.
Notice what actually won the case: not a clever hack, not guesswork — a disciplined, repeatable process that any other examiner could have followed and reached the same conclusion. That is the entire game in this field.
"Digital forensics is basically hacking." Not quite. Hacking is about finding a way in. Forensics is about proving, after the fact, exactly what happened — often the opposite skill set, focused on documentation and restraint rather than exploitation.
"If I can't see the file anymore, it's gone." You already know from this unit that this is usually false. Visibility and existence are two different things on a disk.
"You need expensive lab equipment to start." You need a write blocker and specialized hardware for real casework eventually — but the reasoning, the commands, and the mindset can all be practiced today, on a phone, for free.
"Formatting a drive destroys everything." A quick format mostly clears the file system's index, very similar to deletion. A full, multi-pass wipe is a different story — but most people never actually do that.
Watch This Before Your First Practical
This short lecture introduces the field from the ground up and pairs well with everything above. Watch it fully before attempting the exercise below.
DFS101: Introduction to Digital Forensics
Practical Exercise 1 — Hash Your First Piece of "Evidence"
You don't need a laptop or any special hardware for this. Open Google Cloud Shell in Chrome on your phone (console.cloud.google.com → tap the Cloud Shell icon at the top right), and follow along step by step:
echo "Case File 001 - Original Statement" > evidence.txt sha256sum evidence.txtWrite down that hash value somewhere — it is your file's unique fingerprint. Now make a tiny, almost invisible change to the file:
echo " " >> evidence.txt sha256sum evidence.txtCompare the two hash values carefully. They will look completely different, even though your change was one invisible space character. In your own words, write 2–3 sentences explaining what just happened, and why this matters in a real investigation where evidence must never be altered after it is collected.
Practical Exercise 2 — Two Files, Same Content, Different Names
Now let's test whether a hash cares about a file's name, or only its contents:
echo "Identical content" > file_a.txt echo "Identical content" > file_b.txt sha256sum file_a.txt file_b.txtLook closely at the two hash values. Are they the same or different? Write one sentence explaining what this tells you about what a hash actually measures — and why an investigator can use hashing to prove two files found in different locations are, in fact, the exact same piece of evidence.
💡 Remember: You don't need expensive forensic hardware to start learning this field. A phone, a browser, and Google Cloud Shell give you a real Linux terminal to practice on — the exact same command family professionals use every day. Your device is not your limitation — your discipline is.
Before we walk through the process, let's define the terms that make it up.
Chain of Custody Document — a physical or digital form that logs every person who has handled a piece of evidence, the exact time they handled it, and what action they took.
Preservation — the act of protecting evidence from being altered, damaged, or destroyed, starting the moment it is discovered.
Acquisition — the step where an investigator makes a verified forensic copy of the original evidence, so the original itself is never touched again.
Analysis — examining the acquired copy carefully to extract meaningful, factual findings.
Presentation — reporting those findings clearly enough that a judge, jury, or a manager with zero technical background can understand and trust them.
Evidence Tag / Evidence ID — a unique label attached to every item the moment it is seized, so it can never be confused with another item in the same case, or another case entirely.
Custodian — whoever currently holds legal and physical responsibility for a piece of evidence at any given moment. There is always exactly one custodian, never zero, never two.
Here is something I want you to remember for the rest of your career: the technical finding is rarely what gets a case thrown out — sloppy documentation is. A defense lawyer's very first move, almost every single time, is to ask: "can you prove nobody tampered with this evidence between the moment it was seized and the moment it was presented here today?" If your paper trail has even one gap, the honest answer becomes no — and the evidence can be dismissed, no matter how strong or damning it is.
Every real investigation — whether it's a stolen company laptop or a nation-state breach — follows the same five-stage process:
Miss a step anywhere in that sequence, or fail to log it properly, and the chain breaks — permanently. There is no "fixing it later." Once a gap exists in the documentation, it exists forever.
A proper log is more detailed than most beginners expect. At minimum, every entry needs:
Notice the pattern: every single field exists to answer one question in advance — "who could have tampered with this, and when?" A complete log makes the answer, provably, "no one."
1. The gap in time. Evidence sits somewhere for two hours with no logged custodian. Even if nothing happened, you cannot prove that — and "we're pretty sure" is not admissible.
2. The missing signature. A transfer happens, but the receiving examiner forgets to sign and date the log. On paper, the evidence appears to have vanished and reappeared.
3. The mismatched hash. A verification hash doesn't match the previous one on record. This doesn't always mean tampering — sometimes it's a labeling error — but it must be investigated and documented immediately, never quietly ignored.
Watch: Understanding Chain of Custody
This short video walks through exactly why chain of custody is treated as a legal requirement, not a formality, using real examples of cases that fell apart because of documentation gaps.
Understanding Chain of Custody in Digital Forensics
Practical Exercise 1 — Build a Chain of Custody Log
Using Google Docs or Sheets on your phone, create a simple chain of custody log with these columns:
Now repeat the hashing exercise from Unit 1.1 on a brand-new file, and log it in your custody form exactly as if it were real case evidence you had just seized. Fill in every column — this discipline is the entire point of the exercise.
Practical Exercise 2 — Simulate a Multi-Party Transfer
Real evidence rarely stays with one person. Simulate a three-step transfer of your evidence file from Exercise 1:
Re-hash the file at each stage and confirm the value hasn't changed. Then write 2–3 sentences: if "Examiner B" had failed to log the handoff, what specific argument could a defense lawyer make in court?
💡 Remember: In real investigations, technical brilliance rarely saves a case with broken paperwork. Discipline in documentation is a forensic skill in its own right, not a side task.
New unit, new vocabulary — let's lock these in first.
Disk Imaging is the process of creating an exact, bit-for-bit copy of a storage device — every sector, including deleted and "empty" space, not just the files a user can see.
Write Blocker is hardware or software that guarantees you can read a device without any possibility of writing to it, so the original stays completely untouched during examination.
FTK Imager is a free forensic tool used to create disk images and generate their hash values, with a simple graphical interface.
dd is a Linux command-line tool that can also create raw disk images, byte for byte — the terminal-based cousin of FTK Imager.
Physical Acquisition — imaging an entire physical device, sector by sector, capturing everything: visible files, deleted files, unallocated space, and hidden partitions.
Logical Acquisition — copying only the files and folders visible under the active file system. Faster, but leaves deleted data and hidden artifacts behind.
Here is the single rule that governs this entire unit, and honestly, most of your career if you go into this field: you never analyze the original evidence directly. You image it first, verify the image matches the original using hash values, and only then do you work — on the image, never the source.
Think about why this matters. If your analysis software crashes, or you make a mistake halfway through, or a file gets accidentally modified — none of that matters, because you can simply re-image from the untouched original. But if you had worked directly on the original device, one mistake could destroy the only copy of the evidence that will ever exist.
The standard acquisition workflow looks like this, every single time, without exception:
A physical acquisition captures the entire drive — every sector, whether it contains a visible file, a deleted file, or nothing the operating system currently recognizes. This is the gold standard for serious investigations, because it captures everything a later analysis might need, including data the suspect believed was gone.
A logical acquisition only grabs what the active file system shows — the files and folders a normal user would see. It's much faster and sometimes appropriate for quick triage, but it will completely miss deleted files, slack space, and hidden partitions. As a rule for this course: when in doubt, go physical. You can always extract a logical view from a physical image later, but you can never go the other way around.
Raw / DD — an exact byte-for-byte copy with no extra structure. Universally compatible with almost every forensic tool, but offers no built-in compression or metadata.
E01 (EnCase Evidence Format) — the most widely used professional format. Supports compression and stores case metadata (examiner name, case number, hash values) directly inside the image file.
AFF (Advanced Forensic Format) — an open-source alternative to E01, less common today but still seen in some toolchains.
For this course, we'll work primarily with raw/dd images, since they're the simplest to create and verify from a command line — but you should recognize all three names when you see them in the field.
Watch: Creating a Drive Image with FTK Imager
This demonstrates the graphical workflow professionals use day to day. Pay close attention to the hash verification step at the end — that's the part students most often forget.
How to Create a Drive Image Using FTK Imager
Practical Exercise 1 — Image and Verify a File
We'll simulate the imaging workflow using Cloud Shell, since true disk imaging requires physical hardware you don't have yet — but the logic is identical.
dd if=evidence.txt of=evidence.img bs=1MThis creates a raw copy, exactly like imaging a full disk would — just at a much smaller scale. Now hash both files to compare them:
sha256sum evidence.txt evidence.imgIf the two hashes match exactly, you've just proven your "image" is a perfect, unaltered copy — this is precisely what a real investigator does with FTK Imager on a 500GB hard drive, just scaled up enormously.
Practical Exercise 2 — Double-Verify with Two Hash Algorithms
Professional reports often include more than one hash algorithm, since it makes a coincidental collision astronomically less likely. Run both against your image file:
md5sum evidence.img sha256sum evidence.imgRecord both values as if writing them into a real acquisition report. Then explain in one or two sentences: why would an investigator bother recording two different hash values for the same file instead of just one?
💡 Remember: The moment you skip verifying a hash after imaging, everything you find afterward becomes questionable in court. Verify first, analyze second — always, no exceptions.
New unit — new vocabulary, as always.
File System is the structure an operating system uses to organize and keep track of files on a storage device — examples include NTFS on Windows, ext4 on Linux, and APFS on iPhone.
Deleted File — when you "delete" a file, the operating system usually only removes the pointer to it from its index. The actual data itself stays sitting on the disk, untouched, until something else happens to overwrite that exact spot.
Unallocated Space is disk space the file system marks as free and reusable — even though old data may still physically be sitting there, fully recoverable.
Slack Space is the small leftover gap at the end of a file's last storage block. Files rarely fill a block exactly, and whatever data used to occupy that leftover space before can sometimes still be recovered.
MAC Times — Modified, Accessed, and Created timestamps attached to every file. Comparing these three times often reveals exactly what a user did, and when.
Autopsy is free, open-source forensic software used to browse disk images, recover deleted files, and build timelines of user activity.
This is the single most important idea in this entire unit, so read it twice: deleting a file almost never destroys it.
Picture a disk like a library's card catalogue. Every book has a card telling you exactly where on the shelf to find it. When you "delete" a book, the librarian doesn't burn it — they just pull its card out of the catalogue and mark that shelf spot as "available." The book itself stays exactly where it was, until someone else requests a book and happens to get assigned that same spot. A forensic investigator's job, in this analogy, is to walk the shelves directly and ignore the missing cards entirely.
Autopsy does exactly this through a process called file carving — it scans unallocated space for recognizable file signatures (the unique byte patterns that mark the start of a JPEG, a Word document, a PDF, and so on) and rebuilds files the file system itself has already forgotten about.
This is precisely why criminals who think hitting "delete" protects them are, more often than not, dead wrong — and why understanding this gap is genuinely one of the most valuable skills you can bring into a security role.
NTFS (Windows) — keeps a master index called the Master File Table (MFT), which records the location, size, and timestamps of every file. When a file is deleted, its MFT entry is usually just marked as free — the data itself often survives untouched.
ext4 (Linux) — uses a similar concept called inodes to track file metadata separately from the actual file content, and behaves similarly around deletion.
APFS (iPhone / macOS) — a newer file system that uses "snapshots," which can sometimes preserve earlier states of the file system even after changes, making certain recoveries easier than on older systems.
You don't need to memorize the internal structure of each — what matters is the shared pattern: every file system separates "where the data physically lives" from "whether anything currently points to it." That gap is where recovery lives.
Every file carries three timestamps that, read together, tell a story: when it was Modified (content last changed), Accessed (last opened or read), and Created (first written to this location).
A file created and modified at the same second, but accessed hours later, suggests it sat untouched until someone opened it. A file modified moments before a device was wiped often points directly at intent. Reading MAC times is rarely about any single timestamp — it's about the relationship between all three, compared across multiple files, that builds a timeline of what a user actually did.
Watch: Recovering Deleted Files with Autopsy
Watch how a real deleted file is located and restored inside Autopsy's interface — notice how the "Deleted Files" category in the sidebar makes this almost effortless once you know where to look.
How to Find and Recover Deleted Files using Autopsy
Practical Exercise 1 — Recover a "Deleted" File
Using Cloud Shell, create and then delete a file:
echo "Confidential note" > secret.txt rm secret.txtAs far as the file system is concerned, that file is now gone. In a full lab session, you would load a disk image containing a deletion exactly like this into Autopsy, and use its file recovery module to bring the file back — proving to yourself, hands-on, that "delete" rarely means gone.
Practical Exercise 2 — Read a File's Timestamps
Create a file, wait a moment, then modify it, and inspect its metadata:
echo "Draft version" > report.txt sleep 5 echo "Final version" >> report.txt stat report.txtLook at the Modify, Access, and Change fields in the output. Write 2–3 sentences explaining what story these timestamps would tell an investigator who found only this file, with no other context.
💡 Remember: Criminals who think deleting evidence protects them are almost always wrong. Understanding this gap is exactly what makes you valuable as an investigator.
Let's define this unit's vocabulary before anything else.
RAM (Random Access Memory) is the computer's short-term, working memory. It holds everything the system is actively doing right now — and it empties completely the instant power is cut.
Memory Dump is a saved snapshot of everything that was sitting in RAM at one specific moment in time.
Volatility is the leading free, open-source framework for analyzing memory dumps — used to extract running processes, active network connections, and even encryption keys.
Volatile Evidence is any evidence that disappears once a device loses power. RAM is, by far, the most important example of this.
Order of Volatility — a ranked list, from most fragile to least fragile, of what evidence to capture first during a live investigation: CPU registers and cache, then RAM, then network state, then running processes, and only afterward disk data, which is comparatively stable.
Live Forensics — examining a system while it is still running, as opposed to "dead" forensics performed on a powered-off image.
Here's why this unit matters more than most students expect walking in: some of the most damaging evidence in modern cases never touches the hard drive at all. Malware that runs entirely inside memory, a password typed into a login form seconds before capture, a chat message before it was encrypted — all of it can live only in RAM and nowhere else. If an investigator pulls the plug before capturing memory, that evidence is gone permanently. There is no second chance.
This is exactly why the very first instinct you learned in disk forensics — "preserve, don't touch anything" — actually reverses here. With a live, running system suspected of compromise, the correct order of operations is: capture memory first, power down second. Get that order backwards, and you lose evidence that can never be recovered by any other means.
From a single memory dump, Volatility can extract:
Not all evidence disappears at the same speed. Forensic responders follow a ranked order, from most fragile to least, so nothing irreplaceable is lost while collecting something that would have survived anyway:
This ordering is why memory forensics gets its own unit, separate from disk forensics — the two operate on completely different clocks.
Dead forensics — the approach from Units 1.3 and 1.4 — examines a powered-off, imaged system. Nothing changes while you work, which is exactly why it's the safer default whenever it's an option.
Live forensics examines a system while it's still running, which is riskier — every command you type on a live system potentially changes something — but it's the only way to capture volatile evidence at all. This is why live forensics demands extreme discipline: use trusted, verified tools, document every single command you run, and capture memory before doing anything else.
Watch: Introduction to the Volatility Framework
This walks through installing Volatility and running your first commands against a memory dump — pslist, netscan, and a few others you'll recognize from the notes above.
Introduction to Volatility Framework: Memory Forensics Made Easy
Practical Exercise 1 — Think Like a First Responder
No memory dump needed for this one — this is a decision-making drill, and it's one of the most important habits you'll build in this unit.
Scenario: you arrive at a workstation that's still logged in and appears to be running unfamiliar software quietly in the background. Your manager tells you to "shut it down immediately to stop the damage." What do you do, and why? Write your answer referencing what you now know about volatile evidence and the order of volatility.
Practical Exercise 2 — List Live Processes Yourself
You can practice the underlying logic of Volatility's process listing right now, on a live system, using Cloud Shell:
ps auxThis lists every process currently running on that machine, similar in spirit to Volatility's pslist command against a memory dump. Pick two unfamiliar-looking processes from the output and write one sentence each guessing what they might do, based on their name — this is exactly the instinct an investigator uses when scanning a real process list for something suspicious.
💡 Remember: The instinct to "turn it off and unplug it" is usually wrong in an active incident. Capture memory before you kill power — you only get one shot at volatile evidence.
Vocabulary first, as always.
Packet is the basic unit of data sent across a network. Every email, web page, and file transfer gets broken into many small packets before it ever leaves your device.
Packet Capture (PCAP) is a saved file containing raw network traffic, captured exactly as it crossed a specific point on a network.
Wireshark is the industry-standard free tool for capturing and analyzing network traffic, packet by packet, in enormous detail.
IP Address is the numeric address that identifies a device on a network — similar, conceptually, to a postal address for data.
Port is a numbered "door" on a device that specific types of traffic use — for example, web traffic typically uses port 443, and email uses others entirely. An IP address gets data to the right building; a port gets it to the right room.
Command-and-Control (C2) Traffic is network communication between a compromised device and an attacker's remote server, used to send stolen data out or receive new instructions.
Disk and memory forensics tell you what happened on a machine. Network forensics tells you what happened between machines — which is very often exactly how an attacker got in, or exactly where stolen data ended up afterward.
When you open a PCAP file in Wireshark, you can see, packet by packet:
A single suspicious connection to an unfamiliar IP address, repeating at the exact same interval every few minutes, is very often the first fingerprint of a compromised machine quietly "phoning home" to an attacker. Learning to spot that pattern is one of the most practically useful skills in this entire module.
Every network connection is really described by four pieces of information at once: the sending IP and port, and the receiving IP and port. Investigators call this a socket pair. Knowing just an IP address tells you which machine was involved; knowing the port as well tells you what kind of conversation it was likely having — a web request, an email transfer, a remote login attempt, and so on.
Some ports show up constantly in investigations, and it's worth recognizing them on sight:
Beaconing — a device contacting the same external address at suspiciously regular intervals, often a sign of malware checking in with its controller.
Unusual data volume — a workstation suddenly sending far more data out than it normally receives, which can indicate information being stolen.
Traffic to unfamiliar countries or providers — not proof of anything on its own, but a reasonable trigger for closer inspection when combined with other signals.
None of these signs prove compromise by themselves — context and corroboration always matter — but recognizing the shape of suspicious traffic is exactly the instinct this unit is building.
Watch: Learn Wireshark in 10 Minutes
A fast, beginner-friendly walkthrough of the Wireshark interface — filters, packet lists, and how to read a basic conversation between two devices.
Learn Wireshark in 10 Minutes - Wireshark Tutorial for Beginners
Practical Exercise 1 — Read a Network Conversation
Since Wireshark itself needs a graphical desktop, we'll start with the underlying logic using Cloud Shell's built-in network tool:
curl -v https://example.comRead through the verbose output carefully. Identify: which IP address your request connected to, what port was used, and what response came back. This is exactly the same question-and-answer structure Wireshark shows visually for every packet on a network — here, you're just reading it in text form first, before you ever open the graphical tool.
Practical Exercise 2 — Resolve a Domain to an IP Address
Every connection to a website actually starts with a DNS lookup, converting a name into an address. Try it yourself:
nslookup example.comNote the IP address returned. Then imagine a scenario where a compromised device performs this exact same lookup, but for a domain nobody in the company recognizes, every five minutes, all day long. Write 2–3 sentences explaining why this pattern alone would justify a closer investigation.
💡 Remember: Attackers can hide files and even wipe logs, but the network conversation itself is much harder to erase after the fact. Traffic doesn't lie about where it went.
Final set of vocabulary for this module.
Forensic Report is the final written document presenting an investigator's findings clearly enough for a non-technical reader — a judge, a manager, a jury — to understand and trust without needing any background in technology.
Finding is a specific, evidence-backed fact discovered during analysis — for example, "the file was created at 14:02 and its hash matches the original image exactly."
Methodology Section is the part of a report explaining precisely which tools and steps were used, in enough detail that another investigator could repeat the work and land on the same result.
Expert Witness — a qualified investigator called to testify in court, explaining findings to a judge or jury and defending the methodology under cross-examination.
Chain of Reasoning — the logical path from raw evidence to a stated conclusion, with no unstated assumptions or leaps a skeptical reader couldn't follow.
Here is a truth every experienced investigator learns eventually: all the technical skill in the world means nothing if you can't explain what you found. A brilliant discovery, written in jargon a judge cannot follow, is functionally useless in court — it might as well not exist. Every professional forensic report follows roughly the same five-part structure:
Notice what's deliberately missing from that list: guesswork. A good forensic report never says "the suspect probably did X." Instead, it says "the evidence shows X occurred at this time, on this device, verified by this hash." That distinction — fact versus opinion — is exactly what makes a report defensible under cross-examination.
Overreaching language. "This proves the suspect is guilty" claims more than the evidence supports. "This is consistent with X, and inconsistent with Y" is more defensible and, honestly, more accurate.
Unexplained jargon. Terms like "MFT," "slack space," or "pslist" mean nothing to a judge unless you define them the first time you use them, in plain language.
Passive, vague phrasing. "It was found that..." hides who found it and how. "I examined the image using Autopsy version X and found..." is specific, attributable, and repeatable.
Missing timestamps. Every finding needs an exact date and time attached — "recently" or "shortly after" invites doubt that a specific timestamp closes off entirely.
If a case goes to trial, the investigator who wrote the report is often the one who has to defend it out loud, under cross-examination, in front of a judge or jury. This is where sloppy shortcuts from earlier in the process resurface publicly — a skipped hash check, an undocumented gap in custody, a guess dressed up as a finding. Everything you documented carefully in Units 1.1 through 1.6 exists precisely to make this moment survivable. An investigator who can calmly say "here is my log, here is my hash, here is exactly what I did and why" rarely loses credibility on the stand — not because they're clever in the moment, but because they did the work correctly, months earlier, without cutting corners.
Watch: Report Writing and Presentation
This closing lecture ties together everything from the module — how a formal digital forensics report should actually be structured and worded before it ever reaches a courtroom or a client.
Digital Forensics: Report Writing and Presentation
Capstone Mini-Investigation
Using everything from Units 1.1–1.6, complete this end-to-end mini-case on your phone:
Before considering your capstone complete, confirm each of these honestly:
💡 Remember: A forensic investigator's real product is never the discovery itself — it's the report someone else can trust and act on. Write for the reader who knows nothing, not the expert who already knows everything.