威胁行为体利用Discord Webhooks进行C2通信

攻击者正日益滥用Discord的Webhook功能，将其作为开源软件包内隐蔽的命令与控制通道，从而在不搭建专用基础设施的情况下，秘密窃取敏感信息、主机遥测数据和开发环境数据。

Socket威胁研究团队记录了npm、PyPI和RubyGems平台上活跃的此类滥用行为。在这些攻击中，硬编码的Discord Webhook URL充当了只写的数据接收端，通过HTTPS协议将数据传送至攻击者控制的频道。由于Webhook的POST请求与发往被广泛允许的域的普通JSON流量相似，这些操作常常能绕过边界过滤器和基于特征的检测控制。

Discord Webhooks如何成为数据外泄管道

Discord Webhook是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、.env、ayarlar.js和ayarlar.json（土耳其语中的“设置”），读取文件内容并将其分块，然后通过POST请求发送到硬编码的Discord Webhook。

更简单的nodejs.discord包，则是在discord.js库外封装了一个薄层，用于将任意字符串转发到嵌入的Webhook URL。虽然这种模式有时用于日志记录，但如果它在安装脚本或运行时被调用，则可以轻易地变成一个数据接收器。

在PyPI生态中，恶意包malinssx会重写setuptools的install命令，使得在执行pip install安装时，静默触发一个向Discord Webhook发送POST请求的操作，并发送一条越南语通知消息。同一攻击者账号sdadasda232323还发布了功能相同的包（如malicus、maliinn），重复使用同一个Webhook。这表明攻击者可能在通过自动化或迭代发布不同名称的包，以逃避针对单一软件包的删除措施。

• npm攻击目标：针对如.env、config.json及土耳其语“ayarlar”设置文件等配置文件。
• PyPI渗透：在pip install过程中执行的安装时钩子。
• RubyGems利用：收集包括/etc/passwd和系统元数据在内的主机级数据。
• 跨平台持久化：同一威胁行为体在多个软件包生态系统中部署攻击。

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

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

利用Discord Webhook进行C2通信颠覆了软件供应链攻击的成本模式。它是免费的、快速的，流量通过TLS加密发送至一个受欢迎的域名，且除了持有URL外，无需任何认证流程。

当这种技术与安装时钩子、postinstall脚本或Ruby/Python的setup覆盖等方法结合时，这些恶意包可以在应用程序运行时控制或端点检测与响应（EDR）系统介入之前，就早已从开发人员笔记本电脑和CI运行器中窃取了机密信息。

类似的攻击模式也在Telegram、Slack和GitHub的Webhook中被观察到，这突显了攻击者正更广泛地转向“利用商品化C2即服务”的策略，这削弱了静态入侵指标（IOC）的价值。

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

防御措施应侧重于行为和出口流量控制。应将Webhook端点视为潜在的数据外泄渠道，并在可行的情况下通过DNS和TLS SNI过滤来实施允许列表策略。

通过锁文件锁定依赖项版本，要求提供来源证明或SLSA证明，并通过PR扫描对依赖项更新进行门控，以标记硬编码的Webhook URL、出站网络调用和安装时执行。在软件包差异中扫描密钥访问行为，并以最小权限范围轮换开发人员凭据。

在CI/CD环境中，默认情况下禁止构建和测试步骤的出站互联网访问，并仅授予范围狭窄的例外。最后，为开发工作流程配备具备软件包信誉和恶意软件检测能力的工具，以便在基于Webhook的外泄模式造成实际危害之前进行拦截。

入侵指标