npm／PyPI／RubyGems パッケージを介した Discord C2：ステルス情報漏洩が加速

Threat Actors Exploit Discord Webhooks for C2 via npm, PyPI, and Ruby Packages

2025/10/12 gbhackers — オープンソース・パッケージ内での Command and Control (C2) チャネルとして、Discord Webhook を悪用する脅威アクターが増えている。それにより、専用のインフラを構築することなく、機密情報／ホスト・テレメトリ／開発者環境データのステルス的な流出が可能になる。Socket の脅威調査チームが確認したのは、npm／PyPI／RubyGems 内でハードコードされた Discord Webhook URL が、書き込み専用のデータ受信先 (シンク)として機能し、HTTPS 経由で攻撃者が管理するチャネルへデータを吸い上げるという、活発な悪用の事例である。

Webhook の POST リクエストは、広く許可されるドメインへの通常の JSON トラフィックに似ているため、こうした操作は境界フィルタリングやシグネチャ・ベースの制御をしばしば回避する。

Discord Webhook が情報漏洩のパイプとなる仕組み

Discord Webhook は、ID とシークレット・トークンを含む URL のみを必要とする HTTPS エンドポイントであり、当該 URL を保有するだけでチャンネルへメッセージを投稿できる。

このライブ・エンドポイントは通常、成功時に 204 No Content を返し、”?wait=true” 時には 200 OK を返す。その一方で 401／404／429 は、それぞれ無効なトークン／削除／レート制限を示す。

重要なことは、Webhook URL が書き込み専用である点だ。防御側は URL 単体では過去のチャンネル履歴を読み取れないため、削除や事後調査が困難になる一方で、攻撃者の手間とコストは低減される。

  • 書き込み専用アクセス：Webhook URL はメッセージ投稿のみを許可し、チャンネル履歴の読み取りは許可しない。
  • 最小限の認証：ID とシークレット・トークンを含む URL の所持のみでよい。
  • 標準的な HTTP レスポンス：ライブ・エンドポイントは検証のために予測可能なステータス・コードを返す。
  • ステルス性：トラフィックは人気の Discord ドメインへの正当な JSON POST のように見える。
エコシステム全体にわたる悪意のパッケージ

npm では、mysql-dumpdiscord が config.json／.env／ayarlar.js／ayarlar.json (ayarlar はトルコ語で設定) などの機密性の高いコンフィグ・アーティファクトがターゲットになる。このパッケージは、対象ファイルの内容を読み取った上でチャンク化し、ハードコードされた Discord Webhook へ POST 送信する。

さらに単純な手法として、nodejs.discord は discord.js を薄くラップし、任意の文字列を埋め込み、Webhook URL に転送する。このパターンはログ記録に使用されることもあるが、インストール・スクリプトやランタイムから呼び出されるなら、容易にデータ流出源となる可能性がある。

PyPI の事例では、malinssx が setuptools の install コマンドをオーバーライドし、pip install 中に Discord Webhook への POST をサイレントにトリガーし、ベトナム語の通知メッセージが送信された。

同一のパッケージ (malicus／maliinn) が同一アクター・ハンドル sdadasda232323 により公開され、同じ 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 経由で人気ドメインへ送信される無料かつ高速なトラフィックであり、Webhook URL を取得する以外に認証ワークフローを要しない。

インストール時フック／ポスト・インストール・スクリプト、あるいは Ruby / Python のセットアップ上書きと組み合わせることで、これらのパッケージはアプリケーションの実行時制御や EDR 検出が作動する前に、開発者のノート PC や CI ランナーから機密情報を盗み出すことが可能である。

同様のパターンは、Telegram／Slack／GitHub の Webhook においても確認されており、コモディティ化された C2 サービスへの広範な移行による、静的 IOC の有用性の低下を浮き彫りにしている。

  • 経済的利点：無料のインフラによりホスティング・コストと技術的な複雑性が軽減される。
  • 回避戦術：信頼されたドメインへの TLS トラフィックは、大半のセキュリティ制御を迂回する。
  • タイミング悪用：インストール時の実行はランタイム監視よりも先行する。
  • 攻撃対象領域の拡大：Telegram／Slack／GitHub の Webhook でも同様のパターンが顕在化している。

動作制御と出力制御を中心に構築する、緩和策が必要になる。推奨される考え方は、Webhook エンドポイントを潜在的な情報漏洩経路として扱い、可能な場合には DNS／TLS SNI フィルタリングによる許可リストを適用することだ。

それに加えて、依存関係管理の強化が不可欠である。この依存関係はロックファイルで固定し、出所証明／SLSA 認証を要求する。PR スキャンでゲートされる依存関係の更新により、ハードコードされた Webhook URL／アウト・バウンド・ネットワーク呼び出し／インストール時実行をフラグ付けする。

パッケージ差分に対してシークレット・アクセス・スキャンを実施し、開発者の認証情報は最小権限スコープでローテーションする。CI では、ビルドおよびテスト手順のアウトバウンド・インターネットをデフォルトで拒否し、厳格にスコープされた例外のみを許可する。

開発者ワークフローに対して、パッケージ・レピュテーション検査とマルウェア検出を実装することが推奨される。それにより、Webhook ベースの情報漏洩パターンが侵入する前に阻止できるようになる。

Indicators of Compromise (IoCs):
IDTechnique Name
T1005Data from Local System
T1016System Network Configuration Discovery
T1020Automated Exfiltration
T1033Account Discovery
T1059Command and Scripting Interpreter
T1059.006Command and Scripting Interpreter: Python
T1059.007Command and Scripting Interpreter: JavaScript
T1071.001Application Layer Protocol: Web Protocols
T1082System Information Discovery
T1119Automated Collection
T1195.002Supply Chain Compromise: Compromise Software Supply Chain
T1552.001Unsecured Credentials: Credentials In Files
T1567Exfiltration Over Web Service

問題の原因はパッケージ供給チェーンと、配布メカニズムの設計上の弱点にあるように感じます。ハードコードされた Webhook URL やインストール時フックが、そのままデータ送信の経路となり、TLS 経由で正当トラフィックに紛れることで、境界防御が容易に回避されてしまうようです。さらに、同一アクターが複数のエコシステムで同手法を使うため、一度の侵入が広範囲な情報流出につながる構造的な問題があると、この記事は指摘しています。よろしければ、Discord で検索も、ご参照ください。