FortiClient EMS供应链攻击：当端点管理器变成攻击跳板

攻击者利用CVE-2026-35616绕过FortiClient EMS认证，通过合法的端点管理通道向所有受管设备推送恶意”安全更新”，窃取浏览器密码、Cookie和支付信息。

开篇

2026年5月，Arctic Wolf安全团队披露了一起令人警醒的攻击事件：威胁行为者利用FortiClient Endpoint Management Server（EMS）的一个严重漏洞，将本应保护端点安全的管理系统，变成了分发恶意软件的工具。

这不是一起普通的数据窃取事件。攻击者利用的，正是企业安全基础设施中最受信任的组件之一——端点管理平台。通过伪装成Fortinet官方更新，恶意载荷借助合法管理通道”合法”地分发到每一台受管终端。

这种”以彼之矛，攻彼之盾”的手法，标志着供应链攻击进入了一个新阶段。

一、攻击链完整还原

1.1 初始突破：CVE-2026-35616

整个攻击链始于对FortiClient EMS的CVE-2026-35616漏洞的利用。这是一个CVSS 9.1的严重漏洞，属于预认证API访问绕过导致的权限提升。

FortiClient EMS是Fortinet企业端点安全解决方案的管理中枢，负责集中管理、策略下发和软件更新。它拥有对所有受管端点设备的高级权限——包括远程执行命令、推送软件更新、修改安全策略等。

漏洞的本质是：EMS的某些API端点缺乏有效的认证检查，未经认证的攻击者可以通过直接调用这些API获取管理员级别的权限。这意味着，任何能访问EMS服务端口的人，都可以绕过登录直接接管整个端点管理系统。

1.2 权限提升：篡改管理策略

获得EMS的管理权限后，攻击者并未急于部署恶意软件，而是先进行了一系列精心的准备工作：

第一步：延迟固件升级提醒

攻击者修改了端点配置，推迟了固件升级的提醒通知。这一步的目的是防止受管设备在攻击过程中弹出升级提示，引起用户警觉。

第二步：修改远程访问配置

攻击者修改了Remote Access Profile配置，为后续的远程访问留好后门。

第三步：植入恶意执行策略

最关键的一步——修改端点策略配置，在其中插入了恶意PowerShell脚本。这个脚本会在每一台受管设备上执行。

“威胁行为者利用了FortiClient自身的管理通道，向受管端点推送恶意PowerShell命令，其方式与合法管理操作无法区分。” ——Arctic Wolf

1.3 恶意载荷：披着羊皮的EKZ Infostealer

攻击者使用的恶意软件被命名为EKZ Infostealer，它的分发方式极具欺骗性：

分发链路：

FortiClient EMS（已被控制）
    ↓ 推送"更新"
fortitray.exe（合法FortiClient组件）
    ↓ 调用
malicious.cmd脚本
    ↓ 执行
Base64编码的PowerShell脚本
    ↓ 下载并运行
FortiEndpoint_Patch.exe（伪装为Fortinet更新）
    ↓ 释放
EKZ Infostealer

关键细节：

攻击者利用了fortitray.exe——这是FortiClient的合法组件——来启动恶意CMD脚本。这种方式极大地提高了攻击的隐蔽性，因为安全软件通常会信任FortiClient的合法进程。

下载的FortiEndpoint_Patch.exe从文件名到图标都伪装成了Fortinet官方更新。然而，它的真实身份是一个Windows信息窃取器，专门针对：

窃取的数据被写入日志文件并保存到ProgramData目录。值得注意的是，窃取器本身没有网络外传功能——数据回传完全由前面的PowerShell脚本完成，通过HTTP POST请求发送到攻击者控制的服务器83.138.53[.]110。

这种职责分离的设计降低了被安全软件检测到的风险：窃取器只负责收集数据（减少网络行为特征），外传由另一个组件完成。

二、攻击的影响分析

2.1 规模效应

这起攻击最可怕的地方在于规模效应：攻击者只需要攻破一个EMS服务器，就能同时影响其管理的所有端点设备。

“一旦攻击者获得了修改EMS管理配置的路径，每一台受管端点都变成了潜在的执行目标，无需为每台设备寻找单独的入侵路径。”

这意味着，如果一个EMS管理着1000台终端，攻击者只需要利用一个漏洞，就能同时向1000台设备推送恶意软件。

2.2 窃取数据的后续利用

窃取的浏览器凭据和Cookie的危害远不止直接的数据泄露：

场景1：绕过MFA 现代企业广泛使用MFA（多因素认证），但会话Cookie是MFA之后的产物。攻击者利用窃取的Cookie可以直接恢复已认证的会话，完全绕过MFA的验证步骤。

场景2：横向移动 浏览器保存的密码可能包括内部系统、VPN、云服务的登录凭据。攻击者可以利用这些凭据从一台被入侵的终端扩展到更多系统和网络。

场景3：财务损失 自动填充数据中的信用卡信息、地址、手机号等，可被用于网络购物、欺诈等犯罪活动。

2.3 信任链条的破坏

这起攻击最深层的危害是对安全产品信任链的破坏。当端点管理器——企业安全架构中最核心的组件之一——变成攻击工具时，企业安全团队将面临一个令人困惑的困境：

• 安全更新推送是真的更新还是恶意软件？
• 端点管理策略是管理员的意图还是攻击者的植入？
• 安全产品的告警是误报还是正在发生的入侵？

三、技术启示：三重失败叠加

这起攻击并非单一安全缺陷导致，而是三重安全失败的叠加效应：

3.1 第一重：认证失败

FortiClient EMS的API存在预认证绕过漏洞，这是整个攻击链的入口。一个暴露在网络中的管理接口，不应该存在不需要认证就能获取管理员权限的API端点。

教训：所有管理接口，尤其是面向网络的API，必须实施严格的认证和授权检查。零信任原则不应仅适用于终端用户，更应适用于系统间的API调用。

3.2 第二重：完整性验证失败

攻击者能够伪装成Fortinet的更新并推送恶意可执行文件，说明系统缺乏对推送内容的完整性验证。一个安全产品的更新分发机制，竟然允许推送未签名的任意可执行文件。

教训：端点管理系统推送的所有内容（策略脚本、软件更新、配置文件）都必须经过数字签名验证。任何未经合法签名的代码都不应被执行。

3.3 第三重：行为监控失败

攻击过程中产生了多个异常行为信号——配置篡改、异常的PowerShell执行、Base64解码、外部数据回传——但这些行为在攻击持续期间未被有效检测和拦截。

教训：端点检测与响应（EDR）系统应关注行为的异常性，而不仅是文件的特征。即使进程来自合法的可信组件（如fortitray.exe），其异常的子进程行为也应触发告警。

四、防御建议

4.1 立即行动

4.2 架构加固

• 网络隔离：EMS服务器不应直接暴露在公网，应通过VPN或零信任网络访问（ZTNA）进行管理
• API安全审计：定期对EMS及其他管理平台的API进行安全测试
• 代码签名验证：启用所有端点管理推送内容的数字签名验证
• 最小权限原则：限制EMS服务器的网络出站策略，防止数据外传

4.3 检测策略

检测规则1：Fortitray.exe启动cmd.exe的异常子进程链
检测规则2：PowerShell执行Base64解码命令
检测规则3：向未知IP的HTTP POST请求（ProgramData目录）
检测规则4：EMS配置的非授权变更
检测规则5：固件升级提醒被异常推迟

五、供应链安全的新常态

FortiClient EMS攻击事件并非孤例。近年来，安全基础设施被武器化的案例层出不穷：SolarWinds Orion事件、Kaseya VSA攻击、ManageEngine漏洞利用……攻击者越来越倾向于攻击安全工具本身，因为：

1. 信任最高：安全产品拥有系统中最高的权限
2. 覆盖最广：一个管理平台控制成百上千的终端
3. 检测最难：安全产品本身的行为常常被排除在安全监控之外

对于企业安全团队来说，这起事件传递了一个明确的信号：你的安全工具可能正在保护你的同时，也成为了攻击者眼中的最佳跳板。 保护安全基础设施本身，已经和用它来保护业务系统一样重要。

结语

当端点管理器变成攻击分发平台，当安全更新变成恶意载荷的伪装，当合法组件成为攻击的载体——传统的信任模型正在被一一击破。

FortiClient EMS攻击事件的教训是深刻的：在安全防御体系中，没有什么是天然可信的。每一层信任关系都需要被验证，每一条管理通道都需要被保护，每一个”合法”操作都需要被审计。

因为下一次攻击，可能就来自你最信任的安全工具。

参考来源：Arctic Wolf、The Hacker News 漏洞编号：CVE-2026-35616 CVSS评分：9.1（Critical） 影响版本：FortiClient EMS < 7.4.7