Mastra npm supply-chain compromiseとSapphire Sleetの件で、管理者がまず確認すべき場所は、Microsoft Defenderポータルの「Threat analytics」「Threat intelligence」「Advanced hunting」「Incidents & alerts」「Settings > Endpoints」です。結論としては、影響有無の確認、IoCの照合、Defenderの保護設定、CI/CD環境の調査、開発者へのトークンローテーション周知を同時に進める必要があります。
Microsoftは2026年6月19日の更新で、このMastra npm supply-chain compromiseを、北朝鮮系の国家支援型アクターであるSapphire Sleetに高い信頼度で関連付けました。公式ソース上の分類は「Research」で、Microsoft Defender Security Research TeamとMicrosoft Threat Intelligenceによる調査として公開されています。(Microsoft)
Mastra npm supply-chain compromiseとSapphire Sleetの要点
今回のインシデントは、単に「npmパッケージに悪意あるコードが入った」という話ではありません。開発者端末やCI/CDパイプラインでnpm installまたはnpm updateが実行されるだけで、アプリケーションコードから該当パッケージを直接importしていなくても影響を受ける可能性があった点が重要です。
Microsoftの調査では、Mastraおよび@mastraスコープの140以上のnpmパッケージが影響を受け、攻撃者はehindero npmメンテナーアカウントを乗っ取り、easy-day-jsというdayjsに似せたタイポスクワット依存関係を注入したとされています。easy-day-jsはインストール時のpostinstallフックを使い、難読化されたドロッパー、C2通信、二段階目ペイロードの取得、隠しプロセス実行へつながる挙動を持っていました。(Microsoft)
| 確認項目 | 内容 | 実務上の意味 |
|---|---|---|
| 公式分類 | Microsoft Security Blog上ではResearch | 製品リリース告知ではなく、脅威調査として読む |
| 関連アクター | Sapphire Sleet | 金融、暗号資産、ブロックチェーン関連の組織は特に優先度を上げる |
| 影響範囲 | Mastraおよび@mastraスコープの140以上のパッケージ | 直接依存だけでなく、ロックファイルとCI/CDキャッシュも確認する |
| 悪性依存関係 | easy-day-js | dayjsではなく、名前が似た別パッケージを探す |
| 主なリスク | 認証情報、トークン、ビルド環境、下流ソフトウェア完全性 | 端末調査だけで終わらせず、シークレット更新まで実施する |
| 日本時間での目安 | 悪性版公開は2026年6月17日午前10時台 | 日本の開発チームにはUTCではなくJSTで周知する |
Microsoftは、侵害済みパッケージが削除され、攻撃者の@mastraスコープへの公開権限が取り消されたことも説明しています。ただし、すでに該当時間帯にインストールされた環境では、ローカル端末、CI runner、コンテナイメージ、キャッシュ、ビルド成果物に痕跡が残っている可能性があります。(Microsoft)
Microsoft Defenderで最初に確認する管理画面
Microsoft Defenderポータルは、脅威の保護、検出、調査、対応を一元化する管理画面です。Microsoft Defender XDRでは、Incidents & alerts、Hunting、Threat analyticsなどの機能が統合され、契約しているサブスクリプションに応じて表示される機能が変わります。(Microsoft Learn)
| 目的 | 管理画面 | 確認すること |
|---|---|---|
| 公式の脅威レポートを確認する | Threat analytics | Mastra、Sapphire Sleet、npmで検索し、Analyst report、Indicators、Recommended actionsを確認 |
| 組織内の関連インシデントを見る | Incidents & alerts | Node.js、PowerShell、C2通信、Defender除外追加に関するアラートを確認 |
| 端末・CI runnerの痕跡を探す | Hunting > Advanced hunting | easy-day-js、setup.cjs、C2 IP、Runキー、PowerShell実行をKQLで検索 |
| IoCをブロックまたは警告に使う | Settings > Endpoints > Indicators | IP、URL、ドメインのIndicatorを追加。対象デバイスグループを絞る |
| Defenderの保護機能を確認する | Settings > Endpoints > Advanced features | EDR in block mode、Custom network indicators、Tamper protection、Live responseを確認 |
| クラウド保護を管理する | Intune admin center > Endpoint security > Antivirus | Microsoft Defender AntivirusポリシーでAllow Cloud Protectionとサンプル送信を確認 |
| 脅威インテリジェンスを深掘りする | Threat intelligence > Intel explorer / Intel profiles | Sapphire Sleet、関連ドメイン、IP、ファイルハッシュ、インフラ関係を調査 |
Threat analyticsでは、脅威ごとの概要、アナリストレポート、関連インシデント、影響資産、推奨アクション、Indicatorsタブを確認できます。Indicatorsタブはプレビュー機能としてIoCの一覧を提供し、Microsoftの研究者が新しい証拠を見つけると更新される仕組みです。(Microsoft Learn)
利用条件と権限でつまずきやすいポイント
Threat analyticsを利用するには、少なくとも1つのMicrosoft Defender XDR製品ライセンスが必要です。ただし、Microsoft Defender for Endpoint P1のみではThreat analyticsのアクセス要件を満たしません。また、レポートや関連アラート、影響資産を見るには、Security data basicsの読み取り権限などが必要です。(Microsoft Learn)
Advanced huntingは、最大30日分の生データを探索できるクエリベースのハンティング機能です。Microsoft Defender for Endpoint、Defender for Office 365、Defender for Cloud Apps、Defender for Identity、Microsoft Sentinelのデータを対象にできますが、実際に見えるテーブルはライセンス、連携状態、RBAC権限に左右されます。(Microsoft Learn)
Microsoft Threat IntelligenceはDefenderポータルに統合されており、Threat intelligenceメニューからIntel profilesやIntel explorerを利用できます。Defender TI premiumライセンスが前提となる機能がある一方、premiumライセンスがないユーザーでも無料のDefender TI offeringにアクセスできるとMicrosoft Learnでは説明されています。既存のDefender TI体験は2026年8月1日の製品廃止まで利用可能と案内されています。(Microsoft Learn)
ネットワークIndicatorでIP、URL、ドメインをブロックするには、Microsoft Defender for Endpoint Plan 1またはPlan 2が対象です。Microsoft EdgeなどMicrosoftブラウザーではSmartScreenが関係し、それ以外のブラウザーやアプリではNetwork Protectionをブロックモードにする必要があります。Custom network indicatorsは、DefenderポータルのSettings > Endpoints > General > Advanced featuresで有効化します。(Microsoft Learn)
Mastra / Sapphire Sleet対応で確認すべきDefender設定
今回のようなnpmサプライチェーン攻撃では、検出だけでなく「攻撃者に保護設定を弱められていないか」の確認が重要です。Microsoftの調査では、ポスト侵害段階でDefender除外の追加やサービスレベルの永続化が観測されています。(Microsoft)
| 設定 | 確認場所 | 望ましい状態 | 注意点 |
|---|---|---|---|
| Cloud-delivered protection | Intune > Endpoint security > Antivirus | Allowed | Block at first sight、サンプル解析、EDR in block modeなど複数機能に関係 |
| Automatic sample submission | Intune > Endpoint security > Antivirus | Send safe samples automatically以上 | Never sendやAlways promptは保護レベルを下げる場合がある |
| Tamper protection | Settings > Endpoints > Advanced features / Intune | 有効 | 攻撃者による保護設定変更や除外追加を抑止する |
| EDR in block mode | Settings > Endpoints > Advanced features | 必要に応じて有効 | Defender Antivirusがパッシブでも悪性アーティファクトのブロックに寄与 |
| Custom network indicators | Settings > Endpoints > Advanced features | 有効 | C2 IP、ドメインをIndicatorで制御する前提 |
| Network Protection | Intune、GPO、セキュリティベースライン | ブロックモード | 非MicrosoftブラウザーやNode.jsなどの通信制御で重要 |
| Device onboarding | Settings > Endpoints > Device management > Onboarding | 開発者端末、CI runner、ビルドサーバーまで対象 | 開発端末だけでなく、一時的なrunnerやサーバーも棚卸しする |
| Threat analytics通知 | Settings > Microsoft Defender XDR > Email notifications > Threat analytics | SOC、開発責任者、インフラ責任者に通知 | レポート更新を見逃すとIoC更新への反応が遅れる |
Cloud-delivered protectionは既定で有効とされますが、過去の組織ポリシーで無効化されている場合があります。IntuneではEndpoint security > AntivirusからMicrosoft Defender Antivirusポリシーを作成または編集し、Allow Cloud ProtectionをAllowedに設定します。PowerShellではSet-MpPreference -MAPSReporting AdvancedやSet-MpPreference -SubmitSamplesConsent SendAllSamplesで構成できますが、組織環境ではIntuneやポリシーによる一元管理を優先してください。(Microsoft Learn)
Tamper protectionは、ウイルスと脅威の防止、リアルタイム保護、クラウド保護、除外設定などが不正に変更されるのを防ぐ機能です。Microsoft Learnでは、PowerShellのGet-MpComputerStatusでIsTamperProtectedやRealTimeProtectionEnabledを確認する方法も示されています。(Microsoft Learn)
Get-MpComputerStatus |
Select-Object IsTamperProtected, RealTimeProtectionEnabled, AMServiceEnabled, AntivirusEnabledAdvanced huntingで確認するKQL例
Microsoftのブログでは、setup.cjsやeasy-day-jsを含むNode.jsプロセス、C2 IPへのアウトバウンド通信を探すAdvanced huntingクエリが提示されています。ここでは実務で使いやすいように、30日以内の調査に広げた例を示します。Advanced huntingのクエリはUTC基準で扱われるため、2026年6月17日午前10時台JSTの事象を調べる場合もUTC換算を意識してください。(Microsoft)
easy-day-jsまたはsetup.cjsの実行痕跡を探す
DeviceProcessEvents
| where Timestamp > ago(30d)
| where FileName in~ ("node", "node.exe")
| where ProcessCommandLine has_any ("setup.cjs", "easy-day-js", "--no-warnings")
or FolderPath has "easy-day-js"
| project Timestamp, DeviceName, AccountName, FileName,
ProcessCommandLine, FolderPath,
InitiatingProcessFileName, InitiatingProcessCommandLine,
DeviceId, ReportId
| order by Timestamp descこのクエリでヒットした場合は、単に該当ファイルを削除するのではなく、該当端末で実行されたnpmコマンド、作業ディレクトリ、Gitリポジトリ、CIジョブ名、同時刻のネットワーク通信を確認します。開発者端末でヒットした場合、ブラウザー拡張機能、暗号資産ウォレット、クラウド認証情報、npmトークン、GitHub PAT、CI/CDシークレットの漏えい可能性を前提に扱うべきです。
C2 IPおよび関連ドメインへの通信を探す
DeviceNetworkEvents
| where Timestamp > ago(30d)
| where RemoteIP in ("23.254.164.92", "23.254.164.123")
or RemoteUrl has_any ("teams.onweblive.org", "maskasd.com")
| project Timestamp, DeviceName, InitiatingProcessFileName,
InitiatingProcessCommandLine, RemoteIP, RemotePort,
RemoteUrl, ActionType, DeviceId, ReportId
| order by Timestamp descMicrosoftが公開したIoCには、23.254.164.92、23.254.164.123、teams.onweblive.org、maskasd.comなどが含まれています。ネットワークIndicatorでブロックする場合は、Settings > Endpoints > IndicatorsからIP addressesまたはURLs/Domainsタブを使い、対象デバイスグループ、期限、説明を明確に設定します。なお、URL/IPブロックは反映まで最大48時間かかる場合があり、多くの場合は2時間未満とされています。(Microsoft)
Runキーと不審な永続化を探す
DeviceRegistryEvents
| where Timestamp > ago(30d)
| where RegistryKey has @"\Software\Microsoft\Windows\CurrentVersion\Run"
| where RegistryValueName in~ ("NvmProtocal", "MicrosoftUpdate")
or RegistryValueData has_any ("NodePackages", "protocal.cjs", "system.bat")
| project Timestamp, DeviceName, ActionType, RegistryKey,
RegistryValueName, RegistryValueData,
InitiatingProcessFileName, InitiatingProcessCommandLine,
DeviceId, ReportId
| order by Timestamp descMicrosoftの調査では、WindowsでHKCU\...\CurrentVersion\Runを使った永続化、NvmProtocal、protocal.cjs、MicrosoftUpdateなど、正規のNode.jsやMicrosoft更新に見せかける名称が使われています。名前だけで安全と判断せず、作成時刻、親プロセス、実行ユーザー、配置先パスをセットで確認してください。(Microsoft)
Defender除外や不審なサービス作成を探す
DeviceProcessEvents
| where Timestamp > ago(30d)
| where ProcessCommandLine has_any ("Add-MpPreference", "Set-MpPreference", "ExclusionPath")
or ProcessCommandLine has "sc create scdev"
or ProcessCommandLine has "scdev.dll"
| project Timestamp, DeviceName, AccountName, FileName,
ProcessCommandLine, InitiatingProcessFileName,
InitiatingProcessCommandLine, DeviceId, ReportId
| order by Timestamp descDefender除外の変更は、マルウェアそのものの検出よりも見落とされやすいポイントです。特にC:\Windows\System32のような広すぎる除外、正規サービスに見せかけた自動起動サービス、svchost.exeを使う不審なサービス定義があれば、端末隔離とフォレンジックを優先します。
カスタム検出ルールにするか、一回限りの調査にするか
Mastra npm supply-chain compromiseへの対応では、まずAdvanced huntingで過去30日を調査し、ヒット状況を把握します。そのうえで、今後も同様のnpmポストインストール攻撃を監視したい場合は、Custom detection rulesとして登録します。
Microsoft Defender XDRのカスタム検出は、Advanced huntingクエリをもとに定期実行し、条件一致時にアラートや応答アクションを生成できます。作成時はAdvanced huntingからCreate detection ruleを選ぶ方法と、Custom detection rules一覧から新規作成する方法があります。Defenderデータを対象にする場合、Timestamp、DeviceIdまたはDeviceNameなどの列を返すように設計すると、アラートの紐付けが安定します。(Microsoft Learn)
| 判断基準 | 一回限りのAdvanced hunting | Custom detection rules |
|---|---|---|
| 目的 | 既に影響を受けたか確認する | 今後の類似挙動を継続監視する |
| 対象 | 2026年6月17日前後のnpm実行、C2通信 | Node.js postinstall、難読化スクリプト、異常なPowerShell |
| メリット | ノイズを見ながら柔軟に調査できる | SOCの運用フローに乗せやすい |
| 注意点 | 実行し忘れると追跡が止まる | クエリが広すぎるとアラート疲れを招く |
| 推奨 | 初動調査、影響範囲特定 | 影響端末があった場合、または開発端末が多い組織 |
カスタム検出は、1回の実行で最大150件のアラート生成制限があります。通常業務で発生するNode.js実行まで拾うとノイズが増えるため、setup.cjs、easy-day-js、不審な一時ディレクトリ、既知C2、Defender除外変更など、複数条件を組み合わせて精度を上げてください。(Microsoft Learn)
開発者とCI/CD管理者へ周知する内容
今回の攻撃は、セキュリティ担当だけで完結しません。開発者、SRE、CI/CD管理者、情シスが同じ前提で動けるように、短く具体的な周知文を出すことが重要です。
周知で必ず伝えるべきこと
| 対象 | 伝える内容 | 理由 |
|---|---|---|
| 開発者 | 2026年6月17日午前10時以降にMastra関連でnpm installまたはnpm updateを実行した場合は申告 | 依存関係の解決だけでpostinstallが走る可能性がある |
| CI/CD管理者 | 該当時間帯のジョブログ、runner、キャッシュ、コンテナレイヤーを確認 | 一時runnerでもシークレットが読み取られた可能性がある |
| リポジトリ管理者 | package-lock.json、pnpm-lock.yaml、yarn.lockでeasy-day-jsを検索 | 直接依存ではなく推移的依存で入る可能性がある |
| クラウド管理者 | GitHub PAT、npm token、Azure/AWS/GCPキー、LLM APIキーを棚卸し | 開発端末やCIに保存された認証情報が狙われる |
| ヘルプデスク | 該当端末を自己判断で初期化しないよう案内 | 証跡が消えると影響範囲の判断が難しくなる |
開発者には、次のようなコマンドを案内すると実務で確認しやすくなります。ただし、ヒットした端末では証跡保全を優先し、勝手に削除や再インストールを進めないよう明記してください。
npm ls easy-day-js
grep -R "easy-day-js" package-lock.json pnpm-lock.yaml yarn.lock 2>/dev/null社内周知文の例
2026年6月17日午前10時以降に、Mastraまたは
@mastra関連パッケージを含むプロジェクトでnpm installまたはnpm updateを実行した方は、開発端末名、リポジトリ名、実行時刻、CIジョブ名をセキュリティ担当へ連絡してください。該当端末では、自己判断でキャッシュ削除、再インストール、初期化を行わないでください。必要に応じて、npm token、GitHub PAT、クラウド認証情報、CI/CDシークレット、APIキーのローテーションを実施します。
この文面のポイントは、「Mastraを使っている人だけ確認してください」ではなく、「Mastra関連パッケージを含む依存関係でnpm install/updateを実行した人」を対象にすることです。今回の攻撃では、パッケージをアプリケーションコードで使ったかどうかより、インストール時にpostinstallが動いたかどうかが重要です。
対応フロー：検出、封じ込め、復旧、再発防止
Mastra npm supply-chain compromiseとSapphire Sleetの設定確認は、次の順番で進めると抜け漏れを減らせます。
| フェーズ | 実施内容 | 完了条件 |
|---|---|---|
| 影響確認 | Threat analytics、Advanced hunting、ロックファイル、CIログを確認 | 影響端末、影響リポジトリ、影響ジョブの一覧がある |
| 封じ込め | 端末隔離、C2ブロック、該当runner停止、キャッシュ凍結 | 新たな通信やビルド実行が止まっている |
| 認証情報対応 | npm token、GitHub PAT、CI secrets、クラウドキー、APIキーをローテーション | 更新済みキーと失効済みキーが記録されている |
| 証跡確認 | Runキー、サービス、PowerShell履歴削除、Defender除外を確認 | 永続化と防御回避の有無が判断できている |
| 復旧 | クリーンな依存関係、クリーンなrunner、再生成したコンテナでビルド | 侵害時点のキャッシュや成果物を使っていない |
| 再発防止 | lockfile運用、依存関係レビュー、--ignore-scriptsの適用範囲検討 | 開発チームの手順書に反映されている |
Microsoftは緩和策として、影響を受けた@mastraパッケージの直接・推移的依存の確認、node_modulesやlockfile上のeasy-day-js確認、既知の安全なバージョンへの固定、npm install --ignore-scriptsの利用、IoCアーティファクト確認、認証情報やトークンのローテーション、C2 IPのブロック、CI/CDログ監査、クラウド配信保護の有効化を挙げています。(Microsoft)
設定確認で失敗しやすいポイント
Defenderポータルに画面が見えない
管理者によって「Threat analyticsが見えない」「Threat intelligenceが見えない」「Advanced huntingの一部テーブルが見えない」という差が出ることがあります。これは多くの場合、ライセンス、Microsoft Defender XDRの有効化、製品ごとの連携、RBACスコープ、Microsoft Sentinelワークスペース接続のいずれかが原因です。
特にThreat analyticsは、対象レポート自体が見えても、関連インシデント、影響資産、露出、推奨アクションまで見えるかは、利用中の製品と権限に左右されます。SOC担当者にはSecurity Reader相当だけで足りるか、設定変更担当にはSecurity AdministratorやSecurity settings manage相当が必要かを分けて設計してください。(Microsoft Learn)
C2ブロックだけで完了と判断する
C2 IPやドメインをブロックするのは必要ですが、それだけでは不十分です。今回のような攻撃では、すでに取得されたトークン、CI/CDシークレット、ブラウザー情報、永続化されたバックドアの確認が必要です。ネットワーク遮断後も、認証情報のローテーションとビルド環境の再作成を完了条件に含めてください。
dayjsを誤って疑う
悪性パッケージはdayjsではなく、easy-day-jsです。名前が似ているため、開発者向けの周知では「正規のdayjsそのものを削除する話ではない」と明記すると混乱を減らせます。
CI runnerを端末管理の対象外にしている
開発者端末だけをMicrosoft Defender for Endpointにオンボードしていて、CI runner、ビルドサーバー、セルフホストrunner、検証用VMが対象外になっている組織は珍しくありません。今回のようなnpm install起点の攻撃では、むしろCI/CD環境のほうが高価値なシークレットを持っている場合があります。Defender for Endpointのオンボーディング画面では、OSを選択し、接続方式と展開方法を選んでオンボーディングパッケージを取得できます。(Microsoft Learn)
Indicatorの優先順位を誤解する
URL、ドメイン、IPのIndicatorでは、Allow、Warn、Blockが競合した場合、AllowがWarnより、WarnがBlockより優先されます。過去に例外としてAllowを作っていると、今回追加したBlockが効かない可能性があります。Indicatorを追加したら、同じIP、ドメイン、上位ドメイン、長いURLパスのAllow設定がないかも確認してください。(Microsoft Learn)
次に取るべき行動
Mastra npm supply-chain compromiseとSapphire Sleetへの対応では、まずThreat analyticsとMicrosoft Security Blogの情報でIoCと推奨アクションを確認し、Advanced huntingで自組織の実行痕跡を調べます。次に、Settings > EndpointsとIntuneでCloud-delivered protection、Tamper protection、Custom network indicators、Network Protection、EDR in block modeの状態を確認します。
影響が疑われる端末やCI/CDジョブが1件でも見つかった場合は、端末調査だけで終わらせず、npm token、GitHub PAT、クラウド認証情報、CI/CDシークレット、APIキーのローテーションまで進めてください。最後に、開発者へ「該当時間帯にnpm install/updateを実行したか」「easy-day-jsがlockfileに含まれるか」「自己判断で削除しないこと」を周知すれば、技術調査と現場対応の両方をそろえられます。
コメント