此页面由 Cloud Translation API 翻译。

调查和应对威胁

本文档提供了非正式指南，可帮助您调查 Google Cloud 环境中可能由潜在恶意行为者进行的可疑活动。本文档还提供了其他资源，可为 Security Command Center 的发现添加上下文。按照这些步骤操作有助于了解潜在攻击期间发生的情况，并为受影响的资源制定可行的响应措施。

本页面上中的技术不能保证对您之前、当前或未来面对的所有威胁有效。请参阅修复威胁，了解 Security Command Center 不针对威胁提供正式修复指导的原因。

准备工作

您需要具有足够的 Identity and Access Management (IAM) 角色才能查看或修改发现结果和日志以及修改 Google Cloud 资源。如果您在 Security Command Center 中遇到访问权限错误，请向您的管理员寻求帮助，并参阅访问权限控制以了解角色。如需解决资源错误，请参阅受影响产品的相关文档。

了解威胁发现结果

Event Threat Detection 通过将 Cloud Logging 日志流中的事件与已知违规线索 (IoC) 进行匹配，生成安全性发现结果。由内部 Google 安全来源开发的 IoC 可发现潜在漏洞和攻击。Event Threat Detection 还可识别日志流中的已知对抗策略、技术和流程，并检测与组织或项目过去的行为之间的偏差，来检测威胁。如果您在组织级层激活 Security Command Center 高级层级，Event Threat Detection 还可以扫描您的 Google Workspace 日志。

Container Threat Detection 通过收集和分析容器客机内核中观察到的低级行为来生成发现结果。

发现结果会被写入 Security Command Center。如果您在组织级层激活 Security Command Center 高级层级，还可以将发现结果配置为写入 Cloud Logging。

审核发现结果

如需在 Google Cloud 控制台中查看威胁发现结果，请按以下步骤操作：

在 Google Cloud 控制台中，转到 Security Command Center 发现结果页面。
转至“发现结果”
如有必要，请选择您的 Google Cloud 项目、文件夹或组织。
在快速过滤条件部分中，点击相应的过滤条件，以在发现结果的查询结果表中显示所需的发现结果。例如，如果您在来源显示名称子部分中选择 Event Threat Detection 或 Container Threat Detection，则结果中只会显示来自所选服务的发现结果。

该表会填充所选择来源的发现结果。
如需查看特定发现结果的详细信息，请点击 Category 下的发现结果名称。发现结果详情窗格会展开，以显示发现结果的详情摘要。
要查看发现结果的 JSON 定义，请点击 JSON 标签页。

发现结果提供了突发事件中包含的资源的名称和数字标识符，以及环境变量和资源属性。您可以使用此信息快速隔离受影响的资源并确定事件的潜在范围。

为了帮助您进行调查，威胁发现结果还包含指向以下外部资源的链接：

MITRE ATT&CK 框架条目。该框架解释了针对云资源的攻击伎俩，并提供修复指南。
VirusTotal，这是一项 Alphabet 自有服务，用于提供有关潜在恶意文件、网址、网域和 IP 地址的上下文。VirusTotal 指示器字段会提供指向 VirusTotal 的链接（如果有），以帮助您进一步调查潜在的安全问题。

VirusTotal 是单独付费的服务，具有不同的使用限制和功能。您有责任了解并遵守 VirusTotal 的 API 使用政策以及任何相关费用。如需了解详情，请参阅 VirusTotal 文档。

注意：VirusTotal 可能不包含所有恶意软件变体的哈希值。

以下部分概述了针对威胁发现结果的潜在响应。

停用威胁发现结果

解决触发威胁发现结果的问题后，Security Command Center 不会自动将发现结果的状态设置为 INACTIVE。除非您手动将 state 属性设置为 INACTIVE，否则威胁发现结果的状态会保留为 ACTIVE。

对于假正例，请考虑将发现结果的状态保留为 ACTIVE，而不是忽略发现结果。

对于持久或重复的假正例，请创建忽略规则。设置忽略规则可以减少需要管理的发现结果数量，从而可以更轻松地识别真正的威胁。

对于真正的威胁，请在将发现结果的状态设置为 INACTIVE 之前，消除威胁，并完成对检测到的威胁、入侵范围以及任何其他相关发现结果和问题的全面调查。

如需忽略发现结果或更改发现结果的状态，请参阅以下主题：

Event Threat Detection 响应

如需详细了解 Event Threat Detection，请参阅 Event Threat Detection 的工作原理。

本部分不包含由 Event Threat Detection 的自定义模块生成的发现结果的响应，因为您的组织定义了这些检测器的建议操作。

`Evasion: Access from Anonymizing Proxy`

通过检查源自匿名代理 IP 地址（例如 Tor IP 地址）的 Google Cloud 服务修改的 Cloud Audit Logs，检测匿名代理的异常访问。

如需响应这些发现结果，请执行以下操作：

第 1 步：查看发现结果详情

按照查看发现结果中所述，打开 Evasion: Access from Anonymizing Proxy 发现结果。系统会打开发现结果详情面板，其中显示了摘要标签页。
在发现结果详情面板的摘要标签页上，查看以下部分中列出的值：
- 检测到的内容，尤其是以下字段：
  - 主账号电子邮件地址：做出更改的账号（可能被盗用的账号）。
  - IP：从其中执行更改的代理 IP 地址。
- 受影响的资源
- 相关链接，尤其是以下字段：
  - Cloud Logging URI：指向 Logging 条目的链接。
  - MITRE ATT&CK 方法：指向 MITRE ATT&CK 文档的链接。
  - 相关发现结果：指向任何相关发现结果的链接。
（可选）点击 JSON 标签页可查看其他发现结果字段。

第 2 步：研究攻击和响应方法

查看此发现结果类型的 MITRE ATT&CK 框架条目：代理：多级代理。
在 principalEmail 字段中与账号所有者联系。确认该操作是否由合法所有者执行。
如需制定响应方案，请将您的调查结果与 MITRE 研究相结合。

`Defense Evasion: Breakglass Workload Deployment Created`

通过检查 Cloud Audit Logs 来确认是否有任何工作负载部署使用 Breakglass 标志覆盖 Binary Authorization 控制时，检测到 Breakglass Workload Deployment Created。

如需响应此发现结果，请执行以下操作：

第 1 步：查看发现结果详情

按照查看发现结果中所述，打开 Defense Evasion: Breakglass Workload Deployment Created 发现结果。系统会打开发现结果详情面板，其中显示了摘要标签页。
在摘要标签页上，查看以下部分中的信息：
- 检测到的内容，尤其是以下字段：
  - 主账号电子邮件地址：执行修改操作的账号。
  - 方法名称：所调用的方法。
  - Kubernetes Pod：Pod 名称和命名空间。
- 受影响的资源，尤其是以下字段：
  - 资源显示名称：部署所属的 GKE 命名空间。
- 相关链接：
  - Cloud Logging URI：指向 Logging 条目的链接。
  - MITRE ATT&CK 方法：指向 MITRE ATT&CK 文档的链接。
  - 相关发现结果：指向任何相关发现结果的链接。

第 2 步：检查日志

在 Google Cloud 控制台中发现结果详情的摘要标签页上，通过点击 Cloud Logging URI 字段中的链接转到日志浏览器。
查看 protoPayload.resourceName 字段中的值以识别特定的证书签名请求。
使用以下过滤条件检查主账号执行的其他操作：
- resource.labels.cluster_name="CLUSTER_NAME"
- protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"
  
  请替换以下内容：
- CLUSTER_NAME：您在发现结果详情的资源显示名称字段中记下的值。
- PRINCIPAL_EMAIL：您在发现结果详情的主账号电子邮件地址字段中记下的值。

第 3 步：研究攻击和响应方法

查看此发现结果类型的 MITRE ATT&CK 框架条目：防护规避：工作负载部署 Breakglass。
点击发现结果详情摘要标签页中相关发现结果行上的相关发现结果的链接，以查看相关发现结果。
如需制定响应方案，请将您的调查结果与 MITRE 研究相结合。

`Defense Evasion: Breakglass Workload Deployment Updated`

通过检查 Cloud Audit Logs 来确认是否有任何工作负载更新使用 Breakglass 标志覆盖 Binary Authorization 控制时，检测到 Breakglass Workload Deployment Updated。

如需响应此发现结果，请执行以下操作：

第 1 步：查看发现结果详情

按照查看发现结果中所述，打开 Defense Evasion: Breakglass Workload Deployment Updated 发现结果。系统会打开发现结果详情面板，其中显示了摘要标签页。
在摘要标签页上，查看以下部分中的信息：
- 检测到的内容，尤其是以下字段：
  - 主账号电子邮件地址：执行修改操作的账号。
  - 方法名称：所调用的方法。
  - Kubernetes Pod：Pod 名称和命名空间。
- 受影响的资源，尤其是以下字段：
  - 资源显示名称：更新所属的 GKE 命名空间。
- 相关链接：
  - Cloud Logging URI：指向 Logging 条目的链接。
  - MITRE ATT&CK 方法：指向 MITRE ATT&CK 文档的链接。
  - 相关发现结果：指向任何相关发现结果的链接。

第 2 步：检查日志

在 Google Cloud 控制台中发现结果详情的摘要标签页上，通过点击 Cloud Logging URI 字段中的链接转到日志浏览器。
查看 protoPayload.resourceName 字段中的值以识别特定的证书签名请求。
使用以下过滤条件检查主账号执行的其他操作：
- resource.labels.cluster_name="CLUSTER_NAME"
- protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"
  
  请替换以下内容：
- CLUSTER_NAME：您在发现结果详情的资源显示名称字段中记下的值。
- PRINCIPAL_EMAIL：您在发现结果详情的主账号电子邮件地址字段中记下的值。

第 3 步：研究攻击和响应方法

查看此发现结果类型的 MITRE ATT&CK 框架条目：防护规避：工作负载部署 Breakglass。
点击发现结果详情摘要标签页中相关发现结果行上的相关发现结果的链接，以查看相关发现结果。
如需制定响应方案，请将您的调查结果与 MITRE 研究相结合。

`Defense Evasion: Manually Deleted Certificate Signing Request (CSR)`

有人手动删除了证书签名请求 (CSR)。垃圾回收控制器会自动移除 CSR，但恶意行为者可能会手动删除 CSR 以逃避检测。如果已删除的 CSR 对应的是已获批准并已签发的证书，那么潜在恶意方现在可以使用另一种身份验证方法来访问集群。与证书关联的权限因包含的主题而异，但可能具有很高的权限。Kubernetes 不支持证书撤消。如需了解详情，请参阅此提醒的日志消息。

查看 Cloud Logging 中的审核日志和与此 CSR 相关的其他事件的更多提醒，以确定 CSR 是否已approved，以及 CSR 的创建是否是主账号执行的预期活动。
确定 Cloud Logging 的审核日志中是否存在主账号执行的其他恶意活动迹象。例如：
- 删除 CSR 的主账号是否与创建或批准 CSR 的主账号不同？
- 主账号是否尝试过请求、创建、批准或删除其他 CSR？
如果 CSR 审批不在预期之内，或者被认定为是恶意的，集群将需要进行凭据转换以使证书失效。请查看相关指南以了解如何执行集群凭据轮替。

`Defense Evasion: Modify VPC Service Control`

此发现结果不适用于项目级激活。

系统会检查审核日志，以检测 VPC Service Controls 边界上会导致该边界提供的保护减少的更改。下面列出了一些示例：

一个项目被从边界中移除
一个访问权限级别政策被添加到现有边界
一项或多项服务被添加到可访问服务列表中

如需响应此发现结果，请执行以下操作：

第 1 步：查看发现结果详情

按照查看发现结果中所述，打开 Defense Evasion: Modify VPC Service Control 发现结果。系统会打开发现结果详情面板，其中显示了摘要标签页。
在摘要标签页上，查看以下部分中的信息：
- 检测到的内容，尤其是以下字段：
  - 主账号电子邮件地址：执行修改操作的账号。
- 受影响的资源，尤其是以下字段：
  - 资源全名：修改的 VPC Service Controls 边界的名称。
- 相关链接：
  - Cloud Logging URI：指向 Logging 条目的链接。
  - MITRE ATT&CK 方法：指向 MITRE ATT&CK 文档的链接。
  - 相关发现结果：指向任何相关发现结果的链接。
点击 JSON 标签页。
在 JSON 中，记下以下字段。
- sourceProperties
  - properties
    - name：被修改的 VPC Service Controls 边界的名称
    - policyLink：用于控制该边界的访问权限政策的链接
    - delta：对边界做出的减少其保护的更改（REMOVE 或 ADD）
    - restricted_resources：遵循此边界限制的项目。如果您移除某个项目，则所受保护会减少
    - restricted_services：被此边界限制禁止运行的服务。如果您移除某个受限服务，则所受保护会减少
    - allowed_services：根据此边界限制允许运行的服务。如果您添加某个允许的服务，则所受保护会减少
    - access_levels：配置为允许访问边界下资源的访问权限级别。如果您添加更多访问权限级别，则所受保护会减少

第 2 步：检查日志

在发现结果详情面板的“摘要”标签页上，点击 Cloud Logging URI 链接以打开日志浏览器。
使用以下过滤条件查找与 VPC Service Controls 更改相关的管理员活动日志：
- protoPayload.methodName:"AccessContextManager.UpdateServicePerimeter"
- protoPayload.methodName:"AccessContextManager.ReplaceServicePerimeters"

第 3 步：研究攻击和响应方法

查看此发现结果类型的 MITRE ATT&CK 框架条目：防护规避：修改身份验证过程。
点击发现结果详情摘要标签页中相关发现结果行上的相关发现结果的链接，以查看相关发现结果。
如需制定响应方案，请将您的调查结果与 MITRE 研究相结合。

第 4 步：实现响应

以下响应方案可能适合此发现结果，但也可能会影响运营。请仔细评估您在研究中收集的信息，以确定解析发现结果的最佳方法。

联系 VPC Service Controls 政策和边界的所有者。
请考虑还原对边界所做的更改，直到调查完成。
请考虑撤消对边界做出修改的主账号上的 Access Context Manager 角色，直到调查完成。
调查减少的保护措施的使用方式。例如，如果启用了“BigQuery Data Transfer Service API”或将其添加为允许的服务，请检查最开始使用该服务的用户及其转移的内容。

`Defense Evasion: Potential Kubernetes Pod Masquerading`

有人部署了一个 Pod，其命名惯例与 GKE 为常规集群操作创建的默认工作负载类似。这种技术称为“伪装”。如需了解详情，请参阅此提醒的日志消息。

确认 Pod 是合法的。
确定 Cloud Logging 的审核日志中是否存在来自 Pod 或主账号的其他恶意活动迹象。
如果主账号不是服务账号（IAM 或 Kubernetes），请与该账号的所有者联系，以确认合法所有者是否执行了相应操作。
如果主账号是服务账号（IAM 或 Kubernetes），请查明操作来源以确定其合法性。
如果 Pod 不合法，请将其移除，同时移除任何关联的 RBAC 绑定，以及工作负载使用的和允许其创建的服务账号。

`Discovery: Can get sensitive Kubernetes object check`

潜在恶意操作者尝试使用 kubectl auth can-i get 命令确定可以查询 GKE 中的哪些敏感对象。具体来说，操作者运行了以下任何命令：

kubectl auth can-i get '*'
kubectl auth can-i get secrets
kubectl auth can-i get clusterroles/cluster-admin

第 1 步：查看发现结果详情

按照查看发现结果中所述，打开 Discovery: Can get sensitive Kubernetes object check 发现结果。
在发现结果详情的摘要标签页上，记下以下字段的值：
- 在检测到的内容下：
  - Kubernetes 访问权限审核：基于 SelfSubjectAccessReview k8s 资源的请求访问权限审核信息。
  - 主账号电子邮件地址：发出调用的账号。
- 在受影响的资源下：
  - 资源显示名称：执行操作的 Kubernetes 集群。
- 在相关链接下：
  - Cloud Logging URI：指向 Logging 条目的链接。

第 2 步：检查日志

在发现结果详情面板的“摘要”标签页上，点击 Cloud Logging URI 链接以打开日志浏览器。
在加载的页面上，使用以下过滤条件检查主账号执行的其他操作：
- resource.labels.cluster_name="CLUSTER_NAME"
- protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"
  
  请替换以下内容：
- CLUSTER_NAME：您在发现结果详情的资源显示名称字段中记下的值。
- PRINCIPAL_EMAIL：您在发现结果详情的主账号电子邮件地址字段中记下的值。

第 3 步：研究攻击和响应方法

查看此发现结果类型的 MITRE ATT&CK 框架条目：探索
确认所查询对象的敏感度，并确定日志中是否存在主账号执行的其他恶意活动迹象。
如果您在发现结果详情的主账号电子邮件地址行中记下的账号不是服务账号，请与该账号所有者联系以确认合法所有者是否执行了该操作。

如果主账号电子邮件地址是服务账号（IAM 或 Kubernetes），请查明访问权限审核的来源以确定其合法性。
如需制定响应方案，请将您的调查结果与 MITRE 研究相结合。

`Execution: Kubernetes Pod Created with Potential Reverse Shell Arguments`

有人创建了一个 pod，其中包含通常与反向 shell 相关联的命令或参数。攻击者使用反向 shell 来扩大或维持对集群的初始访问权限，并执行任意命令。如需了解详情，请参阅此提醒的日志消息。

确认 Pod 有正当理由指定这些命令和参数。
确定 Cloud Logging 的审核日志中是否存在来自 Pod 或主账号的其他恶意活动迹象。
如果主账号不是服务账号（IAM 或 Kubernetes），请与该账号的所有者联系，以确认合法所有者是否执行了相应操作。
如果主账号是服务账号（IAM 或 Kubernetes），请查明是什么导致服务账号执行此操作及其合法性
如果 Pod 不合法，请将其移除，同时移除任何关联的 RBAC 绑定，以及工作负载使用的和允许其创建的服务账号。

`Execution: Suspicious Exec or Attach to a System Pod`

有人使用 exec 或 attach 命令获取 shell，或在 kube-system 命名空间中运行的容器上执行命令。这些方法有时会用于合法的调试目的。不过，kube-system namespace 适用于由 Kubernetes 创建的系统对象，因此应审核意外的命令执行或 shell 创建。如需了解详情，请参阅此提醒的日志消息。

查看 Cloud Logging 中的审核日志，以确定这是否是主账号执行的预期活动。
确定日志中是否存在主账号的其他恶意活动迹象。

`Exfiltration: BigQuery Data Exfiltration`

Exfiltration: BigQuery Data Exfiltration 返回的发现结果包含两条可能的子规则之一。每条子规则的严重级别各不相同：

严重程度为 HIGH 的子规则 exfil_to_external_table：
- 资源保存在您的组织或项目外部。
严重程度为 LOW 的子规则 vpc_perimeter_violation：
- VPC Service Controls 阻止了复制操作或尝试访问 BigQuery 资源。

如需响应此发现结果，请执行以下操作：

第 1 步：查看发现结果详情

按照查看发现结果中所述，打开 Exfiltration: BigQuery Data Exfiltration 发现结果。
在发现结果详情面板的摘要标签页上，查看以下部分中列出的值：
- 检测到的内容：
  - 严重级别：对于子规则 exfil_to_external_table，严重级别为 HIGH；对于子规则 vpc_perimeter_violation，严重级别为 LOW。
  - 主账号电子邮件地址：用于渗漏数据的账号。
  - 渗漏来源：有关从其中渗漏数据的表的详细信息。
  - 渗漏目标：有关在其中存储渗漏数据的表的详细信息。
- 受影响的资源：
  - 资源全名：从其中渗漏数据的项目、文件夹或组织的完整资源名称。
- 相关链接：
  - Cloud Logging URI：指向 Logging 条目的链接。
  - MITRE ATT&CK 方法：指向 MITRE ATT&CK 文档的链接。
  - 相关发现结果：指向任何相关发现结果的链接。
  - Google Security Operations：指向 Google SecOps 的链接。
点击来源属性标签页，然后查看显示的字段，尤其是：
- detectionCategory：
  - subRuleName：exfil_to_external_table 或 vpc_perimeter_violation。
- evidence：
  - sourceLogId：
    - projectId：包含来源 BigQuery 数据集的 Google Cloud 项目。
- properties
  - dataExfiltrationAttempt
    - jobLink：指向渗漏数据的 BigQuery 作业的链接。
    - query：在 BigQuery 数据集上运行的 SQL 查询。
您可以选择点击 JSON 标签页，查看发现结果的 JSON 属性的完整列表。

第 2 步：在 Google Security Operations 中了解情况

您可以使用 Google Security Operations 来调查此发现结果。Google SecOps 是一项 Google Cloud 服务，可让您以统一的时间调查威胁并透视相关实体。Google SecOps 会丰富发现结果数据，以便您识别感兴趣的指标并简化调查。

只有在组织级层激活 Security Command Center 后，您才能使用 Google SecOps。

转到 Google Cloud 控制台中的 Security Command Center 发现结果页面。

转至“发现结果”
在快速过滤条件面板中，向下滚动到来源显示名称。
在来源显示名称部分中，选择 Event Threat Detection。

该表会填充 Event Threat Detection 的发现结果。
在表中的类别下方，点击 Exfiltration: BigQuery Data Exfiltration 发现结果。系统会打开发现结果详情面板。
在发现结果详情面板的相关链接部分中，点击在 Google 安全运营中心进行调查。
按照 Google SecOps 指导的界面中的说明操作。

以下指南介绍了如何在 Google SecOps 中进行调查：

第 3 步：查看权限和设置

在 Google Cloud 控制台中，转到 IAM 页面。

转到 IAM
如有必要，请选择发现结果 JSON 中的 projectId 字段中列出的项目。
在显示的页面上的过滤条件框中，输入主账号电子邮件地址中列出的电子邮件地址，并检查为该账号分配了哪些权限。

第 4 步：检查日志

在发现结果详情面板的“摘要”标签页上，点击 Cloud Logging URI 链接以打开日志浏览器。
使用以下过滤条件查找与 BigQuery 作业相关的管理员活动日志：
- protoPayload.methodName="Jobservice.insert"
- protoPayload.methodName="google.cloud.bigquery.v2.JobService.InsertJob"

第 5 步：研究攻击和响应方法

查看此发现结果类型的 MITRE ATT&CK 框架条目：Web 服务渗漏：渗漏到 Cloud Storage。
点击发现结果详情摘要标签页中相关发现结果行上的相关发现结果的链接，以查看相关发现结果。相关发现结果属于同一实例和网络上的同一发现结果类型。
如需制定响应方案，请将您的调查结果与 MITRE 研究相结合。

第 6 步：实现响应

以下响应方案可能适合此发现结果，但也可能会影响运营。请仔细评估您在研究中收集的信息，以确定解析发现结果的最佳方法。

与数据被渗漏的项目的所有者联系。
在调查完成之前，请考虑撤消权限（针对 userEmail）。
如需停止进一步的渗漏，请为受影响的 BigQuery 数据集（exfiltration.sources 和 exfiltration.targets）添加严格的 IAM 政策。
如需扫描受影响的数据集是否存在敏感信息，请使用敏感数据保护。您还可以将敏感数据保护数据发送到 Security Command Center。敏感数据保护费用可能相当大，具体取决于信息的数量。请遵循控制敏感数据保护费用的最佳实践。
如需限制对 BigQuery API 的访问权限，请使用 VPC Service Controls。
如需识别并修正过于宽松的角色，请使用 IAM Recommender。

`Exfiltration: BigQuery Data Extraction`

您可以通过检查以下两种场景的审核日志来检测 BigQuery 中的数据渗漏：

资源会保存到组织外部的 Cloud Storage 存储桶中。
资源会保存到您的组织拥有的可公开访问的 Cloud Storage 存储桶中。

对于 Security Command Center 高级层级的项目级激活，此发现结果仅在父级组织中启用了标准层级时才可用。

如需响应此发现结果，请执行以下操作：

第 1 步：查看发现结果详情

按照查看发现结果中所述，打开 Exfiltration: BigQuery Data Extraction 发现结果。系统会打开发现结果详情面板，以显示摘要标签页。
在发现结果详情面板的摘要标签页上，查看以下部分中列出的值：
- 检测到的内容：
  - 主账号电子邮件地址：用于渗漏数据的账号。
  - 渗漏来源：有关从其中渗漏数据的表的详细信息。
  - 渗漏目标：有关在其中存储渗漏数据的表的详细信息。
- 受影响的资源：
  - 资源全名：渗漏其数据的 BigQuery 资源的名称。
  - 项目全名：包含来源 BigQuery 数据集的 Google Cloud 项目。
- 相关链接：
  - Cloud Logging URI：指向 Logging 条目的链接。
  - MITRE ATT&CK 方法：指向 MITRE ATT&CK 文档的链接。
  - 相关发现结果：指向任何相关发现结果的链接。
在发现结果详情面板中，点击 JSON 标签页。
在 JSON 中，记下以下字段。
- sourceProperties：
  - evidence：
    - sourceLogId：
    - projectId：包含来源 BigQuery 数据集的 Google Cloud 项目。
  - properties：
    - extractionAttempt：
    - jobLink：指向渗漏数据的 BigQuery 作业的链接

第 2 步：查看权限和设置

在 Google Cloud 控制台中，转到 IAM 页面。

转到 IAM
如有必要，请选择发现结果 JSON 的 projectId 字段中列出的项目（来自第 1 步）。
在显示的页面上的过滤条件框中，输入主账号电子邮件地址中列出的电子邮件地址（来自第 1 步），并检查为该账号分配了哪些权限。

第 3 步：检查日志

在发现结果详情面板的“摘要”标签页上，点击 Cloud Logging URI 链接以打开日志浏览器。
使用以下过滤条件查找与 BigQuery 作业相关的管理员活动日志：
- protoPayload.methodName="Jobservice.insert"
- protoPayload.methodName="google.cloud.bigquery.v2.JobService.InsertJob"

第 4 步：研究攻击和响应方法

查看此发现结果类型的 MITRE ATT&CK 框架条目：Web 服务渗漏：渗漏到 Cloud Storage。
点击发现结果详情摘要标签页中相关发现结果行上的链接，以查看相关发现结果。相关发现结果属于同一实例和网络上的同一发现结果类型。
如需制定响应方案，请将您的调查结果与 MITRE 研究相结合。

第 5 步：实现响应

以下响应方案可能适合此发现结果，但也可能会影响运营。请仔细评估您在研究中收集的信息，以确定解析发现结果的最佳方法。

与数据被渗漏的项目的所有者联系。
在调查完成之前，考虑对发现结果详情摘要标签页中主账号电子邮件地址行上列出的主账号撤消权限。
如需阻止进一步的渗漏，请为发现结果详情摘要标签页上渗漏来源字段中标识的受影响的 BigQuery 数据集添加严格的 IAM 政策。
如需扫描受影响的数据集是否存在敏感信息，请使用敏感数据保护。您还可以将敏感数据保护数据发送到 Security Command Center。敏感数据保护费用可能相当大，具体取决于信息的数量。请遵循控制敏感数据保护费用的最佳实践。
如需限制对 BigQuery API 的访问权限，请使用 VPC Service Controls。
如果您是存储桶的所有者，请考虑撤消公开访问权限。
如需识别并修正过于宽松的角色，请使用 IAM Recommender。

`Exfiltration: BigQuery Data to Google Drive`

通过检查以下场景中的审核日志，检测到来自 BigQuery 的数据渗漏：

资源会保存到 Google 云端硬盘文件夹中。

如需响应此发现结果，请执行以下操作：

第 1 步：查看发现结果详情

按照查看发现结果中所述，打开 Exfiltration: BigQuery Data to Google Drive 发现结果。
在发现结果详情面板的摘要标签页上，查看以下部分中的信息：
- 检测到的内容，其中包括：
  - 主账号电子邮件地址：用于渗漏数据的账号。
  - 渗漏来源：有关从其中渗漏数据的 BigQuery 表的详细信息。
  - 渗漏目标：有关 Google 云端硬盘中的目标位置的详细信息。
- 受影响的资源，其中包括：
  - 资源全名：渗漏其数据的 BigQuery 资源的名称。
  - 项目全名：包含来源 BigQuery 数据集的 Google Cloud 项目。
- 相关链接，其中包括：
  - Cloud Logging URI：指向 Logging 条目的链接。
  - MITRE ATT&CK 方法：指向 MITRE ATT&CK 文档的链接。
  - 相关发现结果：指向任何相关发现结果的链接。
如需了解详情，请点击 JSON 标签页。
在 JSON 中，记下以下字段。
- sourceProperties：
  - evidence：
    - sourceLogId：
    - projectId：包含来源 BigQuery 数据集的 Google Cloud 项目。
  - properties：
    - extractionAttempt：
    - jobLink：指向渗漏数据的 BigQuery 作业的链接

第 2 步：查看权限和设置

在 Google Cloud 控制台中，转到 IAM 页面。

转到 IAM
如有必要，请选择发现结果 JSON 的 projectId 字段中列出的项目（来自第 1 步）。
在显示的页面上的过滤条件框中，输入 access.principalEmail 中列出的电子邮件地址（来自第 1 步），并检查为该账号分配了哪些权限。

第 3 步：检查日志

在发现结果详情面板的“摘要”标签页上，点击 Cloud Logging URI 链接以打开日志浏览器。
使用以下过滤条件查找与 BigQuery 作业相关的管理员活动日志：
- protoPayload.methodName="Jobservice.insert"
- protoPayload.methodName="google.cloud.bigquery.v2.JobService.InsertJob"

第 4 步：研究攻击和响应方法

查看此发现结果类型的 MITRE ATT&CK 框架条目：Web 服务渗漏：渗漏到 Cloud Storage。
点击发现结果详情摘要标签页中相关发现结果行上的相关发现结果的链接，以查看相关发现结果。相关发现结果属于同一实例和网络上的同一发现结果类型。
如需制定响应方案，请将您的调查结果与 MITRE 研究相结合。

第 5 步：实现响应

以下响应方案可能适合此发现结果，但也可能会影响运营。请仔细评估您在研究中收集的信息，以确定解析发现结果的最佳方法。

与数据被渗漏的项目的所有者联系。
请考虑在 access.principalEmail 字段中撤消主账号的权限，直到调查完成。
如需停止进一步的渗漏，请为受影响的 BigQuery 数据集 (exfiltration.sources) 添加严格的 IAM 政策。
如需扫描受影响的数据集是否存在敏感信息，请使用敏感数据保护。您还可以将敏感数据保护数据发送到 Security Command Center。敏感数据保护费用可能相当大，具体取决于信息的数量。请遵循控制敏感数据保护费用的最佳实践。
如需限制对 BigQuery API 的访问权限，请使用 VPC Service Controls。
如需识别并修正过于宽松的角色，请使用 IAM Recommender。

`Exfiltration: Cloud SQL Data Exfiltration`

您可以通过检查以下两种场景的审核日志来检测 Cloud SQL 中的数据渗漏：

活动实例数据导出到组织外部的 Cloud Storage 存储桶。
活动实例数据导出到组织拥有且可公开访问的 Cloud Storage 存储桶。

支持所有 Cloud SQL 实例类型。

对于 Security Command Center 高级层级的项目级激活，此发现结果仅在父级组织中启用了标准层级时才可用。

如需响应此发现结果，请执行以下操作：

第 1 步：查看发现结果详情

按照查看发现结果中所述，打开 Exfiltration: Cloud SQL Data Exfiltration 发现结果。系统会打开发现结果详情面板，以显示摘要标签页。
在摘要标签页上，查看以下部分中的信息：
- 检测到的内容，尤其是以下字段：
  - 主账号电子邮件地址：用于渗漏数据的账号。
  - 渗漏来源：有关渗漏其数据的 Cloud SQL 实例的详细信息。
  - 渗漏目标：有关数据导出到的 Cloud Storage 存储桶的详细信息。
- 受影响的资源，尤其是以下字段：
  - 资源全名：渗漏其数据的 Cloud SQL 资源的名称。
  - 项目全名：包含来源 Cloud SQL 数据的 Google Cloud 项目。
- 相关链接，其中包括：
  - Cloud Logging URI：指向 Logging 条目的链接。
  - MITRE ATT&CK 方法：指向 MITRE ATT&CK 文档的链接。
  - 相关发现结果：指向任何相关发现结果的链接。
点击 JSON 标签页。
在相应发现结果的 JSON 中，记下以下字段：
- sourceProperties：
  - evidence：
  - sourceLogId：
    - projectId：包含源 Cloud SQL 实例的 Google Cloud 项目。
  - properties
  - bucketAccess：Cloud Storage 存储桶是可公开访问的，还是在组织外部
  - exportScope：导出的数据量，例如整个实例、一个或多个数据库、一个或多个表，或由查询指定的子集

第 2 步：查看权限和设置

在 Google Cloud 控制台中，转到 IAM 页面。

转到 IAM
如有必要，请选择发现结果 JSON 中的 projectId 字段中列出的实例的项目（来自第 1 步）。
在显示的页面上的过滤条件框中，输入发现结果详情摘要标签页中主账号电子邮件地址行上列出的电子邮件地址（来自第 1 步）。检查为该账号分配了哪些权限。

第 3 步：检查日志

在 Google Cloud 控制台中，点击 Cloud Logging URI 中的链接（来自第 1 步），以前往日志浏览器。日志浏览器页面包含与相关 Cloud SQL 实例有关的所有日志。

第 4 步：研究攻击和响应方法

查看此发现结果类型的 MITRE ATT&CK 框架条目：Web 服务渗漏：渗漏到 Cloud Storage。
点击第 1 步中所述的相关发现结果行上的链接，以查看相关发现结果。相关发现结果在同一 Cloud SQL 实例上具有相同的发现结果类型。
如需制定响应方案，请将您的调查结果与 MITRE 研究相结合。

第 5 步：实现响应

以下响应方案可能适合此发现结果，但也可能会影响运营。请仔细评估您在研究中收集的信息，以确定解析发现结果的最佳方法。

与数据被渗漏的项目的所有者联系。
在调查完成之前，请考虑撤消权限（针对 access.principalEmail）。
如需防止进一步渗漏，请向受影响的 Cloud SQL 实例添加严格的 IAM 政策。
要限制针对 Cloud SQL Admin API 的访问和导出，请使用 VPC Service Controls。
如需识别并修正过于宽松的角色，请使用 IAM Recommender。

`Exfiltration: Cloud SQL Restore Backup to External Organization`

通过检查审核日志以确定备份中的数据是否已恢复到组织或项目外部的 Cloud SQL 实例，可检测 Cloud SQL 备份中的数据渗漏。支持所有 Cloud SQL 实例和备份类型。

如需响应此发现结果，请执行以下操作：

第 1 步：查看发现结果详情

按照查看发现结果中所述，打开 Exfiltration: Cloud SQL Restore Backup to External Organization 发现结果。
在发现结果详情面板的摘要标签页上，查看以下部分中的信息：
- 检测到的内容，尤其是以下字段：
  - 主账号电子邮件地址：用于渗漏数据的账号。
  - 渗漏来源：有关通过其创建备份的 Cloud SQL 实例的详细信息。
  - 渗漏目标：有关备份数据恢复到的 Cloud SQL 实例的详细信息。
- 受影响的资源，尤其是以下字段：
  - 资源全名：已恢复的备份的资源名称。
  - 项目全名：包含通过其创建备份的 Cloud SQL 实例的 Google Cloud 项目。
相关链接，尤其是以下字段：
- Cloud Logging URI：指向 Logging 条目的链接。
- MITRE ATT&CK 方法：指向 MITRE ATT&CK 文档的链接。
- 相关发现结果：指向任何相关发现结果的链接。
点击 JSON 标签页。
在 JSON 中，记下以下字段。
- resource：
  - parent_name：从其创建备份的 Cloud SQL 实例的资源名称
- evidence：
  - sourceLogId：
    - projectId：包含来源 BigQuery 数据集的 Google Cloud 项目。
- properties：
  - restoreToExternalInstance：
    - backupId：已恢复的备份作业的 ID

第 2 步：查看权限和设置

在 Google Cloud 控制台中，转到 IAM 页面。

转到 IAM
如有必要，请选择发现结果 JSON 的 projectId 字段中列出的实例的项目（来自第 1 步）。
在显示的页面上的过滤条件框中，输入主账号电子邮件地址中列出的电子邮件地址（来自第 1 步），并检查为该账号分配了哪些权限。

第 3 步：检查日志

在 Google Cloud 控制台中，点击 Cloud Logging URI 中的链接（来自第 1 步），以前往日志浏览器。日志浏览器页面包含与相关 Cloud SQL 实例有关的所有日志。

第 4 步：研究攻击和响应方法

查看此发现结果类型的 MITRE ATT&CK 框架条目：Web 服务渗漏：渗漏到 Cloud Storage。
点击相关发现结果行上的链接，以查看相关发现结果。（来自第 1 步）。相关发现结果在同一 Cloud SQL 实例上具有相同的发现结果类型。
如需制定响应方案，请将您的调查结果与 MITRE 研究相结合。

第 5 步：实现响应

以下响应方案可能适合此发现结果，但也可能会影响运营。请仔细评估您在研究中收集的信息，以确定解析发现结果的最佳方法。

与数据被渗漏的项目的所有者联系。
在调查完成之前，考虑对发现结果详情摘要标签页中主账号电子邮件地址行上列出的主账号撤消权限。
如需防止进一步渗漏，请向受影响的 Cloud SQL 实例添加严格的 IAM 政策。
如需限制对 Cloud SQL Admin API 的访问，请使用 VPC Service Controls。
如需识别并修正过于宽松的角色，请使用 IAM Recommender。

`Exfiltration: Cloud SQL Over-Privileged Grant`

检测将 PostgreSQL 数据库（或数据库中的所有函数或过程）的所有权限授予一个或多个数据库用户的情况。

如需响应此发现结果，请执行以下操作：

第 1 步：查看发现结果详情

按照查看发现结果中所述，打开 Exfiltration: Cloud SQL Over-Privileged Grant 发现结果。
在发现结果详情面板的摘要标签页上，查看以下部分中的信息：
- 检测到的内容，尤其是以下字段：
  - 数据库显示名称：受影响的 Cloud SQL PostgreSQL 实例中的数据库的名称。
  - 数据库用户名：授予超额权限的 PostgreSQL 用户。
  - 数据库查询：授予权限所执行的 PostgreSQL 查询。
  - 数据库授权对象：超额权限的授权对象。
- 受影响的资源，尤其是以下字段：
  - 资源全名：受影响的 Cloud SQL PostgreSQL 实例的资源名称。
  - 父级全名：Cloud SQL PostgreSQL 实例的资源名称。
  - 项目全名：包含 Cloud SQL PostgreSQL 实例的 Google Cloud 项目。
- 相关链接，尤其是以下字段：
  - Cloud Logging URI：指向 Logging 条目的链接。
  - MITRE ATT&CK 方法：指向 MITRE ATT&CK 文档的链接。
  - 相关发现结果：指向任何相关发现结果的链接。
如需查看发现结果的完整 JSON，请点击 JSON 标签页。

第 2 步：查看数据库权限

连接到 PostgreSQL 数据库。
为以下对象列出并显示访问权限：
- 数据库。使用 \l 或 \list 元命令，检查为数据库显示名称中列出的数据库（来自第 1 步）分配了哪些权限。
- 函数或过程。使用 \df 元命令，检查为数据库显示名称中列出的数据库（来自第 1 步）中的函数或过程分配了哪些权限。

第 3 步：检查日志

在 Google Cloud 控制台中，点击 Cloud Logging URI 中的链接（来自第 1 步），以前往日志浏览器。日志浏览器页面包含与相关 Cloud SQL 实例有关的所有日志。
在日志浏览器中，使用以下过滤条件检查 PostgreSQL pgaudit 日志，其中记录了对数据库执行的查询：
- protoPayload.request.database="var class="edit">database"

第 4 步：研究攻击和响应方法

查看此发现结果类型的 MITRE ATT&CK 框架条目： Web 服务渗漏。
如需确定是否需要执行额外的补救步骤，请将您的调查结果与 MITRE 研究相结合。

第 5 步：实现响应

以下响应方案可能适合此发现结果，但也可能会影响运营。请仔细评估您在研究中收集的信息，以确定解析发现结果的最佳方法。

与过度授予权限的实例的所有者联系。
在调查完成之前，考虑撤消数据库授权对象中列出的授权对象的所有权限。
如需限制对数据库（来自第 1 步的数据库显示名称）的访问权限，请撤消第 1 步的授权对象（来自数据库授权对象）的不必要的权限。

`Initial Access: Database Superuser Writes to User Tables`

检测 Cloud SQL 数据库超级用户账号（对 PostgreSQL 来说是 postgres，对 MySQL 来说是 root）何时写入用户表。超级用户（具有非常广泛访问权限的角色）通常不应用于向用户表写入数据。拥有受限程度更严格的访问权限的用户账号应用于每日的常规活动。当超级用户向用户表写入数据时，这可能表示攻击者提升了特权或者伪装成默认数据库用户，并且正在修改数据。它也可能仅表示正常但不安全的做法。

如需响应此发现结果，请执行以下操作：

第 1 步：查看发现结果详情

按照查看发现结果中所述，打开 Initial Access: Database Superuser Writes to User Tables 发现结果。
在发现结果详情面板的摘要标签页上，查看以下部分中的信息：
- 检测到的内容，尤其是以下字段：
  - 数据库显示名称：受影响的 Cloud SQL PostgreSQL 或 MySQL 实例中的数据库的名称。
  - 数据库用户名：超级用户。
  - 数据库查询：写入用户表时执行的 SQL 查询。
- 受影响的资源，尤其是以下字段：
  - 资源全名：受影响的 Cloud SQL 实例的资源名称。
  - 父级完整名称：Cloud SQL 实例的资源名称。
  - 项目全名：包含 Cloud SQL 实例的 Google Cloud 项目。
- 相关链接，尤其是以下字段：
  - Cloud Logging URI：指向 Logging 条目的链接。
  - MITRE ATT&CK 方法：指向 MITRE ATT&CK 文档的链接。
  - 相关发现结果：指向任何相关发现结果的链接。
如需查看发现结果的完整 JSON，请点击 JSON 标签页。

第 2 步：检查日志

在 Google Cloud 控制台中，点击 cloudLoggingQueryURI（第 1 步）中的链接，以转到日志浏览器。日志浏览器页面包含与相关 Cloud SQL 实例有关的所有日志。
使用以下过滤条件检查 PostgreSQL pgaudit 日志或 Cloud SQL for MySQL 审核日志，其中包含超级用户执行的查询：
- protoPayload.request.user="SUPERUSER"

第 3 步：研究攻击和响应方法

查看此发现结果类型的 MITRE ATT&CK 框架条目： Web 服务渗漏。
如需确定是否需要执行额外的补救步骤，请将您的调查结果与 MITRE 研究相结合。

第 4 步：实现响应

以下响应方案可能适合此发现结果，但也可能会影响运营。请仔细评估您在研究中收集的信息，以确定解析发现结果的最佳方法。

查看允许连接到数据库的用户。
- 对于 PostgreSQL，请参阅创建和管理用户
- 对于 MySQL，请参阅使用内置身份验证管理用户
考虑更改超级用户的密码。
- 对于 PostgreSQL，请参阅为默认用户设置密码
- 对于 MySQL，请参阅为默认用户设置密码
考虑为实例上使用的不同类型的查询创建新的受限访问权限用户。
- 仅向新用户授予执行其查询所需的必要权限。
  - 对于 PostgreSQL，请参阅 Grant（命令）
  - 对于 MySQL，请参阅访问权限控制和账号管理
- 更新连接到 Cloud SQL 实例的客户端的凭据

`Initial Access: Anonymous GKE resource created from the internet`

检测潜在的恶意操作者何时使用以下 Kubernetes 默认用户或用户群组之一在集群中创建了新的 Kubernetes 资源：

system:anonymous
system:authenticated
system:unauthenticated

这些用户和群组实际上是匿名的。集群中的基于角色的访问权限控制 (RBAC) 绑定向该用户授予了在集群中创建这些资源的权限。

查看创建的资源和关联的 RBAC 绑定，确保该绑定是必要的。如果不需要该绑定，请将其移除。如需了解详情，请参阅此发现结果对应的日志消息。

如需缓解此问题，请参阅避免使用默认角色和群组。

`Initial Access: GKE resource modified anonymously from the internet`

检测潜在的恶意操作者何时使用以下 Kubernetes 默认用户或用户组之一修改集群中的 Kubernetes 资源：

system:anonymous
system:authenticated
system:unauthenticated

这些用户和群组实际上是匿名的。集群中的基于角色的访问控制 (RBAC) 绑定向该用户授予了修改集群中这些资源的权限。

查看修改后的资源和关联的 RBAC 绑定，确保该绑定是必要的。如果不需要该绑定，请将其移除。如需了解详情，请参阅此发现结果对应的日志消息。

如需缓解此问题，请参阅避免使用默认角色和群组。

`Initial Access: Dormant Service Account Action`

检测处于休眠状态用户管理的服务账号触发了操作的事件。在此上下文中，如果服务账号处于非活跃状态超过 180 天，则会被视为休眠。

如需响应此发现结果，请执行以下操作：

第 1 步：查看发现结果详情

按照查看发现结果中所述，打开 Initial Access: Dormant Service Account Action 发现结果。
在发现结果详情的摘要标签页上，记下以下字段的值。

在检测到的内容下：
- 主账号电子邮件地址：执行操作的休眠服务账号
- 服务名称：服务账号访问的 Google Cloud 服务的 API 名称
- 方法名称：所调用的方法

第 2 步：研究攻击和响应方法

使用服务账号工具（如活动分析器）调查休眠服务账号的活动。
在主账号电子邮件地址字段中与服务账号的所有者联系。确认合法所有者是否执行了此操作。

第 3 步：实现响应

以下响应方案可能适合此发现结果，但也可能会影响运营。请仔细评估您在研究中收集的信息，以确定解析发现结果的最佳方法。

与执行操作的项目的所有者联系。
考虑删除可能被盗用的服务账号，然后轮替和删除可能被破解的项目的所有服务账号访问密钥。删除后，使用该服务账号进行身份验证的应用会失去访问权限。在继续操作之前，您的安全团队应确定所有受影响的应用并与应用所有者合作，以确保业务连续性。
与您的安全团队合作，确定不熟悉的资源，包括 Compute Engine 实例、快照、服务账号和 IAM 用户。删除未使用已获授权的账号创建的资源。
回复来自 Google Cloud 支持的任何通知。
如需限制谁可以创建服务账号，请使用组织政策服务。
如需识别并修正过于宽松的角色，请使用 IAM Recommender。

`Initial Access: Dormant Service Account Key Created`

检测创建了休眠的用户管理的服务账号密钥的事件。在此上下文中，如果服务账号处于非活跃状态超过 180 天，则会被视为休眠。

如需响应此发现结果，请执行以下操作：

第 1 步：查看发现结果详情

按照查看发现结果中所述，打开 Initial Access: Dormant Service Account Key Created 发现结果。
在发现结果详情的摘要标签页上，记下以下字段的值。

在检测到的内容下：
- 主账号电子邮件地址：创建服务账号密钥的用户
在受影响的资源下：
- 资源显示名：新创建的休眠服务账号密钥
- 项目全名：休眠服务账号所在的项目

第 2 步：研究攻击和响应方法

使用服务账号工具（如活动分析器）调查休眠服务账号的活动。
与主账号电子邮件地址字段的所有者联系。确认合法所有者是否执行了此操作。

第 3 步：实现响应

以下响应方案可能适合此发现结果，但也可能会影响运营。请仔细评估您在研究中收集的信息，以确定解析发现结果的最佳方法。

与执行操作的项目的所有者联系。
如果主账号电子邮件地址被盗用，请移除其所有者的访问权限。
在“服务账号”页面中使新创建的服务账号密钥失效。
考虑删除可能被盗用的服务账号，然后轮替和删除可能被破解的项目的所有服务账号访问密钥。删除后，使用该服务账号进行身份验证的应用会失去访问权限。在继续操作之前，您的安全团队应确定所有受影响的应用并与应用所有者合作，以确保业务连续性。
与您的安全团队合作，确定不熟悉的资源，包括 Compute Engine 实例、快照、服务账号和 IAM 用户。删除未使用已获授权的账号创建的资源。
响应来自 Cloud Customer Care 的任何通知。
如需限制谁可以创建服务账号，请使用组织政策服务。
如需识别并修正过于宽松的角色，请使用 IAM Recommender。

`Initial Access: Leaked Service Account Key Used`

检测使用泄露的服务账号密钥对操作进行身份验证的事件。在此情况下，泄露的服务账号密钥是发布到公共互联网上的密钥。例如，服务账号密钥通常错误地发布到公共 GitHub 代码库中。

如需响应此发现结果，请执行以下操作：

第 1 步：查看发现结果详情

按照查看发现结果中所述，打开 Initial Access: Leaked Service Account Key Used 发现结果。
在发现结果详情的摘要标签页上，记下以下字段的值。

在检测到的内容下：
- 主账号电子邮件地址：此操作中使用的服务账号
- 服务名称：服务账号访问的 Google Cloud 服务的 API 名称
- 方法名称：操作的方法名称
- 服务账号密钥名称：用于对此操作进行身份验证的泄露的服务账号密钥
- 说明：有关检测到的内容的说明，包括公共互联网上服务账号密钥的位置
在受影响的资源下：
- 资源显示名称：操作中涉及的资源

第 2 步：检查日志

在 Google Cloud 控制台中，点击 Cloud Logging URI 中的链接，以前往日志浏览器。
在 Google Cloud 控制台工具栏中，选择您的项目或组织。
在加载的页面上，使用以下过滤条件查找相关日志：
- protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"
- protoPayload.authenticationInfo.serviceAccountKeyName="SERVICE_ACCOUNT_KEY_NAME"
将 PRINCIPAL_EMAIL 替换为您在发现结果详情的主账号电子邮件地址字段中记录的值。将 SERVICE_ACCOUNT_KEY_NAME 替换为您在发现结果详细信息的服务账号密钥名称字段中记下的值。

第 3 步：实现响应

以下响应方案可能适合此发现结果，但也可能会影响运营。请仔细评估您在研究中收集的信息，以确定解析发现结果的最佳方法。

立即在“服务账号”页面撤消服务账号密钥。
移除发布服务账号密钥的网页或 GitHub 代码库。
考虑删除被盗用的服务账号。
轮替和删除可能被破解的项目的所有服务账号访问密钥。删除后，使用该服务账号进行身份验证的应用会失去访问权限。在删除之前，您的安全团队应确定所有受影响的应用并与应用所有者合作，以确保业务连续性。
与您的安全团队合作，确定不熟悉的资源，包括 Compute Engine 实例、快照、服务账号和 IAM 用户。删除未使用已获授权的账号创建的资源。
响应来自 Cloud Customer Care 的任何通知。

`Initial Access: Excessive Permission Denied Actions`

检测主账号在多个方法和服务中反复触发“权限遭拒”错误的事件。

如需响应此发现结果，请执行以下操作：

第 1 步：查看发现结果详情

按照查看发现结果中所述，打开 Initial Access: Excessive Permission Denied Actions 发现结果。
在发现结果详情的摘要标签页上，记下以下字段的值。

在检测到的内容下：
- 主账号电子邮件地址：触发多个权限遭拒错误的主账号
- 服务名称：上一次权限遭拒错误发生时所涉及的 Google Cloud 服务的 API 名称
- 方法名称：上一次权限遭拒错误发生时调用的方法
在发现结果详情的来源属性标签页上，记下以下 JSON 字段的值：
- properties.failedActions：发生的权限遭拒错误。对于每个条目，详细信息包括上次发生错误时的服务名称、方法名称、失败尝试次数以及错误发生时间。最多显示 10 个条目。

第 2 步：检查日志

在 Google Cloud 控制台中，点击 Cloud Logging URI 中的链接，以前往日志浏览器。
在 Google Cloud 控制台工具栏中，选择您的项目。
在加载的页面上，使用以下过滤条件查找相关日志：
- protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"
- protoPayload.status.code=7
将 PRINCIPAL_EMAIL 替换为您在发现结果详情的主账号电子邮件地址字段中记录的值。

第 3 步：研究攻击和响应方法

查看此发现结果类型的 MITRE ATT&CK 框架条目：有效账号：云账号。
如需制定响应方案，请将您的调查结果与 MITRE 研究相结合。

第 4 步：实现响应

以下响应方案可能适合此发现结果，但也可能会影响运营。请仔细评估您在研究中收集的信息，以确定解析发现结果的最佳方法。

与主账号电子邮件地址字段中的账号所有者联系。确认合法所有者是否执行了此操作。
删除该账号创建的项目资源，例如陌生的 Compute Engine 实例、快照、服务账号和 IAM 用户等。
与该账号所在项目的所有者联系，并可能删除或停用该账号。

`Brute Force: SSH`

检测主机上的 SSH 暴力破解能力。如需响应此发现结果，请执行以下操作：

第 1 步：查看发现结果详情

按照查看发现结果中所述，打开 Brute Force: SSH 发现结果。
在发现结果详情面板的摘要标签页上，查看以下部分中的信息：
- 检测到的内容，尤其是以下字段：
  - 调用方 IP：发起攻击的 IP 地址。
  - 用户名：登录的账号。
- 受影响的资源
- 相关链接，尤其是以下字段：
  - Cloud Logging URI：指向 Logging 条目的链接。
  - MITRE ATT&CK 方法：指向 MITRE ATT&CK 文档的链接。
  - 相关发现结果：指向任何相关发现结果的链接。
  - 在 Google Security Operations 中调查：指向 Google SecOps 的链接。
点击 JSON 标签页。
在 JSON 中，记下以下字段。
- sourceProperties：
  - evidence：
    - sourceLogId：用于标识日志条目的项目 ID 和时间戳
    - projectId：包含发现结果的项目
  - properties：
    - attempts：
    - Attempts：登录尝试次数
      - username：登录的账号
      - vmName：虚拟机的名称
      - authResult：SSH 身份验证结果

第 2 步：在 Google Security Operations 中了解情况

您可以使用 Google Security Operations 来调查此发现结果。Google SecOps 是一项 Google Cloud 服务，可帮助您在简单易用的时间范围内调查威胁并遍历相关实体。Google SecOps 会丰富发现结果数据，以便您识别感兴趣的指标并简化调查。

只有在组织级层激活 Security Command Center 后，您才能使用 Google SecOps。

转到 Google Cloud 控制台中的 Security Command Center 发现结果页面。

转至“发现结果”
在快速过滤条件面板中，向下滚动到来源显示名称。
在来源显示名称部分中，选择 Event Threat Detection。

系统会根据所选来源类型在表中填充发现结果。
在表格中的类别下方，点击 Brute Force: SSH 发现结果。系统会打开发现结果详情面板。
在发现结果详情面板的相关链接部分中，点击在 Google 安全运营中心进行调查。
按照 Google SecOps 指导的界面中的说明操作。

以下指南介绍了如何在 Google SecOps 中进行调查：

第 3 步：查看权限和设置

在 Google Cloud 控制台中，转到信息中心。

转到信息中心
选择 projectId 中指定的项目。
导航到资源卡片，然后点击 Compute Engine。
点击与 vmName 中的名称和可用区匹配的虚拟机实例。查看该实例的详细信息，包括网络和访问设置。
在导航面板中，点击 VPC 网络，然后点击防火墙。移除或禁用端口 22 上的过于宽松的防火墙规则。

第 4 步：检查日志

在 Google Cloud 控制台中，点击 Cloud Logging URI 中的链接，以前往日志浏览器。
在加载的页面上，使用以下过滤条件查找与发现结果详情摘要标签页中主账号电子邮件地址行上列出的 IP 地址相关的 VPC 流日志：
- logName="projects/projectId/logs/syslog"
- labels."compute.googleapis.com/resource_name"="vmName"

第 5 步：研究攻击和响应方法

查看此发现结果类型的 MITRE ATT&CK 框架条目：有效账号：本地账号。
点击发现结果详情摘要标签页中相关发现结果行上的相关发现结果的链接，以查看相关发现结果。相关发现结果属于同一实例和网络上的同一发现结果类型。
如需制定响应方案，请将您的调查结果与 MITRE 研究相结合。

第 6 步：实现响应

以下响应方案可能适合此发现结果，但也可能会影响运营。请仔细评估您在研究中收集的信息，以确定解析发现结果的最佳方法。

与成功尝试暴力破解的项目的所有者联系。
调查可能被破解的实例，并移除所有发现的恶意软件。为了帮助您检测和移除，请使用端点检测和响应解决方案。
考虑停用对虚拟机的 SSH 访问权限。如需了解如何停用 SSH 密钥，请参阅限制虚拟机的 SSH 密钥。此步骤可能会中断对虚拟机的授权访问，因此请考虑您的组织需求，然后再继续。
仅将 SSH 身份验证与已获授权的密钥结合使用。
通过更新防火墙规则或使用 Google Cloud Armor 阻止恶意 IP 地址。您可以在 Security Command Center 集成式服务页面上启用 Google Cloud Armor。如果信息量很大，Google Cloud Armor 的费用可能会非常高。如需了解详情，请参阅 Google Cloud Armor 价格指南。

`Credential Access: External Member Added To Privileged Group`

此发现结果不适用于项目级激活。

检测外部成员添加到特权 Google 群组（被授予敏感角色或权限的群组）的时间。如需响应此发现结果，请执行以下操作：

第 1 步：查看发现结果详情

按照查看发现结果中所述，打开 Credential Access: External Member Added To Privileged Group 发现结果。系统会打开发现结果详情面板，以显示摘要标签页。
在摘要标签页上，查看以下部分中的信息：
- 检测到的内容，尤其是以下字段：
  - 主账号电子邮件地址：做出更改的账号。
- 受影响的资源
- 相关链接，尤其是以下字段：
  - Cloud Logging URI：指向 Logging 条目的链接。
  - MITRE ATT&CK 方法：指向 MITRE ATT&CK 文档的链接。
  - 相关发现结果：指向任何相关发现结果的链接。
在详情面板中，点击 JSON 标签页。
在 JSON 中，记下以下字段。
- groupName：在其中进行更改的 Google 群组
- externalMember：新添加的外部成员
- sensitiveRoles：与此群组关联的敏感角色

第 2 步：查看群组成员

转到 Google 群组。

转到 Google 群组。
点击您要查看的群组的名称。
在导航菜单中，点击成员。
如果新添加的外部成员不应在此群组中，请点击成员名称旁边的复选框，然后选择 移除成员或 将成员加入屏蔽名单。

如需移除或成员，您必须是 Google Workspace 管理员，或者在 Google 群组中拥有 Owner 或 Manager 角色。如需了解详情，请参阅向群组成员分配角色。

第 3 步：检查日志

在发现结果详情面板的“摘要”标签页上，点击 Cloud Logging URI 链接以打开日志浏览器。
如有必要，请选择您的项目。
在加载的页面上，使用以下过滤条件检查日志，了解 Google 群组成员资格是否发生更改：
- protoPayload.methodName="google.apps.cloudidentity.groups.v1.MembershipsService.UpdateMembership"
- protoPayload.authenticationInfo.principalEmail="principalEmail"

第 4 步：研究攻击和响应方法

查看发现结果类型的 MITRE ATT&CK 框架条目：有效账号。
如需确定是否需要执行额外的补救步骤，请将您的调查结果与 MITRE 研究相结合。

`Credential Access: Failed Attempt to Approve Kubernetes Certificate Signing Request (CSR)`

有人尝试手动批准证书签名请求 (CSR)，但操作失败。创建用于集群身份验证的证书是攻击者创建对已被入侵集群的永久访问权限的常用方法。与证书关联的权限因包含的正文而异，但可能具有很高的特权。如需了解详情，请参阅此提醒的日志消息。

查看 Cloud Logging 中的审核日志和其他 CSR 相关事件的更多提醒，以确定是否有任何 CSR 已approved并已颁发，以及 CSR 相关操作是否是主账号执行的预期活动。
确定 Cloud Logging 的审核日志中是否存在主账号执行的其他恶意活动迹象。例如：
- 尝试批准 CSR 的主账号是否与创建 CSR 的主账号不同？
- 主账号是否尝试过请求、创建、批准或删除其他 CSR？
如果 CSR 审批不在预期之内，或者被认定为是恶意的，集群将需要进行凭据轮替以使证书失效。请查看相关指南以了解如何执行集群凭据轮替。

`Credential Access: Manually Approved Kubernetes Certificate Signing Request (CSR)`

有人手动批准了证书签名请求 (CSR)。创建用于集群身份验证的证书是攻击者创建对已被入侵集群的永久访问权限的常用方法。与证书关联的权限因包含的正文而异，但可能具有高特权。如需了解详情，请参阅此提醒的日志消息。

查看 Cloud Logging 中的审核日志和其他 CSR 相关事件的更多提醒，以确定 CSR 相关操作是否是主账号执行的预期活动。
确定 Cloud Logging 的审核日志中是否存在主账号执行的其他恶意活动迹象。例如：
- 批准 CSR 的主账号是否与创建 CSR 的主账号不同？
- CSR 是否指定了内置 signer，但最终因它不符合 signer 的条件而需要手动批准？
- 主账号是否尝试过请求、创建、批准或删除其他 CSR？
如果 CSR 审批不在预期之内，或者被认定为是恶意的，集群将需要进行凭据轮替以使证书失效。请查看相关指南以了解如何执行集群凭据轮替。

`Credential Access: Privileged Group Opened To Public`

此发现结果不适用于项目级激活。

检测到特权 Google 群组（被授予敏感角色或权限的群组）变为可供公众访问。如需响应此发现结果，请执行以下操作：

第 1 步：查看发现结果详情

按照查看发现结果中所述，打开 Credential Access: Privileged Group Opened To Public 发现结果。系统会打开发现结果详情面板，以显示摘要标签页。
在摘要标签页上，查看以下部分中的信息：
- 检测到的内容，尤其是以下字段：
  - 主账号电子邮件地址：做出更改的账号，该账号可能被盗用。
- 受影响的资源
- 相关链接，尤其是以下字段：
  - Cloud Logging URI：指向 Logging 条目的链接。
  - MITRE ATT&CK 方法：指向 MITRE ATT&CK 文档的链接。
  - 相关发现结果：指向任何相关发现结果的链接。
1. 点击 JSON 标签页。
2. 在 JSON 中，记下以下字段。
- groupName：在其中进行更改的 Google 群组
- sensitiveRoles：与此群组关联的敏感角色
- whoCanJoin：群组的可加入性设置

第 2 步：查看群组访问权限设置

转到 Google 群组的管理控制台。您必须是 Google Workspace 管理员才能登录控制台。

转到管理控制台
在导航窗格中，点击目录，然后选择群组。
点击您要查看的群组的名称。
点击访问权限设置，然后在哪些人可以加入群组下查看此群组的可加入性设置。
如有需要，请在下拉菜单中更改可加入性设置。

第 3 步：检查日志

在发现结果详情面板的“摘要”标签页上，点击 Cloud Logging URI 链接以打开日志浏览器。
如有必要，请选择您的项目。
在加载的页面上，使用以下过滤条件检查日志，了解 Google 群组设置是否发生更改：
- protoPayload.methodName="google.admin.AdminService.changeGroupSetting"
- protoPayload.authenticationInfo.principalEmail="principalEmail"

第 4 步：研究攻击和响应方法

查看发现结果类型的 MITRE ATT&CK 框架条目：有效账号。
如需确定是否需要执行额外的补救步骤，请将您的调查结果与 MITRE 研究相结合。

`Credential Access: Secrets Accessed in Kubernetes Namespace`

检测 Pod 的 default Kubernetes 服务账号何时被用于访问集群中的 Secret 对象。除非您使用 Role 对象或 ClusterRole 对象明确授予访问权限，否则 default Kubernetes 服务账号不应有权访问 Secret 对象。

`Credential Access: Sensitive Role Granted To Hybrid Group`

检测到具有外部成员的 Google 群组被授予敏感角色或权限。如需响应此发现结果，请执行以下操作：

第 1 步：查看发现结果详情

按照查看发现结果中所述，打开 Credential Access: Sensitive Role Granted To Hybrid Group 发现结果。系统会打开发现结果详情面板，以显示摘要标签页。
在摘要标签页上，查看以下部分中的信息：
- 检测到的内容，尤其是以下字段：
  - 主账号电子邮件地址：做出更改的账号，该账号可能被盗用。
- 受影响的资源，尤其是以下字段：
  - 资源全名：为其授予新角色的资源。
- 相关链接，尤其是以下字段：
  - Cloud Logging URI：指向 Logging 条目的链接。
  - MITRE ATT&CK 方法：指向 MITRE ATT&CK 文档的链接。
  - 相关发现结果：指向任何相关发现结果的链接。
1. 点击 JSON 标签页。
2. 在 JSON 中，记下以下字段。
- groupName：在其中进行更改的 Google 群组
- bindingDeltas：为此群组新授予的敏感角色。

第 2 步：查看群组权限

转到 Google Cloud 控制台中的 IAM 页面。

转到 IAM
在过滤条件字段中，输入 groupName 中列出的账号名称。
查看为群组授予的敏感角色。
如果不需要新添加的敏感角色，请撤消此角色。

您需要特定权限才能管理组织或项目中的角色。如需了解详情，请参阅所需权限。

第 3 步：检查日志

在发现结果详情面板的“摘要”标签页上，点击 Cloud Logging URI 链接以打开日志浏览器。
如有必要，请选择您的项目。
在加载的页面上，使用以下过滤条件检查日志，了解 Google 群组设置是否发生更改：
- protoPayload.methodName="SetIamPolicy"
- protoPayload.authenticationInfo.principalEmail="principalEmail"

第 4 步：研究攻击和响应方法

查看发现结果类型的 MITRE ATT&CK 框架条目：有效账号。
如需确定是否需要执行额外的补救步骤，请将您的调查结果与 MITRE 研究相结合。

`Malware: Cryptomining Bad IP`

通过检查 VPC 流日志和 Cloud DNS 日志中与已知的命令以及控制网域和 IP 地址的连接，检测到恶意软件。如需响应此发现结果，请执行以下操作：

第 1 步：查看发现结果详情

按照查看发现结果中所述，打开 Malware: Cryptomining Bad IP 发现结果。系统会打开发现结果详情面板，以显示摘要标签页。
在摘要标签页上，查看以下部分中的信息：
- 检测到的内容，尤其是以下字段：
  - 来源 IP：疑似挖矿 IP 地址。
  - 来源端口：连接的来源端口（如果有）。
  - 目的地 IP：目标 IP 地址。
  - 目的地端口：连接的目的地端口（如果有）。
  - 协议：与连接关联的 IANA 协议。
- 受影响的资源
- 相关链接，其中包括以下字段：
  - Logging URI：指向 Logging 条目的链接。
  - MITRE ATT&CK 方法：指向 MITRE ATT&CK 文档的链接。
  - 相关发现结果：指向任何相关发现结果的链接。
  - Flow Analyzer（预览版）：指向 Network Intelligence Center 的 Flow Analyzer 功能的链接。只有在启用 VPC 流日志后，此字段才会显示。
在发现结果的详情视图中，点击来源属性标签页。
展开媒体资源，然后记下以下字段中的项目和实例值：
- instanceDetails：记下 Compute Engine 实例的项目 ID 和名称。项目 ID 和实例名称如下例所示：
```
/projects/PROJECT_ID/zones/ZONE/instances/INSTANCE_NAME
```
如需查看发现结果的完整 JSON，请点击 JSON 标签页。

第 2 步：查看权限和设置

在 Google Cloud 控制台中，转到信息中心页面。

转到信息中心
选择 properties_project_id 中指定的项目。
导航到资源卡片，然后点击 Compute Engine。
点击与 properties_sourceInstance 匹配的虚拟机实例。调查可能被破解的实例是否存在恶意软件。
在导航面板中，点击 VPC 网络，然后点击防火墙。移除或停用过于宽松的防火墙规则。

第 3 步：检查日志

在 Google Cloud 控制台中，打开日志浏览器。

打开日志浏览器
在 Google Cloud 控制台工具栏中，选择您的项目。
在加载的页面上，使用以下过滤条件查找与 Properties_ip_0 相关的 VPC 流日志：
- logName="projects/properties_project_id/logs/compute.googleapis.com%2Fvpc_flows"
- (jsonPayload.connection.src_ip="Properties_ip_0" OR jsonPayload.connection.dest_ip="Properties_ip_0")

第 4 步：研究攻击和响应方法

查看此发现结果类型的 MITRE ATT&CK 框架条目：资源黑客攻击。
如需制定响应方案，请将您的调查结果与 MITRE 研究相结合。

第 5 步：实现响应

以下响应方案可能适合此发现结果，但也可能会影响运营。请仔细评估您在研究中收集的信息，以确定解析发现结果的最佳方法。

与包含恶意软件的项目的所有者联系。
调查可能被破解的实例，并移除所有发现的恶意软件。为了帮助您检测和移除，请使用端点检测和响应解决方案。
如有必要，请停止已被破解的实例并用新实例取代。
通过更新防火墙规则或使用 Google Cloud Armor 阻止恶意 IP 地址。您可以在 Security Command Center 集成式服务页面上启用 Google Cloud Armor。如果数据量很大，Google Cloud Armor 的费用可能会非常高。如需了解详情，请参阅 Google Cloud Armor 价格指南。

`Initial Access: Log4j Compromise Attempt`

当检测到标头或网址参数中的 Java 命名和目录接口 (JNDI) 查找时，系统会生成此发现结果。这些查找可能表明 Log4Shell 被漏洞利用的尝试。如需响应此发现结果，请执行以下操作：

第 1 步：查看发现结果详情

按照查看发现结果详情中所述，打开 Initial Access: Log4j Compromise Attempt 发现结果。系统会打开发现结果详情面板，以显示摘要标签页。
在摘要标签页上，查看以下部分中的信息：
- 检测到的内容
- 受影响的资源
- 相关链接，尤其是以下字段：
  - Cloud Logging URI：指向 Logging 条目的链接。
  - MITRE ATT&CK 方法：指向 MITRE ATT&CK 文档的链接。
  - 相关发现结果：指向任何相关发现结果的链接。
- 在发现结果的详情视图中，点击 JSON 标签页。
- 在 JSON 中，记下以下字段。
- properties
  - loadBalancerName：接收 JNDI 查找的负载均衡器的名称
  - requestUrl：HTTP 请求的网址。如果此字段存在，则包含 JNDI 查找。
  - requestUserAgent：发送 HTTP 请求的用户代理。如果存在，则包含 JNDI 查找。
  - refererUrl：发送 HTTP 请求的页面的网址。如果此字段存在，则包含 JNDI 查找。

第 2 步：检查日志

在 Google Cloud 控制台中，点击第 1 步的 Cloud Logging URI 中的链接，以前往日志浏览器。
在加载的页面上，检查 httpRequest 字段中是否存在 ${jndi:ldap:// 等字符串令牌，这可能表示潜在的漏洞利用尝试。

请参阅 Logging 文档中的 CVE-2021-44228：检测 Log4Shell 漏洞利用，查看要搜索的示例字符串以及示例查询。

第 3 步：研究攻击和响应方法

查看此发现结果类型的 MITRE ATT&CK 框架条目：利用面向公众的应用。
点击发现结果详情摘要标签页中相关发现结果行上的相关发现结果的链接，以查看相关发现结果。相关发现结果在同一实例和网络上属于同一发现结果类型。
如需制定响应方案，请将您的调查结果与 MITRE 研究相结合。

第 4 步：实现响应

以下响应方案可能适合此发现结果，但也可能会影响运营。请仔细评估您在研究中收集的信息，以确定解析发现结果的最佳方法。

升级到最新版本的 Log4j2。
遵循 Google Cloud 有关调查和应对“Apache Log4j 2”漏洞的建议。
实施 Apache Log4j 安全漏洞中推荐的缓解措施。
如果您使用 Google Cloud Armor，请将 cve-canary rule 部署到新的或现有的 Google Cloud Armor 安全政策。如需了解详情，请参阅 Google Cloud Armor WAF 规则以帮助缓解 Apache Log4j 漏洞。

`Active Scan: Log4j Vulnerable to RCE`

受支持的 Log4j 漏洞扫描工具会在 HTTP 参数、网址和文本字段中注入经过混淆处理的 JNDI 查找，并对扫描工具控制的网域进行回调。发现经过去混淆处理的网域的 DNS 查询时，系统会生成此发现结果。只有当 JNDI 查找成功时，才会发生此类查询，这表示活跃的 Log4j 漏洞。如需响应此发现结果，请执行以下操作：

第 1 步：查看发现结果详情

按照查看发现结果详情中所述，打开 Active Scan: Log4j Vulnerable to RCE 发现结果。系统会打开发现结果详情面板，以显示摘要标签页。
在摘要标签页上，查看以下部分中的信息：
- 检测到的内容
- 受影响的资源，尤其是以下字段：
  - 资源全名：易受 Log4j RCE 攻击的 Compute Engine 实例的完整资源名称。
- 相关链接，尤其是以下字段：
  - Cloud Logging URI：指向 Logging 条目的链接。
  - MITRE ATT&CK 方法：指向 MITRE ATT&CK 文档的链接。
  - 相关发现结果：指向任何相关发现结果的链接。
在发现结果的详情视图中，点击 JSON 标签页。
在 JSON 中，记下以下字段。
- properties
  - scannerDomain：扫描工具在 JNDI 查找过程中使用的网域。这会表明哪个扫描工具发现了漏洞。
  - sourceIp：用于进行 DNS 查询的 IP 地址
  - vpcName：在其中执行 DNS 查询的实例上的网络名称。

第 2 步：检查日志

在 Google Cloud 控制台中，点击第 1 步的 Cloud Logging URI 中的链接，以前往日志浏览器。
在加载的页面上，检查 httpRequest 字段中是否存在 ${jndi:ldap:// 等字符串令牌，这可能表示潜在的漏洞利用尝试。

请参阅 Logging 文档中的 CVE-2021-44228：检测 Log4Shell 漏洞利用，查看要搜索的示例字符串以及示例查询。

第 3 步：研究攻击和响应方法

查看此发现结果类型的 MITRE ATT&CK 框架条目：利用远程服务。
点击发现结果详情摘要标签页中相关发现结果行上的相关发现结果的链接，以查看相关发现结果。相关发现结果属于同一实例和网络上的同一发现结果类型。
如需制定响应方案，请将您的调查结果与 MITRE 研究相结合。

第 4 步：实现响应

以下响应方案可能适合此发现结果，但也可能会影响运营。请仔细评估您在研究中收集的信息，以确定解析发现结果的最佳方法。

升级到最新版本的 Log4j2。
遵循 Google Cloud 有关调查和应对“Apache Log4j 2”漏洞的建议。
实施 Apache Log4j 安全漏洞中推荐的缓解措施。
如果您使用 Google Cloud Armor，请将 cve-canary rule 部署到新的或现有的 Google Cloud Armor 安全政策。如需了解详情，请参阅 Google Cloud Armor WAF 规则以帮助缓解 Apache Log4j 漏洞。

`Leaked credentials`

此发现结果不适用于项目级激活。

当 Google Cloud 服务账号凭据意外在网上泄露或被破解时生成此发现结果。如需响应此发现结果，请执行以下操作：

第 1 步：查看发现结果详情

按照查看发现结果详情中所述，打开 account_has_leaked_credentials 发现结果。系统会打开发现结果详情面板，以显示摘要标签页。
在摘要标签页上，查看以下部分中的信息：

检测到的内容
受影响的资源

点击来源属性标签页并注意以下字段：
- Compromised_account：可能被盗用的服务账号
- Project_identifier：包含可能已泄露的账号凭据的项目
- URL：指向 GitHub 代码库的链接
如需查看发现结果的完整 JSON，请点击 JSON 标签页。

第 2 步：查看项目和服务账号权限

在 Google Cloud 控制台中，转到 IAM 页面。

转到 IAM
如有必要，选择 Project_identifier 中列出的项目。
在显示的页面上的过滤条件框中，输入 Compromised_account 中列出的账号名称并检查已分配的权限。
在 Google Cloud 控制台中，转到服务账号页面。

转到“服务账号”
在显示的页面上的过滤条件框中，输入被盗用的服务账号的名称，并检查该服务账号的密钥和密钥创建日期。

第 3 步：检查日志

在 Google Cloud 控制台中，打开日志浏览器。

打开日志浏览器
在 Google Cloud 控制台工具栏中，选择您的项目。
在加载的页面上，使用以下过滤条件检查新的或更新后的 IAM 资源中的活动日志：
- proto_payload.method_name="google.iam.admin.v1.CreateServiceAccount"
- protoPayload.methodName="SetIamPolicy"
- resource.type="gce_instance" AND log_name="projects/Project_identifier/logs/cloudaudit.googleapis.com%2Factivity"
- protoPayload.methodName="InsertProjectOwnershipInvite"
- protoPayload.authenticationInfo.principalEmail="Compromised_account"

第 4 步：研究攻击和响应方法

查看此发现结果类型的 MITRE ATT&CK 框架条目：有效账号：云账号。
点击 relatedFindingURI 中的链接查看相关发现结果。相关发现结果属于同一实例和网络上的同一发现结果类型。
如需制定响应方案，请将您的调查结果与 MITRE 研究相结合。

第 5 步：实现响应

以下响应方案可能适合此发现结果，但也可能会影响运营。请仔细评估您在研究中收集的信息，以确定解析发现结果的最佳方法。

与凭据被泄露的项目的所有者联系。
考虑删除被盗用的服务账号，然后轮替和删除被破解的项目的所有服务账号访问密钥。删除后，使用该服务账号进行身份验证的资源会失去访问权限。在继续操作之前，您的安全团队应确定所有受影响的资源并与资源所有者合作，以确保业务连续性。
与您的安全团队合作，确定不熟悉的资源，包括 Compute Engine 实例、快照、服务账号和 IAM 用户。删除未使用已获授权的账号创建的资源。
回复来自 Google Cloud 支持的通知。
如需限制谁可以创建服务账号，请使用组织政策服务。
如需识别并修正过于宽松的角色，请使用 IAM Recommender。
打开 URL 链接并删除已泄露的凭据。获取有关已被破解的账号的更多信息，然后联系所有者。

`Malware`

通过检查 VPC 流日志和 Cloud DNS 日志中与已知的命令以及控制网域和 IP 地址的连接，检测到恶意软件。目前，Event Threat Detection 提供常规恶意软件检测（Malware: Bad IP 和 Malware: Bad Domain）和特别针对 Log4j 相关恶意软件（Log4j Malware: Bad IP 和 Log4j Malware: Bad Domain）的检测器。

以下步骤介绍了如何调查和回应基于 IP 地址的调查结果。对于基于网域的发现结果，补救步骤类似。

第 1 步：查看发现结果详情

打开相关的恶意软件发现结果。按照查看发现结果中所述，以下步骤使用 Malware: Bad IP 发现结果。系统会打开发现结果详情面板，以显示摘要标签页。
在摘要标签页上，查看以下部分中的信息：
- 检测到的内容，尤其是以下字段：
  - 指示器网域：对于 Bad domain 发现结果，此字段是触发发现结果的网域。
  - 指示器 IP：对于 Bad IP 发现结果，此字段是触发发现结果的 IP 地址。
  - 来源 IP：对于 Bad IP 发现结果，此字段是已知的恶意软件命令和控制 IP 地址。
  - 来源端口：对于 Bad IP 发现结果，此字段是连接的来源端口。
  - 目的地 IP：对于 Bad IP 发现结果，此字段是恶意软件的目标 IP 地址。
  - 目的地端口：对于 Bad IP 发现结果，此字段是连接的目的地端口。
  - 协议：对于 Bad IP 发现结果，此字段是与连接关联的 IANA 协议编号。
- 受影响的资源，尤其是以下字段：
  - 资源全名：受影响的 Compute Engine 实例的完整资源名称。
  - 项目全名：包含相应发现结果的项目的完整资源名称。
- 相关链接，尤其是以下字段：
  - Cloud Logging URI：指向 Logging 条目的链接。
  - MITRE ATT&CK 方法：指向 MITRE ATT&CK 文档的链接。
  - 相关发现结果：指向任何相关发现结果的链接。
  - 在 Google Security Operations 中调查：指向 Google SecOps 的链接。
  - VirusTotal 指示器：指向 VirusTotal 分析页面的链接。
  - Flow Analyzer（预览版）：指向 Network Intelligence Center 的 Flow Analyzer 功能的链接。只有在启用 VPC 流日志后，此字段才会显示。
1. 点击 JSON 标签页并注意以下字段：
  - evidence：
  - sourceLogId：
    - projectID：在其中检测到问题的项目的 ID。
  - properties：
  - InstanceDetails：Compute Engine 实例的资源地址。

第 2 步：在 Google Security Operations 中了解情况

只有在组织级层激活 Security Command Center 后，您才能使用 Google SecOps。

转到 Google Cloud 控制台中的 Security Command Center 发现结果页面。

转至“发现结果”
在快速过滤条件面板中，滚动到来源显示名称。
在来源显示名称部分中，选择 Event Threat Detection。

系统会根据所选来源类型在表中填充发现结果。
在表中的类别下方，点击 Malware: Bad IP 发现结果。系统会打开发现结果详情面板。
在发现结果详情面板的相关链接部分中，点击在 Google 安全运营中心进行调查。
按照 Google SecOps 指导的界面中的说明操作。

以下指南介绍了如何在 Google SecOps 中进行调查：

第 3 步：查看权限和设置

在 Google Cloud 控制台中，转到信息中心页面。

转到信息中心
选择摘要标签页上的项目全名行中指定的项目。
导航到资源卡片，然后点击 Compute Engine。
点击与资源全名中的名称和可用区匹配的虚拟机实例。查看该实例的详细信息，包括网络和访问设置。
在导航面板中，点击 VPC 网络，然后点击防火墙。移除或停用过于宽松的防火墙规则。

第 4 步：检查日志

在发现结果详情面板的“摘要”标签页上，点击 Cloud Logging URI 链接以打开日志浏览器。
在加载的页面上，使用以下过滤条件查找与来源 IP 中的 IP 地址相关的 VPC 流日志：
- logName="projects/projectId/logs/compute.googleapis.com%2Fvpc_flows" AND (jsonPayload.connection.src_ip="SOURCE_IP" OR jsonPayload.connection.dest_ip="destIP")
  
  请替换以下内容：
  - PROJECT_ID 中选择 projectId 中列出的项目。
  - 将 SOURCE_IP 替换为发现结果详情摘要标签页中的来源 IP 行上列出的 IP 地址。

第 5 步：检查流程分析器

您必须启用 VPC 流日志才能执行以下流程。

确保您已升级日志存储桶以使用 Log Analytics。如需了解相关说明，请参阅升级存储桶以使用 Log Analytics。升级无需额外付费。
在 Google Cloud 控制台中，前往 Flow Analyzer 页面：

前往 Flow Analyzer

您还可以通过发现结果详情窗格的摘要标签页中相关链接部分的 Flow Analyzer 网址链接访问 Flow Analyzer。
如需进一步调查与 Event Threat Detection 发现结果相关的信息，请使用操作栏中的时间范围选择器更改时间段。时间段应反映发现结果的首次报告时间。例如，如果发现问题是在过去 2 小时内报告的，您可以将时间段设置为过去 6 小时。这样可确保流程分析器中的时间段包含报告发现的时间。
过滤流量分析器，以便针对与恶意 IP 地址发现结果关联的 IP 地址显示适当的结果：
1. 在查询部分的来源行中的过滤条件菜单中，选择 IP。
2. 在值字段中，输入与相应发现关联的 IP 地址，然后点击运行新查询。
  
  如果流量分析器未针对 IP 地址显示任何结果，请从来源行中清除过滤条件，然后在目标行中使用相同的过滤条件再次运行查询。
分析结果。如需详细了解特定数据流，请点击所有数据流表格中的详细信息，以打开数据流详情窗格。

第 6 步：研究攻击和响应方法

查看此发现结果类型的 MITRE ATT&CK 框架条目：动态解析以及命令和控制。
点击发现结果详情摘要标签页中相关发现结果行上的相关发现结果的链接，以查看相关发现结果。相关发现结果属于同一实例和网络上的同一发现结果类型。
点击 VirusTotal 指示器中的链接，以检查 VirusTotal 上标记的网址和网域。VirusTotal 是一项 Alphabet 自有服务，提供了有关潜在恶意文件、网址、网域和 IP 地址的上下文。
如需制定响应方案，请将您的调查结果与 MITRE 研究相结合。

第 6 步：实现响应

以下响应方案可能适合此发现结果，但也可能会影响运营。请仔细评估您在研究中收集的信息，以确定解析发现结果的最佳方法。

与包含恶意软件的项目的所有者联系。
调查可能被破解的实例，并移除所有发现的恶意软件。为了帮助您检测和移除，请使用端点检测和响应解决方案。
如需跟踪可以插入恶意软件的活动和漏洞，请检查与被破解的实例关联的审核日志和系统日志。
如有必要，请停止已被破解的实例并用新实例取代。
通过更新防火墙规则或使用 Google Cloud Armor 阻止恶意 IP 地址。您可以在 Security Command Center 集成式服务页面上启用 Google Cloud Armor。如果数据量很大，Google Cloud Armor 的费用可能会非常高。如需了解详情，请参阅 Google Cloud Armor 价格指南。
如需控制对虚拟机映像的访问和使用，请使用安全强化型虚拟机和可信映像 IAM 政策。

`Persistence: IAM Anomalous Grant`

系统会检查审核日志以检测是否添加了可能认为可疑的 IAM (IAM) 角色授权。

以下是异常授权的示例：

通过 Google Cloud 控制台邀请外部用户（例如 gmail.com 用户）作为项目所有者
授予敏感权限的服务账号
授予敏感权限的自定义角色
从您的组织或项目外部添加的服务账号

IAM Anomalous Grant 发现结果的独特之处在于，它包含子规则，用于提供有关此发现结果每个实例的更具体的信息。此发现结果的严重级别分类取决于子规则。每项子规则可能需要不同的响应。

以下列表显示了所有可能的子规则及其严重程度：

external_service_account_added_to_policy：
- HIGH（如果授予了高度敏感的角色，或在组织级层授予了中等敏感角色）。如需了解详情，请参阅高度敏感角色。
- MEDIUM（如果授予了中等敏感角色）。如需了解详情，请参阅中等敏感角色。
external_member_invited_to_policy：HIGH
external_member_added_to_policy：
- HIGH（如果授予了高度敏感的角色，或在组织级层授予了中等敏感角色）。如需了解详情，请参阅高度敏感角色。
- MEDIUM（如果授予了中等敏感角色）。如需了解详情，请参阅中等敏感角色。
custom_role_given_sensitive_permissions：MEDIUM
service_account_granted_sensitive_role_to_member：HIGH
policy_modified_by_default_compute_service_account：HIGH

如需响应此发现结果，请执行以下操作：

第 1 步：查看发现结果详情

按照查看发现结果中所述，打开 Persistence: IAM Anomalous Grant 发现结果。系统会打开发现结果详情面板，以显示摘要标签页。
在摘要标签页上，查看以下部分中的信息：
- 检测到的内容，尤其是以下字段：
  - 主账号电子邮件地址：分配了角色的用户或服务账号的电子邮件地址。
- 受影响的资源
- 相关链接，尤其是以下字段：
  - Cloud Logging URI：指向 Logging 条目的链接。
  - MITRE ATT&CK 方法：指向 MITRE ATT&CK 文档的链接。
  - 相关发现结果：指向任何相关发现结果的链接。
  - VirusTotal 指示器：指向 VirusTotal 分析页面的链接。
  - 在 Google Security Operations 中调查：指向 Google SecOps 的链接。
点击 JSON 标签页。系统会显示该发现结果的完整 JSON 文件。
在相应发现结果的 JSON 中，记下以下字段：
- detectionCategory：
  - subRuleName：有关所发生异常授予类型的更具体信息。子规则决定了此发现结果的严重级别分类。
- evidence：
  - sourceLogId：
  - projectId：包含发现结果的项目的 ID。
- properties：
  - sensitiveRoleGrant：
    - bindingDeltas：
    - Action：用户执行的操作。
    - Role：为用户分配的角色。
    - member：获得该角色的用户的电子邮件地址。

第 2 步：在 Google Security Operations 中了解情况

如果您在项目级层激活 Security Command Center，则无法在 Google SecOps 中调查 Security Command Center 发现结果。

转到 Google Cloud 控制台中的 Security Command Center 发现结果页面。

转至“发现结果”
在快速过滤条件面板中，向下滚动到来源显示名称。
在来源显示名称部分中，选择 Event Threat Detection。

系统会根据所选来源类型在表中填充发现结果。
在表格中的类别下方，点击 Persistence: IAM Anomalous Grant 发现结果。系统会打开发现结果详情面板。
在发现结果详情面板的相关链接部分中，点击在 Google 安全运营中心进行调查。
按照 Google SecOps 指导的界面中的说明操作。

以下指南介绍了如何在 Google SecOps 中进行调查：

第 3 步：检查日志

在发现结果详情面板的“摘要”标签页上，点击 Cloud Logging URI 链接以打开日志浏览器。
在加载的页面上，使用以下过滤条件查找新的或更新后的 IAM 资源：
- protoPayload.methodName="SetIamPolicy"
- protoPayload.methodName="google.iam.admin.v1.UpdateRole"
- protoPayload.methodName="google.iam.admin.v1.CreateRole"

第 4 步：研究攻击和响应方法

查看此发现结果类型的 MITRE ATT&CK 框架条目：有效账号：云账号。
点击发现结果详情摘要标签页中相关发现结果行上的链接，以查看相关发现结果。相关发现结果在同一实例和网络上属于同一发现结果类型。
如需制定响应方案，请将您的调查结果与 MITRE 研究相结合。

第 5 步：实现响应

以下响应方案可能适合此发现结果，但也可能会影响运营。请仔细评估您在研究中收集的信息，以确定解析发现结果的最佳方法。

与账号被盗用的项目的所有者联系。
删除被盗用的服务账号，然后轮替和删除被破解的项目的所有服务账号访问密钥。删除后，使用该服务账号进行身份验证的资源会失去访问权限。
删除未经授权的账号创建的项目资源，例如不熟悉的 Compute Engine 实例、快照、服务账号和 IAM 用户。
如需限制添加 gmail.com 用户，请使用组织政策。
如需识别并修正过于宽松的角色，请使用 IAM Recommender。

`Persistence: Impersonation Role Granted for Dormant Service Account`

检测向主账号授予模拟角色的事件，该事件允许该主账号模拟休眠的用户管理的服务账号。在此发现结果中，休眠服务账号是受影响的资源，如果服务账号处于非活跃状态超过 180 天，则会被视为休眠。

如需响应此发现结果，请执行以下操作：

第 1 步：查看发现结果详情

按照查看发现结果中所述，打开 Persistence: Impersonation Role Granted for Dormant Service Account 发现结果。
在发现结果详情的摘要标签页上，记下以下字段的值。

在检测到的内容下：
- 主账号电子邮件地址：执行授予角色操作的用户
- 违规访问授权主账号名称：被授予模拟角色的主账号
在受影响的资源下：
- 资源显示名称：作为资源的休眠服务账号
- 项目全名：休眠服务账号所在的项目

第 2 步：研究攻击和响应方法

使用服务账号工具（如活动分析器）调查休眠服务账号的活动。
与主账号电子邮件地址字段的所有者联系。确认合法所有者是否执行了此操作。

第 3 步：检查日志

在发现结果详情面板的摘要标签页上，点击相关链接下的 Cloud Logging URI 链接以打开 Logs Explorer。

第 4 步：实现响应

以下响应方案可能适合此发现结果，但也可能会影响运营。请仔细评估您在研究中收集的信息，以确定解析发现结果的最佳方法。

与执行操作的项目的所有者联系。
如果主账号电子邮件地址被盗用，请移除其所有者的访问权限。
从目标成员中移除新授予的模拟角色。
考虑删除可能被盗用的服务账号，然后轮替和删除可能被破解的项目的所有服务账号访问密钥。删除后，使用该服务账号进行身份验证的应用会失去访问权限。在继续操作之前，您的安全团队应确定所有受影响的应用并与应用所有者合作，以确保业务连续性。
与您的安全团队合作，确定不熟悉的资源，包括 Compute Engine 实例、快照、服务账号和 IAM 用户。删除未使用已获授权的账号创建的资源。
响应来自 Cloud Customer Care 的任何通知。
如需限制谁可以创建服务账号，请使用组织政策服务。
如需识别并修正过于宽松的角色，请使用 IAM Recommender。

`Persistence: Unmanaged Account Granted Sensitive Role`

检测向不受管理的账号授予敏感角色的事件。系统管理员无法控制不受管理的账号。例如，当相应员工离职后，管理员将无法删除该账号。因此，向不受管理的账号授予敏感角色会给组织带来潜在的安全风险。

如需响应此发现结果，请执行以下操作：

第 1 步：查看发现结果详情

按照查看发现结果中所述，打开 Persistence: Unmanaged Account Granted Sensitive Role 发现结果。
在发现结果详情的摘要标签页上，记下以下字段的值。

在检测到的内容下：
- 主账号电子邮件地址：执行授予角色操作的用户
- 违规访问授权主账号名称：收到授权的非受管账号
- 违规访问授权授予的角色：授予的敏感角色

第 2 步：研究攻击和响应方法

与主账号电子邮件地址字段的所有者联系。确认合法所有者是否执行了此操作。
与违规的访问权限授予。主账号名称字段的所有者联系，了解不受管理的账号的来源。

第 3 步：检查日志

在发现结果详情面板的摘要标签页上，点击相关链接下的 Cloud Logging URI 链接以打开 Logs Explorer。

第 4 步：实现响应

以下响应方案可能适合此发现结果，但也可能会影响运营。请仔细评估您在研究中收集的信息，以确定解析发现结果的最佳方法。

与执行操作的项目的所有者联系。
如果主账号电子邮件地址被盗用，请移除其所有者的访问权限。
从不受管理的账号中移除新授予的敏感角色。
不妨考虑使用转移工具将非受管账号转换为受管理账号，并将此账号移交给系统管理员管理。

`Persistence: New API Method`

在组织、文件夹或项目中检测到潜在恶意行事者的异常管理员活动。异常活动可以是以下任一活动：

组织、文件夹或项目中的主账号的新活动
组织、文件夹或项目中主账号的一段时间内没有出现的活动

第 1 步：查看发现结果详情

按照查看发现结果中所述，打开 Persistence: New API Method 发现结果。
在发现结果详情的摘要标签页上，记下以下字段的值：
- 在检测到的内容下：
  - 主账号电子邮件地址：发出调用的账号
  - 服务名称：操作中使用的 Google Cloud 服务的 API 名称
  - 方法名称：所调用的方法
- 在受影响的资源下：
  - 资源显示名称：受影响资源的名称，可以与组织、文件夹或项目的名称相同
  - 资源路径：资源层次结构中活动发生的位置

第 2 步：研究攻击和响应方法

查看此发现结果类型的 MITRE ATT&CK 框架条目：持久性。
调查在组织、文件夹或项目中执行此操作是否有必要，以及此操作是否由账号的合法所有者执行。组织、文件夹或项目显示在资源路径行上，账号显示在主账号电子邮件地址行上。
如需制定响应方案，请将您的调查结果与 MITRE 研究相结合。

`Persistence: New Geography`

此发现结果不适用于项目级激活。

根据发出请求的 IP 地址的地理位置，IAM 用户或服务账号从异常位置访问 Google Cloud。

第 1 步：查看发现结果详情

按照本页面前面部分的查看发现结果详情中所述，打开 Persistence: New Geography 发现结果。系统会打开发现结果详情面板，以显示摘要标签页。
在摘要标签页上，查看以下部分中的信息：

检测到的内容，尤其是以下字段：
- 主账号电子邮件地址：可能被盗用的用户账号。
受影响的资源，尤其是以下字段：
- 项目全名：包含可能被盗用的用户账号的项目。
相关链接，尤其是以下字段：
- Cloud Logging URI：指向 Logging 条目的链接。
- MITRE ATT&CK 方法：指向 MITRE ATT&CK 文档的链接。
- 相关发现结果：指向任何相关发现结果的链接。

在发现结果的详情视图中，点击 JSON 标签页。
在 JSON 中，记下以下 sourceProperties 字段：
- affectedResources：
  - gcpResourceName：受影响的资源
- evidence：
  - sourceLogId：
  - projectId：包含发现结果的项目的 ID。
- properties：
  - anomalousLocation：
  - anomalousLocation：预估的用户当前位置。
  - callerIp：外部 IP 地址。
  - notSeenInLast：用于建立正常行为基准的时间段。
  - typicalGeolocations：用户通常在其中访问 Google Cloud 资源的位置。

第 2 步：查看项目和账号权限

在 Google Cloud 控制台中，转到 IAM 页面。

转到 IAM
如有必要，请选择发现结果 JSON 中的 projectID 字段中列出的项目。
在显示的页面上的过滤条件框中，输入主账号电子邮件地址中列出的账号名称，并检查授予的角色。

第 3 步：检查日志

在发现结果详情面板的“摘要”标签页上，点击 Cloud Logging URI 链接以打开日志浏览器。
如有必要，请选择您的项目。
在加载的页面上，使用以下过滤条件检查新的或更新后的 IAM 资源中的活动日志：
- protoPayload.methodName="SetIamPolicy"
- protoPayload.methodName="google.iam.admin.v1.UpdateRole"
- protoPayload.methodName="google.iam.admin.v1.CreateRole"
- protoPayload.authenticationInfo.principalEmail="principalEmail"

第 4 步：研究攻击和响应方法

查看此发现结果类型的 MITRE ATT&CK 框架条目：有效账号：云账号。
如需制定响应方案，请将您的调查结果与 MITRE 研究相结合。

第 5 步：实现响应

以下响应方案可能适合此发现结果，但也可能会影响运营。请仔细评估您在研究中收集的信息，以确定解析发现结果的最佳方法。

与账号被盗用的项目的所有者联系。
查看 anomalousLocation、typicalGeolocations 和 notSeenInLast 字段，以验证访问是否异常以及账号是否被盗用。
删除未经授权的账号创建的项目资源，例如不熟悉的 Compute Engine 实例、快照、服务账号和 IAM 用户。
如需将新资源的创建限制在特定区域，请参阅限制资源位置。
如需识别并修正过于宽松的角色，请使用 IAM Recommender。

`Persistence: New User Agent`

此发现结果不适用于项目级激活。

IAM 服务账号按异常用户代理所指示使用可疑的软件访问 Google Cloud。

第 1 步：查看发现结果详情

按照本页面前面部分的查看发现结果详情中所述，打开 Persistence: New User Agent 发现结果。系统会打开发现结果详情面板，以显示摘要标签页。
在摘要标签页上，查看以下部分中的信息：
- 检测到的内容，尤其是以下字段：
  - 主账号电子邮件地址：可能被盗用的服务账号。
- 受影响的资源，尤其是以下字段：
  - 项目全名：包含可能被盗用的服务账号的项目。
- 相关链接，尤其是以下字段：
  - Cloud Logging URI：指向 Logging 条目的链接。
  - MITRE ATT&CK 方法：指向 MITRE ATT&CK 文档的链接。
  - 相关发现结果：指向任何相关发现结果的链接。
1. 在发现结果的详情视图中，点击 JSON 标签页。
2. 在 JSON 中，记下以下字段。
- projectId：包含可能被盗用的服务账号的项目。
- callerUserAgent：异常用户代理。
- anomalousSoftwareClassification：软件类型。
- notSeenInLast：用于建立正常行为基准的时间段。

第 2 步：查看项目和账号权限

在 Google Cloud 控制台中，转到 IAM 页面。

转到 IAM
如有必要，选择 projectId 中列出的项目。
在显示的页面上的过滤条件框中，输入发现结果详情摘要标签页中主账号电子邮件地址行上列出的账号名称，并检查授予的角色。
在 Google Cloud 控制台中，转到服务账号页面。

转到“服务账号”
在显示的页面上的过滤条件框中，输入发现结果详情摘要标签页中主账号电子邮件地址行上列出的账号名称。
检查该服务账号的密钥和密钥创建日期。

第 3 步：检查日志

在发现结果详情面板的“摘要”标签页上，点击 Cloud Logging URI 链接以打开日志浏览器。
如有必要，请选择您的项目。
在加载的页面上，使用以下过滤条件检查新的或更新后的 IAM 资源中的活动日志：
- proto_payload.method_name="google.iam.admin.v1.CreateServiceAccount"
- protoPayload.methodName="SetIamPolicy"
- protoPayload.methodName="google.iam.admin.v1.UpdateRole"
- protoPayload.methodName="google.iam.admin.v1.CreateRole"
- protoPayload.authenticationInfo.principalEmail="principalEmail"

第 4 步：研究攻击和响应方法

查看此发现结果类型的 MITRE ATT&CK 框架条目：有效账号：云账号。
如需制定响应方案，请将您的调查结果与 MITRE 研究相结合。

第 5 步：实现响应

以下响应方案可能适合此发现结果，但也可能会影响运营。请仔细评估您在研究中收集的信息，以确定解析发现结果的最佳方法。

与账号被盗用的项目的所有者联系。
查看 anomalousSoftwareClassification、callerUserAgent 和 behaviorPeriod 字段，以验证访问是否异常以及账号是否被盗用。
删除未经授权的账号创建的项目资源，例如不熟悉的 Compute Engine 实例、快照、服务账号和 IAM 用户。
如需将新资源的创建限制在特定区域，请参阅限制资源位置。
如需识别并修正过于宽松的角色，请使用 IAM Recommender。

`Privilege Escalation: Changes to sensitive Kubernetes RBAC objects`

为了提升特权，潜在恶意操作者尝试使用 PUT 或 PATCH 请求修改敏感 cluster-admin 角色的 ClusterRole、RoleBinding 或 ClusterRoleBinding 基于角色的访问权限控制 (RBAC) 对象。

第 1 步：查看发现结果详情

按照查看发现结果中所述，打开 Privilege Escalation: Changes to sensitive Kubernetes RBAC objects 发现结果。系统会打开发现结果详情面板，以显示摘要标签页。
在摘要标签页上，查看以下部分中的信息：
- 检测到的内容，尤其是以下字段：
  - 主账号电子邮件地址：发出调用的账号。
  - 方法名称：所调用的方法。
  - Kubernetes 绑定：已修改的敏感 Kubernetes 绑定或 ClusterRoleBinding。
- 受影响的资源，尤其是以下字段：
  - 资源显示名称：执行操作的 Kubernetes 集群。
- 相关链接，尤其是以下字段：
  - Cloud Logging URI：指向 Logging 条目的链接。
  - MITRE ATT&CK 方法：指向 MITRE ATT&CK 文档的链接。
  - 相关发现结果：指向任何相关发现结果的链接。
在检测到的内容部分中，点击 Kubernetes 绑定行上的绑定的名称。系统会显示绑定详细信息。
在显示的绑定中，请注意绑定详细信息。

第 2 步：检查日志

在 Google Cloud 控制台中发现结果详情的摘要标签页上，通过点击 Cloud Logging URI 字段中的链接转到日志浏览器。
如果方法名称中的值是 PATCH 方法，请检查请求正文，了解哪些属性已被修改。

在 update (PUT) 调用中，系统会在请求中发送整个对象，因此更改不太明显。
使用以下过滤条件检查主账号执行的其他操作：
- resource.labels.cluster_name="CLUSTER_NAME"
- protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"
  
  请替换以下内容：
- CLUSTER_NAME：您在发现结果详情的资源显示名称字段中记下的值。
- PRINCIPAL_EMAIL：您在发现结果详情的主账号电子邮件地址字段中记下的值。

第 3 步：研究攻击和响应方法

查看此发现结果类型的 MITRE ATT&CK 框架条目：提升权限
确认对象的敏感度以及是否有必要进行修改。
对于绑定，您可以检查主体，并调查主体是否需要其绑定到的角色。
确定日志中是否存在主账号的其他恶意活动迹象。
如果主账号电子邮件地址不是服务账号，请与该账号的所有者联系，以确认合法所有者是否执行了该操作。

如果主账号电子邮件地址是服务账号（IAM 或 Kubernetes），请查明修改来源以确定其合法性。
如需制定响应方案，请将您的调查结果与 MITRE 研究相结合。

`Privilege Escalation: Create Kubernetes CSR for master cert`

为了提升特权，潜在恶意操作者创建了 Kubernetes 主实例证书签名请求 (CSR)，用于向其授予 cluster-admin 访问权限。

第 1 步：查看发现结果详情

按照查看发现结果中所述，打开 Privilege Escalation: Create Kubernetes CSR for master cert 发现结果。系统会打开发现结果详情面板，以显示摘要标签页。
在摘要标签页上，查看以下部分中的信息：
- 检测到的内容，尤其是以下字段：
  - 主账号电子邮件地址：发出调用的账号。
  - 方法名称：所调用的方法。
- 受影响的资源，尤其是以下字段：
  - 资源显示名称：执行操作的 Kubernetes 集群。
- 相关链接，尤其是以下字段：
  - Cloud Logging URI：指向 Logging 条目的链接。
  - MITRE ATT&CK 方法：指向 MITRE ATT&CK 文档的链接。
  - 相关发现结果：指向任何相关发现结果的链接。

第 2 步：检查日志

在 Google Cloud 控制台中发现结果详情的摘要标签页上，通过点击 Cloud Logging URI 字段中的链接转到日志浏览器。
查看 protoPayload.resourceName 字段中的值以识别特定的证书签名请求。
使用以下过滤条件检查主账号执行的其他操作：
- resource.labels.cluster_name="CLUSTER_NAME"
- protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"
  
  请替换以下内容：
- CLUSTER_NAME：您在发现结果详情的资源显示名称字段中记下的值。
- PRINCIPAL_EMAIL：您在发现结果详情的主账号电子邮件地址字段中记下的值。

第 3 步：研究攻击和响应方法

查看此发现结果类型的 MITRE ATT&CK 框架条目：提升权限。
调查是否有必要向 cluster-admin 授予访问权限。
如果主账号电子邮件地址不是服务账号，请与该账号的所有者联系，以确认合法所有者是否执行了该操作。

如果主账号电子邮件地址是服务账号（IAM 或 Kubernetes），请查明操作来源以确定其合法性。
如需制定响应方案，请将您的调查结果与 MITRE 研究相结合。

`Privilege Escalation: Creation of sensitive Kubernetes bindings`

为了提升特权，潜在恶意操作者尝试为 cluster-admin 角色创建新的 RoleBinding 或 ClusterRoleBinding 对象。

第 1 步：查看发现结果详情

按照查看发现结果中所述，打开 Privilege Escalation: Creation of sensitive Kubernetes bindings 发现结果。系统会打开发现结果详情面板，以显示摘要标签页。
在摘要标签页上，查看以下部分中的信息：
- 检测到的内容，尤其是以下字段：
  - 主账号电子邮件地址：发出调用的账号。
  - Kubernetes 绑定：已创建的敏感 Kubernetes 绑定或 ClusterRoleBinding。
- 受影响的资源，尤其是以下字段：
  - 资源显示名称：执行操作的 Kubernetes 集群。
- 相关链接，尤其是以下字段：
  - Cloud Logging URI：指向 Logging 条目的链接。
  - MITRE ATT&CK 方法：指向 MITRE ATT&CK 文档的链接。
  - 相关发现结果：指向任何相关发现结果的链接。

第 2 步：检查日志

在 Google Cloud 控制台中发现结果详情的摘要标签页上，通过点击 Cloud Logging URI 字段中的链接转到日志浏览器。
使用以下过滤条件检查主账号执行的其他操作：
- resource.labels.cluster_name="CLUSTER_NAME"
- protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"
  
  请替换以下内容：
- CLUSTER_NAME：您在发现结果详情的资源显示名称字段中记下的值。
- PRINCIPAL_EMAIL：您在发现结果详情的主账号电子邮件地址字段中记下的值。

第 3 步：研究攻击和响应方法

查看此发现结果类型的 MITRE ATT&CK 框架条目：提升权限。
确认已创建的绑定的敏感性以及主体是否需要这些角色。
对于绑定，您可以检查主体，并调查主体是否需要其绑定到的角色。
确定日志中是否存在主账号的其他恶意活动迹象。
如果主账号电子邮件地址不是服务账号，请与该账号的所有者联系，以确认合法所有者是否执行了该操作。

如果主账号电子邮件地址是服务账号（IAM 或 Kubernetes），请查明操作来源以确定其合法性。
如需制定响应方案，请将您的调查结果与 MITRE 研究相结合。

`Privilege Escalation: Effectively Anonymous Users Granted GKE Cluster Access`

有人创建了引用以下某个用户或群组的 RBAC 绑定：

system:anonymous
system:authenticated
system:unauthenticated

这些用户和群组实际上是匿名的，因此在向任何 RBAC 角色创建角色绑定或集群角色绑定时，应避免使用它们。检查绑定，确保其必要性。如果不需要该绑定，请将其移除。如需了解详情，请参阅此发现的日志消息。

查看向 system:anonymous 用户、system:unauthenticated group 或 system:authenticated 群组授予了权限的任何已创建的绑定。
确定 Cloud Logging 的审核日志中是否存在主账号执行的其他恶意活动迹象。

如果存在恶意活动迹象，请查看相关指南以了解如何调查和移除允许此访问的绑定。

`Privilege Escalation: Get Kubernetes CSR with compromised bootstrap credentials`

为了提升特权，潜在恶意操作者使用 kubectl 命令和被破解的引导凭据查询了证书签名请求 (CSR)。

以下是此规则检测到的命令示例：

kubectl --client-certificate kubelet.crt --client-key kubelet.key --server YOUR_SERVER get csr CSR_NAME

第 1 步：查看发现结果详情

按照查看发现结果中所述，打开 Privilege Escalation: Get Kubernetes CSR with compromised bootstrap credentials 发现结果。系统会打开发现结果详情面板，以显示摘要标签页。
在摘要标签页上，查看以下部分中的信息：
- 检测到的内容，尤其是以下字段：
  - 主账号电子邮件地址：发出调用的账号。
  - 方法名称：所调用的方法。
- 在受影响的资源下：
  - 资源显示名称：执行操作的 Kubernetes 集群。
- 相关链接，尤其是以下字段：
  - Cloud Logging URI：指向 Logging 条目的链接。
  - MITRE ATT&CK 方法：指向 MITRE ATT&CK 文档的链接。
  - 相关发现结果：指向任何相关发现结果的链接。

第 2 步：检查日志

如果您在发现结果详情的方法名称字段中记下的方法名称是 GET 方法，请执行以下操作：

在 Google Cloud 控制台中发现结果详情的摘要标签页上，通过点击 Cloud Logging URI 字段中的链接转到日志浏览器。
查看 protoPayload.resourceName 字段中的值以识别特定的证书签名请求。

第 3 步：研究攻击和响应方法

查看此发现结果类型的 MITRE ATT&CK 框架条目：提升权限。
如果日志条目中包含特定 CSR，请调查证书的敏感度以及是否有必要执行该操作。
如需制定响应方案，请将您的调查结果与 MITRE 研究相结合。

`Privilege Escalation: Launch of privileged Kubernetes container`

潜在恶意操作者创建了包含特权容器或具有提升特权功能的容器的 Pod。

特权容器的 privileged 字段设置为 true。具有提权能力的容器的 allowPrivilegeEscalation 字段设置为 true。如需了解详情，请参阅 Kubernetes 文档中的 SecurityContext v1 core API 参考。

第 1 步：查看发现结果详情

按照查看发现结果中所述，打开 Privilege Escalation: Launch of privileged Kubernetes container 发现结果。系统会打开发现结果详情面板，以显示摘要标签页。
在摘要标签页上，查看以下部分中的信息：
- 检测到的内容，尤其是以下字段：
  - 主账号电子邮件地址：发出调用的账号。
  - Kubernetes pod：新创建的具有特权容器的 Pod。
- 受影响的资源，尤其是以下字段：
  - 资源显示名称：执行操作的 Kubernetes 集群。
- 相关链接，尤其是以下字段：
  - Cloud Logging URI：指向 Logging 条目的链接。
  - MITRE ATT&CK 方法：指向 MITRE ATT&CK 文档的链接。
  - 相关发现结果：指向任何相关发现结果的链接。
在 JSON 标签页上，记下发现结果字段的值：
- findings.kubernetes.pods[].containers：在 Pod 中出现的特权容器。

第 2 步：检查日志

在 Google Cloud 控制台中发现结果详情的摘要标签页上，通过点击 Cloud Logging URI 字段中的链接转到日志浏览器。
使用以下过滤条件检查主账号执行的其他操作：
- resource.labels.cluster_name="CLUSTER_NAME"
- protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"
  
  请替换以下内容：
- CLUSTER_NAME：您在发现结果详情的资源显示名称字段中记下的值。
- PRINCIPAL_EMAIL：您在发现结果详情的主账号电子邮件地址字段中记下的值。

第 3 步：研究攻击和响应方法

查看此发现结果类型的 MITRE ATT&CK 框架条目：提升权限。
确认创建的容器需要访问主机资源和内核功能。
确定日志中是否存在主账号的其他恶意活动迹象。
如果主账号电子邮件地址不是服务账号，请与该账号的所有者联系，以确认合法所有者是否执行了该操作。

如果主账号电子邮件地址是服务账号（IAM 或 Kubernetes），请查明操作来源以确定其合法性。
如需制定响应方案，请将您的调查结果与 MITRE 研究相结合。

`Privilege Escalation: Dormant Service Account Granted Sensitive Role`

检测向休眠的用户管理的服务账号授予敏感 IAM 角色的事件。在此上下文中，如果服务账号处于非活跃状态超过 180 天，则会被视为休眠。

如需响应此发现结果，请执行以下操作：

第 1 步：查看发现结果详情

按照查看发现结果中所述，打开 Privilege Escalation: Dormant Service Account Granted Sensitive Role 发现结果。
在发现结果详情的摘要标签页上，记下以下字段的值。

在检测到的内容下：
- 主账号电子邮件地址：执行授予角色操作的用户
- 违规访问授权主账号名称：接受敏感角色的休眠服务账号
- 违规访问授权授予的角色：分配的敏感 IAM 角色
在受影响的资源下：
- 资源显示名称：向休眠服务账号授予敏感 IAM 角色的组织、文件夹或项目。

第 2 步：研究攻击和响应方法

使用服务账号工具（如活动分析器）调查休眠服务账号的活动。
与主账号电子邮件地址字段的所有者联系。确认合法所有者是否执行了此操作。

第 3 步：检查日志

在发现结果详情面板的摘要标签页上，点击相关链接下的 Cloud Logging URI 链接以打开 Logs Explorer。

第 4 步：实现响应

以下响应方案可能适合此发现结果，但也可能会影响运营。请仔细评估您在研究中收集的信息，以确定解析发现结果的最佳方法。

与执行操作的项目的所有者联系。
如果主账号电子邮件地址被盗用，请移除其所有者的访问权限。
从休眠服务账号中移除新分配的敏感 IAM 角色。
考虑删除可能被盗用的服务账号，然后轮替和删除可能被破解的项目的所有服务账号访问密钥。删除后，使用该服务账号进行身份验证的资源会失去访问权限。在继续操作之前，您的安全团队应确定所有受影响的资源并与资源所有者合作，以确保业务连续性。
与您的安全团队合作，确定不熟悉的资源，包括 Compute Engine 实例、快照、服务账号和 IAM 用户。删除未使用已获授权的账号创建的资源。
响应来自 Cloud Customer Care 的任何通知。
如需限制谁可以创建服务账号，请使用组织政策服务。
如需识别并修正过于宽松的角色，请使用 IAM Recommender。

`Privilege Escalation: Anomalous Impersonation of Service Account for Admin Activity`

通过检查管理员活动审核日志以查看服务账号模拟请求中是否出现任何异常值，可检测服务账号的异常模拟。

如需响应此发现结果，请执行以下操作：

第 1 步：查看发现结果详情

按照查看发现结果中所述，打开 Privilege Escalation: Anomalous Impersonation of Service Account for Admin Activity 发现结果。系统会打开发现结果详情面板，以显示摘要标签页。
在摘要标签页上，查看以下部分中的信息：
- 检测到的内容，尤其是以下字段：
  - 主账号电子邮件地址：模拟请求中用于访问 Google Cloud 的最终服务账号。
  - 服务名称：模拟请求所涉及的 Google Cloud 服务的 API 名称。
  - 方法名称：所调用的方法。
  - 服务账号委托信息：委托链中服务账号的详细信息，列表底部的主账号是模拟请求的调用方。
- 受影响的资源，尤其是以下字段：
  - 资源全名：集群的名称。
- 相关链接，尤其是以下字段：
  - Cloud Logging URI：指向 Logging 条目的链接。
  - MITRE ATT&CK 方法：指向 MITRE ATT&CK 文档的链接。
  - 相关发现结果：指向任何相关发现结果的链接。

第 2 步：研究攻击和响应方法

在主账号电子邮件地址字段中与服务账号的所有者联系。确认合法所有者是否执行了此操作。
调查委托链中的主账号，以验证请求是否异常以及是否有任何账号被盗用。
在服务账号委托信息列表中与模拟调用者的所有者联系。确认合法所有者是否执行了此操作。

第 3 步：实现响应

以下响应方案可能适合此发现结果，但也可能会影响运营。请仔细评估您在研究中收集的信息，以确定解析发现结果的最佳方法。

与执行操作的项目的所有者联系。
考虑删除可能被盗用的服务账号，然后轮替和删除可能被破解的项目的所有服务账号访问密钥。删除后，使用该服务账号进行身份验证的资源会失去访问权限。在继续操作之前，您的安全团队应确定所有受影响的资源并与资源所有者合作，以确保业务连续性。
与您的安全团队合作，确定不熟悉的资源，包括 Compute Engine 实例、快照、服务账号和 IAM 用户。删除未使用已获授权的账号创建的资源。
回复来自 Google Cloud 支持的任何通知。
如需限制谁可以创建服务账号，请使用组织政策服务。
如需识别并修正过于宽松的角色，请使用 IAM Recommender。

`Privilege Escalation: Anomalous Multistep Service Account Delegation for Admin Activity`

通过检查管理员活动审核日志来查看服务账号模拟请求中是否出现任何异常，检测到 Anomalous Multistep Service Account Delegation。

如需响应此发现结果，请执行以下操作：

第 1 步：查看发现结果详情

按照查看发现结果中所述，打开 Privilege Escalation: Anomalous Multistep Service Account Delegation for Admin Activity 发现结果。系统会打开发现结果详情面板，以显示摘要标签页。
在摘要标签页上，查看以下部分中的信息：
- 检测到的内容，尤其是以下字段：
  - 主账号电子邮件地址：模拟请求中用于访问 Google Cloud 的最终服务账号。
  - 服务名称：模拟请求所涉及的 Google Cloud 服务的 API 名称。
  - 方法名称：所调用的方法。
  - 服务账号委托信息：委托链中服务账号的详细信息，列表底部的主账号是模拟请求的调用方。
- 受影响的资源
- 相关链接，尤其是以下字段：
  - Cloud Logging URI：指向 Logging 条目的链接。
  - MITRE ATT&CK 方法：指向 MITRE ATT&CK 文档的链接。
  - 相关发现结果：指向任何相关发现结果的链接。

第 2 步：研究攻击和响应方法

在主账号电子邮件地址字段中与服务账号的所有者联系。确认合法所有者是否执行了此操作。
调查委托链中的主账号，以验证请求是否异常以及是否有任何账号被盗用。
在服务账号委托信息列表中与模拟调用者的所有者联系。确认合法所有者是否执行了此操作。

第 3 步：实现响应

以下响应方案可能适合此发现结果，但也可能会影响运营。请仔细评估您在研究中收集的信息，以确定解析发现结果的最佳方法。

与执行操作的项目的所有者联系。
考虑删除可能被盗用的服务账号，然后轮替和删除可能被破解的项目的所有服务账号访问密钥。删除后，使用该服务账号进行身份验证的资源会失去访问权限。在继续操作之前，您的安全团队应确定所有受影响的资源并与资源所有者合作，以确保业务连续性。
与您的安全团队合作，确定不熟悉的资源，包括 Compute Engine 实例、快照、服务账号和 IAM 用户。删除未使用已获授权的账号创建的资源。
回复来自 Google Cloud 支持的任何通知。
如需限制谁可以创建服务账号，请使用组织政策服务。
如需识别并修正过于宽松的角色，请使用 IAM Recommender。

`Privilege Escalation: Anomalous Multistep Service Account Delegation for Data Access`

通过检查数据访问审核日志来查看服务账号模拟请求中是否出现任何异常，检测到 Anomalous Multistep Service Account Delegation。

如需响应此发现结果，请执行以下操作：

第 1 步：查看发现结果详情

按照查看发现结果中所述，打开 Privilege Escalation: Anomalous Multistep Service Account Delegation for Data Access 发现结果。系统会打开发现结果详情面板，以显示摘要标签页。
在摘要标签页上，查看以下部分中的信息：
- 检测到的内容，尤其是以下字段：
  - 主账号电子邮件地址：用于访问 Google Cloud 的模拟请求中的最终服务账号
  - 服务名称：模拟请求所涉及的 Google Cloud 服务的 API 名称
  - 方法名称：所调用的方法
  - 服务账号委托信息：委托链中服务账号的详细信息，列表底部的主账号是模拟请求的调用方
- 受影响的资源
- 相关链接，尤其是以下字段：
  - Cloud Logging URI：指向 Logging 条目的链接。
  - MITRE ATT&CK 方法：指向 MITRE ATT&CK 文档的链接。
  - 相关发现结果：指向任何相关发现结果的链接。

第 2 步：研究攻击和响应方法

在主账号电子邮件地址字段中与服务账号的所有者联系。确认合法所有者是否执行了此操作。
调查委托链中的主账号，以验证请求是否异常以及是否有任何账号被盗用。
在服务账号委托信息列表中与模拟调用者的所有者联系。确认合法所有者是否执行了此操作。

第 3 步：实现响应

以下响应方案可能适合此发现结果，但也可能会影响运营。请仔细评估您在研究中收集的信息，以确定解析发现结果的最佳方法。

与执行操作的项目的所有者联系。
考虑删除可能被盗用的服务账号，然后轮替和删除可能被破解的项目的所有服务账号访问密钥。删除后，使用该服务账号进行身份验证的资源会失去访问权限。在继续操作之前，您的安全团队应确定所有受影响的资源并与资源所有者合作，以确保业务连续性。
与您的安全团队合作，确定不熟悉的资源，包括 Compute Engine 实例、快照、服务账号和 IAM 用户。删除未使用已获授权的账号创建的资源。
回复来自 Google Cloud 支持的任何通知。
如需限制谁可以创建服务账号，请使用组织政策服务。
如需识别并修正过于宽松的角色，请使用 IAM Recommender。

`Privilege Escalation: Anomalous Service Account Impersonator for Admin Activity`

通过检查管理员活动审核日志来查看服务账号模拟请求中是否出现任何异常，检测到 Anomalous Service Account Impersonator。

如需响应此发现结果，请执行以下操作：

第 1 步：查看发现结果详情

按照查看发现结果中所述，打开 Privilege Escalation: Anomalous Service Account Impersonator for Admin Activity 发现结果。系统会打开发现结果详情面板，以显示摘要标签页。
在摘要标签页上，查看以下部分中的信息：
- 检测到的内容，尤其是以下字段：
  - 主账号电子邮件地址：用于访问 Google Cloud 的模拟请求中的最终服务账号
  - 服务名称：模拟请求所涉及的 Google Cloud 服务的 API 名称
  - 方法名称：所调用的方法
  - 服务账号委托信息：委托链中服务账号的详细信息，列表底部的主账号是模拟请求的调用方
- 受影响的资源
- 相关链接，尤其是以下字段：
  - Cloud Logging URI：指向 Logging 条目的链接。
  - MITRE ATT&CK 方法：指向 MITRE ATT&CK 文档的链接。
  - 相关发现结果：指向任何相关发现结果的链接。

第 2 步：研究攻击和响应方法

在主账号电子邮件地址字段中与服务账号的所有者联系。确认合法所有者是否执行了此操作。
调查委托链中的主账号，以验证请求是否异常以及是否有任何账号被盗用。
在服务账号委托信息列表中与模拟调用者的所有者联系。确认合法所有者是否执行了此操作。

第 3 步：实现响应

以下响应方案可能适合此发现结果，但也可能会影响运营。请仔细评估您在研究中收集的信息，以确定解析发现结果的最佳方法。

与执行操作的项目的所有者联系。
考虑删除可能被盗用的服务账号，然后轮替和删除可能被破解的项目的所有服务账号访问密钥。删除后，使用该服务账号进行身份验证的资源会失去访问权限。在继续操作之前，您的安全团队应确定所有受影响的资源并与资源所有者合作，以确保业务连续性。
与您的安全团队合作，确定不熟悉的资源，包括 Compute Engine 实例、快照、服务账号和 IAM 用户。删除未使用已获授权的账号创建的资源。
回复来自 Google Cloud 支持的任何通知。
如需限制谁可以创建服务账号，请使用组织政策服务。
如需识别并修正过于宽松的角色，请使用 IAM Recommender。

`Privilege Escalation: Anomalous Service Account Impersonator for Data Access`

通过检查数据访问审核日志以查看服务账号模拟请求中是否出现任何异常值，可检测异常服务账号模拟者。

如需响应此发现结果，请执行以下操作：

第 1 步：查看发现结果详情

按照查看发现结果中所述，打开 Privilege Escalation: Anomalous Service Account Impersonator for Data Access 发现结果。
在发现结果详情的摘要标签页上，记下以下字段的值。

在检测到的内容下：
- 主账号电子邮件地址：用于访问 Google Cloud 的模拟请求中的最终服务账号
- 服务名称：模拟请求所涉及的 Google Cloud 服务的 API 名称
- 方法名称：所调用的方法
- 服务账号委托信息：委托链中服务账号的详细信息，列表底部的主账号是模拟请求的调用方

第 2 步：研究攻击和响应方法

在主账号电子邮件地址字段中与服务账号的所有者联系。确认合法所有者是否执行了此操作。
调查委托链中的主账号，以验证请求是否异常以及是否有任何账号被盗用。
在服务账号委托信息列表中与模拟调用者的所有者联系。确认合法所有者是否执行了此操作。

第 3 步：实现响应

以下响应方案可能适合此发现结果，但也可能会影响运营。请仔细评估您在研究中收集的信息，以确定解析发现结果的最佳方法。

与执行操作的项目的所有者联系。
考虑删除可能被盗用的服务账号，然后轮替和删除可能被破解的项目的所有服务账号访问密钥。删除后，使用该服务账号进行身份验证的资源会失去访问权限。在继续操作之前，您的安全团队应确定所有受影响的资源并与资源所有者合作，以确保业务连续性。
与您的安全团队合作，确定不熟悉的资源，包括 Compute Engine 实例、快照、服务账号和 IAM 用户。删除未使用已获授权的账号创建的资源。
回复来自 Google Cloud 支持的任何通知。
如需限制谁可以创建服务账号，请使用组织政策服务。
如需识别并修正过于宽松的角色，请使用 IAM Recommender。

`Privilege Escalation: ClusterRole with Privileged Verbs`

某人创建了一个包含 bind、escalate 或 impersonate 动词的 RBAC ClusterRole 对象。绑定到具有这些动词的角色的正文可以冒充具有更高特权的其他用户、绑定到包含其他权限的其他 Role 或 ClusterRole 对象，或修改自己的 ClusterRole 权限。这可能会导致这些正文获得 cluster-admin 权限。如需了解详情，请参阅此提醒的日志消息。

查看 ClusterRole 和关联的 ClusterRoleBindings，以确认正文是否确实需要这些权限。
如果可能，请避免创建涉及 bind、escalate 或 impersonate 动词的角色。
确定 Cloud Logging 的审核日志中是否存在主账号执行的其他恶意活动迹象。
在 RBAC 角色中分配权限时，请遵循最小权限原则并授予执行任务所需的最低权限。使用最小权限原则可以降低集群被盗用时提升权限的可能性，并降低过度访问权限导致安全事件的可能性。

`Privilege Escalation: ClusterRoleBinding to Privileged Role`

有人创建了一个引用默认 system:controller:clusterrole-aggregation-controller ClusterRole 的 RBAC ClusterRoleBinding。此默认 ClusterRole 具有 escalate 动词，允许正文修改自己的角色的权限，从而导致权限提升。如需了解详情，请参阅此提醒的日志消息。

检查引用 system:controller:clusterrole-aggregation-controller ClusterRole 的所有 ClusterRoleBinding。
查看对 system:controller:clusterrole-aggregation-controller ClusterRole 所做的任何修改。
确定 Cloud Logging 的审核日志中是否存在创建了 ClusterRoleBinding 的主账号执行的其他恶意活动迹象。

`Privilege Escalation: Suspicious Kubernetes Container Names - Exploitation and Escape`

某人部署了一个命名惯例类似于用于容器逃逸或在集群上执行其他攻击的常用工具的 Pod。如需了解详情，请参阅此提醒的日志消息。

确认 Pod 是合法的。
确定 Cloud Logging 的审核日志中是否存在来自 Pod 或主账号的其他恶意活动迹象。
如果主账号不是服务账号（IAM 或 Kubernetes），请与该账号的所有者联系，以确认合法所有者是否执行了相应操作。
如果主账号是服务账号（IAM 或 Kubernetes），请查明操作来源以确定其合法性。
如果 Pod 不合法，请将其移除，同时移除任何关联的 RBAC 绑定，以及工作负载使用的和允许其创建的服务账号。

`Privilege Escalation: Workload Created with a Sensitive Host Path Mount`

某人创建了一个工作负载，其中包含一个 hostPath 卷，该卷已装载到主机节点文件系统上的敏感路径。访问主机文件系统上的这些路径可用于访问节点上的特权或敏感信息，以及用于容器逃逸。请尽可能不要在集群中允许任何 hostPath 卷。如需了解详情，请参阅此提醒的日志消息。

查看工作负载，确定是否必须使用此 hostPath 卷才能实现预期功能。如果是，请确保路径指向尽可能具体的目录。例如，使用 /etc/myapp/myfiles，而不是 / 或 /etc。
确定 Cloud Logging 的审核日志中是否存在与此工作负载相关的其他恶意活动迹象。

如需在集群中阻止 hostPath 卷装载，请参阅相关指南以了解如何强制执行 Pod 安全标准。

`Privilege Escalation: Workload with shareProcessNamespace enabled`

某位用户部署了一个工作负载，并将 shareProcessNamespace 选项设置为 true，以允许所有容器共享相同的 Linux 进程命名空间。这可能会导致不可信或已被入侵的容器通过访问和控制其他容器中运行的进程的环境变量、内存和其他敏感数据来提升权限。某些工作负载可能出于合法原因需要运行此功能，例如日志处理边车容器或调试容器。如需了解详情，请参阅此提醒的日志消息。

确认工作负载确实需要访问工作负载中所有容器的共享进程命名空间。
检查 Cloud Logging 的审核日志中是否存在主账号执行的其他恶意活动迹象。
如果主账号不是服务账号（IAM 或 Kubernetes），请与该账号的所有者联系，以确认他们是否执行了相应操作。
如果主账号是服务账号（IAM 或 Kubernetes），请查明是什么导致服务账号执行此操作及其合法性。

`Service account self-investigation`

使用服务账号凭据来调查与同一服务账号关联的角色和权限。此发现结果表明服务账号凭据被破解，应立即采取措施。

第 1 步：查看发现结果详情

按照本页面前面部分的查看发现结果详情中所述，打开 Discovery: Service Account Self-Investigation 发现结果。系统会打开发现结果详情面板，以显示摘要标签页。
在摘要标签页上，查看以下部分中的信息：
- 检测到的内容，尤其是以下字段：
  - 严重级别：分配给发现结果的风险级别。如果触发此发现结果的 API 调用未经授权，则严重级别为 HIGH；服务账号无权使用 projects.getIamPolicy API 查询其自己的 IAM 权限。
  - 主账号电子邮件地址：可能被盗用的服务账号。
  - 调用方 IP 地址：内部或外部 IP 地址
- 受影响的资源，尤其是以下字段：
  - 资源全名：
  - 项目全名：包含可能已泄露的账号凭据的项目。
- 相关链接，尤其是以下字段：
  - Cloud Logging URI：指向 Logging 条目的链接。
  - MITRE ATT&CK 方法：指向 MITRE ATT&CK 文档的链接。
  - 相关发现结果：指向任何相关发现结果的链接。
1. 如需查看发现结果的完整 JSON，请点击 JSON 标签页。

第 2 步：查看项目和服务账号权限

在 Google Cloud 控制台中，转到 IAM 页面。

转到 IAM
如有必要，请选择发现结果 JSON 的 projectID 字段中列出的项目。
在显示的页面上的过滤条件框中，输入主账号电子邮件地址中列出的账号名称，并检查分配的权限。
在 Google Cloud 控制台中，转到服务账号页面。

转到“服务账号”
在显示的页面上的过滤条件框中，输入被盗用的服务账号的名称，并检查该服务账号的密钥和密钥创建日期。

第 3 步：检查日志

在发现结果详情面板的“摘要”标签页上，点击 Cloud Logging URI 链接以打开日志浏览器。
如有必要，请选择您的项目。
在加载的页面上，使用以下过滤条件检查新的或更新后的 IAM 资源中的活动日志：
- proto_payload.method_name="google.iam.admin.v1.CreateServiceAccount"
- protoPayload.methodName="SetIamPolicy"
- protoPayload.authenticationInfo.principalEmail="principalEmail"

第 4 步：研究攻击和响应方法

查看发现结果类型的 MITRE ATT&CK 框架条目：权限组发现：Cloud Groups。
如需制定响应方案，请将您的调查结果与 MITRE 研究相结合。

第 5 步：实现响应

以下响应方案可能适合此发现结果，但也可能会影响运营。请仔细评估您在研究中收集的信息，以确定解析发现结果的最佳方法。

与账号被盗用的项目的所有者联系。
删除被盗用的服务账号，然后轮替和删除被破解的项目的所有服务账号访问密钥。删除后，使用该服务账号进行身份验证的资源会失去访问权限。
删除被盗用的账号创建的项目资源，例如不熟悉的 Compute Engine 实例、快照、服务账号和 IAM 用户。

`Inhibit System Recovery: Deleted Google Cloud Backup and DR host`

Event Threat Detection 会检查审核日志，以检测运行受备份和灾难恢复服务保护的应用的主机是否被删除。主机被删除后，与主机关联的应用将无法备份。

如需响应此发现结果，请执行以下操作：

第 1 步：查看发现结果详情

按照查看发现结果中所述，打开 Inhibit System Recovery: Deleted Google Cloud Backup and DR host 发现结果。系统会打开发现结果详情面板，以显示摘要标签页。
在摘要标签页上，查看以下部分中的信息：
- 检测到的内容，尤其是以下字段：
  - 应用名称：与备份和灾难恢复关联的数据库或虚拟机的名称
  - 主机名：连接到备份和灾难恢复的主机的名称
  - 主账号主体：已成功执行操作的用户
- 受影响的资源
  - 资源显示名称：删除主机所在的项目
- 相关链接，尤其是以下字段：
  - MITRE ATTACK 方法：指向 MITRE ATT&CK 文档的链接
  - Logging URI：用于打开 Logs Explorer 的链接

第 2 步：研究攻击和响应方法

在主账号电子邮件地址字段中与服务账号的所有者联系。确认合法所有者是否执行了此操作。

第 3 步：实现响应

以下响应方案可能适合此发现结果。请仔细评估您在调查中收集的信息，以确定解析发现结果的最佳方法。

在执行操作的项目中，转到管理控制台。
确认已删除的主机不再位于备份和灾难恢复主机列表中。
选择添加主机选项，重新添加已删除的主机。

`Inhibit System Recovery: Google Cloud Backup and DR remove plan`

Security Command Center 会检查审核日志，以检测用于将备份政策应用于应用的 Backup and DR Service 备份方案异常删除的情况。

第 1 步：查看发现结果详情

按照查看发现结果中所述，打开 Inhibit System Recovery: Google Cloud Backup and DR remove plan 发现结果。系统会打开发现结果详情面板，以显示摘要标签页。
在摘要标签页上，查看以下部分中的信息：
- 检测到的内容，尤其是以下字段：
  - 应用名称：与备份和灾难恢复关联的数据库或虚拟机的名称
  - 配置文件名称：指定应用和虚拟机数据备份的存储目标
  - 模板名称：用于定义备份频率、时间表和保留时间的一组政策的名称
- 受影响的资源
  - 资源显示名称：删除方案所在的项目
- 相关链接，尤其是以下字段：
  - MITRE ATTACK 方法：指向 MITRE ATT&CK 文档的链接
  - Logging URI：用于打开 Logs Explorer 的链接

第 2 步：研究攻击和响应方法

在主账号电子邮件地址字段中与服务账号的所有者联系。确认合法所有者是否执行了此操作。

第 3 步：实现响应

以下响应方案可能适合此发现结果。请仔细评估您在调查中收集的信息，以确定解析发现结果的最佳方法。

在执行操作的项目中，转到管理控制台。
在应用管理器标签页中，找到不再受保护的受影响应用，然后查看每款应用的备份政策。

`Inhibit System Recovery: Google Cloud Backup and DR delete template`

Security Command Center 会检查审核日志，以检测模板的异常删除情况。模板是可应用于多个应用的备份基础配置。

第 1 步：查看发现结果详情

按照查看发现结果中所述，打开 Inhibit System Recovery: Google Cloud Backup and DR delete template 发现结果。系统会打开发现结果详情面板，以显示摘要标签页。
在摘要标签页上，查看以下部分中的信息：
- 检测到的内容，尤其是以下字段：
  - 模板名称：用于定义备份频率、时间表和保留时间的一组政策的名称
  - 主账号主体：已成功执行操作的用户
- 受影响的资源
  - 资源显示名称：删除模板所在的项目
- 相关链接，尤其是以下字段：
  - MITRE ATTACK 方法：指向 MITRE ATT&CK 文档的链接
  - Logging URI：用于打开 Logs Explorer 的链接

第 2 步：研究攻击和响应方法

在主账号电子邮件地址字段中与服务账号的所有者联系。确认合法所有者是否执行了此操作。

第 3 步：实现响应

以下响应方案可能适合此发现结果。请仔细评估您在调查中收集的信息，以确定解析发现结果的最佳方法。

在执行操作的项目中，前往管理控制台。
在应用管理器标签页中，找到不再受保护的受影响应用，然后查看每款应用的备份政策。
如需重新添加模板，请前往备份方案标签页，选择模板，然后选择“创建模板”选项。

`Inhibit System Recovery: Google Cloud Backup and DR delete policy`

系统会检查审核日志，以检测是否有政策被删除。政策定义了备份的存储方式和存储位置。

第 1 步：查看发现结果详情

按照查看发现结果中所述，打开 Inhibit System Recovery: Google Cloud Backup and DR delete policy 发现结果。系统会打开发现结果详情面板，以显示摘要标签页。
在摘要标签页上，查看以下部分中的信息：
- 检测到的内容，尤其是以下字段：
  - 政策名称：单个政策的名称，用于定义备份频率、时间表和保留时间
  - 主账号主体：已成功执行操作的用户
- 受影响的资源
  - 资源显示名称：删除政策所在的项目
- 相关链接，尤其是以下字段：
  - MITRE ATTACK 方法：指向 MITRE ATT&CK 文档的链接
  - Logging URI：用于打开 Logs Explorer 的链接。

第 2 步：研究攻击和响应方法

在主账号电子邮件地址字段中与服务账号的所有者联系。确认合法所有者是否执行了此操作。

第 3 步：实现响应

以下响应方案可能适合此发现结果。请仔细评估您在研究中收集的信息，以确定解析发现结果的最佳方法。1. 在执行操作的项目中，转到管理控制台。2. 在应用管理器标签页中，选择受影响的应用，然后查看应用所应用的政策设置。

`Inhibit System Recovery: Google Cloud Backup and DR delete profile`

系统会检查审核日志，以检测是否有用户删除了个人资料。配置文件用于定义用于存储备份的存储池。

第 1 步：查看发现结果详情

按照查看发现结果中所述，打开 Inhibit System Recovery: Google Cloud Backup and DR delete profile 发现结果。系统会打开发现结果详情面板，以显示摘要标签页。
在摘要标签页上，查看以下部分中的信息：
- 检测到的内容，尤其是以下字段：
  - 配置文件名称：指定应用和虚拟机数据备份的存储目标
  - 主账号主体：已成功执行操作的用户
- 受影响的资源
  - 资源显示名称：删除配置文件的项目
- 相关链接，尤其是以下字段：
  - MITRE ATTACK 方法：指向 MITRE ATT&CK 文档的链接
  - Logging URI：用于打开 Logs Explorer 的链接

第 2 步：研究攻击和响应方法

在主账号电子邮件地址字段中与服务账号的所有者联系。确认合法所有者是否执行了此操作。

第 3 步：实现响应

以下响应方案可能适合此发现结果。请仔细评估您在研究中收集的信息，以确定解析发现结果的最佳方法。1. 在执行操作的项目中，转到管理控制台。2. 在备份方案标签页中，选择配置文件以查看所有配置文件的列表。 3. 查看配置文件，确认已设置所有必需的配置文件。 4.如果系统误删了已删除的配置文件，请选择创建配置文件，为备份和灾难恢复设备定义存储目标。

`Inhibit System Recovery: Google Cloud Backup and DR delete storage pool`

系统会检查审核日志以检测是否有存储空间池被删除。存储池会将 Cloud Storage 存储桶与备份和灾难恢复相关联。

第 1 步：查看发现结果详情

按照查看发现结果中所述，打开 Inhibit System Recovery: Google Cloud Backup and DR delete storage pool 发现结果。系统会打开发现结果详情面板，以显示摘要标签页。
在摘要标签页上，查看以下部分中的信息：
- 检测到的内容，尤其是以下字段：
  - 存储桶名称：用于存储备份的存储桶的名称
  - 主账号主体：已成功执行操作的用户
- 受影响的资源
  - 资源显示名称：删除存储分区所在的项目
- 相关链接，尤其是以下字段：
  - MITRE ATTACK 方法：指向 MITRE ATT&CK 文档的链接
  - Logging URI：用于打开 Logs Explorer 的链接

第 2 步：研究攻击和响应方法

在主账号电子邮件地址字段中与服务账号的所有者联系。确认合法所有者是否执行了此操作。

第 3 步：实现响应

以下响应方案可能适合此发现结果。请仔细评估您在研究中收集的信息，以确定解析发现结果的最佳方法。1. 在执行操作的项目中，转到管理控制台。2. 在“管理”标签页中，选择存储池以查看所有存储池的列表。3. 查看存储池与备份设备的关联。 4.如果某个处于活动状态的设备没有关联的存储池，请选择添加 OnVault 池以重新添加。

`Data Destruction: Google Cloud Backup and DR expire image`

潜在恶意操作者请求删除备份映像。

第 1 步：查看发现结果详情

按照查看发现结果中所述，打开 Inhibit System Recovery: Google Cloud Backup and DR expire image 发现结果。系统会打开发现结果详情面板，以显示摘要标签页。
在摘要标签页上，查看以下部分中的信息：
- 检测到的内容，尤其是以下字段：
  - 政策名称：单个政策的名称，用于定义备份频率、时间表和保留时间
  - 模板名称：用于定义备份频率、时间表和保留时间的一组政策的名称
  - 配置文件名称：指定应用和虚拟机数据备份的存储目标
  - 主账号主体：已成功执行操作的用户
- 受影响的资源
  - 资源显示名称：删除备份映像的项目
- 相关链接，尤其是以下字段：
  - MITRE ATTACK 方法：指向 MITRE ATT&CK 文档的链接
  - Logging URI：用于打开 Logs Explorer 的链接

第 2 步：研究攻击和响应方法

在主账号电子邮件地址字段中与服务账号的所有者联系。确认合法所有者是否执行了此操作。

第 3 步：实现响应

以下响应方案可能适合此发现结果。请仔细评估您在研究中收集的信息，以确定解析发现结果的最佳方法。1. 在执行操作的项目中，转到管理控制台。2. 转到“监控”标签页，然后选择“作业”以查看删除备份作业的状态。3. 如果删除作业未获得授权，请转到 IAM 权限，以查看有权访问备份数据的用户。

`Data Destruction: Google Cloud Backup and DR expire all images`

潜在恶意操作者请求删除与应用关联的所有备份映像。

第 1 步：查看发现结果详情

按照查看发现结果中所述，打开 Inhibit System Recovery: Google Cloud Backup and DR expire all images 发现结果。系统会打开发现结果详情面板，以显示摘要标签页。
在摘要标签页上，查看以下部分中的信息：
- 检测到的内容，尤其是以下字段：
  - 政策名称：单个政策的名称，用于定义备份频率、时间表和保留时间
  - 模板名称：用于定义备份频率、时间表和保留时间的一组政策的名称
  - 配置文件名称：指定应用和虚拟机数据备份的存储目标
  - 主账号主体：已成功执行操作的用户
- 受影响的资源
  - 资源显示名称：删除备份映像的项目
- 相关链接，尤其是以下字段：
  - MITRE ATTACK 方法：指向 MITRE ATT&CK 文档的链接
  - Logging URI：用于打开 Logs Explorer 的链接。

第 2 步：研究攻击和响应方法

在主账号电子邮件地址字段中与服务账号的所有者联系。确认合法所有者是否执行了此操作。

第 3 步：实现响应

`Data Destruction: Google Cloud Backup and DR remove appliance`

系统会检查审核日志，以检测备份和恢复设备是否已被移除。备份和恢复设备是备份操作的重要组成部分。

第 1 步：查看发现结果详情

按照查看发现结果中所述，打开 Inhibit System Recovery: Google Cloud Backup and DR remove appliance 发现结果。系统会打开发现结果详情面板，以显示摘要标签页。
在摘要标签页上，查看以下部分中的信息：
- 检测到的内容，尤其是以下字段：
  - 设备名称：连接到备份和灾难恢复的虚拟机或数据库的名称
  - 主账号主体：已成功执行操作的用户
- 受影响的资源
  - 资源显示名称：删除设备所在的项目
- 相关链接，尤其是以下字段：
  - MITRE ATTACK 方法：指向 MITRE ATT&CK 文档的链接
  - Logging URI：用于打开 Logs Explorer 的链接

第 2 步：研究攻击和响应方法

在主账号电子邮件地址字段中与服务账号的所有者联系。确认合法所有者是否执行了此操作。

第 3 步：实现响应

以下响应方案可能适合此发现结果。请仔细评估您在研究中收集的信息，以确定解析发现结果的最佳方法。1. 在执行操作的项目中，转到管理控制台。2. 在应用管理器标签页中，找到不再受保护的受影响应用，然后查看每款应用的备份政策。3. 如需创建新设备并将保护重新应用于未受保护的应用，请在 Google Cloud 控制台中转到“备份和灾难恢复”，然后选择“部署另一个备份或恢复设备”选项。4.在存储菜单中，为每台新设备配置存储目标。配置设备后，当您为应用创建配置文件时，该设备会显示为一个选项。

`Impact: Google Cloud Backup and DR reduced backup expiration`

Event Threat Detection 会检查审核日志，以检测备份和灾难恢复服务设备上备份的到期日期是否已缩短。

如需响应此发现结果，请执行以下操作：

第 1 步：查看发现结果详情

按照查看发现结果中所述，打开 Impact: Google Cloud Backup and DR reduced backup expiration 发现结果。系统会打开发现结果详情面板，以显示摘要标签页。
在摘要标签页上，查看以下部分中的信息：
- 检测到的内容，尤其是以下字段：
  - 说明：检测相关信息
  - 主账号正文：已成功执行操作的用户或服务账号
- 受影响的资源
  - 资源显示名称：缩短了备份到期时间的项目。
- 相关链接，尤其是以下字段：
  - MITRE ATTACK 方法：指向 MITRE ATT&CK 文档的链接。
  - Logging URI：用于打开 Logs Explorer 的链接。

第 2 步：研究攻击和响应方法

在主账号主题字段中与服务账号的所有者联系。确认合法所有者是否执行了此操作。

第 3 步：实现响应

以下响应方案可能适合此发现结果。请仔细评估您在调查中收集的信息，以确定解析发现结果的最佳方法。

在执行操作的项目中，转到管理控制台。
在应用管理器标签页中，找到缩短了备份到期时间的受影响应用，并验证主账号是否有意缩短到期时间。
如需为应用启动新的备份，请选择管理备份配置以创建按需备份或安排新的备份。

`Impact: Google Cloud Backup and DR reduced backup frequency`

Event Threat Detection 会检查审核日志，以检测是否已修改备份计划以降低备份频率。

如需响应此发现结果，请执行以下操作：

第 1 步：查看发现结果详情

按照查看发现结果中所述，打开 Impact: Google Cloud Backup and DR reduced backup frequency 发现结果。系统会打开发现结果详情面板，以显示摘要标签页。
在摘要标签页上，查看以下部分中的信息：
- 检测到的内容，尤其是以下字段：
  - 说明：检测相关信息
  - 主账号正文：已成功执行操作的用户或服务账号
- 受影响的资源
  - 资源显示名称：缩减了备份频率的项目。
- 相关链接，尤其是以下字段：
  - MITRE ATTACK 方法：指向 MITRE ATT&CK 文档的链接。
  - Logging URI：用于打开 Logs Explorer 的链接。

第 2 步：研究攻击和响应方法

在主账号主题字段中与服务账号的所有者联系。确认合法所有者是否执行了此操作。

第 3 步：实现响应

以下响应方案可能适合此发现结果。请仔细评估您在调查中收集的信息，以确定解析发现结果的最佳方法。

在执行操作的项目中，转到管理控制台。
在应用管理器标签页中，找到已降低备份频率的受影响应用，并验证相应更改是否为主要负责人有意做出的。
如需为应用启动新的备份，请选择管理备份配置以创建按需备份或安排新的备份。

`Impact: Suspicious Kubernetes Container Names - Coin Mining`

某位用户部署了一个 Pod，其命名惯例与常见的加密货币矿机类似。这可能是已获得集群初始访问权限的攻击者企图使用集群资源进行加密货币挖矿。如需了解详情，请参阅此提醒的日志消息。

确认 Pod 是合法的。
确定 Cloud Logging 的审核日志中是否存在来自 Pod 或主账号的其他恶意活动迹象。
如果主账号不是服务账号（IAM 或 Kubernetes），请与该账号的所有者联系，以确认合法所有者是否执行了相应操作。
如果主账号是服务账号（IAM 或 Kubernetes），请查明操作来源以确定其合法性。
如果 Pod 不合法，请将其移除，同时移除任何关联的 RBAC 绑定，以及工作负载使用的和允许其创建的服务账号。

`Lateral Movement: Modified Boot Disk Attached to Instance`

系统会检查审核日志，以检测 Compute Engine 实例资源之间是否存在可疑的磁盘移动。系统已将可能已修改的启动磁盘挂接到您的 Compute Engine。

第 1 步：查看发现结果详情

按照查看发现结果中所述，打开 Lateral Movement: Modify Boot Disk Attaching to Instance 发现结果。系统会打开发现结果详情面板，以显示摘要标签页。
在摘要标签页上，记下以下字段的值。

在检测到的内容下：
- 主账号电子邮件地址：执行操作的服务账号
- 服务名称：服务账号访问的 Google Cloud 服务的 API 名称
- 方法名称：所调用的方法

第 2 步：研究攻击和响应方法

使用服务账号工具（如活动分析器）调查关联的服务账号的活动。
在主账号电子邮件地址字段中与服务账号的所有者联系。确认合法所有者是否执行了此操作。

第 3 步：实现响应

以下响应方案可能适合此发现结果，但也可能会影响运营。请仔细评估您在研究中收集的信息，以确定解析发现结果的最佳方法。

与执行操作的项目的所有者联系。
考虑为 Compute Engine 虚拟机实例使用安全启动。
考虑删除可能被盗用的服务账号，然后轮替和删除可能被破解的项目的所有服务账号访问密钥。删除后，使用该服务账号进行身份验证的应用会失去访问权限。在继续操作之前，您的安全团队应确定所有受影响的应用并与应用所有者合作，以确保业务连续性。
与您的安全团队合作，确定不熟悉的资源，包括 Compute Engine 实例、快照、服务账号和 IAM 用户。删除未使用已获授权的账号创建的资源。
回复来自 Google Cloud 支持的任何通知。

`Privilege Escalation: AlloyDB Over-Privileged Grant`

检测将 AlloyDB for PostgreSQL 数据库（或数据库中的所有函数或过程）的所有权限授予一个或多个数据库用户的情况。

如需响应此发现结果，请执行以下操作：

第 1 步：查看发现结果详情

按照查看发现结果中所述，打开 Privilege Escalation: AlloyDB Over-Privileged Grant 发现结果。
在发现结果详情面板的摘要标签页上，查看以下部分中的信息：
- 检测到的内容，尤其是以下字段：
  - 数据库显示名称：受影响的 AlloyDB for PostgreSQL 实例中的数据库的名称。
  - 数据库用户名：授予超额权限的 PostgreSQL 用户。
  - 数据库查询：授予权限所执行的 PostgreSQL 查询。
  - 数据库授权对象：超额权限的授权对象。
- 受影响的资源，尤其是以下字段：
  - 资源全名：受影响的 AlloyDB for PostgreSQL 实例的资源名称。
  - 父级全名：AlloyDB for PostgreSQL 实例的资源名称。
  - 项目全名：包含 AlloyDB for PostgreSQL 实例的 Google Cloud 项目。
- 相关链接，尤其是以下字段：
  - Cloud Logging URI：指向 Logging 条目的链接。
  - MITRE ATT&CK 方法：指向 MITRE ATT&CK 文档的链接。
如需查看发现结果的完整 JSON，请点击 JSON 标签页。

第 2 步：查看数据库权限

连接到 AlloyDB for PostgreSQL 实例。
为以下对象列出并显示访问权限：
- 数据库。使用 \l 或 \list 元命令，检查为数据库显示名称中列出的数据库（来自第 1 步）分配了哪些权限。
- 函数或过程。使用 \df 元命令，检查为数据库显示名称中列出的数据库（来自第 1 步）中的函数或过程分配了哪些权限。

第 3 步：检查日志

在 Google Cloud 控制台中，点击 Cloud Logging URI 中的链接（来自第 1 步），以前往日志浏览器。日志浏览器页面包含与相关 Cloud SQL 实例有关的所有日志。
在日志浏览器中，使用以下过滤条件检查 PostgreSQL pgaudit 日志，其中记录了对数据库执行的查询：
- protoPayload.request.database="var class="edit">database"

第 4 步：研究攻击和响应方法

查看此发现结果类型的 MITRE ATT&CK 框架条目： Web 服务渗漏。
如需确定是否需要执行额外的补救步骤，请将您的调查结果与 MITRE 研究相结合。

第 5 步：实现响应

以下响应方案可能适合此发现结果，但也可能会影响运营。请仔细评估您在研究中收集的信息，以确定解析发现结果的最佳方法。

与过度授予权限的实例的所有者联系。
在调查完成之前，考虑撤消数据库授权对象中列出的授权对象的所有权限。
如需限制对数据库（来自第 1 步的数据库显示名称）的访问权限，请撤消第 1 步的授权对象（来自数据库授权对象）的不必要的权限。

`Privilege Escalation: AlloyDB Database Superuser Writes to User Tables`

检测 AlloyDB for PostgreSQL 数据库超级用户账号 (postgres) 何时写入用户表。超级用户（具有非常广泛访问权限的角色）通常不应用于写入用户表。拥有受限程度更严格的访问权限的用户账号应用于每日的常规活动。当超级用户向用户表写入数据时，这可能表示攻击者提升了特权或者伪装成默认数据库用户，并且正在修改数据。它也可能仅表示正常但不安全的做法。

如需响应此发现结果，请执行以下操作：

第 1 步：查看发现结果详情

按照查看发现结果中所述，打开 Privilege Escalation: AlloyDB Database Superuser Writes to User Tables 发现结果。
在发现结果详情面板的摘要标签页上，查看以下部分中的信息：
- 检测到的内容，尤其是以下字段：
  - 数据库显示名称：受影响的 AlloyDB for PostgreSQL 实例中的数据库的名称。
  - 数据库用户名：超级用户。
  - 数据库查询：写入用户表时执行的 SQL 查询。
- 受影响的资源，尤其是以下字段：
  - 资源全名：受影响的 AlloyDB for PostgreSQL 实例的资源名称。
  - 父级全名：AlloyDB for PostgreSQL 实例的资源名称。
  - 项目全名：包含 AlloyDB for PostgreSQL 实例的 Google Cloud 项目。
- 相关链接，尤其是以下字段：
  - Cloud Logging URI：指向 Logging 条目的链接。
  - MITRE ATT&CK 方法：指向 MITRE ATT&CK 文档的链接。
如需查看发现结果的完整 JSON，请点击 JSON 标签页。

第 2 步：检查日志

在 Google Cloud 控制台中，点击 cloudLoggingQueryURI（第 1 步）中的链接，以转到日志浏览器。日志浏览器页面包含与相关 AlloyDB for PostgreSQL 实例有关的所有日志。
使用以下过滤条件检查 PostgreSQL pgaudit 日志，其中包含超级用户执行的查询：
- protoPayload.request.user="postgres"

第 3 步：研究攻击和响应方法

查看此发现结果类型的 MITRE ATT&CK 框架条目： Web 服务渗漏。
如需确定是否需要执行额外的补救步骤，请将您的调查结果与 MITRE 研究相结合。

第 4 步：实现响应

以下响应方案可能适合此发现结果，但也可能会影响运营。请仔细评估您在研究中收集的信息，以确定解析发现结果的最佳方法。

查看允许连接到数据库的用户。
考虑更改超级用户的密码。
考虑为实例上使用的不同类型的查询创建新的受限访问权限用户。
- 仅向新用户授予执行其查询所需的必要权限。
- 更新连接到 AlloyDB for PostgreSQL 实例的客户端的凭据

Compute Engine 管理员元数据检测

`Persistence: GCE Admin Added SSH Key`

说明操作

说明	操作
在已建立的实例上更改了 `ssh-keys` Compute Engine 实例元数据键。	已在超过 7 天前创建的实例上修改了 Compute Engine 实例元数据键 `ssh-keys`。验证更改是否是由成员有意进行的，或者是否是攻击者为引入对您的组织的新访问权限而实施的。	使用以下过滤条件检查日志： `protopayload.resource.labels.instance_id=INSTANCE_ID` `protoPayload.serviceName="compute.googleapis.com"` `(protoPayload.metadata.instanceMetaData.addedMetadataKey : "ssh-keys" OR protoPayload.metadata.instanceMetaData.modifiedMetadataKey : "ssh-keys" )` `logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Factivity` 替换以下内容： `INSTANCE_ID`：发现结果中列出的 `gceInstanceId` `ORGANIZATION_ID`：您的组织 ID。
触发此发现结果的研究事件： MITRE： https://attack.mitre.org/techniques/T1098/004/

在已建立的实例上更改了 ssh-keys Compute Engine 实例元数据键。

已在超过 7 天前创建的实例上修改了 Compute Engine 实例元数据键 ssh-keys。验证更改是否是由成员有意进行的，或者是否是攻击者为引入对您的组织的新访问权限而实施的。

使用以下过滤条件检查日志：

protopayload.resource.labels.instance_id=INSTANCE_ID

protoPayload.serviceName="compute.googleapis.com"

(protoPayload.metadata.instanceMetaData.addedMetadataKey : "ssh-keys" OR protoPayload.metadata.instanceMetaData.modifiedMetadataKey : "ssh-keys" )

logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Factivity

替换以下内容：

INSTANCE_ID：发现结果中列出的 gceInstanceId
ORGANIZATION_ID：您的组织 ID。

触发此发现结果的研究事件：

MITRE： https://attack.mitre.org/techniques/T1098/004/

`Persistence: GCE Admin Added Startup Script`

说明操作

说明	操作
在已建立的实例上更改了 `startup-script` 或 `startup-script-url` Compute Engine 实例元数据键。	已在超过 7 天前创建的实例上修改了 Compute Engine 实例元数据键 `startup-script` 或 `startup-script-url`。验证更改是否是由成员有意进行的，或者是否是攻击者为引入对您的组织的新访问权限而实施的。	使用以下过滤条件检查日志： `protopayload.resource.labels.instance_id=INSTANCE_ID` `protoPayload.serviceName="compute.googleapis.com"` `((protoPayload.metadata.instanceMetaData.addedMetadataKey : "startup-script" OR protoPayload.metadata.instanceMetaData.modifiedMetadataKey : "startup-script" )` `OR (protoPayload.metadata.instanceMetaData.addedMetadataKey : "startup-script-url" OR protoPayload.metadata.instanceMetaData.modifiedMetadataKey : "startup-script-url" ))` `logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Factivity` 替换以下内容： `INSTANCE_ID`：发现结果中列出的 `gceInstanceId` `ORGANIZATION_ID`：您的组织 ID。
触发此发现结果的研究事件： MITRE： https://attack.mitre.org/techniques/T1098/004/

在已建立的实例上更改了 startup-script 或 startup-script-url Compute Engine 实例元数据键。

已在超过 7 天前创建的实例上修改了 Compute Engine 实例元数据键 startup-script 或 startup-script-url。验证更改是否是由成员有意进行的，或者是否是攻击者为引入对您的组织的新访问权限而实施的。

使用以下过滤条件检查日志：

protopayload.resource.labels.instance_id=INSTANCE_ID

protoPayload.serviceName="compute.googleapis.com"

((protoPayload.metadata.instanceMetaData.addedMetadataKey : "startup-script" OR protoPayload.metadata.instanceMetaData.modifiedMetadataKey : "startup-script" )

OR (protoPayload.metadata.instanceMetaData.addedMetadataKey : "startup-script-url" OR protoPayload.metadata.instanceMetaData.modifiedMetadataKey : "startup-script-url" ))

logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Factivity

替换以下内容：

INSTANCE_ID：发现结果中列出的 gceInstanceId
ORGANIZATION_ID：您的组织 ID。

触发此发现结果的研究事件：

MITRE： https://attack.mitre.org/techniques/T1098/004/

Google Workspace 日志检测

如果您与 Cloud Logging 共享 Google Workspace 日志，则 Event Threat Detection 会针对多个 Google Workspace 威胁生成发现结果。由于 Google Workspace 日志处于组织级层，因此只有当您在组织级层激活 Security Command Center 时，Event Threat Detection 才能扫描这些日志。

Event Threat Detection 可以充实日志事件并将发现结果写入 Security Command Center。下表包含 Google Workspace 威胁、相关 MITRE ATT&CK 框架条目，以及有关触发发现结果的事件的详细信息。您还可以使用特定过滤条件检查日志，并合并所有信息来应对 Google Workspace 威胁。

`Initial Access: Disabled Password Leak`

如果您在项目级层激活 Security Command Center，则无法看到此发现结果。

说明操作

由于检测到密码泄露，成员的账号被停用。

为受影响的账号重置密码，并建议成员为公司账号使用安全系数高的唯一密码。

说明	操作
由于检测到密码泄露，成员的账号被停用。	为受影响的账号重置密码，并建议成员为公司账号使用安全系数高的唯一密码。	使用以下过滤条件检查日志： `protopayload.resource.labels.service="login.googleapis.com"` `logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fdata_access` 将 `ORGANIZATION_ID` 替换为您的组织 ID。
触发此发现结果的研究事件： MITRE： https://attack.mitre.org/techniques/T1078/ Workspace 事件详情： https://developers.google.com/admin-sdk/reports/v1/appendix/activity/login#account_disabled_password_leak

使用以下过滤条件检查日志：

protopayload.resource.labels.service="login.googleapis.com"

logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fdata_access

将 ORGANIZATION_ID 替换为您的组织 ID。

触发此发现结果的研究事件：

MITRE： https://attack.mitre.org/techniques/T1078/
Workspace 事件详情： https://developers.google.com/admin-sdk/reports/v1/appendix/activity/login#account_disabled_password_leak

`Initial Access: Suspicious Login Blocked`

如果您在项目级层激活 Security Command Center，则无法看到此发现结果。

说明操作

检测到并阻止了成员账号的可疑登录。

此账号可能会被攻击者定位。确保用户账号遵循组织的安全准则，以实现安全系数高的密码和多重身份验证。

说明	操作
检测到并阻止了成员账号的可疑登录。	此账号可能会被攻击者定位。确保用户账号遵循组织的安全准则，以实现安全系数高的密码和多重身份验证。	使用以下过滤条件检查日志： `protopayload.resource.labels.service="login.googleapis.com"` `logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fdata_access` 将 `ORGANIZATION_ID` 替换为您的组织 ID。
触发此发现结果的研究事件： MITRE： https://attack.mitre.org/techniques/T1078/ Workspace 事件详情： https://developers.google.com/admin-sdk/reports/v1/appendix/activity/login#suspicious_login

使用以下过滤条件检查日志：

protopayload.resource.labels.service="login.googleapis.com"

logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fdata_access

将 ORGANIZATION_ID 替换为您的组织 ID。

触发此发现结果的研究事件：

MITRE： https://attack.mitre.org/techniques/T1078/
Workspace 事件详情： https://developers.google.com/admin-sdk/reports/v1/appendix/activity/login#suspicious_login

`Initial Access: Account Disabled Hijacked`

如果您在项目级层激活 Security Command Center，则无法看到此发现结果。

说明操作

成员的账号因可疑活动而被暂停。

此账号遭到盗用。重置账号密码，并建议用户为公司账号创建安全系数高的唯一密码。

说明	操作
成员的账号因可疑活动而被暂停。	此账号遭到盗用。重置账号密码，并建议用户为公司账号创建安全系数高的唯一密码。	使用以下过滤条件检查日志： `protopayload.resource.labels.service="login.googleapis.com"` `logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fdata_access` 将 `ORGANIZATION_ID` 替换为您的组织 ID。
触发此发现结果的研究事件： MITRE： https://attack.mitre.org/techniques/T1078/ Workspace 事件详情： https://developers.google.com/admin-sdk/reports/v1/appendix/activity/login#account_disabled_hijacked

使用以下过滤条件检查日志：

protopayload.resource.labels.service="login.googleapis.com"

logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fdata_access

将 ORGANIZATION_ID 替换为您的组织 ID。

触发此发现结果的研究事件：

MITRE： https://attack.mitre.org/techniques/T1078/
Workspace 事件详情： https://developers.google.com/admin-sdk/reports/v1/appendix/activity/login#account_disabled_hijacked

`Impair Defenses: Two Step Verification Disabled`

如果您在项目级层激活 Security Command Center，则无法看到此发现结果。

说明操作

成员停用了两步验证。

验证用户是否打算停用两步验证。如果您的组织需要两步验证，请确保用户立即启用两步验证。

说明	操作
成员停用了两步验证。	验证用户是否打算停用两步验证。如果您的组织需要两步验证，请确保用户立即启用两步验证。	使用以下过滤条件检查日志： `protopayload.resource.labels.service="login.googleapis.com"` `logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fdata_access` 将 `ORGANIZATION_ID` 替换为您的组织 ID。
触发此发现结果的研究事件： MITRE： https://attack.mitre.org/techniques/T1562/ Workspace 事件详情： https://developers.google.com/admin-sdk/reports/v1/appendix/activity/login#2sv_disable

使用以下过滤条件检查日志：

protopayload.resource.labels.service="login.googleapis.com"

logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fdata_access

将 ORGANIZATION_ID 替换为您的组织 ID。

触发此发现结果的研究事件：

MITRE： https://attack.mitre.org/techniques/T1562/
Workspace 事件详情： https://developers.google.com/admin-sdk/reports/v1/appendix/activity/login#2sv_disable

`Initial Access: Government Based Attack`

如果您在项目级层激活 Security Command Center，则无法看到此发现结果。

说明操作

政府支持的攻击者可能尝试入侵成员账号或计算机。

此账号可能会被攻击者定位。确保用户账号遵循组织的安全准则，以实现安全系数高的密码和多重身份验证。

说明	操作
政府支持的攻击者可能尝试入侵成员账号或计算机。	此账号可能会被攻击者定位。确保用户账号遵循组织的安全准则，以实现安全系数高的密码和多重身份验证。	使用以下过滤条件检查日志： `protopayload.resource.labels.service="login.googleapis.com"` `logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fdata_access` 将 `ORGANIZATION_ID` 替换为您的组织 ID。
触发此发现结果的研究事件： MITRE： https://attack.mitre.org/techniques/T1078/ Workspace 事件详情： https://developers.google.com/admin-sdk/reports/v1/appendix/activity/login#gov_attack_warning

使用以下过滤条件检查日志：

protopayload.resource.labels.service="login.googleapis.com"

logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fdata_access

将 ORGANIZATION_ID 替换为您的组织 ID。

触发此发现结果的研究事件：

MITRE： https://attack.mitre.org/techniques/T1078/
Workspace 事件详情： https://developers.google.com/admin-sdk/reports/v1/appendix/activity/login#gov_attack_warning

`Persistence: SSO Enablement Toggle`

如果您在项目级层激活 Security Command Center，则无法看到此发现结果。

说明操作

管理员账号的“启用单点登录 (SSO)”设置已停用。

您的组织的单点登录设置发生了更改。验证更改是否是由成员有意进行的，或者是否是攻击者为引入对您的组织的新访问权限而实施的。

说明	操作
管理员账号的“启用单点登录 (SSO)”设置已停用。	您的组织的单点登录设置发生了更改。验证更改是否是由成员有意进行的，或者是否是攻击者为引入对您的组织的新访问权限而实施的。	使用以下过滤条件检查日志： `protopayload.resource.labels.service="admin.googleapis.com"` `protopayload.metadata.event.parameter.value=DOMAIN_NAME` `logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Factivity` 替换以下内容： `DOMAIN_NAME`：发现结果中列出的 `domainName` `ORGANIZATION_ID`：您的组织 ID。
触发此发现结果的研究事件： MITRE： https://attack.mitre.org/techniques/T1098/ Workspace 事件详情： https://developers.google.com/admin-sdk/reports/v1/appendix/activity/admin-domain-settings#TOGGLE_SSO_ENABLED

使用以下过滤条件检查日志：

protopayload.resource.labels.service="admin.googleapis.com"

protopayload.metadata.event.parameter.value=DOMAIN_NAME

logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Factivity

替换以下内容：

DOMAIN_NAME：发现结果中列出的 domainName
ORGANIZATION_ID：您的组织 ID。

触发此发现结果的研究事件：

MITRE： https://attack.mitre.org/techniques/T1098/
Workspace 事件详情： https://developers.google.com/admin-sdk/reports/v1/appendix/activity/admin-domain-settings#TOGGLE_SSO_ENABLED

`Persistence: SSO Settings Changed`

如果您在项目级层激活 Security Command Center，则无法看到此发现结果。

说明操作

管理员账号的 SSO 设置已更改。

您的组织的单点登录设置发生了更改。验证更改是否是由成员有意进行的，或者是否是攻击者为引入对您的组织的新访问权限而实施的。

说明	操作
管理员账号的 SSO 设置已更改。	您的组织的单点登录设置发生了更改。验证更改是否是由成员有意进行的，或者是否是攻击者为引入对您的组织的新访问权限而实施的。	使用以下过滤条件检查日志： `protopayload.resource.labels.service="admin.googleapis.com"` `protopayload.metadata.event.parameter.value=DOMAIN_NAME` `logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Factivity` 替换以下内容： `DOMAIN_NAME`：发现结果中列出的 `domainName` `ORGANIZATION_ID`：您的组织 ID。
触发此发现结果的研究事件： MITRE： https://attack.mitre.org/techniques/T1098/ Workspace 事件详情： https://developers.google.com/admin-sdk/reports/v1/appendix/activity/admin-domain-settings#CHANGE_SSO_SETTINGS

使用以下过滤条件检查日志：

protopayload.resource.labels.service="admin.googleapis.com"

protopayload.metadata.event.parameter.value=DOMAIN_NAME

logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Factivity

替换以下内容：

DOMAIN_NAME：发现结果中列出的 domainName
ORGANIZATION_ID：您的组织 ID。

触发此发现结果的研究事件：

MITRE： https://attack.mitre.org/techniques/T1098/
Workspace 事件详情： https://developers.google.com/admin-sdk/reports/v1/appendix/activity/admin-domain-settings#CHANGE_SSO_SETTINGS

`Impair Defenses: Strong Authentication Disabled`

如果您在项目级层激活 Security Command Center，则无法看到此发现结果。

说明操作

您的组织已停用两步验证。

您的组织不再需要两步验证。了解这是否是管理员有意更改的政策，或者这是攻击者试图简化账号盗用的行为。

说明	操作
您的组织已停用两步验证。	您的组织不再需要两步验证。了解这是否是管理员有意更改的政策，或者这是攻击者试图简化账号盗用的行为。	使用以下过滤条件检查日志： `protopayload.resource.labels.service="admin.googleapis.com"` `logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Factivity` 将 `ORGANIZATION_ID` 替换为您的组织 ID。
触发此发现结果的研究事件： MITRE： https://attack.mitre.org/techniques/T1562/ Workspace 事件详情： https://developers.google.com/admin-sdk/reports/v1/appendix/activity/admin-security-settings#ENFORCE_STRONG_AUTHENTICATION

使用以下过滤条件检查日志：

protopayload.resource.labels.service="admin.googleapis.com"

logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Factivity

将 ORGANIZATION_ID 替换为您的组织 ID。

触发此发现结果的研究事件：

MITRE： https://attack.mitre.org/techniques/T1562/
Workspace 事件详情： https://developers.google.com/admin-sdk/reports/v1/appendix/activity/admin-security-settings#ENFORCE_STRONG_AUTHENTICATION

应对 Google Workspace 威胁

Google Workspace 发现结果仅适用于组织级 Security Command Center 激活。对于项目级层激活，系统无法扫描 Google Workspace 日志。

如果您是 Google Workspace 管理员，则可以使用相应服务的安全工具来解决这些威胁：

这些工具包括提醒、安全信息中心、安全建议，可以帮助您调查和解决威胁。

如果您不是 Google Workspace 管理员，请执行以下操作：

如果您仍有权访问自己的账号，请更改或重置您的密码并开启两步验证。
联系您的 Google Workspace 管理员或您的公司中管理 Google Workspace 账号的团队。您可以使用这些发现结果来表明账号可能遭到盗用。

Cloud IDS 威胁检测

`Cloud IDS: THREAT_ID`

Cloud IDS 发现结果由 Cloud IDS 生成，Cloud IDS 是一项安全服务，用于监控进出 Google Cloud 资源的流量是否存在威胁。Cloud IDS 检测到威胁时，会将有关威胁的信息（例如源 IP 地址、目的地地址和端口号）发送到 Event Threat Detection，后者随后会发出威胁发现结果。

第 1 步：查看发现结果详情

按照查看发现结果中所述，打开 Cloud IDS: THREAT_ID 发现结果。
在发现结果详情的摘要标签页上，查看以下部分中列出的值：
- 检测到的内容，尤其是以下字段：
  - 协议：使用的网络协议
  - 事件时间：事件发生的时间
  - 说明：有关相应发现的更多信息
  - 严重程度：提醒的严重程度
  - 目的地 IP：网络流量的目标 IP
  - 目的地端口：网络流量的目标端口
  - 来源 IP：网络流量的来源 IP
  - 来源端口：网络流量的来源端口
- 受影响的资源，尤其是以下字段：
  - 资源全名：包含存在威胁的网络的项目
- 相关链接，尤其是以下字段：
  - Cloud Logging URI：Cloud IDS 日志条目的链接 - 这些条目包含搜索 Palo Alto Networks Threat Vault 所需的信息
- 检测服务
  - 发现结果类别：Cloud IDS 威胁名称
如需查看发现结果的完整 JSON，请点击 JSON 标签页。

第 2 步：查找攻击和响应方法

查看发现详情后，请参阅 Cloud IDS 文档中的“调查威胁提醒”部分，确定适当的响应措施。

您可以点击发现结果详情中的 Cloud Logging URI 字段中的链接，在原始日志条目中详细了解检测到的事件。

Container Threat Detection 响应

如需详细了解 Container Threat Detection，请参阅 Container Threat Detection 的工作原理。

`Added Binary Executed`

执行了不属于原始容器映像的二进制文件。攻击者通常在刚开始入侵后安装漏洞工具和恶意软件。确保容器不可变是一项重要的最佳实践。这项发现的严重性较低，因为贵组织可能未遵循此最佳实践。如果二进制文件的哈希值是已知的失陷指标 (IoC)，则会出现相应的 Execution: Added Malicious Binary Executed 发现结果。如需响应此发现结果，请执行以下操作：

第 1 步：查看发现结果详情

按照查看发现结果中所述，打开 Added Binary Executed 发现结果。系统会打开发现结果详情面板，以显示摘要标签页。
在摘要标签页上，查看以下部分中的信息：
- 检测到的内容，尤其是以下字段：
  - 程序二进制文件：添加的二进制文件的绝对路径。
  - 参数：调用添加的二进制文件时提供的参数。
- 受影响的资源，尤其是以下字段：
  - 资源全名：集群的完整资源名称，其中包括项目编号、位置和集群名称。
- 相关链接，尤其是以下字段：
  - VirusTotal 指示器：指向 VirusTotal 分析页面的链接。
点击 JSON 并注意以下字段：
- resource：
  - project_display_name：包含集群的项目的名称。
- sourceProperties：
  - Pod_Namespace：Pod 的 Kubernetes 命名空间的名称。
  - Pod_Name：GKE Pod 的名称。
  - Container_Name：受影响的容器的名称。
  - Container_Image_Uri：要部署的容器映像的名称。
  - VM_Instance_Name：在其中执行 Pod 的 GKE 节点的名称。
找出此容器在相似时间发生的其他问题。相关发现可能表明此活动具有恶意，而不是未遵循最佳实践。

第 2 步：查看集群和节点

在 Google Cloud 控制台中，转到 Kubernetes 集群页面。
转到 KUBERNETES 集群
如有必要，在 Google Cloud 控制台的工具栏中选择 resource.project_display_name 中列出的项目。
选择发现结果详情摘要标签页中资源全名行上列出的集群。请记下有关集群及其所有者的所有元数据。
点击节点标签页。选择 VM_Instance_Name 中列出的节点。
点击详细信息标签页，并记下 container.googleapis.com/instance_id 注解。

第 3 步：审核 Pod

在 Google Cloud 控制台中，转到 Kubernetes 工作负载页面。
转到“Kubernetes 工作负载”
如有必要，在 Google Cloud 控制台工具栏中选择 resource.project_display_name 中列出的项目。
如有必要，对发现结果详情摘要标签页中资源全名行上列出的集群以及 Pod_Namespace 中列出的 Pod 命名空间进行过滤。
选择 Pod_Name 中列出的 Pod。请记下有关 Pod 及其所有者的所有元数据。

第 4 步：检查日志

在 Google Cloud 控制台中，打开日志浏览器。

打开日志浏览器
如有必要，在 Google Cloud 控制台的工具栏中选择 resource.project_display_name 中列出的项目。
将选择时间范围设置为感兴趣的时间段。
在加载的页面上，执行以下操作：
1. 使用以下过滤条件查找 Pod_Name 的 Pod 日志：
  - resource.type="k8s_container"
  - resource.labels.project_id="resource.project_display_name"
  - resource.labels.location="location"
  - resource.labels.cluster_name="cluster_name"
  - resource.labels.namespace_name="Pod_Namespace"
  - resource.labels.pod_name="Pod_Name"
2. 使用以下过滤条件查找集群审核日志：
  - logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
  - resource.type="k8s_cluster"
  - resource.labels.project_id="resource.project_display_name"
  - resource.labels.location="location"
  - resource.labels.cluster_name="cluster_name"
  - Pod_Name
3. 使用以下过滤条件查找 GKE 节点控制台日志：
  - resource.type="gce_instance"
  - resource.labels.instance_id="instance_id"

第 5 步：检查正在运行的容器

如果容器仍在运行，则或许可以直接检查容器环境。

转到 Google Cloud 控制台。

打开 Google Cloud 控制台
如有必要，在 Google Cloud 控制台的工具栏中选择 resource.project_display_name 中列出的项目。
点击激活 Cloud Shell
通过运行以下命令获取集群的 GKE 凭据。

对于可用区级集群：
```
  gcloud container clusters get-credentials cluster_name --zone location --project project_name
```
对于地区级集群：
```
  gcloud container clusters get-credentials cluster_name --region location --project project_name
```
替换以下内容：
- cluster_name：resource.labels.cluster_name 中列出的集群
- location：resource.labels.location 中列出的位置
- project_name：resource.project_display_name 中列出的项目名称
运行以下命令来检索添加的二进制文件：
```
  kubectl cp Pod_Namespace/Pod_Name:Process_Binary_Fullpath -c Container_Name  local_file
```
将 local_file 替换为本地文件路径，以存储添加的二进制文件。
通过运行以下命令连接到容器环境：
```
  kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
```
此命令要求容器在 /bin/sh 处安装 shell。

第 6 步：研究攻击和响应方法

查看此发现结果类型的 MITRE ATT&CK 框架条目：Ingress Tool Transfer、Native API。
点击 VirusTotal 指示器中的链接，在 VirusTotal 上查看被标记为恶意的二进制文件的 SHA-256 哈希值。VirusTotal 是一项 Alphabet 自有服务，提供了有关潜在恶意文件、网址、网域和 IP 地址的上下文。
如需制定响应方案，请将您的调查结果与 MITRE 研究和 VirusTotal 分析相结合。

第 7 步：实现响应

以下响应方案可能适合此发现结果，但也可能会影响运营。请仔细评估您在研究中收集的信息，以确定解析发现结果的最佳方法。

如果二进制文件打算包含在容器中，请重新构建包含二进制文件的容器映像。这样，容器就可以是不可变的。
否则，请与容器遭入侵的项目的所有者联系。
停止或删除遭入侵的容器，并将其替换为新容器。

`Added Library Loaded`

已加载不属于原始容器映像的库。攻击者可能会将恶意库加载到现有程序中，以绕过代码执行保护措施并隐藏恶意代码。确保容器不可变是一项重要的最佳实践。这项发现的严重性较低，因为贵组织可能未遵循此最佳实践。如果二进制文件的哈希值是已知的失陷指标 (IoC)，则会出现相应的 Execution: Added Malicious Library Loaded 发现结果。如需响应此发现结果，请执行以下操作：

第 1 步：查看发现结果详情

按照查看发现结果中所述，打开 Added Library Loaded 发现结果。系统会打开发现结果详情面板，以显示摘要标签页。
在摘要标签页上，查看以下部分中的信息：
- 检测到的内容，尤其是以下字段：
  - 程序二进制文件：加载库的进程二进制文件的完整路径。
  - 库：有关添加的库的详细信息。
  - 参数：调用进程二进制文件时提供的参数。
- 受影响的资源，尤其是以下字段：
  - 资源全名：集群的完整资源名称。
- 相关链接，尤其是以下字段：
  - VirusTotal 指示器：指向 VirusTotal 分析页面的链接。
点击 JSON 标签页并注意以下字段：
- resource：
  - project_display_name：包含资产的项目的名称。
- sourceProperties：
  - Pod_Namespace：Pod 的 Kubernetes 命名空间的名称。
  - Pod_Name：GKE Pod 的名称。
  - Container_Name：受影响的容器的名称。
  - Container_Image_Uri：要执行的容器映像的名称。
  - VM_Instance_Name：在其中执行 Pod 的 GKE 节点的名称。
找出此容器在相似时间发生的其他问题。相关发现可能表明此活动具有恶意，而不是未遵循最佳实践。

第 2 步：查看集群和节点

在 Google Cloud 控制台中，转到 Kubernetes 集群页面。
转到 KUBERNETES 集群
如有必要，在 Google Cloud 控制台工具栏中选择 resource.project_display_name 中列出的项目。
选择 resource.name 中列出的集群。请记下有关集群及其所有者的所有元数据。
点击节点标签页。选择 VM_Instance_Name 中列出的节点。
点击详细信息标签页，并记下 container.googleapis.com/instance_id 注解。

第 3 步：审核 Pod

在 Google Cloud 控制台中，转到 Kubernetes 工作负载页面。
转到“Kubernetes 工作负载”
如有必要，在 Google Cloud 控制台工具栏中选择 resource.project_display_name 中列出的项目。
如有必要，对发现结果详情摘要标签页中资源全名行上列出的集群以及 Pod_Namespace 中列出的 Pod 命名空间进行过滤。
选择 Pod_Name 中列出的 Pod。请记下有关 Pod 及其所有者的所有元数据。

第 4 步：检查日志

在 Google Cloud 控制台中，打开日志浏览器。

打开日志浏览器
如有必要，在 Google Cloud 控制台工具栏中选择 resource.project_display_name 中列出的项目。
将选择时间范围设置为感兴趣的时间段。
在加载的页面上，执行以下操作：
1. 使用以下过滤条件查找 Pod_Name 的 Pod 日志：
  - resource.type="k8s_container"
  - resource.labels.project_id="resource.project_display_name"
  - resource.labels.location="location"
  - resource.labels.cluster_name="cluster_name"
  - resource.labels.namespace_name="Pod_Namespace"
  - resource.labels.pod_name="Pod_Name"
2. 使用以下过滤条件查找集群审核日志：
  - logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
  - resource.type="k8s_cluster"
  - resource.labels.project_id="resource.project_display_name"
  - resource.labels.location="location"
  - resource.labels.cluster_name="cluster_name"
  - Pod_Name
3. 使用以下过滤条件查找 GKE 节点控制台日志：
  - resource.type="gce_instance"
  - resource.labels.instance_id="instance_id"

第 5 步：检查正在运行的容器

如果容器仍在运行，则或许可以直接检查容器环境。

转到 Google Cloud 控制台。

打开 Google Cloud 控制台
如有必要，在 Google Cloud 控制台工具栏中选择 resource.project_display_name 中列出的项目。
点击激活 Cloud Shell。

通过运行以下命令获取集群的 GKE 凭据。

对于可用区级集群：

  gcloud container clusters get-credentials cluster_name --zone location --project resource.project_display_name

对于地区级集群：

  gcloud container clusters get-credentials cluster_name --region location --project resource.project_display_name

运行以下命令来检索添加的库：
```
  kubectl cp Pod_Namespace/Pod_Name: Added_Library_Fullpath -c Container_Name  local_file
```
将 local_file 替换为本地文件路径，以存储添加的库。
通过运行以下命令连接到容器环境：
```
  kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
```
此命令要求容器在 /bin/sh 处安装 shell。

第 6 步：研究攻击和响应方法

查看此发现结果类型的 MITRE ATT&CK 框架条目：Ingress Tool Transfer、Shared Modules。
点击 VirusTotal 指示器中的链接，在 VirusTotal 上查看被标记为恶意的二进制文件的 SHA-256 哈希值。VirusTotal 是一项 Alphabet 自有服务，提供了有关潜在恶意文件、网址、网域和 IP 地址的上下文。
如需制定响应方案，请将您的调查结果与 MITRE 研究和 VirusTotal 分析相结合。

第 7 步：实现响应

以下响应方案可能适合此发现结果，但也可能会影响运营。请仔细评估您在研究中收集的信息，以确定解析发现结果的最佳方法。

如果该库打算包含在容器中，请重新构建包含该库的容器映像。这样，容器就可以是不可变的。
否则，请与容器遭入侵的项目的所有者联系。
停止或删除遭入侵的容器，并将其替换为新容器。

`Execution: Added Malicious Binary Executed`

执行了不属于原始容器映像的恶意二进制文件。攻击者通常在刚开始入侵后安装漏洞工具和恶意软件。如需响应此发现结果，请执行以下操作：

第 1 步：查看发现结果详情

按照查看发现结果中所述，打开 Execution: Added Malicious Binary Executed 发现结果。系统会打开发现结果详情面板，以显示摘要标签页。
在摘要标签页上，查看以下部分中的信息：
- 检测到的内容，尤其是以下字段：
  - 程序二进制文件：添加的二进制文件的绝对路径。
  - 参数：调用添加的二进制文件时提供的参数。
  - 容器：受影响的容器的名称。
  - 容器 URI：要部署的容器映像的名称。
- 受影响的资源，尤其是以下字段：
  - 资源全名：集群的完整资源名称，其中包括项目编号、位置和集群名称。
- 相关链接，尤其是以下字段：
  - VirusTotal 指示器：指向 VirusTotal 分析页面的链接。
点击 JSON 标签页并注意以下字段：
- sourceProperties：
  - VM_Instance_Name：在其中执行 Pod 的 GKE 节点的名称。

第 2 步：查看集群和节点

在 Google Cloud 控制台中，转到 Kubernetes 集群页面。
转到 KUBERNETES 集群
如有必要，在 Google Cloud 控制台的工具栏中选择 resource.project_display_name 中列出的项目。
选择发现结果详情摘要标签页中资源全名行上列出的集群。请记下有关集群及其所有者的所有元数据。
点击节点标签页。选择 VM_Instance_Name 中列出的节点。
点击详细信息标签页，并记下 container.googleapis.com/instance_id 注解。

第 3 步：审核 Pod

在 Google Cloud 控制台中，转到 Kubernetes 工作负载页面。
转到“Kubernetes 工作负载”
如有必要，在 Google Cloud 控制台工具栏中选择 resource.project_display_name 中列出的项目。
如有必要，对发现结果详情摘要标签页中资源全名行上列出的集群以及 Pod_Namespace 中列出的 Pod 命名空间进行过滤。
选择 Pod_Name 中列出的 Pod。请记下有关 Pod 及其所有者的所有元数据。

第 4 步：检查日志

在 Google Cloud 控制台中，打开日志浏览器。

打开日志浏览器
如有必要，在 Google Cloud 控制台的工具栏中选择 resource.project_display_name 中列出的项目。
将选择时间范围设置为感兴趣的时间段。
在加载的页面上，执行以下操作：
1. 使用以下过滤条件查找 Pod_Name 的 Pod 日志：
  - resource.type="k8s_container"
  - resource.labels.project_id="resource.project_display_name"
  - resource.labels.location="location"
  - resource.labels.cluster_name="cluster_name"
  - resource.labels.namespace_name="Pod_Namespace"
  - resource.labels.pod_name="Pod_Name"
2. 使用以下过滤条件查找集群审核日志：
  - logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
  - resource.type="k8s_cluster"
  - resource.labels.project_id="resource.project_display_name"
  - resource.labels.location="location"
  - resource.labels.cluster_name="cluster_name"
  - Pod_Name
3. 使用以下过滤条件查找 GKE 节点控制台日志：
  - resource.type="gce_instance"
  - resource.labels.instance_id="instance_id"

第 5 步：检查正在运行的容器

如果容器仍在运行，则或许可以直接检查容器环境。

转到 Google Cloud 控制台。

打开 Google Cloud 控制台
如有必要，在 Google Cloud 控制台的工具栏中选择 resource.project_display_name 中列出的项目。
点击激活 Cloud Shell
通过运行以下命令获取集群的 GKE 凭据。

对于可用区级集群：
```
  gcloud container clusters get-credentials cluster_name --zone location --project project_name
```
对于地区级集群：
```
  gcloud container clusters get-credentials cluster_name --region location --project project_name
```
替换以下内容：
- cluster_name：resource.labels.cluster_name 中列出的集群
- location：resource.labels.location 中列出的位置
- project_name：resource.project_display_name 中列出的项目名称
检索添加的恶意二进制文件：
```
  kubectl cp Pod_Namespace/Pod_Name:Process_Binary_Fullpath -c Container_Name  local_file
```
将 local_file 替换为本地路径，以存储添加的恶意二进制文件。

连接到容器环境：

  kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh

此命令要求容器在 /bin/sh 处安装 shell。

第 6 步：研究攻击和响应方法

查看此发现结果类型的 MITRE ATT&CK 框架条目：Ingress Tool Transfer、Native API。
点击 VirusTotal 指示器中的链接，在 VirusTotal 上查看被标记为恶意的二进制文件的 SHA-256 哈希值。VirusTotal 是一项 Alphabet 自有服务，提供了有关潜在恶意文件、网址、网域和 IP 地址的上下文。
如需制定响应方案，请将您的调查结果与 MITRE 研究和 VirusTotal 分析相结合。

第 7 步：实现响应

以下响应方案可能适合此发现结果，但也可能会影响运营。请仔细评估您在研究中收集的信息，以确定解析发现结果的最佳方法。

与容器遭入侵的项目的所有者联系。
停止或删除遭入侵的容器，并将其替换为新容器。

`Execution: Added Malicious Library Loaded`

已加载不属于原始容器映像的恶意库。攻击者可能会将恶意库加载到现有程序中，以绕过代码执行保护措施并隐藏恶意代码。如需响应此发现结果，请执行以下操作：

第 1 步：查看发现结果详情

按照查看发现结果中所述，打开 Execution: Added Malicious Library Loaded 发现结果。系统会打开发现结果详情面板，以显示摘要标签页。
在摘要标签页上，查看以下部分中的信息：
- 检测到的内容，尤其是以下字段：
  - 程序二进制文件：加载库的进程二进制文件的完整路径。
  - 库：有关添加的库的详细信息。
  - 参数：调用进程二进制文件时提供的参数。
  - 容器：受影响的容器的名称。
  - 容器 URI：要部署的容器映像的名称。
- 受影响的资源，尤其是以下字段：
  - 资源全名：集群的完整资源名称。
- 相关链接，尤其是以下字段：
  - VirusTotal 指示器：指向 VirusTotal 分析页面的链接。
点击 JSON 标签页并注意以下字段：
- sourceProperties：
  - VM_Instance_Name：在其中执行 Pod 的 GKE 节点的名称。

第 2 步：查看集群和节点

在 Google Cloud 控制台中，转到 Kubernetes 集群页面。
转到 KUBERNETES 集群
如有必要，在 Google Cloud 控制台工具栏中选择 resource.project_display_name 中列出的项目。
选择发现结果详情摘要标签页中资源全名行上列出的集群。请记下有关集群及其所有者的所有元数据。
点击节点标签页。选择 VM_Instance_Name 中列出的节点。
点击详细信息标签页，并记下 container.googleapis.com/instance_id 注解。

第 3 步：审核 Pod

在 Google Cloud 控制台中，转到 Kubernetes 工作负载页面。
转到“Kubernetes 工作负载”
如有必要，在 Google Cloud 控制台工具栏中选择 resource.project_display_name 中列出的项目。
如有必要，对发现结果详情摘要标签页中资源全名行上列出的集群以及 Pod_Namespace 中列出的 Pod 命名空间进行过滤。
选择 Pod_Name 中列出的 Pod。请记下有关 Pod 及其所有者的所有元数据。

第 4 步：检查日志

在 Google Cloud 控制台中，打开日志浏览器。

打开日志浏览器
如有必要，在 Google Cloud 控制台工具栏中选择 resource.project_display_name 中列出的项目。
将选择时间范围设置为感兴趣的时间段。
在加载的页面上，执行以下操作：
1. 使用以下过滤条件查找 Pod_Name 的 Pod 日志：
  - resource.type="k8s_container"
  - resource.labels.project_id="resource.project_display_name"
  - resource.labels.location="location"
  - resource.labels.cluster_name="cluster_name"
  - resource.labels.namespace_name="Pod_Namespace"
  - resource.labels.pod_name="Pod_Name"
2. 使用以下过滤条件查找集群审核日志：
  - logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
  - resource.type="k8s_cluster"
  - resource.labels.project_id="resource.project_display_name"
  - resource.labels.location="location"
  - resource.labels.cluster_name="cluster_name"
  - Pod_Name
3. 使用以下过滤条件查找 GKE 节点控制台日志：
  - resource.type="gce_instance"
  - resource.labels.instance_id="instance_id"

第 5 步：检查正在运行的容器

如果容器仍在运行，则或许可以直接检查容器环境。

转到 Google Cloud 控制台。

打开 Google Cloud 控制台
如有必要，在 Google Cloud 控制台工具栏中选择 resource.project_display_name 中列出的项目。
点击激活 Cloud Shell。

通过运行以下命令获取集群的 GKE 凭据。

对于可用区级集群：

  gcloud container clusters get-credentials cluster_name --zone location --project resource.project_display_name

对于地区级集群：

  gcloud container clusters get-credentials cluster_name --region location --project resource.project_display_name

检索添加的恶意库：

  kubectl cp Pod_Namespace/Pod_Name: Added_Library_Fullpath -c Container_Name  local_file

将 local_file 替换为本地路径，以存储添加的恶意库。

连接到容器环境：

  kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh

此命令要求容器在 /bin/sh 处安装 shell。

第 6 步：研究攻击和响应方法

查看此发现结果类型的 MITRE ATT&CK 框架条目：Ingress Tool Transfer、Shared Modules。
点击 VirusTotal 指示器中的链接，在 VirusTotal 上查看被标记为恶意的二进制文件的 SHA-256 哈希值。VirusTotal 是一项 Alphabet 自有服务，提供了有关潜在恶意文件、网址、网域和 IP 地址的上下文。
如需制定响应方案，请将您的调查结果与 MITRE 研究和 VirusTotal 分析相结合。

第 7 步：实现响应

以下响应方案可能适合此发现结果，但也可能会影响运营。请仔细评估您在研究中收集的信息，以确定解析发现结果的最佳方法。

与容器遭入侵的项目的所有者联系。
停止或删除遭入侵的容器，并将其替换为新容器。

`Execution: Built in Malicious Binary Executed`

已执行的二进制文件，其中包含以下二进制文件：

包含在原始容器映像中。
根据威胁情报被识别为恶意。

攻击者控制容器映像代码库或创建流水线，并将恶意二进制文件注入容器映像。如需响应此发现结果，请执行以下操作：

第 1 步：查看发现结果详情

按照查看发现结果中所述，打开 Execution: Built in Malicious Binary Executed 发现结果。系统会打开发现结果详情面板，以显示摘要标签页。
在摘要标签页上，查看以下部分中的信息：
- 检测到的内容，尤其是以下字段：
  - 程序二进制文件：内置二进制文件的绝对路径。
  - 参数：调用内置二进制文件时提供的参数。
  - 容器：受影响的容器的名称。
  - 容器 URI：要部署的容器映像的名称。
- 受影响的资源，尤其是以下字段：
  - 资源全名：集群的完整资源名称，其中包括项目编号、位置和集群名称。
- 相关链接，尤其是以下字段：
  - VirusTotal 指示器：指向 VirusTotal 分析页面的链接。
点击 JSON 并注意以下字段：
- sourceProperties：
  - VM_Instance_Name：在其中执行 Pod 的 GKE 节点的名称。

第 2 步：查看集群和节点

在 Google Cloud 控制台中，转到 Kubernetes 集群页面。
转到 KUBERNETES 集群
如有必要，在 Google Cloud 控制台的工具栏中选择 resource.project_display_name 中列出的项目。
选择发现结果详情摘要标签页中资源全名行上列出的集群。请记下有关集群及其所有者的所有元数据。
点击节点标签页。选择 VM_Instance_Name 中列出的节点。
点击详细信息标签页，并记下 container.googleapis.com/instance_id 注解。

第 3 步：审核 Pod

在 Google Cloud 控制台中，转到 Kubernetes 工作负载页面。
转到“Kubernetes 工作负载”
如有必要，在 Google Cloud 控制台工具栏中选择 resource.project_display_name 中列出的项目。
如有必要，对发现结果详情摘要标签页中资源全名行上列出的集群以及 Pod_Namespace 中列出的 Pod 命名空间进行过滤。
选择 Pod_Name 中列出的 Pod。请记下有关 Pod 及其所有者的所有元数据。

第 4 步：检查日志

在 Google Cloud 控制台中，打开日志浏览器。

打开日志浏览器
如有必要，在 Google Cloud 控制台的工具栏中选择 resource.project_display_name 中列出的项目。
将选择时间范围设置为感兴趣的时间段。
在加载的页面上，执行以下操作：
1. 使用以下过滤条件查找 Pod_Name 的 Pod 日志：
  - resource.type="k8s_container"
  - resource.labels.project_id="resource.project_display_name"
  - resource.labels.location="location"
  - resource.labels.cluster_name="cluster_name"
  - resource.labels.namespace_name="Pod_Namespace"
  - resource.labels.pod_name="Pod_Name"
2. 使用以下过滤条件查找集群审核日志：
  - logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
  - resource.type="k8s_cluster"
  - resource.labels.project_id="resource.project_display_name"
  - resource.labels.location="location"
  - resource.labels.cluster_name="cluster_name"
  - Pod_Name
3. 使用以下过滤条件查找 GKE 节点控制台日志：
  - resource.type="gce_instance"
  - resource.labels.instance_id="instance_id"

第 5 步：检查正在运行的容器

如果容器仍在运行，则或许可以直接检查容器环境。

转到 Google Cloud 控制台。

打开 Google Cloud 控制台
如有必要，在 Google Cloud 控制台的工具栏中选择 resource.project_display_name 中列出的项目。
点击激活 Cloud Shell
通过运行以下命令获取集群的 GKE 凭据。

对于可用区级集群：
```
  gcloud container clusters get-credentials cluster_name --zone location --project project_name
```
对于地区级集群：
```
  gcloud container clusters get-credentials cluster_name --region location --project project_name
```
替换以下内容：
- cluster_name：resource.labels.cluster_name 中列出的集群
- location：resource.labels.location 中列出的位置
- project_name：resource.project_display_name 中列出的项目名称
检索内置的恶意二进制文件：
```
  kubectl cp Pod_Namespace/Pod_Name:Process_Binary_Fullpath -c Container_Name  local_file
```
将 local_file 替换为用于存储构建的恶意二进制文件的本地路径。

连接到容器环境：

  kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh

此命令要求容器在 /bin/sh 处安装 shell。

第 6 步：研究攻击和响应方法

查看此发现结果类型的 MITRE ATT&CK 框架条目：Ingress Tool Transfer、Native API。
点击 VirusTotal 指示器中的链接，在 VirusTotal 上查看被标记为恶意的二进制文件的 SHA-256 哈希值。VirusTotal 是一项 Alphabet 自有服务，提供了有关潜在恶意文件、网址、网域和 IP 地址的上下文。
如需制定响应方案，请将您的调查结果与 MITRE 研究和 VirusTotal 分析相结合。

第 7 步：实现响应

以下响应方案可能适合此发现结果，但也可能会影响运营。请仔细评估您在研究中收集的信息，以确定解析发现结果的最佳方法。

与容器遭入侵的项目的所有者联系。
停止或删除遭入侵的容器，并将其替换为新容器。

`Execution: Container Escape`

执行了用于容器逃逸活动的已知可疑工具二进制文件。这可能表示容器逃逸尝试，即容器内的进程尝试打破隔离并与主机系统或其他容器交互。这是一个高严重性问题，因为这表明攻击者可能正在尝试获得超出容器边界的访问权限，可能会破坏主机或其他基础架构。容器逃逸可能是由配置错误、容器运行时中的漏洞或特权容器被利用所致。

如需响应此发现结果，请执行以下操作：

第 1 步：查看发现结果详情

按照查看发现结果中所述，打开 Execution: Container Escape 发现结果。系统会打开发现结果详情面板，以显示摘要标签页。
在摘要标签页上，查看以下部分中的信息：
- 检测到的内容，尤其是以下字段：
  - 程序二进制文件：所执行二进制文件的绝对路径。
  - 参数：二进制文件执行期间传递的参数。
- 受影响的资源，尤其是以下字段：
  - 资源全名：集群的完整资源名称，其中包括项目编号、位置和集群名称。
在发现结果的详情视图中，点击 JSON 标签页。
在 JSON 中，记下以下字段。
- resource：
  - project_display_name：包含集群的项目的名称。
- finding：
  - processes：
  - binary：
    - path：已执行二进制文件的完整路径。
  - args：执行二进制文件时提供的参数。
- sourceProperties：
  - Pod_Namespace：Pod 的 Kubernetes 命名空间的名称。
  - Pod_Name：GKE Pod 的名称。
  - Container_Name：受影响的容器的名称。
  - Container_Image_Uri：要部署的容器映像的名称。
  - VM_Instance_Name：在其中执行 Pod 的 GKE 节点的名称。
找出此容器在相似时间发生的其他问题。相关发现可能表明此活动具有恶意，而不是未遵循最佳实践。

第 2 步：查看集群和节点

在 Google Cloud 控制台中，前往 Kubernetes 集群页面。
转到 Kubernetes 集群
如有必要，在 Google Cloud 控制台工具栏中选择 resource.project_display_name 中列出的项目。
选择发现结果详情摘要标签页中资源全名行上列出的集群。请记下有关集群及其所有者的所有元数据。
点击节点标签页。选择 VM_Instance_Name 中列出的节点。
点击详细信息标签页，并记下 container.googleapis.com/instance_id 注解。

第 3 步：审核 Pod

在 Google Cloud 控制台中，前往 Kubernetes 工作负载页面。
前往“Kubernetes 工作负载”页面
如有必要，在 Google Cloud 控制台工具栏中选择 resource.project_display_name 中列出的项目。
如有必要，对发现结果详情摘要标签页中资源全名行上列出的集群以及 Pod_Namespace 中列出的 Pod 命名空间进行过滤。
选择 Pod_Name 中列出的 Pod。请记下有关 Pod 及其所有者的所有元数据。

第 4 步：检查日志

在 Google Cloud 控制台中，打开日志浏览器。

前往 Logs Explorer
如有必要，在 Google Cloud 控制台工具栏中选择 resource.project_display_name 中列出的项目。
将选择时间范围设置为感兴趣的时间段。
在加载的页面上，执行以下操作：
1. 使用以下过滤条件查找 Pod_Name 的 Pod 日志：
  - resource.type="k8s_container"
  - resource.labels.project_id="RESOURCE.PROJECT_DISPLAY_NAME"
  - resource.labels.location="LOCATION"
  - resource.labels.cluster_name="CLUSTER_NAME"
  - resource.labels.namespace_name="POD_NAMESPACE"
  - resource.labels.pod_name="POD_NAME"
2. 使用以下过滤条件查找集群审核日志：
  - logName="projects/RESOURCE.PROJECT_DISPLAY_NAME/logs/cloudaudit.googleapis.com%2Factivity"
  - resource.type="k8s_cluster"
  - resource.labels.project_id="RESOURCE.PROJECT_DISPLAY_NAME"
  - resource.labels.location="LOCATION"
  - resource.labels.cluster_name="CLUSTER_NAME"
  - POD_NAME
3. 使用以下过滤条件查找 GKE 节点控制台日志：
  - resource.type="gce_instance"
  - resource.labels.instance_id="INSTANCE_ID"

第 5 步：检查正在运行的容器

如果容器仍在运行，则或许可以直接检查容器环境。

转到 Google Cloud 控制台。

打开 Google Cloud 控制台
如有必要，在 Google Cloud 控制台工具栏中选择 resource.project_display_name 中列出的项目。
点击激活 Cloud Shell

通过运行以下命令获取集群的 GKE 凭据。

对于可用区级集群：

gcloud container clusters get-credentials CLUSTER_NAME \
      --zone LOCATION \
      --project PROJECT_NAME

对于地区级集群：

gcloud container clusters get-credentials CLUSTER_NAME \
      --region LOCATION \
      --project PROJECT_NAME

替换以下内容：

CLUSTER_NAME：resource.labels.cluster_name 中列出的集群
LOCATION：resource.labels.location 中列出的位置
PROJECT_NAME：resource.project_display_name 中列出的项目名称

检索已执行的二进制文件：

kubectl cp \
      POD_NAMESPACE/POD_NAME:PROCESS_BINARY_FULLPATH \
      -c CONTAINER_NAME \
      LOCAL_FILE

将 local_file 替换为本地文件路径，以存储添加的二进制文件。

通过运行以下命令连接到容器环境：

kubectl exec \
      --namespace=POD_NAMESPACE \
      -ti POD_NAME \
      -c CONTAINER_NAME \
      -- /bin/sh

此命令要求容器在 /bin/sh 处安装 shell。

第 6 步：研究攻击和响应方法

查看此发现结果类型的 MITRE ATT&CK 框架条目：逃离到主机。
如需制定响应方案，请将您的调查结果与 MITRE 研究相结合。

第 7 步：实现响应

以下响应方案可能适合此发现结果，但也可能会影响运营。请仔细评估您在研究中收集的信息，以确定解析发现结果的最佳方法。

与容器遭入侵的项目的所有者联系。
停止或删除遭入侵的容器，并将其替换为新容器。

`Execution: Kubernetes Attack Tool Execution`

在容器中执行了 Kubernetes 攻击工具，这表明攻击者可能尝试利用 Kubernetes 环境中的漏洞。攻击者通常会使用这些工具来提升特权、执行横向移动或破坏集群中的其他资源。这是一条严重级别的发现，因为执行此类工具表明有人刻意尝试控制 Kubernetes 组件（例如 API 服务器、节点或工作负载）。攻击者可能会使用这些工具绕过安全控制措施、操纵配置或渗漏敏感数据。

如需响应此发现结果，请执行以下操作：

第 1 步：查看发现结果详情

按照查看发现结果中所述，打开 Execution: Kubernetes Attack Tool Execution 发现结果。系统会打开发现结果详情面板，以显示摘要标签页。
在摘要标签页上，查看以下部分中的信息：
- 检测到的内容，尤其是以下字段：
  - 程序二进制文件：所执行二进制文件的绝对路径。
  - 参数：二进制文件执行期间传递的参数。
- 受影响的资源，尤其是以下字段：
  - 资源全名：集群的完整资源名称，其中包括项目编号、位置和集群名称。
在发现结果的详情视图中，点击 JSON 标签页。
在 JSON 中，记下以下字段。
- resource：
  - project_display_name：包含集群的项目的名称。
- finding：
  - processes：
    - binary：
    - path：已执行二进制文件的完整路径。
  - args：执行二进制文件时提供的参数。
- sourceProperties：
  - Pod_Namespace：Pod 的 Kubernetes 命名空间的名称。
  - Pod_Name：GKE Pod 的名称。
  - Container_Name：受影响的容器的名称。
  - Container_Image_Uri：要部署的容器映像的名称。
  - VM_Instance_Name：在其中执行 Pod 的 GKE 节点的名称。
找出此容器在相似时间发生的其他问题。相关发现可能表明此活动具有恶意，而不是未遵循最佳实践。

第 2 步：查看集群和节点

在 Google Cloud 控制台中，前往 Kubernetes 集群页面。
转到 Kubernetes 集群
如有必要，在 Google Cloud 控制台工具栏中选择 resource.project_display_name 中列出的项目。
选择发现结果详情摘要标签页中资源全名行上列出的集群。请记下有关集群及其所有者的所有元数据。
点击节点标签页。选择 VM_Instance_Name 中列出的节点。
点击详细信息标签页，并记下 container.googleapis.com/instance_id 注解。

第 3 步：审核 Pod

在 Google Cloud 控制台中，前往 Kubernetes 工作负载页面。
前往“Kubernetes 工作负载”页面
如有必要，在 Google Cloud 控制台工具栏中选择 resource.project_display_name 中列出的项目。
如有必要，对发现结果详情摘要标签页中资源全名行上列出的集群以及 Pod_Namespace 中列出的 Pod 命名空间进行过滤。
选择 Pod_Name 中列出的 Pod。请记下有关 Pod 及其所有者的所有元数据。

第 4 步：检查日志

在 Google Cloud 控制台中，打开日志浏览器。

前往 Logs Explorer
如有必要，在 Google Cloud 控制台工具栏中选择 resource.project_display_name 中列出的项目。
将选择时间范围设置为感兴趣的时间段。
在加载的页面上，执行以下操作：
1. 使用以下过滤条件查找 Pod_Name 的 Pod 日志：
  - resource.type="k8s_container"
  - resource.labels.project_id="RESOURCE.PROJECT_DISPLAY_NAME"
  - resource.labels.location="LOCATION"
  - resource.labels.cluster_name="CLUSTER_NAME"
  - resource.labels.namespace_name="POD_NAMESPACE"
  - resource.labels.pod_name="POD_NAME"
2. 使用以下过滤条件查找集群审核日志：
  - logName="projects/RESOURCE.PROJECT_DISPLAY_NAME/logs/cloudaudit.googleapis.com%2Factivity"
  - resource.type="k8s_cluster"
  - resource.labels.project_id="RESOURCE.PROJECT_DISPLAY_NAME"
  - resource.labels.location="LOCATION"
  - resource.labels.cluster_name="CLUSTER_NAME"
  - POD_NAME
3. 使用以下过滤条件查找 GKE 节点控制台日志：
  - resource.type="gce_instance"
  - resource.labels.instance_id="INSTANCE_ID"

第 5 步：检查正在运行的容器

如果容器仍在运行，则或许可以直接检查容器环境。

转到 Google Cloud 控制台。

打开 Google Cloud 控制台
如有必要，在 Google Cloud 控制台工具栏中选择 resource.project_display_name 中列出的项目。
点击激活 Cloud Shell

通过运行以下命令获取集群的 GKE 凭据。

对于可用区级集群：

gcloud container clusters get-credentials CLUSTER_NAME --zone LOCATION --project PROJECT_NAME

对于地区级集群：

gcloud container clusters get-credentials CLUSTER_NAME --region LOCATION --project PROJECT_NAME

替换以下内容：

CLUSTER_NAME：resource.labels.cluster_name 中列出的集群
LOCATION：resource.labels.location 中列出的位置
PROJECT_NAME：resource.project_display_name 中列出的项目名称

检索已执行的二进制文件：

kubectl cp \
      POD_NAMESPACE/POD_NAME:PROCESS_BINARY_FULLPATH \
      -c CONTAINER_NAME \
      LOCAL_FILE

将 LOCAL_FILE 替换为本地文件路径，以存储已执行的二进制文件。

通过运行以下命令连接到容器环境：

kubectl exec \
      --namespace=POD_NAMESPACE \
      -ti POD_NAME \
      -c CONTAINER_NAME \
      -- /bin/sh

此命令要求容器在 /bin/sh 处安装 shell。

第 6 步：研究攻击和响应方法

查看此发现结果类型的 MITRE ATT&CK 框架条目：获取功能：工具。
如需制定响应方案，请将您的调查结果与 MITRE 研究相结合。

第 7 步：实现响应

以下响应方案可能适合此发现结果，但也可能会影响运营。请仔细评估您在研究中收集的信息，以确定解析发现结果的最佳方法。

与容器遭入侵的项目的所有者联系。
停止或删除遭入侵的容器，并将其替换为新容器。

`Execution: Local Reconnaissance Tool Execution`

在容器内执行了本地侦察工具，这表明攻击者正在收集有关容器环境的信息，例如网络配置、活动进程或已挂载的文件系统。此类工具通常在攻击的早期阶段使用，用于绘制潜在目标图和识别弱点。这是一个中等严重性的发现，因为它表明攻击者正在积极探测容器以寻找进一步利用的机会。

如需响应此发现结果，请执行以下操作：

第 1 步：查看发现结果详情

按照查看发现结果中所述，打开 Execution: Local Reconnaissance Tool Execution 发现结果。系统会打开发现结果详情面板，以显示摘要标签页。
在摘要标签页上，查看以下部分中的信息：
- 检测到的内容，尤其是以下字段：
  - 程序二进制文件：所执行二进制文件的绝对路径。
  - 参数：二进制文件执行期间传递的参数。
- 受影响的资源，尤其是以下字段：
  - 资源全名：集群的完整资源名称，其中包括项目编号、位置和集群名称。
在发现结果的详情视图中，点击 JSON 标签页。
在 JSON 中，记下以下字段。
- resource：
  - project_display_name：包含集群的项目的名称。
- finding：
  - processes：
    - binary：
    - path：已执行二进制文件的完整路径。
  - args：执行二进制文件时提供的参数。
- sourceProperties：
  - Pod_Namespace：Pod 的 Kubernetes 命名空间的名称。
  - Pod_Name：GKE Pod 的名称。
  - Container_Name：受影响的容器的名称。
  - Container_Image_Uri：要部署的容器映像的名称。
  - VM_Instance_Name：在其中执行 Pod 的 GKE 节点的名称。
找出此容器在相似时间发生的其他问题。相关发现可能表明此活动具有恶意，而不是未遵循最佳实践。

第 2 步：查看集群和节点

在 Google Cloud 控制台中，前往 Kubernetes 集群页面。
转到 Kubernetes 集群
如有必要，在 Google Cloud 控制台工具栏中选择 resource.project_display_name 中列出的项目。
选择发现结果详情摘要标签页中资源全名行上列出的集群。请记下有关集群及其所有者的所有元数据。
点击节点标签页。选择 VM_Instance_Name 中列出的节点。
点击详细信息标签页，并记下 container.googleapis.com/instance_id 注解。

第 3 步：审核 Pod

在 Google Cloud 控制台中，前往 Kubernetes 工作负载页面。
前往“Kubernetes 工作负载”页面
如有必要，在 Google Cloud 控制台工具栏中选择 resource.project_display_name 中列出的项目。
如有必要，对发现结果详情摘要标签页中资源全名行上列出的集群以及 Pod_Namespace 中列出的 Pod 命名空间进行过滤。
选择 Pod_Name 中列出的 Pod。请记下有关 Pod 及其所有者的所有元数据。

第 4 步：检查日志

在 Google Cloud 控制台中，打开日志浏览器。

前往 Logs Explorer
如有必要，在 Google Cloud 控制台工具栏中选择 resource.project_display_name 中列出的项目。
将选择时间范围设置为感兴趣的时间段。
在加载的页面上，执行以下操作：
1. 使用以下过滤条件查找 Pod_Name 的 Pod 日志：
  - resource.type="k8s_container"
  - resource.labels.project_id="RESOURCE.PROJECT_DISPLAY_NAME"
  - resource.labels.location="LOCATION"
  - resource.labels.cluster_name="CLUSTER_NAME"
  - resource.labels.namespace_name="POD_NAMESPACE"
  - resource.labels.pod_name="POD_NAME"
2. 使用以下过滤条件查找集群审核日志：
  - logName="projects/RESOURCE.PROJECT_DISPLAY_NAME/logs/cloudaudit.googleapis.com%2Factivity"
  - resource.type="k8s_cluster"
  - resource.labels.project_id="RESOURCE.PROJECT_DISPLAY_NAME"
  - resource.labels.location="LOCATION"
  - resource.labels.cluster_name="CLUSTER_NAME"
  - POD_NAME
3. 使用以下过滤条件查找 GKE 节点控制台日志：
  - resource.type="gce_instance"
  - resource.labels.instance_id="INSTANCE_ID"

第 5 步：检查正在运行的容器

如果容器仍在运行，则或许可以直接检查容器环境。

转到 Google Cloud 控制台。

打开 Google Cloud 控制台
如有必要，在 Google Cloud 控制台工具栏中选择 resource.project_display_name 中列出的项目。
点击激活 Cloud Shell

通过运行以下命令获取集群的 GKE 凭据。

对于可用区级集群：

gcloud container clusters get-credentials CLUSTER_NAME \
      --zone LOCATION \
      --project PROJECT_NAME

对于地区级集群：

gcloud container clusters get-credentials CLUSTER_NAME \
      --region LOCATION \
      --project PROJECT_NAME

替换以下内容：

CLUSTER_NAME：resource.labels.cluster_name 中列出的集群
LOCATION：resource.labels.location 中列出的位置
PROJECT_NAME：resource.project_display_name 中列出的项目名称

检索添加的二进制文件：

kubectl cp \
      POD_NAMESPACE/POD_NAME:PROCESS_BINARY_FULLPATH \
      -c CONTAINER_NAME \
      LOCAL_FILE

将 LOCAL_FILE 替换为本地文件路径，以存储添加的二进制文件。

通过运行以下命令连接到容器环境：

kubectl exec \
      --namespace=POD_NAMESPACE \
      -ti POD_NAME \
      -c CONTAINER_NAME \
      -- /bin/sh

此命令要求容器在 /bin/sh 处安装 shell。

第 6 步：研究攻击和响应方法

查看此发现结果类型的 MITRE ATT&CK 框架条目：主动扫描。
如需制定响应方案，请将您的调查结果与 MITRE 研究相结合。

第 7 步：实现响应

以下响应方案可能适合此发现结果，但也可能会影响运营。请仔细评估您在研究中收集的信息，以确定解析发现结果的最佳方法。

与容器遭入侵的项目的所有者联系。
停止或删除遭入侵的容器，并将其替换为新容器。

`Execution: Malicious Python executed`

机器学习模型将已执行的 Python 代码识别为恶意代码。攻击者可以利用 Python 来转移工具，并在不使用二进制文件的情况下执行命令。确保容器不可变是一项重要的最佳实践。使用脚本转移工具可能会模仿攻击者的入侵工具传输技术，导致不必要的检测。

如需响应此发现结果，请执行以下操作：

第 1 步：查看发现结果详情

按照查看发现结果中所述，打开 Execution: Malicious Python executed 发现结果。系统会打开发现结果详情面板，以显示摘要标签页。
在摘要标签页上，查看以下部分中的信息：
- 检测到的内容，尤其是以下字段：
  - 程序二进制文件：有关调用脚本的解释器的详细信息。
  - 脚本：磁盘上的脚本名称的绝对路径；此属性仅会针对写入磁盘的脚本显示，不会针对字面量脚本执行显示，例如 python3 -c。
  - 参数：调用脚本时提供的参数。
- 受影响的资源，尤其是以下字段：
  - 资源全名：集群的完整资源名称，其中包括项目编号、位置和集群名称。
- 相关链接，尤其是以下字段：
  - VirusTotal 指示器：指向 VirusTotal 分析页面的链接。
在发现结果的详情视图中，点击 JSON 标签页。
在 JSON 中，记下以下字段。
- finding：
  - processes：
  - script：
    - contents：已执行脚本的内容，由于性能原因，内容可能会被截断；这有助于进行调查
    - sha256：script.contents 的 SHA-256 哈希
- resource：
  - project_display_name：包含资产的项目的名称。
- sourceProperties：
  - Pod_Namespace：Pod 的 Kubernetes 命名空间的名称。
  - Pod_Name：GKE Pod 的名称。
  - Container_Name：受影响的容器的名称。
  - Container_Image_Uri：要执行的容器映像的名称。
  - VM_Instance_Name：在其中执行 Pod 的 GKE 节点的名称。
找出此容器在相似时间发生的其他问题。例如，如果脚本删除了二进制文件，请检查是否有与该二进制文件相关的发现。

第 2 步：查看集群和节点

在 Google Cloud 控制台中，转到 Kubernetes 集群页面。

转到 KUBERNETES 集群
如有必要，在 Google Cloud 控制台的工具栏中选择 resource.project_display_name 中列出的项目。
选择发现结果详情摘要标签页中资源全名行上列出的集群。请记下有关集群及其所有者的所有元数据。
点击节点标签页。选择 VM_Instance_Name 中列出的节点。
点击详细信息标签页，并记下 container.googleapis.com/instance_id 注解。

第 3 步：审核 Pod

在 Google Cloud 控制台中，转到 Kubernetes 工作负载页面。

转到“Kubernetes 工作负载”
如有必要，在 Google Cloud 控制台的工具栏中选择 resource.project_display_name 中列出的项目。
如有必要，对 resource.name 中列出的集群和 Pod_Namespace 中列出的 Pod 命名空间进行过滤。
选择 Pod_Name 中列出的 Pod。请记下有关 Pod 及其所有者的所有元数据。

第 4 步：检查日志

在 Google Cloud 控制台中，打开日志浏览器。

打开日志浏览器
如有必要，在 Google Cloud 控制台工具栏中选择 resource.project_display_name 中列出的项目。
将选择时间范围设置为感兴趣的时间段。
在加载的页面上，执行以下操作：
1. 使用以下过滤条件查找 Pod_Name 的 Pod 日志：
  - resource.type="k8s_container"
  - resource.labels.project_id="resource.project_display_name"
  - resource.labels.location="location"
  - resource.labels.cluster_name="cluster_name"
  - resource.labels.namespace_name="Pod_Namespace"
  - resource.labels.pod_name="Pod_Name"
2. 使用以下过滤条件查找集群审核日志：
  - logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
  - resource.type="k8s_cluster"
  - resource.labels.project_id="resource.project_display_name"
  - resource.labels.location="location"
  - resource.labels.cluster_name="cluster_name"
  - Pod_Name
3. 使用以下过滤条件查找 GKE 节点控制台日志：
  - resource.type="gce_instance"
  - resource.labels.instance_id="instance_id"

第 5 步：检查正在运行的容器

如果容器仍在运行，则或许可以直接检查容器环境。

在 Google Cloud 控制台中，转到 Kubernetes 集群页面。

转到 KUBERNETES 集群
点击 resource.labels.cluster_name 中显示的集群的名称。
在集群页面上，点击连接，然后点击在 Cloud Shell 中运行。

Cloud Shell 将在终端中为集群启动和添加命令。
按 Enter 键，如果出现为 Cloud Shell 提供授权对话框，请点击授权。
通过运行以下命令连接到容器环境：
```
  kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
```
此命令要求容器在 /bin/sh 处安装 shell。

第 6 步：研究攻击和响应方法

查看此发现类型的 MITRE ATT&CK 框架条目：Command and Scripting Interpreter、Ingress Tool Transfer。
点击 VirusTotal 指示器中的链接，在 VirusTotal 上查看被标记为恶意的二进制文件的 SHA-256 哈希值。VirusTotal 是一项 Alphabet 自有服务，提供了有关潜在恶意文件、网址、网域和 IP 地址的上下文。
如需制定响应方案，请将您的调查结果与 MITRE 研究和 VirusTotal 分析相结合。

第 7 步：实现响应

以下响应方案可能适合此发现结果，但也可能会影响运营。请仔细评估您在研究中收集的信息，以确定解析发现结果的最佳方法。

如果 Python 对容器进行了预期的更改，请重新构建容器映像，以免需要进行任何更改。这样，容器就可以不可变。
否则，请与容器遭入侵的项目的所有者联系。
停止或删除遭入侵的容器，并将其替换为新容器。

`Execution: Modified Malicious Binary Executed`

已执行的二进制文件，其中包含以下二进制文件：

包含在原始容器映像中。
在容器运行时修改。
根据威胁情报被识别为恶意。

攻击者通常在刚开始入侵后安装漏洞工具和恶意软件。如需响应此发现结果，请执行以下操作：

第 1 步：查看发现结果详情

按照查看发现结果中所述，打开 Execution: Modified Malicious Binary Executed 发现结果。系统会打开发现结果详情面板，以显示摘要标签页。
在摘要标签页上，查看以下部分中的信息：
- 检测到的内容，尤其是以下字段：
  - 程序二进制文件：修改后的二进制文件的绝对路径。
  - 参数：调用修改后的二进制文件时提供的参数。
  - 容器：受影响的容器的名称。
  - 容器 URI：要部署的容器映像的名称。
- 受影响的资源，尤其是以下字段：
  - 资源全名：集群的完整资源名称，其中包括项目编号、位置和集群名称。
- 相关链接，尤其是以下字段：
  - VirusTotal 指示器：指向 VirusTotal 分析页面的链接。
点击 JSON 并注意以下字段：
- sourceProperties：
  - VM_Instance_Name：在其中执行 Pod 的 GKE 节点的名称。

第 2 步：查看集群和节点

在 Google Cloud 控制台中，转到 Kubernetes 集群页面。
转到 KUBERNETES 集群
如有必要，在 Google Cloud 控制台的工具栏中选择 resource.project_display_name 中列出的项目。
选择发现结果详情摘要标签页中资源全名行上列出的集群。请记下有关集群及其所有者的所有元数据。
点击节点标签页。选择 VM_Instance_Name 中列出的节点。
点击详细信息标签页，并记下 container.googleapis.com/instance_id 注解。

第 3 步：审核 Pod

在 Google Cloud 控制台中，转到 Kubernetes 工作负载页面。
转到“Kubernetes 工作负载”
如有必要，在 Google Cloud 控制台工具栏中选择 resource.project_display_name 中列出的项目。
如有必要，对发现结果详情摘要标签页中资源全名行上列出的集群以及 Pod_Namespace 中列出的 Pod 命名空间进行过滤。
选择 Pod_Name 中列出的 Pod。请记下有关 Pod 及其所有者的所有元数据。

第 4 步：检查日志

在 Google Cloud 控制台中，打开日志浏览器。

打开日志浏览器
如有必要，在 Google Cloud 控制台的工具栏中选择 resource.project_display_name 中列出的项目。
将选择时间范围设置为感兴趣的时间段。
在加载的页面上，执行以下操作：
1. 使用以下过滤条件查找 Pod_Name 的 Pod 日志：
  - resource.type="k8s_container"
  - resource.labels.project_id="resource.project_display_name"
  - resource.labels.location="location"
  - resource.labels.cluster_name="cluster_name"
  - resource.labels.namespace_name="Pod_Namespace"
  - resource.labels.pod_name="Pod_Name"
2. 使用以下过滤条件查找集群审核日志：
  - logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
  - resource.type="k8s_cluster"
  - resource.labels.project_id="resource.project_display_name"
  - resource.labels.location="location"
  - resource.labels.cluster_name="cluster_name"
  - Pod_Name
3. 使用以下过滤条件查找 GKE 节点控制台日志：
  - resource.type="gce_instance"
  - resource.labels.instance_id="instance_id"

第 5 步：检查正在运行的容器

如果容器仍在运行，则或许可以直接检查容器环境。

转到 Google Cloud 控制台。

打开 Google Cloud 控制台
如有必要，在 Google Cloud 控制台的工具栏中选择 resource.project_display_name 中列出的项目。
点击激活 Cloud Shell
通过运行以下命令获取集群的 GKE 凭据。

对于可用区级集群：
```
  gcloud container clusters get-credentials cluster_name --zone location --project project_name
```
对于地区级集群：
```
  gcloud container clusters get-credentials cluster_name --region location --project project_name
```
替换以下内容：
- cluster_name：resource.labels.cluster_name 中列出的集群
- location：resource.labels.location 中列出的位置
- project_name：resource.project_display_name 中列出的项目名称
检索修改后的恶意二进制文件：
```
  kubectl cp Pod_Namespace/Pod_Name:Process_Binary_Fullpath -c Container_Name  local_file
```
将 local_file 替换为用于存储经过修改的恶意二进制文件的本地路径。

连接到容器环境：

  kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh

此命令要求容器在 /bin/sh 处安装 shell。

第 6 步：研究攻击和响应方法

查看此发现结果类型的 MITRE ATT&CK 框架条目：Ingress Tool Transfer、Native API。
点击 VirusTotal 指示器中的链接，在 VirusTotal 上查看被标记为恶意的二进制文件的 SHA-256 哈希值。VirusTotal 是一项 Alphabet 自有服务，提供了有关潜在恶意文件、网址、网域和 IP 地址的上下文。
如需制定响应方案，请将您的调查结果与 MITRE 研究和 VirusTotal 分析相结合。

第 7 步：实现响应

以下响应方案可能适合此发现结果，但也可能会影响运营。请仔细评估您在研究中收集的信息，以确定解析发现结果的最佳方法。

与容器遭入侵的项目的所有者联系。
停止或删除遭入侵的容器，并将其替换为新容器。

`Execution: Modified Malicious Library Loaded`

已加载的库，其中包含以下内容：

包含在原始容器映像中。
在容器运行时修改。
根据威胁情报被识别为恶意。

攻击者可能会将恶意库加载到现有程序中，以绕过代码执行保护措施并隐藏恶意代码。如需响应此发现结果，请执行以下操作：

第 1 步：查看发现结果详情

按照查看发现结果中所述，打开 Execution: Modified Malicious Library Loaded 发现结果。系统会打开发现结果详情面板，以显示摘要标签页。
在摘要标签页上，查看以下部分中的信息：
- 检测到的内容，尤其是以下字段：
  - 程序二进制文件：加载库的进程二进制文件的完整路径。
  - 库：有关修改的库的详细信息。
  - 参数：调用进程二进制文件时提供的参数。
  - 容器：受影响的容器的名称。
  - 容器 URI：要部署的容器映像的名称。
- 受影响的资源，尤其是以下字段：
  - 资源全名：集群的完整资源名称。
- 相关链接，尤其是以下字段：
  - VirusTotal 指示器：指向 VirusTotal 分析页面的链接。
点击 JSON 标签页并注意以下字段：
- sourceProperties：
  - VM_Instance_Name：在其中执行 Pod 的 GKE 节点的名称。

第 2 步：查看集群和节点

在 Google Cloud 控制台中，转到 Kubernetes 集群页面。
转到 KUBERNETES 集群
如有必要，在 Google Cloud 控制台工具栏中选择 resource.project_display_name 中列出的项目。
选择 resource.name 中列出的集群。请记下有关集群及其所有者的所有元数据。
点击节点标签页。选择 VM_Instance_Name 中列出的节点。
点击详细信息标签页，并记下 container.googleapis.com/instance_id 注解。

第 3 步：审核 Pod

在 Google Cloud 控制台中，转到 Kubernetes 工作负载页面。
转到“Kubernetes 工作负载”
如有必要，在 Google Cloud 控制台工具栏中选择 resource.project_display_name 中列出的项目。
如有必要，对发现结果详情摘要标签页中资源全名行上列出的集群以及 Pod_Namespace 中列出的 Pod 命名空间进行过滤。
选择 Pod_Name 中列出的 Pod。请记下有关 Pod 及其所有者的所有元数据。

第 4 步：检查日志

在 Google Cloud 控制台中，打开日志浏览器。

打开日志浏览器
如有必要，在 Google Cloud 控制台工具栏中选择 resource.project_display_name 中列出的项目。
将选择时间范围设置为感兴趣的时间段。
在加载的页面上，执行以下操作：
1. 使用以下过滤条件查找 Pod_Name 的 Pod 日志：
  - resource.type="k8s_container"
  - resource.labels.project_id="resource.project_display_name"
  - resource.labels.location="location"
  - resource.labels.cluster_name="cluster_name"
  - resource.labels.namespace_name="Pod_Namespace"
  - resource.labels.pod_name="Pod_Name"
2. 使用以下过滤条件查找集群审核日志：
  - logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
  - resource.type="k8s_cluster"
  - resource.labels.project_id="resource.project_display_name"
  - resource.labels.location="location"
  - resource.labels.cluster_name="cluster_name"
  - Pod_Name
3. 使用以下过滤条件查找 GKE 节点控制台日志：
  - resource.type="gce_instance"
  - resource.labels.instance_id="instance_id"

第 5 步：检查正在运行的容器

如果容器仍在运行，则或许可以直接检查容器环境。

转到 Google Cloud 控制台。

打开 Google Cloud 控制台
如有必要，在 Google Cloud 控制台工具栏中选择 resource.project_display_name 中列出的项目。
点击激活 Cloud Shell。

通过运行以下命令获取集群的 GKE 凭据。

对于可用区级集群：

  gcloud container clusters get-credentials cluster_name --zone location --project resource.project_display_name

对于地区级集群：

  gcloud container clusters get-credentials cluster_name --region location --project resource.project_display_name

检索修改后的恶意库：

  kubectl cp Pod_Namespace/Pod_Name: Added_Library_Fullpath -c Container_Name  local_file

将 local_file 替换为本地路径，以存储修改后的恶意库。

连接到容器环境：

  kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh

此命令要求容器在 /bin/sh 处安装 shell。

第 6 步：研究攻击和响应方法

查看此发现结果类型的 MITRE ATT&CK 框架条目：Ingress Tool Transfer、Shared Modules。
点击 VirusTotal 指示器中的链接，在 VirusTotal 上查看被标记为恶意的二进制文件的 SHA-256 哈希值。VirusTotal 是一项 Alphabet 自有服务，提供了有关潜在恶意文件、网址、网域和 IP 地址的上下文。
如需制定响应方案，请将您的调查结果与 MITRE 研究和 VirusTotal 分析相结合。

第 7 步：实现响应

以下响应方案可能适合此发现结果，但也可能会影响运营。请仔细评估您在研究中收集的信息，以确定解析发现结果的最佳方法。

与容器遭入侵的项目的所有者联系。
停止或删除遭入侵的容器，并将其替换为新容器。

`Malicious Script Executed`

机器学习模型将执行的 Bash 代码识别为恶意代码。攻击者可以利用 Bash 来转移工具，并在不使用二进制文件的情况下执行命令。确保容器不可变是一项重要的最佳实践。使用脚本转移工具可能会模仿攻击者的入侵工具传输技术，从而导致不必要的检测。

如需响应此发现结果，请执行以下操作：

第 1 步：查看发现结果详情

按照查看发现结果中所述，打开 Malicious Script Executed 发现结果。系统会打开发现结果详情面板，以显示摘要标签页。
在摘要标签页上，查看以下部分中的信息：
- 检测到的内容，尤其是以下字段：
  - 程序二进制文件：有关调用脚本的解释器的详细信息。
  - 脚本：磁盘上的脚本名称的绝对路径；此属性仅会针对写入磁盘的脚本显示，不会针对字面量脚本执行显示，例如 bash -c。
  - 参数：调用脚本时提供的参数。
- 受影响的资源，尤其是以下字段：
  - 资源全名：集群的完整资源名称，其中包括项目编号、位置和集群名称。
- 相关链接，尤其是以下字段：
  - VirusTotal 指示器：指向 VirusTotal 分析页面的链接。
在发现结果的详情视图中，点击 JSON 标签页。
在 JSON 中，记下以下字段。
- finding：
  - processes：
  - script：
    - contents：已执行脚本的内容，由于性能原因，内容可能会被截断；这有助于进行调查
    - sha256：script.contents 的 SHA-256 哈希
- resource：
  - project_display_name：包含资产的项目的名称。
- sourceProperties：
  - Pod_Namespace：Pod 的 Kubernetes 命名空间的名称。
  - Pod_Name：GKE Pod 的名称。
  - Container_Name：受影响的容器的名称。
  - Container_Image_Uri：要执行的容器映像的名称。
  - VM_Instance_Name：在其中执行 Pod 的 GKE 节点的名称。
找出此容器在相似时间发生的其他问题。例如，如果脚本删除了二进制文件，请检查是否有与该二进制文件相关的发现。

第 2 步：查看集群和节点

在 Google Cloud 控制台中，转到 Kubernetes 集群页面。

转到 KUBERNETES 集群
如有必要，在 Google Cloud 控制台的工具栏中选择 resource.project_display_name 中列出的项目。
选择发现结果详情摘要标签页中资源全名行上列出的集群。请记下有关集群及其所有者的所有元数据。
点击节点标签页。选择 VM_Instance_Name 中列出的节点。
点击详细信息标签页，并记下 container.googleapis.com/instance_id 注解。

第 3 步：审核 Pod

在 Google Cloud 控制台中，转到 Kubernetes 工作负载页面。

转到“Kubernetes 工作负载”
如有必要，在 Google Cloud 控制台的工具栏中选择 resource.project_display_name 中列出的项目。
如有必要，对 resource.name 中列出的集群和 Pod_Namespace 中列出的 Pod 命名空间进行过滤。
选择 Pod_Name 中列出的 Pod。请记下有关 Pod 及其所有者的所有元数据。

第 4 步：检查日志

在 Google Cloud 控制台中，打开日志浏览器。

打开日志浏览器
如有必要，在 Google Cloud 控制台工具栏中选择 resource.project_display_name 中列出的项目。
将选择时间范围设置为感兴趣的时间段。
在加载的页面上，执行以下操作：
1. 使用以下过滤条件查找 Pod_Name 的 Pod 日志：
  - resource.type="k8s_container"
  - resource.labels.project_id="resource.project_display_name"
  - resource.labels.location="location"
  - resource.labels.cluster_name="cluster_name"
  - resource.labels.namespace_name="Pod_Namespace"
  - resource.labels.pod_name="Pod_Name"
2. 使用以下过滤条件查找集群审核日志：
  - logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
  - resource.type="k8s_cluster"
  - resource.labels.project_id="resource.project_display_name"
  - resource.labels.location="location"
  - resource.labels.cluster_name="cluster_name"
  - Pod_Name
3. 使用以下过滤条件查找 GKE 节点控制台日志：
  - resource.type="gce_instance"
  - resource.labels.instance_id="instance_id"

第 5 步：检查正在运行的容器

如果容器仍在运行，则或许可以直接检查容器环境。

在 Google Cloud 控制台中，转到 Kubernetes 集群页面。

转到 KUBERNETES 集群
点击 resource.labels.cluster_name 中显示的集群的名称。
在集群页面上，点击连接，然后点击在 Cloud Shell 中运行。

Cloud Shell 将在终端中为集群启动和添加命令。
按 Enter 键，如果出现为 Cloud Shell 提供授权对话框，请点击授权。
通过运行以下命令连接到容器环境：
```
  kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
```
此命令要求容器在 /bin/sh 处安装 shell。

第 6 步：研究攻击和响应方法

查看此发现结果类型的 MITRE ATT&CK 框架条目：Command and Scripting Interpreter、Ingress Tool Transfer。
点击 VirusTotal 指示器中的链接，在 VirusTotal 上查看被标记为恶意的二进制文件的 SHA-256 哈希值。VirusTotal 是一项 Alphabet 自有服务，提供了有关潜在恶意文件、网址、网域和 IP 地址的上下文。
如需制定响应方案，请将您的调查结果与 MITRE 研究和 VirusTotal 分析相结合。

第 7 步：实现响应

以下响应方案可能适合此发现结果，但也可能会影响运营。请仔细评估您在研究中收集的信息，以确定解析发现结果的最佳方法。

如果脚本对容器进行了预期更改，请重新构建容器映像，以免需要进行任何更改。这样，容器就可以是不可变的。
否则，请与容器遭入侵的项目的所有者联系。
停止或删除遭入侵的容器，并将其替换为新容器。

`Malicious URL Observed`

Container Threat Detection 在可执行进程的参数列表中观察到恶意网址。攻击者可以通过恶意网址加载恶意软件或恶意库。

如需对此发现结果采取措施，请执行以下步骤。

第 1 步：查看发现结果详情

按照查看发现结果中所述，打开 Malicious URL Observed 发现结果。系统会打开发现结果详情面板，以显示摘要标签页。
在摘要标签页上，查看以下部分中的信息：
- 检测到的内容，尤其是以下字段：
  - URI：观察到的恶意 URI。
  - 添加的二进制文件：接收包含恶意网址的参数的进程二进制文件的完整路径。
  - 参数：调用进程二进制文件时提供的参数。
  - 环境变量：调用进程二进制文件时有效的环境变量。
  - 容器：容器的名称。
  - Kubernetes Pod：Pod 名称和命名空间。
- 受影响的资源，尤其是以下字段：
  - 资源显示名称：受影响资源的名称。
  - 资源全名：集群的完整资源名称。完整资源名称包含以下信息：
    - 包含集群的项目：projects/PROJECT_ID
    - 集群所在的位置：zone/ZONE 或 locations/LOCATION
    - 集群的名称：projects/CLUSTER_NAME
- 相关链接，尤其是以下字段：
  - VirusTotal 指示器：指向 VirusTotal 分析页面的链接。
在 JSON 标签页上的 sourceProperties 特性中，记下 VM_Instance_Name 属性的值。

第 2 步：查看集群和节点

在 Google Cloud 控制台中，转到 Kubernetes 集群页面。

转到 KUBERNETES 集群
如有必要，在 Google Cloud 控制台工具栏上，选择资源全名 (resource.name) 中显示的项目。项目名称显示在完整资源名称中的 /projects/ 之后。
点击您在发现结果摘要的资源显示名称 (resource.display_name) 中记下的集群名称。集群页面随即会打开。
在“集群详情”页面的“元数据”部分中，记下可能有助于解决威胁的任何用户定义信息，例如标识集群所有者的信息。
点击“节点”标签页。
从列出的节点中，选择与您之前在发现结果 JSON 中记下的 VM_Instance_Name 的值匹配的节点。
在节点详情页面的详情标签页上的注解部分中，记下 container.googleapis.com/instance_id 注解的值。

第 3 步：审核 Pod

在 Google Cloud 控制台中，转到 Kubernetes 工作负载页面。

转到“Kubernetes 工作负载”
如有必要，在 Google Cloud 控制台工具栏上，选择您在发现结果摘要的集群的资源全名 (resource.name) 中记下的项目。
点击显示系统工作负载。
根据您在发现结果摘要的资源全名 (resource.name) 中记下的集群名称以及（如有必要）您记下的 pod 命名空间 (kubernetes.pods.ns) 过滤工作负载列表。
点击与您之前在发现结果 JSON 中记下的 VM_Instance_Name 属性的值匹配的工作负载名称。Pod 详情页面随即会打开。
在 Pod 详情页面上，记下可能有助于您解决威胁的有关 Pod 的任何信息。

第 4 步：检查日志

在 Google Cloud 控制台中，打开日志浏览器。

打开日志浏览器
如有必要，在 Google Cloud 控制台工具栏上，选择资源全名 (resource.name) 中显示的项目。
将选择时间范围设置为感兴趣的时间段。
在加载的页面上，执行以下操作：
1. 使用以下过滤条件查找 pod kubernetes.pods.name 的 Pod 日志：
  - resource.type="k8s_container"
  - resource.labels.project_id="PROJECT_ID"
  - resource.labels.location="LOCATION"
  - resource.labels.cluster_name="CLUSTER_NAME"
  - resource.labels.namespace_name="NAMESPACE_NAME"
  - resource.labels.pod_name="POD_NAME"
2. 使用以下过滤条件查找集群审核日志：
  - logName="projects/PROJECT_NAME/logs/cloudaudit.googleapis.com%2Factivity"
  - resource.type="k8s_cluster"
  - resource.labels.project_id="PROJECT_ID"
  - resource.labels.location="LOCATION_OR_ZONE"
  - resource.labels.cluster_name="CLUSTER_NAME/var>"
  - POD_NAME
3. 使用以下过滤条件查找 GKE 节点控制台日志：
  - resource.type="gce_instance"
  - resource.labels.instance_id="INSTANCE_ID"

第 5 步：检查正在运行的容器

如果容器仍在运行，则或许可以直接检查容器环境。

在 Google Cloud 控制台中，转到 Kubernetes 集群页面。

转到 KUBERNETES 集群
点击 resource.labels.cluster_name 中显示的集群的名称。
在集群页面上，点击连接，然后点击在 Cloud Shell 中运行。

Cloud Shell 将在终端中为集群启动和添加命令。
按 Enter 键，如果出现为 Cloud Shell 提供授权对话框，请点击授权。
通过运行以下命令连接到容器环境：
```
  kubectl exec --namespace=POD_NAMESPACE -ti POD_NAME -c CONTAINER_NAME -- /bin/sh
```
将 CONTAINER_NAME 替换为您之前在发现结果摘要中记下的容器的名称。

此命令要求容器在 /bin/sh 处安装 shell。

第 6 步：研究攻击和响应方法

查看安全浏览网站状态，详细了解网址被归类为恶意网址的原因。
查看以下发现结果类型的 MITRE ATT&CK 框架条目：Ingress Tools Transfer。
点击 VirusTotal 指示器中的链接，在 VirusTotal 上查看被标记为恶意的二进制文件的 SHA-256 哈希值。VirusTotal 是一项 Alphabet 自有服务，提供了有关潜在恶意文件、网址、网域和 IP 地址的上下文。
如需制定响应方案，请将您的调查结果与 MITRE 研究和 VirusTotal 分析相结合。

第 7 步：实现响应

以下响应方案可能适合此发现结果，但也可能会影响运营。请仔细评估您在研究中收集的信息，以确定解析发现结果的最佳方法。

与容器遭入侵的项目的所有者联系。
停止或删除遭入侵的容器，并将其替换为新容器。

`Reverse Shell`

通过流式传输重定向到远程连接的套接字的过程。如果大量生成网络连接的 shell，则攻击者可能会在有限的初始入侵后执行任意操作。如需响应此发现结果，请执行以下操作：

第 1 步：查看发现结果详情

按照查看发现结果中所述，打开 Reverse Shell 发现结果。系统会打开发现结果详情面板，以显示摘要标签页。
在摘要标签页上，查看以下部分中的信息：
- 检测到的内容，尤其是以下字段：
  - 程序二进制文件：在流重定向到远程套接字时启动的进程的绝对路径。
  - 参数：调用进程二进制文件时提供的参数。
- 受影响的资源，尤其是以下字段：
  - 资源全名：集群的完整资源名称。
  - 项目全名：受影响的 Google Cloud 项目。
- 相关链接，尤其是以下字段：
  - VirusTotal 指示器：指向 VirusTotal 分析页面的链接。
在发现结果的详情视图中，点击 JSON 标签页。
在 JSON 中，记下以下字段。
- resource：
  - project_display_name：包含资产的项目的名称。
- sourceProperties：
  - Pod_Namespace：Pod 的 Kubernetes 命名空间的名称。
  - Pod_Name：GKE Pod 的名称。
  - Container_Name：受影响的容器的名称。
  - VM_Instance_Name：在其中执行 Pod 的 GKE 节点的名称。
  - Reverse_Shell_Stdin_Redirection_Dst_Ip：连接的远程 IP 地址
  - Reverse_Shell_Stdin_Redirection_Dst_Port：远程端口
  - Reverse_Shell_Stdin_Redirection_Src_Ip：连接的本地 IP 地址
  - Reverse_Shell_Stdin_Redirection_Src_Port：本地端口
  - Container_Image_Uri：要执行的容器映像的名称。

第 2 步：查看集群和节点

在 Google Cloud 控制台中，转到 Kubernetes 集群页面。

转到 KUBERNETES 集群
如有必要，在 Google Cloud 控制台工具栏中选择 resource.project_display_name 中列出的项目。
选择 resource.name 中列出的集群。请记下有关集群及其所有者的所有元数据。
点击节点标签页。选择 VM_Instance_Name 中列出的节点。
点击详细信息标签页，并记下 container.googleapis.com/instance_id 注解。

第 3 步：审核 Pod

在 Google Cloud 控制台中，转到 Kubernetes 工作负载页面。

转到“Kubernetes 工作负载”
如有必要，在 Google Cloud 控制台工具栏中选择 resource.project_display_name 中列出的项目。
如有必要，对 resource.name 中列出的集群和 Pod_Namespace 中列出的 Pod 命名空间进行过滤。
选择 Pod_Name 中列出的 Pod。请记下有关 Pod 及其所有者的所有元数据。

第 4 步：检查日志

在 Google Cloud 控制台中，打开日志浏览器。

打开日志浏览器
如有必要，在 Google Cloud 控制台工具栏中选择 resource.project_display_name 中列出的项目。
将选择时间范围设置为感兴趣的时间段。
在加载的页面上，执行以下操作：
1. 使用以下过滤条件查找 Pod_Name 的 Pod 日志：
  - resource.type="k8s_container"
  - resource.labels.project_id="resource.project_display_name"
  - resource.labels.location="location"
  - resource.labels.cluster_name="cluster_name"
  - resource.labels.namespace_name="Pod_Namespace"
  - resource.labels.pod_name="Pod_Name"
2. 使用以下过滤条件查找集群审核日志：
  - logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
  - resource.type="k8s_cluster"
  - resource.labels.project_id="resource.project_display_name"
  - resource.labels.location="location"
  - resource.labels.cluster_name="cluster_name"
  - Pod_Name
3. 使用以下过滤条件查找 GKE 节点控制台日志：
  - resource.type="gce_instance"
  - resource.labels.instance_id="instance_id"

第 5 步：检查正在运行的容器

如果容器仍在运行，则或许可以直接检查容器环境。

转到 Google Cloud 控制台。

打开 Google Cloud 控制台
如有必要，在 Google Cloud 控制台工具栏中选择 resource.project_display_name 中列出的项目。
点击激活 Cloud Shell。

通过运行以下命令获取集群的 GKE 凭据。

对于可用区级集群：

  gcloud container clusters get-credentials cluster_name --zone location --project resource.project_display_name

对于地区级集群：

  gcloud container clusters get-credentials cluster_name --region location --project resource.project_display_name

通过运行以下命令，在容器环境中启动 shell：
```
  kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
```
此命令要求容器在 /bin/sh 处安装 shell。

如需查看在容器中运行的所有进程，请在容器 shell 中运行以下命令：
```
  ps axjf
```
此命令要求容器安装 /bin/ps。

第 6 步：研究攻击和响应方法

查看此发现结果类型的 MITRE ATT&CK 框架条目：Command and Scripting Interpreter、Ingress Tool Transfer。
点击 VirusTotal 指示器中的链接，在 VirusTotal 上查看被标记为恶意的二进制文件的 SHA-256 哈希值。VirusTotal 是一项 Alphabet 自有服务，提供了有关潜在恶意文件、网址、网域和 IP 地址的上下文。
如需制定响应方案，请将您的调查结果与 MITRE 研究和 VirusTotal 分析相结合。

第 7 步：实现响应

以下响应方案可能适合此发现结果，但也可能会影响运营。请仔细评估您在研究中收集的信息，以确定解析发现结果的最佳方法。

与容器遭入侵的项目的所有者联系。
停止或删除遭入侵的容器，并将其替换为新容器。

`Unexpected Child Shell`

Container Threat Detection 观察到一个意外生成子 Shell 进程的进程。此事件可能表示攻击者正在尝试滥用 Shell 命令和脚本。

如需对此发现结果采取措施，请执行以下步骤。

第 1 步：查看发现结果详情

按照查看发现结果中所述，打开 Unexpected Child Shell 发现结果。系统会打开发现结果详情面板，以显示摘要标签页。
在摘要标签页上，查看以下部分中的信息：
- 检测到的内容，尤其是以下字段：
  - 父级进程：意外创建子级 Shell 进程的进程。
  - 子进程：子 Shell 进程。
  - 参数：提供给子 Shell 进程二进制文件的参数。
  - 环境变量：子 Shell 进程二进制文件的环境变量。
  - 容器：容器的名称。
  - 容器 URI：容器的映像 URI。
  - Kubernetes Pod：Pod 名称和命名空间。
- 受影响的资源，尤其是以下字段：
  - 资源显示名称：受影响资源的名称。
  - 资源全名：集群的完整资源名称。完整资源名称包含以下信息：
    - 包含集群的项目：projects/PROJECT_ID
    - 集群所在的位置：zone/ZONE 或 locations/LOCATION
    - 集群的名称：projects/CLUSTER_NAME
- 相关链接，尤其是以下字段：
  - VirusTotal 指示器：指向 VirusTotal 分析页面的链接。
点击 JSON 标签页并注意以下字段：

+processes：包含与发现结果相关的所有进程的数组。此数组包括子 Shell 进程和父进程。+resource：+project_display_name：包含资产的项目的名称。+sourceProperties：+VM_Instance_Name：在其中执行 Pod 的 GKE 节点的名称。

第 2 步：查看集群和节点

在 Google Cloud 控制台中，转到 Kubernetes 集群页面。

转到 KUBERNETES 集群
如有必要，在 Google Cloud 控制台工具栏中选择 resource.project_display_name 中列出的项目。
选择 resource.name 中列出的集群。请记下有关集群及其所有者的所有元数据。
点击节点标签页。选择 VM_Instance_Name 中列出的节点。
点击详细信息标签页，并记下 container.googleapis.com/instance_id 注解。

第 3 步：审核 Pod

在 Google Cloud 控制台中，转到 Kubernetes 工作负载页面。

转到“Kubernetes 工作负载”
如有必要，在 Google Cloud 控制台工具栏上，选择您在发现结果摘要的集群的资源全名 (resource.name) 中记下的项目。
点击显示系统工作负载。
根据您在发现结果摘要的资源全名 (resource.name) 中记下的集群名称以及（如有必要）您记下的 pod 命名空间 (kubernetes.pods.ns) 过滤工作负载列表。
点击与您之前在发现结果 JSON 中记下的 VM_Instance_Name 属性的值匹配的工作负载名称。Pod 详情页面随即会打开。
在 Pod 详情页面上，记下可能有助于您解决威胁的有关 Pod 的任何信息。

第 4 步：检查日志

在 Google Cloud 控制台中，打开日志浏览器。

打开日志浏览器
在 Google Cloud 控制台工具栏中，选择 resource.project_display_name 中列出的项目。
将选择时间范围设置为感兴趣的时间段。
在加载的页面上，执行以下操作：
1. 使用以下过滤条件查找 Pod_Name 的 Pod 日志：
  - resource.type="k8s_container"
  - resource.labels.project_id="resource.project_display_name"
  - resource.labels.location="location"
  - resource.labels.cluster_name="cluster_name"
  - resource.labels.namespace_name="Pod_Namespace"
  - resource.labels.pod_name="Pod_Name"
2. 使用以下过滤条件查找集群审核日志：
  - logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
  - resource.type="k8s_cluster"
  - resource.labels.project_id="resource.project_display_name"
  - resource.labels.location="location"
  - resource.labels.cluster_name="cluster_name"
  - Pod_Name
3. 使用以下过滤条件查找 GKE 节点控制台日志：
  - resource.type="gce_instance"
  - resource.labels.instance_id="instance_id"

第 5 步：检查正在运行的容器

如果容器仍在运行，则或许可以直接检查容器环境。

转到 Google Cloud 控制台。

打开 Google Cloud 控制台
在 Google Cloud 控制台工具栏中，选择 resource.project_display_name 中列出的项目。
点击激活 Cloud Shell。

通过运行以下命令获取集群的 GKE 凭据。

对于可用区级集群，请运行以下命令：

  gcloud container clusters get-credentials cluster_name --zone location --project resource.project_display_name

对于区域级集群，请运行以下命令：

  gcloud container clusters get-credentials cluster_name --region location --project resource.project_display_name

如需在容器环境中启动 Shell，请运行以下命令：
```
  kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
```
此命令要求容器在 /bin/sh 处安装 shell。

如需查看在容器中运行的所有进程，请在容器 shell 中运行以下命令：
```
  ps axjf
```
此命令要求容器安装 /bin/ps。

第 6 步：研究攻击和响应方法

查看此发现结果类型的 MITRE ATT&CK 框架条目：Command and Scripting Interpreter: Unix Shell。
点击 VirusTotal 指示器中的链接，在 VirusTotal 上查看被标记为恶意的二进制文件的 SHA-256 哈希值。VirusTotal 是一项 Alphabet 自有服务，提供了有关潜在恶意文件、网址、网域和 IP 地址的上下文。
如需制定响应方案，请将您的调查结果与 MITRE 研究和 VirusTotal 分析相结合。

第 7 步：实现响应

以下响应方案可能适合此发现结果，但也可能会影响运营。请仔细评估您在研究中收集的信息，以确定解析发现结果的最佳方法。

与容器遭入侵的项目的所有者联系。
停止或删除遭入侵的容器，并将其替换为新容器。

VM Threat Detection 响应

如需详细了解 VM Threat Detection，请参阅 VM Threat Detection 概览。

`Defense Evasion: Rootkit`

VM Threat Detection 在 Compute Engine 虚拟机实例中检测到与已知内核模式 rootkit 匹配的信号组合。

Defense Evasion: Rootkit 发现结果类别是以下发现结果类别的超集。因此，本部分也适用于这些发现结果类别。

Defense Evasion: Unexpected ftrace handler（预览版）
Defense Evasion: Unexpected interrupt handler（预览版）
Defense Evasion: Unexpected kernel code modification（预览版）
Defense Evasion: Unexpected kernel modules（预览版）
Defense Evasion: Unexpected kernel read-only data modification（预览版）
Defense Evasion: Unexpected kprobe handler（预览版）
Defense Evasion: Unexpected processes in runqueue（预览版）
Defense Evasion: Unexpected system call handler（预览版）

如需响应这些发现结果，请执行以下操作。

第 1 步：查看发现结果详情

按照查看发现结果中所述，打开相应发现结果。系统会打开发现结果详情面板，以显示摘要标签页。
在摘要标签页上，查看以下部分中的信息：
- 检测到的内容，尤其是以下字段：
  - 内核 rootkit 名称：检测到的 rootkit 的家族名称，例如 Diamorphine。
  - 意外的内核代码页面：内核代码页面是否位于不应位于其中的内核或模块代码区域。
  - 意外的系统调用处理程序：系统调用处理程序是否位于不应位于的内核或模块代码区域。
- 受影响的资源，尤其是以下字段：
  - 资源全名：受影响的虚拟机实例的完整资源名称，其中包括该实例所在的项目的 ID。
如需查看此发现结果的完整 JSON，请在发现结果的详情视图中点击 JSON 标签页。

第 2 步：检查日志

在 Google Cloud 控制台中，打开日志浏览器。

前往 Logs Explorer
在 Google Cloud 控制台工具栏中，选择包含发现结果详情摘要标签页上资源全名行中指定的虚拟机实例的项目。
查看日志，了解受影响虚拟机实例是否存在入侵迹象。例如，检查是否存在可疑或未知的活动以及凭据被盗用的迹象。

第 3 步：查看权限和设置

在发现结果详情摘要标签页的资源全名字段中，点击相应链接。
查看虚拟机实例的详细信息，包括网络和访问设置。

第 4 步：检查受影响的虚拟机

按照检查虚拟机是否存在内核内存篡改迹象中的说明操作。

第 5 步：研究攻击和响应方法

查看防御规避的 MITRE ATT&CK 框架条目。
如需制定响应方案，请将您的调查结果与 MITRE 研究相结合。

第 6 步：实现响应

以下响应方案可能适合此发现结果，但也可能会影响运营。请仔细评估您在研究中收集的信息，以确定解析发现结果的最佳方法。

联系该虚拟机的所有者。
如有必要，请停止已被破解的实例并用新实例取代。
如需进行法医分析，请考虑备份虚拟机和永久性磁盘。如需了解详情，请参阅 Compute Engine 文档中的数据保护选项。
删除虚拟机实例。
如需进一步调查，不妨考虑使用 Mandiant 等突发事件响应服务。

`Execution: Cryptocurrency Mining Hash Match`

VM Threat Detection 通过将正在运行的程序的内存哈希与已知加密货币挖矿软件的内存哈希匹配，检测到加密货币挖矿活动。

如需响应这些发现结果，请执行以下操作：

第 1 步：查看发现结果详情

按照查看发现结果中所述，打开 Execution: Cryptocurrency Mining Hash Match 发现结果。系统会打开发现结果详情面板，以显示摘要标签页。
在摘要标签页上，查看以下部分中的信息：
- 检测到的内容，尤其是以下字段：
  - 二进制文件系列：检测到的加密货币应用。
  - 程序二进制文件：进程的绝对路径。
  - 参数：调用进程二进制文件时提供的参数。
  - 进程名称：在与检测到的签名匹配相关联的虚拟机实例中运行的进程的名称。
  VM Threat Detection 可以识别主要 Linux 发行版中的内核版本。如果它可以识别受影响的虚拟机的内核版本，则可以确定应用的进程详细信息，并填充发现结果的 processes 字段。如果 VM Threat Detection 无法识别内核（例如，内核是自定义构建的），则系统不会填充发现结果的 processes 字段。
- 受影响的资源，尤其是以下字段：
  - 资源全名：受影响的虚拟机实例的完整资源名称，其中包括该实例所在的项目的 ID。
如需查看此发现结果的完整 JSON，请在发现结果的详情视图中点击 JSON 标签页。
- indicator
  - signatures：
    - memory_hash_signature：与内存页面哈希对应的签名。
    - detections
      - binary：加密货币应用的二进制文件的名称，例如 linux--x86-64_ethminer_0.19.0_alpha.0_cuda10.0。
      - percent_pages_matched：内存中与页面哈希数据库中已知加密货币应用的页面匹配的页面百分比。

第 2 步：检查日志

在 Google Cloud 控制台中，打开日志浏览器。

打开日志浏览器
在 Google Cloud 控制台的工具栏中，选择包含发现结果详情摘要标签页上资源全名行中指定的虚拟机实例的项目。
查看日志，了解受影响虚拟机实例是否存在入侵迹象。例如，检查是否存在可疑或未知的活动以及凭据被盗用的迹象。

第 3 步：查看权限和设置

在发现结果详情摘要标签页的资源全名字段中，点击相应链接。
查看虚拟机实例的详细信息，包括网络和访问设置。

第 4 步：研究攻击和响应方法

查看执行的 MITRE ATT&CK 框架条目。
如需制定响应方案，请将您的调查结果与 MITRE 研究相结合。

第 5 步：实现响应

以下响应方案可能适合此发现结果，但也可能会影响运营。请仔细评估您在研究中收集的信息，以确定解析发现结果的最佳方法。

为了帮助您检测和移除，请使用端点检测和响应解决方案。

联系该虚拟机的所有者。
确认该应用是否为挖矿应用：
- 如果提供了检测到的应用的进程名称和二进制文件路径，请在调查中考虑发现结果详情摘要标签页上程序二进制文件、参数和进程名称行中的值。
- 如果未提供进程详细信息，请检查内存哈希签名中的二进制文件名称是否可以提供线索。考虑使用名为 linux-x86-64_xmrig_2.14.1 的二进制文件。您可以使用 grep 命令搜索存储空间中的重要文件。在搜索模式中使用二进制名称的有意义的部分，在本例中为 xmrig。检查搜索结果。
- 检查正在运行的进程，尤其是 CPU 使用率较高的进程，看看是否存在任何无法识别的进程。确定关联的应用是否为挖矿应用。
- 在存储空间的文件中搜索挖矿应用使用的常见字符串，例如 btc.com、ethminer、xmrig、cpuminer 和 randomx。如需查看您可以搜索的字符串的更多示例，请参阅软件名称和 YARA 规则以及列出的每个软件的相关文档。
如果您确定该应用是挖矿应用，并且其进程仍在运行，请终止该进程。在虚拟机的存储空间中找到应用的可执行二进制文件，并将其删除。
如有必要，请停止已被破解的实例并用新实例取代。

`Execution: Cryptocurrency Mining YARA Rule`

VM Threat Detection 通过匹配内存模式（例如，已知加密货币挖矿软件使用的工作证明常量）检测到加密货币挖矿活动。

如需响应这些发现结果，请执行以下操作：

第 1 步：查看发现结果详情

按照查看发现结果中所述，打开 Execution: Cryptocurrency Mining YARA Rule 发现结果。系统会打开发现结果详情面板，以显示摘要标签页。
在摘要标签页上，查看以下部分中的信息：
- 检测到的内容，尤其是以下字段：
  - YARA 规则名称：针对 YARA 检测器触发的规则。
  - 程序二进制文件：进程的绝对路径。
  - 参数：调用进程二进制文件时提供的参数。
  - 进程名称：在与检测到的签名匹配相关联的虚拟机实例中运行的进程的名称。
  VM Threat Detection 可以识别主要 Linux 发行版中的内核版本。如果它可以识别受影响的虚拟机的内核版本，则可以确定应用的进程详细信息，并填充发现结果的 processes 字段。如果 VM Threat Detection 无法识别内核（例如，内核是自定义构建的），则系统不会填充发现结果的 processes 字段。
- 受影响的资源，尤其是以下字段：
  - 资源全名：受影响的虚拟机实例的完整资源名称，其中包括该实例所在的项目的 ID。
- 相关链接，尤其是以下字段：
  - Cloud Logging URI：指向 Logging 条目的链接。
  - MITRE ATT&CK 方法：指向 MITRE ATT&CK 文档的链接。
  - 相关发现结果：指向任何相关发现结果的链接。
  - VirusTotal 指示器：指向 VirusTotal 分析页面的链接。
  - 在 Google Security Operations 中调查：指向 Google SecOps 的链接。
如需查看此发现结果的完整 JSON，请在发现结果的详情视图中点击 JSON 标签页。

第 2 步：检查日志

在 Google Cloud 控制台中，打开日志浏览器。

打开日志浏览器
在 Google Cloud 控制台的工具栏中，选择包含发现结果详情摘要标签页上资源全名行中指定的虚拟机实例的项目。
查看日志，了解受影响虚拟机实例是否存在入侵迹象。例如，检查是否存在可疑或未知的活动以及凭据被盗用的迹象。

第 3 步：查看权限和设置

在发现结果详情摘要标签页的资源全名字段中，点击相应链接。
查看虚拟机实例的详细信息，包括网络和访问设置。

第 4 步：研究攻击和响应方法

查看执行的 MITRE ATT&CK 框架条目。
如需制定响应方案，请将您的调查结果与 MITRE 研究相结合。

第 5 步：实现响应

以下响应方案可能适合此发现结果，但也可能会影响运营。请仔细评估您在研究中收集的信息，以确定解析发现结果的最佳方法。

为了帮助您检测和移除，请使用端点检测和响应解决方案。

联系该虚拟机的所有者。
确认该应用是否为挖矿应用：
- 如果提供了检测到的应用的进程名称和二进制文件路径，请在调查中考虑发现结果详情摘要标签页上程序二进制文件、参数和进程名称行中的值。
- 检查正在运行的进程，尤其是 CPU 使用率较高的进程，看看是否存在任何无法识别的进程。确定关联的应用是否为挖矿应用。
- 在存储空间的文件中搜索挖矿应用使用的常见字符串，例如 btc.com、ethminer、xmrig、cpuminer 和 randomx。如需查看您可以搜索的字符串的更多示例，请参阅软件名称和 YARA 规则以及列出的每个软件的相关文档。
如果您确定该应用是挖矿应用，并且其进程仍在运行，请终止该进程。在虚拟机的存储空间中找到应用的可执行二进制文件，并将其删除。
如有必要，请停止已被破解的实例并用新实例取代。

`Execution: cryptocurrency mining combined detection`

VM Threat Detection 在一天内检测到来自单个来源的多个类别的发现结果。单个应用可以同时触发 Execution: Cryptocurrency Mining YARA Rule 和 Execution: Cryptocurrency Mining Hash Match findings。

如需响应组合发现结果，请同时按照针对 Execution: Cryptocurrency Mining YARA Rule 和 Execution: Cryptocurrency Mining Hash Match findings 的响应说明操作。

`Malware: Malicious file on disk (YARA)`

VM Threat Detection 通过扫描虚拟机的永久性磁盘以查找已知恶意软件签名，检测到一个潜在恶意文件。

如需响应这些发现结果，请执行以下操作：

第 1 步：查看发现结果详情

按照查看发现结果中所述，打开 Malware: Malicious file on disk (YARA) 发现结果。系统会打开发现结果详情面板，以显示摘要标签页。
在摘要标签页上，查看以下部分中的信息：
- 检测到的内容，尤其是以下字段：
  - YARA 规则名称：匹配到的 YARA 规则。
  - 文件：分区 UUID 和检测到的可能恶意文件的相对路径。
- 受影响的资源，尤其是以下字段：
  - 资源全名：受影响的虚拟机实例的完整资源名称，其中包括该实例所在的项目的 ID。
如需查看此发现结果的完整 JSON，请在发现结果的详情视图中点击 JSON 标签页。
在 JSON 中，记下以下字段：
- indicator
  - signatures：
    - yaraRuleSignature：与匹配的 YARA 规则对应的签名。

第 2 步：检查日志

在 Google Cloud 控制台中，打开日志浏览器。

打开日志浏览器
在 Google Cloud 控制台的工具栏中，选择包含发现结果详情摘要标签页上资源全名行中指定的虚拟机实例的项目。
查看日志，了解受影响虚拟机实例是否存在入侵迹象。例如，检查是否存在可疑或未知的活动以及凭据被盗用的迹象。

第 3 步：查看权限和设置

在发现结果详情摘要标签页的资源全名字段中，点击相应链接。
查看虚拟机实例的详细信息，包括网络和访问设置。

第 4 步：研究攻击和响应方法

点击 VirusTotal 指示器中的链接，在 VirusTotal 上查看被标记为恶意的二进制文件的 SHA-256 哈希值。VirusTotal 是一项 Alphabet 自有服务，提供了有关潜在恶意文件、网址、网域和 IP 地址的上下文。

第 5 步：实现响应

以下响应方案可能适合此发现结果，但也可能会影响运营。请仔细评估您在研究中收集的信息，以确定解析发现结果的最佳方法。

联系该虚拟机的所有者。
如有必要，请找到并删除可能存在恶意的文件。如需获取文件的分区 UUID 和相对路径，请参阅发现结果详情的摘要标签页上的文件字段。为了帮助您检测和移除，请使用端点检测和响应解决方案。
如有必要，请停止已被破解的实例并用新实例取代。

注意：使用 Security Command Center Enterprise 层级时，您还可以通过威胁响应手册执行此操作。
如需进行法医分析，请考虑备份虚拟机和永久性磁盘。如需了解详情，请参阅 Compute Engine 文档中的数据保护选项。
如需进一步调查，不妨考虑使用 Mandiant 等突发事件响应服务。

修复相关漏洞

为了帮助防止威胁再次发生，请查看并修复相关的漏洞和错误配置发现结果。

如需查找任何相关发现结果，请按照以下步骤操作：

在 Google Cloud 控制台中，进入 Security Command Center 发现结果页面。

转至“发现结果”
查看威胁发现结果，然后复制可能出现在任何相关漏洞或配置错误发现结果中的特性的值，例如主账号电子邮件地址或受影响资源的名称。
在发现结果页面上，点击修改查询来打开查询编辑器。
点击添加过滤条件。 选择过滤条件菜单随即会打开。
从菜单左侧的过滤条件类别列表中，选择包含您在威胁发现结果中记下的特性的类别。

例如，如果您记下了受影响资源的完整名称，请选择资源。资源类别的特性类型会显示在右侧的列中，包括完整名称特性。
从显示的特性中，选择您在威胁发现结果中记下的特性的类型。属性值的搜索面板会在右侧打开，并显示所选属性类型所有找到的值。
在过滤条件字段中，粘贴您从威胁发现结果复制的属性值。显示的值列表会更新，仅显示与粘贴的值匹配的值。
从显示的值列表中选择一个或多个值，然后点击应用。发现结果的查询结果面板会更新，仅显示匹配的发现结果。
如果结果中有许多发现结果，请通过从快速过滤条件面板中选择其他过滤条件来过滤发现结果。

例如，如需仅显示包含所选特性值的 Vulnerability 和 Misconfiguration 类发现结果，请向下滚动到快速过滤条件面板的发现结果类部分，然后选择漏洞和配置错误。

除了 Google 提供的入侵线索外，作为 Palo Alto Networks 客户的用户还可以将 Palo Alto Networks 的 AutoFocus Threat Intelligence 与 Event Threat Detection 集成。AutoFocus 是一项威胁情报服务，可提供有关网络威胁的信息。如需了解详情，请访问 Google Cloud 控制台中的 AutoFocus 页面。

修复威胁

修复 Event Threat Detection 和 Container Threat Detection 发现结果并不像修复 Security Command Center 发现的错误配置和漏洞一样简单。

错误配置和违规情况会识别资源中可能被利用的漏洞。通常，配置错误有已知且容易实现的修复方案，例如启用防火墙或轮替加密密钥。

威胁与漏洞有所不同，威胁是动态的，并指示针对一个或多个资源的可能发生的活跃漏洞。修复建议可能对保护资源安全不起作用，因为实现漏洞所用的确切方法可能未知。

例如，Added Binary Executed 发现结果指示容器中发布了未获授权的二进制文件。基本的修复建议可能有助于您隔离容器并删除该二进制文件，但可能无法解决允许攻击者执行此二进制文件的根本原因。您需要了解容器映像的损坏程度才能修复漏洞。如需确定文件是通过配置错误端口添加的还是通过其他一些方式添加的，您需要进行全面调查。对您的系统具有专业知识的分析师可能需要查看系统是否存在漏洞。

作恶方会使用不同的技术攻击资源，因此，对特定漏洞应用修复方案可能对攻击的变化不起作用。例如，为了响应 Brute Force: SSH 结果，您可以降低某些用户账号的权限级别来限制对资源的访问权限。但是，安全系数低的密码可能仍会提供攻击路径。

攻击途径范围广使得很难提供适用于所有情况的修复步骤。Security Command Center 在云安全方案中的作用是近乎实时地发现受影响的资源，告诉您面临的威胁，并提供证据和上下文来帮助您进行调查。但您的安全人员必须使用 Security Command Center 发现结果中的敏感信息来确定修复问题并保护资源免受未来攻击的最佳方法。

后续步骤

请参阅 Event Threat Detection 概览，详细了解该服务及其检测的威胁。
请参阅 Container Threat Detection 概览，了解该服务的工作原理。
请参阅 VM Threat Detection 概览，详细了解该服务及其检测的威胁。