Digital
Forensics

Digital forensics is the application of scientific methodology to the identification, preservation, analysis, and presentation of digital evidence. It sits at the intersection of computer science, law, and investigative practice — and the rigour it demands from all three domains simultaneously is what makes it one of the most technically and intellectually demanding specialisations in security.

The discipline emerged in the late 1980s and early 1990s as law enforcement began encountering computers as both tools of crime and repositories of evidence. Early digital forensics was largely ad hoc — investigators with computer knowledge doing their best without standardised methodology or dedicated tooling. The first significant legal recognition of digital evidence came through cases in the early 1990s, and the field has since matured into a recognised profession with certifications, standards bodies, peer-reviewed research, and expert witness protocols.

The Four Goals

Every digital forensic investigation, regardless of context or complexity, pursues four sequential goals:

1. Identify — locate and recognise potential evidence. This requires knowing where evidence might exist across different storage media, operating systems, applications, and network infrastructure. Identifying evidence that hasn't yet been collected is as important as analysing what you have.
2. Preserve — protect evidence from alteration or destruction. Forensic soundness — the property of evidence that allows it to be verified as unmodified — is established during preservation. This is where write blockers, cryptographic hashing, and chain of custody documentation enter the process.
3. Analyse — examine preserved evidence to reconstruct events, identify artefacts, attribute actions to individuals, and answer the questions driving the investigation. Analysis requires both technical knowledge and analytical discipline — the ability to reason from evidence rather than starting with a conclusion.
4. Present — communicate findings clearly and accurately to an appropriate audience. In legal proceedings this means expert testimony. In corporate investigations it means a written report. In an IR context it may mean a verbal briefing to the CISO. Findings that cannot be communicated effectively are findings that cannot drive decisions.

Forensics vs Incident Response

Digital forensics and incident response are closely related but distinct disciplines. They are often performed by overlapping teams — particularly in smaller organisations — but they have different primary objectives that sometimes create tension.

Incident response is operationally focused. Its primary goal is containing damage, eradicating the threat, and restoring normal operations as quickly as possible. Evidence preservation is important to IR, but it is one consideration among many — speed of containment often takes precedence.

Digital forensics is investigatively focused. Its primary goal is establishing what happened, how, and by whom — with a standard of rigour sufficient for legal proceedings. It operates under more stringent evidence handling requirements and moves more deliberately than operational IR.

In practice, the initial response to a major incident is IR-led (contain, eradicate, recover) while forensics runs in parallel or follows immediately after (preserve, analyse, present). The key handoff point is evidence preservation — the IR team must not destroy forensic evidence in the process of containing the incident, which requires forensic awareness even in the operational response phase.

Branches of the Discipline

Digital forensics encompasses several distinct sub-disciplines, each with its own tooling, methodology, and specialist knowledge requirements:

• Disk / File System Forensics — examination of storage media: hard drives, SSDs, USB devices, optical media. Analysis of file systems (NTFS, ext4, APFS, FAT32), deleted file recovery, metadata analysis, timeline reconstruction.
• Memory Forensics — acquisition and analysis of volatile memory (RAM). Captures running processes, network connections, encryption keys, injected code, and credential material that exists nowhere on disk.
• Network Forensics — analysis of network traffic captures and logs. Reconstructs communications, identifies attack vectors, traces lateral movement, and can recover transmitted files and credentials.
• Mobile Device Forensics — extraction and analysis of evidence from smartphones and tablets. Encompasses iOS, Android, and legacy platforms; includes app data, location history, communications, and cloud account artefacts.
• Cloud Forensics — investigation of incidents involving cloud infrastructure. Navigates shared responsibility model constraints, cloud-native logging, and cross-jurisdiction evidence issues.
• Malware Forensics — analysis of malicious software. Combines static analysis (examining code without executing it) with dynamic analysis (observing behaviour in a controlled environment) to understand malware capabilities and origins.
• Database Forensics — investigation of database systems for evidence of data theft, modification, or destruction. Specialised and less commonly encountered outside financial crime and insider threat cases.

Admissibility Standards

Digital forensic evidence is only as valuable as its admissibility in the proceedings where it is used. Two competing legal standards govern the admissibility of expert testimony in US federal courts:

The Frye Standard (from Frye v. United States, 1923) holds that scientific evidence is admissible if the methodology used is generally accepted within the relevant scientific community. It is a community-consensus test.

The Daubert Standard (from Daubert v. Merrell Dow Pharmaceuticals, 1993) is the current federal standard and has been adopted by most US states. It gives judges a gatekeeper role and requires that expert testimony be based on: sufficient facts or data, reliable methodology, the methodology having been tested and subjected to peer review, a known or potential error rate, and general acceptance in the relevant scientific community. Daubert is stricter than Frye and places greater demands on expert witnesses to demonstrate the scientific rigour of their methods.

In the UK, the Criminal Procedure Rules and the ACPO (Association of Chief Police Officers) Principles — now superseded by the Digital Forensics Working Group guidelines — govern digital forensic practice. The four ACPO principles remain the most cited framework for UK practitioners: no action taken by law enforcement should change data held on a computer or storage media; a competent person must be able to explain the process used; an audit trail must be created; and the Investigating Officer is responsible for ensuring the law and these principles are adhered to.

Why Methodology Matters More Than Tools

A recurring mistake in early-career forensic analysts is tool-centrism — the belief that having the right software is the primary determinant of a good investigation. Tools change. EnCase was the industry standard; then FTK; now Autopsy, Magnet AXIOM, and X-Ways all have significant market share, and Volatility has become essential for memory work that didn't exist as a discipline a decade ago. An analyst whose skills are tied to a specific tool is perpetually behind.

Methodology — the systematic, documented, reproducible approach to evidence handling and analysis — is what gives forensic findings their legal and investigative value. A finding reached by impeccable methodology using open-source tools will survive courtroom scrutiny. A finding reached by sloppy methodology using the most expensive commercial platform on the market will not.

Digital forensics is a legally-embedded discipline. Every decision a forensic examiner makes — what to collect, how to collect it, what to document, what to disclose — has potential legal consequences. An examiner who is technically brilliant but legally naive will produce findings that collapse under challenge, expose their organisation to liability, or — in criminal cases — result in evidence being excluded and investigations failing. This chapter provides the legal and ethical grounding that every forensic practitioner needs before touching evidence.

Chain of Custody in Depth

Chain of custody is the continuous, documented record of who had possession of evidence, when, and what they did with it. It is not a formality — it is the mechanism by which courts determine whether evidence is reliable.

A chain of custody failure occurs when there is a gap in the record: a period during which we cannot account for where the evidence was or who had access to it. Opposing counsel will argue that the gap represents an opportunity for tampering. Courts may exclude the evidence. Even if exclusion is not ordered, the gap will be used to undermine the weight of the evidence in the minds of a jury or judge.

A complete chain of custody record for digital evidence includes:

• Unique evidence identifier (number or label) assigned at the point of collection
• Description: device type, make/model, serial number, storage capacity, physical condition
• Date, time, and location of collection
• Name, role, and signature of the collecting examiner
• Hash values (MD5 and SHA-256 minimum) of any forensic images taken
• Storage location after collection — evidence bag number, locker location, or encrypted cloud storage with access logging
• Every subsequent transfer: receiving party, date/time, purpose, and signature
• Every access: who accessed it, when, for what purpose, and for how long

Search and Seizure Law

The Fourth Amendment to the US Constitution protects individuals against unreasonable searches and seizures by government actors. For law enforcement digital forensics, this means a valid warrant is generally required to search digital devices — including content stored in the cloud. The key cases shaping digital search and seizure law:

• Riley v. California (2014) — Supreme Court held unanimously that police cannot search the digital contents of a cell phone during an arrest without a warrant. Established that the digital privacy interest in a smartphone is categorically different from physical items incident to arrest.
• Carpenter v. United States (2018) — Supreme Court held that accessing historical cell-site location information from a carrier without a warrant violates the Fourth Amendment. Extended Fourth Amendment protection to some third-party data.
• United States v. Warshak (2010) — Sixth Circuit held that email stored on a third-party server is protected by the Fourth Amendment. Influential in shaping how warrants for cloud content are obtained.

For corporate investigators — non-law-enforcement — the Fourth Amendment does not apply directly (it constrains government actors, not private parties). However, authorisation requirements still apply: investigators must have a legitimate legal basis for their investigation, typically derived from employment agreements, acceptable use policies, and HR/legal authorisation.

Authorisation Requirements

Before any forensic examination begins, the examiner must have clear, documented authorisation. The form of that authorisation depends on the context:

Privacy Considerations

Digital devices — particularly personal smartphones and laptops — contain extraordinarily intimate records of a person's life: medical information, financial records, communications with attorneys, mental health data, religious practices, and sexual behaviour. Forensic examiners routinely encounter this material as a byproduct of examining devices for specific evidence. The ethical obligation to handle it appropriately is significant.

Scope limitation is the primary mechanism: forensic analysis should be limited to the evidence specified in the authorisation. An investigator authorised to examine financial records on a corporate laptop should not be reading personal medical files on the same device — even if they are technically visible during the examination.

GDPR implications for EU-based investigations: personal data collected during a forensic investigation is still subject to GDPR. Processing must have a lawful basis (typically Article 6(1)(f) — legitimate interests — or Article 9 for special category data). Data minimisation applies — collect only what is necessary for the specific investigative purpose. Retention periods apply — investigation data cannot be held indefinitely.

BYOD complications: when an employee uses a personal device for work, forensic imaging of that device captures both corporate data (the investigative target) and personal data (outside the authorisation scope). Some organisations address this with MDM (Mobile Device Management) that separates corporate containers from personal data; others require employees to consent to full device examination as a condition of BYOD participation. Neither approach eliminates the privacy tension.

Expert Witness Standards

When forensic findings are presented in legal proceedings, the examiner may be called as an expert witness. Expert witnesses occupy a unique position in law — unlike fact witnesses (who can only testify to what they directly observed), expert witnesses are permitted to offer opinions on matters within their expertise. This makes the qualification of the expert, and the reliability of their methodology, subject to judicial scrutiny.

Under Daubert, a forensic expert must be prepared to address:

• Their qualifications — education, training, certifications (EnCE, GCFA, GCFE, CCE), professional experience
• The specific methodology used — which tools, which settings, which procedures
• Whether the methodology has been tested and peer-reviewed
• The known error rate of the methodology and any tools used
• Whether the methodology is generally accepted in the forensic community

Expert witnesses in forensics are frequently challenged on cross-examination about tool reliability, alternative explanations for findings, whether the chain of custody was properly maintained, and whether the examiner maintained objectivity. Preparation for testimony requires anticipating these challenges and being able to address them with technical precision and composure.

Forensic Ethics

The ethical obligations of a forensic examiner are distinct from those of an investigator, lawyer, or IR analyst. The forensic examiner's primary obligation is to the evidence and to the truth — not to the party that retained them.

Objectivity is the central ethical requirement. A forensic examiner hired by the prosecution must follow the evidence wherever it leads — including to exculpatory findings that help the defence. A forensic examiner hired by a corporation must document findings accurately even if they are damaging to the organisation. The moment an examiner begins shaping findings to serve a predetermined conclusion, they have ceased to be a forensic examiner and become an advocate — a role that should be played by lawyers, not scientists.

Scope discipline — remaining within the authorised scope of the examination — protects both the investigation and the examiner. Examining data outside the authorised scope can result in evidence being excluded, in civil liability for privacy violations, and in professional disciplinary action.

Before any evidence is touched, before any tool is launched, before any analysis begins — there must be methodology. The principles covered in this chapter are not bureaucratic formalities. They are the scaffolding that makes forensic findings trustworthy, reproducible, and legally defensible. An examiner who understands these principles deeply will make better decisions under pressure; one who treats them as checkbox compliance will eventually produce work that fails when it matters most.

Locard's Exchange Principle

Edmund Locard, the French criminologist, articulated in the early 20th century what is now known as his Exchange Principle: every contact leaves a trace. In physical forensics, this means a perpetrator leaves evidence at a crime scene and takes evidence away — fibres, fingerprints, DNA. The physical world cannot be touched without mutual exchange.

In digital forensics, the principle applies with equal force but different mechanics. Every action performed on a digital system leaves traces — in logs, in filesystem metadata, in registry keys, in memory. The attacker leaves traces. But so does the forensic examiner.

When a forensic examiner accesses a live system, they modify it: they update access timestamps on files they open; their tools write to disk; their network connections appear in logs. This is unavoidable for live systems — which is precisely why the order of evidence collection matters, why forensically sound acquisition procedures exist, and why examiners must document every action they take on a live system so that their own traces can be distinguished from the attacker's.

Order of Volatility

Not all evidence persists for the same length of time. The order of volatility governs the sequence in which a forensic examiner should collect evidence — capturing the most ephemeral data first, before it disappears, and working toward more persistent storage.

In practice, the examiner may not be able to collect everything — time, access, and resources constrain what is possible. Knowing the order of volatility allows the examiner to triage intelligently, capturing the most at-risk evidence first and accepting that some lower-priority data may be collected later or not at all.

Forensic Soundness

Forensic soundness is the property of an acquisition process that ensures the evidence collected is a complete and accurate representation of the original, has not been altered by the collection process, and can be verified as such. A forensically sound acquisition has three components:

1. Completeness — every bit of the source media is captured, including allocated data, deleted data, unallocated space, and slack space. A simple file copy is not forensically sound because it only captures allocated files.
2. Integrity — the acquisition process itself did not modify the source. This is achieved through write protection.
3. Verifiability — the examiner can prove the copy is identical to the original through cryptographic hashing.

Write Protection

Write protection is the mechanism that prevents any data from being written to the source media during forensic examination. Without write protection, connecting a suspect drive to a forensic workstation triggers automatic OS activity — drive enumeration, thumbnail generation, Last Accessed timestamp updates — that permanently modifies the evidence.

Hardware write blockers are physical devices that sit between the source drive and the forensic workstation, intercepting any write commands and preventing them from reaching the drive. Major manufacturers include Tableau (now Cellebrite), WiebeTech (now CRU), and UFED. Hardware write blockers are required for legally admissible evidence in most jurisdictions.

Software write blockers are OS-level configurations or tools that prevent writes to a connected device. Windows registry write blocking (HKLM\SYSTEM\CurrentControlSet\Control\StorageDevicePolicies\WriteProtect = 1), or the write-blocking functionality in forensic Linux distributions (SIFT Workstation, CAINE), provide software-level protection. Accepted for operational IR but may not satisfy the evidentiary requirements of criminal proceedings.

Cryptographic Hashing and Verification

A cryptographic hash is a fixed-length fingerprint of data — change a single bit in the input and the hash output changes completely. Forensic hashing establishes, with cryptographic certainty, that a forensic copy is identical to the original at the moment of acquisition, and that neither has been modified since.

The standard forensic workflow:

1. Hash the source drive before acquisition (source hash)
2. Acquire the forensic image
3. Hash the forensic image (destination hash)
4. Compare source and destination hashes — if they match, the image is verified
5. Hash the forensic image again at the start of each analysis session (working hash) — if it matches the destination hash, the working copy has not been modified

Modern forensic formats (E01, AFF4) embed the hash in the image file itself. Any modification to the image will cause a hash mismatch on verification — making tampering immediately detectable.

Documentation Discipline

Documentation in digital forensics serves a purpose beyond bureaucratic compliance — it is the audit trail that allows another examiner to reproduce every step of the investigation and reach the same conclusions. Without documentation, findings cannot be verified, challenged, or built upon.

What to document during an examination:

• The physical state and condition of the device at collection (photograph the device and any damage)
• Every command executed on a live system during triage, with timestamp
• Every tool used, version number, and settings applied
• All hash values with the time they were calculated
• Every finding, with the artefact location, tool or method used to identify it, and timestamp
• Any anomalies encountered — unexpected tool behaviour, unreadable sectors, evidence of anti-forensics
• Time and date of each work session

The forensic copy (the write-blocked image) is the evidence. The working copy is what the examiner actually analyses. These must be kept distinct — the working copy can be restored from the forensic copy if contaminated; the forensic copy must remain unmodified.

Windows is the operating system most commonly encountered in enterprise forensic investigations, and NTFS is its native filesystem. A thorough understanding of NTFS internals — how it stores data, what metadata it records, and where evidence persists even after deletion — is foundational to Windows forensic analysis. This chapter covers the filesystem structures that matter most for investigations, followed by the Windows Registry as a rich source of user activity and system configuration evidence.

NTFS Architecture Overview

NTFS (New Technology File System) was introduced with Windows NT and has been the default Windows filesystem since Windows XP. Its core design principles — journaling for reliability, per-file security descriptors, support for large volumes and files, and extensive metadata — make it one of the most forensically rich filesystems in common use.

Every NTFS volume begins with the Volume Boot Record (VBR), which contains the NTFS BPB (BIOS Parameter Block) — parameters describing the volume geometry. The first system file, $MFT, is the Master File Table.

The Master File Table ($MFT)

The MFT is the heart of NTFS. Every file and directory on an NTFS volume — including system files — has a corresponding record in the MFT. Each MFT record is 1024 bytes by default and contains attributes that describe the file: its name, timestamps, security descriptor, data location, and the data itself (for very small files, data is stored directly in the MFT record — called resident data).

Key MFT system files:

The $UsnJrnl (Update Sequence Number Journal) is forensically critical. It records all file and directory changes on the volume — creation, deletion, rename, attribute modification — with timestamps. Because it retains a rolling history (typically tens of thousands of entries), it often preserves evidence of file operations that occurred before the examiner arrived — including file deletion. Tools like MFTECmd.exe (Eric Zimmerman) parse the UsnJrnl into human-readable output.

NTFS Timestamps — MACB

NTFS records four timestamps for every file, stored in the $STANDARD_INFORMATION attribute and, separately, in the $FILE_NAME attribute. These are known by the acronym MACB:

• M — Modified: when the file's data content was last changed
• A — Accessed: when the file was last read (not reliable — Windows disables Last Access updates by default since Vista for performance reasons)
• C — Changed: when the MFT entry itself was last changed (metadata modification — rename, permission change, attribute update)
• B — Born (Created): when the file was created on this volume

The $STANDARD_INFORMATION timestamps are user-accessible and can be modified by programs (including attacker tools — see Chapter 13). The $FILE_NAME timestamps are set by the kernel and are significantly harder to manipulate from user space — making discrepancies between the two a key indicator of timestomping (deliberate timestamp manipulation).

Deleted File Recovery

When a file is deleted in Windows, the following happens in NTFS:

1. The MFT record for the file is marked as not in use (a single bit flip in the record header)
2. The clusters occupied by the file's data are marked as available in the $Bitmap
3. The file's entry in its parent directory is removed
4. The data itself is not overwritten

This means that immediately after deletion, all of the file's data is still physically present on the disk — only the filesystem's bookkeeping has been updated. Recovery is possible until the clusters are overwritten by new data. On an active system, this may happen quickly; on a less active system or a seized device powered off after deletion, recovery may succeed even weeks or months later.

Recovery tools (Autopsy, PhotoRec, FTK, Recuva) recover deleted files by scanning unallocated space for known file signatures — a technique called file carving — and by parsing MFT records marked as not in use, which still contain metadata about the deleted file.

Slack Space

NTFS allocates disk space in clusters — the minimum allocation unit, typically 4KB. If a file is 5KB, it occupies two clusters (8KB total), leaving 3KB of allocated but unused space at the end of the second cluster. This wasted space is called file slack.

File slack is divided into two types:

• RAM slack — the space between the end of the file data and the end of the last sector (512 bytes). In older Windows versions, this was filled with RAM contents at the time of writing — a fascinating and occasionally evidence-rich artefact. Modern Windows zeros this space.
• Drive slack — the space between the end of the last sector used and the end of the last allocated cluster. May contain remnants of previously deleted files that once occupied those clusters.

Slack space analysis has produced evidence in numerous cases — fragments of previously existing files recovered from the slack space of a current file. It requires a forensic tool that can access the raw disk image rather than the filesystem layer.

Alternate Data Streams (ADS)

NTFS supports Alternate Data Streams — the ability to attach additional named data streams to any file or directory. The primary data stream (the file content you see in Explorer) is the unnamed stream. ADS are named streams that exist alongside it, invisible to standard directory listings.

ADS are used legitimately by Windows (the Zone.Identifier stream marks files downloaded from the internet — forensically useful for proving provenance) and by some applications. They are also used by malware to hide executable code and data. A file that appears to be a 1KB text document may have a 500KB malicious executable hidden in an ADS.

The Windows Registry

The Windows Registry is a hierarchical database that stores configuration information for the operating system, hardware, and applications. From a forensic standpoint, it is one of the richest evidence sources on a Windows system — recording user activity, program execution, hardware connections, network history, and system configuration in ways that users and most malware do not anticipate or fully clean up.

Registry Structure

The Registry is divided into five root keys (hives). The two most forensically valuable are HKEY_LOCAL_MACHINE (HKLM) — system-wide settings — and HKEY_CURRENT_USER (HKCU) — per-user settings. The hive files on disk:

High-Value Forensic Registry Keys

Windows generates a remarkable volume of forensic artefacts in the normal course of operation — records of program execution, file access, user activity, and system events that persist even after users attempt to cover their tracks. This chapter covers the artefacts that experienced Windows forensics practitioners reach for first, along with the interpretation pitfalls that trip up less experienced analysts.

Prefetch Files

The Windows Prefetch service monitors the first 10 seconds of application launch and caches data to speed up subsequent launches. As a side effect, it creates a .pf file in C:\Windows\Prefetch\ for each executable that runs, recording:

• The executable name and path
• Up to 8 timestamps: last run time and (on Windows 8+) the last 8 run times
• Run count
• All files and directories referenced during the first 10 seconds of execution (DLLs loaded, data files opened, temp files created)

Prefetch is enabled by default on workstations and disabled by default on servers (to reduce I/O overhead). Its forensic value is significant: it proves a program executed, when it last ran, how many times it ran, and what files it accessed — even if the executable itself has been deleted.

LNK Files and Jump Lists

Windows automatically creates LNK shortcut files when a user opens a file, even if no shortcut is manually created. These are stored in C:\Users\[user]\AppData\Roaming\Microsoft\Windows\Recent\. Each LNK file records:

• The target file path (original and sometimes network location)
• Target file size at the time of access
• Target file timestamps (modified, accessed, created) at the time of access
• Volume serial number and drive type (removable, fixed, network)
• Machine NetBIOS name where the target resided

LNK files prove a file was accessed even if the file itself is gone. The volume serial number and machine name inside an LNK prove which machine or removable device the file came from — critical for data exfiltration investigations.

Jump Lists are extension of the LNK concept — per-application lists of recently accessed files stored in AppData\Roaming\Microsoft\Windows\Recent\AutomaticDestinations\ and CustomDestinations\. Each file is named with an application ID (AppID) hash and contains multiple LNK entries. Jump Lists can preserve access records going back much further than the Recent folder, which is typically limited to the most recent files.

Shellbags

Shellbags record Windows Explorer's folder browsing history — every folder a user has opened in Explorer generates a Shellbag entry, which persists in the Registry even after the folder is deleted or the connected device is removed. This makes Shellbags uniquely valuable for proving that a user accessed a specific folder — including folders on external drives and network shares that no longer exist.

Shellbags are stored in UsrClass.dat (for Desktop IE and Windows Explorer 7+) under Local Settings\Software\Microsoft\Windows\Shell\BagMRU and Bags. Eric Zimmerman's ShellBagsExplorer provides a GUI for navigating the Shellbag tree and reconstructing folder browsing timelines.

Browser Artefacts

Web browsers record extensive activity that is forensically valuable: history, cached content, downloads, saved credentials, form fill data, and session cookies. The storage format and location varies by browser:

All Chromium-based browser databases (History, Cookies, Login Data) are SQLite files. Standard SQLite browsers (DB Browser for SQLite, sqlitebrowser) or forensic tools (Magnet AXIOM, Hindsight) can query them directly. Browser artefacts prove web-based file exfiltration (uploads to cloud storage, webmail attachments), research behaviour (reconnaissance of targets), and credential compromise (saved passwords).

Windows Event Log Forensics

Windows Event Logs are one of the highest-value evidence sources in Windows forensics. Stored in C:\Windows\System32\winevt\Logs\ as .evtx files, they record security events, system events, application events, and application-specific logs. Key Event IDs:

Volume Shadow Copies

Volume Shadow Copy Service (VSS) creates point-in-time snapshots of NTFS volumes, used by Windows for System Restore, Previous Versions, and backup. These shadow copies can be a forensic goldmine — they may contain Registry hives, event logs, and files from points in time before the attacker arrived or before they deleted evidence.

Attackers know this. Ransomware routinely executes vssadmin delete shadows /all /quiet or equivalent before encrypting files. The presence of this command in process creation logs (Event ID 4688) or in Prefetch is itself strong evidence of malicious intent. Detecting the deletion of shadow copies is a key ransomware indicator.

mklink /d C:\vss \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\

SRUM — System Resource Usage Monitor

Introduced in Windows 8, SRUM records application and network usage data going back approximately 30 days in C:\Windows\System32\sru\SRUDB.dat — an ESE (Extensible Storage Engine) database. SRUM records include:

• Every application that ran, with total CPU time, memory usage, and I/O byte counts
• Network usage per application — bytes sent and received per network interface
• Energy consumption data

SRUM is particularly valuable for data exfiltration investigations: it records the exact number of bytes sent by each application over each network interface over the past 30 days. Even if the attacker deleted their tools, SRUM may preserve a record that a specific process sent hundreds of megabytes of data to an external IP.

While Windows dominates enterprise endpoint environments, Linux dominates servers, cloud infrastructure, and DevOps toolchains — and macOS is ubiquitous in creative, technology, and executive roles. Forensic investigations routinely span all three platforms. This chapter covers the key artefacts and methodological differences that apply when moving beyond Windows.

Linux Filesystem Forensics — ext4

The ext4 filesystem (Fourth Extended Filesystem) is the default on most Linux distributions. Its forensic characteristics differ significantly from NTFS:

• Inodes — ext4 uses inodes (index nodes) rather than an MFT. Each inode stores file metadata: permissions, owner, timestamps, and pointers to data blocks. The inode does not store the filename — that is stored in the directory entry that points to the inode. When a file is deleted, the directory entry is removed, but the inode and data blocks may persist until overwritten.
• Three timestamps — Linux traditionally records three timestamps: mtime (data modification), atime (access — may be disabled with noatime mount option), and ctime (inode change — metadata modification). A fourth, btime (birth/creation time), was added in ext4 but is not exposed by all tools.
• Journal — ext4 journals filesystem transactions for crash recovery. The journal may retain recent filesystem operations that can be forensically recovered, similar to the NTFS $LogFile.
• No MFT equivalent — there is no central file describing all other files. Forensic tools must scan inode tables and directory structures to reconstruct the filesystem.

Linux Log Files

Linux centralises logs in /var/log/. The most forensically valuable:

On systems using systemd (most modern Linux distributions), logs are also stored in the binary journal at /var/log/journal/ and queried with journalctl. The journal correlates log entries from all services with precise timestamps and can be filtered by unit, time range, priority, and user.

Bash History and Its Limitations

The bash shell records commands to ~/.bash_history. Each user has their own history file. This is among the first artefacts investigators check — and among the most frequently manipulated.

Limitations and manipulation techniques investigators must account for:

• History is written on shell exit — commands executed in a session that is killed (rather than exited normally) may not be written to .bash_history
• HISTSIZE and HISTFILESIZE — environment variables that control how many commands are retained. Setting both to 0 disables history entirely.
• HISTFILE — can be set to /dev/null to discard all history
• Prefixing with a space — commands prefixed with a space are not recorded (when HISTCONTROL=ignorespace is set, which is common)
• Direct deletion — history -c clears in-memory history; deleting .bash_history removes the file

Despite these limitations, bash history often retains evidence that attackers overlook. Additionally, the absence of history for a period where the system was clearly active is itself a finding. Correlate bash history with auth.log login records to identify periods of activity with no corresponding history.

Linux Persistence Artefacts

Linux persistence mechanisms leave forensic traces across multiple locations. A systematic persistence check during a Linux forensic investigation:

macOS Forensics

macOS presents a distinct forensic environment — built on a BSD Unix foundation but with Apple-specific filesystem, logging, and application frameworks layered on top.

APFS — Apple File System

APFS (Apple File System) replaced HFS+ as the default macOS filesystem in 2017. Key forensic characteristics:

• Clone files — APFS supports instant file cloning (copy-on-write). Cloned files share data blocks until one is modified. This complicates deleted file recovery — a deleted clone may be partially recoverable through its source.
• Snapshots — APFS supports filesystem snapshots. Time Machine backups use APFS snapshots on APFS volumes. These are forensically equivalent to VSS on Windows — historical filesystem states accessible for investigation.
• Encryption — APFS supports per-file and per-volume encryption. FileVault 2 on modern Macs uses APFS encryption. Without the user's login password or a FileVault recovery key, an encrypted APFS volume cannot be examined.
• Timestamps — APFS stores four timestamps: created, modified, changed (metadata), and accessed — similar to ext4.

macOS Unified Logging

Apple replaced the traditional syslog architecture with the Unified Logging System in macOS 10.12 (Sierra). Log data is stored in a compressed binary format at /var/db/diagnostics/ and queried with the log command or Console.app. The unified log captures significantly more system activity than traditional syslog but requires specific query knowledge to use effectively.

Key macOS Forensic Artefacts

Memory forensics is one of the most powerful and technically demanding sub-disciplines in digital forensics. It occupies a unique forensic space: the contents of RAM are invisible to filesystem analysis, disappear on shutdown, and contain categories of evidence — active encryption keys, injected shellcode, credentials in plaintext, and the full process execution state — that no other forensic technique can recover. As malware has increasingly moved toward fileless, memory-resident techniques specifically to evade disk-based detection and forensics, memory analysis has become an essential skill for any serious practitioner.

Why Memory Forensics Matters

Physical RAM contains evidence that exists nowhere else on the system:

• Fileless malware — malware that loads entirely into memory without writing executable files to disk. PowerShell Empire, Cobalt Strike's in-memory payloads, and reflectively loaded DLLs all fall into this category. They leave no disk artefacts for traditional forensics to find.
• Encryption keys — BitLocker volume master keys, TrueCrypt/VeraCrypt keys, and ransomware encryption keys in use are present in RAM while the encrypted volume or process is active. A memory dump taken before shutdown may allow decryption of otherwise inaccessible evidence.
• Credentials in plaintext — Windows caches credentials in LSASS memory for single sign-on purposes. Tools like Mimikatz exploit this to extract plaintext passwords and NTLM hashes. A memory dump taken from a compromised system may reveal all credentials that were cached at the time.
• Network connections — active network connections maintained by running processes — including C2 connections — are visible in memory even if the process has been configured to hide them from standard OS tools.
• Process injection artefacts — injected shellcode, hollowed processes, and reflectively loaded DLLs leave characteristic signatures in memory that Volatility can identify even when they are invisible to the operating system's own process listing tools.

Memory Acquisition

Memory acquisition must be performed on a live system — you cannot image RAM from a powered-off machine (with the extremely rare exception of cold boot attacks, where RAM contents persist briefly at low temperatures after shutdown). This creates a challenge: the act of running acquisition software modifies the memory you are trying to capture.

Windows Memory Acquisition

WinPmem is the most widely used open-source Windows memory acquisition tool. It operates as a kernel driver that maps physical memory to a file. Output formats include AFF4 (compatible with Volatility 3) and raw (dd-compatible).

DumpIt provides an extremely simple one-click acquisition — run the binary and it creates a raw memory dump in the same directory. Produces a CSV process listing alongside the dump. Excellent for non-technical responders who need to acquire memory quickly.

Magnet RAM Capture (Magnet Forensics, free) provides a GUI interface and outputs a .mem file. Useful in situations where a GUI is preferred.

The hibernation file (C:\hiberfil.sys) — when Windows hibernates, it writes the full contents of RAM to the hibernation file on disk. This is a compressed memory image that Volatility can analyse directly after decompression. If a system was hibernated during or after an incident, the hiberfil.sys is a ready-made memory image.

VMware and Hyper-V snapshots — virtual machine snapshots include a memory image (.vmem for VMware, checkpoint files for Hyper-V). If the compromised system is a VM and a snapshot exists, this may be the easiest path to memory evidence.

Linux Memory Acquisition — LiME

LiME (Linux Memory Extractor) is a loadable kernel module that acquires physical memory with minimal process footprint. It must be compiled for the specific kernel version of the target system — this compilation should be done on an identical system (same kernel, same distribution) to avoid instability.

Volatility 3 — The Analysis Framework

Volatility 3 is the current version of the most widely used open-source memory forensics framework. It analyses memory images from Windows, Linux, and macOS using a plugin architecture. The transition from Volatility 2 to 3 brought Python 3 support, improved performance, and a new symbol table system — but the core analytical approach remains the same.

Getting Started

Process Analysis

Process analysis is typically the first step in a memory forensics investigation. Volatility provides three complementary process listing plugins, each using a different data structure:

Comparing pslist and psscan output is a classic rootkit detection technique. Processes that appear in psscan but not in pslist have been deliberately hidden from the OS process listing by a rootkit — a strong indicator of malicious activity.

Suspicious Process Indicators

• Unexpected parent processes — cmd.exe or powershell.exe spawned by winword.exe, excel.exe, or a web browser indicates code execution from a document or web content
• Misspelled or masquerading process names — svchost.exe running from C:\Users\Public\ or scvhost.exe, svch0st.exe
• svchost.exe without required parent — legitimate svchost.exe always has services.exe as its parent
• Single-instance processes with multiple instances — lsass.exe, smss.exe, and winlogon.exe should appear only once in a standard system
• Unusual creation times — a process running for 45 days on a system that was rebooted 3 days ago is anomalous
• Unusual process path — any executable running from %TEMP%, AppData, or the Recycle Bin is suspicious

Network Connections from Memory

Injected Code Detection

Process injection is a technique used by malware and post-exploitation frameworks to execute code within the memory space of a legitimate process — hiding malicious activity behind a trusted process name. Memory forensics can detect injection even when the injected code is invisible to the OS.

malfind

The windows.malfind plugin identifies memory regions that are: executable (PAGE_EXECUTE_READWRITE or similar), not backed by a file on disk (private memory rather than memory-mapped from a legitimate DLL), and contain what appears to be executable code (PE headers or shellcode signatures).

Hollowed Processes

Process hollowing creates a legitimate process (e.g., svchost.exe), unmaps its memory, and replaces it with malicious code. The process appears legitimate in the process listing but is executing attacker code. Detection: compare the process's in-memory image against the on-disk version of the same executable using windows.dlllist and windows.dumpfiles; significant differences indicate hollowing.

Credential Extraction

Network forensics is the capture and analysis of network traffic to reconstruct communications, identify attack vectors, and recover transmitted content. Its fundamental challenge is the opposite of disk forensics: disk artefacts persist and must be collected before they are overwritten; network traffic is ephemeral and must be captured at the moment it occurs — or not at all. This places a premium on pre-positioned capture infrastructure and rapid response to activate capture when an incident is detected.

PCAP Fundamentals

A PCAP (Packet Capture) file contains a timestamped record of all network packets observed at a capture point. Full-packet capture (also called "full content" capture) preserves the complete payload of every packet — including the data being transmitted. This is the most forensically complete form of network evidence but also the most storage-intensive.

Capture points determine what traffic is visible:

• Network TAP (Test Access Point) — a hardware device that passively copies traffic from a network link without affecting the link. The gold standard for network forensics — captures everything without introducing latency or failure risk.
• SPAN/mirror port — a switch feature that copies traffic from one or more ports/VLANs to a designated monitoring port. Common and flexible but can miss packets under high load.
• Endpoint capture — running Wireshark or tcpdump on the affected system itself. Captures only traffic to and from that endpoint. The capturing process modifies the system (relevant to Locard) but is often the only option after the fact.
• Network IDS/IPS sensors — if inline IDS is deployed, it may have captured (or logged metadata about) the traffic of interest.

Wireshark in Depth

Wireshark is the standard tool for interactive PCAP analysis. Its GUI provides protocol dissection, stream reconstruction, and export capabilities that make network forensics accessible. Key analytical techniques:

Display Filters

Following Streams

Right-click any packet → Follow → TCP Stream (or UDP Stream, HTTP Stream, TLS Stream) reconstructs the complete conversation in human-readable form. For unencrypted protocols, this reveals the full content of the communication — credentials transmitted in cleartext, commands sent to a remote shell, files transferred over HTTP.

Export Objects

Wireshark can reconstruct and export files transmitted over HTTP, FTP, SMB, TFTP, and DICOM. File → Export Objects → HTTP shows all HTTP objects in the capture and allows selective or bulk export. Exported files can then be hashed and submitted to VirusTotal or analysed in a sandbox.

NetFlow and Traffic Metadata

Full packet capture is storage-intensive — a 1Gbps link at full utilisation generates roughly 450GB of PCAP per hour. For large enterprise networks, continuous full-packet capture at perimeter is impractical. NetFlow (Cisco's protocol, widely standardised as IPFIX) provides traffic metadata — the "who talked to whom, when, for how long, how much" — at a fraction of the storage cost.

A NetFlow record contains: source and destination IP and port, protocol, start and end time, byte count, packet count, and TCP flags. No payload data. Despite the absence of payload, NetFlow is extremely powerful for:

• Lateral movement detection — unusual SMB connections between workstations, SSH from unexpected sources
• Data exfiltration scoping — identifying large outbound transfers to external IPs
• C2 beacon pattern identification — periodic connections with consistent byte counts and intervals
• Scope reconstruction — determining which internal hosts communicated with the identified C2 infrastructure

DNS Forensics

DNS logs — query logs recording every domain name resolution attempted by every host — are among the most valuable and underutilised network forensic data sources. Almost every network attack involving an external component uses DNS: C2 beacons resolve their C2 hostname, exfiltration tools look up cloud storage endpoints, phishing sites are reached by DNS resolution, and malware dropper URLs are resolved before download.

DNS Tunnelling Detection

DNS tunnelling encodes data in DNS query subdomains. To detect it in DNS logs:

• High-entropy subdomain labels — legitimate subdomains are human-readable; tunnelled subdomains are base32/base64 encoded data (d2hvd3dhc3RoYXQ.evil.com)
• Unusual query volume — a single host making hundreds of DNS queries per minute to the same domain
• Unusual record types — TXT, NULL, and MX record queries are sometimes used for tunnelling
• Query length distribution — tunnelled subdomains are often much longer than normal (50+ characters per label)

DGA (Domain Generation Algorithm) Detection

Malware families using DGAs generate large numbers of pseudo-random domain names daily, connecting only to the one that resolves (which the attacker has registered). In DNS logs, DGA activity appears as: many NXDOMAIN (non-existent domain) responses followed by one successful resolution. The successful domain is the active C2.

TLS and Encrypted Traffic Analysis

The majority of modern network traffic is TLS-encrypted, which means payload data is not directly readable in PCAP. However, significant forensic value remains:

• SNI (Server Name Indication) — the TLS ClientHello contains the target domain name in plaintext, even for HTTPS traffic. Extracting SNI from a PCAP reveals which domains a host was communicating with, even without decryption.
• Certificate analysis — the server certificate exchanged during the TLS handshake is visible in plaintext. Certificate subject, issuer, validity period, and Subject Alternative Names reveal information about the server. Self-signed certificates or certificates with suspicious subjects are red flags.
• JA3 fingerprinting — JA3 hashes a combination of TLS ClientHello parameters (cipher suites, extensions, elliptic curves) to produce a fingerprint of the TLS implementation. Different software (browsers, malware frameworks, legitimate tools) produces different JA3 hashes. Cobalt Strike, for example, has a known default JA3 hash that appears in captures of Cobalt Strike C2 traffic.
• Traffic pattern analysis — timing, packet sizes, and connection patterns of encrypted traffic can reveal beaconing even without decryption. A process making a TLS connection to the same IP every 60 seconds, transferring ~200 bytes each time, is a beacon regardless of what the payload contains.

Disk forensics is the original discipline from which everything else in digital forensics grew. Before there were mobile devices, cloud infrastructure, or memory forensics frameworks, there were hard drives — and the methodology developed to forensically image and analyse them established the principles that govern the entire field. This chapter covers imaging methodology, format selection, and the increasingly important complications introduced by modern solid-state storage.

Storage Device Types and Their Forensic Implications

Not all storage devices behave the same way forensically. Understanding the underlying technology determines what evidence can be recovered and how:

• HDD (Hard Disk Drive) — spinning platter storage. Data is written to physical sectors; deleted data persists until those sectors are physically overwritten by new data. No internal mechanisms that zero data on deletion. The most forensically permissive storage type — deleted file recovery is highly reliable on an HDD that has not been heavily written since deletion.
• SSD (Solid State Drive) — NAND flash storage with a controller. The TRIM command (issued by the OS when files are deleted) instructs the controller to zero out the corresponding NAND pages asynchronously. TRIM dramatically reduces deleted file recovery success. Additionally, wear levelling means the physical location of data shifts over time — logical-to-physical mapping is controlled by the drive's internal firmware, not the forensic examiner.
• NVMe — the interface protocol used by the fastest SSDs. Same forensic characteristics as SATA SSDs; TRIM applies.
• USB Flash Drives — similar to SSDs but typically without TRIM support, making deleted file recovery more reliable than on SSDs. Controllers vary widely; some drives remap sectors in ways that complicate forensic imaging.
• eMMC (embedded MMC) — found in tablets, Chromebooks, and lower-end laptops. Soldered directly to the motherboard; removal for forensic imaging requires chip-off techniques (desoldering and reading the NAND directly) or JTAG access.

Hardware Write Blockers

Hardware write blockers are passive devices that sit between the evidence drive and the forensic workstation. They allow read commands to pass through normally while intercepting and discarding any write commands. This ensures zero modification of the evidence drive during imaging.

Selection criteria for write blockers:

• Interface support — does it support the drive's interface? SATA, IDE, USB 3.0, NVMe/M.2, SD card, and CF card each require different adapters or dedicated write blocker models.
• Speed — write blocker throughput should not be the bottleneck. Modern write blockers support USB 3.2 Gen 2 (20Gbps) and PCIe NVMe passthrough for fast acquisition.
• Validation — the write blocker should be validated against the NIST Computer Forensics Tool Testing (CFTT) programme.

Major manufacturers: Tableau (Cellebrite T8u USB 3.0, T356789iu multi-interface), WiebeTech / CRU (Forensic ComboDock), Logicube.

FTK Imager in Depth

FTK Imager (AccessData, free) is the most widely used Windows forensic imaging tool. It can image physical drives, logical drives, memory, and individual files/folders, and supports E01, DD, AFF, and other formats.

Command-Line Imaging — dd, dcfldd, dc3dd

On Linux/Mac (and via Windows Subsystem for Linux), command-line tools provide flexible imaging with scriptable verification:

Image Formats Compared

SSD Forensics Complications

The TRIM command fundamentally changes deleted file recovery on SSDs. When the OS deletes a file on an SSD with TRIM enabled (the default on Windows, macOS, and most Linux distributions), it issues a TRIM command to the drive controller, which marks the corresponding NAND pages for zeroing. The controller zeros these pages asynchronously — often within seconds to minutes on an idle drive.

Practical implications for forensic investigators:

• Power off immediately — if a live SSD is in an incident and deleted file recovery may be needed, power off the device as quickly as possible (without formal shutdown, which triggers more writes). An idle SSD running TRIM in the background can zero deleted data faster than you can image it.
• TRIM may already have run — on a drive seized hours after deletion, assume TRIM has executed and deleted file recovery may be impossible. Adjust investigation strategy accordingly.
• Wear levelling — the SSD controller remaps logical sectors to different physical NAND pages over time to distribute wear. This means the same logical sector address may point to different physical locations over the drive's lifetime, and previously written data may persist at physical locations that are no longer mapped to any logical sector — potentially recoverable with specialised chip-off or vendor-assisted techniques.
• Vendor and model matters — TRIM implementation and aggressiveness varies by SSD firmware. Some enterprise SSDs have different TRIM behaviour than consumer models. Researching the specific drive model before forensic acquisition is worthwhile.

Mobile devices are increasingly the primary digital evidence source in investigations ranging from corporate insider threats to criminal proceedings. They contain location history, communications, app usage data, and credential stores that provide a uniquely intimate record of human behaviour. They are also among the most technically challenging devices to examine — encryption is strong, extraction methods vary by device and OS version, and manufacturer and carrier variations create a fragmented landscape that requires specialised tooling and ongoing training.

Extraction Types

Mobile forensics distinguishes several extraction types, ordered from least to most invasive and from least to most complete:

iOS Forensics

iOS is designed with forensics in mind — but from the user's perspective, not the investigator's. Apple's hardware encryption (the Secure Enclave, hardware AES encryption tied to the device UID key) makes physical acquisition of a locked iPhone effectively impossible without the passcode. The investigator's approach is therefore largely shaped by whether the device is locked and whether the passcode is known.

iTunes/Finder backups are the most accessible source of iOS data without jailbreaking. An unencrypted backup contains messages, call logs, contacts, photos, app data for most applications, and location data. An encrypted backup additionally contains keychain items (saved passwords). Creating a backup over USB using the target computer (which may already have a trust relationship with the device) avoids any modification to the device itself.

GrayKey (Grayshift) and Cellebrite Premium provide law enforcement with passcode extraction capability for certain iOS versions by exploiting bootloader or OS vulnerabilities. These capabilities are version-specific — there is an ongoing cat-and-mouse between Apple's patching and extraction tool updates. Most corporate forensic examiners do not have access to these tools; they are primarily law enforcement capabilities.

iCloud backups and iCloud Drive data may be accessible with the user's Apple ID credentials or through legal process. iCloud backups contain similar data to local iTunes backups. iCloud Drive contains files the user has explicitly synced. Apple provides law enforcement with iCloud data in response to valid legal process.

Android Forensics

Android's open architecture and extreme device fragmentation create both more flexibility and more complexity than iOS. Extraction methods vary by manufacturer, Android version, and whether the device has been rooted.

ADB (Android Debug Bridge) — the primary developer interface for Android. With USB debugging enabled and the device unlocked, ADB provides access to device data and can perform logical backups. Without root, the backup is limited to apps that permit backup. With root, full filesystem access is available.

EDL (Emergency Download Mode) — a low-level Qualcomm chipset mode that provides direct flash memory access, bypassing Android's security model. Requires device-specific EDL credentials (which forensic tool vendors obtain through various means) but provides physical-level acquisition on many Android devices using Qualcomm SoCs.

Mobile Forensic Tools

• Cellebrite UFED — the dominant commercial mobile forensics platform. Hardware device with software companion (Physical Analyzer). Supports hundreds of device models, multiple extraction types, and automated parsing of app artefacts.
• Oxygen Forensic Detective — strong app artefact parsing, cloud account extraction, and drone forensics. Popular in corporate and insurance investigation contexts.
• Magnet AXIOM — multi-platform (mobile + computer + cloud) unified forensics platform. Strong for investigations spanning multiple device types.
• iLEAPP / ALEAPP — open-source iOS and Android artifact parsers. Free, actively maintained, and excellent for specific artefact categories.

Key App Artefacts

Messaging apps store evidence in local databases that can be extracted and analysed:

• WhatsApp — messages in msgstore.db (Android), encrypted with a device-specific key stored locally. Contact information and media metadata in additional databases.
• Signal — designed to resist forensic extraction. Messages encrypted in the local database with a passphrase; cloud backup disabled by default. Physical acquisition of a rooted device with the passphrase may recover messages.
• iMessage / SMS — stored in sms.db on iOS in the backup. Includes message content, timestamps, and contact information for both SMS and iMessage conversations.
• Location data — iOS stores significant location history in cache.db and in the KnowledgeC database. Android stores location history in Google account data (Google Timeline) and in-app location databases.

Legal Considerations — Compelled Decryption

The Fifth Amendment (US) protects against compelled self-incrimination. Courts have reached inconsistent conclusions on whether compelling a defendant to provide their device passcode constitutes testimonial self-incrimination protected by the Fifth Amendment — or whether it is merely a physical act (like providing a physical key) not protected by the Fifth. The law in this area is unsettled and evolving, varies by jurisdiction, and must be navigated with legal counsel.

Malware forensics is the sub-discipline that most closely bridges incident response and digital forensics. When a malicious file is recovered during a forensic investigation, analysis of that file can reveal: how the attacker got in, what the malware was designed to do, what data may have been exfiltrated, and whether other samples from the same campaign are present elsewhere in the environment. This chapter covers the analytical workflow — from initial static examination through dynamic behavioural analysis — and the YARA rules that translate those findings into detection capability.

The Analysis Workflow

Malware analysis follows a deliberate sequence designed to gather progressively deeper information while controlling risk:

1. Triaging — quick initial classification: is this file actually malicious? What type of file is it? Is it packed? Answers from hashing, VirusTotal, and basic static checks.
2. Static analysis — examining the file without executing it. Strings, imports, PE structure, embedded resources, entropy analysis.
3. Dynamic analysis — executing the file in a controlled (sandboxed) environment and observing behaviour: process creation, file writes, registry modifications, network connections.
4. Advanced static analysis — disassembly and decompilation of the binary code to understand logic that was not revealed by strings or behaviour.
5. Reporting and detection — documenting findings and writing YARA rules, network signatures, and detection content based on the analysis.

For most incident response scenarios, triage through dynamic analysis (steps 1–3) is sufficient. Advanced static analysis (step 4) requires reverse engineering skills that are a separate specialisation; it is typically reserved for novel, high-priority malware families.

Static Analysis

File Identification and Hashing

Before analysis, establish the file's identity:

PE File Structure

Most Windows malware is a Portable Executable (PE) file — the standard Windows binary format. Understanding PE structure allows rapid assessment of a file's capabilities without execution:

• DOS Header and stub — every PE begins with the ASCII bytes MZ (4D 5A). This is the universal PE file signature. A file masquerading as a PDF or image that begins with MZ is actually an executable.
• PE Header — machine type (x86 vs x64), compilation timestamp (useful for attribution but easily manipulated), number of sections
• Section headers — .text (code), .data (initialised data), .rdata (read-only data, strings, imports), .rsrc (resources). Sections with unusual names or unusual combinations of executable + writable permissions indicate packed or modified code.
• Import Address Table (IAT) — lists the DLLs and functions the executable imports. The imports reveal capabilities: CreateRemoteThread + VirtualAllocEx + WriteProcessMemory = process injection; CryptEncrypt + FindFirstFile + MoveFileExA = ransomware; WSAStartup + connect + recv = network capability.

Strings Analysis

The strings tool (Linux) or Strings (Sysinternals, Windows) extracts printable character sequences from a binary file. Even from an unexecuted file, strings often reveal: C2 domain names and IP addresses, file paths, registry keys, mutex names, error messages (which may include debugging information left by the developer), and configuration data.

Entropy Analysis

High entropy in a PE section indicates encrypted or compressed data — a characteristic of packed malware. Legitimate executables typically have entropy below 7.0 in their code sections; packed malware often has entropy of 7.5–8.0 in sections that contain the compressed payload. Tools like PEiD, Detect-It-Easy (DIE), and pestudio visualise per-section entropy and identify common packer signatures.

Dynamic Analysis

Dynamic analysis executes the malware in a controlled environment and observes its behaviour. The standard approach uses a sandboxed virtual machine with monitoring tools pre-installed. The VM must be isolated from the production network but may need simulated internet connectivity (INetSim or FakeDNS) to allow C2 callbacks that would otherwise fail and affect behaviour.

Core Monitoring Tools (FlareVM / REMnux)

Automated Sandboxes

For rapid triage, online sandboxes provide automated dynamic analysis without setting up a local environment:

• Any.run — interactive sandbox; watch malware execute in real time in a browser
• VirusTotal / Files → Behaviour — automated behaviour analysis for submitted files
• Cuckoo Sandbox — self-hosted automated analysis; configure multiple analysis VMs for different OS versions
• CAPE Sandbox — Cuckoo fork with enhanced capability for unpacking and config extraction

Caution: do not submit sensitive or classified samples to public online sandboxes. All public sandbox services retain submitted files and make them accessible to other users. Use a private Cuckoo deployment for sensitive samples.

YARA Rules

YARA is a pattern-matching tool and rule language designed to describe and identify malware samples based on textual or binary patterns. A YARA rule consists of: a rule name, metadata, string definitions, and a condition that specifies when the strings constitute a match.

rule CobaltStrike_Beacon {
  meta:
    author = "Analyst"
    description = "Detects CobaltStrike beacon shellcode"
    date = "2024-01-15"
  strings:
    $s1 = "ReflectiveLoader" ascii
    $s2 = { 4D 5A 90 00 03 00 00 00 }  // MZ PE header
    $s3 = "/C ping -n 1 -w 3000" ascii wide
    $sleep = "sleep" ascii fullword
  condition:
    $s1 and ($s2 or $s3) and $sleep
}

Anti-Analysis Techniques

Malware authors are aware that their code will be analysed and take countermeasures. Recognising these techniques is essential for understanding why analysis is producing unexpected results:

• Packing / obfuscation — compressing or encrypting the malware payload. The outer layer (stub) decompresses/decrypts and executes the real payload in memory. Most commercial packers (UPX, Themida, VMProtect) and custom packers are detectable by entropy analysis and packer signatures.
• VM detection — checking for VM artefacts: VMware registry keys, virtualisation-specific device names, CPUID responses, timing differences between physical and virtual hardware. If a VM is detected, the malware may terminate, behave differently, or drop a benign payload.
• Anti-debugging — detecting the presence of a debugger via IsDebuggerPresent(), CheckRemoteDebuggerPresent(), and more sophisticated timing and exception-based checks. Anti-debugging causes the malware to terminate or change behaviour when a debugger is attached.
• Sleep calls — malware that sleeps for long periods during sandbox execution to outlast the sandbox timeout. Sandboxes typically run samples for 60–120 seconds; malware that sleeps for 5+ minutes will not display its full behaviour.
• Environment checks — checking username, computer name, domain membership, or the number of running processes. Sandboxes often have no domain, a small number of processes, and generic machine names — checks that fail these conditions indicate a non-enterprise environment and trigger evasion.

Fileless Malware Forensics

Fileless malware executes entirely in memory — no executable file is written to disk. Common fileless techniques: PowerShell or WMI executing base64-encoded payloads from the Registry or directly from a command line; process injection into a legitimate process; reflective DLL loading that maps a DLL into memory without writing it to disk.

Forensic recovery of fileless malware evidence:

• Memory dumps — the primary source. Volatility's malfind and dlllist plugins identify injected code. Dumped memory regions can be analysed with static analysis tools or submitted to sandboxes.
• Event ID 4104 (PowerShell Script Block Logging) — if enabled, records the full content of PowerShell script blocks before they execute, including deobfuscated content. This captures fileless PowerShell stages even when no script file was written to disk.
• Registry artefacts — fileless malware often stores its payload in the Registry (Run keys, COM object registration, WMI subscriptions). Registry forensics may recover the payload even after the process has terminated.
• Process creation logs — Event ID 4688 with command-line logging captures the obfuscated PowerShell or WMI command that launched the fileless payload.

Cloud forensics is one of the fastest-evolving areas of the discipline — and one where practitioners trained exclusively on traditional endpoint and network forensics frequently struggle. The absence of physical media, the shared infrastructure model, ephemeral compute, and the provider's control over underlying infrastructure require a fundamental shift in both methodology and tooling. This chapter covers the practical approach to forensics across major cloud platforms and the SaaS applications that run on them.

How Cloud Forensics Differs

Traditional forensics: the examiner physically accesses the device, applies a write blocker, images the storage media, and analyses the image. The entire process is under the examiner's control.

Cloud forensics: the examiner has no access to physical hardware, cannot image underlying storage media, is dependent on the provider's logging infrastructure for evidence, and is working with ephemeral resources that may have been terminated before the investigation begins. The provider controls the evidence.

This shifts the forensic approach from evidence collection from media to evidence collection from APIs and logs. The quality of a cloud forensic investigation is directly proportional to the quality of the logging configuration — which, in most cloud environments, is not enabled comprehensively by default.

AWS Forensics

CloudTrail — The Control Plane Log

AWS CloudTrail records every API call made to AWS services — who called what, from where, with what parameters, at what time. It is the single most important evidence source for AWS forensic investigations.

fields @timestamp, eventName, sourceIPAddress, userAgent
| filter userIdentity.arn like "arn:aws:iam::123456789:user/compromised-user"
| filter @timestamp between 1704067200000 and 1704153600000
| sort @timestamp asc

fields @timestamp, sourceIPAddress, userIdentity.userName
| filter eventName = "ConsoleLogin"
| sort @timestamp desc

fields @timestamp, sourceIPAddress, requestParameters.bucketName, requestParameters.key
| filter eventName = "GetObject"
| sort @timestamp desc

EC2 Instance Forensics

Forensically examining a running EC2 instance can be done in several ways:

• EBS snapshot acquisition — take a snapshot of the instance's EBS volumes, create a new volume from the snapshot, and attach it to a separate forensic EC2 instance for examination. This provides a point-in-time disk image without affecting the running instance. The forensic instance can run Autopsy, Sleuth Kit, or other tools to analyse the volume.
• SSM Session Manager — AWS Systems Manager provides a browser-based or CLI shell to EC2 instances without SSH. Useful for live response commands (process listing, memory collection, network state) when SSH access is not available or has been disabled as a containment measure.
• Memory acquisition on EC2 — acquire RAM using WinPmem or LiME on the running instance, then upload the dump to S3 for analysis. Note that this writes to the instance's local storage — document this as forensic contamination.

GuardDuty

AWS GuardDuty is a managed threat detection service that analyses CloudTrail, VPC Flow Logs, and DNS logs for threat indicators. GuardDuty findings are pre-mapped to ATT&CK techniques and provide a starting point for investigation. Key forensic value: GuardDuty may identify threats that occurred before the investigation began — its findings can extend the investigation timeline backwards.

Azure Forensics

Azure disk snapshot for VM forensics: create a managed disk snapshot via the portal or CLI, export it to a storage account as a VHD, download and mount the VHD for offline analysis.

Microsoft 365 Forensics

Microsoft 365 is the most widely used SaaS platform in enterprise environments and a frequent target in business email compromise, insider threat, and data exfiltration investigations. The primary forensic data source is the Unified Audit Log (UAL).

The UAL records user and admin activities across Exchange Online, SharePoint, OneDrive, Teams, and Azure AD. It must be explicitly enabled (not on by default in all tenants) and is retained for 90 days for E3 plans, 365 days for E5 plans. The retention cliff at 90/365 days is a common discovery that prevents full reconstruction of incidents with long dwell times.

Search-UnifiedAuditLog -StartDate "2024-01-01" -EndDate "2024-01-15" 
-UserIds "[email protected]" -ResultSize 5000

Search-UnifiedAuditLog -Operations "Set-InboxRule","New-InboxRule" 
-StartDate "2024-01-01" -EndDate "2024-01-15"

Search-UnifiedAuditLog -RecordType SharePointFileOperation 
-Operations FileAccessed,FileDownloaded -StartDate "2024-01-01" -EndDate "2024-01-15"

Container and Kubernetes Forensics

Container workloads introduce ephemeral forensic challenges. A compromised container may be terminated and replaced within seconds, destroying all in-container evidence. The forensic approach for containers:

• Do not terminate the suspect container — pause it (docker pause [container]) or preserve it with docker commit to create an image before it exits
• Container filesystem — docker export [container] > container.tar captures the complete container filesystem as a tarball for offline analysis
• Kubernetes audit logs — API server audit logs record every kubectl action, pod creation, and RBAC-related activity. Enable with --audit-log-path and an audit policy file.
• Falco — runtime security tool that generates alerts on suspicious container behaviour (shell spawned in container, sensitive file access, network connection from unexpected process)

Cross-Border Jurisdiction and Evidence Preservation

Cloud data may be physically stored in multiple jurisdictions simultaneously. This creates complications for both evidence collection (what legal process is required in each jurisdiction?) and data protection compliance (does collecting and moving this data violate GDPR or other data residency requirements?).

Practical guidance: issue a legal hold notice to the cloud provider as early as possible to preserve data before retention periods expire. Work with legal counsel to identify the correct legal process for each jurisdiction where evidence may reside. Document the geographic distribution of data before beginning collection.

Anti-forensics encompasses the techniques used to prevent, complicate, or mislead digital forensic investigation. Understanding these techniques is essential for practitioners: you must know what attackers do to cover their tracks, why those techniques sometimes work, and — critically — the forensic artefacts that anti-forensic activities themselves leave behind. The fundamental truth that most practitioners eventually discover is this: attempting to hide evidence usually creates new evidence.

Timestomping

Timestomping is the deliberate modification of file timestamps to mislead timeline analysis. An attacker may change the timestamps of a malicious file to match the timestamps of benign system files, making it appear to have existed long before the attack — or to predate the organisation's log retention window.

Detection: As covered in Chapter 4, NTFS maintains two sets of timestamps — $STANDARD_INFORMATION (modifiable from user space) and $FILE_NAME (kernel-set, significantly harder to modify). When a file's $STANDARD_INFORMATION timestamps differ significantly from its $FILE_NAME timestamps, timestomping is indicated. Additionally, the $UsnJrnl change journal records the actual time of file system operations — including the metadata change that occurred when timestamps were modified.

Secure Deletion

Standard file deletion does not overwrite data — it only removes filesystem pointers. Secure deletion tools overwrite the file's data before deletion, preventing recovery. Common tools:

• sdelete (Sysinternals) — overwrites file data with zero passes, random passes, or DoD 5220.22-M standard overwrite pattern before deletion. Leaves artefacts: Prefetch, Event Logs, and the $UsnJrnl record the execution of sdelete.
• Eraser — Windows GUI secure deletion tool. Same artefacts as sdelete.
• shred / wipe (Linux) — command-line secure deletion. Effective on HDDs; partially effective on SSDs (due to wear levelling, different physical pages than the logical address may not be overwritten).

Forensic limitation: secure deletion of individual files is less effective than it appears because: (1) the filesystem may have retained the file's data in $LogFile, VSS snapshots, or SIEM logs before deletion; (2) file carving from unallocated space may not recover the file but may recover slack from adjacent clusters; (3) the act of running a secure deletion tool leaves artefacts — Prefetch, UserAssist, Event Logs — that prove something was being hidden.

Full-Disk Encryption

Full-disk encryption (FDE) — BitLocker, FileVault, LUKS — is legitimate and recommended security practice, but it presents a real challenge for forensic investigations when the decryption key is unavailable.

Avenues for accessing an FDE-protected drive:

• Recovery key — BitLocker recovery keys are often stored in Active Directory (corporate), Microsoft Account (consumer), or a printout. Azure AD stores BitLocker keys for Intune-enrolled devices.
• Memory acquisition — the decryption key is held in RAM while the volume is mounted. A live memory dump (Chapter 7) from a running system with the volume mounted may allow key recovery. Volatility plugins (Bitlocker plugin, AESKeyFinder) search for key material in memory dumps.
• TPM cold boot — extremely rare; applicable to specific older configurations.
• Legal compulsion — depending on jurisdiction and the Fifth Amendment considerations discussed in Chapter 10, decryption keys may be compelled via court order.

Living-Off-the-Land (LOLBIN) Techniques

Living-off-the-land attackers use built-in OS binaries and scripting environments rather than custom malware — exploiting tools that are present on every Windows or Linux installation and that generate less obvious forensic evidence than third-party tools.

Common Windows LOLBINs and their forensic traces:

Steganography

Steganography hides data within other files — most commonly images or audio files — in ways that are invisible to casual inspection. A JPEG file can contain a hidden archive, encryption keys, or C2 command instructions embedded in the pixel data or EXIF metadata. Detection requires specialised tools (StegSpy, SteghideDetect) or statistical analysis of file entropy and pixel distribution anomalies.

In practice, steganography is an uncommon forensic finding outside of nation-state and sophisticated cybercrime investigations. When encountered, it typically indicates a level of operational security sophistication that should prompt reassessment of the investigation's scope.

The finest forensic analysis in the world has zero practical value if it cannot be communicated effectively to its audience. Forensic reports and expert testimony are the mechanisms by which technical findings become legal decisions, corporate policy changes, criminal convictions, or civil judgments. The skills required to produce them are distinct from the skills required to conduct the analysis — and equally important.

The Forensic Report Structure

A complete forensic examination report typically contains the following sections:

1. Cover page and executive summary — case name/number, examiner details, date, and a non-technical summary of findings and conclusions. The executive summary is written last but read first. It must be comprehensible to a judge, juror, HR director, or senior executive with no technical background. Findings stated in plain language. Conclusions stated explicitly and without hedging.
2. Scope and objectives — what questions was the examination designed to answer? What was in scope? What was explicitly out of scope? Defining scope protects against scope creep challenges in court.
3. Methodology — what processes, tools, and versions were used? In what sequence? This section must be detailed enough that another qualified examiner could follow the same steps. Tool versions matter — the same tool name may produce different results across versions.
4. Evidence examined — a list of every item of evidence examined, with its unique identifier, description, hash values, and chain of custody reference.
5. Findings — what was found? Each finding presented separately, with the artefact location, the tool and method used to identify it, and the raw data (log line, hex dump, screenshot) supporting it. Findings are factual — they describe what was observed, not what it means.
6. Analysis and conclusions — what do the findings mean? This section contains the examiner's interpretation, expert opinion, and conclusions. Distinguish clearly between facts (what was found) and opinions (what the examiner believes the facts mean).
7. Limitations — what could not be determined? What evidence was unavailable, corrupt, or incomplete? What alternative explanations exist for the findings? Honest acknowledgement of limitations strengthens rather than weakens a report — it demonstrates the examiner's objectivity.
8. Appendices — raw output, tool logs, hash verification reports, timeline exports, and any other supporting material too detailed to include in the main report body.

Writing for Non-Technical Audiences

Most forensic reports will be read — and judged — by people who are not technical. Judges, jurors, HR directors, insurance adjusters, and executives are the primary audiences for forensic conclusions. Technical prose written for a peer audience will confuse and alienate these readers.

Practical writing guidance:

• Define every technical term on first use — do not assume the reader knows what NTFS, MFT, Prefetch, or NTLM mean
• Use analogy — "the Prefetch file is similar to the 'Recently Used' list in an office application — it records that the program ran and when" is more useful than a technically precise description for a non-technical reader
• State conclusions explicitly — "Based on the above evidence, I conclude that User X executed the file malware.exe at 14:32:07 UTC on 15 January 2024 from the system's local C: drive" is a conclusion. "The evidence may potentially suggest some possible connection between User X and malware.exe" is not.
• Use consistent terminology — choose one term for each concept and use it throughout the report. Alternating between "the suspect," "the user," "the employee," and "John Smith" creates ambiguity.

Expert Testimony

When a forensic report is used in legal proceedings, the examiner may be called to testify as an expert witness. This is a skill that requires preparation and practice — being technically competent does not automatically make one a good witness.

Direct examination — the side that retained you asks questions designed to elicit your methodology and findings. Speak clearly, avoid jargon, use analogies, and pause between question and answer. Do not volunteer information beyond what was asked.

Cross-examination — opposing counsel's goal is to undermine your methodology, your qualifications, or your conclusions. Common attacks: challenging tool reliability, proposing alternative explanations for findings, questioning whether you considered exculpatory evidence, suggesting bias based on who retained you. Responses to these challenges must be calm, factual, and grounded in your methodology.

Key principles for testimony:

• Say "I don't know" or "I cannot determine that from the evidence" rather than speculating beyond your findings
• Correct any mischaracterisation of your testimony immediately and politely
• Distinguish consistently between what you found (fact) and what you concluded (opinion)
• Do not change your opinion under pressure — if opposing counsel proposes an alternative explanation, evaluate it fairly; if it is not supported by the evidence, say so clearly

Confirmation Bias and Objectivity

Confirmation bias — the tendency to search for, interpret, and remember information in a way that confirms pre-existing beliefs — is the most dangerous cognitive error in forensic practice. An examiner who begins an investigation believing the suspect is guilty will unconsciously interpret ambiguous evidence against the suspect, assign less weight to exculpatory findings, and stop investigating once a confirming narrative is established.

Structural countermeasures:

• Hypothesis testing — formulate alternative hypotheses before examining evidence and actively look for evidence that would support each one, not just the primary hypothesis
• Peer review — have a colleague review findings and conclusions before finalising the report. The reviewer should have access to the evidence and the methodology, not just the draft report.
• Document exculpatory evidence — explicitly note evidence that does not support the primary hypothesis. An examiner who mentions only incriminating evidence is not being objective.

Reproducibility

A forensic finding is scientifically valid only if it is reproducible — another qualified examiner, given the same evidence and the same methodology, must be able to reach the same conclusion. This standard governs every aspect of forensic practice: tool selection, documentation discipline, methodology description, and conclusion drafting.

In practice, reproducibility is tested by: opposing parties commissioning their own forensic examination of the same evidence; defence experts reviewing the prosecution's forensic methodology; and regulatory bodies auditing practitioner certifications and methodologies. A forensic practitioner whose work cannot survive this scrutiny is not practising forensics — they are practising advocacy in a forensic costume.

Digital forensics is a discipline learned through practice far more than through reading. This final chapter provides the practical scaffolding for putting everything in this module to use: the tools that professional examiners reach for, the environments where you can practise legally and safely, the certifications that structure skill development and are recognised by employers, and the community resources that will keep your knowledge current long after this module is complete.

The Forensic Analyst's Toolkit

Open Source Tools

Commercial Platforms

• Magnet AXIOM — leading multi-platform commercial forensics suite. Unified computer, mobile, and cloud analysis with automated artefact parsing and AI-assisted analysis.
• Cellebrite Digital Collector / UFED — dominant mobile forensics platform, expanding into enterprise endpoint forensics.
• X-Ways Forensics — high-performance disk forensics tool favoured by forensic laboratories for its speed and precision on large-scale investigations.
• EnCase Forensic (OpenText) — long-standing enterprise forensics platform with strong case management and court-accepted workflow.

Setting Up a Forensic Workstation

SIFT Workstation

The SANS Investigative Forensics Toolkit (SIFT) is a free, open-source Linux distribution pre-configured with a comprehensive forensic toolset. Built on Ubuntu, it includes Volatility, Autopsy, Sleuth Kit, log2timeline/plaso, Eric Zimmerman's tools (via Wine), and dozens of other utilities. SIFT is the standard training environment for SANS forensics courses (FOR508, FOR572, FOR585) and is freely downloadable.

REMnux

REMnux is a Linux distribution specialised for malware analysis. It includes static analysis tools (PE analysis, disassembly), dynamic analysis tools (sandboxing support, process monitoring), network simulation (INetSim, FakeDNS), and reverse engineering tools. REMnux and SIFT can be co-installed on the same system.

FlareVM

FLARE VM is a Windows-based malware analysis environment maintained by Mandiant. It converts a Windows VM into a fully equipped malware analysis workstation: IDA Pro (community), Ghidra, x64dbg, dnSpy, PE-bear, Python/Jupyter for scripting, and hundreds of additional tools installed via Chocolatey.

Practice Environments

• NIST CFReDS (Computer Forensic Reference Data Sets) — a library of forensically prepared images with known content, maintained by NIST for tool testing and training. Excellent for validating that your tools and methodology produce correct results.
• CTF challenges — Capture-the-Flag competitions frequently include DFIR challenges. CyberDefenders, BlueTeamLabs Online, and HackTheBox's Sherlock category all provide forensics-focused challenges with realistic artefacts. These are the best free practice resource available.
• Magnet CTF — Magnet Forensics runs periodic CTF competitions with mobile and computer forensics challenges. Solutions are published afterwards with explanations.
• MemLabs — a GitHub repository of memory forensics CTF challenges specifically designed around Volatility analysis. Six progressively harder challenges from introduction to advanced.

Certifications

The DFIR Community

• Conferences: DFRWS (Digital Forensics Research Workshop) — peer-reviewed academic/practitioner conference; OSDFCon (Open Source Digital Forensics Conference) — open-source tools focused; SANS DFIR Summit — practitioner presentations.
• Blogs and research: Brian Carrier (TSK), Matt Suiche (memory forensics), Maxim Suhanov (Windows artefacts), DFIR.Science, About DFIR (Jessica Hyde).
• GitHub resources: Awesome DFIR repositories aggregate tool lists, challenge resources, and research. The EricZimmerman GitHub is essential for Windows forensics tooling.
• Discord communities: DFIR Discord, BlueTeamLabs, and CyberDefenders all have active DFIR channels where practitioners share findings, tools, and career guidance.