调查和应对威胁

本文档提供了一些非正式指导信息，可帮助您调查在您的 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 控制台中查看威胁发现结果，请按照以下步骤操作：

1. 在 Google Cloud 控制台中，前往 Security Command Center 发现结果页面。

   转至“发现结果”

2. 如有必要，请选择您的 Google Cloud 项目、文件夹或组织。

3. 在快速过滤条件部分中，点击相应的过滤条件，以在发现结果的查询结果表中显示所需的发现结果。例如，如果您在来源显示名称子部分中选择 Event Threat Detection 或 Container Threat Detection，则结果中只会显示来自所选服务的发现结果。

   该表会填充所选择来源的发现结果。

4. 如需查看特定发现结果的详细信息，请点击 Category 下的发现结果名称。发现结果详情窗格会展开，以显示发现结果的详情摘要。

5. 要查看发现结果的 JSON 定义，请点击 JSON 标签页。

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

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

• MITRE ATT&CK 框架条目。该框架解释了针对云资源的攻击伎俩，并提供修复指南。

• VirusTotal，一项 Alphabet 自有服务，提供了有关潜在恶意文件、网址、网域和 IP 地址的上下文。VirusTotal 指标字段（如果有）会提供 VirusTotal 链接，以帮助您进一步调查潜在的安全问题。

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

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

停用威胁发现结果

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

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

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

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

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

• 忽略发现的结果
• 更改发现结果的状态

Event Threat Detection 响应

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

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

Active Scan: Log4j Vulnerable to RCE

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

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

1. 按照查看发现结果详情中所述，打开 Active Scan: Log4j Vulnerable to RCE 发现结果。系统会打开发现结果详细信息面板，以显示摘要标签页。

2. 在摘要标签页上，查看以下部分中的信息：

   • 检测到的内容
   • 受影响的资源，尤其是以下字段：
     • 资源全名：易受 Log4j RCE 攻击的 Compute Engine 实例的完整资源名称。
   • 相关链接，尤其是以下字段：
     • Cloud Logging URI：指向 Logging 条目的链接。
     • MITRE ATT&CK 方法：指向 MITRE ATT&CK 文档的链接。
     • 相关发现结果：指向任何相关发现结果的链接。

3. 在发现结果的详情视图中，点击 JSON 标签页。

4. 在 JSON 中，请注意以下字段。

   • properties
     • scannerDomain：扫描工具在 JNDI 查找过程中使用的网域。这会表明哪个扫描工具发现了漏洞。
     • sourceIp：用于进行 DNS 查询的 IP 地址
     • vpcName：在其中执行 DNS 查询的实例上的网络名称。

第 2 步：检查日志

1. 在 Google Cloud 控制台中，点击第 1 步的 Cloud Logging URI 字段中的链接，以前往 Logs Explorer。

2. 在加载的页面上，检查 httpRequest 字段中是否存在 ${jndi:ldap:// 等字符串令牌，这可能表示潜在的漏洞利用尝试。

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

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

1. 查看此发现结果类型的 MITRE ATT&CK 框架条目：利用远程服务。
2. 点击发现结果详情摘要标签页中相关发现结果行上的相关发现结果的链接，以查看相关发现结果。 相关发现结果属于同一实例和网络上的同一发现结果类型。
3. 如需制定响应方案，请将您的调查结果与 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 漏洞。

Brute Force: SSH

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

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

1. 按照查看发现结果中所述，打开 Brute Force: SSH 发现结果。

2. 在发现结果详细信息面板的摘要标签页上，查看以下部分中的信息：

   • 检测到的内容，尤其是以下字段：

     • 调用方 IP：发起攻击的 IP 地址。
     • 用户名：登录的账号。

   • 受影响的资源

   • 相关链接，尤其是以下字段：

     • Cloud Logging URI：指向 Logging 条目的链接。
     • MITRE ATT&CK 方法：指向 MITRE ATT&CK 文档的链接。
     • 相关发现结果：指向任何相关发现结果的链接。

3. 点击 JSON 标签页。

4. 在 JSON 中，请注意以下字段。

   • sourceProperties：
     • evidence：
       • sourceLogId：用于标识日志条目的项目 ID 和时间戳
       • projectId：包含发现结果的项目
     • properties：
       • attempts：
       • Attempts：登录尝试次数
         • username：登录的账号
         • vmName：虚拟机的名称
         • authResult：SSH 身份验证结果

第 2 步：查看权限和设置

1. 在 Google Cloud 控制台中，前往信息中心。

   转到信息中心

2. 选择 projectId 中指定的项目。

3. 导航到资源卡片，然后点击 Compute Engine。

4. 点击与 vmName 中的名称和可用区匹配的虚拟机实例。查看该实例的详细信息，包括网络和访问设置。

5. 在导航窗格中，点击 VPC 网络，然后点击防火墙。 移除或禁用端口 22 上的过于宽松的防火墙规则。

第 3 步：检查日志

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

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

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

第 5 步：实现响应

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

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

Credential Access: CloudDB Failed login from Anonymizing Proxy IP

检测到数据库实例中来自已知匿名化 IP 地址的登录失败事件。 这些匿名化地址是 Tor 节点。这可能表明攻击者正试图未经授权地访问您的实例。

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

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

1. 按照查看发现结果中所述，打开 Credential Access: CloudDB Failed login from Anonymizing Proxy IP 发现结果。

2. 在发现结果详细信息面板的摘要标签页上，查看以下部分中的信息：

   • 检测到的内容，尤其是以下字段：
   • 指示器 IP 地址，即匿名化 IP 地址。
   • 数据库显示名称：受影响的 Cloud SQL PostgreSQL、MySQL 或 AlloyDB 实例中的数据库的名称。
   • 数据库用户名：用户。
   • 项目全名：包含 Cloud SQL 实例的 Google Cloud 项目。

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

1. 查看此发现结果类型的 MITRE ATT&CK 框架条目：凭据访问。
2. 如需确定是否需要执行额外的补救步骤，请将您的调查结果与 MITRE 研究相结合。

第 3 步：实现响应

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

• 查看允许连接到数据库的用户。

  • 对于 PostgreSQL，请参阅创建和管理用户
  • 对于 MySQL，请参阅使用内置身份验证管理用户

• 考虑更改用户的密码。

  • 对于 PostgreSQL，请参阅为默认用户设置密码

  • 对于 MySQL，请参阅为默认用户设置密码

  • 更新连接到 Cloud SQL 实例的客户端的凭证

• 查看对您实例的网络访问权限

  • 对于 PostgreSQL，请参阅为默认用户设置密码
  • 对于 MySQL，请参阅为默认用户设置密码

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

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

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

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

有人手动批准了证书签名请求 (CSR)。攻击者常常通过创建集群身份验证证书来创建对遭入侵集群的永久访问权限。与证书关联的权限因包含的主体而异，但可能具有很高的权限。如需了解详情，请参阅此提醒的日志消息。

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

Credential Access: Secrets Accessed in Kubernetes Namespace

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

Defense Evasion: Breakglass Workload Deployment Created

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

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

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

1. 按照查看发现结果中所述，打开 Defense Evasion: Breakglass Workload Deployment Created 发现结果。系统会打开发现结果详细信息面板，其中显示了摘要标签页。

2. 在摘要标签页上，查看以下部分中的信息：

   • 检测到的内容，尤其是以下字段：
     • 主账号电子邮件地址：执行修改操作的账号。
     • 方法名称：所调用的方法。
     • Kubernetes Pod：Pod 名称和命名空间。
   • 受影响的资源，尤其是以下字段：
     • 资源显示名称：部署所属的 GKE 命名空间。
   • 相关链接：
     • Cloud Logging URI：指向 Logging 条目的链接。
     • MITRE ATT&CK 方法：指向 MITRE ATT&CK 文档的链接。
     • 相关发现结果：指向任何相关发现结果的链接。

第 2 步：检查日志

1. 在 Google Cloud 控制台中发现结果详细信息的摘要标签页上，通过点击 Cloud Logging URI 字段中的链接转到 Logs Explorer。
2. 查看 protoPayload.resourceName 字段中的值以识别特定的证书签名请求。

3. 使用以下过滤条件检查主账号执行的其他操作：

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     替换以下内容：

   • CLUSTER_NAME：您在发现结果详情的资源显示名称字段中记下的值。

   • PRINCIPAL_EMAIL：您在发现结果详情的主账号电子邮件地址字段中记下的值。

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

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

Defense Evasion: Breakglass Workload Deployment Updated

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

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

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

1. 按照查看发现结果中所述，打开 Defense Evasion: Breakglass Workload Deployment Updated 发现结果。系统会打开发现结果详细信息面板，其中显示了摘要标签页。

2. 在摘要标签页上，查看以下部分中的信息：

   • 检测到的内容，尤其是以下字段：
     • 主账号电子邮件地址：执行修改操作的账号。
     • 方法名称：所调用的方法。
     • Kubernetes Pod：Pod 名称和命名空间。
   • 受影响的资源，尤其是以下字段：
     • 资源显示名称：更新所属的 GKE 命名空间。
   • 相关链接：
     • Cloud Logging URI：指向 Logging 条目的链接。
     • MITRE ATT&CK 方法：指向 MITRE ATT&CK 文档的链接。
     • 相关发现结果：指向任何相关发现结果的链接。

第 2 步：检查日志

1. 在 Google Cloud 控制台中发现结果详细信息的摘要标签页上，通过点击 Cloud Logging URI 字段中的链接转到 Logs Explorer。
2. 查看 protoPayload.resourceName 字段中的值以识别特定的证书签名请求。

3. 使用以下过滤条件检查主账号执行的其他操作：

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     替换以下内容：

   • CLUSTER_NAME：您在发现结果详情的资源显示名称字段中记下的值。

   • PRINCIPAL_EMAIL：您在发现结果详情的主账号电子邮件地址字段中记下的值。

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

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

Defense Evasion: GCS Bucket IP Filtering Modified

Event Threat Detection 会检查审核日志，以检测 Cloud Storage 存储桶上的 IP 过滤配置是否已更新。

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

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

1. 按照查看发现结果中所述，打开 Defense Evasion: GCS Bucket IP Filtering Modified 发现结果。系统会打开发现结果详细信息面板，以显示摘要标签页。
2. 在摘要标签页上，查看以下部分中的信息：
   • 检测到的内容，尤其是以下字段：
     • 说明：有关检测的信息
     • 主账号主体：已成功执行操作的用户或服务账号
   • 受影响的资源
     • 资源显示名称：已更新配置的存储桶。
   • 相关链接，尤其是以下字段：
     • MITRE ATT&CK 方法：指向 MITRE ATT&CK 文档的链接。
     • Logging URI：用于打开 Logs Explorer 的链接。

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

联系主账号正文字段中的服务账号或用户账号所有者。 确认合法所有者是否执行了此操作。

Defense Evasion: Manually Deleted Certificate Signing Request (CSR)

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

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

Defense Evasion: Modify VPC Service Control

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

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

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

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

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

1. 按照查看发现结果中所述，打开 Defense Evasion: Modify VPC Service Control 发现结果。系统会打开发现结果详细信息面板，其中显示了摘要标签页。

2. 在摘要标签页上，查看以下部分中的信息：

   • 检测到的内容，尤其是以下字段：
     • 主账号电子邮件地址：执行修改操作的账号。
   • 受影响的资源，尤其是以下字段：
     • 资源全名：修改的 VPC Service Controls 边界的名称。
   • 相关链接：
     • Cloud Logging URI：指向 Logging 条目的链接。
     • MITRE ATT&CK 方法：指向 MITRE ATT&CK 文档的链接。
     • 相关发现结果：指向任何相关发现结果的链接。

3. 点击 JSON 标签页。

4. 在 JSON 中，请注意以下字段。

   • sourceProperties
     • properties
       • name：被修改的 VPC Service Controls 边界的名称
       • policyLink：用于控制该边界的访问权限政策的链接
       • delta：对边界做出的减少其保护的更改（REMOVE 或 ADD）
       • restricted_resources：遵循此边界限制的项目。如果您移除某个项目，则所受保护会减少
       • restricted_services：被此边界限制禁止运行的服务。如果您移除某个受限服务，则所受保护会减少
       • allowed_services：根据此边界限制允许运行的服务。如果您添加某个允许的服务，则所受保护会减少
       • access_levels：配置为允许访问边界下资源的访问权限级别。如果您添加更多访问权限级别，则所受保护会减少

第 2 步：检查日志

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

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

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

第 4 步：实现响应

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

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

Defense Evasion: Potential Kubernetes Pod Masquerading

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

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

Defense Evasion: Project HTTP Policy Block Disabled

Event Threat Detection 会检查审核日志，以检测 constraints/storage.secureHttpTransport 政策是否已更新为停用 HTTP 政策块。

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

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

1. 按照查看发现结果中所述，打开 Defense Evasion: Project HTTP Policy Block Disabled 发现结果。系统会打开发现结果详细信息面板，以显示摘要标签页。
2. 在摘要标签页上，查看以下部分中的信息：
   • 检测到的内容，尤其是以下字段：
     • 说明：有关检测的信息
     • 主账号主体：已成功执行操作的用户或服务账号
   • 受影响的资源
     • 资源显示名称：已更新政策的项目/文件夹/组织。
   • 相关链接，尤其是以下字段：
     • MITRE ATT&CK 方法：指向 MITRE ATT&CK 文档的链接。
     • Logging URI：用于打开 Logs Explorer 的链接。

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

联系主账号正文字段中的服务账号或用户账号所有者。 确认合法所有者是否执行了停用 constraints/storage.secureHttpTransport 政策的操作。

Defensive Evasion: Static Pod Created

有人在您的 GKE 集群中创建了静态 Pod。 静态 Pod 直接在节点上运行，并绕过 Kubernetes API 服务器，这使得它们更难以监控和控制。攻击者可以利用此功能来逃避检测或维护持久性。

1. 查看静态 Pod 的清单文件及其用途。验证其合法性和必要性。
2. 评估静态 Pod 的功能是否可以通过 Kubernetes API 服务器管理的常规 Pod 实现。
3. 如果需要静态 Pod，请确保它遵循安全最佳实践并具有最低权限。
4. 监控静态 Pod 的活动及其对集群的影响。

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 步：查看发现结果详情

1. 按照查看发现结果中所述，打开 Discovery: Can get sensitive Kubernetes object check 发现结果。

2. 在发现结果详情的摘要标签页上，记下以下字段的值：

   • 在检测到的内容下：
     • Kubernetes 访问权限审核：根据 SelfSubjectAccessReview k8s 资源请求的访问权限审核信息。
     • 主账号电子邮件地址：发出调用的账号。
   • 在受影响的资源下：
     • 资源显示名称：执行操作的 Kubernetes 集群。
   • 在相关链接下：
     • Cloud Logging URI：指向 Logging 条目的链接。

第 2 步：检查日志

1. 在发现结果详细信息面板的“摘要”标签页上，点击 Cloud Logging URI 链接以打开 Logs Explorer。

2. 在加载的页面上，使用以下过滤条件检查主账号执行的其他操作：

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     替换以下内容：

   • CLUSTER_NAME：您在发现结果详情的资源显示名称字段中记下的值。

   • PRINCIPAL_EMAIL：您在发现结果详情的主账号电子邮件地址字段中记下的值。

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

1. 查看此发现结果类型的 MITRE ATT&CK 框架条目：探索
2. 确认所查询对象的敏感度，并确定日志中是否存在主账号执行的其他恶意活动迹象。

3. 如果您在发现结果详情的主账号电子邮件地址行中记下的账号不是服务账号，请与该账号所有者联系以确认合法所有者是否执行了该操作。

   如果主账号电子邮件地址是服务账号（IAM 或 Kubernetes），请查明访问权限审核的来源以确定其合法性。

4. 如需制定响应方案，请将您的调查结果与 MITRE 研究相结合。

Evasion: Access from Anonymizing Proxy

通过检查源自与 Tor 网络关联的 IP 地址的 Google Cloud 服务修改的 Cloud Audit Logs，检测匿名代理的异常访问。

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

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

1. 按照查看发现结果中所述，打开 Evasion: Access from Anonymizing Proxy 发现结果。系统会打开发现结果详细信息面板，其中显示了摘要标签页。

2. 在发现结果详细信息面板的摘要标签页上，查看以下部分中列出的值：

   • 检测到的内容，尤其是以下字段：
     • 主账号电子邮件地址：做出更改的账号（可能被盗用的账号）。
     • IP：从其中执行更改的代理 IP 地址。
   • 受影响的资源
   • 相关链接，尤其是以下字段：
     • Cloud Logging URI：指向 Logging 条目的链接。
     • MITRE ATT&CK 方法：指向 MITRE ATT&CK 文档的链接。
     • 相关发现结果：指向任何相关发现结果的链接。

3. （可选）点击 JSON 标签页以查看其他发现结果字段。

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

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

Execution: Cryptomining Docker Image

通过添加可进行加密货币挖矿的已知不良 Docker 映像，检测 Cloud Run 服务或作业的创建或修改时间。

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

1. 检查容器映像，确定是否符合预期。
2. 删除遭入侵的容器，并将其替换为新容器。

Execution: GKE launch excessively capable container

有人在具有受提升安全上下文的 GKE 集群中部署了具有以下一个或多个功能的容器：

• CAP_SYS_MODULE
• CAP_SYS_RAWIO
• CAP_SYS_PTRACE
• CAP_SYS_BOOT
• CAP_DAC_READ_SEARCH
• CAP_NET_ADMIN
• CAP_BPF

这些功能之前曾用于从容器中逃逸，因此应谨慎配置。

1. 查看容器的 Pod 定义中的安全上下文。找出对于其功能来说不是严格必要的任何功能。
2. 尽可能移除或减少过多的功能。遵循最小权限原则。

Execution: Kubernetes Pod Created with Potential Reverse Shell Arguments

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

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

Execution: Suspicious Exec or Attach to a System Pod

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

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

查看相关指南以了解如何针对允许此访问的 RBAC 角色和集群角色使用最小权限原则。

Execution: Workload triggered in sensitive namespace

有人在 kube-system 或 kube-public 命名空间中部署了工作负载（例如 Pod 或 Deployment）。这些命名空间对于 GKE 集群操作至关重要，未经授权的工作负载可能会破坏集群的稳定性或安全性。

1. 确定已部署的工作负载及其用途。
2. 如果工作负载未经授权，请将其删除，并调查部署来源。

Exfiltration: BigQuery Data Exfiltration

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

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

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

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

1. 按照查看发现结果中所述，打开 Exfiltration: BigQuery Data Exfiltration 发现结果。

2. 在发现结果详细信息面板的摘要标签页上，查看以下部分中列出的值：

   • 检测到的内容：
     • 严重程度：对于子规则 exfil_to_external_table，严重程度为 HIGH；对于子规则 vpc_perimeter_violation，严重程度为 LOW。
     • 主账号电子邮件地址：用于渗漏数据的账号。
     • 渗漏来源：有关从其中渗漏数据的表的详细信息。
     • 渗漏目标：有关在其中存储渗漏数据的表的详细信息。
   • 受影响的资源：
     • 资源全名：从其中渗漏数据的项目、文件夹或组织的完整资源名称。
   • 相关链接：
     • Cloud Logging URI：指向 Logging 条目的链接。
     • MITRE ATT&CK 方法：指向 MITRE ATT&CK 文档的链接。
     • 相关发现结果：指向任何相关发现结果的链接。

3. 点击来源属性标签页，查看显示的字段，尤其是：

   • detectionCategory：
     • subRuleName：exfil_to_external_table 或 vpc_perimeter_violation。
   • evidence：
     • sourceLogId：
       • projectId：包含来源 BigQuery 数据集的 Google Cloud 项目。
   • properties
     • dataExfiltrationAttempt
       • jobLink：指向渗漏数据的 BigQuery 作业的链接。
       • query：在 BigQuery 数据集上运行的 SQL 查询。

4. 您可以选择点击 JSON 标签页，查看发现结果的完整 JSON 属性列表。

第 2 步：查看权限和设置

1. 在 Google Cloud 控制台中，前往 IAM 页面。

   转到 IAM

2. 如有必要，请选择发现结果 JSON 中 projectId 字段中列出的项目。

3. 在显示的页面上的过滤条件框中，输入主账号电子邮件地址中列出的电子邮件地址，并检查为该账号分配了哪些权限。

第 3 步：检查日志

1. 在发现结果详细信息面板的“摘要”标签页上，点击 Cloud Logging URI 链接以打开 Logs Explorer。

2. 使用以下过滤条件查找与 BigQuery 作业相关的管理员活动日志：

   • protoPayload.methodName="Jobservice.insert"
   • protoPayload.methodName="google.cloud.bigquery.v2.JobService.InsertJob"

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

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

第 5 步：实现响应

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

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

Exfiltration: BigQuery Data Extraction

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

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

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

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

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

1. 按照查看发现结果中所述，打开 Exfiltration: BigQuery Data Extraction 发现结果。系统会打开发现结果详细信息面板，以显示摘要标签页。

2. 在发现结果详细信息面板的摘要标签页上，查看以下部分中列出的值：

   • 检测到的内容：
     • 主账号电子邮件地址：用于渗漏数据的账号。
     • 渗漏来源：有关从其中渗漏数据的表的详细信息。
     • 渗漏目标：有关在其中存储渗漏数据的表的详细信息。
   • 受影响的资源：
     • 资源全名：渗漏其数据的 BigQuery 资源的名称。
     • 项目全名：包含来源 BigQuery 数据集的 Google Cloud 项目。
   • 相关链接：
     • Cloud Logging URI：指向 Logging 条目的链接。
     • MITRE ATT&CK 方法：指向 MITRE ATT&CK 文档的链接。
     • 相关发现结果：指向任何相关发现结果的链接。

3. 在发现结果详细信息面板中，点击 JSON 标签页。

4. 在 JSON 中，请注意以下字段。

   • sourceProperties：
     • evidence：
       • sourceLogId：
       • projectId：包含来源 BigQuery 数据集的 Google Cloud 项目。
     • properties：
       • extractionAttempt：
       • jobLink：指向渗漏数据的 BigQuery 作业的链接

第 2 步：查看权限和设置

1. 在 Google Cloud 控制台中，前往 IAM 页面。

   转到 IAM

2. 如有必要，请选择发现结果 JSON 中 projectId 字段中列出的项目（来自第 1 步）。

3. 在显示的页面上的过滤条件框中，输入主账号电子邮件地址中列出的电子邮件地址（来自第 1 步），并检查为该账号分配了哪些权限。

第 3 步：检查日志

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

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

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

第 5 步：实现响应

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

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

Exfiltration: BigQuery Data to Google Drive

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

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

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

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

1. 按照查看发现结果中所述，打开 Exfiltration: BigQuery Data to Google Drive 发现结果。

2. 在发现结果详细信息面板的摘要标签页上，查看以下部分中的信息：

   • 检测到的内容，其中包括：
     • 主账号电子邮件地址：用于渗漏数据的账号。
     • 渗漏来源：有关从其中渗漏数据的 BigQuery 表的详细信息。
     • 渗漏目标：有关 Google 云端硬盘中的目标位置的详细信息。
   • 受影响的资源，其中包括：
     • 资源全名：渗漏其数据的 BigQuery 资源的名称。
     • 项目全名：包含来源 BigQuery 数据集的 Google Cloud 项目。
   • 相关链接，其中包括：
     • Cloud Logging URI：指向 Logging 条目的链接。
     • MITRE ATT&CK 方法：指向 MITRE ATT&CK 文档的链接。
     • 相关发现结果：指向任何相关发现结果的链接。

3. 如需了解详情，请点击 JSON 标签页。

4. 在 JSON 中，请注意以下字段。

   • sourceProperties：
     • evidence：
       • sourceLogId：
       • projectId：包含来源 BigQuery 数据集的 Google Cloud 项目。
     • properties：
       • extractionAttempt：
       • jobLink：指向渗漏数据的 BigQuery 作业的链接

第 2 步：查看权限和设置

1. 在 Google Cloud 控制台中，前往 IAM 页面。

   转到 IAM

2. 如有必要，请选择发现结果 JSON 中 projectId 字段中列出的项目（来自第 1 步）。

3. 在显示的页面上的过滤条件框中，输入 access.principalEmail 中列出的电子邮件地址（来自第 1 步），并检查为该账号分配了哪些权限。

第 3 步：检查日志

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

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

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

第 5 步：实现响应

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

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

Exfiltration: Cloud SQL Data Exfiltration

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

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

支持所有 Cloud SQL 实例类型。

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

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

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

1. 按照查看发现结果中所述，打开 Exfiltration: Cloud SQL Data Exfiltration 发现结果。系统会打开发现结果详细信息面板，以显示摘要标签页。

2. 在摘要标签页上，查看以下部分中的信息：

   • 检测到的内容，尤其是以下字段：
     • 主账号电子邮件地址：用于渗漏数据的账号。
     • 渗漏来源：有关渗漏其数据的 Cloud SQL 实例的详细信息。
     • 渗漏目标：有关数据导出到的 Cloud Storage 存储桶的详细信息。
   • 受影响的资源，尤其是以下字段：
     • 资源全名：渗漏其数据的 Cloud SQL 资源的名称。
     • 项目全名：包含来源 Cloud SQL 数据的 Google Cloud 项目。
   • 相关链接，其中包括：
     • Cloud Logging URI：指向 Logging 条目的链接。
     • MITRE ATT&CK 方法：指向 MITRE ATT&CK 文档的链接。
     • 相关发现结果：指向任何相关发现结果的链接。

3. 点击 JSON 标签页。

4. 在发现结果的 JSON 中，注意以下字段：

   • sourceProperties：
     • evidence：
     • sourceLogId：
       • projectId：包含来源 Cloud SQL 实例的 Google Cloud 项目。
     • properties
     • bucketAccess：Cloud Storage 存储桶是可公开访问的，还是在组织外部
     • exportScope：导出的数据量，例如整个实例、一个或多个数据库、一个或多个表，或由查询指定的子集

第 2 步：查看权限和设置

1. 在 Google Cloud 控制台中，前往 IAM 页面。

   转到 IAM

2. 如有必要，请选择发现结果 JSON 中 projectId 字段中列出的实例的项目（来自第 1 步）。

3. 在显示的页面上的过滤条件框中，输入发现结果详情摘要标签页中主账号电子邮件地址行上列出的电子邮件地址（来自第 1 步）。检查为该账号分配了哪些权限。

第 3 步：检查日志

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

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

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

第 5 步：实现响应

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

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

Exfiltration: Cloud SQL Over-Privileged Grant

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

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

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

1. 按照查看发现结果中所述，打开 Exfiltration: Cloud SQL Over-Privileged Grant 发现结果。

2. 在发现结果详细信息面板的摘要标签页上，查看以下部分中的信息：

   • 检测到的内容，尤其是以下字段：
     • 数据库显示名称：受影响的 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 文档的链接。
     • 相关发现结果：指向任何相关发现结果的链接。

3. 如需查看发现结果的完整 JSON，请点击 JSON 标签页。

第 2 步：查看数据库权限

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

第 3 步：检查日志

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

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

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

第 5 步：实现响应

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

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

Exfiltration: Cloud SQL Restore Backup to External Organization

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

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

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

1. 按照查看发现结果中所述，打开 Exfiltration: Cloud SQL Restore Backup to External Organization 发现结果。

2. 在发现结果详细信息面板的摘要标签页上，查看以下部分中的信息：

   • 检测到的内容，尤其是以下字段：
     • 主账号电子邮件地址：用于渗漏数据的账号。
     • 渗漏来源：有关通过其创建备份的 Cloud SQL 实例的详细信息。
     • 渗漏目标：有关备份数据恢复到的 Cloud SQL 实例的详细信息。
   • 受影响的资源，尤其是以下字段：
     • 资源全名：已恢复的备份的资源名称。
     • 项目全名：包含通过其创建备份的 Cloud SQL 实例的 Google Cloud 项目。

3. 相关链接，尤其是以下字段：

   • Cloud Logging URI：指向 Logging 条目的链接。
   • MITRE ATT&CK 方法：指向 MITRE ATT&CK 文档的链接。
   • 相关发现结果：指向任何相关发现结果的链接。

4. 点击 JSON 标签页。

5. 在 JSON 中，请注意以下字段。

   • resource：
     • parent_name：从其创建备份的 Cloud SQL 实例的资源名称
   • evidence：
     • sourceLogId：
       • projectId：包含来源 BigQuery 数据集的 Google Cloud 项目。
   • properties：
     • restoreToExternalInstance：
       • backupId：已恢复的备份作业的 ID

第 2 步：查看权限和设置

1. 在 Google Cloud 控制台中，前往 IAM 页面。

   转到 IAM

2. 如有必要，请选择发现结果 JSON 中 projectId 字段中列出的实例的项目（来自第 1 步）。

3. 在显示的页面上的过滤条件框中，输入主账号电子邮件地址中列出的电子邮件地址（来自第 1 步），并检查为该账号分配了哪些权限。

第 3 步：检查日志

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

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

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

第 5 步：实现响应

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

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

Impact: Cryptomining Commands

检测已知加密货币挖矿命令何时作为作业执行时将运行的入口点传递到 Cloud Run 作业。

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

1. 检查作业、命令和容器，确定是否符合预期。
2. 删除遭入侵的作业和容器。

Impact: Deleted Google Cloud Backup and DR Backup

Event Threat Detection 会检查审核日志，以检测存储在备份保险柜中的备份是否已删除。

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

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

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

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

联系主账号主体字段中的服务账号所有者，并确认他们是否执行了相应操作。

Impact: Deleted Google Cloud Backup and DR host

Event Threat Detection 会检查审核日志，以检测是否删除了运行由 Backup and DR Service 保护的应用的主机。主机删除后，与该主机关联的应用将无法备份。

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

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

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

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

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

第 3 步：实现响应

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

1. 在执行操作的项目中，转到管理控制台。
2. 确认已删除的主机不再位于 Backup and DR 主机列表中。
3. 选择添加主机选项，以重新添加已删除的主机。

Impact: Deleted Google Cloud Backup and DR plan association

Event Threat Detection 会检查审核日志，以检测方案关联是否已删除。

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

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

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

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

联系主账号主体字段中的服务账号所有者，并确认他们是否执行了相应操作。

Impact: Deleted Google Cloud Backup and DR Vault

Event Threat Detection 会检查审核日志，以检测备份保险柜是否已删除。

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

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

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

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

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

Impact: GKE kube-dns modification detected

有人修改了 GKE 集群中的 kube-dns 配置。 GKE kube-dns 是集群网络的关键组成部分，如果配置错误，可能会导致安全事故。

1. 查看集群的 kube-dns 配置，以确定任何可疑更改。

Impact: Google Cloud Backup and DR delete policy

系统会检查审核日志，以检测政策的删除情况。政策定义了进行备份的方式和存储位置。

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

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

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

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

第 3 步：实现响应

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

Impact: Google Cloud Backup and DR delete profile

系统会检查审核日志，以检测配置文件的删除情况。配置文件定义用于存储备份的存储池。

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

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

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

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

第 3 步：实现响应

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

Impact: Google Cloud Backup and DR delete template

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

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

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

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

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

第 3 步：实现响应

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

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

Impact: Google Cloud Backup and DR delete storage pool

系统会检查审核日志以检测是否存储池的删除情况。存储池会将 Cloud Storage 存储桶与 Backup and DR 关联。

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

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

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

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

第 3 步：实现响应

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

Impact: Google Cloud Backup and DR expire all images

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

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

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

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

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

第 3 步：实现响应

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

Impact: Google Cloud Backup and DR expire image

潜在恶意方已请求删除备份映像。

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

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

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

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

第 3 步：实现响应

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

Impact: Google Cloud Backup and DR reduced backup expiration

Event Threat Detection 会检查审核日志，以检测 Backup and DR Service 设备上的备份的失效日期是否已缩短。

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

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

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

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

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

第 3 步：实现响应

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

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

Impact: Google Cloud Backup and DR reduced backup frequency

Event Threat Detection 会检查审核日志，以检测是否修改了备份方案来降低备份频率。

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

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

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

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

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

第 3 步：实现响应

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

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

Impact: Google Cloud Backup and DR remove appliance

系统会检查审核日志以检测备份和恢复设备的移除情况。备份和恢复设备是备份操作的关键组成部分。

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

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

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

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

第 3 步：实现响应

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

Impact: Google Cloud Backup and DR remove plan

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

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

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

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

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

第 3 步：实现响应

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

1. 在执行操作的项目中，转到管理控制台。
2. 在应用管理器标签页中，查找不再受保护的受影响应用，并查看各个应用的备份政策。

Impact: Suspicious Kubernetes Container Names - Cryptocurrency Mining

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

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

Initial Access: Anonymous GKE resource created from the internet

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

• system:anonymous
• system:authenticated
• system:unauthenticated

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

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

如需解决此发现结果，请参阅避免使用默认角色和群组。

Initial Access: CloudDB Successful login from Anonymizing Proxy IP

检测到有人通过已知的匿名化 IP 地址成功登录您的数据库实例。这些匿名化地址是 Tor 节点。 这可能表明攻击者获得了对您实例的初始访问权限。

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

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

1. 按照查看发现结果中所述，打开 Initial Access: CloudDB Successful login from Anonymizing Proxy IP 发现结果。

2. 在发现结果详细信息面板的摘要标签页上，查看以下部分中的信息：

   • 检测到的内容，尤其是以下字段：
   • 指示器 IP 地址，即匿名化 IP 地址。
   • 数据库显示名称：受影响的 Cloud SQL PostgreSQL、MySQL 或 AlloyDB 实例中的数据库的名称。
   • 数据库用户名：用户。
   • 项目全名：包含 Cloud SQL 实例的 Google Cloud 项目。

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

1. 查看此发现结果类型的 MITRE ATT&CK 框架条目：初始访问。
2. 如需确定是否需要执行额外的补救步骤，请将您的调查结果与 MITRE 研究相结合。

第 3 步：实现响应

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

• 查看允许连接到数据库的用户。

  • 对于 PostgreSQL，请参阅创建和管理用户
  • 对于 MySQL，请参阅使用内置身份验证管理用户

• 考虑更改用户的密码。

  • 对于 PostgreSQL，请参阅为默认用户设置密码

  • 对于 MySQL，请参阅为默认用户设置密码

  • 更新连接到 Cloud SQL 实例的客户端的凭证

Initial Access: Database Superuser Writes to User Tables

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

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

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

1. 按照查看发现结果中所述，打开 Initial Access: Database Superuser Writes to User Tables 发现结果。

2. 在发现结果详细信息面板的摘要标签页上，查看以下部分中的信息：

   • 检测到的内容，尤其是以下字段：
     • 数据库显示名称：受影响的 Cloud SQL PostgreSQL 或 MySQL 实例中的数据库的名称。
     • 数据库用户名：超级用户。
     • 数据库查询：在写入用户表时执行的 SQL 查询。
   • 受影响的资源，尤其是以下字段：
     • 资源全名：受影响的 Cloud SQL 实例的资源名称。
     • 父级完整名称：Cloud SQL 实例的资源名称。
     • 项目全名：包含 Cloud SQL 实例的 Google Cloud 项目。
   • 相关链接，尤其是以下字段：
     • Cloud Logging URI：指向 Logging 条目的链接。
     • MITRE ATT&CK 方法：指向 MITRE ATT&CK 文档的链接。
     • 相关发现结果：指向任何相关发现结果的链接。

3. 如需查看发现结果的完整 JSON，请点击 JSON 标签页。

第 2 步：检查日志

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

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

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

第 4 步：实现响应

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

• 查看允许连接到数据库的用户。

  • 对于 PostgreSQL，请参阅创建和管理用户
  • 对于 MySQL，请参阅使用内置身份验证管理用户

• 考虑更改超级用户的密码。

  • 对于 PostgreSQL，请参阅为默认用户设置密码
  • 对于 MySQL，请参阅为默认用户设置密码

• 考虑为在实例中使用的不同类型的查询创建一个具有有限访问权限的新用户。

  • 仅向新用户授予执行此查询所需的必要权限。

    • 对于 PostgreSQL，请参阅 Grant（命令）
    • 对于 MySQL，请参阅访问权限控制和账号管理

  • 更新连接到 Cloud SQL 实例的客户端的凭证

Initial Access: Dormant Service Account Action

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

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

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

1. 按照查看发现结果中所述，打开 Initial Access: Dormant Service Account Action 发现结果。

2. 在发现结果详情的摘要标签页上，记下以下字段的值。

   在检测到的内容下：

   • 主账号电子邮件地址：执行操作的休眠服务账号
   • 服务名称：服务账号访问的 Google Cloud 服务的 API 名称
   • 方法名称：所调用的方法

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

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

第 3 步：实现响应

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

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

Initial Access: Dormant Service Account Activity in AI Service

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

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

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

1. 按照查看发现结果中所述，打开 Initial Access: Dormant Service Account Activity in AI Service 发现结果。

2. 在发现结果详情的摘要标签页上，记下以下字段的值。

   在检测到的内容下：

   • 主账号电子邮件地址：执行操作的休眠服务账号
   • 方法名称：所调用的方法
   • AI 资源：可能受到影响的 AI 资源，例如 Vertex AI 资源和 AI 模型。

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

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

第 3 步：实现响应

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

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

Initial Access: Dormant Service Account Key Created

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

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

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

1. 按照查看发现结果中所述，打开 Initial Access: Dormant Service Account Key Created 发现结果。

2. 在发现结果详情的摘要标签页上，记下以下字段的值。

   在检测到的内容下：

   • 主账号电子邮件地址：创建服务账号密钥的用户

   在受影响的资源下：

   • 资源显示名：新创建的休眠服务账号密钥
   • 项目全名：休眠服务账号所在的项目

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

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

第 3 步：实现响应

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

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

Initial Access: Excessive Permission Denied Actions

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

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

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

1. 按照查看发现结果中所述，打开 Initial Access: Excessive Permission Denied Actions 发现结果。

2. 在发现结果详情的摘要标签页上，记下以下字段的值。

   在检测到的内容下：

   • 主账号电子邮件地址：触发多个权限遭拒错误的主账号
   • 服务名称：上一次权限遭拒错误发生时正在使用的 Google Cloud 服务的 API 名称
   • 方法名称：上一次权限遭拒错误发生时调用的方法

3. 在发现结果详情的来源属性标签页上，记下以下 JSON 字段的值：

   • properties.failedActions：发生的权限遭拒错误。对于每个条目，详细信息包括上次发生错误时的服务名称、方法名称、失败尝试次数以及错误发生时间。最多显示 10 个条目。

第 2 步：检查日志

1. 在 Google Cloud 控制台中，点击 Cloud Logging URI 中的链接，以前往 Logs Explorer。
2. 在 Google Cloud 控制台工具栏中，选择您的项目。

3. 在加载的页面上，使用以下过滤条件查找相关日志：

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"
   • protoPayload.status.code=7

   将 PRINCIPAL_EMAIL 替换为您在发现结果详情的主账号电子邮件地址字段中记录的值。

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

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

第 4 步：实现响应

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

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

Initial Access: GKE NodePort service created

有人创建了 NodePort 服务。NodePort 服务会直接在节点的 IP 地址和静态端口上公开 Pod，从而使 Pod 可从集群外部访问。这可能会引发严重的安全风险，因为攻击者可能会利用已公开服务中的漏洞来获取对集群或敏感数据的访问权限。

1. 查看服务的配置，确定其用途。
2. 考虑限制网络政策以保护服务的安全。

Initial Access: GKE resource modified anonymously from the internet

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

• system:anonymous
• system:authenticated
• system:unauthenticated

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

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

如需解决此发现结果，请参阅避免使用默认角色和群组。

Initial Access: Leaked Service Account Key Used

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

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

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

1. 按照查看发现结果中所述，打开 Initial Access: Leaked Service Account Key Used 发现结果。

2. 在发现结果详情的摘要标签页上，记下以下字段的值。

   在检测到的内容下：

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

   在受影响的资源下：

   • 资源显示名称：操作中涉及的资源

第 2 步：检查日志

1. 在 Google Cloud 控制台中，点击 Cloud Logging URI 中的链接，以前往 Logs Explorer。
2. 在 Google Cloud 控制台工具栏中，选择您的项目或组织。

3. 在加载的页面上，使用以下过滤条件查找相关日志：

   • 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: Log4j Compromise Attempt

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

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

1. 按照查看发现结果详情中所述，打开 Initial Access: Log4j Compromise Attempt 发现结果。系统会打开发现结果详细信息面板，以显示摘要标签页。

2. 在摘要标签页上，查看以下部分中的信息：

   • 检测到的内容
   • 受影响的资源
   • 相关链接，尤其是以下字段：
     • 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 步：检查日志

1. 在 Google Cloud 控制台中，点击第 1 步的 Cloud Logging URI 字段中的链接，以前往 Logs Explorer。

2. 在加载的页面上，检查 httpRequest 字段中是否存在 ${jndi:ldap:// 等字符串令牌，这可能表示潜在的漏洞利用尝试。

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

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

1. 查看此发现结果类型的 MITRE ATT&CK 框架条目：利用面向公众的应用。
2. 点击发现结果详情摘要标签页中相关发现结果行上的相关发现结果的链接，以查看相关发现结果。相关发现结果在同一实例和网络上属于同一发现结果类型。
3. 如需制定响应方案，请将您的调查结果与 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 漏洞。

Initial Access: Successful API call made from a TOR proxy IP

从与 Tor 网络关联的 IP 地址向您的 GKE 集群发出了成功的 API 调用。Tor 可提供匿名性，攻击者通常会利用这一点来隐藏自己的身份。

1. 调查 API 调用和访问的资源的性质。
2. 查看您的网络政策和防火墙规则，以阻止来自 Tor 代理 IP 地址的访问。

Lateral Movement: Modified Boot Disk Attached to Instance

系统会检查审核日志以检测 Compute Engine 实例资源中可疑的磁盘移动情况。可能已修改的启动磁盘已挂接到您的 Compute Engine。

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

1. 按照查看发现结果中所述，打开 Lateral Movement: Modify Boot Disk Attaching to Instance 发现结果。 系统会打开发现结果详细信息面板，以显示摘要标签页。

2. 在摘要标签页上，记下以下字段的值。

   在检测到的内容下：

   • 主账号邮件：执行操作的服务账号
   • 服务名称：服务账号访问的 Google Cloud 服务的 API 名称
   • 方法名称：所调用的方法

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

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

第 3 步：实现响应

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

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

Leaked credentials

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

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

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

1. 按照查看发现结果详情中所述，打开 account_has_leaked_credentials 发现结果。系统会打开发现结果详细信息面板，以显示摘要标签页。

2. 在摘要标签页上，查看以下部分中的信息：

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

1. 点击来源属性标签页并注意以下字段：

   • Compromised_account：可能被盗用的服务账号
   • Project_identifier：包含可能已泄露的账号凭据的项目
   • URL：指向 GitHub 代码库的链接

2. 如需查看发现结果的完整 JSON，请点击 JSON 标签页。

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

1. 在 Google Cloud 控制台中，前往 IAM 页面。

   转到 IAM

2. 如有必要，选择 Project_identifier 中列出的项目。

3. 在显示的页面上的过滤条件框中，输入 Compromised_account 中列出的账号名称并检查已分配的权限。

4. 在 Google Cloud 控制台中，前往服务账号页面。

   转到“服务账号”

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

第 3 步：检查日志

1. 在 Google Cloud 控制台中，前往 Logs Explorer。

   前往 Logs Explorer

2. 在 Google Cloud 控制台工具栏中，选择您的项目。

3. 在加载的页面上，使用以下过滤条件检查新的或更新后的 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 步：研究攻击和响应方法

1. 查看此发现结果类型的 MITRE ATT&CK 框架条目：有效账号：云账号。
2. 点击 relatedFindingURI 中的链接查看相关发现结果。相关发现结果属于同一实例和网络上的同一发现结果类型。
3. 如需制定响应方案，请将您的调查结果与 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 步：查看发现结果详情

1. 打开相关的恶意软件发现结果。按照查看发现结果中所述，以下步骤使用 Malware: Bad IP 发现结果。系统会打开发现结果详细信息面板，以显示摘要标签页。

2. 在摘要标签页上，查看以下部分中的信息：

   • 检测到的内容，尤其是以下字段：
     • 指示器网域：对于 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 文档的链接。
     • 相关发现结果：指向任何相关发现结果的链接。
     • VirusTotal 指示器：指向 VirusTotal 分析页面的链接。
     • Flow Analyzer：指向 Network Intelligence Center 的 Flow Analyzer 功能的链接。只有在启用 VPC 流日志后，此字段才会显示。

   1. 点击 JSON 标签页并注意以下字段：

      • evidence：
      • sourceLogId：
        • projectID：在其中检测到问题的项目的 ID。
      • properties：
      • InstanceDetails：Compute Engine 实例的资源地址。

第 2 步：查看权限和设置

1. 在 Google Cloud 控制台中，前往信息中心页面。

   转到信息中心

2. 选择摘要标签页上的项目全名行中指定的项目。

3. 导航到资源卡片，然后点击 Compute Engine。

4. 点击与资源全名中的名称和可用区匹配的虚拟机实例。查看该实例的详细信息，包括网络和访问设置。

5. 在导航窗格中，点击 VPC 网络，然后点击防火墙。 移除或停用过于宽松的防火墙规则。

第 3 步：检查日志

1. 在发现结果详细信息面板的“摘要”标签页上，点击 Cloud Logging URI 链接以打开 Logs Explorer。

2. 在加载的页面上，使用以下过滤条件查找与来源 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 地址。

第 4 步：检查 Flow Analyzer

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

1. 确保您已将日志存储桶升级为使用 Log Analytics。 如需了解相关说明，请参阅升级存储桶以使用 Log Analytics。升级不会产生额外费用。

2. 在 Google Cloud 控制台中，前往 Flow Analyzer 页面：

   前往 Flow Analyzer

   您还可以通过发现结果详细信息窗格的摘要标签页上相关链接部分中的 Flow Analyzer 网址链接访问 Flow Analyzer。

3. 如需进一步调查与 Event Threat Detection 发现结果相关的信息，请使用操作栏中的时间范围选择器更改时间段。时间范围应反映首次报告发现结果的时间。例如，如果发现结果是在过去 2 小时内报告的，您可以将时间范围设置为过去 6 小时。这样可确保 Flow Analyzer 中的时间段包含发现结果的报告时间。

4. 过滤 Flow Analyzer，以显示与恶意 IP 发现结果关联的 IP 地址的适当结果：

   1. 在查询部分的来源行中，从过滤条件菜单中选择 IP。

   2. 在值字段中，输入与相应发现结果关联的 IP 地址，然后点击运行新查询。

      如果 Flow Analyzer 未显示 IP 地址的任何结果，请清除来源行中的过滤条件，然后在目标行中使用相同的过滤条件再次运行查询。

5. 分析结果。如需了解特定流的更多信息，请点击所有数据流表中的详细信息，以打开流详细信息窗格。

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

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

第 6 步：实现响应

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

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

Malware: Cryptomining Bad IP

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

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

1. 按照查看发现结果中所述，打开 Malware: Cryptomining Bad IP 发现结果。系统会打开发现结果详细信息面板，以显示摘要标签页。

2. 在摘要标签页上，查看以下部分中的信息：

   • 检测到的内容，尤其是以下字段：
     • 来源 IP：疑似加密货币挖矿 IP 地址。
     • 来源端口：连接的来源端口（如果有）。
     • 目标 IP：目标 IP 地址。
     • 目标端口：连接的目标端口（如果有）。
     • 协议：与连接关联的 IANA 协议。
   • 受影响的资源
   • 相关链接，其中包括以下字段：
     • Logging URI：指向 Logging 条目的链接。
     • MITRE ATT&CK 方法：指向 MITRE ATT&CK 文档的链接。
     • 相关发现结果：指向任何相关发现结果的链接。
     • Flow Analyzer：指向 Network Intelligence Center 的 Flow Analyzer 功能的链接。只有在启用 VPC 流日志后，此字段才会显示。

3. 在发现结果的详情视图中，点击来源属性标签页。

4. 展开属性，并记下以下字段中的项目和实例值：

   • instanceDetails：记下项目 ID 和 Compute Engine 实例的名称。项目 ID 和实例名称如下例所示：

     /projects/PROJECT_ID/zones/ZONE/instances/INSTANCE_NAME

5. 如需查看发现结果的完整 JSON，请点击 JSON 标签页。

第 2 步：查看权限和设置

1. 在 Google Cloud 控制台中，前往信息中心页面。

   转到信息中心

2. 选择 properties_project_id 中指定的项目。

3. 导航到资源卡片，然后点击 Compute Engine。

4. 点击与 properties_sourceInstance 匹配的虚拟机实例。调查可能被破解的实例是否存在恶意软件。

5. 在导航窗格中，点击 VPC 网络，然后点击防火墙。 移除或停用过于宽松的防火墙规则。

第 3 步：检查日志

1. 在 Google Cloud 控制台中，前往 Logs Explorer。

   前往 Logs Explorer

2. 在 Google Cloud 控制台工具栏中，选择您的项目。

3. 在加载的页面上，使用以下过滤条件查找与 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 步：研究攻击和响应方法

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

第 5 步：实现响应

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

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

Persistence: GKE Webhook Configuration Detected

在您的 GKE 集群中检测到 webhook 配置。 webhook 可以拦截和修改 Kubernetes API 请求，可能使攻击者能够在您的集群中持久化或操纵资源。

1. 确定 webhook 配置的用途和来源。验证其来源可信且用途合法。
2. 查看 webhook 配置，了解其范围及其拦截的请求类型。
3. 监控 webhook 活动，查看是否存在任何可疑或未经授权的操作。
4. 如果 webhook 不必要或其行为令人担忧，请考虑将其移除或停用。

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 步：查看发现结果详情

1. 按照查看发现结果中所述，打开 Persistence: IAM Anomalous Grant 发现结果。系统会打开发现结果详细信息面板，以显示摘要标签页。

2. 在摘要标签页上，查看以下部分中的信息：

   • 检测到的内容，尤其是以下字段：
     • 主账号邮件：分配了角色的用户或服务账号的邮箱。

   • 受影响的资源

   • 相关链接，尤其是以下字段：

     • Cloud Logging URI：指向 Logging 条目的链接。
     • MITRE ATT&CK 方法：指向 MITRE ATT&CK 文档的链接。
     • 相关发现结果：指向任何相关发现结果的链接。
     • VirusTotal 指示器：指向 VirusTotal 分析页面的链接。

3. 点击 JSON 标签页。系统会显示该发现结果的完整 JSON。

4. 在发现结果的 JSON 中，注意以下字段：

   • detectionCategory：
     • subRuleName：有关发生的异常授权类型的更具体的信息。子规则决定此发现结果的严重程度分类。
   • evidence：
     • sourceLogId：
     • projectId：包含发现结果的项目的 ID。
   • properties：
     • sensitiveRoleGrant：
       • bindingDeltas：
       • Action：用户执行的操作。
       • Role：为用户分配的角色。
       • member：获得该角色的用户的电子邮件地址。

第 2 步：检查日志

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

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

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

第 4 步：实现响应

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

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

Persistence: New AI API Method

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

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

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

1. 按照查看发现结果中所述，打开 Persistence: New AI API Method 发现结果。

2. 在发现结果详情的摘要标签页上，记下以下字段的值：

   • 在检测到的内容下：
     • 主账号电子邮件地址：发出调用的账号
     • 方法名称：所调用的方法
     • AI 资源：可能受到影响的 AI 资源，例如 Vertex AI 资源和 AI 模型。
   • 在受影响的资源下：
     • 资源显示名称：受影响资源的名称，可能与组织、文件夹或项目的名称相同
     • 资源路径：活动发生的资源层次结构中的位置

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

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

Persistence: New API Method

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

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

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

1. 按照查看发现结果中所述，打开 Persistence: New API Method 发现结果。

2. 在发现结果详情的摘要标签页上，记下以下字段的值：

   • 在检测到的内容下：
     • 主账号电子邮件地址：发出调用的账号
     • 服务名称：操作中使用的 Google Cloud 服务的 API 名称
     • 方法名称：所调用的方法
   • 在受影响的资源下：
     • 资源显示名称：受影响资源的名称，可能与组织、文件夹或项目的名称相同
     • 资源路径：活动发生的资源层次结构中的位置

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

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

Persistence: New Geography

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

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

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

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

2. 在摘要标签页上，查看以下部分中的信息：

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

1. 在发现结果的详情视图中，点击 JSON 标签页。

2. 在 JSON 中，请注意以下 sourceProperties 字段：

   • affectedResources：
     • gcpResourceName：受影响的资源
   • evidence：
     • sourceLogId：
     • projectId：包含发现结果的项目的 ID。
   • properties：
     • anomalousLocation：
     • anomalousLocation：预估的用户当前位置。
     • callerIp：外部 IP 地址。
     • notSeenInLast：用于建立正常行为基准的时间段。
     • typicalGeolocations：用户通常在其中访问Google Cloud 资源的位置。

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

1. 在 Google Cloud 控制台中，前往 IAM 页面。

   转到 IAM

2. 如有必要，请选择发现结果 JSON 中 projectID 字段中列出的项目。

3. 在显示的页面上的过滤条件框中，输入主账号电子邮件地址中列出的账号名称，并检查授予的角色。

第 3 步：检查日志

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

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

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

第 5 步：实现响应

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

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

Persistence: New Geography for AI Service

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

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

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

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

2. 在摘要标签页上，查看以下部分中的信息：

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

1. 在发现结果的详情视图中，点击 JSON 标签页。

2. 在 JSON 中，请注意以下 sourceProperties 字段：

   • affectedResources：
     • gcpResourceName：受影响的资源
   • evidence：
     • sourceLogId：
     • projectId：包含发现结果的项目的 ID。
   • properties：
     • anomalousLocation：
     • anomalousLocation：预估的用户当前位置。
     • callerIp：外部 IP 地址。
     • notSeenInLast：用于建立正常行为基准的时间段。
     • typicalGeolocations：用户通常在其中访问Google Cloud 资源的位置。
   • aiModel：
     • name：受影响的 AI Model
   • vertexAi：
     • datasets：受影响的 Vertex AI 数据集
     • pipelines：受影响的 Vertex AI 训练流水线

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

1. 在 Google Cloud 控制台中，前往 IAM 页面。

   转到 IAM

2. 如有必要，请选择发现结果 JSON 中 projectID 字段中列出的项目。

3. 在显示的页面上的过滤条件框中，输入主账号电子邮件地址中列出的账号名称，并检查授予的角色。

第 3 步：检查日志

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

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

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

第 5 步：实现响应

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

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

Persistence: New User Agent

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

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

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

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

2. 在摘要标签页上，查看以下部分中的信息：

   • 检测到的内容，尤其是以下字段：
     • 主账号邮件：可能被盗用的服务账号。
   • 受影响的资源，尤其是以下字段：
     • 项目全名：包含可能被盗用的服务账号的项目。
   • 相关链接，尤其是以下字段：
     • Cloud Logging URI：指向 Logging 条目的链接。
     • MITRE ATT&CK 方法：指向 MITRE ATT&CK 文档的链接。
     • 相关发现结果：指向任何相关发现结果的链接。
   1. 在发现结果的详情视图中，点击 JSON 标签页。
   2. 在 JSON 中，请注意以下字段。
   • projectId：包含可能被盗用的服务账号的项目。
   • callerUserAgent：异常用户代理。
   • anomalousSoftwareClassification：软件类型。
   • notSeenInLast：用于建立正常行为基准的时间段。

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

1. 在 Google Cloud 控制台中，前往 IAM 页面。

   转到 IAM

2. 如有必要，选择 projectId 中列出的项目。

3. 在显示的页面上的过滤条件框中，输入发现结果详情摘要标签页中主账号电子邮件地址行上列出的账号名称，并检查授予的角色。

4. 在 Google Cloud 控制台中，前往服务账号页面。

   转到“服务账号”

5. 在显示的页面上的过滤条件框中，输入发现结果详情摘要标签页中主账号电子邮件地址行上列出的账号名称。

6. 检查该服务账号的密钥和密钥创建日期。

第 3 步：检查日志

1. 在发现结果详细信息面板的“摘要”标签页上，点击 Cloud Logging URI 链接以打开 Logs Explorer。
2. 如有必要，请选择您的项目。
3. 在加载的页面上，使用以下过滤条件检查新的或更新后的 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 步：研究攻击和响应方法

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

第 5 步：实现响应

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

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

Persistence: Service Account Created in sensitive namespace

有人在敏感命名空间中创建了服务账号。kube-system 和 kube-public 命名空间对于 GKE 集群操作至关重要，未经授权的服务账号可能会破坏集群的稳定性和安全性。1. 如果服务账号未经授权，请将其删除，并调查创建方法。

Persistence: Unmanaged Account Granted Sensitive Role

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

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

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

1. 按照查看发现结果中所述，打开 Persistence: Unmanaged Account Granted Sensitive Role 发现结果。

2. 在发现结果详情的摘要标签页上，记下以下字段的值。

   在检测到的内容下：

   • 主账号电子邮件地址：执行授予角色操作的用户
   • 违规访问授权主账号名称：接受授权的非受管账号
   • 违规访问授权授予的角色：授予的敏感角色

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

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

第 3 步：检查日志

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

第 4 步：实现响应

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

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

Privilege Escalation: AlloyDB Database Superuser Writes to User Tables

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

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

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

1. 按照查看发现结果中所述，打开 Privilege Escalation: AlloyDB Database Superuser Writes to User Tables 发现结果。

2. 在发现结果详细信息面板的摘要标签页上，查看以下部分中的信息：

   • 检测到的内容，尤其是以下字段：
     • 数据库显示名称：受影响的 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 文档的链接。

3. 如需查看发现结果的完整 JSON，请点击 JSON 标签页。

第 2 步：检查日志

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

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

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

第 4 步：实现响应

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

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

Privilege Escalation: AlloyDB Over-Privileged Grant

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

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

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

1. 按照查看发现结果中所述，打开 Privilege Escalation: AlloyDB Over-Privileged Grant 发现结果。

2. 在发现结果详细信息面板的摘要标签页上，查看以下部分中的信息：

   • 检测到的内容，尤其是以下字段：
     • 数据库显示名称：受影响的 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 文档的链接。

3. 如需查看发现结果的完整 JSON，请点击 JSON 标签页。

第 2 步：查看数据库权限

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

第 3 步：检查日志

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

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

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

第 5 步：实现响应

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

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

Privilege Escalation: Anomalous Impersonation of Service Account for Admin Activity

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

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

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

1. 按照查看发现结果中所述，打开 Privilege Escalation: Anomalous Impersonation of Service Account for Admin Activity 发现结果。系统会打开发现结果详细信息面板，以显示摘要标签页。

2. 在摘要标签页上，查看以下部分中的信息：

   • 检测到的内容，尤其是以下字段：
     • 主账号邮件：用于访问 Google Cloud的模拟请求中的最终服务账号。
     • 服务名称：模拟请求所涉及的 Google Cloud 服务的 API 名称。
     • 方法名称：所调用的方法。
     • 服务账号委托信息：委托链中服务账号的详细信息，列表底部的主账号是模拟请求的调用方。
   • 受影响的资源，尤其是以下字段：
     • 资源全名：集群的名称。
   • 相关链接，尤其是以下字段：
     • Cloud Logging URI：指向 Logging 条目的链接。
     • MITRE ATT&CK 方法：指向 MITRE ATT&CK 文档的链接。
     • 相关发现结果：指向任何相关发现结果的链接。

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

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

第 3 步：实现响应

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

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

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

当 AI 服务的管理员活动审核日志显示服务账号模拟请求中出现异常时，系统会检测到 Anomalous Impersonation of Service Account。

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

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

1. 按照查看发现结果中所述，打开 Privilege Escalation: Anomalous Impersonation of Service Account for AI Admin Activity 发现结果。系统会打开发现结果详细信息面板，以显示摘要标签页。

2. 在摘要标签页上，查看以下部分中的信息：

   • 检测到的内容，尤其是以下字段：
     • 主账号邮件：用于访问 Google Cloud的模拟请求中的最终服务账号。
     • 方法名称：所调用的方法。
     • 服务账号委托信息：委托链中服务账号的详细信息。列表底部的主账号是模拟请求的调用方。
     • AI 资源：可能受到影响的 AI 资源，例如 Vertex AI 资源和 AI 模型。
   • 受影响的资源，尤其是以下字段：
     • 资源全名：集群的名称。
   • 相关链接，尤其是以下字段：
     • Cloud Logging URI：指向 Logging 条目的链接。
     • MITRE ATT&CK 方法：指向 MITRE ATT&CK 文档的链接。
     • 相关发现结果：指向任何相关发现结果的链接。

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

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

第 3 步：实现响应

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

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

Privilege Escalation: Anomalous Multistep Service Account Delegation for Admin Activity

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

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

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

1. 按照查看发现结果中所述，打开 Privilege Escalation: Anomalous Multistep Service Account Delegation for Admin Activity 发现结果。 系统会打开发现结果详细信息面板，以显示摘要标签页。

2. 在摘要标签页上，查看以下部分中的信息：

   • 检测到的内容，尤其是以下字段：
     • 主账号邮件：用于访问 Google Cloud的模拟请求中的最终服务账号。
     • 服务名称：模拟请求所涉及的 Google Cloud 服务的 API 名称。
     • 方法名称：所调用的方法。
     • 服务账号委托信息：委托链中服务账号的详细信息，列表底部的主账号是模拟请求的调用方。
   • 受影响的资源
   • 相关链接，尤其是以下字段：
     • Cloud Logging URI：指向 Logging 条目的链接。
     • MITRE ATT&CK 方法：指向 MITRE ATT&CK 文档的链接。
     • 相关发现结果：指向任何相关发现结果的链接。

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

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

第 3 步：实现响应

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

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

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

当 AI 服务的管理员活动审核日志显示服务账号模拟请求中出现异常时，系统会检测到 Anomalous Multistep Service Account Delegation。

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

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

1. 按照查看发现结果中所述，打开 Privilege Escalation: Anomalous Multistep Service Account Delegation for AI Admin Activity 发现结果。 系统会打开发现结果详细信息面板，以显示摘要标签页。

2. 在摘要标签页上，查看以下部分中的信息：

   • 检测到的内容，尤其是以下字段：
     • 主账号邮件：用于访问 Google Cloud的模拟请求中的最终服务账号。
     • 方法名称：所调用的方法。
     • 服务账号委托信息：委托链中服务账号的详细信息。列表底部的主账号是模拟请求的调用方。
     • AI 资源：可能受到影响的 AI 资源，例如 Vertex AI 资源和 AI 模型。
   • 受影响的资源
   • 相关链接，尤其是以下字段：
     • Cloud Logging URI：指向 Logging 条目的链接。
     • MITRE ATT&CK 方法：指向 MITRE ATT&CK 文档的链接。
     • 相关发现结果：指向任何相关发现结果的链接。

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

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

第 3 步：实现响应

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

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

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

当 AI 服务的管理员活动审核日志显示服务账号模拟请求中出现异常时，系统会检测到 Anomalous Multistep Service Account Delegation。

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

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

1. 按照查看发现结果中所述，打开 Privilege Escalation: Anomalous Multistep Service Account Delegation for AI Data Access 发现结果。系统会打开发现结果详细信息面板，以显示摘要标签页。

2. 在摘要标签页上，查看以下部分中的信息：

   • 检测到的内容，尤其是以下字段：
     • 主账号邮件：用于访问 Google Cloud的模拟请求中的最终服务账号
     • 方法名称：所调用的方法
     • 服务账号委托信息：委托链中服务账号的详细信息。列表底部的主账号是模拟请求的调用方
     • AI 资源：可能受到影响的 AI 资源，例如 Vertex AI 资源和 AI 模型。
   • 受影响的资源
   • 相关链接，尤其是以下字段：
     • Cloud Logging URI：指向 Logging 条目的链接。
     • MITRE ATT&CK 方法：指向 MITRE ATT&CK 文档的链接。
     • 相关发现结果：指向任何相关发现结果的链接。

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

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

第 3 步：实现响应

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

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

Privilege Escalation: Anomalous Multistep Service Account Delegation for Data Access

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

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

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

1. 按照查看发现结果中所述，打开 Privilege Escalation: Anomalous Multistep Service Account Delegation for Data Access 发现结果。系统会打开发现结果详细信息面板，以显示摘要标签页。

2. 在摘要标签页上，查看以下部分中的信息：

   • 检测到的内容，尤其是以下字段：
     • 主账号邮件：用于访问 Google Cloud的模拟请求中的最终服务账号
     • 服务名称：模拟请求所涉及的 Google Cloud 服务的 API 名称
     • 方法名称：所调用的方法
     • 服务账号委托信息：委托链中服务账号的详细信息，列表底部的主账号是模拟请求的调用方
   • 受影响的资源
   • 相关链接，尤其是以下字段：
     • Cloud Logging URI：指向 Logging 条目的链接。
     • MITRE ATT&CK 方法：指向 MITRE ATT&CK 文档的链接。
     • 相关发现结果：指向任何相关发现结果的链接。

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

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

第 3 步：实现响应

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

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

Privilege Escalation: Anomalous Service Account Impersonator for Admin Activity

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

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

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

1. 按照查看发现结果中所述，打开 Privilege Escalation: Anomalous Service Account Impersonator for Admin Activity 发现结果。系统会打开发现结果详细信息面板，以显示摘要标签页。

2. 在摘要标签页上，查看以下部分中的信息：

   • 检测到的内容，尤其是以下字段：

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

   • 受影响的资源

   • 相关链接，尤其是以下字段：

     • Cloud Logging URI：指向 Logging 条目的链接。
     • MITRE ATT&CK 方法：指向 MITRE ATT&CK 文档的链接。
     • 相关发现结果：指向任何相关发现结果的链接。

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

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

第 3 步：实现响应

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

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

Privilege Escalation: Anomalous Service Account Impersonator for AI Admin Activity

当 AI 服务的管理员活动审核日志显示服务账号模拟请求中出现异常时，系统会检测到 Anomalous Service Account Impersonator。

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

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

1. 按照查看发现结果中所述，打开 Privilege Escalation: Anomalous Service Account Impersonator for AI Admin Activity 发现结果。系统会打开发现结果详细信息面板，以显示摘要标签页。

2. 在摘要标签页上，查看以下部分中的信息：

   • 检测到的内容，尤其是以下字段：
     • 主账号邮件：用于访问 Google Cloud的模拟请求中的最终服务账号
     • 方法名称：所调用的方法
     • 服务账号委托信息：委托链中服务账号的详细信息。列表底部的主账号是模拟请求的调用方
     • AI 资源：可能受到影响的 AI 资源，例如 Vertex AI 资源和 AI 模型。
   • 受影响的资源
   • 相关链接，尤其是以下字段：
     • Cloud Logging URI：指向 Logging 条目的链接。
     • MITRE ATT&CK 方法：指向 MITRE ATT&CK 文档的链接。
     • 相关发现结果：指向任何相关发现结果的链接。

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

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

第 3 步：实现响应

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

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

Privilege Escalation: Anomalous Service Account Impersonator for AI Data Access

当 AI 服务的管理员活动审核日志显示服务账号模拟请求中出现异常时，系统会检测到 Anomalous Service Account Impersonator。

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

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

1. 按照查看发现结果中所述，打开 Privilege Escalation: Anomalous Service Account Impersonator for AI Data Access 发现结果。

2. 在发现结果详情的摘要标签页上，记下以下字段的值。

   在检测到的内容下：

   • 主账号邮件：用于访问 Google Cloud的模拟请求中的最终服务账号
   • 方法名称：所调用的方法
   • 服务账号委托信息：委托链中服务账号的详细信息。列表底部的主账号是模拟请求的调用方
   • AI 资源：可能受到影响的 AI 资源，例如 Vertex AI 资源和 AI 模型。

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

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

第 3 步：实现响应

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

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

Privilege Escalation: Anomalous Service Account Impersonator for Data Access

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

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

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

1. 按照查看发现结果中所述，打开 Privilege Escalation: Anomalous Service Account Impersonator for Data Access 发现结果。

2. 在发现结果详情的摘要标签页上，记下以下字段的值。

   在检测到的内容下：

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

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

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

第 3 步：实现响应

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

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

Privilege Escalation: Changes to sensitive Kubernetes RBAC objects

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

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

1. 按照查看发现结果中所述，打开 Privilege Escalation: Changes to sensitive Kubernetes RBAC objects 发现结果。 系统会打开发现结果详细信息面板，以显示摘要标签页。

2. 在摘要标签页上，查看以下部分中的信息：

   • 检测到的内容，尤其是以下字段：
     • 主账号电子邮件地址：发出调用的账号。
     • 方法名称：所调用的方法。
     • Kubernetes 绑定：已修改的敏感 Kubernetes 绑定或 ClusterRoleBinding。
   • 受影响的资源，尤其是以下字段：
     • 资源显示名称：执行操作的 Kubernetes 集群。
   • 相关链接，尤其是以下字段：
     • Cloud Logging URI：指向 Logging 条目的链接。
     • MITRE ATT&CK 方法：指向 MITRE ATT&CK 文档的链接。
     • 相关发现结果：指向任何相关发现结果的链接。

3. 在检测到的内容部分中，点击 Kubernetes 绑定行上的绑定的名称。系统会显示绑定详细信息。

4. 在显示的绑定中，请注意绑定详细信息。

第 2 步：检查日志

1. 在 Google Cloud 控制台中发现结果详细信息的摘要标签页上，通过点击 Cloud Logging URI 字段中的链接转到 Logs Explorer。

2. 如果方法名称中的值是 PATCH 方法，请检查请求正文，了解修改了哪些属性。

   在 update (PUT) 调用中，整个对象会在请求中发送，因此更改不太明显。

3. 使用以下过滤条件检查主账号执行的其他操作：

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     替换以下内容：

   • CLUSTER_NAME：您在发现结果详情的资源显示名称字段中记下的值。

   • PRINCIPAL_EMAIL：您在发现结果详情的主账号电子邮件地址字段中记下的值。

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

1. 查看此发现结果类型的 MITRE ATT&CK 框架条目：提升权限
2. 确认对象的敏感度以及是否有必要进行修改。
3. 对于绑定，您可以检查主体，并调查主体是否需要其绑定到的角色。
4. 确定日志中是否存在主账号的其他恶意活动迹象。

5. 如果主账号电子邮件地址不是服务账号，请与该账号的所有者联系，以确认合法所有者是否执行了该操作。

   如果主账号电子邮件地址是服务账号（IAM 或 Kubernetes），请查明修改来源以确定其合法性。

6. 如需制定响应方案，请将您的调查结果与 MITRE 研究相结合。

Privilege Escalation: ClusterRole with Privileged Verbs

有人创建了包含 bind、escalate 或 impersonate 动词的 RBAC ClusterRole。与包含这些动词的角色绑定的主体可以伪装成具有更高权限的其他用户，绑定到包含更多权限的其他 Role 或 ClusterRole，或者修改自己的 ClusterRole 权限。这可能会导致这些主体获得 cluster-admin 特权。如需了解详情，请参阅此提醒的日志消息。

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

Privilege Escalation: ClusterRoleBinding to Privileged Role

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

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

Privilege Escalation: Create Kubernetes CSR for master cert

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

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

1. 按照查看发现结果中所述，打开 Privilege Escalation: Create Kubernetes CSR for master cert 发现结果。系统会打开发现结果详细信息面板，以显示摘要标签页。

2. 在摘要标签页上，查看以下部分中的信息：

   • 检测到的内容，尤其是以下字段：
     • 主账号电子邮件地址：发出调用的账号。
     • 方法名称：所调用的方法。
   • 受影响的资源，尤其是以下字段：
     • 资源显示名称：执行操作的 Kubernetes 集群。
   • 相关链接，尤其是以下字段：
     • Cloud Logging URI：指向 Logging 条目的链接。
     • MITRE ATT&CK 方法：指向 MITRE ATT&CK 文档的链接。
     • 相关发现结果：指向任何相关发现结果的链接。

第 2 步：检查日志

1. 在 Google Cloud 控制台中发现结果详细信息的摘要标签页上，通过点击 Cloud Logging URI 字段中的链接转到 Logs Explorer。
2. 查看 protoPayload.resourceName 字段中的值以识别特定的证书签名请求。

3. 使用以下过滤条件检查主账号执行的其他操作：

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     替换以下内容：

   • CLUSTER_NAME：您在发现结果详情的资源显示名称字段中记下的值。

   • PRINCIPAL_EMAIL：您在发现结果详情的主账号电子邮件地址字段中记下的值。

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

1. 查看此发现结果类型的 MITRE ATT&CK 框架条目：提升权限。
2. 调查是否有必要向 cluster-admin 授予访问权限。

3. 如果主账号电子邮件地址不是服务账号，请与该账号的所有者联系，以确认合法所有者是否执行了该操作。

   如果主账号电子邮件地址是服务账号（IAM 或 Kubernetes），请查明操作来源以确定其合法性。

4. 如需制定响应方案，请将您的调查结果与 MITRE 研究相结合。

Privilege Escalation: Creation of sensitive Kubernetes bindings

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

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

1. 按照查看发现结果中所述，打开 Privilege Escalation: Creation of sensitive Kubernetes bindings 发现结果。 系统会打开发现结果详细信息面板，以显示摘要标签页。

2. 在摘要标签页上，查看以下部分中的信息：

   • 检测到的内容，尤其是以下字段：
     • 主账号电子邮件地址：发出调用的账号。
     • Kubernetes 绑定：已创建的敏感 Kubernetes 绑定或 ClusterRoleBinding。
   • 受影响的资源，尤其是以下字段：
     • 资源显示名称：执行操作的 Kubernetes 集群。
   • 相关链接，尤其是以下字段：
     • Cloud Logging URI：指向 Logging 条目的链接。
     • MITRE ATT&CK 方法：指向 MITRE ATT&CK 文档的链接。
     • 相关发现结果：指向任何相关发现结果的链接。

第 2 步：检查日志

1. 在 Google Cloud 控制台中发现结果详细信息的摘要标签页上，通过点击 Cloud Logging URI 字段中的链接转到 Logs Explorer。

2. 使用以下过滤条件检查主账号执行的其他操作：

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     替换以下内容：

   • CLUSTER_NAME：您在发现结果详情的资源显示名称字段中记下的值。

   • PRINCIPAL_EMAIL：您在发现结果详情的主账号电子邮件地址字段中记下的值。

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

1. 查看此发现结果类型的 MITRE ATT&CK 框架条目：提升权限。
2. 确认已创建的绑定的敏感性以及主体是否需要这些角色。
3. 对于绑定，您可以检查主体，并调查主体是否需要其绑定到的角色。
4. 确定日志中是否存在主账号的其他恶意活动迹象。

5. 如果主账号电子邮件地址不是服务账号，请与该账号的所有者联系，以确认合法所有者是否执行了该操作。

   如果主账号电子邮件地址是服务账号（IAM 或 Kubernetes），请查明操作来源以确定其合法性。

6. 如需制定响应方案，请将您的调查结果与 MITRE 研究相结合。

Privilege Escalation: Default Compute Engine Service Account SetIAMPolicy

检测何时使用默认 Compute Engine 服务账号为 Cloud Run 服务设置 IAM 政策。当来自无服务器服务的 Compute Engine token 遭泄露时，这可能是攻击者获取权限后进行的攻击行为。

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

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

Privilege Escalation: Dormant Service Account Granted Sensitive Role

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

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

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

1. 按照查看发现结果中所述，打开 Privilege Escalation: Dormant Service Account Granted Sensitive Role 发现结果。

2. 在发现结果详情的摘要标签页上，记下以下字段的值。

   在检测到的内容下：

   • 主账号电子邮件地址：执行授予角色操作的用户
   • 违规访问授权主账号名称：接受敏感角色的休眠服务账号
   • 违规访问授权授予的角色：分配的敏感 IAM 角色

   在受影响的资源下：

   • 资源显示名称：向休眠服务账号授予敏感 IAM 角色的组织、文件夹或项目。

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

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

第 3 步：检查日志

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

第 4 步：实现响应

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

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

Privilege Escalation: Effectively Anonymous Users Granted GKE Cluster Access

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

• system:anonymous
• system:authenticated
• system:unauthenticated

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

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

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

Privilege Escalation: External Member Added To Privileged Group

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

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

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

1. 按照查看发现结果中所述，打开 Privilege Escalation: External Member Added To Privileged Group 发现结果。 系统会打开发现结果详细信息面板，以显示摘要标签页。

2. 在摘要标签页上，查看以下部分中的信息：

   • 检测到的内容，尤其是以下字段：
     • 主账号电子邮件地址：做出更改的账号。
   • 受影响的资源
   • 相关链接，尤其是以下字段：
     • Cloud Logging URI：指向 Logging 条目的链接。
     • MITRE ATT&CK 方法：指向 MITRE ATT&CK 文档的链接。
     • 相关发现结果：指向任何相关发现结果的链接。

3. 在详细信息面板中，点击 JSON 标签页。

4. 在 JSON 中，请注意以下字段。

   • groupName：在其中进行更改的 Google 群组
   • externalMember：新添加的外部成员
   • sensitiveRoles：与此群组关联的敏感角色

第 2 步：查看群组成员

1. 转到 Google 群组。

   转到 Google 群组。

2. 点击您要查看的群组的名称。

3. 在导航菜单中，点击成员。

4. 如果新添加的外部成员不应在此群组中，请点击成员名称旁边的复选框，然后选择 remove_circle_outline 移除成员或 not_interested 将成员加入屏蔽名单。

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

第 3 步：检查日志

1. 在发现结果详细信息面板的“摘要”标签页上，点击 Cloud Logging URI 链接以打开 Logs Explorer。

2. 如有必要，请选择您的项目。

3. 在加载的页面上，使用以下过滤条件检查日志，了解 Google 群组成员资格是否发生更改：

   • protoPayload.methodName="google.apps.cloudidentity.groups.v1.MembershipsService.UpdateMembership"
   • protoPayload.authenticationInfo.principalEmail="principalEmail"

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

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

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 步：查看发现结果详情

1. 按照查看发现结果中所述，打开 Privilege Escalation: Get Kubernetes CSR with compromised bootstrap credentials 发现结果。 系统会打开发现结果详细信息面板，以显示摘要标签页。

2. 在摘要标签页上，查看以下部分中的信息：

   • 检测到的内容，尤其是以下字段：
     • 主账号电子邮件地址：发出调用的账号。
     • 方法名称：所调用的方法。
   • 在受影响的资源下：
     • 资源显示名称：执行操作的 Kubernetes 集群。
   • 相关链接，尤其是以下字段：
     • Cloud Logging URI：指向 Logging 条目的链接。
     • MITRE ATT&CK 方法：指向 MITRE ATT&CK 文档的链接。
     • 相关发现结果：指向任何相关发现结果的链接。

第 2 步：检查日志

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

1. 在 Google Cloud 控制台中发现结果详细信息的摘要标签页上，通过点击 Cloud Logging URI 字段中的链接转到 Logs Explorer。
2. 查看 protoPayload.resourceName 字段中的值以识别特定的证书签名请求。

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

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

Privilege Escalation: Impersonation Role Granted for Dormant Service Account

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

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

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

1. 按照查看发现结果中所述，打开 Privilege Escalation: Impersonation Role Granted for Dormant Service Account 发现结果。

2. 在发现结果详情的摘要标签页上，记下以下字段的值。

   在检测到的内容下：

   • 主账号电子邮件地址：执行授予角色操作的用户
   • 违规访问授权主账号名称：被授予模拟角色的主账号

   在受影响的资源下：

   • 资源显示名称：作为资源的休眠服务账号
   • 项目全名：休眠服务账号所在的项目

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

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

第 3 步：检查日志

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

第 4 步：实现响应

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

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

Privilege Escalation: Launch of privileged Kubernetes container

潜在恶意方已创建一个 Pod，该 Pod 包含特权容器或具有提升权限功能的容器。

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

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

1. 按照查看发现结果中所述，打开 Privilege Escalation: Launch of privileged Kubernetes container 发现结果。 系统会打开发现结果详细信息面板，以显示摘要标签页。

2. 在摘要标签页上，查看以下部分中的信息：

   • 检测到的内容，尤其是以下字段：
     • 主账号电子邮件地址：发出调用的账号。
     • Kubernetes pod：新创建的具有特权容器的 Pod。
   • 受影响的资源，尤其是以下字段：
     • 资源显示名称：执行操作的 Kubernetes 集群。
   • 相关链接，尤其是以下字段：
     • Cloud Logging URI：指向 Logging 条目的链接。
     • MITRE ATT&CK 方法：指向 MITRE ATT&CK 文档的链接。
     • 相关发现结果：指向任何相关发现结果的链接。

3. 在 JSON 标签页上，记下发现结果字段的值：

   • findings.kubernetes.pods[].containers：Pod 中启用的特权容器。

第 2 步：检查日志

1. 在 Google Cloud 控制台中发现结果详细信息的摘要标签页上，通过点击 Cloud Logging URI 字段中的链接转到 Logs Explorer。

2. 使用以下过滤条件检查主账号执行的其他操作：

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     替换以下内容：

   • CLUSTER_NAME：您在发现结果详情的资源显示名称字段中记下的值。

   • PRINCIPAL_EMAIL：您在发现结果详情的主账号电子邮件地址字段中记下的值。

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

1. 查看此发现结果类型的 MITRE ATT&CK 框架条目：提升权限。
2. 确认创建的容器需要访问主机资源和内核功能。
3. 确定日志中是否存在主账号的其他恶意活动迹象。

4. 如果主账号电子邮件地址不是服务账号，请与该账号的所有者联系，以确认合法所有者是否执行了该操作。

   如果主账号电子邮件地址是服务账号（IAM 或 Kubernetes），请查明操作来源以确定其合法性。

5. 如需制定响应方案，请将您的调查结果与 MITRE 研究相结合。

Privilege Escalation: Privileged Group Opened To Public

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

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

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

1. 按照查看发现结果中所述，打开 Privilege Escalation: Privileged Group Opened To Public 发现结果。 系统会打开发现结果详细信息面板，以显示摘要标签页。

2. 在摘要标签页上，查看以下部分中的信息：

   • 检测到的内容，尤其是以下字段：
     • 主账号电子邮件地址：做出更改的账号，该账号可能被盗用。
   • 受影响的资源
   • 相关链接，尤其是以下字段：
     • Cloud Logging URI：指向 Logging 条目的链接。
     • MITRE ATT&CK 方法：指向 MITRE ATT&CK 文档的链接。
     • 相关发现结果：指向任何相关发现结果的链接。
   1. 点击 JSON 标签页。
   2. 在 JSON 中，请注意以下字段。
   • groupName：在其中进行更改的 Google 群组
   • sensitiveRoles：与此群组关联的敏感角色
   • whoCanJoin：群组的可加入性设置

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

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

   转到管理控制台

2. 在导航窗格中，点击目录，然后选择群组。

3. 点击您要查看的群组的名称。

4. 点击访问权限设置，然后在哪些人可以加入群组下查看此群组的可加入性设置。

5. 如有需要，请在下拉菜单中更改可加入性设置。

第 3 步：检查日志

1. 在发现结果详细信息面板的“摘要”标签页上，点击 Cloud Logging URI 链接以打开 Logs Explorer。

2. 如有必要，请选择您的项目。

3. 在加载的页面上，使用以下过滤条件检查日志，了解 Google 群组设置是否发生更改：

   • protoPayload.methodName="google.admin.AdminService.changeGroupSetting"
   • protoPayload.authenticationInfo.principalEmail="principalEmail"

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

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

Privilege Escalation: Sensitive Role Granted To Hybrid Group

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

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

1. 按照查看发现结果中所述，打开 Privilege Escalation: Sensitive Role Granted To Hybrid Group 发现结果。系统会打开发现结果详细信息面板，以显示摘要标签页。

2. 在摘要标签页上，查看以下部分中的信息：

   • 检测到的内容，尤其是以下字段：
     • 主账号电子邮件地址：做出更改的账号，该账号可能被盗用。
   • 受影响的资源，尤其是以下字段：
     • 资源全名：为其授予新角色的资源。
   • 相关链接，尤其是以下字段：
     • Cloud Logging URI：指向 Logging 条目的链接。
     • MITRE ATT&CK 方法：指向 MITRE ATT&CK 文档的链接。
     • 相关发现结果：指向任何相关发现结果的链接。
   1. 点击 JSON 标签页。
   2. 在 JSON 中，请注意以下字段。
   • groupName：在其中进行更改的 Google 群组
   • bindingDeltas：为此群组新授予的敏感角色。

第 2 步：查看群组权限

1. 前往 Google Cloud 控制台中的 IAM 页面。

   转到 IAM

2. 在过滤条件字段中，输入 groupName 中列出的账号名称。

3. 查看为群组授予的敏感角色。

4. 如果不需要新添加的敏感角色，请撤消此角色。

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

第 3 步：检查日志

1. 在发现结果详细信息面板的“摘要”标签页上，点击 Cloud Logging URI 链接以打开 Logs Explorer。

2. 如有必要，请选择您的项目。

3. 在加载的页面上，使用以下过滤条件检查日志，了解 Google 群组设置是否发生更改：

   • protoPayload.methodName="SetIamPolicy"
   • protoPayload.authenticationInfo.principalEmail="principalEmail"

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

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

Privilege Escalation: Suspicious Kubernetes Container Names - Exploitation and Escape

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

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

Privilege Escalation: Workload Created with a Sensitive Host Path Mount

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

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

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

Privilege Escalation: Workload with shareProcessNamespace enabled

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

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

Service account self-investigation

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

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

1. 按照本页面前面部分的查看发现结果详情中所述，打开 Discovery: Service Account Self-Investigation 发现结果。系统会打开发现结果详细信息面板，以显示摘要标签页。

2. 在摘要标签页上，查看以下部分中的信息：

   • 检测到的内容，尤其是以下字段：
     • 严重级别：分配给发现结果的风险级别。如果触发此发现结果的 API 调用未经授权，则严重级别为 HIGH；服务账号无权使用 projects.getIamPolicy API 查询其自己的 IAM 权限。
     • 主账号邮件：可能被盗用的服务账号。
     • 调用方 IP：内部或外部 IP 地址
   • 受影响的资源，尤其是以下字段：
     • 资源全名：
     • 项目全名：包含可能已泄露的账号凭证的项目。
   • 相关链接，尤其是以下字段：
     • Cloud Logging URI：指向 Logging 条目的链接。
     • MITRE ATT&CK 方法：指向 MITRE ATT&CK 文档的链接。
     • 相关发现结果：指向任何相关发现结果的链接。
   1. 如需查看发现结果的完整 JSON，请点击 JSON 标签页。

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

1. 在 Google Cloud 控制台中，前往 IAM 页面。

   转到 IAM

2. 如有必要，请选择发现结果 JSON 的 projectID 字段中列出的项目。

3. 在显示的页面上的过滤条件框中，输入主账号电子邮件地址中列出的账号名称，并检查分配的权限。

4. 在 Google Cloud 控制台中，前往服务账号页面。

   转到“服务账号”

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

第 3 步：检查日志

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

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

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

第 5 步：实现响应

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

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

Compute Engine 管理员元数据检测

Persistence: GCE Admin Added SSH Key

Persistence: GCE Admin Added Startup Script

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，则无法使用此发现结果。

Initial Access: Suspicious Login Blocked

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

Initial Access: Account Disabled Hijacked

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

Impair Defenses: Two Step Verification Disabled

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

Initial Access: Government Based Attack

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

Persistence: SSO Enablement Toggle

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

Persistence: SSO Settings Changed

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

Impair Defenses: Strong Authentication Disabled

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

应对 Google Workspace 威胁

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

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

• 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，然后 Event Threat Detection 会生成威胁发现结果。

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

1. 按照查看发现结果中所述，打开 Cloud IDS: THREAT_ID 发现结果。

2. 在发现结果详细信息中的摘要标签页上，查看以下部分中列出的值：

   • 检测到的内容，尤其是以下字段：
     • 协议：所使用的网络协议
     • 事件时间：事件发生的时间
     • 说明：有关发现结果的更多信息
     • 严重程度：提醒的严重程度
     • 目标 IP：网络流量的目标 IP
     • 目标端口：网络流量的目标端口
     • 来源 IP：网络流量的来源 IP
     • 来源端口：网络流量的来源端口
   • 受影响的资源，尤其是以下字段：
     • 资源全名：包含存在威胁的网络的项目
   • 相关链接，尤其是以下字段：
     • Cloud Logging URI：指向 Cloud IDS Logging 条目的链接 - 这些条目包含搜索 Palo Alto Networks 的 Threat Vault 所需的信息
   • 检测服务
     • 发现结果类别 Cloud IDS 威胁名称

3. 如需查看发现结果的完整 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 步：查看发现结果详情

1. 按照查看发现结果中所述，打开 Added Binary Executed 发现结果。系统会打开发现结果详细信息面板，以显示摘要标签页。

2. 在摘要标签页上，查看以下部分中的信息：

   • 检测到的内容，尤其是以下字段：
     • 程序二进制文件：添加的二进制文件的绝对路径。
     • 参数：调用添加的二进制文件时提供的参数。
   • 受影响的资源，尤其是以下字段：
     • 资源全名：集群的完整资源名称，其中包括项目编号、位置和集群名称。
   • 相关链接，尤其是以下字段：
     • VirusTotal 指示器：指向 VirusTotal 分析页面的链接。

3. 点击 JSON，并注意以下字段：

   • resource：
     • project_display_name：包含集群的项目的名称。
   • sourceProperties：
     • Pod_Namespace：Pod 的 Kubernetes 命名空间的名称。
     • Pod_Name：GKE Pod 的名称。
     • Container_Name：受影响的容器的名称。
     • Container_Image_Uri：要部署的容器映像的名称。
     • VM_Instance_Name：在其中执行 Pod 的 GKE 节点的名称。

4. 识别此容器在相似时间发生的其他发现结果。相关发现结果可能表明此活动是恶意活动，而不是未遵循最佳实践。

第 2 步：查看集群和节点

1. 在 Google Cloud 控制台中，前往 Kubernetes 集群页面。

   转到 KUBERNETES 集群

2. 如有必要，在 Google Cloud 控制台工具栏中选择 resource.project_display_name 中列出的项目。

3. 选择发现结果详情摘要标签页中资源全名行上列出的集群。请记下有关集群及其所有者的所有元数据。

4. 点击节点标签页。选择 VM_Instance_Name 中列出的节点。

5. 点击详细信息标签页，并记下 container.googleapis.com/instance_id 注解。

第 3 步：审核 Pod

1. 在 Google Cloud 控制台中，前往 Kubernetes 工作负载页面。

   转到“Kubernetes 工作负载”

2. 如有必要，在 Google Cloud 控制台工具栏中选择 resource.project_display_name 中列出的项目。

3. 如有必要，对发现结果详情摘要标签页中资源全名行上列出的集群以及 Pod_Namespace 中列出的 Pod 命名空间进行过滤。

4. 选择 Pod_Name 中列出的 Pod。请记下有关 Pod 及其所有者的所有元数据。

第 4 步：检查日志

1. 在 Google Cloud 控制台中，前往 Logs Explorer。

   前往 Logs Explorer

2. 如有必要，在 Google Cloud 控制台工具栏中选择 resource.project_display_name 中列出的项目。

3. 将选择时间范围设置为感兴趣的时间段。

4. 在加载的页面上，执行以下操作：

   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 步：检查正在运行的容器

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

1. 前往 Google Cloud 控制台。

   打开 Google Cloud 控制台

2. 如有必要，在 Google Cloud 控制台工具栏中选择 resource.project_display_name 中列出的项目。

3. 点击激活 Cloud Shell

4. 通过运行以下命令获取集群的 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 中列出的项目名称

5. 运行以下命令来检索添加的二进制文件：

     kubectl cp Pod_Namespace/Pod_Name:Process_Binary_Fullpath -c Container_Name  local_file
   

   将 local_file 替换为本地文件路径，以存储添加的二进制文件。

6. 通过运行以下命令连接到容器环境：

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

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

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

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

第 7 步：实现响应

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

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

Added Library Loaded

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

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

1. 按照查看发现结果中所述，打开 Added Library Loaded 发现结果。系统会打开发现结果详细信息面板，以显示摘要标签页。

2. 在摘要标签页上，查看以下部分中的信息：

   • 检测到的内容，尤其是以下字段：
     • 程序二进制文件：加载库的进程二进制文件的完整路径。
     • 库：有关添加的库的详细信息。
     • 参数：调用进程二进制文件时提供的参数。
   • 受影响的资源，尤其是以下字段：
     • 资源全名：集群的完整资源名称。
   • 相关链接，尤其是以下字段：
     • VirusTotal 指示器：指向 VirusTotal 分析页面的链接。

3. 点击 JSON 标签页并注意以下字段：

   • resource：
     • project_display_name：包含资产的项目的名称。
   • sourceProperties：
     • Pod_Namespace：Pod 的 Kubernetes 命名空间的名称。
     • Pod_Name：GKE Pod 的名称。
     • Container_Name：受影响的容器的名称。
     • Container_Image_Uri：要执行的容器映像的名称。
     • VM_Instance_Name：在其中执行 Pod 的 GKE 节点的名称。

4. 识别此容器在相似时间发生的其他发现结果。相关发现结果可能表明此活动是恶意活动，而不是未遵循最佳实践。

第 2 步：查看集群和节点

1. 在 Google Cloud 控制台中，前往 Kubernetes 集群页面。

   转到 KUBERNETES 集群

2. 如有必要，在 Google Cloud 控制台工具栏中选择 resource.project_display_name 中列出的项目。

3. 选择 resource.name 中列出的集群。请记下有关集群及其所有者的所有元数据。

4. 点击节点标签页。选择 VM_Instance_Name 中列出的节点。

5. 点击详细信息标签页，并记下 container.googleapis.com/instance_id 注解。

第 3 步：审核 Pod

1. 在 Google Cloud 控制台中，前往 Kubernetes 工作负载页面。

   转到“Kubernetes 工作负载”

2. 如有必要，在 Google Cloud 控制台工具栏中选择 resource.project_display_name 中列出的项目。

3. 如有必要，对发现结果详情摘要标签页中资源全名行上列出的集群以及 Pod_Namespace 中列出的 Pod 命名空间进行过滤。

4. 选择 Pod_Name 中列出的 Pod。请记下有关 Pod 及其所有者的所有元数据。

第 4 步：检查日志

1. 在 Google Cloud 控制台中，前往 Logs Explorer。

   前往 Logs Explorer

2. 如有必要，在 Google Cloud 控制台工具栏中选择 resource.project_display_name 中列出的项目。

3. 将选择时间范围设置为感兴趣的时间段。

4. 在加载的页面上，执行以下操作：

   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 步：检查正在运行的容器

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

1. 前往 Google Cloud 控制台。

   打开 Google Cloud 控制台

2. 如有必要，在 Google Cloud 控制台工具栏中选择 resource.project_display_name 中列出的项目。

3. 点击激活 Cloud Shell。

4. 通过运行以下命令获取集群的 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
   

5. 运行以下命令来检索添加的库：

     kubectl cp Pod_Namespace/Pod_Name: Added_Library_Fullpath -c Container_Name  local_file
   

   将 local_file 替换为本地文件路径，以存储添加的库。

6. 通过运行以下命令连接到容器环境：

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

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

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

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

第 7 步：实现响应

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

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

Command and Control: Steganography Tool Detected

检测到一个进程利用了类似 Unix 的发行版中常见的信息隐写工具来潜在隐藏通信。这种行为表明，攻击者试图在与外部实体交换的看似无害的数字消息中隐藏命令和控制 (C2) 流量或敏感数据。攻击者通常会使用信息隐写来逃避网络监控，并使恶意活动不那么引人注目。这些工具的存在表明，有人故意试图混淆非法数据传输。此行为可能会导致敏感信息进一步遭入侵或渗漏。识别隐藏的内容对于准确评估涉及的风险至关重要。

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

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

1. 按照查看发现结果中所述，打开 Command and Control: Steganography Tool Detected 发现结果。系统会打开发现结果详细信息面板，以显示摘要标签页。

2. 在摘要标签页上，查看以下部分中的信息：

   • 检测到的内容，尤其是以下字段：
     • 程序二进制文件：所执行二进制文件的绝对路径。
     • 参数：二进制文件执行期间传递的参数。
   • 受影响的资源，尤其是以下字段：
     • 资源全名：集群的完整资源名称，其中包括项目编号、位置和集群名称。

3. 在发现结果的详情视图中，点击 JSON 标签页。

4. 在 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 节点的名称。

5. 识别此容器在相似时间发生的其他发现结果。 相关发现结果可能表明此活动是恶意活动，而不是未遵循最佳实践。

第 2 步：查看集群和节点

1. 在 Google Cloud 控制台中，前往 Kubernetes 集群页面。

   前往 Kubernetes 集群

2. 如有必要，在 Google Cloud 控制台工具栏中选择 resource.project_display_name 中列出的项目。

3. 选择发现结果详细信息摘要标签页中资源全名行上列出的集群。请记下有关集群及其所有者的所有元数据。

4. 点击节点标签页。选择 VM_Instance_Name 中列出的节点。

5. 点击详细信息标签页，并记下 container.googleapis.com/instance_id 注解。

第 3 步：审核 Pod

1. 在 Google Cloud 控制台中，前往 Kubernetes 工作负载页面。

   前往 Kubernetes 工作负载

2. 如有必要，在 Google Cloud 控制台工具栏中选择 resource.project_display_name 中列出的项目。

3. 如有必要，对发现结果详细信息摘要标签页中资源全名行上列出的集群以及 Pod_Namespace 中列出的 Pod 命名空间进行过滤。

4. 选择 Pod_Name 中列出的 Pod。请记下有关 Pod 及其所有者的所有元数据。

第 4 步：检查日志

1. 在 Google Cloud 控制台中，前往 Logs Explorer。

   前往 Logs Explorer

2. 如有必要，在 Google Cloud 控制台工具栏中选择 resource.project_display_name 中列出的项目。

3. 将选择时间范围设置为感兴趣的时间段。

4. 在加载的页面上，执行以下操作：

   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 步：检查正在运行的容器

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

1. 前往 Google Cloud 控制台。

   打开 Google Cloud 控制台

2. 如有必要，在 Google Cloud 控制台工具栏中选择 resource.project_display_name 中列出的项目。

3. 点击激活 Cloud Shell

4. 通过运行以下命令获取集群的 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 中列出的项目名称

5. 检索已执行的二进制文件：

   kubectl cp \
         POD_NAMESPACE/POD_NAME:PROCESS_BINARY_FULLPATH \
         -c CONTAINER_NAME \
         LOCAL_FILE
   

   将 local_file 替换为本地文件路径，以存储添加的二进制文件。

6. 通过运行以下命令连接到容器环境：

   kubectl exec \
         --namespace=POD_NAMESPACE \
         -ti POD_NAME \
         -c CONTAINER_NAME \
         -- /bin/sh
   

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

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

1. 查看此发现结果类型的 MITRE ATT&CK 框架条目：数据混淆：信息隐写。
2. 如需制定响应方案，请将您的调查结果与 MITRE 研究相结合。

第 7 步：实现响应

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

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

Credential Access: Find Google Cloud Credentials

检测到某个进程正在搜索 Google Cloud 凭证。此行为表明有人试图找到并提取存储的 Secret，这些 Secret 可用于提升特权、访问受限资源或在环境中横向移动。攻击者经常扫描凭证，以便获得对云资源的未经授权的访问权限，从而提升特权或执行恶意行为。

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

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

1. 按照查看发现结果中所述，打开 Credential Access: Find Google Cloud Credentials 发现结果。系统会打开发现结果详细信息面板，以显示摘要标签页。

2. 在摘要标签页上，查看以下部分中的信息：

   • 检测到的内容，尤其是以下字段：
     • 程序二进制文件：所执行二进制文件的绝对路径。
     • 参数：二进制文件执行期间传递的参数。
   • 受影响的资源，尤其是以下字段：
     • 资源全名：集群的完整资源名称，其中包括项目编号、位置和集群名称。

3. 在发现结果的详情视图中，点击 JSON 标签页。

4. 在 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 节点的名称。

5. 识别此容器在相似时间发生的其他发现结果。 相关发现结果可能表明此活动是恶意活动，而不是未遵循最佳实践。

第 2 步：查看集群和节点

1. 在 Google Cloud 控制台中，前往 Kubernetes 集群页面。

   前往 Kubernetes 集群

2. 如有必要，在 Google Cloud 控制台工具栏中选择 resource.project_display_name 中列出的项目。

3. 选择发现结果详细信息摘要标签页中资源全名行上列出的集群。请记下有关集群及其所有者的所有元数据。

4. 点击节点标签页。选择 VM_Instance_Name 中列出的节点。

5. 点击详细信息标签页，并记下 container.googleapis.com/instance_id 注解。

第 3 步：审核 Pod

1. 在 Google Cloud 控制台中，前往 Kubernetes 工作负载页面。

   前往 Kubernetes 工作负载

2. 如有必要，在 Google Cloud 控制台工具栏中选择 resource.project_display_name 中列出的项目。

3. 如有必要，对发现结果详细信息摘要标签页中资源全名行上列出的集群以及 Pod_Namespace 中列出的 Pod 命名空间进行过滤。

4. 选择 Pod_Name 中列出的 Pod。请记下有关 Pod 及其所有者的所有元数据。

第 4 步：检查日志

1. 在 Google Cloud 控制台中，前往 Logs Explorer。

   前往 Logs Explorer

2. 如有必要，在 Google Cloud 控制台工具栏中选择 resource.project_display_name 中列出的项目。

3. 将选择时间范围设置为感兴趣的时间段。

4. 在加载的页面上，执行以下操作：

   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 步：检查正在运行的容器

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

1. 前往 Google Cloud 控制台。

   打开 Google Cloud 控制台

2. 如有必要，在 Google Cloud 控制台工具栏中选择 resource.project_display_name 中列出的项目。

3. 点击激活 Cloud Shell

4. 通过运行以下命令获取集群的 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 中列出的项目名称

5. 通过运行以下命令连接到容器环境：

   kubectl exec \
         --namespace=POD_NAMESPACE \
         -ti POD_NAME \
         -c CONTAINER_NAME \
         -- /bin/sh
   

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

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

1. 查看此发现结果类型的 MITRE ATT&CK 框架条目：不安全的凭证：私钥。
2. 如需制定响应方案，请将您的调查结果与 MITRE 研究相结合。

第 7 步：实现响应

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

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

Credential Access: GPG Key Reconnaissance

检测到一个进程正在搜索 GPG 密钥。此行为表明有人试图找到并提取存储的安全密钥，这些密钥用于对文档进行加密和解密，并与数字签名搭配使用对文档进行身份验证。攻击者使用安全密钥未经授权访问关键信息和系统，因此这是需要立即进行调查的高严重程度的检测。

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

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

1. 按照查看发现结果中所述，打开 Credential Access: GPG Key Reconnaissance 发现结果。系统会打开发现结果详细信息面板，以显示摘要标签页。

2. 在摘要标签页上，查看以下部分中的信息：

   • 检测到的内容，尤其是以下字段：
     • 程序二进制文件：所执行二进制文件的绝对路径。
     • 参数：二进制文件执行期间传递的参数。
   • 受影响的资源，尤其是以下字段：
     • 资源全名：集群的完整资源名称，其中包括项目编号、位置和集群名称。

3. 在发现结果的详情视图中，点击 JSON 标签页。

4. 在 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 节点的名称。

5. 识别此容器在相似时间发生的其他发现结果。 相关发现结果可能表明此活动是恶意活动，而不是未遵循最佳实践。

第 2 步：查看集群和节点

1. 在 Google Cloud 控制台中，前往 Kubernetes 集群页面。

   前往 Kubernetes 集群

2. 如有必要，在 Google Cloud 控制台工具栏中选择 resource.project_display_name 中列出的项目。

3. 选择发现结果详细信息摘要标签页中资源全名行上列出的集群。请记下有关集群及其所有者的所有元数据。

4. 点击节点标签页。选择 VM_Instance_Name 中列出的节点。

5. 点击详细信息标签页，并记下 container.googleapis.com/instance_id 注解。

第 3 步：审核 Pod

1. 在 Google Cloud 控制台中，前往 Kubernetes 工作负载页面。

   前往 Kubernetes 工作负载

2. 如有必要，在 Google Cloud 控制台工具栏中选择 resource.project_display_name 中列出的项目。

3. 如有必要，对发现结果详细信息摘要标签页中资源全名行上列出的集群以及 Pod_Namespace 中列出的 Pod 命名空间进行过滤。

4. 选择 Pod_Name 中列出的 Pod。请记下有关 Pod 及其所有者的所有元数据。

第 4 步：检查日志

1. 在 Google Cloud 控制台中，前往 Logs Explorer。

   前往 Logs Explorer

2. 如有必要，在 Google Cloud 控制台工具栏中选择 resource.project_display_name 中列出的项目。

3. 将选择时间范围设置为感兴趣的时间段。

4. 在加载的页面上，执行以下操作：

   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 步：检查正在运行的容器

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

1. 前往 Google Cloud 控制台。

   打开 Google Cloud 控制台

2. 如有必要，在 Google Cloud 控制台工具栏中选择 resource.project_display_name 中列出的项目。

3. 点击激活 Cloud Shell

4. 通过运行以下命令获取集群的 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 中列出的项目名称

5. 通过运行以下命令连接到容器环境：

   kubectl exec \
         --namespace=POD_NAMESPACE \
         -ti POD_NAME \
         -c CONTAINER_NAME \
         -- /bin/sh
   

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

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

1. 查看此发现结果类型的 MITRE ATT&CK 框架条目：不安全的凭证：私钥。
2. 如需制定响应方案，请将您的调查结果与 MITRE 研究相结合。

第 7 步：实现响应

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

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

Credential Access: Search Private Keys or Passwords

检测到一个进程在容器中搜索私钥、凭证或其他敏感的身份验证信息。此行为表明有人试图找到并提取存储的 Secret，这些 Secret 可用于提升特权、访问受限资源或在环境中横向移动。攻击者经常扫描 SSH 密钥、API 令牌或数据库凭证，以便未经授权访问关键系统，因此这是一种高严重程度的检测，需要立即进行调查。

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

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

1. 按照查看发现结果中所述，打开 Credential Access: Search Private Keys or Passwords 发现结果。系统会打开发现结果详细信息面板，以显示摘要标签页。

2. 在摘要标签页上，查看以下部分中的信息：

   • 检测到的内容，尤其是以下字段：
     • 程序二进制文件：所执行二进制文件的绝对路径。
     • 参数：二进制文件执行期间传递的参数。
   • 受影响的资源，尤其是以下字段：
     • 资源全名：集群的完整资源名称，其中包括项目编号、位置和集群名称。

3. 在发现结果的详情视图中，点击 JSON 标签页。

4. 在 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 节点的名称。

5. 识别此容器在相似时间发生的其他发现结果。 相关发现结果可能表明此活动是恶意活动，而不是未遵循最佳实践。

第 2 步：查看集群和节点

1. 在 Google Cloud 控制台中，前往 Kubernetes 集群页面。

   前往 Kubernetes 集群

2. 如有必要，在 Google Cloud 控制台工具栏中选择 resource.project_display_name 中列出的项目。

3. 选择发现结果详细信息摘要标签页中资源全名行上列出的集群。请记下有关集群及其所有者的所有元数据。

4. 点击节点标签页。选择 VM_Instance_Name 中列出的节点。

5. 点击详细信息标签页，并记下 container.googleapis.com/instance_id 注解。

第 3 步：审核 Pod

1. 在 Google Cloud 控制台中，前往 Kubernetes 工作负载页面。

   前往 Kubernetes 工作负载

2. 如有必要，在 Google Cloud 控制台工具栏中选择 resource.project_display_name 中列出的项目。

3. 如有必要，对发现结果详细信息摘要标签页中资源全名行上列出的集群以及 Pod_Namespace 中列出的 Pod 命名空间进行过滤。

4. 选择 Pod_Name 中列出的 Pod。请记下有关 Pod 及其所有者的所有元数据。

第 4 步：检查日志

1. 在 Google Cloud 控制台中，前往 Logs Explorer。

   前往 Logs Explorer

2. 如有必要，在 Google Cloud 控制台工具栏中选择 resource.project_display_name 中列出的项目。

3. 将选择时间范围设置为感兴趣的时间段。

4. 在加载的页面上，执行以下操作：

   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 步：检查正在运行的容器

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

1. 前往 Google Cloud 控制台。

   打开 Google Cloud 控制台

2. 如有必要，在 Google Cloud 控制台工具栏中选择 resource.project_display_name 中列出的项目。

3. 点击激活 Cloud Shell

4. 通过运行以下命令获取集群的 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 中列出的项目名称

5. 检索已执行的二进制文件：

   kubectl cp \
         POD_NAMESPACE/POD_NAME:PROCESS_BINARY_FULLPATH \
         -c CONTAINER_NAME \
         LOCAL_FILE
   

   将 local_file 替换为本地文件路径，以存储添加的二进制文件。

6. 通过运行以下命令连接到容器环境：

   kubectl exec \
         --namespace=POD_NAMESPACE \
         -ti POD_NAME \
         -c CONTAINER_NAME \
         -- /bin/sh
   

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

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

1. 查看此发现结果类型的 MITRE ATT&CK 框架条目：不安全的凭证：文件中的凭证。
2. 如需制定响应方案，请将您的调查结果与 MITRE 研究相结合。

第 7 步：实现响应

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

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

Defense Evasion: Base64 ELF File Command Line

执行了一个进程，其中包含一个 ELF（可执行和可链接格式）文件的参数。如果检测到执行经过编码的 ELF 文件，则表示攻击者正尝试对二进制数据进行编码，以便将其传输到仅限 ASCII 的命令行。攻击者可以使用此技术来逃避检测并运行嵌入 ELF 文件中的恶意代码。

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

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

1. 按照查看发现结果中所述，打开 Defense Evasion: Base64 ELF File Command Line 发现结果。系统会打开发现结果详细信息面板，以显示摘要标签页。

2. 在摘要标签页上，查看以下部分中的信息：

   • 检测到的内容，尤其是以下字段：
     • 程序二进制文件：所执行二进制文件的绝对路径。
     • 参数：二进制文件执行期间传递的参数。
   • 受影响的资源，尤其是以下字段：
     • 资源全名：集群的完整资源名称，其中包括项目编号、位置和集群名称。

3. 在发现结果的详情视图中，点击 JSON 标签页。

4. 在 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 节点的名称。

5. 识别此容器在相似时间发生的其他发现结果。 相关发现结果可能表明此活动是恶意活动，而不是未遵循最佳实践。

第 2 步：查看集群和节点

1. 在 Google Cloud 控制台中，前往 Kubernetes 集群页面。

   前往 Kubernetes 集群

2. 如有必要，在 Google Cloud 控制台工具栏中选择 resource.project_display_name 中列出的项目。

3. 选择发现结果详细信息摘要标签页中资源全名行上列出的集群。请记下有关集群及其所有者的所有元数据。

4. 点击节点标签页。选择 VM_Instance_Name 中列出的节点。

5. 点击详细信息标签页，并记下 container.googleapis.com/instance_id 注解。

第 3 步：审核 Pod

1. 在 Google Cloud 控制台中，前往 Kubernetes 工作负载页面。

   前往 Kubernetes 工作负载

2. 如有必要，在 Google Cloud 控制台工具栏中选择 resource.project_display_name 中列出的项目。

3. 如有必要，对发现结果详细信息摘要标签页中资源全名行上列出的集群以及 Pod_Namespace 中列出的 Pod 命名空间进行过滤。

4. 选择 Pod_Name 中列出的 Pod。请记下有关 Pod 及其所有者的所有元数据。

第 4 步：检查日志

1. 在 Google Cloud 控制台中，前往 Logs Explorer。

   前往 Logs Explorer

2. 如有必要，在 Google Cloud 控制台工具栏中选择 resource.project_display_name 中列出的项目。

3. 将选择时间范围设置为感兴趣的时间段。

4. 在加载的页面上，执行以下操作：

   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 步：检查正在运行的容器

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

1. 前往 Google Cloud 控制台。

   打开 Google Cloud 控制台

2. 如有必要，在 Google Cloud 控制台工具栏中选择 resource.project_display_name 中列出的项目。

3. 点击激活 Cloud Shell

4. 通过运行以下命令获取集群的 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 中列出的项目名称

5. 检索已执行的二进制文件：

   kubectl cp \
         POD_NAMESPACE/POD_NAME:PROCESS_BINARY_FULLPATH \
         -c CONTAINER_NAME \
         LOCAL_FILE
   

   将 local_file 替换为本地文件路径，以存储添加的二进制文件。

6. 通过运行以下命令连接到容器环境：

   kubectl exec \
         --namespace=POD_NAMESPACE \
         -ti POD_NAME \
         -c CONTAINER_NAME \
         -- /bin/sh
   

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