AD FS レプリケーションの悪用: ネットワーク経由で AD FS シークレットを盗む

アプリケーションやデータをホストするために、Microsoft 365 などのクラウドベースのサービスを採用する組織が増えています。巧妙な脅威アクターが注目を集めており、Mandiant は、Microsoft 365 への長期にわたる永続的なアクセスを主な目的の 1 つとして重視する傾向が強まっていることを確認しています。この目標を達成するための斬新で検出が困難な方法の開発に重点が置かれていることは、最近のUNC2452 の検出と Microsoft 365 へのアクセスによって強調されました。このグループの主要な TTP の 1 つは、組織の AD FS サーバーからトークン署名証明書を盗み、MFA をバイパスし、任意のユーザーとしていつでもクラウド サービスにアクセスできるようにすることでした。防御側はこれまで、この証明書の防御とエコシステム全体を、AD FS サーバーとサービス アカウントに関する慎重なアクセス制御と検出の取り組みに関連付けていましたが、これでは十分ではなくなりました。このブログ投稿では、適切な権限を持つ攻撃者が、暗号化されたトークン署名証明書を内部ネットワークのどこからでも抽出できる方法を紹介します。抽出されると、攻撃者はそれを簡単に復号化し、クラウド サービスへのアクセスを開始できます。

Active Directory フェデレーション サービス

Active Directory フェデレーション サービス (AD FS) は、フェデレーション ID とアクセス管理を可能にする Windows サーバーの機能です。 Microsoft 365 などのエンタープライズ アプリケーションにアクセスするためのシングル サインオン機能を提供するために、組織によってよく使用されます。技術的には、AD FS はID プロバイダー(IdP) として機能し、Microsoft 365 はサービス プロバイダー(SP) です。今後は Microsoft 365 を例として使用しますが、この手法は AD FS を信頼するように設定されているすべてのサービスに適用できます。 AD FS は、ユーザーの ID を確認し、ユーザーを説明するアサーションを発行します。 Microsoft 365 は、AD FS を信頼してユーザー ID を確認し、アサーションを提供します。 Microsoft 365 にとって、AD FS がどのように検証を実行したかは問題ではなく、必要なのはアサーションだけです。

一般的な展開 (図 1) では、AD FS は Active Directory を使用してユーザーの ID を確認します。少なくとも、AD FS 展開は、企業のオンプレミス ネットワーク内の 2 つのサーバー (プライマリ AD FS サーバーと AD FS Web アプリケーション プロキシ (WAP)) で構成されます。プロキシは DMZ に配置され、インターネットから AD FS サーバーへのサインオン試行をプロキシする以外の機能はありません。プライマリ AD FS サーバーは、プロキシされた要求を受け取り、ユーザーの ID を確認し、ユーザーの SAML セキュリティ トークンにパッケージ化されたアサーションを発行します。

AD FS によって発行されたSAML トークンは、Microsoft 365 に対してユーザーの ID を証明し、承認の決定にも使用できます。 SAML トークンは、次の 2 つの主要コンポーネントを持つ XML ドキュメントです。

1. アサーション: アサーションは、ユーザーの ID を記述する XML 要素です。アサーションは、ユーザー SID、グループ メンバーシップ SID、またはユーザーの部署名などのその他の要素である可能性があります。 1 つの SAML トークンに複数のアサーションを関連付けることができます。
2. デジタル署名: SAML トークンのアサーションは、AD FS サーバーに存在する公開/秘密キーのペアを使用してデジタル署名されます。これはトークン署名証明書と呼ばれます。

トークン署名証明書は、AD FS のセキュリティの基盤です。 Microsoft 365 は、デジタル署名を使用して、SAML トークンが認証され、有効であり、信頼する AD FS サーバーからのものであることを検証します。 To enable this validation, an administrator share the public component of the Token Signing Certificate with Microsoft 365. 次に、これを使用して、SAML トークンのデジタル署名を暗号的に検証し、トークンの信頼性と整合性を証明します。つまり、攻撃者がトークン署名証明書を入手した場合、任意の SAML トークンを生成して、任意のユーザーとして任意のフェデレーション アプリケーションにアクセスでき、MFA をバイパスすることさえできます。

ゴールデン SAML

ゴールデン SAML は 2017 年に CyberArk によって造られ、有効なトークン署名証明書が与えられたSP にアクセスするために SAML トークンを偽造する技術を記述しています。 TROOPERS 19では、攻撃者が AD FS サーバーからトークン署名証明書を抽出する方法と、防御側のための軽減戦略について詳しく説明しました。

既定の AD FS 構成では、トークン署名証明書は、AD FS サーバーで実行されている Windows Internal Database (WID) インスタンス内に格納されます。 WID は多かれ少なかれ MS SQL Express ですが、データベースには特別な名前付きパイプ接続を介してローカルでのみアクセスできます。 AD FS では、データベースはさらに AD FS サービス アカウントのみにロックダウンされます。トークン署名証明書は、 IdentityServerPolicy.ServiceStateSummaryテーブルに暗号化された状態で格納されます。図 2 には、AD FS がサービスの開始時に XML ドキュメントとして必要とするすべての設定を格納する列を含む 1 つの行が含まれています。

図 2: AD FS データベースに格納されているトークン署名証明書の例

AD FS データベースに格納されているトークン署名証明書は、対称キー暗号化を使用して暗号化されます。 Windows は、分散キー管理 (DKM) と呼ばれるテクノロジを使用して、対称キーの派生に使用されるシークレット値を Active Directory コンテナーに格納します。 AD FS サービス アカウントは、このコンテナーの属性を読み取り、対称キーを取得して、トークン署名証明書を解読できます。

AD FS レプリケーション

AD FS は、大規模なエンタープライズ ネットワークでの高可用性と負荷分散のためのファーム構成もサポートしています。ファーム内の個々の AD FS サーバーは、一意のトークン署名証明書を使用するように構成できます。ただし、デフォルトでは、サーバーは同じトークン署名証明書を共有します。相互に同期を保つために、ファームにはプライマリ ノードとセカンダリ ノードがあります。セカンダリ ノードは、レプリケーション サービスを利用して、プライマリ AD FS サーバーから構成設定と証明書を取得します。これを容易にするために、AD FS は Windows Communication Foundation (WCF) を利用します。

WCF は、開発者がサービス指向アプリケーションを構築できるようにするフレームワークです。 WCF アプリケーションには、メッセージを受信して処理するサービスと、サービスにメッセージを送信して応答を受信するクライアントの 2 つのコンポーネントがあります。 AD FS サーバーは、ポリシー ストア転送サービスと呼ばれる WCF サービスを内部で実行します。

このサービスにメッセージを送信するために、クライアントは URL http://<adfs サーバー名>:80/adfs/services/policystoretransferに接続します。チャネルが HTTP 経由であっても、交換される実際のデータは転送中に暗号化されることに注意してください。また、プライマリ AD FS サーバーは 1 つですが、AD FS ファーム内のすべてのノードがこの WCF サービスを実行し、レプリケーションに使用できることを理解することも重要です。

メッセージを受信すると、WCF サービスは承認チェックを実行して、呼び出し元の ID が要求された情報の受信を許可されていることを確認します。アクセス許可のチェックは、AD FS データベースのIdentityServerPolicy.ServiceStateSummaryテーブルにも格納されている承認ポリシーを評価することによって行われます。ポリシーは、プライマリ SID が AD FS サービス アカウントまたはAD FS サーバーのローカル管理者グループのメンバーである任意の ID と一致する ID を許可します。クライアントの ID が承認チェックに合格すると、WCF サービスは要求された情報を含むメッセージを返します。

図 3: AD FS サーバーの既定の承認ポリシー

虐待の余地

攻撃者はポリシー ストア転送サービスを悪用して、ネットワーク経由で暗号化されたトークン署名証明書を取得できます。これは、Active Directory の DCSync 手法と同様です。データは引き続き暗号化されており、復号化するには Active Directory に保存されている DKM キーが必要であることに注意してください。ただし、この手法では、防御者が AD FS サーバーを保護し、トークン署名証明書の盗難を監視する方法を大幅に変更する必要があります。

まず、以前の手法では、AD FS サーバーでコードを実行してデータを抽出するか、少なくとも SMB 接続を使用してバッキング データベース ファイルを転送する必要がありました。セキュリティで保護された資格情報管理、EDR、ネットワーク セグメンテーションを使用した強力な多層防御プログラムにより、企業は攻撃者が AD FS サーバーとトークン署名証明書にアクセスすることを非常に困難にすることができます。ただし、AD FS レプリケーション サービスを悪用するには、標準の HTTP ポート経由で AD FS サーバーにアクセスするだけで済みます。 AD FS の既定のインストールでは、任意のシステムからの HTTP トラフィックを許可する Windows ファイアウォール規則も作成されます。さらに、攻撃者は AD FS サービス アカウントの資格情報を必要とせず、代わりに AD FS サーバーのローカル管理者である任意のアカウントを使用できます。最後に、AD FS サーバーでレプリケーション イベントが発生したときに記録されるイベント ログ メッセージはありません。全体として、これにより、この手法は実行がはるかに簡単になり、検出がはるかに難しくなります。

承認ポリシー自体も悪用の機会を提供します。承認ポリシーは構成データベースに XML テキストとして保存されるため、十分なアクセス権を持つ脅威アクターがポリシーをより寛容なものに変更する可能性があります。攻撃者は、承認ポリシーを変更して、ドメイン ユーザーS-1-5-21-X-513などのグループ SID を含めることができます。同様に、ACE を Active Directory の DKM キー コンテナーに追加することもできます。これにより、攻撃者は簡単にトークン署名証明書を取得し、任意のドメイン ユーザー資格情報を使用して復号化できます。これにより、要件としてネットワークへのアクセスのみでゴールデン SAML 攻撃を実行する永続的な機能が提供されます。

Mandiant は、この手法が実際に使用されていることをまだ確認していません。ただし、POC を作成するのは簡単であり、間もなくサポートされる公開ツールが 1 つあります。図 4 は、リモート AD FS サーバーからトークン署名証明書を抽出するために .NET で記述された POC コードの出力を示しています。

緩和策

この手法に対する最善の軽減策は、Windows ファイアウォールを使用してポート 80 TCP へのアクセスをファーム内の AD FS サーバーのみに制限することです。組織に AD FS サーバーが 1 つしかない場合は、ポート 80 TCP を完全にブロックできます。ユーザー認証のための AD FS サーバーおよびプロキシとの間のすべてのトラフィックはポート 443 TCP を介して行われるため、このブロックを配置することができます。

インバウンド通信を制限するには、AD FS がインストール時に挿入する既存のファイアウォール規則を変更します。

Set-NetFirewallRule -DisplayName “AD FS HTTP Services (TCP-In)” -RemoteAddress <ADFS1 IP アドレス>,<ADFS2 IP アドレス>

ルールが存在しない場合は、図 5 のスクリプトレットをすべての ADFS サーバーに適用して作成する必要があります。

図 5: Windows ファイアウォール – ADFS サーバーを許可 – TCP 80

内部ネットワークを監視している組織は、ポリシー ストア転送サービスをホストするアドレスへの HTTP POST 要求についてアラートを出すことができます。 AD FS ファームがある場合は、AD FS サーバーの IP アドレスをルールに対してホワイトリストに登録する必要があります。図 6 は、このアクティビティを検出する Snort ルールの例を示しています。

図 6: Snort ルールの例

謝辞

Mandiant は、Dr. Nestori Syynimaa (@DrAzureAD) の素晴らしい功績に感謝したいと思います。 Syynimaa 博士は、独自に AD FS サーバー間の構成情報のレプリケーションを調査することを考え、ブログで調査結果を公開しています。また、Mandiant は、この手法の緩和と検出に関する Microsoft の協力にも感謝します。最後に、緩和と検出に関するフィードバックを提供してくれた Mandiant Security Transformation サービス チームの Mike Burns に感謝します。