信息收集到了一些碎片，我下一步应该怎么做

确认好下一步的方向

上一段结束后，你手里大概会有这些内容：目标IP和DNS记录，一串子域名，一些开放端口和它对应的服务版本，网站用的一些CMS类型和版本号，一些能直接打开的后台入口，或者再是一份完整的源码。

东西确实不少?下一步咋做？

很多人最容易卡的地方就是这里。语法会吗？会。工具会吗？会。碎片也有一堆，但是看着这些信息一点想法没有。下一步怎么做?不知道哪条线索值得先动手。

这一段要补的，就是这一部分。

一、这个阶段做了什么

渗透测试常见的七个阶段：前期交互 / 预接触、情报收集、威胁建模、漏洞分析、渗透攻击 / 漏洞利用、后渗透、报告。

前面的步骤只能解决目标有什么的问题。而这个阶段要解决的是根据现有的条件有没有可行的渗透方向与实际能渗透的方式是什么？

大部分人的问题都出现在把两个步骤合为一步，就是直接拿着扫描器结果直接用，结果很多漏洞根本打不通，不知道问题出在哪里，而且服务器后台还留了很多告警日志。

二、列假设：把碎片信息整理成渗透思路

接着上一步的素材，后面我们可以这样做。

声明：本次实验是在靶场的情况下进行，为对任何未授权系统进行渗透测试

假设你已经从泄露的.git目录下还原了整份的代码，翻找到了wp-includes/version.php文件，里面写着$wp_version='6.9.4'。页面的头部也带着`。

然后我们就拿到了第一个线索：目标使用的WordPress 6.9.4。

然后可以再看看收集到的目录，后台/wp-admin/能够跳转到/wp-login.php?redirect_to=http%3A%2F%2F192.168.235.128%3A8080%2Fwp-admin%2F&reauth=1的登录页面

我们就拿到了第二条线索：目标的后台暴露在了公网。

通过这两个信息可以进行一次推演。WordPress是使用非常广的内容管理系统，在搭建这个网站之前我的原本方案就是用这个。

通过搜索相关信息可以得到这两个信息：

版本对上了，也有相关的公告，找到了对应的入口。那我们就有这么一条攻击路径：通过6.9.4的已知漏洞，实现后台直达，可以在不登录的情况下拿下拿到权限。

注意到目前为止只是假设，因为现在我们得到的只有版本落在受影响的区间，至于能否管用还要继续验证。

列假设其实就只有这三条：

1. 看版本找到已知的漏洞。版本号信息是最有价值的，因为只需要这个就能知道对方公开的修复信息。
2. 看功能猜问题：有上传的地方看看能不能传递木马，有搜索框的地方看看能不能用注入，有登录的地方看看能不能绕过。功能决定可能出现的漏洞类型。
3. 看配置找暴露面：后台是否直接暴露在公网，目录的列表是否打开，备份文件是不是不用鉴权就能下载。这些问题不需要任何漏洞，配置错了就是存在问题。

三、验证：用假设进行尝试

先用工具进行扫描，再对重点项目做人工认证。

一个WordPress的站点可能会扫出几十条都是正常的，但是很多得到的都是些xmlrpc.php开启、用户名枚举或者readme.html可读，这些都是问题，但是离拿到权限还差很多，能拿到权限的可能就一两条，这一行有一个最容易被忽略的经验。

CVE-2026-63030的POC做了什么？

它的作用可以概括为一句话：把我怀疑这里有洞变成一句有票据的结论。

它做的事情很简单，向目标发一串构建好的请求，每个请求里有一个数据库的是非题，答案是[是]就停半秒响应，答案如果是[否]就立即返回，脚本按照时间核对，就是使用布尔逻辑True/False.

通过一遍遍的问，把目标的表前缀、现有管理员编号问出来，最后可以在不知道任何密码的情况下往后台添加一个新的管理员账号。

这个脚本还会处理一些相对琐碎的事情：怎么确认这些结果是不是因为网络突然卡了而出现的巧合？对于这个问题，脚本会计算机器的基准响应时间，如果发现有抖动的产生就重新进行测试，如果有抖动就会重新进行测试，最后去中间为定阈值。

一次完整的流程是什么样的

我直接用Vulhub的靶场复现了一下。把命令和参数去掉，流程主要的流程大概只有这三步。

第一步，先跑只检测的模式：输入命令python poc.py http://192.168.235.128:8080/ --check，末尾的--check代表执法探测请求，不碰数据库

第二步，跑完整的模式：去掉--check跑一侧完整的，可以看到这些信息：文章表前缀、现有的管理员编号、三条缓存文章的编号，最后还给出了新建账号的用户名密码。

第三步,去后台登录:把脚本给的账号拿到目录/wp-admin登录，查看账号密码是否正确。

查看用户页面，可以看到脚本新建的管理员账号和admin并排在一起

四、扫描出来的漏洞不一定是真的

很多人都容易栽在这里。

扫描器上说的「特征匹配上了」并不等同于「漏洞可利用」。因为漏洞的利用是多个因素的组合。

第一层：版本对上了不代表链能跑通

比如，WordPress的CVE-2026-63030影响6.9.0到6.9.4和7.0.0-7.0.1版本，CVE-2026-60137还多出了6.8.0到6.8.5版本。一个完整的利用链是需要两个CVE同时存在，所以如果是跑6.8的站点就会只受CVE-2026-60137的影响，所以完整的链路是无法跑通的

第二层：官方的评级不等于这台机器上的实际伤害

官方已经把这条链路归为了远程代码执行，理由是管理员可以装可执行插件。但是那个POC只到创建完管理员就停止了，注释里写过，不登录后台、不上传插件、不支持系统的命令。

这一步要从多一个管理员到能够执行任意命令，中间还有插件安装策略、文件系统权限、主机加固(补丁)三个门槛，只要任何一个出现问题，就无法造成更大的危害。

第三层：数量并不等同于质量

用漏洞扫描器扫出来几十条，可能能那权限的就只有一条。很多人看到这样的结果都是一个个拿去尝试，结果试到第五条就不想动了。

做漏洞分析重要的是排序，把所有的漏洞按照能拿到权限、能拿到数据、能看到泄露的信息这三项分开，从可利用性和影响范围的角度进行排序。

五、应该怎么防

第一：管理好版本号的一个重要的情报源

页面头部的generator标签、readme.html、报错页面里面的路径，这些都会泄露精确的版本信息，能去掉就去掉。攻击者拿不到版本信息就无法收集到相关的CVE资料，渗透难度会更大。

第二：第一时间更新

我搭建好的靶场之所以能够还原是因为compose文件里的配置关掉了WordPress的自动更新。如果是在真实的环境中开着的话，补丁一发布系统就会自己升级，攻击链就断了

第三：按照情况对漏洞进行优先级排序修复，不能只看评分

对于暴露在公网的应该优先修复，有公开的POC优先修复，能直接拿到权限的优先修复，哪些在内网前面的且还有防护的可以往后面放一放。在资源有限的情况下对高危项进行资源平分相当于没有排。

第四：把资产表建立起来

如果连自己的站点每一个用的什么版本都不清楚，那补丁管理更是无从谈起。攻击者能通过测绘引擎得到的资产表你自己就要先有一份。

六、最后

回到最开始的问题：当你已经有一部分信息了。下一步咋做？

这个答案不是在你找到的这些碎片化的信息里，是在你的聪明脑袋里。这些碎片的信息之所以能被利用是靠的推演，看到的是当你看到版本就能想到查公告的思考能力。

这个本事没有捷径。工具方法现在很好学，只有判断力这个东西是靠一次次的推演磨练出来的。

希望下一次当你收集到碎片后你能先问自己一个问题：这些信息在这里，哪一个能直接对上公开的数据库？能完全对上的一条就是路径。