Unit 3: Data Acquisition and Windows Forensics

I. Orientation — Forensic Soundness and Evidence Integrity

Digital evidence analysis is the identification, preservation, acquisition, examination, analysis, and reporting of data with potential evidential value. Its governing principle is forensic soundness: investigators must preserve the original evidence, use reliable methods, document every action, and demonstrate that examined data is an authentic representation of what was collected.

• Integrity: Cryptographic hashes such as SHA-256 establish whether data changed between acquisition and examination.
• Repeatability: A competent examiner using the same image, tools, and procedure should obtain comparable results.
• Chain of custody: Records identify who collected, transferred, stored, or examined evidence, with dates, times, purposes, and signatures.
• Order of volatility: Data likely to disappear first—CPU state, network connections, processes, and RAM—is collected before persistent disk data when circumstances permit.
• Minimal alteration: Hardware or software write blockers prevent writes to storage media; live acquisition is documented because it necessarily modifies system state.
• Legal authority: Collection must remain within the scope of consent, organizational policy, warrant, court order, or other applicable authority.
• Evidence versus interpretation: An artifact is a recorded fact; conclusions require correlation among timestamps, logs, metadata, registry data, memory, and user activity.
• Time normalization: Examiners record the system clock, time zone, daylight-saving configuration, and clock drift before constructing timelines.

II. Data Acquisition — Creating a Defensible Forensic Copy

A. Data Acquisition Fundamentals

Data acquisition is the controlled copying of digital information from a source into a form suitable for preservation and examination.

• Physical acquisition: Copies every addressable sector, including allocated files, deleted-file remnants, unallocated space, and file-system slack.
• Logical acquisition: Copies selected files, folders, or logical volumes; it may omit deleted data and inaccessible file-system regions.
• Sparse or targeted acquisition: Collects specified artifacts, such as registry hives or browser databases, when time, authority, or storage is limited.
• Forensic image formats:
  • RAW/DD: A sector-for-sector stream with broad tool compatibility but little built-in metadata.
  • E01: Supports metadata, segmentation, compression, and internal integrity checks.
  • AFF/AFF4: Extensible formats designed to store image data and associated metadata.
• Write protection: A hardware write blocker is preferred for detached drives; its operation should be tested before use.
• Hash verification: A source or acquired image is hashed with an approved algorithm such as SHA-256.

SHA-256(image_before) = SHA-256(image_after)

Matching 256-bit digests support the conclusion that the image remained unchanged; a hash proves integrity, not ownership or relevance.

B. Data Acquisition Methodology

A defensible methodology converts collection into a documented and reproducible sequence.

• Preparation: Confirm legal authority, identify devices, synchronize the examiner’s clock, sanitize destination media, and prepare validated tools.
• Scene documentation: Photograph device connections and screens; record serial numbers, logged-in users, power state, encryption indicators, and network status.
• Triage decision: Choose live or dead-box acquisition according to volatility, encryption, operational impact, and risk.
  1. Live acquisition: Preserves RAM, active sessions, mounted encrypted volumes, and network state, but changes memory and disk artifacts.
  2. Dead-box acquisition: Powers down or removes media for controlled imaging, but loses volatile information and may leave encrypted data inaccessible.
• Acquisition: Connect through write protection where applicable, create the image, capture tool output, and record errors or unreadable sectors.
• Verification: Calculate acquisition and verification hashes; preserve the original image as read-only and examine a working copy.
• Documentation: Record tool name and version, commands, start and end times, source and destination identifiers, hashes, and examiner actions.

C. Preparing an Image for Examination

Image preparation ensures that examination occurs on a verified working copy without changing the preserved master.

• Validation: Recalculate the image hash and compare it with the acquisition record before analysis.
• Master and working copies: Secure the master in controlled storage; conduct examinations on a duplicate or verified read-only mount.
• Mounting: Mount partitions read-only and note sector size, partition offsets, volume labels, file systems, and encryption status.
• File-system review: Identify NTFS, FAT, exFAT, ReFS, recovery partitions, volume shadow copies, and unsupported or damaged structures.
• Indexing: Generate file listings, hashes, MIME or signature classifications, keyword indexes, and thumbnail databases.
• Known-file filtering: Compare hashes with trusted known-good sets to reduce irrelevant operating-system files; known-bad sets can flag previously identified material.
• Recovery preparation: Parse deleted entries and carve unallocated space by file signatures, recognizing that carved files may lack names, paths, and metadata.
• Auditability: Preserve examination logs, tool versions, configuration settings, and exported artifact hashes.

D. Collection of Volatile and Non-volatile Information

Collection order balances the short lifespan of live data against the need to preserve persistent evidence.

• Volatile information: Includes RAM, running processes, loaded modules, logged-on sessions, open files, clipboard contents, command history, network connections, ARP cache, and encryption keys.
• Non-volatile information: Includes internal drives, removable media, registry hives, browser databases, event logs, pagefile, hibernation data, and backups.
• Recommended live sequence: Record system time and screen state, collect network and process information, acquire memory, and then collect persistent media.
• Trusted tools: Collection programs should run from controlled external media; their executable hashes and command lines should be recorded.
• Contamination: Every live command consumes memory and can create logs or temporary files, so actions must be minimized and documented.
• Shutdown choice: Pulling power may preserve disk state but risks data loss; normal shutdown writes extensively to disk. The decision depends on encryption, malware, system type, and investigative policy.

III. Memory Forensics — Reconstructing Live System State

A. Windows Memory Analysis

Windows memory analysis examines a RAM image to recover runtime evidence that may never exist on disk.

• Acquisition context: Record Windows version, architecture, hostname, capture time, tool, and whether virtualization or hibernation was involved.
• Process analysis: Enumerate active and terminated processes, parent-child relationships, start times, command lines, tokens, handles, and loaded DLLs.
• Anomaly indicators: Unexpected parent processes, hidden processes, executable memory, injected code, unsigned modules, and suspicious command lines may indicate compromise.
• Network evidence: Recover TCP/UDP endpoints, local and remote addresses, ports, owning processes, and connection states.
• User activity: Memory may contain console commands, clipboard text, browser fragments, credentials, chat content, and decrypted documents.
• Kernel evidence: Drivers, callbacks, hooks, and kernel objects can reveal rootkits or persistence mechanisms.
• Correlation: A connection attributed to a process becomes stronger evidence when its timestamp, executable hash, registry persistence, and firewall or event logs agree.
• Limitation: RAM is a time-specific, incomplete snapshot; swapped-out, overwritten, or corrupted pages can produce gaps.

IV. Registry Forensics — Examining Windows Configuration Databases

A. Windows Registry Analysis

The Windows Registry stores system, software, user, and device configuration in hierarchical hives containing keys, values, and timestamped metadata.

• Major hives:
  • SYSTEM: Services, drivers, control sets, and computer configuration.
  • SOFTWARE: Installed software and system-wide application settings.
  • SAM: Local account information and relative identifiers.
  • SECURITY: Local security policy and protected secrets.
  • NTUSER.DAT/UsrClass.dat: User-specific settings, shell activity, and application artifacts.
• Persistence evidence: Run keys, services, scheduled-task references, and shell settings can identify programs configured to start automatically.
• User activity: Recent-document lists, UserAssist, typed paths, shellbags, and application-specific keys may indicate execution or folder interaction.
• Device history: USB-related keys can reveal device identifiers, friendly names, and prior connection information.
• Timestamps: A registry key’s last-write time records modification of the key, not necessarily creation or access of every contained value.
• Transaction data: Hive transaction logs may help reconstruct recent changes or recover a consistent hive.
• Interpretive caution: Registry artifacts vary across Windows versions and can be modified by software, synchronization, cleanup tools, or administrators.

V. Browser Forensics — Reconstructing Web Activity

A. Cache, Cookie, and History Examination in Web Browsers

Browser artifacts can reveal visited resources, stored content, authentication state, searches, downloads, and user interaction.

• Cache: Stores local copies of images, scripts, pages, and media to improve performance; cached content may survive after history deletion.
• Cookies: Store domain-scoped name-value data such as session identifiers, preferences, tracking values, creation times, and expiry times.
• History: Records visited URLs, titles, visit counts, transition types, and timestamps, commonly in SQLite databases.
• Downloads: Browser records may identify source URL, destination path, start and completion times, file size, and interruption status.
• Session artifacts: Open tabs, recently closed tabs, form data, and recovery files can reconstruct browsing immediately before a crash or shutdown.
• Private browsing: Reduces locally retained history but does not eliminate RAM remnants, DNS data, downloaded files, router logs, or server-side records.
• Analysis method: Examine copied databases with associated write-ahead logs and journals; opening the original database may alter it.
• Attribution limit: A browser record shows activity within a profile, but user attribution requires correlation with logon, device, and timeline evidence.

VI. File-System Forensics — Content, Structure, and Time

A. Windows Files and Metadata Examination

Windows file examination combines file content with NTFS structures and metadata to determine origin, use, alteration, and deletion.

• NTFS records: The Master File Table stores file names, attributes, data locations, security information, and timestamps.
• Timestamp sets: NTFS commonly records creation, modification, MFT-entry change, and access times in $STANDARD_INFORMATION and $FILE_NAME.
• Alternate data streams: NTFS permits additional named streams, potentially concealing data beyond the normal file content.
• Deleted files: Deletion usually marks records and clusters available for reuse; recovery depends on whether metadata and content were overwritten.
• Link files: .lnk files may preserve target paths, volume identifiers, file sizes, and timestamps even when the target is absent.
• Prefetch: Where enabled, .pf files can support program-execution analysis through executable names, referenced resources, and run information.
• Document metadata: Office documents, PDFs, images, and media may contain authors, application versions, revision dates, GPS coordinates, or device models.
• Signature checking: A file extension such as .jpg should be compared with its internal header; mismatches can indicate renaming or concealment.

VII. Plain-Text Evidence — Human-Readable Activity Records

A. Text-based Logs

Text-based logs record application, server, security-tool, and script activity in formats such as plain text, CSV, JSON, XML, or line-delimited records.

• Common sources: Web servers, firewalls, antivirus products, VPN clients, PowerShell transcripts, installers, backup tools, and custom applications.
• Parsing fields: Extract timestamp, host, user, process, source and destination address, event type, status code, and message.
• Time issues: Logs may use local time, UTC, offsets, or no time zone; clock drift and rotation boundaries must be documented.
• Search strategy: Filter on usernames, IP addresses, domains, file hashes, error codes, and narrow time windows before expanding.
• Rotation and compression: Numbered, dated, or compressed archives may contain earlier events missing from the active log.
• Integrity concerns: Plain text is easily edited, so validate through hashes, permissions, centralized copies, and corroborating records.
• Interpretation: Absence of a line does not prove absence of an event; logging may have been disabled, filtered, overwritten, or misconfigured.

VIII. Event-Log Forensics — Structured Windows Activity Records

A. Windows Event Logs

Windows Event Logs are structured .evtx records generated by the operating system, services, applications, and auditing components.

• Primary channels: System records operating-system components; Application records software events; Security records audited security activity.
• Event structure: Records typically contain provider, event ID, level, computer, timestamp, record ID, user security identifier, and event-specific data.
• Useful evidence: Logs can support analysis of logons, process creation, service installation, account changes, audit-policy changes, crashes, and shutdowns.
• Identification: Event ID must be interpreted with its provider, Windows version, channel, and configured audit policy; the number alone is insufficient.
• Logon analysis: Successful and failed authentication records should be correlated with logon type, account, source workstation, source address, and related session identifiers.
• Collection: Preserve original .evtx files and export parsed views separately; record hashes and include archived channels where available.
• Tampering indicators: Unexpected log clearing, service interruption, missing record ranges, or inconsistent timestamps may indicate deletion or manipulation.
• Correlation: Event logs gain evidential strength when aligned with registry changes, prefetch, browser history, memory findings, and external network logs.