凌晨两点我盯着屏幕上那个低权限的shell窗口身边是几乎一整天的战果——一个webshell能执行命令但只能在应用账户的权限范围内打转。系统补丁齐全常见内核漏洞全部失效数据库密码也换过了常规套路仿佛走到死胡同。这是攻防演练中最常见的时刻也是最考验基本功的时刻。从权限突破到全域掌控中间隔着的恰恰就是提权这一道分水岭。这篇文章我想聊聊自己在授权攻防评估中积累的提权思路、路径拆解和防守建议适合红队新手、蓝队防守人员以及所有想把系统安全基线做扎实的运维朋友。全程不点评任何未授权行为所有技术讨论均限定在合规演练与授权测试范围内。1. 为什么提权是攻防博弈的分水岭1.1 低权限Shell意味着什么拿到一个低权限shell表面看是进去了实际上你处在一个相当尴尬的位置。以Windows环境为例很多Web应用默认跑在IIS的应用池账户下Linux上则是www-data或者nginx用户。这些账户权限极其有限通常只能写入自己的临时目录、访问web根目录任何涉及系统配置、注册表、服务管理、其他用户文件的操作都会收到拒绝访问。这种情况下你能做什么读取一些配置文件、查看网络环境、尝试列目录。但也仅此而已。系统里90%的关键资产都在高权限账户手里而你连读取的资格都没有。用夸张一点的说法你站在银行大厅里但身上只有一把储物柜的钥匙金库的门、监控室的电脑、后台的管理系统全都离你十万八千里。提权是否成功直接决定整个攻防评估的走向。提不上去你只能在这台机器的犄角旮旯里来回打转横向移动也无从谈起。提上去了普通账户变SYSTEM或root单机控制权就到手接下来才有资格谈域环境、谈全域掌控。所以我把这一步叫分水岭一点不夸张。1.2 权限边界背后的信任设计想理解提权先要理解权限系统在设计时埋下的信任假设。操作系统在做访问控制时本质上是回答一个问题这个主体进程、用户有没有权限访问那个客体文件、注册表项、服务、进程大多数时候操作系统是及格的安全管家。低权限用户碰不了高权限文件普通进程改不了内核数据结构。但问题出在信任传递上如果某个高权限的服务会去读取一个低权限用户可写的文件或者某个高权限进程会执行低权限用户可控的路径上的程序那权限边界就被撕开了一个口子。这里的核心概念是权限提升不是目标而是结果。你并没有真的黑掉操作系统内核你只是利用了系统里一个本来就不合理的信任关系。比如管理员为了省事把某个文件夹设成Everyone可写恰巧这个文件夹路径被一个SYSTEM权限的服务引用那普通用户写一个恶意DLL进去等服务重启代码就在SYSTEM上下文里执行了。整个过程没有一个漏洞被触发全是配置和信任的错配。想通了这一点提权的思路就打开了别总盯着内核漏洞先看看系统里有哪些不合理的信任关系可以利用。1.3 攻防双方在同一时刻的争夺从攻防博弈的角度看提权窗口期是非常剧烈的对抗阶段。攻击方在疯狂枚举系统信息、尝试各种路径防守方在盯着日志告警、分析异常进程行为。每一秒的时间差都可能决定结果。真实红队评估里我见过太多例子攻击方已经拿到低权限shell开始跑枚举脚本结果枚举脚本动静太大触发了EDR的进程行为检测防守方直接隔离主机整个评估提前终结。反过来也有防守方日志留存不完整攻击方在低权限状态待了几个小时才被发现那时候权限早就提上去了凭据也抓完了。这一阶段的博弈核心是信息差。攻击方想尽办法在防守方察觉之前完成提权和凭据收集防守方则希望用最短时间发现异常并切断链路。所以提权操作要快、要稳、要静默防守方的检测规则也要围绕提权的关键行为做针对性设计。2. 提权的底层路径从配置缺陷到信任滥用2.1 配置错配远比漏洞利用常见很多人一想到提权就想到内核漏洞比如Linux上的脏牛、Windows上的各种提权CVE。但以我这些年做攻防评估的经验真正在实战中高频利用的反而是配置层面的错误。理由很简单内核漏洞受系统版本和补丁影响极大现在稍微像样的企业环境都会定期打补丁漏洞利用的成功率并不稳定。而配置错误不一样只要管理员有过一次疏忽它就像一道没上锁的后门静静躺在那里任何时候都能用。常见的配置错配可以分成几类。一类是文件系统权限过大低权限用户可写高权限进程运行所需的文件一类是服务配置可被低权限用户修改还有一类是计划任务指向了可写的脚本或二进制。这几类问题的共同点是低权限主体能够在高权限主体的执行链路上投毒。我用一个生活化的类比小偷进不了金库但发现金库管理员每天都会去门口那家咖啡店买咖啡而小偷恰好能偷偷往咖啡里加东西。提权攻防就是这么回事——你不直接攻击金库你攻击金库管理员信任的那杯咖啡。2.2 凭据比漏洞更可靠的突破口如果说配置错配是第一大提权入口那么凭据就是当之无愧的第二大入口而且往往是更高效的入口。原因很扎心凭据太好找了。你可以检查环境变量、搜索配置文件、翻浏览器保存的密码、看数据库连接字符串、翻历史命令。很多应用为了省事会在配置文件里写明文的管理员密码或数据库密码。你甚至不需要走任何漏洞利用流程拿到密码直接切换用户提权完成。在Windows平台上凭据收集的手段更多。LSASS进程内存中可能缓存了登录用户的凭据SAM文件里存着本地账户的密码哈希DPAPI凭据备份也可能被滥用。很多人对Mimikatz这类工具的印象停留在抓密码三个字上但它的本质是把Windows信任的凭据存储机制变成了攻击面。防守方觉得凭据放在系统里是理所当然的攻击方恰恰就在利用这个理所当然。我个人的经验是做提权之前永远先花二十分钟找凭据而不是花二十分钟找漏洞利用代码。凭据的成功率高、稳定性强、动静小是性价比最高的路径。后面我会专门说这条路径在实战中的优先级排序。2.3 服务与任务借高权限进程之手服务和计划任务是另一类高频提权入口。它们的共同特征是由系统或高权限账户启动但启动链路的某个环节却可以被低权限用户影响。先看Windows服务。一个服务要运行系统会读取服务配置包括二进制路径然后用配置里指定的账户权限启动该进程。如果普通用户有权限修改服务配置或者服务引用的程序路径可被普通用户写入提权就是顺手的事。还有一个非常经典的未引用服务路径问题服务路径带空格且没加引号时系统会按空格拆分路径去尝试加载如果中间某个目录可写放一个伪造的可执行文件服务一重启代码就以高权限跑了。Linux上的情况类似。cron定时任务如果指向了一个普通用户可写的脚本或者运行脚本的目录可写等任务执行时高权限上下文就会加载你的代码。sudo配置如果写得太宽比如允许普通用户以root权限执行某个通配命令那绕过命令参数限制也是常见攻击手法。这一块的核心思路是借力打力。你不是自己冲击权限边界而是让系统里已有的高权限进程替你去越界。2.4 内核层最后的选项内核漏洞确实是提权手段里最硬核的一种但在实战中的定位一直很微妙。它不需要依赖任何配置错误不需要找凭据只要系统存在漏洞且版本匹配就能直接拿到最高权限。然而它的短板也很明显打补丁后的系统基本用不了、利用代码可能不稳定导致蓝屏或宕机、部分EDR会对系统调用行为做监控。我在真实评估中会把它放在最后原因只有一个可控性差。攻防演练的目标是验证安全防护的有效性不是把客户的生产环境搞崩溃。一次内核利用导致的系统宕机很可能让整个评估项目陷入被动。相比之下配置错误和服务滥用虽然看起来不够炫酷但稳定性极高而且完全可控。内核利用更适合在测试环境验证过稳定性之后再谨慎使用。如果目标系统是生产环境的高价值主机我的建议是优先把前面三类路径走完实在无路可走再考虑内核层。3. Windows与Linux两套思维下的提权实战3.1 Windows提权路径速览Windows的权限模型比Linux复杂得多提权路径也更多样。我按实战频率从高到低整理了几条服务与DLL劫持类。优先检查非默认服务的二进制路径是否可写、服务配置是否可修改、是否存在未引用的服务路径。这类问题用PowerUp或手工检查都能发现成功率高且不需要重启系统——很多服务可以被普通用户触发重启或通过sc命令操作。如果一个服务以SYSTEM权限运行而配置可写直接把binPath改成自己的程序然后重启服务就是SYSTEM。令牌模拟类。Windows的令牌Token机制允许进程临时借用其他用户的权限。如果当前账户拥有SeImpersonatePrivilege或SeAssignPrimaryTokenPrivilege这类特权就可以利用Potato系列工具或PrintSpoofer等通过让高权限服务访问你伪造的命名管道实现在高权限上下文执行代码。IIS应用池账户、MSSQL服务账户通常带着这些特权所以这类技术在Web和数据库服务器上非常常见。凭据提取类。前面说过LSASS内存、SAM文件、DPAPI备份都是凭据来源。拿到本地管理员哈希后用哈希传递Pass-the-Hash的方式直接访问其他主机或服务这在Windows内网里几乎是默认技能。注册表与启动项类。某些注册表项如果Everyone可写而启动项里又恰好引用了这些项普通用户可以在注册表里写入自己的命令等系统启动或用户登录时执行。AlwaysInstallElevated如果被设置为开启普通用户能以SYSTEM权限安装MSI包也是一个经典入口。每个版本的系统还会有一些细节差异但思路框架是不变的枚举服务的运行账户、检查路径可写性、翻注册表、找存储的凭据、看进程令牌特权。Windows上我习惯用WinPEAS先做一轮全面枚举再针对枚举结果做人工确认因为这个工具的覆盖面很全能省下不少重复劳动。3.2 Linux提权路径速览Linux的提权路径相对清晰核心是围绕文件权限、进程权限和计划任务做文章。SUID/SGID类。设置了SUID位的程序会以文件所有者的身份运行如果这个所有者是root而程序本身存在漏洞或可以被参数操控就可能实现提权。比如经典的find、nmap、vim等带了SUID位那就是天然的漏洞。扫描命令很简单find / -perm -4000 -type f 2/dev/null。sudo配置类。sudo -l查看当前用户被授权执行的命令如果某个命令可以以root身份执行且该命令支持绕过shell或读写任意文件比如vim、less、python、perl那就等于拿到了root。这类问题的根源是管理员没有遵循最小权限原则给了太多半可控的命令。计划任务类。查看/etc/cron*下的定时任务如果某个脚本文件对当前用户可写或者脚本所在的目录可写等到root的cron任务执行时代码就会以root身份运行。还有一种PATH注入cron任务里如果用了相对路径的脚本名而攻击者能在任务运行时的PATH环境变量对应的某个可写目录里放同名脚本同样可以劫持执行链。Capabilities类。Linux的capabilities机制把root权限拆成细粒度能力如果某个程序被设置了过大的capability比如cap_sys_admin也可以通过它实现提权。用getcap -r / 2/dev/null扫描。共享与容器类。如果当前用户在docker组里直接挂载宿主机根目录到容器里就是rootNFS如果配置了no_root_squash低权限用户在客户端挂载后创建SUID文件服务端以root运行时也会执行。这类问题在容器化环境里特别多见。Linux提权的优势在于信息透明几乎所有配置都能通过命令查到。我的建议是进入系统后先跑一轮LinPEAS重点看Interesting Files和Processes部分的输出再结合手工命令验证。3.3 一条真实环境的提权链路复盘讲一个我自己做过的评估案例还原完整的链路方便你理解前面说的思路如何串联起来。目标是一台运行Tomcat的Linux服务器Web应用存在文件上传漏洞我上传了Webshell拿到了Tomcat进程的用户权限也就是tomcat账户。这个账户非常受限但足够我读取web目录和Tomcat配置文件。常规的内核漏洞扫描显示补丁已打全sudo -l也没有任何可用条目看起来像一条死路。我没有急着放弃先做了一轮信息收集。发现Tomcat的conf目录下有个tomcat-users.xml里面竟然配了一个manager角色的账户密码是明文而且这个账户的密码和系统上一个用户deploy的密码一样。尝试用这组凭据su切换到deploy账户成功了。到这里权限从tomcat提升到了deploy但deploy也只是普通用户。继续翻deploy家目录发现.bash_history里有一条命令sudo /usr/bin/rsync --daemon。看到rsync我就来了精神因为sudo权限如果允许执行rsync利用rsync的远程shell选项就能拿到root shell。果然sudo -l显示deploy可以免密执行/usr/bin/rsync我直接构造了一个rsync命令把本机目录同步到临时目录利用rsync支持的-e参数反弹了shell最终拿到root。这条链路不算复杂但它很典型第一个跳板是凭据复用第二个跳板是sudo命令配置过宽。全程没有用任何漏洞利用代码全靠配置信息串联。事后我给出的修复建议也很简单不要复用密码、收紧sudo的rsync权限、定期清理历史命令文件。防守方听完很沉默因为这些都是早知道应该做的事。4. 全域掌控从单台主机到整个业务域4.1 单机提权之后的下一步很多人误以为拿到一台主机的root或SYSTEM权限就算掌控全局了在真实攻防演练里远不是这么回事。单机权限只是全域掌控的起点接下来要做的第一件事是重新定义自己的位置这台机器是什么角色它连接了哪些网段有没有域环境它信任哪些账户和主机我会按这个顺序做信息收集先看网络配置和路由表确认主机在哪个网段再看ARP缓存、DNS记录、hosts文件判断是否存在域环境然后查看当前用户是否有域账户权限、能否解析域控地址最后翻看已建立的网络连接找到这台机器正在和哪些IP通信。这些信息直接决定了你的横向移动方向。用一句话概括单机提权让你拿到了「通往内网的第一把钥匙」但钥匙能开多少扇门取决于你花多少耐心去观察这栋楼的结构。4.2 域环境里的提权逻辑进入域环境之后提权的含义从普通用户到root变成了普通域用户到域管理员。攻击路径不再是单机的配置错误而是整个ADActive Directory的信任关系问题。比如Kerberoasting本质是利用任何域用户都可以请求服务账户SPN账户的TGS票据这个特性把票据拿下来离线破解只要服务账户的密码强度不够域内任意一个普通用户都能一步步逼近域管理员权限。AS-REP Roasting则是针对配置了不需要预认证的账户原理类似。还有委派滥用。如果某个服务账户配置了非约束委派或约束委派攻击者控制了这台服务主机之后就可以伪装成任意用户访问被委派的服务甚至拿到域管理员的令牌。这类攻击路径抽象且隐蔽留给防守方的检测点非常少。BloodHound是我强烈推荐的一个工具它能把AD域内的权限关系和攻击路径可视化。输入一个普通域账户的凭据它会在后台分析ACL、组成员关系、委派配置、会话信息最终画出一张从你当前位置到域管理员的地图。很多攻防演练里找到路径比执行利用更重要——因为路径揭示了问题本质。4.3 持久化与权限维持全域掌控的另一半是掌控的时间要足够长。攻防演练通常持续数周如果每次拿到权限后只能维持几分钟就被防守方踢掉那前面的努力就白费了。持久化的本质是在系统里留下一个只有你知道的、能让你随时回来的后门。Windows上常见的有计划任务、服务、注册表Run键、WMI事件订阅、启动文件夹、COM劫持等。Linux上常见的有SSH公钥后门、计划任务、rc.local启动脚本、PAM后门。这里必须强调一点所有持久化操作都必须严格限定在授权评估范围内明确知道自己部署了什么、留在哪里、评估结束后要清理干净。一次不透明的持久化操作轻则让客户对你的专业性打问号重则可能引发法律风险。我个人的习惯是在部署任何持久化机制之前先写清楚保留时间、清理方式、影响范围再动手。4.4 痕迹清理不是可选项攻防演练的质量评估中痕迹清理往往被忽视但它直接影响攻防双方的公平性。攻击方留下的日志和工具文件一方面会让防守方更早发现问题另一方面也会污染后续的取证分析。清理不是简单地把日志删了。更稳妥的做法是精准删除与自己操作相关的日志条目修改文件的访问时间和修改时间让它们看起来像历史文件把临时上传的工具放到容易被忽略的目录并设置ACL拒绝其他用户读取卸载部署的临时服务。不过我也要提醒一句痕迹清理的目标是消除评估对生产环境的干扰而不是做违法犯罪式的反取证。这个度要把握好一切以授权协议里的边界为准。5. 防守方视角如何让提权这条路走不通5.1 最小权限原则的落地经验所有提权攻击的本质都是权限过大或边界模糊。最小权限原则说起来简单落地却需要持续的执行力。我在给客户做基线检查时会发现很多系统的最初部署是符合最小权限要求的但运行几个月后为了排查问题运维把某些目录改成了Everyone可写给某个服务账户加了本地管理员权限结果一直没改回来。落地的几个关键点。第一服务账户不许交互式登录密码要长且定期轮换最好用组托管服务账户gMSA这样自动管理密码的机制。第二普通用户坚决不给本地管理员权限需要通过管理操作时走独立的特权账号管理平台。第三文件和目录权限用按需开放的原则谁需要访问谁申请而不是一刀切Everyone。第四sudo规则要精确到命令级别能用参数限制就用参数限制避免出现允许rsync这种过宽授权。一句话最小权限不是一锤子买卖是每一次配置变更时都要问自己一句这个权限真的必要吗。5.2 高危配置检查清单防守方最省力的方式是建立可落地的自查清单把已知的高危配置全部纳入巡检。下面的表格是我在实际项目中常用的检查项每一项都能对接到具体的攻击路径检查项风险说明自查方式未引用的服务路径低权限用户可在中间路径放恶意程序列出所有服务路径检查含空格且未加引号的项Everyone可写的服务路径服务程序文件可被篡改核对关键服务二进制文件的ACL权限普通用户可修改服务配置直接改binPath实现SYSTEM执行检查服务配置项的写入权限sudo授权过宽免密执行可绕过命令sudo -l逐条评估授权命令风险SUID位异常带SUID位的程序可被利用find / -perm -4000梳理白名单定时任务调用可写脚本root cron执行低权限用户可写文件审查cron配置和对应脚本权限明文凭据存放配置文件、历史命令泄露密码扫描配置文件和历史命令中包含密码的记录AlwaysInstallElevated开启普通用户以SYSTEM安装MSI检查两个注册表键是否同为1Windows令牌特权过大拥有SeImpersonate特权易被滥用检查服务账户的令牌特权列表LAPS未启用域内本地管理员密码通用检查AD中LAPS属性是否配置这张清单不是一次性做完就完了我建议至少每个季度巡检一次而且每次配置变更后都做增量核查。攻防演练前做全面检查平时做自动化巡检效果最好。5.3 检测与应急响应的关键点提权攻击的检测远比漏洞利用检测容易。因为提权过程通常伴随着一组特征性的行为比如低权限用户执行了高权限命令、进程创建了父子关系异常的命令行、某个服务绑定的路径发生了变化、系统账户在非登录时间产生了登录事件。Windows平台建议重点监控几个事件ID4624登录成功留意登录类型为3或9且账户为服务账户的情况、4648显式凭据登录、4672分配给新登录的特权如果普通用户获得SeDebugPrivilege等就需要关注、4688进程创建配合CommandLine过滤、4703令牌权限调整、4720创建用户等。Linux平台则要关注/var/log/auth.log中的sudo日志、su切换记录以及auditd配置的策略变更和特权提升事件。应急响应的思路也要转变。不要等攻击者已经提权成功后再去溯源而是把检测点前移到权限变更和执行链路异常两个环节。比如某个服务路径从C:\Program Files\App\app.exe变成了C:\temp\evil.exe这本身就是强告警信号完全可以在攻击者重启服务拿到SYSTEM之前就触发阻断。6. 工具选型与我的实战心得6.1 常用提权辅助工具与定位工欲善其事必先利其器。我整理一下自己在授权评估中常用的工具和定位方便你建立自己的工具箱。工具名称适用平台核心用途使用注意LinPEASLinux自动化枚举提权线索输出噪音较多需人工过滤WinPEASWindows自动化枚举提权线索建议用原版源码编译避免源码篡改风险PowerUpWindows查找服务目录和配置的提权路径功能相对单一辅助为主SeatbeltWindows主机安全配置全面枚举适合在获取初始权限后快速摸底BloodHoundWindows域分析AD攻击路径不可在目标域控上直接运行需用SharpHound收集后再分析MimikatzWindows提取LSASS内凭据仅限授权环境需先确认杀软策略Impacket套件跨平台远程命令执行、哈希传递、票据传递注意远程执行时的日志痕迹CrackMapExec/NetExec跨平台批量验证凭据与主机权限批量操作动静较大控制并发工具是加速器不是主心骨。我在很多项目里见过一个现象工具跑了一晚上输出几百页报告正经提权路径一条没分析明白。原因很简单工具的枚举结果需要人工结合业务环境去判断优先级而不是拿来就盲目利用。6.2 真实评估中的几个经验教训第一个教训是信息收集永远优先于漏洞利用。有一次我花了将近三个小时分析一条看起来像内核漏洞的线索最后发现是枚举脚本自己创建的文件触发了误报。如果最初就多花十分钟看看文件时间戳和进程关系就不会走这个弯路。现在我的习惯是拿到shell后先花20分钟做信息收集把网络、用户、配置、进程、凭据线索全部理清再决定优先走哪条路径。第二个教训是优先选稳定的路径而不是理论最快的路径。早期参加攻防演练时我倾向于一上来就找最高权限的利用方式结果不是利用失败浪费时间就是动静太大引发告警。后来我调整了策略先看配置错误、再找凭据、最后才是漏洞利用。这条路径排序在实践中胜率最高而且每一步的失败成本都很低。第三个教训是每个操作都要考虑可逆性。在目标系统上执行命令之前先想一想这个命令会不会导致系统异常会不会产生难以清理的痕迹。特别是涉及到服务的重启、内核模块加载、进程终止这类操作我会在测试环境先验证一次再上真实目标。6.3 授权边界与职业底线最后必须讲一讲边界。所有提权技术无论是本文里提到的配置枚举、凭据提取还是利用工具都只能在拥有书面授权的范围内使用。攻防演练、渗透测试、红队评估这些活动的前提是客户明确授权并且授权协议中写明了目标范围、时间窗口和操作边界。在实际操作中我给自己定了几条铁律不碰授权范围外的任何系统不在评估结束后保留任何凭据和访问通道所有敏感操作都有记录可追溯拿到的数据只用于评估报告不复制、不扩散。这几条铁律不是什么高尚的标准而是这个行业能良性运转的基本底线。这也是为什么我一直强调攻防博弈的终极目标不是打倒对方而是通过模拟真实攻击帮助防守方发现盲区、补齐短板。每一次成功的提权都应该对应一条有效的修复建议每一次全域掌控都应该让客户意识到自己的信任边界在哪里。我自己这些年做下来最大的体会是提权这个环节真正考验的不是工具用得有多熟练而是你对系统信任模型的理解有多深。你越清楚系统信任什么就越容易找到信任被滥用的位置。反过来防守方如果能理清自己的信任边界也就知道该在哪里设防。这个博弈没有终点但每一次交手都会让双方的认知更深一层。