レジストリという名の最後の防壁：モダンWindowsハーデニングの深淵
国内外のインシデントレスポンスの現場に立っていると、どれほど巧妙なEDRや次世代ファイアウォールを導入していようとも、エンドポイントの足元がすくい取られる瞬間を幾度となく目撃する。攻撃者が侵入後に最初に狙うのは、ネットワークの境界ではない。ドメインコントローラーや重要サーバーのメモリ空間に眠る、平文同然の認証クレデンシャルそのものだ。
GUIのセキュリティ設定や一世代前のグループポリシー（GPO）をポチポチと変更して「要塞化完了」と安心しているエンジニアが多いが、それは実戦の脅威モデルを全く理解していない。サイバー犯罪者や国家系APTグループは、OSの低レイヤにおける認証プロトコルの歴史的負債（Legacy Debt）を熟知し、メモリのダンプやパケットの偽装によっていとも簡単に権限昇格を果たす。
今回は、Windowsの心臓部である「レジストリ」を直接叩き、OSの認証メカニズムの根本的な挙動を書き換えることで、こうした高度な攻撃ベクトルを物理的に遮断するための実践的なハードニング手法を、攻撃者の視点を交えながら徹底的に解説する。
—
1. 考古学的脆弱性の温床：LMHashの完全無効化
なぜNTLMよりもLMHashが危険なのか
今のモダンなWindows環境において、レガシーな認証プロトコルであるNTLMですら「時代遅れ」とされているが、そのはるか以前、Windows 9xやNT 4.0の時代から引き継がれている LM (LAN Manager) Hash がいまだにデフォルトでメモリ上に生成される仕様（あるいはその互換性維持）残っているとしたら、君のサーバーは最初から穴だらけだと言わざるを得ない。
LMHashの最大の欠陥は、その暗号学的脆弱性にある。
1. パスワードを最大14文字までに切り詰め、さらに大文字に変換する。
2. 7文字ずつに分割し、それぞれDES暗号化を行う。
3. 塩（Salt）を使用しないため、レインボーテーブルやブルートフォース攻撃に対して圧倒的に脆弱であり、数秒で平文のパスワードや等価のハッシュが導き出される。
攻撃者がメモリダンプツール（Mimikatz やタスクマネージャーのプロセスdump機能など）を用いてLSASS（Local Security Authority Subsystem Service）プロセスを侵害した際、LMHashが存在していれば、パスワードの復元は容易を極める。
レジストリによるLMHashの無効化と強制排除
この負債を断ち切るには、レジストリの NoLmHash パラメーターを操作し、OSに対してLMHashの生成・保存を一切行わないよう強制する必要がある。
以下のPowerShellスクリプトは、インフラストラクチャの自動デプロイやGPO適用前のベースライン設定として、確実に適用すべき設定である。
# =====================================================================
# Script Name: Disable-LMHash.ps1
# Description: LMHashの生成を無効化し、メモリ上の認証強度を向上させる
# Target: Windows Server 2012R2 / 2016 / 2019 / 2022, Windows 10 / 11
# =====================================================================
$RegPath = "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa"
# レジストリアイテムの存在確認と作成・値の設定
if (-not (Test-Path $RegPath)) {
New-Item -Path $RegPath -Force | Out-Null
}
# NoLmHash 値を 1 に設定することで、LMハッシュの生成を禁止する
Set-ItemProperty -Path $RegPath -Name "NoLmHash" -Value 1 -Type DWord
Write-Host "[+] LMHashの無効化が正常にレジストリに適用されました。" -ForegroundColor Green
Write-Host "[*] 完全に有効化するには、システムの再起動が必要です。" -ForegroundColor Yellowこの設定を行うことで、たとえ攻撃者がLSASSのメモリ空間にアクセス権を得たとしても、LMHashベースの脆弱なクレデンシャルを窃取することは不可能になる。
—
2. LSASSの聖域化：PPL（Protected Process Light）の強制有効化
LSASSメモリダンプという悪夢
ペネトレーションテストやレッドチーム演習において、Windowsマシンのローカル管理者権限（NT AUTHORITY\SYSTEM）を奪取した攻撃者が最初に行うルーティンは、ほぼ間違いなく lsass.exe のプロセスダンプである。
LSASSは、ユーザーのログオン、パスワード変更、アクセストークンの検証などを一手に担う極めて重要なプロセスであり、そのメモリ空間には、Kerberosチケット、NTLMハッシュ、さらには平文のパスワード（WDigestが有効な場合）がむき出しの状態でキャッシュされている。従来のWindowsでは、管理者権限を持つユーザーであれば、いかなるプロセスからもLSASSのメモリを読み取ることができた。これが、ランサムウェアやAPTがラテラルムーブメント（横展開）の足がかりを築く最大の原因である。
PPL（Protected Process Light）による防御レイヤ
この脆弱な挙動を防ぐため、Microsoftは PPL (Protected Process Light) という仕組みを提供している。LSASSを「保護プロセス」として動作させ、信頼された署名（Microsoftのコード署名）を持つプロセス以外からのメモリ読み取りやハンドル取得を、カーネルレベルで完全にブロックする。
しかし、厄介なことに、一部の古いサードパーティ製セキュリティ製品や監視エージェントがLSASSのメモリにフックをかける必要があったため、OSのデフォルトではPPLが強制有効化されていないケースが多い。
以下のレジストリ設定により、LSASSをPPLとして強制起動させることができる。
# =====================================================================
# Script Name: Enable-LsaProtection.ps1
# Description: LSASSプロセスを保護（PPL）し、メモリダンプ攻撃をブロックする
# =====================================================================
$RegPath = "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa"
if (-not (Test-Path $RegPath)) {
New-Item -Path $RegPath -Force | Out-Null
}
# RunAsPPL を 1 に設定 (再起動が必要)
Set-ItemProperty -Path $RegPath -Name "RunAsPPL" -Value 1 -Type DWord
# UEFIセキュアブート環境や仮想化ベースのセキュリティ(VBS)と併用する場合は
# RunAsPPLBoot设置为 2（オプションだが、より強固な保護）
# Set-ItemProperty -Path $RegPath -Name "RunAsPPLBoot" -Value 2 -Type DWord
Write-Host "[+] LSA保護 (RunAsPPL) の設定が完了しました。" -ForegroundColor Green
Write-Host "[!] 注意: サードパーティ製の古いEDRや監視ツールが動作不良を起こす可能性があります。必ず検証環境でテストしてください。" -ForegroundColor Redアーキテクチャ上の注意点と監査の観点
RunAsPPL を有効化すると、悪意あるツール（Mimikatz の sekurlsa::logonpasswords や ProcDump など）を使ったメモリ抽出は、カーネルによって即座に拒否され、Access is denied （エラーコード 5）が返されるようになる。
ただし、セキュリティ監査の現場では、「設定したつもり」になっていて実はサードパーティ製ドライバーによって無効化されているケースを見落とすな。必ずイベントログ（Security-Auditing イベントID 4673 や 3000番台）を監視し、LSASSへの不正なアクセス試行が確実にブロックされているかを検証するパイプラインを構築しておくべきだ。
—
3. その他の極秘裏に強化すべき認証関連レジストリ
LMHashの無効化とLSA保護の他にも、OSの認証要塞化において絶対に外せないレジストリ設定が存在する。これらは攻撃者が好む「踏み台」のシナリオを根底から断つための防壁となる。
1. WDigest認証の無効化（平文パスワードキャッシュの禁止）
Windowsはデフォルトで、HTTPやWebDAVなどを介した認証を高速化するために、LSASS上にユーザーのパスワードを「平文」でキャッシュする（WDigest）。これが有効なままだと、LSASSのメモリを覗き見られた瞬間に平文パスワードが完全に露出する。
# WDigestによる平文パスワードのキャッシュを無効化
$WDigestPath = "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest"
if (-not (Test-Path $WDigestPath)) { New-Item -Path $WDigestPath -Force | Out-Null }
Set-ItemProperty -Path $WDigestPath -Name "UseLogonCredential" -Value 0 -Type DWord2. NTLMv1の完全排除とNTLMv2の強制
ネットワーク認証において、脆弱なNTLMv1やLM応答の使用を許可している環境は、現代のセキュリティ基準においては論外である。クライアントおよびサーバー間の認証レベル（LmCompatibilityLevel）を厳格化する。
# 認証レベルを「NTLMv2のみ送信し、NTLMv1は拒否する」に設定
$LsaPath = "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa"
Set-ItemProperty -Path $LsaPath -Name "LmCompatibilityLevel" -Value 5 -Type DWord*値 5 は、クライアントはNTLMv2のみを送信し、サーバーはNTLMv1の接続を拒否、NTLMv2のみを受け入れる最強のセキュリティレベルを意味する。*
—
4. チーフセキュリティアーキテクトからの提言：自動化と監視のループ
レジストリによる要塞化は、一度スクリプトを実行して終わりではない。組織全体のインフラストラクチャがスケールするにつれて、GPOの適用漏れや、マスターイメージ（Golden Image）の古さによって、いつの間にか脆弱な設定が再発泡（Drift）する現象が頻発する。
真に信頼できるセキュリティ体制を構築するためには、以下の3層の防御と監査ループを回し続ける必要がある。
1. Infrastructure as Code (IaC) による不変のベースライン
TerraformやAnsible、あるいはIntune / GPOを用いて、デプロイの初期段階で必ず上記のレジストリ値が強制適用されるパイプラインを構築する。
2. EDR/SIEMによるレジストリ改ざん検知
攻撃者が権限昇格後にセキュリティ設定をバイパスするため、レジストリの RunAsPPL や NoLmHash の値を書き換えようとする試み（レジストリキーの変更イベント ID 4657）をリアルタイムで検知し、SOC（Security Operation Center）へアラートを飛ばす仕組みを実装する。
3. 定期的なコンプライアンススキャン
CIS BenchmarksやSTIGなどの業界標準フレームワークに基づき、組織内の全Windowsサーバーのレジストリ状態を定期的に自動スキャンし、スコア化して経営層や開発チームにフィードバックする。
脆弱性は常にシステムの最もメンテナンスが行き届いていない、あるいは「過去の互換性のために残された」隙間を突いてやってくる。レジストリの深淵をコントロールすることは、単なる設定変更ではなく、OSの根幹における信頼の基盤（Root of Trust）を取り戻す作業に他ならない。泥臭く、しかし圧倒的な技術的裏付けを持って、自社のインフラストラクチャを真の要塞へと仕立て上げてほしい。
コメント