做了十多年Windows系统运维和应急响应见过不少利用系统“信任链”搞事的样本。今天要聊的UAC白名单程序提权本质上不是去爆破系统漏洞而是摸透了UAC用户账户控制的信任机制后用系统自己签名的程序完成权限跳板。简单说一个普通权限的进程可以不弹出任何确认框借助受信任的自动提权程序把自己拉升到管理员权限。这事在攻防演练、恶意软件分析和企业安全加固场景里都是绕不开的一课。对安全工程师、系统管理员和做EDR检测的人来说弄懂这条链路的原理和防御方式比单纯背下几条绕过命令有价值得多。1. 先吃透UAC机制为什么一个弹窗背后藏着这么多文章很多人对UAC的理解停留在“弹窗点确定就提权”但真实机制比这复杂。要讲清白名单程序提权必须先把UAC的底层设计拆开看。1.1 完整性级别UAC不是“弹窗”是门禁系统UAC全称是用户账户控制底层依赖的是Windows的强制完整性控制MIC。系统里每个进程都带了一个完整性级别标签常见的有低、中、高、系统四级。完整性级别决定了进程能访问哪些资源中完整性进程不能向高完整性的目录或注册表项写入高完整性进程也不能直接碰系统完整性级别的内核对象。可以理解成一家公司的门禁卡普通员工卡能进办公区但进不了机房UAC弹窗就是你补办一张进出机房的临时授权卡。管理员账号登录Windows时explorer.exe和大多数用户进程默认拿到的是过滤令牌这个令牌故意去掉了管理员特权所以日常操作都处于中完整性。一旦点击UAC上的“是”进程就切换为完整令牌完整性级别抬到高。提权研究的核心不是研究怎么让UAC弹窗消失而是研究怎么让一个进程跳过过滤令牌、直接获得完整令牌。这里有个很多人忽略的细节标准用户和管理员提升后的令牌并不完全一样。标准用户提升后获得的是管理员组的完整令牌但仍受某些策略限制而管理员提升后拿到的是完整的Administrators令牌。完整性级别是“进程从哪个令牌启动”决定的不是“当前用户是谁”决定的。所以即使你登录的是管理员账号只要进程从过滤令牌启动它就是中完整性写不了高完整性资源。1.2 自动提权标记系统自己信任的程序可以“免检”那什么程序能自己抬高完整性还不弹窗答案藏在程序清单manifest里。manifest中有两个关键字段一个叫requestedExecutionLevel一个叫autoElevate。如果exe的manifest标记为requireAdministrator同时又带autoElevate标记系统会认为它是被微软信任的系统组件直接从过滤令牌自动切换到完整令牌整个过程不出任何弹窗。但微软不是随便什么程序都允许自动提权有几个硬性约束程序二进制必须由微软签名必须位于Program Files或System32这类受保护目录系统还会校验文件是否可能被普通用户篡改。这就是UAC白名单程序的由来——它们是被系统“盖章”的可信程序不需要经过用户确认就能自动提权。我的Windows运维经验里这些程序平时不起眼但它们的价值就在于“自动提权”能力。系统组件需要在登录后直接以管理员权限完成配置比如调整时区、更改默认程序、管理设备设置如果每次都弹窗用户体验会非常糟糕。所以微软用白名单签名目录三重约束来换取体验这个设计在正常情况下没问题问题出在“白名单程序执行的内容是否可控”。1.3 “绕过”的本质信任的边界被越过了UAC白名单提权绕开的核心不在UAC弹窗本身而在这几个条件交汇第一存在一批autoElevate白名单程序第二它们启动时可能会去解析用户可控的配置比如文件关联、协议处理器或环境变量第三用户对注册表HKCU和某些目录有完全控制权。当这三个条件串起来就会形成一条“高完整性进程执行了用户可控命令”的路径。严格意义上UAC白名单提权不算漏洞利用更多是设计特性被滥用。它和内核提权完全不同——不需要Shellcode、不需要覆盖函数指针只需要会改注册表。这也解释了为什么微软历史上对部分入口做了修补但这个思路至今仍有变体活跃因为只要autoElevate机制存在只要用户还能控制某些配置输入同样的逻辑就能换个入口继续生效。2. 白名单程序提权的核心思路拆解理解了UAC的自动提权机制接下来看攻击者到底是怎么利用的。核心思路其实可以总结成一句话找一个自动提权的白名单程序让它以高完整性启动同时想办法让它在启动过程中执行你指定的命令。2.1 为什么攻击者盯上白名单程序如果恶意进程以中完整性运行想提权又不想触发弹窗常见方向有三个一是找内核漏洞代价高且不稳定二是找服务漏洞需要分析服务代码三是找autoElevate程序门槛最低、最稳定。白名单程序这条路最大的优势在于自动提权是系统行为不是漏洞行为。杀毒软件和EDR对系统签名程序的敏感度天然会低一些很多检测规则只看进程名不查父进程链这给了白名单程序很大的躲藏空间。另一个优势是无需编译、无需上传额外的提权工具系统里现成的exe就能用攻击面非常干净。从防御角度看这意味着你在排查提权攻击时不能只看有没有可疑的exe落地还要盯住那些系统白名单程序被调用的上下文。一个fodhelper.exe出现在进程列表里并不算异常但它如果是被一个低权限进程启动的那就值得多看一眼。2.2 文件关联与协议处理器劫持链路最经典的利用方式是“文件关联/协议处理器劫持”。先理解两个概念文件关联是指文件扩展名对应的打开程序协议处理器是指类似ms-settings、mailto这类URL协议对应的处理程序。Windows里这些东西都存在注册表里具体位置是Software\Classes下的键。关键点在于注册表的优先级HKCU\Software\Classes下的键优先级比HKLM\Software\Classes更高。而每个普通用户对HKCU本身有完全写入权限。这意味着普通用户可以定义某个协议的处理程序并且这个定义会覆盖系统级定义。链路就这样通了普通用户先写入一个HKCU\Software\Classes\ms-settings键把默认命令改成自己指定的程序然后运行一个自动提权、内部又会加载ms-settings协议的白名单程序比如fodhelper.exe。fodhelper.exe以高完整性启动后要打开ms-settings协议去注册表找处理程序找到的却是用户预先埋好的恶意命令。于是恶意命令继承了高完整性权限提权完成全程没有任何弹窗。这个链路里最关键的一环是白名单程序启动时会去查询用户可控的注册表项。fodhelper.exe设计上是用来启动Windows设置页面的它用ms-settings协议来定位目标页面这种“运行时查注册表”的行为本身是正常的但查询结果被用户操控了整条链就变味了。2.3 常见白名单目标程序清单工作中经常被利用的自动提权程序我整理了一份常用清单方便做排查时对照。程序路径对应注册表关联原用途利用状态fodhelper.exeHKCU\Software\Classes\ms-settingsWindows设置经典部分系统已缓解ComputerDefaults.exeHKCU\Software\Classes\ms-settings默认程序设置思路相同sdclt.exe备份还原中心相关备份与还原历史上有过版本差异大slui.exeWindows激活系统激活部分版本可用eventvwr.exeHKCU\Software\Classes\mscfile事件查看器老版本可用新版本已修补需要注意这些程序的可用性会随Windows版本变化而变化微软在多次更新中做了针对性修补。排查时不要只盯着exe名字而是要关注“白名单程序注册表关联键”的组合行为。2.4 同类变体思路环境变量与可执行文件搜索顺序除了协议处理器劫持还有两个变体方向值得研究。一个是环境变量劫持某些autoElevate程序启动时会读取特定环境变量来拼接路径如果这个环境变量可以被普通用户覆盖指向可控目录就能在提升后的进程里插入恶意文件。另一个是可执行文件搜索顺序劫持系统在查找DLL或exe时有固定顺序某些自动提权程序会加载它认为“一定存在”的组件但如果在可写路径提前放置同名文件就可能被优先加载。这两个变体的共同规律还是那句找自动提权能力用户可影响的配置输入。做检测时与其针对每个变体单独写规则不如从“谁启动了我信任的程序”这个角度入手效果反而更好。3. 安全研究者视角的实操复盘原理讲完落到实操。这里强调一下以下内容全部基于隔离实验环境目的是理解攻击链路以便做防御检测不是鼓励在任何未授权系统上测试。3.1 三步定位自动提权程序第一步是识别哪些程序带autoElevate标记。微软官方工具SIGCHECK可以查看exe的manifest信息命令很简单sigcheck -m C:\Windows\System32\fodhelper.exe输出里会有一段XML格式的manifest信息重点看requestedExecutionLevel和autoElevate字段。如果两者都满足这个程序就是潜在的自动提权白名单程序。我平时会在干净的测试虚拟机里把System32目录下所有exe批量跑一遍sigcheck筛选出所有带autoElevate标记的文件做一个本地清单这个清单对后续的监控规则白名单很有用。批量筛选后还要人工分析这些程序在启动时会读取哪些注册表键或环境变量。这一步没有捷径只能逐个在Process Monitor里观察注册表访问记录。关注那些HKCU\Software\Classes路径下的读取尤其是有写入权限的键。3.2 文件关联劫持链路验证在隔离实验环境里可以用一个无害命令验证整条链路是否可行。以notepad.exe作为验证命令因为它即使被启动也不会造成破坏。先在测试机写入恶意的协议处理器关联reg add HKCU\Software\Classes\ms-settings\Shell\Open\command /d C:\Windows\System32\notepad.exe /f reg add HKCU\Software\Classes\ms-settings\Shell\Open\command /v DelegateExecute /t REG_SZ /d /f然后触发白名单程序C:\Windows\System32\fodhelper.exe如果一切正常系统会弹出记事本窗口。从用户视角看整个过程没有任何UAC弹窗但notepad.exe实际是在高完整性级别下运行的。这里有两个容易踩的坑。第一个如果只设置默认值而不设置DelegateExecute空值某些Windows版本会忽略默认命令反而去执行系统内部的处理程序。第二个在64位系统上部分程序会受注册表重定向影响写入时要注意别落在WOW6432Node节点下否则可能不被读取。3.3 行为观测与验证提权是否成功不能只看弹没弹窗要看实际进程的完整性级别。用Process Explorer打开notepad.exe的属性切到“安全”标签页能看到完整性级别显示为“高”。或者用命令行验证whoami /groups | findstr S-1-16返回的SID里如果是S-1-16-12288就代表高完整性S-1-16-8192是中完整性。通过这种方式可以清晰看到fodhelper.exe作为白名单程序确实把notepad.exe带到了高完整性级别。从防御角度观察整个进程树explorer.exe中完整性启动了一个不常见的子进程这个进程随后又启动了一个非系统组件。这种“系统信任程序→执行了非签名程序”的进程链是检测UAC提权行为最可靠的信号之一。4. 进程链检测与应急响应理解了攻击链之后防御的重点就很清晰了。这里分享一套实际可落地的检测方案包含Sysmon配置、注册表监控和日志关联分析。4.1 为什么进程链分析是关键单独看fodhelper.exe的启动在系统里每天都会发生很多次不一定异常。但把父进程、子进程串起来看异常就明显了正常情况下fodhelper.exe的父进程应该是explorer.exe或services.exe它启动的子进程是系统设置进程而攻击场景里它的父进程可能是浏览器、Office或恶意脚本进程子进程则可能是cmd.exe、powershell.exe、mshta.exe等脚本宿主。所以进程链分析是这类攻击检测的核心。我见过不少安全设备只关注“fodhelper.exe启动”这种单点事件结果误报率极高根本没法用。改成关注“知名白名单程序→非白名单程序”这个两级进程链后准确率立刻上来了。4.2 Sysmon配置示例Sysmon是Windows上做进程链监控的利器。以下是一个精简的检测配置重点关注进程创建Event ID 1和注册表变更Event ID 13。Sysmon schemaversion4.50 EventFiltering ProcessCreate onmatchinclude ParentImage conditionisC:\Windows\System32\fodhelper.exe/ParentImage Image conditionis notC:\Windows\System32\*.exe/Image /ProcessCreate ProcessCreate onmatchinclude ParentImage conditionisC:\Windows\System32\ComputerDefaults.exe/ParentImage Image conditionis notC:\Windows\System32\*.exe/Image /ProcessCreate RegistryEvent onmatchinclude TargetObject conditioncontainsHKCU\Software\Classes\ms-settings/TargetObject /RegistryEvent /EventFiltering /Sysmon这段配置的意思是如果fodhelper.exe或ComputerDefaults.exe启动了一个不在System32目录下的子进程立刻记录如果HKCU\Software\Classes\ms-settings键被修改也立刻记录。两个规则命中任意一个就说明可能有UAC提权攻击正在发生。实际部署时需要注意Sysmon配置xml用UTF-16编码保存才能正常加载否则服务起不来。安装命令也一并附上sysmon -accepteula -i sysmon-config.xml4.3 注册表关键点监控Sysmon负责事后记录如果想做实时告警可以用PowerShell写一个简单的注册表监听脚本监控常见提权关联键$keys ( HKCU:\Software\Classes\ms-settings, HKCU:\Software\Classes\mscfile, HKCU:\Software\Classes\ms-msdt ) foreach ($key in $keys) { $action { $path $Event.SourceEventArgs.NewEvent.TargetObject Write-Warning UAC bypass registry key modified: $path } Register-WmiEvent -Query SELECT * FROM RegistryKeyChangeEvent WHERE HiveHKEY_USERS -Action $action }不过这个方案在AD域环境里不太够用正确做法是把Sysmon日志接入SIEM平台再写关联查询规则。下面是一个标准的Kusto查询思路用于检测白名单进程起非系统命令DeviceProcessEvents | where InitiatingProcessFileName in (fodhelper.exe, ComputerDefaults.exe, sdclt.exe, slui.exe) | where not(FolderPath startswith C:\\Windows\\System32) | project Timestamp, DeviceName, InitiatingProcessFileName, FileName, FolderPath4.4 日志审计的补充如果短期内无法部署SysmonWindows自带的安全日志也能提供线索。启用“审核进程创建”组策略后Event ID 4688会记录每个进程的创建行为包括父进程信息。命令行参数默认不记录需要额外开启“审核进程创建”下的“在命令行中包含进程创建命令行”策略。实际排查时我一般先查4688里有没有“父进程是fodhelper.exe但子进程不是系统程序的记录”。这种查询不像Sysmon那么精细但配合4688事件里的登录会话信息至少能还原出攻击发生的时间窗口和来源会话应急时够用。5. 系统加固与修复建议检测是发现问题的能力加固是减少问题的手段。UAC白名单提权的加固可以从几个维度同时下手。5.1 UAC配置基线UAC的配置项在本地安全策略里路径是“安全设置→本地策略→安全选项”。涉及UAC的选项一共有十来个核心建议是这几点将“标准用户的提升提示行为”设置为“自动拒绝提升请求”将“管理员批准模式下管理员的提升提示行为”设置为“提示凭据”而不是“提示同意”在Membership中启用“以管理员批准模式运行所有管理员”。其中最关键的是最后一项。如果关闭了“以管理员批准模式运行所有管理员”内置管理员账号会直接以高完整性令牌运行所有进程UAC形同虚设。很多运维为了方便会关闭这项这是非常危险的做法等于把所有提权路径都敞开了。5.2 注册表ACL加固既然攻击链依赖HKCU\Software\Classes下特定键的修改权限加固思路就是把这些键的写入权限收回来。标准做法是用注册表ACL设置阻止普通用户对高风险关联键的写入。最简单的方式是导出这些键的注册表项用regini或PowerShell重新设定ACL。下面是一个PowerShell示例将ms-settings键的写入权限限制为Administrators和SYSTEM$keyPath HKCU:\Software\Classes\ms-settings $acl Get-Acl $keyPath $acl.SetAccessRuleProtection($true, $false) $adminRule New-Object System.Security.AccessControl.RegistryAccessRule(Administrators,FullControl,Allow) $acl.AddAccessRule($adminRule) Set-Acl $keyPath $acl但要提醒一句直接改ACL在部分Windows版本里可能影响系统正常功能比如设置页面打不开。稳妥起见生产环境建议先在测试机验证后再批量下发或者用组策略的注册表首选项统一配置而不是手工逐台改。5.3 应用控制策略限制应用白名单AppLocker或Windows Defender Application Control是对抗这类提权最有效的手段之一。核心思路是即使攻击者利用白名单程序提权成功他执行的命令如果不在白名单策略内依然会被阻止。推荐配置两条规则一条允许System32和Program Files目录下的签名程序执行一条阻断从用户临时目录和下载目录启动的exe、cmd、powershell。这样就算攻击者写入注册表关联启动路径在临时目录的payload也会被拦截提权链直接断在最后一步。部署应用控制策略时要注意不要把规则设得过严否则企业里一堆第三方软件跑不起来。我的经验是先开“仅审核”模式跑一到两周收集全量误报后再切“强制”模式。5.4 基线自检清单最后收口成一份加固自检清单可以直接作为内部安全检查的参考项检查项期望值检查方式管理员批准模式下所有管理员启用本地安全策略标准用户提升提示自动拒绝提升请求本地安全策略HKCU\Software\Classes\ms-settings写入权限仅管理员/SYSTEMreg query icaclsSysmon进程链监控已部署并采集事件ID 1/13服务状态应用控制策略已禁用临时目录代码执行AppLocker有效性验证安全日志审核进程创建已启用含命令行参数组策略不需要一次性全部做到可以从第1项和第4项开始这两个是投入产出比最高的。6. 常见问题与排查技巧实录最后这部分把工作中经常遇到的UAC提权相关问题整理成速查表并分享几个排查技巧。问题现象可能原因排查与解决思路模拟验证时按键写入但没有弹程序缺少DelegateExecute空值或键路径写错检查注册表路径是否完整补上空值再试注册表修改后fodhelper.exe直接白屏系统版本已修补ms-settings协议校验更严换同思路的入口或检查是否应为HKCU被组策略覆盖64位系统上写入的注册表不生效进程访问的是WOW6432Node节点确认写入位置使用Sysmon的注册表事件确认实际访问路径加固后系统设置页面无法打开ms-settings关联被ACL锁死调整ACL保留管理员可读恢复系统级处理程序Sysmon部署后服务无法启动XML编码问题常见于使用UTF-8用UTF-16 LE编码重新保存配置进程链监控误报率高只看单级进程没看完整父子链引入命令行参数匹配和签名校验排掉系统常规操作排查技巧上有几个经验值得分享。第一遇到“奇怪”的注册表键先看LastWriteTime这个时间戳经常能直接指向攻击时间窗口。第二不要在注册表里一眼看到“ms-settings”就下手很多攻击者会把恶意键伪装成正常的GUID或类标识符要结合进程行为判断。第三做根因分析时优先确认父进程是谁启动的一个表现为系统进程的exe父进程是Office宏还是Windows更新服务性质完全不同。还有一个容易被忽视的点UAC白名单程序本身就带微软签名很多安全产品默认放行签名程序所以这类攻击天然比无签名木马更难被发现。写检测规则时尽量不要把“签名是否有效”当作放行条件更可靠的方法是容忍你不想管的那部分系统路径但严格管控“签名程序启动非签名程序”这条边界路径。这条边界路径说到底是“信任链”上的设计取舍。微软用autoElevate换易用性攻击者在这条信任链上找可以插入命令的缝隙。对防御者来说与其等待微软修补每一个入口不如从进程链视角把“谁启动了谁、启动后干了什么”盯住。个人的体会是UAC提权这类攻击没有银弹但把注册表关键节点管住、把白名单程序的子进程管住绝大多数脚本级的提权尝试都会在第一步被拦截剩下的漏网之鱼也都会在进程链日志里留下清晰的痕迹。这套方法论比单纯记几个提权命令更值得花时间吃透。