Windows AlwaysInstallElevated 配置缺陷导致本地权限提升的验证与修复

背景

AlwaysInstallElevated 是 Windows Installer 的一项策略配置。若计算机策略与当前用户策略同时启用，低权限用户启动 MSI 安装包时，Windows Installer 可能使用 SYSTEM 权限执行安装逻辑。该问题本质上属于错误的权限边界配置，常见于为解决软件部署权限问题而临时开启策略、随后未及时回收的终端或服务器。

本文仅讨论已授权环境中的配置核查与无破坏验证，不提供恶意 MSI 制作方法。排查重点包括双注册表项、策略来源、Windows Installer 服务行为以及日志留痕。

适用场景与风险条件

产生实际风险通常需要同时满足以下条件：

• 低权限用户能够登录目标 Windows 主机并执行本地程序。
• HKLM 与 HKCU 下的 AlwaysInstallElevated 均为 DWORD 值 1。
• Windows Installer 未被其他应用控制策略完全阻断。
• 攻击者能够向本地磁盘写入或访问一个自定义 MSI 包。

如果只有一个注册表项被启用，通常不足以形成该权限提升路径，但仍应视为策略配置异常。特别要注意：HKCU 的检查必须在目标普通用户上下文中执行，管理员账户下查到的结果不能代表其他用户配置。

问题定位

先以待验证的普通域用户或本地用户登录，在非提权命令行中读取策略。不要只依赖自动化扫描器的结论。

whoami
whoami /groups

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

powershell -NoProfile -Command "$m=(Get-ItemProperty -Path 'HKLM:\Software\Policies\Microsoft\Windows\Installer' -Name AlwaysInstallElevated -ErrorAction SilentlyContinue).AlwaysInstallElevated; $u=(Get-ItemProperty -Path 'HKCU:\Software\Policies\Microsoft\Windows\Installer' -Name AlwaysInstallElevated -ErrorAction SilentlyContinue).AlwaysInstallElevated; [pscustomobject]@{Machine=$m;User=$u;Exploitable=($m -eq 1 -and $u -eq 1)}"

两个值均为 0x1 时，应进一步确认它们来自本地策略还是域组策略，避免直接改注册表后被 GPO 再次覆盖。

gpresult /scope computer /h C:\Windows\Temp\gp-computer.html
gpresult /scope user /h C:\Windows\Temp\gp-user.html

reg query "HKLM\Software\Policies\Microsoft\Windows\Installer" /s
reg query "HKCU\Software\Policies\Microsoft\Windows\Installer" /s

技术分析

相关策略分别位于计算机和用户策略分支：

MSI 不只是文件复制容器，还可包含自定义操作。双策略启用后，安装事务中的高权限阶段可能由 Windows Installer 服务执行，因此原本只能控制自身用户目录的普通用户，有机会让安装逻辑跨越到 SYSTEM 权限边界。

不能仅以“安装成功”判断漏洞成立。验证时应证明高权限安装阶段确实发生，同时避免写入系统敏感位置、创建账户、关闭防护或建立持久化。

授权环境中的安全验证

推荐使用内部签名的审计 MSI。该安装包只执行两个动作：将固定文本写入专用测试目录，并在文件内容中记录执行身份；卸载时删除测试文件。不要让验证包调用 PowerShell、cmd、网络下载或用户管理命令。

测试目录可固定为 C:\ProgramData\AE-Audit，并提前记录基线。执行前开启 MSI 详细日志：

mkdir C:\ProgramData\AE-Audit 2>nul
icacls C:\ProgramData\AE-Audit

msiexec.exe /i C:\Audit\AE-Audit.msi /qn /norestart /L*V C:\Windows\Temp\AE-Audit-install.log

type C:\ProgramData\AE-Audit\execution-context.txt
icacls C:\ProgramData\AE-Audit\execution-context.txt
findstr /i /c:"Product:" /c:"Action start" /c:"Return value 3" C:\Windows\Temp\AE-Audit-install.log

msiexec.exe /x C:\Audit\AE-Audit.msi /qn /norestart /L*V C:\Windows\Temp\AE-Audit-remove.log

审计 MSI 应在隔离测试机上预先检查其 CustomAction 表、InstallExecuteSequence 表和签名状态。可以使用 Windows SDK 中的 Orca 检查表项，确认不存在外部命令、网络访问、服务创建和自启动配置。生产环境中优先选择仅写入审计文件的原生 MSI 动作。

日志与取证排查

Windows Installer 相关事件通常可在 Application 日志和 Microsoft-Windows-MSIInstaller 提供程序中找到。不同系统版本的事件内容存在差异，应按提供程序、产品名、时间窗口和调用进程关联，而不是只依赖单一事件编号。

wevtutil qe Application /q:"*[System[Provider[@Name='MsiInstaller'] and TimeCreated[timediff(@SystemTime) <= 86400000]]]" /f:text /c:100

powershell -NoProfile -Command "Get-WinEvent -FilterHashtable @{LogName='Application'; ProviderName='MsiInstaller'; StartTime=(Get-Date).AddDays(-1)} -ErrorAction SilentlyContinue | Select-Object TimeCreated,Id,LevelDisplayName,Message | Format-List"

powershell -NoProfile -Command "Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4688; StartTime=(Get-Date).AddHours(-4)} -ErrorAction SilentlyContinue | Where-Object {$_.Message -match 'msiexec.exe'} | Select-Object TimeCreated,Id,Message | Format-List"

若环境已启用进程创建审计或 Sysmon，可重点检查普通用户会话启动 msiexec.exe 后，由 SYSTEM 上下文产生的子进程。正常软件部署也可能出现相似行为，因此需要结合 MSI 路径、签名、哈希、父进程、命令行及安装时间判断。

• MSI 是否来自用户可写目录，例如 Downloads、Temp、桌面或共享盘。
• 文件是否无签名，或签名主体与组织的软件发布方不一致。
• msiexec.exe 是否出现异常子进程，如脚本解释器、用户管理工具或网络客户端。
• 安装时间附近是否新增服务、计划任务、管理员组成员或启动项。
• 终端防护是否记录同一文件哈希在多台主机执行。

修复步骤

首选从对应的本地或域组策略中禁用，不建议只删除注册表值。策略位置通常为“计算机配置或用户配置 → 管理模板 → Windows 组件 → Windows Installer → 始终以提升的权限进行安装”，计算机和用户两侧都应设置为“已禁用”。

确认不受域策略托管后，可由管理员进行应急处置：

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

gpupdate /force

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

HKCU 修复需覆盖所有受影响用户配置。域环境应修改下发该配置的 GPO，并通过 gpresult 确认最终生效对象；若仅在管理员会话中修改 HKCU，其他用户配置单元中的危险值仍可能保留。

纵深防护建议

• 通过基线策略明确禁用计算机和用户两侧的 AlwaysInstallElevated。
• 使用 AppLocker 或 Windows Defender Application Control 限制非受信 MSI，尤其是用户可写目录中的安装包。
• 软件分发统一使用受管平台和组织签名，不把“允许所有用户提权安装”作为部署兼容方案。
• 保留 Windows Installer 日志，并采集进程创建事件、命令行和文件哈希。
• 对策略注册表项建立持续合规检查，避免临时排障配置长期遗留。
• 发现疑似利用后，不要只修复策略；还应检查服务、计划任务、本地管理员组、启动项及近期落地文件。

复测标准

修复完成后，至少验证以下三项：两个策略值均不存在或为 0；普通用户执行审计 MSI 时不再获得提升后的安装行为；域策略刷新和重启后配置不会回滚。若启用了应用控制，还应确认来自用户可写目录的未授权 MSI 被阻断并产生可检索日志。

总结

AlwaysInstallElevated 的危险点不是单个注册表值，而是计算机与用户策略同时放宽 Windows Installer 权限。有效排查需要在真实普通用户上下文中检查双策略、追溯 GPO 来源，并结合 MSI 日志和进程审计确认权限边界。修复时应从策略源头禁用，同时补充安装包签名、应用控制和日志监控，避免同类配置再次进入生产环境。

这个问题排查时要同时检查计算机和当前用户两处策略。只有两处的 AlwaysInstallElevated 都为 1，普通用户启动的 MSI 才会按提升权限安装：

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

powershell -NoProfile -Command "$p='Software\Policies\Microsoft\Windows\Installer'; [pscustomobject]@{HKLM=(Get-ItemPropertyValue -Path ('Registry::HKEY_LOCAL_MACHINE\'+$p) -Name AlwaysInstallElevated -ErrorAction SilentlyContinue); HKCU=(Get-ItemPropertyValue -Path ('Registry::HKEY_CURRENT_USER\'+$p) -Name AlwaysInstallElevated -ErrorAction SilentlyContinue)}"

不要只删注册表值，还要确认它是否由域策略或 MDM 下发，否则刷新策略后会重新出现：

gpresult /h "%TEMP%\gp.html"
start "" "%TEMP%\gp.html"

reg query "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\History" /s /f AlwaysInstallElevated

修复建议在组策略中将以下两项都显式设为“已禁用”，而不是“未配置”：

• 计算机配置 → 管理模板 → Windows 组件 → Windows Installer → 始终以提升的权限进行安装
• 用户配置 → 管理模板 → Windows 组件 → Windows Installer → 始终以提升的权限进行安装

单机应急处理可以直接写入禁用值，之后再刷新策略并复查：

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
gpupdate /force

验证漏洞时不建议使用带命令执行、自启动或新增管理员账户动作的 MSI。在隔离测试机上制作一个仅尝试向受保护目录写入标记文件的测试包即可，并结合 Procmon 确认 msiexec.exe 的完整性级别及写入结果。修复后，标准用户发起同一安装应无法静默完成受保护写入，且应进入正常的 UAC/管理员凭据流程。

最后建议排查策略暴露期间的安装痕迹。可查看“应用程序”日志中的 MsiInstaller 事件，并重点核对非管理员用户发起、来源位于用户可写目录或临时目录的 MSI：

Get-WinEvent -FilterHashtable @{
  LogName='Application'
  ProviderName='MsiInstaller'
  StartTime=(Get-Date).AddDays(-30)
} | Select-Object TimeCreated, Id, UserId, Message |
    Sort-Object TimeCreated -Descending

这里需要注意：把策略关闭只能阻止后续利用，不会回滚此前 MSI 已写入的服务、计划任务、启动项或文件。若确认曾长期同时启用两处策略，还应继续检查服务创建、计划任务和本地管理员组变更。