2022年9月13日（火）
著者：カウンター・スレット・ユニット（CTU™）リサーチチーム
最終更新日：2022年9月20日
※本記事は、https://www.secureworks.com/ で公開されている Azure Active Directory Pass-Through Authentication Flaws を翻訳したもので、 2022年9月13日執筆時点の見解となります。
パススルー認証（PTA: Pass-through authentication）とは、Azure Active Directory（Azure AD）のハイブリッドIDにおける認証方法のひとつであり、ひとつまたは複数のオンプレミスサーバーにインストールされたPTAエージェントに依存します。Azure ADは証明書ベースの認証（CBA）を用いて各エージェントを識別します。2022年5月、Secureworks®カウンター・スレット・ユニット™（CTU）のリサーチャーはPTAで使用されているプロトコルがどう悪用可能かを分析しました。その結果、CBAの証明書が攻撃者の手でエクスポートされるとPTAエージェントのID情報が窃取される恐れがあることがわかりました。侵害された証明書および攻撃者に乗っ取られたPTAエージェントが併用されると、検知不可能なバックドアが作成され、無効なパスワードによるログイン、資格情報の収集、およびリモート型サービス妨害（DoS）攻撃の実施につながる恐れがあります。攻撃者は証明書が失効するたびに更新し、ネットワーク内での永続性を何年にもわたって維持できます。証明書が侵害されると、対象組織の管理者側で無効化することはできません。
当社は2022年5月10日、上記の分析結果をMicrosoft社に報告しました。7月2日にMicrosoft社より、「PTAは想定通りに動作している」との回答がありましたが、当社が報告した欠陥への対処予定については何ら言及されていませんでした。
更新情報：9月20日、Microsoft社より、これらの問題への対応計画についてのアップデートがありました。
Azure ADハイブリッドIDにおける認証オプション
Azure ADのハイブリッドIDには3つの認証オプションがあります（図1）。Microsoft社は、パスワードハッシュ同期（PHS）による認証を推奨しています。フェデレーション認証およびPTAは、パスワードハッシュをクラウドと同期できない/あえて同期しない組織もしくは、認証コントロールを強化したい組織向けのオプションです。フェデレーション認証は通常、Windows Server OSの一部であるMicrosoft Active Directoryフェデレーションサービス（AD FS）と一緒に実装されます。ただしAD FSは（Golden SAMLを使った）Solorigate攻撃などの標的になったこともあり、通常はフェデレーション認証よりもPTAのほうが望ましいとされています。これらの攻撃では、侵害されたAD FSサーバーから攻撃グループがトークン署名証明書をエクスポートし、SAMLトークンを偽造してユーザーに成りすましていました。
図1：Azure ADハイブリッドIDの認証オプション（出典：Secureworks）
PTAは、ひとつまたは複数のオンプレミスサーバーにインストールされたPTAエージェントに依存します。Microsoft社は、高可用性を維持できるよう少なくとも3つのエージェントをインストールすることを推奨しています。各テナントは、最大40のエージェントを保有できます。図2は、PTAのアーキテクチャ概要です。
図2：PTAのアーキテクチャ概要（出典：Secureworks）
- ユーザーがAzure ADのIDプラットフォームを利用するサービス（Microsoft 365など）にアクセスし、自身のユーザー名とパスワードを入力します。
- Azure ADが資格情報を暗号化し、ひとつまたは複数のPTAエージェント宛に認証要求を送信します。
- PTAエージェントがユーザーの資格情報を復号し、当該資格情報を使ってActive Directoryへのログインを試みた後、実行結果をAzure ADに返します。
インストール
PTAエージェントのインストール中に、証明書署名要求（CSR）がAzure ADのエンドポイント（https: //<テナントID> . registration . msappproxy . net/register/RegisterConnector）宛に送信されます（図3）。その後、Azure ADが署名した証明書を含むレスポンスが返されます。
図3：PTAエージェントの登録要求（出典：Secureworks）
証明書はHISconnectorRegistrationCA . his . msappproxy . netから発行されます。証明書のサブジェクト名はAzure ADのテナントIDです（図4）。エージェントIDはグローバル一意識別子（GUID）となります。GUIDは、オブジェクト識別子（OID）の値1.3.6.1.4.1.311.82.1にバイト配列としてエンコードされます。証明書の有効期間は6ヵ月です。
図4：PTAエージェントの証明書情報およびその詳細（出典：Secureworks）
PTAエージェントおよび関連するIPアドレス/ステータスの一覧はAzure SQL Databaseに格納されており、Azure ADポータルで閲覧できます（図5）。なお、エージェントIDはこの一覧に掲載されません。
図5：Azure ADポータルに表示されたPTAエージェントの一覧（出典：Secureworks）
管理者権限をもつユーザーは、MS Graph APIまたはAADInternalsなどのツールを使ってエージェントIDを閲覧できます。図6には、2つのエージェントおよびそれぞれのIDが例示されています。最初のIDは図4の証明書と一致しますが、IDの各セグメントにはRFC4122規格に従って証明書の値が逆順で列挙されています。
図6：AADInternalsを使って列挙したPTAエージェントの一覧（出典：Secureworks）
PTAエージェントのIDは、Azure ADサインインログ詳細画面のAuthentication Details（認証の詳細）タブに格納されています。エージェントIDは、ユーザー認証に使用されたエージェントを識別するためのIDです。たとえば図7を見ると、図6で2番目に表示されたエージェントが認証を実行したことがわかります。
図7：Azure ADサインインログに表示される認証の詳細（出典：Secureworks）
PTAエージェントが使う証明書の拇印（Thumbprint）は、ディスク上の設定ファイル（ファイル名：C:\ProgramData\Microsoft\Azure AD Connect Authentication Agent\Config\TrustSettings.xml）に格納されています（図8）。
図8：PTAエージェントの設定ファイル（出典：Secureworks）
データ保護API（DPAPI）によって保護される秘密鍵を含む証明書は、AADInternalsやMimikatzなどのツールを介してエクスポートすることができます。AADInternalsを使うと、<コンピューターの正式名称>_<テナントID>_<エージェントID>.pfxという命名形式のPFXファイルで証明書がエクスポートされます（図9）。
図9：AADInternals によるPTAエージェント証明書のエクスポート（出典：Secureworks）
PTAエージェントの起動プロセス
PTAに関する主な技術的コンポーネントはAzure AD、Azure Service BusおよびAzure AD Connectの認証エージェント（PTA）です。このエージェントが、設定の詳細を定めるブートストラップ（Bootstrap）ドキュメントを検索します。さらに、識別されたエンドポイントにWebSocket接続を確立するためのコマンド＆コントロール（C2）チャネルの一覧も検索します（図10）。
図10：PTAエージェントの起動手順（出典：Secureworks）
- PTAエージェントがhttps: //<tenant ID> . pta . bootstrap . his . msappproxy . net/ConnectorBootstrapに接続し、CBAを用いて自らを識別します。
- Azure ADが該当リージョンのエンドポイントへのHTTPリダイレクト要求をPTAエージェントに送信します。
- PTAエージェントがリージョン内のエンドポイント（https: //bootstrap-<xxxn> . his . msappproxy . net/ConnectorBootstrap）に接続します。変数<xxxn>にはアルファベット3文字と数字1字が含まれます。
- Azure ADが、複数の設定情報およびPTAエージェントに近接するシグナルリスナーエンドポイント一覧を含むXML形式のブートストラップドキュメントを返します（図11）。
PTAエージェントは、ドキュメントの指示に従って特定のコマンド＆コントロール（C2）チャネルにAzure Service Bus経由で接続し、命令を待ち受けます。
図11：ブートストラップファイルの抜粋（出典：Secureworks）
- PTAエージェントが各シグナルリスナーエンドポイントにWebSocket接続を確立し、認証要求の受信準備を整えます。エンドポイントはAzure Service Busで実装されています。
PTAエージェントは10分おきに上記手順の1～4を繰り返し、ブートストラップドキュメントを更新します。エージェントは必要に応じ、当該ドキュメントのXMLデータ（手順5）で定義されたシグナルリスナーエンドポイントに再接続します。
PTAによる認証プロセス
PTAでは、Azure Service Bus、Azure Relay、Azure AD Application Proxyサービスを使用します（図12）。これらの要素が、Azure ADからPTAエージェントへの認証要求や、PTAエージェントからAzure ADへの認証レスポンスを配信します。
図12：PTAによる認証プロセス（出典：Secureworks）
- Azure ADが接続先エージェントすべてにAzure Service Busを介して通知を送信します。通知内容にはAzure Relayのアドレスが含まれます。
- PTAエージェントがAzure RelayへのWebSocket接続を確立します。
- Azure ADがAzure Relayを介してPTAエージェントに認証要求を送信します。
- PTAエージェントがオンプレミスのActive Directoryドメインへのログインを試みます。その後、HTTP POSTリクエストで認証結果をAzure Web Application Proxyに送信します。
手順3で送信された認証要求はXMLファイル形式です（図13）。EncryptedData要素には、別々の証明書を用いて暗号化された資格情報の配列が含まれています。キー識別子は<エージェントID>_<証明書の拇印>の形式になっています。個々のPTAエージェントはこの形式をもとに、投入された資格情報の中から自らに該当する情報を復号できます。
図13：認証要求（出典：Secureworks）
与えられた資格情報を用いて署名を完了したPTAエージェントは、Proxy経由でAzure ADにレスポンスメッセージを送信します。このメッセージは2つのクレームを含むJSONファイルです。認証成功のレスポンス（図14）では
「http: //schemas . xmlsoap . org/ws/2005/05/identity/claims/authentication」のクレームがTrueに設定され、
「http:// schemas . xmlsoap . org/ws/2002/05/identity/claims/name」のクレームがユーザー本人のユーザー名に設定されます。Azure ADではユーザー名の有効性をチェックしません。
図14：認証が成功した際のレスポンス（出典：Secureworks）
認証失敗のレスポンス（図15）では、
「http: //schemas . xmlsoap . org/ws/2005/05/identity/claims/authentication」のクレームがFalseに設定され、
「http: //schemas . xmlsoap . org/ws/2002/05/identity/claims/validationfailurereasoning」のクレームにエラーコードが表示されます。たとえばエラー1327は「アカウント制限により、このユーザーはサインインできません」という内容です。
図15：認証が失敗した際のレスポンス（出典：Secureworks）
カスタムPTAエージェント
CTUリサーチャーは、PTAエージェントが使用するプロトコルを調査した後、既存エージェントの証明書を用いて概念実証用のカスタムエージェントを作成しました。このエージェントを起動するとAzure ADに接続し、認証要求を待ちます。図16には、与えられた証明書を用いてAzure ADに接続し、資格情報を復号し、ユーザーパスワードを平文表示するカスタムエージェントの動きが示されています。このカスタムエージェントは、パスワードが有効か否かを問わず、すべての要求を承認または拒否することができます。攻撃者が同様のカスタムエージェントを作成すれば、資格情報を窃取したりバックドアを設置したりできるほか、有効な資格情報が入った認証要求を拒否してDoS攻撃を実施することもできます。
図16：カスタムPTAエージェント（出典：Secureworks）
CTUリサーチャーは、カスタムPTAエージェントが起動するとAzure ADポータルで当該エージェントのIPアドレスが変更されることを確認しました（図17）。しかし、10分後の次回実行サイクルで最初のPTAエージェントがブートストラップを取得すると、IPアドレスは元に戻りました。この振る舞いから、PTAエージェントがブートストラップを取得するたびにIPアドレスの値が更新されると考えられます。カスタムエージェントの参照先をシステム上に存在するブートストラップファイルに指定したところ、Azure ADポータル上のIPアドレスは書き換えられませんでした。この結果を見ると、シグナルリスナーエンドポイントに直接接続してもIPアドレスの値には影響がないと考えられます。したがって、攻撃者が既存のブートストラップを使ってAzure ADに接続すれば、検知の目を逃れることができます。
図17：PTAエージェントのIPアドレス変更（出典：Secureworks）
PTAエージェントの認証に用いる証明書は6ヵ月間有効です。証明書が失効した場合、またはPTAエージェントが10日間非アクティブ状態だった場合は、エージェント側でパスワードを復号できません。その場合、PTAエージェントから、ブートストラップファイルに定義されているTrustRenewEndpointにHTTP POSTリクエストを送信することで、Azure ADとの信頼関係を「更新」できます。失効した証明書は、このエンドポイントのCBAに利用でき、認証後にAzure ADから新たな証明書が返されます。信頼を更新してもPTAエージェントのIPアドレスの値が更新されたり、以前の証明書が無効化されたりすることはありません。したがって、単一のエージェントが複数の有効な証明書を保有できます。単一のPTAエージェントが10件を超えるアクティブな証明書を保有している場合、認証要求には最も新しい10件の証明書で暗号化されたパスワードが含まれることがCTUリサーチャーの調べで確認されました。攻撃者が侵害したPTAエージェントで証明書を10回以上更新すれば、元々のPTAエージェントが資格情報を復号できなくなるため、DoS攻撃が可能になります。
Azure ADポータルで管理者が閲覧可能な情報は ブートストラップのXMLファイル要求時に投入されるため、侵害された証明書を用いてPTAエージェントに成りすましてもMicrosoft管理者ツールには検知されません。当社が作成したカスタムPTAエージェントは、アクティブなエージェントと証明書をすべてダンプ（出力）できるため（図18）、管理者側で侵害されたエージェントを検知・特定する際に役立ちます。
図18：当社のPTAカスタムエージェントがダンプしたアクティブエージェント
このカスタムエージェントは、エージェントIDおよびアクティブな証明書の拇印をテキストファイルにエクスポートします。図19のPTAエージェント（ID: 672843e0-8b25-434f-93e2-5d5071139e09）は、3つのアクティブな証明書を保有しています。つまり、侵害されたエージェントの証明書を使って、証明書が2回更新されていることになります。更新された証明書のステータスが「アクティブ」になっているため、過去10日間に攻撃者がこれらを使用したと考えられます。
図19：アクティブなエージェントと証明書の一覧（出典：Secureworks）
AD FSのトークン署名証明書とは異なり、PTAエージェントの証明書は明示的に取り消すことはできません。管理者側でサーバーからPTAエージェントを削除することはできますが、Azure SQL Databaseで直接PTAエージェントを削除することはできません。エージェントをデータベースから削除するには、エージェントを10日間非アクティブな状態にしておく必要があります。10日を過ぎると、Microsoftによってエージェントが自動削除されます。侵害されたPTAエージェントに紐づけられた証明書が攻撃者によって頻繁に使用されている場合、エージェントのステータスが非アクティブになることはありません。
Microsoft社への報告および回答内容
当社は2022年5月10日、CTUリサーチャーによる初期段階の調査結果をMicrosoft Security Response Center（MSRC）宛に報告しました。その後、検知不可能なアクセスに関する追加の調査結果を5月16日に提出しました。CTUリサーチチームはMSRCより7月7日付で以下の回答を得ました。
ご指摘の問題について当社チームで評価し、この攻撃にはまず管理者権限のアクセスを取得し、セキュリティが厳重な資産を侵害する必要があると理解しました。当社製品をご利用のお客様がセキュリティ強化に関する当社のハードニングガイダンスに従ったにもかかわらず、攻撃者がPTAエージェント実行サーバーにアクセスしたという場合は、攻撃者がユーザーの資格情報をあらかじめ入手していたと考えられます。したがって、ご指摘の脆弱性自体がさらなるリスクをもたらすことはないと考えています。緩和策として、お客様からのエスカレーションにもとづきサーバー側でエージェントをブロックする機能を提供しています。さらに、監査ログの改善を通じた検出メカニズム強化策についても現在検討中です。
結論
侵害されたPTAエージェントの証明書が攻撃者の手に渡ると、永続的かつ検知不能な形で標的組織に侵入されてしまいます。侵害された証明書を用いた攻撃活動の一例は以下のとおりです。
- 資格情報の窃取
- バックドアの設置
- 有効なパスワードの拒否、または証明書を10回以上更新することによるDoS攻撃
CTUリサーチャーは、組織のテナントを保護するための以下のアクションを実施することを推奨しています。
- PTAエージェントの実行サーバーを含むオンプレミスのハイブリッドIDコンポーネントをすべてTier 0（階層0）サーバーとして扱う。
- Microsoft社が前述のセキュリティ課題に対処するまでの間、パススルー認証以外のハイブリッド認証方式（PHS、フェデレーション認証など）の使用を検討する。
- 不審なアクティビティ（誤ったパスワードによるログインなど）を監視する。サインインのアクティビティはAzure ADポータルおよびMicrosoft Graphのサインインレポートの「ベータ」版でも確認可能。PTAエージェントに侵害の痕跡がある場合は、ただちにAzure ADポータル経由でサポート依頼を作成し、エージェントを無効化する。
- PTAエージェントが攻撃用バックドアとして悪用されないよう、多要素認証を使用する。
9月20日更新
9月13日にこの調査結果が公表された後、Microsoft社の担当者は、これらの問題に対処する計画について、次のような最新情報を提供しました。
この技術では、攻撃者がすでに標的マシンの管理者権限でのアクセスを取得している必要があります。最適な保護のために、お客様はこちらのハードニングガイダンスに従うことを推奨します: Azure AD Connect。Azure AD Connect: Prerequisites and hardware – Microsoft Entra | Microsoft Docs。さらに、お客様は、ハードニング戦略を補完し、オンプレミスのCrypto API（CAPI）キーへのアクセスやキーファイル操作、パススルー認証（PTA）ログオンイベントに関連するオンプレミスADとAzure ADインタラクティブサインインログ間の不一致を監視する必要があります。当社は、同様の攻撃から保護する新しい方法を常に模索しており、PTAエージェントの継続的なりすましを識別するために、現在のAzure ADのログにいくつかの拡張機能を追加する作業を行っています。
