第120篇 AI全栈 · 攻防实战一马平川拿下虚拟化云平台

原创

陈看山
陈看山

安全诸子

2026年11月6日 12:01
上海

去阅读

很多做企业安全建设的读者，最近都在问同一个问题：拿到了一个疑似存在漏洞的虚拟化云平台入口，到底该按什么顺序推进，才能既把风险验证清楚，又不把一次授权演练做成“只截了一张图”的无效复盘。虚拟化平台和普通业务系统不一样，它上面跑的是整片内网的“地基”，一旦判断失误，要么白忙一场，要么在取证阶段把关键证据弄丢。这篇就把这条流程拆成可照着改的作战手册，围绕授权演练语境讲清楚输入、阶段、判断点和交付物。

先定位卡点：难的不是打点，是“打点之后怎么走”

来源里的真实路径很典型：信息收集阶段发现飞企互联-FE企业运营管理平台存在历史文件上传问题，在授权范围内验证并取得服务器权限，随后进入内网翻找文件、提取 hash。真正卡住人的地方出现在后半段——hash 解不开，爆破碰撞成功率低，扫描结果里又出现了 VMware vSphere v7.0 Linux 版本。

这就是本文要解决的卡点：入口权限不等于目标达成，虚拟化云平台的推进需要一条从“普通主机”到“管理平面”的明确路径，以及每一步的判断标准。很多人在这里要么死磕 hash 解密，要么盲目套用网上脚本，结果时间全耗在路径不匹配上。来源里就有一个很具体的教训：CVE-2021-21972 的利用脚本针对的是 vCenter 6.5/6.7 的目录结构，而目标是 7.0，遍历到一百多个路径仍未成功，才发现版本对不上。这类“脚本能跑但目标不吃”的情况，是流程里最该被前置拦住的。

定义清楚输入、输出、角色和约束

在动手之前，先把这次演练的边界写下来，后面每一步都回来对照。

输入：授权范围说明（域名、IP 段、时间窗）、已确认的入口权限、内网可达性、目标资产清单（尤其是虚拟化与云平台组件）。来源中打点阶段的信息收集就是输入的一部分，FE 平台的历史上传问题属于“已确认入口”。

输出：可复现的路径记录、每一步的判断依据、最终是否触及管理平面的结论、以及证据留存。注意，输出不是“拿到多少台机器”，而是“路径是否闭环、结论是否可信”。

角色：打点与入口验证、内网横向与凭据处理、虚拟化平台专项、取证与记录。小团队可以一人多角，但判断点必须分开写，避免自己给自己背书。

约束：只做授权范围内的动作；对生产虚拟化平台的操作优先选择只读或低影响方式；任何可能影响业务连续性的动作（快照、内存读取）必须提前报备。来源里提到“后续获取某个虚拟机权限，常规是利用生成快照配合内存读取，很费时间”，这句话本身就是约束提示——成本高、影响面大，不适合作为默认动作。

阶段一：入口验证与凭据盘点，先把手里的牌数清

入口拿到后，第一件事不是急着扫内网，而是把已获得的凭据和会话盘一遍。

动作上，来源给出的做法是翻找文件、提取 hash。这里要加两个判断点：一是 hash 的类型和可解性，二是这些 hash 对应的账号在哪些主机上有效。来源明确写了“hash 解不开”“爆破没有碰撞成功几个”，这说明继续在解密上投入的边际收益很低，应该及时切换到“hash 直接利用”的思路。

交付物是一张凭据清单：账号、hash 类型、来源主机、疑似适用范围。风险点在于把时间全压在离线破解上，忽略了 hash 可以直接用于特定认证方式这一事实。优化建议是把“可解性评估”作为独立判断点，解不开就记录并转向，不要恋战。

阶段二：横向到管理面，用对认证方式比拿到明文更关键

来源里最有价值的一段，是 hash 解不开但可以用于 RDP 登录，并选择了 mimikatz 的 hash 传递方式，配合开启 Restricted Admin mode。这条路径的工程意义在于：它绕开了“必须先有明文密码”的假设。

具体动作分三步：先在目标上开启 Restricted Admin mode（来源给出的注册表操作为 DisableRestrictedAdmin 置 0，并用 reg query 确认生效），再用 mimikatz 执行哈希传递并拉起 mstsc 的 restrictedadmin 会话，最后在弹窗中选择连接完成登录。

判断点很明确：如果目标不允许修改注册表，或者策略限制 restricted admin，这条路就走不通，应尽早换路径而不是反复重试。交付物是“可登录的管理主机清单”和对应的认证方式记录。风险点在于对注册表的修改属于配置变更，在授权演练中要记录清楚并在结束后恢复。来源里登录成功后翻找 mstsc 记录、浏览器记录并无高价值发现，这恰恰说明：横向成功不等于目标达成，要盯着“管理平面”而不是“某台机器”。

阶段三：虚拟化平台专项，版本决定路径

扫描结果里出现 VMware vSphere v7.0 Linux，这是整条链路的分水岭。来源在这里给出了两个尝试和一次明确止损。

CVE-2021-21972 的关键在于路径随版本变化：6.5/6.7 早期版本在 vsphere-ui 的 work/deployer 目录下，6.7 较新版本在 static/resources/libs 下，而 7.0 的 resources 目录名是动态生成的，可以通过访问 /ui 获取目录信息。来源的脚本按 6.5/6.7 路径遍历，到一百多个仍未成功，判断出是版本不匹配后停止。这个“停”本身就是正确动作。

随后转向 CVE-2021-22005，网上脚本恰好支持 Linux，目标也是 Linux，成功拿下。这里有个细节值得记下来：想直接写 webshell 时一直缺字符，原因未明，最后改用蚁剑以 cmdlinux 方式连接。这个现象提醒我们，利用链里的“写入内容不完整”往往和字符集、转义、目标解析有关，遇到时不要硬调，换连接方式或换载荷形态更快。

拿到执行权限后，目标是找 db 或 cookie。来源给出的路径是 /storage/db/vmware-vmdir/data.mdb（Windows 对应 C:\ProgramData\VMware\vCenterServer\data\vmdird\data.mdb），从中获得有效的管理员 cookie，解密后借助浏览器插件替换 cookie，访问 https://IP/ui 登录管理界面。到这里，虚拟化平台才算真正拿下。

阶段对比：不同做法的收益与代价

这张表可以直接改造成你们自己的检查清单，把“优化建议”列换成责任人。

最容易出问题的三个环节与修复办法

第一个是版本与路径错配。来源里遍历一百多个路径才发现目标不匹配，这是典型的“脚本先行、版本后看”。修复办法是把版本识别放在利用之前：先确认 vCenter 版本与操作系统，再对照路径规则，7.0 的动态 resources 目录先通过 /ui 探测再定位。

第二个是凭据处理的方向错误。hash 解不开时继续爆破，收益极低。修复办法是明确两条并行线：离线破解作为低优先级后台任务，直接利用（如受限管理模式下的哈希传递）作为主线，两者互不阻塞。

第三个是拿到执行权限后急于写 webshell。来源里缺字符的问题消耗了时间，最终改用蚁剑连接解决。修复办法是预设多种载荷形态和连接方式，写入异常时先换形态而不是反复调参；同时明确目标是“拿管理面凭据”，webshell 只是手段。

最小可执行版本与迭代路线

如果你要拿这套流程去改现有做法，最小版本可以这样落地：第一步，入口验证后 30 分钟内产出凭据清单并标注可解性；第二步，横向阶段先探测认证策略，能走受限管理就走，走不通立刻记录换路；第三步，虚拟化专项先做版本识别和路径对照，再决定用哪个利用方式；第四步，管理面取证只做只读提取，cookie 获取后立即验证登录并留存证据。

迭代方向上，第一轮把“版本-路径对照表”固化成团队资产，第二轮把凭据清单模板和变更留痕规范补齐，第三轮再把单机深入（快照与内存读取）作为可选模块接入，并明确其时间与影响成本。

给读者的实践建议

基于当前可见信息，这条链路真正的价值不在某一个漏洞，而在于“判断点前置”：版本先于脚本、凭据可解性先于爆破、认证策略先于横向、管理面先于单机。建议你下次演练前，先把本文那张表的五列抄成自己的检查项，每完成一个阶段就回填产出物和风险点；如果某个判断点连续两次不通，就按来源里的做法果断止损换路径，而不是在同一处反复消耗。授权范围内把流程跑顺，比多拿一台机器更有复用价值。