Azure AD参加端末におけるPRT (Primary Refresh Token)悪用のリスクと対策について

更新日：2023.08.01

はじめに

オフェンシブセキュリティ部ペネトレーションテスト課の安里悠矢です。
普段は組織内の社内ITインフラやクラウド環境上に構築されたインフラに対するペネトレーションテストをしています。

テレワーク環境の整備が進んだ昨今、エンドポイント端末の管理とセキュリティ対策はゼロトラストネットワークを実現するにあたって重要なポイントとなります。
ゼロトラストネットワークのよくある構成の一例としては、エンドポイント端末を Azure ADに参加させてIntuneでデバイス管理を実装している環境が挙げられます。
Azure ADに参加するエンドポイント端末は、PRT(Primary Refresh Token)と呼ばれる認証済みトークンを保持しています。
実際のペネトレーションテストでPRTを発見した際には、このトークンを悪用して組織が利用するAzure ADの他、チャットツールなどの各種クラウドサービスへ侵入していくことが多々あります。
また、ペネトレーションテスト実施後には、このトークンが攻撃者によって盗まれてしまったことを検知するにはどのようにしたら良いのか、トークンの悪用を確認した時点で無効化するにはどのようにしたら良いのかというご相談をお客様からよくいただきます。

Azure ADを利用したゼロトラストネットワーク構成を採用している組織は多いものの、PRTに関する日本語の文献は少なく、悪用された場合のリスクが一般的にはあまり知られていないため、PRTの悪用に備えた対策まで行われているところは少ないかもしれません。
本稿をきっかけに、テレワーク環境を整備する企業にとってPRTにどのようなリスクが存在するかを知り、セキュアなテレワーク環境の構築にお役立ていただけたら幸甚です。

「AzureAD」におけるPRTとは？

Azure ADにおけるPRT (Primary Refresh Token)は、WindowsデバイスにおいてSSO (シングルサインオン) の機能を提供するためのトークンです。
つまり、Azure ADに接続されたアプリケーションが存在し、且つ端末利用者がそのアクセス権を所有している場合、 PRTを用いてアプリケーションに IDとパスワードを入力することなく自動でサインインし、アプリケーションを利用することが可能です。

図1：各クラウドアプリケーションとAzure ADとの連携

試しにAzure ADに参加済みのWindows端末のEdgeブラウザを使用し、Office 365にアクセスする際の挙動を見てみましょう。
まず、コマンドプロンプトにて「dsregcmd.exe /status」コマンドを実行します。「AzureAdPrt: YES」と出力されていれば Windows端末が Azure ADに参加しており、 PRTを所有していることが確認できます。

図2：dsregcmd.exe /status コマンド結果の抜粋

続いて、EdgeブラウザからOffice365にアクセスします。Microsoftの認証画面に一瞬リダイレクトされますが、すぐにOffice365のトップ画面が表示されます。

図3：シームレスなサインインの画面

この動作時のHTTP通信の詳細を確認すると、サインイン時のリクエストのCookieヘッダに「x-ms-RefreshTokenCredential」が付与されていることが分かります。このCookieに付与された値が前述のPRTであり、IDとパスワードを提示することなくシームレスなサインインを実現しています。
※PRTを使用したブラウザSSOの詳細は、Microsoftの公式ドキュメントが参考になります。
参考:プライマリ更新トークンとは - Microsoft Docs

図4：PRTを使用した際のHTTPリクエスト

ユーザーがサインイン時にPRTを使用しているかどうかはAzure ADのサインインログから確認できます。

図5：PRT使用時のAzure ADのサインインログ

なお、サインインにPRTを使用する場合、追加のMFAが要求されなくなります。これはPRTにはユーザー名、パスワード、MFAによる認証に成功したという情報が既に格納されており、それ以上の資格情報が必要とされないためです。

※ 条件付きアクセスポリシーは、PRTを用いた認証後に評価されます。そのため、条件付きアクセスポリシーが全く評価されないというわけではありません。PRTには既にMFA認証に成功したという情報が格納されていることから、条件付きアクセスでMFAを要求するように設定してもMFAを再度要求されることはありませんが、国やIPアドレスなどの場所に基づいた追加の条件付きアクセスポリシーについては正常に評価されます。

PRTの悪用と利用価値について

前述の通り、PRTはAzure ADに接続された各アプリケーションへのシングルサインオンを行うためのトークンです。つまり、攻撃者に何らかの方法でエンドポイント端末へ侵入され、端末内のPRTを取得されることは、組織が利用する各種アプリケーションにまで侵害が拡大する可能性があることを意味します。
また、ゼロトラストネットワーク製品やVPN製品などのアプリケーションとAzure ADを連携することでアクセス元の制限を行っている場合においても、PRTを悪用することで攻撃者は組織内の内部ネットワークのみで運用されているサービスやネットワークにもアクセスすることが可能です。
このため、PRTは攻撃者にとって非常に価値のある認証済みトークンとなります。

PRTを実際に取得してみる

実際に攻撃者がAzure ADに参加する端末に侵入できたと想定して端末からPRTを取得し、Office365にアクセスしてみます。
PRTを取得するためのツールとして以下を使用します。
参考: leechristensen / RequestAADRefreshToken - github.com

※ 本稿では詳細な解説は省きますが当該ツールが登場した後にPRTの仕様が変更されており、正常に動作させるためには若干のプログラムの修正が必要です。

図6：端末内からPRTを取得

図7：Chromeブラウザの開発ツールを使用しCookieを追加

図8：PRTを使用してoffice.comにアクセス

もう少し掘り下げて、PRTの取得方法を見てみる

specterops社の以下の記事では、Google Chromeブラウザの拡張機能「 Windows Accounts 」の
動作をデバッグした際の挙動を記載しています。この記事によるとPRTの取得時に「C:\Windows\System32\MicrosoftAccountTokenProvider.dll 」を読み込みさらに「GetCookieInfoForUri」関数を呼び出していることが分かります。
参考: Requesting Azure AD Request Tokens on Azure-AD-joined Machines for Browser SSO - posts.specterops.io

PRT悪用の検出がなぜ難しいのか？どのように検出するのか？

PRTはエンドポイント端末をAzure ADに参加させるためにIDとパスワードやMFAを提示した上で発行されます。つまり一度既に認証情報を提示してAzure ADに信頼されたトークンであるため、仮に悪用されたとしても悪性な通信かどうかを判定することは困難です。
そのため、クラウド側のサインインログやエンドポイント端末上で発生するログ等を組み合わせて振る舞いを監視した上で、通信が悪性なものかを判定する必要があります。

クラウド側のサインインログによる検出方法

クラウド側での検出方法としては、サインインログを元に検出ロジックを組む方法があります。
一例として営業ユーザー（ sumeragi@328moe.onmicrosoft.com ）が通常業務でAzure Portal を使用することはなく、営業ユーザーによるAzure Portal へのアクセスが発生した場合は悪用の可能性があると仮定し、メールで通知するケースを考えてみましょう。
事前にAzure ADのサインインログをLogAnalyticsに転送するように設定した上で、KQLを作成します。

AADNonInteractiveUserSignInLogs
| where UserPrincipalName == "sumeragi@328moe.onmicrosoft.com"

KQLを実行すると、アプリケーションのサインインログが表示されます。AppDisplayNameを確認すると営業ユーザーがAzure Portalにサインインしていることが確認できます。

図9： KQLの実行結果

さらにパラメータ「AppId」で条件を設定してアラートルールを作成することで、通常はAzure Portal を使用しないユーザーによるサインインの検出と、アラートメールの送信が可能です。

図10：LogAnalytics: アラートルールの作成

図11：アラートメールの抜粋

Azure AD Identity Protection によるユーザーとサインインのリスク検出

Azure AD Identity Protectionを使用している場合、対策のベースラインとして利用することができます。
例えば、通常端末を使用している場所とは全く異なる場所からPRTを使用した場合、「異常なトークン」として検出することが可能です。一方で、エンドポイント端末を通信の踏み台としてAzure ADにサインインした場合には、正常な通信との判別が困難であり、悪用の検出はできない可能性があることをご留意ください。

図12：Azure Identity Protection: 通常とは異なるデバイスからのサインインを検出

エンドポイント端末側のイベントログによる検出方法

通常PRTを取得する際には、「MicrosoftAccountTokenProvider.dll」が呼び出されます。そのため、当該DLLの読み込みをどのプロセスが実行しているかを監視することで、検出のベースラインを作成することができます。一般的なEDR製品でもDLLの読み込みは監視していますが、全てのDLLの読み込みを監視しているわけではないため、別途Sysmonを利用してDLLの読み込みを監視する必要があります。
以下は、DLLの読み込みをイベントログに記録するためのサンプルのXMLファイルです。このXMLファイルをSysmonで読み込みます。

<Sysmon schemaversion="4.83">
  <EventFiltering>
    <RuleGroup name="Load MicrosoftAccountTokenProvider.dll" groupRelation="or">
      <ImageLoad onmatch="include">
        <ImageLoaded condition="contains">MicrosoftAccountTokenProvider.dll</ImageLoaded>
      </ImageLoad>  
    </RuleGroup>
  </EventFiltering>
</Sysmon>

「MicrosoftAccountTokenProvider.dll」が読み込まれた場合に、以下のようにイベントログに記録することが可能です。

図13：イベントログに記録されたDLLの読み込み情報

このイベントログをSIEMに取り込むことで、不正なプロセスがDLLを読み込んだかどうかを検出するための設定ができるようになります。
一方で、当該DLLは正規のユーザーによる通常動作でも読み込まれるDLLです。そのため、どのプロセスがDLLを読み込むかを事前に把握したり、ログを監視しながら実際にどのプロセスがDLLを読み込んでいるのかを確認したりする必要があります。一定期間ログを取り続けることで、組織内でどのプロセスがDLLを読み込むかを把握できるようになりますので、徐々に検出精度をあげていくことができます。
全量ではないものの通常操作でDLLを読み込むプロセスについては、以下の記事にも記載されておりますのでご参照ください。
参考: Requesting Azure AD Request Tokens on Azure-AD-joined Machines for Browser SSO - posts.specterops.io

また、EDRを選定する機会がある場合は、選定のポイントとしてPRTの悪用を検出できるような機能が備わっているかを確認して決めるのも良いでしょう。

PRTが悪用された場合の対処方法

PRTが悪用を検知した場合や、Azure ADユーザーの侵害を確認した場合、アカウントの無効化を行う必要があります。また、単純にアカウントを無効化しただけでは、PRTを含む発行済みのセッションは有効期限まで継続して利用できてしまうため、アカウントだけではなく併せてセッションの無効化も必要です。
アカウントの無効化の手順については以下の通りMicrosoftドキュメントが公開されていますが、Azure ADやMSOLのPowerShellモジュールが将来的に非推奨となるため、Microsoft Graph PowerShell モジュールに置き換えたものを記載します。

参考: Azure Active Directory でユーザーアクセスを取り消す - lean.microsoft.com

今回は、Azure ADのみの利用と想定して記載します。以降の手順は Azure ADの管理者ユーザーにて実行する必要があります。
※ ユーザIDの部分や、DeviceIdの部分はお使いの環境に合わせて読み替えてください。

・アカウントの無効化

Update-MgUser -UserId johndoe@contoso.com -AccountEnabled:$false

・セッション/アクセストークンの取り消し

Invoke-MgInvalidateUserRefreshToken -UserId johndoe@contoso.com

・デバイスの無効化

Update-MgDevice -DeviceId $deviceId -AccountEnabled:$false

また、上記の手順を実行することでAzure ADで管理されたユーザーとデバイスについては無効化が完了しますが、シングルサインオンでサインインをした各アプリケーションについては個別でセッションの取り消しが必要です。ユーザーがどのアプリケーションのサインインに成功したかはAzure ADのサインインログを確認します。有事の際にはセッションの取り消し作業で慌ただしくなりますので、各アプリケーションでのセッションの取り消し方法を予め確認しておくことを推奨します。

今回は、Azure ADユーザやPRTの悪用という観点にフォーカスして対応手順を記載しています。実際にエンドポイント端末が攻撃者によって侵害されている場合は、上記の対応だけでは不足する点がありますのでご注意ください。

将来的な対策方法

現在パブリックプレビューの機能となりますが、Azureにおいて「サインインセッションのトークン保護」の機能がリリースされています。これは、トークンの盗難やリプレイ攻撃の対策として実装されたものであり、トークンが意図したデバイス上でのみ使用することを保証するための機能となります。本稿執筆時点では、対応するアプリケーションが現時点では限定的であり全ての連携されるアプリケーションが対象ではありません。ですが、将来的には何らかの方法で全てのアプリケーションにトークンを保護するような仕組みが提供されていくのかもしれません。

参考: パブリックプレビュー: サインインセッションのトークン保護 - Japan Azure Identity Support Blog

終わりに

今回は「Azure AD」参加端末におけるPRT(Primary Refresh Token)悪用のリスクと対策」について記事を作成しました。
昨今、セキュリティ対策製品の検知・防御をすり抜けた攻撃も多く、エンドポイント端末が攻撃者によって侵害されたことを想定した検出方法を多層防御的に実装する必要性が出てきています。
この記事を読んで、未対策の状態から徐々に検知精度を向上させたり、自組織のセキュリティ対策を少しでも強化したりすることにお役立ていただけると筆者としてもとても嬉しく思います。

宣伝

弊社では、ペネトレーションテストによってお客様の利用する環境の脆弱性や運用上の問題点を様々な観点で調査・ご報告しています。
自組織のセキュリティ対策の有効性がどの程度なのか、テストを通して擬似インシデントが発生した際にSOCやCSIRTが適切に動けるかといった観点での評価も実施しております。
弊社のペネトレーションテストにご興味がありましたら是非お問い合わせください。

・ペネトレーションテストサービスページ
https://gmo-cybersecurity.com/service/pentest/

・レッドチーム演習サービスページ
https://gmo-cybersecurity.com/service/redteam/