偽のGitHubプロジェクトによるGitVenomキャンペーンの詳細分析と対策

近年、オープンソースコードの普及により、開発者は迅速なプロトタイピングや効率的な開発を実現しています。しかし、その一方で、GitHub などのコード共有プラットフォームは攻撃者にとっても魅力的な標的となりつつあります。特に、Kaspersky の Securelist が報告した GitVenom キャンペーン では、攻撃者が偽の GitHub リポジトリを多数作成し、一見有用に見えるツール群を装いながら、実際はマルウェアを拡散しています。これらのリポジトリには、認証情報や暗号通貨ウォレットのデータ、さらにはシステムへのリモートアクセスを実現するためのバックドアなど、極めて危険なペイロードが埋め込まれています。さらに、npm で提供される Node.js のパッケージにおいても、postinstall スクリプトや依存関係を悪用した仕掛けが散見され、開発環境や実稼働システムへの侵入リスクが高まっています。今回の記事では、GitVenom キャンペーンにおける複数のプログラミング言語での悪意のあるコードの埋め込み手法を中心に、攻撃者がどのように正規プロジェクトを偽装し、利用者を狙っているのかを詳細に解説します。これにより、開発者はコード取得時のチェックポイントや、npm などのパッケージ管理システムに潜むリスクを正確に把握し、防御策を強化する必要性を認識できるでしょう。

GitVenom キャンペーンの攻撃者は、GitHub 上に数百もの偽リポジトリを作成し、魅力的なプロジェクト名で利用者の信頼を獲得しています。例として、Instagram の自動化ツール、Bitcoin ウォレット管理用の Telegram ボット、さらには人気ゲーム「Valorant」向けのハッキングツールなど、多岐にわたるジャンルのプロジェクトが挙げられます。これらのリポジトリは、見た目を正規のプロジェクトに似せるため、以下のような工夫が施されています。

• 整った README.md ファイルの生成
  AI ツールなどを用いて、実際の機能説明や導入手順、利用例が記載され、信頼性を高めるよう仕上げられています。

• コミット履歴の偽装
  タイムスタンプや大量の無意味なコミットを追加することで、活発なプロジェクトに見せかけ、利用者の警戒心を下げる手法が取られています。

• 多言語対応の悪意あるコード
  攻撃者は、対象言語ごとに異なる手口を用いてマルウェアを埋め込んでいます。

各言語における悪意のあるコードの埋め込み手法

• Python のケース
  プロジェクトファイル内に、2000文字以上のタブ文字を含む行を挿入した後、暗号化されたスクリプトを復号して実行するコードが仕込まれています。

  subprocess.run(['pip', 'install', 'cryptography'], stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL)
  subprocess.run(['pip', 'install', 'fernet'], stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL)
  from fernet import Fernet; import requests
  exec(Fernet(b'<暗号化された悪意のあるPythonスクリプト>'))
  

• JavaScript のケース
  プロジェクトのメインファイルから呼び出される悪意のある関数が定義され、Base64 でエンコードされたスクリプトをデコードし、実行する仕掛けが施されています。

  function runPayload() {
      let encoded = "PG1hbGljaW91cyBjb2RlPg==";
      let script = atob(encoded);
      eval(script);
  }
  runPayload();
  

• C, C++, C# のケース
  Visual Studio のプロジェクトファイル内に、ビルド前に実行されるように PreBuildEvent 属性を利用して、悪意のあるバッチスクリプトを隠し、ペイロードの実行を指示する手法が採られています。たとえば、プロジェクトの設定ファイルに以下のような記述が見られます。

  <PreBuildEvent>malicious_script.bat</PreBuildEvent>
  

• Node.js / npm のケース
  近年、攻撃者は npm エコシステムにも目を向け、npm install によって導入される Node.js のモジュールに悪意のあるコードを紛れ込ませる手口を取っています。具体的には、以下のような手法が報告されています。

  • postinstall フックの悪用
    パッケージのインストール後に自動実行される postinstall スクリプト内に、外部サーバーから追加のマルウェアコンポーネントをダウンロードするコードや、システム情報を収集するコードが埋め込まれている場合があります。

    {
      "scripts": {
        "postinstall": "node ./malicious.js"
      }
    }
    

    この malicious.js 内では、ユーザーの認証情報やブラウザ履歴、暗号通貨ウォレットの情報が収集され、7z で圧縮された上、Telegram 経由で攻撃者に送信される仕組みが実装されることも確認されています。

  • 依存関係の乗っ取り
    正規のパッケージに見せかけた上で、他の広く利用されているライブラリの依存関係に紛れ込む形で悪意のあるコードが埋め込まれるケースも散見され、これにより、直接 GitHub からコードを取得しなくとも、npm 経由で広範な感染リスクが生じます。過去には event-stream など、一部で依存関係経由の攻撃が報告されており、今回の GitVenom キャンペーンの手口と共通する部分も見受けられます。

(clickで画像を拡大)

悪意あるペイロードの最終的な目的

いずれのプログラミング言語でも、埋め込まれた悪意のあるコードの最終目的は同じです。攻撃者は、初動段階で偽プロジェクトに紛れ込ませたコードをトリガーとして、管理下の GitHub や外部サーバーから追加の悪意あるコンポーネントをダウンロードし、システム内に常駐させます。具体的には、以下のツールや手法が確認されています。

• Node.js 製の情報窃取ツール
  保存された認証情報、暗号通貨ウォレットのデータ、ブラウジング履歴などを収集し、収集データを .7z 形式で圧縮後、Telegram 経由で攻撃者に送信。

• AsyncRAT および Quasar Backdoor
  リモートからシステムを制御するためのツールとして、後続の操作やデータ窃取の足がかりとして利用されます。

• クリップボードハイジャッカー
  クリップボード内の暗号通貨ウォレットアドレスを監視し、攻撃者が管理するアドレスに置き換えることで、実際に 2024年11月に約 5 BTC（当時約485,000米ドル相当）の詐取が報告されています。

さらに、GitVenom キャンペーンは少なくとも2年前から活動しており、ロシア、ブラジル、トルコなど、世界各国で感染事例が確認されています。攻撃者は、各プログラミング言語ごとに最適な悪意あるコードの埋め込み手法を駆使し、正規のプロジェクトに見せかけた形でシステム内部に潜在的な脅威を仕込むため、開発者やセキュリティ担当者は、これらのサプライチェーン攻撃に対して一層の警戒が必要です。

(clickで画像を拡大)

最新の脅威とLLM支援コード生成に対する包括的対策

GitVenom キャンペーンのように、攻撃者は正規プロジェクトに偽装したリポジトリやnpmパッケージを利用してサプライチェーン攻撃を実施し、システムや認証情報、さらには暗号通貨ウォレットなどの重要資産を狙っています。これまでの攻撃手法に加え、今年は特にLLM（大規模言語モデル）をベースとしたコーディング支援エージェントが盛んです。これにより、AIが自動生成したコードに組み込まれるオープンソースライブラリの安全性チェックが、従来以上に重要な課題となっています。

AI自動生成コードに潜むリスク

• 盲信による危険性
  開発者が「AIがコードを完璧に生成してくれる」と考え、生成されたコードを十分に検査せずにそのまま運用環境へ投入してしまうと、意図せぬ脆弱性や悪意のある依存ライブラリが混入するリスクが高まります。LLM自体は学習データに基づいて生成するため、最新の脅威情報やサプライチェーン攻撃の手法に追随できない場合があります。

• オープンソースライブラリの検査不足
  AIが自動生成したコードは、しばしば多くのオープンソースライブラリや外部依存関係に依存します。しかし、その中に悪意あるコードが仕込まれている場合、生成コード自体に問題がなくても、実行時に脆弱性が発現する恐れがあります。特に、postinstallスクリプトや依存パッケージの乗っ取りは、従来のコードレビューだけでは検出が難しいケースが多く見受けられます。

技術者が講じるべき具体的対策

1. リポジトリ・コードの徹底検証

   • コードレビューの実施:
     自動生成されたコードであっても、必ず人手によるレビューを実施し、難読化された部分や不要な長大な文字列、意図不明な処理がないかを確認する。特に、AI生成コードは人間の目で細部まで精査することが不可欠です。
   • コミット履歴・メタデータの監視:
     GitHub上のリポジトリにおけるコミット履歴、タイムスタンプ、タグの付与状況などに不自然な点がないかをチェックし、偽装されたプロジェクトでないかを判断する。

2. 静的解析と動的検査ツールの活用

   • 静的解析ツールの導入:
     SonarQube、Semgrep、ESLint、npm audit、Snykなどを活用し、コード内の脆弱性や不審な記述、依存関係に潜む問題を自動で検出する。
   • 動的検証環境の構築:
     自動生成コードや新たに導入されたnpmパッケージは、まずサンドボックス環境で実行検証を行い、ネットワーク通信や外部サーバーとの接続、予期せぬ動作が発生していないかを監視する。

3. サプライチェーンセキュリティの強化

   • 依存関係の厳格な管理:
     package-lock.json や yarn.lock などのロックファイルを定期的に見直し、脆弱性情報を踏まえたアップデートを実施する。公式リポジトリ以外の依存パッケージは、コード署名やハッシュ値による検証を徹底する。
   • サードパーティの信頼性評価:
     利用するライブラリの開発元、更新頻度、コミュニティの評価、既往の脆弱性報告などを事前にチェックし、不審な挙動を示すパッケージの導入を控える。

4. CI/CDパイプラインにおける自動化検査の実装

   • 自動化された脆弱性スキャン:
     CI/CDパイプラインに脆弱性スキャナーや依存関係のモニタリングツールを組み込み、コード変更時やパッケージ更新時に自動で検査を実行する仕組みを導入する。
   • リアルタイムのログ監視:
     SIEMやEDRツールを利用して、実運用環境における不審なネットワーク通信やシステム挙動をリアルタイムで監視し、即時対応ができる体制を整備する。

5. LLMベンダーとの連携とガイドラインの整備

   • 生成コードのセキュリティ評価:
     LLMを提供する各ベンダーは、生成コードにおけるセキュリティ上のリスクや既知の脆弱性についての情報を積極的に公開し、ユーザーが安全に利用できるためのガイドラインを整備すべきです。開発チームは、使用するLLMツールの評価基準や利用ポリシーを明確にし、定期的に見直す必要があります。
   • 内部教育の強化:
     開発者や運用担当者に対して、AI支援ツールのリスク、オープンソース依存の脆弱性、サプライチェーン攻撃の最新事例などについて定期的な研修を実施し、意識の向上を図る。

6. オープンソースコミュニティとの情報共有

   • 脆弱性情報の共有:
     最新の攻撃手法や悪意あるコードの事例について、オープンソースコミュニティやセキュリティ情報共有プラットフォームと連携し、情報の共有・フィードバックを行うことで、全体的なセキュリティレベルを向上させる。
   • ベストプラクティスの策定:
     社内外での成功事例や対策の実践を元に、AI生成コードやオープンソースライブラリ利用時のベストプラクティスを策定し、文書化して運用プロセスに組み込む。

(clickで画像を拡大)

結論

攻撃者は、GitVenom キャンペーンに代表されるように、サプライチェーン全体に対して巧妙な手口を用いることで、従来のセキュリティ対策をすり抜けてきました。これに加え、LLMによる自動生成コードの普及は、開発プロセスにおける効率化と同時に、新たな脅威を内包する要因となっています。「AIがやってくれている」という安心感に頼ることなく、生成されたコードやその依存ライブラリに対して、常に厳格な検査とレビューを実施することが不可欠です。

技術者は、上記の具体的な対策を総合的に実施することで、GitVenomキャンペーンやサプライチェーン攻撃、そしてAI自動生成コードに潜む脆弱性といった複合的なリスクに対抗する体制を整える必要があります。これにより、開発環境および最終プロダクション環境の安全性を高いレベルで確保し、万が一のインシデント発生時にも迅速な対応と被害の最小化が可能となります。