本主题提供了一些非正式指导信息,以帮助您调查和应对威胁,并利用其他资源为 Security Command Center 的发现添加上下文。按照这些步骤操作有助于了解潜在攻击期间发生的情况,并为受影响的资源制定可行的响应措施。
本页面上中的技术不能保证对您之前、当前或未来面对的所有威胁有效。请参阅修复威胁,了解 Security Command Center 不针对威胁提供正式修复指导的原因。
准备工作
您需要具有足够的 Identity and Access Management (IAM) 角色才能查看或修改发现结果和日志以及修改 Google Cloud 资源。如果您在 Security Command Center 中遇到访问权限错误,请向您的管理员寻求帮助,并参阅访问权限控制以了解角色。如需解决资源错误,请参阅受影响产品的相关文档。
了解威胁发现结果
事件威胁检测 通过匹配 Cloud Logging 日志中的事件来生成安全发现结果 流式传输到已知的威胁指标 (IoC)。由内部 Google 安全来源开发的 IoC 可发现潜在漏洞和攻击。事件威胁检测还通过识别已知的对手来检测威胁 记录流中的战术、技术和程序,并检测 与组织或项目过往行为之间的差异。如果您在组织级层激活 Security Command Center 高级层级,Event Threat Detection 还可以扫描您的 Google Workspace 日志。
容器威胁检测 通过收集并分析在 AI 环境中观察到的低水平行为, 容器的客机内核。
发现结果会被写入 Security Command Center。如果您在组织级层激活 Security Command Center 高级层级,还可以将发现结果配置为写入 Cloud Logging。
审核发现结果
如需在 Google Cloud 控制台中查看威胁发现结果,请按以下步骤操作:
在 Google Cloud 控制台中,转到 Security Command Center 发现结果页面。
如有必要,请选择您的 Google Cloud 项目、文件夹或组织。
在快速过滤条件部分中,点击相应的过滤条件,以在发现结果的查询结果表中显示所需的发现结果。例如,如果您在来源显示名称子部分中选择 Event Threat Detection 或 Container Threat Detection,则结果中只会显示来自所选服务的发现结果。
该表会填充所选择来源的发现结果。
如需查看特定发现结果的详细信息,请点击
Category
下的发现结果名称。发现结果详情窗格会展开,以显示发现结果的详情摘要。要查看发现结果的 JSON 定义,请点击 JSON 标签页。
发现结果提供了突发事件中包含的资源的名称和数字标识符,以及环境变量和资源属性。您可以使用此信息快速隔离受影响的资源并确定事件的潜在范围。
为了帮助您进行调查,威胁发现结果还包含指向以下外部资源的链接:
- MITRE ATT&CK 框架条目。该框架解释了针对云资源的攻击伎俩,并提供修复指南。
- VirusTotal,一项 Alphabet 自有服务,提供了有关潜在恶意文件、网址、网域和 IP 地址的上下文。
以下部分概述了针对威胁发现结果的潜在响应。
停用威胁发现结果
解决触发威胁发现结果的问题后,Security Command Center 不会自动将发现结果的状态设置为 INACTIVE
。除非您手动将 state
属性设置为 INACTIVE
,否则威胁发现结果的状态会保留为 ACTIVE
。
对于假正例,请考虑将发现结果的状态保留为 ACTIVE
,而不是忽略发现结果。
对于持久或重复的假正例,请创建忽略规则。设置忽略规则可以减少需要管理的发现结果数量,从而可以更轻松地识别真正的威胁。
对于真正的威胁,请在将发现结果的状态设置为 INACTIVE
之前,消除威胁,并完成对检测到的威胁、入侵范围以及任何其他相关发现结果和问题的全面调查。
如需忽略发现结果或更改发现结果的状态,请参阅以下主题:
Event Threat Detection 响应
如需详细了解 Event Threat Detection,请参阅 Event Threat Detection 的工作原理。
本部分不包含由 Event Threat Detection 的自定义模块生成的发现结果的响应,因为您的组织定义了这些检测器的建议操作。
Evasion: Access from Anonymizing Proxy
通过检查源自匿名代理 IP 地址(例如 Tor IP 地址)的 Google Cloud 服务修改的 Cloud Audit Logs,检测匿名代理的异常访问。
如需响应这些发现结果,请执行以下操作:
第 1 步:查看发现结果详情
- 按照查看发现结果中所述,打开
Evasion: Access from Anonymizing Proxy
发现结果。系统会打开发现结果详情面板,其中显示了摘要标签页。 在发现结果详情面板的摘要标签页上,查看以下部分中列出的值:
- 检测到的内容,尤其是以下字段:
- 主账号电子邮件地址:做出更改的账号(可能被盗用的账号)。
- IP:从其中执行更改的代理 IP 地址。
- 受影响的资源
- 相关链接,尤其是以下字段:
- Cloud Logging URI:指向 Logging 条目的链接。
- MITRE ATT&CK 方法:指向 MITRE ATT&CK 文档的链接。
- 相关发现结果:指向任何相关发现结果的链接。
- 检测到的内容,尤其是以下字段:
(可选)点击 JSON 标签页以查看其他发现结果字段。
第 2 步:研究攻击和响应方法
- 查看此发现结果类型的 MITRE ATT&CK 框架条目:代理:多级代理。
- 在
principalEmail
字段中与账号所有者联系。确认该操作是否由合法所有者执行。 - 如需制定响应方案,请将您的调查结果与 MITRE 研究相结合。
Defense Evasion: Breakglass Workload Deployment Created
通过检查 Cloud Audit Logs 来确认是否有任何工作负载部署使用 Breakglass 标志覆盖 Binary Authorization 控制时,检测到 Breakglass Workload Deployment Created
。
如需响应此发现结果,请执行以下操作:
第 1 步:查看发现结果详情
- 按照查看发现结果中所述,打开
Defense Evasion: Breakglass Workload Deployment Created
发现结果。系统会打开发现结果详情面板,其中显示了摘要标签页。 在摘要标签页上,查看以下部分中的信息:
- 检测到的内容,尤其是以下字段:
- 主账号电子邮件地址:执行修改操作的账号。
- 方法名称:所调用的方法。
- Kubernetes Pod:Pod 名称和命名空间。
- 受影响的资源,尤其是以下字段:
- 资源显示名称:部署所属的 GKE 命名空间。
- 相关链接:
- Cloud Logging URI:指向 Logging 条目的链接。
- MITRE ATT&CK 方法:指向 MITRE ATT&CK 文档的链接。
- 相关发现结果:指向任何相关发现结果的链接。
- 检测到的内容,尤其是以下字段:
第 2 步:检查日志
- 在 Google Cloud 控制台中发现结果详情的摘要标签页上,通过点击 Cloud Logging URI 字段中的链接转到日志浏览器。
- 查看
protoPayload.resourceName
字段中的值以识别特定的证书签名请求。 使用以下过滤条件检查主账号执行的其他操作:
resource.labels.cluster_name="CLUSTER_NAME"
protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"
请替换以下内容:
CLUSTER_NAME
:您在发现结果详情的资源显示名称字段中记下的值。PRINCIPAL_EMAIL
:您在发现结果详情的主账号电子邮件地址字段中记下的值。
第 3 步:研究攻击和响应方法
- 查看此发现结果类型的 MITRE ATT&CK 框架条目: 防护规避:工作负载部署 Breakglass。
- 点击发现结果详情摘要标签页中相关发现结果行上的相关发现结果的链接,以查看相关发现结果。
- 如需制定响应方案,请将您的调查结果与 MITRE 研究相结合。
Defense Evasion: Breakglass Workload Deployment Updated
通过检查 Cloud Audit Logs 来确认是否有任何工作负载更新使用 Breakglass 标志覆盖 Binary Authorization 控制时,检测到 Breakglass Workload Deployment Updated
。
如需响应此发现结果,请执行以下操作:
第 1 步:查看发现结果详情
- 按照查看发现结果中所述,打开
Defense Evasion: Breakglass Workload Deployment Updated
发现结果。系统会打开发现结果详情面板,其中显示了摘要标签页。 在摘要标签页上,查看以下部分中的信息:
- 检测到的内容,尤其是以下字段:
- 主账号电子邮件地址:执行修改操作的账号。
- 方法名称:所调用的方法。
- Kubernetes Pod:Pod 名称和命名空间。
- 受影响的资源,尤其是以下字段:
- 资源显示名称:更新所属的 GKE 命名空间。
- 相关链接:
- Cloud Logging URI:指向 Logging 条目的链接。
- MITRE ATT&CK 方法:指向 MITRE ATT&CK 文档的链接。
- 相关发现结果:指向任何相关发现结果的链接。
- 检测到的内容,尤其是以下字段:
第 2 步:检查日志
- 在 Google Cloud 控制台中发现结果详情的摘要标签页上,通过点击 Cloud Logging URI 字段中的链接转到日志浏览器。
- 查看
protoPayload.resourceName
字段中的值以识别特定的证书签名请求。 使用以下过滤条件检查主账号执行的其他操作:
resource.labels.cluster_name="CLUSTER_NAME"
protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"
请替换以下内容:
CLUSTER_NAME
:您在发现结果详情的资源显示名称字段中记下的值。PRINCIPAL_EMAIL
:您在发现结果详情的主账号电子邮件地址字段中记下的值。
第 3 步:研究攻击和响应方法
- 查看此发现结果类型的 MITRE ATT&CK 框架条目: 防护规避:工作负载部署 Breakglass。
- 点击发现结果详情摘要标签页中相关发现结果行上的相关发现结果的链接,以查看相关发现结果。
- 如需制定响应方案,请将您的调查结果与 MITRE 研究相结合。
Defense Evasion: Manually Deleted Certificate Signing Request (CSR)
有人手动删除了证书签名请求 (CSR)。垃圾回收控制器会自动移除 CSR,但恶意行为者可能会手动删除 CSR 以逃避检测。如果已删除的 CSR 对应的是已获批准并已签发的证书,那么潜在恶意方现在可以使用另一种身份验证方法来访问集群。与证书关联的权限因包含的主题而异,但可能具有很高的权限。Kubernetes 不支持证书 撤消。如需了解详情,请参阅此提醒的日志消息。
- 查看 Cloud Logging 中的审核日志以及其他提醒,
与此 CSR 相关的事件,以确定 CSR 是否为
approved
,以及 主账号的 CSR 创建活动符合预期。 - 确定 Cloud Logging 的审核日志中是否存在主账号执行的其他恶意活动迹象。例如:
- 删除 CSR 的主账号是否与创建或批准 CSR 的主账号不同?
- 主账号是否尝试过请求、创建、批准或删除其他 CSR?
- 如果 CSR 审批不在预期之内,或者被认定为是恶意的,集群将需要进行凭据变换以使证书失效。请查看相关指南以了解如何执行集群凭据轮替。
Defense Evasion: Modify VPC Service Control
此发现结果不适用于项目级激活。
系统会检查审核日志,以检测 VPC Service Controls 边界上会导致该边界提供的保护减少的更改。下面列出了一些示例:
如需响应此发现结果,请执行以下操作:
第 1 步:查看发现结果详情
- 按照查看发现结果中所述,打开
Defense Evasion: Modify VPC Service Control
发现结果。系统会打开发现结果详情面板,其中显示了摘要标签页。 在摘要标签页上,查看以下部分中的信息:
- 检测到的内容,尤其是以下字段:
- 主账号电子邮件地址:执行修改操作的账号。
- 受影响的资源,尤其是以下字段:
- 资源全名:修改的 VPC Service Controls 边界的名称。
- 相关链接:
- Cloud Logging URI:指向 Logging 条目的链接。
- MITRE ATT&CK 方法:指向 MITRE ATT&CK 文档的链接。
- 相关发现结果:指向任何相关发现结果的链接。
- 检测到的内容,尤其是以下字段:
点击 JSON 标签页。
在 JSON 中,记下以下字段。
sourceProperties
properties
name
:被修改的 VPC Service Controls 边界的名称policyLink
:用于控制该边界的访问权限政策的链接delta
:对边界做出的减少其保护的更改(REMOVE
或ADD
)restricted_resources
:遵循此边界限制的项目。如果您移除某个项目,则所受保护会减少restricted_services
:被此边界限制禁止运行的服务。如果您移除某个受限服务,则所受保护会减少allowed_services
:根据此边界限制允许运行的服务。如果您添加某个允许的服务,则所受保护会减少access_levels
:配置为允许访问边界下资源的访问权限级别。如果您添加更多访问权限级别,则所受保护会减少
第 2 步:检查日志
- 在发现结果详情面板的“摘要”标签页上,点击 Cloud Logging URI 链接以打开日志浏览器。
- 使用以下过滤条件查找与 VPC Service Controls 更改相关的管理员活动日志:
protoPayload.methodName:"AccessContextManager.UpdateServicePerimeter"
protoPayload.methodName:"AccessContextManager.ReplaceServicePerimeters"
第 3 步:研究攻击和响应方法
- 查看此发现结果类型的 MITRE ATT&CK 框架条目: 防护规避:修改身份验证过程。
- 点击发现结果详情摘要标签页中相关发现结果行上的相关发现结果的链接,以查看相关发现结果。
- 如需制定响应方案,请将您的调查结果与 MITRE 研究相结合。
第 4 步:实现响应
以下响应方案可能适合此发现结果,但也可能会影响运营。请仔细评估您在研究中收集的信息,以确定解析发现结果的最佳方法。
- 联系 VPC Service Controls 政策和边界的所有者。
- 请考虑还原对边界所做的更改,直到调查完成。
- 请考虑撤消对边界做出修改的主账号上的 Access Context Manager 角色,直到调查完成。
- 调查减少的保护措施的使用方式。例如,如果启用了“BigQuery Data Transfer Service API”或将其添加为允许的服务,请检查最开始使用该服务的用户及其转移的内容。
Defense Evasion: Potential Kubernetes Pod Masquerading
有人部署了一个 Pod,其命名惯例与 GKE 为常规集群操作创建的默认工作负载类似。这种技术称为“伪装”。如需了解详情,请参阅此提醒的日志消息。
- 确认 Pod 是合法的。
- 确定是否存在来自 Pod 的其他恶意活动迹象,或 主账号。
- 如果主账号不是服务账号(IAM 或 Kubernetes),请与该账号的所有者联系,以确认合法所有者是否执行了相应操作。
- 如果主账号是服务账号(IAM 或 Kubernetes),请查明操作来源以确定其合法性。
- 如果 Pod 不合法,请移除它以及所有关联的 RBAC 绑定和服务账号,以及 创建过程。
Discovery: Can get sensitive Kubernetes object check
潜在恶意操作者尝试使用 kubectl
auth can-i get
命令确定可以查询 GKE 中的哪些敏感对象。具体来说,操作者运行了以下任何命令:
kubectl auth can-i get '*'
kubectl auth can-i get secrets
kubectl auth can-i get clusterroles/cluster-admin
第 1 步:查看发现结果详情
- 按照查看发现结果中所述,打开
Discovery: Can get sensitive Kubernetes object check
发现结果。 在发现结果详情的摘要标签页上,记下以下字段的值:
- 在检测到的内容下:
- Kubernetes 访问权限审核:基于
SelfSubjectAccessReview
k8s 资源的请求访问权限审核信息。 - 主账号电子邮件地址:发出调用的账号。
- Kubernetes 访问权限审核:基于
- 在受影响的资源下:
- 资源显示名称:执行操作的 Kubernetes 集群。
- 在相关链接下:
- Cloud Logging URI:指向 Logging 条目的链接。
- 在检测到的内容下:
第 2 步:检查日志
- 在发现结果详情面板的“摘要”标签页上,点击 Cloud Logging URI 链接以打开日志浏览器。
在加载的页面上,使用以下过滤条件检查主账号执行的其他操作:
resource.labels.cluster_name="CLUSTER_NAME"
protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"
请替换以下内容:
CLUSTER_NAME
:您在发现结果详情的资源显示名称字段中记下的值。PRINCIPAL_EMAIL
:您在发现结果详情的主账号电子邮件地址字段中记下的值。
第 3 步:研究攻击和响应方法
- 查看以下发现结果类型的 MITRE ATT&CK 框架条目: 发现广告系列
- 确认所查询对象的敏感度,并确定日志中是否存在主账号执行的其他恶意活动迹象。
如果您在发现结果详情的主账号电子邮件地址行中记下的账号不是服务账号,请与该账号所有者联系以确认合法所有者是否执行了该操作。
如果主账号电子邮件地址是服务账号(IAM 或 Kubernetes),请查明访问权限审核的来源以确定其合法性。
如需制定响应方案,请将您的调查结果与 MITRE 研究相结合。
Execution: Kubernetes Pod Created with Potential Reverse Shell Arguments
有人创建了一个 Pod,它包含通常与 Google Cloud 相关的 并使用反向 shell 进行测试。攻击者 使用反向 shell 扩展或保持对集群的初始访问权限,并且 来执行任意命令。如需了解详情,请参阅此提醒的日志消息。
- 确认 Pod 有正当理由指定这些命令, 参数。
- 确定 Cloud Logging 的审核日志中是否存在来自 Pod 或主账号的其他恶意活动迹象。
- 如果主账号不是服务账号(IAM 或 Kubernetes),请与该账号的所有者联系,以确认合法所有者是否执行了相应操作。
- 如果主账号是服务账号(IAM 或 Kubernetes), 确定服务账号执行此操作的合法性 动作
- 如果 Pod 不合法,请将其移除,同时移除任何关联的 RBAC 绑定,以及工作负载使用的和允许其创建的服务账号。
Execution: Suspicious Exec or Attach to a System Pod
有人使用 exec
或 attach
命令获取 shell,或在 kube-system
命名空间中运行的容器上执行命令。这些方法包括
有时会用于合法的调试目的。不过,kube-system
namespace
适用于由 Kubernetes 创建的系统对象,因此应审核意外的命令执行或 shell 创建。有关详情,请参阅
此提醒的日志消息。
- 查看 Cloud Logging 中的审核日志,确定这是否符合预期 主账号的活动
- 确定日志中是否存在主账号的其他恶意活动迹象。
对于允许进行此访问的 RBAC 角色和集群角色,请查看有关使用最小权限原则的指南。
Exfiltration: BigQuery Data Exfiltration
Exfiltration: BigQuery
Data Exfiltration
返回的发现结果包含两条可能的子规则之一。每条子规则的严重级别各不相同:
- 严重程度为
HIGH
的子规则exfil_to_external_table
:- 有一项资源保存在您的组织或项目之外。
- 严重程度为
LOW
的子规则vpc_perimeter_violation
:- VPC Service Controls 阻止了复制操作或尝试访问 BigQuery 资源。
如需响应此发现结果,请执行以下操作:
第 1 步:查看发现结果详情
- 按照查看发现结果中所述,打开
Exfiltration: BigQuery Data Exfiltration
发现结果。 在发现结果详情面板的摘要标签页上,查看以下部分中列出的值:
- 检测到的内容:
- 严重程度:对于子规则
exfil_to_external_table
,严重程度为HIGH
;对于子规则vpc_perimeter_violation
,严重程度为LOW
。 - 主账号电子邮件地址:用于渗漏数据的账号。
- 渗漏来源:有关从其中渗漏数据的表的详细信息。
- 渗漏目标:有关在其中存储渗漏数据的表的详细信息。
- 严重程度:对于子规则
- 受影响的资源:
- 资源全名:从其中渗漏数据的项目、文件夹或组织的完整资源名称。
- 相关链接:
- Cloud Logging URI:指向 Logging 条目的链接。
- MITRE ATT&CK 方法:指向 MITRE ATT&CK 文档的链接。
- 相关发现结果:指向任何相关发现结果的链接。
- Chronicle:指向 Google SecOps 的链接。
- 检测到的内容:
点击来源属性标签页,然后查看显示的字段,尤其是:
detectionCategory
:subRuleName
:exfil_to_external_table
或vpc_perimeter_violation
。
evidence
:sourceLogId
:projectId
:包含来源 BigQuery 数据集的 Google Cloud 项目。
properties
dataExfiltrationAttempt
jobLink
:指向渗漏数据的 BigQuery 作业的链接。query
:在 BigQuery 数据集上运行的 SQL 查询。
您可以选择点击 JSON 标签页,查看发现结果的 JSON 属性的完整列表。
第 2 步:在 Google Security Operations 中了解情况
您可以使用 Google Security Operations 来调查此发现结果。Google SecOps 是一项 Google Cloud 服务,可让您以统一的时间调查威胁并透视相关实体。Google SecOps 会丰富发现结果数据,以便您识别感兴趣的指标并简化调查。
只有当您在组织级别激活 Security Command Center 时,才能使用 Google SecOps。
转到 Google Cloud 控制台中的 Security Command Center 发现结果页面。
在快速过滤条件面板中,向下滚动到来源显示名称。
在来源显示名称部分,选择事件威胁检测。
该表会填充 Event Threat Detection 的发现结果。
在表中的类别下方,点击
Exfiltration: BigQuery Data Exfiltration
发现结果。系统会打开发现结果详情面板。在发现结果详情面板的相关链接部分中,点击在 Chronicle 中进行调查。
按照 Google SecOps 指导的界面中的说明操作。
使用以下指南在 Google SecOps 中开展调查:
第 3 步:查看权限和设置
在 Google Cloud 控制台中,转到 IAM 页面。
如有必要,请选择发现结果 JSON 中的
projectId
字段中列出的项目。在显示的页面上的过滤条件框中,输入主账号电子邮件地址中列出的电子邮件地址,并检查为该账号分配了哪些权限。
第 4 步:检查日志
- 在发现结果详情面板的“摘要”标签页上,点击 Cloud Logging URI 链接以打开日志浏览器。
使用以下过滤条件查找与 BigQuery 作业相关的管理员活动日志:
protoPayload.methodName="Jobservice.insert"
protoPayload.methodName="google.cloud.bigquery.v2.JobService.InsertJob"
第 5 步:研究攻击和响应方法
- 查看此发现结果类型的 MITRE ATT&CK 框架条目:Web 服务渗漏:渗漏到 Cloud Storage。
- 点击发现结果详情摘要标签页中相关发现结果行上的相关发现结果的链接,以查看相关发现结果。 相关发现结果属于同一实例和网络上的同一发现结果类型。
- 如需制定响应方案,请将您的调查结果与 MITRE 研究相结合。
第 6 步:实现响应
以下响应方案可能适合此发现结果,但也可能会影响运营。请仔细评估您在研究中收集的信息,以确定解析发现结果的最佳方法。
- 与数据被渗漏的项目的所有者联系。
- 在调查完成之前,请考虑撤消权限(针对
userEmail
)。 - 如需停止进一步的渗漏,请为受影响的 BigQuery 数据集(
exfiltration.sources
和exfiltration.targets
)添加严格的 IAM 政策。 - 如需扫描受影响的数据集是否存在敏感信息,请使用敏感数据保护。您还可以将敏感数据保护数据发送到 Security Command Center。根据信息量, 敏感数据保护费用可能很高。遵循最佳实践 将敏感数据保护费用 控制。
- 如需限制对 BigQuery API 的访问权限,请使用 VPC Service Controls。
- 如需识别并修正过于宽松的角色,请使用 IAM Recommender。
Exfiltration: BigQuery Data Extraction
您可以通过检查以下两种场景的审核日志来检测 BigQuery 中的数据渗漏:
- 资源会保存到组织外部的 Cloud Storage 存储桶中。
- 资源会保存到您的组织拥有的可公开访问的 Cloud Storage 存储桶中。
对于 Security Command Center 高级层级的项目级激活,此发现结果仅在父级组织中启用了标准层级时才可用。
如需响应此发现结果,请执行以下操作:
第 1 步:查看发现结果详情
- 按照查看发现结果中所述,打开
Exfiltration: BigQuery Data Extraction
发现结果。系统会打开发现结果详情面板,以显示摘要标签页。 在发现结果详情面板的摘要标签页上,查看以下部分中列出的值:
- 检测到的内容:
- 主账号电子邮件地址:用于渗漏数据的账号。
- 渗漏来源:有关从其中渗漏数据的表的详细信息。
- 渗漏目标:有关在其中存储渗漏数据的表的详细信息。
- 受影响的资源:
- 资源全名:渗漏其数据的 BigQuery 资源的名称。
- 项目全名:包含来源 BigQuery 数据集的 Google Cloud 项目。
- 相关链接:
- Cloud Logging URI:指向 Logging 条目的链接。
- MITRE ATT&CK 方法:指向 MITRE ATT&CK 文档的链接。
- 相关发现结果:指向任何相关发现结果的链接。
- 检测到的内容:
在发现结果详情面板中,点击 JSON 标签页。
在 JSON 中,请注意以下字段。
sourceProperties
:evidence
:sourceLogId
:projectId
:包含来源 BigQuery 数据集的 Google Cloud 项目。
properties
:extractionAttempt
:jobLink
:指向渗漏数据的 BigQuery 作业的链接
第 2 步:查看权限和设置
在 Google Cloud 控制台中,转到 IAM 页面。
如有必要,请选择发现结果 JSON 的
projectId
字段中列出的项目(来自第 1 步)。在显示的页面上的过滤条件框中,输入主账号电子邮件地址中列出的电子邮件地址(来自第 1 步),并检查为该账号分配了哪些权限。
第 3 步:检查日志
- 在发现结果详情面板的“摘要”标签页上,点击 Cloud Logging URI 链接以打开日志浏览器。
- 使用以下过滤条件查找与 BigQuery 作业相关的管理员活动日志:
protoPayload.methodName="Jobservice.insert"
protoPayload.methodName="google.cloud.bigquery.v2.JobService.InsertJob"
第 4 步:研究攻击和响应方法
- 查看此发现结果类型的 MITRE ATT&CK 框架条目:Web 服务渗漏:渗漏到 Cloud Storage。
- 点击发现结果详情摘要标签页中相关发现结果行上的链接,以查看相关发现结果。 相关发现结果属于同一实例和网络上的同一发现结果类型。
- 如需制定响应方案,请将您的调查结果与 MITRE 研究相结合。
第 5 步:实现响应
以下响应方案可能适合此发现结果,但也可能会影响运营。请仔细评估您在研究中收集的信息,以确定解析发现结果的最佳方法。
- 与数据被渗漏的项目的所有者联系。
- 在调查完成之前,考虑对发现结果详情摘要标签页中主账号电子邮件地址行上列出的主账号撤消权限。
- 如需阻止进一步的渗漏,请为发现结果详情摘要标签页上渗漏来源字段中标识的受影响的 BigQuery 数据集添加严格的 IAM 政策。
- 如需扫描受影响的数据集是否存在敏感信息,请使用敏感数据保护。您还可以将敏感数据保护数据发送到 Security Command Center。敏感数据保护费用可能相当大,具体取决于信息的数量。请遵循控制敏感数据保护费用的最佳实践。
- 如需限制对 BigQuery API 的访问权限,请使用 VPC Service Controls。
- 如果您是存储桶的所有者,请考虑撤消公开访问权限。
- 如需识别并修正过于宽松的角色,请使用 IAM Recommender。
Exfiltration: BigQuery Data to Google Drive
通过检查以下场景中的审核日志,检测到来自 BigQuery 的数据渗漏:
- 资源会保存到 Google 云端硬盘文件夹中。
如需响应此发现结果,请执行以下操作:
第 1 步:查看发现结果详情
- 按照查看发现结果中所述,打开
Exfiltration: BigQuery Data to Google Drive
发现结果。 在发现结果详情面板的摘要标签页上,查看以下部分中的信息:
- 检测到的内容,其中包括:
- 主账号电子邮件地址:用于渗漏数据的账号。
- 渗漏来源:有关从其中渗漏数据的 BigQuery 表的详细信息。
- 渗漏目标:有关 Google 云端硬盘中的目标位置的详细信息。
- 受影响的资源,其中包括:
- 资源全名:渗漏其数据的 BigQuery 资源的名称。
- 项目全名:包含来源 BigQuery 数据集的 Google Cloud 项目。
- 相关链接,其中包括:
- Cloud Logging URI:指向 Logging 条目的链接。
- MITRE ATT&CK 方法:指向 MITRE ATT&CK 文档的链接。
- 相关发现结果:指向任何相关发现结果的链接。
- 检测到的内容,其中包括:
如需了解详情,请点击 JSON 标签页。
在 JSON 中,记下以下字段。
sourceProperties
:evidence
:sourceLogId
:projectId
:包含来源 BigQuery 数据集的 Google Cloud 项目。
properties
:extractionAttempt
:jobLink
:指向渗漏数据的 BigQuery 作业的链接
第 2 步:查看权限和设置
在 Google Cloud 控制台中,转到 IAM 页面。
如有必要,请选择
projectId
查找 JSON(参见第 1 步)。在显示的页面上的过滤条件框中,输入
access.principalEmail
中列出的电子邮件地址(来自第 1 步),并检查为该账号分配了哪些权限。
第 3 步:检查日志
- 在发现结果详情面板的“摘要”标签页上,点击 Cloud Logging URI 链接以打开日志浏览器。
- 使用以下过滤条件查找与 BigQuery 作业相关的管理员活动日志:
protoPayload.methodName="Jobservice.insert"
protoPayload.methodName="google.cloud.bigquery.v2.JobService.InsertJob"
第 4 步:研究攻击和响应方法
- 查看此发现结果类型的 MITRE ATT&CK 框架条目:Web 服务渗漏:渗漏到 Cloud Storage。
- 点击发现结果详情摘要标签页中相关发现结果行上的相关发现结果的链接,以查看相关发现结果。 相关发现结果属于同一实例和网络上的同一发现结果类型。
- 如需制定响应方案,请将您的调查结果与 MITRE 研究相结合。
第 5 步:实现响应
以下响应方案可能适合此发现结果,但也可能会影响运营。请仔细评估您在研究中收集的信息,以确定解析发现结果的最佳方法。
- 与数据被渗漏的项目的所有者联系。
- 请考虑在
access.principalEmail
字段中撤消主账号的权限,直到调查完成。 - 如需停止进一步的渗漏,请为受影响的 BigQuery 数据集 (
exfiltration.sources
) 添加严格的 IAM 政策。 - 如需扫描受影响的数据集是否存在敏感信息,请使用敏感数据保护。您还可以发送 敏感数据保护数据传输到 Security Command Center。敏感数据保护费用可能相当大,具体取决于信息的数量。请遵循控制敏感数据保护费用的最佳实践。
- 如需限制对 BigQuery API 的访问权限,请使用 VPC Service Controls。
- 如需识别并修正过于宽松的角色,请使用 IAM Recommender。
Exfiltration: Cloud SQL Data Exfiltration
您可以通过检查以下两种场景的审核日志来检测 Cloud SQL 中的数据渗漏:
- 活动实例数据导出到组织外部的 Cloud Storage 存储桶。
- 活动实例数据导出到组织拥有且可公开访问的 Cloud Storage 存储桶。
支持所有 Cloud SQL 实例类型。
对于 Security Command Center 高级层级的项目级激活,此发现结果仅在父级组织中启用了标准层级时才可用。
如需响应此发现结果,请执行以下操作:
第 1 步:查看发现结果详情
- 按照查看发现结果中所述,打开
Exfiltration: Cloud SQL Data Exfiltration
发现结果。系统会打开发现结果详情面板,以显示摘要标签页。 在摘要标签页上,查看以下部分中的信息:
- 检测到的内容,尤其是以下字段:
- 主账号电子邮件地址:用于渗漏数据的账号。
- 渗漏来源:有关渗漏其数据的 Cloud SQL 实例的详细信息。
- 渗漏目标:有关数据导出到的 Cloud Storage 存储桶的详细信息。
- 受影响的资源,尤其是以下字段:
- 资源全名:渗漏其数据的 Cloud SQL 资源的名称。
- 项目全名:包含来源 Cloud SQL 数据的 Google Cloud 项目。
- 相关链接,其中包括:
- Cloud Logging URI:指向 Logging 条目的链接。
- MITRE ATT&CK 方法:指向 MITRE ATT&CK 文档的链接。
- 相关发现结果:指向任何相关发现结果的链接。
- 检测到的内容,尤其是以下字段:
点击 JSON 标签页。
在发现结果的 JSON 中,请注意以下字段:
sourceProperties
:evidence
:sourceLogId
:projectId
:包含源 Cloud SQL 实例的 Google Cloud 项目。
properties
bucketAccess
:Cloud Storage 存储桶是可公开访问的,还是在组织外部exportScope
:导出的数据量,例如整个实例、一个或多个数据库、一个或多个表,或由查询指定的子集
第 2 步:查看权限和设置
在 Google Cloud 控制台中,转到 IAM 页面。
如有必要,请选择 发现结果 JSON 中的
projectId
字段(参见第 1 步)。在显示的页面上的过滤条件框中,输入发现结果详情摘要标签页中主账号电子邮件地址行上列出的电子邮件地址(来自第 1 步)。检查为该账号分配了哪些权限。
第 3 步:检查日志
- 在 Google Cloud 控制台中,点击 Cloud Logging URI 中的链接(来自第 1 步),以前往日志浏览器。日志浏览器页面包含与相关 Cloud SQL 实例有关的所有日志。
第 4 步:研究攻击和响应方法
- 查看此发现结果类型的 MITRE ATT&CK 框架条目:Web 服务渗漏:渗漏到 Cloud Storage。
- 点击第 1 步中所述的相关发现结果行上的链接,以查看相关发现结果。相关发现结果在同一 Cloud SQL 实例上具有相同的发现结果类型。
- 如需制定响应方案,请将您的调查结果与 MITRE 研究相结合。
第 5 步:实现响应
以下响应方案可能适合此发现结果,但也可能会影响运营。请仔细评估您在研究中收集的信息,以确定解析发现结果的最佳方法。
- 与数据被渗漏的项目的所有者联系。
- 在调查完成之前,请考虑撤消权限(针对
access.principalEmail
)。 - 如需防止进一步渗漏,请向受影响的 Cloud SQL 实例添加严格的 IAM 政策。
- 要限制针对 Cloud SQL Admin API 的访问和导出,请使用 VPC Service Controls。
- 如需识别并修正过于宽松的角色,请使用 IAM Recommender。
Exfiltration: Cloud SQL Restore Backup to External Organization
通过检查审核日志以确定备份中的数据是否已恢复到组织或项目外部的 Cloud SQL 实例,可检测 Cloud SQL 备份中的数据渗漏。支持所有 Cloud SQL 实例和备份类型。
如需响应此发现结果,请执行以下操作:
第 1 步:查看发现结果详情
- 按照查看发现结果中所述,打开
Exfiltration: Cloud SQL Restore Backup to External Organization
发现结果。 在发现结果详情面板的摘要标签页上,查看以下部分中的信息:
- 检测到的内容,尤其是以下字段:
- 主账号电子邮件地址:用于渗漏数据的账号。
- 渗漏来源:有关通过其创建备份的 Cloud SQL 实例的详细信息。
- 渗漏目标:有关备份数据恢复到的 Cloud SQL 实例的详细信息。
- 受影响的资源,尤其是以下字段:
- 资源全名:原备份的资源名称 已恢复。
- 项目全名:包含通过其创建备份的 Cloud SQL 实例的 Google Cloud 项目。
- 检测到的内容,尤其是以下字段:
相关链接,尤其是以下字段:
- Cloud Logging URI:指向 Logging 条目的链接。
- MITRE ATT&CK 方法:指向 MITRE ATT&CK 文档的链接。
- 相关发现结果:指向任何相关发现结果的链接。
点击 JSON 标签页。
在 JSON 中,记下以下字段。
resource
:parent_name
:从其创建备份的 Cloud SQL 实例的资源名称
evidence
:sourceLogId
:projectId
:包含来源 BigQuery 数据集的 Google Cloud 项目。
properties
:restoreToExternalInstance
:backupId
:已恢复的备份作业的 ID
第 2 步:查看权限和设置
在 Google Cloud 控制台中,转到 IAM 页面。
如有必要,请选择发现结果 JSON 的
projectId
字段中列出的实例的项目(来自第 1 步)。在显示的页面上的过滤条件框中,输入主账号电子邮件地址中列出的电子邮件地址(来自第 1 步),并检查为该账号分配了哪些权限。
第 3 步:检查日志
- 在 Google Cloud 控制台中,点击 Cloud Logging URI 中的链接(来自第 1 步),以前往日志浏览器。日志浏览器页面包含与相关 Cloud SQL 实例有关的所有日志。
第 4 步:研究攻击和响应方法
- 查看此发现结果类型的 MITRE ATT&CK 框架条目:Web 服务渗漏:渗漏到 Cloud Storage。
- 点击相关发现结果行上的链接,以查看相关发现结果。(来自第 1 步)。相关发现结果在同一 Cloud SQL 实例上具有相同的发现结果类型。
- 如需制定响应方案,请将您的调查结果与 MITRE 研究相结合。
第 5 步:实现响应
以下响应方案可能适合此发现结果,但也可能会影响运营。请仔细评估您在研究中收集的信息,以确定解析发现结果的最佳方法。
- 与数据被渗漏的项目的所有者联系。
- 在调查完成之前,考虑对发现结果详情摘要标签页中主账号电子邮件地址行上列出的主账号撤消权限。
- 如需防止进一步渗漏,请向受影响的 Cloud SQL 实例添加严格的 IAM 政策。
- 如需限制对 Cloud SQL Admin API 的访问,请使用 VPC Service Controls。
- 如需识别并修正过于宽松的角色,请使用 IAM Recommender。
Exfiltration: Cloud SQL Over-Privileged Grant
检测将 PostgreSQL 数据库(或数据库中的所有函数或过程)的所有权限授予一个或多个数据库用户的情况。
如需响应此发现结果,请执行以下操作:
第 1 步:查看发现结果详情
- 按照查看发现结果中所述,打开
Exfiltration: Cloud SQL Over-Privileged Grant
发现结果。 在发现结果详情面板的摘要标签页上,查看以下部分中的信息:
- 检测到的内容,尤其是以下字段:
- 数据库显示名称:受影响的 Cloud SQL PostgreSQL 实例中的数据库的名称。
- 数据库用户名:授予超额权限的 PostgreSQL 用户。
- 数据库查询:授予权限所执行的 PostgreSQL 查询。
- 数据库授权对象:超额权限的授权对象。
- 受影响的资源,尤其是以下字段:
- 资源全名:Cloud SQL 的资源名称 受影响的 PostgreSQL 实例。
- 父级全名:Cloud SQL 的资源名称 PostgreSQL 实例。
- 项目全名:包含 Cloud SQL PostgreSQL 实例。
- 相关链接,尤其是以下字段:
- Cloud Logging URI:指向 Logging 条目的链接。
- MITRE ATT&CK 方法:指向 MITRE ATT&CK 文档的链接。
- 相关发现结果:指向任何相关发现结果的链接。
- 检测到的内容,尤其是以下字段:
如需查看发现结果的完整 JSON,请点击 JSON 标签页。
第 2 步:查看数据库权限
- 连接到 PostgreSQL 数据库。
- 为以下对象列出并显示访问权限:
第 3 步:检查日志
- 在 Google Cloud 控制台中,点击 Cloud Logging URI 中的链接(来自第 1 步),以前往日志浏览器。日志浏览器页面包含与相关 Cloud SQL 实例有关的所有日志。
- 在日志浏览器中,查看 PostgreSQL
pgaudit
日志,这些日志会记录 使用以下过滤条件对数据库执行的查询:protoPayload.request.database="var class="edit">database"
第 4 步:研究攻击和响应方法
- 查看此发现结果类型的 MITRE ATT&CK 框架条目: Web 服务渗漏。
- 如需确定是否需要执行额外的补救步骤,请将您的调查结果与 MITRE 研究相结合。
第 5 步:实现响应
以下响应计划可能适合此发现结果,但也可能会影响运营。 请仔细评估您在研究中收集的信息,以确定解析发现结果的最佳方法。
- 与过度授予权限的实例的所有者联系。
- 在调查完成之前,考虑撤消数据库授权对象中列出的授权对象的所有权限。
- 如需限制对数据库(来自第 1 步的数据库显示名称)的访问权限,请撤消第 1 步的授权对象(来自数据库授权对象)的不必要的权限。
Initial Access: Database Superuser Writes to User Tables
检测 Cloud SQL 数据库超级用户账号(对 PostgreSQL 来说是 postgres
,对 MySQL 来说是 root
)何时写入用户表。超级用户(具有非常广泛访问权限的角色)通常不应用于向用户表写入数据。拥有受限程度更严格的访问权限的用户账号应用于每日的常规活动。当超级用户向用户表写入数据时,这可能表示攻击者提升了特权或者伪装成默认数据库用户,并且正在修改数据。它也可能仅表示正常但不安全的做法。
如需响应此发现结果,请执行以下操作:
第 1 步:查看发现结果详情
- 按照查看发现结果中所述,打开
Initial Access: Database Superuser Writes to User Tables
发现结果。 在发现结果详情面板的摘要标签页上,查看以下部分中的信息:
- 检测到的内容,尤其是以下字段:
- 数据库显示名称: 受影响的 Cloud SQL PostgreSQL 或 MySQL 实例。
- 数据库用户名:超级用户。
- 数据库查询:写入用户表时执行的 SQL 查询。
- 受影响的资源,尤其是以下字段:
- 资源全名:Cloud SQL 的资源名称 实例。
- 父级完整名称:Cloud SQL 实例的资源名称。
- 项目全名:包含 Cloud SQL 实例。
- 相关链接,尤其是以下字段:
- Cloud Logging URI:指向 Logging 条目的链接。
- MITRE ATT&CK 方法:指向 MITRE ATT&CK 文档的链接。
- 相关发现结果:指向任何相关发现结果的链接。
- 检测到的内容,尤其是以下字段:
如需查看发现结果的完整 JSON,请点击 JSON 标签页。
第 2 步:检查日志
- 在 Google Cloud 控制台中,点击
cloudLoggingQueryURI
(第 1 步)中的链接,以转到日志浏览器。日志浏览器页面包含与相关 Cloud SQL 实例有关的所有日志。 - 使用以下过滤条件检查 PostgreSQL pgaudit 日志或 Cloud SQL for MySQL 审核日志,其中包含超级用户执行的查询:
protoPayload.request.user="SUPERUSER"
第 3 步:研究攻击和响应方法
- 查看此发现结果类型的 MITRE ATT&CK 框架条目: Web 服务渗漏。
- 如需确定是否需要执行额外的补救步骤,请将您的调查结果与 MITRE 研究相结合。
第 4 步:实现响应
以下响应计划可能适合此发现结果,但也可能会影响运营。 请仔细评估您在研究中收集的信息,以确定解析发现结果的最佳方法。
查看允许连接到数据库的用户。
- 对于 PostgreSQL,请参阅 创建和管理用户
- 对于 MySQL,请参阅 使用内置身份验证管理用户
考虑更改超级用户的密码。
考虑针对实例上使用的不同类型的查询创建一个访问权限受限的新用户。
仅向新用户授予执行其查询所需的必要权限。
- 对于 PostgreSQL,请参阅 Grant(命令)
- 对于 MySQL,请参阅访问权限控制和账号管理
更新连接到 Cloud SQL 实例的客户端的凭据
Initial Access: Anonymous GKE resource created from the internet
检测潜在恶意方何时使用了以下 Kubernetes 之一 默认用户或用户群组,以在集群中创建新的 Kubernetes 资源:
system:anonymous
system:authenticated
system:unauthenticated
这些用户和群组实际上是匿名的。基于角色的访问权限 控制 (RBAC) 绑定,授予该用户创建 管理这些资源
查看创建的资源和关联的 RBAC 绑定,确保该绑定是必要的。如果不需要该绑定,请将其移除。如需了解详情,请参阅此发现结果对应的日志消息。
如需缓解此问题,请参阅避免使用默认角色和群组。
Initial Access: GKE resource modified anonymously from the internet
检测潜在恶意方何时使用了以下 Kubernetes 之一 默认用户或用户群组来修改集群中的 Kubernetes 资源:
system:anonymous
system:authenticated
system:unauthenticated
这些用户和群组实际上是匿名的。集群中的基于角色的访问控制 (RBAC) 绑定向该用户授予了修改集群中这些资源的权限。
查看修改后的资源和关联的 RBAC 绑定,确保该绑定是必要的。如果不需要此绑定,请将其移除。如需了解详情,请参阅此发现结果对应的日志消息。
如需缓解此问题,请参阅避免使用默认角色和群组。
Initial Access: Dormant Service Account Action
检测处于休眠状态用户管理的服务账号触发了操作的事件。在此上下文中,如果服务账号处于非活跃状态超过 180 天,则会被视为休眠。
如需响应此发现结果,请执行以下操作:
第 1 步:查看发现结果详情
- 按照查看发现结果中所述,打开
Initial Access: Dormant Service Account Action
发现结果。 在发现结果详情的摘要标签页上,记下以下字段的值。
在检测到的内容下:
- 主账号电子邮件地址:执行操作的休眠服务账号
- 服务名称:服务账号访问的 Google Cloud 服务的 API 名称
- 方法名称:所调用的方法
第 2 步:研究攻击和响应方法
第 3 步:实现响应
以下响应方案可能适合此发现结果,但也可能会影响运营。请仔细评估您在研究中收集的信息,以确定解析发现结果的最佳方法。
- 与执行操作的项目的所有者联系。
- 考虑删除可能被盗用的服务账号,然后轮替和删除可能被破解的项目的所有服务账号访问密钥。删除后,使用该服务账号进行身份验证的应用会失去访问权限。在继续操作之前,您的安全团队应确定所有受影响的应用并与应用所有者合作,以确保业务连续性。
- 与您的安全团队合作,确定不熟悉的资源,包括 Compute Engine 实例、快照、服务账号和 IAM 用户。删除未使用已获授权的账号创建的资源。
- 回复来自 Google Cloud 支持的任何通知。
- 如需限制谁可以创建服务账号,请使用组织政策服务。
- 如需识别并修正过于宽松的角色,请使用 IAM Recommender。
Initial Access: Dormant Service Account Key Created
检测创建了休眠的用户管理的服务账号密钥的事件。在此上下文中,如果服务账号处于非活跃状态超过 180 天,则会被视为休眠。
如需响应此发现结果,请执行以下操作:
第 1 步:查看发现结果详情
- 按照查看发现结果中所述,打开
Initial Access: Dormant Service Account Key Created
发现结果。 在发现结果详情的摘要标签页上,记下以下字段的值。
在检测到的内容下:
- 主账号电子邮件地址:创建服务账号密钥的用户
在受影响的资源下:
- 资源显示名:新创建的休眠服务账号密钥
- 项目全名:休眠服务账号所在的项目
第 2 步:研究攻击和响应方法
第 3 步:实现响应
以下响应方案可能适合此发现结果,但也可能会影响运营。请仔细评估您在研究中收集的信息,以确定解析发现结果的最佳方法。
- 与执行操作的项目的所有者联系。
- 如果主账号电子邮件地址被盗用,请移除其所有者的访问权限。
- 在“服务账号”页面中使新创建的服务账号密钥失效。
- 考虑删除可能被盗用的服务账号,然后轮替和删除可能被破解的项目的所有服务账号访问密钥。删除后,使用该服务账号进行身份验证的应用会失去访问权限。在继续操作之前,您的安全团队应确定所有受影响的应用并与应用所有者合作,以确保业务连续性。
- 与您的安全团队合作,确定不熟悉的资源,包括 Compute Engine 实例、快照、服务账号和 IAM 用户。删除未使用已获授权的账号创建的资源。
- 响应来自 Cloud Customer Care 的任何通知。
- 如需限制谁可以创建服务账号,请使用组织政策服务。
- 如需识别并修正过于宽松的角色,请使用 IAM Recommender。
Initial Access: Leaked Service Account Key Used
检测使用泄露的服务账号密钥对操作进行身份验证的事件。在此情况下,泄露的服务账号密钥是发布到公共互联网上的密钥。例如,服务账号密钥通常错误地发布到公共 GitHub 代码库中。
如需响应此发现结果,请执行以下操作:
第 1 步:查看发现结果详情
- 按照查看发现结果中所述,打开
Initial Access: Leaked Service Account Key Used
发现结果。 在发现结果详情的摘要标签页上,记下以下字段的值。
在检测到的内容下:
- 主账号电子邮件地址:此操作中使用的服务账号
- 服务名称:服务账号访问的 Google Cloud 服务的 API 名称
- 方法名称:操作的方法名称
- 服务账号密钥名称:用于对此操作进行身份验证的泄露的服务账号密钥
- 说明:有关检测到的内容的说明,包括公共互联网上服务账号密钥的位置
在受影响的资源下:
- 资源显示名称:操作中涉及的资源
第 2 步:检查日志
- 在 Google Cloud 控制台中,点击 Cloud Logging URI 中的链接,以前往日志浏览器。
- 在 Google Cloud 控制台工具栏中,选择您的项目或组织。
在加载的页面上,使用以下过滤条件查找相关日志:
protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"
protoPayload.authenticationInfo.serviceAccountKeyName="SERVICE_ACCOUNT_KEY_NAME"
将 PRINCIPAL_EMAIL 替换为您在发现结果详情的主账号电子邮件地址字段中记录的值。 将 SERVICE_ACCOUNT_KEY_NAME 替换为您在发现结果详细信息的服务账号密钥名称字段中记下的值。
第 3 步:实现响应
以下响应计划可能适合此发现结果,但也可能会影响运营。 请仔细评估您在研究中收集的信息,以确定解析发现结果的最佳方法。
- 立即在“服务账号”页面撤消服务账号密钥。
- 移除发布服务账号密钥的网页或 GitHub 代码库。
- 考虑删除被盗用的服务账号。
- 轮替和删除可能被破解的项目的所有服务账号访问密钥。删除后,使用该服务账号进行身份验证的应用会失去访问权限。在删除之前,您的安全团队应确定所有受影响的应用并与应用所有者合作,以确保业务连续性。
- 与您的安全团队合作,确定不熟悉的资源,包括 Compute Engine 实例、快照、服务账号和 IAM 用户。删除未使用已获授权的账号创建的资源。
- 响应来自 Cloud Customer Care 的任何通知。
Initial Access: Excessive Permission Denied Actions
检测主账号在多个方法和服务中反复触发“权限遭拒”错误的事件。
如需响应此发现结果,请执行以下操作:
第 1 步:查看发现结果详情
- 按照查看发现结果中所述,打开
Initial Access: Excessive Permission Denied Actions
发现结果。 在发现结果详情的摘要标签页上,记下以下字段的值。
在检测到的内容下:
- 主账号电子邮件地址:触发多个权限遭拒错误的主账号
- 服务名称:上次发生权限遭拒错误的 Google Cloud 服务的 API 名称
- 方法名称:上一次权限遭拒错误发生时调用的方法
在发现结果详情的来源属性标签页上,记下以下 JSON 字段的值:
- properties.failedActions:发生的权限遭拒错误。对于每个条目,详细信息包括上次发生错误时的服务名称、方法名称、失败尝试次数以及错误发生时间。最多显示 10 个条目。
第 2 步:检查日志
- 在 Google Cloud 控制台中,点击 Cloud Logging URI 中的链接,以前往日志浏览器。
- 在 Google Cloud 控制台工具栏中,选择您的项目。
在加载的页面上,使用以下过滤条件查找相关日志:
protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"
protoPayload.status.code=7
将 PRINCIPAL_EMAIL 替换为您在发现结果详情的主账号电子邮件地址字段中记录的值。
第 3 步:研究攻击和响应方法
- 查看此发现结果类型的 MITRE ATT&CK 框架条目:有效账号:云账号。
- 如需制定响应方案,请将您的调查结果与 MITRE 研究相结合。
第 4 步:实现响应
以下响应计划可能适合此发现结果,但也可能会影响运营。 请仔细评估您在研究中收集的信息,以确定解析发现结果的最佳方法。
- 与主账号电子邮件地址字段中的账号所有者联系。确认合法所有者是否执行了此操作。
- 删除该账号创建的项目资源,例如陌生的 Compute Engine 实例、快照、服务账号和 IAM 用户等。
- 与该账号所在项目的所有者联系,并可能删除或停用该账号。
Brute Force: SSH
检测主机上的 SSH 暴力破解能力。如需响应此发现结果,请执行以下操作:
第 1 步:查看发现结果详情
- 按照查看发现结果中所述,打开
Brute Force: SSH
发现结果。 在发现结果详情面板的摘要标签页上,查看以下部分中的信息:
检测到的内容,尤其是以下字段:
- 调用方 IP:发起攻击的 IP 地址。
- 用户名:登录的账号。
受影响的资源
相关链接,尤其是以下字段:
- Cloud Logging URI:指向 Logging 条目的链接。
- MITRE ATT&CK 方法:指向 MITRE ATT&CK 文档的链接。
- 相关发现结果:指向任何相关发现结果的链接。
- Chronicle:指向 Google SecOps 的链接。
点击 JSON 标签页。
在 JSON 中,请注意以下字段。
sourceProperties
:evidence
:sourceLogId
:用于标识日志条目的项目 ID 和时间戳projectId
:包含发现结果的项目
properties
:attempts
:Attempts
:登录尝试次数username
:登录的账号vmName
:虚拟机的名称authResult
:SSH 身份验证结果
第 2 步:调查 Google Security Operations
您可以使用 Google Security Operations 来调查此发现结果。Google SecOps 是一项 Google Cloud 服务,可帮助您在简单易用的时间范围内调查威胁并遍历相关实体。Google SecOps 会丰富发现结果数据,以便您识别感兴趣的指标并简化调查。
只有当您在组织级别激活 Security Command Center 时,才能使用 Google SecOps。
转到 Google Cloud 控制台中的 Security Command Center 发现结果页面。
在快速过滤条件面板中,向下滚动到来源显示名称。
在来源显示名称部分,选择事件威胁检测。
系统会根据所选来源类型在表中填充发现结果。
在表格中的类别下方,点击
Brute Force: SSH
发现结果。 系统会打开发现结果详情面板。在发现结果详情面板的相关链接部分中,点击在 Chronicle 中进行调查。
按照 Google SecOps 指导的界面中的说明操作。
以下指南介绍了如何在 Google SecOps 中进行调查:
第 3 步:查看权限和设置
在 Google Cloud 控制台中,转到信息中心。
选择
projectId
中指定的项目。导航到资源卡片,然后点击 Compute Engine。
点击与
vmName
中的名称和可用区匹配的虚拟机实例。查看该实例的详细信息,包括网络和访问设置。在导航面板中,点击 VPC 网络,然后点击防火墙。移除或禁用端口 22 上的过于宽松的防火墙规则。
第 4 步:检查日志
- 在 Google Cloud 控制台中,点击 Cloud Logging URI 中的链接,以前往日志浏览器。
- 在加载的页面上,使用以下过滤条件查找与发现结果详情摘要标签页中主账号电子邮件地址行上列出的 IP 地址相关的 VPC 流日志:
logName="projects/projectId/logs/syslog"
labels."compute.googleapis.com/resource_name"="vmName"
第 5 步:研究攻击和响应方法
- 查看此发现结果类型的 MITRE ATT&CK 框架条目:有效账号:本地账号。
- 点击发现结果详情摘要标签页中相关发现结果行上的相关发现结果的链接,以查看相关发现结果。 相关发现结果属于同一实例和网络上的同一发现结果类型。
- 如需制定响应方案,请将您的调查结果与 MITRE 研究相结合。
第 6 步:实现响应
以下响应方案可能适合此发现结果,但也可能会影响运营。请仔细评估您在研究中收集的信息,以确定解析发现结果的最佳方法。
- 与成功尝试暴力破解的项目的所有者联系。
- 调查可能被破解的实例,并移除所有发现的恶意软件。为了帮助您检测和移除,请使用端点检测和响应解决方案。
- 考虑停用对虚拟机的 SSH 访问权限。如需了解如何停用 SSH 密钥,请参阅限制虚拟机的 SSH 密钥。此步骤可能会中断对虚拟机的授权访问,因此请考虑您的组织需求,然后再继续。
- 仅将 SSH 身份验证与已获授权的密钥结合使用。
- 通过更新防火墙规则或使用 Google Cloud Armor 阻止恶意 IP 地址。您可以在 Security Command Center 集成式服务页面上启用 Google Cloud Armor。如果信息量很大,Google Cloud Armor 的费用可能会非常高。如需了解详情,请参阅 Google Cloud Armor 价格指南。
Credential Access: External Member Added To Privileged Group
此发现结果不适用于项目级激活。
检测外部成员添加到特权 Google 群组(被授予敏感角色或权限的群组)的时间。如需响应此发现结果,请执行以下操作:
第 1 步:查看发现结果详情
按照查看发现结果中所述,打开
Credential Access: External Member Added To Privileged Group
发现结果。 系统会打开发现结果详情面板,以显示摘要标签页。在摘要标签页上,查看以下部分中的信息:
- 检测到的内容,尤其是以下字段:
- 主账号电子邮件地址:做出更改的账号。
- 受影响的资源
- 相关链接,尤其是以下字段:
- Cloud Logging URI:指向 Logging 条目的链接。
- MITRE ATT&CK 方法:指向 MITRE ATT&CK 文档的链接。
- 相关发现结果:指向任何相关发现结果的链接。
- 检测到的内容,尤其是以下字段:
在详情面板中,点击 JSON 标签页。
在 JSON 中,记下以下字段。
groupName
:在其中进行更改的 Google 群组externalMember
:新添加的外部成员sensitiveRoles
:与此群组关联的敏感角色
第 2 步:查看群组成员
转到 Google 群组。
点击您要查看的群组的名称。
在导航菜单中,点击成员。
如果新添加的外部成员不应在此群组中,请点击成员名称旁边的复选框,然后选择
移除成员或 将成员加入屏蔽名单。如需移除或成员,您必须是 Google Workspace 管理员,或者在 Google 群组中拥有 Owner 或 Manager 角色。如需了解详情,请参阅向群组成员分配角色。
第 3 步:检查日志
- 在发现结果详情面板的“摘要”标签页上,点击 Cloud Logging URI 链接以打开日志浏览器。
如有必要,请选择您的项目。
在加载的页面上,使用以下过滤条件检查日志,了解 Google 群组成员资格是否发生更改:
protoPayload.methodName="google.apps.cloudidentity.groups.v1.MembershipsService.UpdateMembership"
protoPayload.authenticationInfo.principalEmail="principalEmail"
第 4 步:研究攻击和响应方法
- 查看发现结果类型的 MITRE ATT&CK 框架条目:有效账号。
- 如需确定是否需要执行额外的补救步骤,请将您的调查结果与 MITRE 研究相结合。
Credential Access: Failed Attempt to Approve Kubernetes Certificate Signing Request (CSR)
有人尝试手动批准证书签名请求 (CSR),但是 操作失败。创建用于集群身份验证的证书是攻击者创建对已被入侵集群的永久访问权限的常用方法。通过 与证书相关的权限因主题而异 包含,但具有较高特权。如需了解详情,请参阅日志消息 。
- 查看 Cloud Logging 中的审核日志以及其他 CSR 的提醒
相关事件,以确定客户服务代表是否
approved
并已发出,以及客户服务代表是否 相关操作是主账号的预期活动。 - 通过
主账号。例如:
- 尝试批准 CSR 的主账号是否与此 CSR 不同 是谁创造的?
- 主账号尝试过请求、创建、批准或删除 其他客户服务代表?
- 如果 CSR 审批不在预期之内,或者被认定为是恶意的,集群将需要进行凭据轮替以使证书失效。请查看相关指南以了解如何执行集群凭据轮替。
Credential Access: Manually Approved Kubernetes Certificate Signing Request (CSR)
有人手动批准了证书签名请求 (CSR)。创建 用于集群身份验证的证书是攻击者 建立对受损集群的永久性访问权限与证书关联的权限因包含的主体而异,但可能具有高特权。如需了解详情,请参阅此提醒的日志消息。
- 查看 Cloud Logging 中的审核日志和其他 CSR 相关事件的更多提醒,以确定 CSR 相关操作是否是主账号执行的预期活动。
- 确定 Cloud Logging 的审核日志中是否存在主账号执行的其他恶意活动迹象。例如:
- 批准 CSR 的主账号是否与创建 CSR 的主账号不同?
- CSR 是否指定了内置签名者,但最终需要手动 是否因不符合签名者的条件而获得批准?
- 主账号尝试过请求、创建、批准或删除 其他客户服务代表?
- 如果 CSR 审批不在预期之内,或者被认定为是恶意的,集群将需要进行凭据轮替以使证书失效。查看有关执行集群凭据轮替的指南。
Credential Access: Privileged Group Opened To Public
此发现结果不适用于项目级激活。
检测到特权 Google 群组(被授予敏感角色或权限的群组)变为可供公众访问。如需响应此发现结果,请执行以下操作:
第 1 步:查看发现结果详情
按照查看发现结果中所述,打开
Credential Access: Privileged Group Opened To Public
发现结果。 系统会打开发现结果详情面板,以显示摘要标签页。在摘要标签页上,查看以下部分中的信息:
- 检测到的内容,尤其是以下字段:
- 主账号电子邮件地址:做出更改的账号,该账号可能被盗用。
- 受影响的资源
- 相关链接,尤其是以下字段:
- Cloud Logging URI:指向 Logging 条目的链接。
- MITRE ATT&CK 方法:指向 MITRE ATT&CK 文档的链接。
- 相关发现结果:指向任何相关发现结果的链接。
- 点击 JSON 标签页。
- 在 JSON 中,请注意以下字段。
groupName
:在其中进行更改的 Google 群组sensitiveRoles
:与此群组关联的敏感角色whoCanJoin
:群组的可加入性设置
- 检测到的内容,尤其是以下字段:
第 2 步:查看群组访问权限设置
转到 Google 群组的管理控制台。您必须是 Google Workspace 管理员才能登录控制台。
在导航窗格中,点击目录,然后选择群组。
点击您要查看的群组的名称。
点击访问权限设置,然后在哪些人可以加入群组下查看此群组的可加入性设置。
如有需要,请在下拉菜单中更改可加入性设置。
第 3 步:检查日志
- 在发现结果详情面板的“摘要”标签页上,点击 Cloud Logging URI 链接以打开日志浏览器。
如有必要,请选择您的项目。
在加载的页面上,使用以下过滤条件检查日志,了解 Google 群组设置是否发生更改:
protoPayload.methodName="google.admin.AdminService.changeGroupSetting"
protoPayload.authenticationInfo.principalEmail="principalEmail"
第 4 步:研究攻击和响应方法
- 查看发现结果类型的 MITRE ATT&CK 框架条目:有效账号。
- 如需确定是否需要执行额外的补救步骤,请将您的调查结果与 MITRE 研究相结合。
Credential Access: Secrets Accessed in Kubernetes Namespace
检测 Pod 的 default
Kubernetes 服务账号何时被用于访问集群中的 Secret 对象。除非您使用 Role 对象或 ClusterRole 对象明确授予访问权限,否则 default
Kubernetes 服务账号不应有权访问 Secret 对象。
Credential Access: Sensitive Role Granted To Hybrid Group
检测到具有外部成员的 Google 群组被授予敏感角色或权限。如需响应此发现结果,请执行以下操作:
第 1 步:查看发现结果详情
按照查看发现结果中所述,打开
Credential Access: Sensitive Role Granted To Hybrid Group
发现结果。系统会打开发现结果详情面板,以显示摘要标签页。在摘要标签页上,查看以下部分中的信息:
- 检测到的内容,尤其是以下字段:
- 主账号电子邮件地址:做出更改的账号,该账号可能被盗用。
- 受影响的资源,尤其是以下字段:
- 资源全名:为其授予新角色的资源。
- 相关链接,尤其是以下字段:
- Cloud Logging URI:指向 Logging 条目的链接。
- MITRE ATT&CK 方法:指向 MITRE ATT&CK 文档的链接。
- 相关发现结果:指向任何相关发现结果的链接。
- 点击 JSON 标签页。
- 在 JSON 中,请注意以下字段。
groupName
:在其中进行更改的 Google 群组bindingDeltas
:为此群组新授予的敏感角色。
- 检测到的内容,尤其是以下字段:
第 2 步:查看群组权限
转到 Google Cloud 控制台中的 IAM 页面。
在过滤条件字段中,输入
groupName
中列出的账号名称。查看为群组授予的敏感角色。
如果不需要新添加的敏感角色,请撤消此角色。
您需要特定权限才能管理组织或项目中的角色。如需了解详情,请参阅所需权限。
第 3 步:检查日志
- 在发现结果详情面板的“摘要”标签页上,点击 Cloud Logging URI 链接以打开日志浏览器。
如有必要,请选择您的项目。
在加载的页面上,使用以下过滤条件检查日志,了解 Google 群组设置是否发生更改:
protoPayload.methodName="SetIamPolicy"
protoPayload.authenticationInfo.principalEmail="principalEmail"
第 4 步:研究攻击和响应方法
- 查看发现结果类型的 MITRE ATT&CK 框架条目:有效账号。
- 如需确定是否需要执行额外的补救步骤,请将您的调查结果与 MITRE 研究相结合。
Malware: Cryptomining Bad IP
通过检查 VPC 流日志和 Cloud DNS 日志中与已知的命令以及控制网域和 IP 地址的连接,检测到恶意软件。如需响应此发现结果,请执行以下操作:
第 1 步:查看发现结果详情
按照查看发现结果中所述,打开
Malware: Cryptomining Bad IP
发现结果。系统会打开发现结果详情面板,以显示摘要标签页。在摘要标签页上,查看以下部分中的信息:
- 检测到的内容,尤其是以下字段:
- 来源 IP:疑似挖矿 IP 地址。
- 来源端口:连接的来源端口(如果有)。
- 目的地 IP:目标 IP 地址。
- 目的地端口:连接的目的地端口(如果有)。
- 协议:与连接关联的 IANA 协议。
- 受影响的资源
- 相关链接,其中包括以下字段:
- Logging URI:指向 Logging 条目的链接。
- MITRE ATT&CK 方法:指向 MITRE ATT&CK 文档的链接。
- 相关发现结果:指向任何相关发现结果的链接。
- 检测到的内容,尤其是以下字段:
在发现结果的详情视图中,点击来源属性标签页。
展开媒体资源,然后记下以下字段中的项目和实例值:
instanceDetails
:请记下项目 ID 和 Compute Engine 实例系统会显示项目 ID 和实例名称 如以下示例中所示:/projects/PROJECT_ID/zones/ZONE/instances/INSTANCE_NAME
如需查看发现结果的完整 JSON,请点击 JSON 标签页。
第 2 步:查看权限和设置
在 Google Cloud 控制台中,转到信息中心页面。
选择
properties_project_id
。导航到资源卡片,然后点击 Compute Engine。
点击与
properties_sourceInstance
匹配的虚拟机实例。调查可能被破解的实例是否存在恶意软件。在导航面板中,点击 VPC 网络,然后点击防火墙。移除或停用过于宽松的防火墙规则。
第 3 步:检查日志
在 Google Cloud 控制台中,打开日志浏览器。
在 Google Cloud 控制台工具栏中,选择您的项目。
在加载的页面上,使用以下过滤条件查找与
Properties_ip_0
相关的 VPC 流日志:logName="projects/properties_project_id/logs/compute.googleapis.com%2Fvpc_flows"
(jsonPayload.connection.src_ip="Properties_ip_0" OR jsonPayload.connection.dest_ip="Properties_ip_0")
第 4 步:研究攻击和响应方法
- 查看此发现结果类型的 MITRE ATT&CK 框架条目:资源黑客攻击。
- 如需制定响应方案,请将您的调查结果与 MITRE 研究相结合。
第 5 步:实现响应
以下响应方案可能适合此发现结果,但也可能会影响运营。请仔细评估您在研究中收集的信息,以确定解析发现结果的最佳方法。
- 与包含恶意软件的项目的所有者联系。
- 调查可能被破解的实例,并移除所有发现的恶意软件。为了帮助您检测和移除,请使用端点检测和响应解决方案。
- 如有必要,请停止已被破解的实例并用新实例取代。
- 通过更新防火墙规则或使用 Google Cloud Armor 阻止恶意 IP 地址。您可以在 Security Command Center 集成式服务页面上启用 Google Cloud Armor。如果数据量很大,Google Cloud Armor 的费用可能会非常高。如需了解详情,请参阅 Google Cloud Armor 价格指南。
Initial Access: Log4j Compromise Attempt
当检测到标头或网址参数中的 Java 命名和目录接口 (JNDI) 查找时,系统会生成此发现结果。这些查找可能表明 Log4Shell 被漏洞利用的尝试。如需响应此发现结果,请执行以下操作:
第 1 步:查看发现结果详情
按照查看发现结果详情中所述,打开
Initial Access: Log4j Compromise Attempt
发现结果。系统会打开发现结果详情面板,以显示摘要标签页。在摘要标签页上,查看以下部分中的信息:
- 检测到的内容
- 受影响的资源
- 相关链接,尤其是以下字段:
- Cloud Logging URI:指向 Logging 条目的链接。
- MITRE ATT&CK 方法:指向 MITRE ATT&CK 文档的链接。
- 相关发现结果:指向任何相关发现结果的链接。
- 在发现结果的详情视图中,点击 JSON 标签页。
在 JSON 中,记下以下字段。
properties
loadBalancerName
:接收 JNDI 查找的负载均衡器的名称requestUrl
:HTTP 请求的网址。如果此字段存在,则包含 JNDI 查找。requestUserAgent
:发送 HTTP 请求的用户代理。 如果存在,则包含 JNDI 查找。refererUrl
:发送 HTTP 请求的页面的网址。如果此字段存在,则包含 JNDI 查找。
第 2 步:检查日志
- 在 Google Cloud 控制台中,点击第 1 步的 Cloud Logging URI 中的链接,以前往日志浏览器。
在加载的页面上,检查
httpRequest
字段中是否存在${jndi:ldap://
等字符串令牌,这可能表示潜在的漏洞利用尝试。请参阅 Logging 文档中的 CVE-2021-44228:检测 Log4Shell 漏洞利用,查看要搜索的示例字符串以及示例查询。
第 3 步:研究攻击和响应方法
- 查看此发现结果类型的 MITRE ATT&CK 框架条目:利用面向公众的应用。
- 点击发现结果详情摘要标签页中相关发现结果行上的相关发现结果的链接,以查看相关发现结果。相关发现结果在同一实例和网络上属于同一发现结果类型。
- 如需制定响应方案,请将您的调查结果与 MITRE 研究相结合。
第 4 步:实现响应
以下响应方案可能适合此发现结果,但也可能会影响运营。请仔细评估您在研究中收集的信息,以确定解析发现结果的最佳方法。
- 升级到最新版本的 Log4j2。
- 按照 Google Cloud 的建议进行调查和响应 “Apache Log4j2”漏洞。
- 在 Apache Log4j 安全漏洞。
- 如果您使用 Google Cloud Armor,请将
cve-canary rule
部署到新的或现有的 Google Cloud Armor 安全政策。如需了解详情,请参阅 有助于缓解 Apache Log4j 漏洞的 Google Cloud Armor WAF 规则。
Active Scan: Log4j Vulnerable to RCE
受支持的 Log4j 漏洞扫描工具会在 HTTP 参数、网址和文本字段中注入经过混淆处理的 JNDI 查找,并对扫描工具控制的网域进行回调。发现经过去混淆处理的网域的 DNS 查询时,系统会生成此发现结果。只有当 JNDI 查找成功时,才会发生此类查询,这表示活跃的 Log4j 漏洞。如需响应此发现结果,请执行以下操作:
第 1 步:查看发现结果详情
按照查看发现结果详情中所述,打开
Active Scan: Log4j Vulnerable to RCE
发现结果。系统会打开发现结果详情面板,以显示摘要标签页。在摘要标签页上,查看以下部分中的信息:
- 检测到的内容
- 受影响的资源,尤其是以下字段:
- 资源全名: 完整资源名称 容易受到 Log4j RCE 攻击的 Compute Engine 实例。
- 相关链接,尤其是以下字段:
- Cloud Logging URI:指向 Logging 条目的链接。
- MITRE ATT&CK 方法:指向 MITRE ATT&CK 文档的链接。
- 相关发现结果:指向任何相关发现结果的链接。
在发现结果的详情视图中,点击 JSON 标签页。
在 JSON 中,记下以下字段。
properties
scannerDomain
:扫描工具在 JNDI 查找过程中使用的网域。这会表明哪个扫描工具发现了漏洞。sourceIp
:用于进行 DNS 查询的 IP 地址vpcName
:在其中执行 DNS 查询的实例上的网络名称。
第 2 步:检查日志
- 在 Google Cloud 控制台中,点击第 1 步的 Cloud Logging URI 中的链接,以前往日志浏览器。
在加载的页面上,检查
httpRequest
字段中是否存在${jndi:ldap://
等字符串令牌,这可能表示潜在的漏洞利用尝试。请参阅 Logging 文档中的 CVE-2021-44228:检测 Log4Shell 漏洞利用,查看要搜索的示例字符串以及示例查询。
第 3 步:研究攻击和响应方法
- 查看此发现结果类型的 MITRE ATT&CK 框架条目:利用远程服务。
- 点击发现结果详情摘要标签页中相关发现结果行上的相关发现结果的链接,以查看相关发现结果。 相关发现结果属于同一实例和网络上的同一发现结果类型。
- 如需制定响应方案,请将您的调查结果与 MITRE 研究相结合。
第 4 步:实现响应
以下响应方案可能适合此发现结果,但也可能会影响运营。请仔细评估您在研究中收集的信息,以确定解析发现结果的最佳方法。
- 升级到最新版本的 Log4j2。
- 遵循 Google Cloud 有关调查和应对“Apache Log4j 2”漏洞的建议。
- 实施 Apache Log4j 安全漏洞中推荐的缓解措施。
- 如果您使用 Google Cloud Armor,请将
cve-canary rule
部署到新的或现有的 Google Cloud Armor 安全政策。如需了解详情,请参阅 有助于缓解 Apache Log4j 漏洞的 Google Cloud Armor WAF 规则。
Leaked credentials
此发现结果不适用于项目级激活。
当 Google Cloud 服务账号凭据意外在网上泄露或被破解时生成此发现结果。如需响应此发现结果,请执行以下操作:
第 1 步:查看发现结果详情
按照查看发现结果详情中所述,打开
account_has_leaked_credentials
发现结果。系统会打开发现结果详情面板,以显示摘要标签页。在摘要标签页上,查看以下部分中的信息:
- 检测到的内容
- 受影响的资源
点击来源属性标签页并注意以下字段:
Compromised_account
:可能被盗用的服务账号Project_identifier
:包含可能已泄露的账号凭据的项目URL
:指向 GitHub 代码库的链接
如需查看发现结果的完整 JSON,请点击 JSON 标签页。
第 2 步:查看项目和服务账号权限
在 Google Cloud 控制台中,转到 IAM 页面。
如有必要,选择
Project_identifier
中列出的项目。在显示的页面上的过滤条件框中,输入
Compromised_account
中列出的账号名称并检查已分配的权限。在 Google Cloud 控制台中,转到服务账号页面。
在显示的页面上的过滤条件框中,输入被盗用的服务账号的名称,并检查该服务账号的密钥和密钥创建日期。
第 3 步:检查日志
在 Google Cloud 控制台中,打开日志浏览器。
在 Google Cloud 控制台工具栏中,选择您的项目。
在加载的页面上,使用以下过滤条件检查新的或更新后的 IAM 资源中的活动日志:
proto_payload.method_name="google.iam.admin.v1.CreateServiceAccount"
protoPayload.methodName="SetIamPolicy"
resource.type="gce_instance" AND log_name="projects/Project_identifier/logs/cloudaudit.googleapis.com%2Factivity"
protoPayload.methodName="InsertProjectOwnershipInvite"
protoPayload.authenticationInfo.principalEmail="Compromised_account"
第 4 步:研究攻击和响应方法
- 查看此发现结果类型的 MITRE ATT&CK 框架条目:有效账号:云账号。
- 点击
relatedFindingURI
中的链接查看相关发现结果。相关发现结果属于同一实例和网络上的同一发现结果类型。 - 如需制定响应方案,请将您的调查结果与 MITRE 研究相结合。
第 5 步:实现响应
以下响应计划可能适合此发现结果,但也可能会影响运营。 请仔细评估您在研究中收集的信息,以确定解析发现结果的最佳方法。
- 与凭据被泄露的项目的所有者联系。
- 考虑删除被盗用的服务账号,然后轮替和删除被破解的项目的所有服务账号访问密钥。删除后,使用该服务账号进行身份验证的资源会失去访问权限。在继续操作之前,您的安全团队应确定所有受影响的资源并与资源所有者合作,以确保业务连续性。
- 与您的安全团队合作,确定不熟悉的资源,包括 Compute Engine 实例、快照、服务账号和 IAM 用户。删除未使用已获授权的账号创建的资源。
- 回复来自 Google Cloud 支持的通知。
- 如需限制谁可以创建服务账号,请使用组织政策服务。
- 如需识别并修正过于宽松的角色,请使用 IAM Recommender。
- 打开
URL
链接并删除已泄露的凭据。获取有关已被破解的账号的更多信息,然后联系所有者。
Malware
通过检查 VPC 流日志和 Cloud DNS 日志中与已知的命令以及控制网域和 IP 地址的连接,检测到恶意软件。目前,Event Threat Detection 提供常规恶意软件检测(Malware: Bad IP
和 Malware: Bad Domain
)和特别针对 Log4j 相关恶意软件(Log4j Malware: Bad IP
和 Log4j Malware: Bad Domain
)的检测器。
以下步骤介绍了如何 响应基于 IP 的发现结果。对于基于网域的发现结果,补救步骤类似。
第 1 步:查看发现结果详情
打开相关的恶意软件发现结果。按照查看发现结果中所述,以下步骤使用
Malware: Bad IP
发现结果。系统会打开发现结果详情面板,以显示摘要标签页。在摘要标签页上,查看以下部分中的信息:
- 检测到的内容,尤其是以下字段:
- 指示器网域:对于
Bad domain
发现结果,此字段是触发发现结果的网域。 - 指示器 IP:对于
Bad IP
发现结果,此字段是触发发现结果的 IP 地址。 - 来源 IP:对于
Bad IP
发现结果,此字段是已知的恶意软件命令和控制 IP 地址。 - 来源端口:对于
Bad IP
发现结果,此字段是连接的来源端口。 - 目的地 IP:对于
Bad IP
发现结果,此字段是恶意软件的目标 IP 地址。 - 目的地端口:对于
Bad IP
发现结果,此字段是连接的目的地端口。 - 协议:对于
Bad IP
发现结果,此字段是与连接关联的 IANA 协议编号。
- 指示器网域:对于
- 受影响的资源,尤其是以下字段:
- 资源全名:受影响对象的完整资源名称 Compute Engine 实例
- 项目全名:您要创建的项目的完整资源名称 包含发现结果。
- 相关链接,尤其是以下字段:
- Cloud Logging URI:指向 Logging 条目的链接。
- MITRE ATT&CK 方法:指向 MITRE ATT&CK 文档的链接。
- 相关发现结果:指向任何相关发现结果的链接。
- Chronicle:指向 Google SecOps 的链接。
- VirusTotal 指示器:指向 VirusTotal 分析页面的链接。
点击 JSON 标签页,并注意以下字段:
evidence
:sourceLogId
:projectID
:在其中检测到问题的项目的 ID。
properties
:InstanceDetails
:Compute Engine 实例的资源地址。
- 检测到的内容,尤其是以下字段:
第 2 步:在 Google Security Operations 中了解情况
您可以使用 Google Security Operations 来调查此发现结果。Google SecOps 是一项 Google Cloud 服务 调查威胁,并在易于使用的 时间轴。Google SecOps 会丰富发现结果数据,以便您识别感兴趣的指标并简化调查。
只有当您在组织级别激活 Security Command Center 时,才能使用 Google SecOps。
转到 Google Cloud 控制台中的 Security Command Center 发现结果页面。
在快速过滤条件面板中,向下滚动到来源显示名称。
在来源显示名称部分,选择事件威胁检测。
系统会根据所选来源类型在表中填充发现结果。
在表中的类别下方,点击
Malware: Bad IP
发现结果。系统会打开发现结果详情面板。在发现结果详情面板的相关链接部分中,点击在 Chronicle 中进行调查。
按照 Google SecOps 指导的界面中的说明操作。
以下指南介绍了如何在 Google SecOps 中进行调查:
第 3 步:查看权限和设置
在 Google Cloud 控制台中,转到信息中心页面。
选择项目全名行中指定的项目 (在摘要标签页上)。
导航到资源卡片,然后点击 Compute Engine。
点击与 资源全名。 查看该实例的详细信息,包括网络和访问设置。
在导航面板中,点击 VPC 网络,然后点击防火墙。移除或停用过于宽松的防火墙规则。
第 4 步:检查日志
- 在发现结果详情面板的“摘要”标签页上,点击 Cloud Logging URI 链接以打开日志浏览器。
在加载的页面上,使用以下过滤条件查找与来源 IP 中的 IP 地址相关的 VPC 流日志:
logName="projects/projectId/logs/compute.googleapis.com%2Fvpc_flows" AND (jsonPayload.connection.src_ip="SOURCE_IP" OR jsonPayload.connection.dest_ip="destIP")
请替换以下内容:
PROJECT_ID
中选择projectId
中列出的项目。- 将
SOURCE_IP
替换为发现结果详情摘要标签页中的来源 IP 行上列出的 IP 地址。
第 5 步:研究攻击和响应方法
- 查看此发现结果类型的 MITRE ATT&CK 框架条目:动态解析以及命令和控制。
- 点击发现结果详情摘要标签页中相关发现结果行上的相关发现结果的链接,以查看相关发现结果。 相关发现结果属于同一实例和网络上的同一发现结果类型。
- 点击 VirusTotal 指示器中的链接,以检查 VirusTotal 上标记的网址和网域。VirusTotal 是一项 Alphabet 自有服务,提供了有关潜在恶意文件、网址、网域和 IP 地址的上下文。
- 如需制定响应方案,请将您的调查结果与 MITRE 研究相结合。
第 6 步:实现响应
以下响应方案可能适合此发现结果,但也可能会影响运营。请仔细评估您在研究中收集的信息,以确定解析发现结果的最佳方法。
- 与包含恶意软件的项目的所有者联系。
- 调查可能被破解的实例,并移除所有发现的恶意软件。为了帮助您检测和移除,请使用端点检测和响应解决方案。
- 如需跟踪可以插入恶意软件的活动和漏洞,请检查与被破解的实例关联的审核日志和系统日志。
- 如有必要,请停止已被破解的实例并用新实例取代。
- 通过更新防火墙规则或使用 Google Cloud Armor 阻止恶意 IP 地址。您可以在 Security Command Center 集成式服务页面上启用 Google Cloud Armor。如果数据量很大,Google Cloud Armor 的费用可能会非常高。如需了解详情,请参阅 Google Cloud Armor 价格指南。
- 如需控制对虚拟机映像的访问和使用,请使用安全强化型虚拟机和可信映像 IAM 政策。
Malware: Outgoing DoS
Event Threat Detection 通过分析 VPC 流日志检测到有可能使用了实例发起拒绝服务 (DoS) 攻击。如需响应此发现结果,请执行以下操作:
第 1 步:查看发现结果详情
按照查看发现结果中所述,打开
Malware: Outgoing DoS
发现结果。系统会打开发现结果详情面板,以显示摘要标签页。在摘要标签页上,查看以下部分中的信息:
- 检测到的内容
- 来源 IP:DoS 活动的来源 IP 地址。
- 来源端口:连接的来源端口。
- 目标 IP:DoS 活动的目标 IP 地址。
- 目的地端口:连接的目的地端口。
- 受影响的资源
- 相关链接,尤其是以下字段:
- Cloud Logging URI:指向 Logging 条目的链接。
- MITRE ATT&CK 方法:指向 MITRE ATT&CK 文档的链接。
- 相关发现结果:指向任何相关发现结果的链接。
- 在发现结果的详情视图中,点击 JSON 标签页。
- 在 JSON 中,记下以下字段。
sourceInstanceDetails
:受影响的 Compute Engine 虚拟机实例
- 检测到的内容
第 2 步:查看权限和设置
在 Google Cloud 控制台中,转到信息中心页面。
选择
sourceInstanceDetails
中指定的项目。导航到资源卡片,然后点击 Compute Engine。
点击与
sourceInstanceDetails
中的实例名称和可用区匹配的虚拟机实例。查看实例详情,包括网络和访问设置。在导航面板中,点击 VPC 网络,然后点击防火墙。 移除或停用过于宽松的防火墙规则。
第 3 步:检查日志
- 在发现结果详情面板的“摘要”标签页上,点击 Cloud Logging URI 链接以打开日志浏览器。
在加载的页面上,使用以下过滤条件查找与
srcIP
中的 IP 地址相关的 VPC 流日志:logName="projects/PROJECT_ID/logs/compute.googleapis.com%2Fvpc_flows" AND (jsonPayload.connection.src_ip="srcIP" OR jsonPayload.connection.dest_ip="destIP")
请替换以下内容:
- 将
PROJECT_ID
替换为在其中找到问题的项目的 ID。 - 将
SOURCE_IP
替换为发现结果 JSON 中的srcIP
字段上列出的 IP 地址。 - 将
DESTINATION_IP
替换为发现结果 JSON 中的destIp
字段上列出的 IP 地址。
- 将
第 4 步:研究攻击和响应方法
- 查看此发现结果类型的 MITRE ATT&CK 框架条目:网络拒绝服务攻击。
- 点击发现结果详情摘要标签页中相关发现结果行上的相关发现结果的链接,以查看相关发现结果。 相关发现结果属于同一实例和网络上的同一发现结果类型。
- 如需制定响应方案,请将您的调查结果与 MITRE 研究相结合。
第 5 步:实现响应
以下响应方案可能适合此发现结果,但也可能会影响运营。请仔细评估您在研究中收集的信息,以确定解析发现结果的最佳方法。
- 与出现传出 DoS 流量的项目的所有者联系。
- 调查可能被破解的实例,并移除所有发现的恶意软件。为了帮助您检测和移除,请使用端点检测和响应解决方案。
- 如需跟踪可以插入恶意软件的活动和漏洞,请检查与被破解的实例关联的审核日志和系统日志。
- 如有必要,请停止已被破解的实例并用新实例取代。
- 通过更新防火墙规则或使用 Google Cloud Armor 阻止恶意 IP 地址。您可以在 Security Command Center 集成式服务页面上启用 Google Cloud Armor。如果数据量很大,Google Cloud Armor 的费用可能会非常高。如需了解详情,请参阅 Google Cloud Armor 价格指南。
- 如需控制对虚拟机映像的访问和使用,请使用安全强化型虚拟机和可信映像 IAM 政策。
Persistence: IAM Anomalous Grant
系统会检查审核日志以检测是否添加了可能认为可疑的 IAM (IAM) 角色授权。
以下是异常授权的示例:
- 通过 Google Cloud 控制台邀请外部用户(例如 gmail.com 用户)作为项目所有者
- 授予敏感权限的服务账号
- 授予敏感权限的自定义角色
- 从组织或项目外部添加的服务账号
IAM Anomalous Grant
发现结果的独特之处在于包含
子规则,提供有关每个实例的更具体的信息
。此发现结果的严重程度分类取决于
子规则每项子规则可能需要不同的响应。
以下列表显示了所有可能的子规则及其严重程度:
external_service_account_added_to_policy
:external_member_invited_to_policy
:HIGH
external_member_added_to_policy
:custom_role_given_sensitive_permissions
:MEDIUM
service_account_granted_sensitive_role_to_member
:HIGH
policy_modified_by_default_compute_service_account
:HIGH
如需响应此发现结果,请执行以下操作:
第 1 步:查看发现结果详情
按照查看发现结果中所述,打开
Persistence: IAM Anomalous Grant
发现结果。系统会打开发现结果详情面板,以显示摘要标签页。在摘要标签页上,查看以下部分中的信息:
- 检测到的内容,尤其是以下字段:
- 主账号电子邮件地址:分配了角色的用户或服务账号的电子邮件地址。
受影响的资源
相关链接,尤其是以下字段:
- Cloud Logging URI:指向 Logging 条目的链接。
- MITRE ATT&CK 方法:指向 MITRE ATT&CK 文档的链接。
- 相关发现结果:指向任何相关发现结果的链接。
- VirusTotal 指示器:指向 VirusTotal 分析页面的链接。
- Chronicle:指向 Google SecOps 的链接。
- 检测到的内容,尤其是以下字段:
点击 JSON 标签页。系统将显示发现结果的完整 JSON。
在相应发现结果的 JSON 中,记下以下字段:
detectionCategory
:subRuleName
:有关所发生异常授予类型的更具体信息。子规则决定着 此发现结果的分类。
evidence
:sourceLogId
:projectId
:包含发现结果的项目的 ID。
properties
:sensitiveRoleGrant
:bindingDeltas
:Action
:用户执行的操作。Role
:为用户分配的角色。member
:获得该角色的用户的电子邮件地址。
第 2 步:在 Google Security Operations 中了解情况
您可以使用 Google Security Operations 来调查此问题 查找。Google SecOps 是一项 Google Cloud 服务 调查威胁,并在易于使用的 时间轴。Google SecOps 会丰富发现结果数据,以便您识别感兴趣的指标并简化调查。
如果您在项目级层激活 Security Command Center,则无法在 Chronicle 中调查 Security Command Center 发现结果。
转到 Google Cloud 控制台中的 Security Command Center 发现结果页面。
在快速过滤条件面板中,向下滚动到来源显示名称。
在来源显示名称部分,选择事件威胁检测。
系统会根据所选来源类型在表中填充发现结果。
在表格中的类别下方,点击
Persistence: IAM Anomalous Grant
发现结果。系统会打开发现结果详情面板。在发现结果详情面板的相关链接部分中,点击在 Chronicle 中进行调查。
按照 Google SecOps 指导的界面中的说明操作。
使用以下指南在 Google SecOps 中开展调查:
第 3 步:检查日志
- 在发现结果详情面板的“摘要”标签页上,点击 Cloud Logging URI 链接以打开日志浏览器。
- 在加载的页面上,使用以下过滤条件查找新的或更新后的 IAM 资源:
protoPayload.methodName="SetIamPolicy"
protoPayload.methodName="google.iam.admin.v1.UpdateRole"
protoPayload.methodName="google.iam.admin.v1.CreateRole"
第 4 步:研究攻击和响应方法
- 查看此发现结果类型的 MITRE ATT&CK 框架条目:有效账号:云账号。
- 点击发现结果详情摘要标签页中相关发现结果行上的链接,以查看相关发现结果。 相关发现结果在同一实例和网络上属于同一发现结果类型。
- 如需制定响应方案,请将您的调查结果与 MITRE 研究相结合。
第 5 步:实现响应
以下响应计划可能适合此发现结果,但也可能会影响运营。 请仔细评估您在研究中收集的信息,以确定解析发现结果的最佳方法。
- 与账号被盗用的项目的所有者联系。
- 删除被盗用的服务账号,然后轮替和删除被破解的项目的所有服务账号访问密钥。删除后,使用该服务账号进行身份验证的资源会失去访问权限。
- 删除未经授权的账号创建的项目资源,例如不熟悉的 Compute Engine 实例、快照、服务账号和 IAM 用户。
- 如需限制添加 gmail.com 用户,请使用组织政策。
- 如需识别并修正过于宽松的角色,请使用 IAM Recommender。
Persistence: Impersonation Role Granted for Dormant Service Account
检测向主账号授予模拟角色的事件,该事件允许该主账号模拟休眠的用户管理的服务账号。在此发现结果中,休眠服务账号是受影响的资源,如果服务账号处于非活跃状态超过 180 天,则会被视为休眠。
如需响应此发现结果,请执行以下操作:
第 1 步:查看发现结果详情
- 按照查看发现结果中所述,打开
Persistence: Impersonation Role Granted for Dormant Service Account
发现结果。 在发现结果详情的摘要标签页上,记下以下字段的值。
在检测到的内容下:
- 主账号电子邮件地址:执行授予角色操作的用户
- 违规访问授权主账号名称:被授予模拟角色的主账号
在受影响的资源下:
- 资源显示名称:作为资源的休眠服务账号
- 项目全名:休眠服务账号所在的项目
第 2 步:研究攻击和响应方法
第 3 步:检查日志
- 在发现结果详情面板的摘要标签页上,点击相关链接下的 Cloud Logging URI 链接以打开 Logs Explorer。
第 4 步:实现响应
以下响应计划可能适合此发现结果,但也可能会影响运营。 请仔细评估您在研究中收集的信息,以确定解析发现结果的最佳方法。
- 与执行操作的项目的所有者联系。
- 如果主账号电子邮件地址被盗用,请移除其所有者的访问权限。
- 从目标成员中移除新授予的模拟角色。
- 考虑删除可能被盗用的服务账号,然后轮替和删除可能被破解的项目的所有服务账号访问密钥。删除后,使用该服务账号进行身份验证的应用会失去访问权限。在继续操作之前,您的安全团队应确定所有受影响的应用并与应用所有者合作,以确保业务连续性。
- 与您的安全团队合作,确定不熟悉的资源,包括 Compute Engine 实例、快照、服务账号和 IAM 用户。删除未使用已获授权的账号创建的资源。
- 响应来自 Cloud Customer Care 的任何通知。
- 如需限制谁可以创建服务账号,请使用组织政策服务。
- 如需识别并修正过于宽松的角色,请使用 IAM Recommender。
Persistence: Unmanaged Account Granted Sensitive Role
检测向非受管账号授予敏感角色的事件 非受管账号无法由系统管理员控制。例如,当相应员工离职后,管理员将无法删除该账号。因此,向非受管账号授予敏感角色可能会产生 组织的安全风险
如需响应此发现结果,请执行以下操作:
第 1 步:查看发现结果详情
- 按照查看发现结果中所述,打开
Persistence: Unmanaged Account Granted Sensitive Role
发现结果。 在发现结果详情的摘要标签页上,记下以下字段的值。
在检测到的内容下:
- 主账号电子邮件地址:执行授予角色操作的用户
- 违规访问授权主账号名称:获得授权的非受管账号
- 违规访问 grants.Rolegranted:授予的敏感角色
第 2 步:研究攻击和响应方法
- 与主账号电子邮件地址字段的所有者联系。确认合法所有者是否执行了此操作。
- 与违规的 access grants.Principal name 字段的所有者联系,了解不受管理的账号的来源。
第 3 步:检查日志
- 在发现结果详情面板的摘要标签页上,点击相关链接下的 Cloud Logging URI 链接以打开 Logs Explorer。
第 4 步:实现响应
以下响应计划可能适合此发现结果,但也可能会影响运营。 请仔细评估您在研究中收集的信息,以确定解析发现结果的最佳方法。
- 与执行操作的项目的所有者联系。
- 如果主账号电子邮件地址被盗用,请移除其所有者的访问权限。
- 从不受管理的账号中移除新授予的敏感角色。
- 请考虑使用转移工具将非受管账号转换为受管理的账号。 并将此账号迁移到系统管理员的控制之下。
Persistence: New API Method
在组织、文件夹或项目中检测到潜在恶意行事者的异常管理员活动。异常活动可以是以下任一活动:
- 组织、文件夹或项目中的主账号的新活动
- 组织、文件夹或项目中的主账号一段时间未看到的活动
第 1 步:查看发现结果详情
- 按照查看发现结果中所述,打开
Persistence: New API Method
发现结果。 在发现结果详情的摘要标签页上,记下以下字段的值:
- 在检测到的内容下:
- 主账号电子邮件地址:发出调用的账号
- 服务名称:操作中使用的 Google Cloud 服务的 API 名称
- 方法名称:所调用的方法
- 在受影响的资源下:
- 资源显示名称:受影响资源的名称,可以与组织、文件夹或项目的名称相同
- 资源路径:资源层次结构中活动发生的位置
- 在检测到的内容下:
第 2 步:研究攻击和响应方法
- 查看此发现结果类型的 MITRE ATT&CK 框架条目:持久性。
- 调查在组织、文件夹或项目中执行此操作是否有必要,以及该操作是否由账号的合法所有者执行。组织、文件夹或项目显示在资源路径行上,账号显示在主账号电子邮件地址行上。
- 如需制定响应方案,请将您的调查结果与 MITRE 研究相结合。
Persistence: New Geography
此发现结果不适用于项目级激活。
根据发出请求的 IP 地址的地理位置,IAM 用户或服务账号从异常位置访问 Google Cloud。
第 1 步:查看发现结果详情
按照本页面前面部分的查看发现结果详情中所述,打开
Persistence: New Geography
发现结果。系统会打开发现结果详情面板,以显示摘要标签页。在摘要标签页上,查看以下部分中的信息:
- 检测到的内容,尤其是以下字段:
- 主账号电子邮件地址:可能被盗用的用户账号。
- 受影响的资源,尤其是以下字段:
- 项目全名:包含可能被盗用的用户账号的项目。
- 相关链接,尤其是以下字段:
- Cloud Logging URI:指向 Logging 条目的链接。
- MITRE ATT&CK 方法:指向 MITRE ATT&CK 文档的链接。
- 相关发现结果:指向任何相关发现结果的链接。
- 在发现结果的详情视图中,点击 JSON 标签页。
在 JSON 中,请注意以下
sourceProperties
字段:affectedResources
:gcpResourceName
:受影响的资源
evidence
:sourceLogId
:projectId
:包含发现结果的项目的 ID。
properties
:anomalousLocation
:anomalousLocation
:预估的用户当前位置。callerIp
:外部 IP 地址。notSeenInLast
:用于建立正常行为基准的时间段。typicalGeolocations
:用户通常在其中访问 Google Cloud 资源的位置。
第 2 步:查看项目和账号权限
在 Google Cloud 控制台中,转到 IAM 页面。
如有必要,请选择发现结果 JSON 中的
projectID
字段中列出的项目。在显示的页面上的过滤条件框中,输入主账号电子邮件地址中列出的账号名称,并检查授予的角色。
第 3 步:检查日志
- 在发现结果详情面板的“摘要”标签页上,点击 Cloud Logging URI 链接以打开日志浏览器。
- 如有必要,请选择您的项目。
- 在加载的页面上,使用以下过滤条件检查新的或更新后的 IAM 资源中的活动日志:
protoPayload.methodName="SetIamPolicy"
protoPayload.methodName="google.iam.admin.v1.UpdateRole"
protoPayload.methodName="google.iam.admin.v1.CreateRole"
protoPayload.authenticationInfo.principalEmail="principalEmail"
第 4 步:研究攻击和响应方法
- 查看此发现结果类型的 MITRE ATT&CK 框架条目:有效账号:云账号。
- 如需制定响应方案,请将您的调查结果与 MITRE 研究相结合。
第 5 步:实现响应
以下响应计划可能适合此发现结果,但也可能会影响运营。 请仔细评估您在研究中收集的信息,以确定解析发现结果的最佳方法。
- 与账号被盗用的项目的所有者联系。
- 查看
anomalousLocation
、typicalGeolocations
和notSeenInLast
字段,以验证访问是否异常以及账号是否被盗用。 - 删除未经授权的账号创建的项目资源,例如不熟悉的 Compute Engine 实例、快照、服务账号和 IAM 用户。
- 如需将新资源的创建限制在特定区域,请参阅限制资源位置。
- 如需识别并修正过于宽松的角色,请使用 IAM Recommender。
Persistence: New User Agent
此发现结果不适用于项目级激活。
IAM 服务账号按异常用户代理所指示使用可疑的软件访问 Google Cloud。
第 1 步:查看发现结果详情
按照本页面前面部分的查看发现结果详情中所述,打开
Persistence: New User Agent
发现结果。系统会打开发现结果详情面板,以显示摘要标签页。在摘要标签页上,查看以下部分中的信息:
- 检测到的内容,尤其是以下字段:
- 主账号电子邮件地址:可能被盗用的服务账号。
- 受影响的资源,尤其是以下字段:
- 项目全名:包含可能被盗用的服务账号的项目。
- 相关链接,尤其是以下字段:
- Cloud Logging URI:指向 Logging 条目的链接。
- MITRE ATT&CK 方法:指向 MITRE ATT&CK 文档的链接。
- 相关发现结果:指向任何相关发现结果的链接。
- 在发现结果的详情视图中,点击 JSON 标签页。
- 在 JSON 中,请注意以下字段。
projectId
:包含可能被盗用的服务账号的项目。callerUserAgent
:异常用户代理。anomalousSoftwareClassification
:软件类型。notSeenInLast
:用于建立正常行为基准的时间段。
- 检测到的内容,尤其是以下字段:
第 2 步:查看项目和账号权限
在 Google Cloud 控制台中,转到 IAM 页面。
如有必要,选择
projectId
中列出的项目。在显示的页面上的过滤条件框中,输入发现结果详情摘要标签页中主账号电子邮件地址行上列出的账号名称,并检查授予的角色。
在 Google Cloud 控制台中,转到服务账号页面。
在显示的页面上的过滤条件框中,输入发现结果详情摘要标签页中主账号电子邮件地址行上列出的账号名称。
检查该服务账号的密钥和密钥创建日期。
第 3 步:检查日志
- 在发现结果详情面板的“摘要”标签页上,点击 Cloud Logging URI 链接以打开日志浏览器。
- 如有必要,请选择您的项目。
- 在加载的页面上,使用以下过滤条件检查新的或更新后的 IAM 资源中的活动日志:
proto_payload.method_name="google.iam.admin.v1.CreateServiceAccount"
protoPayload.methodName="SetIamPolicy"
protoPayload.methodName="google.iam.admin.v1.UpdateRole"
protoPayload.methodName="google.iam.admin.v1.CreateRole"
protoPayload.authenticationInfo.principalEmail="principalEmail"
第 4 步:研究攻击和响应方法
- 查看此发现结果类型的 MITRE ATT&CK 框架条目:有效账号:云账号。
- 如需制定响应方案,请将您的调查结果与 MITRE 研究相结合。
第 5 步:实现响应
以下响应计划可能适合此发现结果,但也可能会影响运营。 请仔细评估您在研究中收集的信息,以确定解析发现结果的最佳方法。
- 与账号被盗用的项目的所有者联系。
- 查看
anomalousSoftwareClassification
、callerUserAgent
和behaviorPeriod
字段,以验证访问是否异常以及账号是否被盗用。 - 删除未经授权的账号创建的项目资源,例如不熟悉的 Compute Engine 实例、快照、服务账号和 IAM 用户。
- 如需将新资源的创建限制在特定区域,请参阅限制资源位置。
- 如需识别并修正过于宽松的角色,请使用 IAM Recommender。
Privilege Escalation: Changes to sensitive Kubernetes RBAC objects
为了升级特权,潜在恶意操作者试图修改
基于角色的 ClusterRole
、RoleBinding
或 ClusterRoleBinding
访问权限
敏感 cluster-admin
的 Control (RBAC) 对象
(使用 PUT
或 PATCH
请求)。
第 1 步:查看发现结果详情
按照查看发现结果中所述,打开
Privilege Escalation: Changes to sensitive Kubernetes RBAC objects
发现结果。 系统会打开发现结果详情面板,以显示摘要标签页。在摘要标签页上,查看以下部分中的信息:
- 检测到的内容,尤其是以下字段:
- 主账号电子邮件地址:发出调用的账号。
- 方法名称:所调用的方法。
- Kubernetes 绑定:已修改的敏感 Kubernetes 绑定或
ClusterRoleBinding
。
- 受影响的资源,尤其是以下字段:
- 资源显示名称:执行操作的 Kubernetes 集群。
- 相关链接,尤其是以下字段:
- Cloud Logging URI:指向 Logging 条目的链接。
- MITRE ATT&CK 方法:指向 MITRE ATT&CK 文档的链接。
- 相关发现结果:指向任何相关发现结果的链接。
- 检测到的内容,尤其是以下字段:
在检测到的内容部分中,点击 Kubernetes 绑定行上的绑定的名称。系统会显示绑定详细信息。
在显示的绑定中,请注意绑定详细信息。
第 2 步:检查日志
- 在 Google Cloud 控制台中发现结果详情的摘要标签页上,通过点击 Cloud Logging URI 字段中的链接转到日志浏览器。
如果方法名称中的值是
PATCH
方法,请检查请求 查看对哪些属性进行了修改在
update
(PUT
) 调用中,整个对象通过 因此更改不够明确使用以下过滤条件检查主账号执行的其他操作:
resource.labels.cluster_name="CLUSTER_NAME"
protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"
请替换以下内容:
CLUSTER_NAME
:您在发现结果详情的资源显示名称字段中记下的值。PRINCIPAL_EMAIL
:您在发现结果详情的主账号电子邮件地址字段中记下的值。
第 3 步:研究攻击和响应方法
- 查看以下发现结果类型的 MITRE ATT&CK 框架条目: 提升权限
- 确认对象的敏感度以及是否有必要进行修改。
- 对于绑定,您可以检查主体,并调查主体是否需要其绑定到的角色。
- 确定日志中是否存在主账号的其他恶意活动迹象。
如果主账号电子邮件地址不是服务账号,请与该账号的所有者联系,以确认合法所有者是否执行了该操作。
如果主账号电子邮件地址是服务账号(IAM 或 Kubernetes),请查明修改来源以确定其合法性。
如需制定响应方案,请将您的调查结果与 MITRE 研究相结合。
Privilege Escalation: Create Kubernetes CSR for master cert
为了升级特权,潜在恶意方已创建一个 Kubernetes 主实例
证书签名请求
(CSR),从而获得cluster-admin
访问权限。
第 1 步:查看发现结果详情
按照查看发现结果中所述,打开
Privilege Escalation: Create Kubernetes CSR for master cert
发现结果。系统会打开发现结果详情面板,以显示摘要标签页。在摘要标签页上,查看以下部分中的信息:
- 检测到的内容,尤其是以下字段:
- 主账号电子邮件地址:发出调用的账号。
- 方法名称:所调用的方法。
- 受影响的资源,尤其是以下字段:
- 资源显示名称:执行操作的 Kubernetes 集群。
- 相关链接,尤其是以下字段:
- Cloud Logging URI:指向 Logging 条目的链接。
- MITRE ATT&CK 方法:指向 MITRE ATT&CK 文档的链接。
- 相关发现结果:指向任何相关发现结果的链接。
- 检测到的内容,尤其是以下字段:
第 2 步:检查日志
- 在 Google Cloud 控制台中发现结果详情的摘要标签页上,通过点击 Cloud Logging URI 字段中的链接转到日志浏览器。
- 查看
protoPayload.resourceName
字段中的值以识别特定的证书签名请求。 使用以下过滤条件检查主账号执行的其他操作:
resource.labels.cluster_name="CLUSTER_NAME"
protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"
请替换以下内容:
CLUSTER_NAME
:您在发现结果详情的资源显示名称字段中记下的值。PRINCIPAL_EMAIL
:您在发现结果详情的主账号电子邮件地址字段中记下的值。
第 3 步:研究攻击和响应方法
- 查看此发现结果类型的 MITRE ATT&CK 框架条目:提升权限。
- 调查是否有必要授予
cluster-admin
访问权限。 如果主账号电子邮件地址不是服务账号,请与该账号的所有者联系,以确认合法所有者是否执行了该操作。
如果主账号电子邮件地址是服务账号(IAM 或 Kubernetes),请查明操作来源以确定其合法性。
如需制定响应方案,请将您的调查结果与 MITRE 研究相结合。
Privilege Escalation: Creation of sensitive Kubernetes bindings
为了提升特权,潜在恶意操作者尝试为 cluster-admin
角色创建新的 RoleBinding
或 ClusterRoleBinding
对象。
第 1 步:查看发现结果详情
按照查看发现结果中所述,打开
Privilege Escalation: Creation of sensitive Kubernetes bindings
发现结果。 系统会打开发现结果详情面板,以显示摘要标签页。在摘要标签页上,查看以下部分中的信息:
- 检测到的内容,尤其是以下字段:
- 主账号电子邮件地址:发出调用的账号。
- Kubernetes 绑定:已创建的敏感 Kubernetes 绑定或
ClusterRoleBinding
。
- 受影响的资源,尤其是以下字段:
- 资源显示名称:执行操作的 Kubernetes 集群。
- 相关链接,尤其是以下字段:
- Cloud Logging URI:指向 Logging 条目的链接。
- MITRE ATT&CK 方法:指向 MITRE ATT&CK 文档的链接。
- 相关发现结果:指向任何相关发现结果的链接。
- 检测到的内容,尤其是以下字段:
第 2 步:检查日志
- 在 Google Cloud 控制台中发现结果详情的摘要标签页上,通过点击 Cloud Logging URI 字段中的链接转到日志浏览器。
使用以下过滤条件检查主账号执行的其他操作:
resource.labels.cluster_name="CLUSTER_NAME"
protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"
请替换以下内容:
CLUSTER_NAME
:您在发现结果详情的资源显示名称字段中记下的值。PRINCIPAL_EMAIL
:您在发现结果详情的主账号电子邮件地址字段中记下的值。
第 3 步:研究攻击和响应方法
- 查看此发现结果类型的 MITRE ATT&CK 框架条目:提升权限。
- 确认已创建的绑定的敏感性以及主体是否需要这些角色。
- 对于绑定,您可以检查主体,并调查主体是否需要其绑定到的角色。
- 确定日志中是否存在主账号的其他恶意活动迹象。
如果主账号电子邮件地址不是服务账号,请与该账号的所有者联系,以确认合法所有者是否执行了该操作。
如果主账号电子邮件地址是服务账号(IAM 或 Kubernetes),请查明操作来源以确定其合法性。
如需制定响应方案,请将您的调查结果与 MITRE 研究相结合。
Privilege Escalation: Effectively Anonymous Users Granted GKE Cluster Access
有人创建了引用以下某个用户或群组的 RBAC 绑定:
system:anonymous
system:authenticated
system:unauthenticated
这些用户和群组实际上是匿名的,因此在向任何 RBAC 角色创建角色绑定或集群角色绑定时,应避免使用它们。查看 以便确保它的必要性如果不需要该绑定,请将其移除。如需了解详情,请参阅此发现结果的日志消息。
- 查看向以下对象授予权限的任何已创建的绑定:
system:anonymous
位用户、system:unauthenticated group
或system:authenticated
个群组。 - 通过 主账号。
如果有恶意活动的迹象,请查看有关调查和移除允许此访问的绑定的指南。
Privilege Escalation: Get Kubernetes CSR with compromised bootstrap credentials
为了提升特权,潜在恶意操作者使用 kubectl
命令和被破解的引导凭据查询了证书签名请求 (CSR)。
以下是此规则检测到的命令示例:
kubectl --client-certificate kubelet.crt --client-key kubelet.key --server YOUR_SERVER get csr CSR_NAME
第 1 步:查看发现结果详情
按照查看发现结果中所述,打开
Privilege Escalation: Get Kubernetes CSR with compromised bootstrap credentials
发现结果。 系统会打开发现结果详情面板,以显示摘要标签页。在摘要标签页上,查看以下部分中的信息:
- 检测到的内容,尤其是以下字段:
- 主账号电子邮件地址:发出调用的账号。
- 方法名称:所调用的方法。
- 在受影响的资源下:
- 资源显示名称:执行操作的 Kubernetes 集群。
- 相关链接,尤其是以下字段:
- Cloud Logging URI:指向 Logging 条目的链接。
- MITRE ATT&CK 方法:指向 MITRE ATT&CK 文档的链接。
- 相关发现结果:指向任何相关发现结果的链接。
- 检测到的内容,尤其是以下字段:
第 2 步:检查日志
如果您在发现结果详情的方法名称字段中记下的方法名称是 GET
方法,请执行以下操作:
- 在 Google Cloud 控制台中发现结果详情的摘要标签页上,通过点击 Cloud Logging URI 字段中的链接转到日志浏览器。
- 查看
protoPayload.resourceName
字段中的值以识别特定的证书签名请求。
第 3 步:研究攻击和响应方法
- 查看此发现结果类型的 MITRE ATT&CK 框架条目:提升权限。
- 如果日志条目中包含特定 CSR,请调查证书的敏感度以及是否有必要执行该操作。
- 如需制定响应方案,请将您的调查结果与 MITRE 研究相结合。
Privilege Escalation: Launch of privileged Kubernetes container
潜在恶意操作者创建了包含特权容器或具有提升特权功能的容器的 Pod。
特权容器的 privileged
字段设置为 true
。具有提权能力的容器的 allowPrivilegeEscalation
字段设置为 true
。如需了解详情,请参阅 Kubernetes 文档中的 SecurityContext v1 core API 参考。
第 1 步:查看发现结果详情
按照查看发现结果中所述,打开
Privilege Escalation: Launch of privileged Kubernetes container
发现结果。 系统会打开发现结果详情面板,以显示摘要标签页。在摘要标签页上,查看以下部分中的信息:
- 检测到的内容,尤其是以下字段:
- 主账号电子邮件地址:发出调用的账号。
- Kubernetes pod:新创建的具有特权容器的 Pod。
- 受影响的资源,尤其是以下字段:
- 资源显示名称:执行操作的 Kubernetes 集群。
- 相关链接,尤其是以下字段:
- Cloud Logging URI:指向 Logging 条目的链接。
- MITRE ATT&CK 方法:指向 MITRE ATT&CK 文档的链接。
- 相关发现结果:指向任何相关发现结果的链接。
- 检测到的内容,尤其是以下字段:
在 JSON 标签页上,记下发现结果字段的值:
- findings.kubernetes.pods[].containers:特权容器 Pod 中的状态
第 2 步:检查日志
- 在 Google Cloud 控制台中发现结果详情的摘要标签页上,通过点击 Cloud Logging URI 字段中的链接转到日志浏览器。
使用以下过滤条件检查主账号执行的其他操作:
resource.labels.cluster_name="CLUSTER_NAME"
protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"
请替换以下内容:
CLUSTER_NAME
:您在发现结果详情的资源显示名称字段中记下的值。PRINCIPAL_EMAIL
:您在发现结果详情的主账号电子邮件地址字段中记下的值。
第 3 步:研究攻击和响应方法
- 查看此发现结果类型的 MITRE ATT&CK 框架条目:提升权限。
- 确认创建的容器需要访问主机资源和内核功能。
- 确定日志中是否存在主账号的其他恶意活动迹象。
如果主账号电子邮件地址不是服务账号,请与该账号的所有者联系,以确认合法所有者是否执行了该操作。
如果主账号电子邮件地址是服务账号(IAM 或 Kubernetes),请查明操作来源以确定其合法性。
如需制定响应方案,请将您的调查结果与 MITRE 研究相结合。
Privilege Escalation: Dormant Service Account Granted Sensitive Role
检测向休眠的用户管理的服务账号授予敏感 IAM 角色的事件。在此上下文中,如果服务账号处于非活跃状态超过 180 天,则会被视为休眠。
如需响应此发现结果,请执行以下操作:
第 1 步:查看发现结果详情
- 按照查看发现结果中所述,打开
Privilege Escalation: Dormant Service Account Granted Sensitive Role
发现结果。 在发现结果详情的摘要标签页上,记下以下字段的值。
在检测到的内容下:
- 主账号电子邮件地址:执行授予角色操作的用户
- 违规访问 grants.Principal name:获得了敏感角色的休眠服务账号
- 违规访问授权授予的角色:分配的敏感 IAM 角色
在受影响的资源下:
- 资源显示名称:向休眠服务账号授予敏感 IAM 角色的组织、文件夹或项目。
第 2 步:研究攻击和响应方法
第 3 步:检查日志
- 在发现结果详情面板的摘要标签页上,点击相关链接下的 Cloud Logging URI 链接以打开 Logs Explorer。
第 4 步:实现响应
以下响应计划可能适合此发现结果,但也可能会影响运营。 请仔细评估您在研究中收集的信息,以确定解析发现结果的最佳方法。
- 与执行操作的项目的所有者联系。
- 如果主账号电子邮件地址被盗用,请移除其所有者的访问权限。
- 从休眠服务账号中移除新分配的敏感 IAM 角色。
- 考虑删除可能被盗用的服务账号,然后轮替和删除可能被破解的项目的所有服务账号访问密钥。删除后,使用该服务账号进行身份验证的资源会失去访问权限。在继续操作之前,您的安全团队应确定所有受影响的资源并与资源所有者合作,以确保业务连续性。
- 与您的安全团队合作,确定不熟悉的资源,包括 Compute Engine 实例、快照、服务账号和 IAM 用户。删除未使用已获授权的账号创建的资源。
- 响应来自 Cloud Customer Care 的任何通知。
- 如需限制谁可以创建服务账号,请使用组织政策服务。
- 如需识别并修正过于宽松的角色,请使用 IAM Recommender。
Privilege Escalation: Anomalous Impersonation of Service Account for Admin Activity
通过检查管理员活动审核日志以查看服务账号模拟请求中是否出现任何异常值,可检测服务账号的异常模拟。
如需响应此发现结果,请执行以下操作:
第 1 步:查看发现结果详情
按照查看发现结果中所述,打开
Privilege Escalation: Anomalous Impersonation of Service Account for Admin Activity
发现结果。系统会打开发现结果详情面板,以显示摘要标签页。在摘要标签页上,查看以下部分中的信息:
- 检测到的内容,尤其是以下字段:
- 主账号电子邮件地址:模拟请求中用于访问 Google Cloud 的最终服务账号。
- 服务名称:模拟请求所涉及的 Google Cloud 服务的 API 名称。
- 方法名称:所调用的方法。
- 服务账号委托信息:委托链中服务账号的详细信息,列表底部的主账号是模拟请求的调用方。
- 受影响的资源,尤其是以下字段:
- 资源全名:集群的名称。
- 相关链接,尤其是以下字段:
- Cloud Logging URI:指向 Logging 条目的链接。
- MITRE ATT&CK 方法:指向 MITRE ATT&CK 文档的链接。
- 相关发现结果:指向任何相关发现结果的链接。
- 检测到的内容,尤其是以下字段:
第 2 步:研究攻击和响应方法
- 在主账号电子邮件地址字段中与服务账号的所有者联系。确认合法所有者是否执行了此操作。
- 调查委托链中的主账号,以验证请求是否异常以及是否有任何账号被盗用。
- 在服务账号委托信息列表中与模拟调用者的所有者联系。确认合法所有者是否执行了此操作。
第 3 步:实现响应
以下响应方案可能适合此发现结果,但也可能会影响运营。请仔细评估您在研究中收集的信息,以确定解析发现结果的最佳方法。
- 与执行操作的项目的所有者联系。
- 考虑删除可能被盗用的服务账号,然后轮替和删除可能被破解的项目的所有服务账号访问密钥。删除后,使用该服务账号进行身份验证的资源会失去访问权限。在继续操作之前,您的安全团队应确定所有受影响的资源并与资源所有者合作,以确保业务连续性。
- 与您的安全团队合作,确定不熟悉的资源,包括 Compute Engine 实例、快照、服务账号和 IAM 用户。删除未使用已获授权的账号创建的资源。
- 回复来自 Google Cloud 支持的任何通知。
- 如需限制谁可以创建服务账号,请使用组织政策服务。
- 如需识别并修正过于宽松的角色,请使用 IAM Recommender。
Privilege Escalation: Anomalous Multistep Service Account Delegation for Admin Activity
通过检查管理员活动审核日志来查看服务账号模拟请求中是否出现任何异常,检测到 Anomalous Multistep Service Account Delegation
。
如需响应此发现结果,请执行以下操作:
第 1 步:查看发现结果详情
按照查看发现结果中所述,打开
Privilege Escalation: Anomalous Multistep Service Account Delegation for Admin Activity
发现结果。 系统会打开发现结果详情面板,以显示摘要标签页。在摘要标签页上,查看以下部分中的信息:
- 检测到的内容,尤其是以下字段:
- 主账号电子邮件地址:模拟请求中用于访问 Google Cloud 的最终服务账号。
- 服务名称:模拟请求所涉及的 Google Cloud 服务的 API 名称。
- 方法名称:所调用的方法。
- 服务账号委托信息:委托链中服务账号的详细信息,列表底部的主账号是模拟请求的调用方。
- 受影响的资源
- 相关链接,尤其是以下字段:
- Cloud Logging URI:指向 Logging 条目的链接。
- MITRE ATT&CK 方法:指向 MITRE ATT&CK 文档的链接。
- 相关发现结果:指向任何相关发现结果的链接。
- 检测到的内容,尤其是以下字段:
第 2 步:研究攻击和响应方法
- 在主账号电子邮件地址字段中与服务账号的所有者联系。确认合法所有者是否执行了此操作。
- 调查委托链中的主账号,以验证请求是否异常以及是否有任何账号被盗用。
- 在服务账号委托信息列表中与模拟调用者的所有者联系。确认合法所有者是否执行了此操作。
第 3 步:实现响应
以下响应方案可能适合此发现结果,但也可能会影响运营。请仔细评估您在研究中收集的信息,以确定解析发现结果的最佳方法。
- 与执行操作的项目的所有者联系。
- 考虑删除可能被盗用的服务账号,然后轮替和删除可能被破解的项目的所有服务账号访问密钥。删除后,使用该服务账号进行身份验证的资源会失去访问权限。在继续操作之前,您的安全团队应确定所有受影响的资源并与资源所有者合作,以确保业务连续性。
- 与您的安全团队合作,确定不熟悉的资源,包括 Compute Engine 实例、快照、服务账号和 IAM 用户。删除未使用已获授权的账号创建的资源。
- 回复来自 Google Cloud 支持的任何通知。
- 如需限制谁可以创建服务账号,请使用组织政策服务。
- 如需识别并修正过于宽松的角色,请使用 IAM Recommender。
Privilege Escalation: Anomalous Multistep Service Account Delegation for Data Access
通过检查数据访问审核日志来查看服务账号模拟请求中是否出现任何异常,检测到 Anomalous Multistep Service Account Delegation
。
如需响应此发现结果,请执行以下操作:
第 1 步:查看发现结果详情
按照查看发现结果中所述,打开
Privilege Escalation: Anomalous Multistep Service Account Delegation for Data Access
发现结果。系统会打开发现结果详情面板,以显示摘要标签页。在摘要标签页上,查看以下部分中的信息:
- 检测到的内容,尤其是以下字段:
- 主账号电子邮件地址:用于访问 Google Cloud 的模拟请求中的最终服务账号
- 服务名称:模拟请求所涉及的 Google Cloud 服务的 API 名称
- 方法名称:所调用的方法
- 服务账号委托信息:委托链中服务账号的详细信息,列表底部的主账号是模拟请求的调用方
- 受影响的资源
- 相关链接,尤其是以下字段:
- Cloud Logging URI:指向 Logging 条目的链接。
- MITRE ATT&CK 方法:指向 MITRE ATT&CK 文档的链接。
- 相关发现结果:指向任何相关发现结果的链接。
- 检测到的内容,尤其是以下字段:
第 2 步:研究攻击和响应方法
- 在主账号电子邮件地址字段中与服务账号的所有者联系。确认合法所有者是否执行了此操作。
- 调查委托链中的主账号,以验证请求是否异常以及是否有任何账号被盗用。
- 在服务账号委托信息列表中与模拟调用者的所有者联系。确认合法所有者是否执行了此操作。
第 3 步:实现响应
以下响应方案可能适合此发现结果,但也可能会影响运营。请仔细评估您在研究中收集的信息,以确定解析发现结果的最佳方法。
- 与执行操作的项目的所有者联系。
- 考虑删除可能被盗用的服务账号,然后轮替和删除可能被破解的项目的所有服务账号访问密钥。删除后,使用该服务账号进行身份验证的资源会失去访问权限。在继续操作之前,您的安全团队应确定所有受影响的资源并与资源所有者合作,以确保业务连续性。
- 与您的安全团队合作,确定不熟悉的资源,包括 Compute Engine 实例、快照、服务账号和 IAM 用户。删除未使用已获授权的账号创建的资源。
- 回复来自 Google Cloud 支持的任何通知。
- 如需限制谁可以创建服务账号,请使用组织政策服务。
- 如需识别并修正过于宽松的角色,请使用 IAM Recommender。
Privilege Escalation: Anomalous Service Account Impersonator for Admin Activity
通过检查管理员活动审核日志来查看服务账号模拟请求中是否出现任何异常,检测到 Anomalous Service Account Impersonator
。
如需响应此发现结果,请执行以下操作:
第 1 步:查看发现结果详情
按照查看发现结果中所述,打开
Privilege Escalation: Anomalous Service Account Impersonator for Admin Activity
发现结果。系统会打开发现结果详情面板,以显示摘要标签页。在摘要标签页上,查看以下部分中的信息:
检测到的内容,尤其是以下字段:
- 主账号电子邮件地址:用于访问 Google Cloud 的模拟请求中的最终服务账号
- 服务名称:模拟请求所涉及的 Google Cloud 服务的 API 名称
- 方法名称:所调用的方法
- 服务账号委托信息:委托链中服务账号的详细信息,列表底部的主账号是模拟请求的调用方
受影响的资源
相关链接,尤其是以下字段:
- Cloud Logging URI:指向 Logging 条目的链接。
- MITRE ATT&CK 方法:指向 MITRE ATT&CK 文档的链接。
- 相关发现结果:指向任何相关发现结果的链接。
第 2 步:研究攻击和响应方法
- 在主账号电子邮件地址字段中与服务账号的所有者联系。确认合法所有者是否执行了此操作。
- 调查委托链中的主账号,以验证请求是否异常以及是否有任何账号被盗用。
- 在服务账号委托信息列表中与模拟调用者的所有者联系。确认合法所有者是否执行了此操作。
第 3 步:实现响应
以下响应方案可能适合此发现结果,但也可能会影响运营。请仔细评估您在研究中收集的信息,以确定解析发现结果的最佳方法。
- 与执行操作的项目的所有者联系。
- 考虑删除可能被盗用的服务账号,然后轮替和删除可能被破解的项目的所有服务账号访问密钥。删除后,使用该服务账号进行身份验证的资源会失去访问权限。在继续操作之前,您的安全团队应确定所有受影响的资源并与资源所有者合作,以确保业务连续性。
- 与您的安全团队合作,确定不熟悉的资源,包括 Compute Engine 实例、快照、服务账号和 IAM 用户。删除未使用已获授权的账号创建的资源。
- 回复来自 Google Cloud 支持的任何通知。
- 如需限制谁可以创建服务账号,请使用组织政策服务。
- 如需识别并修正过于宽松的角色,请使用 IAM Recommender。
Privilege Escalation: Anomalous Service Account Impersonator for Data Access
通过检查数据访问审核日志以查看服务账号模拟请求中是否出现任何异常值,可检测异常服务账号模拟者。
如需响应此发现结果,请执行以下操作:
第 1 步:查看发现结果详情
- 按照查看发现结果中所述,打开
Privilege Escalation: Anomalous Service Account Impersonator for Data Access
发现结果。 在发现结果详情的摘要标签页上,记下以下字段的值。
在检测到的内容下:
- 主账号电子邮件地址:用于访问 Google Cloud 的模拟请求中的最终服务账号
- 服务名称:模拟请求所涉及的 Google Cloud 服务的 API 名称
- 方法名称:所调用的方法
- 服务账号委托信息:委托链中服务账号的详细信息,列表底部的主账号是模拟请求的调用方
第 2 步:研究攻击和响应方法
- 在主账号电子邮件地址字段中与服务账号的所有者联系。确认合法所有者是否执行了此操作。
- 调查委托链中的主账号,以验证请求是否异常以及是否有任何账号被盗用。
- 在服务账号委托信息列表中与模拟调用者的所有者联系。确认合法所有者是否执行了此操作。
第 3 步:实现响应
以下响应方案可能适合此发现结果,但也可能会影响运营。请仔细评估您在研究中收集的信息,以确定解析发现结果的最佳方法。
- 与执行操作的项目的所有者联系。
- 考虑删除可能被盗用的服务账号,然后轮替和删除可能被破解的项目的所有服务账号访问密钥。删除后,使用该服务账号进行身份验证的资源会失去访问权限。在继续操作之前,您的安全团队应确定所有受影响的资源并与资源所有者合作,以确保业务连续性。
- 与您的安全团队合作,确定不熟悉的资源,包括 Compute Engine 实例、快照、服务账号和 IAM 用户。删除未使用已获授权的账号创建的资源。
- 回复来自 Google Cloud 支持的任何通知。
- 如需限制谁可以创建服务账号,请使用组织政策服务。
- 如需识别并修正过于宽松的角色,请使用 IAM Recommender。
Privilege Escalation: ClusterRole with Privileged Verbs
有人创建了一个包含 bind
、escalate
或 impersonate
动词的 RBAC ClusterRole
对象。绑定到具有这些动词的角色的主语可以
模拟其他用户具有更高权限,绑定到其他 Role
或包含其他权限的 ClusterRole
对象,或者修改自己的
ClusterRole
权限。这可能会使这些主题
cluster-admin
权限。如需了解详情,请参阅此提醒的日志消息。
- 查看
ClusterRole
和关联的ClusterRoleBindings
,进行检查 对象是否确实需要这些权限。 - 如有可能,请避免创建涉及
bind
、escalate
或impersonate
个动词。 - 通过 主账号。
- 在 RBAC 角色中分配权限时,请遵循最小原则 权限,以及授予执行任务所需的最低权限。使用 最小权限原则可降低 上报问题,并降低 过度访问会导致安全事件。
Privilege Escalation: ClusterRoleBinding to Privileged Role
有人创建了一个引用默认值的 RBAC ClusterRoleBinding
system:controller:clusterrole-aggregation-controller
ClusterRole
。此默认 ClusterRole
具有 escalate
动词,允许主体修改自己角色的权限,从而导致权限提升。有关
请参阅此提醒的日志消息。
- 检查引用
system:controller:clusterrole-aggregation-controller
ClusterRole
的所有ClusterRoleBinding
。 - 审核对
system:controller:clusterrole-aggregation-controller
ClusterRole
。 - 确定 Cloud Logging 的审核日志中是否存在创建了
ClusterRoleBinding
的主账号执行的其他恶意活动迹象。
Privilege Escalation: Suspicious Kubernetes Container Names - Exploitation and Escape
有人部署了一个命名惯例类似于用于容器逃逸或在集群上执行其他攻击的常用工具的 Pod。如需了解更多详情, 查看此提醒的日志消息。
- 确认 Pod 是合法的。
- 确定是否存在来自 Pod 的其他恶意活动迹象,或 主账号。
- 如果主账号不是服务账号(IAM 或 Kubernetes),请与该账号的所有者联系,以确认合法所有者是否执行了相应操作。
- 如果主账号是服务账号(IAM 或 Kubernetes),请查明操作来源以确定其合法性。
- 如果 Pod 不合法,请将其移除,同时移除任何关联的 RBAC 绑定,以及工作负载使用的和允许其创建的服务账号。
Privilege Escalation: Workload Created with a Sensitive Host Path Mount
有人创建了一个工作负载,其中包含将 hostPath
卷装载到
敏感路径。访问主机文件系统上的这些路径可用于访问节点上的特权或敏感信息,以及用于容器逃逸。如果可能,不允许任何 hostPath
卷
集群内如需了解详情,请参阅此提醒的日志消息。
- 查看工作负载,确定是否必须使用此
hostPath
卷才能实现预期功能。如果是,请确保路径指向尽可能具体的目录。例如,使用/etc/myapp/myfiles
,而不是/
或/etc
。 - 确定 Cloud Logging 的审核日志中是否存在与此工作负载相关的其他恶意活动迹象。
如需阻止集群中的 hostPath
卷装载,请参阅有关强制执行 Pod 安全标准的指南。
Privilege Escalation: Workload with shareProcessNamespace enabled
有人部署了工作负载,并将 shareProcessNamespace
选项设置为
true
:允许所有容器共享同一个 Linux 进程命名空间。这个
可能会允许不受信任的或被盗用的容器通过
访问和控制环境变量、内存
其他容器中运行的进程的数据。某些工作负载可能出于合法原因需要运行此功能,例如日志处理边车容器或调试容器。如需了解详情,请参阅日志
消息。
- 确认工作负载确实需要访问工作负载中所有容器的共享进程命名空间。
- 检查 Cloud Logging 的审核日志中是否存在主账号执行的其他恶意活动迹象。
- 如果主账号不是服务账号(IAM 或 Kubernetes),请与该账号的所有者联系,以确认他们是否执行了相应操作。
- 如果主账号是服务账号(IAM 或 Kubernetes), 确定服务账号执行此操作的合法性 操作。
Service account self-investigation
使用服务账号凭据来调查与同一服务账号关联的角色和权限。此发现结果表明服务账号凭据被破解,应立即采取措施。
第 1 步:查看发现结果详情
按照本页面前面部分的查看发现结果详情中所述,打开
Discovery: Service Account Self-Investigation
发现结果。系统会打开发现结果详情面板,以显示摘要标签页。在摘要标签页上,查看以下部分中的信息:
- 检测到的内容,尤其是以下字段:
- 严重级别:分配给发现结果的风险级别。如果触发此发现结果的 API 调用未经授权,则严重级别为
HIGH
;服务账号无权使用projects.getIamPolicy
API 查询其自己的 IAM 权限。 - 主账号电子邮件地址:可能被盗用的服务账号。
- 调用方 IP 地址:内部或外部 IP 地址
- 严重级别:分配给发现结果的风险级别。如果触发此发现结果的 API 调用未经授权,则严重级别为
- 受影响的资源,尤其是以下字段:
- 资源全名:
- 项目全名:包含可能已泄露的账号凭据的项目。
- 相关链接,尤其是以下字段:
- Cloud Logging URI:指向 Logging 条目的链接。
- MITRE ATT&CK 方法:指向 MITRE ATT&CK 文档的链接。
- 相关发现结果:指向任何相关发现结果的链接。
- 如需查看发现结果的完整 JSON,请点击 JSON 标签页。
- 检测到的内容,尤其是以下字段:
第 2 步:查看项目和服务账号权限
在 Google Cloud 控制台中,转到 IAM 页面。
如有必要,请选择
projectID
查找 JSON。在显示的页面上的过滤条件框中,输入主账号电子邮件地址中列出的账号名称,并检查分配的权限。
在 Google Cloud 控制台中,转到服务账号页面。
在显示的页面上的过滤条件框中,输入被盗用的服务账号的名称,并检查该服务账号的密钥和密钥创建日期。
第 3 步:检查日志
- 在发现结果详情面板的“摘要”标签页上,点击 Cloud Logging URI 链接以打开日志浏览器。
- 如有必要,请选择您的项目。
- 在加载的页面上,使用以下过滤条件检查新的或更新后的 IAM 资源中的活动日志:
proto_payload.method_name="google.iam.admin.v1.CreateServiceAccount"
protoPayload.methodName="SetIamPolicy"
protoPayload.authenticationInfo.principalEmail="principalEmail"
第 4 步:研究攻击和响应方法
- 查看发现结果类型的 MITRE ATT&CK 框架条目:权限组发现:Cloud Groups。
- 如需制定响应方案,请将您的调查结果与 MITRE 研究相结合。
第 5 步:实现响应
以下响应计划可能适合此发现结果,但也可能会影响运营。 请仔细评估您在研究中收集的信息,以确定解析发现结果的最佳方法。
- 与账号被盗用的项目的所有者联系。
- 删除被盗用的服务账号,然后轮替和删除被破解的项目的所有服务账号访问密钥。删除后,使用该服务账号进行身份验证的资源会失去访问权限。
- 删除被盗用的账号创建的项目资源,例如不熟悉的 Compute Engine 实例、快照、服务账号和 IAM 用户。
Inhibit System Recovery: Deleted Google Cloud Backup and DR host
事件威胁检测会检查审核日志,以检测 运行受备份和灾难恢复服务保护的应用。主机被删除后,与主机关联的应用将无法备份。
如需响应此发现结果,请执行以下操作:
第 1 步:查看发现结果详情
- 按照查看发现结果中所述,打开
Inhibit System Recovery: Deleted Google Cloud Backup and DR host
发现结果。系统会打开发现结果详情面板,以显示摘要标签页。 - 在摘要标签页上,查看以下部分中的信息:
- 检测到的内容,尤其是以下字段:
- Application name:连接到备份和灾难恢复的数据库或虚拟机的名称
- 主机名:连接到备份和灾难恢复的主机的名称
- 主账号主体:已成功执行操作的用户
- 受影响的资源
- 资源显示名称:删除主机所在的项目
- 相关链接,尤其是以下字段:
- MITRE ATTACK 方法:指向 MITRE ATT&CK 文档的链接
- Logging URI:用于打开 Logs Explorer 的链接
- 检测到的内容,尤其是以下字段:
第 2 步:研究攻击和响应方法
在主账号电子邮件地址字段中与服务账号的所有者联系。确认合法所有者是否执行了此操作。
第 3 步:实现响应
以下响应方案可能适合此发现结果。小心 评估您在调查中收集的信息,以确定解决发现结果的最佳方式。
- 在执行操作的项目中,转到管理控制台。
- 确认已删除的主机不再位于备份和灾难恢复主机列表中。
- 选择添加主机选项,以重新添加已删除的主机。
Inhibit System Recovery: Google Cloud Backup and DR remove plan
Security Command Center 检查审核日志以检测 备份和灾难恢复服务备份方案,用于将备份政策应用于应用。
第 1 步:查看发现结果详情
- 按照查看发现结果中所述,打开
Inhibit System Recovery: Google Cloud Backup and DR remove plan
发现结果。系统会打开发现结果详情面板,以显示摘要标签页。 - 在摘要标签页上,查看以下部分中的信息:
- 检测到的内容,尤其是以下字段:
- Application name:连接到备份和灾难恢复的数据库或虚拟机的名称
- 配置文件名称:指定应用和虚拟机数据备份的存储目标
- 模板名称:用于定义备份频率、时间表和保留时间的一组政策的名称
- 受影响的资源
- 资源显示名称:删除了方案的项目
- 相关链接,尤其是以下字段:
- MITRE ATTACK 方法:指向 MITRE ATT&CK 文档的链接
- Logging URI:用于打开 Logs Explorer 的链接
- 检测到的内容,尤其是以下字段:
第 2 步:研究攻击和响应方法
在主账号电子邮件地址字段中与服务账号的所有者联系。确认合法所有者是否执行了此操作。
第 3 步:实现响应
以下响应方案可能适合此发现结果。小心 评估您在调查过程中收集的信息,以确定最佳 解决发现结果的方法。
- 在执行操作的项目中,转到管理控制台。
- 在应用管理器标签页中,找到不再受保护的受影响应用,然后查看每款应用的备份政策。
Inhibit System Recovery: Google Cloud Backup and DR delete template
Security Command Center 会检查审核日志,以检测模板的异常删除情况。模板是备份的基本配置,可应用于 多个应用
第 1 步:查看发现结果详情
- 打开
Inhibit System Recovery: Google Cloud Backup and DR delete template
详见查看发现结果。系统会打开发现结果详情面板,以显示摘要标签页。 - 在摘要标签页上,查看以下部分中的信息:
- 检测到的内容,尤其是以下字段:
- 模板名称:用于定义备份频率、时间表和保留时间的一组政策的名称
- 主账号主体:已成功执行操作的用户
- 受影响的资源
- 资源显示名称:删除了模板的项目
- 相关链接,尤其是以下字段:
- MITRE ATTACK 方法:指向 MITRE ATT&CK 文档的链接
- Logging URI:用于打开 Logs Explorer 的链接
- 检测到的内容,尤其是以下字段:
第 2 步:研究攻击和响应方法
在主账号电子邮件地址字段中与服务账号的所有者联系。确认合法所有者是否执行了此操作。
第 3 步:实现响应
以下响应方案可能适合此发现结果。小心 评估您在调查过程中收集的信息,以确定最佳 解决发现结果的方法。
- 在执行该操作的项目中,转到 管理控制台
- 在应用管理器标签页中,找到不再受保护的受影响应用,然后查看每款应用的备份政策。
- 如需重新添加模板,请前往备份方案标签页,选择模板,然后选择“创建模板”选项。
Inhibit System Recovery: Google Cloud Backup and DR delete policy
系统会检查审核日志,以检测是否有政策被删除。政策定义了备份的方式和存储位置。
第 1 步:查看发现结果详情
- 按照查看发现结果中所述,打开
Inhibit System Recovery: Google Cloud Backup and DR delete policy
发现结果。系统会打开发现结果详情面板,以显示摘要标签页。 - 在摘要标签页上,查看以下部分中的信息:
- 检测到的内容,尤其是以下字段:
- 政策名称:单个政策的名称,用于定义备份 频率、时间表和保留时间
- 主账号主体:已成功执行操作的用户
- 受影响的资源
- 资源显示名称:删除了政策的项目
- 相关链接,尤其是以下字段:
- MITRE ATTACK 方法:指向 MITRE ATT&CK 文档的链接
- Logging URI:用于打开 Logs Explorer 的链接。
- 检测到的内容,尤其是以下字段:
第 2 步:研究攻击和响应方法
在主账号电子邮件地址字段中与服务账号的所有者联系。 确认合法所有者是否执行了此操作。
第 3 步:实现响应
以下响应计划可能适用于此发现结果。请仔细评估您在研究中收集的信息,以确定解析发现结果的最佳方法。1. 在执行操作的项目中,转到管理控制台。2. 在应用管理器标签页中,选择受影响的应用并查看应用于该应用的政策设置。
Inhibit System Recovery: Google Cloud Backup and DR delete profile
系统会检查审核日志,以检测是否删除了配置文件。配置文件定义用于存储备份的存储池。
第 1 步:查看发现结果详情
- 按照查看发现结果中所述,打开
Inhibit System Recovery: Google Cloud Backup and DR delete profile
发现结果。 系统会打开发现结果详情面板,以显示摘要标签页。 - 在摘要标签页上,查看以下部分中的信息:
- 检测到的内容,尤其是以下字段:
- 配置文件名称:指定应用和虚拟机数据备份的存储目标
- 主账号主体:已成功执行操作的用户
- 受影响的资源
- 资源显示名称:在其中删除了配置文件的项目
- 相关链接,尤其是以下字段:
- MITRE ATTACK 方法:指向 MITRE ATT&CK 文档的链接
- Logging URI:用于打开 Logs Explorer 的链接
- 检测到的内容,尤其是以下字段:
第 2 步:研究攻击和响应方法
在主账号电子邮件地址字段中与服务账号的所有者联系。 确认合法所有者是否执行了此操作。
第 3 步:实现响应
以下响应计划可能适用于此发现结果。请仔细评估您在研究中收集的信息,以确定解析发现结果的最佳方法。1. 在执行操作的项目中,转到管理控制台。2. 在备份方案标签页中,选择配置文件以查看所有配置文件的列表。 3. 查看配置文件,确认已设置所有必需的配置文件。 4.如果已删除的配置文件被错误移除,请选择创建配置文件,为备份和灾难恢复设备定义存储目标。
Inhibit System Recovery: Google Cloud Backup and DR delete storage pool
系统会检查审核日志以检测是否有存储池被删除。存储池会将 Cloud Storage 存储桶与备份和灾难恢复相关联。
第 1 步:查看发现结果详情
- 按照查看发现结果中所述,打开
Inhibit System Recovery: Google Cloud Backup and DR delete storage pool
发现结果。 系统会打开发现结果详情面板,以显示摘要标签页。 - 在摘要标签页上,查看以下部分中的信息:
- 检测到的内容,尤其是以下字段:
- 存储桶名称:用于存储备份的存储桶的名称
- 主账号主体:已成功执行操作的用户
- 受影响的资源
- 资源显示名称:删除存储桶所在的项目
- 相关链接,尤其是以下字段:
- MITRE ATTACK 方法:指向 MITRE ATT&CK 文档的链接
- Logging URI:用于打开 Logs Explorer 的链接
- 检测到的内容,尤其是以下字段:
第 2 步:研究攻击和响应方法
在主账号电子邮件地址字段中与服务账号的所有者联系。 确认合法所有者是否执行了此操作。
第 3 步:实现响应
以下响应方案可能适合此发现结果。请仔细评估您在研究中收集的信息,以确定解析发现结果的最佳方法。1. 在执行操作的项目中,转到管理控制台。2. 在“管理”标签页中,选择存储池以查看所有存储池的列表。3. 查看存储池与备份设备的关联。 4.如果活跃设备没有关联的存储池,请选择添加保险柜池以重新添加。
Data Destruction: Google Cloud Backup and DR expire image
潜在恶意方已请求删除备份图片。
第 1 步:查看发现结果详情
- 按照查看发现结果中所述,打开
Inhibit System Recovery: Google Cloud Backup and DR expire image
发现结果。 系统会打开发现结果详情面板,以显示摘要标签页。 - 在摘要标签页上,查看以下部分中的信息:
- 检测到的内容,尤其是以下字段:
- 政策名称:单个政策的名称,用于定义备份频率、时间表和保留时间
- 模板名称:用于定义备份频率、时间表和保留时间的一组政策的名称
- 配置文件名称:指定应用和虚拟机数据的备份的存储目标
- 主账号主体:已成功执行操作的用户
- 受影响的资源
- 资源显示名称:删除备份映像的项目
- 相关链接,尤其是以下字段:
- MITRE ATTACK 方法:指向 MITRE ATT&CK 文档的链接
- Logging URI:用于打开 Logs Explorer 的链接
- 检测到的内容,尤其是以下字段:
第 2 步:研究攻击和响应方法
在主账号电子邮件地址字段中与服务账号的所有者联系。 确认合法所有者是否执行了此操作。
第 3 步:实现响应
以下响应计划可能适用于此发现结果。请仔细评估您在研究中收集的信息,以确定解析发现结果的最佳方法。1. 在执行操作的项目中,转到管理控制台。2. 转到“监控”标签页,然后选择“作业”以查看删除备份作业的状态。3. 如果删除作业未获得授权,请转到 IAM 权限,以查看有权访问备份数据的用户。
Data Destruction: Google Cloud Backup and DR expire all images
潜在恶意方已请求删除与某个应用关联的所有备份图片。
第 1 步:查看发现结果详情
- 按照查看发现结果中所述,打开
Inhibit System Recovery: Google Cloud Backup and DR expire all images
发现结果。 系统会打开发现结果详情面板,以显示摘要标签页。 - 在摘要标签页上,查看以下部分中的信息:
- 检测到的内容,尤其是以下字段:
- 政策名称:单个政策的名称,用于定义备份频率、时间表和保留时间
- 模板名称:用于定义备份频率、时间表和保留时间的一组政策的名称
- 配置文件名称:指定应用和虚拟机数据的备份的存储目标
- 主账号主体:已成功执行操作的用户
- 受影响的资源
- 资源显示名称:删除了备份图片的项目
- 相关链接,尤其是以下字段:
- MITRE ATTACK 方法:指向 MITRE ATT&CK 文档的链接
- Logging URI:用于打开 Logs Explorer 的链接。
- 检测到的内容,尤其是以下字段:
第 2 步:研究攻击和响应方法
在主账号电子邮件地址字段中与服务账号的所有者联系。 确认合法所有者是否执行了此操作。
第 3 步:实现响应
以下响应计划可能适用于此发现结果。请仔细评估您在研究中收集的信息,以确定解析发现结果的最佳方法。1. 在执行操作的项目中,转到管理控制台。2. 转到“监控”标签页,然后选择“作业”以查看删除备份作业的状态。3. 如果删除作业未获得授权,请转到 IAM 权限,以查看有权访问备份数据的用户。
Data Destruction: Google Cloud Backup and DR remove appliance
系统会检查审核日志,以检测是否移除了备份和恢复设备。备份和恢复设备是备份操作的关键组件。
第 1 步:查看发现结果详情
- 按照查看发现结果中所述,打开
Inhibit System Recovery: Google Cloud Backup and DR remove appliance
发现结果。 系统会打开发现结果详情面板,以显示摘要标签页。 - 在摘要标签页上,查看以下部分中的信息:
- 检测到的内容,尤其是以下字段:
- 设备名称:连接到备份和灾难恢复的数据库或虚拟机的名称
- 主账号主体:已成功执行操作的用户
- 受影响的资源
- 资源显示名称:删除设备所在的项目
- 相关链接,尤其是以下字段:
- MITRE ATTACK 方法:指向 MITRE ATT&CK 文档的链接
- Logging URI:用于打开 Logs Explorer 的链接
- 检测到的内容,尤其是以下字段:
第 2 步:研究攻击和响应方法
在主账号电子邮件地址字段中与服务账号的所有者联系。 确认合法所有者是否执行了此操作。
第 3 步:实现响应
以下响应方案可能适合此发现结果。请仔细评估您在研究中收集的信息,以确定解析发现结果的最佳方法。1. 在执行操作的项目中,转到管理控制台。2. 在应用管理器标签页中,找到不再受保护的受影响应用,然后查看每款应用的备份政策。 3. 如需创建新设备并将保护重新应用于未受保护的应用,请在 Google Cloud 控制台中转到“备份和灾难恢复”,然后选择“部署另一个备份或恢复设备”选项。4.在存储菜单中,为每台新设备配置存储目标。配置设备后,当您为应用创建配置文件时,该设备会显示为一个选项。
Impact: Google Cloud Backup and DR reduced backup expiration
事件威胁检测会检查审核日志以检测失效日期 备份和灾难恢复服务设备上的备份的使用量减小了。
如需响应此发现结果,请执行以下操作:
第 1 步:查看发现结果详情
- 按照查看发现结果中所述,打开
Impact: Google Cloud Backup and DR reduced backup expiration
发现结果。通过 相应发现结果的详情面板会打开摘要标签页。 - 在摘要标签页上,查看以下部分中的信息:
- 检测到的内容,尤其是以下字段:
- 说明:检测相关信息
- 主账号主体:已成功执行操作的用户或服务账号
- 受影响的资源
- 资源显示名称:备份将过期的项目 有所减少。
- 相关链接,尤其是以下字段:
- MITRE ATTACK 方法:指向 MITRE ATT&CK 文档的链接。
- Logging URI:用于打开 Logs Explorer 的链接。
- 检测到的内容,尤其是以下字段:
第 2 步:研究攻击和响应方法
在主账号主题字段中,与服务账号的所有者联系。 确认合法所有者是否执行了此操作。
第 3 步:实现响应
以下响应方案可能适合此发现结果。小心 评估您在调查过程中收集的信息,以确定最佳 解决发现结果的方法。
- 在执行操作的项目中,转到管理控制台。
- 在应用管理器标签页中,找到备份的受影响应用 缩短了过期时间,并验证过期日期是否符合 主账号。
- 如需为应用启动新的备份,请选择管理备份配置以创建按需备份或安排新的备份。
Impact: Google Cloud Backup and DR reduced backup frequency
Event Threat Detection 会检查审核日志,以检测是否已修改备份计划以降低备份频率。
如需响应此发现结果,请执行以下操作:
第 1 步:查看发现结果详情
- 打开
Impact: Google Cloud Backup and DR reduced backup frequency
详见查看发现结果。通过 相应发现结果的详情面板会打开摘要标签页。 - 在摘要标签页上,查看以下部分中的信息:
- 检测到的内容,尤其是以下字段:
- 说明:检测相关信息
- 主账号主体:已成功执行操作的用户或服务账号
- 受影响的资源
- 资源显示名称:缩减了备份频率的项目。
- 相关链接,尤其是以下字段:
- MITRE ATTACK 方法:指向 MITRE ATT&CK 文档的链接。
- Logging URI:用于打开 Logs Explorer 的链接。
- 检测到的内容,尤其是以下字段:
第 2 步:研究攻击和响应方法
在主账号主题字段中,与服务账号的所有者联系。 确认合法所有者是否执行了此操作。
第 3 步:实现响应
以下响应方案可能适合此发现结果。小心 评估您在调查过程中收集的信息,以确定最佳 解决发现结果的方法。
- 在执行操作的项目中,转到管理控制台。
- 在应用管理器标签页中,找到备份的受影响应用 频率已降低,并验证更改是否符合 主账号。
- 如需为应用启动新的备份,请选择管理备份配置以创建按需备份或安排新的备份。
Impact: Suspicious Kubernetes Container Names - Coin Mining
某位用户部署了一个 Pod,其命名惯例与常见的加密货币矿机类似。这可能是已获得对集群的初始访问权限的攻击者企图使用集群的资源进行加密货币挖矿。如需了解详情,请参阅此提醒的日志消息。
- 确认 Pod 是合法的。
- 确定是否存在来自 Pod 的其他恶意活动迹象,或 主账号。
- 如果主账号不是服务账号(IAM 或 Kubernetes),请与该账号的所有者联系,以确认合法所有者是否执行了相应操作。
- 如果主账号是服务账号(IAM 或 Kubernetes),请查明操作来源以确定其合法性。
- 如果 Pod 不合法,请将其移除,同时移除任何关联的 RBAC 绑定,以及工作负载使用的和允许其创建的服务账号。
Lateral Movement: Modified Boot Disk Attached to Instance
系统会检查审核日志,以检测 Compute Engine 实例资源之间是否存在可疑的磁盘移动。一个可能经过修改的启动磁盘已挂接到您的 Compute Engine。
第 1 步:查看发现结果详情
- 按照查看发现结果中所述,打开
Lateral Movement: Modify Boot Disk Attaching to Instance
发现结果。 系统会打开发现结果详情面板,以显示摘要标签页。 在摘要标签页上,记下以下字段的值。
在检测到的内容下:
- 主账号电子邮件地址:执行操作的服务账号
- 服务名称:服务账号访问的 Google Cloud 服务的 API 名称
- 方法名称:所调用的方法
第 2 步:研究攻击和响应方法
第 3 步:实现响应
以下响应方案可能适合此发现结果,但也可能会影响运营。请仔细评估您在研究中收集的信息,以确定解析发现结果的最佳方法。
- 与执行操作的项目的所有者联系。
- 建议将 安全启动 Compute Engine 虚拟机实例
- 考虑删除可能被盗用的服务账号,然后轮替和删除可能被破解的项目的所有服务账号访问密钥。删除后,使用该服务账号进行身份验证的应用会失去访问权限。在继续操作之前,您的安全团队应确定所有受影响的应用并与应用所有者合作,以确保业务连续性。
- 与您的安全团队合作,确定不熟悉的资源,包括 Compute Engine 实例、快照、服务账号和 IAM 用户。删除未使用已获授权的账号创建的资源。
- 回复来自 Google Cloud 支持的任何通知。
Privilege Escalation: AlloyDB Over-Privileged Grant
检测将 AlloyDB for PostgreSQL 数据库(或数据库中的所有函数或过程)的所有权限授予一个或多个数据库用户的情况。
如需响应此发现结果,请执行以下操作:
第 1 步:查看发现结果详情
- 按照查看发现结果中所述,打开
Privilege Escalation: AlloyDB Over-Privileged Grant
发现结果。 在发现结果详情面板的摘要标签页上,查看以下部分中的信息:
- 检测到的内容,尤其是以下字段:
- 数据库显示名称:受影响的 AlloyDB for PostgreSQL 实例中的数据库的名称。
- 数据库用户名:授予超额权限的 PostgreSQL 用户。
- 数据库查询:授予权限所执行的 PostgreSQL 查询。
- 数据库授权对象:超额权限的授权对象。
- 受影响的资源,尤其是以下字段:
- 资源全名:受影响的 AlloyDB for PostgreSQL 实例的资源名称。
- 父级全名:AlloyDB for PostgreSQL 的资源名称 实例。
- 项目全名:包含 AlloyDB for PostgreSQL 实例的 Google Cloud 项目。
- 相关链接,尤其是以下字段:
- Cloud Logging URI:指向 Logging 条目的链接。
- MITRE ATT&CK 方法:指向 MITRE ATT&CK 文档的链接。
- 检测到的内容,尤其是以下字段:
如需查看发现结果的完整 JSON,请点击 JSON 标签页。
第 2 步:查看数据库权限
第 3 步:检查日志
- 在 Google Cloud 控制台中,点击 Cloud Logging URI 中的链接(来自第 1 步),以前往日志浏览器。日志浏览器页面包含与相关 Cloud SQL 实例有关的所有日志。
- 在日志浏览器中,查看 PostgreSQL
pgaudit
日志,这些日志会记录 使用以下过滤条件对数据库执行的查询:protoPayload.request.database="var class="edit">database"
第 4 步:研究攻击和响应方法
- 查看此发现结果类型的 MITRE ATT&CK 框架条目: Web 服务渗漏。
- 如需确定是否需要执行额外的补救步骤,请将您的调查结果与 MITRE 研究相结合。
第 5 步:实现响应
以下响应计划可能适合此发现结果,但也可能会影响运营。 请仔细评估您在研究中收集的信息,以确定解析发现结果的最佳方法。
- 与过度授予权限的实例的所有者联系。
- 在调查完成之前,考虑撤消数据库授权对象中列出的授权对象的所有权限。
- 限制对数据库的访问(来自数据库显示名称/ 第 1 步: 不需要撤消 (来自以下对象的数据库受助人)的权限, 第 1 步。
Privilege Escalation: AlloyDB Database Superuser Writes to User Tables
检测 AlloyDB for PostgreSQL 数据库超级用户账号 (postgres
) 何时写入用户表。超级用户(具有非常广泛访问权限的角色)通常不应用于写入用户表。访问权限较为受限的用户账号
用于日常活动。当超级用户向用户执行写入操作时
表上,可能表示攻击者拥有升级的权限或
危害默认数据库用户并修改数据。它还可以
表明了正常但不安全的做法。
如需响应此发现结果,请执行以下操作:
第 1 步:查看发现结果详情
- 按照查看发现结果中所述,打开
Privilege Escalation: AlloyDB Database Superuser Writes to User Tables
发现结果。 在发现结果详情面板的摘要标签页上,查看以下部分中的信息:
- 检测到的内容,尤其是以下字段:
- 数据库显示名称:受影响的 AlloyDB for PostgreSQL 实例中的数据库的名称。
- 数据库用户名:超级用户。
- 数据库查询:写入用户表时执行的 SQL 查询。
- 受影响的资源,尤其是以下字段:
- 资源全名:受影响的 AlloyDB for PostgreSQL 实例的资源名称。
- 父级全名:AlloyDB for PostgreSQL 的资源名称 实例。
- 项目全名:包含 AlloyDB for PostgreSQL 实例的 Google Cloud 项目。
- 相关链接,尤其是以下字段:
- Cloud Logging URI:指向 Logging 条目的链接。
- MITRE ATT&CK 方法:指向 MITRE ATT&CK 文档的链接。
- 检测到的内容,尤其是以下字段:
如需查看发现结果的完整 JSON,请点击 JSON 标签页。
第 2 步:检查日志
- 在 Google Cloud 控制台中,点击
cloudLoggingQueryURI
(第 1 步)中的链接,以转到日志浏览器。日志浏览器页面包含与相关 AlloyDB for PostgreSQL 实例有关的所有日志。 - 检查 PostgreSQL pgaudit 日志的日志,其中包含查询
由超级用户通过下列过滤器执行:
protoPayload.request.user="postgres"
第 3 步:研究攻击和响应方法
- 查看此发现结果类型的 MITRE ATT&CK 框架条目: Web 服务渗漏。
- 如需确定是否需要执行额外的补救步骤,请将您的调查结果与 MITRE 研究相结合。
第 4 步:实现响应
以下响应方案可能适合此发现结果,但也可能会影响运营。请仔细评估您在研究中收集的信息,以确定解析发现结果的最佳方法。
- 查看允许连接到数据库的用户。
- 考虑更改超级用户的密码。
- 考虑新建访问权限受限的用户
了解实例使用的不同查询类型。
- 仅向新用户授予执行其查询所需的必要权限。
- 更新连接到 AlloyDB for PostgreSQL 实例的客户端的凭据
Compute Engine 管理员元数据检测
Persistence: GCE Admin Added SSH Key
说明 | 操作 | |
---|---|---|
在已建立的实例上更改了 ssh-keys Compute Engine 实例元数据键。 |
已在超过 7 天前创建的实例上修改了 Compute Engine 实例元数据键 ssh-keys 。验证更改是否是由成员有意进行的,或者是否是攻击者为引入对您的组织的新访问权限而实施的。 |
使用以下过滤条件检查日志:
替换以下内容:
|
触发此发现结果的研究事件: |
Persistence: GCE Admin Added Startup Script
说明 | 操作 | |
---|---|---|
在已建立的实例上更改了 startup-script 或 startup-script-url Compute Engine 实例元数据键。 |
已在超过 7 天前创建的实例上修改了 Compute Engine 实例元数据键 startup-script 或 startup-script-url 。验证更改是否是由成员有意进行的,或者是否是攻击者为引入对您的组织的新访问权限而实施的。 |
使用以下过滤条件检查日志:
替换以下内容:
|
触发此发现结果的研究事件: |
Google Workspace 日志检测
如果您与 Cloud Logging 共享 Google Workspace 日志,则 Event Threat Detection 会针对多个 Google Workspace 威胁生成发现结果。由于 Google Workspace 日志是组织级别的日志, 只有在您激活 Security Command Center 的情况下,事件威胁检测才能扫描它们 组织级别的权限。
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,则无法看到此发现结果。
说明 | 操作 | |
---|---|---|
管理员账号的“启用单点登录 (SSO)”设置已停用。 | 您的组织的单点登录设置发生了更改。验证更改是否是由成员有意进行的,或者是否是攻击者为引入对您的组织的新访问权限而实施的。 |
使用以下过滤条件检查日志:
替换以下内容:
|
触发此发现结果的研究事件: |
Persistence: SSO Settings Changed
如果您在项目级别激活 Security Command Center,则无法查看此发现结果。
说明 | 操作 | |
---|---|---|
管理员账号的 SSO 设置已更改。 | 您的组织的单点登录设置发生了更改。验证更改是否是由成员有意进行的,或者是否是攻击者为引入对您的组织的新访问权限而实施的。 |
使用以下过滤条件检查日志:
替换以下内容:
|
触发此发现结果的研究事件: |
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 账号的团队。您可以使用这些发现结果来表明账号可能遭到盗用。
Cloud IDS 威胁检测
Cloud IDS: THREAT_ID
Cloud IDS 发现结果 安全服务可监控进出您 用于应对威胁的 Google Cloud 资源。当 Cloud IDS 检测到 它会发送有关威胁的信息,如来源 IP 地址、 目的地地址和端口号发送到 Event Threat Detection,随后它会将 威胁发现。
第 1 步:查看发现结果详情
按照查看发现结果中所述,打开
Cloud IDS: THREAT_ID
发现结果。在发现结果详情的摘要标签页上,查看以下部分中列出的值:
- 检测到的内容,尤其是以下字段:
- 协议:使用的网络协议
- 事件时间:事件发生的时间
- 说明:有关相应发现的更多信息
- 严重程度:提醒的严重程度
- 目标 IP:网络流量的目标 IP
- 目标端口:网络流量的目标端口
- 来源 IP:网络流量的来源 IP
- 来源端口:网络流量的来源端口
- 受影响的资源,尤其是以下字段:
- 资源全名:存在威胁的网络的项目
- 相关链接,尤其是以下字段:
- Cloud Logging URI:指向 Cloud IDS Logging 的链接 条目 - 这些条目包含搜索的必要信息 Palo Alto Networks 威胁保险柜
- 检测服务
- 查找类别:Cloud IDS 威胁名称
- 检测到的内容,尤其是以下字段:
如需查看发现结果的完整 JSON,请点击 JSON 标签页。
第 2 步:查找攻击和响应方法
查看发现详情后,请参阅 Cloud IDS 文档中的“调查威胁提醒”部分,确定适当的响应措施。
您可以在原始日志中找到有关检测到的事件的更多信息 条目,方法是点击发现结果中 Cloud Logging URI 字段中的链接 。
Container Threat Detection 响应
如需详细了解 Container Threat Detection,请参阅 Container Threat Detection 的工作原理。
Added Binary Executed
执行了不属于原始容器映像的二进制文件。攻击者通常在刚开始入侵后安装漏洞工具和恶意软件。确保容器不可变是一项重要的最佳实践。这项发现的严重性较低,因为贵组织可能未遵循此最佳实践。还有相应的
Execution: Added Malicious Binary Executed
结果的
二进制文件是已知的失陷指标 (IoC)。为了回应此发现结果,
执行以下操作:
第 1 步:查看发现结果详情
按照查看发现结果中所述,打开
Added Binary Executed
发现结果。系统会打开发现结果详情面板,以显示摘要标签页。在摘要标签页上,查看以下部分中的信息:
- 检测到的内容,尤其是以下字段:
- 程序二进制文件:添加的二进制文件的绝对路径。
- 参数:调用添加的二进制文件时提供的参数。
- 受影响的资源,尤其是以下字段:
- 资源全名:集群的完整资源名称,其中包括项目编号、位置和集群名称。
- 检测到的内容,尤其是以下字段:
点击 JSON,并注意以下字段:
resource
:project_display_name
:包含集群的项目的名称。
sourceProperties
:Pod_Namespace
:Pod 的 Kubernetes 命名空间的名称。Pod_Name
:GKE Pod 的名称。Container_Name
:受影响的容器的名称。Container_Image_Uri
:要部署的容器映像的名称。VM_Instance_Name
:在其中执行 Pod 的 GKE 节点的名称。
识别在此容器的类似时间发生的其他发现结果。相关发现可能表明此活动是恶意的,而不是未遵循最佳实践。
第 2 步:查看集群和节点
在 Google Cloud 控制台中,转到 Kubernetes 集群页面。
如有必要,在 Google Cloud 控制台的工具栏中选择
resource.project_display_name
中列出的项目。选择发现结果详情摘要标签页中资源全名行上列出的集群。请记下有关集群及其所有者的所有元数据。
点击节点标签页。选择
VM_Instance_Name
中列出的节点。点击详细信息标签页,并记下
container.googleapis.com/instance_id
注解。
第 3 步:审核 Pod
在 Google Cloud 控制台中,转到 Kubernetes 工作负载页面。
如有必要,在 Google Cloud 控制台工具栏中选择
resource.project_display_name
中列出的项目。如有必要,对发现结果详情摘要标签页中资源全名行上列出的集群以及
Pod_Namespace
中列出的 Pod 命名空间进行过滤。选择
Pod_Name
中列出的 Pod。请记下有关 Pod 及其所有者的所有元数据。
第 4 步:检查日志
在 Google Cloud 控制台中,打开日志浏览器。
如有必要,在 Google Cloud 控制台的工具栏中选择
resource.project_display_name
中列出的项目。将选择时间范围设置为感兴趣的时间段。
在加载的页面上,执行以下操作:
- 使用以下过滤条件查找
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"
- 使用以下过滤条件查找集群审核日志:
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
- 使用以下过滤条件查找 GKE 节点控制台日志:
resource.type="gce_instance"
resource.labels.instance_id="instance_id"
- 使用以下过滤条件查找
第 5 步:检查正在运行的容器
如果容器仍在运行,则或许可以直接检查容器环境。
转到 Google Cloud 控制台。
如有必要,在 Google Cloud 控制台的工具栏中选择
resource.project_display_name
中列出的项目。点击激活 Cloud Shell
通过运行以下命令获取集群的 GKE 凭据。
对于可用区级集群:
gcloud container clusters get-credentials cluster_name --zone location --project project_name
对于地区级集群:
gcloud container clusters get-credentials cluster_name --region location --project project_name
替换以下内容:
cluster_name
:resource.labels.cluster_name
中列出的集群location
:resource.labels.location
中列出的位置project_name
:resource.project_display_name
中列出的项目名称
运行以下命令来检索添加的二进制文件:
kubectl cp Pod_Namespace/Pod_Name:Process_Binary_Fullpath -c Container_Name local_file
将
local_file
替换为本地文件路径,以存储添加的二进制文件。通过运行以下命令连接到容器环境:
kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
此命令要求容器在
/bin/sh
处安装 shell。
第 6 步:研究攻击和响应方法
- 查看以下发现结果类型的 MITRE ATT&CK 框架条目: Ingress 工具传输, 原生 API。
- 如需制定响应方案,请将您的调查结果与 MITRE 研究相结合。
第 7 步:实现响应
以下响应方案可能适合此发现结果,但也可能会影响运营。请仔细评估您在研究中收集的信息,以确定解析发现结果的最佳方法。
Added Library Loaded
已加载不属于原始容器映像的库。
攻击者可能会将恶意库加载到现有程序中,以绕过代码执行保护措施并隐藏恶意代码。确保容器不可变是一项重要的最佳实践。这项发现的严重性较低,因为贵组织可能未遵循此最佳实践。如果二进制文件的哈希值是已知的违规线索 (IoC),则会出现相应的 Execution: Added Malicious Library Loaded
发现结果。如需响应此发现结果,请执行以下操作:
第 1 步:查看发现结果详情
按照查看发现结果中所述,打开
Added Library Loaded
发现结果。系统会打开发现结果详情面板,以显示摘要标签页。在摘要标签页上,查看以下部分中的信息:
- 检测到的内容,尤其是以下字段:
- 程序二进制文件:加载 库。
- 库:有关添加的库的详细信息。
- 参数:调用进程二进制文件时提供的参数。
- 受影响的资源,尤其是以下字段:
- 资源全名:完整资源名称 集群的位置
- 检测到的内容,尤其是以下字段:
点击 JSON 标签页并注意以下字段:
resource
:project_display_name
:包含资产的项目的名称。
sourceProperties
:Pod_Namespace
:Pod 的 Kubernetes 命名空间的名称。Pod_Name
:GKE Pod 的名称。Container_Name
:受影响的容器的名称。Container_Image_Uri
:要执行的容器映像的名称。VM_Instance_Name
:在其中执行 Pod 的 GKE 节点的名称。
识别在此容器的类似时间发生的其他发现结果。相关发现可能表明此活动是恶意的,而不是未遵循最佳实践。
第 2 步:查看集群和节点
在 Google Cloud 控制台中,转到 Kubernetes 集群页面。
如有必要,在 Google Cloud 控制台工具栏中选择
resource.project_display_name
中列出的项目。选择
resource.name
中列出的集群。请记下有关集群及其所有者的所有元数据。点击节点标签页。选择
VM_Instance_Name
中列出的节点。点击详细信息标签页,并记下
container.googleapis.com/instance_id
注解。
第 3 步:审核 Pod
在 Google Cloud 控制台中,转到 Kubernetes 工作负载页面。
如有必要,在 Google Cloud 控制台工具栏中选择
resource.project_display_name
中列出的项目。如有必要,对发现结果详情摘要标签页中资源全名行上列出的集群以及
Pod_Namespace
中列出的 Pod 命名空间进行过滤。选择
Pod_Name
中列出的 Pod。请记下有关 Pod 及其所有者的所有元数据。
第 4 步:检查日志
在 Google Cloud 控制台中,打开日志浏览器。
如有必要,在 Google Cloud 控制台工具栏中选择
resource.project_display_name
中列出的项目。将选择时间范围设置为感兴趣的时间段。
在加载的页面上,执行以下操作:
- 使用以下过滤条件查找
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"
- 使用以下过滤条件查找集群审核日志:
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
- 使用以下过滤条件查找 GKE 节点控制台日志:
resource.type="gce_instance"
resource.labels.instance_id="instance_id"
- 使用以下过滤条件查找
第 5 步:检查正在运行的容器
如果容器仍在运行,则或许可以直接检查容器环境。
转到 Google Cloud 控制台。
如有必要,在 Google Cloud 控制台工具栏中选择
resource.project_display_name
中列出的项目。点击激活 Cloud Shell。
通过运行以下命令获取集群的 GKE 凭据。
对于可用区级集群:
gcloud container clusters get-credentials cluster_name --zone location --project resource.project_display_name
对于地区级集群:
gcloud container clusters get-credentials cluster_name --region location --project resource.project_display_name
运行以下命令来检索添加的库:
kubectl cp Pod_Namespace/Pod_Name: Added_Library_Fullpath -c Container_Name local_file
将 local_file 替换为本地文件路径,以存储添加的库。
通过运行以下命令连接到容器环境:
kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
此命令要求容器在
/bin/sh
处安装 shell。
第 6 步:研究攻击和响应方法
- 查看此发现结果类型的 MITRE ATT&CK 框架条目:Ingress Tool Transfer、Shared Modules。
- 如需制定响应方案,请将您的调查结果与 MITRE 研究相结合。
第 7 步:实现响应
以下响应方案可能适合此发现结果,但也可能会影响运营。请仔细评估您在研究中收集的信息,以确定解析发现结果的最佳方法。
Execution: Added Malicious Binary Executed
原始容器映像中未包含的恶意二进制文件 。攻击者通常在刚开始入侵后安装漏洞工具和恶意软件。如需响应此发现结果,请执行以下操作:
第 1 步:查看发现结果详情
按照查看发现结果中所述,打开
Execution: Added Malicious Binary Executed
发现结果。系统会打开发现结果详情面板,以显示摘要标签页。在摘要标签页上,查看以下部分中的信息:
- 检测到的内容,尤其是以下字段:
- 程序二进制文件:添加的二进制文件的绝对路径。
- 参数:调用添加的二进制文件时提供的参数。
- 容器:受影响容器的名称。
- 容器 URI:要部署的容器映像的名称。
- 受影响的资源,尤其是以下字段:
- 资源全名:集群的完整资源名称,其中包括项目编号、位置和集群名称。
- 相关链接,尤其是以下字段:
- VirusTotal 指示器:指向 VirusTotal 分析页面的链接。
- 检测到的内容,尤其是以下字段:
点击 JSON 标签页并注意以下字段:
sourceProperties
:VM_Instance_Name
:在其中执行 Pod 的 GKE 节点的名称。
第 2 步:查看集群和节点
在 Google Cloud 控制台中,转到 Kubernetes 集群页面。
如有必要,在 Google Cloud 控制台的工具栏中选择
resource.project_display_name
中列出的项目。选择发现结果详情摘要标签页中资源全名行上列出的集群。请记下有关集群及其所有者的所有元数据。
点击节点标签页。选择
VM_Instance_Name
中列出的节点。点击详细信息标签页,并记下
container.googleapis.com/instance_id
注解。
第 3 步:审核 Pod
在 Google Cloud 控制台中,转到 Kubernetes 工作负载页面。
如有必要,在 Google Cloud 控制台工具栏中选择
resource.project_display_name
中列出的项目。如有必要,对发现结果详情摘要标签页中资源全名行上列出的集群以及
Pod_Namespace
中列出的 Pod 命名空间进行过滤。选择
Pod_Name
中列出的 Pod。请记下有关 Pod 及其所有者的所有元数据。
第 4 步:检查日志
在 Google Cloud 控制台中,打开日志浏览器。
如有必要,在 Google Cloud 控制台的工具栏中选择
resource.project_display_name
中列出的项目。将选择时间范围设置为感兴趣的时间段。
在加载的页面上,执行以下操作:
- 使用以下过滤条件查找
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"
- 使用以下过滤条件查找集群审核日志:
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
- 使用以下过滤条件查找 GKE 节点控制台日志:
resource.type="gce_instance"
resource.labels.instance_id="instance_id"
- 使用以下过滤条件查找
第 5 步:检查正在运行的容器
如果容器仍在运行,则或许可以直接检查容器环境。
转到 Google Cloud 控制台。
如有必要,在 Google Cloud 控制台的工具栏中选择
resource.project_display_name
中列出的项目。点击激活 Cloud Shell
通过运行以下命令获取集群的 GKE 凭据。
对于可用区级集群:
gcloud container clusters get-credentials cluster_name --zone location --project project_name
对于地区级集群:
gcloud container clusters get-credentials cluster_name --region location --project project_name
替换以下内容:
cluster_name
:resource.labels.cluster_name
中列出的集群location
:resource.labels.location
中列出的位置project_name
:resource.project_display_name
中列出的项目名称
检索添加的恶意二进制文件:
kubectl cp Pod_Namespace/Pod_Name:Process_Binary_Fullpath -c Container_Name local_file
将
local_file
替换为本地路径,以存储添加的恶意二进制文件。连接到容器环境:
kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
此命令要求容器在
/bin/sh
处安装 shell。
第 6 步:研究攻击和响应方法
- 查看此发现结果类型的 MITRE ATT&CK 框架条目:Ingress Tool Transfer、Native API。
- 如需制定响应方案,请将您的调查结果与 MITRE 研究相结合。
- 检查被标记为恶意的二进制文件的 SHA-256 哈希值 VirusTotal(按 点击 VirusTotal 指示器中的链接。VirusTotal 是一项 Alphabet 自有服务,提供了有关潜在恶意文件、网址、网域和 IP 地址的上下文。
第 7 步:实现响应
以下响应方案可能适合此发现结果,但也可能会影响运营。请仔细评估您在研究中收集的信息,以确定解析发现结果的最佳方法。
Execution: Added Malicious Library Loaded
系统加载了一个不属于原始容器映像的恶意库。 攻击者可能会将恶意库加载到现有程序中,以绕过代码执行保护措施并隐藏恶意代码。如需响应此发现结果,请执行以下操作:
第 1 步:查看发现结果详情
按照查看发现结果中所述,打开
Execution: Added Malicious Library Loaded
发现结果。系统会打开发现结果详情面板,以显示摘要标签页。在摘要标签页上,查看以下部分中的信息:
- 检测到的内容,尤其是以下字段:
- 程序二进制文件:加载 库。
- 库:有关添加的库的详细信息。
- 参数:调用进程二进制文件时提供的参数。
- 容器:受影响容器的名称。
- 容器 URI:要部署的容器映像的名称。
- 受影响的资源,尤其是以下字段:
- 资源全名:完整资源名称 集群的位置
- 相关链接,尤其是以下字段:
- VirusTotal 指示器:指向 VirusTotal 分析页面的链接。
- 检测到的内容,尤其是以下字段:
点击 JSON 标签页并注意以下字段:
sourceProperties
:VM_Instance_Name
:在其中执行 Pod 的 GKE 节点的名称。
第 2 步:查看集群和节点
在 Google Cloud 控制台中,转到 Kubernetes 集群页面。
如有必要,在 Google Cloud 控制台工具栏中选择
resource.project_display_name
中列出的项目。选择发现结果详情摘要标签页中资源全名行上列出的集群。请记下有关集群及其所有者的所有元数据。
点击节点标签页。选择
VM_Instance_Name
中列出的节点。点击详细信息标签页,并记下
container.googleapis.com/instance_id
注解。
第 3 步:审核 Pod
在 Google Cloud 控制台中,转到 Kubernetes 工作负载页面。
如有必要,在 Google Cloud 控制台工具栏中选择
resource.project_display_name
中列出的项目。如有必要,对发现结果详情摘要标签页中资源全名行上列出的集群以及
Pod_Namespace
中列出的 Pod 命名空间进行过滤。选择
Pod_Name
中列出的 Pod。请记下有关 Pod 及其所有者的所有元数据。
第 4 步:检查日志
在 Google Cloud 控制台中,打开日志浏览器。
如有必要,在 Google Cloud 控制台工具栏中选择
resource.project_display_name
中列出的项目。将选择时间范围设置为感兴趣的时间段。
在加载的页面上,执行以下操作:
- 使用以下过滤条件查找
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"
- 使用以下过滤条件查找集群审核日志:
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
- 使用以下过滤条件查找 GKE 节点控制台日志:
resource.type="gce_instance"
resource.labels.instance_id="instance_id"
- 使用以下过滤条件查找
第 5 步:检查正在运行的容器
如果容器仍在运行,则或许可以直接检查容器环境。
转到 Google Cloud 控制台。
如有必要,在 Google Cloud 控制台工具栏中选择
resource.project_display_name
中列出的项目。点击激活 Cloud Shell。
通过运行以下命令获取集群的 GKE 凭据。
对于可用区级集群:
gcloud container clusters get-credentials cluster_name --zone location --project resource.project_display_name
对于地区级集群:
gcloud container clusters get-credentials cluster_name --region location --project resource.project_display_name
检索添加的恶意库:
kubectl cp Pod_Namespace/Pod_Name: Added_Library_Fullpath -c Container_Name local_file
将 local_file 替换为用于存储添加的恶意内容的本地路径 库。
连接到容器环境:
kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
此命令要求容器在
/bin/sh
处安装 shell。
第 6 步:研究攻击和响应方法
- 查看以下发现结果类型的 MITRE ATT&CK 框架条目: Ingress 工具传输, 共享模块。
- 如需制定响应方案,请将您的调查结果与 MITRE 研究相结合。
- 点击 VirusTotal 指示器中的链接,检查 VirusTotal 上被标记为恶意的库的 SHA-256 哈希值。VirusTotal 是一项 Alphabet 自有服务,提供了有关潜在恶意文件、网址、网域和 IP 地址的上下文。
第 7 步:实现响应
以下响应方案可能适合此发现结果,但也可能会影响运营。请仔细评估您在研究中收集的信息,以确定解析发现结果的最佳方法。
Execution: Built in Malicious Binary Executed
已执行的二进制文件,其二进制文件:
- 包含在原始容器映像中。
- 根据威胁情报被识别为恶意。
攻击者可以控制容器映像存储库或创建流水线, 其中恶意二进制文件被注入容器映像。如需响应此发现结果,请执行以下操作:
第 1 步:查看发现结果详情
按照查看发现结果中所述,打开
Execution: Built in Malicious Binary Executed
发现结果。系统会打开发现结果详情面板,以显示摘要标签页。在摘要标签页上,查看以下部分中的信息:
- 检测到的内容,尤其是以下字段:
- 程序二进制文件:内置二进制文件的绝对路径。
- 参数:调用内置二进制文件时提供的参数。
- 容器:受影响容器的名称。
- 容器 URI:要部署的容器映像的名称。
- 受影响的资源,尤其是以下字段:
- 资源全名:集群的完整资源名称,其中包括项目编号、位置和集群名称。
- 相关链接,尤其是以下字段:
- VirusTotal 指示器:指向 VirusTotal 分析页面的链接。
- 检测到的内容,尤其是以下字段:
点击 JSON,并注意以下字段:
sourceProperties
:VM_Instance_Name
:在其中执行 Pod 的 GKE 节点的名称。
第 2 步:查看集群和节点
在 Google Cloud 控制台中,转到 Kubernetes 集群页面。
如有必要,在 Google Cloud 控制台的工具栏中选择
resource.project_display_name
中列出的项目。选择发现结果详情摘要标签页中资源全名行上列出的集群。请记下有关集群及其所有者的所有元数据。
点击节点标签页。选择
VM_Instance_Name
中列出的节点。点击详细信息标签页,并记下
container.googleapis.com/instance_id
注解。
第 3 步:审核 Pod
在 Google Cloud 控制台中,转到 Kubernetes 工作负载页面。
如有必要,在 Google Cloud 控制台工具栏中选择
resource.project_display_name
中列出的项目。如有必要,对发现结果详情摘要标签页中资源全名行上列出的集群以及
Pod_Namespace
中列出的 Pod 命名空间进行过滤。选择
Pod_Name
中列出的 Pod。请记下有关 Pod 及其所有者的所有元数据。
第 4 步:检查日志
在 Google Cloud 控制台中,打开日志浏览器。
如有必要,在 Google Cloud 控制台的工具栏中选择
resource.project_display_name
中列出的项目。将选择时间范围设置为感兴趣的时间段。
在加载的页面上,执行以下操作:
- 使用以下过滤条件查找
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"
- 使用以下过滤条件查找集群审核日志:
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
- 使用以下过滤条件查找 GKE 节点控制台日志:
resource.type="gce_instance"
resource.labels.instance_id="instance_id"
- 使用以下过滤条件查找
第 5 步:检查正在运行的容器
如果容器仍在运行,则或许可以直接检查容器环境。
转到 Google Cloud 控制台。
如有必要,在 Google Cloud 控制台的工具栏中选择
resource.project_display_name
中列出的项目。点击激活 Cloud Shell
通过运行以下命令获取集群的 GKE 凭据。
对于可用区级集群:
gcloud container clusters get-credentials cluster_name --zone location --project project_name
对于地区级集群:
gcloud container clusters get-credentials cluster_name --region location --project project_name
替换以下内容:
cluster_name
:resource.labels.cluster_name
中列出的集群location
:resource.labels.location
中列出的位置project_name
:resource.project_display_name
中列出的项目名称
检索内置的恶意二进制文件:
kubectl cp Pod_Namespace/Pod_Name:Process_Binary_Fullpath -c Container_Name local_file
将
local_file
替换为用于存储内置锡恶意二进制文件的本地路径。连接到容器环境:
kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
此命令要求容器在
/bin/sh
处安装 shell。
第 6 步:研究攻击和响应方法
- 查看此发现结果类型的 MITRE ATT&CK 框架条目:Ingress Tool Transfer、Native API。
- 如需制定响应方案,请将您的调查结果与 MITRE 研究相结合。
- 检查被标记为恶意的二进制文件的 SHA-256 哈希值 VirusTotal(按 点击 VirusTotal 指示器中的链接。VirusTotal 是一项 Alphabet 自有服务,提供了有关潜在恶意文件、网址、网域和 IP 地址的上下文。
第 7 步:实现响应
以下响应方案可能适合此发现结果,但也可能会影响运营。请仔细评估您在研究中收集的信息,以确定解析发现结果的最佳方法。
Execution: Malicious Python executed
机器学习模型将执行 Python 代码识别为恶意代码。 攻击者可以使用 Python 传输工具以及执行没有二进制文件的命令。确保容器不可变是一项重要的最佳做法。 使用脚本转移工具可能会模仿攻击者的入侵工具传输技术,从而导致不必要的检测。
如需响应此发现结果,请执行以下操作:
第 1 步:查看发现结果详情
按照查看发现结果中所述,打开
Execution: Malicious Python executed
发现结果。系统会打开发现结果详情面板,以显示摘要标签页。在摘要标签页上,查看以下部分中的信息:
- 检测到的内容,尤其是以下字段:
- 程序二进制文件:有关调用脚本的解释器的详细信息。
- Script:磁盘上脚本名称的绝对路径;这个
属性仅针对写入磁盘的脚本显示,而不针对字面量显示
脚本执行 - 例如
python3 -c
。 - 参数:调用脚本时提供的参数。
- 受影响的资源,尤其是以下字段:
- 资源全名:集群的完整资源名称,其中包括项目编号、位置和集群名称
- 检测到的内容,尤其是以下字段:
在发现结果的详情视图中,点击 JSON 标签页。
在 JSON 中,记下以下字段。
finding
:processes
:script
:contents
:已执行脚本的内容,由于性能原因,内容可能会被截断;这有助于进行调查sha256
:script.contents
的 SHA-256 哈希
resource
:project_display_name
:包含资产的项目的名称。
sourceProperties
:Pod_Namespace
:Pod 的 Kubernetes 命名空间的名称。Pod_Name
:GKE Pod 的名称。Container_Name
:受影响的容器的名称。Container_Image_Uri
:要执行的容器映像的名称。VM_Instance_Name
:在其中执行 Pod 的 GKE 节点的名称。
识别在此容器的类似时间发生的其他发现结果。例如,如果脚本删除了二进制文件,请检查是否有与该二进制文件相关的发现。
第 2 步:查看集群和节点
在 Google Cloud 控制台中,转到 Kubernetes 集群页面。
如有必要,在 Google Cloud 控制台的工具栏中选择
resource.project_display_name
中列出的项目。选择发现结果详情摘要标签页中资源全名行上列出的集群。请记下有关集群及其所有者的所有元数据。
点击节点标签页。选择
VM_Instance_Name
中列出的节点。点击详细信息标签页,并记下
container.googleapis.com/instance_id
注解。
第 3 步:审核 Pod
在 Google Cloud 控制台中,转到 Kubernetes 工作负载页面。
如有必要,在 Google Cloud 控制台的工具栏中选择
resource.project_display_name
中列出的项目。如有必要,对
resource.name
中列出的集群和Pod_Namespace
中列出的 Pod 命名空间进行过滤。选择
Pod_Name
中列出的 Pod。请记下有关 Pod 及其所有者的所有元数据。
第 4 步:检查日志
在 Google Cloud 控制台中,打开日志浏览器。
如有必要,在 Google Cloud 控制台工具栏中选择
resource.project_display_name
中列出的项目。将选择时间范围设置为感兴趣的时间段。
在加载的页面上,执行以下操作:
- 使用以下过滤条件查找
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"
- 使用以下过滤条件查找集群审核日志:
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
- 使用以下过滤条件查找 GKE 节点控制台日志:
resource.type="gce_instance"
resource.labels.instance_id="instance_id"
- 使用以下过滤条件查找
第 5 步:检查正在运行的容器
如果容器仍在运行,则或许可以直接检查容器环境。
在 Google Cloud 控制台中,转到 Kubernetes 集群页面。
点击
resource.labels.cluster_name
中显示的集群的名称。在集群页面上,点击连接,然后点击在 Cloud Shell 中运行。
Cloud Shell 将在终端中为集群启动和添加命令。
按 Enter 键。如果系统显示授权 Cloud Shell 对话框, 点击授权。
通过运行以下命令连接到容器环境:
kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
此命令要求容器在
/bin/sh
处安装 shell。
第 6 步:研究攻击和响应方法
- 查看此发现类型的 MITRE ATT&CK 框架条目:Command and Scripting Interpreter、Ingress Tool Transfer。
- 如需制定响应方案,请将您的调查结果与 MITRE 研究相结合。
第 7 步:实现响应
以下响应方案可能适合此发现结果,但也可能会影响运营。请仔细评估您在研究中收集的信息,以确定解析发现结果的最佳方法。
- 如果 Python 对容器进行了预期更改,请重新构建容器映像,以免需要进行任何更改。这样,容器就可以是不可变的。
- 否则,请与容器遭到入侵的项目的所有者联系。
- 停止或删除遭入侵的容器,并将其替换为新容器。
Execution: Modified Malicious Binary Executed
已执行的二进制文件,其中包含以下二进制文件:
- 包含在原始容器映像中。
- 在容器运行时期间修改。
- 根据威胁情报识别为恶意内容。
攻击者通常在刚开始入侵后安装漏洞工具和恶意软件。如需响应此发现结果,请执行以下操作:
第 1 步:查看发现结果详情
按照查看发现结果中所述,打开
Execution: Modified Malicious Binary Executed
发现结果。系统会打开发现结果详情面板,以显示摘要标签页。在摘要标签页上,查看以下部分中的信息:
- 检测到的内容,尤其是以下字段:
- 程序二进制文件:修改后的二进制文件的绝对路径。
- 参数:调用修改后的二进制文件时提供的参数。
- 容器:受影响容器的名称。
- 容器 URI:要部署的容器映像的名称。
- 受影响的资源,尤其是以下字段:
- 资源全名:集群的完整资源名称,其中包括项目编号、位置和集群名称。
- 相关链接,尤其是以下字段:
- VirusTotal 指示器:指向 VirusTotal 分析页面的链接。
- 检测到的内容,尤其是以下字段:
点击 JSON,并注意以下字段:
sourceProperties
:VM_Instance_Name
:在其中执行 Pod 的 GKE 节点的名称。
第 2 步:查看集群和节点
在 Google Cloud 控制台中,转到 Kubernetes 集群页面。
如有必要,在 Google Cloud 控制台的工具栏中选择
resource.project_display_name
中列出的项目。选择发现结果详情摘要标签页中资源全名行上列出的集群。请记下有关集群及其所有者的所有元数据。
点击节点标签页。选择
VM_Instance_Name
中列出的节点。点击详细信息标签页,并记下
container.googleapis.com/instance_id
注解。
第 3 步:审核 Pod
在 Google Cloud 控制台中,转到 Kubernetes 工作负载页面。
如有必要,在 Google Cloud 控制台工具栏中选择
resource.project_display_name
中列出的项目。如有必要,对发现结果详情摘要标签页中资源全名行上列出的集群以及
Pod_Namespace
中列出的 Pod 命名空间进行过滤。选择
Pod_Name
中列出的 Pod。请记下有关 Pod 及其所有者的所有元数据。
第 4 步:检查日志
在 Google Cloud 控制台中,打开日志浏览器。
如有必要,在 Google Cloud 控制台的工具栏中选择
resource.project_display_name
中列出的项目。将选择时间范围设置为感兴趣的时间段。
在加载的页面上,执行以下操作:
- 使用以下过滤条件查找
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"
- 使用以下过滤条件查找集群审核日志:
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
- 使用以下过滤条件查找 GKE 节点控制台日志:
resource.type="gce_instance"
resource.labels.instance_id="instance_id"
- 使用以下过滤条件查找
第 5 步:检查正在运行的容器
如果容器仍在运行,则或许可以直接检查容器环境。
转到 Google Cloud 控制台。
如有必要,在 Google Cloud 控制台的工具栏中选择
resource.project_display_name
中列出的项目。点击激活 Cloud Shell
通过运行以下命令获取集群的 GKE 凭据。
对于可用区级集群:
gcloud container clusters get-credentials cluster_name --zone location --project project_name
对于地区级集群:
gcloud container clusters get-credentials cluster_name --region location --project project_name
替换以下内容:
cluster_name
:resource.labels.cluster_name
中列出的集群location
:resource.labels.location
中列出的位置project_name
:resource.project_display_name
中列出的项目名称
检索修改后的恶意二进制文件:
kubectl cp Pod_Namespace/Pod_Name:Process_Binary_Fullpath -c Container_Name local_file
将
local_file
替换为用于存储经过修改的恶意二进制文件的本地路径。连接到容器环境:
kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
此命令要求容器在
/bin/sh
处安装 shell。
第 6 步:研究攻击和响应方法
- 查看此发现结果类型的 MITRE ATT&CK 框架条目:Ingress Tool Transfer、Native API。
- 如需制定响应方案,请将您的调查结果与 MITRE 研究相结合。
- 检查被标记为恶意的二进制文件的 SHA-256 哈希值 VirusTotal(按 点击 VirusTotal 指示器中的链接。VirusTotal 是一项 Alphabet 自有服务,提供了有关潜在恶意文件、网址、网域和 IP 地址的上下文。
第 7 步:实现响应
以下响应方案可能适合此发现结果,但也可能会影响运营。请仔细评估您在研究中收集的信息,以确定解析发现结果的最佳方法。
Execution: Modified Malicious Library Loaded
已加载的库,其中包含以下内容:
- 包含在原始容器映像中。
- 在容器运行时期间修改。
- 根据威胁情报识别为恶意内容。
攻击者可能会将恶意库加载到现有程序中,以绕过代码执行保护措施并隐藏恶意代码。如需响应此发现结果,请执行以下操作:
第 1 步:查看发现结果详情
按照查看发现结果中所述,打开
Execution: Modified Malicious Library Loaded
发现结果。系统会打开发现结果详情面板,以显示摘要标签页。在摘要标签页上,查看以下部分中的信息:
- 检测到的内容,尤其是以下字段:
- 程序二进制文件:加载库的进程二进制文件的完整路径。
- 库:关于修改后的库的详细信息。
- 参数:调用进程二进制文件时提供的参数。
- 容器:受影响容器的名称。
- 容器 URI:要部署的容器映像的名称。
- 受影响的资源,尤其是以下字段:
- 资源全名:集群的完整资源名称。
- 相关链接,尤其是以下字段:
- VirusTotal 指示器:指向 VirusTotal 分析页面的链接。
- 检测到的内容,尤其是以下字段:
点击 JSON 标签页并注意以下字段:
sourceProperties
:VM_Instance_Name
:在其中执行 Pod 的 GKE 节点的名称。
第 2 步:查看集群和节点
在 Google Cloud 控制台中,转到 Kubernetes 集群页面。
如有必要,在 Google Cloud 控制台工具栏中选择
resource.project_display_name
中列出的项目。选择
resource.name
中列出的集群。请记下有关集群及其所有者的所有元数据。点击节点标签页。选择
VM_Instance_Name
中列出的节点。点击详细信息标签页,并记下
container.googleapis.com/instance_id
注解。
第 3 步:审核 Pod
在 Google Cloud 控制台中,转到 Kubernetes 工作负载页面。
如有必要,在 Google Cloud 控制台工具栏中选择
resource.project_display_name
中列出的项目。如有必要,对发现结果详情摘要标签页中资源全名行上列出的集群以及
Pod_Namespace
中列出的 Pod 命名空间进行过滤。选择
Pod_Name
中列出的 Pod。请记下有关 Pod 及其所有者的所有元数据。
第 4 步:检查日志
在 Google Cloud 控制台中,打开日志浏览器。
如有必要,在 Google Cloud 控制台工具栏中选择
resource.project_display_name
中列出的项目。将选择时间范围设置为感兴趣的时间段。
在加载的页面上,执行以下操作:
- 使用以下过滤条件查找
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"
- 使用以下过滤条件查找集群审核日志:
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
- 使用以下过滤条件查找 GKE 节点控制台日志:
resource.type="gce_instance"
resource.labels.instance_id="instance_id"
- 使用以下过滤条件查找
第 5 步:检查正在运行的容器
如果容器仍在运行,则或许可以直接检查容器环境。
转到 Google Cloud 控制台。
如有必要,在 Google Cloud 控制台工具栏中选择
resource.project_display_name
中列出的项目。点击激活 Cloud Shell。
通过运行以下命令获取集群的 GKE 凭据。
对于可用区级集群:
gcloud container clusters get-credentials cluster_name --zone location --project resource.project_display_name
对于地区级集群:
gcloud container clusters get-credentials cluster_name --region location --project resource.project_display_name
检索修改后的恶意库:
kubectl cp Pod_Namespace/Pod_Name: Added_Library_Fullpath -c Container_Name local_file
将 local_file 替换为存储已修改的恶意文件的本地路径 库。
连接到容器环境:
kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
此命令要求容器在
/bin/sh
处安装 shell。
第 6 步:研究攻击和响应方法
- 查看此发现结果类型的 MITRE ATT&CK 框架条目:Ingress Tool Transfer、Shared Modules。
- 如需制定响应方案,请将您的调查结果与 MITRE 研究相结合。
- 点击 VirusTotal 指示器中的链接,检查 VirusTotal 上被标记为恶意的库的 SHA-256 哈希值。VirusTotal 是一项 Alphabet 自有服务,提供了有关潜在恶意文件、网址、网域和 IP 地址的上下文。
第 7 步:实现响应
以下响应方案可能适合此发现结果,但也可能会影响运营。请仔细评估您在研究中收集的信息,以确定解析发现结果的最佳方法。
Malicious Script Executed
机器学习模型将执行的 Bash 代码识别为恶意代码。 攻击者可以利用 Bash 来转移工具,并在不使用二进制文件的情况下执行命令。确保容器不可变是一项重要的最佳做法。 使用脚本转移工具可能会模仿攻击者的入侵工具传输技术,导致不必要的检测。
如需响应此发现结果,请执行以下操作:
第 1 步:查看发现结果详情
按照查看发现结果中所述,打开
Malicious Script Executed
发现结果。系统会打开发现结果详情面板,以显示摘要标签页。在摘要标签页上,查看以下部分中的信息:
- 检测到的内容,尤其是以下字段:
- 程序二进制文件:有关调用脚本的解释器的详细信息。
- 脚本:磁盘上的脚本名称的绝对路径;此属性仅会针对写入磁盘的脚本显示,不会针对字面量脚本执行显示,例如
bash -c
。 - 参数:调用脚本时提供的参数。
- 受影响的资源,尤其是以下字段:
- 资源全名:集群的完整资源名称,其中包括项目编号、位置和集群名称
- 检测到的内容,尤其是以下字段:
在发现结果的详情视图中,点击 JSON 标签页。
在 JSON 中,记下以下字段。
finding
:processes
:script
:contents
:已执行脚本的内容,由于性能原因,内容可能会被截断;这有助于进行调查sha256
:script.contents
的 SHA-256 哈希
resource
:project_display_name
:包含资产的项目的名称。
sourceProperties
:Pod_Namespace
:Pod 的 Kubernetes 命名空间的名称。Pod_Name
:GKE Pod 的名称。Container_Name
:受影响的容器的名称。Container_Image_Uri
:要执行的容器映像的名称。VM_Instance_Name
:在其中执行 Pod 的 GKE 节点的名称。
识别在此容器的类似时间发生的其他发现结果。例如,如果脚本删除了二进制文件,请检查是否有与该二进制文件相关的发现。
第 2 步:查看集群和节点
在 Google Cloud 控制台中,转到 Kubernetes 集群页面。
如有必要,在 Google Cloud 控制台的工具栏中选择
resource.project_display_name
中列出的项目。选择发现结果详情摘要标签页中资源全名行上列出的集群。请记下有关集群及其所有者的所有元数据。
点击节点标签页。选择
VM_Instance_Name
中列出的节点。点击详细信息标签页,并记下
container.googleapis.com/instance_id
注解。
第 3 步:审核 Pod
在 Google Cloud 控制台中,转到 Kubernetes 工作负载页面。
如有必要,在 Google Cloud 控制台的工具栏中选择
resource.project_display_name
中列出的项目。如有必要,对
resource.name
中列出的集群和Pod_Namespace
中列出的 Pod 命名空间进行过滤。选择
Pod_Name
中列出的 Pod。请记下有关 Pod 及其所有者的所有元数据。
第 4 步:检查日志
在 Google Cloud 控制台中,打开日志浏览器。
如有必要,在 Google Cloud 控制台工具栏中选择
resource.project_display_name
中列出的项目。将选择时间范围设置为感兴趣的时间段。
在加载的页面上,执行以下操作:
- 使用以下过滤条件查找
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"
- 使用以下过滤条件查找集群审核日志:
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
- 使用以下过滤条件查找 GKE 节点控制台日志:
resource.type="gce_instance"
resource.labels.instance_id="instance_id"
- 使用以下过滤条件查找
第 5 步:检查正在运行的容器
如果容器仍在运行,则或许可以直接检查容器环境。
在 Google Cloud 控制台中,转到 Kubernetes 集群页面。
点击
resource.labels.cluster_name
中显示的集群的名称。在集群页面上,点击连接,然后点击在 Cloud Shell 中运行。
Cloud Shell 将在终端中为集群启动和添加命令。
按 Enter 键,如果出现为 Cloud Shell 提供授权对话框,请点击授权。
通过运行以下命令连接到容器环境:
kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
此命令要求容器在
/bin/sh
处安装 shell。
第 6 步:研究攻击和响应方法
- 查看以下发现结果类型的 MITRE ATT&CK 框架条目: 命令和脚本解释器 Ingress 工具传输。
- 如需制定响应方案,请将您的调查结果与 MITRE 研究相结合。
第 7 步:实现响应
以下响应方案可能适合此发现结果,但也可能会影响运营。请仔细评估您在研究中收集的信息,以确定解析发现结果的最佳方法。
Malicious URL Observed
Container Threat Detection 在可执行进程的参数列表中观察到恶意网址。攻击者可以加载恶意软件或恶意库 通过恶意网址访问
如需对此发现结果采取措施,请执行以下步骤。
第 1 步:查看发现结果详情
按照查看发现结果中所述,打开
Malicious URL Observed
发现结果。系统会打开发现结果详情面板,以显示摘要标签页。在摘要标签页上,查看以下部分中的信息:
- 检测到的内容,尤其是以下字段:
- URI:观察到的恶意 URI。
- 添加的二进制文件:接收包含恶意网址的参数的进程二进制文件的完整路径。
- 参数:调用进程二进制文件时提供的参数。
- 环境变量:调用进程二进制文件时有效的环境变量。
- 容器:容器的名称。
- Kubernetes Pod:Pod 名称和命名空间。
- 受影响的资源,尤其是以下字段:
- 资源显示名称:受影响资源的名称。
- 资源全名:完整资源名称
集群的位置完整资源名称包含以下内容:
信息:
- 包含集群的项目:
projects/PROJECT_ID
- 集群所在的位置:
zone/ZONE
或locations/LOCATION
- 集群的名称:
projects/CLUSTER_NAME
- 包含集群的项目:
- 检测到的内容,尤其是以下字段:
在 JSON 标签页上的
sourceProperties
特性中,记下VM_Instance_Name
属性的值。
第 2 步:查看集群和节点
在 Google Cloud 控制台中,转到 Kubernetes 集群页面。
如有必要,在 Google Cloud 控制台工具栏上,选择资源全名 (
resource.name
) 中显示的项目。项目名称显示在完整资源名称中的/projects/
之后。点击您在发现结果摘要的资源显示名称 (
resource.display_name
) 中记下的集群名称。集群页面随即会打开。在“集群详情”页面的“元数据”部分中,记下可能有助于解决威胁的任何用户定义信息,例如标识集群所有者的信息。
点击“节点”标签页。
从列出的节点中,选择与您之前在发现结果 JSON 中记下的
VM_Instance_Name
的值匹配的节点。在节点详情页面的详情标签页上的注解部分中,记下
container.googleapis.com/instance_id
注解的值。
第 3 步:审核 Pod
在 Google Cloud 控制台中,转到 Kubernetes 工作负载页面。
如有必要,在 Google Cloud 控制台工具栏上,选择您在发现结果摘要的集群的资源全名 (
resource.name
) 中记下的项目。点击显示系统工作负载。
根据您在发现结果摘要的资源全名 (
resource.name
) 中记下的集群名称以及(如有必要)您记下的 pod 命名空间 (kubernetes.pods.ns
) 过滤工作负载列表。点击与
VM_Instance_Name
的值匹配的工作负载名称 属性。Pod 详情页面随即会打开。在 Pod 详情页面上,记下可能有助于您解决威胁的有关 Pod 的任何信息。
第 4 步:检查日志
在 Google Cloud 控制台中,打开日志浏览器。
如有必要,在 Google Cloud 控制台工具栏上,选择资源全名 (
resource.name
) 中显示的项目。将选择时间范围设置为感兴趣的时间段。
在加载的页面上,执行以下操作:
- 使用以下过滤条件查找 pod
kubernetes.pods.name
的 Pod 日志:resource.type="k8s_container"
resource.labels.project_id="PROJECT_ID"
resource.labels.location="LOCATION"
resource.labels.cluster_name="CLUSTER_NAME"
resource.labels.namespace_name="NAMESPACE_NAME"
resource.labels.pod_name="POD_NAME"
- 使用以下过滤条件查找集群审核日志:
logName="projects/PROJECT_NAME/logs/cloudaudit.googleapis.com%2Factivity"
resource.type="k8s_cluster"
resource.labels.project_id="PROJECT_ID"
resource.labels.location="LOCATION_OR_ZONE"
resource.labels.cluster_name="CLUSTER_NAME/var>"
POD_NAME
- 使用以下过滤条件查找 GKE 节点控制台日志:
resource.type="gce_instance"
resource.labels.instance_id="INSTANCE_ID"
- 使用以下过滤条件查找 pod
第 5 步:调查正在运行的容器
如果容器仍在运行,则或许可以直接检查容器环境。
在 Google Cloud 控制台中,转到 Kubernetes 集群页面。
点击
resource.labels.cluster_name
中显示的集群的名称。在集群页面上,点击连接,然后点击在 Cloud Shell 中运行。
Cloud Shell 将在终端中为集群启动和添加命令。
按 Enter 键,如果出现为 Cloud Shell 提供授权对话框,请点击授权。
通过运行以下命令连接到容器环境:
kubectl exec --namespace=POD_NAMESPACE -ti POD_NAME -c CONTAINER_NAME -- /bin/sh
将
CONTAINER_NAME
替换为您之前在发现结果摘要中记下的容器的名称。此命令要求容器在
/bin/sh
处安装 shell。
第 6 步:研究攻击和响应方法
- 查看安全浏览网站状态,详细了解网址被归类为恶意网址的原因。
- 查看以下发现结果类型的 MITRE ATT&CK 框架条目:Ingress Tools Transfer。
- 如需制定响应方案,请将您的调查结果与 MITRE 研究相结合。
第 7 步:实现响应
以下响应方案可能适合此发现结果,但也可能会影响运营。请仔细评估您在研究中收集的信息,以确定解析发现结果的最佳方法。
Reverse Shell
通过流式传输重定向到远程连接的套接字的过程。如果大量生成网络连接的 shell,则攻击者可能会在有限的初始入侵后执行任意操作。如需响应此发现结果,请执行以下操作:
第 1 步:查看发现结果详情
按照查看发现结果中所述,打开
Reverse Shell
发现结果。系统会打开发现结果详情面板,以显示摘要标签页。在摘要标签页上,查看以下部分中的信息:
- 检测到的内容,尤其是以下字段:
- 程序二进制文件:在流重定向到远程套接字时启动的进程的绝对路径。
- 参数:调用进程二进制文件时提供的参数。
- 受影响的资源,尤其是以下字段:
- 资源全名:完整资源名称 集群的位置
- 项目全名:
- 在发现结果的详情视图中,点击 JSON 标签页。
- 在 JSON 中,请注意以下字段。
resource
:project_display_name
:包含资产的项目的名称。
sourceProperties
:Pod_Namespace
:Pod 的 Kubernetes 命名空间的名称。Pod_Name
:GKE Pod 的名称。Container_Name
:受影响的容器的名称。VM_Instance_Name
:在其中执行 Pod 的 GKE 节点的名称。Reverse_Shell_Stdin_Redirection_Dst_Ip
:连接的远程 IP 地址Reverse_Shell_Stdin_Redirection_Dst_Port
:远程端口Reverse_Shell_Stdin_Redirection_Src_Ip
:连接的本地 IP 地址Reverse_Shell_Stdin_Redirection_Src_Port
:本地端口Container_Image_Uri
:要执行的容器映像的名称。
- 检测到的内容,尤其是以下字段:
第 2 步:查看集群和节点
在 Google Cloud 控制台中,转到 Kubernetes 集群页面。
如有必要,在 Google Cloud 控制台工具栏中选择
resource.project_display_name
中列出的项目。选择
resource.name
中列出的集群。请记下有关集群及其所有者的所有元数据。点击节点标签页。选择
VM_Instance_Name
中列出的节点。点击详细信息标签页,并记下
container.googleapis.com/instance_id
注解。
第 3 步:审核 Pod
在 Google Cloud 控制台中,转到 Kubernetes 工作负载页面。
如有必要,在 Google Cloud 控制台工具栏中选择
resource.project_display_name
中列出的项目。如有必要,对
resource.name
中列出的集群和Pod_Namespace
中列出的 Pod 命名空间进行过滤。选择
Pod_Name
中列出的 Pod。请记下有关 Pod 及其所有者的所有元数据。
第 4 步:检查日志
在 Google Cloud 控制台中,打开日志浏览器。
如有必要,在 Google Cloud 控制台工具栏中选择
resource.project_display_name
中列出的项目。将选择时间范围设置为感兴趣的时间段。
在加载的页面上,执行以下操作:
- 使用以下过滤条件查找
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"
- 使用以下过滤条件查找集群审核日志:
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
- 使用以下过滤条件查找 GKE 节点控制台日志:
resource.type="gce_instance"
resource.labels.instance_id="instance_id"
- 使用以下过滤条件查找
第 5 步:检查正在运行的容器
如果容器仍在运行,则或许可以直接检查容器环境。
转到 Google Cloud 控制台。
如有必要,在 Google Cloud 控制台工具栏中选择
resource.project_display_name
中列出的项目。点击激活 Cloud Shell。
通过运行以下命令获取集群的 GKE 凭据。
对于可用区级集群:
gcloud container clusters get-credentials cluster_name --zone location --project resource.project_display_name
对于地区级集群:
gcloud container clusters get-credentials cluster_name --region location --project resource.project_display_name
通过运行以下命令,在容器环境中启动 shell:
kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
此命令要求容器在
/bin/sh
处安装 shell。如需查看在容器中运行的所有进程,请在容器 shell 中运行以下命令:
ps axjf
此命令要求容器安装
/bin/ps
。
第 6 步:研究攻击和响应方法
- 查看此发现结果类型的 MITRE ATT&CK 框架条目:Command and Scripting Interpreter、Ingress Tool Transfer。
- 如需制定响应方案,请将您的调查结果与 MITRE 研究相结合。
第 7 步:实现响应
以下响应方案可能适合此发现结果,但也可能会影响运营。请仔细评估您在研究中收集的信息,以确定解析发现结果的最佳方法。
Unexpected Child Shell
Container Threat Detection 观察到一个意外生成子 Shell 进程的进程。此事件可能表示攻击者正在尝试滥用 Shell 命令和脚本。
如需对此发现结果采取措施,请执行以下步骤。
第 1 步:查看发现结果详情
按照查看发现结果中所述,打开
Unexpected Child Shell
发现结果。系统会打开发现结果详情面板,以显示摘要标签页。在摘要标签页上,查看以下部分中的信息:
- 检测到的内容,尤其是以下字段:
- 父级进程:意外创建子级 Shell 进程的进程。
- 子进程:子 Shell 进程。
- 参数:提供给子 Shell 进程二进制文件的参数。
- 环境变量:子 Shell 进程二进制文件的环境变量。
- 容器:容器的名称。
- 容器 URI:容器的映像 URI。
- Kubernetes Pod:Pod 名称和命名空间。
- 受影响的资源,尤其是以下字段:
- 资源显示名称:受影响资源的名称。
- 资源全名:完整资源名称
集群的位置完整资源名称包含以下信息:
- 包含集群的项目:
projects/PROJECT_ID
- 集群所在的位置:
zone/ZONE
或locations/LOCATION
- 集群的名称:
projects/CLUSTER_NAME
- 包含集群的项目:
- 检测到的内容,尤其是以下字段:
点击 JSON 标签页并注意以下字段:
+processes
:包含与发现结果相关的所有进程的数组。此数组包括子 Shell 进程和父进程。+resource
:+project_display_name
:包含资产的项目的名称。+sourceProperties
:+VM_Instance_Name
:在其中执行 Pod 的 GKE 节点的名称。
第 2 步:查看集群和节点
在 Google Cloud 控制台中,转到 Kubernetes 集群页面。
如有必要,在 Google Cloud 控制台工具栏中选择
resource.project_display_name
中列出的项目。选择
resource.name
中列出的集群。请记下有关集群及其所有者的所有元数据。点击节点标签页。选择
VM_Instance_Name
中列出的节点。点击详细信息标签页,并记下
container.googleapis.com/instance_id
注解。
第 3 步:审核 Pod
在 Google Cloud 控制台中,转到 Kubernetes 工作负载页面。
如有必要,在 Google Cloud 控制台工具栏上,选择您在发现结果摘要的集群的资源全名 (
resource.name
) 中记下的项目。点击显示系统工作负载。
根据您在发现结果摘要的资源全名 (
resource.name
) 中记下的集群名称以及(如有必要)您记下的 pod 命名空间 (kubernetes.pods.ns
) 过滤工作负载列表。点击与您之前在发现结果 JSON 中记下的
VM_Instance_Name
属性的值匹配的工作负载名称。Pod 详情页面随即会打开。在 Pod 详情页面上,记下可能有助于您解决威胁的有关 Pod 的任何信息。
第 4 步:检查日志
在 Google Cloud 控制台中,打开日志浏览器。
在 Google Cloud 控制台工具栏中,选择
resource.project_display_name
中列出的项目。将选择时间范围设置为感兴趣的时间段。
在加载的页面上,执行以下操作:
- 使用以下过滤条件查找
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"
- 使用以下过滤条件查找集群审核日志:
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
- 使用以下过滤条件查找 GKE 节点控制台日志:
resource.type="gce_instance"
resource.labels.instance_id="instance_id"
- 使用以下过滤条件查找
第 5 步:调查正在运行的容器
如果容器仍在运行,则或许可以直接检查容器环境。
转到 Google Cloud 控制台。
在 Google Cloud 控制台工具栏中,选择
resource.project_display_name
中列出的项目。点击激活 Cloud Shell。
通过运行以下命令获取集群的 GKE 凭据。
对于可用区级集群,请运行以下命令:
gcloud container clusters get-credentials cluster_name --zone location --project resource.project_display_name
对于区域级集群,请运行以下命令:
gcloud container clusters get-credentials cluster_name --region location --project resource.project_display_name
如需在容器环境中启动 Shell,请运行以下命令:
kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
此命令要求容器在
/bin/sh
处安装 shell。如需查看在容器中运行的所有进程,请在容器 shell 中运行以下命令:
ps axjf
此命令要求容器安装
/bin/ps
。
第 6 步:研究攻击和响应方法
- 查看此发现结果类型的 MITRE ATT&CK 框架条目:Command and Scripting Interpreter: Unix Shell。
- 如需制定响应方案,请将您的调查结果与 MITRE 研究相结合。
第 7 步:实现响应
以下响应方案可能适合此发现结果,但也可能会影响运营。请仔细评估您在研究中收集的信息,以确定解析发现结果的最佳方法。
VM Threat Detection 响应
如需详细了解 VM Threat Detection,请参阅 VM Threat Detection 概览。
Execution: Cryptocurrency Mining Hash Match
VM Threat Detection 通过将正在运行的程序的内存哈希与已知加密货币挖矿软件的内存哈希匹配,检测到加密货币挖矿活动。
如需响应这些发现结果,请执行以下操作:
第 1 步:查看发现结果详情
按照查看发现结果中所述,打开
Execution: Cryptocurrency Mining Hash Match
发现结果。 系统会打开发现结果详情面板,以显示摘要标签页。在摘要标签页上,查看以下部分中的信息:
检测到的内容,尤其是以下字段:
- 二进制文件系列:检测到的加密货币应用。
- 程序二进制文件:进程的绝对路径。
- 参数:调用进程二进制文件时提供的参数。
- 进程名称:在与检测到的签名匹配相关联的虚拟机实例中运行的进程的名称。
VM Threat Detection 可以识别主要 Linux 发行版中的内核版本。如果它可以识别受影响的虚拟机的内核版本,则可以确定应用的进程详细信息,并填充发现结果的
processes
字段。如果 VM Threat Detection 无法识别内核(例如,内核是自定义构建的),则系统不会填充发现结果的processes
字段。受影响的资源,尤其是以下字段:
- 资源全名:受影响的虚拟机实例的完整资源名称,其中包括该实例所在的项目的 ID。
如需查看此发现结果的完整 JSON,请在发现结果的详情视图中点击 JSON 标签页。
indicator
signatures
:memory_hash_signature
:与内存页面哈希对应的签名。detections
binary
:加密货币应用的二进制文件的名称,例如linux--x86-64_ethminer_0.19.0_alpha.0_cuda10.0
。percent_pages_matched
:内存中与页面哈希数据库中已知加密货币应用的页面匹配的页面百分比。
第 2 步:检查日志
在 Google Cloud 控制台中,打开日志浏览器。
在 Google Cloud 控制台的工具栏中,选择包含发现结果详情摘要标签页上资源全名行中指定的虚拟机实例的项目。
查看日志,了解受影响虚拟机实例是否存在入侵迹象。例如,检查是否存在可疑或未知的活动以及凭据被盗用的迹象。
第 3 步:查看权限和设置
在 Google Cloud 控制台中,转到信息中心页面。
选择发现结果详情摘要标签页中资源全名行中指定的项目。
导航到资源卡片,然后点击 Compute Engine。
点击与资源全名中标识的项目匹配的虚拟机实例。查看该实例的详细信息,包括网络和访问设置。
第 4 步:研究攻击和响应方法
- 查看执行的 MITRE ATT&CK 框架条目。
- 如需制定响应方案,请将您的调查结果与 MITRE 研究相结合。
第 5 步:实现响应
以下响应计划可能适合此发现结果,但也可能会影响运营。 请仔细评估您在研究中收集的信息,以确定解析发现结果的最佳方法。
为了帮助您检测和移除,请使用端点检测和响应解决方案。
- 联系该虚拟机的所有者。
确认该应用是否为挖矿应用:
如果提供了检测到的应用的进程名称和二进制文件路径,请在调查中考虑发现结果详情摘要标签页上程序二进制文件、参数和进程名称行中的值。
如果未提供进程详细信息,请检查内存哈希签名中的二进制文件名称是否可以提供线索。考虑使用名为
linux-x86-64_xmrig_2.14.1
的二进制文件。您可以使用grep
命令搜索存储空间中的重要文件。在搜索模式中使用二进制名称的有意义的部分,在本例中为xmrig
。检查搜索结果。检查正在运行的进程,尤其是 CPU 使用率较高的进程,看看是否存在任何无法识别的进程。确定关联的应用是否为挖矿应用。
在存储空间的文件中搜索挖矿应用使用的常见字符串,例如
btc.com
、ethminer
、xmrig
、cpuminer
和randomx
。如需查看您可以搜索的字符串的更多示例,请参阅软件名称和 YARA 规则以及列出的每个软件的相关文档。
如果您确定该应用是挖矿应用,并且其进程仍在运行,请终止该进程。在虚拟机的存储空间中找到应用的可执行二进制文件,并将其删除。
如有必要,请停止已被破解的实例并用新实例取代。
Execution: Cryptocurrency Mining YARA Rule
VM Threat Detection 通过匹配内存模式(例如,已知加密货币挖矿软件使用的工作证明常量)检测到加密货币挖矿活动。
如需响应这些发现结果,请执行以下操作:
第 1 步:查看发现结果详情
按照查看发现结果中所述,打开
Execution: Cryptocurrency Mining YARA Rule
发现结果。系统会打开发现结果详情面板,以显示摘要标签页。在摘要标签页上,查看以下部分中的信息:
检测到的内容,尤其是以下字段:
- YARA 规则名称:针对 YARA 检测器触发的规则。
- 程序二进制文件:进程的绝对路径。
- 参数:调用进程二进制文件时提供的参数。
- 进程名称:在与检测到的签名匹配相关联的虚拟机实例中运行的进程的名称。
VM Threat Detection 可以识别主要 Linux 发行版中的内核版本。如果它可以识别受影响的虚拟机的内核版本,则可以确定应用的进程详细信息,并填充发现结果的
processes
字段。如果 VM Threat Detection 无法识别内核(例如,内核是自定义构建的),则系统不会填充发现结果的processes
字段。受影响的资源,尤其是以下字段:
- 资源全名:受影响的虚拟机实例的完整资源名称,其中包括该实例所在的项目的 ID。
相关链接,尤其是以下字段:
- Cloud Logging URI:指向 Logging 条目的链接。
- MITRE ATT&CK 方法:指向 MITRE ATT&CK 文档的链接。
- 相关发现结果:指向任何相关发现结果的链接。
- VirusTotal 指示器:指向 VirusTotal 分析页面的链接。
- Chronicle:指向 Google SecOps 的链接。
如需查看此发现结果的完整 JSON,请在发现结果的详情视图中点击 JSON 标签页。
第 2 步:检查日志
在 Google Cloud 控制台中,打开日志浏览器。
在 Google Cloud 控制台的工具栏中,选择包含发现结果详情摘要标签页上资源全名行中指定的虚拟机实例的项目。
查看日志,了解受影响虚拟机实例是否存在入侵迹象。例如,检查是否存在可疑或未知的活动以及凭据被盗用的迹象。
第 3 步:查看权限和设置
在 Google Cloud 控制台中,转到信息中心页面。
选择发现结果详情摘要标签页中资源全名行上列出的资源名称中指定的项目。
导航到资源卡片,然后点击 Compute Engine。
点击与
resourceName
匹配的虚拟机实例。查看该实例的详细信息,包括网络和访问设置。
第 4 步:研究攻击和响应方法
- 查看执行的 MITRE ATT&CK 框架条目。
- 如需制定响应方案,请将您的调查结果与 MITRE 研究相结合。
第 5 步:实现响应
以下响应计划可能适合此发现结果,但也可能会影响运营。 请仔细评估您在研究中收集的信息,以确定解析发现结果的最佳方法。
为了帮助您检测和移除,请使用端点检测和响应解决方案。
- 联系该虚拟机的所有者。
确认该应用是否为挖矿应用:
如果提供了检测到的应用的进程名称和二进制文件路径,请在调查中考虑发现结果详情摘要标签页上程序二进制文件、参数和进程名称行中的值。
检查正在运行的进程,尤其是 CPU 使用率较高的进程,看看是否存在任何无法识别的进程。确定关联的应用是否为挖矿应用。
在存储空间的文件中搜索挖矿应用使用的常见字符串,例如
btc.com
、ethminer
、xmrig
、cpuminer
和randomx
。如需查看您可以搜索的字符串的更多示例,请参阅软件名称和 YARA 规则以及列出的每个软件的相关文档。
如果您确定该应用是挖矿应用,并且其进程仍在运行,请终止该进程。在虚拟机的存储空间中找到应用的可执行二进制文件,并将其删除。
如有必要,请停止已被破解的实例并用新实例取代。
Execution: cryptocurrency mining combined detection
VM Threat Detection 在一天内检测到来自单个来源的多个类别的发现结果。单个应用可以同时触发
Execution: Cryptocurrency Mining YARA Rule
和
Execution: Cryptocurrency Mining Hash Match findings
。
如需响应组合发现结果,请同时按照针对 Execution: Cryptocurrency Mining YARA Rule
和 Execution: Cryptocurrency Mining Hash Match findings
的响应说明操作。
Malware: Malicious file on disk (YARA)
VM Threat Detection 通过扫描虚拟机的 永久性磁盘存储已知恶意软件签名。
如需响应这些发现结果,请执行以下操作:
第 1 步:查看发现结果详情
按照说明打开
Malware: Malicious file on disk (YARA)
发现结果 审核 发现结果。 系统会打开发现结果详情面板,以显示摘要标签页。在摘要标签页上,查看以下部分中的信息:
- 检测到的内容,尤其是以下字段:
- YARA 规则名称:匹配的 YARA 规则。
- 文件:分区 UUID 和检测到的可能恶意文件的相对路径。
- 受影响的资源,尤其是以下字段:
- 资源全名:受影响的虚拟机实例的完整资源名称,其中包括该实例所在的项目的 ID。
- 检测到的内容,尤其是以下字段:
如需查看此发现结果的完整 JSON,请在发现结果的详情视图中点击 JSON 标签页。
在 JSON 中,记下以下字段:
indicator
signatures
:yaraRuleSignature
:与匹配的 YARA 规则对应的签名。
第 2 步:检查日志
在 Google Cloud 控制台中,打开日志浏览器。
在 Google Cloud 控制台的工具栏中,选择包含发现结果详情摘要标签页上资源全名行中指定的虚拟机实例的项目。
查看日志,了解受影响虚拟机实例是否存在入侵迹象。例如,检查是否存在可疑或未知的活动以及凭据被盗用的迹象。
第 3 步:查看权限和设置
在 Google Cloud 控制台中,转到信息中心页面。
选择 资源文件中列出的 发现结果详情的摘要标签页中的资源全名行。
导航到资源卡片,然后点击 Compute Engine。
点击与
resourceName
匹配的虚拟机实例。查看该实例的详细信息,包括网络和访问设置。
第 4 步:研究攻击和响应方法
在 VirusTotal 上查看被标记为恶意的文件的 SHA-256 哈希值。VirusTotal 是一项 Alphabet 自有服务,提供了有关潜在恶意文件、网址、网域和 IP 地址的上下文。
第 5 步:实现响应
以下响应方案可能适合此发现结果,但也可能会影响运营。请仔细评估您在研究中收集的信息,以确定解析发现结果的最佳方法。
联系该虚拟机的所有者。
如有必要,请找到并删除潜在的恶意文件。如需获取文件的分区 UUID 和相对路径,请参阅发现结果详情的摘要标签页上的文件字段。为了帮助您检测和移除,请使用端点检测和响应解决方案。
如有必要,请停止已被破解的实例并用新实例取代。
要进行取证分析,请考虑备份虚拟机和 永久性磁盘有关详情,请参阅数据保护 选项 文档。
如需进一步调查,请考虑使用突发事件响应服务,例如 Mandiant。
修复相关漏洞
为了帮助防止威胁再次发生,请查看并修复相关的漏洞和错误配置发现结果。
如需查找任何相关发现结果,请按照以下步骤操作:
在 Google Cloud 控制台中,进入 Security Command Center 发现结果页面。
查看威胁发现结果,然后复制可能出现在任何相关漏洞或配置错误发现结果中的特性的值,例如主账号电子邮件地址或受影响资源的名称。
在发现结果页面上,点击修改查询来打开查询编辑器。
点击添加过滤条件。 选择过滤条件菜单随即会打开。
从菜单左侧的过滤条件类别列表中,选择包含您在威胁发现结果中记下的特性的类别。
例如,如果您记下了受影响资源的完整名称,请选择资源。资源类别的特性类型会显示在右侧的列中,包括完整名称特性。
从显示的特性中,选择您在威胁发现结果中记下的特性的类型。属性值的搜索面板会在右侧打开,并显示所选属性类型所有找到的值。
在过滤条件字段中,粘贴您从威胁发现结果复制的属性值。显示的值列表会更新,仅显示与粘贴的值匹配的值。
从显示的值列表中选择一个或多个值,然后点击应用。发现结果的查询结果面板会更新,仅显示匹配的发现结果。
如果结果中有许多发现结果,请通过从快速过滤条件面板中选择其他过滤条件来过滤发现结果。
例如,如需仅显示包含所选特性值的
Vulnerability
和Misconfiguration
类发现结果,请向下滚动到快速过滤条件面板的发现结果类部分,然后选择漏洞和配置错误。
除了 Google 提供的入侵线索外,作为 Palo Alto Networks 客户的用户还可以将 Palo Alto Networks 的 AutoFocus Threat Intelligence 与 Event Threat Detection 集成。AutoFocus 是一项威胁情报服务,可提供有关网络威胁的信息。如需了解详情,请访问 Google Cloud 控制台中的 AutoFocus 页面。
修复威胁
修复 Event Threat Detection 和 Container Threat Detection 发现结果并不像修复 Security Command Center 发现的错误配置和漏洞一样简单。
错误配置和违规情况会识别资源中可能被利用的漏洞。通常,配置错误有已知且容易实现的修复方案,例如启用防火墙或轮替加密密钥。
威胁与漏洞有所不同,威胁是动态的,并指示针对一个或多个资源的可能发生的活跃漏洞。修复建议可能对保护资源安全不起作用,因为实现漏洞所用的确切方法可能未知。
例如,Added Binary Executed
发现结果指示容器中发布了未获授权的二进制文件。基本的修复建议可能有助于您隔离容器并删除该二进制文件,但可能无法解决允许攻击者执行此二进制文件的根本原因。您需要了解容器映像的损坏程度才能修复漏洞。如需确定文件是通过配置错误端口添加的还是通过其他一些方式添加的,您需要进行全面调查。对您的系统具有专业知识的分析师可能需要查看系统是否存在漏洞。
作恶方会使用不同的技术攻击资源,因此,对特定漏洞应用修复方案可能对攻击的变化不起作用。例如,为了响应 Brute Force: SSH
结果,您可以降低某些用户账号的权限级别来限制对资源的访问权限。但是,安全系数低的密码可能仍会提供攻击路径。
攻击途径范围广使得很难提供适用于所有情况的修复步骤。Security Command Center 在云安全方案中的作用是近乎实时地发现受影响的资源,告诉您面临的威胁,并提供证据和上下文来帮助您进行调查。但您的安全人员必须使用 Security Command Center 发现结果中的敏感信息来确定修复问题并保护资源免受未来攻击的最佳方法。
后续步骤
请参阅 Event Threat Detection 概览,详细了解该服务及其检测的威胁。
请参阅 Container Threat Detection 概览,了解该服务的工作原理。
请参阅 VM Threat Detection 概览,详细了解该服务及其检测的威胁。