ブログ(脅威調査)

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

アプリケーションやデータをホストするために、Microsoft365などのクラウドベースのサービスが組織において採用されるようになってきています。高度な攻撃者グループもこれに追随しており、Mandiantは、Microsoft365への長期にわたる永続的なアクセスが彼らの主な目的の1つとして注目されていることを確認しています。この目標を達成するための新しい検出困難な手法の開発に焦点を当てていることは、最近のUNC2452の検知とMicrosoft365へのアクセスによって浮き彫りになりました。このグループの主なTTPの1つは、組織のAD FSサーバーからトークン署名証明書を盗んで、MFAを回避し、任意のユーザーとしてクラウド・サービスにいつでもアクセスできるようにすることでした。防御者は、以前はこの証明書の防御とエコシステム全体を関連付ける一方で、AD FSサーバーとサービス・アカウントに関する慎重なアクセス制御と検知の努力を行っていましたが、もはやそれだけでは不十分です。このブログ記事では、適切な権限を持つ攻撃者グループが、暗号化されたトークン署名証明書を内部ネットワークのどこからでも抽出できる方法を示します。それが抽出されると、簡単に復号され、クラウド・サービスへのアクセスを開始されてしまいます。

Active Directory Federation Services

Active Directory Federation Services (AD FS)は、フェデレーティッド・アイデンティティとアクセス管理を可能にするWindows Serverの機能です。Microsoft365などのエンタープライズ・アプリケーションにアクセスするためのシングル・サインオン機能を提供するためによく使用されます。技術的に言えば、AD FSはIDプロバイダー(IdP)として機能し、Microsoft365はサービス・プロバイダー(SP)として機能します。ここでは、Microsoft365を例に取り上げますが、この手法は、AD FSを信頼するように設定されたあらゆるサービスに適用できます。AD FSは、ユーザーのIDを検証し、ユーザー詳細のアサーションを発行します。Microsoft365は、AD FSを信頼してユーザーIDを検証し、アサーションを提供します。Microsoft365にとっては、AD FSがどのように検証を実行したかは重要ではなく、アサーションのみが必要となります。

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

図1:一般的なAD FS展開(ソース:Microsoft)

AD FSによって発行されるSAMLトークンは、Microsoft365に対してユーザーのIDを証明し、認証の判断にも使用することもできます。SAMLトークンは、2つの主要コンポーネントを持つXMLドキュメントです。

  1. Assertions: Assertionsは、ユーザーのIDを記述するXML要素です。アサーションには、ユーザーSID、グループ・メンバーシップSID、またはユーザーの部門名などの要素を使用できます。1つのSAMLトークンに複数のアサーションをアタッチできます。
  2. Digital Signature: SAMLトークン内のアサーションは、AD FSサーバーに存在する公開または秘密鍵ペアを使用してデジタル署名されます。これはトークン署名証明書と呼ばれます。

トークン署名証明書は、AD FSのセキュリティの基盤です。Microsoft365は、デジタル署名を使用して、SAMLトークンが本物かつ有効であり、信頼できるAD FSサーバーから取得されていることを検証します。この検証を有効にするために、管理者はトークン署名証明書のパブリック・コンポーネントをMicrosoft365と共有します。次に、これを使用して、SAMLトークンのデジタル署名を暗号で検証し、トークンの整合性だけでなく、正当性も証明します。つまり、攻撃者グループがトークン署名証明書を保持している場合、任意のユーザーとして任意のフェデレーティッド・アプリケーションにアクセスするために任意のSAMLトークンを生成し、MFAを回避することが可能になります。

Golden SAML

Golden SAMLは、有効なトークン署名証明書を与えられたSPにアクセスするためにSAMLトークンを偽造する技術であり、2017年にCyberArkによって作成された造語です。TROOPERS19では、攻撃者グループが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つの行が含まれています。

<SigningToken>
            <IsChainIncluded>false</IsChainIncluded>
            <IsChainIncludedSpecified>false</IsChainIncludedSpecified>
            <FindValue>99FABAEE46A09CD9B34B9510AB10E2B0C0ACB99B</FindValue>
            <RawCertificate></RawCertificate>
            <EncryptedPfx></EncryptedPfx>
            <StoreNameValue>My</StoreNameValue>
            <StoreLocationValue>CurrentUser</StoreLocationValue>
            <X509FindTypeValue>FindByThumbprint</X509FindTypeValue>
        </SigningToken>

図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サーバーは、Policy Store Transfer Service と呼ばれるWCFサービスを内部で実行します。

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

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

   <AuthorizationPolicy>
   @RuleName = “Permit Service Account”exists([Type ==
    “http://schemas.microsoft.com/ws/2008/06/identity/claims/
    primarysid”, Value == “S-1-5-21-3508695881-2242692613
    -376241919-1107”]) => issue(Type = “http://schemas
    .microsoft.com/authorization/claims/permit”, Value = “
    true”);
   @RuleName = “Permit Local Administrators”exists([Type ==
   “http://schemas.microsoft.com/ws/2008/06/identity/claims/group
   sid”, Value == “S-1-5-32-544”])=> issue(Type = &quot
   ;http://schemas.microsoft.com/authorization/claims/permit”, Value
    = “true”);
   </AuthorizationPolicy>

図3:AD FSサーバーのデフォルトの許可ポリシー

悪用の余地

攻撃者グループは、ポリシー・ストア転送サービス(Policy Store Transfer Service)を悪用して、Active DirectoryのDCSync技術と同様に、暗号化されたトークン署名証明書をネットワーク経由で取得できます。データはまだ暗号化されており、復号するにはActive Directoryに保存されているDKMキーが必要であることが重要です。ただし、この方法では、防御者がセキュリティで保護されたAD FSサーバーをどのように設定し、トークン署名証明書の窃取をどのように監視するかを大幅に変更する必要があります。

まず、従来の技術では、バッキング・データベース・ファイルを転送する際、データ抽出のためにAD FSサーバーでのコード実行、または少なくともSMB接続が必要でした。安全な資格情報管理、EDR、およびネットワーク・セグメンテーションを使用した強力な防御により、企業は攻撃者グループがAD FSサーバーとトークン署名証明書にアクセスすることを非常に難しくしていました。しかし、AD FS Replicationサービスを使用する場合は、標準のHTTPポート経由でAD FSサーバーにアクセスするだけで済みます。AD FSのデフォルト・インストールでは、任意のシステムからのHTTPトラフィックを許可するWindowsファイアウォール・ルールも作成されます。また、攻撃者グループはAD FSサービス・アカウントの認証情報を必要とせず、代わりにAD FSサーバーのローカル管理者である任意のアカウントを使用できます。そして、AD FSサーバーでレプリケーション・イベントが発生したときEvent Logは記述されません。これにより、実行は非常に簡単となり、検知がはるかに困難になります。

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

Mandiantはまだ、現在出回っているこの技術を観察していません。しかし、POCを書くことは簡単であり、私たちは、近い将来それを支えるであろう公開ツールのひとつを見つけました。図4は、リモートAD FSサーバーからトークン署名証明書を抽出するために.NETで記述されたPOCコードの出力を示しています。


図4:POCコード出力

緩和策

この技術に対する最善の緩和策は、Windowsファイアウォールを使用して、TCPポート80へのアクセスをファーム内のAD FSサーバーのみに制限することです。組織に単一のAD FSサーバーしかない場合は、TCPポート80へのアクセスを完全にブロックできます。これは、AD FSサーバーとユーザー認証用プロキシとの間でやり取りされるすべてのトラフィックがTCPポート443を介しているためです。

インバウンド・コミュニケーションを制限するには、AD FSがインストール時に挿入する既存のファイアウォール・ルールを変更します。

Set-NetFirewallRule -DisplayName "AD FS HTTP Services (TCP-In)" -RemoteAddress <ADFS1 IP address>,<ADFS2 IP Address>

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

New-NetFirewallRule -DisplayName "Allow ADFS Servers TCP 80" -Direction Inbound -Action Allow  -Protocol TCP -LocalPort 80 -RemoteAddress <ADFS1 IPAddress >,<ADFS2 IPAddress>

図5:Windowsファイアウォール-ADFSサーバーを許可-TCP80

内部ネットワークを監視している組織は、ポリシー・ストア転送サービス(Policy Store Transfer service)をホストするアドレスへのHTTP POST要求を警告できます。AD FSファームがある場合は、AD FSサーバーのIPアドレスをルールに対してホワイトリストに追加する必要があります。図6に、この活動を検出するためのSnortルールの例を示します。

alert tcp any any -> any 80 (msg:"AD FS Replication"; flow:established, to_server; content:"POST"; http_method; content:"adfs/services/policystoretransfer"; http_uri; threshold:type limit,track by_src,count 1,seconds 3600; priority:3; sid:7000000; rev:1;)

図6:snortルールの例

謝辞

MandiantはNestori Syynimaa博士 (@DrAzureAD)の素晴らしい研究に感謝いたします。Syynimaa博士は、AD FSサーバー間の設定情報の複製について独自に研究を行い、彼のブログでその結果を公開しています。また、Mandiantは、この技術の緩和策と検知方法に対するMicrosoftの協力にも感謝します。最後に、Mandiant Security Transformationサービス・チームのMike Burnsには、緩和策と検知方法に関するフィードバックをいただいたことを感謝します。

 

本ブログは機械翻訳(MT)を使用して翻訳しています。原文と翻訳版の意味、文言が異なる場合は原文を有効とします。

原文:April 27, 2021 「Abusing Replication: Stealing AD FS Secrets Over the Network