北朝鮮ハッカー集団Sapphire Sleet、Mastra AIのnpmパッケージ145個を88分で侵害

影響を受けたパッケージの週間ダウンロード数は合計110万を超える 。この攻撃はAI開発者エコシステムに衝撃を与え、Microsoftは即座にセキュリティポリシーの変更を余儀なくされた。同社は2026年6月19日、本攻撃を高い確度でSapphire Sleetの仕業と断定した 。

侵害の仕組み

攻撃チェーンは、セキュリティ研究者が長年警告してきたパターン——そしてパッケージレジストリが現在排除を急いでいるまさにその認情報の脆弱性——を悪用したものだった。

ステップ1：ソーシャルエンジニアリングとアカウント乗っ取り

攻撃者はまず、Mastraの正規メンテナーに対してソーシャルエンジニアリングを仕掛け、npmアカウントの認証情報を入手することに成功した 。侵害された「ehindero」というアカウントは、@mastraスコープ全体に対する公開権限を持っていた 。

ステップ2：高速な一括公開

乗っ取ったアカウントを用い、攻撃者は@mastra/*名前空間の全パッケージを88分間で再公開した。一部の報告では、この一括公開はわずか19分で行われたとされる 。この速度は、手動ではなく自動化された公開スクリプトの使用を示唆している。

ステップ3：悪意ある依存関係の注入

侵害された各パッケージには、easy-day-js という悪意ある依存関係が仕込まれていた。これは正規の日付ライブラリ「dayjs」を装ったタイポスクワッティングである 。セキュリティ研究者はこのキャンペーンを「easy-day-js」と命名している 。

ステップ4：自動ペイロード実行

悪意あるコードはnpmの postinstall スクリプトを介して自動実行されるよう設計されていた。影響を受けたパッケージを npm install した開発者は、アプリケーションコードを実行するまでもなく、即座にペイロードを起動することになる 。

ステップ5：認証情報と暗号資産の窃取

実行されると、ペイロードは開発者のワークステーションやビルドシステムから暗号資産ウォレットの鍵、クラウド認証情報、CI/CDシークレットを収奪した 。さらに、TLS検証を無効化し、攻撃者の管理するインフラから第2段階の情報窃取マルウェアをダウンロードした 。

属性（アトリビューション）

Microsoftは2026年6月19日、高い確度で本攻撃がSapphire Sleetの仕業であると断定した。同グループは主に金融・暗号資産セクターを標的とする北朝鮮の国家支援アクターである。Microsoftは、これまでに文書化されたSapphire Sleetの活動と一致するインフラおよびTTPs（戦術・技法・手順）を根拠として挙げている 。Amazon Threat Intelligenceもまた、axios、debug、chalk、typo-cryptoを含む他のnpmパッケージ侵害キャンペーンとSapphire Sleetを関連付けている 。

Microsoftのセキュリティ対応

Mastra攻撃は、Microsoftが既に進めていた複数のセキュリティ変更を加速させた。同社は、Sapphire Sleetが悪用したまさにその認証情報ベクトルを排除することを目的とした2つの主要なポリシー変更を発表した。

1. NuGet APIキーの有効期間を30日に短縮

2026年8月17日より、新たに作成されるNuGet.org APIキーの最大有効期間が365日から30日に短縮される 。2026年8月17日より前に作成された全てのAPIキーは、2026年11月1日に強制的に失効する 。

その根拠は明白だ。「失くしやすいゆるい紐」と評される長期有効なAPIキーは、サプライチェーン侵害の主要な攻撃ベクトルとなっている 。盗まれたキーは、攻撃者にトロイの木馬化されたパッケージを公開するための長い猶予を与える。これはMastraインシデントや最近のNX Console npm侵害で起きたことと全く同じである 。

2. Trusted Publishing（OIDCベース）を推奨デフォルトに

Microsoftは全てのパッケージメンテナーに対し、長期有効なAPIキーを短期間のOpenID Connect（OIDC）認証に置き換える最新ワークフローTrusted Publishingへの移行を強く推奨している。これは2025年9月に導入された機能である 。

Trusted Publishingの主な利点 ：

• 長期有効なシークレットが不要：リポジトリやCI/CDシステムに保存する必要がない
• 公開ごとに発行される短期認証情報：自動的に期限切れとなる（通常約1時間）
• ワークロードIDの検証：ポリシーで設定されたリポジトリ、ワークフロー、オプションの環境に対して検証を行う
• 手動のシークレットローテーションが不要
• 認証情報が漏洩した場合の影響範囲（ブラストラディウス）を大幅に削減

Trusted Publishingを使用するCI/CDワークフローが実行されると、プロバイダー（例：GitHub Actions）から暗号化署名付きOIDCトークンを要求する。NuGet.orgは、そのトークンを登録された公開元ポリシーに照らして検証し、その公開セッションでのみ有効な一時的なシングルユースAPIキーを発行する 。

3. エコシステム全体の対策

いくつかの補完的な変更が、Microsoftの対応を支援している：

• npm Classicトークンの失効：npmは2025年12月に全てのClassic長期トークンを永久に失効させた。npm login コマンドは現在、2時間のセッショントークンのみを発行する 。

• npm Granularトークンの有効期限短縮：新たな書き込み可能なGranularアクセストークンの有効期限は、従来の無制限・30日デフォルトから、7日間デフォルト、最大90日間に短縮された 。

• npm Staged Publishing：2026年5月に一般公開され、メンテナーがリリースを公開前に承認するために2FA認証を通過することを必須とする機能である 。

これらの対策は、Sapphire Sleetが悪用したもの——パッケージスコープ全体への公開権限を持つ、長期間有効で脆弱に保護された単一のnpmメンテナートークン——を排除することを目的としている。

開発者・メンテナー向けの重要ポイント

• 既存のNuGet APIキーを今すぐローテーションする：2026年8月17日より前に作成されたキーは、2026年11月1日に失効する。それまでに新しいキーを生成するか、Trusted Publishingに移行すること 。

• 可能な限り早期にTrusted Publishingを採用する：OIDCベースの認証は、CI/CDパイプラインに長期有効なシークレットを保存する必要性を排除する。NuGet.org、npm、PyPIでサポートされている 。

• npmの公開ワークフローを見直す：npmは現在、短期セッショントークン、有効期限が制限されたGranularトークン、Staged Publishingを使用している。CI/CDパイプラインがこれらのサポートされる認証方式のいずれかを使用するように更新されていることを確認すること 。

• パッケージバージョンを固定し、自動的な依存関係アップグレードを避ける：特に重要なインフラストラクチャでは、正常と確認されたバージョンを固定することで、侵害されたパッケージを誤って含めるリスクを回避できる 。

• パッケージインストール時の自動スクリプト実行を無効にする：npm install --ignore-scripts を実行する（またはグローバルに ignore-scripts = true を設定する）ことで、悪意のある postinstall スクリプトの実行を防ぐことができる 。