如果你的企业或客户在用SimpleHelp做远程技术支持，现在请停下来先读这篇文章。2026年4月25日，美国CISA将两个SimpleHelp漏洞同时加入已知被利用漏洞（KEV）目录，其中CVE-2024-57726的CVSS评分高达9.9——这是满分10分以下极少见的"近满分"漏洞。更糟糕的是，DragonForce勒索软件组织已经将这两个漏洞打包成攻击套件，专门用来定向击穿托管服务提供商（MSP）和IT外包服务公司的基础设施。
SimpleHelp是什么，为什么IT外包必须关注
SimpleHelp是一款广泛用于远程技术支持的商业软件，类似于TeamViewer或ConnectWise，允许IT技术人员远程登录客户设备进行运维操作。在IT外包和托管服务市场，SimpleHelp因其部署简单、价格相对合理，被大量中小型MSP采用。这也正是它成为DragonForce攻击目标的原因——一旦攻破MSP的SimpleHelp服务器，攻击者就能以"合法运维人员"的身份进入MSP管理的所有客户环境，形成典型的供应链横向扩散。
两个漏洞的技术细节
| CVE编号 | 类型 | CVSS | 危害 | 修复版本 |
|---|---|---|---|---|
| CVE-2024-57726 | 缺失授权漏洞 | 9.9（严重） | 低权限技术员账户无需额外认证，直接创建超权API密钥提升至服务器管理员 | SimpleHelp 5.5.8+ |
| CVE-2024-57728 | 路径遍历漏洞 | 7.2（高危） | 管理员权限下上传构造的ZIP文件，将恶意文件解压至任意目录，实现持久化后门 | SimpleHelp 5.5.8+ |
这两个漏洞形成了一条完整的攻击链：首先通过CVE-2024-57726将任意技术员账户（甚至是已离职员工的残留账号）提权至管理员，然后利用CVE-2024-57728投递持久化后门，确保即使管理员修改密码、重置账户，攻击者也能维持对服务器的控制。CISA的安全公告明确指出，如果你的SimpleHelp服务器已有12个月以上未升级，应当将其视为"已被潜在攻陷"状态来处理，而不是打完补丁就万事大吉。
DragonForce：专门猎杀MSP的勒索组织
DragonForce是2025年兴起的勒索软件即服务（RaaS）组织，其显著特征是以托管服务提供商作为优先攻击目标。逻辑很简单：攻破一家MSP，等于同时获得该MSP所有客户的访问权限，勒索收益是直接攻击单个企业的数倍乃至数十倍。在本次攻击活动中，DragonForce的典型行为链如下：
- 侦察阶段：通过Shodan等扫描工具定位互联网暴露的SimpleHelp管理界面（默认端口443/80）
- 初始访问：利用CVE-2024-57726，用任意低权限账户创建管理员级API密钥
- 权限维持：通过CVE-2024-57728部署持久化后门，写入Web应用目录
- 横向移动：以"合法IT技术人员"身份通过SimpleHelp接入所有被管理客户的设备
- 数据外泄+加密：使用Rclone批量外泄数据至云存储，随后部署勒索载荷
值得注意的是，步骤4中的横向移动对绝大多数被攻击客户来说几乎不可见——他们的监控系统只会看到"来自MSP的日常运维连接"，不会触发任何告警。
同期CISA KEV更新：D-Link DIR-823X路由器无补丁漏洞
在同一批KEV更新中，CISA还收录了D-Link DIR-823X路由器的CVE-2025-29635（命令注入，CVSS 7.5，已被Mirai僵尸网络利用）。这个漏洞的特殊性在于：D-Link已于2024年停止对该系列的软件支持，官方明确表示不会提供补丁。CISA的指导意见直接是"停用并物理更换设备"。
这对IT外包服务商来说是一个很现实的问题：客户网络中经常存在使用多年的老旧路由器设备，EOL（生命周期终止）设备的漏洞永远无法通过打补丁解决。在每次现场巡检时，建议将客户网络中所有EOL设备列为"待替换风险资产"，并在服务报告中明确说明风险。
应对措施：四步快速自查
- 立即检查SimpleHelp版本：登录管理界面查看版本号，低于5.5.8的必须立即升级，官方提供一键升级功能
- 审计技术员账户列表：删除所有离职员工账户、测试账户及无主账户；检查是否有异常API密钥
- 检查服务器文件系统：重点检查Web目录下是否有非预期文件写入（特别是.jsp、.php、.war格式的可执行文件）
- 排查客户网络EOL设备：D-Link DIR-823X、DIR-850L等已停止支持的型号需列入替换计划
联邦机构的强制修复截止日期是2026年5月8日，对于非联邦机构来说没有法定强制，但考虑到DragonForce的活跃攻击态势，建议将修复窗口控制在本周内。从我们服务北京地区多家中小企业的经验来看，运维工具自身的安全往往被忽视——我们关注客户业务系统的安全，却忘了检查我们用来维护这些系统的工具本身是否安全。这正是供应链攻击最喜欢利用的盲区。