npmの27不正パッケージが「フィッシングの土台」に—営業・商用部門を狙うM365資格情報窃取の持続的キャンペーン

今日の深掘りポイント

• サプライチェーンの“侵害”ではなく“インフラ悪用”：npmとそのCDNを、静的フィッシングページのホスティングとして悪用する手口です。依存関係に組み込まれなくても被害が成立するため、従来のSCAやソフトウェア署名運用では見落としやすいです。
• 標的は技術部門ではなく営業・商用部門：見積・契約・RFP・購買といったビジネスプロセスの入口を狙うため、侵害後のBEC（ビジネスメール詐欺）や取引改ざんに直結しやすいです。
• 正規CDNドメインによる検知回避：unpkg/jsDelivrなど正規配信基盤のURLがメールゲートウェイやプロキシの信頼をすり抜け、URLレピュテーションの“盲点”になります。
• 迅速なローテーションが可能：パッケージ名・バージョンを差し替えるだけでインフラ更新ができ、封じ込め遅延を招きます。キャッシュやバージョニングも検出困難化に寄与します。
• 組織内“ネットワーク分離”の重要性：開発者向けCDNのアクセスはDevセグメントに限定し、営業・バックオフィスからの直接アクセスを原則禁止するなど、役割別のアウトバウンド制御が効果的です。

はじめに

報告によれば、攻撃者が27の悪意あるnpmパッケージを利用し、クライアントサイドのHTML/JavaScriptでフィッシングページを組み立て、被害者をMicrosoftサインインページに誘導するフローを構築しています。狙いは米国および同盟国の重要インフラ関連の組織に属する営業・商用担当者で、特定のメールアドレス群がハードコーディングされるほど標的選定が明確です。CDNを介した正規ドメインの利用により、ゲートウェイやプロキシの“許可されがちなネット宛先”を突き、検知・遮断の難度を押し上げています。

編集部が受け取ったメトリクス全体像からも、短期的な対応の必要性と発生可能性の高さが読み取れる一方、技術的な難易度は高くないため模倣の拡散も懸念されます。国家関与が疑われる旨の指摘もありますが、現時点では公開根拠が限定的なため断定は避け、TTPと標的選定の整合性から“高度に意図的なビジネスプロセス狙い”という評価に留めるのが妥当です。

深掘り詳細

事実整理（確認できる点）

• 攻撃者はnpmレジストリへ複数パッケージを投入し、そのCDN配信（例：unpkgやjsDelivr相当）を用いて静的フィッシングページを提供しています。
• フィッシングはMicrosoftサインインへリダイレクトさせる導線を持ち、資格情報の窃取を狙います。
• 標的は製造業・医療など重要インフラに近い業種の営業・商用担当が中心で、特定のメールアドレスがハードコーディングされるなど、事前偵察に基づくピンポイントな誘導です。
• 攻撃は依存関係を“組み込ませる”ことを前提にしておらず、メールやメッセージのリンクからCDN上のページへ直接誘導する構造です。

出典: The Hacker News

インサイト（なぜ効くのか／どこが盲点か）

• 供給網の“インフラ悪用”という転換点
  メジャーなOSSエコシステムは、レジストリとCDNという高信頼・高可用な配信基盤を備えます。攻撃者はこの基盤を“無料かつスケーラブルなWebホスティング”として使い、URLレピュテーションやドメインベースフィルタを回避します。これはサプライチェーン“侵害”より検出・帰属が難しく、撤去後もバージョンやパッケージ名の差し替えで再出現しやすいです。
• SCAと署名運用の適用限界
  依存関係の取り込みが不要なため、SCAやパッケージ署名、ビルド時のprovenance検証は直接効きません。むしろ“CDNアクセスの許容範囲”こそが防御上の要点で、部門別ネットワーク制御やプロキシの選別ロジックが問われます。
• 標的が営業・商用である理由
  営業・購買は外部とのドキュメント授受・リンククリック頻度が高く、個人名義の連絡先が公開されがちです。侵害後は見積・請求・銀行口座情報の改ざんなどBECに接続しやすく、短期での金銭的・信用的被害を狙えます。技術部門よりセキュリティ強度が相対的に低い組織も多く、MFAの実装差や条件付きアクセスの緩さを突かれやすいです。
• 監視ポイントの“非対称性”
  多くのSOCは悪性ドメインやURL短縮を嫌いますが、unpkgやjsDelivrのような正規CDNはブロックしづらい現実があります。プロキシログで“稀少なパッケージ名・version指定のHTML直叩き”“営業部セグメントからの開発者向けCDNアクセス”といったコンテキスト異常を拾える体制が差になります。

脅威シナリオと影響

• シナリオ1：リンク型スピアフィッシングからのM365アカウント乗っ取り
  営業宛メールの本文や添付から、CDN上のフィッシングページへ誘導。ID/パスワードを奪取し、組織のMicrosoft 365へ即時アクセス。メールルール改ざん、請求書テンプレート改変、外部取引先へのなりすましを通じBECを展開します。影響は短期的な金銭被害と、長期的な信用失墜です。
• シナリオ2：侵害アカウントを踏み台にした仕入・製造サプライヤへの横展開
  侵害済み営業メールボックスから既存スレッドへ割り込む形で取引先に“正規風の”リンクを拡散。同様のCDNホスティングページで連鎖的に資格情報を収集し、サプライチェーン全体のBEC/データ流出を誘発します。
• シナリオ3：一部でMFA疲労や代替経路の突破（仮説）
  資格情報窃取後、MFAが有効な場合は承認依頼の連打や、SMS/音声といった非耐タンパな要素を突く手口へ移行する可能性があります。これは一般的なアクターのTTPであり、今回も併用される余地があるという仮説です。

推定MITRE ATT&CKマッピング（仮説）:

• 偵察: T1593（公開Webの検索）—公開展示会やWeb上の連絡先からのアドレス収集の可能性
• リソース開発: T1583.006（Webサービスの獲得/悪用）—npm/CDNをホスティングとして利用
• 初期侵入: T1566.002（スピアフィッシングリンク）
• 偽装: T1036（正規インフラの外形を利用した偽装）
• 資格情報アクセス/収集: T1078（正規アカウントの不正利用）、T1567.002（Webサービス経由の流出）に接続し得る運用
• 影響拡大: T1114（メール収集）—既存スレッド乗っ取り、BEC拡大

上記は公開情報に基づく推定であり、インシデント対応では自組織のログと照合して確証を取る必要があります。

セキュリティ担当者のアクション

• ネットワーク/プロキシ制御
  • 開発者向けCDN（例：unpkg、cdn.jsdelivr、registry.npmjs.org等）へのアクセスを部門・セグメントで分離し、営業・バックオフィスからの直接アクセスを原則拒否します。
  • ドメイン単位の許可ではなく、パス/拡張子/利用頻度に基づくコンテキスト検知を導入します（例：営業セグメントからの“/package@version/index.html”直アクセスは高リスク）。
  • CDNキャッシュ経由での残存を想定し、否認リストだけでなく肯定リスト主導のポリシーを検討します。
• アイデンティティ防御
  • フィッシング耐性の高いMFA（FIDO2/WebAuthn）を営業・購買を含む全ユーザーへ拡大し、SMS/音声は原則廃止します。
  • 条件付きアクセスでリスクベースの制御（Impossible Travel、未知AS、旧式プロトコル拒否、トークン保護/短寿命化）を有効化します。
  • BEC対策として、転送ルール作成の監査・禁止、支払い口座変更プロセスの多段確認（Out-of-band）を徹底します。
• メール/エンドポイント防御
  • URL再書き換え後のサンドボックス解析で、正規CDN配下でもHTML/JSによるフォーム送信や認証画面模倣を検出するルールを強化します。
  • ブラウザ拡張・EDRでフォーム送信先が自社・Microsoft正規ドメイン以外の場合のポップアップ警告を導入します。
• ログ監視・ハンティング
  • プロキシ/HTTPログで“rare CDN URL”の検出（未知パッケージ名、HTML直参照、短時間でのversion切替アクセス）を定常化します。
  • M365サインインログで新規ASN/国からの成功、短時間での大量メールボックスルール作成、OAuthコンセント要求の異常を狩ります。
  • セキュリティチームは、ハードコーディングされたような特定メールアドレス群に対して、直近のURLクリック・失敗/成功サインイン・MFAプッシュ履歴を突合します。
• 開発・調達プロセス
  • SCAや署名検証は継続しつつ、業務部門が受け取る外部リンクの安全性検査を“開発系CDN”にも等しく適用します。
  • セキュリティ教育は役割別に更新し、営業・商用部門向けに“正規CDNでも危険”という事例を具体的に周知します。

参考情報

• The Hacker News: 27 malicious npm packages used as phishing infrastructure（英語）: https://thehackernews.com/2025/12/27-malicious-npm-packages-used-as.html

本件は“OSSサプライチェーンの侵害”というより、“OSS配信基盤の悪用”が本質です。技術的対策の主戦場はビルドではなく、ネットワーク・ID・メールの境界にあります。メトリクス全体像からも短期的な対処優先度は高く、まずは役割別のアウトバウンド制御とフィッシング耐性MFAの全社適用を加速するのが現実解です。