脆弱なWindowsを「要塞」に変える。レジストリ操作による認証セキュリティの深淵
現場でインシデント対応をしていると、どんなに強固なWAFを積んでいても、最終的に内部ネットワークに侵入した攻撃者が「OSの甘さ」を突いて横展開（ラテラルムーブメント）していく光景を嫌というほど見てきた。
特にWindows環境において、認証の脆弱性はまさに「ザル」だ。今回は、多くのエンジニアが見過ごしている、レジストリレベルでの認証強化について、泥臭い現実を交えて解説する。
—
なぜ「古い認証」が生き残っているのか
攻撃者は、ネットワーク内に足がかりを得た後、まず何をするか？ 答えは Mimikatz のようなツールを使ってメモリから認証情報を抜くことだ。ここで奴らが狙うのが、レガシーな認証プロトコルだ。
特に LMHash は、現代の計算機能力では一瞬でクラックできる「ゴミ」のようなものだが、後方互換性のためにWindowsはデフォルトで保持し続けている。これを無効化しないのは、玄関の鍵をかけずに「昔からの付き合いだから」とドアを開けておくようなものだ。
—
1. LMHashの無効化：認証の「ゴミ」を掃除する
LMHash を無効化することは、現代のWindowsセキュリティの第一歩だ。レジストリで NoLMHash を設定することで、認証強度が格段に上がる。
PowerShellによるレジストリ設定（管理者権限で実行）
以下のスクリプトを、サーバー構築時の自動化パイプラインやGPOのスクリプトに組み込んでほしい。
# LMHashを無効化するレジストリキーの設定
$regPath = "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa"
$name = "NoLMHash"
$value = 1
# キーが存在しない場合は作成し、値を設定する
if (!(Test-Path $regPath)) { New-Item -Path $regPath -Force }
Set-ItemProperty -Path $regPath -Name $name -Value $value -Type DWord
Write-Host "LMHashの無効化が完了しました。再起動後に適用されます。"—
2. LSA保護の有効化：パスワードハッシュを守り抜く
LSA (Local Security Authority) は、Windowsの認証を司る心臓部だ。通常、権限を持つプロセスなら誰でもLSAのメモリを覗き見ることができる。ここに「LSA保護（RunAsPPL）」をかけることで、特権プロセス以外からのメモリ読み取りを拒否させることができる。
レジストリ設定（RunAsPPL）
これも先ほどと同じく、レジストリの Lsa キーに設定を追加する。
# RunAsPPLを有効化（LSAプロセスの保護）
$regPath = "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa"
$name = "RunAsPPL"
$value = 1
Set-ItemProperty -Path $regPath -Name $name -Value $value -Type DWord警告: これを有効にすると、一部のサードパーティ製セキュリティソフトや古いドライバが「保護されたプロセス」として動作できずにエラーを吐くことがある。必ず検証環境でテストしてから本番に適用してくれ。検証を怠った結果、本番サーバーが起動しなくなったエンジニアを何人も見てきた。
—
3. アプリケーション層からの「ガード」：認証情報の漏洩を防ぐ
OSの設定を固めた後は、Webアプリケーション側でも「認証情報の取り扱い」に細心の注意を払う必要がある。例えば、PHPでバックエンドを構築している場合、ユーザーの資格情報をログに出力したり、不適切なセッション管理を行うことは論外だ。
実践：セキュアなセッション管理（PHP実装例）
認証後のセッションハイジャックを防ぐための、最低限の防御コードを載せておく。
<?php
// セッションIDの固定化攻撃を防ぐための設定
// 1. クッキーをJavaScriptからアクセス不可にする (HttpOnly)
// 2. SSL通信のみでクッキーを送る (Secure)
// 3. SameSite属性でCSRFを抑制
session_set_cookie_params([
'lifetime' => 0,
'path' => '/',
'domain' => 'yourdomain.com',
'secure' => true,
'httponly' => true,
'samesite' => 'Strict'
]);
session_start();
// セッションIDを再生成して古いセッションを破棄
session_regenerate_id(true);
?>—
最後に：セキュリティは「設定」で終わらない
レジストリをいじって NoLMHash を設定したからといって、安心しきってはいけない。攻撃者は常に「設定の隙間」を探している。
- 定期的な監査:
AuditPol等を使って、認証失敗のログを監視しているか？ - 権限の最小化: そもそも、そのサーバーでドメイン管理者権限が必要なプロセスが動いていないか？
セキュリティは「チェックリスト」を埋める作業ではなく、「どうすれば攻撃者のコストを最大化できるか」という思考ゲームだ。今回紹介した設定は、そのゲームの土俵に上がるための最低限の装備に過ぎない。
泥臭い現場の知見を積み上げ、常に「自分のサーバーは明日侵入される」という危機感を持って設計にあたってほしい。それが、君たちの手がけるシステムを守る唯一の道だ。
コメント