威胁分子利用Discord Webhooks在主流软件包生态中构建隐蔽C2通道

安全研究人员发现,威胁分子正通过npm、PyPI和RubyGems软件包滥用Discord Webhooks作为隐蔽的命令与控制通道,秘密窃取敏感配置、主机遥测数据和开发环境信息,此类攻击利用合法服务的HTTPS流量以规避传统安全检测。

威胁分子利用Discord Webhooks通过npm、PyPI和Ruby软件包进行C2通信

威胁分子正日益滥用Discord Webhooks作为开源软件包内隐蔽的命令与控制(C2)通道,从而能够在无需搭建专用基础设施的情况下,隐秘地窃取机密信息、主机遥测数据和开发环境数据。

Socket威胁研究团队记录了对npm、PyPI和RubyGems的活跃滥用行为,其中硬编码的Discord Webhook URL充当了只写的数据接收器,通过HTTPS将数据窃取到攻击者控制的频道。由于Webhook的请求数据类似于发往一个被广泛允许的域名的普通JSON流量,这些操作常常能绕过边界过滤和基于特征的检测控制。

Discord Webhooks如何成为数据窃取管道

Discord Webhooks是HTTPS端点,仅需拥有包含ID和密钥令牌的URL即可向频道发送消息。存活的端点通常在成功时返回“204 No Content”,或在设置了 ?wait=true 参数时返回“200 OK”,而401、404和429状态码分别表示令牌无效、Webhook已被删除或触发了速率限制。关键在于,Webhook URL是只写的——防御者无法仅从URL读取之前的频道历史记录——这使得取缔和追溯调查更加困难,同时降低了攻击者的成本和操作难度。

  • 只写访问权限:Webhook URL仅允许发布消息,无法读取频道历史记录。
  • 最小化认证:仅需拥有包含ID和密钥令牌的URL。
  • 标准HTTP响应:存活端点返回可预测的状态码以供验证。
  • 隐蔽优势:流量显示为发往流行的Discord域名的合法JSON请求。

各生态系统的恶意软件包

在npm生态中,mysql-dumpdiscord 针对敏感的配置文件,如 config.json.envayarlar.jsayarlar.json(土耳其语“设置”),读取并将文件内容分块后,通过POST请求发送到硬编码的Discord Webhook。更简单的 nodejs.discord 则是对 discord.js 的薄封装,将任意字符串转发到嵌入的Webhook URL;虽然有时用于日志记录,但如果在安装脚本或运行时调用此模式,极易转变为数据接收器。

在PyPI生态中,malinssx 覆盖了 setuptools 的安装命令,在 pip install 期间静默触发向Discord Webhook的POST请求,发送越南语通知消息。同一攻击者账号 sdadasda232323 发布的相同软件包(malicusmaliinn)重复使用了同一个Webhook,这表明攻击者通过自动化或迭代发布不同名称的软件包来规避针对单一软件包的取缔措施。

  • npm攻击目标:如 .envconfig.json 和土耳其语“ayarlar”设置文件。
  • PyPI渗透方式:在pip安装过程中执行的安装时钩子。
  • RubyGems利用手法:收集主机级数据,包括 /etc/passwd 和系统元数据。
  • 跨平台持久化:同一威胁分子在多个软件包生态系统中进行部署。

在RubyGems生态中,sqlcommenter_rails 更进一步,收集包括 /etc/passwd 内容、/etc/resolv.conf 中的DNS解析器、用户名、主机名、工作目录和主目录、软件包元数据以及通过 api.ipify.org 获取的公网IP在内的主机级信息,然后将完整的有效载荷序列化并发送到硬编码的Discord Webhook。整个过程抑制了错误信息,倾向于静默失败而非抛出显眼的异常。

为何此战术有效——以及应对措施

Discord Webhook C2改变了供应链滥用的经济成本。它是免费的、快速的、利用TLS加密流量混入流行域名,并且除了拥有URL外无需任何认证流程。当与安装时钩子、后安装脚本或Ruby/Python的安装设置覆盖结合时,这些软件包可以在应用程序运行时控制或EDR检测启动之前很久,就从开发者的笔记本电脑和CI运行器中窃取机密信息。在Telegram、Slack和GitHub Webhooks上也观察到了类似模式,凸显了向“商品化C2即服务”的更广泛转变,这削弱了静态攻击指标的价值。

  • 经济优势:免费的基础设施消除了托管成本和技术复杂性。
  • 规避战术:发往受信任域名的TLS流量绕过了大多数安全控制。
  • 时机利用:安装时执行发生在运行时安全监控之前。
  • 扩大攻击面:在Telegram、Slack和GitHub Webhooks上出现类似模式。

缓解措施应侧重于行为和出口控制。将Webhook端点视为潜在的数据窃取向量,并在可行的情况下通过DNS和TLS SNI过滤来执行允许列表。使用锁文件锁定依赖项,要求来源/SLSA证明,并通过PR扫描对依赖项更新进行把关,以标记硬编码的Webhook URL、出站网络调用和安装时执行。在软件包差异中扫描密钥访问行为,并以最小权限范围轮换开发者凭据。在CI/CD中,默认拒绝构建和测试步骤的出站互联网访问,仅授予范围狭窄的例外。最后,为开发者工作流配备软件包声誉和恶意软件检测功能,以便在基于Webhook的窃取模式落地之前进行拦截。

攻击指标 (IoCs):

ID 技术名称
T1005 从本地系统获取数据
T1016 系统网络配置发现
T1020 自动数据窃取
T1033 账户发现
T1059 命令与脚本解释器
T1059.006 命令与脚本解释器: Python
T1059.007 命令与脚本解释器: JavaScript
T1071.001 应用层协议: Web协议
T1082 系统信息发现
T1119 自动收集
T1195.002 供应链危害: 危害软件供应链
T1552.001 不安全的凭据: 文件中的凭据
T1567 通过Web服务进行数据窃取
comments powered by Disqus
使用 Hugo 构建
主题 StackJimmy 设计