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

Introduction and Context

Host forensics examines a computer, mobile workstation, virtual machine, or server as a source of evidence. It seeks to reconstruct what happened on a system, which accounts and processes were involved, what files were created or altered, how an intruder persisted, and whether data was accessed, copied, or destroyed. Unlike network forensics, which primarily studies communications, host forensics studies the system state and the traces left by human and automated activity.

The host is not a neutral container of facts. Operating systems continuously create, modify, cache, rotate, compress, delete, and overwrite data. Time may be represented differently by different artefacts, logs may be incomplete, and normal maintenance can obscure evidence. Consequently, forensic interpretation requires both technical knowledge and disciplined reasoning. An investigator must distinguish an observed fact—for example, that a file was modified—from an inference, such as the conclusion that a particular person edited it.

This chapter develops a comparative approach to Windows, Linux, and macOS forensics. It explains file systems, operating-system artefacts, registries and configuration stores, logs, persistence mechanisms, deleted data, metadata, user activity, timeline construction, and forensic tooling. It also connects technical examination with acquisition, validation, reporting, legal authority, privacy, and organizational decision-making.

Learning Objectives

After studying this chapter, a learner should be able to:

1. Explain the evidential value and limitations of host and file-system artefacts.

2. Compare major characteristics of NTFS, common Linux file systems, and APFS.

3. Identify significant Windows, Linux, and macOS artefacts associated with users, processes, logs, persistence, and file activity.

4. Design a defensible acquisition and examination workflow.

5. Recover and interpret deleted data, metadata, and alternate data sources.

6. Construct and validate a multi-source forensic timeline.

7. Apply forensic tools without compromising evidence integrity.

8. Evaluate technical findings in ethical, legal, and organizational contexts.

The Evidential Logic of a Host

A host investigation normally addresses five questions: what system is being examined; what activity occurred; when it occurred; which account, process, or device was associated with it; and how reliable the available evidence is. These questions are answered by correlating artefacts rather than relying on one file or timestamp.

An artefact is a digital object or observable state that can provide investigative information. Examples include a registry key, shell history entry, browser database, event log, inode, extended attribute, launch agent, prefetch file, or memory-resident process. Artefacts differ in persistence and evidential strength. A signed operating-system log may establish that a service recorded an event, but it may not prove that a human deliberately performed the action. A user document may reveal content and metadata, but its timestamps can change through copying or synchronization.

A useful distinction is between source data, derived data, and interpretation. Source data is acquired directly from the device, such as sectors or a physical memory image. Derived data includes a hash set, parsed event record, recovered file, or timeline entry. Interpretation is the reasoned conclusion drawn from those outputs. Maintaining this distinction improves reproducibility and prevents tools from concealing assumptions.

Volatile and Persistent Evidence

Volatile evidence includes memory contents, active network connections, running processes, open files, mounted volumes, clipboard data, and temporary cryptographic keys. It can disappear when power is removed or a system changes state. Persistent evidence includes storage media, logs, configuration databases, backups, cloud-synchronization records, and removable media. A live response may therefore be necessary, but it changes the system and must be documented.

The order of collection depends on circumstances. If a system is powered on and encryption keys or malicious processes are important, memory and relevant live state may have priority. If alteration risk is high and encryption is not a concern, controlled shutdown or immediate imaging may be preferable. There is no universally correct sequence; the decision should be justified in the case record.

File Systems as Evidence Structures

A file system is more than a directory tree. It records allocation, names, ownership, permissions, timestamps, links, journaling activity, and sometimes snapshots or copy-on-write relationships. The investigator should examine both logical content and structural metadata.

NTFS and Windows Storage

NTFS uses the Master File Table (MFT), in which files and directories are represented by records. MFT records can contain resident data, file attributes, security information, and timestamps. Non-resident data is described through runs that identify allocated clusters. The USN Change Journal records changes such as creation, deletion, extension, and renaming, although it is not a complete historical log and may be disabled, truncated, or overwritten.

Important NTFS features include alternate data streams, which can store data associated with a file but not visible in an ordinary directory listing; reparse points, used for links and other redirections; and Volume Shadow Copies, which may preserve earlier states of files and system configuration. The Recycle Bin contains deleted-file remnants and identifiers, but its contents are not equivalent to all deleted data on the volume.

Linux File Systems

Linux investigations encounter ext4, XFS, Btrfs, and other file systems. In ext4, inodes hold metadata such as ownership, permissions, size, and timestamps, while directory entries associate names with inode numbers. The journal may contain recent metadata or content fragments, but journaling behavior varies and is not a guaranteed history of every operation. Deleted files may remain in unallocated blocks until reused; recovery depends on fragmentation, overwriting, encryption, and the file system’s allocation behavior.

Linux also exposes valuable structures outside the file system itself: `/var/log`, systemd journal storage, shell histories, authentication databases and logs, cron directories, SSH configuration, user home directories, package databases, and temporary directories. Containers, virtual machines, mounted network shares, and cloud agents can distribute evidence across several storage layers.

APFS and macOS Storage

APFS uses containers, volumes, copy-on-write design, snapshots, encryption, and space-sharing. A single physical device may contain multiple volumes, including system, data, recovery, and virtual-machine-related volumes. Copy-on-write and snapshots can preserve historical material, but they also require careful interpretation: a logical file path may correspond to different physical states over time.

macOS evidence commonly includes unified logs, the FSEvents database, Spotlight metadata, property-list files, launch agents and daemons, browser and application databases, quarantine records, shell histories, keychain-related artefacts, and user preference files. macOS privacy controls can limit access to protected locations, so acquisition must account for permissions, full-disk encryption, and the distinction between a live logical collection and a complete physical image.

Operating-System Artefacts and User Activity

Windows

The Windows Registry is a central configuration database composed of hives. Important hives include SYSTEM, SOFTWARE, SECURITY, SAM, and user-specific NTUSER.DAT files. Registry data can reveal installed software, network settings, connected devices, user preferences, recently used files, execution traces, and persistence configuration. Recent activity may also be represented in the Amcache, Shimcache, UserAssist, Jump Lists, LNK files, and Prefetch data. These artefacts have different creation conditions and should not be treated as interchangeable proof of execution.

Windows Event Logs, normally stored as EVTX files, provide records for logon, account management, service activity, task scheduling, PowerShell, security auditing, and system events. Audit configuration determines what was recorded. Windows Defender, firewall, application, and PowerShell logs may help identify downloaded files, script execution, or security-control changes.

User activity can also be inferred from browser history, downloads, cookies, shell bags, Office recent-file lists, Recycle Bin records, USB connection artefacts, and cloud-client databases. Interpretation should consider shared accounts, automated services, remote administration, malware, and synchronization.

Linux

Linux authentication and system logs may be located under `/var/log`, although distribution and configuration determine exact paths. The systemd journal can contain kernel messages, service output, authentication events, and boot records. Relevant sources include `auth.log` or `secure`, `syslog` or `messages`, audit logs, package-manager history, SSH logs, shell history files, and web-server logs.

Persistence commonly appears in systemd service units, timers, cron and anacron jobs, shell startup files, SSH authorized keys, user-level services, `/etc/rc.local` on applicable systems, kernel modules, and scheduled scripts. A forensic analyst should inspect ownership, permissions, creation context, service dependencies, executable paths, and logon relationships rather than assuming that every unusual entry is malicious.

macOS

macOS unified logging records events from many system and application components. It is powerful but requires time-bounded extraction and appropriate predicates; not every event is retained indefinitely. FSEvents can show directory-level changes, while Spotlight metadata may reveal file names, types, dates, and content attributes. Neither source necessarily proves that a user opened or read a file.

Persistence mechanisms include LaunchAgents, LaunchDaemons, login items, configuration profiles, shell startup files, cron entries, browser extensions, application support directories, and modified system components. Quarantine metadata may indicate that an item originated from an external source, but its presence or absence must be interpreted with application and operating-system context.

Persistence, Execution, and Deleted Data

Persistence is a mechanism that enables code or a service to survive reboot, logon, or scheduled execution. Common mechanisms include services, scheduled tasks, startup folders, registry run keys, systemd units, cron jobs, SSH keys, launch agents, login items, and browser or document-application extensions. Persistence analysis should answer: what executes, under which identity, at what trigger, with what privileges, from which path, and whether the entry is legitimate.

Execution evidence is similarly contextual. A prefetch record may indicate that Windows attempted to execute a program, while a shell history entry indicates that a command was recorded by a shell. Neither necessarily identifies the human who initiated it. Process creation logs, memory, application logs, file metadata, user sessions, and network records can strengthen or weaken the inference.

Deleted-data recovery begins with preservation. Investigators should acquire a forensic image, calculate cryptographic hashes, identify partitions and encryption, and work from verified copies. Recovery may use directory entries, MFT records, inodes, journals, unallocated space, slack space, file carving, snapshots, backups, and application databases. File carving reconstructs content from signatures and structure but often loses original names, paths, and timestamps. Solid-state drive garbage collection and TRIM can make recovery impractical; a failed recovery attempt does not prove that data never existed.

Metadata requires particular caution. File-system timestamps may include creation, modification, access, and metadata-change times, but semantics differ by platform. Copying, extraction, time-zone conversion, virtualization, synchronization, and anti-forensic tools can alter them. Hashes establish that two byte sequences are identical; they do not establish when or by whom a file was created.

A Defensible Forensic Workflow

A professional workflow combines incident response with forensic discipline.

Scope and authority. Define the incident, systems, time range, users, and legal authority. Record whether the work is internal, regulatory, civil, or criminal and identify privacy boundaries.

Preservation. Isolate systems when necessary, avoid unnecessary interaction, document power state, photograph or record the environment, and preserve volatile evidence when justified. Prevent remote wiping or continued compromise without destroying relevant evidence.

Acquisition. Select physical, logical, live, or targeted acquisition according to the question. Use write blockers where appropriate, validated tools, trusted media, and documented operators. Record device identifiers, acquisition time, tool versions, errors, and hash values.

Examination. Create working copies, mount images read-only where possible, identify partitions and encryption, parse artefacts, recover deleted material, and inspect memory if available. Tool output should be checked against source data and, for important findings, corroborated through independent methods.

Analysis and timeline construction. Normalize time zones and clock offsets, preserve original timestamps, assign source and confidence fields, and correlate events across users, processes, files, logs, and network activity. A timeline is an analytical model, not an automatic statement of truth.

Reporting. State methods, limitations, findings, supporting artefacts, alternative explanations, and unresolved questions. A defensible report allows another qualified examiner to reproduce the material conclusions.

Timeline Analysis

A useful timeline may contain event time, record time, source, host, user, action, object, process, and confidence. Event time describes when the underlying activity is believed to have occurred; record time describes when an artefact recorded it. For example, a log may be written after a process starts, and a file’s metadata may be updated after a document is saved.

Investigators should normalize UTC offsets but retain original values. Correlation is strongest when independent sources converge: a process-creation event, a persistence entry, a file hash, a user logon, and a network connection occurring in a plausible sequence. Gaps should be reported rather than silently filled.

Tools, Automation, and Validation

Common forensic platforms include Autopsy and The Sleuth Kit, Magnet AXIOM, EnCase, X-Ways Forensics, FTK, Volatility for memory analysis, Plaso and related timeline tools, native Windows Event Viewer or PowerShell, Linux command-line utilities, and macOS artefact parsers. No tool is universally complete. A parser may omit unsupported versions, misinterpret corrupted records, or normalize timestamps incorrectly.

Automation is valuable for hashing, keyword search, event extraction, malware triage, and correlation across many endpoints. However, automated classification and machine-learning systems should be treated as triage aids. Their results require validation, explainability, and human review, particularly where employment, disciplinary, or criminal consequences may follow.

Validation includes testing tools on known datasets, preserving raw records, recording parser versions, checking hashes, comparing multiple tools, and manually inspecting representative source artefacts. Tool output is evidence about an artefact only when its interpretation is technically justified.

Illustrative Case Study: Suspected Insider Data Theft

Background. A research organization reported that confidential design files appeared in a competitor’s possession. A Windows workstation assigned to an engineer was suspected, but the organization also used cloud synchronization and removable media.

Situation. The workstation was powered on and the user was logged in. Management wanted an immediate answer, while legal counsel required preservation of privacy and evidential integrity.

Analysis and approach. The response team documented the screen and network state, isolated the host according to policy, and collected volatile memory because an active synchronization process and possible encryption keys were relevant. A forensic image was then acquired using a write-blocked process and hashed. Investigators examined NTFS metadata, the USN Journal, Recycle Bin, Windows Event Logs, PowerShell records, LNK and Jump List artefacts, browser downloads, USB connection records, cloud-client databases, and Volume Shadow Copies.

The timeline showed a user logon, access to a project directory, creation of an archive, connection of an external storage device, and subsequent deletion of the archive. The USN Journal and MFT supported the sequence, while a cloud log showed synchronization from the same account. However, the archive’s file timestamp alone was not treated as proof of copying. A recovered fragment and a matching hash in the cloud audit record provided stronger corroboration. The team also found that an automated backup job had accessed several files, preventing an unsupported conclusion that every access was deliberate.

Outcome. The report concluded that the account was used to create and synchronize a particular archive during the relevant period, but it distinguished that finding from proof of the individual’s physical presence. Access logs, badge records, and interviews were recommended for attribution. The organization strengthened cloud audit retention, removable-media controls, and separation of administrative accounts.

Learning points. The case demonstrates the value of combining host and cloud evidence, the difference between account activity and personal attribution, the importance of volatile evidence, and the danger of treating one timestamp or one artefact as conclusive.

Limitations, Risks, and Common Errors

Important limitations include full-disk encryption, missing logs, clock drift, overwritten sectors, SSD garbage collection, damaged media, anti-forensic activity, virtualized storage, cloud dependence, and incomplete audit policies. A clean system image does not prove that no incident occurred; it may indicate only that relevant evidence was not retained.

Common errors include examining the original media directly, failing to calculate hashes, shutting down a live encrypted system without considering volatile keys, confusing file modification with user access, ignoring time zones, accepting parser output without validation, and reporting suspicion as fact. Investigators also risk confirmation bias by searching only for artefacts that support an initial allegation.

Ethical, Legal, and Governance Considerations

Host forensics can expose personal communications, health information, credentials, intellectual property, and data belonging to uninvolved users. Collection must be authorized, proportionate, purpose-limited, and securely controlled. Investigators should minimize unrelated data, restrict access, maintain chain of custody, and follow applicable law, organizational policy, contractual obligations, and professional codes.

Evidence handling should preserve authenticity and reproducibility. The chain of custody records possession, transfer, storage, access, and examination. Reports should disclose uncertainty and limitations rather than overstating attribution. Where employees or customers are affected, governance processes should define notification, retention, escalation, and independent review.

Current Developments

Modern investigations increasingly involve endpoint detection and response telemetry, cloud-managed operating systems, remote collection, container layers, software-defined storage, and encrypted endpoints. Endpoint telemetry can provide process trees and network context that traditional disk artefacts lack, but retention and vendor-specific schemas create new dependencies. Snapshot-based systems and synchronized workspaces require investigators to reason across multiple copies and locations.

Artificial intelligence is being used to cluster events, identify anomalous persistence, summarize logs, and prioritize evidence. Its value is greatest in reducing search time; it should not replace source verification or expert judgment. Emerging practice therefore emphasizes provenance, reproducible parsing, privacy-preserving collection, and integration of endpoint, identity, cloud, and file-system evidence.

Best Practices for Professional Examination

• Define the investigative question before collecting excessive data.
• Preserve volatile state when its loss would materially affect the inquiry.
• Acquire and hash evidence using documented, validated procedures.
• Work from copies and preserve raw artefacts.
• Record original time zones, clock offsets, tool versions, and errors.
• Corroborate important findings across independent sources.
• Separate facts, interpretations, assumptions, and confidence levels.
• Treat deleted-data recovery as probabilistic and technically constrained.
• Consider legitimate administrative, backup, and automated explanations.
• Protect privacy and disclose limitations in the final report.

Chapter Summary

Host forensics reconstructs system and user activity from volatile state, storage structures, operating-system databases, logs, application artefacts, and deleted remnants. NTFS, Linux file systems, and APFS expose different forms of metadata, journaling, snapshots, and deletion behavior. Windows Registry hives and EVTX logs, Linux journals and authentication records, and macOS unified logs, FSEvents, property lists, and launch mechanisms are central investigative sources. Persistence and execution must be interpreted in context, while timestamps and deleted data require careful qualification.

A defensible investigation proceeds from authority and preservation through acquisition, validated examination, timeline correlation, and transparent reporting. Tools and automation increase scale but do not remove the need for source verification and expert interpretation. Ethical collection, privacy protection, chain of custody, and explicit uncertainty are as important as technical recovery.

Key Terms

Artefact: A digital object or system trace that may provide investigative information.

Chain of custody: A documented history of evidence possession, transfer, storage, and examination.

File carving: Recovery of files from raw data using content signatures and structural patterns.

FSEvents: A macOS database recording file-system change events, often at directory level.

Hash: A computed digest used to compare or verify digital data.

Inode: A Linux file-system structure containing metadata and pointers to file content.

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

Metadata: Data describing an object, such as ownership, timestamps, size, or location.

NTUSER.DAT: A Windows Registry hive containing user-specific settings and activity traces.

Persistence: A mechanism allowing code or a service to survive reboot, logon, or another trigger.

Plaso: A framework commonly used to extract and normalize forensic timeline events.

Prefetch: A Windows artefact that may provide contextual evidence of program execution.

Registry: The Windows hierarchical configuration and settings database.

Slack space: Unused space within allocated storage units that may contain residual data.

Snapshot: A preserved point-in-time view of a file system or volume.

Systemd journal: A Linux log store managed by systemd.

Timeline: A chronologically organized analytical representation of events from multiple sources.

Volatile evidence: Data likely to disappear or change when a system loses power or continues operating.

Write blocker: A hardware or software control designed to prevent alteration of source media.

Review Questions

Short Answer Questions

1. Distinguish source data, derived data, and interpretation in a host investigation.

2. What information can the NTFS USN Change Journal provide, and why is it incomplete?

3. Why should a file timestamp not be treated as proof of user access?

4. Identify two persistence mechanisms found on Linux and two found on macOS.

5. What is the purpose of calculating a forensic hash?

Long Answer Questions

1. Compare the forensic significance of NTFS, ext4, and APFS, including deletion, metadata, and snapshot considerations.

2. Explain a complete host-forensic workflow from authorization through final reporting.

3. Discuss Windows Registry and Event Log evidence and the risks of misinterpreting execution artefacts.

4. Explain how a forensic timeline is constructed, normalized, corroborated, and qualified.

5. Evaluate the benefits and limitations of automation and AI in host-forensic examinations.

Analytical / Application Questions

1. A Windows archive was created, deleted, and later found in a cloud account. Design an examination strategy that distinguishes account activity, automated synchronization, and deliberate human copying.

2. A Linux server shows an unfamiliar systemd service, but no corresponding authentication event. What artefacts and alternative explanations should be examined before concluding compromise?

3. A macOS investigation finds an FSEvents entry and a quarantine record for an application. Explain what can reasonably be inferred and what additional evidence is needed to establish execution and user attribution.

22. Multiple Choice Questions with Answers

Question 1

Which statement best describes the evidential value of a forensic timeline?

A. It automatically proves the identity of the person who performed every event.

B. It is an analytical model that correlates events from multiple sources and requires interpretation.

C. It replaces the need to preserve original artefacts.

D. It contains only file-system timestamps.

Correct Answer: B. It is an analytical model that correlates events from multiple sources and requires interpretation.

Question 2

Which NTFS feature records changes such as file creation, deletion, and renaming?

A. MFT resident data only

B. USN Change Journal

C. Windows Clipboard

D. SAM hive

Correct Answer: B. USN Change Journal

Question 3

Why is a recovered file through carving often weaker for attribution than an intact directory entry?

A. Carving always changes the file contents.

B. Carving generally cannot preserve the original path and reliable file-system metadata.

C. Carved files cannot be hashed.

D. Carving works only on encrypted volumes.

Correct Answer: B. Carving generally cannot preserve the original path and reliable file-system metadata.

Question 4

Which situation most strongly justifies collecting volatile evidence before shutting down a host?

A. The investigator wants to view the desktop wallpaper.

B. The system may contain active encryption keys and an ongoing malicious process.

C. The disk has already been securely wiped.

D. The host has no network connection.

Correct Answer: B. The system may contain active encryption keys and an ongoing malicious process.

Question 5

Which statement about macOS FSEvents is most accurate?

A. It proves that a user opened every file listed.

B. It records directory-level file-system changes but does not alone prove user intent or file reading.

C. It is a Windows Registry hive.

D. It contains all historical system events indefinitely.

Correct Answer: B. It records directory-level file-system changes but does not alone prove user intent or file reading.

Question 6

An investigator finds a new Linux systemd service running from a user-writable directory. What is the most appropriate next step?

A. Immediately conclude that the service is malware.

B. Examine ownership, service configuration, executable metadata, logs, trigger context, and legitimate software explanations.

C. Delete the service to prevent further activity without documenting it.

D. Ignore it because systemd services cannot provide persistence.

Correct Answer: B. Examine ownership, service configuration, executable metadata, logs, trigger context, and legitimate software explanations.

Question 7

What does a cryptographic hash establish most directly?

A. The person who created a file

B. The time a file was copied

C. That two data sets produce the same digest and are likely identical for the chosen hash function

D. That a file was intentionally deleted

Correct Answer: C. That two data sets produce the same digest and are likely identical for the chosen hash function

Question 8

Which practice best improves the defensibility of tool output?

A. Relying on one parser without examining source data

B. Using validated tools, preserving raw records, recording versions, and corroborating important results

C. Changing timestamps to local time and discarding the originals

D. Reporting only results that support the initial hypothesis

Correct Answer: B. Using validated tools, preserving raw records, recording versions, and corroborating important results

Question 9

In the illustrative insider-theft case, why was the archive timestamp alone insufficient?

A. Timestamps cannot be displayed on Windows.

B. Timestamps may reflect copying, synchronization, or other system activity and do not establish who acted.

C. Archives never contain metadata.

D. Cloud systems cannot record file events.

Correct Answer: B. Timestamps may reflect copying, synchronization, or other system activity and do not establish who acted.

Question 10

Which principle is most relevant when host evidence includes unrelated employee communications?

A. Collect and disclose all available data without restriction.

B. Purpose limitation, proportionality, privacy protection, and access control.

C. Delete all evidence involving personal information.

D. Allow every investigator unrestricted access for transparency.

Correct Answer: B. Purpose limitation, proportionality, privacy protection, and access control.