Windows Registry — A Security & Forensics Primer

It's Windows' central hierarchical configuration database — a key-value store holding settings for the OS, drivers, services, software, and every user, consolidating what used to live in scattered INI files. Structurally it mirrors a filesystem: keys are like folders, values are like files, and each value has a name, a type (string, DWORD, binary, etc.), and data. At the top are five root keys, but only two are "real" stored data — HKLM for machine-wide settings and HKU for all loaded user profiles; HKCU is just a view into the current user's SID under HKU, and HKCR and HKCC are merged or derived views. On disk it's assembled from several hive files under System32\config plus each user's NTUSER.DAT, which matters because offline forensics parses those files directly.

I'd enumerate all the autostart extensibility points, not just the obvious one. The classic Run and RunOnce keys under both HKLM and HKCU's CurrentVersion. The Winlogon keys — Shell should be exactly explorer.exe and Userinit should be userinit.exe, so any extra entries are persistence. The Services key under SYSTEM\CurrentControlSet, since a malicious service or driver runs at boot. Image File Execution Options, where a Debugger value hijacks a target exe — the basis of the sticky-keys backdoor. Plus AppInit_DLLs, Explorer Run policies, and COM hijacking via CLSID InprocServer32. In practice I'd run Sysinternals Autoruns to dump every ASEP, verify signatures, and flag anything unsigned or pointing at a user-writable path like AppData or Temp. These map to MITRE T1547 and T1112.

The credential hives first: SAM holds local account NTLM hashes, SECURITY holds LSA secrets — service-account passwords, cached domain creds, auto-logon passwords — and SYSTEM holds the boot key needed to decrypt SAM, so you grab all three together and can extract credentials offline the same way secretsdump does. SOFTWARE and SYSTEM also hold persistence keys and execution artifacts like ShimCache and AmCache. Then each user's NTUSER.DAT and UsrClass.dat for behavioral evidence — UserAssist for programs they launched, Shellbags for folders they browsed, RecentDocs and typed paths, and USBSTOR for devices attached. The reason hives are so valuable in IR is that Windows writes much of this passively for performance, so it persists even after files are deleted or logs are cleared — ShimCache proving a now-deleted binary ran is a textbook example.

The backbone is Sysmon registry events — ID 12 for key create/delete, 13 for value set, 14 for rename — tuned to watch the autostart and security-disabling keys, plus Windows event 4657 if you've set SACL auditing on specific keys, and EDR which hooks registry operations natively. But the key to making it a real detection rather than noise is context: a write to a Run key is unremarkable because installers do it constantly, so I correlate it with the parent process — Word or an encoded PowerShell writing a Run key is a smoking gun, because those don't legitimately install autostarts. I'd alert specifically on new autostart entries pointing at unsigned binaries or user-writable paths, and on tampering with defenses like disabling Defender, UAC, or LSA protection, or setting AutoAdminLogon with a DefaultPassword.

HKLM is machine-wide and affects all users, while HKCU is the current user's settings — really a view into that user's SID under HKU. The difference matters for both privilege and stealth. Writing persistence to HKLM (like the machine-wide Run key or a service) affects every user and survives across accounts, but it requires administrator rights because HKLM is protected. Writing to HKCU only needs the user's own privileges and runs when that user logs in — so a non-admin attacker who's compromised a user can establish persistence in HKCU without elevation, which is quieter and a common low-privilege foothold. So an attacker's choice of HKLM versus HKCU reflects what privileges they have and how broad and persistent they want the foothold to be, and defenders should watch both.

Several ways. The SAM hive stores local account NTLM hashes, and the SECURITY hive's LSA secrets store service-account plaintext passwords, cached domain credentials, and any auto-logon password — and with the SYSTEM hive's boot key these can be extracted offline by tools like secretsdump or mimikatz, which is why grabbing those hive files is a top attacker objective. A specific classic finding is AutoAdminLogon set with a DefaultPassword value under Winlogon, which is a plaintext password sitting in the registry. Protections: enable LSA Protection (RunAsPPL) to harden LSASS, prefer group-managed service accounts so there's no static password in LSA secrets, avoid auto-logon, restrict local admin and use LAPS so a stolen local hash isn't reusable across machines, and enable Credential Guard to isolate secrets. And monitor for the offline-dump pattern — processes saving the SAM, SYSTEM, or SECURITY hives.