Privilege Escalation · intermediate · ~11 min
**What you will learn** - Enumerate the three classic configuration-only Windows escalation routes: writable **autorun** entries, writable **scheduled-task** targets, and the **AlwaysInstallElevated** MSI policy. - Read and reason about **ACLs and trust boundaries** so you can tell whether a low-privileged user can influence code that a higher-privileged principal runs. - Identify common **stored-credential** hiding spots (Credential Manager, Winlogon autologon, `Unattend.xml`, shell histories) and why they shortcut escalation. - Apply the **defensive fix** for each finding: tighten ACLs, disable AlwaysInstallElevated, purge secrets — and, most importantly, **verify** the fix actually blocks the abuse. - Know which **logs and events** reveal these techniques being attempted, and what you must never log. - Do all of this only inside an **authorized, isolated lab**.
Security objective. The asset you are protecting is administrative control of a Windows host — the SYSTEM / local-admin identity and everything it can reach. The threat is a local, already-authenticated but low-privileged user (or malware running in their context) turning that foothold into full administrator without exploiting a memory bug. As a defender you will learn to detect these misconfigurations before an attacker does, and to remediate and verify them.
This lesson builds directly on two prerequisites. From The Windows registry you already know how keys, values, and the HKLM (machine-wide) vs HKCU (per-user) hives work — that matters because every technique here hinges on who can write which key. From Windows privesc: service misconfigurations you already know the core idea that a privileged process running an artifact a weaker user can modify = escalation; autoruns and scheduled tasks are the same idea applied to different launchers.
Where does this show up? On real engagements these are among the first things an authorized tester (and every automated tool like WinPEAS/PowerUp) checks, precisely because they are pure configuration mistakes — no exploit code, no crash, just an ACL that is too generous or a policy flag left on. Understanding them makes you far better at hardening Windows, which is the point of learning them here.
In authorized professional work these findings matter for three reasons.
Run key, a scheduled task pointed at a world-writable script, or AlwaysInstallElevated=1 gives an attacker SYSTEM using only built-in tools. There is no CVE to patch — only a configuration to fix — so they persist for years in enterprise images and gold builds.AlwaysInstallElevated is sometimes enabled by well-meaning admins to let standard users install approved software. Leftover Unattend.xml from imaging routinely contains plaintext passwords.Each route below follows the same shape: a privileged principal executes something a lower-privileged user can influence. Learn to spot the influence point and the trust boundary it crosses.
Definition. Autorun locations (e.g. HKLM\Software\Microsoft\Windows\CurrentVersion\Run, ...\RunOnce, Startup folders) list programs Windows launches automatically at boot or logon.
Plain explanation. Whatever an HKLM autorun launches runs with the privileges of the account that triggers it — often an administrator at logon, or SYSTEM at boot. If a standard user can write the autorun value (repoint it) or overwrite the target binary it references, their code runs at that higher privilege the next time the trigger fires.
How it works. Windows reads the value at logon/boot and starts the referenced program. Two independent weaknesses matter: the ACL on the registry key (can I change what runs?) and the ACL on the target file (can I change the file that runs?). Either one is enough.
When / when-not. Relevant when a low-priv user has write access to a machine-wide autorun or its target. Not relevant for HKCU autoruns that only run as that same user — no boundary is crossed, so there is no escalation.
Pitfall. Assuming a program in HKLM is safe because only admins should be able to change it. Always check the actual ACL; installers sometimes loosen it.
Definition. The Task Scheduler runs programs/scripts on triggers (time, logon, event) as a configured user.
Plain explanation. This is Windows' equivalent of cron. If a task runs as SYSTEM or an admin but executes a script or binary a weaker user can modify, your code runs as the task's user when it next fires.
How it works. Enumerate with schtasks /query /fo LIST /v. For each task note Run As User, the Task To Run path, and whether you can write that path (or its containing directory). A writable target under a SYSTEM task is the escalation.
When / when-not. Relevant only when the task's principal is more privileged than you and you can influence its target. A task that runs as you, targeting a file only you can write, crosses no boundary.
Pitfall. Focusing on the .exe and missing that the folder is writable — an attacker who can add or replace files in the target directory may still win (e.g. DLL/script planted alongside).
Definition. A Windows Installer policy that, when enabled in both HKLM and HKCU, makes any user's MSI installs run with SYSTEM privileges.
Plain explanation. The two values are HKLM\Software\Policies\Microsoft\Windows\Installer\AlwaysInstallElevated and the same path under HKCU. If both equal 1, any standard user can install an MSI that executes as SYSTEM — a pure misconfiguration, no exploit needed.
How it works. Windows Installer checks both keys before elevating a per-user install. Both set → the install runs elevated → a crafted MSI's custom action runs as SYSTEM. One key set alone does nothing; the AND is deliberate.
When / when-not. Only exploitable when both keys are 1. If either is 0 or absent, the policy is off. This is why the quiz stresses "both keys."
Pitfall. Thinking it is a bug in Windows. It is an intentional (rarely appropriate) policy — the defense is simply never to enable it.
Definition. Secrets left recoverable on disk or in the registry.
Plain explanation. Escalation often skips all of the above because a password is just lying around: Windows Credential Manager, autologon secrets under HKLM\...\Winlogon (DefaultPassword), imaging leftovers (Unattend.xml, sysprep.inf), and shell histories (PowerShell ConsoleHost_history.txt). A recovered admin password ends the game.
How it works. Each store has a known location; a privesc check reads them and looks for credentials the current user should not have.
When / when-not. Relevant on any host that was imaged, auto-logs-in, or where users typed secrets into a shell. Not a factor on a clean, well-managed host — which is the goal.
Pitfall. Believing a credential in Unattend.xml is safe because it is "encoded." Base64 is not encryption; those passwords are trivially recovered.
THREAT MODEL — single Windows host (authorized lab)
ASSET: administrative control (SYSTEM / local admin) + secrets it guards
Trust boundary A: standard user <—> machine-wide config (HKLM, %ProgramData%)
Trust boundary B: standard user <—> privileged principal (SYSTEM/admin)
+-------------------- Windows host --------------------+
| |
| [ Standard user shell ] (entry point: local login) |
| | |
| | can WRITE ... |
| v |
| (A) HKLM Run key / target binary --at logon--> runs as ADMIN >>> boundary crossed
| (A) Scheduled-task script/target --on trigger-> runs as SYSTEM >>> boundary crossed
| (B) MSI + AlwaysInstallElevated=1 --on install-> runs as SYSTEM >>> boundary crossed
| | |
| | can READ ... |
| v |
| Unattend.xml / Winlogon DefaultPassword / history --> admin creds recovered
| |
+------------------------------------------------------+
DEFENDER GOAL: no write path across A, both AIE keys = 0, no readable secrets
Knowledge check.
HKLM or its target binary is automatically protected — when the actual ACL grants standard users write access.)Read-only enumeration you would run inside your own lab. Everything below reads configuration; none of it changes the system.
:: --- Autoruns (machine-wide) ---
reg query "HKLM\Software\Microsoft\Windows\CurrentVersion\Run"
:: lists Value = program that launches machine-wide at logon
:: --- Scheduled tasks (verbose: shows Run As User + Task To Run) ---
schtasks /query /fo LIST /v
:: --- AlwaysInstallElevated: BOTH must be 1 to be exploitable ---
reg query HKLM\Software\Policies\Microsoft\Windows\Installer /v AlwaysInstallElevated
reg query HKCU\Software\Policies\Microsoft\Windows\Installer /v AlwaysInstallElevated
:: --- Autologon secret (read-only check) ---
reg query "HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon" /v DefaultPassword
# Inspect the ACL on an autorun's TARGET file — the key question is
# "can a standard user (or 'Everyone'/'Users') write it?"
Get-Acl 'C:\Program Files\Vendor\agent.exe' | Format-List
# icacls gives a compact view; look for (W)/(M)/(F) granted to Users/Everyone
icacls 'C:\Program Files\Vendor\agent.exe'
Annotations: reg query prints values without changing them. In schtasks ... /v, the fields that decide risk are Run As User (is it more privileged than me?) and Task To Run (can I write that path?). For AlwaysInstallElevated, the rule is a logical AND — one key alone is harmless.
More Windows escalation routes, all variations of "something privileged runs code you can influence".
Programs launched from HKLM\...\Run (and similar) start with the privileges of whoever the autorun runs as. If you can write an HKLM autorun key, or the binary one points to is writable, your code runs at that privilege (often admin/SYSTEM at boot/logon).
Like cron on Linux: a task running as a privileged user that executes a writable script/binary, or one you can reconfigure, runs your code as that user. Enumerate with schtasks /query /fo LIST /v.
A pair of registry flags (HKLM + HKCU ...\Installer\AlwaysInstallElevated = 1) that let any user install MSI packages as SYSTEM. If both are set, craft a malicious MSI → instant SYSTEM. A pure misconfiguration, no exploit. Check both keys.
Windows hides credentials in several places a privesc check harvests: the Credential Manager, autologon settings in the registry (winlogon), unattended-install files (Unattend.xml, sysprep.inf), and saved RDP/PowerShell-history secrets.
Lock down HKLM autorun and task binary ACLs; never set AlwaysInstallElevated; clear credentials from unattend files, registry, and history; use a credential vault.
The example is concept-track (Windows shell/PowerShell + registry), following the INSECURE → SECURE → VERIFY shape. Run only in an isolated lab VM you own.
The following sets up the AlwaysInstallElevated misconfiguration so you can study it. It requires admin to create (that models the mistake an admin makes); the point is what it then allows a standard user to do.
# INSECURE SETUP (lab only): enable AlwaysInstallElevated in BOTH hives.
# This is the misconfiguration under study — never do this on a real host.
New-Item -Path 'HKLM:\Software\Policies\Microsoft\Windows\Installer' -Force | Out-Null
New-Item -Path 'HKCU:\Software\Policies\Microsoft\Windows\Installer' -Force | Out-Null
Set-ItemProperty 'HKLM:\Software\Policies\Microsoft\Windows\Installer' AlwaysInstallElevated 1 -Type DWord
Set-ItemProperty 'HKCU:\Software\Policies\Microsoft\Windows\Installer' AlwaysInstallElevated 1 -Type DWord
With both keys 1, any standard user's MSI install would run as SYSTEM. We deliberately do not provide a payload MSI — that is the offensive half, and it is unnecessary to learn the defense. The finding is proven simply by reading both keys (below).
# REMEDIATION: turn the policy OFF in both hives.
# Preferred in production: enforce via Group Policy so it cannot drift back on.
Set-ItemProperty 'HKLM:\Software\Policies\Microsoft\Windows\Installer' AlwaysInstallElevated 0 -Type DWord
Set-ItemProperty 'HKCU:\Software\Policies\Microsoft\Windows\Installer' AlwaysInstallElevated 0 -Type DWord
# For the autorun/task routes, the fix is an ACL: remove write access from
# standard users on the machine-wide target. Example for an autorun binary:
icacls 'C:\Program Files\Vendor\agent.exe' /remove:g "Users" "Everyone"
icacls 'C:\Program Files\Vendor\agent.exe' /grant:r "Administrators:(F)" "SYSTEM:(F)" "Users:(RX)"
# CHECK 1: AlwaysInstallElevated must be 0 (or absent) in at least one hive.
$hklm = (Get-ItemProperty 'HKLM:\Software\Policies\Microsoft\Windows\Installer' -EA SilentlyContinue).AlwaysInstallElevated
$hkcu = (Get-ItemProperty 'HKCU:\Software\Policies\Microsoft\Windows\Installer' -EA SilentlyContinue).AlwaysInstallElevated
if (($hklm -eq 1) -and ($hkcu -eq 1)) { Write-Host 'FAIL: AlwaysInstallElevated still exploitable' }
else { Write-Host 'PASS: AlwaysInstallElevated disabled' }
# CHECK 2: standard users must NOT have write on the autorun target.
$acl = icacls 'C:\Program Files\Vendor\agent.exe'
if ($acl -match 'Users:.*\(W\)|Everyone:.*\(W\)|Users:.*\(M\)|Users:.*\(F\)') {
Write-Host 'FAIL: standard users can still write the autorun target'
} else {
Write-Host 'PASS: autorun target not writable by standard users'
}
Expected behaviour. Right after the insecure setup, CHECK 1 prints FAIL. After the remediation runs, CHECK 1 prints PASS; CHECK 2 prints PASS once the loose ACL is removed. The "good input" case (an admin still installing a legitimately-elevated MSI through approved channels, or writing the protected file) is unaffected — you have removed the unauthorized path, not the authorized one. That is the defensive proof: bad path rejected, legitimate admin path intact.
Walking the VERIFY block, which is the part that matters for defenders.
| Step | Line | What happens | Why it matters |
|---|---|---|---|
| 1 | $hklm = (Get-ItemProperty ...).AlwaysInstallElevated |
Reads the HKLM policy value; -EA SilentlyContinue yields $null if the key/value is absent |
Absent is treated as "off" — the safe default |
| 2 | $hkcu = (Get-ItemProperty ...) |
Same for the HKCU hive | Both hives must be read because the abuse needs both = 1 |
| 3 | if (($hklm -eq 1) -and ($hkcu -eq 1)) |
The logical AND that mirrors Windows' own check | Encodes the exact exploit precondition, so the test can't give a false PASS |
| 4 | prints FAIL / PASS |
Reports the security decision | This line is what you would log/alert on |
| 5 | $acl = icacls '...agent.exe' |
Captures the target's ACL as text | Autorun/task risk is fundamentally an ACL question |
| 6 | if ($acl -match 'Users:.*\(W\)...') |
Regex looks for write/modify/full granted to Users/Everyone |
These groups include the standard user — a write here is the escalation |
| 7 | prints FAIL / PASS |
Final security decision | Ties the remediation to an observable pass condition |
How values change across the exercise: before remediation, $hklm=1, $hkcu=1 → the AND is true → FAIL. After Set-ItemProperty ... 0, $hkcu becomes 0 → the AND is false → PASS, regardless of HKLM, because the exploit needs both. For the ACL, before the fix the regex matches (Users:(W) present) → FAIL; after icacls /remove:g "Users" the match disappears → PASS.
| # | Wrong approach | Why it is wrong | Corrected approach | How to recognise / prevent |
|---|---|---|---|---|
| 1 | Flagging any HKCU autorun as an escalation |
An HKCU Run key runs as that same user — no boundary is crossed |
Only flag machine-wide (HKLM) autoruns, or HKCU entries a different, higher-priv account will execute |
Ask "who runs this, and are they more privileged than the writer?" |
| 2 | Reporting AlwaysInstallElevated when only one key is 1 |
Windows requires both HKLM and HKCU set to elevate |
Confirm both values are 1 before calling it exploitable |
Always query both hives; treat absent as 0 |
| 3 | Checking only the target .exe, not its folder |
If the directory is writable an attacker can replace/plant files even when the exe ACL looks fine | Audit the ACL on both the file and its parent directory | icacls the folder too; watch for Users:(M)/(W) on the dir |
| 4 | Treating a Base64 password in Unattend.xml as safe |
Base64 is encoding, not encryption — it is trivially reversible | Remove imaging leftovers entirely; store secrets in a vault | Grep imaged hosts for Unattend.xml/sysprep.inf and delete post-image |
| 5 | Running these enumeration commands against a system you don't own | It is unauthorized access — illegal and unethical, regardless of intent | Only test hosts you own or have written authorization for | Keep a signed scope/authorization before any enumeration |
| 6 | "WinPEAS found nothing, so the host is secure" | A scanner proves only what it checks; clean output is not proof of security | Combine tooling with manual review and treat it as one signal | Never equate a passing scan with "secure" |
Common friction when studying these routes, and how to work through it.
reg query returns 'ERROR: The system was unable to find the specified registry key or value'. That usually means the value is simply not set — which for AlwaysInstallElevated is the safe state. Confirm by querying both hives; absence = off.schtasks /query shows a task but no Task To Run. Add /v (verbose) and /fo LIST for the full field set including Run As User. Without /v the risk-relevant fields are hidden.icacls output looks cryptic. Decode the letters: (F) full, (M) modify, (W) write, (RX) read+execute. Any W/M/F for Users, Everyone, or Authenticated Users on a privileged target is the red flag.Questions to ask when a check fails: Who is the principal that executes this artifact? Can my current (lowest) user influence it — write the key, the file, or the folder? Does the exploit precondition (e.g. both AIE keys) actually hold? After remediation, did I re-run the verify step from the standard user's context, and did legitimate admin functionality still work?
Security & safety — detection and logging. These techniques are quiet, but they leave traces if you are watching.
What to log (and alert on):
HKLM\...\Run/RunOnce; Windows Event ID 4657 (a registry value was modified) with the object path, the account that made the change, and timestamp.What to NEVER log: the actual credential values you find (passwords from Unattend.xml, DefaultPassword, Credential Manager), session tokens or cookies, private keys, or unneeded PII. Log the fact and location of a secret ("cleartext password present in C:\Windows\Panther\Unattend.xml"), never the secret itself.
Events that signal abuse: a standard user creating a SYSTEM scheduled task; a modification to a machine-wide Run key by a non-admin; a per-user MSI install executing as SYSTEM; new values under Winlogon autologon; reads of Unattend.xml/sysprep.inf outside imaging windows.
How false positives arise: legitimate software installs and updates do create autoruns, tasks, and elevated MSI installs; patch management and imaging touch these same objects. Baseline what "normal" looks like (approved deployment windows, known installer accounts) so alerts fire on the unexpected actor/time, not on routine administration.
Authorized real-world use case. During a scoped internal penetration test or a Windows hardening review, an assessor lands on a standard-user workstation and checks exactly these routes to see whether a real attacker could reach SYSTEM. Findings feed a report the IT team uses to fix the gold image: tighten autorun/task ACLs, disable AlwaysInstallElevated via GPO, and strip imaging secrets. The same checks run continuously as part of a hardening baseline (e.g. CIS benchmarks flag AlwaysInstallElevated).
Professional best-practice habits.
Unattend.xml).Beginner vs advanced.
| Beginner | Advanced | |
|---|---|---|
| Enumeration | Run reg query/schtasks /v/icacls by hand on a lab VM |
Automate baseline drift detection across a fleet; integrate with SIEM |
| Remediation | Set AIE to 0; remove Users write from one target |
Enforce ACLs + policy centrally via GPO/Intune; use LAPS for local-admin secrets |
| Verification | Re-run the two verify checks | Continuous compliance scanning (CIS) + alerting on 4657/4698 |
| Detection | Read the relevant Event IDs after a change | Build correlation rules for "standard user → SYSTEM task" chains |
All tasks are lab-only: use a disposable Windows VM you own (or an intentionally-vulnerable training VM), with a snapshot taken first. Authorization checklist before you start: (1) you own or have written permission for the VM; (2) it is isolated (host-only/NAT, no production network); (3) you have a clean snapshot to revert to; (4) no real credentials are used anywhere. Each task ends by remediating and verifying.
Beginner 1 — Enumerate AlwaysInstallElevated.
HKLM and HKCU Installer keys read-only.0.Beginner 2 — Read an autorun target's ACL.
HKLM\...\Run, pick one target, run icacls on the file and its folder.Users/Everyone and your risk verdict.(F)/(M)/(W)/(RX).Users write and re-check.Intermediate 1 — Scheduled-task target audit.
schtasks /query /fo LIST /v; for each task compare Run As User vs icacls on Task To Run.Intermediate 2 — Fix-and-verify AlwaysInstallElevated.
Challenge — Stored-credential sweep and cleanup.
Unattend.xml/sysprep.inf under C:\Windows\Panther, the Winlogon DefaultPassword value, and PowerShell ConsoleHost_history.txt; report only presence and path, never the secret.Lab cleanup / reset: after any task that changed the VM, revert to your pre-task snapshot (or explicitly set AIE keys back to 0, restore original ACLs, and delete any test files). Confirm the host is back to a clean baseline before ending.
Main concepts. Three configuration-only Windows escalation routes share one shape — a privileged principal runs something a weaker user can influence: writable machine-wide autoruns (key or target binary), writable scheduled-task targets, and AlwaysInstallElevated (any user installs an MSI as SYSTEM when both HKLM and HKCU keys are 1). Stored credentials (Credential Manager, Winlogon autologon, Unattend.xml/sysprep.inf, shell history) often shortcut the whole process. All are pure misconfigurations — no exploit code.
Key syntax/commands. reg query (both Installer hives), schtasks /query /fo LIST /v (note Run As User + Task To Run), icacls/Get-Acl (look for (W)/(M)/(F) granted to Users/Everyone).
Common mistakes. Flagging harmless HKCU-only autoruns; reporting AIE with only one key set; auditing the file but not its folder; trusting Base64'd passwords; equating a clean scanner run with "secure"; enumerating systems you are not authorized to test.
What to remember. Fixes are simple and must be verified: tighten ACLs so standard users can't write privileged autorun/task targets, keep AlwaysInstallElevated off (ideally by GPO), and purge stored secrets into a vault (LAPS). Log autorun/task changes (Event IDs 4657/4698/4702, 4688) and record the location of any secret you find — never the secret itself. Do all of it only on systems you own or are explicitly authorized to test, and reset your lab afterward. Decoding a value is not the same as verifying a control, and nothing is ever "completely secure."