GHAPPIERマルウェアキャンペーンに関連するサプライチェーン攻撃が、正規のnpmパッケージ@dforge-core/dforge-mcpを侵害し、短期間にわたって自己削除型バックドアを配布していたことが判明しました。
今回の事件は2026年9月9日に始まりました。攻撃者はこのパッケージのメンテナーアカウントを約105分間にわたって使用しました。
侵入が始まった時点で、攻撃者はすでにリポジトリのmainブランチにコードをプッシュする権限を持っていました。この権限をどのように取得したのか、正確な手口はいまだ明らかになっていません。
研究者らは、開発者のデバイスが悪意のあるブラウザ拡張機能やnpmパッケージによって感染したのが最も可能性の高いシナリオだと見ています。
こうしたマルウェアはキャッシュされたGit認証情報を窃取し、攻撃者がメンテナーの身元を利用して無関係な他のGitHubリポジトリにアクセスすることを可能にした可能性があります。
この短いアクセス期間中、脅威アクターはプロジェクトにリモートコードローダーを追加しました。さらに3行のコードを変更し、mainブランチへのプッシュが行われるたびにリリースワークフローが起動するようにしました。
その14分後、攻撃者はワークフローを再度改変し、無人での自動公開を可能にしました。悪意のあるパッケージはバージョン0.2.21としてリリースされ、35分38秒間にわたってnpmの最新バージョンであり続けました。
その後メンテナーは変更を差し戻し、クリーンなバージョン0.2.22を公開しました。しかし研究者らは、悪意のあるリリースを取り下げただけでは、バージョン0.2.21をすでにインストールしたユーザーを完全に保護できない可能性があると警告しています。
この悪意のあるnpmリリースには、正当な来歴(provenance)記録が含まれていました。GitHub Actionsを通じてOpenID Connectのトラステッドパブリッシングを利用してビルドされ、そのビルド証明はSigstoreの追記専用透明性ログに今も記録されています。
この証明は攻撃者のコミットを特定できるものであり、つまりセキュリティ機構が破られたり偽造されたりしたわけではありません。むしろ、悪意のあるソースコードからリリースがビルドされたという事実を正確に記録していたことになります。
今回のケースは、ソフトウェアの来歴証明が持つ重要な限界を示しています。来歴証明は成果物がどこで、どのようにビルドされたかを確認することはできますが、信頼されたリポジトリにコミットされたコードそのものが安全かどうかまでは判断できないのです。
このパッケージはトラステッドパブリッシングを利用していたため、攻撃者はnpmトークンを必要としませんでした。GitHubリポジトリへのプッシュ権限が、リポジトリのCIアイデンティティを通じて事実上パッケージの公開権限になっていたのです。
悪意のあるコードは、99KBのファイルの末尾付近にある1行に隠されていたと報告されています。この1行が4段階の感染チェーンを起動していました。最終段階のインプラントは実行直後にディスクから自身を削除するため、ファイルベースの従来型調査を困難にしています。
組織が侵害されたリリースを実行し、システム内を悪意のあるインプラントについて調査しても何も見つからず、誤って「影響を受けていない」と結論づけてしまう可能性があります。
研究者らはまた、別の被害リポジトリで2つ目のペイロードファミリーを発見しており、これが北朝鮮(DPRK)関連activityと結び付けられているPolinRiderキャンペーンとの関連を示している可能性があるとしています。
このキャンペーンは、ファイル全体を置き換えるのではなく、正規の設定ファイルに悪意のあるペイロードを追記する手口を用いていると報告されています。cloudsekによれば、このマルウェアは通常のコマンド&コントロール用ドメインやサーバーに依存していません。
代わりに、Ethereumブロックチェーンからコマンド&コントロール情報を取得します。攻撃者は空のブロックチェーン取引の受取アドレス内に設定データを埋め込むことができ、これにより遮断が困難な強靭な通信チャネルを構築しています。
ANY.RUNを利用して脅威調査を効率化し、手作業の負担を減らしているSOCチームは16,000社以上にのぼります。貴チーム向けに詳しく見る
翻訳元: https://cyberpress.org/ghappier-hijacks-github-repositories/
