Shai-Hulud 2.0 への対策：やるべき対策と、侵害時の検知ポイントまとめ【セキュア開発技術Blog】

Securityチーム オーナーの松田です。

2025年11月24日に、ふたたびShai-Hulud攻撃が、猛威を振るっています。約700個のパッケージが侵害され、25,000 以上の悪意のあるリポジトリが存在したと言われています。また、12月1日には再び感染が増加し、わずか12時間強で200件以上の新規リポジトリが作成されたようです。非常に長くキャンペーンが継続されている点で引き続き注意が必要です。

本記事では、弊社でも一部進めているShai-Hulud 2.0 への対策についてご紹介したいと思います。

参考：【Wiz: Shai-Hulud 2.0 Supply Chain Attack: 25K+ Repos Exposing Secrets】
https://www.wiz.io/blog/shai-hulud-2-0-ongoing-supply-chain-attack

あわせて読みたい

npmサプライチェーン攻撃Shai-Huludの起点はフィッシング～TOTPの代わりにFIDOで対策を～【セキュア開発… Securityチーム オーナーの松田です。2025年9月に起きたShai-Hulud攻撃とその対策について記事を書きました。皆様のご参考になれば幸いです。 今回の記事概要 2025年9月…

対策概要

対策の基本方針は、以下3つです。

• 長期認証情報の排除
• lock ファイルの強制
• GitHubの設定変更

長期認証情報の排除

Shai-Hulud攻撃にて侵害されると、まず認証情報を窃取されます。例えば、AWSアクセスキーとシークレットアクセスキーをaws cliに設定すると平文で保管されます。AWSアクセスキーとシークレットアクセスキーは、長期認証情報です。窃取されると悪用されてしまいます。

lock ファイルの強制

また、Shai-Hulud攻撃は、マルウェア化されたnpmパッケージをinstallすることで、自身のPCに感染します。そのため、新しいパッケージのバージョンを入れると感染する可能性があります。lockファイルを強制すると、lockファイル作成時点のバージョンで固定されるため、新しいバージョンがインストールされづらくなります。

GitHubの設定変更

最後にGitHubの設定変更です。Shai-Hulud攻撃では、GitHub Actionsを攻撃に利用します。しかし、GitHub Actionsは、使ってないのであればリポジトリごとに無効化することができます。さらに、利用する場合でも、Read権限のみに制限することで悪用を抑えることができます。また、リポジトリのmainブランチに対して、保護、つまりプルリクエストがなければ、mainブランチマージされないという保護をかけることで、新規のGitHub Actionsワークフローの作成を抑制することができます。

ここからは、詳しく見ていきましょう。実際に私たちが実施した対応内容を交えて紹介します。

ローカルPCに対する対策

まずは、ローカルPCに対する対策です。

ローカルPCでの長期認証情報の排除

AWSアクセスキーとシークレットアクセスキー

まず、実施したのは、AWSアクセスキーとシークレットアクセスキーの排除です。

本当に最近、2025年11月19日にAWS CLIの認証をブラウザベースで実現する新コマンド 「aws login」 がリリースされました。ブラウザで認証するだけで、ローカルのAWS CLIが利用できるようになり、AWSアクセスキーとシークレットアクセスキーを使わなくて済みます。認証の有効期限があるので、だいたい次の日には、トークンの有効期限が切れています。

https://aws.amazon.com/jp/blogs/security/simplified-developer-access-to-aws-with-aws-login

AWS IAM Identity Centerを利用している場合は、「aws sso login」が利用可能でしたが、そうでない場合でも、アクセスキーなしにローカルのAWS CLIが利用できるようになるので、これを機に全てのアクセスキーを置き換えました。

なお、この「aws login」はマネージドコンソールのログインを無効化もしくはパスワード変更するとセッション無効化することができます。もし、侵害されたと思っても手動で、無効化できるので、なおいいですね。

GitHubの認証情報

次にGitHubの認証に使うSSH秘密鍵も排除しようと考えました。SSH秘密鍵も長期認証情報です。非常に便利なので好んで使っていましたが、代わりに「gh auth login」を使うことをまず検討しました。

https://cli.github.com/manual/gh_auth_login

しかし、Shai-Hulud 2.0では、攻撃のはじめに「SHA1HULUD」というself hosted runnerを作成します。このself hosted runnerを作成するために、GitHub APIが必要なようですが、「gh auth login」で認証しているとAPIを実行できることを確認しました。ですので、より侵害しやすくなるかもしれません。

「gh auth login」の認証で、gitコマンドも使えますが、この認証は、結局長期認証情報となるトークンをローカルに保管するため、より強い権限の長期認証情報を保管するだけになるかもしれません。通常は、システムの資格情報ストアに安全に保管するのですが、環境によっては平文で保管されてしまいます。そのため、まだ、SSH秘密鍵を使っています。

その他

Azure、GCP、npmなど、その他の認証情報もローカルに長期間保管されるものは、排除しましょう。

ただし、npmについては、TOPページに以下の注意喚起が出ているように、12月9日にclassic tokenが失効され、利用できなくなるようです。なので12月9日以降については認証方法の変更が必要となりそうです。

Security Update: npm classic token creation is now disabled. Existing classic tokens will be revoked on December 9, 2025. Migrate to trusted publishing or granular access tokens to avoid disruption.

参考：【npm】
https://www.npmjs.com/

$ npm ci
$ yarn install --frozen-lockfile
$ pnpm i --frozen-lockfile

ignore-scripts で実行を防止する

新しくパッケージをインストールする場合は、基本的にはそのパッケージおよび依存関係も新しいバージョンが入ります。そのため、Shai-Hulud攻撃のようにパッケージ自体が侵害されて新しいバージョンでマルウェアが公開されるようなケースでは、感染の危険があります。特に、キャンペーン初期には、ゼロディの状態となるため、気づきづらいです。

「npm install <package名> –ignore-scripts」のようにignore-scriptsオプションをつけると、Shai-Hulud攻撃で利用されるpostinstallやpreinstallを抑制できます。つまり、マルウェアがインストールされても、実行されず感染を抑制できます。

例えば、以下のようにignore-scriptsオプション付きでインストールし、auditコマンドやSCAツールでパッケージの脆弱性を確認してから、ignore-scriptsオプションなしでインストールするとよいかと思います。

$ npm install <package名> --ignore-scripts
$ npm audit
$ any sca command
$ npm install <package名>

インストールを遅らせる

さらに、pnpm限定ですが、minimumReleaseAgeも効果的です。このオプションは、侵害されたパッケージをインストールするリスクを軽減するために、新しく公開されたバージョンのインストールを遅らせることができます。pnpmがインストールするまでの最小経過時間（分）を定義します。

minimumReleaseAge: 1440

この例だと、少なくとも 1 日前にリリースされたパッケージのみがインストールできるようになります。

PostHog社の詳細なレポートによると、この機能を使うために、pnpm 10に切り替えられたようです。

参考：【PostHog: Post-mortem of Shai-Hulud attack on November 24th, 2025】
https://posthog.com/blog/nov-24-shai-hulud-attack-post-mortem

npmやyarnをお使いの場合は、同じ効果を Aikido Safe Chain でも得ることができます。

ただし、緊急でアップデートが必要なときに、忘れているとパニックなるので要注意です。（私は、この期間の別の緊急の脆弱性でなりました。。。）

GitHubに対する対策

ここからはGitHubに対する対策を紹介します。主にGitHub Actionsについてです。

Wiz社の調査によると、感染したマシンのうち23%が開発者マシンで、残りの大半はLinuxベースのCI/CDランナーなどのサーバ環境でした。CI/CDにおいても、npm install をします。そのタイミングで感染するようです。感染したCI/CDランナーで最も多いのが、GitHub Actionsです。また、GitHub Actionsは感染後の認証情報搾取にも使われましたので、その抑止も対策に含めたいと思います。

Actions Secretsの長期認証情報の排除

deployのために、Secretsに認証情報を入れているケースがあります。もちろん利用する場合は必要なのですが、この機会に棚卸を実施し、不要なSecretsは削除しましょう。GitHubのPersonal Access Token(PAT)、AWSアクセスキー and シークレットアクセスキー、各種APIキーなど、本当に必要かどうかを見直します。

特に、AWSリソースにActionsからアクセスする場合、OpenID Connectを利用することにより、AWSアクセスキーとシークレットアクセスキーをSecretsに保管する必要がなくなります。

https://docs.github.com/ja/actions/how-tos/secure-your-work/security-harden-deployments/oidc-in-aws

この機会に不要なSecretsを削除しましょう。

GitHub Actionsでもlockファイルを強制する

ローカルPCと同じ内容ですが、「npm ci」を使います。おそらく新しくパッケージをインストールすることはなく、lockファイルもコミットされていれば、「npm ci」で十分だと思います。

GitHub Actionsの無効化

このリポジトリでは、GitHub Actionsを使わないという場合は、無効化しておきましょう。リポジトリのSettings -> Actions -> General から変更可能です。

https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository

無効化しておけば、万が一workflowファイルが作成されたとしても、実行されることはありません。手元の検証では、私が自作したSelf Hosted Runnerは、無効化すると動作しませんでした。

GitHub Actionsのpermissionを限定する

GitHub Actionsを利用している場合は、Permissionを限定します。

下図のようにリポジトリとパッケージの読み取り権限のみとし、さらにActionsからのプルリクエストとその承認を許可しないようにすると、ActionsからWorkflowを勝手に作成されることを抑制できます。

https://docs.github.com/en/actions/tutorials/authenticate-with-github_token#modifying-the-permissions-for-the-github_token

ただし、読み取り権限のみにyamlファイル内で上書きすることが可能です。そのため、読み取り権限のみに限定することは、特に意味はないかもしれません。

なお、プルリクエストを許可しないようにするチェックボックスは上書きできません。

https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#preventing-github-actions-from-creating-or-approving-pull-requests

mainおよびデフォルトブランチの保護

main およびデフォルトブランチに対して、「プルリクエストしないとマージできない」という保護をつけておきましょう。

一人や少人数で開発している場合、プルリクエストに価値を感じないかもしれませんが、余計なソースが混入することを防ぐためにも、プルリクエストとレビューの習慣が必要だと思います。攻撃を防ぐという目的とは別に、この保護は導入した方がよい内容です。

同じくSettings -> Rules -> Rulesets からNew branch rulesetを作成します。Target branchesを指定します。

「Require a pull request before merging」にチェックしましょう。Required approvalsを1にしておくと必ず1人の承認が必要となり、必ずレビューを実施されるようになります。上述のように、GitHub Actionsでプルリクエストとその承認を制限していれば、人間の承認が必要になります。

GitHub ActionsのSecure use reference

 これらの制限は、GitHub ActionsのSecure use referenceを参考にしました。併せてご確認いただくのがよいと思います。

https://docs.github.com/en/actions/reference/security/secure-use

その他のCI/CDランナー

長期認証情報の排除

同じく、不要な長期認証情報の排除をします。特にGitHubのコードをチェックアウトする必要がある場合に、GitHubの長期認証情報であるPersonal access tokens (classic)を使っているかもしれません。この機会に、Fine-grained personal access tokensに変更し、当該リポジトリのみに権限を絞るのはいかがでしょうか？

lockファイルを強制する

CI/CDランナーでもローカルPCと同じ内容ですが、「npm ci」を使っていただけると思います。

侵害されたことを検知する

Shai-Hulud攻撃では、攻撃被害に遭うといくつかのわかりやすい傾向がでます。100%そうなるわけではないようですが、参考にしてください。

変なリポジトリができていないか？

GitHubの認証情報が取られた場合、自分のアカウントにランダムな名前のパブリックリポジトリを作成されます。そのリポジトリに窃取された認証情報が公開されます。

わかりやすく「Sha1-Hulud: The Second Coming」というdescriptionが残ります。

見知らぬworkflowができていないか？

リポジトリを侵害するとGitHub Actionsのworkflowを作成します。discussion.yamlという名前でできるようですが、それ以外にも不審なworkflowができていないか確認しましょう。

リポジトリのActionsタブから確認できます。

なお、上述したActionsの無効化が終了している場合は、Actionsタブが消えますのでご注意ください。

見知らぬRunnerができていないか？

侵害に成功すると、侵害したPCをホストにしたセルフホストランナーが作成されます。その名前が「SHA1HULUD」のようです。リポジトリのSettings -> Actions -> Runnersから、見知らぬRunnerがないか確認しましょう。

侵害されたパッケージを使っていないか？

npmには、「npm audit」という脆弱性チェックコマンドがあります。侵害されたパッケージとバージョンをインストールした場合も検知されると思います。
※脆弱性情報が登録されるまでの期間、例えばキャンペーン初期のゼロデイ段階では検知できない場合もある点には注意が必要です。

さらに、GitHub限定ですが、Dependabot というパッケージの脆弱性をアラートする機能があります。（アラートのみを使います）

また、お使いのSCAツールがあるかもしれません。そういったツールを駆使して、侵害されたパッケージとバージョンを使っていないかチェックしてください。例えば、snykはいち早くShai-Hulud 2.0に対するBlogを掲載されていました。

参考：【Snyk: SHA1-Hulud, npm supply chain incident】
https://snyk.io/jp/blog/sha1-hulud-npm-supply-chain-incident/

被害が確認されたら

まずは、認証情報のローテーションです。AWS、Azure、GCP、npm、GitHubなどの認証情報をローテーションしましょう。同時に、一度全てのセッションを無効化して、とられた認証情報の悪用できないようにしておくといいでしょう。

その後、リポジトリの削除やワークフローの削除、Runnerの削除、パッケージのバージョンアップを実施してください。

まとめ

いかがでしたでしょうか？私たちが現時点でとっている対策の基本方針は、以下3つです。

• 長期認証情報の排除
• lock ファイルの強制
• GitHubの設定変更

特に長期認証情報については、ようやく断捨離できました。この機会にご自身のローカルPCなどの認証情報を見直してみてはいかがでしょうか？

あわせて読みたい

npmサプライチェーン攻撃Shai-Huludの起点はフィッシング～TOTPの代わりにFIDOで対策を～【セキュア開発… Securityチーム オーナーの松田です。2025年9月に起きたShai-Hulud攻撃とその対策について記事を書きました。皆様のご参考になれば幸いです。 今回の記事概要 2025年9月…

【参考サイト】
Wiz: Shai-Hulud 2.0 Aftermath: Trends, Victimology and Impact
https://www.wiz.io/blog/shai-hulud-2-0-aftermath-ongoing-supply-chain-attack
Wiz: Shai-Hulud 2.0 Supply Chain Attack: 25K+ Repos Exposing Secrets
https://www.wiz.io/blog/shai-hulud-2-0-ongoing-supply-chain-attack
Trend Micro: Shai-hulud 2.0キャンペーンがクラウドと開発者エコシステムを標的にhttps://www.trendmicro.com/ja_jp/research/25/k/shai-hulud-2-0-targets-cloud-and-developer-systems.html
PostHog: Post-mortem of Shai-Hulud attack on November 24th, 2025
https://posthog.com/blog/nov-24-shai-hulud-attack-post-mortem
Snyk: SHA1-Hulud, npm supply chain incident
https://snyk.io/jp/blog/sha1-hulud-npm-supply-chain-incident/

この記事を書いた人

株式会社神戸デジタル・ラボ
デジタルビジネス本部　Securityチーム オーナー / 生産技術チーム

神戸大学情報知能工学科卒。2014年にKDLに入社。自社で構築するECサイトのほぼすべてのプロジェクトに関与しながら、多くの開発プロジェクトを経て、現在はSecurityチーム オーナーと全社のセキュア開発を推進する生産技術チームを兼任。開発部門主導のセキュア開発を実践している。
コミュニティ活動として、OWASP Kansaiボードメンバー、アルティメットサイバーセキュリティクイズ実行委員を務める。