本記事で扱う内容
とある業務でMimikatzを実行する機会があったのですが、Windows 11だと思うように動かず、色々調べたまとめとしてMimikatzの動作原理からWindows 11に備わっている主要なセキュリティ機構を紐解いていきます。
キーワード
- Mimikatz
- LSA（Local Security Authority）
- LSASS（Local Security Authority Subsystem Service）
- PPL（Protected Process Light）
- Secure Boot
- UEFI（Unified Extensible Firmware Interface）
- Credential Guard
なお、有識者から見ると「ここ、厳密には違くない？」となる箇所があるやもしれませんが、全体的なイメージを掴むため簡略化している部分もございますので何卒ご容赦ください。
OSというのは非常に難解で、筆者も詳細な動作原理を説明できる知識レベルに達していない点も合わせてご理解いただけますと幸いです。
本記事で扱う内容は一部攻撃者のテクニックに触れますが、あくまでサイバーセキュリティの学習の観点から執筆するものです。検証を行う際は必ず自身のVM等のクローズドな環境で実施してください。
はじめに：Mimikatzとは？
Mimikatz はセキュリティ研究者Benjamin Delpy氏によって2011年に公開された、Windowsシステム上のメモリから認証情報（パスワード、ハッシュ、チケットなど）を抽出するためのオープンソースツールです。
本来はセキュリティ対策に役立てるはずのツールなのですが、悲しきかな、サイバー犯罪者の間では広く利用されてしまっています。
ちなみに名前の由来は、フランス語のスラングで「かわいい猫」の由来があるとか。
Mimikatzはメモリから認証情報を窃取しますが、裏を返すとWindowsはユーザーが入力した認証情報を平文やハッシュ形式でメモリに保管しているということになります。
これらの仕組みを司るのが、LSA（Local Security Authority） です。
Windowsセキュリティの中核「LSA」
LSA（Local Security Authority） はWindowsの認証・セキュリティを担う中核機能で、ログイン等に利用された認証情報をメモリ上に保持します（Windows 11では主にパスワードハッシュ）。
このLSAの実態となるのが lsass.exe と呼ばれるプロセスで、タスクマネージャーからプロセス一覧を確認すると必ず動作しているはずです。
Windowsを起動すると lsass.exe が起動し、LSAサービスが開始されます。ちなみに、lsass.exe をタスクキルするとログインしているユーザーに関するセッション情報も消去されるので、Windowsはクラッシュします。
ここで重要なのが、Windowsプロセスには必ずそのプロセスを実行しているユーザーが存在し、Windowsが動作するための中核となるプロセスは通常、SYSTEM（NT AUTHORITY\SYSTEM） という非常に高位のユーザー権限で実行されます。
lsass.exe もその一つです。そのため通常のユーザーは言うまでもなく、管理者権限でも制御することができません。
そのためMimikatzの実行時に権限昇格を行い、動作権限を SYSTEM に引き上げることでメモリの読み取りを行います。これが簡単にできてしまうことに加えて、SYSTEM 権限で動作するプロセスを保護するような仕組みもなかったため、Windows 7辺りの時代まではMimikatzが跳梁跋扈していたわけです。
「PPL」によるプロセス保護
流石に見過ごせないとMicrosoftが考えたのかは知りませんが、対策としてWindows 8.1以降には PPL（Protected Process Light） という仕組みが導入されることになります。
PPLはWindowsにおける特権プロセスを保護する仕組みで、動作権限とは別に保護レベルというものを設定します。
この保護レベルはデジタル署名により付与され、Windowsに備わる標準ソフトウェアのほか、Microsoftによる審査を受けたアンチウィルスソフト等が持っています。
この署名（Signer）、つまり保護レベルは役割ベースの階層構造になっており、例えば以下のような種類があります。
| Signer | 主な対象 |
|---|---|
| WinTcb（最高位） | OS中核プロセス |
| Lsa | lsass.exe |
| Antimalware | Defender・SentinelOne等のセキュリティ製品 |
| None（通常プロセス） | 非PPL状態 |
プロセスの動作権限に加えて、「設定されたPPLレベルが同等以上であるプロセス」以外からのアクセスが制限されます。そのため、MimikatzがSYSTEM権限を取得しても Lsa 署名を持たないためPPLレベル要求を満たさず、lsass.exe のメモリ領域へのアクセスが不可能となるわけです。
「PPLがあれば大丈夫なのね！」と思う気もしますが、PPLが成り立っているのはデジタル署名の検証が正しく行われる前提があるからで、その署名検証を行うのはカーネルです。そして起動時にPPLが確定した後、実行中の制御を維持するのもカーネルです。
何が言いたいかと言うと、カーネルそのものの信頼性が担保されていなければ、Windowsのセキュリティ基盤そのものが揺らいでしまうということです。
VBSとCredential Guard
PPLで lsass.exe プロセス自体は保護できるようになりましたが、前述の通りPPLが信頼できるのはカーネルが健全であることが前提です。「では、カーネルそのものが侵害されたらどうするの？」という疑問に答えるのが、VBS（Virtualization-Based Security） と呼ばれる仕組みです。
VBSが有効な環境では、Hyper-Vによってシステムのメモリが大きく2つの「信頼レベル」に分離されます。これを VTL（Virtual Trust Level） と呼びます。
| # | 説明 |
|---|---|
| VTL0 | 通常のWindowsカーネルやアプリケーションが動作する、いわゆる普通の領域 |
| VTL1 | 「セキュアカーネル」が動作する、VTL0から隔離された高信頼領域 |
そして、この隔離された領域全体のことを VSM（Virtual Secure Mode） と呼びます。
重要なのは、この2つの領域を制御しているのは Hyper-V（ハイパーバイザー） であるという点です。ハイパーバイザーはWindowsカーネルよりもさらに高い特権レベルで動作するため、VTL0側のカーネルが侵害されて SYSTEM 権限を奪われたとしても、VTL1へのアクセスはハイパーバイザーによりブロックされます。
そしてこのVTL1上で動作するのが、Credential Guard です。
Credential Guardが有効な環境では、VTL1上で LSAIso（Isolated LSA） と呼ばれる特殊なプロセスが動作します。通常の lsass.exe はVTL0上で動作しますが、資格情報（NTLMハッシュ等）の実体はVTL1のLSAIso内に格納され、lsass.exe とはセキュアチャネルを介してのみやり取りされます。分かりやすくいうと、lsass.exe は必要な時だけLSAIsoから資格情報を取得します。
つまり、攻撃者が SYSTEM 権限を奪って lsass.exe のメモリをすべて読み取ったとしても、本当に重要な資格情報はVTL1側に隔離されているため取得不可能、というわけです。
整理すると、Hyper-Vで隔離領域（VSM）を作り、その上でLSAIsoを動かして認証情報を守る仕組み全体がVBS、そしてその機能のひとつとして資格情報の保護を担う部分がCredential Guardと言えます。
UEFIとSecure Boot
というわけでいよいよ話が低レイヤーに近づいてきましたが、OSやカーネル自体が改ざんされていないことを検証する仕組みであるUEFI、そしてSecure Bootについて解説します。
UEFI（Unified Extensible Firmware Interface）
UEFI はBIOSの後継となるファームウェア管理インターフェース（ハードウェア制御とOS起動を担う機能）で、平たくいうとセキュリティ強化版のBIOSです。
PCを起動するとUEFIが動き出し、ブートローダが呼び出された後、そのブートローダがカーネルの実体である ntoskrnl.exe を実行することで本格的にOSが始動するのですが、ブートローダの呼び出し方がBIOSと異なってきます。
> BIOSの場合
- BIOSが起動する
- MBR（Master Boot Record） と呼ばれる、ディスクの先頭512バイトを読み込んで実行する
- MBRのコードがアクティブパーティションのブートセクターを読み込む
- ブートセクターがブートローダーを起動する
- ブートローダーがOSローダーを起動する
- OSローダーがカーネルを起動する
> UEFIの場合
- UEFIが起動する
- NVRAM と呼ばれるメモリに記述されたブートエントリを参照する
-
ESP（EFI System Partition ※ディスク上の特別なパーティション） を読み込み、ブートエントリに従って
.efiファイルを実行する - 起動したOSローダーがカーネルを起動する
ちょっと複雑なようですが、重要なのはファイルシステムを理解しているかという点です。 BIOSはNTFS等のファイルシステムを理解できないため、ディスクの先頭512バイトという予め定められた領域が起動の起点となります。また、実行といってもファイルとしてではなく、ただのバイト列として読み込むことになります。 一方、UEFIはファイルシステム（FAT32）を理解しているので、ディレクトリ構造を辿ることでブートローダー（.efi）を起動します。
Secure Boot
UEFI登場以前では、BIOS → MBR → ブートセクター → ブートローダー → OS という起動チェーンにおいて、読み込むコードに対して検証を行っていません。つまり、MBR（ディスクの先頭512バイト）を改ざんされることで、改ざんコードをそのまま読み込むような設計になっていました。
一方、UEFIでは実行される .efi ファイルに対し、デジタル署名による検証を行います。この検証により、信頼された鍵で署名されたコードのみが実行されるよう制御する仕組みが Secure Boot です。
さいごに
話が散らかってしまった気がしなくもないですが、Mimikatzが「なぜWindows 11では思うように動かないのか」という問いの答えは、ひとつの機能ではなく複数のセキュリティ機構が層を重ねて機能しているからです。
少しMimikatzからは脱線しつつ解説してきましたが、要するに、
Root of Trust（ハードウェア）
│
└─ UEFI
└─ Secure Boot
└─ Windows Boot Loader
└─ Windows Kernel（信頼状態）
├─ VBS（仮想化ベースセキュリティ）
│ ├─ VSM（隔離領域）
│ │ └─ Credential Guard
│ │ └─ 資格情報（Secrets）
│ │
│ └─ HVCI（コード整合性）
│
└─ LSA / LSASS
└─ PPL（プロセス保護）
このように、OSの起動時からユーザーモードへの移行まで、多段階で各セキュリティ機構が協調して動作しています。本記事にて最もお伝えしたかったのはまさにこの点で、上記の図とは逆の流れ（Root of Trustから順に）でセキュリティの全体像を辿ってきました。
Mimikatzの話に立ち返ると、かつては権限昇格さえできれば平文パスワードやNTLMハッシュをごっそり持ち出せた時代がありましたが、PPL・Credential Guard・Secure Boot といった機構が積み重なったことで、現在のWindows 11ではそう簡単にはいかなくなっています。
もちろん、セキュリティと攻撃のいたちごっこは今も続いており、これらの防御を迂回する手法も研究・公開されています。ただ、攻撃手法を深く理解するためにはまず「守る側の仕組み」を知ることが不可欠だと筆者は考えており、本記事がその入り口として少しでもお役に立てれば幸いです。
参考