結論から言うと、Red Hat npm Miasma credential-stealing campaignで最初に確認すべきなのは、「対象パッケージを使っていたか」だけではありません。@redhat-cloud-services 配下の影響版をCI/CDや開発端末でインストールした可能性がある場合、GitHub、npm、Azure、AWS、GCP、Vault、Kubernetes、SSH鍵などの認証情報が露出した前提で調査する必要があります。
Microsoft Threat Intelligenceは、@redhat-cloud-services 配下の32パッケージ、90を超えるバージョンに悪意ある変更が入った大規模なnpmサプライチェーン攻撃としてこのキャンペーンを報告しています。攻撃は、正規のGitHub Actions OIDC公開フローを悪用し、正規に見えるprovenance署名を伴って悪性パッケージを公開していた点が特に重要です。(Microsoft)
一方で、Red Hatは2026年6月3日に更新した公式情報で、影響を受けたパッケージはHybrid Cloud ConsoleのWebインターフェースで使われるフロントエンドJavaScriptライブラリであり、侵害期間中にHybrid Cloud Consoleのリリースは行われていないと説明しています。また、Azure Red Hat OpenShift、OpenShift Dedicated、ROSAなどのRed Hat管理クラウドサービスとは関係しないとも説明しています。(Red Hat Customer Portal)
Microsoft公式情報で押さえるべき変更点
今回の情報は、Microsoft製品の新機能追加ではなく、Microsoft Securityによる脅威分析と防御ガイダンスの更新です。管理者や開発者にとっての変更点は、「npmパッケージの信頼性を名前や署名だけで判断できない」ことが改めて明確になった点にあります。
| 観点 | これまで見落とされがちな判断 | 今回確認すべきポイント |
|---|---|---|
| パッケージ名 | 正規スコープなら比較的安全 | 正規の @redhat-cloud-services スコープでも侵害版が公開された |
| provenance署名 | 署名があれば安心 | 侵害されたCI/CDから公開されると、正規に見える署名が付く場合がある |
| npm install | 依存関係を取得するだけ | preinstall が自動実行され、アプリを起動しなくても感染し得る |
| 影響調査 | package.json の直接依存だけを見る | lockfile、CIログ、キャッシュ、ビルド成果物、開発端末まで確認する |
| 対応範囲 | パッケージ更新で終わり | 認証情報のローテーション、GitHub監査、クラウド権限の棚卸しが必要 |
Microsoftの分析では、悪性パッケージはインストール時にnpmの preinstall フックを使って難読化された4.29MBのドロッパーを実行し、Bunランタイムをダウンロードしたうえで第2段階のペイロードを動かしていました。対象はLinux、macOS、Windowsに及びますが、特にLinuxのCI/CDランナーが主要な標的とみられています。(Microsoft)
何が危険だったのか
この攻撃の危険性は、単に「悪意あるnpmパッケージがあった」という話にとどまりません。攻撃者は、開発者やCI/CD環境にある認証情報を盗み、さらに信頼済みパッケージを再公開することでワームのように拡散しようとしていました。
Microsoftの報告では、ペイロードはGitHub、npm、AWS、Azure、GCP、HashiCorp Vault、Kubernetes、CircleCI、SSH鍵、CLI認証情報、ブラウザデータ、ウォレットファイルなどを対象にしていました。Azureについては、management.azure.com、graph.microsoft.com、Key Vault向けのIMDS OAuth2トークン収集が挙げられています。(Microsoft)
特に注意すべき攻撃の流れ
| 段階 | 内容 | 実務上の意味 |
|---|---|---|
| インストール時実行 | preinstall により npm install 中に自動実行 | アプリを起動していなくても影響を受ける |
| Bunランタイム悪用 | Node.jsからBunへ処理を移す | Node.js前提の監視だけでは見落とす可能性がある |
| CI/CDメモリの探索 | GitHub Actions Runner.Workerのメモリからシークレットを探索 | GitHub Actionsのマスク表示だけでは守れない |
| 権限昇格 | passwordless sudoの設定を試みる | self-hosted runnerでは被害が深くなる可能性がある |
| 外部送信 | GitHubリポジトリ作成やコミットを悪用 | 通常のC2ブロックだけでは検知が難しい |
| 自己拡散 | npmパッケージを再公開し、provenanceを偽装 | downstream依存先にも被害が広がる |
特に「署名があるから安全」「GitHub Actionsで正式にpublishされたから安全」という判断は危険です。今回のケースでは、正規の公開ワークフローが悪用され、悪性パッケージが本物らしく見える形で配布されていました。(Microsoft)
影響を受ける可能性がある組織
影響確認の対象は、Red Hatのサービス利用者だけではありません。自社プロジェクト、社内ツール、CI/CD、サンプルコード、検証環境のいずれかで @redhat-cloud-services 配下のnpmパッケージをインストールしていた場合は確認対象です。
| 対象 | 確認すべき理由 |
|---|---|
| ReactやNode.jsを使う開発チーム | @redhat-cloud-services のUI部品やAPIクライアントを直接・間接依存している可能性がある |
| GitHub Actions利用チーム | Actionsシークレット、OIDCトークン、公開権限が狙われた |
| self-hosted runner運用チーム | ランナー上の環境変数、クラウド認証情報、SSH鍵が残っている可能性がある |
| Azure利用組織 | Azure IMDS、Microsoft Graph、Key Vault関連トークンが収集対象に含まれていた |
| npmパッケージ公開者 | 盗まれたnpm権限で別パッケージが再公開される可能性がある |
| Microsoft Defender XDR利用組織 | Defenderの検知、Threat Analytics、Advanced Huntingで調査できる可能性がある |
Red Hatは、現在の調査結果に基づき顧客側で必要な対応はないと説明しています。ただし、これはRed HatのHybrid Cloud Consoleや管理クラウドサービスに関する説明です。自社の開発環境やCI/CDで該当npmパッケージを利用していた場合は、自社側の調査を省略すべきではありません。(Red Hat Customer Portal)
まず確認すべき依存関係
Microsoftの影響リストには、types、frontend-components、rbac-client、host-inventory-client、compliance-client、patch-client、hcc-pf-mcp、hcc-feo-mcp、hcc-kessel-mcp など、@redhat-cloud-services 配下の多数のパッケージが含まれています。公式リストには32パッケージと各悪性バージョンが掲載されていますが、実務ではまずスコープ単位で検索するのが安全です。(Microsoft)
package.jsonとlockfileを検索する
Linux、macOS、WSLでは、リポジトリ直下で次のように検索します。
grep -R "@redhat-cloud-services/" package.json package-lock.json npm-shrinkwrap.json pnpm-lock.yaml yarn.lock 2>/dev/nullPowerShellでは次のように確認できます。
Select-String -Path package.json,package-lock.json,npm-shrinkwrap.json,pnpm-lock.yaml,yarn.lock -Pattern '@redhat-cloud-services/' -ErrorAction SilentlyContinuepackage.json に直接書かれていなくても、lockfileに含まれていれば間接依存としてインストールされていた可能性があります。特にCIでは npm ci によりlockfileどおりに依存関係が復元されるため、lockfileの確認を優先してください。
node_modulesとCIキャッシュも確認する
過去にインストールされた依存関係が、CIキャッシュ、Dockerレイヤー、開発端末の node_modules、社内npmプロキシに残っている場合があります。
find node_modules/@redhat-cloud-services -maxdepth 2 -name package.json -print 2>/dev/nullCI/CDでは、パッケージ名だけでなく次の痕跡も確認します。
| 確認場所 | 見るべき内容 |
|---|---|
| CIログ | preinstall、bun、bun run、@redhat-cloud-services の出力 |
| lockfile | 悪性バージョンが解決されていないか |
| npmキャッシュ | 侵害期間中に取得したtarballが残っていないか |
| Dockerイメージ | 影響版を含んだままビルドされていないか |
| self-hosted runner | /tmp 配下の不審なBun実行、資格情報ファイル、改変された設定 |
Microsoftは、依存関係ツリーの直接・間接利用、影響版をインストールまたはビルドしたシステム、lockfile、ビルドログ、artifact provenanceを確認するよう推奨しています。(Microsoft)
管理者がすぐ行うべき対応
影響が疑われる場合は、「パッケージを更新してから考える」のではなく、調査範囲を固定し、認証情報の流出を前提に封じ込める順序で対応します。
| 優先度 | 対応 | 失敗しやすいポイント |
|---|---|---|
| 高 | 該当CIジョブとself-hosted runnerを一時停止する | 先に再ビルドすると、残った認証情報で再感染や追加流出が起きる可能性がある |
| 高 | GitHub、npm、クラウド、Vault、Kubernetes、SSH鍵をローテーションする | GitHubのトークンだけを変えて、AzureやKey Vault権限を見落とす |
| 高 | lockfileとCIログを保全する | npm update で証跡が上書きされ、どの版を使ったか分からなくなる |
| 中 | 既知の安全なバージョンへ固定する | latest への自動更新だけに頼る |
| 中 | CIキャッシュ、Dockerレイヤー、npmキャッシュを破棄する | クリーンビルドしたつもりで古いキャッシュを再利用する |
| 中 | GitHubの不審な公開リポジトリやコミットを監査する | 個人アカウント側のリポジトリ作成を見落とす |
| 中 | Microsoft Defender XDRで横断調査する | エンドポイントだけを見て、クラウドアプリやIDの異常を見ない |
Microsoftは、GitHubチームが該当するnpmトークンを無効化した後も、影響を受けた可能性のある認証情報、npmアクセストークン、CI/CDシークレット、クラウド認証情報をローテーションすることを推奨しています。また、GitHub上に「Miasma: The Spreading Blight」という説明を持つ公開リポジトリや、予期しないリポジトリが作られていないか監査することも推奨しています。(Microsoft)
Microsoft Defender XDRで確認すべき設定と検知
Microsoft環境では、Defender製品群を使ってエンドポイント、ID、クラウドアプリ、開発環境を横断的に調査できます。Microsoftは、Microsoft Defender Antivirusのクラウド提供の保護を有効化すること、Microsoft Defender XDRやMicrosoft Defender Vulnerability Managementを使って調査することを推奨しています。(Microsoft)
| 確認項目 | 管理者が見るべきポイント |
|---|---|
| Microsoft Defender Antivirus | クラウド提供の保護が有効か |
| Microsoft Defender for Endpoint | Node.jsからBunを起動する不審なプロセス、資格情報アクセスの検知 |
| Microsoft Defender XDR | エンドポイント、ID、クラウドアプリのインシデント相関 |
| Defender Vulnerability Management | redhat-cloud-services パッケージの利用有無 |
| Defender for Cloud Apps | GitHub APIによる不審なリポジトリ作成、異常なコミット量、通常と異なる場所からの認証 |
| Microsoft Security Copilot | 利用権限がある場合、インシデント調査や脅威ハンティングの支援 |
Microsoftの検知例には、Trojan:JS/ShaiWorm.DAW!MTB、Trojan:JS/ObfusNpmJs、不審なNode.jsプロセス、不審なBunランタイム導入、Kubernetes secrets列挙、GitHub APIの不審利用などが含まれます。Microsoft Defender XDR利用者は、DefenderポータルのThreat Analyticsレポートも参照できます。(Microsoft)
Advanced Huntingでの確認例
Microsoftの公式情報では、Bunの一時ディレクトリ実行、Bunのダウンロード、npmからNode.js、Bunへつながるプロセスチェーン、クラウドメタデータエンドポイントへのアクセスなどを確認するKQL例が示されています。以下は調査時に使いやすい形に整理した例です。(Microsoft)
DeviceProcessEvents
| where FileName in~ ("bun", "bun.exe") or ProcessCommandLine has "bun run"
| where FolderPath startswith "/tmp/" or FolderPath has @"\AppData\Local\Temp"
| project Timestamp, DeviceName, AccountName, InitiatingProcessFileName, ProcessCommandLine, FolderPath
| sort by Timestamp descDeviceNetworkEvents
| where RemoteIP in ("169.254.169.254", "169.254.170.2")
| where InitiatingProcessFileName in~ ("node", "node.exe", "bun", "bun.exe")
| project Timestamp, DeviceName, RemoteIP, RemoteUrl, InitiatingProcessFileName, InitiatingProcessCommandLine
| sort by Timestamp desc最初のクエリは、通常の開発フローでは説明しにくい一時ディレクトリ上のBun実行を探すものです。2つ目は、Node.jsやBunプロセスがクラウドメタデータエンドポイントへアクセスした痕跡を探します。Azure VM、コンテナ、self-hosted runnerでクラウドIDを使っている場合は特に確認してください。
開発者が見直すべきnpm運用
今回の攻撃では、アプリケーションコードを実行する前に npm install の段階で悪性コードが動きます。そのため、依存関係の導入手順そのものを見直す必要があります。
緊急時はinstall scriptsを止めて検証する
Microsoftは、検証が完了するまで自動的な依存関係アップグレードを避け、可能な場合は既知の安全なパッケージバージョンに固定し、npm install 時に --ignore-scripts を使ってpreinstallやpostinstallの実行を無効化することを推奨しています。(Microsoft)
npm ci --ignore-scriptsただし、--ignore-scripts は万能ではありません。正当なパッケージでもインストール時スクリプトを使う場合があり、ビルドやテストが失敗することがあります。恒久対策としては、単にスクリプトを全面禁止するのではなく、次のような運用に寄せるのが現実的です。
| 対策 | 実務での使い方 |
|---|---|
| lockfile固定 | CIでは npm ci を使い、レビュー済みのlockfileだけを反映する |
| 自動更新の一時停止 | インシデント対応中はDependabotなどの自動マージを止める |
| install scriptsの制限 | 初回検証や本番ビルドでは --ignore-scripts を使い、必要なスクリプトだけ個別に許可する |
| CIの最小権限化 | build jobにpublish権限、クラウド管理権限、長期トークンを持たせない |
| runnerの使い捨て化 | 可能な限りephemeral runnerを使い、ジョブ後に環境を破棄する |
| provenanceの過信を避ける | 署名やSLSAだけでなく、公開元CIの権限と変更内容を確認する |
AzureやMicrosoft 365管理者が確認すべきポイント
この攻撃はnpmの問題ですが、Microsoft環境にも影響が及ぶ可能性があります。AzureやMicrosoft 365を使っている組織では、CI/CDに渡している権限を中心に確認してください。
| 確認対象 | チェック内容 |
|---|---|
| Azure Managed Identity | self-hosted runnerやVMに不要なロールが付いていないか |
| Microsoft Entra IDアプリ | クライアントシークレット、証明書、フェデレーション資格情報が不要に広く使われていないか |
| Key Vault | CI/CDから読めるシークレットの範囲が広すぎないか |
| Azureサブスクリプション | ビルド用IDにContributor以上の権限を常時付与していないか |
| GitHub Actions OIDC | sub、branch、environmentなどの条件が緩すぎないか |
| GitHub Secrets | 組織全体に共有されたシークレットが不要なリポジトリから参照可能になっていないか |
特に、ビルド用IDに本番環境のKey Vault読み取り権限やサブスクリプション全体のContributor権限を付けている構成は危険です。攻撃者がCIランナー上でクラウドトークンを取得できると、パッケージ侵害がクラウド侵害へ広がる可能性があります。
安全な移行・展開の進め方
影響が疑われるプロジェクトでは、次の順序で安全な状態へ戻します。
| フェーズ | 作業 | 判断基準 |
|---|---|---|
| 封じ込め | 該当CIジョブ、runner、公開ワークフローを一時停止 | 影響版をインストールした可能性がある環境を増やさない |
| 証跡保全 | lockfile、CIログ、runnerログ、GitHub監査ログを保存 | 後からインストール時刻と取得バージョンを追える |
| 依存関係修正 | 影響版を除外し、既知の安全なバージョンへ固定 | lockfile上から影響版が消えている |
| 認証情報更新 | GitHub、npm、Azure、Vault、Kubernetes、SSH鍵を更新 | 古いトークンでAPIアクセスできない |
| クリーンビルド | 新しいrunner、破棄済みキャッシュ、検証済みlockfileで再ビルド | 古い node_modules やDockerレイヤーを再利用していない |
| 展開後監視 | Defender XDR、GitHub監査ログ、クラウド監査ログを確認 | 不審なrepo作成、Bun実行、メタデータアクセスがない |
ここで重要なのは、パッケージ修正より先に認証情報を整理することです。影響版が実行された後に同じrunnerや同じシークレットで再デプロイすると、修正済みビルドでも侵害済み資格情報が残る可能性があります。
よくある疑問
インストールしただけでも影響を受けるのか
受ける可能性があります。今回の悪性コードはnpmの preinstall フックで動くため、アプリケーションを起動していなくても、npm install や npm ci の段階で実行され得ます。直接依存だけでなく、推移的依存として解決された場合も確認対象です。(Microsoft)
Red Hatのクラウドサービス利用者も対応が必要か
Red Hatは、Hybrid Cloud Consoleのリリースは侵害期間中に行われておらず、該当パッケージはAzure Red Hat OpenShift、ROSA、OpenShift Dedicatedなどの管理クラウドサービスとは関係しないと説明しています。したがって、Red Hatサービス利用だけで直ちに自社CI/CDが影響を受けるとは限りません。ただし、自社プロジェクトで該当npmパッケージを使っていた場合は別問題です。(Red Hat Customer Portal)
provenance署名やSLSAを使っていれば安全か
それだけでは不十分です。今回の攻撃では、侵害されたCI/CD公開フローを通じて、正規に見えるprovenanceを持つ悪性パッケージが公開されました。署名やSLSAは重要ですが、CI/CDの権限、公開ワークフロー、トークン管理、依存関係レビューと組み合わせて使う必要があります。(Microsoft)
Windows開発端末は関係ないのか
関係する可能性があります。Microsoftは、ペイロードがLinux、macOS、Windowsで動作するように各プラットフォーム向けのBunランタイムを動的に取得していたと説明しています。ただし、主な標的はLinuxのCI/CDランナーとみられています。(Microsoft)
まず今日やるべきこと
今回のRed Hat npm Miasma credential-stealing campaignでは、被害確認を「依存パッケージの有無」だけで終わらせないことが重要です。まず、全リポジトリのlockfileで @redhat-cloud-services/ を検索し、該当するCI/CD実行履歴を洗い出してください。次に、影響が疑われるrunnerや開発端末を特定し、GitHub、npm、Azure、Vault、Kubernetes、SSH鍵などの認証情報をローテーションします。
Microsoft Defender XDRを利用している組織は、Threat Analytics、Advanced Hunting、Defender Vulnerability Managementを使い、Bunの不審実行、クラウドメタデータエンドポイントへのアクセス、GitHubでの不審なリポジトリ作成を確認しましょう。
最後に、今後の対策として、CI/CDの最小権限化、ephemeral runnerの採用、lockfileレビュー、install scriptsの制御、GitHub OIDC条件の厳格化を進めることが現実的です。今回の教訓は、サプライチェーン攻撃では「信頼できる名前」よりも「インストール時に何が実行され、どの認証情報に届くか」を基準に設計する必要がある、という点です。
コメント