Windows 提权这四个字做安全的人几乎都听过但真要把链条讲明白绕不开两个视角攻击者怎么想、防守方怎么看。我这次只站在防守方这一侧写。原因很简单我见过太多团队在授权演练里被打穿之后第一反应是我们补丁都打了啊结果一翻日志才发现对方根本没用上什么高深的漏洞只拿到一个域内普通账号靠本机一个配置有问题的服务两分钟内就把权限抬到了系统级留下的痕迹少得可怜。这类事不是个例也不是什么高级技巧纯粹是配置债。这篇文章要解决三件事Windows 主机上哪些位置容易让人把权限抬上去、在授权范围内怎么把这些点一个个翻出来、翻出来之后怎么堵、堵完之后靠什么日志证明真的堵住了。适合企业里的安全运维、系统管理员、做蓝队分析和内网应急的同学也适合刚入行、想把权限提升这件事真正搞清楚的新人。阅读门槛不高但得动手排查和加固这两件事光看是学不会的。1. 先把位置摆正权限提升在整个攻防链条里算什么1.1 一次内部授权演练里看到的真实节奏我参与过的几次内部演练里节奏高度相似拿到一个低权限账号先做本机信息收集然后提权再横向或者建立控制通道。很多同学以为提权是终点其实它是中间那段桥。桥搭好了后面才有条件做更多事。关键在于攻击者主动做提权的动力往往来自一个很现实的约束初始拿到的凭据权限太低。低权限账号能做的事非常有限——读不到其他用户目录、改不了系统配置、装不了服务、连很多注册表键都写不进去。所以从低权限往高权限爬是做后续动作的前置条件。理解了这一点防守方向就清楚了只要让低权限账号在本机爬不上去攻击链条就会在这里断掉后面的横向和持久化也就无从谈起。还有个容易被忽略的事实提权动作本身通常很短几秒到几分钟。但提权成功之后要维持访问就得留下持久化动作比如装服务、建计划任务、改注册表启动项。持久化动作的生命周期长得多也更容易被日志和终端检测抓到。所以对防守方来说提权环节的价值不只是堵住还在于这是个高价值的告警点。1.2 攻击者真正盯上的是三类软柿子把所有公开的权限提升路径归归类本质就三类摸清这三类排查清单也就出来了。第一类是配置类缺陷。服务、计划任务、注册表键、目录权限只要这些对象的访问控制列表里出现了不该出现的低权限主体就存在被利用的空间。这类问题最要命的地方在于它不是漏洞是配置补丁打再多也修不掉。我见过一台打了最新累积更新的服务器因为某个第三方软件在C:\ProgramData下建了个 Everyone 可写目录整台机器的权限边界就形同虚设。第二类是凭据类问题。本地管理员账号在多台机器上共用同一个密码、安装脚本里留了明文密码、浏览器和远程桌面客户端保存了凭据、服务账号密码长期不轮换。这类问题不需要任何技术手段就能扩大战果——拿到一台机器就等于拿到一批机器。第三类是补丁和版本类。缺失的安全更新、长期无人维护的老组件、随软件一起装进来的旧版运行库。这一类是传统认知里的提权漏洞排查相对标准化但也最容易被反正打了补丁这句话糊弄过去——很多团队只关心操作系统补丁第三方组件的更新根本没人管。1.3 提权之后的那一步反而最容易暴露从防守方的性价比看提权成功之后的动作比提权本身更好抓。为什么因为不管用什么方式提权成功接下来总要做几件事建立一条能持续通信的通道、在系统里留下一个能自动恢复的入口、想办法把凭据捞出来。这三件事都会留下痕迹。持续通信意味着周期性的外连请求流量侧能看到规律性的心跳自动恢复入口意味着服务被安装、计划任务被创建、注册表 Run 键被写入凭据捞取意味着对lsass进程的异常访问和内存读取操作。这些动作的时间跨度比提权长产生的日志量也大得多。我个人在实战分析里的经验是把检测重心放在提权后的 30 分钟内发生了什么比死磕他是怎么提权的更容易出成果。因为提权手法可能很隐蔽但后续的持久化动作很难做到完全无痕。2. Windows 权限模型内核到底按什么规则放行2.1 访问令牌、SID 与完整性级别是怎么配合的要判断一个操作会不会被拒绝得看清楚 Windows 的判定逻辑。每个进程都挂着一个访问令牌令牌里装着这个进程的身份信息用户 SID、所属组的 SID 列表、持有的特权列表。当这个进程去访问某个对象时内核会拿令牌里的身份去比对对象上的访问控制列表逐条判定允许还是拒绝。这里有个细节值得注意令牌分主令牌和模拟令牌。服务进程可以用模拟令牌临时借用调用者的身份这个机制本身是为了安全但如果实现不当反而会被当成提权通道。这也是为什么服务类问题排在第一优先级。另一层是完整性级别。从低到高大致是低、中、高、系统四级。普通用户启动的进程跑在中等级别以管理员身份运行的程序跑在高等级别。低完整性级别的进程即使拿到了高权限令牌也无法写入高完整性级别的对象。这个机制能挡掉一部分越权写入但它不是万能的——很多系统目录的权限设置并不完全依赖完整性级别。理解这套模型的实战意义在于排查的时候你要问的不是这个账号是不是管理员而是这个账号对这个对象有没有写权限。很多提权路径根本不需要管理员身份只需要对某个特定对象有修改权限。2.2 服务、计划任务、注册表三个最容易出事的地方为什么是这三个因为它们都有共同特征以高权限运行配置信息以低权限用户可读甚至可写的形式存放在系统里。服务的问题集中在配置文件的权限上。服务的可执行文件路径、服务对应的注册表键、服务所在目录这三处的 ACL 只要对普通用户开放了写权限就存在被替换或被修改配置的空间。尤其是路径中带空格且没有加引号的情况这是微软官方文档里明确提到过的加固项检查方式是读取服务的可执行路径如果路径含空格且整个字符串没有被双引号包裹就应该修正。修正方法有两种重新配置服务路径加上引号或者把路径所在目录的写权限收掉。计划任务的问题在于任务定义文件的可写性。任务以什么身份运行、运行什么程序、什么时候触发这些信息都在任务定义里。如果普通用户能修改任务定义就等于能间接以高权限身份执行任意程序。排查方式是遍历所有以最高权限运行的任务逐个检查任务文件所在目录的 ACL。注册表的风险点主要在两处系统服务的配置键以及自启动项。前者关系到服务怎么加载后者关系到持久化。还有一个经常被忽略的地方是某些组件的 COM 注册信息改掉之后可能改变程序的加载行为。注意服务路径引号这件事修正之前一定要确认服务当前是否在运行、路径是否被其他脚本依赖。我遇到过一次运维直接给路径加引号结果某个老版本监控代理的启动参数被截断服务起不来了。2.3 UAC 不是安全边界别把它当成防线这是我想反复强调的一点。很多人的心理模型是我们有 UAC普通用户弹窗之后也做不了什么。这个理解是错的。UAC 的设计目标是提醒用户让用户在知情的情况下授权它是一个可用性机制不是隔离机制。开启 UAC 之后管理员账号在登录时会拿到两个令牌一个高完整性、一个中完整性默认用中完整性的那个跑进程需要提权时弹窗切换。对于本来就是管理员的账号绕过 UAC 提示在技术上是有办法的。真正的边界是什么是这个账号是不是管理员组的成员。只要账号在管理员组里UAC 挡不住有意为之的攻击者只能挡住无意中的误操作。所以加固的重点应该放在谁在管理员组里而不是UAC 开没开。我的做法是把本机管理员组成员收敛到最小集合日常运维使用独立的管理账号普通用户账号一律不进管理员组。这样即使某台机器被拿到低权限账号也不会因为账号本身就是管理员只是被 UAC 拦了一下而迅速失守。3. 授权范围内的排查清单从手工到脚本化3.1 第一批要看的本机信息拿到一台机器的排查权限后我习惯按固定顺序过一遍基础信息这一步不需要任何第三方工具系统自带的命令就够。# 当前身份与持有的特权 whoami /all # 本地管理员组成员 Get-LocalGroupMember -Group Administrators # 所有服务及其运行账户、可执行路径 Get-CimInstance Win32_Service | Select-Object Name, State, StartMode, StartName, PathName # 以最高权限运行的计划任务 Get-ScheduledTask | Where-Object { $_.Principal.RunLevel -eq Highest } | Select-Object TaskName, TaskPath, State, {nRunAs;e{$_.Principal.UserId}} # 已安装的更新列表用于核对补丁基线 Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 20whoami /all的输出里有个部分特别值得看特权列表。如果一个普通用户账号的令牌里出现了SeDebugPrivilege、SeBackupPrivilege、SeImpersonatePrivilege这类高价值特权就要重点关注。这些特权本身是给特定场景设计的比如备份软件需要备份特权但如果被分配给不该有的主体风险就上来了。服务列表要重点看两列StartName和PathName。StartName是 LocalSystem 或 NetworkService 的服务是高价值目标PathName则用来找路径引号问题和目录权限问题。我一般会把服务列表导出成 CSV再用脚本批量检查每个服务目录的 ACL。3.2 用 Sysinternals 把 ACL 视角补齐系统自带工具能覆盖大部分场景但要看清楚对象权限微软官方那套 Sysinternals 工具还是最顺手的而且它是官方出品在授权环境里用完全没有问题。AccessChk是核心专门用来查对象的访问权限。它的用法很直接告诉它查什么类型的对象、查哪个账号、看什么权限。# 查看所有服务中普通用户可修改配置的 accesschk.exe -uwcqv Users * /accepteula # 查看某个目录下普通用户有写权限的子目录 accesschk.exe -uwd C:\Program Files /accepteula # 查看注册表某个键的权限 accesschk.exe -uwk HKLM\SYSTEM\CurrentControlSet\Services /accepteulaAutoruns用来梳理自启动项它能把服务、驱动、计划任务、登录脚本、浏览器插件这些入口一次性列全而且会标注每个条目的签名状态和文件路径。我做持久化排查的时候Autoruns 是第一步先看有没有签名异常或者路径可疑的条目。Process Explorer主要用来确认进程的令牌信息。选中一个进程看它的 Security 标签页能看到这个进程跑在什么身份下、有没有开启某些特权。这个功能在判断某个服务是不是以高权限在跑的时候非常直观。Sigcheck用来批量核对文件签名和版本信息适合在排查后期做一次全面体检看看系统目录里有没有被替换过的可执行文件。提示AccessChk 的输出量很大命令行里加上-q可以去掉横幅信息配合findstr或者输出到文件再分析效率会高很多。我一般会把结果导成文本再用 PowerShell 做二次筛选。3.3 一份可以复用的 PowerShell 体检脚本手工敲命令适合单台机器超过五台就得脚本化。下面这个脚本我用了挺久覆盖了服务路径、目录权限、计划任务、管理员组这几个核心检查点输出是一张统一的表格方便批量比对。# WinAudit.ps1 - Windows 权限提升风险本机体检 # 仅用于授权范围内的安全自查 $report () # --- 检查一服务可执行路径未加引号 --- Get-CimInstance Win32_Service | ForEach-Object { $path $_.PathName if ($path -and $path -notmatch ^) { # 路径含空格且首字符不是引号 $exePart ($path -split \.exe)[0] .exe if ($exePart -match \s) { $report [PSCustomObject]{ 类别 服务路径引号 对象 $_.Name 详情 $path 风险 中 } } } } # --- 检查二高权限目录对普通用户开放写权限 --- $watchPaths (C:\Program Files, C:\Program Files (x86), C:\ProgramData, C:\Windows\Temp) $badRights Write|Modify|FullControl|TakeOwnership|ChangePermissions $badUsers BUILTIN\\Users|Everyone|Authenticated Users|INTERACTIVE foreach ($p in $watchPaths) { if (Test-Path $p) { (Get-Acl $p).Access | Where-Object { $_.IdentityReference -match $badUsers -and $_.FileSystemRights -match $badRights -and $_.AccessControlType -eq Allow } | ForEach-Object { $report [PSCustomObject]{ 类别 目录权限过宽 对象 $p 详情 $($_.IdentityReference) $($_.FileSystemRights) 风险 高 } } } } # --- 检查三以最高权限运行的计划任务 --- Get-ScheduledTask | Where-Object { $_.Principal.RunLevel -eq Highest } | ForEach-Object { $report [PSCustomObject]{ 类别 高权限计划任务 对象 $($_.TaskPath)$($_.TaskName) 详情 RunAs$($_.Principal.UserId) State$($_.State) 风险 中 } } # --- 检查四当前账号持有的高价值特权 --- $highValue SeDebugPrivilege, SeBackupPrivilege, SeRestorePrivilege, SeTakeOwnershipPrivilege, SeImpersonatePrivilege, SeLoadDriverPrivilege $whoami whoami /priv foreach ($p in $highValue) { if ($whoami -match $p -and $whoami -notmatch $p\sDisabled) { $report [PSCustomObject]{ 类别 高价值特权启用 对象 $env:USERNAME 详情 $p 风险 高 } } } $report | Sort-Object 风险, 类别 | Format-Table -AutoSize $report | Export-Csv -Path .\WinAudit_$(Get-Date -f yyyyMMdd).csv -NoTypeInformation -Encoding UTF8这个脚本有几个设计上的取舍值得说明。第一它做的是发现不是利用。所有检查项都只读取配置信息和权限列表不会去尝试调动任何东西。这是排查脚本该有的边界越界了就不叫自查了。第二风险等级是我按经验划的。目录权限过宽和高价值特权启用标成高是因为这两类直接构成可利用空间服务路径引号和计划任务标成中是因为还需要额外的条件才能形成完整的利用路径。第三输出成 CSV 是为了批量比对。单台机器看表格几十台机器就得靠 CSV 做聚合一眼能看出哪些问题是普遍存在的配置基线缺陷。4. 日志与检测让提权动作留下证据4.1 审计策略该开哪些日志能不能用取决于审计策略开没开。很多环境默认只开了登录审计进程创建、对象访问、服务安装这些全都没记录出事之后查不到东西。我建议至少开启以下几项审计类别子类别实际作用登录/注销登录、特殊登录记录成功登录与高权限登录分配详细跟踪进程创建留下命令行参数这是取证的核心对象访问审核文件系统、审核注册表记录对敏感对象的写操作策略更改审核策略更改发现审计策略被人为关闭系统安全系统扩展记录服务安装、驱动加载账户管理安全组管理、用户账户管理发现账号被加入高权限组命令行审计这一项要单独确认。进程创建事件里如果不带命令行参数日志的价值会下降一大截——你知道有个进程起来了但不知道它带了什么参数看不到攻击者的实际动作。配置可以用auditpol完成# 开启进程创建审计并启用命令行记录 auditpol /set /subcategory:Process Creation /success:enable /failure:enable reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit /v ProcessCreationIncludeCmdLine_Enabled /t REG_DWORD /d 1 /f第二条注册表项是关键不加它的话命令行字段是空的。我见过不少环境的日志里有 4688 事件但命令行那一栏是空的等于白开。4.2 关键事件 ID 判读表系统安全日志和 Sysmon 日志里和提权相关的核心事件就那么几个记住了判读速度会快很多。事件 ID来源判读要点4672Security高权限登录登录类型结合 4624 一起看4688Security进程创建重点看父进程与命令行4697Security服务安装注意服务路径和运行账户7045System服务安装比 4697 更直接含完整路径4673Security调用特权服务看是哪个进程调用的4698/4702Security计划任务创建与更新重点看运行身份4732/4728Security账号被加入本地或全局组4907Security对象审计策略变更可能是在关日志判读的时候有个方法我自己一直在用按进程树看不要按事件 ID 看。先找出一个可疑的父进程然后顺着它的子进程一路往下看它在短时间内启动了哪些东西。正常的运维操作和攻击行为的区别往往不在单个事件上而在整个进程树的形态上——比如一个办公软件突然拉起来一个命令行解释器再往下拉起来一个网络工具这个形态就很不对劲。4.3 控制通道建立的流量与进程侧特征提权成功之后要建立持续通道这一步的特征相对明显。进程侧注意几个现象一个没有数字签名的可执行文件从临时目录启动某个进程的网络连接数长期保持不变但持续存在进程的内存占用很小却一直不退出父进程已经退出但子进程还在跑。这些都是我在实际分析里频繁遇到的形态。流量侧规律性的心跳是最典型的特征。固定间隔、数据量小、目标地址很少变化这三个特征凑在一起就值得深挖。DNS 层面的异常查询也值得关注比如某个内部主机开始对一批看起来随机生成的域名做查询。桌面环境里还有一个容易漏的点定时唤醒与远程控制类进程。有些远控类工具为了稳定性会注册定时任务做自我恢复这类任务在 4698 事件里会留下记录运行身份通常是最高的。排查的时候把高权限 高频触发 路径在用户目录这三条同时命中的任务单独拎出来看。5. 加固落地把能提权的口子一个个焊死5.1 服务与计划任务的 ACL 基线服务这一块我推的做法是把基线写死然后定期比对。第一服务可执行文件所在目录的 ACL 必须收紧只允许 SYSTEM、Administrators 和一个专用的服务账户写入。C:\Program Files下的子目录尤其要注意很多安装程序会把目录权限设成 Everyone 可写装完之后没人改回来。第二服务配置键的权限要检查。注册表里服务对应的键位于HKLM\SYSTEM\CurrentControlSet\Services下这个位置默认权限通常是合理的但第三方软件安装过程中可能会改动。第三服务路径统一加引号。这是成本最低、收益最明确的一条批量处理可以用脚本Get-CimInstance Win32_Service | Where-Object { $_.PathName -and $_.PathName -notmatch ^ -and ($_.PathName -split \.exe)[0] -match \s } | ForEach-Object { $fixed ($_.PathName -replace ^(.*?\.exe)(.*)$, $1) ($_.PathName -replace ^.*?\.exe, ) Write-Host 建议修改: $($_.Name) Write-Host 原路径: $($_.PathName) Write-Host 新路径: $fixed # 确认无误后手动执行: sc.exe config $($_.Name) binPath $fixed }注意脚本里注释掉的那行是故意不自动执行的。路径改写会影响服务启动必须逐个确认。我踩过一次坑一个服务原本的路径后带了多个空格和换行脚本一处理就变成了合法但错误的路径服务直接起不来。所以这类改动我坚持先输出建议、人工确认、分批执行。计划任务这一块基线原则是能用专用账号跑的不要用 SYSTEM。只有当任务确实需要系统级操作时才用最高权限。任务定义文件所在的目录C:\Windows\System32\Tasks权限保持默认不要为了方便运维把它放开。5.2 凭据保护相关的关键设置凭据类问题的加固重点不在技术在流程。本地管理员账号的密码必须每台机器不同。这件事现在有成熟的做法用本地管理员密码解决方案做到自动轮换不需要人工维护。我在没有这套方案的环境里至少会做到按批次分组同批次的机器共用一个密码批次之间不重复。服务账号的密码要定期轮换而且不能用同一套凭据跑多个服务。我见过一个特别典型的场景某企业内部好几个业务系统都用同一个域账号跑服务这个账号被写在一个共享配置文件里权限还是域管理员。这台机器出问题等于整个域出问题。还有几个系统级的设置值得检查凭据保护开启之后凭据不会被明文缓存到内存里能显著降低内存抓取类攻击的收益。开启前要确认硬件和驱动支持。远程桌面连接时的凭据委派默认设置可能允许凭据被带到远程主机运维场景下要按实际需要收紧。缓存凭据数量域环境下本机缓存的登录凭据数量默认为 10可以下调到 0 或 1代价是断网时无法登录。提示这些设置的改动对用户有可感知的影响尤其是缓存凭据数量改成 0 之后笔记本用户断网就没法登录了。上线前一定要和业务方确认别自作主张。5.3 补丁、版本与最小权限的日常运营补丁管理这件事坑主要在覆盖面。操作系统的更新有统一的推送机制第三方组件的更新往往没人管。我的做法是建一份资产清单把所有装了第三方运行库、办公插件、远程管理工具的机器列出来按厂商的更新节奏单独跟。最小权限的落地我总结成三条具体动作。第一本机管理员组只保留必要成员。除了内置管理员账号和一个专用的运维账号其他一律移出。域管理员组更严格只保留极少数专用账号。第二服务账户不进管理员组。如果某个服务确实需要高权限用专门的系统账户跑或者给它单独的服务 SID而不是直接塞进管理员组。第三用户日常使用的账号不做任何特权操作。需要提权的场景走独立的管理账号配合审批流程。这一步很多人觉得麻烦但它是最有效的一条——普通账号提不了权攻击者拿到它也只能停在那里。6. 实操踩坑与排错速查6.1 排查阶段最容易误判的几种情况误判一把正常的运维脚本当成异常。我做过一次应急看到一个凌晨三点启动的命令行进程吓了一跳结果一问是运维团队备份脚本。所以排查结论必须和运维记录对齐看日志之前先拿到变更窗口和定时任务清单。误判二只关注 Bad 的目录忽略了子目录。很多时候主目录权限是正常的问题出在下三层的某个子目录上。检查一定要递归而且要考虑继承权限的影响——父目录收紧之后子目录的显式权限可能还是放开的。误判三把访问被拒绝当成不存在的路径。排查的时候如果是用低权限账号跑的脚本很多路径会因为权限不足读不到脚本里如果没做异常处理就会静默跳过。这些看不见的路径恰恰可能是高风险点。所以体检脚本必须用管理员权限跑而且对读取失败要有记录。误判四把服务停用当成风险消除。一个服务被停用了但它的目录权限和配置键权限还在。哪天有人为了临时需求又把它启动起来风险立刻回来了。误判五忽略凭据复用。在单台机器上看什么都正常放到整个域里看同一个管理员密码出现在三十台机器上这就是最大的风险点。排查必须做横向比对不能只看单机。6.2 加固上线后常见的翻车点现象常见原因处理思路服务无法启动路径改写后参数被截断或目录权限收紧过度先回滚逐条比对原路径字符串权限收紧要保留服务账户的读取和执行权限计划任务执行失败运行账户缺少必要权限或密码已过期用任务历史记录确认失败原因不要直接改回 SYSTEM用户反馈无法登录缓存凭据数改为 0 且网络中断保留至少 1 个缓存凭据或提前通知用户业务系统报错凭据保护开启后依赖明文凭据的旧系统无法工作先在测试环境验证再分批上线备份任务中断备份账号被移出管理员组改用独立服务账户并授予备份相关特权这张表里每一条我都真实遇到过。最需要提醒的是第一条目录权限收紧是加固里最容易出事的操作因为很多服务的运行账户在安装时就设置好了你收权限的时候如果没把那个账户保留进去服务就起不来了。改权限之前一定先把当前的 ACL 完整导出留档。7. 演练边界把合规这件事做在前面7.1 授权、范围和留痕不管你是做内部演练还是外部评估动手之前必须有三样东西书面授权、明确的范围清单、以及过程留痕的约定。授权文件里要写清楚目标资产范围、允许的时间窗口、允许使用的技术手段、以及明确禁止的操作。我一般会在授权里单独列一条禁止项清单把可能影响业务连续性的操作排除在外比如不重启生产设备、不做拒绝服务测试、不在非授权时间触碰业务系统。范围清单要具体到 IP 和主机名不能写内网所有资产这种模糊表述。范围之外的东西哪怕顺手就能看到也不碰。过程留痕这件事很多人会偷懒。我的做法是全程终端录屏加操作日志脚本每一步的执行结果都落盘保存。这不只是为了交付报告更重要的是万一业务侧出现异常能第一时间证明和测试动作无关。7.2 数据与结果的处理演练过程中拿到的东西处理方式要提前约定好。凭据类信息、敏感配置、业务数据这些都不能在报告里原文呈现。报告里应该描述的是风险类型、影响范围、修复建议而不是实际抓到的密码明文。测试结束之后所有测试过程中创建的账号、服务、计划任务、文件都要按清单逐个清理干净并且让业务方确认。我见过演练结束后半年测试用的账号还躺在域管理员组里这比原本的风险还要严重。还有一点是我个人的坚持发现的高风险问题不管演不演练都要在最短时间内告知责任方。有些问题等报告出来再整改中间的时间窗口就是实打实的暴露面。真正做安全的人不会把发现的问题拿来做筹码。最后分享一个我一直在用的习惯给每一台服务器建一份权限变更台账记录这台机器上管理员组成员、服务账户、高权限计划任务的历史变化。出问题的时候这份台账能帮你快速判断哪些是正常变动、哪些是异常新增。这份台账不需要什么复杂的系统一个共享表格就够了但坚持维护下去收益远超投入。