AlwaysInstallElevated: The Windows Installer Misconfiguration That Hands Attackers SYSTEM

AlwaysInstallElevated lets any user install MSIs as SYSTEM. Here's how the LPE works, the two registry keys that trigger it, and how to audit for it.

Most privilege-escalation bugs on Windows are exactly that — bugs. A race condition, an unquoted service path, a DLL loaded from a writable directory. AlwaysInstallElevated is different: it isn't a bug at all. It's a documented policy setting that, when enabled, tells the Windows Installer to run every MSI package with NT AUTHORITY\SYSTEM privileges — no matter who launched it. Flip two registry values and any standard user on the box can install a package that spawns a SYSTEM shell. No exploit, no memory corruption, no CVE. Just a setting that should never have been turned on.

It shows up constantly in the wild because it's genuinely useful to the person who enables it: a help-desk or software-deployment team wants unprivileged users to be able to install approved MSIs without a UAC prompt or an admin call-out. The setting does exactly that — and quietly turns the entire software-installation pipeline into a SYSTEM-execution primitive.

The two registry keys

AlwaysInstallElevated is only dangerous when it is enabled in both the machine hive and the user hive. The Installer checks both, and both must be set to 1 for elevated installs to happen:

HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer\AlwaysInstallElevated = 1
HKCU\SOFTWARE\Policies\Microsoft\Windows\Installer\AlwaysInstallElevated = 1

This "both hives" requirement is why a good audit doesn't just flag the machine key in isolation. A lone HKLM=1 with no matching HKCU value is a misconfiguration worth noting, but it is not directly exploitable by an attacker who can't already write the user hive of a victim — and an attacker who owns HKCU for their own session plus a set HKLM key has everything they need. The exploitable condition is the pair. Reporting a Critical only when both are 1, and an Informational when just one is, keeps the signal honest.

How the escalation works

Once both keys are set, the path from standard user to SYSTEM is short:

The attacker (or any low-priv user) crafts a malicious MSI whose custom action runs a payload — add a local admin, drop a service, or pop a reverse shell.
They run msiexec /quiet /qn /i evil.msi.
Because AlwaysInstallElevated is on, msiexec installs the package in the SYSTEM context, and the custom action executes as SYSTEM.

Tooling like msfvenom -f msi generates a working package in one line, which is why this is one of the first things offensive tooling (PowerUp, WinPEAS, Seatbelt) checks for during local enumeration. If your machine is exploitable, an attacker's automated recon will find it in seconds.

The mental model: AlwaysInstallElevated doesn't grant a permission — it removes the boundary between "user can install software" and "user can run code as SYSTEM." Those are supposed to be very different privileges.

Why it survives so long

Three reasons this misconfiguration lingers on networks for years:

It's invisible day to day. Nothing breaks, no error appears, installs just work. The setting only matters the moment someone weaponizes it.
It's set by GPO, then forgotten. A deployment policy from three org-charts ago pushes it fleet-wide, and no one revisits it.
Standard vuln scanners under-weight it. Because it's a "policy," some tools report it as informational rather than the SYSTEM-level LPE it actually is.

The fix

There is essentially no legitimate reason to leave AlwaysInstallElevated enabled. Use a proper software-deployment channel (SCCM/Intune, an elevated deployment service, or a curated MSI catalog run by a privileged installer account) instead. To remediate, set both values to 0 or delete them:

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

Via Group Policy the same setting lives under Computer Configuration → Administrative Templates → Windows Components → Windows Installer → "Always install with elevated privileges" (and the mirror under User Configuration). Set both to Disabled. If your fleet is managed by GPO, fix it at the policy source or it will re-apply on the next refresh.

Auditing for it

WinSentinel's Windows Installer analyzer reads both hives locally and reports the exploitable pair as a Critical finding, a single-hive setting as Informational, and confirms it's not misfiring on the Windows defaults. It runs as part of a standard audit — no configuration needed:

dotnet tool install --global WinSentinel.Cli
winsentinel --audit

The check is entirely local and read-only: it opens the two policy keys, compares against the safe default (absent / 0), and never writes anything. On a single machine the whole module is free. Across a fleet, the same finding rolls up into an org-level view so you can answer "is any node in my estate exploitable via AlwaysInstallElevated?" in one place instead of RDP-ing to each box.

AlwaysInstallElevated is the kind of finding that's boring right up until it's the pivot in an incident report. It costs nothing to check for and nothing to fix — so there's no excuse to be carrying it.