現場のDFIRから教える：LSASSダンプという「特等席」を奪い返すための防御戦略
インシデント対応の現場にいると、必ずと言っていいほど遭遇するのが lsass.exe のメモリダンプです。攻撃者は、Windowsの認証を司る心臓部である Local Security Authority Subsystem Service (LSASS) を狙い撃ちし、そこに眠るパスワードやハッシュを吸い出そうとします。
「Mimikatzを叩かれたら終わり」というのは半分正解ですが、半分は怠慢です。なぜ彼らがそこを狙うのか、そしてシステム運用側はどうやってその「特等席」をガードすべきか。泥臭い現場の知見を共有します。
—
1. なぜ攻撃者はLSASSを血眼で探すのか
Windowsにおいて、ログインユーザーの資格情報は lsass.exe のメモリ空間にキャッシュされます。攻撃者が管理者権限（SeDebugPrivilege）を奪取した瞬間、彼らは procdump や comsvcs.dll を悪用してこのプロセスをダンプし、Mimikatzで解析します。
特に恐ろしいのは、一度ハッシュやチケットを手に入れれば、たとえパスワードを変更しても攻撃者は「Pass-the-Hash (PtH)」や「Pass-the-Ticket (PtT)」で、あなたのネットワークを徘徊し続けられる点です。これは、パスワードの変更だけでは追放できないことを意味します。
2. 現場で使える「泥臭い」防御策
「アンチウイルスを入れているから大丈夫」というのは幻想です。現代の攻撃者はカスタムバイナリやメモリ内実行で検知を回避します。私たちがとるべきは、「奪われることを前提とした防御」です。
A. Credential Guard の強制（必須）
Windows 10/11およびServer 2016以降であれば、仮想化ベースのセキュリティ（VBS）を利用した Credential Guard を有効にするのが最強の対策です。これにより、LSASSのメモリから資格情報が分離され、Mimikatzがアクセスしても「空っぽ」のデータしか返しません。
設定手順（グループポリシー）:
1. コンピューターの構成 > 管理用テンプレート > システム > Device Guard
2. 仮想化ベースのセキュリティを有効にする を「有効」に設定
3. 資格情報のガードを構成する を「有効（UEFIロック付き）」に設定
—
3. 実装の現場：特権アカウントを守るための考え方
開発者やインフラエンジニアが最もやってはいけないのは、「サーバーに管理者として永続的にログインし続けること」です。
もしあなたがWebアプリ開発の現場で、管理者用のスクリプトを書くなら、権限を最小化し、認証情報をメモリに残さない設計を徹底してください。以下は、Pythonでセキュアに認証情報を扱う（または避ける）ためのベストプラクティスの断片です。
Python：環境変数とシークレットマネージャーの活用
コード内に認証情報を直書きするのは論外です。また、メモリ上に平文で長く保持するのもリスクです。
import os
from secret_manager import get_secret # AWS Secrets ManagerやHashiCorp Vaultのクライアント想定
def execute_privileged_task():
# 認証情報は実行時にのみ取得し、グローバル変数に保持しない
# メモリダンプ時に見つかるリスクを最小化する
db_password = get_secret("DB_PROD_PASSWORD")
try:
# DB接続などの処理
print("タスク実行中...")
finally:
# 処理が終わったら直ちにゼロ埋めする等、メモリ上の生存期間を意識する
db_password = None
del db_password
if __name__ == "__main__":
execute_privileged_task()—
4. 監視による「異常」の検知
防御だけでなく、攻撃の痕跡を早期に見つけることも重要です。Sysmonを導入し、以下のイベントIDをトリガーにSOCでアラートを飛ばす設定をしてください。
- Event ID 10 (ProcessAccess):
lsass.exeに対するアクセス。特にGrantedAccessが0x1010や0x1410といった強力な権限の場合、高確率で攻撃です。 - Event ID 7 (ImageLoad):
lsass.exeに不審なDLL（mimilib.dll等）がロードされていないか監視。
Sysmon設定ファイル（抜粋）:
<RuleGroup name="lsass_protection" groupRelation="or">
<ProcessAccess onmatch="include">
<!-- LSASSへの不審なアクセスを検知する -->
<TargetImage condition="end with">lsass.exe</TargetImage>
<GrantedAccess condition="begin with">0x10</GrantedAccess>
</ProcessAccess>
</RuleGroup>—
最後に：エンジニアとしての矜持
「セキュリティは面倒」と感じるかもしれません。しかし、インシデント対応の現場で、たった一人の管理者の資格情報漏洩から組織全体が制圧される様子を何度も見てきました。
LSASSは、攻撃者にとっての「金庫」です。その金庫の鍵を不用意にシステム上に放置せず、権限分離を行い、異常なプロセスアクセスを即座に検知する。この「守りの作法」を徹底することが、結果としてあなたのエンジニアとしての価値を高め、組織を救うことになります。
今日から、自身の開発環境で「認証情報がどこでどう使われ、メモリ上にどう滞留するか」を一度考えてみてください。それが、最強のDFIRへの第一歩です。
コメント