Registry forensics: structure, contents and evidential limits

The registry is not one artifact

People say "check the registry" the way they say "check the disk". It is not a thing to check; it is a place several hundred unrelated artifacts happen to live, written by different parts of Windows, for different reasons, with different lifetimes and no shared convention about anything.

This page is about what is written in there and what it means. The registry internals guide covers the container: how a hive file is laid out, how a key and a value are stored, what a transaction log is, and how deleted keys are recovered. Everything below assumes that and moves on to the evidence.

The organising idea here is the question, not the key. An examiner does not wake up wanting to read HKLM\SYSTEM\CurrentControlSet\Services; they want to know what ran, what persists, what was plugged in, where somebody went. The keys follow from that.

The maps that follow are interactive. Click any byte, or any row of the table beside it, to read the field that byte belongs to and what it decodes to; the tabs above each map switch between the structures, and the map redraws for whichever one is selected.

One container, and the six unrelated things inside it

The first tab is the container itself. A hive is a file in a format of its own, and it announces that in its first four bytes: regf. Everything a hive holds - keys, values, security descriptors, the free space a deleted key is carved back out of - sits after a 4096-byte header called the base block, which says which version the format is, where the root key begins, how much of the file is in use, and whether the file was closed cleanly or was still being written when it was captured. SYSTEM, SOFTWARE, NTUSER.DAT and Amcache.hve are all the same format; only their contents differ.

The other six tabs are those contents, and they share the container and nothing else. A UserAssist counter, a BAM timestamp, a scheduled task's run history, an MRU (most-recently-used) ordering, a disk signature and a device property are six unrelated structures that happen to be stored in the same place. That is the single most important thing to understand about registry forensics, and it is why there is no such thing as a registry parser - only a parser for each thing in it.

Structure is real and measured. Names, paths and hashes are replaced with a placeholder of the same length, so every offset still adds up and nothing here identifies the machine it came from. The base block is read from %SystemRoot%\System32\config\DRIVERS - a real hive file rather than an NtSaveKeyEx export, because an export is written fresh and its sequence numbers agree for that reason rather than because the hive was closed cleanly.

Full dissection reference

The same fields as a table. Both are drawn from one definition, so the map and the table cannot disagree with each other.

Question 1: what ran on this machine?

Four artifacts answer this, badly on their own and well together. None is a log; all four are side effects of features that exist for other reasons.

UserAssist, and the ROT13 that fools keyword searches

Under Explorer\UserAssist sit 9 GUID subkeys, each with a Count key whose value names are program paths encoded with ROT13. Not encrypted - rotated thirteen places, the cipher that ships as a party trick.

It matters for one practical reason: a raw keyword search of a hive for a program name will not find its UserAssist entry. An examiner grepping an image for evil.exe gets nothing from this key while the evidence sits right there under a name that reads as nonsense. On the reference system a sample entry is 15 characters encoded, and its record is 1,612 bytes.

BAM and DAM: the kernel's own record

The Background Activity Moderator throttles what background programs may do, and to do that it keeps the last execution time of each binary, per user SID, under Services\bam\State\UserSettings. The reference system has 8 SIDs there and each value is a 24-byte record whose first eight bytes are a FILETIME.

It is the closest thing the registry has to an execution log, and its weakness is that it keeps one timestamp per binary. A program run a hundred times leaves the same single record as one run once. It is also cleared on a schedule, so it is a recent window rather than a history.

Every key Crow-Eye reads for this question (12)

The full list, so the page can answer "is this key covered?" rather than leaving it open. A key shown as {ControlSet} is read as CurrentControlSet on a live machine and as the control set Select names in an offline hive.

Question 2: what will run again?

Persistence is the registry's specialty, and it is much larger than the two keys everyone knows. Crow-Eye reads twenty-eight autostart extensibility points beyond Run and RunOnce: Winlogon's Shell and Userinit, Image File Execution Options, AppInit and AppCert DLLs, Active Setup, LSA packages, Boot Execute, per-user CLSID shadowing, Command Processor AutoRun, Drivers32, shell service objects, Browser Helper Objects, SharedTaskScheduler, shell icon overlays, credential providers, netsh helper DLLs, AMSI providers, security providers, print monitors and processors, network providers, WMI autorecover MOFs, and the per-user Load and Run values.

Crow-Eye names these tables for the artifact, never for the technique that abuses them: shell_open_command, not "uac_bypass"; clsid_inprocserver32, not "com hijack". A verdict in a table name becomes a verdict on screen, and the analyst stops being the one who judges.

Every key Crow-Eye reads for this question (49)

The full list, so the page can answer "is this key covered?" rather than leaving it open. A key shown as {ControlSet} is read as CurrentControlSet on a live machine and as the control set Select names in an offline hive.

Question 3: what was plugged into it?

USB history is spread across several keys that each hold a piece, and the piece most people want - when - is in the least accessible of them.

The timestamps live under each device's Properties subkey, in {83da6326-97a6-4088-9453-a1923f573b29}, as four numbered values: 0064 install, 0065 first install, 0066 last arrival, 0067 last removal. They are DEVPROP_TYPE_FILETIME, which is not one of the twelve documented registry types, so a reader that only knows the twelve refuses them.

Every key Crow-Eye reads for this question (14)

The full list, so the page can answer "is this key covered?" rather than leaving it open. A key shown as {ControlSet} is read as CurrentControlSet on a live machine and as the control set Select names in an offline hive.

Question 4: where did the user go?

Explorer remembers, and the remembering is per user and per hive. Shellbags get a page of their own; the rest are MRU lists.

All of these — Shellbags, RecentDocs, the dialog MRUs, TypedPaths, RunMRU and the search history, together with what the user ran (UserAssist, BAM, DAM, FeatureUsage, the Compatibility Assistant) and the rest of the user-activity keys — are read together by the Charts button on each of their table tabs, which opens one User Activity dashboard: every source on one timeline, most-visited places, the volumes and shares each pointed at, and per-item detail. Each table is explained one by one below.

An MRU key holds numbered values and one ordering value. In older keys that is MRUList, a string of letters: on the reference system the RunMRU key holds 2 entries ordered ba. Newer keys use MRUListEx, four-byte indices terminated by 0xFFFFFFFF.

RecentDocs, OpenSaveMRU, LastVisitedMRU, TypedPaths, WordWheelQuery and the RDP client's history are all this shape. Several store shell items rather than strings, which is the same structure a Shellbag and a shortcut use.

That is where they stop being alike. One holds a shell item list to a file, one holds an application name and then a folder, one holds an application name and a window size with no path in it at all, and two hold nothing but a string - so a row from one supports a sentence a row from another does not. Explained in full: the MRU family

Every key Crow-Eye reads for this question (34)

The full list, so the page can answer "is this key covered?" rather than leaving it open. A key shown as {ControlSet} is read as CurrentControlSet on a live machine and as the control set Select names in an offline hive.

Every user-activity table, one by one

Each table below is one tab in Crow-Eye, and each has an Anatomy button that opens its own section here. Its Charts button opens the User Activity dashboard, where it shares one timeline with Shellbags, the MRUs and every other source below. The shell-item tables (RecentDocs, the dialog MRUs, TypedPaths, RunMRU, search, MountPoints2) are explained on the Shell Items page.

UserAssist

Programs and shortcuts this user launched through Explorer, with how often and for how long they had focus. The value names are ROT13-encoded paths (why, and what that breaks).

BAM, the background activity moderator

The kernel's record of the last time each program ran, per user SID (how BAM works).

DAM, the desktop activity moderator

The same record as BAM, kept by the Desktop Activity Moderator. It exists only on devices that support Modern Standby (connected standby), so on most desktops the table is empty - and that is not a gap.

MUICache

Friendly names Explorer read from executables' version resources - which happens when the shell displays or launches them.

RecentApps

Windows 10's early record of recently used apps and the files each opened (builds 1507 to 1607; later builds dropped it).

FeatureUsage (taskbar)

Per-program counters kept by the taskbar (Windows 10 1903 and later).

The compatibility assistant store (PCA)

Programs the Program Compatibility Assistant watched because the user ran them - installers and downloaded tools especially.

File associations (FileExts)

Which programs the user opened each file type with, and which one they chose as the default.

ProgramsCache (Start menu)

The Start menu's cached list of programs, stored as shell items.

Registry Editor: last key and favourites

Where Registry Editor was looking when it was last closed, and the keys saved as favourites.

TypedURLs

Addresses typed into the Internet Explorer (and Explorer) address bar.

Explained in full: browser forensics

Remote desktop client history

Hosts this user connected to with Remote Desktop.

Office recent files and trusted documents

Documents opened in Word, Excel and PowerPoint, and the documents the user let run active content.

Application MRUs (PuTTY, WinSCP, WinRAR, 7-Zip, ...)

What third-party tools remember, read from their own keys.

Camera, microphone and location use (ConsentStore)

When each app last used the camera, microphone or location, with a start and a stop time (Windows 10 1903 and later).

Question 5: what was this machine, and what was it connected to?

Identity and network answer the questions that come up when an image arrives with no context: whose machine is this, what was it called, what network was it on, when was it installed.

Every key Crow-Eye reads for this question (53)

The full list, so the page can answer "is this key covered?" rather than leaving it open. A key shown as {ControlSet} is read as CurrentControlSet on a live machine and as the control set Select names in an offline hive.

What the registry supports, and what it does not

The five questions above each carry their own warning where it belongs, in the artifact it applies to. Four limits are not about any one key — they are properties of the registry itself, and they apply to every finding on this page.

What it is genuinely good for: answering which question. No other artifact on a Windows machine spans execution, persistence, device history, user navigation and machine identity in one container, with the same acquisition and the same parser. The five questions above are the shape of that strength: the registry is rarely the only evidence for a finding, and it is very often the first place the finding is visible.

What Crow-Eye does with all of this

Seventy-odd tables, one per artifact, named for what they hold. Both acquisition routes - the live registry through the API, and the hive files through a shadow copy, raw disk or a backup-privileged export - produce the same tables, so a case has the same shape either way. Where an artifact needs a decoder rather than a read, that decoder is shared: the same code reads a shell item whether it came from a Shellbag, a Jump List or a shortcut. Explained in full: Jump Lists

Deleted keys and values are carved from the hive's freed cells and marked (deleted) in a column of their own, with the key path reconstructed where the parent chain survives and left empty where it does not. And every hive's transaction logs are replayed before parsing, because a hive read from a running machine is mid-transaction by default and its most recent changes are in the log rather than the file.

The registry internals guide is the companion to this page: it explains the file this evidence sits in, and why several of the behaviours above are structural rather than optional.

How the registry's artifacts changed across Windows

Each row below records a change that alters what a reader may conclude, not only how the bytes are arranged. A parser written against one Windows release returns nothing against another, and does so without raising an error.

Reference

Value types, including the ones Microsoft did not document

Which key answers which question

Anti-forensic handling, and what survives it

The preceding sections describe what intact keys support. This section describes the registry after an attempt to remove or evade it, which is the condition in which it is frequently encountered. In most rows the attempt leaves a trace of its own.