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

[アーティクル]
03/14/2024

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

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

前提条件

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

ID 保護シグナルを使用するには、テナントに Microsoft Entra ID P2 のライセンスが付与されている必要があります。
- ID 保護のリスクの概念について
- ID 保護調査の概念について
少なくともセキュリティ管理者ロールを持つアカウント。
Microsoft Graph エクスプローラーを使用する能力を持ち、Microsoft Graph API を (ある程度まで) 使い慣れていること。
アプリケーション監査の概念 (https://aka.ms/AzureADSecOps の一部)を熟知していること。
テナント内のすべてのエンタープライズアプリに、アカウンタビリティを目的として所有者が設定されていることを確認します。アプリ所有者の概要とアプリ所有者の割り当てに関する概念を確認します。
アプリの同意付与の調査の概念 (https://aka.ms/IRPlaybooks の一部) を熟知していること。
次の Microsoft Entra アクセス許可を理解していることを確認してください。
- リスクのあるアクセス許可
- 同意モデルと管理者の同意ワークフロー
ワークロード ID リスク検出の概念を熟知していること。
Microsoft Defender for Cloud Apps を使用するには、完全版の Microsoft 365 E5 ライセンスが必要です。
- 異常検出アラート調査の概念を理解する
次のアプリケーション管理ポリシーについて熟知していること。
- Microsoft Entra アプリケーション認証方法 API の概要 (プレビュー)
- appManagementPolicy リソースの種類
次のアプリガバナンスポリシーについて熟知していること。
- アプリガバナンスのブログ
- Defender for Cloud Apps のアプリガバナンス

必要なツール

効果的な調査を行う場合は、調査用コンピューターに次の 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 を使用することもできます。

[リスク検出の詳細] ポータルページのスクリーンショット。

[リスク検出の詳細] ユーザーインターフェイスページのスクリーンショット。

サービスプリンシパルリスク検出グラフ API のサンプル。

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

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

Microsoft 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": "aaaa0000-bb11-2222-33cc-444444dddddd",
        "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
   
}

回復後の手順

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

危険なサービスプリンシパルに割り当てられているすべての資格情報を一覧表示します。これを行う最善の方法は、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": "aaaaaaaa-0b0b-1c1c-2d2d-333333333333",
             "secretText": null,
             "startDateTime": "2021-06-16T18:19:36.997Z"
         }
     ],

アプリケーション addKey API を使用して、新しい (x509) 証明書資格情報をアプリケーションオブジェクトに追加します。
```
POST ~/applications/{id}/addKey
```
古い認証情報をすべてすぐに削除します。古いパスワード認証情報ごとに、次を使用して削除します。
```
POST ~/applications/{id}/removePassword
```
それぞれの過去のキー資格情報に対して、次を使用して削除します。
```
POST ~/applications/{id}/removeKey
```
アプリケーションに関連付けられているすべてのサービスプリンシパルを修復します。テナントがマルチテナントアプリケーションをホストまたは登録し、アプリケーションに関連付けられている複数のサービスプリンシパルを登録する場合は、この手順に従います。過去に記載されていたものに、同様の手順を実行します。

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

Note

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

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

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

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

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

Identity Protection ポータルでリスクとアラートを確認する方法のスクリーンショット。

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

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

条件付きアクセスポリシーに基づいてユーザーアクセスを制御する方法のスクリーンショット。

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

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

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

アプリのユーザーの同意を許可する方法のスクリーンショット。

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

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

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

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

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

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

リファレンス

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

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

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

新規担当者および経験豊富なアナリスト向けの Microsoft セキュリティ製品およびリソースの概要
セキュリティオペレーションセンター (SOC) の計画
Microsoft Defender XDR のインシデント対応
Microsoft Defender for Cloud (Azure)
Microsoft Sentinel のインシデント応答
Microsoft インシデント対応チームガイドでセキュリティチームとリーダー向けのベストプラクティスを共有
Microsoft インシデント対応ガイドは、セキュリティチームによる疑わしいアクティビティの分析で役に立つ

次の方法で共有

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

前提条件

必要なツール

ワークフロー

調査手順

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

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

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

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

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

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

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

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

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

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

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

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

監査ログを確認する

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

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

包含のステップ

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

回復後の手順

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

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

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

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

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

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

リファレンス

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

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

フィードバック

その他のリソース

次の方法で共有

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

前提条件

必要なツール

ワークフロー

調査手順

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

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

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

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

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

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

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

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

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

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

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

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

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

フラグが設定されたアプリケーションのアプリケーション同意を確認する

監査ログを確認する

アプリケーションに対して、エンドユーザーの不審な同意があったかどうかを判断する

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

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

包含のステップ

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

回復後の手順

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

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

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

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

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

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

ユーザーの同意設定を確認する

管理者の同意フローを実装する

リスクベースのステップアップ同意設定を確認する

リファレンス

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

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

フィードバック

その他のリソース

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

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

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

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

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

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

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