Mastra npm supply-chain compromiseは、Mastra関連のnpmパッケージを使っていた開発端末やCI/CD環境が影響を受けた可能性があるサプライチェーン攻撃です。結論から言うと、Microsoft Defender / Microsoft Threat Intelligence利用者は、@mastra系パッケージとeasy-day-jsの利用有無、npm install実行履歴、CI/CDの外部通信、Defenderの検出状況、認証情報のローテーション要否を優先して確認するべきです。
特に重要なのは、アプリのソースコードで問題のパッケージを直接importしていたかどうかではありません。npmのインストール時にpostinstallスクリプトが動く仕組みを悪用しているため、開発端末やビルド環境でnpm installまたはnpm updateを実行していた場合は、実行時点の依存関係を確認する必要があります。Microsoft Security Blogでは、この件をMicrosoft Defender Security Research TeamとMicrosoft Threat IntelligenceによるResearchとして公開し、2026年6月19日の更新でSapphire Sleetによる活動と高い確度で評価しています。(Microsoft)
Mastra npm supply-chain compromiseとは
Mastra npm supply-chain compromiseは、Mastraエコシステムのnpmパッケージに悪意ある依存関係が混入された攻撃です。Microsoft Threat Intelligenceは、npmレジストリ上のmastraおよび@mastraスコープに属する140以上のパッケージが影響を受けたと説明しています。(Microsoft)
攻撃の中心は、easy-day-jsというnpmパッケージです。名前から分かるように、これは正規の人気ライブラリdayjsに似せたタイポスクワッティング型のパッケージです。侵害されたnpmメンテナーアカウントを使ってMastra関連パッケージにeasy-day-jsが依存関係として追加され、インストール時に悪意あるpostinstall処理が実行される流れでした。(Microsoft)
この攻撃で厄介なのは、ライブラリを実際にアプリケーションコードで呼び出していなくても、インストール処理だけでリスクが発生する点です。開発者のPC、検証サーバー、GitHub ActionsやAzure PipelinesなどのCI/CDランナー、社内のビルドサーバーが確認対象になります。
2026年6月19日の更新で何が変わったのか
今回の更新で特に押さえるべき変更点は、単なる「npmパッケージの侵害」ではなく、Sapphire Sleetの活動として整理された点です。
| 確認ポイント | 内容 |
|---|---|
| 分類 | Microsoft Security Blog上ではResearchとして扱われている |
| 関連製品 | Microsoft Defender、Microsoft Threat Intelligence |
| 主な変更点 | Microsoftが高い確度でSapphire Sleetに関連すると評価 |
| 影響範囲 | mastraおよび@mastraスコープの140以上のnpmパッケージ |
| 悪用された仕組み | npmの依存関係追加とpostinstallスクリプト |
| 重要な確認対象 | 開発端末、CI/CD、ロックファイル、node_modules、外部通信、保存済みシークレット |
Microsoftは2026年6月19日の更新で、この活動を北朝鮮関連の脅威アクターSapphire Sleetに高い確度で帰属すると評価しました。また、同アクターが2026年4月にもAxiosに影響する別のnpmサプライチェーン侵害を行っていたことにも触れています。(Microsoft)
つまり、今回の変更点は「検出名が追加された」というだけではありません。npmの依存関係を悪用した一過性の攻撃ではなく、金融、暗号資産、ブロックチェーン関連の組織を狙う脅威活動の一部として見直す必要があります。
影響を受けやすい対象者
Microsoft Defender / Microsoft Threat Intelligence利用者の中でも、次の環境は優先度を上げて確認してください。
| 対象 | 確認すべき理由 |
|---|---|
| Mastraを利用している開発チーム | 直接または推移的依存関係で影響パッケージを取り込んだ可能性がある |
| Node.js / npmを使うCI/CD環境 | npm install時にpostinstallが動作した可能性がある |
| AIエージェント、LLMアプリ開発チーム | Mastra関連パッケージを検証利用している可能性がある |
| 暗号資産・金融・ブロックチェーン関連企業 | Sapphire Sleetの関心領域と重なるため、被害時の影響が大きい |
| 社内開発基盤の管理者 | トークン、npm認証情報、クラウドキー、GitHubトークンなどの露出確認が必要 |
「本番環境には入れていないから大丈夫」と判断するのは危険です。サプライチェーン攻撃では、開発端末やビルド環境に保存されたアクセストークン、クラウド認証情報、リポジトリ権限が狙われることがあります。今回もMicrosoftは、認証情報、トークン、ビルド環境、下流のソフトウェア完全性にリスクが生じる可能性を示しています。(Microsoft)
すぐ確認したい項目
まずは、影響有無を短時間で切り分けることが重要です。次の順で確認すると、開発チームとセキュリティチームが連携しやすくなります。
| 優先度 | 確認項目 | 具体的な見方 |
|---|---|---|
| 高 | easy-day-jsの存在 | package-lock.json、npm-shrinkwrap.json、node_modulesを検索 |
| 高 | mastra / @mastra/*のバージョン | 影響時期にインストール・更新されていないか確認 |
| 高 | CI/CDログ | 2026年6月17日前後のnpm install、npm update、外部通信を確認 |
| 高 | Defenderアラート | Node.js、PowerShell、C2通信、疑わしいプロセス注入の検出を確認 |
| 中 | 端末内のIOC | 一時ディレクトリ内の.pkg_history、.pkg_logs、不審な.jsファイルを確認 |
| 中 | 認証情報 | npm、GitHub、Azure、クラウドAPIキー、CI/CDシークレットのローテーション要否を判断 |
| 中 | ネットワーク制御 | Microsoftが示したC2 IPや関連ドメインへの通信履歴を確認 |
Microsoftは、影響を減らすための対応として、依存関係ツリーの確認、easy-day-jsの有無確認、既知の安全なバージョンへの固定、npm install --ignore-scriptsの利用、IOC確認、認証情報のローテーション、C2 IPのブロック、CI/CDログ監査、Defender Antivirusのクラウド提供保護の有効化を挙げています。(Microsoft)
Microsoft Defenderで見るべき検出とアラート
Microsoft Defender / Microsoft Defender XDRを利用している場合は、通常のマルウェア検出だけでなく、Node.jsやPowerShellの挙動を横断的に確認する必要があります。
Microsoft Security Blogでは、Microsoft Defender Antivirus、Microsoft Defender for Endpoint、Microsoft Defender XDRが、不審なNode.js実行、悪意あるパッケージ動作、反射型コード読み込み、永続化、C2通信などを検出対象としていると説明しています。(Microsoft)
特に確認したいのは、次のようなアラートです。
| 観点 | 確認するアラート・挙動 |
|---|---|
| npmインストール時の実行 | nodeまたはnode.exeによるsetup.cjs実行 |
| 不審なNode.js挙動 | easy-day-js、--no-warnings、一時ディレクトリ内のJS実行 |
| PowerShell実行 | hidden window、ExecutionPolicy Bypass、外部URLからのスクリプト取得 |
| ファイルレス攻撃 | .NETアセンブリの反射型読み込み、プロセス注入 |
| 永続化 | Registry Run key、サービス登録、LaunchAgent、systemd user unit |
| C2通信 | Microsoftが示したIPアドレスや関連ドメインへの通信 |
注意したいのは、Defenderの検出が出ていないことだけで安全と判断しないことです。CI/CDランナーが短時間で破棄される構成の場合、エンドポイント上の証跡が残りにくい場合があります。ビルドログ、プロキシログ、EDRのDeviceProcessEvents、DeviceNetworkEventsを組み合わせて確認するのが現実的です。
Advanced Huntingで確認するポイント
Microsoft Defender XDRのAdvanced Huntingを使える場合は、Microsoftが提示している観点に沿って、Node.jsのpostinstall実行とC2通信を確認します。Microsoft Security Blogでは、setup.cjsやeasy-day-jsを含むNode.js実行、特定IPへの通信を探すKQL例が示されています。(Microsoft)
実務では、公開されたクエリをそのまま実行するだけでなく、次のように調整してください。
- 対象期間を7日だけに固定せず、影響が疑われる期間まで広げる
- 開発端末だけでなく、CI/CDランナーやビルドサーバーも対象に含める
node.exe、powershell.exe、cmd.exeの親子関係を見る- npmキャッシュ、作業ディレクトリ、一時ディレクトリのパスを確認する
- 検出端末が1台でもあれば、同じリポジトリを扱った端末へ横展開して調査する
例えば、setup.cjsの実行が見つかった場合は、その端末だけで完結させず、同じ時間帯に同じプロジェクトをビルドしたCI/CDジョブ、同じnpmロックファイルを使った開発者端末、同じシークレットにアクセスできたアカウントまで確認範囲を広げるべきです。
Microsoft Threat Intelligence利用者が確認したいこと
Microsoft Threat Intelligenceを利用している組織では、IOCを単にブロックリストへ追加するだけでなく、自社の資産・業務文脈と結びつけて評価することが重要です。
確認したい観点は次のとおりです。
| 観点 | 実務上の確認内容 |
|---|---|
| 脅威アクター | Sapphire Sleetに関連するTTP、過去キャンペーン、自社業界との関連性 |
| IOC | IP、ドメイン、URL、ファイルハッシュ、npmパッケージ名、npmアカウント |
| 露出資産 | 開発端末、CI/CD、ソースコード管理、npmトークン、クラウド認証情報 |
| 影響判断 | インストール履歴、通信履歴、Defenderアラート、シークレット利用履歴 |
| 対応優先度 | 金融・暗号資産・ブロックチェーン関連のシステムを優先 |
Sapphire Sleetは、Microsoftの説明では北朝鮮関連の国家支援型アクターで、金融、暗号資産、ベンチャーキャピタル、ブロックチェーン関連組織を主な標的にしてきたとされています。(Microsoft)
そのため、暗号資産ウォレット、取引基盤、秘密鍵、APIキー、決済・金融系のソースコードにアクセスできる開発環境では、通常のマルウェア感染確認より一段深い調査が必要です。
運用上の注意点
今回のようなnpmサプライチェーン攻撃では、対策を急ぐあまり、開発フローを壊してしまうことがあります。特にnpm install --ignore-scriptsはpostinstallの自動実行を防ぐ有効な手段ですが、一部のパッケージではビルドやネイティブモジュールのセットアップにpostinstallを使う場合があります。
そのため、全社で一律に禁止する前に、次のように段階的に進めると安全です。
| 対策 | 注意点 |
|---|---|
--ignore-scriptsの利用 | CIで失敗するパッケージがないか検証する |
| パッケージバージョン固定 | ロックファイルを必ずレビューし、意図しない更新を防ぐ |
| npmトークンのローテーション | CI/CDに保存されたトークン、個人アクセストークンも対象に含める |
| C2ブロック | ブロックだけで終わらず、過去通信ログも確認する |
| Defender除外設定の監査 | 攻撃者が除外設定を追加していないか確認する |
| CI/CDランナーの再作成 | 侵害が疑われるランナーは再利用せず、クリーンな環境から再構築する |
特に見落としやすいのは、Defenderの除外設定です。Microsoftの分析では、侵害後の段階でMicrosoft Defenderの除外を追加し、永続化を試みる挙動も説明されています。(Microsoft)
開発者が過去にパフォーマンス改善目的で設定した除外と、攻撃者が追加した除外を区別できるよう、変更履歴、管理者操作ログ、Intuneやグループポリシーの設定も確認してください。
被害が疑われる場合の対応手順
影響が疑われる場合は、次の順番で対応します。
| 手順 | 対応内容 |
|---|---|
| 1 | 該当端末・CI/CDランナーをネットワークから隔離する |
| 2 | Defender XDRでプロセス、通信、永続化、PowerShell実行を確認する |
| 3 | package-lock.json、node_modules、npmキャッシュからeasy-day-jsを確認する |
| 4 | Microsoftが公開したIOCと照合する |
| 5 | npm、GitHub、Azure、クラウド、CI/CDの認証情報をローテーションする |
| 6 | 影響した可能性のあるビルド成果物を再生成する |
| 7 | 依存関係管理ルールとpostinstall実行ポリシーを見直す |
ここで重要なのは、端末の削除やパッケージ更新だけで終わらせないことです。サプライチェーン攻撃では、侵害された開発環境から別の認証情報が窃取され、後から別経路で侵入される可能性があります。特にCI/CDのシークレット、npm publish権限、GitHub Actionsの権限、クラウドのデプロイ権限は優先して見直してください。
今回の件から見直したい開発環境の基本対策
Mastra npm supply-chain compromiseは、個別のnpmパッケージだけの問題ではありません。開発環境そのものを攻撃対象として扱う必要があることを示しています。
今後の再発防止として、最低限次の運用を整えておくと効果的です。
- 本番だけでなく、開発端末とCI/CDにもEDRを入れる
- npmパッケージ更新を自動マージせず、ロックファイル差分をレビューする
- メンテナーアカウントやnpm publish権限に多要素認証を適用する
- CI/CDシークレットを最小権限にし、定期的にローテーションする
- postinstallなどライフサイクルスクリプトの実行を可視化する
- Defender XDRのAdvanced Huntingで開発系イベントを定期監査する
- 不審なDefender除外設定やPowerShell実行を継続監視する
短期対応としては、easy-day-jsと影響を受けたMastra関連パッケージの有無、CI/CDログ、Defenderアラート、認証情報の露出可能性を確認します。中期対応としては、依存関係の固定、postinstall実行の制御、CI/CDシークレットの最小権限化、開発端末の監視強化を進めるべきです。
Mastraを使っている組織はもちろん、使っていない組織でも、今回の事例をnpmサプライチェーン攻撃の点検材料として活用できます。Microsoft Defender / Microsoft Threat Intelligenceを利用している場合は、公開IOCの照合だけでなく、自社の開発環境、認証情報、CI/CD権限まで含めて確認することが、実害を防ぐための最短ルートです。
コメント