🛡️NSOC（网络·安全·云一体化运营中心）
7×24 主动监控与专家值守，网络可用性 99.99%，安全事件 百分百全 闭环，云资源一站式管理
今日热点 Top 5
S1 为堵一条路加的那道闸，成了关掉杀软的钥匙
核心内容
安全研究者 Abdelhamid Naceri（网名 Nightmare Eclipse）十一日公开一枚 Windows 提权零日，命名为 SignDrop，暂无 CVE、暂无补丁，PoC 已挂在公开仓库。
它滥用的正是微软二零二五年十月为防日志文件系统（CLFS）认证类攻击而引入的那道缓解机制本身：CLFS 新建日志文件时会一并创建名为 .cnpf 的认证文件，起头的访问检查是有效的，但若之后有另一个特权进程打开该日志文件，认证文件会以 SYSTEM 权限被创建并继承原文件的访问控制。
研究者把这一步接到可被诱导的特权进程上（例如自带防护的安全程序），于是一个普通用户可写的文件被抬成 SYSTEM 可写，PoC 直接给出 SYSTEM 命令解释器。
由于文件创建请求看起来来自安全程序自己的合法进程，各类终端防护方案的防篡改机制拦不住，反过来还可用来把防护关掉。
作者在 Windows 11 26H2、26H2 Experimental 与 Server 2025 Experimental 实测成功，估计约八成 Windows 装机在影响范围内；
自查项为注册表 CLFS 服务下 Authentication 的 Mode 值，取 0 或 1 应按受影响处置（有读者反馈取 3 表示该机制已被自动关闭）。
关闭该缓解不可取——那等于把设备退回到 CLFS 内存破坏类缺陷的暴露面里。
同一位研究者自四月以来已公开 BigDiskBuster、ShieldCrash、LegacyHive、RoguePlanet、BlueHammer 等十余枚零日，因不走私下报告，微软曾表示可能对造成实际危害的行为采取法律行动。
零日CLFS提权防篡改无补丁
为什么重要
缓解机制本身成了入口：为修认证问题而加的那道闸，一年后成为提权通道——防护加得越多，需要回头复核的清单就越长。
能把防护关掉：创建请求看起来来自安全程序自己的进程，防篡改在这种路径上失效，先关防护再干活的套路被打通。
零日到可用工具距离为零：无 CVE、无补丁，PoC 已公开，微软尚无修复时间表，中间没有公告期可以缓冲。
面铺得很宽：约八成 Windows 装机在范围内，办公终端、研发机与运维跳板机都在其中。
处置只能在两种风险之间选：关掉缓解就退回 CLFS 内存破坏风险，留着就等于保留提权通道，只能靠补偿控制争取时间。
顾问金句
这一起要纠的不是「又出一枚零日」，而是「我们习惯把厂商新加的缓解当成防护终点，从此不再回头看它」。
为堵 CLFS 认证问题加的那道闸，本身成了关掉杀软的钥匙——防护越加越多，复核的清单越欠越多，欠的那部分迟早要还。
建议企业做五件事。
首先，按注册表现状做一次全量自查：CLFS 服务下 Authentication 的 Mode 取 0 或 1 的终端按受影响登记，别只看有没有装某款防护。
其次，在无补丁窗口内先上补偿控制：只允许白名单程序从用户可写目录加载，把可被诱导的特权进程收敛到必要范围。
再者，把「关防护」这件事单独设监控：终端防护被停用、排除项被添加、服务被改名这三类事件必须越权告警，而不是等值班同事发现。
而后，对研究者已公开的其余零日做同一轮排查，这批缺陷共用同一份披露节奏。
另外，把这枚零日写进终端与跳板机的准入核查，运维通道上的机器优先级高于办公机。
S2 HTTP/2 的并发，把一个头部函数写成了满分缺陷
核心内容
Apache 基金会十一月十一日发布 2.4.71，修复 mod_http2 的 CVE-2026-119618：HTTP/2 允许客户端在单条连接上并发塞入大量请求，服务端调度多个工作线程并行处理，而 assign_headers() 缺少线程同步保护，工作线程经共享的无锁分配器直接往连接线程名下的内存块写头部，造成堆损坏，进而转化为以 Web 进程权限执行任意命令，无需认证与交互。
影响 2.4.55 至 2.4.70，独立模块 mod_h2 为 2.0.8 至 2.0.42。
Anthropic 的 OSS 扫描器于十月二十六日头一个上报（内部编号 ANT-2026-MAPKT6MZ），Google Cloud 漏洞研究团队的 Anthony Weems 与 Simon Scannell 于十一月三日独立发现同一缺陷。
Red Hat 按 9.8 记分并称已有公开研究演示了针对默认 mod_http2 配置的稳定利用；
Wiz 遥测显示约六成四的云环境存在受影响资源、其中约一半有公网可达实例，但强调尚未发现公开 PoC 与在野攻击，且只有经 Protocols 指令开启 h2 或 h2c 的节点受影响，纯 HTTP/1.1 不受波及。
watchTowr 的建议很直白：要么现在打上补丁，要么在能打之前先把 h2 关掉。
同批还修了 mod_md 的空指针解引用与 mod_vhost_alias 的低危覆盖问题。
ApacheCVE-2026-119618HTTP/2竞态满分
为什么重要
藏在默认层里：只要开了 h2，每个虚拟主机都带着这条竞态，而资产清单通常只写「已启用 HTTP/2」，不写具体版本。
向量完整：免认证、免交互、可达即可用，成功即以 Web 进程权限执行，前置条件只剩一个协议开关。
六成四的云环境有受影响资源：容器基础镜像、前置转发服务、接口网关的底座层层复制，一处不升就等于处处未升。
两家独立撞在同一处：自动化扫描与人工研究同时命中，说明这类并发缺陷可被批量找出来，同类问题不会只此一处。
这是本期少数能当天闭环的事：升 2.4.71 或关 h2，动作单一、代价明确、不需要等厂商排期。
顾问金句
这一起要纠的不是「Apache 又发了个满分」，而是「我们清单上的 Web 服务只记了开没开功能，没记跑的是哪个版本」。
HTTP/2 是默认层里的一层，平时谁也不看它，出问题时它比任何业务应用都靠下——越靠下的东西，越没人给它编版本号。
建议企业做五件事。
首先，按实例导出 Apache 版本与 Protocols 配置，把开了 h2 或 h2c 的全部单独列出来，别混在「Web 服务」这一栏里。
其次，能升的排进本周窗口升到 2.4.71，含容器基础镜像与自制镜像的底座一起重建，别只升宿主机上那一份。
再者，短期升不动的先把 h2 关掉退回 HTTP/1.1，用性能换时间，这个代价是明确可算的。
而后，把 mod_h2 独立部署的分支单独核对，2.0.8 至 2.0.42 全部在范围内。
另外，给边缘与接口网关加一条版本核查项，让「开了什么协议、跑的哪个版本」成为上线验收的一部分。
S3 九十分钟，四十八家机构，一块没人设过密码的面板
核心内容
Huntress 与 Blackpoint 先后确认一起针对托管服务商的活跃攻击：攻击者取得云托管 ScreenConnect 环境的未授权访问后，用平台的 Run Command 远程命令功能，向客户终端批量下发未经授权的远控客户端。
至少 48 家机构、288 台终端受影响，其中含 6 家以上托管服务商；
全部设备在 90 分钟内被打，约三分之一在前 10 分钟内中招。
入口锁定第三方扩展 RMM+ 的 1.0.31 与 1.0.32：该扩展的设计是让外部自动化工具免登录操作会话，它跳过原生账号、权限角色与多因素校验，只认配置项 RMMPlus.AccessKey；
而这两个版本里该参数默认为空，校验逻辑又不拦空值。
管理员装完扩展忘了填密钥，攻击者发一个空口令请求就能以 SYSTEM 权限批量下指令，控制台里不留任何登录记录。
ConnectWise 于十一日澄清核心代码与官方云基础设施均未被攻破，并已在约 400 个合作伙伴环境停用 5 款关联扩展。
后续载荷 SCKit 由 16 个脚本与组件构成：安装第二个客户端连回攻击者服务器、给系统自带防护加排除项、用 TrapWatch 计划任务顶掉真正的客户端，再等技术人员连上受感染设备，窃取浏览器里的会话凭据去接管其已认证会话，并借 Shared Toolbox 这类正常功能继续分发。
代码注释异常详尽，Huntress 与 Blackpoint 均判断由大语言模型生成，但两家都未观察到蠕虫式横向成功。
ScreenConnectRMM+SCKit托管服务空密钥
为什么重要
入口不是主程序：核心代码没被攻破，出事的是一个「为方便自动化而跳过认证」的扩展——扩展清单通常不在补丁流程里。
空值即通行证：默认空密钥加上不拦空值的校验，等于把面板挂在没有口令的状态，还顺手绕开了多因素。
九十与四百：90 分钟打到 48 家机构，厂商在 400 个环境批量停用扩展——影响面按托管关系成倍放大。
反过来伏击技术人员：等工程师连上来再动手，偷会话凭据接管其权限，等于把运维动作本身变成了投递路径。
处置要避开那条通道：两家厂商都建议不要经这块面板去连可疑机器，改用终端检测响应的实时响应或其他独立通道。
顾问金句
这一起要纠的不是「ScreenConnect 有洞」，而是「我们把运维面板当内部工具，从没按对门的标准查过它上面装了什么」。
主程序是干净的，坏的是那个为了省一次登录而默认留空密钥的扩展——省下来的那一次登录，末了要拿几百台终端去还。
建议企业做五件事。
首先，清点全部运维面板上安装的扩展与集成件，逐个核对默认值与密钥是否真的填过，空值一律停用。
其次，把面板从「可信内部」重新归类：按对门标准收敛可达范围，关掉免登录的自动化入口。
再者，回查 Run Command 与 Toolbox 的历史记录，找没人发起过的任务，同步检查异常客户端标识与管理会话。
而后，撤销全部活跃管理会话，从一台干净设备上轮换凭据，别在疑似受感染的终端上做交互式会话。
另外，把「不要从面板连可疑机器」写成处置手册的头一条，替代动作提前演练一遍。
A4 一百 GB，来自四年前并购进来的那套系统
核心内容
马士基十一日确认发生数据外泄：未经授权一方进入并取走了一家此前收购公司所运营的历史本地系统内的数据。
公司称现有调查强烈表明敏感数据尚未被公开，事件局限于该系统，经接口与电子数据交换接入的客户及伙伴系统未受影响，订舱等业务照常。
据 BleepingComputer 报道，自称 WhiteArmor 的团伙已在其泄露站点挂出马士基，索要 500 万美元比特币、限期 30 天，并称握有约 100 GB 数据：近 3 万条司机记录、明文存储的口令、33 个超级管理员账号、已签署的签收单、14.44 万条含采购订单与预先发货通知的库存记录，以及 27,842 条含手机号、邮箱与设备识别码的移动设备日志。
上述规模均为该团伙单方面说法，马士基尚未证实，也未确认收到勒索要求。
背景是：马士基 2022 年以 36 亿美元收购这家第三方物流公司并并入自有物流板块，被收购方此后不再作为独立实体存在。
马士基并购历史系统勒索明文口令
为什么重要
并购留下的不只是客户与仓库：旧系统、旧账号、旧口令体系一并留下，且往往排在新东家资产台账的后排。
明文口令加 33 个超级管理员：一旦属实，要动的不是一台机器，是整个口令与权限基线，还要查复用面。
数据用途在对面很具体：手机号与设备识别码是钓鱼与语音诈骗的原料，签收单与库存记录是供应链情报。
「限于本地系统」这句话要能被验证：接口与电子数据交换未受影响是公司的判断，判断需要日志与流量证据，不是一句声明。
索赔口径与赎金报价脱钩：500 万美元是团伙报价，真实损失取决于口令复用范围与客户信任的恢复速度。
顾问金句
这一起要纠的不是「马士基又被盯上」，而是「我们把并购当成一次交割，没当成一次资产纳管」。
被收购方不再作为独立实体存在，可它那套系统还在、账号还在、口令还是明文——实体消失不等于暴露面消失。
建议企业做五件事。
首先，对近五年并购或关停的业务做一次系统清点，把「还在跑、还连着、还有人能登」的三类单独列出。
其次，给这类系统定一个明确的去向：并入统一纳管，或限期下线，别停在「先留着过渡」的状态里。
再者，把历史系统的口令体系整体重做一遍，明文存储的按已泄露处置，超级管理员账号逐个复核并加多因素。
而后，核对与现有系统的接口与数据交换通道，确认「未受影响」这句话有自己的日志能证明。
另外，把并购尽调的清单往前挪一格：交割前先查对方的口令存储方式与管理员账号数量。
A5 为自家攻防团队准备的开源工具，被拿去偷云凭据
核心内容
Arctic Wolf 披露，攻击者把开源智能体渗透测试平台 AntiFox 的自建实例托管在云上，用于服务探测、漏洞验证、投放 webshell 与收集云凭据。
AntiFox 由 ARTEX 0.1.1 分叉而来、中文界面，仍在公开仓库更新至 2.0 版，发布说明禁止对真实系统使用，但未提供任何技术性约束。
一起样本里，攻击者在暴露于互联网的 IIS 服务器上投放 ASPX webshell、执行系统命令、读取应用配置与数据库连接串，并把配置与日志复制到可被 Web 访问的目录；
另一起事件中，攻击者以有效 AWS 身份读取、复制并删除 S3 对象。
一次入侵中，对方在约 30 分钟内轮换多个身份、发出数百次接口请求，多数被拦，少数成功拿到生产环境密钥。
亚马逊方面表示自身服务未被入侵，给出的建议是按需授权、在实例上强制使用 IMDSv2、不把长期访问密钥写进应用配置，并开启 GuardDuty 类检测。
AntiFox智能体AWS凭据webshell开源工具
为什么重要
工具不分阵营：同一套智能体，防御方用来验证，攻击方用来筛目标，代码是同一份，差别只在谁部署。
声明不等于约束：发布页写着禁止用于真实系统，但没有任何技术限制，自建实例放在云上就是一个可租的攻击平台。
从 webshell 到云凭据是一条直线：应用配置里的长期密钥，就是这条线走到云上那一端的桥。
三十与数百：半小时轮换多个身份、数百次接口请求，靠人看告警追不上，只能靠基线收敛与自动处置。
处置重点是吊销与归因：先撤销会话与密钥，再把「大量被拒里少数成功」的调用挑出来当线索，而不是只封来源地址。
顾问金句
这一起要纠的不是「开源工具被滥用」，而是「我们默认攻防工具只在自家手里跑」。
同一份代码，防御方下载来验证，攻击方下载来筛目标——工具没有阵营，阵营在部署它的人身上。
建议企业做五件事。
首先，清点自建或自托管的攻防工具实例，确认没有一个暴露在公网可达的位置。
其次，把应用配置里的长期访问密钥清出去，改用实例角色加临时凭据，实例上一律强制 IMDSv2。
再者，给云上接口调用建一条基线：异常的身份轮换、短时间内的大量被拒请求，两类都要单独告警。
而后，对「大量被拒里少数成功」的调用做定期回溯，这是这类入侵里残留得较为稳定的痕迹。
另外，把「谁在云上开了什么实例」纳入月度盘点，自建工具的实例与业务实例一起看。
趋势分析
本期五件事都不在门外。
Windows 为堵日志文件系统认证问题加的那道缓解，一年后成了拿 SYSTEM 并关掉终端防护的通道；
Apache 的 HTTP/2 并发缺陷躺在每个开了 h2 的虚拟主机里，约六成四的云环境有受影响资源；
ScreenConnect 被攻破的不是主程序，是一款为免登录自动化而默认空密钥的第三方扩展，九十分钟把远控客户端推到四十八家机构的 288 台终端；
马士基出事的是四年前并购进来、作为独立实体早已不存在的物流系统；
AntiFox 这样为自家攻防团队准备的开源工具，被攻击者在云上自建实例拿去偷 AWS 凭据。
共同点不是洞更深，而是这些位置从来没进过暴露面清单——它们不在拓扑图外侧，不在资产台账前排，也不在任何人的巡检表上。
「里面」正从被边界守住的地方，变成从来没进过清单的地方。
给 CIO 的一句话：别只问「外面还有多少门没关」，改问「里面有多少位置，我们从来没给它编过号」。
是十一月十二日「信任」的下一步：那次说信任需要年检，这次说年检之前，先把要年检的对象数清。
