GitHub を悪用した大規模マルウェア配布キャンペーンの実態

海外のセキュリティ研究者が、GitHub 上で 1万個のリポジトリがトロイの木馬マルウェアを配布 している実態を報告しました(出典)。これは単なるセキュリティインシデントではなく、開発者環境そのものを標的にした組織的な攻撃である点が極めて危険です。

異なる投稿者、異なる名前を持ちながら、数時間ごとに readme ファイルを更新するという共通パターンが、大規模な自動化攻撃であることを強く示唆しています。

この発見のきっかけは、研究者が自身のプロジェクトを検索した際、名前と説明が全く同じのリポジトリが複数見つかったことでした。それらのリポジトリには、数時間前に zip ファイルへのリンクが readme に追加されており、数時間後に削除されるというサイクルが繰り返されていました。

検出パターンから見える手法の巧妙さ

このマルウェア配布キャンペーンが検出困難である理由は、いくつかの工夫にあります。

共通の特徴としては以下の点が挙げられます:

  • 数時間ごとに前のコミットを削除し、新しいコミットをプッシュ
  • readme ファイルのみを更新
  • コミット履歴が他のリポジトリからコピーされている
  • 新規リポジトリであり、フォークではない
  • 投稿者とリポジトリ名が全てユニーク

これらの特徴から、単一のリポジトリを発見しただけではネットワーク全体を特定できない設計になっていることがわかります。GitHub には 5億個以上のリポジトリが存在する中で、研究者は GitHub Archive というサービスを利用 して、数時間ごとに更新されるリポジトリに絞り込むという工夫で大規模スキャンを実現しました。

マルウェアそのものを zip ファイルに外出しすることで、GitHub のスキャン逃れを意図していると考えられます。

zip ファイルの中身は、命令ファイル(Application.cmd や Launcher.cmd)、実行ファイル(loader.exe など)、DLL ファイルから構成されており、VirusTotal でファイル単体をスキャンするとトロイの木馬が検出される状況です。

開発者環境への脅威—ローカル実行環境の危険性

このキャンペーンが特に危険な理由は、GitHub のリポジトリという開発者の信頼できる環境を悪用している という点にあります。

エンジニアの方がプロジェクトを検索した際、名前が似たリポジトリを clone する可能性は十分あります。特にローカル開発環境(自作 PC や開発マシン)での実行を前提とした環境では、マルウェアの実行による被害が直結します。

同様の脅威は他のプラットフォームでも報告されています。例えば Kaspersky が報告した事例では、Steam の Wallpaper Engine を悪用したマルウェアキャンペーンが、ゲーマーの認証情報を盗み、そのアカウントで追加のマルウェアを配布するという自己増殖型の攻撃が展開されていました(出典)。

ローカル LLM や Stable Diffusion など、開発環境での実行が増える中で、無関係なプロジェクトをダウンロードして実行する行為は今後さらにリスク源となる可能性があります。

対策の重要性—開発プロセスへのセキュリティ組み込み

この脅威に対抗するため、開発者の方が取るべき対策は以下の通りです。

対策項目 実装方法 効果
リポジトリの真正性確認 スター数・投稿者の履歴・最終更新日を確認 フェイクリポジトリを見分ける
コミット履歴の審査 readme の更新内容、削除パターンを確認 異常なパターンを検出
zip ファイルの取得抑止 readme のリンク先を無視、代わりに git clone を使用 マルウェアペイロードを回避
サンドボックス環境での実行 仮想環境や docker コンテナで初回実行 本体環境への侵入を防止
VirusTotal の活用 怪しいファイルを事前にスキャン 既知の脅威を検出

GitHub support への報告から削除まで約1ヶ月かかった点を考えると、報告者個人の努力と自動化スクリプトなしには検出さえ困難という現実があります。

これは GitHub を含むプラットフォーム側の課題でもあります。トロイの木馬を含む zip ファイルへのリンク挿入を検出する自動フィルタリング、またはマルウェアリサーチャー向けの報告チャネルの強化が急務と言えます。

今後の展望—開発環境のセキュリティ化

この大規模キャンペーンが示すのは、攻撃者が開発者環境を明確に標的にしている、ということです。クラウドインフラの普及に伴い、開発チームが扱う認証情報やアクセストークンの価値は飛躍的に上がっています。GCP や AWS のトークンを奪取されれば、クラウドリソース全体が危険にさらされます。

今後の対策は、個々の開発者のリテラシー向上だけではなく、CI/CD パイプラインへのセキュリティスキャン統合、コード署名の強制、サプライチェーン攻撃(Software Supply Chain Attack)を想定した組織的な対応が必須になるでしょう。また GitHub 側も、リポジトリの自動削除パターンの検出や、マルウェア関連キーワードの自動フラグ付けなど、より積極的な防御姿勢を求められる段階に入ったと感じます。