マシンDPAPI経由でアクティブなADFS署名鍵を復元する手法

執筆者: Shebin Mathew

はじめに 

2017年にCyberArkの研究者が初めて報告し、2021年にはMandiantの研究者がさらに詳細を明らかにした「Golden SAML」という手法は、Microsoftエコシステムにおいて脅威アクターがID主張を偽造する最も効果的な手段の一つであり続けています。ADFSトークン署名証明書の秘密鍵を取得できれば、攻撃者は多要素認証(MFA)や条件付きアクセス、その他あらゆるID関連の制御を回避し、任意のSAMLフェデレーションアプリケーションに対して任意のユーザーとして認証できてしまいます。

しかし、Mandiantは最近のレッドチーム演習において、ADFS証明書を手動でローテーションした場合、構成のズレ(コンフィグレーションドリフト)によってアクティブな署名鍵がマシンDPAPI上に密かに露出したままになるケースがあることを発見しました。具体的には、AutoCertificateRolloverが無効化されており証明書が手動でローテーションされている環境では、データベースがしばしば「ゴースト」化することが判明しています。つまり、レコード自体は存在し復号にも成功するものの、そこで参照されている証明書はすでにADFSサービスによるトークン署名には使われていない、という状態です。この攻撃経路が注目に値するのは、その根本原因となる構成がエンタープライズ環境で広く採用されているためです。この手法はLSASSや稼働中のADFSサービスプロセスといった、エンタープライズ環境で強化された監視対象となりがちなコンポーネントへの直接的な干渉を避けるため、組織のテレメトリカバレッジによっては検知されにくくなる可能性があります。本稿では、攻撃者がこのTTPを悪用して高権限のSAMLトークンを偽造する手口を詳細に解説し、これを防御するための指針を示します。

技術的知見: 「ゴースト証明書」との遭遇

アナリストは標準的なDKM抽出手順に従い、WIDデータベースから暗号化されたブロブを取得し、Active Directoryに保存されているDKM素材を使って復号を試みました。抽出自体は成功しましたが、復元された証明書はすでにトークン署名には有効ではなく、Entra IDは署名素材が無効であるとして、生成されたトークンを AADSTS500172エラーで拒否しました。この成果物は構造的には正しいものの認証には使用できません。なぜなら、実際に使われているアクティブな署名鍵は、Windowsマシン DPAPIによって保護され、OSの暗号サブシステムによって管理される、システムのマシンスコープの暗号ストアに存在しているからです。この稼働中の鍵の取得に成功すれば、攻撃者は任意のユーザーになりすまして有効なSAMLアサーションを偽造できるようになり、ユーザーの認証情報や多要素認証を回避したうえで、組織環境内のMicrosoft 365やEntra IDを含むあらゆるSAMLフェデレーションアプリケーションへの不正アクセスが可能になります。

分析の結果、AutoCertificateRolloverが無効化されており、手動でのローテーションが実施されていたことが判明しました。この点はGet-AdfsPropertiesコマンドで直接確認され、AutoCertificateRollover: Falseという結果が返されました。これは、証明書のライフサイクル管理が手動の管理プロセスに委ねられていたことを示しています。ADFSサービス自体は署名に新しい有効な鍵を使用していたにもかかわらず、WID設定データベースは新しい証明書を反映するように更新されておらず、期限切れの「ゴースト」エントリだけが記録として残っていました。このズレは、ADFSサービスにおける証明書の有効性に関する警告を示すMicrosoftイベントID 385として表面化します。なお、このイベントはAutoCertificateRolloverを再度有効化し、その後証明書のロールオーバーが実施されれば自動的に解消します。逆に言えば、無効化されたまま対応するデータベース更新を伴わずに手動ローテーションが行われている環境では、このイベントこそが今回のようなズレの発生を示す観測可能な兆候となります。

ADFSは秘密鍵を2つの保護コンテキストで保持しています。ロケーション1(ユーザーDPAPI)では、暗号化された鍵のブロブがディスク上に存在することがありますが、そのDPAPI保護はサービスアカウントのSIDおよびそれに関連付けられたDPAPIマスターキー素材に紐付けられています。今回評価した環境では、ドメインDPAPIバックアップキーを用いた手法によって対話型ユーザープロファイルのマスターキー素材は正常に復号できたものの、ADFSサービスアカウントのプロファイルに関連付けられた復号可能な素材は得られませんでした。その後のオフライン復号の試みもすべて同様に失敗しており、この環境で評価したオンディスク復元手法ではマスターキーが回復不能であったことと整合しています。ただしこの観察結果は評価対象の環境に限定されるものであり、すべてのADFS展開に共通する構造的な特性であるとは限りません。

ロケーション2(マシンRSA)は、ユーザー固有のログオンセッションに依存しません。代わりに、鍵素材はDPAPI_SYSTEMのLSAシークレットと、十分な権限を持つSYSTEMレベルのコンテキストで利用可能なマシンマスターキーを組み合わせたマシンDPAPIによって保護されています。

WID経路がこの鍵を検出できない理由

構成ドリフトが発生しているADFS環境、すなわちAutoCertificateRolloverが無効化された状態で手動証明書ローテーションが行われることの多いケースでは、ADFSサービスホストはOSレベルでは新しく発行された署名証明書に正常にバインドでき、サービスの継続稼働自体は保たれます。しかしWID設定データベースは現在の署名証明書を反映しておらず、古い証明書メタデータが残ったままになる場合があります。

この構成と実行時状態との乖離こそが、ADFSイベントID 385が検出しようとしている状態です。その結果として、WIDデータベースとDKM素材のみに依存する抽出手法では、すでにアクティブな署名には使われていない証明書が返されてしまい、後続のフェデレーションシナリオでアサーションが拒否される事態につながります。

マシンDPAPIストアがどのように生成されるか

マシンDPAPIストアがどのように生成されるかを理解するには、ADFSがトークン署名鍵素材をどのように永続化しているかを確認する必要があります。初回デプロイ時、自動証明書ロールオーバー時、あるいは手動証明書ローテーション時のいずれにおいても、ADFSはRSA秘密鍵素材をC:\ProgramData\Microsoft\Crypto\RSA\MachineKeys\にあるマシンスコープのCAPIキーストアに永続化し、ユーザーに紐付いたDPAPIコンテキストではなくマシンDPAPIコンテキストで保護します。評価環境でのSharpDPAPI/machineによる列挙の結果、アクティブなマシン鍵素材はこのパス配下に存在していることが確認された一方、CNGのCrypto\Keysストアは評価環境では使用が確認されませんでした。

この保護チェーンは、DPAPI_SYSTEMのLSAシークレットと、S-1-5-18セキュリティコンテキストに関連付けられC:\Windows\System32\Microsoft\Protect\S-1-5-18\にDPAPI保護された鍵素材として保存されているマシンマスターキーの両方に依存しています。両者はいずれも、最終的にはホスト上の高権限なSYSTEMレベルのコンテキストでしか解決できません。対応する証明書はLocalMachine\My証明書ストアに登録されており、ADFSはトークン署名操作の際にここから関連する秘密鍵を取得します。

マシンスコープでの鍵保存という設計上の理由は、運用上の堅牢性にあります。マシンスコープの鍵であれば、サービスアカウントのパスワード変更、gMSAのローテーション、システムの再起動、サービスの再起動が発生しても、鍵の再発行や特定の対話型ログオンセッションへの依存なしに使い続けられます。この設計により、基盤となるサービスアカウントの認証情報がどのように変更されても、ADFSサービスは一貫して署名鍵にアクセスできるようになっています。

しかし、この同じ設計上の選択には重要なセキュリティ上の含意もあります。秘密鍵がユーザーに紐付いたDPAPIコンテキストではなくマシンDPAPIによって保護されているため、マシンキーストアおよび関連するDPAPIアーティファクトにアクセスできる十分な権限を持つローカルプロセスであれば、元のサービスログオンセッションとは独立に鍵素材を復元できる可能性があります。その結果、条件がそろえば、アクティブなADFSトークン署名秘密鍵の復元は、LSASSメモリや稼働中のADFSサービスプロセス自体に直接干渉することなく達成できてしまう場合があり、資格情報のダンプやプロセスメモリへのアクセス挙動を主眼とする防御策からは見えにくくなる可能性があります。

設計上の重要な含意

ADFSはトークン署名用の秘密鍵素材をマシンスコープの鍵ストアに永続化し、マシンDPAPIのセマンティクスで保護しています。これは、サービスアカウントの変更、認証情報のローテーション、サービスの再起動を経てもマシンスコープの鍵を維持できるようにするための、公式に文書化された仕様上の挙動です。

しかしこの設計は、標準的なADFSハードニングガイダンスではあまり強調されていない運用上のセキュリティ上の含意をもたらします。マシンキーストア内に保存された秘密鍵はこの保護モデルによって守られていますが、DPAPI_SYSTEM LSAシークレットとホスト上でローカルに利用可能なマシンマスターキーへのアクセス権を持つ、十分な権限を持つSYSTEMレベルのコンテキストであれば復元できてしまう可能性があります。

その結果として、アクティブなADFSトークン署名秘密鍵の復元は、LSASSメモリや稼働中のADFSサービスプロセス自体に直接干渉することなく達成できてしまう場合があり、資格情報のダンプやプロセスメモリへのアクセス挙動を主眼とするセキュリティ対策からは見えにくくなる可能性があります。

復元された鍵を用いて、グローバル管理者のIDになりすましたSAMLアサーションを偽造したところ、Entra IDはこれを有効な認証アサーションとして受け入れ、フェデレーションされたMicrosoft 365テナント内でグローバル管理者権限レベルでの認証済みアクセスが成立してしまいました。

検知とハンティング

防御側は、アプリケーション層の設定ストアのみに頼るのではなく、OSレベルの暗号操作やID発行の挙動に対する可視性を優先的に確保すべきです。

• SACLベースのオブジェクトアクセス監視: C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys\およびC:\Windows\System32\Microsoft\Protect\S-1-5-18\に対してSACL経由のオブジェクトアクセス監査を設定します。正しく設定されていれば、ファイルへのアクセス試行に対してセキュリティイベントID 4663が生成されます。ただしそのカバレッジはSACLの設定内容やアクセス経路に依存するため、これを単独のシグナルとしてではなく、相関分析における補完的な証拠として扱うべきです。

• ADFSトークン発行の整合性: ADFSの監査ログにおいて、一次認証イベントとトークン発行イベントとの間に矛盾がないか監視します。関連するイベントには、ADFSのバージョンや監査設定に応じたトークン発行およびクレーム処理のレコード(イベントID 299、1200番台)が含まれます。目的は、先行する認証コンテキストと明確に紐付けられないトークン発行を特定することです。この検知はリライングパーティトラストごとの通常の認証パターンをベースライン化しておくことで、最も効果を発揮します。

• Entra IDにおけるフェデレーションID監視: Entra IDのサインインログには、受理された偽造アサーションが通常のフェデレーションサインインイベントとして記録されます。この検知にはEntra IDのサインインレコードとADFS側の発行ログとの相関分析が必要であり、どちらか一方のソースだけでは不十分です。特権アカウントについては、想定外のIP(インターネットプロトコル)アドレス範囲、クレームセットの逸脱、ユーザーエージェントの不整合に注目してください。

低減策と修復

ADFSインフラはドメインコントローラーと同等の重要度を持つTier 0のID基盤として扱うべきです。ADFSホスト上でSYSTEم権限へのアクセスが成立した場合、署名鍵は侵害されたものとみなす必要があります。

• ハードウェアによる鍵保護: トークン署名証明書をハードウェアセキュリティモジュール(HSM)へ移行します。HSMで保護された鍵であれば、秘密鍵素材がホスト上のソフトウェアからアクセス可能なストレージに存在すること自体がなくなり、マシンDPAPI経由の抽出経路を完全に排除できます。

• gMSAによるサービスID:ADFSサービスをグループ管理サービスアカウント(gMSA)で実行することで、認証情報のローテーションを自動化し、サービスID管理における運用上のドリフトを低減します。これはマシンスコープの鍵保護そのものには直接対処しませんが、構成ドリフトの一因となる手動での認証情報管理を排除できます。

• Tier 0の管理統制: ADFSサーバーを厳格なTier 0統制のもとで管理します。具体的には、管理アクセス経路の制限、専用の特権アクセスワークステーション(PAW)の使用、一般的なサーバー管理ドメインからの分離、特権アクセス監視の強化などが挙げられます。

• 証明書ローテーションと構成の検証: 侵害が疑われる場合は、トークン署名証明書をローテーションし、ADFSの構成、 LocalMachine\Myストア、フェデレーションメタデータの間で整合性を検証してください。単一の情報源のみを信頼してはいけません。AutoCertificateRolloverが無効化された環境では、手動ローテーションの際にSet-AdfsCertificateを用いてADFSの構成を必ず更新する必要があり、証明書をインストールするだけでは不十分です。ローテーション後は Get-AdfsCertificateを用いて検証してください。その後もイベントID 385が発生する場合は、構成の不整合がないか調査してください。 

• マルチクラウドにおける影響範囲の把握: ADFSトークン署名鍵が侵害された場合、Microsoftのサービスだけでなく、すべてのSAMLリライングパーティトラストに影響が及びます。他のSaaS(Software as a Service)プラットフォームとのID連携にADFSを利用している組織は、ADFSをTier 0インフラとして扱い、すべてのリライングパーティトラストを監査すべきです。ADFSベースのフェデレーションから(例えばネイティブのOIDCフェデレーションへ)移行することで、この特定の攻撃経路自体を排除できます。