Unit 3: Data Acquisition and Windows Forensics - Subjective Questions

Data acquisition is the process of collecting and creating a forensic copy of data from a digital device or storage medium for examination and analysis.

The fundamental principles are:

• Preservation of original evidence: The original device should not be modified. A hardware or software write blocker should be used whenever appropriate.
• Forensic completeness: The acquisition should capture all relevant data, including allocated files, deleted files, unallocated space, slack space, and metadata.
• Integrity verification: Cryptographic hash values are calculated before and after acquisition. Integrity is established when .
• Repeatability: Another competent examiner should be able to repeat the process and obtain equivalent results.
• Documentation: Investigators must record the date, time, device details, tools, settings, errors, and personnel involved.
• Chain of custody: Every transfer, examination, and storage action involving the evidence must be documented.
• Legal authorization: Acquisition must remain within the scope of a warrant, consent, organizational policy, or other lawful authority.

The three acquisition methods differ in the amount and type of data collected.

Physical acquisition

A physical acquisition creates a sector-by-sector or bit-stream copy of the storage medium.

• Captures allocated data, unallocated space, file slack, deleted data remnants, partitions, and file-system metadata.
• Provides the most comprehensive source for forensic examination.
• Requires more storage space and acquisition time.
• May be difficult on encrypted, damaged, or access-restricted devices.

Logical acquisition

A logical acquisition collects files and directories through the operating system, file system, application interface, or backup mechanism.

• Faster and smaller than physical acquisition.
• Useful when only active files are required or physical access is unavailable.
• Usually excludes unallocated space, slack space, and some deleted data.
• May alter access metadata if performed without suitable precautions.

Sparse or targeted acquisition

A sparse acquisition collects selected sectors, file types, folders, or artifacts relevant to the investigation.

• Useful during incident response or when time, bandwidth, or storage is limited.
• Can prioritize logs, registry hives, browser artifacts, and documents.
• Risks omitting evidence that later becomes important.
• Selection criteria must be clearly documented and legally justified.

Comparison

• Completeness: Physical is generally highest; logical and targeted methods are more selective.
• Speed: Targeted is generally fastest, followed by logical and then physical acquisition.
• Deleted-data recovery: Physical acquisition normally offers the best opportunity.
• Use cases: Physical acquisition suits laboratory analysis, logical acquisition suits accessible active data, and targeted acquisition suits triage or urgent response.

The examiner should select the least intrusive method that still satisfies the investigative and legal requirements.

A systematic acquisition methodology includes the following stages:

1. Obtain authorization: Confirm the warrant, consent, policy, or incident-response authority and identify its scope.
2. Prepare resources: Select validated tools, write blockers, sterile storage media, cables, evidence bags, labels, and documentation forms.
3. Assess the scene: Record device condition, power state, connections, users, date and time, visible applications, and possible encryption.
4. Choose the acquisition strategy: Decide between live, dead-box, physical, logical, or targeted acquisition based on volatility and risk.
5. Collect volatile evidence: If justified, acquire RAM, network connections, running processes, logged-on users, and system time before shutdown.
6. Protect the source: Use a write blocker for non-volatile media and avoid unnecessary interaction with the original device.
7. Create the forensic image: Record tool name, version, settings, source identifiers, destination, start time, end time, and any errors.
8. Calculate hashes: Generate cryptographic hashes for the source where possible and for the acquired image.
9. Verify the image: Confirm that the calculated hash values match and test whether the image can be mounted read-only.
10. Package and store evidence: Seal the original media, update the chain-of-custody record, and store evidence securely.
11. Create working copies: Conduct analysis on verified copies rather than on the original evidence.

These controls demonstrate that digital evidence has remained authentic and reliable.

• Write blockers: A hardware or software write blocker prevents write commands from reaching the source medium. It reduces the risk of changing file contents, timestamps, metadata, or file-system structures during acquisition.
• Cryptographic hashing: A hash algorithm produces a fixed-length digest representing the acquired data. The source and image hashes are compared using . Recalculation at later stages can show that the evidence has not changed.
• Chain of custody: This is a chronological record of evidence possession and handling. It identifies who collected, transferred, examined, stored, or returned the evidence, together with relevant dates, times, and purposes.

For strong evidential reliability, the examiner should also:

• Use validated forensic tools and record their versions.
• Document any unavoidable modification or acquisition error.
• Seal and label original media correctly.
• Store originals and master images in access-controlled locations.
• Perform analysis on verified working copies.

A hash does not independently prove who collected the evidence or whether the correct device was seized; therefore, hashing must be supported by complete documentation and chain-of-custody controls.

Preparation should preserve the master image while producing a controlled examination environment.

• Verify integrity: Recalculate the image hash and compare it with the acquisition hash.
• Preserve the master: Mark the master image as read-only and place it in secure evidence storage.
• Create a working copy: Duplicate the verified master and calculate a hash for the working copy.
• Validate the format: Confirm that all segments of formats such as E01 or AFF are present and readable.
• Mount safely: Attach the working image in read-only mode or load it into a forensic suite that does not alter the image.
• Identify partitions and file systems: Locate normal, hidden, deleted, encrypted, and recovery partitions.
• Check encryption and compression: Determine whether credentials, recovery keys, or specialized tools are required.
• Configure analysis settings: Set the correct time zone, character encoding, hash sets, keyword lists, and file-type signatures.
• Index and parse artifacts: Build searchable indexes and parse registry, browser, log, and file-system artifacts.
• Document actions: Record tools, versions, settings, time-zone assumptions, hash results, and processing errors.

Volatile information is data that may change or disappear when a system is powered off, restarted, disconnected, or allowed to continue operating.

A practical order of volatility is:

1. CPU registers and cache, where technically feasible.
2. System date, time, and time-zone information.
3. Active network connections, listening ports, ARP cache, and routing data.
4. Running processes, loaded modules, services, handles, and logged-on sessions.
5. Clipboard contents, command history, and temporary authentication information.
6. Physical memory or RAM.
7. Temporary files and other rapidly changing system data.
8. Persistent storage, including disks, logs, and registry hive files.

RAM may reveal malware, encryption keys, commands, injected code, unsaved content, and network sessions. However, collecting volatile data necessarily changes system state. Therefore, the examiner must use trusted tools, minimize interaction, record every command, preserve tool output, and document the collection time and system condition.

Non-volatile information persists after power is removed and is commonly stored on hard drives, solid-state drives, removable media, and firmware-backed storage.

The collection procedure should include:

• Photographing and labeling the device and recording make, model, capacity, and serial number.
• Isolating the device according to the approved procedure.
• Removing storage media when appropriate and connecting it through a write blocker.
• Creating a physical or logical forensic image with a validated tool.
• Computing and recording cryptographic hash values.
• Preserving the original device and analyzing a verified working copy.

Important artifacts include:

• User files, program files, and system files.
• File-system metadata and partition structures.
• Deleted files, unallocated space, and file slack.
• Registry hive files and transaction logs.
• Windows Event Logs and text-based application logs.
• Browser cache, cookies, history, downloads, and session data.
• Page files, hibernation files, crash dumps, and restore points.
• Shortcut files, Jump Lists, Recycle Bin records, and prefetch data.

The examiner must consider SSD garbage collection, TRIM, encryption, hidden partitions, and cloud-synchronized content when selecting the collection method.

Live acquisition is performed while the computer is running, whereas dead-box acquisition is performed after the system has been shut down and its storage is accessed independently.

Live acquisition

• Captures RAM, running processes, network sessions, mounted encrypted volumes, logged-on users, and temporary data.
• Is appropriate when full-disk encryption is active, shutting down would destroy evidence, or immediate incident-response data is needed.
• Alters the system because forensic tools and commands consume memory and processor resources.
• May trigger malware, anti-forensic mechanisms, or remote activity.

Dead-box acquisition

• Allows storage to be imaged through a write blocker with minimal change to the source.
• Is more repeatable and usually preferred for complete disk acquisition.
• Does not preserve RAM contents, active sessions, or keys held only in memory.
• May make encrypted data inaccessible if the decryption key is lost during shutdown.

The choice should be based on system state, encryption, volatility, safety, legal authority, and investigative objectives. When live acquisition is necessary, the examiner should collect the most volatile evidence first, use trusted tools, and document all resulting changes.

Windows memory analysis examines a captured RAM image to reconstruct the state of a running system.

Major stages

1. Verify the image: Calculate a cryptographic hash and preserve the original memory image.
2. Identify system characteristics: Determine the Windows version, architecture, kernel information, and acquisition time.
3. Enumerate execution: Recover active and terminated processes, process trees, threads, handles, services, and loaded modules.
4. Analyze networking: Identify sockets, listening ports, remote addresses, and process-to-connection relationships.
5. Inspect memory regions: Examine virtual address descriptors, executable memory, mapped files, heaps, and suspicious permissions.
6. Search for hidden activity: Compare multiple process-enumeration methods and inspect unlinked or manipulated kernel structures.
7. Extract artifacts: Dump suspicious processes, DLLs, drivers, command lines, registry data, console history, and strings.
8. Correlate findings: Compare memory evidence with disk files, event logs, network records, and timeline data.

Recoverable artifacts

• Running and recently terminated processes.
• Process IDs, parent-child relationships, command lines, and environment variables.
• Loaded DLLs, kernel drivers, services, and open handles.
• Network connections, sockets, and cached network information.
• In-memory malware, injected code, and unpacked executables.
• Decryption material or credentials, subject to legal authority and tool capability.
• Clipboard data, console commands, unsaved text, and fragments of communications.
• Registry keys and file-system data cached in memory.

Memory analysis is valuable because malicious code may be encrypted or absent on disk but visible in its active, decompressed form in RAM.

An examiner should combine structural comparison, memory-region inspection, and network correlation.

• Process-tree analysis: Identify unusual parent-child relationships, unexpected execution paths, misleading names, or system processes running under incorrect parents.
• Cross-view comparison: Compare active process lists with scans for residual process structures. A process found by scanning but absent from normal linked lists may be terminated, hidden, or unlinked.
• Memory permission checks: Look for private regions with executable permissions, especially writable and executable pages.
• Injected-code indicators: Examine regions that lack a legitimate mapped file, contain portable executable headers, or hold suspicious shellcode-like instructions.
• Module comparison: Compare normally loaded modules with mapped or scanned modules to detect unlinked DLLs.
• Thread analysis: Identify threads whose start addresses point to private or unexpected executable regions.
• Network correlation: Map sockets and remote endpoints to owning processes, then investigate unusual destinations, ports, or connections owned by unexpected executables.
• Extraction and validation: Dump suspicious regions or processes, calculate hashes, inspect strings and imports, and scan them with trusted analytical tools.

No single indicator proves injection or concealment. Findings should be correlated with executable signatures, disk artifacts, event logs, persistence mechanisms, and threat intelligence before reaching a conclusion.

The Windows Registry is a hierarchical database containing operating-system, hardware, application, security, and user configuration information. It is organized into keys, subkeys, values, and associated metadata such as key last-write times.

Major hives include:

• SYSTEM: Contains control sets, services, drivers, device configuration, computer name, network settings, and time-zone information.
• SOFTWARE: Stores operating-system and installed-application configuration, version details, and some startup entries.
• SAM: Contains local account information and security-related account data. Access and interpretation require appropriate authority.
• SECURITY: Stores local security policy and cached security-related information.
• NTUSER.DAT: A per-user hive containing user preferences, recently used items, application settings, and user-level execution artifacts.
• UsrClass.dat: Stores per-user shell and class-registration information, including artifacts relevant to folder and shell interaction.
• DEFAULT: Contains settings used for system and default logon contexts.

Registry evidence can establish persistence, user activity, connected devices, installed software, network configuration, and system settings. Examiners should also collect transaction logs because they may contain recent or recoverable registry changes.

Registry artifacts support reconstruction by recording system-wide and per-user configuration changes.

• User activity: Recent-document lists, typed paths, search terms, dialog histories, and shell-related keys may show files or locations accessed by a user.
• Program execution: UserAssist, application compatibility artifacts, and other execution-related keys may indicate that a program was launched. Interpretation depends on the Windows version and artifact semantics.
• Connected devices: USB storage and device-enumeration keys may identify device type, vendor, product, serial information, and prior connection to the system.
• Persistence mechanisms: System-wide and per-user startup keys, service definitions, shell modifications, and related entries may cause programs to execute at boot or logon.
• Network activity: Network profile and interface keys can reveal configured adapters, prior networks, addresses, and related timestamps.
• Account information: Profile-list and account-related keys can associate security identifiers with user-profile paths.

For reliable interpretation, the examiner should:

1. Preserve the hive files and transaction logs.
2. Record each key's path, value, data type, and last-write time.
3. Account for control sets, user security identifiers, and Windows version differences.
4. Correlate registry timestamps with event logs, file metadata, browser records, and shortcut artifacts.

A registry key's last-write time generally applies to the key rather than to each individual value, so conclusions must not exceed what the artifact actually proves.

Browser artifacts record different aspects of web activity.

• Cache: Stores local copies of downloaded web resources such as images, scripts, style sheets, and documents. It may reveal viewed content even when the original website is unavailable, but cached resources do not always prove that the user deliberately viewed every item.
• Cookies: Store small pieces of data set by websites, including session identifiers, preferences, tracking identifiers, domains, paths, and expiration times. Cookies can support attribution of sessions or site interaction, but they may be shared, synchronized, or created automatically.
• History: Records visited URLs and may include page titles, visit counts, transition types, and timestamps. It is useful for building a browsing timeline, although private browsing, deletion, synchronization, or browser settings may create gaps.

Other useful browser artifacts include:

• Download records and downloaded-file paths.
• Form and search history.
• Bookmarks and favorites.
• Saved sessions and open tabs.
• Autofill databases and extension data.
• Local storage, session storage, and indexed application data.

These artifacts should be correlated with DNS records, cache files, file metadata, event logs, and network evidence before drawing conclusions about user intent.

A structured browser examination may proceed as follows:

1. Identify browsers and profiles: Locate installed browsers, profile directories, portable installations, and multiple user profiles.
2. Preserve relevant data: Acquire browser databases, cache directories, cookies, history, session files, local storage, preferences, extensions, and journal files.
3. Work on copies: Hash the collected files and analyze verified copies rather than active browser profiles.
4. Parse native structures: Interpret SQLite databases, cache indexes, JSON files, binary records, and write-ahead logs with validated tools.
5. Normalize time values: Convert browser-specific timestamps to a common time zone while preserving the original values.
6. Recover deleted records: Examine unallocated database pages, SQLite free lists, journal files, write-ahead logs, file slack, and disk unallocated space.
7. Analyze downloads: Correlate source URLs, target paths, start and completion times, file hashes, and file-system metadata.
8. Investigate private browsing: Search RAM, page files, hibernation files, DNS caches, temporary files, crash data, and operating-system logs for residual evidence.
9. Correlate artifacts: Compare browser records with cache objects, cookies, registry data, shortcut files, and network logs.
10. Report limitations: Explain clock differences, synchronization, profile sharing, automatic requests, deleted data, and incomplete private-mode retention.

Private browsing reduces local retention but does not guarantee that no evidence exists elsewhere on the system or network.

NTFS metadata records how files and directories are named, stored, timestamped, secured, and changed.

• Master File Table: The MFT contains a record for each file and directory. Records may include file names, timestamps, attributes, security references, and pointers to stored data.
• File-name and standard-information attributes: These may maintain different timestamp sets, allowing comparison for inconsistency or manipulation.
• Directory indexes: Directory structures can retain information about active and sometimes previously referenced entries.
• Change journal: The USN change journal records file and directory change events such as creation, deletion, renaming, and data modification.
• NTFS log file: Transaction records may assist in understanding recent file-system operations and recovering historical metadata.
• Bitmap: Indicates which clusters are allocated or unallocated.
• Alternate data streams: Additional named streams can conceal or store data associated with a file.
• Unallocated space and slack: These areas may contain remnants of deleted files or previous content.

By correlating file contents with MFT entries, change records, logs, and application artifacts, an examiner can reconstruct file creation, modification, movement, renaming, deletion, and possible concealment.

Windows file systems commonly maintain timestamps associated with file creation, modification, access, and metadata-entry changes. These are often summarized as MACB times, although exact meanings and update behavior depend on the file system and Windows configuration.

Possible timestomping indicators include:

• Conflicts between timestamp sets stored in different NTFS attributes.
• A file timestamp that predates operating-system installation, application installation, or directory creation.
• Multiple unrelated files with identical or unnaturally rounded timestamp values.
• Mismatch between file timestamps and compilation, signing, download, archive, or document metadata.
• Change-journal or transaction-log entries showing activity later than the displayed file times.
• Prefetch, shortcut, Jump List, browser-download, registry, or event-log records that contradict the file's timestamps.
• Sequence or record information suggesting recent creation despite old displayed times.

The examiner should preserve raw timestamp values, document the time zone and clock condition, and construct a multi-source timeline. Timestamp inconsistency is an indicator rather than automatic proof of malicious manipulation because copying, restoring, extracting archives, synchronization, and software behavior can legitimately alter timestamps.

These areas may preserve content that is not visible through ordinary directory browsing.

• Deleted files: Examine deleted MFT records and directory entries. If content clusters have not been overwritten, the file may be recoverable with its name and metadata.
• File carving: Search unallocated space for known file signatures and structural patterns. Carving can recover content when file-system metadata is missing, though filenames and original paths may be lost.
• File slack: Inspect unused bytes between a file's logical end and the end of its allocated storage unit. Slack may contain fragments of previous data.
• Unallocated space: Search for documents, images, messages, database fragments, registry remnants, and other deleted content.
• Alternate data streams: Enumerate named NTFS streams, compare stream sizes, and extract suspicious streams for type and hash analysis.
• Validation: Check recovered file headers, footers, internal structure, hashes, and application readability.
• Correlation: Relate recovered content to MFT metadata, change journals, logs, browser activity, and user artifacts.

Recovery is not guaranteed. Data may have been overwritten, encrypted, compressed, fragmented, or removed by SSD TRIM and garbage collection. The report should distinguish complete recovery from partial or inferred recovery.

Text-based logs are records stored in readable or delimited formats such as plain text, CSV, JSON, XML, or application-specific text. Examples include web-server logs, firewall logs, antivirus logs, installer logs, PowerShell transcripts, and application logs.

A sound examination process includes:

• Collection: Acquire active and rotated logs, compressed archives, configuration files, and logs from centralized servers when authorized.
• Preservation: Copy logs using a controlled method, calculate hashes, and record source paths, host information, collection time, and access permissions.
• Format identification: Determine delimiters, field order, character encoding, line endings, and whether multiline entries are used.
• Time normalization: Identify the recorded time zone, daylight-saving behavior, and clock drift. Preserve original timestamps and create normalized values for correlation.
• Parsing: Extract fields such as timestamp, host, user, process, action, source address, destination, status, and message.
• Analysis: Search for authentication failures, privilege changes, suspicious commands, unusual addresses, error bursts, and evidence of log deletion or rotation.
• Correlation: Compare entries with event logs, browser records, file metadata, memory evidence, and network captures.

Investigators must account for forged entries, missing records, inconsistent clocks, altered configuration, retention limits, and variable application formats.

Windows Event Logs are structured records generally stored in EVTX files. Each event can include a channel, provider, event identifier, level, computer name, security context, timestamp, record identifier, and event-specific data.

Important channels include:

• Security: Logons, account activity, privilege use, process creation when enabled, and audit-policy events.
• System: Service, driver, shutdown, startup, hardware, and operating-system events.
• Application: Events produced by applications and services.
• PowerShell and operational channels: Script-engine activity and component-specific diagnostic records, depending on configuration.

An examiner can reconstruct an incident by:

1. Preserving EVTX files and associated metadata from the image or live system.
2. Identifying the audit policy and determining which events could have been recorded.
3. Filtering by time range, user, host, provider, event identifier, process, and network address.
4. Correlating logon sessions with process creation, service installation, scheduled activity, privilege use, and network connections.
5. Searching for service changes, new accounts, group membership changes, audit-policy modification, and log clearing.
6. Building a normalized timeline and comparing it with registry, memory, browser, file-system, and external log evidence.

The absence of an event does not prove that an action did not occur. Logging may have been disabled, records may have rotated, or an attacker may have cleared or modified logs.

An integrated plan should preserve volatile evidence first and then correlate artifacts from independent sources.

1. Authorization and preparation

• Confirm legal authority, objectives, affected users, and collection scope.
• Prepare validated tools, sterile media, write blockers, documentation, and secure storage.
• Photograph the workstation and record its screen, connections, power state, date, time, and apparent time zone.

2. Live and volatile collection

• Consider network isolation without immediately powering off the system.
• Record system time, logged-on users, processes, services, network connections, routes, and listening ports.
• Capture RAM before shutdown because it may contain injected malware, command lines, sessions, and encryption material.
• Hash all outputs and document every command and resulting system change.

3. Non-volatile acquisition

• Select a controlled shutdown method only after volatile evidence has been collected and risks assessed.
• Image storage through a write blocker using physical acquisition where feasible.
• Calculate and record source and image hashes, preserve the master, and create a working copy.

4. Memory analysis

• Reconstruct process trees, loaded modules, drivers, handles, command lines, and network sockets.
• Search for hidden processes, injected executable regions, suspicious thread start addresses, and unlinked modules.
• Dump suspicious components and correlate their hashes and paths with disk evidence.

5. Registry analysis

• Examine service and startup locations, user-level persistence, installed software, connected devices, network profiles, and program-execution artifacts.
• Include hive transaction logs and record key last-write times carefully.

6. Browser examination

• Parse history, cache, cookies, downloads, sessions, local storage, and database journals for every profile.
• Recover deleted records where possible and compare URLs with network endpoints found in memory.

7. File and metadata analysis

• Examine the MFT, change journal, transaction logs, alternate data streams, unallocated space, and suspicious executables.
• Compare timestamp sets and external artifacts for signs of timestomping.

8. Log analysis and reporting

• Review Security, System, Application, PowerShell, antivirus, firewall, and application logs.
• Normalize timestamps and build a combined timeline of logons, browser activity, process execution, file changes, persistence, and network communication.
• Report facts separately from interpretations, document limitations, preserve hashes, and maintain the chain of custody throughout.