Forensic

Question 01

What is the difference between volatile and non-volatile evidence?

Volatile evidence disappears when the power goes off or the system state changes; non-volatile evidence stays on storage without power.

Volatile evidence lives in places that need constant power or constant activity: RAM, running processes, open network connections, logged-in users, the clipboard, ARP and DNS caches, routing tables and the system clock. It can be lost in seconds by a reboot, a shutdown, or simply by the machine carrying on running.

Non-volatile evidence survives without power: files on a hard drive or SSD, partitions, event logs, registry hives stored on disk, browser history, email stores, USB sticks and backups. It is not fragile in the same way, so it can be collected later and more than once.

• Why it matters: investigators collect in order of volatility (RFC 3227), most fragile first: CPU registers and cache, then RAM and network state, then temporary files, then disk, then remote logs, then archives.
• A caution: a running computer keeps changing its disk too, and SSD housekeeping such as TRIM can destroy deleted data on its own. Non-volatile means it survives power loss, not that it is untouchable.

Question 02

Why should an investigator preserve RAM when appropriate?

Memory holds evidence that exists nowhere on disk, and it is gone the moment the machine is switched off.

RAM shows what the computer was doing at that moment: the processes that were running, the network connections they held open, the commands that had been typed, and the files and registry keys they were using. Fileless malware and injected code may exist only in memory, so a disk image alone can miss the whole attack.

Memory can also contain things that are never saved in plain form on disk: encryption keys for BitLocker or VeraCrypt volumes, passwords and session tokens, chat messages, and the contents of private browser windows. A memory image gives an analyst a chance to unlock encrypted disks and to see an attack as it happened.

• How: capture it early with a trusted tool run from external media (for example WinPmem, FTK Imager or Magnet RAM Capture), then hash the dump and analyse it with a tool such as Volatility.
• When appropriate: capturing RAM changes the system slightly, can crash an unstable machine, and means little on a computer that is already powered off. The examiner weighs this and records the decision and the tool footprint.

Question 03

Why is a forensic image different from a normal file backup?

A backup copies the files you can see so they can be restored; a forensic image is an exact, verified, bit-for-bit copy of the whole device.

A normal backup copies files and folders through the operating system. It skips deleted files, unallocated space, slack space and hidden areas, it may change timestamps as it reads, and it proves nothing about whether the copy matches the original.

A forensic image copies every sector of the storage device, in order, including partition tables, file system metadata, deleted files that have not been overwritten, and unused space where fragments of old data survive. It is made through a write blocker so the original cannot be changed, and the source and the image are hashed to prove they match.

• Formats: raw (dd) or E01, which also stores case details, examiner name, time and hashes.
• Use: analysis is done on copies of the image, so the original stays untouched and anyone can repeat the work.
• Result: the image stands up in court because its accuracy can be demonstrated; a backup cannot do that.

Question 04

What does a SHA-256 hash tell you?

It is a 64-character fingerprint of the data: identical data always gives the same hash, and any change gives a completely different one.

SHA-256 turns any input into a fixed 256-bit value, written as 64 hexadecimal characters. It is one-way, so you cannot rebuild the data from the hash, and it is collision-resistant, so finding two different inputs with the same hash is not practical.

In forensics that gives three uses. Examiners hash a drive when they acquire it and again after imaging to show the copy is exact. They re-hash later to show nothing has changed since. They also compare file hashes against known sets, such as the NSRL list of standard software files to ignore, or lists of known malware to find.

• Avalanche effect: changing a single character flips about half of the hash bits.
• What it does not tell you: who made the data, when, or what it means.

See it on a real message in Lab 01: one added character changed 58 of the 64 hash characters. →

Question 05

What are the limitations of using a hash to establish evidence integrity?

A hash can show that data has changed, but it cannot show that it is genuine, who changed it, or what changed.

A hash is only as trustworthy as the place it is recorded. If someone can alter the evidence and the stored hash together, the check still passes. A hash taken after tampering simply fingerprints the tampered data, so the first hash must be taken at acquisition, by the examiner, and recorded somewhere safe.

A hash also gives a bare yes or no. It does not say which bytes changed, and harmless changes such as a mounted file system updating a timestamp break it just like malicious ones. It cannot be used on live data that keeps changing, such as RAM or running logs, except on the captured copy.

• Weak algorithms: MD5 and SHA-1 have known collision attacks, so use SHA-256 or better, often alongside a second hash.
• No origin or time: a hash does not prove who created the data or when. Digital signatures and trusted timestamps cover that.
• Fixes: record hashes in the signed report and chain of custody, keep a copy in a separate place, use write blockers, and hash in segments so a damaged area can be located.

Lab 01 shows the weak spot: if Amaka replaced both the message and its hash, nobody would notice. →

Question 06

What information can be obtained from a Windows process listing?

A process listing shows what is running on the machine, who started it, from where, and what it is connected to.

For each process Windows records its name and process ID (PID), the parent process ID, the account it runs as, the session, when it started, and how much CPU and memory it uses. With more detail you also get the full path of the program, its command-line arguments, the DLLs it has loaded, the files and registry keys it has open, its threads, and the network connections it owns.

The parent-child relationships are especially useful, because they show how a program was launched and let the examiner follow an attack from the first process to the last.

• Tools: tasklist /v /svc, Get-Process, Task Manager and Sysinternals Process Explorer; netstat -ano links connections to PIDs.
• Command lines: Get-CimInstance Win32_Process shows the full command line of each process.
• From memory: Volatility's pslist, pstree and psscan list processes in a memory image, and psscan can reveal processes that were hidden or had already ended.

Question 07

Why might a suspicious process require further investigation?

Odd details in a process listing are leads, not proof; each one needs checking against other evidence before anyone concludes it is malicious.

Attackers disguise malware by copying the look of normal Windows processes, so examiners check each process against what is normal. These are the common warning signs, and any one of them is a reason to dig further rather than a verdict.

• Wrong name or place: scvhost.exe instead of svchost.exe, or a system-looking name running from Temp, AppData or Downloads instead of System32.
• Wrong parent: Word or a browser launching cmd.exe or PowerShell, or svchost.exe not started by services.exe.
• Suspicious command line: encoded PowerShell (-enc), hidden windows, or downloads from unknown addresses.
• Network behaviour: regular connections to unfamiliar addresses, which can be command-and-control beaconing.
• Other signs: no valid digital signature, unusual CPU use (cryptominers), or code injected into a legitimate process.

Legitimate tools are misused too, so context decides. The next steps are to check the file hash and signature against threat intelligence such as VirusTotal, dump the process memory, look for how it persists (Run keys, services, scheduled tasks), and line it up with logs and network records.

Question 08

What types of activity may be recorded in the Windows Registry?

The Registry is Windows' configuration database, and it keeps traces of software, devices, users and what they have done.

The Registry is stored in hive files such as SYSTEM, SOFTWARE, SAM, SECURITY and each user's NTUSER.DAT. Every key keeps a last-write time, which lets an examiner date activity.

• System details: Windows version and install date, computer name, time zone, last shutdown time, and user accounts with logon counts.
• Software and persistence: installed programs, services, and autorun entries such as the Run and RunOnce keys that malware uses to survive a reboot.
• Program execution: UserAssist, BAM/DAM, Amcache and ShimCache show programs that ran or were present, and roughly when.
• User activity: recently opened documents (RecentDocs), typed paths, open and save dialog history, and ShellBags showing folders that were browsed, including on removable and network drives.
• Devices: every USB storage device that was connected, with its serial number and first and last connection times.
• Networks: Wi-Fi networks joined, mapped drives, and Remote Desktop connection history.

The Registry shows traces and settings, not intent, so findings are read together with other artifacts.

Question 09

Why does a USB device record not necessarily prove that files were copied?

A USB record proves a device was connected; it does not prove anything was copied to or from it.

Windows records the make, serial number and first and last connection times of a USB storage device, plus the drive letter and the user account it was used under. All of that shows a device was plugged in. It does not show what happened next.

• It may only have been plugged in to charge, or opened and never used.
• Files may have been read or viewed, not copied.
• Files may have been copied onto the machine from the device, which is the opposite direction.
• Someone else may have been using the account or the machine at the time.
• Clock and time zone problems can make the times unreliable.

To claim files were copied, the examiner needs corroboration: shortcut (LNK) files and Jump Lists that point to files on the removable drive, ShellBags showing its folders were opened, file system records and the USN journal, event logs for the device, and ideally the same files, matching by hash, found on the device itself. Without that, the careful statement is 'this device was connected between these times', not 'this person took these files'.

Question 10

Why must investigators correlate multiple artifacts?

One artifact is a single fragment that can be innocent, incomplete or wrong; several independent artifacts agreeing is what makes a finding reliable.

Each artifact records only a narrow piece of the story, on its own clock, with its own limits. Logs rotate, timestamps can be changed on purpose (timestomping) or thrown off by clock errors, and individual records can be misread. When different sources point to the same event, the conclusion is much harder to dispute.

• Example: a Registry entry shows a USB drive connected at 14:02, a shortcut file shows a document opened from drive E: at 14:05, ShellBags show that folder browsed, the event log shows the user logged on at 13:58, and the document's file system timestamps match. Together they tell a story that none of them could alone.
• Contradictions are useful too: they reveal wrong clocks, anti-forensic tampering or a wrong assumption.
• Method: convert everything to one time standard (usually UTC), build a timeline, and note which facts are confirmed and which are only inferred.

Question 11

What information should be included in a chain of custody?

The chain of custody is the unbroken written record of who held the evidence, when, where and why, from collection to court.

Every item gets a unique evidence ID, and the record should include the following.

• Description: make, model, serial number, capacity, condition, photographs, and where and in what state (on, off, locked) it was found.
• Collection: who collected it (name, role and signature), the date, time and time zone, and the legal authority such as a warrant or consent.
• Acquisition: the tool and version used, whether a write blocker was used, and the hash values of the source and the image.
• Every transfer: from whom, to whom, date and time, reason, and signatures on both sides.
• Storage: the location, how it was sealed (bag, tamper-evident seal number) and a log of everyone who accessed it.
• Actions: each examination carried out, by whom and when, with hash checks at each stage.
• Outcome: final disposal, such as return to the owner or destruction.

A gap or an unexplained change in the record lets the other side argue the evidence could have been tampered with, which can reduce its weight or get it excluded.

Question 12

Why should investigators document unsuccessful procedures and acquisition errors?

The examiner's work must be open to challenge and repeatable, so failures and errors are part of the evidence's history and must be recorded.

A failed attempt can change the evidence. A tool that crashed may have written to the disk, a retried command may have altered timestamps, and an interrupted copy may be incomplete. The court needs to know this, because it affects how far the evidence can be trusted.

• Honesty and credibility: opposing experts will look for what the examiner left out. An error that is recorded and explained is a footnote; one that is hidden and then discovered looks like concealment.
• Accuracy of the findings: bad sectors that were skipped, a hash mismatch, or a partial RAM capture limit what can be claimed, and the report must say so.
• Repeatability: another examiner can see what was tried, avoid the same dead end, and verify the work.
• Audit trail: guidance such as the UK ACPO principles asks that a record of every process applied is kept, so an independent third party could repeat it and reach the same result.
• Improvement: the record helps validate tools and refine procedures.