社内のWindowsサーバーに不審な認証ログが記録されている。パスワードを変更したはずなのに、攻撃者が繰り返しアクセスしてくる――そんな事態が起きたとき、原因のひとつとして疑うべきなのが「パス・ザ・ハッシュ攻撃」です。
この記事では、パスワードをクラックしなくても認証を突破できる「パス・ザ・ハッシュ(Pass the Hash)攻撃」について、仕組みから防御手順まで現場で使えるレベルで解説します。Windows・Active Directory環境を管理している情シス担当者にとって、特に知っておいてほしい内容です。

パス・ザ・ハッシュ攻撃とは?
パス・ザ・ハッシュ(Pass the Hash、略称PtH)攻撃とは、Windowsのパスワード認証で使われる「NTLMハッシュ(パスワードを一方向変換した値)」を盗み取り、パスワードそのものを知らなくても認証を通過してしまう攻撃手法です。
通常、ネットワーク越しのWindows認証ではパスワードをそのまま送信するのではなく、パスワードをハッシュ化した値を使ったチャレンジ・レスポンスをやり取りします。パス・ザ・ハッシュはこの仕組みの「ハッシュがあれば認証できる」という性質を悪用します。
攻撃者が一度でも管理者権限を持つ端末に侵入できれば、メモリ上に保管されたNTLMハッシュを取り出し、そのハッシュをそのまま別のシステムの認証に使いまわします。平文パスワードを入手する必要がないため、パスワードをどれだけ長く複雑にしても、ハッシュが盗まれた時点では意味をなさないことがあります。これがPtH攻撃の最も危険な特徴です。
攻撃の仕組み――NTLMハッシュが「鍵」になる理由
WindowsのNTLM認証プロセスを防御目的で理解しておきましょう。
NTLMとは何か
NTLM(NT LAN Manager)は、Microsoftが設計したチャレンジ・レスポンス方式の認証プロトコルです。サーバーからチャレンジ値(ランダムな数列)を受け取り、クライアントはパスワードから生成したNTLMハッシュと組み合わせてレスポンスを返します。
この仕組みでは、ハッシュ値そのものが「クライアントの正当性を証明するもの」として機能します。攻撃者がハッシュを持っていれば、正規ユーザーと区別がつきません。
LSASS(ローカルセキュリティオーソリティプロセス)の役割
Windowsでは、LSASS(lsass.exe)というシステムプロセスが認証情報を管理しています。このプロセスはログオン中のユーザーのNTLMハッシュや、場合によってはパスワード情報をメモリ上に保持します。攻撃者が管理者権限を取得した後にLSASSのメモリをダンプすることで、ハッシュを抜き取ることが可能です。
攻撃の一般的な流れ
パス・ザ・ハッシュ攻撃の典型的なステップはおよそ次のとおりです。
・初期侵入: フィッシングメール・脆弱性悪用・パスワードリスト攻撃などで端末1台を制圧する
・特権昇格: ローカル管理者権限を取得してLSASSメモリにアクセスできる状態にする
・ハッシュ取得: LSASSメモリをダンプしてNTLMハッシュを取り出す
・横移動(ラテラルムーブメント): 盗んだハッシュで別の端末・サーバーに認証し、侵害範囲を拡大する
・目標達成: ドメインコントローラーに到達し、ドメイン全体の制御を掌握する
パス・ザ・ハッシュを使ったラテラルムーブメントの流れ
ラテラルムーブメント(内部横移動)にPtH攻撃がどう使われるかを整理しておくと、検知設計に役立ちます。
攻撃者はまず特権ハッシュを集めます。特に「全端末に共通のローカルAdministratorパスワード」が設定されている環境では、1台のハッシュを取れば全台に侵入できてしまいます。これは多くの企業のWindows環境でよく見られる状態で、攻撃者にとって都合のよい条件です。
次にSMB・RDP・WMIなどを経由してハッシュを流用します。Windowsの正規プロセスが使われるため、ログを見ただけでは「正規の管理操作なのか攻撃なのか」が判別しにくくなります。
最終的にはドメインコントローラーへ到達し、ゴールデンチケット攻撃など次の段階に進む踏み台となることが多いです。ドメイン全体が侵害されると、アカウントやパスワードを変更してもその効果が薄れてしまいます。
具体的な防御手順
1. LAPS(ローカル管理者パスワードソリューション)の導入
LAPS(Local Administrator Password Solution)は、Microsoftが提供するツールで、ドメイン参加端末のローカルAdministratorパスワードを端末ごとにランダム生成し、定期的に自動変更します。
全端末に共通パスワードを使う状態が最大の弱点であるため、LAPSを導入するだけで「1台のハッシュで全台侵入」という連鎖を断ち切れます。Windows Server 2019以降やWindows 11では「Windows LAPS」として組み込み機能化されており、追加コストなしで展開できます。
# Windows LAPS の有効化(PowerShell・ドメイン参加端末で実行) # ドメインスキーマの更新(ドメイン管理者が一度だけ実施) Update-LapsADSchema # GPO でLAPS有効化後、端末の状態を確認 Get-LapsADPassword -Identity "PC-NAME" -AsPlainText
2. Credential Guard と LSA Protection の有効化
Windows Defender Credential Guardは、仮想化ベースのセキュリティ(VBS)を使ってLSASSプロセスを隔離し、ハッシュをメモリから直接読み取る攻撃を防ぎます。Windows 10/11 EnterpriseおよびWindows Server 2016以降で利用できます。
LSA Protection(RunAsPPL)は、LSASS.exeをProtected Processとして動作させることで、署名のない外部プロセスからのメモリ読み取りを防ぐ機能です。グループポリシーまたはレジストリで有効化できます。
# LSA Protection をレジストリで有効化(再起動が必要) reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v RunAsPPL /t REG_DWORD /d 1 /f # 設定確認 reg query HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v RunAsPPL # 結果が 0x1 であれば有効 # グループポリシーの設定パス(参考) # コンピューターの構成 > Windowsの設定 > セキュリティの設定 # > ローカルポリシー > セキュリティオプション # 「ローカルセキュリティオーソリティ(LSA)の保護」を有効化
3. Protected Users セキュリティグループへの追加
Active Directory の「Protected Users」グループに特権アカウントを追加すると、そのアカウントに対して次の制限が自動的に適用されます。
・NTLMによる認証が禁止される: Kerberosのみで認証が行われるため、NTLMハッシュを盗んでも使えない
・資格情報のキャッシュが無効になる: ハッシュがメモリに残りにくくなる
・DES・RC4暗号の使用が禁止される: 弱い暗号化方式が排除される
ドメイン管理者アカウント・特権サービスアカウントをこのグループに入れるだけで、NTLMハッシュを盗んでも使えない状態を作れます。ただし、NTLMしか対応していない古いアプリケーションが動かなくなる可能性があるため、事前の影響調査が必要です。
4. NTLM認証の制限とKerberos強制
グループポリシーでドメイン内のNTLMをできる限り制限し、Kerberos認証を強制します。いきなり全禁止にするとアプリ障害が起きやすいため、段階的なアプローチをとります。
・Step 1(監査): NTLMの使用状況をイベントログで把握する(イベントID 4776・4624 ログオンタイプを確認)
・Step 2(制限): 「ドメインサーバーへのNTLM認証を拒否」ポリシーを段階的に適用する
・Step 3(例外管理): NTLMv2が必要なシステムを洗い出して例外処理し、順次移行する
# PowerShellでNTLM認証イベントを監査(ドメインコントローラーで実行) Get-WinEvent -LogName Security -FilterXPath ` "*[System[(EventID=4776)]]" | Select-Object -First 20 TimeCreated,Message # GPOでのNTLM制限設定パス(参考) # コンピューターの構成 > Windowsの設定 > セキュリティの設定 > ローカルポリシー # > セキュリティオプション # 「ネットワークセキュリティ: NTLM を制限する: このドメイン内のNTLM認証」
5. ネットワークセグメンテーションで横移動を封じる
攻撃者が1台侵害しても横移動できないよう、ネットワークをセグメント分割します。特に、一般端末どうしが直接通信できる「フラットなネットワーク」は最も危険な構成です。
・管理VLANの分離: サーバー管理用のアクセス経路を専用VLANに限定する
・端末間のSMB通信を禁止: Windowsホストファイアウォールで端末→端末のSMB(445番ポート)を遮断する
・ジャンプサーバーの設置: 管理操作は専用のジャンプサーバー経由に一本化し、直接RDPを禁止する
Active Directory環境の権限管理と監査ログ設計もあわせて整備することで、侵害の早期検知が可能になります。
中小企業でも今日からできること
「Credential GuardはEnterpriseエディションが必要」「LAPSの展開が大変そう」と感じる場合でも、まず取り組める施策があります。
・共通のローカルAdministratorアカウントを無効化・削除する: 全端末で同じパスワードを使っているなら、今すぐ廃止または無効化してください。これだけで連鎖侵害のリスクを大幅に下げられます
・管理者アカウントの日常利用を禁止する: ドメイン管理者アカウントで普段のPC作業をしないルールを徹底する。権限昇格が必要なときだけ使う運用に切り替えると、ハッシュがメモリに残る時間を最小化できます
・多要素認証(MFA)の適用範囲を広げる: VPN・リモートデスクトップ・Microsoft 365にMFAを設定する。NTLMが残っていても、MFAが要求される経路では攻撃の成功を難しくできます
・エンドポイント検知ツール(EDR)を導入する: LSASSへのメモリアクセスを試みる不審なプロセスをリアルタイムで検知できます
まずこの4点を整備してから、LAPS・Credential Guardの展開に進む順番が現実的です。
よくある誤解と注意点
「パスワードを変えればハッシュも無効になる」は正しいが、タイミングと調査が重要
パスワードを変更すれば古いNTLMハッシュは使えなくなります。しかし、攻撃者がすでにドメイン内に侵入してドメインコントローラーのハッシュを取得していた場合、パスワード変更前に新たなバックドアを仕込んでいる可能性があります。PtH攻撃を疑う場合は、パスワード変更だけでなくインシデント調査(侵害範囲の確認)をセットで実施する必要があります。
「Kerberosにすれば完全に安全」ではない
Kerberosを強制すれば確かにNTLMハッシュの再利用は防げます。ただし、Kerberosにも「ゴールデンチケット攻撃」「シルバーチケット攻撃」「パス・ザ・チケット(Pass the Ticket)攻撃」といった手法があります。NTLMを排除してKerberos環境を整えることは重要なステップですが、それだけで終わりではありません。
「一般ユーザーアカウントのハッシュは安全」ではない
管理者権限がないアカウントのハッシュでも、そのアカウントがアクセスできるファイルサーバー・メールサーバーへのなりすましには十分使えます。最小権限の原則を徹底し、ハッシュが盗まれた際の影響範囲を最小化することが重要です。
「検知が難しい」は「不可能」ではない
PtH攻撃はWindowsの正規プロセスを使うため検知が難しいとされますが、「同一アカウントが短時間に複数端末へ認証する」「管理者でない端末がSMBで他端末に接続する」などの異常パターンはSIEMやEDRで検知できます。ログ監視の設計も合わせて整えましょう。

本記事のまとめ
| 対策 | 効果 | 難易度 |
|---|---|---|
| LAPS導入(ローカルAdminパスワードのランダム化) | 横移動の連鎖を遮断 | 中(展開作業が必要) |
| Credential Guard有効化 | LSASSからのハッシュ窃取を防止 | 中(Enterprise版が必要) |
| Protected Usersグループへの追加 | 特権アカウントのNTLM認証を禁止 | 低(設定変更のみ) |
| NTLM制限とKerberos強制 | ハッシュ再利用の根本的防止 | 高(互換性調査が必要) |
| ネットワークセグメンテーション | 横移動の物理的な遮断 | 中(ネットワーク設計変更) |
| 共通ローカルAdminアカウントの廃止 | 最も即効性がある連鎖防止策 | 低(設定変更のみ) |
パス・ザ・ハッシュ攻撃は「パスワードを複雑にする」だけでは防げません。ハッシュを盗まれてもそれが使えない環境を設計することが本質的な対策です。まず共通ローカルAdminアカウントの廃止とProtected Usersグループの活用から始め、段階的にLAPS・Credential Guardへと強化していくのが現実的なロードマップです。
PR
詳解 インシデントレスポンス(Steve Anson/石川朝久訳)
パス・ザ・ハッシュ攻撃に代表されるWindows環境の侵害調査から証拠保全・根本原因分析まで、インシデント対応の全工程を体系的に解説した実践書です。Active Directory環境でのフォレンジック手法も詳しく扱っています。
