The Windows registry

Overview

Security objective: the asset you are protecting is the integrity and confidentiality of Windows configuration data. The registry decides what runs at boot, what privileges an installer gets, and sometimes stores credentials in plaintext. The threats are (1) persistence — an attacker plants an entry so their code re-runs after reboot, and (2) privilege escalation — a low-privileged user abuses a writable machine-wide key or a permissive policy to gain SYSTEM. By the end you will be able to detect these misconfigurations by querying the registry and prevent them by fixing permissions and policies.

The registry is Windows' central, hierarchical configuration database. Instead of scattering settings across dozens of text files (as on Unix), Windows keeps operating-system, driver, service, and application settings together in one tree. Programs read and write it constantly.

The tree is divided into hives at the top. The two you will use most are:

• HKLM (HKEY_LOCAL_MACHINE) — machine-wide settings that apply to every user. Writing here normally requires administrator rights.
• HKCU (HKEY_CURRENT_USER) — settings for the user who is logged in right now. A normal user can write their own HKCU freely.

This lesson sits in the Windows Fundamentals track. It builds on the previous lesson on Windows services (win-services) — many services are configured through registry keys, and a service that launches a program named in a writable key is a classic escalation path. It leads into the Event Viewer and Windows logging lesson (win-event-viewer), where you will see how registry changes are recorded so defenders can catch them. No prior lessons are required beyond basic comfort with a Windows command prompt.

Throughout, remember the difference between reading and changing the registry. Enumeration (reading) is low-risk. Changing keys can break a machine, so every write in this lesson happens only on a system you own or are explicitly authorized to test — a personal VM, a lab container, or a purpose-built vulnerable box.

Why it matters

In authorized professional work — a Windows penetration test, a configuration audit, or blue-team hardening — the registry is a recurring checkpoint. It holds three things that decide security outcomes:

• Autostart entries. Run keys, service definitions, and similar locations list programs that launch automatically. Attackers use them for persistence; when a machine-wide autostart key is writable by a normal user, it also becomes an escalation path.
• Plaintext secrets. Some applications and Windows features (notably Winlogon autologon) leave credentials in the registry in cleartext. An auditor who finds these reports them; an attacker who finds them reuses them.
• Escalation policies. Flags such as AlwaysInstallElevated change the security model of the whole machine. When set, any user can install an MSI as SYSTEM.

For a defender, the same knowledge is what lets you harden a build: lock down key permissions, disable dangerous policies, remove leftover secrets, and turn on auditing so tampering shows up in the logs. Checking Run keys, autologon values, and AlwaysInstallElevated is routine on both sides of the engagement — offense reports them, defense removes them.

Core concepts

The registry has a small number of ideas. Learn each one on its own, then see how they combine into the security-relevant locations.

1. Hives

Definition: hives are the top-level roots of the registry tree.

Plain explanation: think of hives as the top folders of a filesystem. Everything else lives inside one of them.

How it works: the main hives are:

When it matters: the scope of a hive tells you the blast radius. A change in HKCU affects one user; a change in HKLM affects everyone and usually needs admin rights. That difference is the heart of most registry-based escalation reasoning.

Pitfall: HKCR and HKCC are views built from HKLM and HKU, not independent stores. Editing the same setting in two places can confuse you — prefer the underlying HKLM/HKU location.

2. Keys and values

Definition: keys are containers (like folders); values are the named data entries inside a key.

Plain explanation: a key is a folder; a value is a named setting inside it. A value has three parts: a name, a type, and data.

How it works: common value types include REG_SZ (text string), REG_DWORD (32-bit number, often a 0/1 flag), REG_BINARY (raw bytes), and REG_MULTI_SZ (list of strings). The special value name (Default) is the unnamed value every key can hold.

When/when-not: you read values to learn configuration; you change them only when hardening or in an authorized lab. Never edit values on a production machine you do not own.

Pitfall: the type matters. A policy that expects a REG_DWORD of 1 will ignore a REG_SZ value of "1". Wrong type = setting silently does nothing.

3. Autorun (Run) keys

Definition: keys whose values name programs Windows starts automatically at logon or boot.

Plain explanation: each value in a Run key is "launch this program". Windows walks the list and starts everything in it.

How it works: the classic locations are HKLM\Software\Microsoft\Windows\CurrentVersion\Run (runs for every user) and HKCU\Software\Microsoft\Windows\CurrentVersion\Run (runs for the current user). There is also RunOnce (runs a single time then deletes the entry).

When it matters: for persistence, an attacker adds a value so their code re-launches after reboot. For escalation, the danger is permissions: if a normal user can write to an HKLM Run key or to the file a Run value points at, and that program later runs in an administrator's or SYSTEM context, the low-privileged user's code inherits those privileges.

Pitfall: an entry in an HKCU Run key runs only as that user — it is persistence, not escalation. Do not overstate impact: escalation needs a trust boundary to be crossed (low user's input running as high user).

4. Stored secrets (autologon)

Definition: credentials left in the registry as readable data.

Plain explanation: some software, and the Windows autologon feature, save a username and password so login is automatic. The autologon password is stored in cleartext under Winlogon.

How it works: the values DefaultUserName, DefaultDomainName, and DefaultPassword live under HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon. If DefaultPassword is present, anyone who can read that key learns the password.

When it matters: finding these during an authorized audit is a reportable finding. The fix is to stop using plaintext autologon (or at least use the LSA-secret mechanism instead of a cleartext value).

Pitfall: absence of DefaultPassword does not prove autologon is off — some setups store the secret as an LSA secret instead. Report what you can verify, not what you assume.

5. AlwaysInstallElevated

Definition: a policy that, when enabled in both HKLM and HKCU, lets any user install MSI packages with SYSTEM privileges.

Plain explanation: it is meant to let non-admins install approved software, but it effectively hands SYSTEM to any user who can run an installer.

How it works: the REG_DWORD value AlwaysInstallElevated must equal 1 under both HKLM\Software\Policies\Microsoft\Windows\Installer and HKCU\Software\Policies\Microsoft\Windows\Installer. If either is missing or 0, the escalation does not apply.

When it matters: it is one of the highest-severity Windows misconfigurations because it is an instant, reliable path to SYSTEM. Auditors always check it; defenders always disable it.

Pitfall: checking only HKLM (or only HKCU) is a common mistake — the policy needs both set to 1 to be exploitable. Reporting it as exploitable when only one is set is a false positive.

THREAT MODEL — Windows registry misconfigurations

  ASSET: config integrity + stored secrets that decide what
         runs, at what privilege, on this Windows host

  ACTORS
    [ Low-privileged user ]  <-- untrusted, our test account
    [ Administrator / SYSTEM ] <-- high trust, runs autostart items

  TRUST BOUNDARY
    ====================================================
    HKCU (user can write own)   |   HKLM (admin-only)
    ------------------------------------------------
    user-scope autostart        |   machine-scope autostart
    (persistence, same user)    |   (persistence + escalation
                                |    IF writable by low user)
    ====================================================

  ENTRY POINTS a reviewer inspects
    - HKLM\...\Run, RunOnce        -> autostart, check ACLs
    - Winlogon DefaultPassword     -> plaintext secret
    - HKLM & HKCU AlwaysInstallElevated -> policy escalation
    - file paths named by Run values -> writable target?

  ESCALATION occurs only when the boundary is crossed:
    low user controls input (key/value/file) that a high
    user (admin/SYSTEM) later executes.

Knowledge check

1. What asset is protected in this lesson, and which trust boundary separates a normal user from an administrator in the registry? (Hint: think HKCU vs HKLM.)
2. A value in HKCU\...\Run launches a program every time you log in. Is that persistence, escalation, or both — and what insecure assumption would make you call it escalation by mistake?
3. AlwaysInstallElevated is 1 in HKLM but the HKCU value is missing. Is the machine exploitable through this policy? Why or why not?
4. Which log source would show an analyst that a Run value was added or a Winlogon value changed? (You will meet it in the next lesson.)
5. Why must every write in this lesson happen only on a VM or lab box you own or are authorized to test?

Syntax notes

The command-line tool is reg. For enumeration you almost always use reg query. The graphical editor is regedit.

REM Read one value from a key. /v names the value.
reg query "HKLM\Software\Microsoft\Windows\CurrentVersion\Run"

REM Read a single named value.
reg query "HKCU\Software\Microsoft\Windows NT\CurrentVersion\Winlogon" /v DefaultUserName

REM Recursively search all hives for a keyword (case-insensitive).
reg query HKLM /f password /t REG_SZ /s

REM Add / change a value (LAB ONLY, admin for HKLM).
REM /t = type, /d = data, /f = don't prompt for confirmation.
reg add "HKCU\Software\Policies\Microsoft\Windows\Installer" /v AlwaysInstallElevated /t REG_DWORD /d 1 /f

REM Delete a value (used here for cleanup / remediation).
reg delete "HKCU\Software\Policies\Microsoft\Windows\Installer" /v AlwaysInstallElevated /f

Key flags: /v <name> targets a value, /t <type> sets the type, /d <data> sets the data, /s recurses, /f skips the "are you sure" prompt, and /f <pattern> with /f in a query is the search pattern. Reads are safe to run anywhere you are authorized; writes (reg add, reg delete) change the system and belong only in your lab.

A useful built-in for auditing autostarts is Get-CimInstance in PowerShell, but the community standard is Sysinternals Autoruns (autorunsc.exe) for a full inventory — mentioned here as a real tool, not required for the exercises.

Lesson

The registry is Windows' hierarchical configuration database. It keeps settings for the OS, drivers, services, and applications together in one tree.

Structure

Hives are the top-level roots:

• HKLM (HKEY_LOCAL_MACHINE) — machine-wide settings. Writing here needs admin rights.
• HKCU (HKEY_CURRENT_USER) — the current user's settings.

Inside a hive, keys act like folders. Each key holds values, where a name maps to typed data.

Security-relevant keys

Autorun and persistence

• Examples: HKLM\...\Run, HKCU\...\Run, and service keys.
• These list programs that launch automatically.
• They serve as a persistence spot for attackers.
• They are also a privilege-escalation vector: if a normal user can write an HKLM autorun that later runs as admin or SYSTEM, that user gains higher privileges.

Stored secrets

• Applications sometimes store passwords or keys in the registry.
• Historically, winlogon autologon credentials are stored here in plaintext.

AlwaysInstallElevated

• A registry flag. When set, any user can install MSI packages as SYSTEM.
• This is an instant escalation (covered in the privesc material).

Tools

• reg query and reg add — the command-line interface.
• regedit — the graphical editor.

Searching the registry for credentials and writable autorun keys is standard Windows enumeration.

Code examples

The shape below is INSECURE → SECURE → VERIFY. All three parts run in a Windows command prompt on a machine you own or are authorized to test. The insecure step deliberately creates a bad configuration so you can practise detecting and fixing it. Nothing here is an exploit — it is a misconfiguration you plant and then remediate.

1. INSECURE — WARNING: intentionally vulnerable — use only in a local, isolated, authorized lab. Do not deploy.

REM --- Plant the AlwaysInstallElevated misconfiguration (LAB ONLY) ---
REM Requires an elevated prompt for the HKLM half.
reg add "HKLM\Software\Policies\Microsoft\Windows\Installer" /v AlwaysInstallElevated /t REG_DWORD /d 1 /f
reg add "HKCU\Software\Policies\Microsoft\Windows\Installer" /v AlwaysInstallElevated /t REG_DWORD /d 1 /f

REM --- Plant a plaintext autologon secret (LAB ONLY, placeholder value) ---
reg add "HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon" /v DefaultPassword /t REG_SZ /d <development-placeholder> /f

After this, a reviewer's enumeration would flag the box: the policy is set in both hives, and a cleartext password value exists. This is exactly the state you want to be able to detect and fix.

2. DETECT — the enumeration a reviewer runs

REM Is AlwaysInstallElevated set in BOTH hives? (Both == exploitable.)
reg query "HKLM\Software\Policies\Microsoft\Windows\Installer" /v AlwaysInstallElevated
reg query "HKCU\Software\Policies\Microsoft\Windows\Installer" /v AlwaysInstallElevated

REM Any autologon password left in cleartext?
reg query "HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon" /v DefaultPassword

REM List machine-wide autostart programs to review.
reg query "HKLM\Software\Microsoft\Windows\CurrentVersion\Run"

Expected output when the misconfig is present (data shown as a placeholder):

HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer
    AlwaysInstallElevated    REG_DWORD    0x1

HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\Installer
    AlwaysInstallElevated    REG_DWORD    0x1

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon
    DefaultPassword    REG_SZ    <development-placeholder>

Both hives showing 0x1 is the finding. If only one hive shows it, the policy is not exploitable — report accordingly.

3. SECURE — remediate

REM Disable AlwaysInstallElevated in both hives (set to 0 or delete).
reg add "HKLM\Software\Policies\Microsoft\Windows\Installer" /v AlwaysInstallElevated /t REG_DWORD /d 0 /f
reg add "HKCU\Software\Policies\Microsoft\Windows\Installer" /v AlwaysInstallElevated /t REG_DWORD /d 0 /f

REM Remove the plaintext autologon password.
reg delete "HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon" /v DefaultPassword /f
reg delete "HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon" /v AutoAdminLogon /f

4. VERIFY — prove the fix rejects the bad state and accepts the good state

REM Bad state should now be gone: the query should report 0x0 or "unable to find".
reg query "HKLM\Software\Policies\Microsoft\Windows\Installer" /v AlwaysInstallElevated
reg query "HKCU\Software\Policies\Microsoft\Windows\Installer" /v AlwaysInstallElevated

REM Secret should be gone: expect "ERROR: The system was unable to find the specified value".
reg query "HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon" /v DefaultPassword

Expected verification output:

    AlwaysInstallElevated    REG_DWORD    0x0
    AlwaysInstallElevated    REG_DWORD    0x0
ERROR: The system was unable to find the specified registry key or value: DefaultPassword

The verify step is what turns "I changed something" into "I proved the vulnerable state is gone and the safe state holds." A remediation you cannot re-query is not finished.

Line by line

Walking through the DETECT and VERIFY commands, since those are the ones you will run most on an assessment.

1. reg query "HKLM\...\Installer" /v AlwaysInstallElevated — asks for one named value in the HKLM policy key. reg prints the key path, then a line with the value name, type, and data. If the value does not exist you get ERROR: The system was unable to find....
2. The identical query against HKCU\...\Installer — you must run both. Only if both return 0x1 is the policy exploitable. This two-key requirement is the single most common thing beginners get wrong.
3. reg query "...\Winlogon" /v DefaultPassword — reads the autologon password value. Its mere presence is the finding; you do not need to (and should not) copy the data into a report — record that a cleartext credential exists and where.
4. reg query "HKLM\...\Run" (no /v) — with no value name, reg lists all values under the key, giving you the full machine-wide autostart inventory to review against known-good software.

The VERIFY commands are the same queries after remediation. Follow the data field:

When the after column matches the right side, and the queries confirm it, the machine no longer exhibits the finding. That confirmation — re-running the exact detection command and seeing a safe result — is the mitigation-verification step required for every finding.

Common mistakes

Mistake 1 — Reporting AlwaysInstallElevated from one hive.

• Wrong: seeing AlwaysInstallElevated = 1 in HKLM only and calling the box exploitable.
• Why wrong: the policy takes effect only when both HKLM and HKCU are 1. One hive alone does nothing.
• Corrected: query both hives; report exploitable only if both are 1.
• Recognise/prevent: build the two-key check into your checklist; a finding without both queries recorded is incomplete.

Mistake 2 — Calling an HKCU Run entry "privilege escalation."

• Wrong: "there is a program in the user's Run key, so the user can escalate."
• Why wrong: an HKCU Run entry executes as that same user — no trust boundary is crossed. It is persistence at best.
• Corrected: escalation requires a low user's input running in a higher context (writable HKLM key or writable file that admin/SYSTEM runs).
• Recognise/prevent: always ask "who writes it" vs "who runs it." Same identity = no escalation.

Mistake 3 — Editing the registry on a machine you do not own.

• Wrong: running reg add/reg delete during a test without clear scope, or on production.
• Why wrong: registry writes can break boot, disable logins, or destroy configuration; doing so without authorization is both harmful and unlawful.
• Corrected: enumeration (read) only, unless the rules of engagement explicitly authorize changes, and even then prefer a snapshot/VM.
• Recognise/prevent: keep reads and writes mentally separate; confirm scope before any write.

Mistake 4 — Wrong value type.

• Wrong: setting a policy flag as REG_SZ "1" instead of REG_DWORD 1.
• Why wrong: Windows reads the flag as a DWORD; a string is ignored, so your "fix" or "repro" silently does nothing.
• Corrected: match the documented type with /t REG_DWORD.
• Recognise/prevent: query the value after setting it and confirm both type and data.

Mistake 5 — Copying a real secret into your notes.

• Wrong: pasting a DefaultPassword value into a report or ticket.
• Why wrong: it spreads the credential and may violate handling rules.
• Corrected: record that a cleartext credential exists at a location; store any needed proof in an approved evidence vault, redacted.
• Recognise/prevent: treat any value that looks like a secret as sensitive by default.

Debugging tips

Common problems and how to work through them:

• ERROR: Access is denied. You are querying or writing a key that needs higher rights. Reads of some HKLM subkeys and any HKLM write need an elevated (Run as administrator) prompt. Open an admin command prompt and retry. If a read is denied, that itself is information about the key's ACL.
• ERROR: The system was unable to find the specified registry key or value. The key or value does not exist. For a detection query this is often the good result (the misconfig is absent). Double-check the exact path and value name — a single wrong word (e.g. Windows NT vs Windows) points at a different key.
• A value you set seems to have no effect. Check the type. reg query shows REG_DWORD vs REG_SZ; policies expect DWORDs. Re-add with the correct /t.
• reg query HKLM /f password /s returns nothing or hangs. Recursive searches over a whole hive are slow and can be large; scope the search to a subtree (e.g. a specific Software path) and add /t REG_SZ to limit types.
• Changes do not persist after reboot in the lab. Some policy keys are refreshed by Group Policy. If your VM is domain-joined or has local policy, GPO may overwrite manual reg add values — expected, and a reminder that the durable fix is at the policy layer, not a one-off value.

Questions to ask when a registry check fails or surprises you:

1. Am I in an elevated prompt, and does this key require it?
2. Is the path exactly right (hive, Windows vs Windows NT, spelling)?
3. Is the value the type I expect, and does its data mean what I think (0x1 = enabled)?
4. For an escalation claim: who can write this, and who runs what it points to — is a boundary actually crossed?
5. Could Group Policy be setting this value out from under me?

Memory safety

Security & safety — detection, logging, and evidence handling

The registry is a favorite place for attackers to hide, so defenders must be able to see changes to it. Enable auditing and forward the events.

What to log (registry-relevant Windows events):

• Enable object-access auditing and set a SACL on sensitive keys (Run keys, Winlogon, the Installer policy key). This produces Event ID 4657 ("A registry value was modified") in the Security log.
• Event ID 4663 — an attempt to access a registry object.
• Sysmon Event ID 12/13/14 — registry key/value create, set, and rename — is the practical, high-signal source most teams rely on.
• For each event capture: timestamp, source account/SID and process, the key/value path (the resource), the old and new data where available, the result (success/failure — the security decision), and a correlation id so you can tie the change to a session or host across your SIEM.

What to NEVER log:

• The plaintext contents of secret-bearing values (e.g. a DefaultPassword). Log that the value at a path changed, not the password itself.
• Session tokens, private keys, full password data, or unrelated PII pulled from other values. Redact before the event leaves the host.

Which events signal abuse:

• A new value under an HKLM Run/RunOnce key, especially pointing to a user-writable path or a temp directory.
• AlwaysInstallElevated flipping to 1 in either hive.
• A DefaultPassword/AutoAdminLogon appearing under Winlogon.
• Changes made by an unexpected process (a script host, an office app) rather than an installer or admin tool.

How false positives arise:

• Legitimate software installers add Run keys and touch policy values as designed.
• Patch cycles and management agents (SCCM/Intune) change many keys in bursts.
• Group Policy re-writes policy values on refresh, which can look like tampering.
• Tune by baselining known-good software and correlating the process that made the change, not just the key path.

Evidence handling: if a value must be captured as proof, store it in an approved, access-controlled evidence location, redact any secret data, and reference it by path and hash in the report rather than pasting the raw secret.

Real-world uses

Authorized real-world use case: during a scoped internal Windows penetration test, a reviewer enumerates a workstation's registry to look for quick escalation and hygiene issues. They read (never blindly write) the Run keys, Winlogon autologon values, and the AlwaysInstallElevated policy in both hives. Finding AlwaysInstallElevated = 1 in both hives, they document a high-severity finding, provide a safe reproduction, and hand the client a remediation (set to 0/delete via GPO) plus a retest query. The blue team, in parallel, uses the same knowledge to write a detection: alert when AlwaysInstallElevated is set or when a Run key gains a value pointing at a user-writable path.

Professional best-practice habits:

Beginners should aim to read, understand, report, and verify a fix. Advanced practitioners move to fleet-wide hardening baselines, detection engineering, and ACL analysis of who can write which autostart locations.

Practice tasks

All tasks are lab-only: run them on a personal Windows VM, a disposable container, or an intentionally-vulnerable practice box you own or are explicitly authorized to use. Never against systems you do not control.

Authorization checklist (complete before any write):

• The target is a VM/box I own or am explicitly authorized to test.
• I have a snapshot or can rebuild the machine.
• Writes are limited to the keys named in the task.
• I have the cleanup/reset steps ready before I start.

Beginner 1 — Map the hives.

• Objective: build a mental model of the tree.
• Requirements: using reg query, list the top of HKLM and HKCU, then read one value from a harmless key (e.g. HKLM\Software\Microsoft\Windows NT\CurrentVersion /v ProductName).
• Output: note the hive, key path, value name, type, and data for the value you read.
• Constraints: read-only; no reg add/reg delete.
• Hints: reg query <key> with no /v lists everything under a key.
• Concepts: hives, keys, values, value types.

Beginner 2 — Inventory autostart entries.

• Objective: find what launches automatically.
• Requirements: query both HKLM\...\CurrentVersion\Run and HKCU\...\CurrentVersion\Run. For each value, write down whether it would run machine-wide or for the current user only.
• Output: a two-column list (value → scope).
• Constraints: read-only.
• Hints: the hive tells you the scope; HKCU = current user, HKLM = everyone.
• Concepts: autorun keys, hive scope, persistence vs escalation.

Intermediate 1 — Detect AlwaysInstallElevated correctly.

• Objective: apply the two-hive rule.
• Requirements: in the lab, plant the misconfig from the lesson (both hives 1), then write the exact two queries that determine exploitability. Then set HKCU to 0 and re-run — show that it is now not exploitable even though HKLM is still 1.
• Input/Output: record the 0x1/0x0 results for each state.
• Constraints: lab VM only; REG_DWORD type.
• Hints: both must be 1; either being 0/absent means safe.
• Concepts: AlwaysInstallElevated, DWORD type, false positives.
• Defensive conclusion: remediate by setting both to 0, then verify with the same queries.

Intermediate 2 — Find and safely handle a stored secret.

• Objective: detect a plaintext autologon credential without mishandling it.
• Requirements: plant a DefaultPassword with a <development-placeholder> value, then query Winlogon to detect it. Write a one-line finding that records the location but not the secret.
• Output: a finding note (path + "cleartext credential present") — no password copied.
• Constraints: lab only; placeholder value only.
• Hints: presence of the value is the finding.
• Concepts: stored secrets, evidence handling, what-not-to-log.
• Defensive conclusion: reg delete the value and any AutoAdminLogon, then re-query to prove it is gone.

Challenge — End-to-end detect → remediate → verify → detect (defensive).

• Objective: run a full mini-audit and prove your fix.
• Requirements: on your lab VM, (1) plant AlwaysInstallElevated (both hives) and a placeholder Winlogon DefaultPassword; (2) write a short script/checklist that detects both issues; (3) remediate both; (4) re-run the detection to verify a clean result; (5) describe which log/Sysmon events would have recorded each change and one plausible false positive for each.
• Constraints: lab only; every write reversible; complete the authorization checklist first.
• Hints: keep detection and remediation as separate, re-runnable steps so verification is just "run detection again."
• Concepts: everything above plus detection/logging.
• Defensive conclusion: the deliverable is the verified clean state and the detection logic, not the misconfig.

Lab cleanup / reset steps:

1. reg delete "HKLM\Software\Policies\Microsoft\Windows\Installer" /v AlwaysInstallElevated /f
2. reg delete "HKCU\Software\Policies\Microsoft\Windows\Installer" /v AlwaysInstallElevated /f
3. reg delete "HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon" /v DefaultPassword /f
4. reg delete "HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon" /v AutoAdminLogon /f
5. Prefer reverting to a clean VM snapshot to guarantee no residue.

Summary

Main concepts. The registry is Windows' central configuration database, organized into hives (HKLM = machine-wide/admin, HKCU = current user) that contain keys (folders) and values (name + type + data). Three security-relevant areas: autorun (Run) keys (persistence, and escalation when a machine-wide key or its target is writable by a low user), stored secrets (Winlogon DefaultPassword in cleartext), and the AlwaysInstallElevated policy (SYSTEM installs when set to 1 in both HKLM and HKCU).

Key syntax/commands. reg query <key> [/v <name>] [/s /f <pattern>] to read; reg add ... /t REG_DWORD /d 1 /f and reg delete ... /f to change (lab only); regedit for the GUI.

Common mistakes. Reporting AlwaysInstallElevated from one hive; calling an HKCU Run entry "escalation" (no boundary crossed); editing a machine you do not own; wrong value type; copying real secrets into notes.

What to remember. Reads are safe; writes belong only in an authorized lab. Escalation requires a low user's input to run in a higher context — always ask who writes vs who runs. Every finding needs a fix plus a verification (re-run the detection and see a clean result), and defenders should log registry changes (Event ID 4657, Sysmon 12–14) while never logging the secret values themselves. Nothing is ever "completely secure" — you reduce and detect risk, then prove it.