ブログ（脅威調査）

Microsoft365とAzureの Active Directoryバックドアの検出

| by Mike Burns
Mandiant
Detection
Incident Response
Backdoor

Mandiantは、Microsoft365(M365) とAzure Active Directory (Azure AD) で発生する侵害の増加を確認してきました。これらの侵害のほとんどは、フィッシング・メールによって、M365にアクセスするために使用される認証情報を、フィッシング・サイトに入力するようユーザーに強制することによって発生します。他の侵害としては、パスワードのスプレー、パスワードのスタッフィング、M365テナントに対する簡単なブルート・フォースの試みなどがあります。これらの侵害のほぼすべてにおいて、ユーザーやアカウントは多要素認証 (MFA)によって保護されていませんでした。

これらの日和見的攻撃は、M365およびAzure ADにとって、最も一般的な形式の侵害であり、通常、持続性を確立するための最初のベクトルです。インシデントレスポンス(IR)エンゲージメントとプロアクティブなクラウドアセスメントの両方で、しばしば要求されます。

アイデンティティ・フェデレーションの悪用

攻撃者の条件

  • Active Directory Federation Servicesを実行しているADおよびサーバーへのローカル管理アクセス

または

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

M365認証の手法のひとつに、フェデレーション・サービスの使用があります。M365ドメインが連携ドメインとして構成されている場合、M365と外部IDプロバイダーの間に信頼関係が構築されます。多くの場合、この信頼関係はオンプレミスのActive Directoryドメイン用Active Directory Federation Services (ADFS)サーバーに確立されます。

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


図4:Microsoft365 Federationのサインイン・ワークフロー

AADInternalsにはPowerShell機能があり、ADFS認証処理を模倣するセキュリティ・トークンを作成します。有効なUserPrincipalName、Immutable ID、IssuerURIを指定すると、攻撃者はテナントの任意のユーザーとしてセキュリティ・トークンを生成できます。さらに重要な点は、このセキュリティ・トークンが生成されると、攻撃者がMFAを迂回できるようになることです。

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

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

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

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

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


図5:AADInternals Open-AADIntOffice365Portalコマンド

手法2:クラウド侵害

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

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


図6:Get-MsolUser-listユーザーUPN&ImmutableId

  • IssuerURI
    • これは管理対象ドメインを連携ドメインに変換することによって取得できます。図7～図10は、AADInternals ConvertTo-AADIntBackdoorコマンド(図8)を使用して、攻撃者が連携ドメインに独自のIssuerURIを登録できるよう方法を示しています。


図7:登録済みドメインと認証のGet-msoldomain-list


図8:ConvertTo-AADIntBackdoor-連携認証に変換


図9:変更された認証方法


図10:Azure ADポータルの登録済みドメイン

注:既存の連携ドメインとの生産および認証を中断しない(および検出されないままにしない)ために、攻撃者はテナントに新しいドメインを登録する場合があります。


図11:新しい連携ドメインを使用したAADInternals Open-AADIntOffice365Portal Command

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

しかし防御者はこの方法で統合された監査ログに多数のイベントを生成し、監視と警告に活用することができます。

M365統合監査ログとAzure ADログのバックドアのハンティング

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

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


図15:Azure ADサインイン

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


図16:Azure AD Sign-in logs-On-Premisesディレクトリ同期サービス・アカウント

Azure AD Sign-inから、Azure AD Application Proxy ConnectorへのAzure AD Sign-inの監視とベースラインを行います。ユーザ名、IP、および場所を検証してください。

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


図17:Azure AD Sign-inログ-Azure AD Application Proxy Connector

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


図18:Register Connector-Azure Sentinelログ

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


図19:Azure Active Directoryパススルー認証エージェントのステータス

  • Office365Security&Compliance Centerの統合監査ログで「Directory Administration Activity」を監視し、警告します。攻撃者が侵害されたクラウド・テナント内にドメイン連携を作成し、攻撃者所有のインフラストラクチャにリンクすると、ログにアクティビティが生成されます(図21) 。
    • https://Protections.office.com/unifiedauitlog> 監査ログ検索
    • ディレクトリ管理を選択：すべてのアクティビティを選択するには、カテゴリを有効にします。
    • 新しいアラート・ポリシーの作成(図20)


図20:Unified Audit Log>Create new alert policy


図21:ドメイン関連イベントに対してフィルタリングされたUnified Audit Log

  • Azure Sentinelを使用すると、より詳細なディレクトリ管理アクティビティを不審な活動用に変更できます。これには、ドメインの追加、削除、変更とその認証設定が含まれます(図22) 。
    • Azure SentinelでのOfficeActivityオペレーションの監視により、これが正規化された活動であるかどうか、または攻撃者がPTAまたは連携のバックアップドアの設定に取り組んでいるかどうかを組織内で検証できます。
      • 表:OfficeActivity
        • 操作: Set-AcceptedDomain
        • 運用: Set-MsolDomainFederationSettings
        • 操作: Add-FederatedDomain
        • 操作: New-Accepted Domain
        • 操作: Remove-Accepted Domain
        • 操作: Remove-FederatedDomain


図22:OfficeActivity Operations Azure Sentinelのログ

検知オンプレミス

攻撃者がオンプレミス・インフラストラクチャを侵害し、AADInternalsなどのツールを利用してクラウドへのアクセス範囲を拡大することを目的としており、AD ConnectまたはADFSサービスを実行しているサーバーにアクセス可能な場合は、タイムリーなオンプレミスの検知と封じ込めが重要です。以下の方法を活用することで、このブログで説明する活動範囲に合わせて最適化された可視性と検知を確保できます。

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


図23:EventID410-Installed Module

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


図24:インストール済みモジュールを一覧表示するGet-Moduleコマンド

  • C:\PTASpyおよびC:\PTASpy\PTASpy.csvが存在することを示すアラート
    • これは、ツールによって傍受されたすべてのアカウントの記録を含むログファイルのデフォルトの場所です。攻撃者は、これを使用して認証情報を収集することもあるため、これらのアカウントのパスワードを再設定することが重要です(図25)。


図25:PTASpy.csvログ・アクティビティ

緩和

この攻撃を成功させるには、攻撃者がAzure AD Connectを実行しているサーバーの管理者権限を取得するか、M365内でグローバル管理者権限を取得する必要があります。グローバル管理者アカウントの制限や適切な保護、Tier0アセットの適切な保護などのシンプルなプラクティスにより、組織に対しAADInternals PowerShellを利用しようとする攻撃者の危険性を大幅に減らすことができます。

  • Azure AD Connectサーバーへのアクセスを制限
    • アイデンティティ・プロバイダとして機能、またはアイデンティティ連携を促進するいかなるサーバーも、Tier0資産として扱われます。
  • 専用のグローバル管理者アカウントを個別に作成
    • グローバル管理者は、クラウドのみのアカウントにする必要があります。.
    • これらのアカウントでは、いかなるライセンスも保持しない
  • すべてのアカウント(admins、users、サービス)にMFAを実施
    • 特定のアカウントでMFAを使用できない場合は、そのアカウントのログオンを信頼できるネットワークに制限する条件付きアクセスルールを適用します。これは、特にサービス・アカウントに適しています。
  • レガシー認証をブロックするロードマップを確立
  • オンプレミスからクラウドに同期するアカウントを制限
    • 極秘アカウントやサービス・アカウントをクラウドに同期しないでください。
  • Azure管理ロールを使用
    • 環境を管理するには、すべてがグローバル管理者である必要はありません。
  • パススルー認証でパスワード・ハッシュ同期を使用
    • 多くの組織は、パスワードをAzure ADに同期することを望んでいます。このサービスのメリットは、リスクを大きく上回ります。グローバルおよびカスタムの禁止されたパスワードリストをクラウドとオンプレミスの両方で使用できることは大きなメリットになります。
  • すべてのM365統合監査ログとAzureログをSIEMに転送し、検知を構築
    • この投稿で推奨されているログを転送し、セキュリティ・オペレーションチーム内で適切な検知とプレイブックを構築していることを確認します。
    • 具体的な監視対象:
      • Set-AcceptedDomain
      • Set-MsolDomainFederationSettings
      • Add-FederatedDomain
      • New-Accepted Domain
      • Remove-Accepted Domain
      • Remove-FederatedDomain
  • M365テナントに設定されているすべてのアイデンティティ・プロバイダとカスタム・ドメインを定期的に確認
    • 攻撃者がグローバル管理者権限の取得に成功した場合、持続性を維持するために独自のIDプロバイダーとカスタム・ドメイン追加を選択できます。

謝辞

このブログ記事の作成にあたり、Mandiantと協力してくれたMicosoft社のDaniel Taylor氏, Roberto Bamberger氏、Jennifer Kendall氏 に心から感謝します。

 

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

原文：September 30, 2020 「Detecting Microsoft 365 and Azure Active Directory Backdoors」

前の投稿
次の投稿