【DFIR最前線】メモリから暴く「Mimikatz」の足跡：lsass.exeを守り抜くための鉄則
現場でインシデント対応をしていると、決まって遭遇するのが「lsass.exe」を巡る攻防です。攻撃者が一度ドメイン環境に足がかりを作れば、彼らは迷わず lsass.exe のメモリをダンプし、平文パスワードやNTLMハッシュをかっさらおうとします。
「EDRを入れているから大丈夫」と高を括っているそこのあなた。攻撃者はそのEDRのフックを回避する手法を常に開発しています。今回は、メモリフォレンジックの観点から、Mimikatzが残す生々しい爪痕を追い、エンジニアが今日から打てる「防御の要」について解説します。
—
1. なぜ「lsass.exe」が狙われるのか？
Windowsの認証サブシステムである lsass.exe（Local Security Authority Subsystem Service）は、ユーザーがログオンするたびに、その認証情報（Kerberosチケット、NTLMハッシュなど）をメモリ上に保持します。
攻撃者が行うのは、このメモリ領域に対する「読み取り」です。Mimikatzの sekurlsa::logonpasswords コマンドがまさにそれですが、彼らは生のダンプを行う代わりに、最近では「MiniDumpWriteDump」APIを悪用したり、難読化されたメモリ読み取り手法を駆使したりします。
フォレンジックの視点：何を見るべきか？
メモリイメージ（memdump.raw）を Volatility 等で解析する際、私たちは以下の点に注目します。
- 異常なハンドル:
lsass.exeに対してPROCESS_QUERY_INFORMATIONやPROCESS_VM_READ権限を要求している怪しいプロセスはないか。 - 非署名モジュールのロード:
lsass.exeのアドレス空間にインジェクトされた未知のDLL。 - ログの不整合: イベントID 4663（オブジェクトアクセス）や、プロセスの起動順序の不自然さ。
—
2. 実践的防御：攻撃の芽を摘む実装と設定
「メモリダンプを検知する」のは重要ですが、それ以前に「メモリダンプをさせない」環境を作ることが、我々エンジニアの責務です。
対策1：Credential Guard の強制有効化
Windows 10/Server 2016以降であれば、Credential Guard は必須です。これは仮想化ベースのセキュリティ（VBS）を使用して、lsass.exe の認証情報を隔離された空間に守る仕組みです。
グループポリシーでの設定:
1. コンピューターの構成 > 管理用テンプレート > システム > Device Guard
2. 仮想化ベースのセキュリティを有効にする を「有効」に設定
3. 資格情報ガードの構成 を「有効（UEFI ロックあり）」に設定
これだけで、Mimikatzの標準的な手法によるメモリからのパスワード抽出はほぼ無効化されます。
対策2：アプリケーション側の防御（特権管理の徹底）
Webアプリやサービスを実行するアカウントに「管理者権限」や「SeDebugPrivilege」を持たせていませんか？それが攻撃者の踏み台になります。
もしアプリケーション側でクレデンシャルを扱うなら、決して生のパスワードをメモリ上に長く保持せず、即座に暗号化処理を行うべきです。Pythonでの安全なハッシュ保存例を示します。
import hashlib
import os
# パスワードを直接メモリに置かず、ソルト付きハッシュで管理する例
def generate_secure_hash(password: str):
# 強力なソルトを生成
salt = os.urandom(32)
# 256bit以上のハッシュアルゴリズムを使用
hash_obj = hashlib.pbkdf2_hmac(
'sha256',
password.encode('utf-8'),
salt,
100000 # イテレーション回数は多めに設定
)
return salt, hash_obj
# 解説: パスワードを比較する際も、生の文字列を比較せず、
# 入力値を同様にハッシュ化してから比較（hashing check）することで、
# メモリダンプから平文を抜き取られるリスクを軽減します。—
3. Web/API層からの攻撃を防ぐ（WAF設定のTips）
意外かもしれませんが、Webアプリケーションの脆弱性を突いてバックドアを設置し、そこから lsass.exe にアクセスされるケースが増えています。以下のNginx設定のように、不要な特権コマンドの実行をブロックするルールをWAF/IPSに組み込んでおきましょう。
# Nginx/ModSecurity等での攻撃パターンブロック設定例
# Mimikatz等のツールでよく使われる文字列をリクエストヘッダやBodyから検知
location / {
# 悪意ある文字列をブロックする正規表現例
if ($request_body ~* "(sekurlsa|logonpasswords|dump|lsass)") {
return 403;
# ログに記録し、管理者にアラートを飛ばす設計にすること
}
}—
最後に：エンジニアが持つべき「疑いの目」
インシデントレスポンスの現場で私が常に伝えているのは、「ログがない場所で何が起きているかを想像せよ」ということです。
lsass.exe のメモリを読まれるということは、ドメイン環境において「王鍵」を奪われることを意味します。防御は多層的であるべきです。
1. Credential Guard でメモリを保護する。
2. 最小権限の原則 を徹底し、サービスアカウントに不必要な権限を与えない。
3. EDRの感度 を上げ、lsass.exe へのアクセスをトリガーに即時遮断する設定を入れる。
皆さんの管理するシステムが、攻撃者にとって「割に合わないターゲット」になるよう、地道な設定の積み重ねを怠らないでください。それが、私たちのプロとしての仕事です。
もし「メモリダンプの痕跡を見つけた」という緊急事態に直面したら、焦らずにプロセスのダンプを取得し、Volatility等のツールで「誰が・いつ・何のために」アクセスしたのかを追跡してください。その一歩が、被害を最小限に抑える鍵になります。
コメント