🐥

Shai-Huludのようなnpm 経由で侵入する Node.js 系マルウェアを切り口に、Windows 11 のセキュリティ構造を紐解く

に公開
npm
tpm
Shai-Hulud
サプライチェーン攻撃
windows11セキュリティ
idea

本記事では、Windows 11 環境で npm を利用している際に、「Shai-Hulud」のようなマルウェアに感染した場合、どの程度の危険性があるのかを明らかにすることを目的としています。ChatGPT から得た情報をもとに、私自身の考察を交えながら、Windows 11 のセキュリティ構造について解説します。 ※筆者は Windows 11 およびセキュリティ分野の専門家ではありませんので、内容は参考程度にご覧ください。

また、npm だけでなく Python の pip などにおいても、今後同様のサプライチェーン攻撃（コード供給元を狙った攻撃）が発生する可能性があります。したがって、開発環境として利用している Windows 11 がどのようなセキュリティ機構を備えており、どこまで保護されているのかを事前に理解しておくことは非常に有益だと考えます。

Shai-HuludとNode.jsマルウェアの脅威

ChatGptに聞いたプロンプト
「Shai-Huludに関連して、Windows11のセキュリティを紐解きたい。Shai-Huludはnpmによりマルウェアに感染させるものだが、実際の動作は、Node.jsのfsやprocess.envとfetchやAxiosを利用したものと考えられる。その場合、普通ファイルは危険だが、パスワードなどWindows11で管理している部分が安全かどうか解説してほしい。」

注意：上記プロンプトは「Node.jsのfsやprocess.envとfetchやAxiosを利用したものと考えられる。」というようにShai-Huludの定義について私がネットやAIに聞いて断定した質問になっているため、その質問に引っ張られた回答になっているかもしれません。というのもShai-Huludが本当に、こういうものなのかの確証はありませんのでご注意ください。

🧩 1. Shai-Huludとは（前提）

Shai-Hulud は 2024年に確認された npm パッケージ感染型マルウェア で、
Node.js の実行環境を狙い、開発者のマシン上で以下のような動作をします：

  • postinstall スクリプトなどで自動実行
  • fs モジュールでローカルファイルをスキャン
  • process.env で環境変数を収集
  • fetch や axios でリモートへ送信

つまり 「開発環境の情報窃取」 が主な目的です。
（npm login トークン、クラウドAPIキー、環境変数、SSH鍵 など）

補足：postinstallとは
npmパッケージには、インストールや更新のタイミングで自動的に実行される「ライフサイクルスクリプト（フック）」で、postinstallなどがある。postinstallとは、パッケージのインストール完了後に自動的に実行されるスクリプトです。package.jsonのscriptsセクションに定義できます。
定義場所：package.jsonのscriptsフィールドに記述します。

{
  "scripts": {
    "postinstall": "node steal.js"
  }
}

postinstall の有無をチェックすることは有効だが、それだけでは不十分です。
postinstall は代表的なトリガーですが、マルウェア作者は他にもたくさんの方法でコードを実行させます。

なぜ postinstall チェックだけでは不十分か

  • マルウェアは postinstall 以外の npm ライフサイクルスクリプトを使える（preinstall, install, prepare, prepublishOnly など）。
  • 悪意あるコードは 依存パッケージ側の package.json に仕込まれる（自分の package.json に無くても感染する）。
  • スクリプトは単純な node steal.js 以外に、難読化されたワンライナーや curl/powershell を呼ぶコマンドにできる。
  • ネイティブバイナリ（postinstall でビルドされるもの）や node-gyp を使ってネイティブコードを組み込む手法もある。
  • prepare や prepublish などは npm install や npm pack のタイミングで発動する。
  • scripts を直接使わず、install 時に依存の optionalDependencies や peerDependencies を経由してトリガーさせる手口もある。

🧠 2. Node.jsマルウェアの「到達範囲」

Shai-Hulud は Node.js の権限で実行されるため、
Node.js プロセスがアクセスできる範囲が攻撃対象になります。

Node.js が直接アクセスできるもの：

対象 取得可能性 説明
fs で読み取れるファイル あり 権限のあるユーザのホームディレクトリ内ファイルなど
process.env あり 各種環境変数（APIキー、DBパスワードなど）
process.cwd() や .env ファイル あり プロジェクト直下の設定ファイル
npm キャッシュや設定 あり npm トークンなどが残る場合

Node.js が直接アクセスできないもの：

対象 理由 セキュリティ構造
Windows Hello / BitLocker / TPM の秘密鍵 Node.js は OS レベルのキー保護領域にアクセスできない カーネルレベルで暗号化＋ハードウェアバインド
Windows Credential Manager の保存情報 取得には Win32 API（Credential Manager API）経由での明示的な権限が必要 通常の Node.js からは不可
ブラウザ保存のパスワード（Edge/Chrome） DPAPI（Data Protection API）で暗号化され、ユーザトークンが必要 Node.js スクリプト単体では解読不能
OS システムフォルダ (C:\Windows\System32) 管理者権限がなければ変更・読み取り制限あり UAC で保護

つまり：

🔐 「ファイルや環境変数レベル」までは危険だが、Windows 自体の認証情報（TPM, Credential Manager, DPAPI）は基本的に安全。

🧰 3. 実際に漏れうる情報の例

攻撃者が Shai-Hulud を仕込んだ npm パッケージを公開し、
開発者が npm install した場合：

  1. postinstall スクリプトで Node.js スクリプトが自動実行
  2. fs 経由で .env, .npmrc, .ssh/id_rsa などを読み込み
  3. process.env から AWS_ACCESS_KEY_ID などを抽出
  4. fetch or axios で外部サーバーへPOST送信

このように、「あなたの開発環境の中の秘密」（APIキーなど）は危険に晒されます。
ただし、Windows 11 自体が保持しているパスワードストアは暗号化・保護されており、直接は盗まれません。

🧱 4. Windows 11の保護メカニズム（Node.jsから見た壁）

保護層 仕組み Node.jsから突破可能か
UAC (ユーザーアカウント制御) 管理者権限要求をポップアップで確認 ❌ 不可能（明示的な昇格が必要）
TPM 2.0 秘密鍵をハードウェアで保護 ❌ 不可能
Credential Guard / LSA Protection 認証資格情報を隔離 ❌ 不可能
Windows Hello 生体情報はTPMに格納 ❌ 不可能
BitLocker ドライブ暗号化 ❌ 不可能（OS稼働中は論理的には復号状態）
DPAPI アプリ毎に暗号化鍵を分離 ⚠️ 不正利用は困難だが、同一ユーザー権限なら理論上復号可

🧮 5. まとめ

項目 安全性 補足
Node.js プロジェクト内の .env ❌ 危険 fsで容易に取得される
Windows Credential Manager のパスワード ✅ 安全 Node.js からアクセス不可
Edge/Chrome のパスワード ✅ 安全 DPAPI により暗号化
AWS/GCP のAPIキー（環境変数） ❌ 危険 process.envから取得可能
SSH秘密鍵 ❌ 危険 権限があれば読み取り可能
Windows Hello や BitLocker 鍵 ✅ 安全 TPM管理のため

🧭 対策まとめ

  1. npmパッケージのインストールは信頼できるもののみ

    • 特に postinstall スクリプトの有無を確認

  2. 環境変数に機密情報を直接書かない

    • .env ファイルを .gitignore する

  3. APIキーやトークンは Windows Credential Manager に保存し、アプリ側で取得する方法を使う

  4. Windows Defender + SmartScreen を常に有効に

  5. npm のセキュリティ監査

    npm audit

補足：npm auditとは、Node.jsプロジェクトの依存パッケージに含まれる既知の脆弱性を検出し、修正方法を提示するセキュリティ監査コマンドです。

プロンプト「Windows 11の保護メカニズムの保護層について、それぞれ詳細に解説してほしい。」

ChatGptの回答
以下では、先に挙げたWindows 11 の保護層それぞれについて、技術的な仕組み、何を守るのか、攻撃者（あるいは Node.js ベースのマルウェア）がどう振る舞えるかの観点、実務でできる対策を詳細に説明します。項目ごとに「仕組み → 攻撃面 → 対応策（実践）」の順でまとめます。必要に応じてすぐ使える確認コマンドや設定ポイントも書きます。

UAC（User Account Control: ユーザーアカウント制御）

仕組み

  • 標準ユーザー権限と管理者権限（Administrator）を明確に分離するWindowsの機能。
  • 高権限（管理者）操作を行うプロセスは「昇格（elevation）」が必要。昇格時にGUIで確認ダイアログ（Consent prompt / Credential prompt）を出す。
  • 多くの攻撃は管理者権限を必要とするため、UACは自動的なフル権限取得を難しくする防御層になる。

攻撃面（マルウェア視点）

  • UACが有効でも、ユーザが承認するとマルウェアは管理者権限を得られる（ソーシャルエンジニアリング）。
  • 一部の既知の「UACバイパス」手法（脆弱に設計された自動起動エントリや信頼済みプロセスの悪用）を使えば、昇格がユーザの明示的承認なしに可能になる場合がある（ただしこれらは OS のパッチで随時修正される）。
  • 一般的なNode.jsプロセスは最初は通常ユーザ権限で起動するため、UAC単体では .env やユーザファイルの読み取りを防げない。

対応策（実践）

  • UACを「最小権限」を保つ設定にする（既定のまま有効化）。
  • 管理者権限が必要な作業は専用の管理アカウントで行い、普段は標準ユーザアカウントを使う。
  • 不要な自動起動（スタートアップ）やサービスには管理者承認が必要な形で制御する。
  • システムのパッチを当て、UACバイパス脆弱性を解消しておく。

TPM（Trusted Platform Module）とSecure Boot

仕組み

  • TPM はマシンに内蔵された専用ハードウェア。暗号キーやプラットフォームの測定値（ブート時のハッシュ）を安全に保管・使える。
  • Secure Boot はUEFIレベルでブートローダー/カーネルが改ざんされていないか検証する仕組み。信頼チェーンを作る。
  • Windows 11 では TPM 2.0 と Secure Boot が推奨・要件になっている（セキュリティ強化目的）。

攻撃面

  • オフライン攻撃防止：ドライブを抜き取って別PCで解析したり鍵を抜くのが難しくなる（BitLockerの鍵がTPMに依存している場合）。
  • OSが稼働中でユーザがログイン済みだと、論理的にはメモリ中の鍵情報や復号済みデータにアクセス可能（＝TPMは主にオフライン保護や鍵の非移送性を担う）。
  • TPM自体をエミュレートするような高度な攻撃やファームウェア脆弱性があれば回避される可能性がある（稀だが注意点）。

対応策（実践）

  • TPM と Secure Boot を有効にして使う（Windows 11 の要件）。
  • BitLocker を TPM と組み合わせて使用し、回復キーは安全な場所（企業ではKey EscrowやAzure AD）に保管。
  • UEFI/TPM ファームウェアを最新に保つ（マザーボード・ベンダのアップデート）。

TPMを深堀

TPMは重要なので、CopilotにTPMについて深堀して質問して得た回答を貼っておきます。（主にpinが4桁でも安全な理由）
TPMには限定的な記憶領域があり、主に暗号鍵や認証情報を安全に保管します。PIN入力に対するマルウェア対策は試行回数制限だけでなく、応答遅延やロックアウト、ハードウェア隔離など複数の防御機構が組み合わさっています。

🧠 TPMの記憶領域について
  • TPMには内部ストレージ領域がありますが、容量は非常に限られています（数KB〜数十KB程度）。
  • 主に以下の情報を保持します：
    • ストレージルートキー（SRK）：TPMが生成する暗号鍵の親となる鍵
    • 認証情報（PINのハッシュなど）
    • プラットフォーム測定値（PCR）：セキュアブートやリモートアテステーションに使用
  • 秘密鍵はTPM外に出ることはなく、演算はTPM内部で完結します。
🛡️ マルウェアによるPIN入力への対策

TPMはPINのブルートフォースや不正入力に対して、以下のような多層的な防御を備えています：

対策機構 内容 効果
試行回数制限 PINの誤入力が一定回数を超えるとTPMがロックアウト ブルートフォース攻撃を防止
応答遅延（Rate Limiting） 認証失敗が続くと応答時間を意図的に遅らせる 自動化攻撃の効率を低下させる
ロックアウト期間 ロック解除まで一定時間待機が必要（例：10分で1カウント減） 継続的な攻撃を困難にする
ハードウェア隔離 TPMはOSやアプリから独立した領域で動作 マルウェアが直接アクセスできない
TPM所有権管理 WindowsがTPMの所有権を取得し、保護ロジックを実装 不正な承認値推測を検出し応答を停止
⚠️ 注意点と補足
  • TPMはPINそのものを記憶しているわけではなく、ハッシュ化された認証値を保持します。
  • TPM 2.0では、より高度なロックアウト管理が可能で、グループポリシーやPowerShellコマンドで制御できます。
  • PIN入力は物理端末上でのみ許可され、ネットワーク経由でのPIN送信は設計上排除されています。

BitLocker（ドライブ暗号化）

仕組み

  • ディスクの内容を暗号化することで、物理的にドライブを取り外して別PCで読み取ることを防止。
  • TPMと組み合わせると、正しいハードウェアとブートシーケンスがないと復号鍵を得られない。

攻撃面

  • OS稼働中にマルウェアが入り込めば、動いているシステム上ではファイルは読み書き可能（なぜならOSが復号しているため）。
  • 主な効果は「物理盗難 / ドライブ抜き取り対策」であり、実行中のプロセスから機密を守るものではない。

対応策（実践）

  • BitLocker を有効にする（TPM + PIN の二要素オプションがより安全）。
  • 回復キーはクラウド（Azure AD）やオフライン安全保管にする。
  • 盗難対策／データ保護の一環として導入する。

DPAPI（Data Protection API）とブラウザ/アプリのパスワード保存

仕組み

  • DPAPI は Windows が提供するAPIで、アプリケーションがユーザ単位やマシン単位でデータを暗号化できる仕組み。
  • ブラウザ（Edge, Chrome Windows版）は Windows の DPAPI（あるいは独自の暗号化 + DPAPI）を使って保存パスワードを暗号化することが多い。暗号鍵はユーザのログイン資格情報（NTLMハッシュ等）やDPAPIの内部鍵と結びつく。

攻撃面（重要なニュアンス）

  • 同一ユーザ権限のプロセスからは、DPAPIで暗号化されたデータを復号できる場合がある。なぜなら復号にはそのユーザの資格情報が使われるため、ユーザでログインしている状態・同じユーザコンテキストで動くマルウェアは CryptUnprotectData 等を呼んで復号可能。
  • つまり「DPAPIは強力だが、攻撃者が同一ユーザ権限でコードを実行できる場合は万能ではない」。ただし、LSA/Credential Guard などでさらに隔離されていれば難易度は上がる。

対応策（実践）

  • ブラウザやアプリの保存パスワードに依存しない。機密はより強い保管手段（ハードウェア-backed key、専用のシークレットマネージャ）へ。
  • 個人開発者でも、OSに平文の環境変数や .env を残さない（DPAPIに頼らずとも、ファイル自体が読まれれば終わり）。
  • 多要素認証（MFA）を各サービスで必ず有効化。
  • （個人的に思ったこと）アカウントを普段使いと開発で分けたほうがいいかもしれない。

Credential Manager / LSA (Local Security Authority) / Credential Guard（認証情報保護）

仕組み

  • Credential Manager は Windows が用意するユーザ資格情報の保管・管理機能（ネットワーク資格情報やWindows共有の資格など）。
  • LSASS（Local Security Authority Subsystem Service） はログオン認証情報を扱う主要サービス。これをダンプされるとパスワードやNTLMハッシュが流出する恐れがある。
  • Credential Guard は Virtualization-based Security (VBS) を使い、LSA を仮想化した隔離領域（VSM: Virtual Secure Mode）で実行させ、メモリダンプなどから資格情報が盗まれるのを防ぐ技術。

攻撃面

  • 伝統的攻撃では lsass.exe のメモリをダンプして認証トークンやハッシュを盗む手法が使われる（Mimikatz 等）。
  • Credential Guard が有効であれば、LSAの機密がハードに隔離され、通常のメモリダンプやプロセス注入でアクセスできなくなる。
  • ただし、Credential Guard を無効化したり、VSM自体に脆弱性があれば例外。

対応策（実践）

  • 企業では Credential Guard を有効にする（Group Policy や Windows Defender の設定で有効化）。ハードウェア要件（TPM, Secure Boot, VBS対応CPU）に注意。
  • LSA 保護（Run as a service を保護する LSA Protection）を有効にする。
  • 管理者権限の使用を極力制限し、特にドメイン管理者アカウントは別物理/分離された環境でのみ使用。
  • EDR（Endpoint Detection and Response）製品を導入し、lsass への不審なアクセスを検出する。

Virtualization-based Security (VBS) と Windows Defender Application Guard / Windows Sandbox

仕組み

  • VBS は仮想化機能（Hyper-V）を使って、システム内の敏感コンポーネント（LSA, Credential storesなど）を隔離。
  • Windows Defender Application Guard (WDAG) はブラウザコンテンツの隔離（信頼できないサイトを仮想コンテナで開く）を行う。
  • Windows Sandbox は一時的で隔離された軽量仮想環境を提供し、ダウンロードや不確実なアプリの実行に使える。

攻撃面

  • VBSにより、攻撃者がホストOSの通常メモリやプロセスを操作しても隔離領域には簡単に到達できない。
  • ただし、攻撃者がハイパーバイザをターゲットにするか、VBSの実装に脆弱性があれば回避される危険性がある（高度な攻撃）。

対応策（実践）

  • VBS（HVCI/Memory Integrity）を有効にしておくと、ドライバやカーネルレベルの悪用が難しくなる。
  • ウェブ閲覧は WDAG か Sandboxを活用してリスク分離を行う。
  • VBSを有効にするにはハードウェア要件や互換性チェックが必要（ドライバの互換性確認）。

Windows Defender（Microsoft Defender） と SmartScreen

仕組み

  • Microsoft Defender Antivirus：シグネチャ／ヒューリスティック／クラウド検出を使い、マルウェア防御を行う。
  • SmartScreen：ファイルダウンロードやURLの評判をチェックし、不明な実行ファイルの実行を警告する。
  • Defender のエンドポイント保護は、悪意ある挙動（挙動検知）を検出する能力を強めている。

攻撃面

  • 新規・ゼロデイのマルウェアは最初は検出されにくいが、振る舞いベースの検知やクラウド相関で後続検出されやすい。
  • マルウェアは通常、検出回避（難読化、ランタイム生成コード）を行うが、振る舞い検知はこれを補う。

対応策（実践）

  • Microsoft Defender を有効にし、リアルタイム保護とクラウドベース保護をオン。
  • SmartScreen を有効にして、未知の実行ファイルのダウンロードや実行時に警告を受ける。
  • 定期スキャンやEDRソリューションで不審な挙動を監視する。

コード整合性（Code Integrity）・WDAC（Windows Defender Application Control）・ASLR/DEP/CFG

仕組み

  • Code Integrity / WDAC：実行可能なコードをホワイトリスト管理し、署名されていないコードや未承認コードの実行をブロック。
  • ASLR（Address Space Layout Randomization） / DEP（Data Execution Prevention） / CFG（Control Flow Guard）：実行時のメモリ配置や実行保護でバッファオーバーフローやコード実行攻撃を難しくする。

攻撃面

  • 署名やホワイトリストが強いと、任意の EXE / DLL の実行が難しくなる（ただしスクリプト言語（PowerShell, Node.js）を介した攻撃は別ルートとなる）。
  • ASLR/DEP/CFG により、エクスプロイト成功率が下がるが、ブラウザのサンドボックスやプロセス間の脆弱性を突く高度攻撃は残る。

対応策（実践）

  • 企業では WDAC を利用して実行ポリシーを定め、署名済みバイナリのみ許可する運用にする。
  • Windows の「Exploit Protection」（システム/プログラム単位）を有効にし、ASLR/DEP/CFG を強制する。
  • スクリプト管理（PowerShell 言語モード、Constrained Language Mode）や実行ポリシーの監査。

実務的観点：Node.js / npm ベースの脅威に対する具体的対策（要点まとめ）

  1. 最小権限で実行

    • 開発環境でも日常作業は標準ユーザで行う。Nodeプロセスも管理者権限での起動を避ける。

  2. シークレット管理

    • .env に生のキーを置かない。Windows では Credential Manager、Azure Key Vault、HashiCorp Vault、秘密管理ライブラリを使用。

  3. npm の信頼性チェック

    • 不要なグローバルインストールを避け、パッケージのメンテナ・ダウンロード履歴・postinstall スクリプトを確認。npm audit を定期的に実行。

  4. 実行ファイルの検査とサンドボックス化

    • 不審なスクリプトは Windows Sandbox やコンテナで検査する。

  5. EDR/アンチウイルス導入

    • Defender＋場合によっては追加の EDR で挙動検知を行う。

  6. MFAとキーのローテーション

    • 漏洩時の被害最小化のために API キーやパスワードは短めにローテーションする。

  7. ログと検出

    • プロセス起動ログ、ネットワーク送信ログ、npm のインストールログを監査し、外部へのPOSTがあればアラート。

最後に（要約）

  • ファイルや環境変数など「ユーザ空間」にある秘密は、Node.js マルウェアに非常によく狙われる。
  • 一方で、TPM・Credential Guard・DPAPI（ハードウェア/隔離ベース）などOSの保護層は高い防御力を持つが、同一ユーザ権限で動くプロセスは一部を復号できるという重要な制約がある点に要注意。
  • 結論としては、OSの保護機能に頼るだけでなく、開発者側がシークレット管理を設計し直す（Vault利用、最小権限、回転／MFA）ことが最も効果的です。

所感

・Shai-Huludのような、npm 経由で侵入する Node.js 系マルウェアをパソコンに入れてしまった場合、Node.jsで実行できることはやられてしまうと思った。
・.envや.sshなど「ユーザ空間」にあるファイルは、見られる可能性が高いが、Windows11によって保護されている情報は、簡単には見られない。
・Windows11のセキュリティは強力だ思うが、理解するのは難しい。以下、個人的理解を簡単にまとめておきます。

・UAC（User Account Control: ユーザーアカウント制御）
「管理者の権限が必要です」というポップアップで保護。
・TPM（Trusted Platform Module）とSecure Boot
マシンに内蔵された記憶領域付き専用ハードウェア。重要なカギなどを保存。pinや顔認証でアクセスする。TPMに関しては、こちらのYoutubeを見るとイメージできます。
パスキーの話からTPMの役割がよくわかります。
https://youtu.be/SbhLvaWzngQ?si=LxDRdXBhT9FySYHY&t=428
・BitLocker（ドライブ暗号化）
ストレージを盗まれたときの対策だけで、パソコンの動作が遅くなるからOFFにしたほうがいいという情報をよく見ますが、通常使用時のセキュリティ向上の役目もあるかもしれないので私はONにしときます。
・DPAPI（Data Protection API）とブラウザ/アプリのパスワード保存
1番身近なのが、ブラウザで自動的にパスワードを入力するために保存されている機能。Edgeの設定、パスワードとオートフィル / Microsoft パスワード マネージャーから確認できる。個人的には、重要なサイトの本当のパスワードは保存せず、ドメインチェックのために適当なパスワードを保存しておき、ドメインが正しければ、そのパスワードがオートフィルされる。（フィッシングサイトの場合、ドメインが違うのでオートフィルされない）その後、本来のパスワードを手動で入れています。（面倒くさいですが）
・Credential Manager / LSA (Local Security Authority) / Credential Guard（認証情報保護）
1番身近なのが、GitHubでpushするときにGCMを使っている場合、ここでPAT（Personal Access Token）を管理。Windowsの場合（Credential Manager）スタートメニュー → 「資格情報マネージャー」「Windows資格情報」または「Web資格情報」から github.com で pushで使っているPATが確認できる。
・Virtualization-based Security (VBS) と Windows Defender Application Guard / Windows Sandbox
コンテナに閉じ込めて実行し、コンテナ外に出る情報を監視できる機能だと思う。サンドボックスについては、こちらで記事にしました。。
・Windows Defender（Microsoft Defender） と SmartScreen
Windows Defenderは、Windowsに標準搭載された無料のセキュリティ機能。SmartScreenとは、フィッシング詐欺サイトやマルウェアを含むウェブサイトへのアクセスや、安全でないファイルやアプリのダウンロードをブロックするWindowsのセキュリティ機能
・コード整合性（Code Integrity）・WDAC（Windows Defender Application Control）・ASLR/DEP/CFG
固定のコードの実行時やメモリに関する内容なので、個人的に後回しで学習でもいいと思った。

Windows11のセキュリティ設定をいじるのは、よく理解してないと再起不能になる可能性があるので私は基本的にデフォルトのままにしてます。
サンドボックスは、切り分けて、いろいろセキュリティ対策できそうなので勉強しようと思います。

Discussion