Windows Forensics

• Windows Forensics
  • Windows Registry
    • Root Keys
    • User Log-on and Log-off
    • USB Device History
    • Other Forensically Interesting Registry Keys
  • Event Logs
    • Security Audit Policy
    • Viewing Event Logs
    • Log-on Attempts
  • Link Files (Shortcuts)
  • Recycle Bin
  • Application Metadata
    • Microsoft Office Metadata
    • Multimedia File Metadata (Exif)
  • Web Browser Forensics
  • E-mail Forensics
    • Retrieval Protocols
    • Finding E-mail Archives
    • Analyzing E-mails
  • Installed Programs
    • Prefetch Files
  • Forensic Timelines
    • Timeline Creation Tools
    • Timeline Investigation Approaches
    • Timeline Pitfalls
  • Further Reading

Windows systems leave a remarkably complete record of user activity. This document covers the principal forensic evidence sources in Windows: the Registry, event logs, link files, the Recycle Bin, application metadata, browser history, e-mail archives, installed programs, and forensic timelines.

A key principle runs through all of this: it is easy to forge data in one place, but very difficult to forge it consistently in every place it is recorded. The Registry and event logs should tell the same story. Application metadata timestamps, file system metadata timestamps, and Registry entries should be mutually consistent. Unexplained discrepancies are a strong indicator of tampering.

Windows Registry

The Registry is Windows’ persistent configuration store. If Windows remembers something across a reboot, it is in the Registry. It records user activity, hardware history, installed software, recently accessed files, and much more.

Storage: Registry data is stored in binary files called hives, located at:

• C:\Windows\system32\config\ — system-wide hives
• C:\Users\<username>\ntuser.dat — per-user hive

Structure: a Registry hive is a hierarchy of keys (analogous to directories) and values (analogous to files). Values can be binary, plaintext, or hexadecimal. Every key has a last written timestamp — not shown by the default regedit.exe, but visible in tools like Registry Commander or via export to plaintext.

Root Keys

User Log-on and Log-off

To identify the last account that logged in:

Hive:  HKLM\SOFTWARE
Key:   Microsoft\Windows\CurrentVersion\Authentication\LogonUI
Value: LastLoggedOnUser       (username)
Value: LastLoggedOnSAMUser    (domain\username)

To find the last shutdown time:

Hive:  HKLM\SYSTEM
Key:   <CurrentControlSet>\Control\Windows
Value: ShutdownTime   (binary timestamp)

Cross-referencing the shutdown time with the last write time on each user’s ntuser.dat can identify which account was logged in when the machine was shut down.

USB Device History

Every USB device ever connected to the machine leaves a Registry entry:

HKLM\SYSTEM\CurrentControlSet\Enum\USBSTOR

Under USBSTOR, there are two levels of subkeys:

1. Device class key — named with the device type description (e.g., “Cruzer micro 1GB flash storage”)
2. Instance key — named with the device’s serial number (or a pseudorandom ID prefixed with & if the device has no serial number)

This lets an investigator link a specific physical device to this machine, and link the device to a time period.

First installation time: search for the device serial number in C:\Windows\setupapi.dev.log. The log records the date and time the device was first connected.

Last attachment time: the last written timestamp on the key at HKLM\SYSTEM\CurrentControlSet\Enum\USB\<hardware ID> indicates the last time the device was attached.

All-time device history (Vista/7): HKLM\Software\Microsoft\Windows Portable Devices\Devices — lists all devices ever connected, with display names.

Caution: connecting a confiscated USB device to a forensic workstation will create a new entry on that workstation. Use a software write blocker before connecting any evidence device.

Other Forensically Interesting Registry Keys

Event Logs

Windows provides a centralized event logging service. Applications and the OS write timestamped records to log files stored at C:\Windows\system32\winevt\logs\. Since Vista, logs use the well-documented .evtx (XML-based) format.

Each event record includes: date/time, user account, computer name, event ID, and a description.

Forensic value: event logs and Registry data should be mutually consistent. They record the same activity independently. Discrepancies between them are a strong signal of tampering.

Security Audit Policy

The volume and detail of event log data depends on the local security audit policy. Home versions of Windows log very little by default; server versions log extensively. The audit policy itself is a forensic artifact — a machine with auditing disabled may have been deliberately configured that way.

Viewing Event Logs

Event logs can be opened in Windows Event Viewer (on the original system or on another Windows machine running the same OS version). Since descriptions are assembled from Registry entries and application DLLs, viewing logs on a different system may yield incomplete descriptions.

Options for offline analysis:

1. Collect on the live system before shutdown (shutdown itself adds events to the logs)
2. Open on a machine running the same Windows version (system event descriptions will be correct; application descriptions may not be)
3. Boot the forensic image in a virtual machine to ensure the application DLLs are present

Log-on Attempts

The security event log, filtered by task category (Logon/Logoff) and keyword (Audit Success / Audit Failure), shows a timestamped record of all login attempts. A sequence of rapid failed logons is a classic brute-force indicator. Correlate with network traffic for the same time window to trace the source.

Link Files (Shortcuts)

Link files (.lnk files) are created automatically by Windows when:

• Programs are installed
• Files are opened from the desktop or Start menu
• Files are accessed via Windows Explorer recent items

Each link file contains:

• The full path to the target file, including the drive letter or volume serial number
• The serial number and volume label of the storage device containing the target
• A last-accessed timestamp (when the shortcut was clicked)

Forensic significance:

• If a user opened a file on an external USB drive that is no longer present, the link file on the desktop or in the recent items folder still records the full path and the device’s serial number — connecting the user to content on a device that has since been removed
• A shortcut to a folder of illegal files, with a recent access timestamp that correlates with Registry and event log entries showing the user was logged in, directly rebuts a claim of ignorance

Recycle Bin

From NTFS’s perspective, the Recycle Bin is just another folder. From a forensics perspective, it records deliberate deletion attempts.

When a user “deletes” a file, Windows moves it to the Recycle Bin rather than actually deleting it. The actual NTFS deletion happens only when the Recycle Bin is “emptied.”

Structure: C:\$Recycle.Bin\<SID+RID>\ — one subdirectory per user account, named with the account’s full security identifier.

Per-deleted-file pair:

• $R<random><ext> — the file’s actual content (renamed to avoid collisions)
• $I<random><ext> — metadata: original filename, full original path, and time of deletion

Forensic significance: the presence of a file in the Recycle Bin, with a deletion timestamp and the user’s SID, shows that a specific account deliberately attempted to delete that file. If the file was relevant to the investigation, this can constitute attempted destruction of evidence.

Application Metadata

File system metadata (NTFS timestamps, file size) treat file contents as a black box. Application metadata are stored inside the file itself and describe the file’s content in much richer detail.

Properties of application metadata:

• Stored in XML (Office files, modern formats) or proprietary binary formats
• Often survive file copying (the NTFS creation timestamp updates on copy; the internal application timestamp does not)
• Easier to forge than NTFS metadata — no system-level enforcement — but forgery must be done with dedicated tools (whose presence in the Registry is itself forensically relevant)

Microsoft Office Metadata

Office documents carry extensive embedded metadata, including:

• Created, last-written, and last-accessed timestamps (internal, not NTFS)
• The last 10 authors to edit the document (based on the name configured in Office at each save)
• Revision history (if Track Changes was enabled — enormous evidentiary value)
• Hidden comments and annotations
• Cut-and-paste provenance: if content was pasted from another Office file, the path to the source file is often recorded
• Image provenance: if images were imported, their source URLs or file paths may be embedded

Case study — metadata tampering detection: A CEO produced a safety procedures document with plausible-looking timestamps in both $STANDARD_INFORMATION and the application metadata. Registry examination revealed metadata-tampering software on his laptop. Investigators then checked the $FILE_NAME attribute timestamps (which are not updated after creation and are not affected by common tampering tools) and found they post-dated the incident. Confronted with the discrepancy, the suspect confessed to forging the document.

Multimedia File Metadata (Exif)

Digital photos (JPEG, TIFF) contain Exif metadata:

• Date and time of capture
• Camera make, model, and serial number
• Camera settings (aperture, shutter speed, ISO, focal length)
• Preview thumbnail (can help reconstruct a damaged image)
• GPS coordinates (if the device is GPS-enabled and geotagging is on — default on most smartphones)

GPS coordinates have been used to locate fugitives (the John McAfee case in 2012: a Vice reporter posted an iPhone photo whose Exif GPS data revealed his location in Guatemala).

Social media platforms typically strip Exif data before publishing — but retain it internally.

Note: music files carry DRM credentials (rightful owner, download timestamp); video files embed playback licensing. These can help establish the provenance of pirated media.

Web Browser Forensics

Browsers accumulate extensive forensic evidence, much of it difficult to fully purge:

Internet Explorer: uses proprietary binary index.dat files that must be parsed by a forensics tool. The cache index maps each browsing event (URL + timestamp) to the locally cached file.

Firefox, Chrome: use SQLite databases — directly queryable with standard SQL tools.

Typed URLs vs. history: history records all URLs visited (including from clicked links); typed URLs record only what the user manually typed into the address bar, proving intent to navigate to that destination.

Dynamic content limitation: server-side scripts and dynamically generated content cannot be reconstructed from the local cache, because the content was generated on the server at request time.

E-mail Forensics

E-mail leaves traces at multiple points:

• On the mail server (the authoritative record; may require a subpoena)
• In the local mail client archive (if POP3 or IMAP is used)
• In the browser cache (if webmail is used)

Retrieval Protocols

Finding E-mail Archives

On Windows, local mail archives are typically found under C:\Users\<username>\AppData\Roaming\:

• Thunderbird: Thunderbird\Profiles\<profile>\Mail\Inbox
• Outlook: .pst or .ost database files with internal unallocated space and deleted record recovery (forensics tools can recover deleted messages and contacts)

Analyzing E-mails

• Most clients store mail as plaintext; a text editor can open them
• Commercial forensics suites (EnCase, Autopsy) index mail archives for fast search
• Attachments are stored inline as Base64-encoded fragments and can be recovered manually or by tool
• E-mail headers record the full routing path from sender to recipient — there is no such thing as truly anonymous e-mail without special anonymizing infrastructure

Installed Programs

Forensic examination of installed programs can:

• Identify tools used to commit a crime (anti-forensics software, hacking tools, piracy tools)
• Establish the general purpose of the machine (work vs. personal use)
• Reveal recently uninstalled programs that the user tried to hide

Key locations:

Caution: the presence of a program does not prove that a specific user installed or knowingly used it. It could have been installed by another user with shared access, installed as a dependency of something else, or delivered by malware.

Prefetch Files

Windows uses prefetching to speed up repeated program launches. Prefetch files are stored at C:\Windows\Prefetch\*.pf (up to 128, retained by recency).

Each .pf file records:

• Full path to the executable
• Last run time
• Number of times run from that location
• DLLs required by the executable

Because prefetch files are less well-known and less likely to be targeted by a user attempting to destroy evidence, they are valuable for corroborating other findings and detecting inconsistencies.

Forensic Timelines

All the artifacts described above are most powerful when integrated into a single chronological timeline. A timeline allows an investigator to answer: what happened first, what happened next, and does the sequence make sense?

Timeline Creation Tools

• mactime (part of The Sleuth Kit): reads NTFS file system timestamps for all files and produces a tab-delimited event list
• log2timeline: integrated server logs and mactime output into a unified timeline
• plaso (the current successor): a Python library and tool suite that ingests Apache logs, Windows event logs, PCAP files, Exif data, syslog, link file metadata, Windows firewall logs, antivirus logs, browser data, Registry data, and mactime data — producing a comprehensive “super timeline” in CSV, JSON, or XML output
• Commercial suites: FTK, EnCase, and others have built-in timeline generation

Timeline Investigation Approaches

Bulk timeline: collect everything first, then analyze. Best when you don’t yet know what is relevant. Produces potentially millions of entries; requires SQL queries, Excel histograms, or automated analysis to find anomalies.

Targeted timeline: decide what artifacts matter first (e.g., file transfers and login events for an insider threat investigation), then collect only those. Faster and more focused, but risks missing unexpected evidence.

Pattern-of-life baseline: establish what the user normally does (login/logout times, applications used, network activity). Deviations from baseline are candidate anomalies worth investigating.

Timeline Pitfalls

• Time zones: all timestamps must be normalized to the same time zone (GMT is standard) before integrating. A single mis-converted timestamp can invert the ordering of events and produce completely wrong conclusions.
• Clock skew: a machine that has been offline will drift from correct time. Even small skew can alter event ordering significantly.
• Scale: multi-machine investigations (e.g., a corporate network breach) may produce billions of events. Manual analysis is not feasible; tools and filters are essential.
• Confirmation bias: large datasets will always contain apparent anomalies. Do not treat an anomaly as evidence of a crime without tying it to a specific criminal act. Digital artifacts must be linked to the elements of the offense.

Further Reading

• E. Casey. (2011). “Digital Evidence on Windows Systems” (Chapter 17). In Digital Evidence and Computer Crime (3rd ed.). Academic Press.
• R. D. Pittman and D. Shaver. (2010). “Windows Forensic Analysis” (Chapter 5). In Handbook of Digital Forensics and Investigation (E. Casey, ed.). Academic Press.
• A. Crenshaw. (2009). “Forensically Interesting Spots in the Windows 7, Vista and XP File System and Registry.” Irongeek.com.