結論から言うと、Mastraまたは@mastra/*系のnpmパッケージを、2026年6月中旬以降に開発端末やCI/CD環境でnpm installまたはnpm updateした可能性がある場合は、アプリで実際にimportしていたかどうかに関係なく確認対象です。今回のMastra npm supply-chain compromiseは、インストール時に動くpostinstallが悪用されたため、ソースコード上で該当パッケージを呼び出していなくても、開発端末・ビルドランナー・CI/CDシークレットが影響を受ける可能性があります。(Microsoft)
Microsoft Security Blogでは、この記事は2026年6月17日に「Research」として公開され、6月19日の更新でMicrosoftはこの活動を北朝鮮系の脅威アクターSapphire Sleetに高い確度で帰属するとしています。対象サービスとしてはMicrosoft Defenderが示されており、Microsoft Defender / Microsoft Threat Intelligenceの管理者は、検知状況の確認だけでなく、権限、監査、IOC登録、CI/CDの復旧、開発者への周知まで一連で対応する必要があります。(Microsoft)
まず押さえるべき判断基準：影響は「使ったコード」ではなく「インストールした環境」で見る
今回の注意点は、通常の脆弱性対応のように「該当ライブラリをアプリが実行時に使っているか」だけでは判断できないことです。Microsoftの分析では、侵害されたMastra関連パッケージにeasy-day-jsという悪意あるtyposquatパッケージが依存関係として追加され、npm install時のpostinstallで難読化されたドロッパーが実行されました。つまり、ビルドや依存関係解決の段階でリスクが発生します。(Microsoft)
| 確認対象 | リスク判断 | まず行う対応 |
|---|---|---|
開発端末でmastraまたは@mastra/*をインストールした | 高 | Defenderで端末調査、IOC確認、必要に応じて隔離 |
CI/CDランナーでnpm installまたはnpm updateを実行した | 高 | ランナー再作成、CI/CDログ確認、シークレットローテーション |
package-lock.jsonやnode_modulesにeasy-day-jsがある | 高 | ビルド停止、該当端末・ランナーの調査 |
| リポジトリに依存関係はあるが、該当期間にインストールしていない | 中 | ロックファイルとCI履歴を確認 |
| Mastra系パッケージを使っていない | 低 | 組織内の横断検索だけ実施 |
管理者が最初にすべきことは、Defenderのアラート画面を眺めることだけではありません。開発チームに「該当期間にどの端末・どのランナーでnpm installが実行されたか」を確認し、セキュリティ側ではMicrosoft Defender XDRのAdvanced Hunting、Threat analytics、IOC登録、ネットワーク遮断、認証情報のローテーションを並行して進めます。
Mastra npm supply-chain compromiseで何が起きたのか
Microsoft Threat Intelligenceの分析によると、攻撃はnpmメンテナーアカウントehinderoの乗っ取りから始まりました。このアカウントはMastraエコシステム全体にpublish権限を持っており、攻撃者はMastraおよび@mastraスコープの140以上のパッケージに、dayjsを装った悪意あるeasy-day-jsを依存関係として注入しました。侵害されたバージョンはlatestとして公開され、通常の依存関係更新で取り込まれる可能性がありました。(Microsoft)
Microsoftが示した流れを管理者向けに整理すると、次のようになります。
| 段階 | 起きたこと | 管理者が見るべきポイント |
|---|---|---|
| npmアカウント侵害 | Mastra関連のpublish権限を持つアカウントが悪用された | npm監査ログ、公開元、CI/CD経由でない手動publishの有無 |
| 悪意ある依存関係の追加 | easy-day-js@^1.11.21が追加された | package-lock.json、node_modules、SBOM |
| weaponized版の取得 | SemVerにより[email protected]が解決される可能性 | lockfile、npmキャッシュ、CIログ |
postinstall実行 | setup.cjsが自動実行される | Defenderのプロセスイベント、Node.js実行履歴 |
| C2通信・第2段階ペイロード | C2へ通信し、追加ペイロードを取得 | ネットワークイベント、プロキシログ、FWログ |
| 永続化・防御回避 | Runキー、PowerShellバックドア、Defender除外、サービス永続化など | レジストリ、サービス、Defender設定変更 |
特に危険なのは、攻撃が単なる「悪意あるnpmパッケージの混入」で終わっていない点です。Microsoftは、C2通信が成立した端末ではPowerShellバックドア、永続化、Defender除外の追加、SYSTEMコンテキストでのサービス型インプラントまで観測したと説明しています。(Microsoft)
Microsoft Defender管理者向けの初動チェックリスト
Microsoft Defender / Microsoft Threat Intelligenceの管理者は、次の順番で確認すると抜け漏れを減らせます。ポイントは、セキュリティ部門だけで完結させず、開発チーム、CI/CD管理者、ID管理者を巻き込むことです。
| 優先度 | 確認項目 | 具体的な確認先 | 対応判断 |
|---|---|---|---|
| 高 | easy-day-jsの存在 | package-lock.json、node_modules、npmキャッシュ、CI成果物 | 見つかったらインシデント扱いで調査 |
| 高 | npm install実行端末 | Defender XDR Advanced Hunting、EDR、端末管理台帳 | 該当端末を特定し、必要に応じて隔離 |
| 高 | CI/CDランナーの使用履歴 | GitHub Actions、Azure Pipelines、自己ホストランナー、ビルドログ | 該当ランナーは再作成を優先 |
| 高 | C2通信 | Defenderのネットワークイベント、プロキシ、Firewall、DNSログ | 通信があれば認証情報侵害を前提に対応 |
| 高 | シークレット露出 | npm token、GitHub token、Azure資格情報、クラウドAPIキー | 該当環境のトークンをローテーション |
| 中 | 永続化の痕跡 | Runキー、サービス、system.bat、scdev.dll | 見つかった端末は再イメージを検討 |
| 中 | Defender除外の変更 | Defender設定、変更履歴、管理ポリシー | 不審な除外は削除し、変更者を確認 |
| 中 | Threat Intelligenceの確認 | Threat analytics、Intelligence explorer、Intel profiles | IOCと関連レポートをSOC手順に反映 |
Microsoftは軽減策として、影響を受けた@mastraパッケージの直接・推移的依存関係の確認、easy-day-jsの有無の確認、既知の安全なバージョンへの固定、--ignore-scriptsの利用、IOCの確認、資格情報やトークンのローテーション、C2 IPのブロック、CI/CDログの監査、Defender Antivirusのクラウド提供保護の有効化を挙げています。(Microsoft)
開発端末とCI/CDで確認する具体的な場所
影響範囲の洗い出しでは、まずリポジトリ単位ではなく「インストールが実行された場所」単位で確認します。開発端末、自己ホスト型CIランナー、ビルドコンテナ、npmキャッシュ、Dockerイメージ作成環境が対象です。
リポジトリ側では、次のような確認が有効です。
grep -R "\"easy-day-js\"" package-lock.json npm-shrinkwrap.json pnpm-lock.yaml yarn.lock 2>/dev/null
grep -R "\"@mastra/" package.json package-lock.json pnpm-lock.yaml yarn.lock 2>/dev/null
npm ls easy-day-js端末側では、MicrosoftがIOCとして示している$TMPDIR/.pkg_history、$TMPDIR/.pkg_logs、ホームディレクトリ配下のランダム名JavaScriptファイルなどを確認します。(Microsoft)
Windows端末では、PowerShellで次のように一時フォルダーとユーザープロファイルを確認できます。
Get-ChildItem $env:TEMP,$env:USERPROFILE -Force -Recurse -ErrorAction SilentlyContinue |
Where-Object {
$_.Name -in ".pkg_history",".pkg_logs","system.bat","scdev.dll","protocal.cjs","protocol.cjs" -or
$_.Name -match "^[0-9a-fA-F]{8,}\.js$"
} |
Select-Object FullName, LastWriteTime, LengthLinuxまたはmacOSでは、次のような確認が実務的です。
find /tmp "$HOME" \
\( -name ".pkg_history" -o -name ".pkg_logs" -o -name "protocal.cjs" -o -name "protocol.cjs" -o -name "nvmconf.service" \) \
-print 2>/dev/nullMicrosoftのブログ本文では永続化ファイル名としてprotocal.cjsという綴りが説明され、IOC表ではprotocol.cjsという表記も見られます。調査では、どちらか一方だけを検索するのではなく、両方を条件に入れると見落としを減らせます。(Microsoft)
Microsoft Defender XDRで実行したいAdvanced Hunting
Microsoft Defender XDRのAdvanced Huntingは、最大30日分の生データをクエリで探索できる脅威ハンティング機能です。Defender for Endpoint、Defender for Office 365、Defender for Cloud Apps、Defender for Identity、Microsoft Sentinelのデータを横断して確認できます。(Microsoft Learn)
まず、Microsoftが示した観点に沿って、Node.jsによるsetup.cjsやeasy-day-jsの実行を確認します。
DeviceProcessEvents
| where Timestamp >= datetime(2026-06-16T00:00:00Z)
| where FileName in~ ("node.exe", "node")
| where ProcessCommandLine has_any ("setup.cjs", "easy-day-js")
or (ProcessCommandLine has "--no-warnings" and ProcessCommandLine has ".cjs")
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine, FolderPath, InitiatingProcessFileName, InitiatingProcessCommandLine
| sort by Timestamp descC2通信の確認では、MicrosoftがIOCとして示したIP、ドメイン、URLをもとに、Defenderのネットワークイベントを確認します。Microsoftは23.254.164[.]92、23.254.164[.]123、teams[.]onweblive[.]org、maskasd[.]comなどをIOCとして示しています。(Microsoft)
DeviceNetworkEvents
| where Timestamp >= datetime(2026-06-16T00:00:00Z)
| where RemoteIP in ("23.254.164.92", "23.254.164.123")
or RemoteUrl has_any ("teams.onweblive.org", "maskasd.com", "23.254.164.92")
| project Timestamp, DeviceName, RemoteIP, RemotePort, RemoteUrl, InitiatingProcessFileName, InitiatingProcessCommandLine, ActionType
| sort by Timestamp desc永続化の痕跡も確認します。特にWindowsでは、Runキー、隠しPowerShell、MicrosoftUpdateを装った値、scdevサービスなどが調査対象になります。
DeviceRegistryEvents
| where Timestamp >= datetime(2026-06-16T00:00:00Z)
| where RegistryKey has @"\Software\Microsoft\Windows\CurrentVersion\Run"
| where RegistryValueName in~ ("NvmProtocal", "MicrosoftUpdate")
or RegistryValueData has_any ("protocal.cjs", "protocol.cjs", "system.bat", "powershell")
| project Timestamp, DeviceName, ActionType, RegistryKey, RegistryValueName, RegistryValueData, InitiatingProcessFileName, InitiatingProcessCommandLine
| sort by Timestamp descファイルIOCの確認では、Microsoftが示したSHA-256やホスト上の痕跡を条件にします。IOCに該当する場合は、単なるマルウェア検知ではなく、CI/CDシークレットや開発者資格情報が露出した可能性まで見てください。
DeviceFileEvents
| where Timestamp >= datetime(2026-06-16T00:00:00Z)
| where FileName in~ (".pkg_history", ".pkg_logs", "system.bat", "scdev.dll", "protocal.cjs", "protocol.cjs")
or SHA256 in~ (
"B122A9873BEDF145AE2A7FD024B5F309007DBB025149F4DC4AC3F7E4F32A36A4",
"AE70DD4F6BC0D1C8C2848E4E6B51934626C4818DCB5AF99D080DDBD7DC337185",
"B73DE25C053C3225A077738A1FCBD9CA6966D7B3CD6F5494A30F0AA0EAE55C7E",
"221c45a790dec2a296af57969e1165a16f8f49733aeab64c0bbd768d9943badf"
)
| project Timestamp, DeviceName, ActionType, FileName, FolderPath, SHA256, InitiatingProcessFileName, InitiatingProcessCommandLine
| sort by Timestamp descIOC登録とブロックで失敗しやすいポイント
Microsoft Defender for Endpointでは、ファイルハッシュ、IPアドレス、URL/ドメイン、証明書などのインジケーターを管理できます。管理画面では、Settings > Endpoints > Indicatorsから種類ごとに追加・更新・削除できます。CSVによる一括インポートも可能ですが、1回のバッチでアップロードできるインジケーター数には制限があるため、大量登録時は分割が必要です。(Microsoft Learn)
ネットワークIOCをブロックする場合は、MicrosoftブラウザーではSmartScreen、Microsoft以外のブラウザーや非ブラウザープロセスではNetwork Protectionの有効化が関係します。また、Custom network indicatorsを使うには、Defenderポータルの高度な機能で有効化しておく必要があります。ブロック反映には最大48時間かかる場合があり、多くの場合は2時間未満とされています。(Microsoft Learn)
| IOC種別 | 登録例 | 推奨アクション | 注意点 |
|---|---|---|---|
| IPアドレス | 23.254.164.92、23.254.164.123 | Block | 内部IPは対象外。ネットワーク保護の要件を確認 |
| ドメイン | teams[.]onweblive[.]org、maskasd[.]com | Block | 既存のAllowポリシーが優先されていないか確認 |
| URL | https[:]//23[.]254[.]164[.]92:8000/update/49890878など | Block | HTTPSのフルパス制御はブラウザーや方式により差が出る |
| ファイルハッシュ | setup.cjs、easy-day-js-1.11.22.tgzなどのSHA-256 | Block and remediate | ハッシュ登録だけでなく実行履歴も調査 |
| ホスト痕跡 | .pkg_history、.pkg_logs、system.bat | ハンティング条件 | Indicator登録より調査クエリ向き |
特に注意したいのは、Allow、Warn、Blockの競合です。Microsoftのドキュメントでは、同じ対象に複数のアクションが設定された場合、Allow > Warn > Blockの順に優先されます。C2や悪性ハッシュをBlockしたつもりでも、過去のAllow設定が残っていると期待どおりに止まらない可能性があります。(Microsoft Learn)
権限確認：誰が調査・対応できる状態か
インシデント時に詰まりやすいのが、Defenderポータル内の権限です。Advanced Huntingを実行できる人、Threat analyticsを読める人、IOCを登録できる人、端末隔離などの応答操作ができる人が分かれていると、初動が遅れます。
Microsoft Defender XDRのAdvanced Huntingを使うには権限が必要で、Unified RBACではメール・コラボレーション系テーブル、アラート・挙動系テーブルなど、参照できるデータ範囲が権限によって分かれます。Microsoft Entraロールでは、Global Administrator、Security Administrator、Security Reader、Global Readerなどが高度なハンティングデータへの読み取りアクセスに関係します。(Microsoft Learn)
Threat analyticsについては、少なくとも1つのMicrosoft Defender製品ライセンスが必要で、Defender for Endpoint P1だけではThreat analyticsアクセスを付与しない例外があります。さらに、Threat analyticsレポート、関連インシデント、影響資産を見るにはSecurity data basics (read)、露出データや推奨アクションを見るにはVulnerability ManagementやExposure Managementの読み取り権限が関係します。(Microsoft Learn)
| 作業 | 必要な人 | 権限の考え方 |
|---|---|---|
| Advanced Huntingの実行 | SOC、EDR運用担当 | セキュリティデータの読み取り権限を付与 |
| Threat analyticsの確認 | SOC、脅威インテリジェンス担当 | レポート、影響資産、推奨アクションを見られる権限 |
| IOC登録・変更 | Defender運用責任者 | 誤登録の影響が大きいため少人数に限定 |
| 端末隔離・修復 | EDR対応担当 | 対応アクション権限を付与 |
| RBAC変更 | セキュリティ管理者 | Microsoft EntraのSecurity Administrator以上を基準に管理 |
Microsoft Defender unified RBACの管理には、少なくともMicrosoft Entra IDのSecurity Administratorが必要です。Global Administratorであれば何でも自動的に見える、という前提で運用するのではなく、平時から最小権限で役割を整理しておくことが重要です。(Microsoft Learn)
Microsoft Threat Intelligenceの移行ポイントも同時に確認する
今回のような脅威インテリジェンス起点の調査では、Microsoft Threat Intelligenceをどこで見るかも重要です。Microsoft Learnでは、従来の単独Microsoft Threat IntelligenceポータルとIntel Explorer experienceは2026年8月1日に廃止予定で、Microsoft Threat Intelligence機能はMicrosoft Defenderポータルに統合されると案内されています。(Microsoft Learn)
そのため、今回の対応を機に、次の移行タスクも進めておくと実務上の手戻りを減らせます。
| 移行対象 | 見直す内容 |
|---|---|
| ブックマーク | 旧Defender TIポータルではなくDefenderポータルのThreat intelligence導線へ変更 |
| 手順書 | 「Threat intelligence > Intelligence explorer / Intel profiles」で探す手順に更新 |
| 権限 | Defender unified RBACでThreat Intelligence、Threat analytics、Advanced Huntingの権限を整理 |
| プロジェクト運用 | IOC、調査メモ、関係者、判断結果をDefenderポータル側の運用に寄せる |
| SOC周知 | 「旧ポータルで探す」手順を残さない |
Defenderポータルでは、IP、ドメイン、URL、ファイルなどのエンティティページにThreat Intelligence Insightsが表示され、Intelligence explorerやIntel profilesから脅威アクター、ツール、IOC、関連分析にアクセスできます。今回のようにIOCから調査を始めるケースでは、Defenderポータル上でエンティティ、インシデント、アラート、脅威インテリジェンスをつなげて見る運用に寄せるべきです。(Microsoft Learn)
復旧時にやるべきこと：削除だけで終わらせない
easy-day-jsや侵害されたMastraパッケージを削除しただけでは、対応として不十分です。postinstallが実行された可能性がある端末やCI/CDランナーでは、すでにトークン、履歴、環境変数、クラウド認証情報が収集されている前提で動く必要があります。
実務では、次の順序で復旧すると判断しやすくなります。
| 順番 | 作業 | 判断基準 |
| -: | ————- | ——————————————- |
| 1 | ビルド停止 | 該当パッケージを含むCI/CDを一時停止 |
| 2 | 証拠保全 | Defenderイベント、CIログ、ロックファイル、npmキャッシュを保存 |
| 3 | ランナー再作成 | 自己ホスト型ランナーはクリーンイメージから再構築 |
| 4 | シークレットローテーション | CI/CD変数、npm token、GitHub token、クラウドAPIキーを更新 |
| 5 | 安全な依存関係へ固定 | Microsoftが示す既知の安全バージョンを基準にロック |
| 6 | 再ビルド | クリーン環境で再取得・再ビルド |
| 7 | 監視強化 | IOC、KQL、カスタム検出、ネットワーク制御を反映 |
Microsoftは、mastraでは1.13.0以前、@mastra/coreでは1.42.0以前は影響を受けないと説明しています。ただし、他の@mastra/*パッケージや推移的依存関係が関係する場合があるため、単一パッケージ名だけで安全判断しないことが大切です。(Microsoft)
再発防止：npmのサプライチェーン対策を運用に落とす
今回の件は、セキュリティ製品だけで防ぐ問題ではありません。npmパッケージのpublish権限、CI/CDのシークレット管理、ライフサイクルスクリプトの扱い、開発端末の監視がつながって初めてリスクを下げられます。
特に見直したいのは次の点です。
| 対策 | 実務でのポイント |
|---|---|
| パッケージバージョン固定 | latest任せにせず、lockfileとレビューを必須にする |
| ライフサイクルスクリプト制御 | 初回検証時はnpm ci --ignore-scriptsを使い、必要なスクリプトを明示的に許可 |
| CI/CDの短命化 | 自己ホスト型ランナーは使い回さず、可能ならエフェメラル化 |
| シークレット最小化 | ビルドジョブごとに必要最小限の権限だけ渡す |
| egress制御 | CI/CDランナーから任意の外部IPへ通信できる状態を避ける |
| npmアカウント保護 | MFA、publish権限の棚卸し、不要なメンテナー権限の削除 |
| 依存関係レビュー | RenovateやDependabotのPRを自動マージしないルールを設ける |
| SOC連携 | 開発チームからnpm異常をDefender運用へ連絡する窓口を決める |
--ignore-scriptsは有効な防御策ですが、すべてのnpmパッケージで常時使うと正当なビルドやネイティブモジュールのセットアップが壊れる場合があります。現実的には、「未知・新規・緊急更新の検証ジョブではスクリプトを無効化し、承認済みの依存関係だけ本番ビルドで許可する」という段階的な運用が向いています。
開発チームへ周知する文面例
管理者から開発チームへは、技術的な詳細を長く説明するよりも、確認してほしい行動を明確に伝えるのが効果的です。
Mastra / @mastra 系npmパッケージに関するサプライチェーン侵害が確認されています。
2026年6月16日以降に、開発端末またはCI/CD環境で mastra / @mastra/* を含む npm install または npm update を実行した場合は、アプリで実際にimportしていなくても確認対象です。
以下を確認してください。
- package-lock.json、pnpm-lock.yaml、yarn.lock、node_modules に easy-day-js がないか
- CI/CDログに該当期間の npm install / npm update がないか
- 自己ホスト型ランナーで該当ビルドを実行していないか
- npm token、GitHub token、クラウドAPIキーなどが該当環境に存在していなかったか
該当する場合は、該当端末やランナーを使い続けず、セキュリティ管理者へ連絡してください。この周知では、「アプリで使っていなければ安全」と誤解されないようにすることが重要です。今回の本質は、実行時のライブラリ利用ではなく、インストール時のライフサイクルスクリプト実行です。
まとめ：Defender管理者はIOC確認、権限整理、CI/CD復旧まで一気通貫で対応する
Mastra npm supply-chain compromiseとSapphire Sleetの件で、Microsoft Defender / Microsoft Threat Intelligence管理者が最初に見るべきポイントは、Defenderのアラート有無だけではありません。easy-day-js、setup.cjs、C2通信、永続化、Defender除外、CI/CDシークレット、自己ホストランナーまでを一つの攻撃経路として確認する必要があります。
すぐに取るべき行動は、次の5つです。
- Mastra /
@mastra/*/easy-day-jsの利用有無をロックファイル、CIログ、端末で確認する - Microsoft Defender XDRのAdvanced HuntingでNode.js実行、C2通信、永続化の痕跡を探す
- IOCをDefenderやネットワーク制御に反映し、Allow設定の競合がないか確認する
- 該当端末・CI/CDランナーに存在したトークンやAPIキーをローテーションする
- Microsoft Threat Intelligenceの確認手順をDefenderポータル中心の運用へ移行する
今回のようなnpmサプライチェーン攻撃では、開発者だけ、SOCだけ、ID管理者だけでは対応が分断されます。Defender管理者は、検知・調査・復旧・周知・再発防止をつなぐ役割として、該当環境を早期に洗い出し、CI/CDと認証情報の安全性まで確認してください。
コメント