了解您需要在云取证调查中使用哪些工具和数据源，以及它们如何在现实生活中付诸实践。

网络安全取证是在攻击发生后提取和恢复数据以对其进行全面评估的过程。它由对攻击识别来触发，需要收集所有相关数据并随后根据这些证据进行深入调查。取证过程最终会根据调查的见解得出一份报告。

在此博客中，我们将简要介绍取证过程的一些指南，并阐明传统取证和云取证之间的区别。我们还将提供在调查中需要使用哪些工具和数据源的备忘单，最后，我们将介绍一个由容器警报触发的云取证调查示例。

取证指南

为了帮助我们专注于取证的目标，即全面了解攻击行为，让我们将流程分解为前五个指南问题：

• 最初的接入点是什么？

• 黑客是否触及到其他资源，如果是，如何接触？

• 黑客是否在环境中获得持久性，如果是，如何获得？

• 攻击的影响是什么？

• 下次如何避免这种情况？

充足准备是回答这些问题的关键。如果在攻击前没有相关的数据日志和工具，只能收集和分析有限的证据，导致调查中存在不同的盲点。这直接影响取证过程结果的质量。

为了克服这些障碍并为基于云的事件收集所需的证据，安全团队必须采用与传统端点解决方案不同的方法。

传统取证与云取证

尽管在云和端点的取证过程中的指导性问题相似甚至相同，但过程根本不同。造成这种差异的根本原因在于架构和黑客的意图。

架构：现代云基础设施非常复杂和动态。它由不同的组件组成，例如虚拟机、容器、无服务器功能、VPC、身份服务、存储和应用程序。这些组件中的每一个都可能是攻击面，并具有不同的安全措施。这会影响整个攻击链：从初始访问和持久性，到横向移动和影响。传统的安全基础设施（即 EDR 和防火墙）并不完全适用于云。

黑客的意图：云和端点在组织内提供不同的功能。当黑客获得对端点设备或云资产的访问权限时，他们的最终目标可能会有所不同。了解黑客心态的能力有助于将不同事件之间的点联系起来，并确定攻击的时间顺序。虽然端点攻击通常涉及窃取数据（例如 cookie 和密码）或内部网络传播以部署勒索软件，但大多数记录在案的云攻击要么是关于利用计算资源，要么是获取对敏感数据存储的访问权限。例如，如果我们看到黑客创建了大量的 EC2 VM，我们可以推断出攻击的最终目标是资源劫持。

准备环境：资源和工具备忘单

由于云很复杂，因此追踪攻击事件需要关联来自各种资源的事件。让我们谈谈前五个来源：

• 云提供商审计日志

• 网络流量日志

• 容器编排日志

• 工作负载映像快照

• 工作负载运行时事件

这些事件也可以用作警报流的一部分——如果您正在构建 SOC 和事件响应流程，您会发现这很有用。

云提供商审计日志

云提供商的审计日志跟踪对云提供商API的调用。这包括与 CLI 和云管理控制台 UI 的交互。这些日志可以帮助跟踪与身份和资源相关的云原生账户活动（例如，IAM 账户创建了虚拟机或访问了云原生数据库）。

资料来源：

• AWS – CloudTrail,https://aws.amazon.com/cloudtrail/

• GCP –云审计日志, https://cloud.google.com/logging/docs/audit

• Azure – Azure 按层拆分日志。让我们关注平台日志：

• 登录日志, https://learn.microsoft.com/en-us/azure/active-directory/reports-monitoring/concept-sign-ins

• 审计日志——收集用户创建和密码更改等事件, https://learn.microsoft.com/en-us/azure/active-directory/reports-monitoring/concept-audit-logs

• Azure 租户（活动目录相关日志）：

• Azure 订阅：活动日志——收集对资源执行的事件，例如 Web 应用程序创建或资源修改 ，https://learn.microsoft.com/en-us/azure/azure-monitor/essentials/activity-log

• Azure 资源：资源日志  ——收集底层资源事件，例如对数据库的请求

网络流量日志 (VPC)

VPC 网络流量（也由云提供商收集）可以帮助识别黑客的 IP。它可以通过确定恶意流量首次出现和最后一次出现的时间来帮助确定攻击时间。值得注意的是，到 IMDS 的流量包含在云提供商日志中，而不是网络流日志中。

解决方案：

• 亚马逊云 VPC 流日志, https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html

• 谷歌云 VPC 流日志, https://cloud.google.com/vpc/docs/flow-logs

• Azure 网络观察器, https://learn.microsoft.com/en-us/azure/network-watcher/network-watcher-monitoring-overview

容器编排审计日志

大多数现代云基础设施由容器编排工具管理的微服务组成。我们将重点关注 Kubernetes，因为它是主要的容器编排工具。与云提供商审计日志一样，容器编排审计日志跟踪与编排器 API 的交互（例如，服务帐户创建了一个新的 pod 并在其上执行了命令）。

资料来源：

• Kubernetes 审计日志, https://kubernetes.io/docs/tasks/debug/debug-cluster/audit/

• 在 EKS 中，您需要启用这些日志（日志将流式传输到 CloudWatch）

• 在 AKS 和 GKE 中，它们默认启用

• OpenShift 审计日志, https://docs.openshift.com/container-platform/4.10/security/audit-log-view.html

工作负载快照

工作负载快照有助于跟踪基于磁盘更改的事件。bash 历史记录、Web 服务访问日志、系统日志和 init 服务等数据都驻留在磁盘上。此外，如果攻击包括落在磁盘上的有效负载，则工作负载快照可以收集样本以供进一步分析。每个应用程序或服务安装都应配置为记录日志。

由于云资源是动态的，建议根据某些可疑事件设置工作负载文件收集的自动触发器。工作负载快照（默认情况下云提供商不会记录）可以通过多种方式记录，例如通过工作负载本身的专用脚本或使用云提供商备份功能。例如，请参阅AWS EC2 备份文档。

工作负载运行时事件

获取工作负载快照并不足够的。有不同的运行时事件会在磁盘上留下有限的痕迹，例如无文件恶意软件。此外，黑客在执行恶意活动后会尝试擦除磁盘上的任何痕迹。因此，跟踪容器、节点和 VM 上的运行时事件可以实现与工作负载相关的全面调查。

在 Linux 中用于跟踪运行时事件的顶级技术是 Auditd 和 eBPF。

• Auditd是 Linux 审计系统用户态守护进程，负责将审计记录写入磁盘。Auditd 默认记录与安全相关的事件。使用 Auditd，可以创建预定义的审计规则来跟踪资源上的可疑事件。

• eBPF（extended Berkeley Packet Filter）是一个事件驱动的 Linux 内核子系统。它允许挂钩某些事件，例如系统调用和网络事件。大多数商业 Linux agent解决方案都依赖 eBPF，因为它比其他解决方案具有许多优势，例如性能和安全事件覆盖。

其他有用的工具是fanotify和inotify。这些工具监视文件系统上的事件，例如文件创建、文件修改和文件打开。

尽管也可以使用内核模块，但不推荐使用它们，因为它们会使您的环境处于危险之中，内核模块中的错误可能会使系统崩溃。

我们现在将展示在攻击调查过程中拥有这组资源和工具的价值。

现实生活中的例子

在此示例中，我们将根据我们在测试环境中模拟的真实攻击场景来完成取证过程。在模拟攻击之前，我们确保设置了来自不同来源的收集日志（参见上面的备忘单），这样我们就可以为攻击场景中的每个步骤提供证据。

取证调查过程

在调查过程中，我们将利用本文开头提到的五个指导性问题来帮助我们缩小关注范围。在这个特定案例中，我们的取证过程是由通过运行时事件工具在网站托管 pod 上的反向 shell 上发出的警报触发的。

初始访问：警报包含黑客在反向 shell 命令行中的 IP。我们可以看到 shell 是由用户ID 33 执行的，在该容器的上下文中该用户是 www-data 用户。这强烈表明黑客的初始访问点是通过容器上托管的 WordPress Web 界面。现在让我们调查 Apache 访问日志并搜索黑客的 IP 以验证黑客确实与 Web 界面进行了交互。我们可以看到来自黑客 IP 的管理员登录和上传名为“wp-shell”的插件的发布请求。查看上传插件的PHP文件，我们可以看到web shell（ /wp-content/plugins/wp- shell/rshell.php）。

权限提升：在验证了黑客的初始访问点之后，让我们检查 pod 本身，看看黑客还发起了哪些其他操作。在调查我们从 pod 收集的工作负载事件时，我们发现其中一个高危事件是由 root 发起的可疑挂载执行。这表明黑客可能已经进行了特权升级并试图逃离容器。查看mount命令行后，我们发现这是一种常见的特权容器逃逸方法。因为我们知道这个 pod 是有特权的，所以我们怀疑黑客能够逃到主机。

持久性：既然我们怀疑黑客能够逃离 pod 并在节点上执行命令，我们可以评估黑客试图利用这个机会横向移动到其他资源和/或创建持久性。让我们首先检查 Kubernetes 审计日志，看看在容器逃逸的可疑时间范围内执行了哪些命令。在节点上查询创建日志或发布请求时({$.user.username =”system:node:ip-192-168-61-188.ec2.internal”})，我们得到一个非常多的输出. 我们可以过滤掉嘈杂的 API 调用或在日志中搜索有趣的调用，例如 pod 创建 {$.verb = "create" && $.requestURI= pods && $.user.username ="system:node:ip-192-168-61-188.ec2.internal输出表明有人试图创建一个名为 legit-stuff 的 pod。由于从节点创建 Pod 受到 EKS RBAC 的限制，因此黑客得到了失败响应。

鉴于 pod 创建尝试，我们还检查 Docker 映像和容器，看看黑客是否能够通过 Docker socket创建容器。在幕后，Kubernetes 使用 containerd，它通过公开 docker.sock 来支持 Docker API。与这个socket交互的黑客可以使用它来管理该节点上的容器，即使他们受到 RBAC 的限制。我们可以通过执行docker ps或查看节点上的/var/lib/docker路径（ ls –la /var/lib/docker/containers). 经过快速调查，我们可以确认黑客创建了一个在启动时执行后门的特权容器；这是黑客在环境中创建持久性意图的一部分。

横向移动：我们应该调查节点上现有的 pod，看看黑客是否已经通过 Docker socket移动到节点上的其他资源。VPC 流量日志显示“data-fetcher”pod 和黑客的 IP 之间存在流量。基于此，我们可以假设黑客已经横向移动到“data-fetcher”pod。

影响： data-fetcher pod 的服务账户附加了 s3-get-object-role IAM 角色。该角色拥有“super sensitive”S3 存储桶授予的所有 S3 权限。在攻击时间范围内搜索 CloudTrail 日志或与 S3 存储桶的交互时，事件日志表明生成事件的用户agent是 AWS CLI 用户agent，这是一种异常行为。我们还可以看到在同一时间窗口内发起了对 clients-records 的 GetObject 请求。client-records 数据与黑客 IP 与data-fetcher pod 之间流中的数据大小相似。我们可以推断，黑客成功窃取了“client-records”数据，这些数据以明文形式存储，因此加剧了影响。

取证流程洞察

现在我们已经完成了取证过程并从各种事件源中生成了见解，让我们回到最初的指南问题：

最初的接入点是什么

黑客利用弱的 WordPress 管理面板凭据，上传 web shell，并在托管 WordPress 服务的容器上执行任意命令。

黑客是否传播到其他资源，如果是，如何传播

黑客逃脱了托管 WordPress 服务的 pod，列出了集群中的所有 pod ，并横向移动到节点上另一个名为“data-fetcher”的 pod。然后，黑客从“data-fetcher”pod访问敏感的 S3 存储桶 (pod -> host -> pod -> S3) 。

黑客是否在环境中获得持久性，如果是，如何获得

黑客在带有后门的节点上创建了一个特权 pod，允许黑客访问该节点上的其他 pod。

**违规的影响是什么 **

敏感的客户数据遭到泄露。这可能会对组织造成严重的业务损害。

下次如何避免这种情况

要回答这个问题，我们需要调查攻击的每一步并评估如何阻止它。这从使用弱凭证开始，包括一个暴露的管理面板、一个部署在特权容器上面向互联网的服务，以及以明文形式存储在 S3 存储桶中的敏感数据。

概括

云架构很复杂，其攻击面也很复杂。取证过程的成功在于准备并确保我们拥有云中不同事件的证据，包括云提供商审计日志、网络流量日志、容器编排审计日志、工作负载快照和工作负载运行时事件。在我们提供的真实示例中，我们展示了一个简化的取证调查，以强调全面了解事件是高效取证过程的关键。

请点一下右下角的“在看”，谢谢！！

请帮忙点赞， 谢谢！！

请帮忙转发，谢谢！！

暗号: 602959