边界安全，拒绝摆烂

跳转微信打开

Flocks AI安全运营挑战赛来了

阅读原文

跳转微信打开

英雄请揭榜，好汉请报名！

CSOP 2026 • AI安全大会官宣定档后

评论区被各位读者“DDoS”啦！

我们挑选了部分留言话题作为“英雄榜”

诚邀天下网安英雄，揭榜登台！

投稿截止时间为2026年5月20日24:00

请发送邮件到csop@threatbook.cn

如果您想报名参加本次大会

请直接扫描文章结尾二维码进行报名

以下，英雄请揭榜：

再次诚邀各路网安英雄揭榜

另：如果您想报名参加本次大会

请扫描下方二维码进行报名

最后，鸣谢此次出镜的侠探V分身——AI智者

·END·

跳转微信打开

蠕虫式传播

5月11日，微步情报局监测到全球广泛使用的JavaScript开源库TanStack遭遇供应链投毒。

攻击者通过伪装仓库中的孤立commit，利用GitHub Actions漏洞向42个@tanstack/*核心包精准注入了84个恶意版本，被篡改的组件普遍新增一个约 2.3 MB、经过重度混淆的router_init.js 文件，可窃取CI/CD凭证、OIDC令牌与云服务密钥，并借助窃取的凭证自动向npm发布更多受感染包以实现横向扩散。目前，感染活动仍在持续，恶意版本数量仍在上升，排查方式参见后文。

本次攻击特点如下：

• 凭证窃取范围广: 恶意脚本会窃取包括 AWS/GCP 密钥、.npmrc 文件、GitHub 令牌（Actions环境变量/gh CLI）、SSH 私钥在内的大量凭证。

• 自我传播能力强: 恶意代码具备蠕虫能力，会通过窃取的 OIDC 令牌自动向 NPM 发布受感染的新组件版本，横向传播。

• 威胁开发者: 恶意脚本会篡受感染的开发者环境中的 VS Code 和 Claude Code配置，实现持久化。

时间线（UTC）

2026年5月10日 17:16 : 攻击者创建了 zblgg/configuration 仓库，伪装成配置仓库。

●2026年5月11日 15:46: 攻击者在其控制的仓库中创建了一个孤立的（orphaned）commit，内含恶意核心载荷tanstack_runner.js。

●2026年5月11日 19:20 - 19:26: 攻击者通过该 commit 向42个@tanstack/*包发布了84个恶意版本。

●2026年5月11日 19:46: 安全研究员ashishkurmi在内部监控中检测到攻击。

●2026年5月11日 20:01:stepsecurity向 TanStack 官方发出预警。

●后续: TanStack 官方立即响应，关闭发布管道，并与 NPM 官方合作移除了所有恶意版本。

影响范围

直接影响: 84个@tanstack/* 组件包被投毒。常见受影响包及版本如下：

●确认安全:@tanstack/query*、@tanstack/table*、@tanstack/form*等主流工具库不在本次影响范围内。

排查方案

1. 项目依赖排查

立即检查项目的package-lock.json或yarn.lock文件，包含上述任一恶意版本号的依赖，即可确认受影响。强烈建议运行以下命令精确检查，并核对文件的哈希值:

其已知的 SHA-256 哈希值为：

●router_init.js / router_runtime.js:ab4fcadaec49c03278063dd269ea5eef82d24f2124a8e15d7b90f2fa8601266c

2. 系统受感染检查

确认以下文件和持久化配置是否存在，这些是恶意代码的典型植入特征：

●Claude Code 配置目录:.claude/settings.json（包含恶意 hooks）、.claude/router_runtime.js

●VS Code 任务配置:.vscode/tasks.json（被篡改）

●环境变量: 检查进程环境变量中是否存在__DAEMONIZED标识，这是恶意代码用于防止重复执行的机制。

3. 命令检查

3.1 检查Git仓库异常提交

运行以下命令，检查仓库中是否有恶意提交：

git log --all--author=claude@users.noreply.github.com --oneline

若发现可疑提交，请立即调查其内容。

3.2 恶意行为发现(Linux)

find ~ -path '*/.claude/setup.mjs' -o -path '*/.vscode/setup.mjs'

find ~/.config -name '*gh-token-monitor*'

find ~/.local/bin -name 'gh-token-monitor.sh'

find /tmp -name 'tmp.ts018051808.lock'

ps aux | grep -E 'tanstack_runner|router_runtime|gh-token-monitor|bun'

若发现可疑行为，请立即调查其内容。

3.3 npm脚本研判是否安装恶意库(全平台)

执行方式：node check-versions.js 

check-versions.js的sha256:

99180aec0f99b2e0fe0753453e4d88f8f9ac86a411c45ed23bcaea6b0db541a6

可访问微步云沙箱S查询下载：https://s.threatbook.com/

临时处置建议

网络层面阻断：如无业务需求，阻止对*.getsession.org域名的出站访问。

隔离受影响机器：立即将受害机器与公司网络和互联网断开，防止更多凭证外泄。

轮换所有凭证：在一台未受感染的独立、安全机器上，轮换所有可能泄露的凭证。优先级如下：

●NPM 令牌: 攻击者会滥用 OIDC 信任机制进行发布。

●GitHub 个人访问令牌 (PATs)和 OIDC 信任配置。

●AWS、GCP等静态密钥和服务角色凭证。

●Vault 令牌、Kubernetes service account 令牌等。

彻底清除并重装环境：删除整个node_modules目录和package-lock.json/yarn.lock文件，然后重新执行npm install或yarn。

IOC

文件

router_init.js / router_runtime.js

●SHA256 ab4fcadaec49c03278063dd269ea5eef82d24f2124a8e15d7b90f2fa8601266c

●SHA1 12ed9a3c1f73617aefdb740480695c04405d7b4b

●MD5 833fd59ebe66a4449982c6d18db656b4

tanstack_runner.js / router_init.js

●SHA256 2ec78d556d696e208927cc503d48e4b5eb56b31abc2870c2ed2e98d6be27fc96

●SHA1 e7d582b98ca80690883175470e96f703ef6dc497

●MD5 b82e54923f7e440664d2d75bd31588ca

网络

hxxp://filev2[.]getsession[.]org/file/

以下不能封禁

hxxp://169[.]254[.]169[.]254/latest/api/token （AWS EC2 IMDSv2 token acquisition）

hxxp://169[.]254[.]170[.]2（AWS ECS 任务元数据端点凭据收获）

hxxps://api[.]GitHub[.]com/repos/ （GitHub REST API — secrets enmulation and repo manipulation）

hxxps://registry[.]NPMJS[.]org/-/npm/v1/tokens（NPM 令牌验证）

vault[.]svc[.]cluster[.]local:8200（集群内 HashiCorp Vault API 端点）

参考链接

https://socket.dev/blog/tanstack-npm-packages-compromised-mini-shai-hulud-supply-chain-attack

跳转微信打开

攻击macOS的四类手法解读

跳转微信打开

攻击AI就靠这些

过去收敛攻击面

无非端口、服务、漏洞、钓鱼入口……

但今年AI的落地

带来AI中转站、AI Agent以及AI基础设施

处处皆是攻击面，很难收敛

5月13日14:00，我们将举办线上直播

对今年演练的AI攻击面进行详细解读

此次直播为审核制闭门分享，请扫码报名

作用是什么？用户访问大模型，很多并非直连官方服务，而是依赖LiteLLM、One API、自研Proxy等中转站进行转发。

攻击面在哪？被劫持或者使用攻击者提供的中转站。除了能看见交互内容，更危险的是还能修改返回命令。

这不仅仅是理论！具体攻击手法和案例，直播解读。

攻击面在哪？Agent可以执行任务，它处理的所有内容来源都是攻击面：IM消息、GitHub Issue、Jira工单、邮件……

风险有哪些？用自身的软件、工具、接口等合法读写权限，执行恶意命令。

不过，并非所有Agent都会成为攻击面，需要满足一套风险公式。

风险公式详情以及攻击案例，直播解读。

有哪些基础设施？AI的落地需要大模型网关、MCP Server、中转站、Ollama等模型服务、Dify及n8n等AI工作流平台……这些都是基础设施。

攻击面在哪？AI基础设施包含复杂的供应链，因此漏洞、投毒、不安全配置都会带来攻击面，例如最近的LiteLLM、Axios供应链投毒。

具体风险以及漏洞情报指南，直播解读。

面对这么多风险，AI安全的第一步不是如何拦截，而应该是资产化。看不见资产，根本谈不上安全治理。

AI资产及攻击面梳理、收敛策略、攻击手法预测，直播解读。

直播时间：5月13日下午14:00，欢迎微信扫描二维码报名。

跳转微信打开

一、 漏洞概述微步情报局监测到，Linux Kernel被披露存在本地权限提升漏洞，代号 “DirtyFrag

一、 漏洞概述

微步情报局监测到，Linux Kernel被披露存在本地权限提升漏洞，代号 “DirtyFrag”。

DirtyFrag是一类 Linux 本地提权漏洞，核心问题是：攻击者可以把只读文件的 page cache页面通过 splice() 放进网络包的sk_buff frag中，随后内核某些网络协议路径在这个frag上执行“原地加解密”操作，导致本不该被修改的只读文件缓存页被写入。磁盘文件没有被直接改写，但后续读取、执行该文件时会看到被污染的page cache内容，从而实现提权。

它和Dirty Pipe、Copy Fail属于相近问题类型，都是围绕page cache、零拷贝路径和内核写入边界假设失效展开。不同点在于Dirty Pipe主要污染pipe buffer，而DirtyFrag污染的是 struct sk_buff的frag。

目前该漏洞细节及 PoC 已公开，微步情报局对部分操作系统进行了验证，UOS、麒麟等信创系统，以及Rocy Linux、Ubuntu等非信创系统均受影响，详细结果如下。

OneSEC可以关注提权相关告警(规则ID：9030):

二、 已验证操作系统及版本

三、 临时缓解措施

1. 判断可用的临时缓解方式

先根据内核配置确认相关功能是否可以通过模块方式禁用：

grep -E 'CONFIG_INET_ESP|CONFIG_INET6_ESP|CONFIG_AF_RXRPC' /boot/config-$(uname -r)

判断方式：

●CONFIG_INET_ESP=m / CONFIG_INET6_ESP=m：esp4 / esp6 以模块形式存在，可以通过 modprobe 黑名单临时禁用，并尝试卸载当前已加载模块。

●CONFIG_AF_RXRPC=m：rxrpc 以模块形式存在，可以通过 modprobe 黑名单临时禁用，并尝试卸载当前已加载模块。

●CONFIG_INET_ESP=y / CONFIG_INET6_ESP=y：ESP 功能编译进内核，无法通过 rmmod 或 modprobe 黑名单完全禁用，只能通过升级修复内核、切换不包含该功能的内核，或禁用 user namespace 做辅助降风险。

●CONFIG_AF_RXRPC=y：RxRPC 编译进内核，无法通过卸载模块方式禁用，应优先升级修复内核或切换不包含该功能的内核。

●如果没有看到 CONFIG_AF_RXRPC，或结果为 CONFIG_AF_RXRPC is not set，说明当前内核未启用 RxRPC。很多发行版默认并不会编译 RxRPC，这种情况下无需针对 rxrpc 模块做禁用处置。

2. 排查 user namespace 状态

ESP 场景

当第 1 节输出 CONFIG_INET_ESP=y 或 CONFIG_INET6_ESP=y，且短期无法升级或切换内核时，可以检查系统是否允许创建 user namespace：

cat /proc/sys/user/max_user_namespaces

如果输出为 0，说明系统已经禁止创建 user namespace，这可以降低 DirtyFrag xfrm-ESP 变体被普通本地用户触发的风险。

如果输出大于 0，且业务确认不依赖 user namespace，可以考虑将其设置为 0 作为 ESP 内建场景下的辅助降风险措施。

如业务确认不依赖 user namespace，可以临时禁用：

sudo sysctl -w user.max_user_namespaces=0

如需重启后保持生效，可以写入独立 sysctl 配置：

echo'user.max_user_namespaces = 0'|sudotee /etc/sysctl.d/99-disable-userns.conf
sudo sysctl --system

ESP 场景下需要注意：

●user.max_user_namespaces=0 只能作为 ESP 变体的辅助缓解，不能替代升级修复内核。

●如果攻击者已经拥有真实 CAP_NET_ADMIN，或运行在具备相关能力的特权容器 / 特权服务中，禁用 user namespace 不能阻断这类路径。

RxRPC 场景

RxRPC 路径不依赖 user namespace。即使 user.max_user_namespaces=0，如果当前内核启用了 RxRPC，普通用户仍可能通过 add_key("rxrpc", ...)、socket(AF_RXRPC)、splice() 等接口触发相关路径。

因此：

●如果第 1 节输出 CONFIG_AF_RXRPC=m，应按第 3 节禁用 rxrpc 模块。

●如果第 1 节输出 CONFIG_AF_RXRPC=y，rxrpc 已编译进内核，无法通过模块黑名单禁用，应优先升级修复内核或切换不包含该功能的内核。

●如果没有看到 CONFIG_AF_RXRPC，或结果为 CONFIG_AF_RXRPC is not set，说明当前内核未启用 RxRPC，无需针对 rxrpc 做禁用处置。

3. 评估影响并临时禁用相关模块

只有第 1 节检查结果中出现以下输出时，才适用本节的模块禁用措施：

●CONFIG_INET_ESP=m

●CONFIG_INET6_ESP=m

●CONFIG_AF_RXRPC=m

这些输出表示对应功能以模块形式存在，可以通过 modprobe 黑名单阻止后续加载，并尝试卸载当前已加载模块。

如果输出为 =y，说明对应功能已编译进内核，本节的 modprobe 黑名单和 rmmod 不能完成禁用；应优先升级修复内核、切换不包含该功能的内核，或按第 2 节对 ESP 变体进行辅助降风险。

如果没有看到 CONFIG_AF_RXRPC，或结果为 CONFIG_AF_RXRPC is not set，说明当前内核未启用 RxRPC，无需针对 rxrpc 执行本节禁用命令。

禁用前需要评估影响：

●esp4 / esp6：影响 IPsec ESP，例如 strongSwan、libreswan、站点 VPN、主机到主机 IPsec。

●rxrpc：影响 RxRPC/kAFS，常见于 AFS 相关场景。

●user.max_user_namespaces=0：可能影响 rootless Docker、Podman、LXC、沙箱应用、部分 CI 构建环境。

如果业务不依赖这些功能，可以写入 modprobe 黑名单，并卸载当前已加载模块：

sudosh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf"
sudo rmmod esp4 esp6 rxrpc 2>/dev/null ||true

4. 验证缓解是否生效

再次检查模块是否仍然加载：

lsmod |grep -E '^(esp4|esp6|rxrpc)'

如果没有输出，说明当前运行环境中这些模块未加载。

也可以测试是否还能手动加载：

sudo modprobe esp4
sudo modprobe esp6
sudo modprobe rxrpc

预期结果是加载失败。

跳转微信打开

跳转微信打开

一大波受影响系统列表请查收

一、 漏洞概况

微步情报局监测到，Linux Kernel 被披露存在本地权限提升漏洞，漏洞编号 CVE-2026-31431，代号 “Copy Fail”。该漏洞源于内核 crypto: algif_aead 模块在处理 AEAD操作时的逻辑缺陷，可导致本地低权限攻击者通过 AF_ALG 加密接口向任意可读文件的页缓存（page cache）写入受控的少量数据（PoC 中为 4 字节块），进而篡改 setuid 等特权二进制文件，实现本地权限提升至 root。

目前该漏洞细节及 PoC 已公开，利用门槛极低（仅需约 10 行 Python 脚本），影响过去 9 年内大多数主流 Linux 发行版。

微步情报局对部分操作系统进行了验证，UOS、麒麟、openEuler等信创系统，以及Redhat、Ubuntu等非信创系统均受影响，列表见下文。

OneSEC可以关注提权相关告警(规则ID：9030):

二、已人工验证的系统

UOS受影响版本：1070、1060

统信软件推出的国产商业化Linux桌面/服务器发行版，基于Debian社区版深度定制

1070：

1060：

kylin受影响版本：V11、V10

天津麒麟开发的国产Linux操作系统，广泛应用于政府与军工领域

V11：

V10：

CUOS验证版本：4  不受影响

中国联通推出的企业级Linux服务器操作系统，聚焦云与通信场景

openEuler受影响版本：24.03 (LTS-SP1)

华为开源的国产Linux发行版，聚焦服务器与云计算场景，LTS长期支持版本

CTyunOS  受影响版本：V4.0 25.07

中国电信基于openEuler衍生的服务器操作系统，面向CTyun电信云基础设施

Ubuntu  受影响版本：V22.04  不受影响版本：V17.04

Canonical发行的全球流行Linux桌面/服务器发行版，生态成熟、用户基数大

V22.04：

V17.04：

Redhat  验证版本：7.9不受影响

红帽企业级Linux（RHEL）经典版本，企业服务器市场的主流选择之一

CentOS  验证版本：7不受影响

原社区版企业级Linux，7为Stream前身，现已转型为RHEL的上游预览版

Anolis OS  受影响版本：8.9

阿里云开源的国产Linux发行版，与RHEL生态二进制兼容，专注云与数据中心场景

Oracle Linux  受影响版本：10.0

甲骨文推出的企业级Linux，基于RHEL兼容内核，提供UEK内核与RHCK双启动选项

OpenCloudOS  受影响版本：9.4

腾讯主导开源的国产Linux发行版，源自CentOS Stream，聚焦云原生与服务器场景

NewStartOS  受影响版本：6.06

湖南麒麟研发的国产Linux桌面/服务器操作系统，基于Kylin内核，聚焦政府与教育行业

Debian  受影响版本：13

社区主导的经典自由开源Linux发行版（代号"Trixie"），是Ubuntu/RHEL等众多发行版的上游根基

三、其他版本验证

由于公开的Python PoC的检测准确性依赖于Python版本（Python低版本较低时需要的底层接口可能并未实现），如果想自查所用操作系统是否受影响，建议使用微步提供的通用PoC进行排查。

风险提示：禁止在线上环境进行验证，验证程序可能会损坏系统的su命令内存映像。

curl -fsSL https://onesandbox-release.threatbook.cn/poc/CVE-2026-31431/copyfail -o /tmp/copyfail && chmod +x /tmp/copyfail && /tmp/copyfail && rm -f /tmp/copyfail

·END·

跳转微信打开

跳转微信打开

跳转微信打开

跳转微信打开

跳转微信打开

战意渐浓！

跳转微信打开

双项领跑中国EDR市场

跳转微信打开

是你想的那件事吗？

CSOP 2026 • AI安全大会首站正式定档6月中下旬！

本次大会以“共智・共进・共生”为主题，探讨AI驱动的自主安全和AI应用带来的安全风险与机遇，即日起面向全行业征集最具实战价值的议题与案例。无论您是深耕一线的甲方安全负责人，还是走在创新前沿的AI安全研究者，只要您有可落地、可复用的实践成果，欢迎站上这个讲台！

我们希望这是一场什么样的AI安全大会？

首先，我们只聚焦安全运营与实战。不空谈概念，不扩大外延，只为解决甲方当下和不久的将来要面临的【真】问题——从自主安全防御到智能体闭环，从AI治理到应急响应。  

其次，我们希望每位参会嘉宾都能带走可借鉴、可实操、可落地的收获。听完一个议题，就能回去写方案；走出会场，就能动手开干。  

最后，我们希望CSOP大会只是一个引子，而不是终点。此后，我们将在全国各地搭建平台，通过线下沙龙、工作坊和闭门研讨会等形式促进业内AI安全经验的深度交流，收集并分享真正好用的AI安全用例。我们希望天马行空的想象能够落地生根，也希望大家在汹涌而至的变革中抓住机遇，不因风险而裹足不前。

我们希望知道您想听什么、要讲什么

本次大会的议题将围绕AI 赋能安全运营、AI 安全治理、AI 安全前沿趋势三大方向展开，我们在此给出一些议题，以求抛砖引玉：

• AI Agent 驱动安全运营自动闭环：自动值守、巡检、研判与响应实战

• AI Native 安全运营体系架构设计与落地路径

• AI Agent 赋能红队演练：自动化漏洞挖掘、渗透测试、攻防评估实践

• AI 新风险与攻击面：Agent 漏洞、Skills 投毒、权限越权、数据泄露等风险

• AI Agent 安全治理体系：准入评估、权限管控、行为审计、合规约束最佳实践

• 企业落地 AI Agent 全生命周期安全保障：设计、开发、上线、运营、管控

• AI 攻防对抗趋势：智能化攻击与防御的长期博弈

• AI 时代网络安全新机遇与新风险

……

但我们相信更好的议题一定来自您的构想和实践，因此我们希望征集观众想听/行业真正关心的议题，为此，我们设计了以下几种参与规则：

【我是听众，我想听！】

在评论区留言，写下你最想听的AI 安全议题、实战案例、技术深度、治理经验。

点赞前10名的评论，将获得大会定制纪念礼品一份。（统计截止时间为4月24日18:00）

若你建议的议题最终成功邀请到讲者并登台演讲，提交者将有机会获得：CSOP 大会 VIP 门票 1 张

【我是讲者，我开麦！】

请发送邮件到csop@threatbook.cn

邮件主题：CSOP AI 安全大会 - 议题申请 - 姓名/单位

内容包含：议题标题、500 字左右内容摘要、个人简介、联系方式

我们会对内容进行审核，最终确认登台演讲的嘉宾将获得：

• 大会演讲嘉宾专属荣誉证书

• CSOP 大会 VIP 门票 2 张（含1站全程参会 + 晚宴）

• 大会官方媒体曝光、大会资料包 

• 企业安全负责人圈层交流机会

【我自己不好上台，但我觉得ta特别棒！】

我们还设置了推荐奖，您可以发送邮件到csop@threatbook.cn推荐您身边的同业者登台分享。

邮件主题：CSOP AI 安全大会 - 嘉宾推荐 - 姓名/单位

内容包含：议题方向、演讲人姓名/单位、推荐人姓名/单位

如果最终顺利登台演讲，推荐人将有机会获得：

• CSOP 大会 VIP 门票 1 张（含1站全程参会 + 晚宴）

• 大会定制礼品2份

• 大会资料包 1份

从古至今，我们无数人、无数次歌颂勇气。而安全行业，从未像此刻这样需要勇气。

面对Agentic AI的自主进化浪潮，有人观望，有人焦虑，我们呼唤真正的先行者用行动重构安全运营的未来图。

愿我们都能：大胆想象，小心求证，正视AI带来的风险与机遇，与AI“共智、共进、共生”。

跳转微信打开

作为香港警队CSTCB网络安全特别行动小组成员，微步在线（ThreatBook）是本次演练唯一的网络安全技术支撑单位

近日，由香港警务处联合国际刑警组织，中国澳门司法警察局、新加坡警察部队、新加坡网络安全局及韩国国家警察厅共同参与的“网络及实体反恐联合演练2026”（代号“潜网”）顺利落幕。作为香港警队CSTCB网络安全特别行动小组成员，微步在线（ThreatBook）是本次演练唯一的网络安全技术支撑单位，全程提供技术支撑与情报分析服务，与四地执法机构、基础设施运营方携手，共同筑牢跨境反恐安全防线。

本次实战演练汇集了中国香港、中国澳门、新加坡、韩国四地及国际刑警组织共计380余名相关人员，香港金融管理局、多家银行及分支机构代表也参与其中，香港警务处处长周一鸣亲临现场视察指导。

演练聚焦当前全球日益复杂的“混合式恐怖威胁”，模拟多种贴近实战的紧急场景，全面检验各方协同应对能力，全程紧扣跨境反恐核心需求，先后模拟恐怖活动融资、跨境恐怖组织同步攻击四地金融机构、航空业及医疗系统等场景，同时涵盖大型活动场馆爆炸装置放置、无人机操控扰乱等高危情形，重点测试各单位在高压环境下的情报共享、快速应变、联合处置及协同作战能力，进一步强化执法机构与重要基础设施运营方的合作纽带。

作为中国网络安全领域的知名企业，微步凭借深厚的威胁情报积累与专业的技术能力，全程深度参与演练核心环节。微步中国香港、新加坡及中国澳门团队各司其职、密切配合，以“网络安全特别行动小组”成员身份，开展精准的网络威胁情报分析，针对恶意软件攻击手法、网络威胁拆解等关键环节提供专业技术指导与意见，助力各地警方高效识别、处置网络威胁。

随着数字化时代的快速发展，网络攻击与恐怖活动的融合趋势日益明显，跨境威胁不受边界限制，防御工作同样需要跨境协同。此次微步受邀参与演练，不仅是香港警务处及各方合作机构对其技术实力的高度认可，更是其践行“守护数字安全”使命的具体体现，也进一步印证了微步在关键信息基础设施防护、跨境威胁应对方面的扎实能力。此前，微步已获任香港警务处网络安全特别行动小组成员，多次为区域网络安全保障提供支撑与助力。

未来，微步将持续深耕网络安全领域，聚焦港澳区域安全需求，深化与香港警务处、澳门司法警察局等港澳执法机构及行业伙伴的紧密合作，不断优化威胁情报与安全防御技术，以技术赋能安全，以协作抵御威胁， 既为维护港澳区域的安全稳定、公共秩序及数字经济健康发展贡献核心力量，也将继续为新加坡及全球市场提供专业网络安全支撑，守护全球数字空间安全。 

跳转微信打开

在2026年世界互联网大会亚太峰会“AI×网络安全：人类与智能体共存”主题论坛上“威胁情报分享暨支撑单位评级结果”颁奖仪式圆满举行。微步在线以排名第一的优异成绩，斩获本次评级“突出贡献奖”，彰显了行业与权威机构对其威胁情报实力的高度认可。

本次威胁情报评级评价由香港政府数字政策办公室（DPO）、HKCERT、Gov.cert.hk，以及香港网络安全专业协会、香港网络安全研究院联合发起，自2025年4月正式启动。评审围绕多个核心维度严格打分：威胁情报准确度、情报质量与实战价值、与香港本地场景的数据关联性等。微步以威胁情报（TI）与人工智能（AI）为技术内核打造下一代威胁情报体系，威胁情报准确率高达99.99%，可分钟级产出全品类多维情报，深度适配香港金融、政务、关键信息基础设施等本地场景，实战价值突出，可全面支撑全流程安全运营，在本次威胁情报评级中综合实力排名斩获第一。

圆桌对话：微步AI安全能力赋能香港关键行业

针对香港金融、政务等关键行业的安全运营升级需求，微步联合创始人李秋石在圆桌对话中明确表示，全新发布的Flocks智能安全数字员工可实现7×24小时自动化威胁处置，替代人工重复响应，通过持续学习攻防数据完成自我迭代，帮助机构从“人工被动响应”升级为自进化安全运营模式，大幅降低人力依赖、缩短威胁处置时效，为香港关键信息基础设施运营单位、金融机构筑牢全天候、高合规的安全运营防线。

AI智能体在金融、政务场景加速落地过程中，作为核心执行单元的Skills组件已成为新型攻击焦点，攻击者通过篡改Skill、投毒、窃取API密钥等手段实施渗透，传统安全工具难以识别此类潜伏威胁。微步推出的SafeSkill一站式AI Agent安全平台，可在Skills上线前完成全面风险筛查，精准阻断恶意Skill落地，从源头守护AI智能体组件安全。微步联合创始人李秋石表示，网络攻防对抗已迈入全新维度，防守方也要学会借助AI工具，“用魔法打败魔法”。

与此同时，全球AI供应链投毒事件持续高发，Axios、LiteLLM等核心组件相继遭到恶意污染，风险通过软件依赖链快速向下游扩散，给关键行业带来数据泄露、业务中断等严重威胁。微步始终保持高度重视，持续进行威胁监测与应急响应，凭借顶尖威胁情报与攻防实战能力，全球率先完成Axios供应链投毒事件溯源并发布专业报告，同步联动终端、流量、边界全系列安全产品，快速输出IOC检测规则与拦截处置方案，为香港关键行业提供及时可靠的供应链攻击防护支撑，全力护航香港可信AI生态建设。

深耕香港，筑牢网络安全韧性

微步与香港网络安全领域渊源深厚。早在2023年，微步在线便在香港成立子公司，通过本地服务团队为香港多家金融机构、企业及政府关联单位提供威胁检测与响应服务，核心产品已服务香港金融、政府、大型企业等重要领域多家标杆客户。

近年来，微步在香港网络安全领域屡获认可：2025年，作为核心技术支撑单位参与“香港网络安全攻防演练-以攻筑防2025”，凭借领先的威胁情报与攻防技术能力获颁香港特区政府感谢证书；2026年初，正式获得香港警务处委任，成为“网络安全特别行动小组”（CSATF）核心成员，与小组单位共同守护香港数字空间安全与关键基础设施稳定。微步以AI＋威胁情报双引擎，积极参与本地威胁情报共享与联合防御，持续为香港各行业提供精准威胁防护。

此次在香港威胁情报评级评价中排名第一、荣获“突出贡献奖”，标志着微步的技术实力与服务能力再次获得香港政府和权威机构的高度认可。这不仅是对微步过往成绩的肯定，而且进一步巩固了微步在香港威胁情报领域的领军地位。

深耕香港、服务大湾区，微步将持续贡献威胁情报能力及安全运营实战经验，促进香港特别行政区业界网络安全联合防御，携手提升香港整体网络安全防护与韧性，为维护国家网络安全发展筑牢网络安全基底。

跳转微信打开

疯狂的供应链投毒

算上Axios、Apifox和LiteLLM，最近已经发生太多大规模供应链投毒了。

很多安全人员都在忙着封禁C2，清理恶意文件，却忽略了最重要的一件事——关键凭证、密钥已经被拿走且无法挽回，因此重置这些资产，远比封域名、删文件更重要。

否则，我们得到的只是被清理干净的机器，失去的却可能是整个内网，甚至更多。

这还真不夸张。我们不妨回顾一下Apifox投毒事件中，微步发现的攻击者窃取对象。

目标非常明确：盗取关键凭证。其危害是非常严重的。

危害一：长期驻留权限

攻击者拿到AK/SK、浏览器保存的账密、shell命令历史中保存的凭证等，可以仿冒合法身份实现长期驻留，并不依赖远控木马。

危害二：从一台机器到“整个内网

攻击者利用SSH私钥、令牌横向跳转到其他机器、代码仓库、生产主机还有一堆集权系统，这时整个内网就等于失陷了。

危害三：“套娃式”供应链污染

攻击者通过Git凭证、npm令牌、SVN凭证，再次投毒代码仓库，那么后门可能会沿着供应链继续传导下去。

LiteLLM就是如此。攻击者篡改了CI/CD流水线上的漏扫工具Trivy，得以窃取其PyPI发布凭证并发布包含后门的版本，进一步污染下游项目及最终用户。

最近供应链投毒事件如此高发，很难说不是凭证失窃引发的多米诺骨牌效应。

既然如此，凭证为什么还容易被忽略？根本问题在于，木马执行起来后的行为不可见，不知道有没有偷凭证，因此容易陷入误区。

误区一：恶意代码清理不干净，反复启动

尤其是比较隐蔽的持久化和驻留项，包括注册表、计划任务、系统服务、Rootkit等等，很难发现。比如我们只隔离了文件，木马很快就能重新执行起来，不停反复。

误区二：横移看不见，排查失陷有遗漏

横移的方法多种多样，如果缺乏必要的可见性，很容易发生遗漏。

误区三：不知道敏感数据失窃，或者了解的不全面

恶意代码加载起来后，很快就会将数据打包好回传至C2，很难第一时间发现。

此外，攻击者的目标数据非常多样，包括各类AK/SK、认证Token、密钥、shell命令历史记录中的各种临时密码，重置时很容易漏掉其中一部分。

当然无论如何，在遭遇供应链投毒后，阻断网络通信、清除恶意代码，一直都是最高优先级的两件事，可以快速帮助我们抑制感染进一步扩散。

但具体怎么做，在微步MDR团队处理的数千起事件里，除了包含足够的可见性，还有一套通用SOP。

检测与抑制阶段：封禁IOC，排查、隔离受影响终端

（1）对于公开C2应迅速封禁，并在EDR、NDR、网关设备上，定位攻击有效期内的反连请求。比如针对Axios npm投毒，可在EDR中排查3月31日反连sfrclak.com的终端。

（2）通过被投毒的软件名称、版本号等，在桌管/软管上排查安装这些软件及相关依赖项目的终端。比如Axios被投毒导致OpenClaw也受到到影响，可以禁止OpenClaw的使用。

（3）对于隐藏比较深的项目，还可检查node_modules中的恶意包。

通过上述方法定位到的受影响终端，都应第一时间隔离。

根除阶段：清理恶意代码，将软件变更至安全版本

按照官方文档，将软件升级或回滚至安全的版本。同时排查清理所有恶意代码，实在难以清理的可以重装机器。但在重装之前，应尽可能抓取内存镜像和磁盘镜像，便于后续逆向与拓线。排查、清理对象包括但不限于：

（1）恶意样本及相关文件

可以根据恶意文件名，在EDR日志中检索对应的文件创建行为，确定不同失陷终端上的安装路径。文件可以手动删除，也可以通过EDR下发删除任务。

（2）注册表、系统服务、计划任务等驻留项

如发现木马清理不掉，一定要注意排查攻击者留下的驻留项，包括进程链中涉及的注册表修改、系统服务和计划任务创建以及Rootkit加载等，如存在应当一同清理。

（3）后渗透工具

重点监控异常创建的nmap、mimikatz、procdump等工具，这些常被攻击者用来端口扫描、窃密、提权等，便于开展后续渗透。

（4）新的未知C2

在排查过程中，一旦发现恶意代码反连新的非公开C2，也需要封禁，同时排查是否还有其他终端请求这个C2。

（5）横向移动

如果发现横向移动迹象，比如用PsExec在远程终端执行命令，wmic调用进程等，则需要在横移的机器重复上述排查清理动作。

不过横移远不止这些行为，利用失窃凭证进行的“合法化”横移，需要综合流量、终端以及服务器的日志排查，这里就不赘述了。

恢复阶段：排查敏感数据访问，重置失窃凭证

恶意代码清理完成后，经验证没有恶意活动的，就可以恢复正常使用了，但涉及到凭证窃取的事件，相关联的凭证一定要及时重置。

可以在EDR上检索恶意组件相关的敏感文件访问行为，确认凭证是否失窃。例如在Apifox投毒事件中，可以看到攻击者访问了这些文件（部分），其中包含的凭证需要重置。

如果无法确定失窃范围，或者担心其他潜在风险，应当扩大重置凭证的范围，默认攻击者所有目标凭证均已失窃。

验证阶段：对可能受影响的系统持续重点监测

（1）明确监测范围：重点监测失窃凭证关联的主机、核心业务系统、云服务、代码仓库等，尤其是“失陷发生后至凭证重置完成前”的时间段。

（2）重点监测行为：排查是否存在以下高风险行为——异地登录、未授权访问（权限异常提升、访问未授权资源）、异常API调用（高频调用、非业务时段调用）和账户创建。

通过上述四步，绝大部分事件都能得到很好的处理。

当然，不同的事件细节差异很大，有的只投递了单纯的窃密后门，偷完就跑，不在终端上驻留；有的涉及到复杂的远控木马和强对抗手法，需要安全人员结合实际情况判断。

对于安全团队资源有限、希望提升响应效率的企业，可考虑微步MDR服务，由专业团队协助完成全流程应急响应与持续监控，降低供应链投毒风险。

如需针对安全事件进行应急

请扫客服码沟通/电话咨询

跳转微信打开

落地三部曲，附带详细时间点

在Claude Mythos Preview和Project Glasswing横空出世后不久，4月12日，云安全联盟CSA联合SANS、[un]prompted、OWASP GenAI Security Project等全球权威机构，正式发布《AI Vulnerability Storm: Building a “Mythos-ready” Security Program》（AI漏洞风暴：构建“Mythos‑Ready”安全项目） 报告。

这份报告诞生自一场紧急闭门线上会议，最终由近20位全球网络安全资深研究者联合撰写，250位顶尖CISO与安全从业者共同审阅，他们一致认为，以Mythos为代表的AI大模型正在引发结构性的“AI漏洞风暴”，传统漏洞防治体系将全面失效，企业必须立刻转向AI驱动、韧性优先、自动化闭环的Mythos‑Ready安全模式，否则将在机器速度的攻击面前失去防御能力。

报告为企业提供了可落地的三步应对框架：

· 诊断当前安全项目现状与影响力

· 更新安全计划与风险登记册草案

· 执行适配Mythos环境的行动优先级。

Mythos等大模型将带来席卷全球的漏洞海啸，而Glasswing计划仅覆盖极少数海外头部厂商，没有任何一家中国企业在名单之内。被排除在提前防御圈之外的我们，究竟该如何自救？微步对这份报告进行了全文深度编译，旨在为国内CISO与安全团队提供参考。以下：

 一、Mythos的真实能力边界：AI攻击进入机器速度时代

Anthropic官方宣称，Mythos具备三项颠覆行业的核心能力，每一项都直接击穿传统防御假设：

1. 无需辅助框架生成Exp

Anthropic内部测试显示，在相同条件下，Mythos在火狐浏览器上成功生成181个可运行利用代码，而上一代模型Claude Opus 4.6仅成功2次，自主性与可靠性实现量级跃升。

2. 可挖掘复杂链式漏洞

能够识别由多个漏洞组合串联的高级利用路径，突破传统单一漏洞检测局限。

3. 单提示词完成全流程攻击（One-shot capability）

无需复杂配置与人工辅助，单次提示即可完成漏洞发现、利用生成、攻击编排。

结果是惊人的：Mythos漏洞利用成功率高达72%，可跨主流操作系统、浏览器发现数千个零日漏洞，甚至能挖出OpenBSD已存在27年的深层漏洞。

报告引用Zero Day Clock数据更令人警醒：

漏洞从公开披露到被武器化的时间（TTE），已从过去的数年、数月，急剧压缩至2026年的20小时以内。

与此同时，Linux内核漏洞报告从每周2个激增至每周10个，且全部从AI幻觉转为真实可利用漏洞，开源供应链的风险面已全面失控。

二、Mythos只是个开始，不可逆的趋势已经到来

Mythos不是一次技术演示，而是网络安全时代的分水岭。报告明确指出，这场危机带来三大不可逆趋势：

1. 攻防不对称彻底固化

AI大幅降低攻击成本与技能门槛，攻击者获得结构性优势，防守方补丁速度永远追不上漏洞武器化速度，陷入永久被动追赶。

2. 漏洞披露进入海啸模式

Mythos只是一个开始，后续会连续出现大规模AI发现漏洞浪潮，在最坏的情况下CVE、NVD、漏洞悬赏、企业应急体系将全部过载。

3. 安全运营全面AI化

防御性AI尚未成熟，但AI编码代理已能立刻提升效率；拒绝使用AI工具、停留在人工操作的安全团队，将在机器速度攻击面前完全失去抵抗能力。

报告同时列出企业必须面对的5项严重（Critical）风险：

- AI以机器速度自主加速漏洞利用

- 防御方AI自动化能力严重不足

- 未受控的AI代理带来全新攻击面

- 事件检测与响应速度无法匹配机器速度

- 网络安全风险模型完全过时

再加上资产清单不全、软件交付链路无AI审查、网络架构无法阻止横向移动、漏洞管理被动、威胁情报滞后等高风险点，传统安全体系正在全面失效。

 三、我们应当如何行动？

报告认为，为了实现Mythos-Ready安全体系，下列行动项必须立即执行：

启用基于大语言模型（LLM）的漏洞发现与修复能力

不同于防御性AI技术，基于LLM的漏洞发现能力已完全成熟，可直接用于我们的防御优势。立即行动：让AI代理对任意代码执行安全审查，并逐步搭建VulnOps（漏洞运营）能力体系。

更新风险指标

随着安全格局的剧变，你现有的许多指标与风险评估可能已经过时，甚至会影响业务汇报。请思考如何更新这些指标，并与利益相关方充分沟通这一挑战。

用Coding Agent全面加速团队效率

尽管防御性AI技术仍落后于攻击性AI，但AI Agent已能全方位加速人类工作，从事件响应到GRC（治理、风险与合规）全流程。鼓励并要求你的团队使用这些Agent来提升能力：开展漏洞分诊与补丁测试、红队演练环境搭建、自动化审计数据采集，全面提速安全运营。

准备应对更多安全事件

开展多起同时发生、高严重度事件的桌面演练；提前制定高级别、关键事件的响应预案。尽可能自动化修复能力，验证并启用分段、出口过滤、零信任架构、抗钓鱼MFA（多因素认证）、密钥轮换等缓解控制措施，以限制漏洞利用后的攻击影响，保护供应链安全。

强化基础安全建设

基础安全措施依然有效，可优先用于应对无法直接缓解的风险。网络分段、已知漏洞修复、身份与访问管理、纵深防御，所有这些都会提升攻击者的入侵难度。趁还有时间，扩大这些投入以降低潜在风险，是极为审慎的选择。

防范团队倦怠

漏洞披露的节奏与量级将远超以往任何时期。请申请额外的人力与预算，预留缓冲能力，避免现有员工职业倦怠（原文用词为burnout，燃尽了），同时同步推进更多自动化部署。

向Mythos‑Ready型安全体系演进

Mythos只是网络安全风险领域众多变革中的一项。若尚未启动相关工作，应认真考虑将Mythos及其影响纳入你的安全战略。

拓展外联与合作，构建集体防御

攻击者早已以产业链模式运作：众包协作、共享工具、集体行动。立即与行业协调组织、ISAC（信息共享与分析中心）、CERT（计算机应急响应小组）、标准机构开展合作，共享威胁情报、协同响应，并制定针对当前形势的行业专项指南。防御方必须效仿攻击者的协同模式，充分利用协调组织。团队胜过信息孤岛，联盟胜过单打独斗，配备正确技术的联盟终将获胜。

四、落地三部曲：从诊断到执行

报告给出了一个从快速评估到阶段性执行的“实战三部曲”：

第一步：10个问题，快速诊断企业的安全现状

一个可行的问题清单，方便企业CISO基于提问梳理其对安全项目的影响达成客观事实，并评估对各类业务职能的影响力。

第二步：基于回答，更新风险登记草案

完成10问诊断后，企业需要输出Mythos‑Ready风险登记草案，覆盖严重/高/中三个等级，明确风险描述、类型、框架依据与对应行动。此处的的表格大量援引了MITRE ATLAS、OWASP Agentic Top 10（2026）、NIST CSF2.0等框架内容，由于内容较多，建议读者参考文章“阅读原文”中的报告完整版。

第三步：执行优先行动（激进时间表）——全文汉化完整版

报告称，这份清单“专为周一就需要拿出方案的CISO设计”，是报告最核心的落地输出：

说明：

- 风险等级：严重=不处理立即面临暴露；高=45天内出现重大风险

- 类别：治理=结构性前提；风险控制=直接降风险；运营支撑=让控制可执行

结语：AI漏洞风暴不是预警，是当下危机

基于人工智能的攻击代表了攻防模式的结构性转变，且这一趋势不会改变。利用漏洞发现的成本和能力门槛正在大幅降低，漏洞披露与武器化之间的时间间隔正压缩至趋近于零，而以往需要国家级资源才能具备的能力，如今正变得广泛可用。

做到Mythos‑Ready，核心在于达成四项目标：

1.构建韧性架构，限制漏洞利用与攻击影响

2.在攻击者之前主动发现自身漏洞

3.规模化快速响应，最小化业务中断

4.用AI代理全面加速安全团队能力

AI漏洞风暴已经登陆，企业已经没有时间观望。构建Mythos‑Ready安全体系，不是应对一个模型，而是适应一整个时代。

参考链接（点击“阅读原文”可直达）：

https://labs.cloudsecurityalliance.org/wp-content/uploads/2026/04/mythosready.pdf

阅读原文

跳转微信打开