情報窃取ワーム「Shai-Hulud」の探索対象が469箇所へ拡大、AIツール設定や開発環境を標的に

要点

• セキュリティ企業GitGuardianの調査により、情報窃取型ワーム「Shai-Hulud」の新型亜種が469箇所もの認証情報保存場所をスキャンすることが判明した。

• 以前の亜種がスキャンしていた189箇所から探索範囲が大幅に増加し、CLIキャッシュやIDE、AI開発ツールの設定ファイルまで対象が広がっている。

• 攻撃者はシステムの信頼関係を直接破壊するのではなく、正規の認証情報を奪取してソースコードやクラウド、パッケージ公開権限へとアクセスを連鎖させている。

• 恒常的な公開用トークンの悪用を防ぐため、OIDCなどを活用した短寿命な認証方式の導入や、セキュリティ境界を横断したシークレット管理が求められている。

• 2026年8月上旬、セキュリティ企業のGitGuardianに所属する研究チームは、情報窃取型ワーム「Shai-Hulud（シャイ・フルード）」の新たな亜種を確認したと報告した。この亜種は、開発環境やCI/CD（継続的インテグレーション／継続的デプロイ）ツール、クラウド設定、AIツールの構成情報など、計469箇所に存在する認証情報をスキャンするよう進化しているという。従来の189箇所から探索範囲が大幅に広がっており、開発エコシステムにおける認証情報を直接狙う攻撃の拡大が浮き彫りになっている。

189箇所から469箇所へ急増したスキャン対象

GitGuardianの調査によると、Shai-Huludは感染した環境内で利用可能な認証情報を網羅的に探索するよう設計されている。初期の亜種では189のパスを調べていたが、今回の亜種ではその対象が469箇所へと大幅に拡張された。

現代の開発環境には、ソースコードの保管場所以外にも多岐にわたる認証情報が存在している。従来の攻撃でも狙われやすかった環境変数ファイル（.env）やシェルの実行履歴、パッケージマネージャーの設定ファイルに加え、今回の亜種ではCLI（コマンドラインインターフェース）ツールのキャッシュやCI/CDの構成ファイル、統合開発環境（IDE）の設定、さらにはAI開発ツールの構成ファイルに含まれるアクセスキーまでもが収集対象となっている。

攻撃者はあらかじめ特定の重要な認証情報を絞り込んで狙うのではなく、まず手当たり次第に取得可能な情報を集め、その後に個々の認証情報がどのシステムへのアクセス権を持つかを判別しているとみられる。

認証情報の窃取から始まるサプライチェーン攻撃の連鎖

Shai-Huludは、単に端末内の情報を盗み出すだけでなく、侵害した環境から次の攻撃先へと侵入を広げるサプライチェーン攻撃の連鎖を生み出している。

ソフトウェアサプライチェーンは、パッケージレジストリやオープンソースのメンテナー、ビルド時に取得する依存関係など、各構成要素間の信頼関係の上に成り立っている。Shai-Huludのようなマルウェアを操る攻撃者は、これらの信頼関係自体を破壊するのではなく、その関係性を支える正規の認証情報や常時付与された権限そのものを悪用している。

端末内で見つかったトークンを足がかりにソースコードへアクセスし、そのソースコード内に含まれるクラウド認証情報を用いてインフラ環境へ侵入する。さらに、GitHubのトークンを利用して他のリポジトリへの書き込み権限を得たり、パッケージ公開用の認証情報を使って正規の配信ルートからソフトウェアを公開したりといった連鎖が発生する。このように、盗まれた認証情報が新たな環境への侵入をつなぐ結節点として機能している。

パッケージ公開権限の保護と短寿命トークンの重要性

収集される認証情報の中でも、パッケージを公開・配信するための権限は特に大きな脅威をもたらす。公開用のトークンが悪用されると、他の開発者やビルドシステム、利用組織が自動的に取り込む信頼されたパッケージを通じて、マルウェアが自動的に拡散されることになるためだ。

こうした事態を防ぐため、防御側では恒常的に有効な公開用トークンへの依存を減らすことが最優先事項となっている。OpenID Connect（OIDC：外部サービス間で安全に認証を行うための標準プロトコル）や厳格にスコープが制限された仕組みを活用し、検証済みの短寿命な認証方式を採用することが推奨されている。DockerやGitHub Actionsによる最近のアップデートなど、OIDC連携や「Trusted Publishing（信頼された公開）」の普及に向けた業界の取り組みも進んでいる。また、運用上残さざるを得ない長寿命の公開用トークンについては、極めて機密性の高いインフラと同等に扱う必要があると指摘されている。

セキュリティ境界を横断する認証情報の管理課題

組織内における認証情報の管理には、従来のセキュリティ区分による死角が存在する。セキュリティチームは通常、ソースコード管理、CI/CD、クラウド、エンドポイント（端末）、アプリケーションといった分野ごとに分かれて対策を講じることが多い。

しかし、実際の認証情報はこれらの境界を横断して存在している。1人の開発者が日常の業務の中でGitHub、npm、AWS、Kubernetes、社内API、ビルド基盤など多岐にわたるシステムへの認証を行っており、CI/CDパイプラインも同様に多様な権限を保持している。そのため、端末のローカル環境に保存された単一のファイルが、クラウド環境やパッケージ公開権限といったまったく別の重要リソースへの操作権限を握っているケースが珍しくない。

シークレット管理の成熟度を高める組織においては、単に認証情報がどこで発見されたかだけでなく、その認証情報がどのような権限を持ち、どのシステムへ接続できるのかを把握することが不可欠となっている。