Operating System and Endpoint ForensicsIntroductionOperating-system (OS) and endpoint forensics examines the data created, modified, stored, and deleted by computers and endpoint devices. An endpoint may be a workstation, laptop, server, virtual machine, or mobile-adjacent computer used to access organisational resources. Unlike network forensics, which primarily observes communications, endpoint forensics investigates the state and history of a device: who used it, how it was configured, which programs executed, what files were accessed, how authentication occurred, and whether persistence or anti-forensic techniques were used. The central forensic problem is inferential. An artifact rarely proves an action by itself. A registry value may indicate configuration, a log may record an event, and a file-system timestamp may reflect metadata processing rather than human activity. Reliable conclusions therefore arise from corroboration among independent artifacts, careful preservation, knowledge of operating-system semantics, and explicit treatment of uncertainty. This chapter applies a cross-platform approach to Windows, Linux, and macOS. It addresses acquisition, registries and configuration stores, logs, user activity, authentication, persistence, execution traces, deleted files, timeline construction, and interpretation. It also considers professional, legal, ethical, and governance requirements. Learning ObjectivesBy the end of this chapter, the reader should be able to: 1. Explain the forensic value and limitations of major Windows, Linux, and macOS artifacts. 2. Distinguish acquisition, preservation, examination, analysis, and reporting. 3. Interpret authentication records, execution traces, persistence mechanisms, and user-activity artifacts. 4. Construct a defensible event timeline from heterogeneous time sources. 5. Recover and evaluate deleted-file evidence without confusing recoverability with proof of use. 6. Correlate artifacts to infer user or system actions while expressing uncertainty appropriately. 7. Apply sound validation, documentation, privacy, and chain-of-custody practices. 1. A Forensic Model of the EndpointA useful model treats an endpoint as four interacting layers: - Hardware and storage: disks, SSDs, removable media, firmware, partitions, file systems, and volatile memory.
- Operating-system services: authentication, scheduling, logging, networking, process creation, update services, and security controls.
- Applications: browsers, office software, messaging tools, development environments, and security products.
- User and organisational context: identities, permissions, work practices, policies, time zones, and cloud services.
Artifacts can be classified by their relationship to an event: - Direct records are generated close to the event, such as a process-creation record or authentication log.
- Indirect records preserve a consequence of an event, such as a recently opened-file list or a shell history entry.
- State artifacts describe a configuration at a particular time, such as a persistence entry or a registry setting.
- Content artifacts contain the object itself, such as a document, browser database, executable, or recovered file.
The distinction between presence, execution, and use is essential. The presence of an executable does not establish that it ran. A process record supports execution, but execution does not establish that a person intentionally operated the program; a scheduled task, service, malware, or another process may have launched it. Attribution requires correlation with identity, session, input, network activity, and contextual evidence. A standard forensic workflow is: 1. Preparation: define authority, scope, questions, tooling, and personnel. 2. Identification: locate devices, users, accounts, data sources, and volatile evidence. 3. Preservation: prevent alteration; document custody and calculate cryptographic hashes where appropriate. 4. Acquisition: create a forensic image or logically collect specified artifacts using validated methods. 5. Examination: extract records, recover deleted data, decode formats, and normalise timestamps. 6. Analysis: correlate evidence, test competing explanations, and assess reliability. 7. Reporting: state methods, findings, limitations, assumptions, and reproducible supporting evidence. A forensic image should be verified using hashes, but a matching hash proves that two byte sequences are identical; it does not prove that the source itself was complete, authentic, or correctly interpreted. Write blockers, read-only acquisition, documented tool versions, and independent verification reduce risk. 2. Time, Identity, and Evidential Reliability2.1 Time semanticsOperating systems contain several timestamps. Common file-system times include creation or birth time, modification time, access time, and metadata-change time. Their meaning differs by file system and operating system. A modification time normally concerns file content; a metadata-change time may change when permissions or names change. Access-time updates may be disabled, delayed, or suppressed for performance. Copying a file can create a new object with a new creation time while retaining an older modification time. Investigators should record: - the raw timestamp;
- the source artifact and field name;
- the time zone or offset;
- whether the value is UTC, local time, or an epoch value;
- clock-skew assumptions;
- precision and known limitations.
A timeline is not merely a sort operation. It is a model of events with different confidence levels. For example, a central log may provide a precise process-creation time, whereas a file timestamp may only indicate that a state existed by a particular time. 2.2 Identity and attributionAn account identifier, security identifier, UID, or login name is not automatically a human identity. Shared accounts, service accounts, delegated credentials, remote sessions, token theft, and administrative actions complicate attribution. A strong attribution assessment correlates account records with logon sessions, device location, authentication method, process lineage, interactive input, network addresses, and organisational knowledge. 2.3 Confidence and competing hypothesesA disciplined report distinguishes observation from interpretation: - Observation: “A process record shows `powershell.exe` launched at 14:03:22 UTC.”
- Interpretation: “The command interpreter executed under the account associated with session X.”
- Inference: “The activity is consistent with an operator running a script.”
- Limit: “The artifact does not alone establish who physically operated the keyboard.”
Investigators should consider alternatives, including automated maintenance, software updates, malware, clock error, log loss, and artifact fabrication. Corroboration increases confidence, but several artifacts derived from the same underlying source are not fully independent. 3. Windows Endpoint Forensics3.1 Registry artifactsThe Windows Registry is a hierarchical configuration database composed of hives. Important sources include: - SAM: local account and group information, subject to access restrictions and encryption-related considerations.
- SYSTEM: computer configuration, services, mounted devices, control sets, and hardware-related information.
- SOFTWARE: installed software, operating-system settings, and application configuration.
- SECURITY: local security policy and protected security data.
- NTUSER.DAT: per-user settings, shell activity, application preferences, and user-specific traces.
- UsrClass.dat: user shell and COM-related information.
Registry interpretation requires attention to transaction logs, backup hives, last-write times, value types, and profile identity. A registry key’s last-write time normally indicates a change to that key, not necessarily the time a user performed the underlying activity. UserAssist entries, for example, can support evidence that graphical applications or shortcuts were used, but they should be evaluated alongside Prefetch, process logs, shortcut files, and user-session evidence. Useful Windows artifacts include RecentDocs, jump lists, shellbags, mounted-device records, USB-related keys, Windows shortcut files, and application-specific databases. Each has a different evidential meaning. Shellbags may preserve evidence of folder navigation, including folders no longer present, but they do not necessarily prove that a file was opened. USB artifacts can associate a device identifier with a host, but connection does not prove data transfer. 3.2 Windows event loggingThe Windows Event Log system stores records in channels such as Security, System, Application, and operational logs. Relevant security events may include successful and failed logons, explicit credential use, account changes, process creation, service installation, and audit-policy changes. The exact event identifiers and available fields depend on operating-system version, audit policy, logging configuration, forwarding, and endpoint security products. Process-creation auditing is especially valuable when command-line capture is enabled. It can reveal parent-child relationships, executable paths, account context, and command arguments. However, logs may be disabled, cleared, overwritten, forwarded incompletely, or modified by an attacker with sufficient privilege. Event records should therefore be compared with Prefetch, Amcache, Shimcache, Defender records, PowerShell logs, scheduled-task data, and file-system evidence. PowerShell operational logs, script-block logging, transcription, and module logging can provide execution detail, but they are policy-dependent. Security products may preserve detections and process telemetry beyond the native event logs. These sources are powerful but proprietary; investigators must preserve original exports and document collection methods. 3.3 Windows execution traces- Prefetch may indicate that an executable ran and can contain execution-related metadata. It is not available or equally informative on every Windows configuration and should not be treated as a precise universal execution counter.
- Amcache records information about applications and files observed by Windows application-compatibility components. Presence is not conclusive proof of execution.
- Shimcache/AppCompatCache records compatibility-related information and has historically been overinterpreted. It may show that a path was processed by the system, not necessarily that the program executed.
- UserAssist supports evidence of user-facing application interaction but is not a complete activity log.
- Windows Defender and EDR telemetry can contain process, detection, quarantine, and remediation events.
The best practice is to state exactly what an artifact supports rather than using the broad label “execution evidence.” 3.4 Persistence on WindowsCommon persistence locations include services, scheduled tasks, Run and RunOnce registry keys, startup folders, WMI event subscriptions, browser extensions, Office add-ins, Winlogon components, DLL search-order abuse, and modified shortcuts. Persistence analysis should examine creation or modification time, executable path, signer, owner, permissions, parent process, task triggers, service account, and associated network activity. 4. Linux Endpoint Forensics4.1 File systems and system recordsLinux systems commonly use ext4, XFS, Btrfs, or other file systems. Investigators should examine superblocks, journal structures, inodes, directory entries, extended attributes, access-control lists, symbolic links, and mount history. File-system semantics vary. For example, inode metadata-change time is distinct from content modification time, and journal records may assist recovery but do not guarantee recovery of all deleted content. Important system records include `/etc/passwd`, `/etc/shadow` where legally and technically accessible, `/etc/group`, `/etc/sudoers`, SSH configuration, host identity files, mounted-file-system data, and package-manager databases. These reveal accounts, privileges, software installation, trust relationships, and configuration state. 4.2 Logs and authenticationTraditional systems may use text logs under `/var/log`, including authentication, system, kernel, daemon, and package logs. Modern distributions frequently use `systemd-journald`, whose journal records can be queried using `journalctl`. Authentication evidence may include successful and failed SSH logins, sudo use, console logins, session creation, privilege changes, and account-management events. The presence of a successful SSH record demonstrates an authenticated session according to the server’s records; it does not necessarily establish the geographic identity of the user. Investigators should correlate source addresses, SSH keys, session processes, shell history, command auditing, VPN logs, and endpoint telemetry. Logs may be rotated, compressed, remote, incomplete, or affected by time synchronisation. 4.3 User activity and executionShell histories such as `.bash_history`, `.zsh_history`, and histories of other shells may reveal commands, but history behaviour is configurable. Commands may not be written until logout, may be disabled, may omit timestamps, or may be edited. History is therefore corroborative rather than complete. Other evidence includes shell configuration, recently accessed files, desktop environment data, browser profiles, application logs, process accounting, audit frameworks, and endpoint detection tools. Linux Audit (`auditd`) can record system calls and security-relevant events when correctly configured. `execve` records, for example, can support process execution analysis, while audit rules may be absent or too broad to answer a particular question. 4.4 Linux persistencePersistence may occur through systemd services and timers, cron and `at` jobs, shell startup files, SSH `authorized_keys`, user-level services, init scripts, kernel modules, udev rules, desktop autostart entries, and application plugins. Analysis should distinguish legitimate administration from malicious modification. File ownership, package provenance, service dependencies, creation times, and configuration history are valuable contextual evidence. 5. macOS Endpoint ForensicsmacOS combines a Unix foundation with Apple-specific security, configuration, and application artifacts. Key evidence includes APFS metadata and snapshots, unified logs, launch services, plist files, quarantine records, browser data, shell histories, authentication records, and user activity databases. 5.1 APFS and system protectionAPFS supports copy-on-write structures, snapshots, encryption, clones, and rich metadata. Deleted-file recovery is consequently dependent on allocation state, snapshots, encryption, and the collection method. FileVault may protect data at rest; lawful access and key handling must be addressed before acquisition. System Integrity Protection and the sealed system volume can constrain modification and affect artifact interpretation. 5.2 Unified logging and authenticationThe macOS unified log contains structured system and application messages. It is powerful for process, security, service, and configuration analysis but is subject to retention and privacy considerations. Authentication records, authorization databases, SSH logs, login-window activity, and management-system records may identify sessions and privilege use. Investigators should preserve native log formats where possible because conversion can lose fields or relationships. 5.3 macOS activity and persistence artifactsProperty-list files (`.plist`) contain system and application configuration. Launch agents and launch daemons are important persistence locations; they may be installed system-wide or within a user profile. Other mechanisms include login items, configuration profiles, cron, shell startup files, browser extensions, application plug-ins, and modified applications. Quarantine metadata can record downloaded-file origin and security assessment information. Spotlight and metadata databases may reveal indexed names and locations. Recent-item records, browser databases, shell history, application containers, and Finder-related artifacts can help reconstruct user activity. As with all platforms, an indexed or listed item is not automatically evidence that a person opened it. 6. Deleted Files and Unallocated EvidenceDeletion commonly removes a directory reference while leaving some or all content until storage is reused. Recovery methods include file-system metadata analysis, journal examination, carving, snapshot review, backup analysis, and examination of application databases. Carving identifies file signatures and structures without relying on directory metadata, but fragmented or encrypted files may be incomplete or misidentified. Traditional magnetic disks often provide more recovery opportunities than modern SSDs. TRIM and garbage collection can make deleted blocks unavailable, while encryption can make recovered bytes unintelligible without keys. Cloud synchronisation, recycle bins, snapshots, shadow copies, and endpoint backups may preserve deleted content or metadata. Recovered content must be validated. A carved image lacking its original path has weaker contextual value than an intact file linked to a user profile and application record. Hashes, file signatures, internal timestamps, embedded metadata, surrounding directory entries, and corroborating logs should be documented. “Recovered” means that bytes were obtained; it does not prove when or by whom the file was created, viewed, or deleted. 7. Timeline Construction and Event CorrelationA forensic timeline integrates file-system events, registry changes, log records, process activity, authentication, browser activity, persistence changes, and network indicators. A practical timeline schema includes: `timestamp | time basis | source | event | subject | object | account | host | confidence | limitations` The time basis records whether the timestamp is UTC, local time, or another representation. Normalisation should preserve the original value and offset rather than replacing it. Events should be grouped into episodes, such as “initial access,” “privilege escalation,” “collection,” and “persistence,” but labels must remain hypotheses until supported. Worked example: correlating an alleged script executionConsider an illustrative endpoint incident. At 09:14:02 UTC, a Windows process log records `powershell.exe` launched by `winword.exe` under user account U. At 09:14:03, PowerShell script-block logging records a command that creates a scheduled task. At 09:14:05, the Task Scheduler operational log records creation of task `Updater`, whose action points to a script in the user’s temporary directory. At 09:15:11, an EDR record reports the script connecting to an external address. A file-system record shows the script was created at 09:13:58 and modified at 09:14:01. The strongest conclusion is that the endpoint recorded a chain consistent with a document process launching PowerShell, creating persistence, and making a network connection. The process relationship and near-time agreement are mutually reinforcing. Nevertheless, the evidence does not by itself prove that user U intentionally opened a malicious document. A phishing attachment, automated document processing, remote control, or stolen session could produce similar records. The report should therefore distinguish recorded process activity from human attribution. 8. Applied Case Study: Illustrative Ransomware InvestigationBackgroundA university research workstation is suspected of encrypting a shared research folder. The workstation dual-boots are not involved; the investigation concerns a Windows endpoint used by a named researcher and several service accounts. ProblemInvestigators must determine whether encryption was caused by an authorised maintenance tool, a compromised account, or malware; identify persistence; and establish the likely sequence without altering evidence. Analysis and approachThe team isolates the system while preserving power when volatile data is required, documents the state, and acquires a verified forensic image. Memory is collected before shutdown because encryption keys, running processes, and network sessions may be transient. Event logs, EDR telemetry, Registry hives, scheduled tasks, Prefetch, user profiles, browser data, and shadow-copy information are examined. The timeline shows a successful remote logon using an account not normally used by the researcher. Minutes later, a signed remote-administration utility runs from an unusual directory. Process telemetry records a child process that enumerates network shares. A scheduled task is created for persistence, and multiple file-renaming operations occur under the same session. The task’s executable is unsigned and has a hash matching a known ransomware sample in the organisation’s threat-intelligence repository. Shadow copies are deleted shortly afterward. OutcomeThe evidence supports a conclusion that the workstation was used in a ransomware operation through a remote session and that persistence was established through a scheduled task. The account may have been compromised, but the endpoint evidence alone cannot identify the person who stole or used the credentials. The team preserves the relevant artifacts, records hashes, informs incident response, resets credentials, blocks the malicious indicators, and checks other systems for the same task and executable. Learning pointsThe case demonstrates the value of combining authentication, process lineage, persistence records, file activity, and threat intelligence. No single artifact proves the complete narrative. It also shows why volatile acquisition, time synchronisation, service-account governance, and central log retention are operational controls as well as forensic conveniences. 9. Professional, Ethical, and Governance ConsiderationsEndpoint evidence can contain private communications, health information, credentials, photographs, source code, and unrelated personal data. Investigators must operate under documented authority and apply proportionality, minimisation, access control, retention limits, and secure handling. Scope should specify devices, accounts, time periods, and questions. Examiners should avoid unnecessary browsing of unrelated content and should segregate privileged or legally protected material according to applicable procedures. Chain of custody should identify who collected, transferred, accessed, and stored evidence, with dates, purposes, and integrity checks. Tools should be validated against known test images and their versions recorded. Automated extraction and AI-assisted classification may accelerate triage, but outputs require human validation. AI systems can hallucinate interpretations, expose sensitive data, or reproduce biased assumptions. They should not be treated as independent proof; original artifacts and reproducible methods remain primary. Legal requirements differ across jurisdictions and may address search authority, employee monitoring, cross-border cloud evidence, data protection, and admissibility. Investigators should involve legal and privacy specialists where necessary. 10. Challenges, Limitations, and Best PracticesMajor challenges include encryption, secure deletion, SSD garbage collection, log rotation, anti-forensic manipulation, cloud dependence, proprietary formats, virtualisation, containerisation, clock error, and rapidly changing application storage. Attackers may clear logs, alter timestamps, use living-off-the-land tools, exploit legitimate remote-management software, or operate entirely in memory. Best practices are to: - define hypotheses and scope before examination;
- collect volatile evidence when justified and document order of volatility;
- preserve original data and work from verified copies;
- retain raw artifacts as well as parsed output;
- use multiple independent sources for important conclusions;
- record time zones, clock offsets, tool versions, and parsing assumptions;
- distinguish observation, interpretation, inference, and uncertainty;
- test tools and maintain reproducible procedures;
- protect personal and privileged information;
- report negative findings cautiously, because absence may reflect logging or retention limitations;
- maintain current knowledge of OS versions, security controls, file systems, and enterprise telemetry.
Contemporary DevelopmentsEndpoint detection and response platforms increasingly provide centralised process trees, script content, identity context, and cloud-assisted analytics. Enterprise operating systems also generate richer security telemetry, while zero-trust architectures distribute authentication and policy evidence across identity providers, management platforms, and endpoints. Virtual machines, containers, remote desktops, and synchronised cloud folders complicate the definition of “the endpoint.” Modern investigations therefore combine host artifacts with identity, network, cloud, and threat-intelligence sources. This creates better coverage but introduces correlation, privacy, retention, and evidential-independence problems. Research opportunities include standardised provenance models, robust timeline uncertainty representation, explainable automated triage, and methods for validating artifacts in encrypted and copy-on-write storage. Chapter SummaryOperating-system and endpoint forensics reconstructs system and user activity from artifacts created across storage, operating-system services, applications, and identity systems. Windows investigations commonly examine Registry hives, Event Logs, process and PowerShell records, Prefetch, Amcache, shell artifacts, and persistence locations. Linux investigations emphasise file-system metadata, authentication logs, journald, shell histories, audit records, package data, SSH evidence, and systemd or cron persistence. macOS investigations include APFS, unified logs, property lists, launch agents and daemons, quarantine data, authentication records, and application containers. Reliable conclusions depend on preservation, time normalisation, identity analysis, cross-artifact correlation, and explicit limitations. Deleted-file recovery is constrained by file-system behaviour, SSD processing, encryption, and snapshots. A timeline is an analytical model rather than a mere list of timestamps. Ethical practice requires lawful authority, privacy protection, chain of custody, validated tools, and careful separation of observations from inferences. AI and endpoint platforms can assist examination, but original evidence and expert verification remain essential. Key TermsArtifact: Data that records or reflects a system state or event. Chain of custody: Documented history of evidence possession, handling, and transfer. Endpoint: A computer or device connected to or participating in an information system. Event log: A structured or textual record generated by an operating system or application. File-system metadata: Information describing a file, such as name, size, ownership, and timestamps. Forensic image: A bit-level or logically defined copy acquired for examination. Journaling: File-system recording of changes to assist consistency and, sometimes, recovery. Launch daemon: A macOS system service commonly managed by launchd. Persistence: A mechanism that enables software or access to survive restart or logout. Prefetch: A Windows artifact associated with application loading and execution optimisation. Registry hive: A file containing a portion of the Windows Registry. Shimcache: Windows application-compatibility data that may provide path-related evidence. Shell history: A record maintained by a command interpreter of entered commands. Timeline: A chronologically organised and interpreted set of forensic events. Unallocated space: Storage not currently assigned to an active file-system object. UserAssist: Windows per-user data associated with graphical application and shortcut activity. Volatile evidence: Data likely to disappear or change when a system is powered off or altered. Write blocker: A hardware or software control intended to prevent modification of source media. Review QuestionsShort Answer Questions1. Why does the presence of an executable not prove that it was executed? 2. Distinguish a Registry key last-write time from the time of a user action. 3. Name two limitations of shell-history evidence on Linux. 4. Why can SSDs reduce the reliability of deleted-file recovery? 5. What information should be retained when normalising timestamps? Long Answer Questions1. Compare Windows, Linux, and macOS authentication artifacts and explain how each may be corroborated. 2. Explain how persistence mechanisms differ across the three operating systems and describe an examination method. 3. Discuss the evidential value and limitations of Windows Prefetch, Amcache, Shimcache, and UserAssist. 4. Describe a defensible endpoint-forensic workflow from preparation through reporting. 5. Explain how privacy, legal authority, chain of custody, and tool validation affect endpoint investigations. Analytical / Application Questions1. An SSH login, a shell-history entry, and a file modification occur within five minutes, but the system clock is found to be seven minutes slow. Construct a corrected timeline and identify what remains uncertain. 2. A Windows scheduled task launches an unsigned executable, but no process-creation log exists. Identify at least four additional artifacts that could support or challenge an execution hypothesis. 3. A deleted macOS document is recovered from a snapshot but has no original Finder record. Assess what can and cannot be concluded about its creation, access, and deletion. Multiple Choice Questions with AnswersQuestion 1Which artifact is primarily a per-user Windows configuration store? A. NTUSER.DAT B. The ext4 journal C. systemd-journald D. The macOS unified log Correct Answer: A. NTUSER.DAT Question 2What does a successful SSH authentication record establish most directly? A. The physical identity of the operator B. That the server recorded an authenticated session C. That commands were executed interactively D. That files were transferred Correct Answer: B. That the server recorded an authenticated session Question 3Why should a file-system access time be interpreted cautiously? A. It is always stored in local time B. It can be disabled, delayed, or suppressed C. It records only file deletion D. It is generated only by antivirus software Correct Answer: B. It can be disabled, delayed, or suppressed Question 4Which Windows evidence most directly supports a process parent-child relationship when configured? A. Process-creation auditing with command-line data B. A file extension C. A Registry hive filename D. A volume label Correct Answer: A. Process-creation auditing with command-line data Question 5Which is a common macOS persistence location? A. Launch agents B. The Linux shadow file C. Windows Prefetch D. The ext4 superblock Correct Answer: A. Launch agents Question 6What does file carving primarily use when directory metadata is unavailable? A. File signatures and internal structures B. User passwords C. Registry last-write times D. Network routing tables Correct Answer: A. File signatures and internal structures Question 7Which statement about a forensic hash is correct? A. It proves who created the file B. It proves that compared byte sequences are identical C. It guarantees the source image was complete D. It identifies the user at the keyboard Correct Answer: B. It proves that compared byte sequences are identical Question 8A scheduled task is found on a Windows system. What is the most appropriate immediate interpretation? A. The task is automatically malicious B. The task is evidence of a possible persistence or automation mechanism requiring context C. The task proves interactive execution D. The task proves data exfiltration Correct Answer: B. The task is evidence of a possible persistence or automation mechanism requiring context Question 9Which Linux mechanism can record security-relevant system-call activity when configured? A. auditd B. UserAssist C. LaunchServices D. Amcache Correct Answer: A. auditd Question 10Why should investigators preserve original artifact formats where possible? A. Parsed output is always inaccurate B. Conversion can lose fields or relationships needed for interpretation C. Original formats cannot be hashed D. It prevents all anti-forensic activity Correct Answer: B. Conversion can lose fields or relationships needed for interpretation
|