Digital Forensics and Incident Response

Chapter 7
Storage, File-System and Operating-System Forensics

Post Graduate Program in Cyber Security
Digital Forensics and Incident Response   •   Post Graduate

7. Storage, File-System and Operating-System Forensics

Introduction and Context

Digital evidence rarely exists as a single, clearly labelled file. It is distributed across storage media, file-system structures, operating-system databases, logs, memory-backed artefacts, application records and remnants of previously deleted information. A forensic examiner must therefore understand not only how to copy data, but also how the operating system stores, names, indexes, timestamps, protects and sometimes conceals it.

Storage and operating-system forensics addresses the examination of persistent media and the software environment that uses it. It supports investigations into unauthorised access, malware execution, insider activity, data theft, policy violations, intellectual-property loss and system compromise. The work connects closely with incident response: an incident responder may identify a suspicious host, while the forensic examiner reconstructs what occurred, when it occurred, which account or process was involved, and what evidence supports that conclusion.

The central difficulty is that digital artefacts have different evidential qualities. A file may be allocated, deleted, encrypted, compressed, fragmented or partially overwritten. A timestamp may reflect creation, modification, metadata change or access rather than the moment an event actually occurred. A log may record an authentication attempt without proving that a person physically operated the device. Sound forensic interpretation therefore requires technical knowledge, contextual reasoning, validation and disciplined documentation.

Learning Objectives

By the end of this chapter, students should be able to:

1. Explain how storage media and file systems represent files, metadata and deleted data.

2. Distinguish allocated, unallocated, slack, hidden and carved evidence.

3. Compare important forensic characteristics of NTFS, FAT-family, ext4 and APFS file systems.

4. Apply a defensible workflow for imaging, preserving and analysing storage evidence.

5. Interpret Windows, Linux and macOS artefacts, including logs, registries, processes, persistence locations and execution traces.

6. Correlate artefacts into timelines while accounting for clock errors, time zones and evidential limitations.

7. Evaluate common forensic mistakes, anti-forensic techniques, privacy concerns and emerging challenges.

The Storage Medium as an Evidential System

A storage device contains more than user-visible documents. At the physical or logical level it may contain partition tables, boot records, file-system metadata, allocated files, deleted records, unallocated sectors, recovery partitions, hibernation data, swap or page files, application caches and remnants of earlier installations. Solid-state drives introduce additional complexity because wear levelling, garbage collection and the TRIM command can make recovery less predictable than recovery from traditional magnetic disks.

A forensic acquisition should preserve the original evidence and create a verifiable working copy. Common acquisition forms include a physical image of addressable sectors, a logical collection of selected files, and a targeted collection of specific artefacts. Physical imaging offers the broadest opportunity for recovery, whereas logical acquisition may be appropriate when scope, authorisation, cloud architecture or operational constraints limit access. The choice must be justified rather than assumed.

Integrity is normally demonstrated through cryptographic hashes calculated during or after acquisition. A hash does not prove that the contents are truthful or that the device was not compromised before seizure; it demonstrates that the examined copy corresponds to the acquired data. Chain-of-custody records add information about who handled the evidence, when, for what purpose and under what conditions. Write blockers, controlled boot environments and documented tool versions reduce the risk of altering evidence.

How File Systems Represent Reality

A file system provides structures for naming, locating, allocating and protecting data. The visible directory tree is only an interpretation of those structures. A directory entry may remain after the file content has been removed; metadata may survive while content is overwritten; and a file may have multiple names or hard links that refer to the same underlying data.

Allocated, deleted and unallocated data

Allocated data is associated with an active file-system record. Deleted data is data whose active directory reference has been removed or marked inactive, although its content or metadata may remain. Unallocated space is storage not currently assigned to an active file. It can contain complete deleted files, fragments, previous versions, temporary content or random residual data. File slack is the unused portion of the final storage unit allocated to a file and may contain remnants from earlier use.

Deleted-file recovery is not equivalent to restoration. Recovery may depend on whether metadata remains, whether the file was fragmented, whether sectors were reused, whether encryption was involved and whether solid-state maintenance operations have altered the medium. A recovered file should be described precisely—for example, “partially recovered content from unallocated space”—rather than presented as an intact original when uncertainty exists.

Metadata and timestamps

File metadata can include names, sizes, ownership, permissions, location information, allocation status and timestamps. Investigators commonly distinguish timestamps for modification, access, metadata change and creation, although their availability and meaning differ between file systems and operating systems. Timestamps may be changed by copying, extraction, backup restoration, time synchronisation, application behaviour or an examiner’s own actions.

A useful timeline therefore combines file-system timestamps with independent artefacts such as authentication logs, browser records, process execution traces, email headers, network records and event logs. Time must be normalised with attention to UTC offsets, daylight-saving changes, clock drift and the difference between event time and recording time.

Hidden and alternative storage

Evidence may be hidden through ordinary attributes, unusual directory names, alternate data streams, sparse files, disk images, encrypted containers, nested archives or partitions not mounted by the operating system. Hiding alone does not establish malicious intent. An examiner should document how an item was identified, whether it was accessible to ordinary users and whether its content is relevant to the investigative question.

Major File Systems in Forensic Examination

NTFS

NTFS is the principal file system used by modern Windows systems. Its Master File Table (MFT) contains records describing files and directories. An MFT record may hold resident file content, timestamps, security information and references to non-resident data runs. NTFS also uses structures such as the USN Change Journal, which records changes to files and directories, and the Recycle Bin, which may preserve information about deleted user files.

NTFS supports alternate data streams, a feature that can store content associated with a file without appearing in its ordinary size or directory listing. Legitimate applications use streams in some circumstances, but attackers may abuse them to conceal payloads. Important Windows evidence may also exist outside NTFS itself, including the registry, event logs, prefetch data, shortcut files and user-profile artefacts.

The USN Journal is valuable for reconstructing file creation, modification, renaming and deletion activity, but it is not a complete audit trail. Journal retention is limited, records may be overwritten, and entries indicate file-system changes rather than necessarily identifying the human actor.

FAT and exFAT

FAT-family systems use allocation tables and directory entries that are comparatively simple and widely supported. They remain relevant for removable media, cameras and embedded devices. Deleted directory entries may preserve portions of names, while allocation chains can assist recovery. FAT systems generally provide a less rich security and journalling model than NTFS, so interpretation often relies on directory structures, timestamps, media context and corroborating operating-system artefacts.

ext4

ext4 is widely used on Linux. It uses inodes to store metadata and references to data blocks, with extents representing ranges of contiguous blocks. Journalling improves consistency after interruption but does not constitute a complete record of user activity. Relevant artefacts may include inode metadata, journal records, shell histories, system logs, authentication records, package databases, cron configuration and user-specific application files.

Linux permissions, ownership, symbolic links, hard links and extended attributes are important to interpretation. A file’s ownership does not by itself prove who created it, particularly where services, scheduled jobs or elevated privileges are involved. Deleted-file recovery may be affected by journalling, block reuse and solid-state behaviour.

APFS

APFS is used by current macOS systems and supports features such as containers, volumes, snapshots, copy-on-write metadata, encryption and space sharing. Copy-on-write design can preserve historical states in snapshots, but it also means that a conventional view of “the” disk may be incomplete. FileVault encryption, secure hardware, user authentication and key availability strongly affect acquisition and analysis.

macOS investigations commonly combine APFS information with Unified Logs, the EndpointSecurity or system security context, launch agents and daemons, property-list files, quarantine records, shell history, browser artefacts, application databases and user activity databases. Snapshot and volume relationships must be documented because an artefact may belong to a current volume, a snapshot or another volume in the same container.

A Defensible Forensic Workflow

A sound examination proceeds from preservation to interpretation. First, define authority, scope, investigative questions and the relevant time period. Identify devices, accounts, encryption conditions, volatile information and risks of remote alteration. If a live system is running, volatile evidence such as memory, active network connections, logged-on users and processes may be lost during shutdown; however, live collection can also alter the system. The decision must be risk-based and documented.

Next, preserve and acquire the evidence using validated procedures. Record device identifiers, acquisition method, tool and version, operator, start and end times, errors, hash values and storage conditions. Where possible, examine a verified copy rather than the original. Maintain separate working copies for different analytical tasks when necessary.

Analysis should begin with broad orientation: partitions, volumes, operating-system versions, user accounts, time settings, encryption status and major directories. The examiner then develops targeted hypotheses. For example, a suspected data-theft investigation may require correlation of removable-media connection records, file-system changes, archive creation, shell or application history, authentication events and network activity.

Interpretation should use multiple artefacts. A single timestamp or filename is weak evidence when isolated. Confidence increases when independent records agree, such as a process execution trace, a corresponding prefetch record, a registry entry showing a recently used file, and an event log showing the same account logged on during the relevant period. Contradictions must be retained and explained rather than silently discarded.

Finally, report methods, findings, limitations and confidence. The report should distinguish observations from interpretations and interpretations from conclusions. Reproducibility is strengthened by recording queries, tool settings, hash values, extracted artefacts and relevant screenshots or tables.

Operating-System Forensics

Windows artefacts

The Windows Registry is a hierarchical configuration database composed of hives such as SYSTEM, SOFTWARE, SECURITY, SAM and user-specific NTUSER.DAT files. Registry artefacts can reveal installed software, device history, user preferences, network configuration, recently accessed items and persistence locations. ShellBags may provide evidence of directory navigation, including some folders no longer present. UserAssist records can assist analysis of graphical application execution, although their interpretation depends on Windows version and user context.

Windows event logs, commonly stored in EVTX format, may record logons, account changes, service activity, process creation, scheduled tasks, PowerShell activity, policy changes and security events. Logging depends on configuration, retention and privileges. The absence of an event is not proof that the activity did not occur.

Execution traces may include Prefetch files, Windows Defender records, Amcache data, Shimcache and shortcut files. These artefacts have different meanings. Prefetch can support a conclusion that an executable was loaded on a system, but it does not necessarily prove who launched it or exactly how many times it ran. Amcache and Shimcache can provide evidence of program presence or compatibility processing, but should not be treated as interchangeable execution logs.

Persistence analysis examines services, scheduled tasks, startup folders, Run and RunOnce registry keys, WMI subscriptions, browser extensions, DLL search paths and other mechanisms. Investigation should identify the persistence location, the referenced executable or script, its creation or modification time, associated account, permissions and whether the mechanism is legitimate.

Linux artefacts

Linux evidence is distributed across system-wide and user-specific locations. Logs may be handled by systemd-journald, traditional syslog services or application-specific mechanisms. Authentication records such as those associated with successful and failed logins, sudo use, SSH access and account changes are particularly important. Their exact format and retention vary by distribution.

Shell histories, including Bash or Zsh history, can reveal commands, paths and administrative activity, but history is user-configurable, may be disabled, may omit commands and may be altered. It must therefore be corroborated with process accounting, audit records, file timestamps, package logs and network evidence.

Processes can be examined through live collection, process accounting, system logs and artefacts such as service definitions, cron entries, systemd units, SSH configuration, shell initialisation files and user-level autostart locations. Persistence may involve system services, timers, cron, modified profiles, kernel modules, LD_PRELOAD abuse, startup scripts or application-level mechanisms. Elevated execution through sudo or compromised service accounts complicates attribution.

macOS artefacts

macOS uses property-list files for many configuration and application settings. LaunchAgents and LaunchDaemons are important persistence locations; the former commonly operate in a user context, while the latter may operate with system privileges. Login items, shell configuration, cron entries, browser extensions and application-specific launch mechanisms should also be examined.

The Unified Logging system records many operating-system and application events, but collection and interpretation require attention to predicates, time ranges and retention. Quarantine metadata can show that a file originated from an external source and may record download-related information. Recent-items databases, Finder activity, browser history, shell history and application databases can help reconstruct user interaction.

macOS execution analysis may incorporate quarantine records, application metadata, code-signing information, Gatekeeper-related events, process observations and persistence artefacts. A valid signature does not guarantee that software is benign; it indicates a relationship to a signing identity and must be interpreted with provenance and behaviour.

Correlation, Timelines and Attribution

Timeline construction is a reasoning process rather than a sorting exercise. The examiner should identify the time basis of every artefact, convert times consistently, preserve original values and record uncertainty. A file modification time may indicate when content changed, while an event-log time may indicate when a system recorded an event. Network timestamps may be generated by a different clock altogether.

Attribution requires particular caution. An account name identifies a security principal, not necessarily a human being. Shared credentials, remote administration, malware, scheduled tasks, service accounts and virtual machines can all separate a recorded identity from the person who caused an action. Stronger attribution may arise when authentication, endpoint activity, network source, physical access and independent user-specific artefacts converge.

A useful analytical model is the event–artefact–hypothesis cycle. The examiner proposes a hypothesis, identifies artefacts expected if it were true, tests those artefacts, considers alternative explanations and updates the hypothesis. This approach limits confirmation bias and makes conclusions more transparent.

Applied Case: Investigating Suspected Data Exfiltration

Background

The following is an illustrative case. A financial-services organisation suspects that an employee copied a confidential customer database before leaving the company. The employee’s Windows workstation remains available for forensic examination, and the organisation has authorised collection of the workstation, relevant server logs and removable-device records.

Situation and problem

The allegation is based on a large archive appearing in a user directory shortly before resignation. Management wants to know whether the archive contained confidential data, whether it was copied to removable media, and whether the evidence supports attribution to the employee rather than to automated backup software or another user.

Analysis and approach

Investigators first document the system state, isolate the workstation according to incident-response procedures and acquire a verified forensic image. They identify the Windows version, time zone, user accounts, encryption status and connected storage devices. The analysis finds:

  • an archive file in the employee’s profile with creation and modification times within the relevant period;
  • NTFS metadata indicating subsequent movement of the archive and a deletion event recorded in available journal information;
  • a Windows event record showing the employee’s interactive logon during the relevant interval;
  • Prefetch and application artefacts consistent with execution of an archive utility;
  • a registry and operating-system record indicating connection of a removable storage device;
  • fragments of the archive and filenames in unallocated space;
  • no evidence that the organisation’s backup agent created or accessed the archive.

The archive itself is partially recovered. Its file listing includes database extracts, but portions of content are missing. The investigators compare the recovered filenames with server-side access logs and find that the employee’s account queried the corresponding data during the same period. They also identify a later network connection from the workstation to an external service, but cannot establish from endpoint evidence alone that the archive was uploaded.

Outcome

The evidence supports the conclusion that an archive containing names associated with confidential data was created and that an archive utility was executed while the employee was logged on. Removable-device artefacts support the possibility of copying, but the evidence is insufficient to state with certainty that the complete archive was transferred or uploaded. The report expresses these distinctions explicitly.

Learning points

The case demonstrates the value of correlation. No single artefact proves exfiltration. File-system metadata, execution traces, logon records, removable-device history, server logs and recovered fragments collectively establish a stronger account. It also illustrates why partial recovery should not be overstated and why attribution must separate account activity from absolute proof of human action.

Challenges, Risks and Common Mistakes

A frequent mistake is treating timestamps as unquestionable facts. Another is assuming that a deleted file is permanently gone or, conversely, that every deleted item can be fully recovered. Investigators may overlook alternate data streams, snapshots, mounted volumes, cloud-synchronisation folders, application databases or user-specific locations.

Tool output can create false confidence. Forensic tools implement parsers and interpretations that may differ across versions. Important findings should be validated through independent methods where practical, especially when conclusions depend on a specialised artefact. Anti-forensic behaviour—including timestamp manipulation, log clearing, secure deletion, encryption, file wiping, renamed utilities and living-off-the-land techniques—should be considered, but not asserted without evidence.

Modern storage creates additional constraints. SSD TRIM and garbage collection can reduce recoverability. Full-disk encryption may make a powered-off device inaccessible without keys, while live acquisition may expose volatile keys but alter the system. Virtual machines, containers, remote desktops and cloud-synchronised data distribute evidence across boundaries that a single disk image cannot represent.

Ethical, Legal and Governance Considerations

Forensic authority must be defined before collection. Investigators should follow applicable law, organisational policy, warrants, consent limits, contractual obligations and privacy requirements. Personal data unrelated to the investigation should be minimised, protected and retained only as authorised. Sensitive material may require restricted handling, segregation or special reporting procedures.

Examiners should maintain competence, use validated methods, document uncertainty and avoid misleading language. Findings should be reproducible and defensible to technical and non-technical audiences. When evidence may be used in disciplinary or judicial proceedings, disclosure obligations, continuity records and expert-witness standards become especially important.

Automation, Analytics and Emerging Practice

Automation assists with hashing, indexing, known-file filtering, timeline generation, malware triage, log parsing and correlation across endpoints. Machine-learning systems may prioritise suspicious files or identify anomalous process behaviour, but their results are investigative leads rather than self-authenticating conclusions. Models can inherit bias from training data, misclassify legitimate administration and obscure the reasoning behind a result.

Current practice increasingly involves endpoint detection and response telemetry, cloud audit logs, remote collection, mobile-linked accounts, encrypted volumes and large-scale enterprise investigations. The forensic examiner must understand how retention policies, centralised logging, privacy controls and provider APIs affect evidential completeness. Future-ready practice combines traditional disk analysis with memory, identity, network, cloud and application evidence while preserving provenance for every data source.

Best Practices for Professional Examination

A defensible examiner should:

  • define the question, authority and scope before collection;
  • preserve volatile evidence when justified by risk;
  • use write protection and verified images where possible;
  • calculate and record hashes and maintain chain of custody;
  • examine file-system metadata, content and operating-system artefacts together;
  • preserve original timestamps and document time-zone conversion;
  • corroborate important findings with independent artefacts;
  • distinguish observation, interpretation and conclusion;
  • record tool versions, parsing limitations and unsuccessful attempts;
  • protect irrelevant personal data and restrict access to sensitive evidence; and
  • state uncertainty clearly, especially where recovery is partial or attribution is indirect.

Chapter Summary

Storage and operating-system forensics examines the structures through which systems store data and record activity. Allocated files, deleted content, unallocated space, slack, hidden storage and file-system metadata each provide different forms of evidence. NTFS, FAT-family systems, ext4 and APFS have distinct structures and limitations that shape acquisition and recovery.

A reliable investigation preserves evidence, verifies acquisition, analyses both file-system and operating-system artefacts, correlates independent sources and reports uncertainty. Windows examinations often rely on the Registry, EVTX logs, Prefetch, Amcache, Shimcache, USN Journal and persistence locations. Linux examinations draw on journald or syslog records, authentication logs, shell history, cron, systemd and service artefacts. macOS examinations commonly involve APFS volumes and snapshots, Unified Logs, property lists, quarantine data, LaunchAgents and LaunchDaemons.

The forensic examiner must avoid simplistic conclusions about timestamps, deletion, execution and attribution. Encryption, SSD behaviour, anti-forensics, distributed cloud evidence and privacy obligations make professional judgement essential. Automation and analytics can improve scale and prioritisation, but human validation, provenance and transparent reasoning remain central.

Key Terms

Allocated space: Storage currently assigned to an active file or directory.

Unallocated space: Storage not currently assigned to an active file-system object.

File slack: Unused space within the final allocation unit assigned to a file.

File carving: Recovery of files from data patterns without relying primarily on file-system metadata.

Metadata: Descriptive information about data, such as size, ownership, location and timestamps.

MFT: The NTFS Master File Table containing records describing files and directories.

USN Change Journal: An NTFS record of selected file-system changes.

Inode: An ext4 structure containing file metadata and references to data blocks.

APFS snapshot: A point-in-time representation supported by APFS copy-on-write mechanisms.

Alternate data stream: An NTFS data stream associated with a file but not shown in its ordinary content view.

Write blocker: A hardware or software control designed to prevent writes to acquired media.

Cryptographic hash: A fixed-length digest used to verify data integrity.

Chain of custody: Documentation of evidence possession, handling and transfer.

Prefetch: A Windows artefact that can provide evidence related to executable loading.

Registry hive: A Windows Registry file containing a structured portion of configuration data.

Persistence: A mechanism that allows software or access to survive restart or user logout.

Unified Log: The macOS logging system containing operating-system and application records.

Timeline analysis: Correlation and interpretation of events according to normalised time.

Living off the land: Use of legitimate system tools for activities that may be malicious.

Attribution: The process of associating an action with an account, process, device or person while recognising evidential limits.

Review Questions

Short Answer Questions

1. Distinguish allocated space, unallocated space and file slack.

2. Why should a forensic examiner avoid treating one timestamp as conclusive proof of an event?

3. What information can the NTFS USN Change Journal provide, and what is one limitation?

4. Name two important Linux persistence locations or mechanisms.

5. Why is a cryptographic hash important during forensic acquisition?

Long Answer Questions

1. Explain a defensible workflow for acquiring and analysing a storage device in an incident investigation.

2. Compare the forensic significance of NTFS, ext4 and APFS structures.

3. Discuss how Windows Registry artefacts, event logs and execution traces can be correlated.

4. Explain the principal challenges of interpreting deleted files and recovered fragments.

5. Describe how ethical, privacy and governance requirements influence forensic examination.

Analytical / Application Questions

1. A recovered archive has a modification time matching an employee’s logon, but no direct evidence shows transfer to an external device. What conclusions are justified, and what additional artefacts would you seek?

2. A Linux shell history shows a suspicious command, but authentication logs show several administrators used the system. How would you assess attribution?

3. An examiner finds a macOS LaunchAgent pointing to an unsigned executable and a corresponding quarantine record. What hypotheses should be tested before concluding that persistence was malicious?

22. Multiple Choice Questions with Answers

Question 1

Which statement best describes unallocated space?

A. Space currently assigned to an active directory only

B. Storage not currently assigned to an active file-system object

C. The unused portion of every file’s final block

D. A reserved area containing only operating-system logs

Correct Answer: B. Storage not currently assigned to an active file-system object

Question 2

Why should Prefetch evidence generally not be treated as a complete execution log?

A. It exists only on Linux systems

B. It records network packets rather than programs

C. It can support loading of an executable but does not necessarily identify the human launcher or exact run count

D. It is stored exclusively in unallocated space

Correct Answer: C. It can support loading of an executable but does not necessarily identify the human launcher or exact run count

Question 3

Which NTFS feature may conceal content from an ordinary file-size listing?

A. An alternate data stream

B. An ext4 inode

C. A macOS LaunchDaemon

D. A FAT directory checksum

Correct Answer: A. An alternate data stream

Question 4

An investigator finds a deleted file whose metadata remains but whose content is partly overwritten. The most accurate description is:

A. The original file has been completely restored

B. The file is proven to have been encrypted

C. The content is partially recovered and should be reported with limitations

D. The metadata proves who physically created the file

Correct Answer: C. The content is partially recovered and should be reported with limitations

Question 5

Which practice most directly protects the integrity of an acquired storage image?

A. Opening the original device repeatedly in the user interface

B. Using a write blocker and recording cryptographic hashes

C. Changing all file timestamps to UTC

D. Deleting irrelevant files before imaging

Correct Answer: B. Using a write blocker and recording cryptographic hashes

Question 6

Why must a forensic timeline account for time zones and clock drift?

A. File systems do not store any metadata

B. Different evidence sources may record events using different clocks and time bases

C. Hash values change when time zones change

D. Encryption always removes timestamps

Correct Answer: B. Different evidence sources may record events using different clocks and time bases

Question 7

Which artefact combination would provide the strongest support for a Windows application-activity hypothesis?

A. A filename alone

B. A single file-access timestamp alone

C. A process-related trace, a corresponding logon and corroborating application or file-system artefacts

D. An empty Recycle Bin alone

Correct Answer: C. A process-related trace, a corresponding logon and corroborating application or file-system artefacts

Question 8

What is a significant limitation of shell history in Linux investigations?

A. It can never contain commands

B. It is always generated by the kernel and cannot be altered

C. It may be disabled, incomplete or modified by the user

D. It exists only after a system reboot

Correct Answer: C. It may be disabled, incomplete or modified by the user

Question 9

A macOS LaunchAgent references an unfamiliar executable. What should the examiner do first?

A. Conclude immediately that the executable is malware

B. Delete the LaunchAgent to stop persistence

C. Correlate its path, ownership, timestamps, signature, quarantine data and process evidence

D. Assume it is legitimate because it is signed by the operating system

Correct Answer: C. Correlate its path, ownership, timestamps, signature, quarantine data and process evidence

Question 10

Which conclusion is most defensible when an employee’s account was logged on while an archive utility executed?

A. The employee is conclusively proven to have created and uploaded the archive

B. The account and execution evidence support activity during the session, but human attribution and upload require further corroboration

C. The archive must have been created by backup software

D. The event cannot be relevant because timestamps are never useful

Correct Answer: B. The account and execution evidence support activity during the session, but human attribution and upload require further corroboration

Digital Forensics and Incident Response
Chapter 7 of 15