Microsoft 365 および Azure Active Directory バックドアの検出

Mandiant では、Microsoft 365 (M365) と Azure Active Directory (Azure AD) に関連するインシデントが増加しています。これらのインシデントのほとんどは、M365 へのアクセスに使用する資格情報をフィッシング サイトに入力するようにユーザーに強制するフィッシング メールの結果です。その他のインシデントは、パスワード スプレー、パスワード スタッフィング、または M365 テナントに対する単純なブルート フォース攻撃の結果です。これらのインシデントのほとんどすべてで、ユーザーまたはアカウントは多要素認証 (MFA) によって保護されていませんでした。

これらの日和見攻撃は、確かに M365 と Azure AD の侵害の最も一般的な形式であり、通常、永続性を確立するための最初のベクトルです。インシデント対応 (IR) エンゲージメントとプロアクティブなクラウド評価の両方で、次のような質問を受けることがよくあります。

• Mandiant が M365 と Azure AD に対して確認している他の種類の攻撃は何ですか?
• オンプレミスの侵害が M365 と Azure AD に “垂直” に移行する可能性はありますか?
• グローバル管理者アカウントが侵害された場合、侵害されたアカウントが検出され、パスワードのリセットが発生し、MFA が適用された後でも永続性を維持することは可能ですか?

AADInternals PowerShell モジュール

いくつかのインシデントで、Mandiant は、攻撃者がAADInternalsと呼ばれる PowerShell モジュールを利用しているのを目撃しました。これにより、攻撃者は、オンプレミスから Azure AD に垂直に移動し、バックドアを確立し、パスワードを盗み、ユーザー セキュリティ トークンを生成し、MFA 保護をバイパスすることができます。この PowerShell モジュールにより、攻撃者は最初の根絶作業が行われた後でも、テナント内で永続性を維持することができました。

このモジュールの実際の動作を確認し、その仕組みを理解するには、Dr. Nestori Syynimaa の PSCONFEU 2020 プレゼンテーション、 Abusing Azure Active Directory: Who would you like to be today? を参照してください。は、モジュールの詳細な概要を提供します。

AADInternals の使用を検出するには、これらの攻撃の一部がどのように機能するかを理解することが重要です。理解が深まれば、ログ分析とホストベースのインジケーターの組み合わせにより、異常な使用を検出できます。

バックドア 1: パススルー認証の悪用

攻撃者の要件

• パススルー認証を実行しているサーバーへのローカル管理アクセス

または

• M365 グローバル管理者の資格情報

AADInternals PowerShell モジュールには、 Install-AADIntPTASPYという関数が含まれています。この機能は、Azure AD とオンプレミス環境で PTA エージェントを実行しているサーバーとの間で発生するパススルー認証 (PTA) プロセス内に中間者として自身を挿入することによって機能します。通常、PTA エージェントは、Azure AD Connect (AAD Connect) と同じオンプレミス サーバーで実行されます。

PTA が有効になっている場合、Azure AD に対して発生するすべてのログオンは、オンプレミスの PTA エージェントにリダイレクトされます。 PTA エージェントは、オンプレミスの Active Directory ドメイン コントローラーに、認証アカウントのパスワードが有効かどうかを尋ねます。有効な場合、PTA エージェントは Azure AD に応答して、リクエスター アクセスを許可します。図 1 は、パススルー認証のワークフローと、AADInternals が要求を傍受できる場所を示しています。

関数が実行されると、Azure AD に対するすべての PTA 試行は、インストールされているAADIntPTASpyモジュールによってインターセプトされます。モジュールは、ユーザーのパスワードの試行を記録し、PTA エージェントに代わって Azure AD に返信します。この応答は、パスワードの試行が有効であったことを Azure AD に通知し、パスワードが正しくない場合でも、ユーザーにクラウドへのアクセスを許可します。攻撃者がAADIntPTASpyを埋め込んだ場合、攻撃者は PTA を使用して認証を試みる任意のユーザーとしてログインでき、アクセスが許可されます。

さらに、 AADIntPTASpyモジュールによって登録されたすべてのパスワード試行は、サーバー上のログ ファイルに記録されます (デフォルトの場所: C:PTASpyPTASPy.csv )。図 2 は、ログ ファイルをデコードしてユーザーのパスワードを平文で明らかにする方法を示しています。

この機能は、攻撃者が PTA 経由で認証された任意のユーザーとしてログインできるようにするだけでなく、Azure AD に正規にログインしているユーザー パスワードを収集するためのリポジトリとしても機能します。これにより、攻撃者は攻撃をネットワークの他の領域に向けることができます。または、単一要素認証を利用する可能性がある他のインターネット アクセス可能なポータル (VPN ゲートウェイなど) に対してこれらの資格情報を使用できます。

攻撃者は、次の 2 つの方法のいずれかでこのモジュールを使用できます。

方法 1: オンプレミス侵害

攻撃者はオンプレミス ドメインへのアクセス権を取得し、AADConnect / PTA エージェント サーバーに横方向に移動できます。このサーバーから、攻撃者は AADInternals PowerShell モジュールを利用して、 Install-AADIntPTASpy関数を呼び出す可能性があります。

方法 2: クラウド侵害

攻撃者が Azure AD グローバル管理者アカウントの侵害に成功した場合、攻撃者自身のインフラストラクチャから攻撃が実行される可能性があります。攻撃者は、自分が管理するサーバーに PTA エージェントをインストールし、侵害されたグローバル管理者アカウントを使用してエージェントを登録できます (図 3)。

Azure AD に登録されると、不正なサーバーはすべてのログイン試行の傍受と承認を開始します。方法 1 と同様に、このサーバーを使用して有効な資格情報を収集することもできます。

バックドア 2: Identity Federation の悪用

攻撃者の要件

• Active Directory フェデレーション サービスを実行している AD およびサーバーへのローカル管理アクセス

または

• M365 グローバル管理者の資格情報

M365 に対する認証のもう 1 つの方法は、フェデレーション サービスを使用することです。 M365 ドメインがフェデレーション ドメインとして構成されている場合、M365 と外部 ID プロバイダーの間に信頼が構成されます。多くの場合、この信頼は、オンプレミスの Active Directory ドメインの Active Directory フェデレーション サービス (ADFS) サーバーで確立されます。

信頼が確立されると、ユーザーがフェデレーション ドメインを使用して M365 にログインすると、その要求は外部 ID プロバイダー (ADFS) にリダイレクトされ、そこで認証が検証されます (図 4)。検証が完了すると、ADFS サーバーはユーザーにセキュリティ トークンを提供します。このトークンは M365 によって信頼され、プラットフォームへのアクセスを許可します。

AADInternals には、ADFS 認証プロセスを模倣するセキュリティ トークンを作成するための PowerShell 関数があります。関数に有効な UserPrincipalName、不変 ID、および IssuerURI を提供すると、攻撃者はテナントの任意のユーザーとしてセキュリティ トークンを生成できます。さらに懸念されるのは、このセキュリティ トークンが生成されると、攻撃者が MFA をバイパスできるようになることです。

バックドア 1 と同様に、この攻撃は侵害されたオンプレミス環境から、または攻撃者自身のインフラストラクチャから実行される可能性があります。

方法 1: オンプレミス侵害

攻撃者は、昇格されたアクセス権を持つオンプレミス ドメインへのアクセス権を取得すると、必要な情報を収集し始めて、独自のセキュリティ トークンを作成し、任意のユーザーとして M365 にバックドアできます。攻撃者は以下を必要とします:

• 有効な UserPrincipalName と Immutable。
  • これらの属性は両方とも、オンプレミスの Active Directory ドメインから取得できます。
• ADFS サーバーの IssuerURI と ADFS 署名証明書。
  • これは、サーバーに直接ログインするか、特権アカウントを介してサーバーにリモートでクエリを実行するときに、ADFS サーバーから取得できます。

攻撃者が AADInternals Open-AADIntOffice365Portalコマンドを使用して必要な情報を収集すると、攻撃者に M365 へのアクセスを許可するユーザーのセキュリティ トークンを生成できます (図 5)。

方法 2: クラウド侵害

攻撃者が独自のインフラストラクチャを使用して M365 グローバル管理者アカウントを侵害した場合、攻撃者は管理アクセスを使用してユーザー情報を収集し、テナントを再構成してバックドアを確立できます。この方法では、攻撃者は以下を要求します。

• 有効な UserPrincipalName と有効な ImmutableId。
  • 図 6 は、 Get-MsolUserコマンドが Azure AD からユーザーの ImmutableId を取得する方法を示しています。

• 発行者URI
  • これは、マネージド ドメインをフェデレーション ドメインに変換することで取得できます。図 7 ～ 10 は、AADInternals ConvertTo-AADIntBackdoorコマンド (図 8) を使用して、攻撃者がフェデレーション ドメインに独自の IssuerURI を登録できるようにする方法を示しています。

注: 既存のフェデレーション ドメインでの運用と認証を中断しない (そして検出されないようにする) ために、攻撃者は新しいドメインをテナントに登録することを選択する可能性があります。

攻撃者が任意のユーザーの ImmutableId を使用してテナントを適切に構成すると、 Open-AADIntOffice365Portalコマンドを実行してセキュリティ トークンを生成できます (図 11)。これにより、攻撃者は、有効な証明書や正当な IssuerURI を必要とせずに、そのユーザーとしてログインできるようになります。

防御側にとって幸いなことに、この方法では統合監査ログに多数のイベントが生成され、監視とアラートに活用できます。

緩和と検出

持続性が確立されると、前述の方法のいずれかを使用しているログイン アクティビティを検出することが非常に困難になる可能性があります。代わりに、M365 統合監査ログと Azure AD サインイン アクティビティを監視してアラートを出し、異常なアクティビティを検出することをお勧めします。

FireEye Helix での検出

Mandiant はこの手法が実際に使用されていることを確認したため、これらの検出を FireEye Helix セキュリティ プラットフォームに組み込む必要があると感じました。 Helix のエンジニアは、AADInternals PowerShell モジュールを利用する攻撃者の検出可能なアクティビティを監視する新しい検出ルールをいくつか作成しました。

次の 5 つのルールは、サーバーのイベント ログを監視し、AADInternals PowerShell モジュールのインストールと使用について警告します (図 12)。これらのアクティビティの検出は、攻撃者が M365 および Azure AD 環境へのバックドアを構成する準備をしているという忠実度の高いアラートである可能性があります。

攻撃者が AADInternals を使用してバックドアの構成に成功した場合、Helix は、Office 365 統合監査ログと Azure アクティビティ ログに登録された次のイベントについて、可能性のあるイベントの兆候として警告を発します (図 13 および図 14)。これらのアラートは、正当な管理者のアクティビティによってトリガーされる可能性があることに注意してください。これらのアラートに対応するときは、まず M365 および Azure AD 管理者に確認して、セキュリティ イベントを発生させる前にアクティビティを確認してください。

M365 統合監査ログと Azure AD ログでバックドアを探す

グローバル管理者アカウントが侵害された疑いがあり、潜在的な悪用の兆候について Azure AD を確認したい場合は、以下を確認する必要があります (これらと同じ概念をプロアクティブなログ監視に使用できることに注意してください)。

• Azure AD サインイン ログから、オンプレミス ディレクトリ同期サービス アカウントからのログオン アクティビティを監視します。このアカウントは、Azure AD Connect サービスによって使用されます (図 15)。

• このアカウントで使用される IP アドレスのベースラインを設定し、IP がオンプレミスの WAN インフラストラクチャに割り当てられたものと一致することを確認します。攻撃者が独自のインフラストラクチャで PTA エージェントを構成している場合、ベースラインと一致しない IP が表示されることは、攻撃者によって不正な PTA エージェントが構成されていることを示している可能性があります (図 16)。

Azure AD サインインから、Azure AD アプリケーション プロキシ コネクタへの Azure AD サインインを監視およびベースライン化します。ユーザー名、IP、場所を確認してください。

これらのイベントは通常、新しい PTA エージェントがテナントに接続されたときにのみ生成されます。これは、攻撃者のインフラストラクチャでホストされている不正な PTA サーバーに攻撃者が接続したことを示している可能性があります (図 17)。

Azure Sentinel を使用している場合、このイベントは Azure AuditLogs テーブルにも ” Register Connector ” OperationName として登録されます (図 18)。

• Azure AD Connect ブレードの下の Azure 管理ポータルで、PTA エージェントを実行しているすべての登録済みサーバーを確認します。認証エージェントと IP は、インフラストラクチャと一致する必要があります (図 19)。
  • https://portal.azure.com にログインします。
    • [Azure AD Connect] > [パススルー認証] を選択します

• Office 365 セキュリティ & コンプライアンス センターの統合監査ログで “ディレクトリ管理アクティビティ” を監視し、警告します。攻撃者が侵害されたクラウド テナント内にドメイン フェデレーションを作成し、これを攻撃者が所有するインフラストラクチャにリンクできる場合、ログにアクティビティが生成されます (図 21)。
  • https://Protections.office.com/unifiedauitlog > 監査ログ検索
  • すべてのアクティビティを選択するには、ディレクトリ管理のアクティブ化カテゴリを選択します
  • 新しいアラート ポリシーの作成 (図 20)

• Azure Sentinel を使用すると、疑わしいアクティビティに対してより詳細なディレクトリ管理アクティビティを変更できます。これには、ドメインとその認証設定の追加、削除、変更が含まれます (図 22)。
  • Azure Sentinel でのOfficeActivity操作の監視により、組織は、これが正規化されたアクティビティであるかどうか、または攻撃者が PTA またはフェデレーションのバックドアの設定に取り組んでいるかどうかを検証できます。
    • 表: OfficeActivity
      • 操作: Set-AcceptedDomain
      • 操作: MsolDomainFederationSettings の設定
      • 操作: FederatedDomain の追加
      • 操作: 新規承認済みドメイン
      • 操作: 承認済みドメインの削除
      • 操作: FederatedDomain の削除

オンプレミスでの検出

攻撃者がオンプレミスのインフラストラクチャを侵害し、AADInternals などのツールを利用してクラウドを含むようにアクセスの範囲を拡大する意図で、AD Connect または ADFS サービスを実行しているサーバーにアクセスできる場合、タイムリーなオンプレミスの検出と封じ込めが必要です。鍵。次の方法を活用して、この投稿で説明されているアクティビティの範囲で最適化された可視性と検出を確保できます。

• ADFS および Azure AD Connect サーバーをTier 0 資産として扱います。
  • それぞれに専用サーバーを使用します。これらの役割とサーバーを他に加えてインストールしないでください。ファイル サーバー上で実行されている Azure AD Connect をよく見かけます。
• AD Connect および ADFS サーバーでPowerShell ログが最適化されていることを確認する
• ADFS および AADConnect サーバー ログの Microsoft-Windows-PowerShell/Operational ログを確認します。
  • PowerShell ログが有効になっている場合は、イベント ID 4101 を検索します。このイベント ID は、AADInternals がインストールされたイベントを記録します (図 23)。

• さらに、このログを有効にすると、攻撃者が使用した PowerShell コマンドを確認できます。
  • PowerShell で Get-Module -All を実行し、AADInternals の存在を探します (図 24)。

• C:PTASpy および C:PTASpyPTASpy.csv の存在を警告します。
  • これは、ツールによって傍受されたすべてのアカウントの記録を含むログ ファイルの既定の場所です。攻撃者はこれを使用して資格情報を収集することもできるため、これらのアカウントのパスワードをリセットすることが重要です (図 25)。

緩和策

この攻撃が成功するためには、攻撃者は Azure AD Connect を実行しているサーバーで管理者権限を取得するか、M365 内でグローバル管理者権限を取得する必要があります。グローバル管理者アカウントを制限して適切に保護するだけでなく、階層 0 の資産を適切に保護するなどの単純なプラクティスにより、攻撃者が組織に対して AADInternals PowerShell をうまく使用するリスクを大幅に減らすことができます。

• Azure AD Connect サーバーへのアクセスを制限または制限します。
  • ID プロバイダーとして機能するサーバー、または ID フェデレーションを促進するサーバーは、Tier 0 の資産として扱う必要があります。
• 個別の専用グローバル管理者アカウントを作成します。
  • グローバル管理者は、クラウドのみのアカウントである必要があります。
  • これらのアカウントはライセンスを保持しないでください。
• すべてのアカウント (管理者、ユーザー、およびサービス) に MFA を実装します。
  • 特定のアカウントが MFA を使用できない場合は、信頼できるネットワークへのログオンを制限する条件付きアクセス ルールを適用します。これは、サービス アカウントの場合に特に有効です。
• 従来の認証をブロックするためのロードマップを確立します。
• オンプレミスからクラウドに同期されるアカウントを制限します。
  • 特権アカウントまたはサービス アカウントをクラウドに同期しないでください。
• Azure 管理ロールを使用します。
  • 環境を管理するために、全員またはすべてがグローバル管理者である必要はありません。
• パススルー認証でパスワード ハッシュ同期を使用します。
  • 多くの組織は、パスワードを Azure AD に同期することに消極的です。このサービスのメリットは、リスクを大幅に上回ります。クラウドとオンプレミスの両方で、グローバルおよびカスタムの禁止パスワード リストを使用できることは、非常に大きなメリットです。
• すべての M365 統合監査ログと Azure ログを SIEM に転送し、検出を構築します。
  • この投稿で推奨されているログを転送し、セキュリティ運用チーム内で適切な検出とプレイブックを構築していることを確認してください。
  • 具体的には次を監視します。
    • Set-AcceptedDomain
    • セット-MsolDomainFederationSettings
    • Add-FederatedDomain
    • 新規承認済みドメイン
    • 承認済みドメインの削除
    • 削除 FederatedDomain
• M365 テナントで構成されているすべての ID プロバイダーとカスタム ドメインを定期的に確認します。
  • 攻撃者がグローバル管理者権限の取得に成功した場合、永続性を維持するために独自の ID プロバイダーとカスタム ドメインを追加することを選択する可能性があります。

謝辞

このブログ投稿の作成で Mandiant と協力してくれた Microsoft の Daniel Taylor、Roberto Bamberger、Jennifer Kendall に特に感謝します。