脅威アクターが、npmのTrusted Publishing機能を悪用し、正規パッケージを通じてステルス性の高いバックドアを配布するソフトウェアサプライチェーン攻撃キャンペーンにおいて、少なくとも65件の公開GitHubリポジトリを侵害していたことが判明しました。
悪用された悪性パッケージは、MCP関連のnpmパッケージである@dforge-core/dforge-mcpと特定されており、そのメンテナーアカウントは9月9日に約105分間にわたり悪用されました。
攻撃者はまず、パッケージのインストールを破損させるバージョン0.2.20をプッシュした後、実際に機能するローダーを含むバージョン0.2.21を公開しました。
この汚染されたバージョンは、取り下げられるまでの35分38秒間、パッケージの最新リリースとして存在し続けました。
preinstallやpostinstallの段階で実行される一般的なnpmマルウェアとは異なり、GHAPPIERローダーはMCPサーバーが起動された場合にのみ動作する仕組みになっていました。
この遅延実行モデルにより、パッケージのインストール時、依存関係のスキャン時、自動ビルド検証時に発見される可能性が低くなっていました。
悪性バージョンをダウンロードしたものの、パッケージを一度も起動しなかったシステムでは、ペイロードは実行されませんでした。
このキャンペーンは、ソフトウェアの来歴（プロベナンス）検証システムが抱える重大な限界を浮き彫りにしています。
CloudSEKの分析によれば、攻撃者はパッケージのリリースワークフローを改変し、mainブランチへのプッシュがGitHub Actions経由での公開を自動的にトリガーするようにしていました。
その14分後には、npmのOIDCベースのTrusted Publishing機構を利用した無人リリース活動を可能にするため、ワークフローがさらに変更されました。
その結果生成されたパッケージには、Sigstoreの透明性ログに記録された有効なプロベナンス認証が付与されていました。
しかし、この認証が証明するのは、成果物がどこで、どのようにビルドされたかという点のみであり、元となったソースコードの変更が正当なものであったかどうかは証明していません。
つまり、このパッケージは、侵害されたリポジトリの正規のCI/CDワークフローからリリースされたものとして、暗号学的には「検証済み」となっていたのです。
CloudSEKは、「プロベナンスは成果物がどこでビルドされたかを証明するものであり、そのソースが正直に作られたものであるかを証明するものではない」と指摘しています。
今回の事案は、保護されたブランチにプッシュされたあらゆるコードをリリース自動化の仕組みが信頼してしまう場合、リポジトリへの書き込み権限がそのままパッケージ公開権限に直結しかねないことを示しています。
この隠しローダーは、99KBのファイル内にわずか1行のコードとして埋め込まれており、4段階の実行チェーンを開始する仕組みでした。
最終的なペイロードは汎用のリモートシェルを展開し、実行中にディスク上の自身を削除することで、フォレンジック調査による復元をより困難にしていました。
調査担当者はGHAPPIERの活動を追跡し、少なくとも65件の公開GitHubリポジトリ、73件の感染ファイル、22件のアカウントを特定しました。
別の侵害されたリポジトリで発見された2つ目のペイロードは、2026年3月以降OpenSourceMalwareが追跡してきたマルウェアキャンペーン「PolinRider」と完全に一致するものでした。
CloudSEKの研究者らによれば、GHAPPIERと名付けられたこの作戦は、攻撃者がメンテナーのソースリポジトリとCI/CDパイプラインへのアクセス権を獲得した場合、検証済みのnpmプロベナンスであっても悪性リリースに付与され得ることを示しているといいます。
GitHubリポジトリ65件
PolinRiderはこれまで認証情報の窃取活動と関連付けられており、開発者の認証情報が盗まれたことが初期侵入経路であった可能性が高いと考えられます。
CloudSEKは@dforge-core/dforge-mcpのメンテナーアカウントが侵害された正確な経路を特定できませんでしたが、悪性のブラウザ拡張機能または事前にインストールされていたパッケージが開発者のワークステーションに感染していた可能性があると評価しています。
研究者らは、GitHub、npm、あるいはパッケージ自体が直接的に悪用された証拠は見つかっていないとしています。
PolinRiderに関連するコンポーネントは、約0.20ドルの空のイーサリアムトランザクションから設定情報を取得していました。
この設計により、従来型のコマンド&コントロール用ドメインやホスト型の設定サーバーが不要となり、防御側にとってはブロックすべき明確なドメイン、連絡すべきレジストラ、押収すべきサーバーといった手がかりが得られない状態になっています。
一部の研究者はPolinRiderの活動を北朝鮮の攻撃者と関連付けていますが、CloudSEKは独自の調査ではこの帰属を裏付けることはできなかったとしています。
そのため、現時点で得られている証拠は、このマルウェアファミリーとの関連性を示すにとどまり、国家の関与が確定した帰属を示すものではありません。
各組織は直ちに、@dforge-core/dforge-mcpのバージョン0.2.21を参照しているロックファイルを特定し、依存関係をバージョン0.2.22または他の安全性が確認済みのリリースに固定する必要があります。
CloudSEKは、実行の痕跡が目に見える形で残っていない場合であっても、0.2.21を参照するロックファイルのエントリは潜在的な侵害の兆候として扱うべきだと推奨しています。
Microsoftは最近、これに関連するMini Shai-Huludキャンペーンを報告しています。これは、侵害されたnpmパッケージを利用して、Linuxベースのgithub Actions環境からGitHub、AWS、Vault、npm、Kubernetes、1Passwordの認証情報を窃取するものでした。
セキュリティチームは、GitHub Actionsのリリースワークフローについても、トリガーへの不審な変更がないか監査すべきです。特に、mainブランチへのあらゆるプッシュがパッケージ公開を呼び出せるようにする変更には注意が必要です。
Securityupdate alerts
今回の事案では、改変後の自動化の仕組みがバックドア入りパッケージのリリースに使用されるわずか14分前に、ワークフローのトリガーが変更されていました。
今回の攻撃は、敵対者がCI/CD環境、GitHub Actionsトークン、クラウド認証情報、npm公開トークン、Kubernetesシークレット、開発者向けツールを標的とする、より広範なnpmエコシステムへの侵害の流れを踏襲するものです。
メンテナーにとっての教訓は明確です。Trusted PublishingやSLSA準拠のプロベナンスは依然として価値ある管理策ではあるものの、ソースコード管理の侵害、過度に広範なCI権限、レビューされていないリリースワークフローの変更を補うことはできないという点です。
侵害指標（IOC）
| Artefact | SHA-256 |
|---|---|
| Carrier tarball 0.2.21 | e9045b27557e5019fe44a1d5ae4b77714faa65fef883127ca7db85b7970afab4 |
| skills/indexe.cjs | f2c8234c00b1f5b0b135534bf51207dc0239647890b73531996d60c90cf9e866 |
| package.json 0.2.21 | a85c6955ad689aa89eaae8c8b30723935274f069aed044489cfd922b46bcf2f7 |
| Stage 1 dispatcher | c8337c06f4d3e79dd65aca4058b7a32c763468cdc7df76a849c55395d703a40d |
| Stage 2 Linux | 50ed4f880d6d38ee26f410fc6bd9b734e4857b3a94ee6ef152e7e1158bd83153 |
| Stage 2 macOS | bb36446376455c96b574567b7ee849657d8fe15ace897f460ad3fb867be9aafc |
| Stage 2 Windows | cc8502cb19ef30fe2ce68306e800bbb343e5da6799a57a91d1ebb4cb027029a5 |
注: IPアドレスおよびドメインは、意図しない名前解決やハイパーリンク化を防ぐため、意図的に無害化表記（例: [.]）としています。再度有効な形式に戻す作業は、MISP、VirusTotal、SIEMなどの管理された脅威インテリジェンスプラットフォーム内でのみ行ってください。
SOCのアラート調査時間を1件あたり21分短縮。即座に対応できるIOCコンテキストでSOCを強化しましょう: TI Lookupを自社SOCに統合する
翻訳元: https://gbhackers.com/65-github-repositories/
