Check Point 防火墙在野攻击链：PHP2Shell 破门、DynamicCLI 提权 root、ESXi 宿主机遭擦除

事件概述：官方确认在野利用，CISA 已限期修复

11 月 12 日，Check Point 发布紧急安全公告 sk1000362：Gaia 操作系统 DynamicCLI 进程存在本地权限提升漏洞 CVE-2026-123039（CVSS 3.1 7.8），攻击者可以用一个普通的本地登录账户，拿到网关设备的 root 权限。同一天发布的 Check Point Research 分析报告披露，该漏洞已经不是在野利用的"候选目标"，而是真实攻击链中的一环——先通过 Mobile Access 门户的 PHP2Shell 漏洞（CVE-2026-109618 / CVE-2026-109619，未认证远程代码执行）破门，再借 DynamicCLI 提权到 root，安装后门，最后横向连上 VMware ESXi 宿主机运行擦除器。CISA 已于 11 月 13 日把 CVE-2026-123039 列入已知在野利用漏洞目录（KEV），联邦机构须在 11 月 16 日前完成修复。

Check Point 官方口径是：约二十几台未打补丁的系统被攻陷，攻击分两波——第一波从 10 月 30 日开始，针对以色列机构的 Mobile Access 门户；第二波从 11 月 2 日开始，打击了多个国家的 Security Gateway。官方称两波攻击都没有明显的行业偏好，属于机会主义的初始访问尝试。

攻击链拆解：五步从公网到 ESXi 宿主机

这条攻击链值得逐段看，因为每一段单独看都不算新鲜，串起来却完整覆盖了"边界设备→root→虚拟化层"的经典路径：

第一步，PHP2Shell 未认证入场。攻击者直接攻击暴露在公网的 Mobile Access 门户，利用 PHP2Shell 两个远程代码执行漏洞拿下门户服务账户。这两个漏洞本站此前解读过（PHP 运行时缺陷，无需认证、单条请求即可执行代码），这次是它在真实 campaign 中的落地。

第二步，DynamicCLI 套接字提权 root。CVE-2026-123039 的问题在于权限分配：DynamicCLI 进程以 root 运行，却通过一个任何本地进程都可以写入的控制套接字接收命令，且不校验连接者身份。于是门户服务账户这个低权限本地账户，就能提交以 root 身份执行的命令。

第三步，留置后门。拿到 root 后，攻击者部署 PHP Web Shell，以及两个后门工具：TSGA（被动式工具）和 TSProxy（钩入 appliance 进程、监控流量），再用 gogo 工具扫描内网。

第四步，横向进入虚拟化层。攻击者通过 SSH 连接到了一台 VMware ESXi 宿主机——这一步是整条链里最值得警惕的信号：边界防火墙失陷后，虚拟化基础设施成为下一个目标。

第五步，运行擦除器。在部分失陷环境中，攻击者运行了 destroy_v6 擦除器，递归删除文件并尝试覆写，同时留下提及巴以冲突的 DREAM_ANNEXATION.txt 留言文件。

影响范围与利用前提

受 CVE-2026-123039 影响的产品包括 Security Gateway、Firewall、Security Management Server、Multi-Domain 与 Scalable Platforms，版本覆盖 R81 到 R82.20。Spark 系列防火墙和 Smart-1 Cloud 不受该漏洞影响，但 Check Point 博客提示 Spark 受 PHP2Shell 影响——也就是说，只堵住提权这一环并不够，入口侧的 PHP2Shell 同样要处理。

利用前提方面：PHP2Shell 环节要求 Mobile Access 门户可达且运行受影响版本；提权环节要求攻击者在设备上已有任意本地账户权限。两段叠加，意味着"门户暴露公网 + 未及时打补丁"的网关处在完整攻击路径上。由 MSP 代管的防火墙往往同时具备这两个特征，却缺少客户侧的可见性，是需要重点确认的对象。

为什么站长和企业运维要关注

防火墙不是普通资产。它是网络边界上"默认受信"的设备，日志、会话、凭据、VPN 隧道都经过它；它一旦失陷，攻击者看到的不是一台机器，而是整个内网的地图。这条链还演示了两件更宏观的趋势：一是 PHP2Shell 这类"运行时通用漏洞"会被快速武器化到具体产品上，从披露到在野利用以天计；二是破坏性行动正在向虚拟化层延伸——擦除器跑在 ESXi 上，一台宿主机上的虚拟机可能全部陪葬，备份如果和虚拟化平台打通，同样危险。

对中小企业来说，自有网关的概率不高，但"MSP 托管防火墙 + 虚拟化环境"的组合非常常见。这正是需要向服务商问清楚的问题：补丁打到哪个 Take 了、Mobile Access 暴露面收敛了没有。

排查思路

Check Point 官方与 CISA 的建议方向一致，排查可以分四步走：

1. 版本与补丁级别核对。在网关上确认当前版本与 Jumbo Hotfix 的 Take 编号，对照下文修复版本表；重点标出 internet-facing 的 Mobile Access 网关。

2. 本地账户审计。DynamicCLI 套接字的利用前提是本地账户，检查网关上是否存在多余本地账户、shell 账户或异常的服务账户派生会话。

3. 日志与官方指标检查。按 Check Point 公告检查 /var/log/dynamicCli.log 及官方发布的失陷指标（IoC），回溯时间至少到 10 月 30 日；同时检查 Web 目录是否存在异常脚本、异常出站连接。

4. 虚拟化侧核查。如果网关与虚拟化平台管理网互通，检查 ESXi 是否有来自网关的异常 SSH 会话、异常文件删除或覆写行为。

需要说明的口径：官方未公布完整 IoC 清单细节，"未见失陷迹象"不等于"未失陷"，日志断档、被删除本身就是信号。

修复与缓解建议

修复方面，Check Point 已随 11 月 Jumbo Hotfix 发布修复，受影响分支的修复版本为：R82.20 Take 14、R82.10 Take 52、R82 Take 132、R81.20 Take 174。升级顺序上，官方建议先打管理服务器和网关，其中暴露在互联网的 Mobile Access 网关最优先。

已经 EOL 的 R81 与 R81.10 没有官方修复，官方临时缓解是停用 dynamic_server 进程并防止其重启。这是一个降低安全水位的动作（DynamicCLI 相关管理功能会受影响），操作前请确认远程运维通道是否依赖该组件，并先在测试环境或维护窗口验证；更根本的出路是规划升级到受支持版本。

对疑似失陷设备，建议按 CISA 的取证分诊口径处置：先隔离、保留镜像与日志，再重建，不要"打完补丁就当没事"；补丁或重建后轮换该设备接触过的所有凭据，包括管理账户、证书和下游系统口令。任何重启生产网关、调整防火墙策略的操作，都请先备份配置、评估业务影响，并选择业务低峰期执行。以上版本与步骤口径以 Check Point 官方公告和 CISA 指引为准。

后续观察

两个值得继续跟踪的点。一是归因：攻击活动时间偏向中国时区，恶意软件和基础设施也与中国背景工具有关联，但擦除器和政治留言并不符合已知中国背景行动的特征——Check Point 明确提示可能存在假旗，官方不做高置信度归因，外界也不应替厂商下结论。二是 KEV 期限：11 月 16 日是联邦机构的修复死线，历史上这类期限前后往往会再出现一波扫描和利用尝试，暴露在公网的设备应当在期限前完成升级或缓解。

更广义的教训是：这条链里没有利用什么惊人的零日，PHP2Shell 是已知的 PHP 缺陷，DynamicCLI 是权限分配失误，真正的失分点是补丁延迟和暴露面管理。边界设备的"可信"地位，恰恰使它成为攻击者最愿意花时间打磨攻击链的地方。