JPCERT/CC Eyes

ほとんどの標的型攻撃では、マルウエアに感染して侵入された端末は1台にとどまらず、横断的に他の端末そして重要なサーバーも侵入されていきます。この横断的な侵入を目的として、パスワードハッシュが窃取されることがあります。一方、このような情報窃取への防御を強化するための機能として、Windows 8.1等ではLSAの保護モードが、Windows 10 EnterpriseではCredential Guardが導入されました。今回は、これらの効果を検証するとともに、保護の効果を損なわないために注意すべき点について解説します。

LSAの保護モードの概要

LSA (Local Security Authority)は、Windowsのセキュリティに関するサブシステムです。LSAはユーザーの資格情報を管理しており、メモリ上にパスワードハッシュなどを保持しています。Windows 8.1等では、これらの情報の窃取を防ぐために、LSAの保護モードを有効化することができます。

LSAの保護モードを有効化するには、TechNetライブラリ[1]に説明されているようにレジストリを編集しOSを再起動します。有効化すると、保護モードに対応していないLSAプラグインは機能しなくなりますので、ご注意ください。保護モードに対応していないプラグインは、保護モードの変更前に監査モードを有効化することにより判別することもできます。

この保護モードはWindows 8.1とWindows Server 2012 R2で初めて導入されました。その後にリリースされたWindows 10については、ビルド 10240では保護モードにすると正常に起動できませんでしたが、ビルド 10586 (バージョン 1511、November Update、TH2)では保護モードでも正常に起動できることを確認しています。

実際の攻撃に用いられた検体によりLSAの保護モードの効果を検証

パスワードハッシュをダンプする機能を持つ、実際の攻撃に用いられた4種類の検体を用いて、ハッシュダンプを試みることによりLSAの保護モードの効果を検証しました。各検体の機能等を表 1に示します。それぞれのダンプ結果を図 1～図 6に示すとともに、LSAの保護モードでのダンプ成否を表 2にまとめます。

検証は、Windows 10 ビルド 10586とWindows 8.1で行い、同じ結果となることを確認しています。

表 1: パスワードハッシュをダンプする検体

表 2: LSAの保護モードでのパスワードハッシュダンプの成否

 

LSAの保護モードでは、mimikatzとgsecdumpの2検体は図 2や図 4のようにエラーが発生しダンプに失敗しました。一方、LSAの保護モードを有効にしていない場合、mimikatzとgsecdumpの2検体は、ログオンしているドメインユーザーの情報を図 1や図 3のようにダンプできます。ドメインユーザーの情報は、ドメイン内の他のコンピューターへ侵入する手がかりとなり得えます(Pass-the-Hash攻撃など)。LSAの保護モードでは、この情報の窃取を防ぎ、横断的侵入を困難にする効果を期待できます。

なお、PwDump7とQuarksPwDumpの2検体は、LSAのプロセスから情報を窃取するのではなく、ディスクデバイスから読み出したりレジストリAPIを用いることでダンプを実現しているため、LSAの保護モードが有効か無効かによらず常に図 5や図 6のように成功します。ただし、これら2検体がダンプしているのはドメインユーザーではなくローカルユーザーの情報です。

Credential Guardの概要

Windows 10 Enterpriseの場合は、LSAを保護するより高度な仕組み「Credential Guard」も使用することができます。Credential Guardは、ハードウェアを用いた仮想化によってOSから隔離された保護環境を基盤としています。すなわち、Credential Guardを有効にすると、LSAの機密性の高い部分のデータや処理がOSから分離され、保護されます[2][3]。LSAの保護モードとCredential Guardの比較を表 3に示します。

表 3: LSAの保護モードとCredential Guardの比較

Credential Guardは、グループポリシー管理コンソールで有効化できます。ただし、Hyper-V Hypervisorが予め有効化されていない場合には、同コンソールによる設定後に再起動した後、さらにもう一度手動で再起動するまで実際にはCredential Guardが有効にならないことがあります。また、Credential Guardのためのハードウェア要件が満たされていない場合や、Credential Guardに必要な機能がUEFI(BIOS)の設定で無効化されている場合、グループポリシー管理コンソール上でCredential Guardを有効化できたように見えても実際には機能しません。実際にCredential Guardが有効かどうかは、システム情報を表示させることにより確認できます。[2]

実際の攻撃に用いられた検体によりCredential Guardの効果を検証

表 1と同じ検体を用いてハッシュダンプを試みることにより、Credential Guardの効果を検証しました。それぞれの検体がパスワードハッシュを正しくダンプできたかどうかを表 4に示します。各々ダンプを試みた際の出力結果は図 5～図 8のとおりです。

表 4: Credential Guard有効時のパスワードハッシュダンプの成否

表 4に示したとおり、ダンプの成否はLSAの保護モードが有効な時(表 2)と同様です。mimikatzやgsecdumpでCredential Guard有効時にダンプを試みた結果の図 7や図 8では、LSAの保護モードが有効な時の図 2や図 4のようなエラーは発生していませんが、これは表 3のようにLSAの保護モードとCredential Guardとで保護の仕組みが異なっているためであり、パスワードハッシュが窃取されてしまっているわけではありません。

LSAが保護されていない環境でのmimikatzのダンプ結果の図 1とCredential Guard有効時の図 7を、また、同様にgsecdumpについても図 3と図 8を見比べてみると、パスワードを変更せずに各検体を実行した結果であるにも関わらず、パスワードハッシュの値が異なっていて、Credential Guard有効時には無意味なパスワードハッシュダンプ結果(図 7と図 8)しか得られていません。すなわち、Credential Guardが有効な時には、パスワードハッシュは窃取されていないということになります。

なお、PwDump7とQuarksPwDumpによるローカルのパスワードハッシュダンプは、LSAを情報源としていないため、LSAの保護モードと同様に、Credential Guardが有効であっても成功します。

保護の効果を損なわないための注意点1

LSAが保護されていない環境でmimikatzを使ったダンプ結果の図 1と、LSAが保護された環境でQuarksPwDumpを使ったダンプ結果の図 6を見比べてみると、図1のuser1と図6のlocaluser1のパスワードハッシュ(NTLM)が一致しています。すなわち、これらのユーザーには同じパスワードが設定されているのですが、実はuser1はドメインユーザーであり、localuser1はローカルユーザーです。mimikatzを使われても、LSAの保護モードやCredential Guardでドメインユーザーのパスワードハッシュの窃取を防ぐことができますが、QuarksPwDumpを使われると、LSAの保護モードやCredential Guardではローカルユーザーのパスワードハッシュダンプを防ぐ効果がありません。

したがって、ドメインユーザーとローカルユーザーに同じパスワードを設定している場合、LSAの保護モードまたはCredential Guardが有効化されていても、ローカルユーザーのパスワードハッシュがPwDump7やQuarksPwDump等を使って窃取され、それを用いてドメインへ侵入されてしまう可能性が高くなります。ドメイン内の端末のローカルユーザーには、ドメインユーザーと同じパスワードを設定しないようにしましょう。

保護の効果を損なわないための注意点2

LSAの保護モードやCredential GuardでもダンプできるQuarksPwDumpを使うと、ローカルのディスクにキャッシュされたドメインログオン情報を図 9のようにダンプすることができます。

このキャッシュは、ドメインから一時的にオフラインとなったノートPCで使用するためのものです。キャッシュに含まれる情報は、LSAの保護モードやCredential Guardでは窃取を防ぐことができません。常時ドメインにオンライン状態のまま利用する端末などは、キャッシュの必要が無く、キャッシュを無効化することができます。キャッシュを無効化するには、グループポリシーを編集[4]、または、レジストリを編集します。[5]

キャッシュを無効化すると、図 10のようにQuarksPwDumpでもドメインパスワードを見つけることができなくなります。

なお、端末を動作させるネットワーク環境などにより、このキャッシュを無効化できない場合は、パスワードの強度(長さ、文字の種類、辞書等からの推測の困難性)を特に高めたほうがよいでしょう。なぜなら、このキャッシュされたパスワードハッシュは、LSAから窃取するものとは異なる形式のため、そのままPass-the-Hash攻撃に用いることはできませんが、このハッシュを解読するツール等は既に存在しているため、脆弱なパスワードでは突破されてしまう可能性が高くなるからです。

おわりに

LSAの保護モードやCredential Guardが、ドメインのパスワードハッシュの窃取を防ぐことによって、標的型攻撃における横断的な侵攻を困難にする効果的な保護機能のひとつであることを検証しました。機能を有効化するにあたっては、ハードウェアとソフトウェアの要件を満たしているか、ドライバやプラグインに影響が無いかを、予めご確認ください。また、保護の効果を損なってしまう利用形態になっていないかを点検してください。LSAの保護モードやCredential Guardを利用して、よりセキュアなWindowsドメイン環境を構築するためのご参考になれば幸いです。

分析センター 今松 憲一

参考情報
[1] Microsoft - 追加のLSAの保護の構成
　　https://technet.microsoft.com/ja-jp/library/dn408187.aspx

[2] Microsoft - Credential Guard によるドメインの派生資格情報の保護
　　https://technet.microsoft.com/ja-jp/library/mt483740(v=vs.85).aspx

[3] FFRI - Windows 10 セキュリティリスク抑制効果調査報告 Phase1
　　http://www.ffri.jp/assets/files/research/research_papers/windows10_security_ja.pdf

[4] Microsoft - 対話型ログオン: キャッシュする過去のログオン数 (ドメイン コントローラーが使用できない場合)
　　https://technet.microsoft.com/ja-jp/library/mt629048(v=vs.85).aspx

[5] Microsoft - キャッシュされたログオン情報
　　https://support.microsoft.com/ja-jp/kb/172931