Typosquatted npm packagesとは？Microsoft公式情報から見る影響範囲と確認ポイント

Microsoftが公開した「Typosquatted npm packages used to steal cloud and CI/CD secrets」は、Microsoft製品の仕様変更ではなく、npmパッケージを悪用したサプライチェーン攻撃への注意喚起です。結論から言うと、2026年5月28日以降にOpenSearch、Elasticsearch、DevOps、環境設定系に見えるnpmパッケージをインストールした開発端末やCI/CDランナーは、ロックファイル・ビルドログ・ネットワークログ・クラウド認証情報を確認する必要があります。

今回の問題で特に危険なのは、アプリケーションコードからパッケージを読み込まなくても、npm installやnpm ciの途中で悪意ある処理が実行される点です。Microsoftによると、攻撃者はOpenSearchやElasticSearch関連に見える14個のnpmパッケージを短時間で公開し、AWS、HashiCorp Vault、GitHub Actions、npmの認証情報を狙いました。該当パッケージやユーザーはnpmチームへのフィードバック後に削除されたとされていますが、すでにインストール済みの環境、CIのキャッシュ、流出した可能性のあるトークンは別途確認が必要です。(Microsoft)

今回の公式情報で押さえるべきポイント

今回の「Typosquatted npm packages used to steal cloud and CI/CD secrets」は、単に「怪しいnpmパッケージに注意しましょう」という話ではありません。開発環境とクラウド環境の境界が曖昧になっている現場では、npmパッケージのインストールがそのままクラウド認証情報の流出につながる可能性がある、という実務上の警告です。

Microsoftの公式情報では、攻撃者は新規作成したnpmメンテナー名義で14個の悪意あるパッケージを公開しました。これらはOpenSearch、ElasticSearch、DevOps、環境設定ライブラリに見える名前を使い、一部では正規のOpenSearchプロジェクトに見えるリポジトリ情報をpackage.jsonに設定していました。さらに、古くから存在する成熟したパッケージに見せるため、高いバージョン番号も使われていました。(Microsoft)

観点	従来見落としがちな前提	今回見直すべきポイント
npm install	依存関係を入れるだけの操作	インストール時スクリプトでコード実行される可能性がある
package.json	repositoryやhomepageが正しければ安心	メタデータは偽装できるため、名前・作者・公開履歴も確認する
CI/CDランナー	ビルド用なので被害は限定的	AWS、Vault、GitHub Actions、npmトークンが置かれていると影響が大きい
ロックファイル	再現性のためのファイル	侵害パッケージの混入有無を追跡する証跡になる
Defender製品	端末保護だけに使う	Microsoft Defender XDRやVulnerability Managementで横断的に調査する

重要なのは、今回の対応を「該当パッケージを消して終わり」にしないことです。クラウドやCI/CDのシークレットが露出した可能性がある場合、パッケージ削除だけではリスクは残ります。

Typosquatted npm packagesとは何か

Typosquatted npm packagesとは、正規パッケージに似た名前や説明を使い、開発者の入力ミスや思い込みを狙ってインストールさせるnpmパッケージです。今回のケースでは、OpenSearchやElasticSearchのセットアップ支援ツールに見える名前が使われました。

Microsoftが挙げている該当パッケージは以下の14個です。npm上で削除済みでも、package-lock.json、yarn.lock、pnpm-lock.yaml、CIログ、コンテナイメージ、社内npmプロキシのキャッシュに痕跡が残っている場合があります。(Microsoft)

分類	パッケージ名
@vpmdhajスコープ付き	@vpmdhaj/elastic-helper、@vpmdhaj/devops-tools、@vpmdhaj/opensearch-setup、@vpmdhaj/search-setup
OpenSearch/ElasticSearch風の名称	opensearch-security-scanner、opensearch-setup、opensearch-setup-tool、opensearch-config-utility、search-engine-setup、search-cluster-setup、elastic-opensearch-helper、vpmdhaj-opensearch-setup
環境設定ツール風の名称	env-config-manager、app-config-utility

「OpenSearchやElasticsearchを使っていないから関係ない」と判断するのは早計です。env-config-managerやapp-config-utilityのように、一般的な設定管理ツールに見える名前も含まれているため、テンプレートプロジェクト、検証用リポジトリ、一時的なCIジョブに混入していないか確認する価値があります。

何が変わるのか：npm installを安全な前提にしない

今回の公式情報を実務に落とし込むと、最も大きな変更点は「npm installを無条件に信頼しない」運用への転換です。

npmにはライフサイクルスクリプトがあり、npm installやnpm ciの過程でpreinstall、install、postinstallなどが実行されます。npm公式ドキュメントでも、npm ciやnpm install時にこれらのライフサイクルイベントが実行されることが説明されています。(npm ドキュメント)

今回の悪意あるパッケージでは、この仕組みが悪用されました。Microsoftによると、該当パッケージはインストール時フックを持ち、被害者のコード側でrequire()しなくても、インストールされた時点で悪意ある処理が動作します。(Microsoft)

攻撃チェーンの流れ

攻撃は大きく次のように進みます。

段階	内容	管理者・開発者が見るべき痕跡
誘導	正規パッケージに似た名前、偽装されたメタデータ、高いバージョン番号で信頼させる	依存関係の追加履歴、Pull Request、lockfileの差分
実行	preinstallなどのnpmライフサイクルフックでコード実行	npm installログ、CIビルドログ、プロセス実行ログ
第1世代ステージャー	C2へホスト情報を送信し、payload.binを取得・実行	X-Supply: 1ヘッダー、aab.sportsontheweb[.]netへの通信
第2世代ステージャー	正規のBunランタイムをローダーとして悪用し、同梱ペイロードを実行	Node.jsプロセスからのBunダウンロード、setup.mjs、opensearch_init.js
認証情報窃取	AWS、Vault、GitHub Actions、npmの認証情報を探索	AWS CloudTrail、GitHub Actionsログ、npmトークン利用履歴

第2世代では、インストール時に不審なC2通信を発生させず、正規のBunランタイムをダウンロードしてローダーとして使う設計が確認されています。ネットワーク監視だけで検知しようとすると見逃しやすくなるため、プロセス作成、ファイル作成、Bun実行、lockfileの差分を組み合わせて確認する必要があります。(Microsoft)

影響範囲：開発端末だけでなくCI/CDとクラウドまで確認する

今回の攻撃は、npmパッケージの問題でありながら、影響範囲はNode.jsプロジェクト内に閉じません。Microsoftの分析では、ステージ2のペイロードはAWSのIMDSやECSタスクメタデータ、AWS Secrets Manager、HashiCorp Vault、npmトークン、GitHub Actions環境の情報を狙うように作られていました。(Microsoft)

確認対象は次のように広げて考えるべきです。

対象	確認するもの	想定されるリスク
開発者PC	node_modules、npmキャッシュ、ロックファイル、端末のEDR検知	ローカルのAWS認証情報、npmトークン、Vaultトークンの流出
CI/CDランナー	ビルドログ、ジョブ環境変数、ワークスペース、キャッシュ	GitHub Actionsシークレット、クラウドデプロイ権限の悪用
コンテナビルド環境	Docker buildログ、ベースイメージ、レイヤーキャッシュ	侵害済み依存関係を含むイメージの再利用
AWS環境	CloudTrail、STS、Secrets Manager、ECS/EC2メタデータアクセス	権限昇格、横展開、Secrets Manager内のシークレット取得
npm公開アカウント	publish token、所有パッケージ、公開履歴	盗まれたトークンによる後続のサプライチェーン攻撃
GitHubリポジトリ	Actionsの実行履歴、workflow変更、権限設定	リポジトリ改ざん、CI/CDパイプラインの不正操作

特に注意したいのは、CI/CDランナーです。開発者PCよりも高い権限を持つクラウド認証情報やデプロイ用トークンが置かれていることが多く、侵害された場合の影響が大きくなります。

管理者が最初に確認すべきこと

管理者は、まず「2026年5月28日以降に該当パッケージをインストールまたはビルドした環境があるか」を確認します。Microsoftも、同日以降に影響を受けるパッケージバージョンをインストールまたはビルドしたシステムを特定することを推奨しています。(Microsoft)

ロックファイルを検索する

リポジトリ単位で調査する場合は、package-lock.json、yarn.lock、pnpm-lock.yamlを検索します。Windows環境ならPowerShellで次のように確認できます。

$packages = @(
  "@vpmdhaj/elastic-helper",
  "@vpmdhaj/devops-tools",
  "@vpmdhaj/opensearch-setup",
  "@vpmdhaj/search-setup",
  "opensearch-security-scanner",
  "opensearch-setup",
  "opensearch-setup-tool",
  "opensearch-config-utility",
  "search-engine-setup",
  "search-cluster-setup",
  "elastic-opensearch-helper",
  "vpmdhaj-opensearch-setup",
  "env-config-manager",
  "app-config-utility"
)

Get-ChildItem -Recurse -Include package-lock.json,yarn.lock,pnpm-lock.yaml |
  Select-String -Pattern $packages |
  Select-Object Path, LineNumber, Line

LinuxやmacOSの開発環境、CI上では次のように検索できます。

grep -R --line-number -E '@vpmdhaj/elastic-helper|@vpmdhaj/devops-tools|@vpmdhaj/opensearch-setup|@vpmdhaj/search-setup|opensearch-security-scanner|opensearch-setup|opensearch-setup-tool|opensearch-config-utility|search-engine-setup|search-cluster-setup|elastic-opensearch-helper|vpmdhaj-opensearch-setup|env-config-manager|app-config-utility' \
  package-lock.json yarn.lock pnpm-lock.yaml 2>/dev/null

ヒットした場合は、単に依存関係から削除するだけでなく、該当日時に使われていたCI/CDシークレットやクラウド認証情報を洗い出します。

CI/CDログとネットワークログを確認する

Microsoftは、aab.sportsontheweb[.]netへの通信、X-Supply: 1ヘッダー、Node.jsプロセスによるBunランタイムのダウンロード、__DAEMONIZED=1を伴うプロセス実行などを確認ポイントとして挙げています。(Microsoft)

プロキシ、DNS、ファイアウォールで確認すべき主な痕跡は以下です。

痕跡	意味	対応
aab.sportsontheweb[.]netへの通信	第1世代ステージャーのC2通信の可能性	通信元ホストを特定し、端末・CIランナーを隔離対象にする
X-Supply: 1ヘッダー	キャンペーン固有の高確度な検知シグナル	プロキシログで横断検索する
github.com/oven-sh/bun/releases/downloadへのNode.js起点の通信	第2世代ローダーがBunを取得した可能性	正規利用と照合し、ビルド手順にない場合は調査する
payload.bin、setup.mjs、opensearch_init.js、ai_init.js	悪意あるステージャーやペイロードの可能性	EDRで端末横断検索し、該当環境を再構築する
169.254.169.254、169.254.170.2へのNode.js/Bunからのアクセス	AWS IMDS/ECSメタデータ探索の可能性	CloudTrailと合わせて権限利用を確認する

Bunを正規に使っている組織では、Bun関連の検知がすべて悪性とは限りません。普段のビルド手順にBunが含まれているか、Node.jsの依存関係インストール中に突然Bunが呼ばれていないかで判断します。

Microsoft Defenderで確認するポイント

Microsoftは、Microsoft Defender Antivirusが悪意あるコンポーネントを検知・ブロックすること、Microsoft Defender XDRでエンドポイント、ID、クラウドアプリ、開発環境にまたがる調査ができること、Microsoft Defender Vulnerability Managementで影響パッケージを検索できることを案内しています。(Microsoft)

Microsoft Defender XDRを使える環境では、まず以下の観点でAdvanced Huntingを実行します。

DeviceProcessEvents
| where Timestamp > ago(30d)
| where FileName in~ ("node.exe", "node", "npm.cmd", "npm.exe", "npx.cmd", "npx.exe")
| where ProcessCommandLine has_any (
    "@vpmdhaj",
    "opensearch-setup",
    "opensearch-setup-tool",
    "opensearch-config-utility",
    "opensearch-security-scanner",
    "search-engine-setup",
    "search-cluster-setup",
    "elastic-opensearch-helper",
    "vpmdhaj-opensearch-setup",
    "env-config-manager",
    "app-config-utility"
)
| project Timestamp, DeviceName, FileName, ProcessCommandLine,
          InitiatingProcessFileName, InitiatingProcessCommandLine, AccountName

payload.binの存在確認も有効です。

DeviceFileEvents
| where Timestamp > ago(30d)
| where FileName =~ "payload.bin"
| where FolderPath has "node_modules"
| project Timestamp, DeviceName, FolderPath, FileName,
          InitiatingProcessFileName, InitiatingProcessCommandLine, AccountName

Bunランタイムの不審なダウンロードは、次の観点で確認します。

DeviceNetworkEvents
| where Timestamp > ago(30d)
| where InitiatingProcessFileName in~ ("node.exe", "node")
| where RemoteUrl has "github.com/oven-sh/bun/releases/download"
| project Timestamp, DeviceName, RemoteUrl, RemoteIP,
          InitiatingProcessFileName, InitiatingProcessCommandLine, AccountName

上記は調査の入口です。ヒットした端末があれば、同じ時間帯のプロセスツリー、ユーザー、CIジョブ、関連リポジトリ、使用されたシークレットまで追跡します。

開発者が確認すべき設定と運用

開発者側では、依存関係を追加する手順と、npm install時のスクリプト実行を見直します。

ignore-scriptsを検証環境で使う

Microsoftは、npm install --ignore-scriptsまたはnpm config set ignore-scripts trueでpre/post installスクリプトの実行を抑止することを緩和策として挙げています。npm公式ドキュメントでも、ignore-scriptsをtrueにするとpackage.jsonで指定されたスクリプトを実行しないと説明されています。(Microsoft)

ただし、これを全環境で即時適用すると、ネイティブモジュールのビルド、バイナリ取得、コード生成など正当なpostinstallを使うパッケージが壊れる場合があります。おすすめは、次の順番です。

フェーズ	やること	判断基準
調査	CIの検証ジョブでnpm ci --ignore-scriptsを試す	どのパッケージがスクリプトに依存しているかを把握する
分離	依存関係インストールとビルド・テストを別ジョブに分ける	インストール段階でネットワークや権限を最小化できるか
許可制	必要なpostinstallだけを例外として扱う	例外理由、所有者、更新頻度を記録できるか
本番展開	リリース用CIに段階適用する	キャッシュ削除、再現性、ロールバック手順があるか

「ビルドが通らないからignore-scriptsは無理」と考えるのではなく、まずどの依存関係がインストール時実行に依存しているかを棚卸しすることが重要です。

パッケージ名だけで判断しない

今回の攻撃では、パッケージ名、repository、homepage、バージョン番号が信頼感を出すために使われました。つまり、package.jsonのメタデータが正規プロジェクトを指していても、それだけでは安全とは言えません。

新しい依存関係を追加する前に、最低限次を確認します。

npm view <package-name> name version description repository homepage author maintainers time dist-tags
npm view <package-name> scripts

確認すべきポイントは次の通りです。

確認項目	危険な兆候
名前	正規パッケージに似ているが、スコープや単語順が微妙に違う
作者・maintainers	作成直後のアカウント、実績がない、正規組織と関係が確認できない
公開履歴	初回公開なのに高いバージョン番号が付いている
repository	正規リポジトリに見えるが、npmパッケージの所有者と一致しない
scripts	preinstall、install、postinstallで外部通信やバイナリ実行をしている
依存関係	小さな設定ツールなのに不要なネットワーク・実行系依存がある

特にCI/CD環境で使うパッケージは、開発者個人の判断だけで追加せず、レビュー対象にするべきです。

認証情報のローテーションは優先順位を決める

該当パッケージのインストール痕跡がある場合、すべてのトークンを同時に更新しようとすると混乱します。まず、攻撃対象として明示されている認証情報から優先順位を付けます。

優先度	対象	理由
高	npm publish token	盗まれると自社パッケージを悪用した二次被害につながる
高	GitHub Actionsのデプロイ用シークレット	リポジトリ改ざんやCI/CDパイプライン操作に使われる可能性がある
高	AWS IAM/STS関連の認証情報	横展開、Secrets Manager取得、クラウドリソース操作につながる
高	HashiCorp Vaultトークン	他のシークレットへの入口になる
中	開発者ローカルのAWSプロファイルやnpmトークン	端末で該当パッケージを入れていた場合に確認する
中	コンテナレジストリやデプロイ鍵	CI環境変数として渡していた場合に確認する

Microsoftも、影響を受けたランナーや開発端末に露出していた可能性があるAWS IAM/STS、HashiCorp Vault、npm publish、GitHub Actionsトークンのローテーションを推奨しています。(Microsoft)

ローテーション時は、古いトークンを無効化するだけでなく、無効化前後に不審な利用がなかったかを確認します。たとえばnpm公開アカウントなら、想定外のパッケージ公開、所有者変更、トークン作成履歴を確認します。AWSならCloudTrailでsts:GetCallerIdentity、sts:AssumeRole、secretsmanager:ListSecrets、secretsmanager:GetSecretValueの時系列を見ます。

npm publish tokenはOIDCへの移行を検討する

npmパッケージを公開している組織では、長期間有効なnpm publish tokenをCI/CDに保存し続ける運用を見直すべきです。

npmのTrusted Publishingは、CI/CDワークフローからOIDCを使ってnpmパッケージを公開する仕組みで、長期間有効なnpmトークンを不要にできると説明されています。対応プロバイダーにはGitHub Actions、GitLab CI/CD、CircleCIが含まれますが、npm CLI 11.5.1以上、Node 22.14.0以上が必要であり、セルフホストランナーは現時点では未対応とされています。(npm ドキュメント)

移行時の注意点は以下です。

項目	注意点
npm CLIとNode.jsのバージョン	Trusted Publishingの要件を満たすか確認する
CI/CDプロバイダー	GitHub Actions、GitLab CI/CD、CircleCIの対応条件を確認する
セルフホストランナー	現時点の制約に注意し、代替策や段階移行を考える
既存のpublish token	OIDC移行後も残っていると攻撃面が残るため、不要なトークンを削除する
リリース手順	tag作成、レビュー、承認、公開ジョブを分離し、誤公開を防ぐ

GitHub Actionsを使っている場合は、GITHUB_TOKENの権限も見直します。GitHub公式ドキュメントでは、permissionsキーを使ってワークフローまたはジョブ単位でGITHUB_TOKENの権限を変更し、必要最小限の権限を付与することが推奨されています。(GitHub Docs)

たとえば、テストだけのジョブにcontents: writeやpackages: writeは不要です。依存関係をインストールするジョブでは読み取り専用にし、公開やデプロイの権限を持つジョブは承認付きの環境に分けると、被害範囲を狭められます。

AWSやクラウド側で確認すべき設定

今回のペイロードはAWS EC2のIMDS、ECSタスクメタデータ、AWS Secrets Managerを狙う挙動が確認されています。AWS環境を使っている場合は、アプリケーションやCIランナーが不要なメタデータアクセスを持っていないかを確認します。(Microsoft)

AWSの公式ドキュメントでは、EC2インスタンスのメタデータサービスは有効・無効を設定でき、IMDSv2のみを要求する設定も可能です。ただし、IMDSv2を強制したりメタデータアクセスを無効化したりすると、IMDSv1やインスタンスメタデータに依存するアプリケーションやエージェントが動かなくなる可能性があるため、変更前のテストが必要です。(AWS ドキュメント)

確認すべき観点は次の通りです。

確認項目	推奨される考え方
CIランナーのIAMロール	ビルドに必要な最小権限だけにする
Secrets Managerアクセス	全リージョン・全シークレットを読める権限を避ける
EC2 IMDS	不要なら無効化、必要ならIMDSv2必須を検討する
ECSタスクロール	タスクごとに権限を分離し、共有ロールを避ける
CloudTrail	ビルド基盤や開発端末由来の不自然なSTS・Secrets Manager操作を確認する

「CIだから一時的な環境で安全」とは限りません。短時間のランナーでも、実行中にシークレットへアクセスできれば十分に悪用されます。

展開時に失敗しやすいポイント

対策を急ぐほど、運用トラブルも起きやすくなります。特に以下の失敗に注意してください。

失敗しやすい対応	なぜ危険か	正しい進め方
該当パッケージを削除して終了する	すでに認証情報が流出している可能性が残る	削除、ログ調査、トークンローテーションをセットで行う
CIキャッシュを残したまま再ビルドする	node_modulesやnpmキャッシュに痕跡が残る	キャッシュ破棄後、クリーンなランナーで再ビルドする
ignore-scriptsを全環境に即時適用する	正当なビルド処理が壊れる可能性がある	検証環境で依存関係ごとに影響を把握する
Bun通信をすべて悪性扱いする	正規にBunを使うプロジェクトで誤検知が増える	ビルド定義と照合し、Node.js起点の不自然なBun実行を重視する
開発者PCだけ確認する	CI/CDランナーのほうが高権限の場合が多い	端末、CI、クラウド、npmアカウントを一連の経路として調査する
npm auditだけで判断する	悪意あるパッケージ混入の調査には不十分な場合がある	lockfile、ビルドログ、EDR、ネットワークログを併用する

すぐ実施するチェックリスト

まずは次の順番で確認すると、影響範囲を絞り込みやすくなります。

タイミング	実施内容
すぐ	該当14パッケージ名をロックファイル、CIログ、社内npmキャッシュで検索する
すぐ	aab.sportsontheweb[.]netとX-Supply: 1をプロキシ・DNS・Firewallログで検索する
すぐ	Microsoft Defender XDRでNode.js、npm、Bun、payload.bin、__DAEMONIZED=1を横断検索する
24時間以内	ヒットした端末・ランナーに露出していたAWS、Vault、GitHub Actions、npmトークンをローテーションする
24時間以内	CIキャッシュ、コンテナビルドキャッシュ、汚染された可能性のある成果物を破棄する
数日以内	ignore-scriptsの検証、依存関係追加ルール、npm publish tokenのOIDC移行を計画する
継続対応	新規依存関係のレビュー、lockfile差分レビュー、DefenderやSIEMでの検知ルールを標準化する

今回の対応で重要なのは、個別のnpmパッケージ名だけを追うのではなく、「依存関係インストール時に任意コードが動く」「CI/CDに高権限のシークレットが集まりやすい」「盗まれたnpm publish tokenが次のサプライチェーン攻撃に使われる」という流れを断つことです。

まずはロックファイルとCIログを検索し、ヒットがあれば該当環境をクリーンに再構築し、関連するトークンを優先順位付きでローテーションします。そのうえで、ignore-scriptsの段階導入、Microsoft Defender XDRでの継続監視、npm Trusted Publishingによる長期トークン削減まで進めると、今回の攻撃だけでなく次のnpmサプライチェーン攻撃にも備えやすくなります。