🛡️NSOC（网络·安全·云一体化运营中心）
7×24 主动监控与专家值守，网络可用性 99.99%，安全事件 百分百全 闭环，云资源一站式管理
今日热点 Top 5
S1 一个备份应用被窃的凭据，在两个半小时里走进一百七十三个租户，全程零次多因素认证挑战
核心内容
十月十七日报道，攻击者滥用 ConnectWise Cloud Backup（原 SkyKick 备份）名下的一枚 Microsoft 365 凭据，未授权访问客户的 M365 环境。
这款云备份与恢复服务面向托管服务提供商，为保护客户的 Microsoft 365 或 Google Workspace 数据，在每一个安装它的租户里都被授予对邮件、OneDrive、SharePoint、Teams 与目录数据的广泛访问。
Huntress 观测到已确认的未授权登录涉及一百七十三个合作方与客户租户，十月十七日的数字比前一天多出十一个；
实际影响面更大，因为一个托管服务提供商的租户背后可以是几十家客户组织。
这枚凭据自十月十三日起被使用，十月十五日六时十三分至八时三十四分（UTC）是集中读取的窗口，共两个半小时，来源地址为 144.172.64.128。
攻击者按字典序遍历租户、每隔几秒换一个，说明手里有一份目标清单在跑脚本。
同一个地址在十月十三日与十四日还对四家律师事务所租户做过口令喷洒，但未观测到成功的用户登录。
Todyl 的分析显示，登录继承了该应用既有的授权范围：对邮件与附件的读写（经 Exchange Web Services 拿到完整邮箱访问）、OneDrive 与 SharePoint 文件、Teams 聊天，还包括恢复数据的能力。
关键在于全程零次多因素认证挑战：服务主体登录鉴的是应用身份而非人类账号，条件访问策略在此不生效；
撤销用户会话也结束不了这份访问，在租户里停用该应用只能阻止新令牌签发，已签发的令牌在失效前依然可用（有分析给出上限为九十分钟）。
至少在一个合作方租户里，Cloud Management 的 Teams 应用把自己加进了全局管理员角色，随后运行一个 Python 脚本（其 HTTP 请求头里的调用方标识为 Python-urllib/3.12）改动了租户内另外两个应用——一个托管服务管理应用，以及 Huntress 安全平台自身——给两者添加了新的客户端机密。
这两个应用都是受信任的特权工具：给托管管理应用加凭据可以把访问延伸到该托管服务提供商的全部客户租户，而给安全工具加凭据，等于拿到那个工具被允许做的一切。
这两条新机密在 ConnectWise 关停 Cloud Backup 之后依然有效，仍能换出新令牌。
Microsoft 表示正在跟踪一起活跃的供应链攻击，攻击者滥用了客户此前授予该应用的权限，其中包含目录读写全部这样的高特权范围，并观测到攻击者在目标租户里给服务主体追加凭据以维持直接访问。
ConnectWise 于十月十七日七时（UTC）停用了七个应用身份、吊销了相关证书、关停 Cloud Backup 应用访问，SaaS Security 与 Cloud Management 临时下线；
现有备份归档仍加密保存且未发现被访问证据，但备份计划与恢复功能暂停。
排查入口在 Entra 管理中心的监视、登录日志、服务主体登录页签，按应用编号过滤，默认的用户登录页签看不到这些记录。
ConnectWiseSkyKickOAuth凭据M365供应链服务主体登录
为什么重要
多因素认证这一次不是被绕过，而是没有被问到。服务主体登录鉴的是应用身份，条件访问策略管不到它；以「我们已经上了多因素认证」为前提的清单，在这里一条都不生效。
被授予的是应用级的广泛授权，而这份授权对每一个安装了它的租户同时有效。一枚凭据的失手半径等于它的全部装机租户，不需要逐个攻破。
停用应用不等于收回访问。已签发的令牌在失效前依然可用，有分析给出上限为九十分钟；而在别处被追加的新客户端机密，在关停之后仍然有效。
攻击者把权限写进了别人的信任关系里。给托管管理应用与安全平台追加凭据，是把这条路径延伸到该托管服务提供商的客户租户，以及那个安全工具被允许做的一切。
目录读取这一类动作在 Microsoft Graph 上不留下审计痕迹。Huntress 因此建议不要等证据、现在就动手——这也是本周期反复出现的同一个形状。
顾问金句
这一起里被攻破的不是哪一个租户的边界，而是「把权限授给一个应用」这件事本身的默认前提。
建议企业做五件事。
首先，把服务主体登录切成一条独立的排查入口：Entra 管理中心的登录日志要切到服务主体登录页签、按应用编号过滤，默认的用户登录页签根本看不到这些记录；
没有这一步，台账上会是零。
其次，把委派出去的授权做一次清点：哪些第三方应用持有对邮件、文件、目录的读写，其中哪些是长期有效的，哪些已经没人用了；
这一枚凭据之所以厉害，是因为它在每一个安装它的租户里都被授予了广泛访问。
再者，把「停用」与「失效」分成两件事：停用应用只阻止新令牌签发，已签发的令牌在失效前依然可用，而在别处被追加的客户端机密在关停之后仍然有效，因此要另行吊销与轮换。
而后，把追加凭据本身当作一类要监控的动作：审计日志里出现某个应用把自己加进目录角色、或给别的应用写新机密，这类事件的优先级应高于任何一次异常登录。
另外，把备份与恢复类应用单独列进供应商风险清单：它为了干活必须拥有广泛访问，出了事影响的是全部客户租户，要问清对方的通知口径与恢复时间。
S2 远程支持设备的零日自八月末就在用，攻击者直奔设备里存的密凭据库，走时把日志一并删掉
核心内容
十月十五日协同披露、十月十六日被美国网络安全和基础设施安全局收进在野利用目录的 CVE-2026-102764，是 BeyondTrust 远程支持设备（原 Bomgar）上的一颗认证绕过缺陷，按 NVD 口径评九点三分。
缺陷出在产品的内部消息组件：它没有充分校验收到的消息来源，在特定条件下攻击者可以在这台设备上执行文件操作，进而通向完整失陷。
受影响的是二十六点二点三 及更早版本；
修复补丁 BT26-05-RS 覆盖二十四点三点一至二十六点二点三，低于二十四点三点一 的必须先升级才能打补丁。
特权远程访问产品与受影响的组件共用代码，厂方自测未找到利用路径，但出于谨慎同样发布了补丁并建议自托管客户立即打上。
时间线值得单独记：八月二十九日攻击者已利用这颗零日打进一台由 BeyondTrust 托管的实例与一台自托管设备；
九月二十七日另一家安全设备厂商的失陷消息公开，触发了厂方的狩猎；
九月二十八日厂方威胁狩猎团队发现那一例，二十七分钟内完成遏制，当晚产品安全团队复现出入路径；
九月三十日 Mandiant 确认自托管客户侧的发现；
十月八日补丁发布，十月九日云端实例全部自动打完；
十月十五日协同披露。
十月十六日进 KEV，联邦机构处置期限是十月十九日，也就是今天。
失陷后的动作指向很集中：提权到 root，尝试从设备自带的密凭据库里抽取口令、API 密钥与终端凭据，部署 BARECLAW 隧道工具进入内网，改写配置模板让站点服务账号获得免密 root，改动 Jump Item 与团队权限为管理员，窃取内部文档与应用系统资产清单，并删除系统、Web 服务器与应用的日志。
Mandiant 与 Google 威胁情报组把这个长期专打边界与远维设备的集群记为 ARMORY CASTLE（此前的跟踪编号为 UNC5221）。
厂方在客户打完补丁前暂缓公开技术细节。
截至十月十六日没有公开的概念验证代码。
两家都强调指标在不同受害者之间极少重复，因此要靠行为来查：来自住宅宽带或商业 VPN 的异常特权会话、Web 目录里不认识的可执行文件、Web 服务账号派生 shell、未经授权的账号与权限与会话策略变更，以及在同一会话内开始又结束的日志转发中断。
Mandiant 的判断很直接：把窗口期内任何暴露在互联网上、跑着受影响版本的设备，在复核完成前都当作已经失陷；
而升级并不能挽回此前的暴露。
CVE-2026-102764BeyondTrust远程支持零日在野KEV
为什么重要
KEV 上的日期标记的是公共时钟开始走的日子，不是攻击开始的日子。这颗零日从八月末就在用，到十月十五日才公开，中间隔了四十七天。
被打穿的是一道为了方便而开的门。远程支持设备存在的意义就是让人从外部进来，它的暴露面是设计出来的，不是疏忽。
进去之后头一件事是抽取密凭据库。这台设备为了方便而存着别人的口令、密钥与终端凭据，拿到它等于拿到它所连接的一切。
补丁覆盖不到此前的暴露。Mandiant 的原话是把窗口期内暴露在互联网上的设备在复核前当作已失陷，而升级并不挽回此前那段。
排查依据从文件换成了行为：异常特权会话、Web 服务账号派生 shell、同一会话内开始又结束的日志转发中断。这几项平时都不在巡检清单里。
顾问金句
这一颗要纠的不是补丁打得多快，而是「KEV 上的日期」被当成了攻击开始的日子。
建议企业做五件事。
首先，把狩猎窗口回推到八月二十九日而不是十月十五日：这颗零日从八月底就在用，按披露日往后查会稳定地漏掉前面四十七天。
其次，把密凭据库的抽取当作既定事实来处置：这台设备为了方便而存着别人的口令、API 密钥与终端凭据，失陷后要轮换的不是设备口令，而是它所连接的全部系统凭据。
再者，把「暂缓公开技术细节」读成一段窗口期而不是一段安全期：厂方是为了让客户先打完补丁才不公开，漏洞本身与在野利用都没有因此变慢。
而后，把日志转发中断单独做成一条检测项：攻击者删本地日志，痕迹特征是转发在同一会话内开始又结束，只有把设备日志实时外送到自己收不到的地方才看得见。
另外，把低于二十四点三点一 的设备单列：补丁装不上，只能先升级，而以「在维护合同里」为判据的清单回答不了它是否还在可打补丁的版本上。
A3 Web 防护系统自己的统计功能默认开启，一颗命令注入换来承载它的那台主机的 root，而补丁会擦掉痕迹
核心内容
十月十八日报道，日本 JPCERT/CC 与厂商 EG Secure Solutions 确认，SiteGuard Server Edition 这套基于主机的 Web 应用防护系统上的一颗操作系统命令注入缺陷已被在野利用，编号 CVE-2026-106931，按四点零版标准评八点五分（三点一版口径七点八分）。
缺陷落在产品的统计功能里，而这个功能默认开启。
日本漏洞备注通告把它定为严重并确认已有在野利用；
JPCERT/CC 同日发出紧急告警，指出该产品在日本部署广泛。
攻击者借精心构造的输入进入统计功能，命令交由操作系统执行，从而在这台运行防护系统的机器上拿到 root（Linux 与 FreeBSD）或 SYSTEM（Windows）。
受影响范围从二点二零 起：非 FreeBSD 的 Apache httpd、Nginx 与 IIS 版本在八点零更新五 之前，FreeBSD 的 Apache httpd 与 Nginx 版本在七点零更新六 之前；
IIS 的三点一零 至四点零更新四 不在受影响范围。
修复版本为八点零更新五（非 FreeBSD）与七点零更新六（FreeBSD）；
无法升级的可以打厂商提供的、替换统计处理文件的独立补丁，该补丁对已终止支持的版本同样提供。
JPCERT/CC 指出，关闭统计功能同样可以阻断这条攻击路径。
厂商声称该产品保护超过一百五十万个网站，其 WordPress 插件安装在约五十万个站点上。
两个时间差值得记：厂商九月二十九日先行通知了持有直接支持合同的客户，十月十四日才公开公告，中间隔了两周，没有直接支持合同的客户在那两周里没有任何正式通知，而公开时利用已经在进行。
另一条不寻常的指令来自厂商自己的公告：更新或打补丁可能擦掉入侵痕迹，因此管理员要先从 Web 管理界面的诊断信息里下载并留存诊断数据，再动手修复。
JPCERT/CC 建议受影响组织一边更新一边做失陷检查。
厂商没有公布攻击者身份、受影响机器数量，也没有说明初始访问是怎么拿到的。
CVE-2026-106931SiteGuardWeb防护默认开启在野利用
为什么重要
被打穿的是防护本身。这套系统装在被保护应用所在的那台机器上，为的是在流量到达应用之前拦住它；它的失陷不是绕过了边界，而是从边界内部跨过去。
统计功能默认开启。多数安装跑着它而并不知道，一份为可观测性设计的功能成了远程命令执行的入口；默认开启在防护设备上应当与对外暴露的服务同等看待。
补丁会擦掉痕迹，因此先取证再修复。在 root 级访问已经成立的情况下，急着打补丁会毁掉用来判断此前是否已被拖过一遍的证据。
两周的通知差。持有直接支持合同的客户九月二十九日就知道，其他人十月十四日才知道，而利用在两者之前已经开始。
基于主机的防护把风险集中在一台机器上。防护系统、数据库与应用同机，一处缺陷足以同时影响三者；这也是它与边缘托管形态的分界所在。
顾问金句
这一颗里被交出去的不是策略配置，而是承载策略的那台机器本身。
建议企业做五件事。
首先，把默认开启的功能当作暴露面来盘一遍：统计功能默认开启，多数安装跑着它而并不知道，凡是这台机器上不用的功能先关掉，能关掉的那部分就是可以拿掉的攻击面。
其次，把取证排在修复前面：厂商公告写明更新或补丁可能擦掉入侵痕迹，因此要先下载并留存诊断信息再动手；
顺序反了会得到一份「没有痕迹」的假结论。
再者，把失陷检查与更新排在同一次窗口里而不是分成两件事：JPCERT/CC 的建议是一边更新一边查，而在 root 级访问下，被拖过一遍的机器与只被扫过一遍的机器在日志上可能看不出差别。
而后，把基于主机的防护与边缘托管形态分开评估：前者看得见解密后的流量、不依赖第三方做 TLS 终止，代价是缺陷直接等于源站 root；
后者把缺陷留在服务商那一侧，代价是把 TLS 终止与一份流量副本交给第三方。
另外，把厂商的通知渠道列进依赖清单：这一次持有直接支持合同的客户早两周知道，而没有这类合同的组织连正式通知都没有。
A4 更新服务器每次只被改五到十分钟：厂商侧七月末已称整改完毕，中招机器上的计划任务还在每三小时跑一次
核心内容
十月十六日，Google 威胁情报组（GTIG）与 Mandiant、以及 ManageEngine 威胁分析实验室分别公开了对 AOMEI Backupper 更新基础设施的供应链篡改调查，把这种手法称为瞬时供应链篡改。
AOMEI Backupper 是 Windows 备份与磁盘克隆程序，厂商注册于中国香港；
它和同厂的远程桌面工具一样，由后台服务定期通过 HTTPS 向厂商服务器检查更新与推广弹窗。
驱动这次检查的是两个文件：一个指定要下载的更新包与用于校验的校验和，另一个告诉弹窗服务显示什么、运行什么。
程序对这两个文件都不做加密校验，而那个本应证明下载真实性的校验和，就写在同一份未签名的、指定包名的文件里。
程序本身没有被利用，没有漏洞，除了安装并运行之外不需要用户做任何事；
攻击者只要在服务器上把两个文本文件改几分钟。
GTIG 与 Mandiant 确认了三个篡改窗口：五月二十八日十时四十分至五十分（UTC）十分钟，七月十六日八时三十三分至八时三十九分六分钟，七月二十日十时三十五分至十时四十分五分钟；
实际发生的可能更多。
只有在窗口期内恰好来检查更新的副本会中招，窗口前后检查的都拿到干净文件，这正是它难以被发现的原因。
GTIG 判断投放是机会主义的，命中哪台取决于那几分钟谁来轮询。
从其遥测看，受影响组织集中在信息技术服务、电信与高等教育，分布在澳大利亚、巴西、印度、巴基斯坦、葡萄牙、新加坡、南非、西班牙、瑞士、土耳其与美国共十一个国家，报告未给出总数并称实际数字可能更高。
落地的载荷是一个叫 CROSSROAD 的下载器：它把组件包解到本地一个 Radmin 目录，创建每三小时运行一次的计划任务，然后把自己从磁盘上删掉。
包里带一份正规签名的 Radmin，ManageEngine 的实验室发现它被放置但从未启用，没有监听、没有配置、没有新账号；
远程控制来自另一个植入体——计划任务运行那个签名的 Radmin，它加载旁边一个攻击者构造的动态链接库，后者再加载 SHINYROAD 植入体，给出远程 shell 并可按命令拉取运行新代码。
它只与一个硬编码地址通信，没有备用，因此封掉那一个地址就能切断攻击者的控制。
CROSSROAD 只在部分地区运行：它检查机器位置，若在中国则停止，ManageEngine 补充说它发现主机上装有特定安全组件时也会停止。
通过检查的机器上，GTIG 后来看到第二套工具被推到 SHINYROAD 之上：开源 Adaptix C2 框架，伪装成 Nitro PDF 阅读器。
七月二十日那一次窗口里还有第二个花样，不需要运行任何程序：通知文件被改成弹一个不可见的一像素窗口，通过 WebDAV 指向攻击者服务器上的一个文件；
渲染这个窗口就可能让 Windows 把当前登录用户的 NetNTLMv2 响应发到攻击者地址，用户侧完全看不到。
时间线上，ManageEngine 实验室五月二十八日首次记录到活动（两家不相关客户机上装出了 Radmin），六月七日客户提出问题、实验室同日通知 AOMEI；
AOMEI 起初的说法是内容在传输中被截获篡改，实验室认为证据不支持这一解释——两台机器都经 HTTPS 从 AOMEI 自己的服务器取文件，跨国跨网，且程序是按正常更新步骤拉取的。
七月中其监测器当场抓到一次窗口，确认改动来自 AOMEI 一侧。
Mandiant 七月十七日通知 AOMEI 并共享指标，AOMEI 七月二十九日称已采取纠正措施加固服务器；
截至发表，实验室未独立确认失陷已被遏制。
两份报告都没有说明攻击者如何取得在 AOMEI 服务器上改文件的能力，AOMEI 十月九日发布的八点五点零 更新日志里也没有一条涉及更新校验方式的改动。
GTIG 把这个集群记为 UNC7017，未指认国家或已知组织，并称这是它遇到的头一个以如此短的时间间隔构建的 Windows 供应链失陷，「有效规避了传统时点式分诊与自动化文件扫描」。
处置建议是覆盖四月至七月的整个区间，且不要用「现在去厂商下载页看一眼」来判断——文件几分钟内就改回，那个页面几乎总是干净的，已经出现过真实告警被当成误报排除的情况。
供应链AOMEI瞬时篡改CROSSROADUNC7017
为什么重要
攻击窗口比任何一轮巡检的间隔都短。三个窗口分别是十分钟、六分钟、五分钟，而以某个时点的状态做验收的手段，在这三段里几乎必然采不到样。
校验和与它要校验的文件是同一份未签名文件。程序对更新配置不做加密校验，那个本应证明真实性的校验和就写在指定包名的那份文件里，改了它就等于同时改掉了判据。
厂商侧整改完毕不等于机器干净。下载器会建计划任务并把自己从磁盘上删掉，本地更新文件也会被还原成真实内容，因此中招机器与厂商下载页看起来都是正常的。
没有漏洞、没有用户动作。这是这一起与补丁类事件的本质差别：除了安装并运行，用户什么都不能做，也就没有什么可以提前防住。
它规避的正是时点式分诊。GTIG 的原话是有效规避传统时点式分诊与自动化文件扫描；以扫描结果与下载页现状为判据的流程，会稳定地把真实告警判成误报。
顾问金句
这一起要纠的不是「有没有打补丁」——这里根本没有补丁可打，要纠的是「我们凭什么相信下载到的东西」。
建议企业做五件事。
首先，把排查窗口拉到四月起而不是从发现那天起：三个篡改窗口全在五月到七月，而报告明确建议覆盖整个区间，按告警日期倒查会一段都看不到。
其次，把「厂商下载页现在干净」从判据里去掉：文件几分钟内就改回，那个页面几乎总是干净的，已经有分析团队据此把真实告警当成误报排除；
要看的是告警发生那一刻链路上实际取到的是什么。
再者，把计划任务与旁路加载做成常规检测项：查每三小时运行一次的任务、查程序目录里与签名程序并排放置的动态链接库、查从弹窗目录跑起来的程序，这三项都比文件哈希更早暴露问题。
而后，把出方向的服务器消息块与 WebDAV 流量一并收口：七月二十日那一次不需要运行任何程序，一个不可见的一像素窗口就可能把登录用户的响应凭证送到外部地址，封掉出方向 445 与对外 WebDAV 是直接有效的一道。
另外，把更新校验方式列进采购的验收项：这一起的根子是程序对更新配置不做加密校验，买的时候不问，出事之后没有可改的地方。
A5 AI 编程工具托管控制台里的第三方模型密钥被拿出来，用户收到的头一条异常提示来自模型厂商的账单
核心内容
十月十七日，开源 AI 编程智能体 OpenCode 的运营方 Anomaly Innovations 通报一起安全事件：一套正处于停用流程中的旧系统遭到未授权访问，保存在用户工作区里的第三方服务 API 密钥可能已经暴露，涉及 OpenAI、Anthropic 与 Google 等厂商的密钥。
运营方把事件描述为与大规模蒸馏攻击有关，受波及的是约百分之一点四的 OpenCode Console 用户，并已于当地时间十七日上午通过邮件通知全部受影响用户；
未收到邮件的用户不在影响范围内。
受影响的是在 Console 里绑定过外部模型服务密钥的部分用户，只在命令行本地运行、密钥存在本机配置文件里的用户不在此列。
运营方称目前无法确认这些密钥是否被恶意使用，初步调查也未发现其他数据泄露证据，正与 Anthropic、OpenAI 与 Google 协同处置，并已要求受影响用户到各服务商管理后台撤销并更换密钥、检查近期调用记录。
与此同时，多名用户报告的异常开销出现在官方通知之前：有人 Anthropic 账户产生四百美元未授权扣费，有人 Google 服务产生约二百欧元意外费用且相关项目因滥用被暂停；
还有用户在收到 OpenCode 通知之前，就先收到了 OpenAI 与 Anthropic 发来的异常使用提醒。
运营方今年还有过三条互不相关的安全通告（含一月的 CVE-2026-22812 与 CVE-2026-22813），但它们都不解释这次的凭据暴露，升级客户端并不能修复这件事，轮换密钥才是。
受影响账号数量、进入路径、未授权访问持续了多久、是否每一个存着的密钥都被取走，均未披露。
结构性的一点是：OpenCode 这样做并不特殊，几乎所有支持自带密钥的 AI 编程工具、智能体框架与聊天前端都把厂商密钥存在自己这里，每一处都成了这份密钥可能丢失的地方；
而一枚密钥通常带着账户的全部消费额度，可以从任何地址发起，能调用账户可及的每一个模型。
OpenCodeAPI密钥AI编程蒸馏攻击凭据轮换
为什么重要
头一个发现异常的是模型厂商的账单，不是工具方的告警。等账单说话，暴露窗口已经按小时算完。
蒸馏攻击改变了这份密钥的价值。它的目的不是免费用算力，而是把前沿模型的回答大量收集起来喂给自己的模型；持证机构的密钥因此更值钱，因为它看起来像一个正常团队在大量写代码。
升级客户端不修复这件事。运营方今年另外三条通告与这次凭据暴露无关，把它们混为一谈会得到一份已经处理完的错觉。
自带密钥这种用法把一份密钥复制到了每一个工具里。每一处都是它可能丢失的地方，而一枚密钥通常带着账户的全部消费额度与可及的全部模型。
影响范围是按绑定关系算的，不是按用户比例算的。百分之一点四 这个数字回答不了有多少枚企业密钥在列。
顾问金句
这一起里被交出去的不是代码，而是模型服务的钥匙，而发现丢了钥匙的是收账单的那一方。
建议企业做五件事。
首先，把「有没有人用过这类托管控制台」当成一个要回答的问题：问研发团队、查企业卡账单与报销记录、在各模型厂商后台搜名字里带工具名的密钥，三件事都做一遍才有答案。
其次，把轮换做在各厂商的管理后台而不是工具方：直接到模型厂商的控制台撤销并重新签发，不要跟着事件邮件里的链接走，这类事件发生后几小时内就会出现仿冒钓鱼。
再者，把调用记录的留存排在轮换之前：先导出调用记录再作废旧密钥，否则那段被用掉的记录会随着密钥一起消失，事后无法核对。
而后，把消费上限与告警在模型厂商一侧设硬：单枚密钥按项目与额度收窄，异常用量与陌生模型的调用直接触发告警，而不是等月底账单。
另外，把密钥的存放点做成一张清点表：自带密钥的用法会把同一枚密钥复制到每一个工具里，每一处都是它可能丢失的地方，轮换时找不到全部调用方才是真正的成本。
趋势分析
本周期五条热点讲的是同一件事：控制措施的验收对象是人，而这一批访问根本不以人的身份发生，也未必留下「发生过」这件事的记录。
ConnectWise Cloud Backup（原 SkyKick 备份）名下那枚被窃的 Microsoft 365 凭据，在十月十五日两个半小时里走进一百七十三个租户，全程零次多因素认证挑战——因为服务主体登录鉴的是应用身份而不是人，条件访问策略管不到它；
攻击者还把一个 ConnectWise 应用自己加进全局管理员角色，再给另外两个受信任应用（其中一个是安全厂商自己的平台）写下新的客户端机密，而这两条机密在 Cloud Backup 被关停之后依然能换出新令牌。
BeyondTrust 远程支持设备上那颗九点三分的认证绕过缺陷自八月末就被零日利用，攻击者进去之后直奔设备里存的密凭据库，走的时候把系统、Web 服务器与应用的日志一并删掉，厂方与 Mandiant 给出的排查依据里有一条是「日志转发在同一个会话内开始又结束」。
SiteGuard 这套 Web 防护系统的统计功能默认开启，一颗命令注入就能换来承载它的那台主机的 root，而厂商公告里写着一条反常的话：打补丁本身可能擦掉入侵痕迹，因此要先下载诊断信息。
AOMEI Backupper 的更新服务器每次只被改五到十分钟就还原，厂商侧七月末已称完成整改，可已经中招的机器上那个计划任务还在每三小时跑一次，而厂商下载页当下是干净的。
OpenCode Console 里存着的第三方模型 API 密钥被拿出来，厂商称之为大规模蒸馏攻击，而用户收到的头一条异常提示来自模型厂商的账单，不是来自 OpenCode。
把这五条放在一起，一句话说透：过去几天里被拿走的不是数据，而是「这段话发生过」的证据；
而多数企业的审计与验收，默认记录一定会产生。
