五台敞开的服务器，暴露了 PeopleSoft 零日漏洞如何一路走到数据勒索

1 行动之所以现形，是因为五台服务器忘了关门

2026 年 6 月 9 日，五个相邻公网地址像一间忘了锁门的工作室。每台主机都在 8888 端口开放 Python SimpleHTTP 目录，列表里躺着改装过的远程管理 Agent、行动文件，以及本该只属于操作者的 shell 历史。此前，受害方只能从 web 请求、新进程和数据异动看到攻击的一角；这一次，行动者自己的工作记忆露了出来。

目录没有交出全部受害者和每一道命令，却彻底改变了公开证据的质量。文件名可以和哈希对应，Agent 内置的管理地址可以直接读取，操作顺序也有迹可循。五台服务器还留着同一份命令历史，使基础设施搭建、内部侦察、横向传播、压缩数据，以及最后那条通往 ShinyHunters 泄露基础设施的外连，第一次能被放进同一张案卷。

这次意外暴露让整段故事始终贴着实物推进。Oracle 公告确认 PeopleSoft 更新环境管理组件存在未授权、网络可达的接管漏洞；Mandiant 与 GTIG 补上真实行动；开放目录提供作业细节；固定版本 MeshCentral 和 OpenJDK 源码解释两个后续机制。每份来源回答自己的问题，日期、哈希、路径、进程或函数彼此咬合时，它们才构成同一条证据链。

1.1 代码与处置图：Oracle 关闭入口，响应团队清除入口之后留下的整条控制链

1.2 一份命令历史，把散落文件排成了完整事件

暂存地址从 142.11.200.186 连到 142.11.200.190。防火墙报表里，连续地址很容易被压成一个网段；取证时，每个地址仍是独立主机，拥有自己的供应商记录、文件系统与网络历史。每次下载和会话都要保留准确地址与端口，否则过早合并会遮住谁提供了二进制、谁接收 Agent、又是谁发起最后一条外连。采集清单还要逐台写明首次观察、最后观察、服务商归属、响应头和本地时钟；其中一台缺日志时，不能拿相邻地址的记录补成它的经历。连续编号说明部署上的邻近，不会让五套证据自动变成同一台机器。

五台机器上的 .bash_history 完全相同，这是一条强证据，也有明确限度。它支持共用镜像、同步家目录、复制文件或重复部署流程，却不能证明操作者在五台服务器上逐字敲过同样命令。GTIG 公布的哈希 2ab684d93c1553fad87041b4dea97188a97e78589deee2a7bacff905564f3a35 让后续镜像可以精确比对，周边文件元数据则用来判断副本何时、怎样到达每台主机。

历史记录显示，5 月 27 日 22:14 UTC 安装 MeshCentral 1.1.59；十一分钟后的 22:25，又安装 npm 包 acme-client，用于给 azurenetfiles.net 自动申请证书。两个时间点描述了管理服务与 TLS 身份的准备，距离 Oracle 公告还有近两周，也给证书透明度、DNS、服务商、软件包和进程日志划出可回查的起点。

5 月 29 日 18:46 UTC，历史里出现一条查询全局 npm 包的命令，目标名称以 authenticode 开头。GTIG 没有替它强行选定用途：相应包可能用于签名，也可能只检查文件元数据。命令能证明操作者关心这种工具，却不能证明签名已经发生。要再往前一步，还需恢复包清单、npm 缓存、shell 输出、签名事件或真正带签名的二进制。对二进制的验证要记录签名者、证书链、摘要算法、签名时间和校验结果，并同暂存文件哈希精确对应；只看到 Windows 属性页出现发布者名称还不够。若包曾安装又删除，npm lock、缓存 tarball、审计日志和文件系统 journal 仍可能说明具体版本及使用窗口。

目录里有三个预配置 Windows Agent：meshagent32-azure-ops.exe、meshagent64-azure-ops.exe 和 meshagent64-v2.exe。名字借 Azure 运维词汇伪装，静态配置却指向 wss://azurenetfiles.net:443/agent.ashx。另一个 Linux meshagent 没带同样配置，GTIG 因而判断部署参数可能从命令行传入。Windows 追查可同时用哈希与管理端字符串，Linux 还要查参数和服务配置。

同一份历史随后出现 meshctrl.js 命令、PeopleSoft 配置读取、为特定受害环境编写 fanout 脚本、核对勒索留言、压缩归档，以及连接 176.120.22.24 的 SSH 会话。有些行自带时间，有些没有。顺序仍有意义，却不能给每个动作擅自补上分钟级时间；软件包日志、文件时间、服务商流量与目标端遥测必须替缺失时钟作证。

目录曝光之前，Google 已开始通知一百多家机构：这些机构的公网 IP 与疑似易受攻击的 PeopleSoft 端点相关。这是一组根据暴露信号形成的通知对象，并非受害者总数。服务可能应答探测，却已经修补、被未知控制挡住、无人使用，或刚由所有者封锁；反过来，某台主机也可能经后来不再可见的路线遭到入侵。通知登记应同时保存“机构数、地址数、端点数、已回应数、完成验证数”，因为一所机构可能拥有多套地址，一套入口也可能服务多个域。只有本地日志、主机效果或数据证据出现后，记录才进入相应的入侵状态，外部探测本身不替所有者作结论。

被通知机构中，68% 来自高等教育。这个比例只属于“暴露并收到通知”的集合，不能改写成全球高校部署率，也不能当作入侵率。集中度仍然值得重视：高校常同时拥有长期运行的企业应用、分散管理、合作伙伴入口，以及身份、科研、财务和学生数据。一旦入口出现，找到真正负责人和确认公网路线往往比普通资产更费时间。

Mandiant 报告，有些机构及时封锁或完成修复；另一些遭到入侵，之后还在 ShinyHunters 泄露站看见被盗资料。事件记录必须把这些结果分开：暴露但未受影响、尝试利用、确认利用、建立远程控制、访问数据、传出数据、公开数据，每一步含义都不同。省掉中间状态，会把一次有价值的通知行动误写成不准确的受害名单。

已观察行动从 5 月 27 日延续到 6 月 9 日，Oracle 首版警报在 6 月 10 日发布，因此最早利用发生在供应商公开之前，构成本轮行动中的零日利用。时间线没有告诉我们行动者何时最初发现漏洞、暂存搭建前侦察了多久，也不能证明每个请求都使用完全相同的载荷；它至少排除了“最早受害者只是没及时打公开补丁”这种解释。

6 月 9 日，公开威胁报告指出这些开放目录，GTIG 才得以详细整理五台主机。同一天也出现在另一条时间线上：被盗机构数据登上 ShinyHunters 泄露站。若再叠加暂存历史最后的 SSH 目的地，时间接近会增强运行联系；但时钟偏差、公开前准备，以及从未暴露的其他基础设施仍要保留在分析里。

等目录被人看到时，行动早已穿过多个系统：公网 PeopleSoft、web 层、远程管理服务器、被管理 Agent、内部 SSH 目标、归档暂存区和泄露站基础设施。接下来的故事就沿着这些交接往前走：先看 Oracle 点名的维护组件，再跟随文件和正常管理功能，观察一个暴露服务怎样逐步长成更广的数据勒索行动。

2 一项维护服务，成了事件里的第一个房间

PeopleSoft 环境管理框架本来就用于帮助管理员发现和管理支撑应用的各类系统，因此受影响组件能看到环境里的关键部分并不意外。这也说明，它不能像普通员工页面那样对待。能够触及配置、元数据和应用基础设施的维护入口，一旦暴露，代价远高于日常交易使用的浏览器界面。

在这轮行动里，活动与环境管理 Hub 应用及 PeopleSoft Integration Gateway 的 HTTP Listening Connector 对得上。Mandiant 建议追查来自外部的 POST /PSEMHUB/hub 与 POST /PSIGW/HttpListeningConnector。两个路径是重要支点，证据却要再往前一层：究竟哪台公网监听器、代理规则、虚拟主机、负载均衡器或合作伙伴路线，让不可信请求抵达这里。

第一个安全判断因而属于架构。某版本存在漏洞，不等于这套实例一定能经行动所需路径访问；反过来，资产看板标成“内网”的实例，也可能被隐藏代理路线暴露。补丁状态、部署模式、应用运行状态，以及所有通往管理路径的网络路线必须合并核验，任何一个字段都不能独自给出完整答案。

2.1 Oracle 确认接管条件，真实行动补上路径与时间

Oracle 6 月 10 日警报把 CVE-2026-35273 定位在 PeopleSoft Enterprise PeopleTools 的“Updates Environment Management”组件，受支持且确认受影响的是 8.61 与 8.62。风险矩阵说明：漏洞经 HTTP 可达，无须身份验证和用户交互，攻击复杂度低，对机密性、完整性与可用性都可造成完全影响。文字版矩阵直接把成功结果称为接管 PeopleTools。

CVSS 3.1 向量是 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H，基础分 9.8。分数描述受影响产品的一般利用条件，却不会告诉所有者：PSEMHUB 是否启用、反向代理是否转发、每个节点是否已经安装官方修复，或入侵是否早已发生。这些都要回到部署与事件证据。

Oracle 还特别说明，停止支持的更早版本没有接受此次漏洞测试，但很可能同样受影响。这句话堵住了一个常见误区：未出现在受支持版本表里，不代表供应商确认安全。这些旧版 PeopleTools 需要升级到能够取得官方缓解与修复的受支持版本；升级完成前，应按存在风险处理暴露和历史追查，同时不能声称 Oracle 测过它没有测试的版本。

机器可读 CSAF 把 PeopleTools 8.61 与 8.62 标成已知受影响产品，列出 Oracle bug ID 39522949，重复接管结论和 CVSS 向量，并把有效支持合同客户引向供应商修复。它在 6 月 10 日以 final 状态发布；这里的 final 只描述公告状态，不能替任何本地服务器证明补丁已经安装。

六天后，Oracle 六月关键安全补丁更新说明，PeopleSoft PeopleTools 与 Enterprise Applications 的本次更新已经包含该警报修复及其他补丁。这样形成两个供应商里程碑：6 月 10 日的带外警报，与 6 月 16 日的集中更新。变更记录要保存具体安装包、节点、时间和安装后验证；若失败后重新执行，还要分别保留每次结果。只有一句“六月补丁已打”不足以还原事件。

Mandiant 在 5 月 27 日至 6 月 9 日观察到与 PSEMHUB 端点及本漏洞利用一致的活动。事件报告提供了供应商矩阵不负责描述的披露前时间和作业语境，却没有公开完整漏洞载荷或 PeopleSoft 私有代码改动。因此，复现式断言应止于公开证据能覆盖的部分：未授权 RCE、端点吻合、已观察后续行为和 Oracle 修复。

第二条路径 /PSIGW/HttpListeningConnector 需要单独查看请求。Mandiant 建议在请求头或参数中寻找 127.0.0.1、localhost、::1 和内部地址段，因为服务端请求行为可能触及外部客户端无法直达的服务。应按政策保存完整请求、可信代理解析结果、响应和关联 ID；只留归一化 URI，可能恰好丢掉决定性的目标值。重复参数、大小写变化、百分号编码、IPv6 表达和代理附加的头部都要原样留存，再另做规范化副本供检索。分析人员还需区分客户端实际提交值与网关重写值，否则一次代理转换就可能把目标地址的来源归错。

2.2 端点是否可达，是配置事实，不是版本标签

可达性常藏在架构背后。外部扫描可能只看到普通 PeopleSoft 登录页，路径代理却在暗中转发 PSEMHUB；所谓“私有”应用也可能经 VPN 地址池、合作伙伴隧道、云入口、备用主机名或错误负载均衡规则抵达。验证时先枚举监听器和路由，再从获批外部位置测试准确管理路径。资产清单与 DNS 是线索，不是最终证明。

部署模式决定紧急缓解怎么做。Mandiant 转述 Oracle 建议：多服务器配置中关闭 Environment Management Hub 服务，单服务器配置中移除 PSEMHUB 应用。这个区别避免管理员把某种停服脚本硬套到另一种打包方式。行动前应确认 PIA 域、托管服务器、启动脚本、已部署应用、依赖关系和回滚方案。

若服务一时不能关闭，公开建议要求阻断外部访问 /PSEMHUB/* 与 /PSIGW/HttpListeningConnector。Mandiant 认为这不会影响标准用户 PIA 会话，因为它们服务于管理或系统间通信；本地集成仍需验证。确有业务用途的 Connector 应只允许明确来源系统和受认证路线，不能继续对整个互联网开放。

只靠 WAF 检查请求体，无法长期替代路径隔离。Mandiant 明确提醒，侧重正文内容的规则可能被绕过。路径级拒绝、移除监听器、停止服务或精确来源白名单，能减少进入脆弱代码的请求。WAF 日志依然珍贵，尤其是同时记录拦截与放行正文时；但“告警已开启”不能当成入口已经消失。变更记录应保存规则 ID、配置版本、生效节点、动作、命中样本和上游是否仍收到请求；同名规则在不同设备上可能处于观察、拦截或关闭状态。正文可能含凭据与个人信息，采集时还要套用访问控制和保留期限，既保住调查价值，也避免把敏感载荷复制到普通工单。

Oracle 风险矩阵约定，协议写 HTTP 时也包括安全变体。HTTPS 能防止传输途中被动窃听，却不会改变端点是否验证调用者、TLS 终止后是否安全处理内容。只搜明文 HTTP 监听器的资产查询会漏掉相关 HTTPS 部署；若反向代理终止 TLS，应用日志与边缘日志看到的来源、协议也可能不同。

入口消失，只回答新的未授权请求还能否进来，不能解释变更前发生过什么。只要有入侵可能，web 层文件系统、事务元数据、进程历史、外连、远程管理 Agent 与内部认证尝试都要先保全。下一章将从暴露端点走到这些主机效果，因为安静的边缘完全可能与一枚已经驻留的进程或文件同时存在。

3 第一条请求结束后，web 层仍可能替入侵续命

一条利用请求可能只存在不到一秒，留下的改变却能长期驻留。PeopleSoft web 层里，这种改变可能是塞进已部署应用的 JSP、事务目录里的二进制或脚本、用于暂存的异常子目录，也可能是某个可信 Java 进程稍后才读取的环境 XML。它们都会把调查范围从边缘日志延伸到主机，并在脆弱路由封锁后继续存在。

Mandiant 给出了具体位置：已部署 PSEMHUB.war 目录、envmetadata/transactions、异常的 logs、persistantstorage 或 scratchpad，以及 envmetadata/data/environment 下近期新建或修改的 XML。报告还要求注意 TCP 445 外连。把它们拆成不同主机问题，比笼统喊一句“查 webshell”更有用。

XML 提示最容易被误读。公开报告描述的是一种持久化机会：构造过的环境元数据可在应用重启时经 XMLDecoder 处理。这属于初始访问之后。Oracle 公开警报没有说 XMLDecoder 就是 CVE-2026-35273 的根因，固定开源记录同样不包含 PeopleSoft 私有调用者。因此，Java 路径只能解释后续能力，不能顶替供应商尚未公开的漏洞成因。

3.1 JSP、事务目录和外连 SMB，各自讲着不同的事

web 应用复核从 <PS_CFG_HOME>/webserv/<domain>/applications/peoplesoft/PSEMHUB.war/ 开始。仅凭路径无法判定 JSP，因为供应商和客户都可能部署正常页面。应先用出厂应用、已装补丁、获批定制和部署记录建立基线，再查内容、哈希、所有者、大小或时间不符的文件，同时覆盖可能稍后展开到正式目录的暂存副本。

每个异常 JSP 都要连同上下文保存：创建与修改元数据、文件所有者和权限、适用时的备用数据流、相邻组件签名，以及 SHA-256。随后在 WebLogic 访问与应用日志里找它第一次被调用的时间，把服务线程或进程接到子进程和外连。文件写入后从未执行，与页面已经拉起命令，是两种不同影响状态。还要检查编译缓存、类加载和部署日志，因为源 JSP 被删除后，已经生成的类或仍在内存中的应用上下文可能继续工作。请求参数若因隐私政策无法保存，可留下受控哈希、长度和关联 ID，让响应团队仍能把调用与端点效果对齐。

集群部署会让比对更复杂。负载均衡可能把利用请求送到一台托管服务器，共享部署、同步步骤或管理员操作却把结果传给其他节点；也可能只有一台残留 JSP，所有同伴都没有。必须检查每个节点、挂载共享、部署暂存区和 PIA 域使用的备份。“集群干净”不能只凭响应健康检查的那台样本服务器。

envmetadata/transactions 可能留下 Environment Management 工作的输入、中间对象、归档、脚本或输出。Mandiant 建议寻找未授权目录、文件与二进制投放。清理前，按原路径、时间、权限、扩展属性和哈希递归采集；条件允许时再做卷或文件系统镜像。普通管理工具打开或移动对象，都可能改掉原本能给事件排序的元数据。时间解释还要注明文件系统和挂载语义：复制、解包、恢复快照或跨卷移动都可能重写部分时间。目录项、journal、应用日志和父进程共同支持排序，单个 mtime 只是一条观察；发现反常时间时先查操作来源，不能立刻把它叫作时间戳篡改。

外连 SMB 讲的是另一段故事。利用链可能迫使 PeopleSoft 主机访问外部 SMB 监听器，暴露 Windows 机器账号的 NetNTLM 挑战响应。TCP 445 防火墙记录只能按传感器能力证明尝试或流量，不能自动证明响应已被截获、破解、转发或使用。还需认证日志、数据包、目的端记录与后续账号活动逐级补齐。域控制器和目标服务器上的机器账号认证时间，可用来检验挑战响应之后是否出现新使用；若只有 SYN 或被阻断会话，结论就停在尝试。响应记录应明确传感器看到的是连接、握手、认证还是成功会话，避免同一告警在转述中不断升级。

3.2 XMLDecoder 会把对象描述一路变成可执行调用

Mandiant 建议检查 <docroot>/envmetadata/data/environment/ 下近期创建或修改的 XML，因为它可能在应用重启后经 XMLDecoder 执行。“重启后”给出了实用关联点：可疑写入可能一直休眠，直到可信服务初始化、读取元数据并制造新进程或文件效果。因此，重启和部署事件必须与文件创建排在一起，不能只留在可用性看板。

Java API 把 XMLDecoder 描述为 XMLEncoder 的配套类，读取用于创建 Java 对象的 XML 归档。这已经超出被动键值解析。固定 OpenJDK 版本中，readObject() 调用 parsingComplete()；若解析未结束，解码器就把输入交给 DocumentHandler.parse()。文档允许的元素词汇，随后决定会组装出哪些对象操作。

DocumentHandler.startElement() 接收每个 SAX 元素，按标签名找到相应 ElementHandler，创建处理器、传入属性，再启动元素。解码器支持的标签涵盖值、对象、方法、属性、数组和新实例等构造。这里完成了从原始 XML 语法到带类型操作图的转换；最终效果仍取决于输入能触及哪些元素、类、所有者和参数。

NewElementHandler 展示对象构造怎样落地：class 属性经文档所有者解析，参数值被收集，ConstructorFinder.findConstructor() 选出兼容构造器，处理器再调用 newInstance()。在正常归档里，这会恢复预期 Java 对象；面对来源不可信且表达能力很强的归档，同一机制也可能实例化应用开发者从未打算让外部写入者选择的类型。

object 与 void 等处理器还能组装 java.beans.Expression 或 statement，把目标、方法和参数放进去。求值最终走到 Statement.invoke()；固定源码按运行时类型选择方法或构造器，再调用 MethodUtil.invoke() 或 Constructor.newInstance()。所以解码输入能够携带行为：XML 元素不只是复制进字段，也能描述在可信 Java 进程里执行的调用。

这条开源调用路径只证明通用能力，不等于完整 PeopleSoft 持久化路径。公开记录没有给出负责定位环境 XML 的产品类、选择解码器的私有代码、每种拓扑下的服务身份，或事件里的构造 XML。本地调查可用栈、进程监控、类加载、文件访问和重启关联填补一部分；其余部分应明确写成不可得，不能凭想象补出私有调用链。

分析应在隔离环境里的保全副本上完成。不要把未知归档喂给生产 PeopleSoft 服务或普通 XMLDecoder，只为了“看看会怎样”。静态结构、哈希、类名与方法名，加上受控插桩，足以判断风险而无须重放行动者操作。官方修复与部署缓解仍是主线；临时过滤几个元素或删除一份 XML，无法覆盖其他写入路径、JSP 或已经安装的远程 Agent。

4 MeshCentral 把一台失陷服务器变成了管理平面

web 层 shell 适合打开入口，却往往噪声大，还依赖脆弱应用继续在线。暂存证据表明，行动者准备了更稳的东西：完整 MeshCentral 服务端，以及能把失陷系统纳入管理的 Agent。一旦 Agent 信任行动者的管理端，正常远程运维功能便可提供命令执行、结果回收、文件操作与持续控制，后续每一步都无须再穿过 PSEMHUB。

MeshCentral 是开源远程监控与管理平台，大量机构正常使用，单独出现没有恶意含义。本轮行动之所以成立，来自一组同时出现的事实：行动者控制的基础设施、Azure 风格伪装、内置 azurenetfiles.net 管理端、在失陷系统安装，以及命令历史里的 PeopleSoft 侦察和横向操作。同一产品若由获批管理员连接获批管理端，就是另一件事。

固定版本源码很重要，因为“远程命令”四个字太宽泛。1.1.59 版完整展示：命令行客户端如何序列化任务，服务端如何核验节点权限与连接状态，已认证 Agent 怎样接收，Agent 如何拉起平台 shell，结果又怎样回传。于是，同一项操作会在多个位置留下彼此独立、可以互证的记录。

4.1 1.1.59 版源码完整展示 RunCommand 怎样走到 shell

固定版本 meshctrl.js 在第 1753 行进入 runcommand 分支，计算 runAsUser 与 reply，随后发送 JSON：action 为 runcommands，还包括选定 node ID、命令类型、命令正文、response ID 和两个选项。CLI 不在自己所在机器执行命令，它向 MeshCentral 服务端提交一项经过认证的管理请求。复核日志时应保存整条 JSON、登录会话、服务器接收时间和 CLI 来源，不能只截取命令正文。response ID 用来把请求与回复配对，却未必在所有重启和租户间永久唯一，用户、域、节点与窄时间窗仍要共同参与关联。

服务端在 meshuser.js 进入 case 'runcommands'，校验节点数组、命令类型和域格式，再对每个目标调用 GetNodeWithRights()。所以任务在投递 Agent 之前，已经绑定到 MeshCentral 用户和已知节点记录。即使操作系统子进程最后以 Agent 服务账号运行，服务端日志与事件仍可能保留管理身份。

对于标准 shell、PowerShell 或 Bash，服务端检查 MESHRIGHT_REMOTECOMMAND 权限位，还把请求类型映射到目标平台：Windows Agent 接受命令提示符或 PowerShell，非 Windows Agent 使用 Unix 风格 shell 类型。这些是正常安全控制；在本事件里，它们之所以进入攻击路径，是因为行动者掌握自己管理服务器上的获权管理员账号。

校验通过后，服务端生成包含 action: runcommands、类型、命令、运行身份、结果选项与 response ID 的 Agent 消息。只有目标在线、存在 Agent 信息且 authenticated == 2 时才会发送。随后，服务端分发 runcommands 事件，写入用户、节点、命令、类型和运行身份；若仍有留存，这几乎就是操作者意图的直接记录。事件存在说明服务端接受并路由了任务，reply 缺失却有多种解释：未要求返回、Agent 断线、端点执行失败或日志过期。只有把服务端事件、Agent 会话和端点进程放在一起，才能区分“发出过”与“执行过”。

Agent 认证并非装饰。meshagent.js 的 processAgentSignature() 会核验绑定证书与 nonce 的签名，连接之后才进入已认证状态。正常管理中，这阻止任意端点冒充已管节点；本事件里，预配置 Agent 与行动者管理端建立了一条密码学上有效、业务上未授权的信任。认证成功只说明软件信任谁，不能替机构决定这个管理端是否合法。

Agent 的 agents/meshcore.js 在约第 1714 行接收 runcommands。已有命令子进程运行时，它会拒绝第二项任务；runAsUser 则区分 Agent 身份、用户优先或仅用户三种模式。这些细节会改变遥测：命令可能以服务身份或交互用户运行，仅用户模式失败时甚至不会出现子进程。服务端任务要同时与端点成功和缺失结果比对。端点侧还应保留父进程、访问令牌、登录 session、完整参数和标准输入来源；PowerShell 从标准输入接收正文时，普通进程命令行可能看不到实际操作。没有可见子进程只能说明当前传感器没捕获执行，不能反向删除服务端任务记录。

Windows 上，类型一拉起 cmd.exe，类型二启动无配置文件的 powershell.exe 并从标准输入读取；非 Windows 类型三启动 /bin/sh。Agent 收集标准输出和错误，写入命令与 exit，在启用 reply 时把结果送回。这条准确路径把管理任务、平台 shell 和可能返回的侦察内容连在一起。

5 最初那些命令，都在追问 PeopleSoft 是怎样拼起来的

Agent 准备好后，命令历史没有立刻出现戏剧化的破坏，先是一连串问题：这是什么主机、当前身份是谁、PeopleSoft 挂载点在哪里、进程调度配置里有哪些机器、WebLogic 还知道哪些域内节点。答案把一台失陷端点变成了系统地图，地图上是共用名称、存储、凭据与作业角色的应用节点。

这些命令都来自普通 Unix 工具，价值取决于它们查了什么文件和命名规则。一般进程清单对企业应用帮助有限；从 psappsrv.cfg 取出的地址、包含 ps_config 的 NFS 挂载，或 WebLogic 服务器条目，却能直接指出下一台应用节点及其关系。检测必须理解这种语境，因为全面阻断 grep、mount 或 cat 根本无法运行。

公开报告对命令历史中的受害方字符串和凭据做了遮盖，这是必要处理；留下来的结构仍足以制作防守分析：命令类别、源进程、父级 MeshAgent、目标文件、目录模式、输出位置和后续网络目的地。本地响应可以用自己的未脱敏日志，把每次读取接到随后 SSH 尝试，却无须在公开报告里泄露账号材料。

5.1 配置文件成了主机、挂载点与应用角色的地图

行动者通过 meshctrl.js 运行 hostname 与 id 之类简单检查，确认当前机器名、用户和组，以及 Agent 是否具备后续操作所需权限。在端点遥测里，它们只有放进上下文才有价值：父进程是未获批 MeshAgent，执行又紧跟新 Agent 连接。同样命令若来自管理员正常自动化，则十分常见。

进程调度拓扑来自 psappsrv.cfg。历史在 PeopleSoft 配置家目录中搜索 Address= 与 HostName=，还限制返回行数。这是有目标的发现：应用已经替行动者维护了同伴目录，无须盲扫整个地址空间。保存文件打开事件和可得的命令输出，再把发现地址与同一主机后续连接比较。返回行数被限制，意味着公开历史未必包含文件中所有节点；本地调查应检查完整配置及当时版本，并标记哪些名称真的出现在命令结果。若 MeshCentral 开启 reply，输出还可能只存在管理端事件库里，端点 shell 历史未必保留。

mount 查询按 psoft、ps_config 和 nfs 等名称过滤。挂载输出可能暴露共享配置家目录、应用二进制、批处理区域和数据交换路径，也会给出远端服务器。可写共享挂载还可能让一台主机的影响扩散到其他节点。卸载或重建客户端前，应记录来源、选项、相关进程、近期写入和服务端访问日志。每个共享路径还要确认服务端导出、客户端缓存和快照策略，因为一份文件可能从任一位置被恢复。若日志显示多个节点读取同一对象，应按读者分别判断影响，不能把一次共享写入机械计成多次投放。

本地 /etc/hosts 又提供了一份列表。行动者搜索与受害环境相关的命名模式，之后 fanout 脚本继续使用匹配主机。静态 hosts 文件常因团队更关注 DNS 而被忽略，却可能保存外部解析器永远看不到的应用别名。文件历史、配置管理和端点读取，可以还原失陷时究竟暴露了哪些名称。

WebLogic config.xml 从另一个角度描述应用域：视环境而定，它可能包含托管服务器、监听地址、集群、部署、数据源及其他关系。公开报告确认行动者检查这些文件来绘制应用服务器，却没有披露所有取值。本地案件应把它当作敏感配置，比较 MeshAgent 子 shell 的访问与正常管理工具的访问。

几份来源叠在一起，才形成图谱：psappsrv.cfg 给出调度主机，mount 输出给出存储关系，/etc/hosts 给出本地别名，WebLogic 配置补充应用角色。这张图还可以反向套在连接日志上——某主机先在配置读取里出现，几分钟后收到 SSH，联系显然强于同一天里两条互不相干的记录。

5.2 fanout 脚本把这张地图变成了一轮轮 SSH 尝试

当历史在 /tmp 里写入 [victim_abbreviation]_fanout.sh，行动从画地图进入重复访问。GTIG 公布了脱敏脚本，因为它能解释横向模式：筛选主机、尝试固定凭据、把留言复制到 PeopleSoft 路径、统计结果，再搜索已经写入的文件。主机模式和基础目录都为一个具体环境定制。

目标来自 /etc/hosts：脚本按被遮盖的受害方模式或 csprd[0-9] 过滤主机名、去掉注释并排序去重，再循环尝试一组写死的常见管理与应用账号密码。公开报告遮盖了凭据取值，受影响环境的认证日志仍能给出用户名、来源、顺序与结果；即使没有登录成功，hosts 读取、脚本、shell 历史和成组 SSH 连接也会留下清晰残迹。

密码路径使用 sshpass，关闭严格主机密钥检查，并设置六秒连接超时；密码失败后，脚本再尝试当前用户的 key-based SSH。这些选择会留下鲜明组合：sshpass 进程、密集 SSH、被参数压掉的 known-host 行为、连续失败后的一次成功，以及可能调用既有私钥。EDR 与服务器认证日志应从两端接起来。源端的进程结束码只能说明客户端视角，目标端 sshd 才能确认用户名、认证方式、成功 session 和后续命令。六秒超时还会制造模糊失败：网络迟延、握手中断与密码拒绝在脚本摘要里可能看起来相同，分流时必须回到原始日志。

登录成功后，脚本检查环境基础目录下两个 web 服务目录和进程调度应用目录，把 README-IF-YOU-SEE-THIS-YOUVE-BEEN-HACKED.TXT 流式写入目标，并给本地副本设置 0644 权限。它记录成功、失败等状态，最后搜索全部留言，结果可能经 MeshCentral 返回；实际成功仍由端点和 SSH 日志决定。共享文件系统还能让一次写入出现在多台节点上，所以文件数量不能直接换算成成功会话数。

事件范围必须区分登录尝试、认证成功与完成写入。失败尝试要求检查密码和暴露，成功认证会把账号与目标主机纳入事件，留言写入则证明对应路径的文件控制。没有留言也不能清除主机：凭据可能先成功，后续命令才失败；文件可能被删，行动者也可能执行了别的任务。范围表最好以“源主机、目标主机、账号、认证方式、session、写入路径”为一行，分别标出尝试、成功和观察到的效果。这样同一账号在十台机器上的失败，不会遮住第十一台上的一次成功；共享挂载生成的多个文件也不会膨胀成多个登录。

fanout 脚本没有说明凭据列表最初来自哪里：可能是猜测、常见默认值、此前恢复的秘密，或配置里得到的信息。没有证据就不该替它选择一种故事。应轮换已成功使用或暴露给失陷上下文的凭据，撤销并更换相关 SSH key，检查信任文件与 authorized_keys，再按同一账号追查所有发现节点。帮助行动者移动的地图，也正是遏制所需地图。

6 留言宣告控制，归档文件提出了更难回答的问题

fanout 脚本把一份一眼就能看懂的文字放进应用目录，控制权因此变得喧闹、容易截图，也容易统计。更难处理的证据藏在同一份历史附近：名为 exfil 的目录、带进度测量的 Zstandard 压缩管道，以及一条连接 ShinyHunters 泄露站公网镜像地址的外发 SSH。

这些记录与 6 月 9 日公开的机构数据叠加，能够支持本轮行动存在数据窃取和勒索，却不能替每个本地环境回答全部影响问题。命令行会指出输入目录与输出归档，却未必列出每个文件；网络会话能给出目的地和字节，可能看不到明文；泄露站样本能证明一部分持有，也不能自动覆盖本地归档中的每个对象。本地影响表应按数据集分别列出来源系统、所有者、时间范围、记录类型、可达权限、观察到的读取、暂存副本、归档成员、外发证据和公开样本。某一列没有材料时保持空缺并说明传感器，不能把另一数据集的证明复制过来。

响应必须沿证据状态逐级上升：被选择、被读取、复制进暂存、装入归档、传出、被外部基础设施接收、最终公开。每一级来源和后果不同。勒索留言证明未授权写入，归档与外连决定数据损失判断，泄露公开又改变通知与法律分析。如果全部压成“已外传”三个字，就会丢掉受影响人员真正需要的精度。

6.1 Zstandard、SSH 与泄露站镜像，组成一条证据序列

开放历史先用 du -sb 计算 exfil 目录大小，将数值交给 pv 显示进度，再把内容通过三级、多线程 zstd 压成 exfil.tar.zst。命令清楚表明：操作者准备了一个命名收集区和输出归档，同时给出进程名、参数、可能工作目录，以及输入规模与输出活动之间的预期关系。

公开命令没有列出 exfil 里的成员，本地证据应当补上。保全目录树、归档、shell 历史、命令输出、文件读取遥测和删除记录。归档还在时，用不会向不安全位置解包的工具在取证副本上列元数据，并给容器和成员分别取哈希；归档被删后，journal、快照、备份、EDR 文件事件和源文件读取序列仍可能恢复选择范围。首次检查只读列出成员名、大小、时间、权限和链接目标，先处理绝对路径、上级目录跳转、设备文件与超大展开风险，再决定是否提取。所有派生清单都注明工具、参数和父归档哈希，防止后来把分析产物当成原始对象。

历史最后从暂存基础设施发起 SSH 到 176.120.22.24，GTIG 确认该地址托管 ShinyHunters 泄露站的 clearnet 镜像，这是很强的运行联系。应保留源主机、用户、目的地、密钥或密码方式、会话起止、字节、可得命令和服务商日志。公开材料没有给出数据包，不能声称已直接看见哪份归档穿过该会话。SSH 可以承载交互 shell、命令、SCP、SFTP 或端口转发，单有连接记录不能替它选择通道。若服务端或网络设备能提供 subsystem、通道类型、方向和字节计数，就把这些字段与归档创建时间并列，继续收紧传输判断。

6 月 9 日，被盗机构数据出现在 ShinyHunters 泄露站，说明行动者至少掌握展示或提供的材料，却不保证完整、新鲜，也不自动说明每个文件来源。负责的影响核验应在受控条件下比较名称、哈希、记录数、时间、schema 与样本，同时避免再次扩散被盗数据。只采集作出判断所需的最小材料，记录访问批准、时间、来源、工具和保存位置；截图若足够，就没有理由复制整套数据。样本匹配还要由数据所有者验证字段含义与权威记录，不能凭文件名或行动者写下的数字替受影响人员定案。

6.2 ShinyHunters 是归因判断，主机效果自有证据

UNC6240 是 Mandiant 的活动簇名称，报告把它映射到 ShinyHunters。这个命名依托情报团队掌握的其他材料，把 PeopleSoft 行动连到一名数据勒索行动者，却不会让每一次 MeshCentral 使用、每一次 PSEMHUB 探测，或每个叫 README 的文件都自动归于 ShinyHunters。本地分类仍从完整证据组合起步。

公开材料里最强的行动者联系来自运行层：暂存历史指向托管 ShinyHunters 泄露站镜像的 IP，被盗机构数据在行动期登上该站，fanout 脚本投放勒索留言，基础设施里又有与 PeopleSoft 行动相连的改装 Agent。多条线索互相增强，无须靠一个 logo、聊天记录或自称身份独自承担全部结论。

数据勒索模式会改变响应优先级。行动者可能迅速从入口走到收集，在访问早已建立后才留下响亮留言。恢复系统可用性无法解决影响；团队还要保全归档和外连、保护相关账号、判断哪些数据可见、协调被盗信息涉及的人，并持续观察后续公开或直接施压。

随着基础设施重新审查、其他人冒领，或私有证据公开，归因可能变化；主机事实应保持稳定：某请求抵达暴露路径，某文件出现，某 Agent 连接，某命令运行，某 SSH 登录成功，某归档生成，某批数据被公开。把它们独立保存，情报更新便可改进案件，而不会迫使响应团队重做基本遏制决定。

7 只有每只时钟都标明来源，案件才能严丝合缝

公开重建之所以可信，是因为多份记录指向同一方向；它们却不共享一只时钟。Oracle 有公告和补丁时间，开放 shell 历史有些命令带时戳、有些没有，PeopleSoft 访问、WebLogic、文件元数据、MeshCentral 任务、SSH 认证、归档、网络流和泄露公开又各记各的。分析人员越强迫它们排成光滑时间线，结果可能越失真。原始时间、时区和记录格式必须原样保留，再增加一个可检索的 UTC 归一化值；测得的偏差要附测量方法与有效期。无法测量时就写“偏差未知”，不能为了让图好看而移动事件，也不能覆盖来源自己的时钟。

先把案件做成互相连接的记录，再画故事线。每条记录都要有来源、原始时间和时区、已测时钟偏差、主机或服务标识、可得的身份、对象哈希和采集方法。案件主键保持不变，关系可以标成精确、强关联、可能或未决。这样叙事能随着新证据改进，原始材料却不会被悄悄重写。

目标不是消灭全部未知，而是把未知放在传感器真正停下的位置。代理 request ID 可证明边缘处理过请求，WebLogic 线程说明应用处理，文件事件说明写入，MeshCentral 任务说明命令，端点进程说明执行。一枚标识无法穿透所有系统时，多组较窄的连接仍能承载事件，前提是明确其置信度。

数据影响从能力开始，却不能停在能力。失陷 PeopleSoft 服务身份可能有权限读取大量应用数据，这说明潜在暴露；文件打开、数据库审计、批处理输出访问或命令结果才证明实际读取。范围先从权限画大，再按观察到的访问收紧，既不能假设所有可达数据都被收集，也不能把没有日志误解成绝无访问。

配置读取还需单列。psappsrv.cfg、WebLogic XML、hosts、挂载、密钥与服务设置可能没有多少受监管个人数据，却能显著帮助横向移动。它们会影响恢复，因为主机名、账号、集成端点和信任路线在原服务器重建后仍有价值。把它们称为“只是配置”，可能让新环境继续暴露在旧知识面前。

保留下来的 exfil 目录，比宽泛权限更能说明选择行为。成员树可能显示收集了哪些业务领域和日期；文件读取遥测还能区分行动者批量复制，与目录里本来就有的旧文件。所有者、mtime、ctime、源路径和命令上下文要合并查看，尤其当行动者借用了既有管理员工作区暂存数据时。

确认归档内容与创建后，可以证明打包，却还不能证明传输完成。外发流量、SSH 服务端日志、目的端服务商记录和外部持有证据，才把结论继续向前推。传感器只记到未知字节会话时就如实写；字节与归档高度吻合但内容加密时，也应写清关联及限度。精确措辞在通知中尤其重要。

泄露站公开对实际展示或可下载的材料构成强证据。应在受控条件下与本地 schema 和记录比较，写下哈希及取样方法。行动者宣称的记录数可能夸大、不完整，或混合多个系统。真正的记录所有者要用权威数据源核对受影响行与人员，调查团队则保存对方实际提供了什么。

最终案件台账应保留未决项及负责人、后果：代理正文缺失、WebLogic 日志过期、节点离线、归档已删、MeshCentral reply 未知、服务商记录不可得、凭据来源不明、泄露样本不完整。传感器从未存在时，“未知”不是失败；写清它影响哪项决定，以及什么证据能改变判断，它就会变成可执行工作。每项还应有复核日期、升级条件和关闭理由；证据留存到期前主动提醒负责人。若穷尽来源仍无答案，可以把调查动作关闭，但原问题仍标为不可确定，后续通知与风险决定就能看见这份缺口。

8 恢复从拆掉入口开始，到证明整条路线消失为止

恢复有四个彼此相连的目标：阻止新请求进入脆弱维护路径，清掉初始访问后建立的每个落脚点，让支撑横向移动的凭据和信任关系失效，并用证据解决数据影响。只打补丁会留下远程 Agent 和被盗秘密，只删 Agent 会留下入口；保全之前匆忙恢复服务，又可能抹掉通知所需记录。

顺序由证据的易失性决定。代理缓冲、进程内存、Agent session、开放套接字、shell 历史、临时归档与服务商日志可能很快消失，随后才是文件系统快照、配置导出和应用日志。遏制阶段关闭暴露路线与不可信外发，同时保留受控调查通道；官方修补、清理、凭据更新、重建和验证再由明确负责人推进。

这同时是 PeopleSoft 应用事件、远程管理事件、身份事件，也可能是数据事件。应用团队理解 PIA 拓扑与维护服务，端点和 Unix 团队掌握进程与 SSH，网络团队持有入口和出口，身份团队负责账号恢复，法务与隐私团队负责通知，供应商和服务商还可能保留缺失证据。共享案件记录可避免一条工作线宣布结束，另一条路线却仍敞开；案件负责人还应维护跨团队依赖表，写清每项封堵的前置条件、证据负责人和复测时间。

8.1 先保全，再封入口，最后重建信任

1. 先保全易失证据：导出边缘、PIA、WebLogic、认证、EDR、DNS、防火墙和流量记录，快照 web 层、PS_CFG_HOME、PSEMHUB、事务与环境元数据、临时目录、服务配置和挂载存储；安全且合规时，在停止 Java 或 MeshAgent 前保存进程与内存状态。
2. 隔离并限制外连：让受影响主机离开不可信网络，同时保留受控取证入口；封锁准确暂存地址、azurenetfiles.net 与 /agent.ashx，限制 PeopleSoft 节点外连 SMB，并复核异常 SSH。
3. 按拓扑关闭入口并安装修复：多服务器停用 EMHub，单服务器移除 PSEMHUB，阻断两条公开管理路径；逐台核对 PeopleTools 版本、补丁清单、实际加载版本、启动状态、监听器和外部测试，停止支持版本安排升级。
4. 保全后清除落脚点：移除异常 JSP、事务对象、环境 XML、脚本、归档、留言、启动项，以及未获批 MeshAgent、服务、配置、节点信任和安装包；合法 MeshCentral 环境按管理端身份与行动者基础设施分开。
5. 重建身份信任：重置成功认证或暴露给失陷上下文的账号，更换相关 SSH key，检查 authorized_keys，并在有读取证据时轮换 PeopleSoft、WebLogic、session 与 token；机器账号 NetNTLM 风险先按证据确认再处置。
6. 同步基础设施与数据响应：向服务商提交带 UTC 窗口和哈希的保全请求，再安排下线；同时确定归档与泄露样本涉及的数据集、所有者和证据状态，避免遏制动作先抹掉重建与通知所需记录。

8.2 真正关闭的事件，应经得住重启、完整工作周期和逐节点验收

重启本身就是验证环节，因为报告里的 XMLDecoder 持久化可能等待应用初始化。重启前给相关 XML 与启动配置建基线；重启时记录 Java 进程、读取文件、加载模块、子进程、网络和新文件；重启后再比对哈希与目录树。健康检查成功当然必要，却不能替代对“未授权行为没有回来”的观察。集群应按获批顺序逐节点重启，记录每台实际承接流量的时间，避免只观察未被请求命中的备用节点。发现异常时先保全新效果及触发输入，再按预定方案隔离或回滚，不能用连续重启冲掉刚出现的证据。

监控要继续覆盖完整作业周期。PeopleSoft 调度、集成、维护任务、备份和批处理可能数小时后才以另一身份激活。继续观察 MeshAgent 会话复现、新 JSP 或 XML 写入、外连 SMB、异常 SSH、归档创建和相关基础设施连接。窗口应覆盖组织真实日程，不能随意在恢复后一小时就结束。

从获批外部来源，针对所有地址、主机名、代理路线和协议变体重做暴露测试。管理路径应得到预定拒绝或不存在，正常 PIA 与明确获批的系统集成仍保持健康。保存请求与响应。看板上的“服务已停”远不如一次外部测试有力，因为备用监听器可能仍在转发。测试前记录解析器、DNS 结果、代理出口和 TLS 证书，防止缓存或分流把请求送往旧节点；测试后从服务端确认同一 request ID 是否抵达预期监听器。既要保存拒绝结果，也要保存合法集成成功样本，证明修复没有把业务可用性一起切断。

技术恢复同时完成数据评估：盘点保全的暂存目录与归档，比较读取事件和传输字节，核对任何泄露样本，找到数据所有者。分别记录哪些可达、哪些已访问、哪些已打包、哪些很可能离开、哪些已经公开。通知应按每组数据最强证据状态书写，也要承认日志缺失无法消除的空白。

验收条件要落到每台节点和每段信任关系：官方修复已装或组件已移除，不可信路线关闭，异常文件与 Agent 消失，启动状态获批，失陷账号与 key 更换，横向目标复核，服务商保全完成，数据决定有人负责，监控经得住重启。每项附查询、时间、覆盖范围和签字，也记录离线或退役资产例外。由未执行原变更的人抽查样本，确认查询能够重跑、证据仍可打开、失败结果没有被摘要丢掉。关闭日期还要早于关键日志到期日，为最后一次独立复核留下时间。

行动之所以成功，是因为它一路利用正常管理关系：维护端点、可信 Java 进程、远程管理 Agent、应用配置、SSH 和压缩。恢复则沿同一条路线反向走回来：关上维护入口，证明可信读取者只得到干净输入，切断未授权管理端，让地图里的凭据失效，查清归档去向，并让每个结论都可复现。做到这里，五台开放暂存服务器才真正成为结尾，而不只是故事最初被看见的地方。