The Registry

Registry Structure and Hives

The registry is organized as a hierarchical database, conceptually similar to a filesystem. Instead of folders and files it has keys and values. A key is a container, roughly equivalent to a directory, and it can hold subkeys and values.

A value has a name, a data type, and actual data, roughly equivalent to a file with a name and contents. The entire structure is rooted at a small set of predefined top-level containers called hives, each identified by a constant that starts with HKEY.

The Five Hives

Every registry path lives under one of these five root containers.

Hive Files on Disk

These in-memory hives are backed by physical hive files on disk. HKLM\SAM, HKLM\SECURITY, HKLM\SOFTWARE, and HKLM\SYSTEM correspond to files of the same name in C:\Windows\System32\config.

Per-user hives live inside each profile: NTUSER.DAT in the user's profile root backs HKCU, and UsrClass.dat under AppData\Local\Microsoft\Windows backs the user-specific portion of HKCR. This matters for forensics because these files can be pulled directly from a disk image, or from a Volume Shadow Copy, and parsed offline with tools like RegRipper or Registry Explorer even when the machine is not running.

The Registry as Configuration and Identity Store

Describing the registry purely as "where Windows keeps its settings" undersells what actually accumulates there. Windows itself uses it for the obvious things: network adapter configuration, driver bindings, feature flags, and policy settings pushed down by Group Policy or Intune. But nearly every third-party application installed on a Windows machine also writes to the registry, often extensively, and that installed-software footprint is where things get interesting for an investigator.

Installation Records

When software is installed through a standard installer, it typically registers an entry under HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall. That entry records the product name, publisher, install date, and uninstall command, and it is exactly what Control Panel's "Programs and Features" reads to build its list.

This means the registry holds a fairly reliable record of what has been installed on a machine and when, independent of whether the application is currently running or has left files behind. Investigators use this routinely to establish whether a suspicious tool was ever installed on a host, even after the files themselves have been deleted.

Incidental User Activity Evidence

Beyond installation records, the registry accumulates a surprising amount of user activity evidence. None of these keys exist because Microsoft wanted to help forensic examiners, they exist to make the shell feel responsive and personalized. The forensic value is a side effect of ordinary UI convenience features quietly logging behavior.

Why This Dual Nature Matters

This dual nature, configuration store and incidental activity log, is why the registry shows up constantly in both directions of security work. Defenders read it to reconstruct what happened on a compromised host: what ran, what was installed, what a user touched. Attackers write to it, sometimes deliberately for persistence and sometimes just as a side effect of executing malware, and both kinds of writes leave evidence. Treating the registry as "just config" misses most of why it matters to an investigation.

Persistence via Run Keys

The Run and RunOnce keys are the oldest and most widely recognized persistence mechanism in Windows, and they remain in active use by both legitimate software and malware today. Both keys accept an arbitrary command line as the value data, so an entry can point directly at an executable, a script interpreter with a script argument, or a living-off-the-land binary invoked with malicious arguments.

Run vs RunOnce, HKLM vs HKCU

The two keys differ in one respect: whether Windows keeps the value or deletes it after firing once. RunOnce is meant for cases like installers that need one more step after a reboot, but it works just as well for an attacker who wants a payload to fire on next logon and remove the evidence of its own trigger automatically.

Lesser-Known Siblings

• RunServices / RunServicesOnce. Deprecated legacy keys from older Windows versions that some tooling still checks.
• Wow6432Node. Duplicates the Run keys under HKLM\Software\WOW6432Node\Microsoft\Windows\CurrentVersion on 64-bit systems for 32-bit application compatibility. Malware occasionally uses this path specifically because analysts scanning only the primary Software hive path can miss it.

Why Attackers Like Them, and Why They Get Caught

Run keys remain popular with attackers, including in commodity malware and low-sophistication intrusions, for a simple reason: they are trivially easy to implement. Writing a single registry value is far less code than installing a service or scheduling a task, and it requires no special privileges when targeting the HKCU variant, since any user can write to their own hive.

The tradeoff is that Run keys are also one of the easiest persistence mechanisms to detect. They are a small, finite, well-known list of locations, and both built-in tools like Autoruns and EDR agents enumerate them by default.

Detecting Run Key Persistence

From a detection standpoint, the practical approach is baselining. A clean installation of Windows plus known-good enterprise software produces a fairly stable, predictable set of Run key entries.

Any new entry appearing outside a change window, especially one pointing at an unsigned binary, a script interpreter, or a path in a user-writable location like %AppData% or %Temp%, warrants investigation. Analysts should also pay attention to the value name and data together, since malware authors frequently choose value names designed to look like legitimate Windows or vendor components while pointing at something else entirely.

Persistence via Services

Windows services are represented in the registry under HKLM\SYSTEM\CurrentControlSet\Services, with each service getting its own subkey named after the service's internal name. That subkey holds the values the Service Control Manager needs to run it, listed in full in the table below.

Two Ways Services Get Abused

• New service creation. An attacker creates an entirely new service, typically using sc.exe, New-Service in PowerShell, or a direct registry write, pointing ImagePath at their payload and setting Start to auto-start.
• Service hijacking. Subtler and often more effective against casual review: an attacker hijacks an existing, legitimate service by modifying its ImagePath value to point at a malicious binary instead of the original one. Because the service name and its outward description remain unchanged, an analyst scanning a list of installed services sees a familiar, expected name and may not think to verify that the path underneath it still points where it should.

Why Services Are Attractive

• Privilege escalation. A service configured to run as LocalSystem executes with SYSTEM-level privileges, a higher tier than most interactively logged-on users have, so service-based persistence often doubles as a privilege escalation vector.
• No logon required. Services start before user logon, so a service-based payload can run and re-establish other footholds even if no one ever logs into the console.
• Reliable survival. Service configuration lives in the registry and is managed centrally by the Service Control Manager, so it survives reboots reliably in a way that some other execution methods do not.

Detecting Service Abuse

• New service creation events, Windows Security Event ID 4697, or Sysmon Event ID 13 registry-value-set events on the Services key.
• Suspicious ImagePath values pointing at unsigned binaries or unusual locations such as user profile directories.
• Look-alike names, service binaries deliberately named to resemble legitimate Windows components.
• ImagePath modification on a pre-existing, well-known service.
• Unexplained restarts of a familiar-sounding service, since a hijacked service typically needs to be restarted for the new ImagePath to take effect.

Key Registry Values

Other Common Persistence Locations

Run keys and services are the two persistence mechanisms most closely tied to the registry, but they are far from the only registry-relevant footholds attackers use. Three more are worth knowing well: scheduled tasks, COM hijacking, and IFEO debugger hijacking.

Scheduled Tasks

Scheduled tasks are technically stored primarily as XML task definition files under C:\Windows\System32\Tasks, but their metadata and cache is also mirrored into the registry under HKLM\Software\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache. A scheduled task that runs at logon or on a recurring trigger achieves essentially the same outcome as a Run key entry.

Analysts investigating persistence should check both mechanisms rather than assuming one covers the other.

COM Hijacking

COM hijacking targets the way Windows resolves Component Object Model class identifiers, or CLSIDs, to the code that implements them. Every registered COM object has an entry under HKCR\CLSID\{GUID}\InprocServer32 or LocalServer32 pointing at the DLL or executable that implements it.

Because HKCU's classes take precedence over HKLM's in the merged HKCR view, an attacker can register a malicious replacement for a legitimate, frequently-invoked CLSID entirely within their own user hive, without needing administrative rights, and have it silently invoked whenever some other trusted process instantiates that COM object in the normal course of business.

IFEO Debugger Hijacking

IFEO is stored under HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options. It was designed so a developer could attach a debugger automatically whenever a specific executable launches, by setting a Debugger value under a subkey named after that executable, for example a subkey named notepad.exe with a Debugger value pointing at a debugger tool.

Windows honors that value literally: whatever is listed as the "debugger" launches instead of, or ahead of, the target program. Attackers abuse this by setting the Debugger value on a security tool's process name to point at their own payload, effectively disabling that tool every time it tries to start, or by setting it on a commonly launched utility to achieve execution.

The Common Thread

What ties these three mechanisms together with Run keys and services is that all of them are, at bottom, registry writes that redirect what code executes under normal, expected circumstances. None require exotic tooling.

An analyst who understands the registry's structure well enough to know where these values live can check all of them quickly with the same set of skills, which is exactly why Autoruns and similar tools enumerate this entire family of locations by default rather than just the classic Run keys.

Registry Forensics and Detection

Everything covered in this chapter points toward the same practical conclusion: registry-based persistence is common precisely because the registry is large, flexible, and only partially monitored by default. A defender's job is to narrow that surface down to a manageable, well-understood set of locations and watch them consistently, rather than trying to review the entire registry, which is neither practical nor useful.

What to Monitor

At minimum, an analyst building registry-based detection should monitor these locations:

• Run and RunOnce keys in both HKLM and HKCU.
• The Services key, for new service creation and ImagePath modification on existing services.
• The IFEO key, for new Debugger values.
• The COM CLSID structure, for unexpected changes to well-known, high-frequency class identifiers.

Tools like Sysinternals Autoruns provide a point-in-time snapshot across most of these locations and are useful for manual triage or incident response, but they do not provide continuous, real-time visibility on their own.

Point-in-Time Snapshots vs Continuous Monitoring

For continuous monitoring, the registry needs to be instrumented so that changes generate events as they happen rather than being discovered later during a manual sweep. Sysmon is the tool most commonly used for this in a Windows environment.

It can be configured to log registry key and value creation, modification, deletion, and renaming, filtered down to the specific paths that matter for persistence rather than the entire hive, which would be far too noisy to be usable.

Looking Ahead to Chapter 6

This chapter has focused on where persistence lives in the registry and why attackers choose these particular locations. Chapter 6 picks up the other half of that picture: the specific Sysmon Event IDs, 12, 13, and 14, that capture registry object creation and deletion, value sets, and key and value renames.

It also covers how to build detection logic around them so that a new Run key entry or a hijacked ImagePath generates an alert instead of waiting to be found during a manual review.