侵害された悪意のあるアプリケーションの調査

  • [アーティクル]

この記事では、顧客テナント内の 1 つ以上のアプリケーションに対する悪意のある攻撃の特定と調査に関するガイダンスを提供します。 詳細な手順は、情報を保護し、さらなるリスクを最小限に抑えるために必要な修復措置を講じる際に役立ちます。

  • 前提条件: 調査を開始する前に完了する必要がある具体的な要件について説明します。 たとえば、有効にする必要があるログ、必要な役割とアクセス許可などです。
  • ワークフロー: この調査を実行するために従う必要がある論理フローを示します。
  • 調査手順: この特定の調査に関する詳細なステップ バイ ステップ ガイダンスが含まれています。
  • 包含手順: 侵害されたアプリケーションを無効にする方法に関する手順が含まれています。
  • 回復手順: 不正なアプリケーション同意付与攻撃から回復する方法、またはその攻撃を緩和する方法について、ハイ レベルの手順を示します。
  • リファレンス: その他の読み物と参考資料が含まれます。

前提条件

調査を開始する前に、詳細情報を収集するための適切なツールとアクセス許可があることを確認してください。

必要なツール

効果的な調査を行う場合は、調査用コンピューターに次の PowerShell モジュールとツールキットをインストールします。

ワークフロー

調査手順の詳細なフロー

調査手順

この調査では、ユーザー レポート、Microsoft Entra サインイン ログの例、または ID 保護検出の形式のいずれかで、アプリケーションが侵害される可能性があることを示していること前提とします。 必要なすべての前提条件の手順を完了し、有効にしてください。

このプレイブックは、Microsoft のすべてのお客様およびその調査チームが完全版の Microsoft 365 E5 または Microsoft Entra ID P2 ライセンス スイートを使用できる、または構成済みであるとは限らないと考えて作成されています。 このプレイブックでは、必要に応じて他の自動化機能が強調表示されます。

アプリケーションの種類の決定

調査フェーズの早い段階でアプリケーションの種類 (マルチテナントまたはシングル テナント) を決定して、アプリケーション所有者に連絡するために必要な正しい情報を取得することが重要です。 詳細については、Microsoft Entra ID のテナントに関する説明を参照してください。

マルチテナント アプリケーション

マルチテナント アプリケーションの場合、アプリケーションはサード パーティによってホストおよび管理されます。 アプリケーション所有者に連絡して問題を報告するために必要なプロセスを特定します。

シングルテナント アプリケーション

組織内のアプリケーション所有者の連絡先の詳細を見つけます。 これは [エンタープライズ アプリケーション] セクションの [所有者] タブにあります。 または、組織にこの情報を含むデータベースがある場合もあります。

また、次の Microsoft Graph クエリを実行することもできます。

GET https://graph.microsoft.com/v1.0/applications/{id}/owners

ID 保護の確認 - リスクのあるワークロード ID

この機能は、このプレイブックの執筆時点でプレビュー段階であり、ライセンス要件はその使用に適用されます。 リスクの高いワークロード ID は、サービス プリンシパルを調査するトリガーですが、特定した他のトリガーをさらに調査するために使用することもできます。 [ID 保護 - 危険なワークロード ID] タブを使用して、サービス プリンシパルのリスク状態をチェックすることも、Microsoft Graph API を使用することもできます。

リスク検出ポータル

リスク検出の詳細

サービス プリンシパル リスク検出 Graph API のサンプル

通常とは異なるサインイン動作を確認する

調査の最初の手順は、サービス プリンシパルの使用における通常とは異なる認証パターンの証拠を見つけることです。 組織が選択した Azure portal、Azure Monitor、Microsoft Sentinel、またはセキュリティ情報イベント管理 (SIEM) システム内の [サービス プリンシパルのサインイン] セクションで次を探します。

  • 場所 - サービス プリンシパルは、予期しない場所/IP アドレスから認証していませんか
  • 失敗 - サービス プリンシパルに対して多数の認証エラーが発生していませんか
  • タイムスタンプ - 予期しない場合に成功した認証が発生していませんか
  • 頻度 - サービス プリンシパルの認証の頻度が増加していませんか?
  • リーク資格情報 - アプリケーションの資格情報はハードコーディングされ、GitHub などのパブリック ソースに公開されていませんか?

Entra ID Identity Protection - 危険なワークロード ID をデプロイした場合は、疑わしいサインインと漏洩資格情報の検出をチェックします。 詳細については、「ワークロード ID のリスクの検出」に関する記事を参照してください。

ターゲット リソースを確認する

サービス プリンシパルのサインイン内で、認証中にサービス プリンシパルがアクセスしていたリソースもチェックします。 サービス プリンシパルがアクセスする必要があるリソースに精通しているため、アプリケーション所有者から入力を取得することが重要です。

リソースでサービス プリンシパルを確認する

認証情報の異常な変更を確認する

監査ログを使用して、アプリケーションとサービス プリンシパルの認証情報の変更に関する情報を取得します。 アプリケーション管理によるカテゴリの、および更新アプリケーション - 認定資格証とシークレット管理によるアクティビティのフィルター処理。

  • サービス プリンシパルに新しく作成された認証情報または予期しない認証情報が割り当てられているかどうかを確認します。
  • Microsoft Graph API を使用して、サービス プリンシパルの資格情報をチェックします。
  • アプリケーションと関連するサービス プリンシパル オブジェクトの両方をチェックします。
  • 作成または変更したカスタム役割を確認します。 以下に示すアクセス許可に注意してください。

作成または変更されたカスタム ロールを確認する

Microsoft Defender for Cloud Apps にアプリ ガバナンスをデプロイした場合は、アプリケーションに関連するアラートについて Azure portal をチェックします。 詳細については、「アプリ脅威の検出と修復をはじめましょう！」をご覧ください。

ID 保護をデプロイした場合は、"リスク検出" レポートと、ユーザーまたはワークロード ID の "リスク履歴" をチェックします。

リスク検出ポータル

Microsoft Defender for Cloud Apps をデプロイした場合は、"OAuth アプリへの資格情報の通常と異なる追加" ポリシーが有効になっていることを確認し、未解決のアラートをチェックします。

詳細については、「OAuthアプリへの資格情報の通常と異なる追加」を参照してください。

さらに、servicePrincipalRiskDetections API と ユーザーの riskDetections API に対してクエリを実行して、これらのリスク検出を取得できます。

異常なアプリ構成の変更を検索する

  • アプリに割り当てられている API のアクセス許可を確認して、アクセス許可がアプリに想定されるアクセス許可と一致していることを確認します。
  • 監査ログを確認します (更新プログラム アプリケーションまたは更新サービス プリンシパルでアクティビティをフィルター処理)。
  • 接続文字列が一貫しているかどうか、およびサインアウト URL が変更されているかどうかを確認します。
  • URL 内のドメインが登録されているものと一致するか確認します。
  • 承認されていないリダイレクト URL を誰かが追加していないか判断します。
  • 所有しているリダイレクト URI の所有権を確認して、有効期限が切れておらず、敵対者によって要求されていることを確認します。

また、Microsoft Defender for Cloud Apps をデプロイした場合は、現在調査しているアプリケーションに関連するアラートを Azure portal にチェックします。 OAuth アプリに対してすべてのアラート ポリシーが既定で有効になっているわけではないため、これらのポリシーがすべて有効になっていることを確認してください。 詳細については、「OAuth アプリ ポリシー」を参照してください。 [調査>OAuth アプリ] タブで、アプリの普及状況と最近のアクティビティに関する情報を表示することもできます。

疑わしいアプリケーション ロールを確認する

  • 監査ログを使用することもできます。 アプリの役割の割り当てをサービス プリンシパルに追加することでアクティビティをフィルターします。
  • 割り当てられたロールに高い権限があるかどうかを確認します。
  • これらの特権が必要かどうかを確認します。

未確認の商用アプリを確認する

  • 商用ギャラリー (公開バージョンと検証済みバージョン) アプリケーションが使用されているかどうかを確認します。

keyCredential プロパティの情報漏えいの兆候を確認する

CVE-2021-42306 で説明されているように、テナントで潜在的な keyCredential プロパティ情報の開示を確認します。

影響を受ける Automation 実行アカウントに関連付けられている影響を受ける Microsoft Entra アプリケーションを特定して修復するには、GitHub リポジトリの修復ガイダンスに移動してください。

重要

侵害の証拠: 侵害の証拠を発見した場合は、包含と回復のセクションで強調表示されている手順を実行することが重要です。 これらの手順はリスクに対処するのに役立ちますが、さらなる影響を回避し、悪いアクターが確実に削除されるように、侵害の原因を理解するためにさらに調査を実行します。

アプリケーションを使用してシステムにアクセスするには、主に 2 つの方法があります。 1 つ目は、通常はフィッシング攻撃を介して、管理者またはユーザーがアプリケーションに同意する必要があります。 この方法は、システムへの初期アクセスの一部であり、"同意フィッシング" と呼ばれることがよくあります。

2 つ目の方法では、永続化、データ収集、およびレーダーの下に留まる目的で、既に侵害された管理者アカウントが新しいアプリを作成します。 たとえば、侵害されてしまった管理者は、一見無害な名前の OAuth アプリを作成し、検出を回避し、アカウントを必要とせずにデータへの長期的なアクセスを許可することができます。 この方法は、多くの場合、国家支援型攻撃で見られます。

さらに調査するために実行できる手順の一部を次に示します。

Microsoft 365 統合監査ログ (UAL) で過去 7 日間のフィッシング詐欺の兆候を確認する

攻撃者が悪意のあるアプリケーションや侵害されたアプリケーションを永続化の手段として使用したり、データを流出させたりする場合、フィッシィングの攻撃活動が関与することがあります。 前の手順で得られた結果に基づいて、次の ID を確認する必要があります。

  • アプリケーションオーナー
  • 管理者の同意

過去 24 時間以内のフィッシング攻撃の兆候の ID を確認します。 すぐに兆候がない場合は、必要に応じてこの期間を 7 日、14 日、30 日に延長します。 フィッシング調査プレイブックの詳細については、「フィッシング調査プレイブック」を参照してください。

過去 7 日間の悪意のあるアプリケーションの同意を検索する

テナントにアプリケーションを追加するには、攻撃者はユーザーまたは管理者を偽装してアプリケーションに同意します。 攻撃の兆候についての詳細は、「アプリケーションの同意付与の調査プレイブック」を参照してください。

監査ログを確認する

そのアプリケーションのすべての同意許可を表示するには、アプリケーションへの同意でアクティビティをフィルター処理します。

  • Microsoft Entra 管理センター監査ログを使用する

  • Microsoft Graph を使用して監査ログをクエリする

    a) 特定の概算時間のフィルター:

GET https://graph.microsoft.com/v1.0/auditLogs/auditLogs/directoryAudits?&$filter=activityDateTime le 2022-01-24

b) "アプリケーションへの同意" 監査ログ エントリの監査ログのフィルター。

https://graph.microsoft.com/v1.0/auditLogs/directoryAudits?directoryAudits?$filter=ActivityType eq 'Consent to application'


"@odata.context": "https://graph.microsoft.com/v1.0/$metadata#auditLogs/directoryAudits",
"value": [
    {
        "id": "Directory_0da73d01-0b6d-4c6c-a083-afc8c968e655_78XJB_266233526",
        "category": "ApplicationManagement",
        "correlationId": "0da73d01-0b6d-4c6c-a083-afc8c968e655",
        "result": "success",
        "resultReason": "",
        "activityDisplayName": "Consent to application",
        "activityDateTime": "2022-03-25T21:21:37.9452149Z",
        "loggedByService": "Core Directory",
        "operationType": "Assign",
       "initiatedBy": {
            "app": null,
            "user": {
                "id": "8b3f927e-4d89-490b-aaa3-e5d4577f1234",
                "displayName": null,
                "userPrincipalName": "admin@contoso.com",
                "ipAddress": "55.154.250.91",
                "userType": null,
                "homeTenantId": null,
                "homeTenantName": null
            }
        },
        "targetResources": [
            {
                "id": "d23d38a1-02ae-409d-884c-60b03cadc989",
                "displayName": "Graph explorer (official site)",
                "type": "ServicePrincipal",
                "userPrincipalName": null,
                "groupType": null,
                "modifiedProperties": [
                    {
                        "displayName": "ConsentContext.IsAdminConsent",
                        "oldValue": null,
                        "newValue": "\"True\""
                    },

c) ログ分析の使用

AuditLogs
| where ActivityDisplayName == "Consent to application"

詳細については、「アプリケーションの同意付与の調査ハンドブック」を参照してください。

ユーザーは、そのユーザーとして機能しながら、保護されたリソースにある一部のデータにアクセスすることをアプリケーションに対して承認できます。 この種類のアクセスを許可するアクセス許可は、「委任されたアクセス許可」またはユーザーの同意と呼ばれます。

ユーザーが同意したアプリを検索するには、LogAnalytics を使用して監査ログを検索します。

AuditLogs
| where ActivityDisplayName == "Consent to application" and (parse_json(tostring(parse_json(tostring(TargetResources[0].modifiedProperties))[0].newValue)) <> "True")

監査ログを調べて、付与されたアクセス許可の範囲が広すぎる (テナント全体または管理者同意) かどうかを確認します

アプリケーションまたはサービス プリンシパルに付与されたアクセス許可の確認には時間がかかる場合があります。 最初は、Microsoft Entra ID で潜在的な 危険なアクセス許可 を理解します。

次に、アプリの同意付与調査でアクセス許可を列挙して確認する方法に関するガイダンスに従います。

アクセス許可が、その能力機能を持つべきではないユーザー ID によって付与されたかどうか、または操作が奇妙な日時に実行されたかどうかを確認します

監査ログを使用して以下を確認します。

AuditLogs
| where OperationName == "Consent to application" 
//| where parse_json(tostring(TargetResources[0].modifiedProperties))[4].displayName == "ConsentAction.Permissions"

Microsoft Entra 監査ログを使用し、アプリケーションへの同意でフィルター処理することもできます。 [監査ログの詳細] セクションで、[変更されたプロパティ] をクリックし、ConsentAction.Permissions を確認します。

Microsoft Entra 監査ログを使用する

包含のステップ

1 つ以上のアプリケーションまたはワークロード ID を悪意のある ID または侵害されたアプリケーションとして識別した後、ただちにこのアプリケーションの資格情報をロールすることや、アプリケーションを直ちに削除することをしなくても構いません。

重要

次の手順を実行する前に、組織は、アプリケーションを無効にした場合のセキュリティへの影響とビジネスへの影響を考慮する必要があります。 アプリケーションを無効にした場合のビジネスへの影響が大きすぎる場合は、このプロセスの復旧ステージの準備と移行を検討してください。

侵害されたアプリケーションを無効にする

一般的な封じ込め戦略では、特定されたアプリケーションへのサインインを無効にし、インシデント応答チームまたは影響を受ける事業単位の時間を割り当て、削除またはキーのローリングの影響を評価します。 調査の結果、管理者アカウントの資格情報も侵害されていると思われる場合は、この種のアクティビティを削除イベントと調整して、テナントにアクセスするすべてのルートが同時に切断されるようにする必要があります。

ユーザーのサインインを無効に切り替える

次の Microsoft Graph PowerShell コードを使用して、アプリへのサインインを無効にすることもできます。

# The AppId of the app to be disabled
$appId = "{AppId}"

# Check if a service principal already exists for the app
$servicePrincipal = Get-MgServicePrincipal -Filter "appId eq '$appId'"

if ($servicePrincipal) {
   # Service principal exists already, disable it

  $ServicePrincipalUpdate =@{
    "accountEnabled" = "false"
  }
   Update-MgServicePrincipal -ServicePrincipalId $servicePrincipal.Id -BodyParameter $ServicePrincipalUpdate
   
} else {
   # Service principal does not yet exist, create it and disable it at the same time
   
   $ServicePrincipalID=@{
	"AppId" = $appId
	"accountEnabled" = "false"
   }
   
   $servicePrincipal = New-MgServicePrincipal -BodyParameter $ServicePrincipalId
   
}

回復後の手順

サービス プリンシパルを修復する

  1. 危険なサービス プリンシパルに割り当てられているすべての資格情報を一覧表示します。 これを行う最良の方法は、GET ~/application/{id} を使用して Microsoft Graph 呼び出しを実行することで、渡される ID はアプリケーション オブジェクト ID です。

    • 資格情報の出力を解析します。 出力には passwordCredentials または keyCredentials が含まれている場合があります。 すべての keyId を記録します。

      "keyCredentials": [],
     "parentalControlSettings": {
         "countriesBlockedForMinors": [],
         "legalAgeGroupRule": "Allow"
     },
     "passwordCredentials": [
         {
             "customKeyIdentifier": null,
             "displayName": "Test",
             "endDateTime": "2021-12-16T19:19:36.997Z",
             "hint": "7~-",
             "keyId": "9f92041c-46b9-4ebc-95fd-e45745734bef",
             "secretText": null,
             "startDateTime": "2021-06-16T18:19:36.997Z"
         }
     ],

  2. アプリケーション addKey API を使用して、新しい (x509) 証明書資格情報をアプリケーション オブジェクトに追加します。

    POST ~/applications/{id}/addKey

  3. 古い認証情報をすべてすぐに削除します。 古いパスワード認証情報ごとに、次を使用して削除します。

    POST ~/applications/{id}/removePassword

    それぞれの過去のキー資格情報に対して、次を使用して削除します。

    POST ~/applications/{id}/removeKey

  4. アプリケーションに関連付けられているすべてのサービス プリンシパルを修復します。 テナントがマルチテナント アプリケーションをホストまたは登録し、アプリケーションに関連付けられている複数のサービス プリンシパルを登録する場合は、この手順に従います。 過去に記載されていたものに、同様の手順を実行します。

  • GET ~/servicePrincipals/{id}

  • 応答で passwordCredentials と keyCredentials を検索し、すべての古い keyId を記録します

  • すべての古いパスワードとキー資格情報を削除します。 以下を使用してください。

    POST ~/servicePrincipals/{id}/removePassword and POST ~/servicePrincipals/{id}/removeKey for this, respectively.

影響を受けるサービス プリンシパル リソースを修復する

サービス プリンシパルがアクセスできる KeyVault シークレットをローテーションすることで、次の優先順位で修復します。

  • GetSecret 呼び出しで直接公開されるシークレット。
  • 公開されている KeyVault の残りのシークレット。
  • 公開されているサブスクリプション全体の残りのシークレット

詳細については、「サービス プリンシパルまたはアプリケーションの証明書とシークレットを対話的に削除してロールオーバーする」を参照してください。

アプリケーションに関する Microsoft Entra SecOps ガイダンスについては、アプリケーションの Microsoft Entra セキュリティ オペレーション ガイド for Appsを参照してください。

優先順位の順に、このシナリオは次のようになります。

  • Graph PowerShell コマンドレット (ApplicationKey + ApplicationPassword の追加/削除) ドキュメントを更新して、認証情報のロールオーバーの例を含めます。
  • このシナリオを簡略化するカスタム コマンドレットを Microsoft Graph PowerShell に追加します。

悪意のあるアプリケーションを無効または削除する

アプリケーションは無効にするか削除するができます。 アプリケーションを無効にするには、[ユーザーがサインインできるように有効にする] で、トグルを [いいえ] に移動します。

Azure portal または Microsoft Graph API を使用して、アプリケーションを一時的または永続的に削除することができます。 論理的な削除を行うと、削除から最大 30 日後にアプリケーションを回復できます。

DELETE /applications/{id}

アプリケーションを完全に削除するには、次の Microsoft Graph API 呼び出しを使用します。

DELETE /directory/deletedItems/{id}

アプリケーションを無効にした場合、またはアプリケーションを論理的に削除する場合は、Microsoft Entra 監査ログで監視を設定して、状態が有効または復旧に戻ったかどうかを確認します。

有効化のログ記録:

  • サービス - コア ディレクトリ
  • アクティビティの種類 - サービス プリンシパルの更新
  • カテゴリ - アプリケーション管理
  • 開始者 (アクター) - アクターの UPN
  • ターゲット - アプリ ID と表示名
  • 変更されたプロパティ - プロパティ名 = 有効なアカウント、新しい値 = true

回復のログ記録:

  • サービス - コア ディレクトリ
  • アクティビティの種類 - サービス プリンシパルの追加
  • カテゴリ - アプリケーション管理
  • 開始者 (アクター) - アクターの UPN
  • ターゲット - アプリ ID と表示名
  • 変更されたプロパティ - プロパティ名 = 有効なアカウント、新しい値 = true

注: Microsoft は、サービス利用規約に違反していることが判明したアプリケーションをグローバルに無効にします。 この場合、これらのアプリケーションは、Microsoft Graph の関連アプリケーションおよびサービス プリンシパル リソースの種類の disabledByMicrosoftStatus プロパティに DisabledDueToViolationOfServicesAgreement と表示されます。 将来的に組織で再度インスタンス化されないようにするために、これらのオブジェクトを削除することはできません。

ワークロード ID の ID 保護の導入

Microsoft は、サインイン時の動作やオフラインでの侵害の兆候からのワークロード ID のリスクを検出します。

詳細については、「ID 保護を使用してワークロード ID をセキュリティで保護する」を参照してください。

これらのアラートは ID 保護 ポータルに表示され、診断設定または ID 保護 API を使用して SIEM ツールにエクスポートできます。

Identity Protection ポータルでリスクとアラートを確認する

リスクのあるワークロード ID 用の条件付きアクセス

条件付きアクセスを使用すると、ID 保護によって "危険な状態" としてマークされたときに指定した特定のアカウントのアクセスをブロックできます。 条件付きアクセスによる適用は、現在、シングルテナント アプリケーションのみに制限されていることに注意してください。

条件付きアクセス ポリシーに基づいて、ユーザー アクセスを制御する

詳細については、「ワークロード ID 用の条件付きアクセス」を参照してください。

アプリケーション リスク ポリシーを実装する

[Microsoft Entra ID]>[エンタープライズ アプリケーション]>[同意とアクセス許可]>[ユーザーの同意設定] でユーザー同意設定を確認します。

オプションから [アプリに対するユーザーの同意を許可する] を選択する

構成オプションを確認するには、「ユーザーがアプリに同意する方法を構成する」を参照してください。

テナント全体についての同意を与える意図で、アプリケーション開発者がユーザーを管理者の同意エンドポイントに誘導する場合、これは管理者の同意フローと呼ばれます。 管理者の同意フローを適切に動作させるために、アプリケーション開発者は、アプリケーション マニフェストの RequiredResourceAccess プロパティにすべてのアクセス許可をリストする必要があります。

ほとんどの組織では、ユーザーがアプリケーションに同意する機能を無効にします。 アプリケーションの同意を引き続き要求する機能をユーザーに付与し、管理レビュー機能を持つ機能を持たせるには、管理者の同意ワークフローを実装することをお勧めします。 管理者の同意ワークフローの手順に従って、テナントで構成します。

管理者の同意などの高い特権を持つ操作の場合は、ガイダンスで定義されている特権アクセス戦略を使用します。

リスクベースのステップアップ同意は、ユーザーが悪意のあるアプリにさらされる機会を減らすことができます。 たとえば、基本以外のアクセス許可を必要とする、発行元が確認されていない新しく登録されたマルチテナント アプリの場合、その同意要求は危険であると見なされます。 危険なユーザーの同意要求が検出された場合、代わりに管理者の同意を求める "ステップアップ" が必要になります。 このステップアップ機能は既定で有効ですが、ユーザーの同意が有効化されている場合にのみ、動作変更につながります。

テナントで有効になっていることを確認し、ここに記載されている構成設定を確認します。

リファレンス

その他のインシデント対応プレイブック

次の追加の種類の攻撃を特定して調査するためのガイダンスを確認してください。

インシデント対応のリソース