谷歌威胁情报预警：ShinyHunters 重启 Oracle PeopleSoft 大规模攻击——这条新闻值得每个外贸企业认真读完

2026 年 9 月 25 日，Google 威胁情报集团（GTIG）与 Mandiant 发布了一份重要更新：与 ShinyHunters 关联的黑客集群 UNC6240 正在重启对 Oracle PeopleSoft 的大规模利用，并已在全球数十个系统上部署了网页后门（web shell），波及高等教育、科技、IT 服务、医疗、农业、运输和政府等多个行业。几天前，同一组织刚刚声称利用 PeopleSoft 漏洞入侵了美国 FBI 的招聘门户并窃取数据——FBI 已确认正在调查。

看到这条新闻，多数外贸企业主的第一个反应是：”我们不用 PeopleSoft，和我无关。”这个反应恰恰是这条情报最想纠正的错觉。这个案例的价值不在于 PeopleSoft 本身，而在于它把过去几年我们反复讲的安全原则用一个国家级受害者演示了一遍——包括”上了 WAF 就安全”的边界错觉、”种后门长期潜伏”的攻击升级，以及为什么应急响应有严格的顺序。我们此前发布过一篇《外贸网站被攻击了怎么办：48小时应急剧本与”高仿站”攻击的原理拆解》，这一篇算是那份剧本的”现实案例续集”。

一、事件时间线：从高校到 FBI，一条完整的攻击链

先把已确认的事实按时间排清楚：

5 月 27 日–6 月 9 日：第一波零日攻击。UNC6240 利用 PeopleTools 8.61/8.62 中 Environment Management Hub（PSEMHUB）组件的漏洞发起攻击，当时该漏洞尚未公开——这是真正的零日攻击，主要目标是高等教育机构。Google 事后通知了 100 多个暴露了相关端点的组织，其中 68% 是高校。6 月 10 日，Oracle 发布带外安全补丁，漏洞编号 CVE-2026-35273，CVSS 评分 9.8——满分级别的严重漏洞，无需任何认证即可远程执行代码。

6 月–9 月：防御者打补丁了吗？Mandiant 的最新报告给出了残酷的答案：很多组织没有打补丁，而是选择了一条”捷径”——在 WAF（Web 应用防火墙）里加规则，封堵 /PSEMHUB/ 路径。

9 月：第二波攻击，WAF 被一个字符绕过。ShinyHunters 改进了利用代码，专打”上了 WAF 规则但没打补丁”的组织，把 web shell 部署到了全球数十个系统上。同期，该组织声称用一个新的 PeopleSoft 零日漏洞入侵了 FBI 招聘门户 apply.fbijobs.gov，篡改页面、声称横向移动进入 AWS GovCloud 环境并窃取了 2–3TB 数据（这些细节中，FBI 仅确认”正在调查”，新零日本身未经独立证实）。

二、技术拆解：绕过防火墙只需要一个字符

第二波攻击中最值得所有技术负责人记住的细节，是 WAF 绕过的方式——简单到令人难堪。

组织们在 6 月的通报之后，普遍在 WAF 规则里封堵了 /PSEMHUB/ 这个路径。ShinyHunters 的应对：把请求路径改写为 /%50SEMHUB/——%50 是字母”P”的 URL 编码。很多 WAF 和反向代理在 URL 解码之前按字面字符串匹配路径，规则里写的是 /PSEMHUB/，来的请求是 /%50SEMHUB/，匹配不上，放行；而应用服务器收到后正常解码，把请求路由到那个漏洞组件——攻击畅通无阻。

一个字符的 URL 编码，废掉了所有”只拦路径、不打补丁”的防御。Mandiant 的建议因此非常直接：WAF 规则和路径封堵不能替代打补丁；防御方必须假设攻击者会使用任何百分号编码、大小写混合或其他未标准化的路径变体。

这是安全领域最经典的教训之一，也是最容易心存侥幸的盲区：边界防御（WAF、封堵、访问控制）遮挡的是”已知路径”，而攻击者的自由度永远大于你列的规则清单。补丁修的是漏洞本身——那个”无论请求怎么写都不该执行的代码”——只有它才没有绕过问题。

三、Web Shell 持久化：”进来了”和”住下了”是两回事

报告确认的第二波攻击范围：全球数十个系统被部署了网页后门。理解这个词的分量，需要看 Mandiant 记录的完整攻击生命周期：

第一步，静默验证。攻击前，目标服务器通常会收到 5–15 个携带序列化 Java 对象的 POST 探测请求。未打补丁的服务器会正常响应（泄露主机操作系统信息），但不留文件、不破坏服务——攻击者悄悄确认”这台可以打”。很多组织日志里有这些请求，却没有任何后续动作，说明已被”踩点”但尚未被利用。

第二步，利用与种后门。通过 Java 反序列化漏洞执行代码后，攻击者在 PSEMHUB 的应用目录里创建 JSP 文件——比如 x.jsp、tunnel.jsp 这类网页后门。此后任何人访问这个文件，就等于在服务器上执行任意命令。还有一个细节极具启发性：攻击者会连续发送多轮请求、创建连续编号的 JSP 文件，原因是目标可能使用了负载均衡——确保后端每一个节点都被种上后门，而不是只有被检查到的那一台。

第三步，横向移动与数据外传。从 web shell 出发，映射内网环境、执行横向移动脚本、窃取数据、回连 ShinyHunters 的泄露运营基础设施。

这正是我们此前反复强调的区分：攻击分为”进来”和”住下”两个阶段，后者危险得多。在《外贸网站被攻击了怎么办》那篇的 48 小时应急剧本里，我们写过为什么慌乱中删除文件是错的、为什么要在全新环境中用确认干净的备份恢复、为什么要排查定时任务里的自重装后门——这次的 PeopleSoft 案例就是”后门持久化”的教科书演示：x.jsp、tunnel.jsp 这类文件，加上已被读取的数据库连接串、集成凭据、云访问密钥，构成的是一套”即使你修好漏洞、攻击者照样回得来”的完整钥匙串。所以 Mandiant 的修复清单里，”轮换 PeopleSoft 服务账号可读的所有凭据”和”部署 web shell 的补丁”是并列的必做项——只打补丁不清钥匙串，等于换了门锁但小偷还留着钥匙。

四、给外贸企业的四个教训

教训一：WAF 不是补丁的替代品。这是本次事件里最贵的学费——数十个组织以为自己”已经防住了”，实际只是把漏洞藏在了规则后面。映射到外贸企业的日常：网站套了 CDN 和防火墙规则，不代表后台漏洞可以不修；”我封了那个路径”永远不等于”漏洞不存在了”。补丁是唯一的根修复，边界规则只是争取打补丁时间的缓冲垫。

教训二：管理端点不该暴露在公网上。PSEMHUB 是一个环境管理组件——它本该是内网管理功能，暴露在互联网上就是攻击面。对照外贸企业自己的系统：网站后台的 admin 路径、旧 ERP 的管理页、测试环境、被遗忘的旧系统子域名——这些”管理入口”暴露在公网的每一个，都是你自己的 PSEMHUB。该关的关、该限 IP 的限 IP、该下线的下线。

教训三：确认过”被踩点”，就要按持久化入侵对待。日志里发现探测请求（哪怕没有后续动作），就说明你在攻击者的目标清单上，且漏洞已确认可利用——此时该做的不是松一口气说”还好没被打”，而是立即补丁、排查后门特征、轮换凭据。ShinyHunters 的”验证后暂不利用”不是仁慈，是节奏管理。

教训四：三个月的补丁拖延，亲手把零日变成 N 日。6 月 10 日 Oracle 就发布了补丁，9 月的攻击者主打的恰恰是”通报了三个月还没打补丁”的组织。企业级系统的补丁管理拖拉是普遍现实——但这次事件证明了拖延的代价曲线：攻击者会研读防御指导，专挑补丁缺口下刀。对承载询盘、客户数据、订单流程的外贸业务系统而言，安全补丁应该进入最高优先级队列，而不是”下次维护窗口再说”。

五、把 PeopleSoft 的排查逻辑迁移到你自己的系统

Mandiant 给 PeopleSoft 用户的排查清单，逻辑可以完整迁移到外贸企业的任何业务系统（询盘系统、CRM、邮件系统、ERP）：第一，翻访问日志，找针对可疑路径的异常 POST 请求和编码变体——重点看来自外部 IP 的请求；第二，检查应用目录里有没有不属于产品自带的文件——尤其是 .jsp/.php 这类可执行脚本文件和来历不明的可执行程序；第三，轮换应用服务账号能读到的所有凭据——数据库连接串、第三方集成凭据、云访问密钥，一个都不留；第四，如果用了负载均衡，检查每一个后端节点，不是只查报警的那台；第五，监控这些主机的出站流量，排查异常的远控工具进程。完整版应急流程，参考此前那篇 48 小时应急剧本：隔离不删除、全凭据轮换、全新环境恢复、修补入口、处理搜索引擎红旗。

写在最后

FBI 的招聘门户都能因为一套企业级软件的漏洞被敲开，这件事说明的不是”Oracle 不行”，而是三个条件的组合杀伤力：企业级系统 + 补丁拖延 + “边界已经挡住了”的错觉——这个组合面前，谁的身份都不构成豁免。外贸企业的询盘系统、CRM、邮件系统、旧 ERP，大多数和 PeopleSoft 一样是”承载核心业务数据、却常年排不上补丁优先级”的系统。

这条情报的合理读法不是恐慌，是动作：今天就把”哪些系统暴露在公网、各自跑什么版本、最近一次打补丁是什么时候”列成一张清单。安全投入的回报从来不是”没被打”的侥幸，而是像这篇报道里的组织一样——别人在两周内被同一招扫倒时，你不在名单上。