漏洞确认了，然后呢
漏洞利用
本文涉及的所有操作均在本地靶场环境中进行，用于理解漏洞原理与防御思路，请勿用于未授权的目标。
上一阶段我们已经完成了在WordPress的后台放一个管理员账号，这个账号可以在后台成功登录。
但是上阶段的演示只是证明这个漏洞能够有运行的条件，这次的漏洞利用不同的地方在于，在证明有运行条件之后我们要怎么留下一个有用的东西，
这次使用的工具也换了一档。上次使用的脚本只是针对于一个漏洞写死的，用完就基本没什么作用了，这一阶段讲的是框架。一个框架装着几千个模块，如果换了目标就直接换模块就可以。
一、这一阶段要做什么？
漏洞利用在渗透流程中位于信息收集、威胁建模与漏洞分析之后。前面两个回答了有什么和能否利用，这一步要回答的是能否直接拿到手。
失败也算产出。报告里写的已验证不可利用和未验证是两个意思。前者能验证不可达，后者不行。
能拿到某种形式的控制权。
二、框架长什么样
讲这个阶段绕不开Metasploit。它是主流的利用框架，而且Kali自带，开源免费。
它的思路是模块化，能把一次渗透拆成六类，各干各的事。
| 模块 | 干什么 | 对应哪个阶段 |
|---|---|---|
| Auxiliary 辅助 | 扫描、识别、爆破，只探测不攻击 | 信息收集 |
| Exploits 利用 | 每个模块对应的具体漏洞 | 漏洞利用 |
| Payloads 载荷 | 打进去了之后要跑的那段代码 | 漏洞利用 |
| Post 后渗透 | 提权、搜集信息、横向移动 | 后渗透 |
| Encoders 编码 | 让载荷做变形以绕过特征匹配 | 辅助 |
| Nops 空指令 | 生成填充指令，能够稳定利用 | 辅助 |
几千个模块我怎么找到我要用的？可以用内置的search。用软件名或者漏洞类型去搜索，辅助模块和利用模块会一起列出来。
比如说我要搜2026年为披露日期的漏洞可以用：search cve:2026
结果框里有一列叫做Rank，它的作用是告诉你这个模块稳不稳。
结果列表里面有一个Rank，这个表示的是模块稳不稳。excellent这一档基本不会把目标服务器搞崩，SQL注入和命令执行基本都在这一档，往下就是great和good，有默认目标、覆盖常见情况。再往下的话就到average、low了，成功率就不敢保证,manual基本等于把服务打挂。如果想要挑模块的话就先看这一列，至少比看名字猜靠谱。
框架有个好处就是它会跟着新漏洞走，只要CVE披露了对应的模块一般很快就会有人提交，不需要自己写利用代码。单洞脚本相比于这个就有很大的局限性，因为它永远停在作者写完的时候。
三、钥匙和进门后应该做的事情
很多人都会搞混的一组概念是Exploit和Payload。
Exploit是打开门的钥匙。它只限于利用漏洞的本身，把代码送进目标的固定执行流程。送进去的是什么他不管。
Payload是进门后要干的事情，进去之后会做什么由它决定。
| Exploit | Payload | |
|---|---|---|
| 谁决定 | 目标有什么漏洞 | 想要拿到的目标 |
| 什么时候定 | 动手之前就有固定的流程 | 什么时候都能改 |
| 换它意味着什么 | 换了个漏洞 | 同一个漏洞换一个目的 |
如果一个漏洞有不同的载荷，那它的结果就会完全不一样：
配一个执行单条命令的看一眼就会退出，命令跑完后连接也就断了。
配一个完整的控制端可以开长期会话，把这个机器当做跳板继续走。Meterpreter属于这一类，它跑在内存里，并不会在磁盘里留文件。
方向是相反的：由目标机器主动连接攻击机交出控制权
目标往往藏在防火墙或者在内网里，外部的连接一般进不去，但是它的外联基本没什么人拦。所以在LHOST的位置一般填自己的地址，让他按照地址连过来。
框架之所以把他们拆开是因为他们的决策时机各不相同
四、确认了，但是为什么有时候还是打不穿
上一个阶段结束后，WordPress的后台就多了一个管理员，很多人的理解是到这里就算是拿下了。但其实还差得远，如果要实现在后台才做的话，离服务器进行任意命令执行还有三道门槛：
第一道：插件安装策略
从后台的管理员到执行代码之间还缺少安装插件这一步。
WordPress里面有一个常量叫做DISALLOW_FILE_MODS，可以在配置文件里面把它设置为true，然后它后台的安装、更新、删除插件功能会全部关闭。
第二道：文件系统权限
后台允许装插件还不够，文件如果没有写入的权限的话也没用，很多站点在加固的时候会把代码目录设置为只读，这样就算插件可以上传但是也无法运行。
第三道：主机层面
代码跑起来后是以Web服务的用户身份运行，这个用户有什么权限，能不能sudo、容器是否为只读，决定了能造成多大的影响。
三道门槛的强度决定了攻击者能到达哪一步。
还有一种打不穿的情况，原因在于漏洞本身。就比如60137的官方标题带着Facilitated的修饰，这种属于促成型注入。这个参数是目标用户有插件或者主题主动把不可信的数据喂进去了。
上几章也讲过，版本是另一个变量。
CVE-2026-60137是WordPress里的SQL注入，影响从6.8.0到7.01；CVE-2026-63030是REST API的路由混淆，漏洞影响从6.9.0到7.0.1这两个版本。
两个漏洞的区间可能并不重合
6.8的站点只有一个，缺了吧请求送进去的入口，缺少能把请求送出去的入口，链路能不能走到底。7.9和7.0两个都在，这完整的路径才能成立。
五、打完了，拿到哪算哪
同一个利用成功，实际上拿到的东西能够分为三挡。
| 档位 | 能做什么 | 危害到了哪个位置 |
|---|---|---|
| 证明能打 | 发无害探测，确认是否可以利用 | 排除误报，报告上写已验证 |
| 拿到数据 | 读文件、查过数据库、下载配置 | 数据泄露，但是系统本质归别人管 |
| 拿到执行的权限 | 跑命令、装东西、长期待着 | 一次质变，拿到服务器 |
这一条链路能说明分档的意义。60137单独存在时只能停在拿到数据，权限只停留在读库但不能推动代码执行，官方只给了5.9分，但是再加上63030的入口，这一条路就能走到拿到执行权限，整体攻击链能达到9.8分。
同一个洞，在不同的版本上停在不同的档位。这就是上一个阶段说的：版本对了不一定能跑通
在报告编写时这三挡也要分开写，一档和三挡能差几个量级，这些内容混在一起在后面的修复中排优先级会很麻烦。
六、咋防
WordPress这一条链路的修法的要点是，别让攻击者走到第三档。
| 措施 | 挡住什么 | 挡不住什么 |
|---|---|---|
| 打补丁 | 整条连，这是根 | 已经进来了的后门和账号 |
DISALLOW_FILE_MODS |
后台装插件的那条路 | 已有了的管理员账号 |
| WAF栏batch/v1端点 | 免认证的入口 | 从内网发送的请求 |
| 目录只读和最小权限 | 落地写文件、往主机层走 | 读数据这一档 |
打补丁听着很简单，但是落地很容易出问题，升到哪是有讲究的：6.8分支一般升到6.8.6就够了，6.9和7.0必须升到6.9.5和7.0.2，少升一个版本就会有一个洞开着。
常量执行起来可能比较麻烦，每次升级插件都要去走命令行或者去部署流程。对于不需要频繁改动的站点这还是很划算的，因为它可以把攻击者卡在能进后台和能执行代码中间.
配置也是一个变量。Cloudflare在分析中提到，这条链要触及受影响的代码路径，前提是站点没有启用持久化对象缓存。同样的版本，配置不同的话结论也不一样。
光靠一个补丁解决不了所有的问题。在打完补丁后还要再检查一遍：后台有没有不认识的管理员，最近有没有新装的插件、PHP文件有没有被动过
七、最后
回到一开始的问题：漏洞确认了然后呢？
答案是真动手试一次，并且要确定自己能拿到哪一档。确认漏洞的存在只是知道门在哪，利用是把门推开待下来。
这两件事的差距很大。知道有漏洞的人很多，但是能真正利用漏洞实现拿到控制权的人少一截，能说明自己拿到哪一档的人更少。
在确认漏洞后，先让自己明白这三个问题：这个洞有没有现成的利用模块、搭配什么载荷，打完之后的算拿到了哪一档。