2026-11-09 19:19:03 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

虚拟化安全 · 攻击层次与错误配置

原创

Rauf Johari
Rauf Johari

网络与信息安全参考

2026年11月7日 08:30
山东

去阅读

SECURELIST · SOC / TI / IR2026.11.06

虚拟化安全 · 攻击层次与错误配置

两起 ESXi 与 Proxmox 勒索软件事件复盘，以及按层次拆解的错误配置影响分析

ESXi · PROXMOX

从监控平台到 ESXi，从一份明文笔记到整个集群

虚拟化安全应急响应

ABSTRACT

原文摘要

通过 ESXi 与 Proxmox 环境中的勒索软件案例，详细拆解虚拟环境网络安全中的错误配置问题。

PART

引言

INTRODUCTION

虚拟环境中的安全事件，可能始于一个软件漏洞、一次人为失误、一处配置弱点，也可能由上述多个因素同时引发。调查往往不会只停留在工作负载层面。Hypervisor、容器运行时、管理控制台、监控平台、身份系统、虚拟网络、数据存储、备份以及自动化账号，都会影响攻击者能够触达的范围。

卡巴斯基 GERT 近期又调查了两起针对 ESXi 与 Proxmox 环境的勒索软件事件。在其中，薄弱的访问控制、不足的网络隔离、暴露的管理服务，以及对特权凭据的不善管理，共同放大了事件影响。一套能够触达虚拟化层的监控系统，同时还暴露了一份可复用的 root 凭据。攻击者一旦控制了这条路径，常规的管理访问权限就足以影响多台主机——整个过程并不需要任何虚拟机逃逸。

这两起事件说明，为什么补丁管理与安全配置必须一同治理。即使 Hypervisor 已打全补丁，它仍可能因共享密码、权限过高的监控账号、开放的 SSH 通道，或一个可从普通服务器网段访问的管理界面而被攻陷。NIST 指南将安全配置基线、受限的管理访问、及时更新的补丁，以及覆盖所有层次的监控，归入同一套健全的安全实践。

在本文中，我们将详细描述这两起事件，并着重分析其中被利用的常见不安全做法——它们如何导致失陷，以及相应的补救措施。我们还会讨论针对虚拟环境的更广泛威胁范围，以便更好地理解可能的防护策略。

PART

防御者必须保护的连通系统

THE CONNECTED STACK

一个企业虚拟环境并不只是 Hyper-V、VMware 或 Docker，而是一整套彼此连通的堆栈。管理控制台、编排工具、监控平台和自动化账号位于 Hypervisor 与容器引擎之上；镜像仓库、镜像存储、虚拟交换机、数据存储和备份系统则在各层之间建立连接。应用程序与业务服务运行在最底层，而大部分管理权限却集中在靠近顶端的位置。

重要的边界远不止“客户机到宿主机”这一条。它们还包括：工作负载到管理平面、监控系统到 Hypervisor、镜像仓库到部署、管理员工作站到控制台、管理平面到存储，以及一个虚拟网段到另一个虚拟网段。

攻击者只需要一条可用的路径。 失陷的可能性，也许就藏在一份被盗的、或存放不当的管理员凭据里，而非某个复杂的逃逸漏洞。

在 GERT 处理的这起案例中，失陷路径正是穿过监控平台，并包含了一份有效的虚拟化平台凭据。

PART

案例一：从网络监控到 ESXi 被加密

CASE #1 · FROM MONITORING TO ENCRYPTION

调查始于一条证据：在虚拟化域控网段的一台 Windows 系统上，出现了 BlackNevas 勒索软件的活动。UserAssist 痕迹记录到 AnyDesk 这款 RMM 工具以及 GMER 二进制文件的执行。该环境同时使用 PRTG Network Monitor 监控其虚拟基础设施。

UserAssist 痕迹：红框标出的是 AnyDesk 与 GMER 二进制的执行记录

现有证据显示，该 PRTG 部署对 ESXi 主机拥有广泛的访问权限，且同一个 root 密码在多台节点上被重复使用。在获取监控环境的访问权限后，攻击者利用这份 ESXi 凭据，通过 SSH 连接到使用同一密码的主机。这样的设计把“监控”“凭据存储”与“直接管理”并成了一条攻击路径。

PRTG 支持在设备级或继承的组级别存储 VMware 凭据。该功能在运维上很实用，但当一台监控服务器持有足以管理其所监控系统的凭据时，它本身就变成了特权基础设施。因此，安全问题不在于“监控是否需要访问权限”，而在于身份、权限、存储方式与允许的网络路径是否被限定在监控任务所需的范围内。

威胁行为者获得了 ESXi 环境的 root 访问权限，并使用 esxcli 命令关闭 execInstalledOnly 策略，从而绕过系统限制，执行加密二进制文件，并实施反取证式的日志删除。下面让我们仔细查看首台主机失陷的时间线。

ESXi（192.168.\.\）时间线

初始失陷

...log

2025-10-18　来自 IP 地址 192.168.\.\ 的连接尝试。

2025-10-19　在一次由 root 从 IP 192.168.\.\ 发起的 SSH 会话中，文件 esx 被上传至系统。

2025-10-19　用户 “root” 尝试执行二进制文件 esx，报错 “Execution of non-installed file prevented”。

chmod 777 esx

./esx /log

2025-10-19　用户 “root” 关闭 execInstalledOnly 选项。

esxcli system settings advanced set -o /User/execInstalledOnly -i 0

2025-10-19　用户 “root” 执行恶意软件 esx。

2025-10-19　来自 IP 192.168.\.\ 的新连接尝试。

与此同时，在使用相同 root 密码的另一台主机上，发生了以下活动：

ESXi（172.16.\.\）时间线

同密码横向

...log

2025-10-19　用户 “root” 从 IP 172.16.\.\ 建立 SSH 连接。

2025-10-19　用户 “root” 执行恶意软件 esx 并清除日志。

chmod a+x esx && chmod 777 esx

./esx /selftest

nohup ./esx /p /vmfs/ /depth 5 /log /wipe

./esx /depth 5 /log /wipe

PART

案例二：一份凭据笔记拖垮整个 Proxmox 环境

CASE #2 · PLAINTEXT CREDENTIAL NOTES

GERT 响应了一起由 The Gentlemen 组织实施的勒索软件事件。在该事件中，威胁行为者利用从初始访问到可见影响之间驻留期内收集到的信息，获取了 Proxmox 的访问权限。在一台已被攻陷的系统管理员工作站上，行为者发现了以明文形式存放在笔记中的管理凭据与访问信息。这些记录提供了使用 root 账号登录 Proxmox 所需的全部信息。

随后，行为者通过被攻陷的 root 账号激活了 VNC WebSocket，从而对 Proxmox 环境取得了广泛控制。这一访问权限随后被用于在集群内下载并执行勒索软件，最终导致整个虚拟环境被加密。以下是显示 root 账号通过 VNC WebSocket 访问其他主机的日志记录。

...log

root@pam [01/08/2026:00:28:36 -0400] \"GET /api2/json/nodes/\\\\\\/vncwebsocket?port=5900&vncticket=\\\\

root@pam [01/08/2026:00:30:17 -0400] \"GET /api2/json/nodes/\\\\\\/vncwebsocket?port=5900&vncticket=\\\\

root@pam [01/08/2026:00:31:19 -0400] \"GET /api2/json/nodes/\\\\\\/vncwebsocket?port=5900&vncticket=\\\\

root@pam [01/08/2026:00:43:38 -0400] \"GET /api2/json/nodes/\\\\\\/vncwebsocket?port=5900&vncticket=\\\\

root@pam [01/08/2026:00:44:49 -0400] \"GET /api2/json/nodes/\\\\\\/vncwebsocket?port=5900&vncticket=\\\\

这起事件清楚地说明，把特权凭据存放在不安全的笔记或其他易于访问的文件中会带来怎样的风险。一旦管理员工作站被攻陷，已保存的凭据就让行为者得以从单个终端进入虚拟化管理层。由于这些凭据属于权限极高的 root 账号，一次糟糕的凭据处理习惯，显著扩大了攻击的范围与影响。特权凭据应当存放在经过批准的密码管理器或特权访问管理系统中，以多因素认证加以保护，并在怀疑管理员工作站被攻陷时立即轮换。

PART

错误配置为何造成大范围影响

WHY MISCONFIGURATION HURTS

两起案例都出现了不安全的配置做法，这些做法被利用后，对主机系统造成了更大的影响。接下来，我们将逐项拆解这些错误配置，看看它们如何促成了进一步的失陷，以及应当如何避免。

MISCONFIGURATION监控系统继承了过高权限01 / 05

在案例一中，监控平台所能做的远不止采集健康与性能数据。它持有——或可以使用——权限足以直接触达 ESXi 的凭据。因此，监控系统被攻陷，就等同于管理平面被攻陷。监控身份应当专用于该任务，并且只授予所部署传感器所需的权限。

MISCONFIGURATION凭据复用02 / 05

密码复用把一份被复原的密钥，变成了整个集群的通行证。系统管理应通过中央管理平面使用具名身份。每台主机都应有独立凭据，并遵循规范的密码存储习惯。密码强度本身并不能限制凭据被盗后的影响，真正起作用的是凭据能在哪里使用以及它存放在哪里。

MISCONFIGURATION直接 root 访问绕过集中管控03 / 05

直接的 SSH 访问让行为者可以以 root 身份认证、上传二进制文件、更改安全设置，而无需先经过 vCenter 的角色控制。VMware 的母公司 Broadcom 建议通过 vCenter 管理 vSphere、在正常运营期间禁用 SSH，并在合适场景下启用锁定模式（Lockdown Mode）。必需的服务账号应作为明确的例外处理，而不是被放进一个宽泛的管理员组。

MISCONFIGURATION缺少增强安全设置04 / 05

最初的执行尝试被 execInstalledOnly 阻止，但攻击者拥有足够权限关闭该策略。Broadcom 记录了将 execInstalledOnly 与 UEFI 安全启动、TPM 支持的配置保护相结合的强制执行选项。这些控制必须被启用、测试，并监控其变更。一个可以被日常管理所用同一份凭据悄悄关闭的设置，在账号失陷之后所能提供的抵抗力相当有限。

MISCONFIGURATION不安全的凭据存储05 / 05

案例二说明，失陷的可能性恰恰藏在特权凭据的暴露之中。缓解策略不仅包括加固管理凭据的存储，还包括机密信息处理方面的一般性加固实践，例如权限管理和定期的访问审计。

PART

如何封堵这条攻击路径

HOW TO CLOSE THE PATH

在本节中，我们分享缓解此类攻击、并检测和阻止其进一步蔓延的补救建议。我们建议采取以下行动：

将监控与管理分离

为每个平台创建专用的监控身份，并将其限制在监控传感器所需的最小对象与操作集合内。不要使用 ESXi root 或其他应急账号执行日常轮询。除非另有经批准的支持流程要求，否则应阻止监控服务器发起交互式管理会话。同样的原则也适用于 VMware 之外的平台。

替换已存储的 root 密码

在监控工具、脚本、计划任务、连接管理器和服务配置中，定位每一份 Hypervisor、管理、存储与备份凭据的副本。在平台支持的前提下，用保险库检索、代理身份或受限 API 令牌取代静态密码。记录每一次凭据检索，并在应急使用或失陷后轮换密钥。

限制对主机的直接访问

将常规的 ESXi 管理流量经由 vCenter 转发，并在测试监控、备份与恢复依赖关系之后，启用合适的锁定模式。默认保持 ESXi Shell 与 SSH 处于停止状态。当支持工作需要 SSH 时，在限定时间内启用、限制来源地址，并对服务启用、root 登录，以及“允许通过 SSH 连接的用户”例外列表的变更发出告警。

使用专用的安全解决方案

在我们的产品组合中，Kaspersky Cloud Workload Security（KCWS）非常适合应对虚拟环境风险，它由两款产品强力组合而成：Kaspersky Hybrid Cloud Security（KHCS）与 Kaspersky Container Security（KCS）。Kaspersky Hybrid Cloud Security 专为保护虚拟化基础设施、私有数据中心与混合云而构建。其获得专利的 Light Agent 架构在不为性能妥协的前提下将资源占用降至最低；通过统一控制台实现的全面基础设施可视化，让管理员对整套混合网络拥有完整的可见性与控制力。Kaspersky Container Security 覆盖容器化应用生命周期的每个阶段，从开发到运行。除其他能力外，该方案还可通过专用扫描器检测镜像、文件系统以及包含 IaC 文件（如 Terraform、CloudFormation、Azure ARM 模板、Helm chart 与 Dockerfile）的仓库中的错误配置。

将配置变更视为安全事件

当 execInstalledOnly、安全启动强制执行、锁定模式、SSH、本地账号、例外用户、防火墙规则或远程日志设置发生变化时发出告警。为预期状态建立基线，并测试安全团队能否检测到未授权的变更。一次性的安全配置，并不意味着该控制会一直在主机上保持生效。

隔离管理网络

将 Hypervisor、监控、备份、存储与集群管理放置于受限的管理网络中。只允许精确必需的源与目标服务。管理员工作站应通过加固的跳板机、以具名身份和多因素认证进入。

保护日志、备份与恢复

将 ESXi、vCenter、Proxmox 监控、身份与网络日志转发到受保护、且被攻陷的管理员无法抹除的存储中。备份平台应使用独立身份、受限的管理路径，以及在常规管理权限之外保存的恢复副本。

PART

被监控虚拟化环境的配置核查

CONFIGURATION CHECKS

以下是在启用虚拟化监控时建议执行的核查项。最安全的状态取决于平台与监控方式，但每一项控制都应经过测试。

控制领域

更安全的状态

验证方式

监控身份

仅具备必要读取与轮询权限的专用服务账号或令牌

审查已分配的角色，并在不使用 root 或全局管理员权限的情况下测试每一个传感器

凭据存储

监控或通用服务器上不存在可还原的主机 root 密码

审查工具配置、脚本、计划任务与连接存储，查找内嵌的凭据、访问令牌或其他机密

网络路径

监控只能访问必要的轮询服务，管理操作则经由跳板机

从监控服务器、用户网段与不受信任的网段测试管理端口

主机直接访问

在适用场景启用锁定模式，并默认停止 SSH 与 ESXi Shell

尝试使用常规账号对主机发起直接的客户端 API 与 SSH 访问

配置完整性

在受支持的环境启用并测试安全启动与 execInstalledOnly 强制执行

通过经批准的流程更改一项测试设置，并确认已生成告警

证据留存

主机、管理、身份、监控、防火墙与 PAM 日志远程存储

生成成功与失败的登录，并核验来源、账号、主机、时间与操作

PART

更广阔的攻击面

THE WIDER ATTACK SURFACE

封堵监控与凭据这两条路径，本身并不足以让环境变安全。虚拟化还依赖隔离边界、可信镜像、管理 API、虚拟网络、存储与备份。每一个层次都需要不同的控制措施，也会在不同位置留下证据。

ATTACK SURFACE虚拟机与容器逃逸01 / 04

在虚拟机逃逸中，客户机内的代码越过了虚拟机边界，影响到宿主机或另一个客户机。弱点可能存在于虚拟设备、集成功能、hypercall 接口，或其他负责将客户机请求转译给宿主机的组件中。一旦逃逸成功，对一台虚拟机的控制就可能延伸为对物理服务器及其上每一个工作负载的控制。VMware CVE-2025-22224 展示了这一风险：拥有虚拟机内管理员权限的攻击者，可以以宿主机上 VMX 进程的身份执行代码，Broadcom 报告称该漏洞已被在野利用。

容器逃逸可以达到类似的结果，但起点不同。Linux 容器与宿主机共享内核，因此其隔离模型与虚拟机不同。命名空间限制了进程可见的范围，cgroups 控制资源使用，而 capabilities 将 root 特权拆分为更小的部分。一个内核或运行时缺陷即可打破这种隔离。Copy Fail（CVE-2026-31431）就是一个很好的内核缺陷示例。已经在容器内运行的代码，可以利用 Linux AF\_ALG 加密套接字修改共享内核页缓存中的页面。由于宿主机和其他容器可能读取相同的缓存页面，其影响不必局限在单个容器之内。修复方式是更新内核；Docker Engine 29.4.3 也收紧了其默认安全配置，以降低尚未打补丁的主机所面临的风险。

不安全的设置同样可以打破边界。特权模式、过多的 capabilities、可写的主机挂载，或对 Docker socket 的访问，都可能在没有任何软件漏洞利用的情况下消除隔离。例如，runc 的 CVE-2024-21626 涉及文件描述符泄漏，可能将宿主机文件系统暴露给恶意镜像或容器进程。

这一差异改变了调查方式。虚拟机通常可以被当作一台独立的计算机来处理，它拥有自己的内核、内存与磁盘。而容器则是被放进命名空间的一组宿主机进程。如果调查人员只收集容器文件系统，他们可能会把最有价值的进程、套接字与控制平面证据留在宿主机上。

ATTACK SURFACE镜像与模板02 / 04

被攻陷的黄金虚拟机镜像或容器基础镜像，可以借由正常的自动化流程扩散。常见的弱点包括：非官方公共镜像、可变标签、权限过高的构建令牌、旧镜像层中可复原的机密，以及会还原出脆弱软件或被遗忘账号的陈旧模板。扫描或许有帮助，但它无法确认制品的构建者是谁，也无法确认最终部署到生产环境的，是否正是那个经过测试与批准的镜像。应使用受控的构建器、来源记录、签名校验，以及基于可信来源的计划性重建。

ATTACK SURFACE管理工具与 API03 / 04

一份被盗的 vCenter 身份、一个暴露的 Docker API、一个权限过大的 Portainer 角色，或一台被攻陷的备份控制台，都可能为攻击者提供比逃逸漏洞更省力的路径。Portainer 安全公告 GHSA-7fw3-x4r2-g7wc 展示了这样一个问题：代理校验了一种绑定挂载的表示形式，却漏掉了等价的 API 形式，使得具备容器创建权限的已认证非管理员用户得以触达宿主机路径。运行时执行了一个“合法”的请求，而授权在管理层其实早已失败。

管理性的文件复制操作同样值得关注。Docker 在 CVE-2026-41567、CVE-2026-41568 与 CVE-2026-42306 中修复了归档与挂载处理方面的缺陷。这些案例需要特定条件以及操作员或 API 活动才能触发。它们提醒我们：要为守护进程打补丁，并记录是谁发起了复制操作、涉及哪个容器、源与目标路径，以及操作结果。

ATTACK SURFACE虚拟网络、存储与备份04 / 04

虚拟工作负载之间的东西向流量可能始终留在一台主机内部，从而绕过物理探针。管理、迁移、存储与工作负载流量应使用彼此独立的区域，并在区域之间实施过滤。快照与内存文件可能包含凭据，而薄弱的数据存储权限则可能暴露整块虚拟磁盘。备份系统需要广泛权限才能恢复服务，这也让它们对企图删除恢复点或触达多台主机的攻击者极具价值。

PART

按层次划分的攻击面示例

ATTACK SURFACE BY LAYER

总结一下，上述攻击向量可能按如下方式加以缓解：

攻击面

初始访问

可能影响

主要控制

凭据与配置

从监控系统或权限过高的账号中复原的密码

直接控制多台 Hypervisor 节点

唯一的保险库凭据、分段访问与配置监控

虚拟机逃逸

客户机内的管理员访问或代码执行权限，叠加一个 Hypervisor 漏洞

宿主机进程或相邻工作负载被攻陷

为 Hypervisor 打补丁，并减少有风险的虚拟设备与客户机权限

影响内核或运行时的恶意容器

容器内的代码或恶意镜像

宿主机文件系统、内核或共享缓存受影响

为内核与运行时打补丁，并移除特权设置

镜像与模板

被攻陷的构建输入仓库或黄金镜像

失陷状态被反复部署

不可变摘要、受控构建、来源记录与校验

管理 API

被盗的身份暴露了端点，或存在授权缺口

全集群范围的管理操作

MFA、最小权限、网络限制与完整的 API 校验

网络、存储与备份

扁平网络，或宽泛的数据存储权限与经由备份的访问

横向移动、数据窃取、加密与恢复能力丧失

分段隔离、最小权限、受保护的备份与流量监控

///

END

结语

CONCLUSION

我们在本文中呈现的 GERT 案例，都不需要攻击者突破虚拟机边界。这条攻击路径是由以下因素共同塑造的：权限过高的监控关系、不安全的密码存储方式、可复原且被复用的 root 凭据、管理网络的可达范围过宽，以及直接的 SSH 管理。每一个要素单独来看都属正常，但合在一起，就让一次失陷得以触达虚拟化主机及其工作负载。

因此，错误配置应当获得与漏洞管理同等的运营重视。团队需要知道：特权凭据存在于何处、哪些系统可以使用它们、哪些网络路径让它们得以生效，以及哪些日志会记录它们的使用。逃逸漏洞、不安全镜像、API 弱点、虚拟网络暴露，以及对存储或备份的攻击依然严重，但封堵已知的管理路径应当排在第一位。

错误配置不是漏洞管理的附庸——它本身就是一条完整的攻击路径。

ORIGINAL / 原文信息

TITLE / 标题

Virtualization security: attack layers and misconfiguration impact

AUTHOR / 作者

Rauf Johari

PUBLISHED / 发布日期

2026 年 11 月 6 日

SOURCE / 来源

Securelist（卡巴斯基官方安全博客）

LINK / 原文链接