遭入侵和恶意应用程序调查

项目
03/10/2024

本文提供有关识别和调查对客户租户中一个或多个应用程序的恶意攻击的指导。分步说明会帮助你采取必要的补救措施以保护信息，并最大程度地降低进一步的风险。

先决条件：介绍在开始调查之前需要完成的特定要求。例如，应启用的日志记录、所需的角色和权限，等等。
工作流：显示执行此调查应遵循的逻辑流。
调查步骤：包括用于此特定调查的详细分步指南。
遏制步骤： 包含有关如何禁用遭入侵应用程序的步骤。
恢复：包含有关如何从对遭入侵应用程序的恶意攻击中恢复/缓解的高级步骤。
参考：包含其他阅读和参考资料。

先决条件

在开始调查之前，确保你具有正确的工具和权限来收集详细的信息。

若要使用标识保护信号，租户必须取得 Microsoft Entra ID P2 许可证。
- 了解标识保护风险概念
- 了解标识保护调查概念
至少有安全管理员角色的帐户。
能够使用 Microsoft Graph 浏览器，并熟悉（在某种程度上）Microsoft Graph API。
自行熟悉应用程序审核概念（https://aka.ms/AzureADSecOps 的一部分）。
确保租户中的所有企业应用都具有出于问责目的而设置的所有者。查看有关应用所有者概述和分配应用所有者的概念。
自行熟悉应用同意授权调查的概念（https://aka.ms/IRPlaybooks 的一部分）。
请确保了解以下 Microsoft Entra 权限：
- 有风险的权限
- 同意模型和管理员同意工作流
自行熟悉工作负载标识风险检测的概念。
你必须具有完整的 Microsoft 365 E5 许可证，才能使用 Microsoft Defender for Cloud Apps。
- 了解异常情况检测警报调查的概念
自行熟悉以下应用程序管理策略：
- Microsoft Entra 应用程序身份验证方法 API 概述（预览）
- appManagementPolicy 资源类型
自行熟悉以下应用治理策略：
- 应用治理博客
- Defender for Cloud Apps 中的应用治理

必需工具

为了进行有效的调查，请在调查计算机上安装以下 PowerShell 模块和工具包：

Workflow

调查步骤的详细流程图。

调查步骤

对于此调查，假设你以用户报告、Microsoft Entra 登录日志示例或标识保护检测的形式获知潜在应用程序入侵的迹象。请确保完成并启用所有所需的先决条件步骤。

创建此剧本时有一个目的，即不是所有 Microsoft 客户或其调查团队都会获得提供的或配置的完整 Microsoft 365 E5 或 Microsoft Entra ID P2 许可证套件。此剧本在适当时重点介绍其他自动化功能。

确定应用程序类型

务必在调查阶段早期确定应用程序（多租户或单租户）的类型，以获取与应用程序所有者联系所需的正确信息。有关详细信息，请参阅 Microsoft Entra ID 中的租户。

多租户应用程序

对于多租户应用程序，应用程序由第三方托管和管理。标识联系应用程序所有者并向应用程序所有者报告问题所需的过程。

单租户应用程序

在组织内查找应用程序所有者的联系人详细信息。可以在“企业应用程序”部分的“所有者”选项卡下找到它。或者，你的组织可能具有一个包含此信息的数据库。

你还可以执行以下 Microsoft Graph 查询：

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

检查标识保护 - 具有风险的工作负载标识

在撰写该剧本时，此功能处于预览状态，其使用将适用许可要求。有风险的工作负载标识可以作为调查服务主体的触发器，但也可用于进一步调查你已识别的其他触发器。可以使用“标识保护 – 有风险的工作负载标识”选项卡检查服务主体的“风险状态”，也可以使用 Microsoft Graph API。

风险检测详细信息门户页面的屏幕截图。

风险检测详细信息用户界面页的屏幕截图。

服务主体风险检测图形 API 的示例。

调查的第一步是查找服务主体使用中异常身份验证模式的证据。在 Azure 门户、Azure Monitor、Microsoft Sentinel 或组织选择的安全信息和事件管理 (SIEM) 系统中，在“服务主体登录”部分中查找以下内容：

位置 – 服务主体是否从你不期望的位置\IP 地址进行身份验证？
失败 - 服务主体是否存在大量身份验证失败的情况？
时间戳 - 是否有时会发生你意想不到的成功身份验证？
频率 - 服务主体的身份验证频率是否增加？
泄漏凭据 - 是否在公共源（如 GitHub）上硬编码和发布任何应用程序凭据？

如果已部署Microsoft Entra ID 标识保护 - 有风险的工作负荷标识，请检查 可疑登录和泄漏凭据检测。有关详细信息，请参阅工作负载标识风险概述。

检查目标资源

在服务主体登录内，还要检查服务主体在身份验证期间访问的资源。请务必从应用程序所有者获取输入，因为它们熟悉服务主体应访问的资源。

有关如何检查服务主体的资源的屏幕截图。

检查异常凭据更改

使用审核日志来获取有关应用程序和服务主体的凭据更改的信息。按“应用程序管理”筛选“类别”，按“更新应用程序 – 证书和密码管理”筛选“活动”。

检查是否有新创建的或意外的凭据分配给服务主体。
使用 Microsoft Graph API 检查服务主体上的凭据。
同时检查应用程序和关联的服务主体对象。
检查你创建或修改的任何自定义角色。请注意下面标记的权限：

有关如何检查已创建或已修改的自定义角色的屏幕截图。

如果在 Microsoft Defender for Cloud Apps 中部署了应用治理，请检查 Azure 门户以了解与应用相关的警报。有关详细信息，请参阅应用威胁检测和修正入门。

如果部署了标识保护，请检查“风险检测”报告，以及用户或工作负载标识的“风险历史记录”。

风险检测门户用户界面的屏幕截图。

如果部署了 Microsoft Defender for Cloud Apps，请确保已启用“向 OAuth 应用异常添加凭据”策略，并检查是否有未处理的警报。

有关详细信息，请参阅向 OAuth 应用异常添加凭据。

此外，还可以查询 servicePrincipalRiskDetections 和用户 riskDetections APIs，以检索这些风险检测。

搜索异常应用程序配置更改

检查分配给应用的 API 权限，以确保权限与应用的预期权限一致。
检查审核日志（按“更新应用程序”或“更新服务主体”筛选“活动”）。
确认连接字符串是否一致，以及是否已修改退出登录 URL。
确认 URL 中的域是否与注册的域一致。
确定是否有人添加了未经授权的重定向 URL。
确认你对所拥有的重定向 URI 的所有权，以确保它并未过期，且未由对手声明。

此外，如果部署了 Microsoft Defender for Cloud Apps，请检查与当前正在调查的应用程序相关的警报的 Azure 门户。默认情况下，并非所有警报策略都为 OAuth 应用启用，因此请确保这些策略都已启用。有关详细信息，请参阅 OAuth 应用策略。你还可以在“调查>OAuth 应用”选项卡下，查看有关应用普遍性和最近活动的信息。

检查可疑的应用程序角色

你还可以使用审核日志。按“向服务主体添加应用角色分配”筛选“活动”。
确认分配的角色是否具有高权限。
确认这些权限是否必要。

检查未验证的商业应用

检查是否正在使用商业库（已发布和经验证版本）应用程序。

检查 keyCredential 属性信息泄漏的迹象

如 CVE-2021-42306 中所述，查看你的租户是否存在潜在的 keyCredential 属性信息泄漏。

若要识别和修正受影响的Microsoft与受影响的自动化运行方式帐户关联的 Entra 应用程序，请导航到修正指南 GitHub 存储库。

重要

如果发现泄露的证据，请务必执行包含和恢复部分中突出显示的步骤。这些步骤有助于降低风险，但开展更深入调查以便了解攻击的来源，可进一步避免受影响并确保消除不良参与者的威胁。

通过使用应用程序来访问系统有两种主要方法。第一种涉及管理员或用户同意的应用程序，通常通过网络钓鱼攻击。此方法是初始访问系统的一部分，通常称为“同意钓鱼”。

第二种方法涉及遭入侵的管理员帐户，为了持久性、数据收集和不易被发现，创建一个新应用。例如，遭入侵的管理员可能使用看似无害的名称创建 OAuth 应用，从而避免检测并允许长期访问数据，而无需帐户。此方法常用于国家/地区攻击。

以下是可以采取的一些步骤，以便进一步调查。

检查 Microsoft 365 统一审核日志 (UAL) 是否有过去七天的网络钓鱼迹象

有时，当攻击者使用恶意或遭入侵的应用程序作为持久性或外泄数据的手段时，会涉及网络钓鱼活动。根据前面步骤的调查结果，应查看以下项的标识：

应用程序所有者
同意管理员

查看标识，了解过去 24 小时内网络钓鱼攻击的迹象。如果没有立即的迹象，则根据需要将此时间跨度延长到 7 天、14 天和 30 天。有关详细的网络钓鱼调查剧本，请参阅网络钓鱼调查剧本。

搜索过去七天内的恶意应用程序同意情况

为了将应用程序添加到租户，攻击者会欺骗用户或管理员以同意应用程序。要了解有关攻击迹象的详细信息，请参阅应用程序同意授予调查剧本。

检查审核日志

要查看该应用程序的所有同意授予，请按“同意使用应用程序”筛选“活动”。

使用 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) 使用 Log Analytics

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 中存在潜在风险的权限。

现在，请遵循有关如何在应用同意授权调查中枚举和查看权限的指导。

检查权限是否由不具备执行此操作能力的用户标识授予，或者操作是否在奇怪的日期和时间执行

使用审核日志查看：

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

还可以使用 Microsoft Entra 审核日志，按“同意使用应用程序”筛选。在“审核日志”详细信息部分中，单击“已修改的属性”，然后查看 "ConsentAction.Permissions"：

如何使用 Microsoft Entra 审核日志的屏幕截图。

遏制步骤

在将一个或多个应用程序或工作负载标识识别为恶意或遭入侵以后，你可能不想立即滚动此应用程序的凭据，也不想立即删除此应用程序。

重要

执行以下步骤之前，组织必须权衡禁用应用程序的安全影响和业务影响。如果禁用应用程序的业务影响太大，则考虑准备并移动到此过程的恢复阶段。

禁用遭入侵的应用程序

典型的遏制策略包括禁止登录已识别的应用程序，以便为事件响应团队或受影响的业务单位提供时间来评估删除或密钥滚动的影响。如果调查让你认为管理员帐户凭据也已泄露，则此类活动应与逐出事件协调，以确保同时截断访问租户的所有路由。

如何禁用用户登录的屏幕截图。

还可以使用以下 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图形调用，其中传递的 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"
         }
     ],

使用应用程序 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 应用程序安全运营指南。

按优先级顺序，此方案为：

更新 Graph PowerShell cmdlet（添加/删除 ApplicationKey + ApplicationPassword）文档，以包含凭据滚动更新的示例。
将自定义 cmdlet 添加到 Microsoft Graph PowerShell，以简化此方案。

禁用或删除恶意应用程序

可以禁用或删除应用程序。要禁用应用程序，请在“启用以供用户登录”下，将切换开关移动到“否”。

可以在 Azure 门户或通过 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。若要防止将来在组织中再次实例化这些对象，不能删除这些对象。

实施工作负载标识的标识保护

Microsoft 通过登录行为和脱机入侵指标检查工作负载标识的风险。

有关详细信息，请参阅使用标识保护服务保护工作负载标识。

这些警报显示在标识保护门户中，并且可以通过“诊断设置”或“标识保护 API”导出到 SIEM 工具。

如何在 Identity Protection 门户中查看风险和警报的屏幕截图。

用于风险工作负载标识的条件访问

当标识保护将特定帐户标记为“有风险”时，条件访问允许你阻止对你指定的特定帐户的访问。通过条件访问强制实施目前仅限于单租户应用程序。

如何基于条件访问策略控制用户访问的屏幕截图。

有关详细信息，请参阅工作负载标识的条件访问。

实施应用程序风险策略

在“Microsoft Entra ID”>“企业应用程序”>“同意和权限”>“用户同意设置”下方，审查用户同意设置。

如何允许用户许可应用的屏幕截图。

要查看配置选项，请参阅配置用户对应用表示同意的方式。

当应用程序开发人员因意图授予对整个租户的同意而将用户定向到管理员同意终结点时，即称为管理员同意流。若要确保管理员同意流正常工作，应用程序开发人员必须列出应用程序清单内“RequiredResourceAccess”属性中的所有权限。

大多数组织禁用用户同意应用程序的功能。若要使用户仍能够请求应用程序同意并具有管理评审功能，建议实现管理员同意工作流。按照管理员同意工作流步骤在你的租户中进行配置。

对于管理员同意等高特权操作，可以参考指导中定义的特权访问策略。

基于风险的升级同意有助于减少用户遭受恶意应用的攻击。例如，以下行为被视为有风险：针对新注册的多租户应用的同意请求，而且这些应用未经过发行商验证且要求非基本权限。如果检测到用户同意请求存在风险，该请求需要“升级”，改为管理员同意。此升级功能默认启用，但如果启用了用户同意，则仅会导致行为更改。

通过

遭入侵和恶意应用程序调查

先决条件

必需工具

Workflow

调查步骤

确定应用程序类型

多租户应用程序

单租户应用程序

检查标识保护 - 具有风险的工作负载标识

检查目标资源

检查异常凭据更改

搜索异常应用程序配置更改

检查可疑的应用程序角色

检查未验证的商业应用

检查 keyCredential 属性信息泄漏的迹象

检查 Microsoft 365 统一审核日志 (UAL) 是否有过去七天的网络钓鱼迹象

搜索过去七天内的恶意应用程序同意情况

检查审核日志

检查审核日志，以查找授予的权限是否过于宽泛（租户范围内或管理员同意）

检查权限是否由不具备执行此操作能力的用户标识授予，或者操作是否在奇怪的日期和时间执行

遏制步骤

禁用遭入侵的应用程序

恢复步骤

修正服务主体

修正受影响的服务主体资源

禁用或删除恶意应用程序

实施工作负载标识的标识保护

用于风险工作负载标识的条件访问

实施应用程序风险策略

参考

其他事件响应剧本

事件响应资源

反馈

其他资源

通过

遭入侵和恶意应用程序调查

先决条件

必需工具

Workflow

调查步骤

确定应用程序类型

多租户应用程序

单租户应用程序

检查标识保护 - 具有风险的工作负载标识

检查异常登录行为

检查目标资源

检查异常凭据更改

搜索异常应用程序配置更改

检查可疑的应用程序角色

检查未验证的商业应用

检查 keyCredential 属性信息泄漏的迹象

检查 Microsoft 365 统一审核日志 (UAL) 是否有过去七天的网络钓鱼迹象

搜索过去七天内的恶意应用程序同意情况

检查已标记应用程序的应用程序同意

检查审核日志

确定是否有可疑的最终用户同意使用该应用程序

检查审核日志，以查找授予的权限是否过于宽泛（租户范围内或管理员同意）

检查权限是否由不具备执行此操作能力的用户标识授予，或者操作是否在奇怪的日期和时间执行

遏制步骤

禁用遭入侵的应用程序

恢复步骤

修正服务主体

修正受影响的服务主体资源

禁用或删除恶意应用程序

实施工作负载标识的标识保护

用于风险工作负载标识的条件访问

实施应用程序风险策略

审阅用户同意设置

实施管理员同意流

查看基于风险的升级同意设置

参考

其他事件响应剧本

事件响应资源

反馈

其他资源