Written by: Shebin Mathew

Introduction

「Golden SAML」手法は、2017 年に CyberArk の研究者 によって初めて紹介され、2021 年には Mandiant の研究者 によってさらに詳しく説明されました。この手法は、Microsoft エコシステムにおいて脅威アクターがアイデンティティの表明を偽造する最も効果的な手法のひとつです。ADFS トークン署名証明書の秘密鍵を取得することで、攻撃者は任意のユーザとして任意の SAML フェデレーションアプリケーションに認証でき、多要素認証 (MFA)、条件付きアクセス、およびすべてのアイデンティティベースの制御を回避できます。

しかし、最近のレッドチーム演習において Mandiant は、ADFS 証明書を手動でローテーションする際に、設定のずれによりアクティブな署名鍵が Machine DPAPI に静かに露出したままになる可能性を発見しました。具体的には、AutoCertificateRollover が無効化され、証明書が手動でローテーションされる環境では、データベースがしばしば「ゴースト」——依然として存在し、復号にも成功するものの、ADFS サービスがトークン署名に使用していない証明書を参照するレコード——となることを発見しました。この攻撃ベクトルは、企業環境で一般的に採用されている設定であるため、注意が必要です。この手法は、LSASS やライブの ADFS サービスプロセスなどのコンポーネントとの直接的なやり取りを避けるため、企業環境で監視が強化されている場合、組織のテレメトリカバレッジによっては可視性が低下する可能性があります。本記事では、攻撃者がこの TTP を悪用して高権限 SAML トークンを偽造する方法と、その防御策の概要を解説します。

Technical Insight: Encountering the ‘Ghost Certificate’

アナリストは標準的な DKM 抽出パスに従い、WID データベースから暗号化された BLOB を取得し、Active Directory に保存されている DKM マテリアルを用いて復号しました。抽出は成功しましたが、復元された証明書はトークン署名に有効ではなく、Entra ID は無効な署名マテリアルを理由に AADSTS500172 でトークンを拒否しました。構造的には正しいものの、この成果物は認証には使用できず、アクティブな署名鍵はシステムのマシンスコープの暗号化ストアに存在し、Windows Machine DPAPI によって保護され、オペレーティングシステムの暗号化サブシステムを通じて管理されています。このアクティブな鍵を正常に取得できれば、攻撃者は任意のユーザに対して有効な SAML アサーションを偽造でき、ユーザ資格情報や多要素認証を必要とせずに、組織環境内の Microsoft 365 や Entra ID を含む任意の SAML フェデレーションアプリケーションへの不正アクセスが可能になります。

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

https://storage.googleapis.com/gweb-cloudblog-publish/images/ghost-database-fig1.max-700x700.png

Figure 1: ADFS certificate enumeration output showing configuration drift between the WID database and the active host certificate

ADFS は秘密鍵を 2 つの保護コンテキストで保持します。Location 1 (User DPAPI) では、暗号化された鍵 BLOB がディスク上に存在する可能性がありますが、DPAPI 保護はサービスアカウントの SID と関連する DPAPI マスターキー マテリアルに紐付けられています。評価対象の環境では、ドメイン DPAPI バックアップ鍵アプローチにより対話型ユーザープロファイル用のマスターキーマテリアルの復号に成功しましたが、ADFS サービスアカウントプロファイルに関連する復号可能マテリアルは返されませんでした。以降のオフライン復号試行もすべて失敗し、評価対象のオンディスク復旧アプローチではマスターキーが復旧できないという観測結果と一致しました。ただし、この観測は評価対象の環境に限定されており、すべての ADFS デプロイメントにおける普遍的なアーキテクチャ特性を表すものではありません。

Location 2 (Machine RSA) は、ユーザ固有のログオンセッションに依存しません。代わりに、Machine DPAPI を使用して鍵マテリアルを保護しており、 DPAPI_SYSTEM LSA シークレットと、十分な権限を持つ SYSTEM レベルのコンテキストで利用可能なマシンマスターキーを活用します。

Why the WID Path Misses This Key

AutoCertificateRollover が無効化されている手動証明書ローテーションで生じやすい設定のずれが発生している ADFS 環境では、ADFS サービスホストは新しくプロビジョニングされた署名証明書をオペレーティングシステムレベルで正常にバインドでき、サービスの継続運用を確保できます。しかし、WID 設定データベースは現在の署名証明書を反映していないため、古い証明書のメタデータが残る可能性があります。

この設定とランタイム状態の乖離が、ADFS イベント ID 385 が検知対象とする状態です。その結果、WID データベースと DKM マテリアルにのみ依存する抽出手法は、アクティブな署名に使用されていない証明書を返す可能性があり、下流のフェデレーションシナリオでアサーションが拒否される原因となります。

Understanding How the Machine DPAPI Store Becomes Populated

Machine DPAPI ストアに鍵が格納される仕組みを理解するには、ADFS がトークン署名鍵マテリアルをどのように永続化するかを調べる必要があります。初回デプロイ、自動証明書ロールオーバー、または手動証明書ローテーションのいずれにおいても、ADFS は RSA 秘密鍵マテリアルを C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys\ にあるマシンスコープの CAPI キー ストアに、ユーザーバインドされた DPAPI コンテキストではなくマシン DPAPI コンテキストを使用して永続化します。評価対象の環境で /machine オプションを指定した SharpDPAPI 列挙により、アクティブなマシン鍵マテリアルがこのパスに存在することが確認され、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 コンテキストではなく Machine DPAPI を使用して保護されているため、マシンキー ストアと関連する DPAPI アーティファクトにアクセスできる十分な権限を持つローカルプロセスは、元のサービスログオンセッションとは独立して鍵マテリアルを復元できる可能性があります。その結果、特定の条件下では、LSASS メモリやライブの ADFS サービスプロセス自体との直接的なやり取りなしに、アクティブな ADFS トークン署名秘密鍵の復元が達成可能であり、資格情報ダンプやプロセスメモリアクセス動作に主眼を置いた防御策の可視性を低下させる可能性があります。

KEY DESIGN IMPLICATION

ADFS はトークン署名秘密鍵マテリアルをマシンスコープのキー ストアに永続化し、Machine DPAPI セマンティクスを使用して保護します。これは、サービスアカウントの変更、資格情報のローテーション、サービスの再起動をまたいでマシンスコープの鍵永続化を可能にする、ドキュメント化された動作です。

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

その結果、LSASS メモリやライブの ADFS サービスプロセス自体との直接的なやり取りなしに、アクティブな ADFS トークン署名秘密鍵の復元が達成可能であり、資格情報ダンプやプロセスメモリアクセス動作に主眼を置いたセキュリティ制御の可視性を低下させる可能性があります。

Attack Flow: Machine DPAPI Key Recovery to SAML Forgery

https://storage.googleapis.com/gweb-cloudblog-publish/images/ghost-database-fig2.max-1300x1300.png

Figure 2: Machine DPAPI extraction flow—five-step process from SYSTEM execution to SAML assertion

https://storage.googleapis.com/gweb-cloudblog-publish/images/ghost-database-fig3.max-500x500.png

Figure 3: ‘SharpDPAPI /machine’ output confirming successful recovery of the active ADFS token-signing private key from the machine DPAPI store

復元された鍵を使用して Global Administrator アイデンティティを偽装した SAML アサーションが作成され、Entra ID はこれを有効な認証アサーションとして受け入れ、フェデレーションされた Microsoft 365 テナント内で Global Administrator 権限レベルでの認証アクセスが実現しました。

Detection and Hunting

防御者は、アプリケーション層の設定ストアに依存するのではなく、オペレーティングシステムレベルの暗号化操作とアイデンティティ発行動作に対する可視性を優先すべきです。

  • SACL-Based Object Access Monitoring: C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys\ および C:\Windows\System32\Microsoft\Protect\S-1-5-18\ に対して SACL を介したオブジェクトアクセス監査を設定します。正しく設定された場合、ファイルアクセス試行に対して Security Event ID 4663 が生成されます。カバレッジは SACL の設定とアクセスパスに依存するため、単独のシグナルではなく相関ベースの検知における裏付け証拠として扱う必要があります。

  • ADFS Token Issuance Consistency: ADFS 監査ログの一次認証イベントとトークン発行イベントの不整合を監視します。関連するイベントには、トークン発行およびクレーム処理レコード（ADFS のバージョンおよび監査設定に応じてイベント ID 299、1200 番台など）が含まれます。目的は、先行する認証コンテキストと明確に相関付けられないトークン発行を特定することです。これは、各リライイングパーティトラストごとの通常の認証パターンをベースライン化している場合に最も効果的です。

  • Federated Identity Monitoring in Entra ID: Entra ID のサインインログは、受け入れられた偽造アサーションを標準的なフェデレーションサインインイベントとして記録します。検知には、Entra ID のサインインレコードを ADFS 側の発行ログと相互相関させる必要があります。いずれのソースも単独では十分ではありません。特権アカウントについては、予期しない IP アドレス範囲、クレームセットの逸脱、ユーザーエージェントの不整合に注目します。

Mitigation and Remediation

ADFS インフラストラクチャは Tier 0 のアイデンティティインフラストラクチャとして扱う必要があり、ドメインコントローラーと同等の重要度 を持ちます。ADFS ホストで SYSTEM アクセスが達成された場合、署名鍵は侵害されたと見なす必要があります。

  • Hardware-Backed Key Protection: トークン署名証明書をハードウェアセキュリティモジュール (HSM) に移行します。HSM バックドの鍵は、秘密鍵マテリアルがホスト上のソフトウェアからアクセス可能なストレージに存在しないことを保証し、Machine DPAPI 抽出パスを完全に排除します。

  • gMSA Service Identity: ADFS サービスをグループマネージドサービスアカウント (gMSA) で実行し、資格情報のローテーションを自動化してサービスアイデンティティ管理における運用ドリフトを低減します。これはマシンスコープの鍵保護に直接対処するものではありませんが、手動の資格情報管理を手動ローテーションにおける設定ドリフトの要因として排除します。

  • Tier 0 Administrative Controls: ADFS サーバーを厳格な Tier 0 制御で管理します。制限された管理アクセス経路、専用特権アクセスワークステーション (PAW)、一般サーバー管理ドメインからの分離、および強化された特権アクセス監視を含みます。

  • Certificate Rotation and Configuration Validation: 侵害が疑われる場合、トークン署名証明書をローテーションし、ADFS 設定、 LocalMachine\My ストア、およびフェデレーションメタデータ間で整合性を検証します。単一の信頼できる情報源に依存しないでください。AutoCertificateRollover が無効化されている環境では、手動ローテーションに Set-AdfsCertificate による ADFS の更新を含める必要があります。証明書のインストールだけでは不十分です。ローテーション後に Get-AdfsCertificate を使用して検証してください。イベント ID 385 がその後に表示された場合は、設定の不整合を調査してください。

  • Multicloud Scope Awareness: 侵害された ADFS トークン署名鍵は、Microsoft サービスだけでなく、すべての SAML リライイングパーティトラストに影響します。ADFS を使用して他の SaaS プラットフォームへアイデンティティフェデレーションを行っている組織は、ADFS を Tier 0 インフラストラクチャとして扱い、すべてのリライイングパーティトラストを監査する必要があります。ADFS ベースのフェデレーションから移行する（例: ネイティブ OIDC フェデレーションへ）ことで、この特定の攻撃経路を排除できます。

Posted in