云端取证揭秘-全-

云端取证揭秘（全）

原文：annas-archive.org/md5/e872f102082b55813ec9c5d31f0157e0

译者：飞龙

协议：CC BY-NC-SA 4.0

序言

云计算已成为在快速发展的数字技术世界中存储、处理和管理数据的重要平台。然而，它也给数字取证领域带来了若干复杂的挑战。Cloud Forensics Demystified是一本全面的指南，旨在揭开这些复杂性，为你提供关于云取证世界的清晰洞察。

本书面向专业人士和爱好者，无论其在数字取证领域的经验如何。本书从建立云计算的基础知识入手，包括其架构、服务模型和部署类型。这些背景知识对于理解云计算在取证调查中所面临的独特挑战和机遇至关重要。

本书接着将重点转向云取证的核心，探讨在云环境中进行有效取证调查的方法和最佳实践。这包括对数据采集技术、取证分析和云计算中特有的法律问题的详细研究。在全书中，强调技术效率与法律合规之间的平衡，反映了云取证的多维特性。

本书的独特之处在于它强调现实世界的应用。通过案例研究和实际场景，你将了解到如何将书中讨论的原理和技术应用于实际的取证调查。这些示例为理论概念提供了实际背景，并为你应对云环境中的不可预测的取证挑战做好准备。

为确保内容的相关性和时效性，Cloud Forensics Demystified还涉及了云技术中的最新趋势和进展。这一前瞻性视角使你能够掌握预见和适应云计算动态变化所需的知识。

本书的目标不仅是解开云取证的神秘面纱，更是激励新一代的取证专家，培养他们在云基础调查中的细致能力。无论你是网络安全专家、法律从业者、学者，还是仅仅是技术爱好者，Cloud Forensics Demystified都为你提供了理论深度和实践洞察的结合，为你掌握这一迷人的领域铺平道路。

当你踏上这段旅程时，你将获得必要的知识和技能，以应对云时代数字取证的复杂性。准备好探索一个曾经难以捉摸的世界，在这里，云计算变成了可触及的取证证据来源。

本书适合人群

云取证揭秘 是一本主要为那些希望扩展云取证调查知识的数字取证从业人员设计的书籍。然而，本书也适合各种经验水平的数字取证和云计算专业人士及爱好者。特别适合那些想要深入了解该主题的人：

  • 寻求云计算专业知识的数字取证与事件响应（DFIR）从业人员：本书面向那些已经掌握数字取证和事件响应技能，但希望扩展能力以在云环境中工作的专业人士。书中涵盖了管理云特有挑战的高级技术和策略，是希望适应云计算的 DFIR 专家的重要资源。

  • 网络安全专业人士：从事网络安全工作的人可以获得宝贵的见解，了解如何在云环境中进行取证调查，因为对云服务的依赖日益增加。

  • 数字取证调查员：本书为取证调查员提供了详细的方法论，用于在云环境中获取和分析数据。

  • 法律从业人员：处理来自云端数字证据的法律专业人士将学习到云取证的法律复杂性。

  • IT 与云计算专业人士：IT 和云计算专业人士可以深入理解管理云服务的取证影响，这对合规和调查准备工作至关重要。

  • 学术界和学生：网络安全、数字取证、信息技术和法律领域的教育工作者和学生将发现本书是一本全面的学术资源。

  • 技术爱好者：对于那些对技术、法律和安全融合感兴趣的人来说，本书提供了对云取证的引人入胜且富有信息量的探讨。

  • 企业合规与风险管理专业人士：专业人士必须理解云取证，以有效降低云数据风险。

本书内容

第一章，云计算简介，提供了云计算的基本概述，包括其架构、服务模型（IaaS、PaaS 和 SaaS）以及部署类型（公有云、私有云和混合云）。本章的目标是刷新或建立基本的云计算知识，这是理解后续取证讨论的基础。

第二章，网络安全与隐私法趋势及其对 DFIR 的影响，深入理解云环境中出现的法律复杂性。这些复杂性包括数据隐私法、合规要求和管辖问题。理解云数据所受法律框架及其对取证调查的影响至关重要。

第三章，探索主要云服务提供商，提供了主要云服务提供商（如 AWS、Azure 和 GCP）的概述。它解释了各自独特的架构和服务，说明了它们如何影响取证调查。

第四章，DFIR 调查 – AWS 中的日志，提供了在 AWS 环境中进行 DFIR（数字取证和事件响应）的详细指南，包括访问、解释和分析日志，以追踪活动并识别安全事件。

第五章，DFIR 调查 – Azure 中的日志，专注于利用 Azure 特有的日志机制进行取证调查。

第六章，DFIR 调查 – GCP 中的日志，专注于在 GCP 中的取证调查，重点是提取和分析 GCP 日志，日志是调查 GCP 环境中事件的关键组成部分。

第七章，云生产力套件，讨论了在云生产力套件中的取证调查挑战，例如 Microsoft 365 和 Google Workspace，并探索如何访问和分析来自这些广泛使用的商务工具的数据。

第八章，数字取证和事件响应过程，提供了云环境中 DFIR 过程的全面指南，包括数字证据的识别、保存、分析和报告。

第九章，常见攻击向量和 TTPs，研究了常见的攻击向量以及在云环境中使用的战术、技术和程序（TTPs），以帮助预测和识别潜在的安全事件。

第十章，云证据采集，讨论了从 AWS、GCP 和 Microsoft Azure 等云环境中采集数字证据的挑战，强调确保证据完整性和法律可采性的最佳实践。

第十一章，分析被破坏的容器，专门讨论了在云环境中分析被破坏的容器和 Kubernetes 平台的取证方法。本章涵盖了如何识别、收集和分析来自这些越来越多用于云应用的容器的证据。

第十二章，分析被破坏的云生产力套件，讨论了分析云生产力套件中漏洞的取证策略。

《云取证解密》的每一章都建立在前一章的基础上，形成了一本全面的指南，涵盖了云取证的理论和实践方面，针对各种专业需求和兴趣量身定制。

为了充分利用本书

为了从本书中获得最大收获，请考虑以下方法：

  • 如果你是云计算的新手，第一章将为你提供关于基本云概念的基础理解。这将有助于你理解后续章节中讨论的复杂话题。

  • 理解法律背景：在进行任何云中的法医工作之前，了解法律背景非常重要。第二章提供了必须遵守的调查法律和法规的基础知识。

  • 研究特定云服务提供商：通过专注于第三章、第四章、第五章和第六章，获得对不同云服务提供商的洞察。根据你在工作中遇到的或最感兴趣的云服务提供商（CSPs）来调整你的学习方向。

  • 实践操作：建议在实践环境中应用书中讨论的概念和技术。可以通过模拟、训练环境，或在你已经从事相关工作的法医调查中进行实践。

  • 专注于 DFIR 过程：第七章和第八章对于理解云环境中事件响应和调查的细微差别至关重要，无论这是否是你的主要兴趣，都请特别关注这些章节。

  • 保持对攻击向量的关注：查看第九章，以便走在安全威胁演变的前沿，并保持对最新攻击方法的了解。

  • 掌握证据获取：第十章到第十二章涵盖了证据获取和分析，对于在实际法医案件中发展实践技能至关重要。

  • 参与案例研究：花时间彻底理解实际的例子和案例研究，它们为理论知识提供了背景，并对现实应用提供了宝贵的理解。

  • 参与社区讨论和工作坊：与网络安全和数字法医社区互动。讨论、工作坊和会议可以提供额外的见解和实践视角。

  • 反思与应用：每章结束后，花些时间思考这些信息如何应用于你当前的知识、经验和职业场景。考虑记下关键的收获，或思考如何将新策略应用于你的工作中。

以结构化的思维方式阅读《云法医揭秘》，以提升你对云法医的技能和理解。

使用的约定

本书中使用了许多文本约定。

sort by 和 limit 控制输出中记录的顺序和数量。

以下是代码块的设置方式：

AzureNetworkAnalytics_CL
| where SubType_s == "FlowLog"
| extend FlowDirection = iff(FlowDirection_s == 'O', 'Outbound', 'Inbound')
| extend AllowedOrDenied = iff(FlowStatus_s == 'A', 'Allowed', 'Denied')

当我们希望引起你对代码块中特定部分的注意时，相关的行或项会以粗体形式突出显示：

StorageBlobLogs
| where TimeGenerated > ago(7d)
| project TimeGenerated, OperationName, AuthenticationType, Uri, _ResourceId, CallerIpAddress

任何命令行输入或输出按如下方式书写：

$ gsutil iam get gs://test_cf1_test1

粗体：表示一个新术语、一个重要的词汇或您在屏幕上看到的文字。例如，菜单或对话框中的文字通常是粗体显示的。以下是一个例子：“所有虚拟网络可以直接通过 Azure 主页上的虚拟网络服务访问。”

提示或重要说明

如此显示。

请联系我们

我们总是欢迎读者的反馈。

一般反馈：如果您对本书的任何内容有疑问，请通过电子邮件联系我们，邮箱地址为 customercare@packtpub.com，并在邮件主题中提及书名。

勘误表：虽然我们已尽力确保内容的准确性，但错误仍然可能发生。如果您在本书中发现了错误，我们将非常感激您能向我们报告。请访问www.packtpub.com/support/errata并填写表格。

盗版：如果您在互联网上发现我们作品的任何非法复制品，我们将非常感激您提供其位置或网站名称。请通过 copyright@packt.com 联系我们，并附上该材料的链接。

如果您有兴趣成为作者：如果您在某个领域具有专业知识，并且有兴趣撰写或参与书籍的编写，请访问authors.packtpub.com。

分享您的想法

阅读完《云取证解密》后，我们非常希望听到您的想法！请点击此处直接前往亚马逊评论页面，分享您的反馈。

您的评论对我们以及技术社区非常重要，它将帮助我们确保提供优质的内容。

下载本书的免费 PDF 副本

感谢您购买本书！

喜欢随时随地阅读，却又无法随身携带纸质书籍？

您购买的电子书是否与您选择的设备不兼容？

不用担心，现在每本 Packt 书籍都附赠免费的无 DRM 限制 PDF 版本。

在任何地方、任何设备上都可以阅读。可以从您最喜欢的技术书籍中直接搜索、复制并粘贴代码到您的应用程序中。

特权不仅仅止步于此，您还可以获得独家折扣、新闻通讯和每日发送到邮箱的精彩免费内容。

按照以下简单步骤获得福利：

  1. 扫描二维码或访问下面的链接

packt.link/free-ebook/9781800564411

  1. 提交您的购买凭证

  2. 就这些！我们将直接通过电子邮件发送您的免费 PDF 和其他福利。

第一部分：云计算基础

在这一部分，我们将探讨云计算的基本方面。这一部分特别有助于你了解云计算的基础知识，以及与云技术相关的法律挑战，尤其是在跨境调查和复杂的云基础设施方面。我们还将介绍一些主要的云服务提供商，提供各种云资源。

本部分包含以下章节：

  • 第一章，云计算简介

  • 第二章，网络安全与隐私法律趋势及其对 DFIR 的影响

  • 第三章，探索主要的云服务提供商

第一章：云计算简介

云计算已经存在多年——这个概念指的是通过互联网向用户或客户提供计算资源。尽管这个概念并不新颖，但它已以各种形式提供，并且可以以多种方式进行部署。云计算的好处在于它天生具备可扩展性、资源灵活性（意味着您可以根据计算需求选择所需的计算资源的强度）和成本效益，这使得组织更容易规划云计算的采纳。因此，组织现在正将其关键数据和业务应用程序迁移到云端，这为事件响应者在调查安全事件和数据泄露时带来了新的挑战。根据 Gartner 的报告，到 2025 年，80%的企业将转向云计算-only 策略，并逐步淘汰传统的数据中心。同时，IDG 2020 年云计算调查表明，至少 92%的公司在其业务运营中使用至少一种或多种云服务（例如，Microsoft 365 用于电子邮件等）。

事件响应者需要了解云计算的工作原理，以有效调查安全事件。事件响应者是主要负责处理与信息技术（IT）系统相关的安全事件的个人或团队。事件响应者通常会分析、调查、控制并解决安全事件。事件响应者对 IT 计算概念有深入的理解，并且掌握调查程序的深厚知识，包括数字取证。

本章将为您提供有关云计算的简要复习，涵盖诸如云计算的历史；云计算的优缺点；云服务和部署模型；以及云计算采纳对几个关键行业的影响等重要话题。

云计算的演变可以追溯到 1960 年代，当时国防高级研究计划局（DARPA）委托麻省理工学院（MIT）开发一个可以供两人或更多人使用的计算环境。1969 年，美国心理学家和计算机科学家 J.C.R. Licklider 在其高级研究计划局网络（ARPANET）的研究过程中，致力于开发允许用户从全球任何地方连接并共享信息的系统。

快进到 1990 年代，在大型主机时代，计算资源是集中提供的。互联网泡沫为网络服务通过互联网提供给消费者铺平了道路（软件即服务（SaaS））。随着云计算变得更加复杂和分布式，管理安全事件和进行取证调查的挑战也随之增加。跨不同云环境和部署模型收集和分析数据的能力对于组织快速有效地应对安全事件至关重要。下图展示了云计算从集中式主机模型到无服务器计算的演变，并突出了在应对基于云的安全事件时，持续发展取证方法的重要性。

图 1.1 – 云演化时间线

图 1.1 – 云演化时间线

云计算的优势与劣势

每项技术都有其独特的复杂性和挑战，每次技术演变背后总有好的一面和坏的一面。以下是云计算的一些优势和劣势。

优势：

  • 现代化与创新：云计算促进了新的创新。云服务提供商投资于先进的基础设施功能，使研究人员和爱好者能够研究和创新新解决方案，如人工智能（AI）、机器学习（ML）、机器人技术等。

  • 可扩展性：显然，采用云计算的一个巨大优势是资源的易于扩展性。存储和计算能力可以根据组织、应用程序或用户需求的变化进行上下扩展，而且这一切无需进行重大硬件或软件投资。云可扩展性对于部署端点检测与响应（EDR）工具特别有用，这些工具可以帮助调查人员识别并遏制威胁，同时对受损系统进行取证。EDR 工具可能非常消耗资源，运行时需要大量的计算能力和存储容量。通过云的可扩展性，调查人员可以迅速为正在调查的系统分配额外的资源，以便运行 EDR（和其他取证）工具，使他们能够更快速、更高效地检测并应对威胁，最大程度地减少业务中断。

  • 灵活性和可达性：您可以随时开启或关闭您的云计算资源；云计算提供了根据用户需求启用或禁用任何服务的灵活性。此外，您可以通过任何具有互联网连接的设备访问您的云服务，从而扩大应用的覆盖范围，接触到更多的远程用户。灵活性使得云服务可以在全球偏远地区提供，而无需在硬件或软件上进行额外投资来托管应用程序。具体而言，这使得法医调查人员能够快速、高效地访问来自整个 IT 环境的数据（通常通过集中式云控制台）。这一点对于在多个地理位置有 IT 基础设施的组织而言，至关重要，有助于识别和响应安全事件。

  • 成本节省：使用云服务的最大优势之一就是显著提高投资回报率和降低成本。无需提前投入资金购买和搭建硬件/软件。无需在数据中心租用空间或建立自己的数据中心，也无需进行资本性投资。运营成本也非常低——仅需支付云服务的运营费用。这意味着组织可以将更多预算用于部署额外的资源，以减轻安全事件带来的影响，比如雇佣安全专家、购买专用的安全工具和提升 IT 基础设施的容量。

  • 灾难恢复：订阅云服务的另一个优势是灾难恢复和确保为用户提供服务的连续性。云服务通常会进行复制、负载均衡，并进行备份，以确保服务的连续性。健全的灾难恢复政策使组织能够快速从安全事件中恢复，减少停机时间和业务中断，并确保在需要时提供可供法医分析的备份。

  • 数据安全：鉴于云服务提供商在设置和提供云服务方面进行了基础设施投资，云服务提供商通常采用严格的安全控制措施，包括加密和高级访问控制。由于云采用共享安全模型，值得注意的是，订阅云服务的客户或企业仍然负责启用加密、配置访问控制以及启用云服务提供商提供的其他安全功能。

缺点：

  • 安全性和隐私风险：虽然云服务提供商在保护云基础设施方面进行大量投资，但将组织或客户信息存储在云端也存在风险，尤其是在云系统配置错误时，可能导致数据泄露。市面上有很多此类例子，反映了这一担忧。

  • 需要互联网连接：由于云资源可以从世界任何地方访问，因此对互联网的依赖非常大。没有互联网连接，您将无法在云上进行任何操作。

  • 潜在的供应商锁定：一旦组织与云服务提供商签约，通过云基础设施向用户提供服务，组织通常会被绑定到同一供应商，使得更换其他供应商变得更加困难。

  • 潜在的服务中断：服务提供商通常会尝试向终端用户提供新特性/产品，在此过程中，他们可能会无意中影响服务，从而导致停机和服务中断。

云服务概述

在今天的世界中，许多服务已经虚拟化，并且可以通过云提供。云提供了资源的可扩展性和成本效益，这些都是其成功的关键因素。

通常，云计算以以下服务模型提供：

  • 基础设施即服务（IaaS）：IaaS 为用户提供对虚拟化资源的访问，例如服务器、操作系统、存储和网络。使用 IaaS，用户还可以自定义其基础设施。例如，他们可以启用存储加密或配置服务器以访问云网络的特定部分。通常，组织会应用这种设置，将其公司数据存储在云中，并希望保护这些数据不被互联网上的人随意访问。此外，安全最佳实践是仅允许云资源访问特定的网络连接，包括公司网络。在 IaaS 中，用户可以在云服务提供商的平台上创建、配置和管理他们的虚拟基础设施，仅为所使用的资源付费。IaaS 提供了最高的控制权限，因为云消费者负责保护其操作系统、应用程序和数据—因此，事件响应者在响应安全事件时将具有更广泛和更细致的访问权限。然而，由于云提供商负责保护物理云基础设施，事件响应者可能需要与云提供商合作，如果根本原因被确定与物理主机、物理网络或物理数据中心有关。

  • 平台即服务（PaaS）：PaaS 为应用程序开发人员提供一个现成的环境，以便他们在无需配置底层基础设施的情况下构建、部署和管理应用程序。在 PaaS 中，云提供商通常根据应用程序的需求和要求打包基础设施。一些平台配置还允许开发人员使用各种流行的编程语言，如 Python、Perl、Go、Ruby、Java、Node.js 和 .NET。PaaS 设置通常允许自动扩展，这意味着根据平台操作所需的性能需求，它可以扩展并分担处理负载，并允许用户透明访问该平台。一些 PaaS 提供商还会提供应用程序监控和遥测，帮助开发人员排除故障并优化他们的应用程序，以服务于客户。PaaS 提供混合级别的控制，因为云提供商管理操作系统，而云消费者只需负责保护应用程序和数据。因此，事件响应者在请求操作系统层的任何证据时，需要与云服务提供商协作。

  • SaaS：SaaS 通过互联网以网络服务的形式向用户提供云托管的软件应用程序。例子包括薪资处理、会计软件、客户关系管理（CRM）和项目管理。云提供商管理基础设施和软件，用户可以通过网页浏览器或专用应用程序从任何具有互联网连接的设备访问软件——例如，访问托管在云上的后端服务的航空公司票务应用程序。SaaS 为云用户提供最低级别的控制，因此，事件响应者需要在应用程序级别处理任何证据/遗留物/日志，并与云提供商协作处理其他问题（如基础设施、操作系统等）。SaaS 的特点包括：

    • 多租户：软件服务可供多个用户使用，位于多个独立的云租户（共享基础设施）上。租户是指专门为用户提供的隔离服务。通过多租户，云服务相互隔离，一个用户的数据对其他用户不可见，从而确保服务中存储数据的安全性和隐私。

    • 自动更新：SaaS 提供商在无需用户干预的情况下管理其软件应用程序的更新或升级。

    • 可扩展性：SaaS 提供商能够扩展并支持大量用户和数据集。

    • 按需付费：SaaS 提供商通常以订阅模式提供服务，因此客户只需为他们所需的资源或软件服务付费。

    • 随时随地可访问：SaaS 服务通常可以从世界任何地方访问。有些 SaaS 提供商还会提供跨设备访问其服务。SaaS 提供商可能会根据访问或订阅服务的用户位置定制其服务。

  • 数据库即服务（DBaaS）：DBaaS 为用户提供受管数据库服务，允许他们在云中存储、管理和分析数据。云提供商管理基础设施、软件和数据备份，为用户提供可扩展且安全的数据库解决方案。对于 DBaaS，事件响应者的重点通常是数据库层面的数字取证（例如数据库配置、数据库日志等），如果客户启用了包括事务日志在内的数据库日志。

  • 函数即服务（FaaS）：FaaS 为用户提供特定的功能，也称为无服务器计算，允许开发人员执行代码而无需管理服务器或基础设施。它是 PaaS 的一个子集；用户可以在云提供商的平台上编写和部署代码，仅为所使用的计算资源付费。例子包括聊天机器人和物联网应用程序。一些无服务器功能包括：

    • 事件驱动：由特定事件触发，并由开发人员指定。它也可以被配置为在满足特定条件时触发。这种设置通常用于警报和通知，当发生事件时，用户会收到通知。

    • 可扩展性：自动扩展以管理功能负载和计算需求，无需手动干预。

    • 按需付费：你只为所使用的部分付费，例如，你将根据所使用的计算资源计费，或使用基于流量的定价，而不是为计算资源支付固定费用。

    • 无状态：FaaS 服务是无状态的，不会保留同一用户的多个请求之间的任何上下文或状态。它们仅按用户请求响应（执行函数）。

    • 短生命周期：函数是短暂的，意味着它们在几秒钟内执行函数并退出。只有在函数执行时才会计费，因为此时计算资源被使用。

我们将在第三章中进一步讨论一些流行云服务提供商所提供的服务和相关产品。

云部署模型

了解云服务可以通过多种方式部署，并且对调查人员具有法医学意义非常重要。这些模型是这些服务如何托管和交付给用户的框架。我们通常可以将云部署分类为四种不同的模型：公有云、私有云、混合云和社区云模型：

  • 公有云：对于所有用户和服务提供商而言，最受欢迎的选择是公有云模式。在这种模式下，服务提供商可以通过常用的基础设施交付他们的应用程序。通常，公有云用于非关键任务，或者由开发人员在公有云租户上开发和测试他们的应用程序。一些公有云服务可能还包括文件托管服务、文件共享服务和电子邮件服务等。在某些情况下，公有云服务是通过多个云服务提供商提供的，例如，通过Amazon Web Services（AWS）和Google Cloud Platform（GCP）提供的公有云应用程序，具体取决于访问网络服务的地区。公有云通常对用户更便宜，并且是按需付费的，可以根据需要进行弹性扩展或缩减。从数字取证的角度来看，在公有云域上进行调查可能会面临挑战，因为云资源通常是共享的，且保存取证数据可能很困难。有时，您也可能找不到正在寻找的相关证据，因为一些资源已终止并不再使用，而云服务提供商将开始重新分配这些资源，这使得从数字取证的角度获得洞察变得更加困难。下图展示了公有云的一些常见使用案例。具体来说，下面的图展示了可以通过公有云交付的各种应用程序，实质上允许用户免费或通过订阅费用访问这些应用程序。

图 1.2 – 公有云的示例

图 1.2 – 公有云的示例

  • 私有云：私有云是由单一组织拥有并运营的专用云基础设施，用于独占托管其应用程序，且仅对单一客户提供服务。举例来说，可能是托管一个机器学习应用程序，或者为某个组织提供虚拟桌面基础设施等。私有云的设置可以是在本地部署，或由第三方托管并具备特定控制。私有云通常构建和维护成本较高，并且允许组织根据其应用需求定义更精细的安全控制。由于私有云要求云基础设施被适当配置和保护，从数字取证的角度来看，通常可以获得取证资料供调查人员审查。由于它是私有云，云资源不会被重新分配给其他租户，因此，在私有云设置中，获得调查所需的日志/取证资料的机会更大。以下图示展示了私有云模型的一些常见使用案例。例如，商业购物应用程序、内部系统（如企业资源规划（ERP）软件）以及其他系统被托管在专用的云基础设施上，并仅提供给有限的用户群体。

图 1.3 – 私有云设置

图 1.3 – 私有云设置

  • 混合云：混合云是公共云和私有云基础设施的结合，用户将混合云视为一个透明的单一云服务。混合云基础设施通常被那些希望在高峰时段卸载处理功能或需要额外存储的组织使用。混合云还可以由一些客户通过利用本地系统并与云基础设施连接来提供额外的服务（例如，额外的存储、云备份等）。然而，从数字取证的角度来看，跨公共云和私有云的混合基础设施可能会给调查人员带来挑战，因为数据和取证资料在公共云和私有云之间分布。因此，根据所选择的部署模型，调查过程中可能会出现盲点，因为某些取证资料可能会丢失，尤其是那些托管在公共云租户中的资料。以下图示展示了一个私有云基础设施，托管内部应用程序（如 ERP 软件及其他内部应用），同时为一般用户提供像 Dropbox 或 Netflix 等服务。这些应用程序的数据备份托管在私有云基础设施中。

图 1.4 – 混合云部署模型

图 1.4 – 混合云部署模型

  • 社区云：具有共同使命的组织可以联合创建一个云基础设施，供特定用户社区使用。通常，参与该社区的组织共同分担云中托管基础设施的费用。这种设置通常由大学或非营利组织运营，这些组织为了共同的目标而联合起来。此类部署的优势是共享托管和为用户提供数据的成本和责任。社区云可以托管在本地、私有云或公共云租户中。由于共享基础设施和资源，调查人员在调查社区云中的违规行为时面临更大的挑战。对于数字取证与事件响应（DFIR）团队而言，在开始对社区云基础设施进行调查之前，确保获得合法授权是非常重要的，因为涉及多个方和多个层次的数据集。DFIR 团队应考虑审查存储在不同位置和服务器上的取证文档时所面临的挑战。图 1.5 展示了社区云，以及具有相同使命的各个组织如何共享一个共同的云基础设施。例如，银行联合建立一个云基础设施，联合向最终用户提供服务，这些可以被归类为为公众提供服务的银行社区。同样，政府机构也可以建立一个社区云基础设施，以便在一个地方为最终用户和公民提供联合服务。

图 1.5 – 社区云模型

图 1.5 – 社区云模型

总结来说，取证数据的可用性取决于云部署模型的选择以及相关数据/日志的记录和保存。

云采用成功案例

许多组织已经将云作为提供服务给客户的主要中心。了解云基础设施和应用与传统的本地 IT 环境之间的区别，以及如何有效应对云中的事件至关重要。通过研究云采用的成功案例，安全专业人员可以了解新兴的云实施趋势、相关的威胁，以及如何积极应对这些威胁。

以下案例研究展示了一些利用云技术来满足业务需求的组织实例：

  • 大型全球娱乐流媒体平台：这家大型流媒体企业采用了云计算，特别是AWS，为最终用户提供流媒体服务。作为全球领先的流媒体提供商之一，拥有来自 190 个国家的超过 2 亿会员，并且每周超过 1.25 亿小时的观看时长，它使用 AWS 进行存储、计算资源和基础设施，以实现快速扩展并满足高峰期的流媒体需求。它还在云中建立了一个虚拟工作室，让艺术人才能够无缝合作，不受任何限制。

  • 体育娱乐：另一家娱乐公司利用 AWS 提供其实时收集的赛车圈速分析数据。它使用云计算扩展接收的数据源数量，进行处理，应用预测机器学习（ML）模块，并利用高性能计算（HPC）为最终用户提供见解。这当然推动了该项运动的更高观众收视率。

  • 加拿大银行（BoC）：BoC 负责监管加拿大的银行系统；它负责制定货币政策并维持金融稳定。BoC 利用 Microsoft Azure 推出了加拿大技能计划，旨在为加拿大人提供在数字经济中蓬勃发展的所需技能。该计划通过微软的 LinkedIn Learning 平台提供免费在线课程和学习路径，涵盖云计算、数据分析和网络安全等主题。该计划在第一年内吸引了超过 7,500 名加拿大人参与，并计划在未来扩展并提供更多学习机会。

云计算和其他技术的影响

云计算对各个行业、经济乃至最重要的最终用户产生了深远影响。类似的技术创新，如机器学习（ML）、区块链和加密学、物联网（IoT）等，改变了我们使用云计算的方式。以下是相关技术创新和云计算的影响：

  • 容器：容器是将应用程序及其相关依赖项打包成一个便于部署和扩展的轻量化单元，能够快速高效地进行部署和扩展。在云计算中，容器可用于支持基于微服务的架构，提高应用程序的性能和可靠性，并增强 DevOps 流程。容器的使用还使得容器编排工具，如 Kubernetes 得以应用，它能够自动化容器化应用程序的部署、扩展和管理。这些工具提供了一种管理大规模容器部署的方法，并确保高可用性和容错能力。

  • DevSecOps：DevSecOps 是一种将安全性融入软件开发生命周期的做法，从构思阶段到执行和部署阶段都包含其中。它提倡“左移”安全、持续安全测试、自动化、协作以及使用云原生安全工具和实践。DevSecOps 通过及早识别和解决安全问题、促进一致性和减少错误，改善基于云的应用程序和基础设施的安全性和可靠性，并确保在开发过程的所有阶段一致地应用安全措施。总的来说，DevSecOps 确保在云应用的整个生命周期内，安全性始终是优先考虑的事项，从而创造一个更加安全和可靠的云计算环境。

  • 机器学习（ML）：部署在云端的机器学习模型可以利用云计算的可扩展性、自动化和可访问性，促进智能应用程序的开发，这些应用能够从数据中学习并随着时间的推移不断改进。机器学习需要大量数据来训练模型并做出准确预测，而云计算提供了处理海量数据所需的计算能力和存储空间。基于云的机器学习平台可以自动化开发机器学习模型中的许多任务，使开发人员能够更轻松地构建和部署机器学习模型，而无需在数据科学或机器学习方面具备深入的专业知识。

  • 量子计算：量子计算需要大量的硬件，将其构建在物理裸金属系统上成本高昂。它被认为是目前最具革命性的计算产品之一，通过处理目前在经典计算中无法解决的复杂问题来实现。进行量子计算有助于增强机器学习、密码学和仿真应用。

  • 区块链：另一个技术创新是区块链技术的应用，它可以实现安全透明的数据共享与交换，并且在行业领域，尤其是金融、医疗和供应链管理中具有重要的应用价值。在云计算中，区块链可以用来在分布式环境中建立信任，支持去中心化应用程序，并增强数据隐私和安全性。

  • 物联网（IoT）：物联网设备生成大量的遥测数据，这些数据可以在云端进行处理和分析。云计算提供了存储、管理和分析这些数据的基础设施和工具，使得智能家居、工业自动化和预测性维护等领域的应用场景得以实现。云计算还使得相关技术可以相互补充，例如，利用物联网的遥测数据训练机器学习模型，并通过人工智能（AI）使智能家居变得更加智能，利用这些预测技术提升其功能。

  • 身份与访问管理（IAM）：云计算推动了 IAM 技术的广泛应用，这使得组织能够管理用户身份并控制对云资源的访问。IAM 技术（如无密码认证）有助于确保只有授权用户才能访问敏感数据，并且使得实施多因素认证和基于角色的访问控制等额外安全功能变得更容易。无密码认证是一种验证和认证用户的方式，无需用户输入密码。一些无密码认证的应用包括以下内容：

    • 生物识别认证：例如，视网膜扫描、指纹识别和面部识别。

    • 公钥加密：用户需要使用公钥-私钥组合进行身份验证。私钥由用户安全保管，而关联的公钥则用于验证身份。

    • 一次性密码：这涉及一个系统生成一次性令牌，用于验证用户的身份。

    • 物理令牌：一种硬件设备，包含验证用户身份所需的信息。物理令牌也可以用来存储用户的私钥进行验证。

摘要

这是一段关于云计算的快速回顾，包括其基本概念、云计算多年来的发展，以及云计算的好处。此外，本章还讨论了各种部署模型，包括公有云、私有云和混合云，以及不同的服务模型，如 IaaS、PaaS 和 SaaS。

理解云计算对于事件响应专业人员至关重要，因为它已成为现代技术的一个重要组成部分，许多组织已经采用基于云的解决方案来存储和处理数据。因此，它是一个复杂的基础设施，深入了解如何以不同形式设置云租户及其复杂性，有助于事件响应人员有效应对安全事件并以法医学上严谨的方式进行调查。

在下一章中，我们将学习法律复杂性和数字取证与事件响应（DFIR）的影响，了解如何处理管辖权和隐私法规。

进一步阅读

第二章：网络和隐私法律趋势及其对 DFIR 的影响

在考虑云服务时，组织必须考虑将数据托管在第三方云服务提供商处所带来的法律风险。因此，也会直接影响取证文物的可用性、哪些文物可以在特定国家之外获取或访问等等。管辖权在云取证中起着关键作用。本章旨在揭示云使用过程中通常出现的法律、隐私和合同风险，以及其对取证调查的影响。

违反顾问（违反教练）的角色

违反顾问（也称为违反教练）是一位具备网络安全及相关法律框架专业知识的律师。违反顾问的职责是了解受影响组织托管的数据，并理解因网络安全事件或泄露所带来的法律影响。通常，违反教练是在安全事件或泄露可能引发诉讼的情况下被聘用（例如，未经授权的私人和敏感数据泄露导致客户身份欺诈），因此，违反教练会向受影响的组织提供建议和法律咨询，帮助其应对和处理事件。

违反教练还可以在事件进入法庭程序时代表组织出庭，但在大多数情况下，组织聘请违反教练是为了识别组织在适当时间内报告事件的法律义务，并限制诉讼的可能性。

为了让违反教练能够为受影响的组织提供法律建议，违反教练与 DFIR 团队合作，确定网络安全事件的性质和原因、私人或敏感数据泄露的程度以及与网络事件本身相关的任何额外信息。为了确保所有涉及网络安全事件的各方（违反教练、组织和 DFIR 团队）可以自由地就网络事件进行沟通，而不会泄露这些通信的风险，违反教练会行使所谓的律师-客户特权或诉讼特权。律师-客户特权或律师-客户特权保护组织、律师和 DFIR 团队之间的通信。如果通信意图为保密和特权，则该通信受到保护，不会被披露，除非该通信被视为事实性质，在某些司法管辖区内，可能无法行使特权。

诉讼特权保护专门为诉讼目的起草的文件和通信，例如，法律顾问指示准备的网络安全取证报告。

组织可能会根据其运营所在的国家/地区，聘请一名或多名漏洞顾问。

重要提示

数字取证调查员熟悉适用于不同管辖区的各种法律法规和框架，以及漏洞顾问的角色，非常重要。在需要时，DFIR 团队应当咨询漏洞顾问/顾问，以确保在收集、分析或处理可能包含敏感信息的取证证据时符合相关法律要求。

云计算采用的一般法律考虑

云计算的法律框架及其采用因国家不同而有所差异，但从整体上来看，以下是通常在法律框架中需要考虑的一些常见概念：

  • 数据保护与隐私：截至 2023 年，大多数组织必须考虑确保其在云中托管的数据的安全性。诸如但不限于欧盟通用数据保护条例（GDPR）和加利福尼亚州消费者隐私法案（CCPA）等法规，规定了如何处理和保护云中的个人数据。部分数据保护和隐私法律可能还会限制数字取证调查员将证据转移到各自管辖区之外：

    • 欧盟的 GDPR 规定了个人数据保护的具体规则，其中包括指示个人信息的处理必须在欧盟范围内合法、公平且透明，并且个人有权访问、修改和删除其个人信息。这意味着，作为调查的一部分，不能将任何证据转移到欧盟（GDPR 执行）区域之外，必须在欧盟地区本地设立并进行取证调查。调查员也可能需要与他们的欧盟同行合作，以遵守 GDPR 要求。即便您可以从全球任何地方访问证据，GDPR 仍要求任何可能包含个人信息的证据必须物理存储在欧盟境内。

    • CCPA 还概述了在涉及个人信息的事件调查中的一些注意事项。它与 GDPR 类似，规定必须合法收集证据，意味着应当有合法的依据来收集这些证据（可能包含个人信息、健康信息等），并进行调查。CCPA 还要求调查员遵守个人信息删除请求，这些信息可能是调查的一部分，并要求调查员在调查过程中采取必要的安全控制措施，防止未授权访问、销毁或篡改证据。

  • 网络风险管理：由于云服务始终可用（在线），它不断带来安全风险，包括数据泄露和网络攻击的风险。法律框架和指南通常要求云服务提供商（CSP）实施安全措施和风险管理策略，以防范这些风险。这通常包括 CSP 拥有适当的风险管理文档，包括事件响应计划，以确保 CSP 熟悉检测、遏制和从事件中恢复的程序。

    企业或云服务消费者在开始采用云服务之前，也需要建立自己的风险管理计划。这也意味着企业与云服务提供商（CSP）合作，定义一个适当的事件响应计划（明确列出 CSP 和企业之间的角色和责任），部署专门的工具来保护、检测和支持云中的调查（例如，端点检测与响应（EDR）工具），以应对网络事件，并开发熟悉云基础设施的内部或外包（以保留形式）专家。

  • 合规性：云计算必须遵守一系列法规，如行业特定的法规（如 GDPR 用于保护欧盟公民的个人信息）、金融法规（支付卡行业数据安全标准（PCI DSS））以及医疗保健法规（健康保险可携性与责任法案（HIPAA）或健康信息信托联盟（HITRUST））。法律框架和指南可能会规定 CSP 必须遵守这些法规的要求。

    此外，如果你的服务是提供给美国政府机构的，那么你的云基础设施必须证明符合联邦风险与授权管理计划（FedRAMP）。FedRAMP 计划为安全评估、访问控制与授权以及云基础设施服务的持续监控提供了一个标准化的方法和框架，以确保 CSP 在向美国政府机构提供服务之前达成必要的安全合规性。遵守 FedRAMP 确保数字取证调查员能够访问任何必要的日志和证据，因为 FedRAMP 规定了 CSP 必须维护日志和证据，保存供取证分析使用的证据，并遵守适当的法律和监管要求。然而，需要注意的是，CSP 不需要为其所有服务（整个云产品）证明 FedRAMP 合规性。

    云服务/产品通常是符合 FedRAMP 的专门化和精心挑选的云服务产品子集，专门为希望利用云服务的美国政府机构设计。因此，调查人员需要认识到，作为调查对象的云服务或产品是否符合 FedRAMP 要求，因为这可能显著影响调查过程中可用的证据和日志。

  • 适用的司法管辖区：云计算可能涉及多个司法管辖区的数据处理和存储，这可能引发关于司法管辖权和法律要求的问题。法律框架和指南可能会解决这些问题，并为跨境数据传输设定要求。

  • 合同考虑事项：云计算通常涉及云服务提供商（CSP）与其客户之间的合同协议。法律框架和指南可能会为这些协议设定要求，例如包括与数据保护、安全性和责任相关的具体条款。

总结来说，组织必须认识到在向云迁移过程中，保护存储在其系统中的信息隐私的法律框架。重要的是，它们必须采取适当的措施，防止私密和敏感信息的意外或未经授权的泄露。对于 DFIR 团队来说，理解合规要求，以支持组织的云迁移至关重要。同样，作为网络安全事件调查的一部分，理解法律要求及其目标将帮助 DFIR 团队集中精力调查私人或敏感信息泄露的根本原因和影响，并规划适当的应对措施，防止安全事件的再次发生。

eDiscovery 考虑事项与法律指导

电子发现（eDiscovery）指的是在法律或监管调查过程中，识别、收集、保全和生产存储在数字格式或电子存储介质中的数据。这包括通过专用工具和软件搜索电子存储信息（ESI），如电子邮件、文档、数据集和其他数字内容。电子发现的法律框架和指南在不断发展，但有一些广泛认可和使用的关键标准和指南。在数字取证中，电子存储信息（ESI）在调查数字犯罪或知识产权盗窃中起着关键作用。数字取证调查员依赖电子存储信息（ESI）来重建威胁行为者的活动、确定泄露的来源或识别任何嫌疑人。电子发现是这一过程中的一个关键组成部分，因为它要求调查人员以法医上可行且合法可辩的方式收集、保全和分析数据。以下是一些广泛接受的电子存储信息（ESI）标准：

  • 国际标准化组织/国际电工委员会（ISO/IEC）27050：ISO/IEC 27050：该标准为在电子发现过程中管理电子存储信息（ESI）提供了一个全面的框架。它旨在帮助组织确保它们遵守与电子发现相关的法律和监管要求，同时保护敏感数据的机密性、完整性和可用性。ISO/IEC 27050 的关键要素包括以下内容：

    • 识别：此阶段涉及识别可能受到法律请求或调查的相关电子存储信息（ESI）。这包括存储在服务器、电子邮件、移动设备或其他数字格式中的数据。

    • 保全：一旦确定了相关的电子存储信息（ESI），必须确保它被保全，以防止其被修改或销毁。这可能包括在任何审查或调查之前制作数据副本、实施法律保持措施，或限制对某些数据的访问，确保数据不能被任何人销毁。

    • 收集：在电子存储信息（ESI）被保全之后，必须对其进行收集和分析，以确定其与法律请求或调查的相关性。这可能包括搜索特定的关键词或短语、审查元数据，或使用取证工具从数字设备中提取数据。

    • 分析：一旦电子存储信息（ESI）被收集，必须对其进行分析，以确定其在法律请求或调查中的重要性和相关性。这可能包括审查数据以识别模式或趋势，或使用分析工具从大数据集中提取见解。

    • 生产：必须将相关的电子存储信息（ESI）提供给请求方或相关主管机关。这可能涉及提供数据副本、制作数据报告或摘要，或在法庭上作为专家证人作证。

  • 云安全联盟（CSA）指南：CSA 提供了一系列与云计算相关的指导文件，包括关于云环境中电子发现的指导。CSA 的指南旨在帮助组织应对云中电子发现的独特挑战，如数据隐私、安全性以及法律和监管合规性：

    • 数据隐私：CSA 建议组织实施强有力的数据隐私控制措施，以保护电子发现过程中敏感数据的安全。这可能涉及使用加密技术保护静态数据和传输中的数据、实施访问控制以限制数据访问权限，或使用数据遮蔽技术来模糊敏感信息。

    • 安全性：CSA 建议组织实施适当的控制措施，以防止电子发现过程中发生泄露和安全事件。这可能包括使用安全监控工具来检测和响应威胁、实施多因素身份验证以防止未经授权的访问，或使用入侵检测和预防系统来检测并阻止恶意活动。

    • 法律和监管合规性：CSA 建议组织确保其遵守与电子发现（eDiscovery）相关的法律和监管要求。这可能涉及定期进行风险评估、实施电子发现的政策和程序，或聘请法律顾问提供关于法律和监管问题的指导。

  • 联邦民事诉讼规则（FRCP）：FRCP 是一套监管美国联邦法院民事诉讼程序的规则。这些规则已经多次修订，以应对电子发现问题。例如，规则要求各方在预计发生诉讼时，实施适当的程序以保留任何包含相关信息的数字内容。规则还确立了电子发现的范围，包括任何可以引出可采证据的支持信息，如工作文件。

  • 塞多纳会议：塞多纳会议是一个非营利性的法律研究和教育组织，提供有关多个问题的法律指导，包括电子发现。该组织发布的出版物涵盖了各种电子发现原则，如比例性、数据隐私、使用技术辅助审查、保全、电子发现过程中的记录管理、跨司法管辖区的电子发现，以及因电子发现而产生的成本和责任。塞多纳会议的出版物常常被法院在电子发现案件中引用，并广泛被认为是电子发现问题的权威指南之一。

  • 电子发现参考模型（EDRM）：EDRM 是一个框架，概述了电子发现过程的各个阶段，从信息管理到制作。该框架旨在为电子发现活动提供一种共同的语言和结构，帮助法律事务各方更有效地理解和管理电子发现过程。EDRM 框架包括九个步骤，分别是信息管理、识别、保存、收集、处理、审查、分析、制作和呈现。每个阶段都设计为在前一个阶段的基础上进行，目标是提供准确、完整且具有法律防御性的证据，以便在法律程序中使用。

总结而言，无论调查人员选择遵循哪个电子发现框架，用于发现、收集、保存和呈现电子存储信息的基本程序通常是相似的。世界各地的法院期望电子存储信息（ESI）以法医合理和具有法律防御性的方法进行收集。

数字法医挑战

云为组织带来了显著的好处，包括更高的灵活性、可扩展性和成本节省。然而，在电子发现和法医调查方面，它也带来了新的挑战。以下列出了调查人员可能遇到的一些常见挑战。每个云法医案件可能会提出独特的挑战，但以下是一些常见的主题：

  • 数据复杂性和量：云为组织提供了几乎无限的存储容量，这意味着在电子发现和法医调查过程中，需要搜索、收集和分析的数据量可能会令人难以承受。

  • 数据安全：云服务提供商负责确保其系统中存储的数据安全，但组织也有责任确保在电子发现和法医调查过程中其数据得到保护。这在多租户云环境中尤为具有挑战性，因为多个组织的数据存储在同一台服务器上。

  • 司法管辖问题：云数据可以存储在多个司法管辖区，这可能使得确定适用于电子发现（eDiscovery）和法医调查的法律法规变得困难。尤其是在数据存储在拥有严格数据保护法律的国家时，这一问题尤为突出，因为组织可能需要在复杂的法律框架下操作以访问和处理数据。法医调查人员必须通过违规教练（法律顾问）获得传票，以便让他们搜索和访问可能由其他司法管辖区的云服务提供商（CSP）托管的数据。云服务提供商可能还会有政策和程序，这可能进一步妨碍获取必要的信息。这显然需要多方合作（组织、调查人员、云服务提供商、违规教练）以允许访问调查对象的相关资料。

  • 缺乏透明度：云服务提供商（CSPs）通常使用专有技术和流程来管理其云基础设施，这可能使得组织难以了解其数据是如何存储、访问和保护的。缺乏透明度可能使组织在进行有效的电子数据发现（eDiscovery）和取证调查时遇到困难。

  • 技术挑战：在云环境中进行电子数据发现和取证调查需要专门的技术技能和工具。这包括从云中各种来源收集和分析数据的能力，包括结构化和非结构化数据集，以及确保数据以取证上可行的方式进行保存的能力。

  • 数据位置和访问：云服务提供商（CSPs）通常将数据分布在不同的位置或区域（即使是在同一国家，数据也会分布在多个存储区，以确保可用性）。这使得调查人员很难找到并访问相关数据。云服务提供商还可能有自己的访问控制，限制或阻止某些数据集的访问。

总结来说，DFIR（数字取证与事件响应）团队在处理云调查案件时将面临这些挑战。在现实中，这通常会因跨司法管辖区的法律要求、电子数据发现要求以及遵循各种法律要求确保调查在法庭上可接受而变得更加复杂。然而，提前熟悉这些挑战并围绕它们规划调查是非常重要的。

私人数据的法律框架

一般来说，私人数据是指任何个人或敏感性质的数据，这些数据不应公开传播。例如，您的姓名、出生日期、地址和社会保障号码（SSN），这些通常被归类为个人身份信息（PII），意味着这些数据集可用于识别某个人。支付卡信息（PCI）是一类机密数据集，包括银行账户、信用卡号码、卡片验证号码以及卡片的到期月份和年份。最后，还有像医疗记录、诊断和评估报告、X 光报告以及心理评估报告这样的数据，称为个人健康信息（PHI），这类数据本质上是敏感的。

信息的敏感性对事件响应者和数字取证调查员也构成挑战。私密数据通常受到数据隐私和安全法律法规（如 GDPR、CCPA 等）的保护，因此公司和事件响应者有责任采取适当措施保护私密数据，并防止未经授权的访问、使用或泄露。这也意味着公司必须履行必要的合同义务，以确保私密数据保持私密。从云取证的角度来看，取证调查员需要了解托管在云中的各种数据集的细微差别。下一节中将介绍一些法律方面的考虑事项。

合同私密数据

任何在合同协议中各方之间共享的信息都被视为机密，不应公开分发。这类数据通常受到合同条款以及适用的数据隐私和安全法律法规的保护。示例包括商业秘密、财务信息、员工或客户的个人信息以及有关产品或服务的专有信息。合同各方可能需要签署保密协议（NDA）或保密条款，明确规定哪些信息被视为机密，以及各方在保护这些信息方面的义务。

受监管的私密数据

这指的是任何受监管或受到法规保护的信息。例如，医疗记录、财务记录和个人身份信息（PII）。如果公司未能保护这些受监管的数据集，将会面临经济处罚和制裁。从事件响应的角度来看，以下是组织应考虑的一些因素：

  • 监管合规：收集、处理或存储受监管私密数据的组织必须遵循如 HIPAA 或 GDPR 等法规。DFIR 团队必须熟悉这些法规，并确保他们的行为不违反任何合规要求。

  • 隐私法律：隐私法律规定了受监管的私密数据应如何收集、处理和存储。DFIR（数字取证与事件响应）团队必须考虑这些隐私法律，以确保他们的行为不会侵犯涉及的个人或组织的隐私权。

  • 数据保留政策：收集受监管私密数据的组织通常有特定的数据保留政策，规定数据应存储多长时间。通常，这一期限从 1 年到 10 年不等。DFIR 团队必须注意这些政策，以确保不会销毁任何应保留的数据。

  • 证据链：DFIR 团队必须保持在调查过程中收集的所有数据的适当证据链。对于受监管的私人数据尤其至关重要，因为任何不当处理或未经授权的披露都可能导致重大的法律和财务后果，包括对公司和 DFIR 团队的经济处罚。

  • 通知要求：许多法规要求组织在发现或确认数据泄露后的特定时间内通知受影响的个人或监管当局，包括隐私专员办公室（如果适用）。DFIR 团队必须了解这些通知要求，并确保与泄露事件顾问（breach coaches）合作，处理通知要求。泄露事件顾问将为 DFIR 团队提供泄露通知要求的指导，帮助他们优先处理某些调查领域，并确保符合通知要求。

与私人数据相关的司法管辖区要求

私人数据可能受到不同司法管辖区的特定法律要求和保护，处理涉及私人数据的事件时，必须遵守这些要求。这也包括这些司法管辖区规定的通知要求。例如，欧盟的 GDPR 要求组织在 72 小时内通知相关当局和个人，若数据泄露影响到私人数据。加利福尼亚消费者隐私法案（CCPA）要求企业在个人信息泄露或遭遇数据泄露时立即通知受影响的相关方/客户。

在 DFIR 工作中，这些司法管辖区的要求可能影响私人数据的收集、处理和共享。例如，数据可能需要以特定方式进行收集和处理，以遵守当地的隐私法律。同样，与执法机关或其他第三方共享数据可能需要法律批准或特定的合同协议。DFIR 专业人员必须熟悉相关司法管辖区的要求，并与法律团队和泄露事件顾问密切合作，确保在处理涉及私人数据的事件时，所有法律和监管要求得到满足。未能遵守这些要求可能会导致组织以及参与调查的个人面临重大的法律和财务后果。

以下法规影响着众多行业和组织，DFIR 团队应根据所调查和分析的数据类型，熟悉这些法规：

  • 健康保险流通与责任法案（HIPAA）：除 GDPR 和 CCPA 外，美国还存在其他隐私法律，其中一些是联邦层面的，例如 HIPAA，它旨在保护个人健康信息的隐私，并要求医疗服务提供商确保保护私人和敏感信息，同时报告任何泄露事件。

  • 公平信用报告法案（FCRA）：该法律规范了消费者报告机构、雇主和其他实体对信用信息的收集、使用和披露。它还赋予消费者访问和更正其信用信息的权利。

  • 家庭教育权利和隐私法案（FERPA）：该法律保护学生教育记录的隐私，并赋予家长和学生访问和更正这些记录的权利。

  • 格兰姆-利奇-布莱利法案（GLBA）：该联邦法律规范了金融机构收集、使用和披露的个人信息。它要求这些机构保护这些信息并向消费者提供其隐私政策的通知。

  • 电子通信隐私法案（ECPA）：该法律规范了电子通信的拦截，并制定了获取和披露由第三方服务提供商存储的电子通信的规则。

  • 儿童在线隐私保护法案（COPPA）：该法律为在线服务提供商提供了有关收集儿童个人信息的指南，特别是 13 岁以下儿童的信息。它要求在线服务提供商在收集儿童个人信息之前获得其父母的同意。

  • 视频隐私保护法案（VPPA）：该法律规范了视频租赁和流媒体服务对个人视频观看信息的收集、使用和披露。它要求这些服务在披露该信息之前获得同意。

  • 国际标准化组织/国际电工委员会（ISO/IEC）27018：ISO/IEC 27018 于 2014 年首次发布，是为保护公共云环境中的个人身份信息（PII）提供指南的标准。DFIR 团队应注意，这是一项标准而非必须遵守的法规。然而，该标准为实施控制措施保护 PII 并帮助客户和监管机构评估 CSP 实施的安全性提供了框架。指导领域包括以下内容：

    • 数据处理的同意与通知：该标准要求 CSP 在收集、使用和披露客户个人信息之前获得客户的同意，并提供关于如何使用其信息的通知。

    • 关于分包商的透明度：该标准要求 CSP 披露可能接触客户个人信息的分包商的使用情况。

    • 数据使用的限制：该标准要求 CSP 限制客户的个人身份信息的使用范围，仅限于其收集的目的，并且如果该信息将用于其他目的，必须获得额外的同意。

    • 安全性和保密控制：该标准要求 CSP 实施安全性和保密控制措施，以保护客户的个人信息，如加密，包括数据标记化、访问控制和事件响应程序。

    • 数据保留和销毁：标准要求云服务提供商（CSP）必须建立个人信息保留和销毁的政策和程序，并确保在数据不再需要时安全销毁。

  • 公认隐私原则（GAPP）：由美国注册会计师协会（AICPA）和加拿大特许会计师协会（CICA）制定的隐私框架，旨在解决隐私问题。GAPP 基于公平信息实践（FIP）开发的 10 条基本隐私原则，用于维护隐私。其包括以下内容：

    • 管理：组织必须指定个人或团队负责信息治理，并实施符合相关隐私法律的适当政策和程序。

    • 通知：组织必须通知个人并详细说明收集、使用、保留和披露的个人信息。

    • 选择与同意：个人或客户有机会选择是否分享私人数据。如果他们选择不分享，可以选择退出，包括在收集、使用和披露个人信息时的选择退出。

    • 收集：组织必须清楚地列出并收集其业务目的所必需的特定个人信息。

    • 使用、保留和销毁：组织仅应将个人信息用于业务目的，并以安全的方式进行销毁。

    • 访问：组织必须向个人/客户提供访问其个人信息的权限，并允许其更改、更新或澄清任何不准确之处。

    • 向第三方披露：组织仅能在获得个人同意或法律要求的情况下，向第三方披露或分享个人信息。

    • 隐私安全：组织必须实施保障措施，确保个人或私人信息免受未经授权的访问、处理、披露或销毁。

    • 质量：与访问类似，组织必须确保收集的个人或私人信息是准确和最新的。

    • 监控与执行：组织必须监控并确保遵守上述原则，并采取适当行动解决任何违规行为。

  • 通用数据保护条例 (GDPR)：欧盟的隐私法规，要求组织遵守个人数据的管理方式。GDPR 适用于任何收集和处理欧盟居民和公民个人可识别信息（PII）的组织，无论其地理位置如何。GDPR 列出了数据控制者和处理者的关键要求：

    • 同意：组织在处理个人数据之前必须征得个人的许可，例如，他们应使用具有同意管理工具的客户关系管理软件（CRM），该工具记录用户同意收集、存储和处理其信息的情况。

    • 透明性：组织必须向个人提供关于收集和处理其个人数据目的的清晰信息。

    • 数据主体权利：个人有权访问、管理其个人数据的准确性或删除其个人数据。

    • 数据最小化：组织只能收集和处理对其业务所必需的个人数据。

    • 安全性：组织必须实施适当的控制措施，以确保个人数据的安全。

    • 问责制：组织必须能够证明符合 GDPR 要求，包括实施适当的数据保护政策和程序。

注意

GDPR 还包括严格的数据泄露通知要求，组织必须在意识到数据泄露后的 72 小时内向监管机构报告任何泄露事件。不遵守 GDPR 可能会导致重大罚款和声誉损害，因此组织必须确保遵守该法规。

  • 隐私影响评估（PIA）：PIA 提供了详细的步骤，帮助组织审查、解决和识别与项目相关的隐私风险。它提供了一个全面的评估标准，用于验证个人信息的收集、使用、存储和处理方式。PIA 过程帮助组织在隐私风险出现之前识别和减轻这些风险，同时确保隐私考虑因素融入项目或计划的设计和实施中。这有助于与利益相关者（包括客户和员工）建立信任，并避免与隐私泄露相关的法律和声誉风险。

注意

在一些司法管辖区，如欧盟的 GDPR 下，PIA 可能是某些类型数据处理活动的强制要求，例如涉及敏感个人数据或大规模处理个人数据的活动。

  • 在加拿大，一些主要的隐私法律包括以下内容：

    • 个人信息保护和电子文档法（PIPEDA），为企业和组织管理和处理个人信息提供框架。

    • 对于由联邦政府主导的机构，存在隐私法，该法定义了收集、使用和披露个人信息的规则。

    • 加拿大反垃圾邮件法（CASL）规定了电子邮件等信息的发送，并要求在发送这些信息之前获得先前的同意。

    • 信息自由与隐私保护法 (FIPPA) 适用于不列颠哥伦比亚省的公共组织，并规定了个人信息的收集、使用和披露的指南。它要求这些组织保护个人信息，并为个人提供访问自己个人信息的权限。

    • 个人信息保护法 (PIPA) 仅适用于加拿大阿尔伯塔省的企业。该法律要求组织在阿尔伯塔省进行商业活动时，在收集、使用或披露个人信息之前获得同意。

    • 加拿大魁北克省第 25 号法案 是一项旨在现代化个人信息保护法律要求的法律。根据第 25 号法案，私营部门组织在收集、处理或披露个人信息时，必须获得个人或客户的同意。第 25 号法案还要求组织采取措施设立防护措施以保护个人信息，并报告任何数据泄露。魁北克省有自己的隐私监管机构——信息访问委员会 (CAI)，该委员会负责监管和执行省内的隐私法律。DFIR 团队应了解 CAI 在调查和执行魁北克省隐私泄露方面的角色，并应与违约指导人员密切合作，确保遵守这些法律。

总结来说，这一法律的核心是要求组织在收集和使用信息之前获得同意，并明确说明收集个人信息的商业目的。组织最终负责部署适当的控制措施以保护个人信息。同样，对于数字取证与响应（DFIR）团队来说，了解这些隐私法律和司法管辖要求至关重要，因为违约指导人员将依赖 DFIR 团队提供基于适用司法管辖和监管要求的适当建议。

以下表格概述了各种隐私法律的简要视图，包括其适用的司法管辖区、关注领域和通知要求。

适用的 法律 适用的 司法管辖区 关注领域 通知受影响个人的要求
通用数据保护条例（GDPR） 欧盟 个人数据保护、数据主体权利、数据控制者和处理者的数据处理、跨境数据转移、数据泄露 一旦意识到数据泄露，必须在 72 小时内通知监管机构；在可能的情况下，通知受影响的个人。
加利福尼亚消费者隐私 法案 (CCPA) 美国加利福尼亚州 个人数据保护、数据主体权利、消费者隐私、个人信息出售 在发现数据泄露后，不迟于 45 天内，及时向受影响的个人和加利福尼亚州总检察长通知数据泄露事件。
个人信息保护与电子文件 法案 (PIPEDA) 加拿大（适用于联邦监管的组织） 个人数据保护、同意、数据主体权利、数据保存与销毁、数据传输 在发生数据泄露后，尽快通知受影响的个人和加拿大隐私专员办公室。
健康保险流动性和责任 法案 (HIPAA) 美国 个人健康信息保护、数据安全与保密、数据主体权利 在发现健康信息泄露后，60 天内向受影响的个人、美国卫生与公共服务部和媒体（如有需要）通知泄露事件。
个人数据保护 法案 (PDPA) 新加坡 个人数据保护、数据主体权利、数据控制者和处理者的数据处理、跨境数据传输、数据泄露 在发现数据泄露后72 小时内，向受影响的个人和个人数据保护委员会通知数据泄露事件。
隐私保护盾 框架 美国、欧盟 跨境数据传输 在发现数据泄露后，尽快并在 72 小时内向受影响的个人和相关主管部门通知数据泄露事件。
个人信息保护 法案 (PIPA) 韩国 个人数据保护、数据主体权利、数据控制者和处理者的数据处理、跨境数据传输、数据泄露 在发现数据泄露后，尽快并在 24 小时内向受影响的个人和韩国通信委员会通知数据泄露事件。
数据保护 法案 2018 英国 个人数据保护、数据主体权利、数据控制者和处理者的数据处理、跨境数据传输 在发现数据泄露后72 小时内，通知泄露事件的详细信息。
个人信息保护 法案 (PIPA) 加拿大不列颠哥伦比亚省 个人数据保护、同意、数据主体权利、数据保存与销毁、数据传输 在发现个人信息泄露后，尽快向受影响的个人和不列颠哥伦比亚省信息与隐私专员办公室通知泄露事件。
个人信息保护法（PIPA） 加拿大阿尔伯塔省 个人数据保护、同意、数据主体权利、数据保留和处置、数据转移 一旦组织确定发生泄露，应尽快向受影响的个人和阿尔伯塔省信息与隐私专员办公室通知个人数据泄露。
个人信息保护法（P-39.1） 加拿大魁北克省 个人数据保护、同意、数据主体权利、数据保留和处置、数据转移 一旦组织确认个人信息泄露发生，应没有不当延迟并尽快向受影响的个人和信息访问委员会通知数据泄露。
个人信息保护法（PIPA） 加拿大安大略省 个人数据保护、同意、数据主体权利、数据保留和处置、数据转移 一旦组织确认泄露发生，应尽快向受影响的个人和安大略省信息与隐私专员办公室通知个人数据泄露。
生物特征信息隐私法（BIPA） 美国伊利诺伊州 生物特征数据保护、同意、数据主体权利 一旦发现泄露，在没有不合理延迟的情况下，并在 30 天内 向受影响的个人、伊利诺伊州总检察长和伊利诺伊州创新与技术部门通知数据泄露。
加州隐私权法（CPRA） 美国加利福尼亚州 个人数据保护、数据主体权利、消费者隐私、个人信息销售 一旦发现泄露，在没有不当延迟的情况下，并在 45 天内 向受影响的个人和加利福尼亚州总检察长通知个人数据泄露。
停止黑客攻击并改善电子数据安全法（SHIELD 法案） 美国纽约 个人数据保护、数据安全、数据泄露通知 向受影响的个人和纽约州总检察长在没有不合理延迟的情况下，并在 合理时间内 通知数据泄露。

表 2.1 – 隐私法律及相关数据泄露通知要求的摘要视图

数据保留和删除的法律影响

存储和保留数据，包括在多租户云环境中，可能会对组织产生重大法律影响。这些影响可能因存储的数据类型、数据存储的司法管辖区以及适用的法律和法规而有所不同。具体来说，包括以下内容：

  • 数据保留要求：根据数据的类型和存储的司法管辖区，组织可能需要根据法律要求保留数据一定时间。未能遵守这些要求可能导致罚款和处罚。

  • 数据隐私法：数据隐私法，如欧盟的 GDPR，对个人数据的收集、使用和披露提出严格要求。存储和保留个人数据的组织必须遵守这些法律，包括实施适当的安全措施以保护数据。

  • 数据泄露通知法：许多司法管辖区有数据泄露通知法，要求在发生数据泄露时，组织必须通知受影响的个人和监管机构。存储和保留数据的组织必须具备适当的数据泄露通知政策和程序，以遵守这些法律。

  • 知识产权法：在云环境中存储和保留数据可能涉及与数据所有权和控制相关的知识产权法律。

财产法

一系列法律，用于保护人类智慧的创造物，如发明、文学、艺术作品、符号、名称和图像。这些法律旨在保护发明者并鼓励创造性自由。

  • 电子发现要求：组织可能需要根据法律请求提供数据，例如在诉讼或政府调查期间。未能保留与这些请求相关的数据可能会导致法律制裁。

另一方面，从法律合规和数字取证角度来看，数据删除具有非常重要的影响，尤其是在数据保留涉及法律和监管指南的强制执行时。在一些司法管辖区，未能遵守保留要求可能会引发财务处罚，因为监管机构会视其为数据处理不当。从取证角度来看，如果删除的数据包含敏感数据或违法行为的证据，可能会对组织的声誉造成重大影响，同时也会影响取证调查。

云服务商的责任和义务及其对事件响应的影响

随着云计算的普及，数字取证响应（DIFR）变得更加复杂。因此，它对数据泄露和其他安全事件的责任和义务分配具有重要影响。在云计算中，涉及多个不同的方，包括云服务提供商（CSP）、云客户以及可能参与的任何第三方服务提供商。这些方的角色不同，因此在发生安全事件时，可能面临不同的责任和责任暴露。

云服务提供商（CSP）通常对安全事件承担更高的责任和义务，因为他们负责云基础设施的整体安全性和可用性。这包括维护数据中心的物理安全性、保护网络基础设施以及实施安全控制以保护客户数据。

云客户对安全事件负有责任，因为他们负责配置和保护自己在云环境中的应用程序和数据。这包括实施适当的访问控制、加密敏感数据以及监控自己的系统以应对安全事件。DFIR 团队需要理解，威胁行为者总是会试图利用暴露在互联网上的内容。因此，如果客户的网页应用程序面向互联网，威胁行为者会尝试利用客户所拥有和托管的应用程序中的漏洞，而不是云基础设施本身。

在 DFIR 的范畴内，云计算中的责任和义务具有重大影响。DFIR 调查可能需要访问存储在云环境中的数据，如果数据被加密或访问控制未正确配置，获取这些数据可能会面临挑战。CSP 也可能有自己的事件响应流程，在发生安全事件时需要遵循，这可能会影响 DFIR 团队及时有效地进行调查的能力。

最终，云计算中的责任和义务可能大相径庭，并且会影响 DFIR 调查。组织必须理解自身的责任，并与 CSP（云服务提供商）密切合作，确保有适当的安全控制措施，并且事件响应流程得到明确定义并被理解。

法域与跨境数据传输

当数据跨境传输时，可能会受到不同法律框架和法规的约束。这可能包括数据隐私法、数据本地化要求以及政府监控法。例如，欧盟的 GDPR 对跨境数据传输有严格要求，这可能会影响组织将数据传输到位于欧盟以外的 CSP 的能力。

作为事件响应人员，了解跨境数据传输的法律影响尤其重要，特别是在进行 DFIR 调查时。根据地区和全球法律框架的不同，访问存储在云中的数据可能会受到限制，或者在访问数据之前可能需要满足额外的法律要求。

因此，作为事件响应人员，了解现有法律框架并制定适当的事件响应计划是非常重要的，这些计划应考虑到云计算所带来的独特挑战。通过这样做，我们可以帮助确保调查以法医合理的方式进行，同时保护数据的隐私和安全。

总结

本章提供了 DFIR 团队在开展涉及云计算的案件取证调查之前需要考虑的各种法律和隐私方面。对法律要求的基本理解无疑能帮助 DFIR 团队确保所有事件响应操作都符合法律和监管要求。本章的关键内容包括以下几点：

  • 这关乎管辖权：数据存储在哪里？它是在云系统上还是在物理服务器上？对于 DFIR 团队而言，理解数据存储的位置，以及在收集或转移数据进行调查之前是否有任何法律要求是非常重要的。

  • 私人数据：DFIR 团队必须非常清楚受影响系统上托管的数据类型。这可能是 PII（个人身份信息）、PHI（个人健康信息）、PCI（支付卡行业数据）或任何其他敏感数据，甚至是它们的组合。然而，在收集和分析数据之前，考虑各管辖区的法律要求非常重要。请记住，DFIR 团队需要确保在分析任何敏感信息之前，明确从组织方面获得同意，同时还需实施必要的安全控制措施，确保只有授权和合格的团队成员才能分析敏感数据。分析完成后，DFIR 团队应考虑安全删除数据。

  • 各种法律法规：DFIR 团队显然面临着紧跟各种法律、法律框架、指导通知等的艰巨挑战。因此，法律顾问或泄露教练将成为你们最好的朋友，特别是为 DFIR 团队提供关于各类法律要求、通知要求以及在收集、存储和维护此类敏感数据之前的同意建议。

通过前几章的学习，我们了解到数据在云端及其他地方的存储。收集和处理个人信息对组织来说责任重大，而对 DFIR 团队而言，更大的责任是识别出涉及个人信息泄露的根本原因。鉴于各种法律强制执行响应和泄露通知，DFIR 团队必须非常清楚如何调查泄露，尤其是在数据存储于云端的情况下。

在接下来的几章中，我们将重点介绍云计算基础知识，并展示从调查角度来看可能至关重要的日志存储位置。我们还将审视各种云服务提供商（CSP）及其相应的能力，帮助 DFIR 团队在调查过程中获得支持。

进一步阅读

第三章：探索主要的云提供商

如在第一章中讨论的那样，云计算已成为许多希望现代化其 IT 基础设施并利用云采用好处的组织的首选。作为事件响应者，重点关注流行云服务提供商的数字取证非常重要，因为它们已被组织广泛采用。在市场上排名靠前的云服务提供商中，您很可能会在下一个云取证项目中遇到三个主要的云提供商：亚马逊网络服务（AWS）、微软 Azure和谷歌云平台（GCP）。

了解这些提供商的工作方式、他们的安全措施以及取证数据存储的位置，对于那些希望确保数据和应用程序安全的组织至关重要，同时也对于事件响应者在应对安全事件时至关重要。每个云服务提供商都有其独特的架构和安全控制，必须理解这些内容，以确保取证调查能够有效进行。例如，AWS、Azure 和 GCP 在数据存储、访问控制和日志记录方面的处理方式各不相同，这可能会影响取证调查。

在本章中，我们将探讨了解这三大常见云服务提供商及其常用服务的重要性。通过了解云服务提供商，组织可以更好地准备应对安全事件，并进行云中的取证调查。

注意

本章的目的是让读者对业内领先的云服务提供商及其产品有一个大致的了解——我们将在本书的第二部分和第三部分中深入探讨每个云提供商的日志资源和事件响应。

亚马逊网络服务（AWS）

2006 年推出的 AWS 是一个云计算平台，提供广泛的服务，帮助组织构建和部署其应用程序和基础设施。AWS 提供大规模的基础设施和计算资源，允许组织将其整个 IT 基础设施虚拟化到云端，这使得 AWS 成为许多组织的关键工具。特别是事件响应者，必须深入了解 AWS，因为它已成为托管关键系统和服务的最流行平台之一。

AWS 提供了丰富的服务，每项服务都旨在满足组织和开发人员的特定需求。AWS 提供的服务超过 200 项，对于新用户来说，可能会觉得平台有些让人迷惑。在本节中，我们将重点介绍组织各个规模常用的核心服务。这些服务包括计算服务，如亚马逊 弹性计算云（EC2）；存储服务，如亚马逊 简单存储服务（S3）；数据库服务，如亚马逊 关系数据库服务（RDS）；网络服务，如亚马逊 虚拟私有云（VPC）；以及安全服务，如 AWS 身份与访问管理（IAM）。

我们将探讨事件响应人员应该熟悉的关键 AWS 服务，并解释为什么了解 AWS 对于现代 IT 环境中的有效事件响应至关重要。

亚马逊弹性计算云（EC2）

亚马逊 EC2 是 AWS 提供的一个网络服务，允许组织创建虚拟化基础设施或服务器（也称为虚拟机）并将其运行在云端。EC2 使组织能够完全控制其计算资源，并为构建应用程序提供可扩展和灵活的基础设施。使用 EC2，组织可以启动和管理被称为实例的虚拟服务器，这些实例可以配置不同的计算能力、存储容量和网络功能。值得注意的是，对于数字取证和事件响应（DFIR）团队来说，AWS 将这些虚拟机称为实例，每个虚拟机都有一个实例标识符。

EC2 提供了多个优势，使其成为各类组织的重要工具。首先，它提供按需扩展功能，这意味着组织可以根据需求变化轻松调整计算资源。EC2 还提供了高可用性，具有多个可用区和自动故障切换功能。此外，EC2 高度可定制，允许组织从各种实例类型、操作系统和软件配置中进行选择。

以下截图展示了通过网页图形用户界面（GUI）创建亚马逊 EC2 实例的过程，包括自定义虚拟机操作系统、硬件、网络和存储能力的选项。

图 3.1 – 在亚马逊 EC2 中启动实例

图 3.1 – 在亚马逊 EC2 中启动实例

组织还可以利用 AWS 的命令行界面（CLI）来创建实例和其他 AWS 资源。AWS CLI 是 AWS 提供的一个强大工具，允许组织通过命令行界面管理其 AWS 资源和服务。举个例子，组织可以通过运行特定命令，如 aws ec2 run-instances，后接你通常通过 GUI 定义的必要参数，如实例类型、安全组和密钥对，来创建实例。这使得组织能够自动化 AWS 中实例创建和配置的过程，提高效率和可扩展性。

对于事件响应人员来说，EC2 特别重要，因为它为响应安全事件提供了灵活且可扩展的基础设施。在事件发生期间，EC2 实例可以快速启动（即通过创建新的虚拟机）来应对增加的工作负载。EC2 实例可以轻松地被隔离和隔离处理，允许事件响应人员遏制事件并防止其蔓延到组织的其他部分。

亚马逊虚拟私有云（VPC）

Amazon VPC 是一项基于云的网络服务，使组织能够在 AWS 云中创建和管理自己的私有虚拟网络。通过 VPC，组织可以创建 AWS 云的隔离部分，称为子网，并通过自定义网络访问控制列表（ACLs）和安全组控制对这些子网的访问。请注意，默认情况下，当你在 AWS 中创建新实例时，AWS 会自动创建一个 VPC 实例。VPC 提供默认配置，但允许你根据需要自定义配置。与 AWS EC2 实例类似，每个 VPC 都通过 VPC ID 由 AWS 进行标识。可以根据需要创建 VPC，或者可以在 AWS VPC 仪表板中访问任何现有的 VPC。以下图示展示了一个 VPC 示例：

图 3.2 – 亚马逊 VPC 示例

图 3.2 – 亚马逊 VPC 示例

从数字取证和事件响应的角度来看，VPC 提供了几个关键的优势。首先，它使组织能够为其计算资源创建一个隔离且安全的环境，从而降低未经授权访问或数据泄露的风险。其次，它提供了对网络流量的精细控制，使组织能够监控和限制对特定资源和子网的访问。最后，它使组织能够创建一个集中的日志记录和监控解决方案，从而更容易检测和响应安全事件。

在 VPC 中响应事件时，响应人员必须首先识别受影响的资源并将其隔离在 VPC 内。然后，他们可以使用 AWS 工具，如 AWS CloudTrail 和 AWS CloudWatch，来监控网络流量并识别任何可疑活动。事件响应人员还可以利用 VPC 的自定义网络 ACL 和安全组来限制对受影响资源的访问，限制事件的蔓延。在 AWS 中响应事件将在本书的 第二部分 讨论。

亚马逊简单存储服务（S3）

亚马逊 S3 是 AWS 提供的一项基于云的对象存储服务。S3 使组织能够以高度可扩展、安全且具成本效益的方式存储、检索和管理大量数据。S3 是许多组织数据存储和备份策略的重要组成部分，广泛应用于数据湖、网页和移动应用程序、备份以及灾难恢复等多种场景。AWS 将每个 S3 实例称为 桶，并且默认情况下，当一个组织创建一个 S3 桶时，它在互联网上是不可公开访问的。你需要进行必要的更改，以允许在互联网上公开访问。然而，请注意，S3 桶的错误配置将导致 S3 上的数据可以在互联网上公开访问（即使本意并非如此）。因此，确保 S3 桶的配置得当非常重要。

从数字取证和事件响应的角度来看，S3 提供了几个关键的好处。首先，它使组织能够以安全且可扩展的方式存储大量数据，从而使调查员和响应人员更容易访问和分析数据。其次，S3 提供了一系列的安全和合规功能，包括加密、访问控制和审计日志，有助于组织保护其数据并遵守相关法规。最后，S3 使组织能够迅速轻松地从数据丢失或损坏中恢复，减少事件对其运营的影响。

数字取证调查员可以利用 S3 在一个安全且可扩展的环境中分析数据。通过访问组织的 S3 桶，调查员可以检查存储在其中的数据，识别模式和异常，并提取相关证据。他们还可以利用 S3 的审计日志功能来跟踪桶的更改，并识别任何可疑活动。

以下截图展示了创建 AWS S3 桶的过程。桶需要一个名称以及 AWS 区域作为一般配置，所有权/访问配置以及服务器端加密。

图 3.3 – 创建 S3 桶

图 3.3 – 创建 S3 桶

AWS 身份与访问管理（IAM）

AWS IAM 是 AWS 提供的一项 Web 服务，提供了一种安全且集中的方式来管理用户身份和对 AWS 资源的访问权限。IAM 允许组织控制谁可以访问 AWS 资源，以及他们可以对这些资源执行哪些操作。这使组织能够执行安全策略，保持合规性，并减少未经授权访问或数据泄露的风险。

IAM（身份和访问管理）非常重要，因为它使组织能够以细粒度和可扩展的方式管理用户对 AWS 资源的访问权限。通过 IAM，组织可以创建和管理组织、组和角色，并为每个对象分配特定权限。这有助于确保只有授权的组织才能访问 AWS 资源，并且它们只能执行与其工作职责相关的操作。IAM 模块允许组织为相关的 AWS 资源设置细粒度的访问控制。

从数字取证和事件响应的角度来看，IAM 提供了几个关键的好处。首先，它使调查员和响应人员能够识别和跟踪 AWS 资源中的用户活动。通过分析 IAM 日志，调查员可以识别哪些用户被授予访问特定资源的权限，以及他们何时访问了这些资源。这些信息可以帮助调查人员识别潜在的安全漏洞、数据外泄尝试或其他可疑活动。

其次，IAM 使组织能够通过撤销特定组织或组对 AWS 资源的访问权限，快速响应安全事件。这有助于控制事件的影响并防止进一步的未经授权访问或数据泄露。IAM 还提供了为特定用例创建临时访问密钥的能力，这有助于在密钥泄露的情况下限制潜在损害的范围。

要将组织的 IAM 用于数字取证和事件响应目的，调查员和响应人员必须具有适当的权限来访问和分析 IAM 日志。IAM 日志提供了 AWS 资源中用户活动的详细记录，包括谁访问了它们、何时访问以及执行了哪些操作。通过分析这些日志，调查员可以识别可疑活动的模式，追踪用户行为，并关联不同 AWS 服务中的事件。以下截图显示了 IAM 仪表盘，其中包含所有用户、角色、策略和访问报告（访问分析器报告、凭证报告以及与 IAM 相关的组织活动）：

图 3.4 – AWS IAM 仪表盘

图 3.4 – AWS IAM 仪表盘

亚马逊关系型数据库服务（RDS）

Amazon RDS 是 AWS 提供的一项托管服务，使组织能够在云中创建、操作和扩展关系型数据库。借助 RDS，组织可以从 MySQL、PostgreSQL、Oracle 和 Microsoft SQL Server 等流行的数据库引擎中进行选择，并轻松管理其数据库，而无需担心基础设施管理。RDS 自动化了繁琐的数据库管理任务，如补丁、备份和软件升级，使组织能够专注于其核心业务。

RDS 是一个对于需要可扩展、可靠且具有成本效益的方式来管理其云中关系型数据库的组织至关重要的服务。借助 RDS，组织可以轻松创建和管理多个数据库实例，每个实例都有自己的数据库引擎、存储容量和性能指标。RDS 还支持高可用性和灾难恢复选项，如多可用区部署、自动故障转移和备份，确保组织的数据始终可访问且得到保护。可以通过任何特定数据库引擎的数据库客户端（例如 MariaDB、Microsoft SQL Server、MySQL、Oracle、PostgreSQL 等）访问 Amazon RDS 数据库实例。要查找已创建的数据库实例的连接信息（即主机、端口和用户），组织可以使用 AWS RDS 控制台，该控制台位于 AWS 管理控制台中，导航至其数据库实例的 连接性 和 安全性 标签。查找连接信息的其他方法包括 AWS CLI 或 RDS API。

数字取证和事件响应人员可以使用组织的 RDS 来调查和响应安全事件和数据泄露。RDS 提供审计日志，使组织能够监控数据库活动，如用户登录、SQL 语句和对数据库对象的修改。审计日志可以导出到 Amazon S3 进行长期保存和分析。

在发生安全事件或数据泄露时，事件响应人员可以使用 RDS 执行取证分析，例如识别攻击源、确定危害的程度，并评估对组织数据的影响。事件响应人员可以使用 RDS 快照创建事件发生前的数据库实例时间点副本，允许他们分析数据库内容和事件发生前的活动。事件响应人员还可以将快照恢复到新的 RDS 实例中，进行进一步分析。

Microsoft Azure

Microsoft Azure 是微软提供的云计算平台和服务，提供一系列云服务，包括计算、存储、网络和分析。它允许组织通过全球数据中心网络构建、部署和管理应用程序和服务，提供按需扩展或缩减的能力，无需本地基础设施。Azure 提供多种服务，包括虚拟机、数据库、应用服务、物联网和机器学习，并且可以与其他微软生产力套件（例如 Microsoft 365）集成（我们将在本书的第七章讨论生产力套件）。Azure 还提供一系列安全功能，包括 IAM、网络安全和威胁防护，帮助确保数据和应用程序的安全。

我们将探索事故响应者应熟悉的关键 Azure 服务，并解释了解 Azure 对于现代 IT 环境中有效的事故响应为何如此重要。

Microsoft Azure 虚拟机

Microsoft Azure 相当于 Amazon EC2 的服务是 Azure 虚拟机，组织可以在微软的云基础设施上部署和运行它们。Azure 虚拟机支持广泛的操作系统，并提供较高的控制水平。通过 Azure 虚拟机，组织可以从多种预配置的虚拟机镜像中进行选择，或创建自定义虚拟机镜像，然后在云中运行它们。

Azure 虚拟机对于需要可扩展和灵活的方式在云中运行应用程序的组织来说非常重要。组织可以轻松地配置和部署 Azure 虚拟机，按需扩展或缩减计算资源，并且只需为使用的资源付费。Azure 虚拟机支持广泛的操作系统，包括 Windows、Linux 和 FreeBSD，并提供从小型到大型的多种虚拟机规格。下图显示了 Microsoft Azure 的虚拟机创建页面，包括自定义虚拟机操作系统、硬件和存储能力的选项。Azure 虚拟机与 AWS EC2 和其他云服务提供商的虚拟化有相似之处——即可以自定义虚拟机的硬件、操作系统、存储和网络配置。

图 3.5 – 在 Azure 中启动虚拟机实例

图 3.5 – 在 Azure 中启动虚拟机实例

数字取证和事件响应人员可以利用组织的 Azure 虚拟机来调查和响应安全事件和数据泄露。Azure 虚拟机提供日志记录和监控功能，使组织能够追踪和分析其虚拟机的执行情况。Azure 虚拟机日志可以导出到 Microsoft Azure 的本地安全工具 Azure Monitor，以进行长期保存和分析，或转发到 Microsoft 的安全信息和事件管理（SIEM）工具 Microsoft Sentinel。

Azure Monitor

Azure Monitor 是一款全面的监控解决方案，用于收集、分析和响应来自 Microsoft Azure 云的遥测数据。

Microsoft Azure 虚拟网络

Microsoft Azure 虚拟网络是一项基于云的服务，允许组织在 Microsoft Azure 云平台上创建、配置和管理虚拟专用网络（VPNs）。Azure 虚拟网络提供云端资源与本地资源之间的安全私密连接，使组织能够将其网络基础设施扩展到云中。通过 Azure 虚拟网络，组织可以创建虚拟网络、子网和网络安全组，以控制对资源的访问并保护它们免受未授权访问。

Azure 虚拟网络对需要在云中建立安全私密网络基础设施的组织至关重要。通过 Azure 虚拟网络，组织可以创建与公共互联网隔离的虚拟网络，从而保障其在云中的应用和数据安全。Azure 虚拟网络支持多种连接选项，包括站点到站点 VPN、点对站点 VPN 和 ExpressRoute，使组织能够选择最符合需求的连接方式。下图展示了一个 Azure 虚拟网络设置示例。请注意，Azure 虚拟网络在功能上类似于 AWS VPC，即用于管理虚拟网络中的虚拟化资源，如虚拟机。

图 3.6 – Azure 虚拟网络示例

图 3.6 – Azure 虚拟网络示例

数字取证和事件响应人员可以利用组织的 Azure 虚拟网络来调查和响应安全事件和数据泄露。Azure 虚拟网络提供日志记录和监控功能，使组织能够追踪和分析云端资源与本地资源之间的网络流量。Azure 虚拟网络日志可以导出到 Azure Monitor 进行长期保存和分析。

在发生安全事件或数据泄露时，事件响应人员还可以使用 Azure 虚拟网络来识别潜在的攻击向量，并调查入侵的范围。事件响应人员可以分析 Azure 虚拟网络日志，以识别异常的网络流量，如未经授权的访问尝试或数据外泄尝试。事件响应人员还可以使用 Azure 虚拟网络的安全功能，如网络安全组，来控制资源的访问并防止未经授权的访问。

Microsoft Azure Blob Storage

Microsoft Azure Blob Storage 是一种基于云的对象存储解决方案，使组织能够以具有成本效益且高度可扩展的方式存储大量非结构化数据，如文本、图像、视频和音频文件。Azure Blob Storage 是 Azure 平台的关键组成部分，提供了许多功能和优势，使其成为各类组织的重要工具。

Azure Blob Storage 的一个关键优势是其可扩展性。组织可以将几乎无限量的数据存储在 Blob Storage 中，并且存储容量可以根据需要轻松地扩展或缩减。这使其成为需要存储大量数据但又不想投资昂贵硬件或基础设施的组织的理想解决方案。

Azure Blob Storage 的另一个优点是其耐用性。Azure Blob Storage 使用冗余存储来确保数据始终可用，即使在硬件故障或其他类型的中断事件中。这意味着组织可以依赖 Azure Blob Storage 存储其关键数据，而无需担心数据丢失或停机。

Azure Blob Storage 还提供了一些功能，使管理存储在云中的数据变得更加容易。组织可以通过基于 Web 的界面轻松访问和管理数据，并且 Blob Storage 提供了一系列安全功能，如加密、访问控制和审计日志，以帮助保护数据免受未经授权的访问，并确保符合行业法规。

数字取证和事件响应人员可以使用组织的 Azure Blob Storage 来存储和分析与网络事件相关的数据，如恶意软件感染、数据泄露或勒索病毒攻击。通过将数据存储在 Azure Blob Storage 中，响应人员可以轻松访问和分析大量数据，无需专门的硬件或基础设施。他们还可以使用 Blob Storage 内置的安全功能，确保数据受到保护并保持安全。

如果 Azure Blob 存储发生事故，响应人员应遵循已建立的事故响应程序，迅速识别并控制事故。这可能涉及隔离受影响的 Blob 存储容器或账户，保存数据以便进行法证分析，并找出事故的根本原因。一旦事故得到控制，响应人员可以使用 Azure Blob 存储的审计日志和其他数据分析工具来调查事故，并识别可能需要解决的其他威胁或漏洞。

创建一个 Blob 存储实例需要三个 Azure 资源：

  • 存储账户

  • 容器

  • 存储 Blob

存储账户在 Azure 中充当数据的唯一区域。在存储账户内创建一个容器，并将一组 Blob 组织在其中。Blob 存储您的文件。图 3.7 显示了一个微软 Azure 存储账户的示例。

图 3.7 – 存储账户示例

图 3.7 – 存储账户示例

微软 Azure Active Directory（Azure AD）

微软Azure Active Directory（Azure AD）是一种基于云的身份和访问管理（IAM）解决方案，允许组织管理跨 Microsoft Azure 平台的资源访问。Azure AD 相当于 AWS IAM。Azure AD 是微软云产品的核心组件，为一系列微软云服务（如 Microsoft 365、Azure 和 Dynamics 365）提供身份验证和授权服务。Azure AD 是希望管理其云资源访问的组织必不可少的工具，使他们能够执行安全策略、简化用户管理并提高整体安全性。

Azure AD 还提供一系列身份管理功能，包括多重身份验证（MFA）、条件访问策略和基于角色的访问控制（RBAC）。这些功能使组织能够基于用户角色、设备健康状况和其他上下文因素来控制对其资源的访问。

数字取证和事故响应人员可以使用组织的 Azure AD 来调查与 IAM 相关的安全事件。通过分析 Azure AD 日志和审计轨迹，响应人员可以识别异常行为，如未经授权的访问尝试、账户被盗或凭证被窃取。

微软 Azure SQL 数据库

微软 Azure 的 Amazon RDS 等效产品是 Azure SQL 数据库，它提供了一个完全托管的 RDS 服务。它作为一个灵活的平台，用于在云环境中存储和组织 SQL 数据，允许访问您的数据，而无需担心与托管数据库的机器相关的系统和数据库管理任务。Azure SQL 数据库基于 Microsoft SQL Server 数据库引擎，为组织提供了广泛的功能和能力，用于管理其数据，包括自动调优、高可用性和内置的安全功能。

Azure SQL 数据库对于需要可扩展和安全平台来管理其云中数据的组织非常重要。使用 Azure SQL 数据库，组织可以轻松地在云中提供和管理其数据库，而无需进行昂贵的硬件和基础设施投资。Azure SQL 数据库为组织提供了高度的灵活性和可扩展性，使其能够根据需要扩展或缩减数据库资源。

数字取证和事件响应人员可以使用组织的 Azure SQL 数据库来调查和应对安全事件和数据泄露。Azure SQL 数据库提供了一系列日志记录和审计功能，允许组织跟踪和分析数据库活动，包括用户活动、架构更改和数据修改。Azure SQL 数据库还提供内置的安全功能，如透明数据加密和行级安全，有助于保护数据免受未经授权的访问。

在发生安全事件或数据泄露时，事件响应人员可以使用 Azure SQL 数据库识别潜在的攻击途径，并调查安全漏洞的程度。事件响应人员可以分析 Azure SQL 数据库日志，识别异常的数据库活动，如未经授权的访问尝试或数据修改。事件响应人员还可以利用 Azure SQL 数据库的安全功能，如审计和行级安全，来调查和减轻安全事件的影响。

Google Cloud Platform（GCP）

GCP 是 Google 提供的一套云计算服务。与 AWS 和 Azure 类似，GCP 提供了一系列云服务，供组织用于构建、部署和管理应用程序和服务。

Google Compute Engine（GCE）

Google Compute Engine（GCE）是 GCP 提供的一项云计算服务，向组织提供按需的虚拟机实例。通过 GCE，组织可以快速轻松地启动虚拟机实例，按需配置并根据需要进行扩展。以下截图展示了 GCE 的控制台，在这里您可以创建虚拟机实例。所有创建的虚拟机实例将出现在此页面上。

图 3.8 – GCE 控制台

图 3.8 – GCE 控制台

GCE 支持多种操作系统，包括 Linux 和 Windows，并为组织提供一系列针对不同工作负载优化的机器类型。与 AWS 和 Azure 类似，您可以根据需要配置 Google 虚拟机的不同计算能力、存储容量和网络功能。图 3.9 展示了 GCE 虚拟机实例创建页面。

图 3.9 – 在 GCE 中启动虚拟机实例

图 3.9 – 在 GCE 中启动虚拟机实例

GCE 与 AWS EC2 和 Microsoft Azure 虚拟机在多个方面有所不同。首先，GCE 提供了一系列针对不同工作负载优化的自定义机器类型，使组织能够选择最适合其应用程序和服务的配置。其次，GCE 为组织提供访问 Google 全球网络基础设施和数据中心的权限，这能够提供比其他云服务商更快的网络性能和更低的延迟。最后，GCE 提供了集成的监控和日志工具，例如 Google 的操作套件（以前称为 Stackdriver），能够简化虚拟机实例管理和监控的过程。事故响应人员可以使用像 Google 的操作套件这样的监控和日志工具，查看在安全事件中是否有任何妥协的迹象。

Google 的操作套件

Google 的操作套件是 GCP 提供的监控、日志记录和诊断平台，用于收集和分析来自 Google 云资源和应用程序的指标、日志和追踪信息。

Google 虚拟私有云（VPC）

Google VPC 是一种网络服务，使组织能够在 GCP 上创建和管理其私有的软件定义网络。Google VPC 提供了一种安全且可扩展的方式来托管云资源，允许组织在其网络内隔离资源，控制访问权限，并根据业务需求配置网络设置。

Google VPC 允许组织在 GCP 环境内创建其虚拟网络。这个虚拟网络与其他网络逻辑隔离，为云资源提供一个安全和私密的环境。组织可以根据业务需求自定义网络设置，如 IP 地址、子网、防火墙规则和路由。通过这种方式，组织可以控制资源之间的流量，并确保只有授权用户才能访问这些资源。以下图示展示了 Google VPC 网络的示例。请注意，Google VPC 在作用上类似于 AWS VPC 和 Azure 虚拟网络，即管理虚拟网络中的虚拟化资源，如虚拟机。

图 3.10 – Google VPC 网络示例

图 3.10 – Google VPC 网络示例

Google 云存储（GCS）

Google 云存储 (GCS) 是 Google 相当于 Amazon S3 和 Azure Blob Storage 的服务，为用户提供可扩展且高可用的对象存储服务。GCS 使用户能够从世界任何地方存储和检索任意数量的数据，并提供多种存储类以适应不同的数据类型和访问模式。以下截图演示了 GCS 对象的创建过程。GCS 还将存储对象组织到存储桶中，如图所示。

图 3.11 – 使用 GCS 创建存储桶

图 3.11 – 使用 GCS 创建存储桶

Google 存储桶需要以下要求：

  • 独特的命名规范

  • 存储数据的位置（Google 数据中心区域）

  • 访问控制配置（通过 ACL）

  • 服务器端加密/保护

Google Cloud SQL

Google Cloud SQL 是 Google Cloud 相当于 AWS RDS 和 Azure SQL 数据库的服务，提供由 Google 云托管的完全托管 RDS。Cloud SQL 支持 MySQL、PostgreSQL 和 SQL Server 数据库，并提供自动备份、复制和故障切换功能。Google Cloud SQL 是一个完全托管的 RDS，提供组织一个解决方案，用于在 GCP 上存储和管理他们的数据库。此服务允许用户轻松部署、管理和扩展他们的数据库，免去管理基础设施、备份和软件更新的负担。通过 Google Cloud SQL，用户可以选择 MySQL、PostgreSQL 和 SQL Server 来支持他们的应用程序和服务。

其他云服务提供商

虽然 AWS、Microsoft Azure 和 GCP 主导了云服务提供商市场，但组织也可以选择其他选项。Oracle Cloud、IBM Cloud、Alibaba Cloud、Rackspace 和 DigitalOcean 是一些不太常见的云服务提供商。每个提供商都提供基本的云服务，如创建虚拟映像和虚拟网络、云存储和数据库服务——这些服务与我们之前讨论的 AWS、Azure 和 GCP 的服务相同。例如，Oracle Cloud 提供全面的云计算解决方案，包括 IaaS、PaaS 和 SaaS，而 IBM Cloud 提供一个混合云平台，能够与私有云和公有云集成。Alibaba Cloud 是中国最大的云提供商，而 Rackspace 提供托管云服务，DigitalOcean 则专注于为开发者提供简单的云基础设施。

总结

本章关于云服务提供商的内容概述了该行业的三大主要玩家：AWS、Microsoft Azure 和 GCP。它强调了对这些提供商的产品和服务有一个大致了解的重要性。这些平台各有一系列产品，但大多数组织通常使用与虚拟机创建、虚拟网络服务、存储和数据库服务相关的云服务解决方案。对这些基本方面有一个大致了解，对于有效响应云端事件并进行取证至关重要。

在云端发生事故或安全漏洞时，了解这些服务提供商如何处理虚拟机创建、网络和存储，可以帮助快速且有依据地响应事故。了解它们各自的能力和配置，有助于更高效的事件管理和取证分析。在下一章中，我们将深入探讨如何响应 AWS 事故——具体来说，是 AWS 产品的各种日志存储位置以及如何利用这些日志进行安全事件的取证分析。

进一步阅读

第四章：DFIR 调查 – AWS 中的日志

通过 第一章 到 第三章，你可能已经认识到云在当今技术格局中的重要性，而任何技术创新的背后都会带来威胁。随着组织使用更多的云产品并托管和存储个人或敏感信息，这些信息很容易遭遇未经授权的披露，无论是意外的还是通过威胁行为者利用系统配置中的漏洞所致。本章将重点讨论如何处理 亚马逊 Web 服务 (AWS) 中发生的事件。我们将讨论可供调查人员使用的各种日志源，以及调查人员如何利用这些日志源。

在我们开始调查之前，我们需要了解哪些日志是默认可用的，哪些日志源必须显式开启；这是组织在确保能够彻底调查安全漏洞时应考虑的事项。我们将专注于配置这些日志，并探讨如何利用 AWS 的一些原生功能进行调查。具体来说，我们将讨论以下 AWS 数据源：

  • 虚拟私有云 (VPC) 流量日志

  • 简单存储服务 (S3) 访问日志

  • AWS CloudTrail

  • AWS CloudWatch

  • Amazon GuardDuty

  • Amazon Detective

VPC 流量日志

我们在 第三章 中简要介绍了 VPC。VPC 是 AWS 中每个实例的网络配置核心。每个 AWS 实例 (弹性计算云 (EC2)) 都会被分配一个 VPC，并通过 VPC ID 唯一标识。VPC 使用户可以完全控制网络环境，包括定义特定的 IP 地址（非公共可路由 IP）、子网和安全组。用户还可以通过其 VPC 连接配置 虚拟私人网络 (VPN)。在默认配置下，AWS 会为每个新的 EC2 实例自动创建一个 VPC。用户也可以将他们的 EC2 实例连接到一个已存在的预配置 VPC。

所有 VPC 都有一个 VPC 标识符 (VPC ID)。VPC ID 是所有与网络相关的配置项的唯一参考点。对于每个实例，如果你想在 AWS 中配置任何网络属性，必须专门查看每个 VPC。在下一个示例中，对于一个特定的 EC2 实例，VPC 捕获了一些特定的细节。

注意

在深入细节之前，值得注意的是，VPC 流量日志与网络流量日志类似。这些日志只捕获网络流量的头信息；例如，源 IP、目标 IP、协议、端口以及连接是否被接受或拒绝（取决于入站和出站连接规则）。

VPC 基础

在下面的截图中，你会注意到 网络 标签下的一些配置信息，这些信息对于 数字取证与事件响应 (DFIR) 团队特别有用：

图 4.1 – 默认 VPC 设置

图 4.1 – 默认 VPC 设置

包括以下内容：

  • 公共 IPv4 地址：此 EC2 实例的可公开路由的 IP 地址方案。

  • VPC ID：将所有网络配置项与此 VPC 设置连接的唯一标识符。

  • 私有 IP DNS 名称（仅限 IPv4）：分配给 EC2 实例的不可公开路由的 IP 地址，通常用于 AWS 提供的后端通信或 EC2 实例间的通信。

  • 子网 ID：VPC 所拥有的 IP 子网。

  • 可用区：VPC 最初配置所在的 AWS 区域。

DFIR 团队可以使用此核心信息集来过滤事件并进行分析。在本章的 AWS CloudWatch 部分，我们将探讨如何将这些信息整合到调查中。

如前述屏幕截图所示，每个 VPC 配备一个或多个子网，负责分配 IP 并管理网络段。你可以在同一个 VPC 下为多个 EC2 实例分配多个子网：

图 4.2 – 默认子网配置和网络接口

图 4.2 – 默认子网配置和网络接口

类似于 VPC 配置，前面的屏幕截图展示了分配给 VPC 的子网的一些默认属性。包括以下内容：

  • 子网 ID：用于标识分配给 VPC 的子网的唯一标识符。

  • 4089。

  • 网络边界组：分配的互联网边缘位置。网络边界组是 AWS 边缘位置和 服务接入点 (PoPs) 的集合，这些位置地理分布并旨在提供 VPC 与公共互联网之间的安全可靠连接。

  • 路由表：指向分配给该子网的特定路由信息架构的唯一标识符。

  • 子网 ARN：子网 Amazon 资源名称 (ARN) 是一个唯一标识符，可以在各种 AWS 服务和 API 中引用该子网，如 AWS CloudFormation 模板、AWS 身份与访问管理 (IAM) 策略和 AWS Lambda 函数。

  • VPC：此子网所分配的 VPC。请注意，此子网被分配到图 4.1所引用的 VPC。

  • 所有者：实例、VPC 和子网所属账户的唯一标识符。出于隐私原因，这个标识符被屏蔽。

  • /20 表示 IP 地址的前 20 位用于网络地址，剩余的 12 位用于主机地址。

  • ca-central）；然而，如果需要，你可以将子网放置在另一个可用区，以提供 容错 (FT) 和弹性。

  • 网络 ACL：另一个唯一标识符，用于精确识别为此子网配置的 访问控制列表 (ACLs) 。ACL 将执行对网络资源的允许与限制。这还可以包括入站和出站网络过滤器。

  • eni-035e09cd5e22e5515：网络接口 ID。

虽然前面的截图指定了必要的配置元素，但每个属性可以根据组织的需求进行调整。然而，DFIR 团队需要注意，前述方面将对调查过程中的威胁性质以及你正在观察的威胁起到作用。

对于 DFIR 团队，以下标签提供了关于网络配置的更多详细信息：

  • 流量日志 表示网络如何被记录。这个 VPC/子网的日志记录在 CloudWatch 中，这使得 DFIR 团队可以查询网络日志。我们将在本章后续部分调查并查询这些日志：

图 4.3 – VPC 流量日志

图 4.3 – VPC 流量日志

注意

请注意，VPC 流量日志默认未启用，需要显式设置。

  • 下一张截图深入展示了配置用于连接到互联网的 路由表。请注意该子网连接的 目标 网络网关标识符（唯一标识符）。路由表定义了与该子网相关的所有实例的路由执行方式。在设置了自定义 VPC 的组织中，路由表可能看起来不同，或者指向 AWS 内的其他网络资源。它可能不会将实例直接暴露到互联网。DFIR 团队需要注意网关和资源分配的路由表，以便进行调查：

图 4.4 – 路由表

图 4.4 – 路由表

  • 以下截图显示了 规则编号 列中进出 * 的详细信息，这意味着一旦任何规则编号被评估完，该规则将最后进行评估。基于进出 ACL，这个资源可以在线访问。它可以访问互联网的任何部分，目前这是最不安全的设置，也是 AWS 提供的默认设置：

图 4.5 – 配置的子网 NACL

图 4.5 – 配置的子网 NACL

现在我们已经回顾了 VPC 下的各种配置项，以下是 AWS 为每个 VPC 提供的概要仪表板，概述了 VPC 配置属性和分配，以及其他信息：

图 4.6 – VPC 概要仪表板

图 4.6 – VPC 概要仪表板

VPC 概要仪表板页面还将提供有关与此 VPC 关联的子网和已配置的流量日志的额外信息。VPC 流量日志默认未启用，需要在 AWS 的 IAM 模块中配置特定的 AWS 资源访问权限。我们将研究如何设置流量日志，以便 DFIR 团队能够调查 AWS 上的网络活动并查询这些日志。

以下截图展示了 AWS 从内部 AWS 视角连接到互联网的网络配置图或资源图。资源图显示了 VPC 中资源之间的连接，概述了从子网到网络地址转换（NAT）网关、互联网网关和网关端点的流量路径。通过资源图，DFIR 团队可以理解 VPC 的设计，确定子网数量，识别哪些子网与路由表相对应，并识别哪些路由表包含到 NAT 网关、互联网网关和网关端点的路由：

图 4.7 – vpc-0183a969 VPC 的资源图

图 4.7 – vpc-0183a969 VPC 的资源图

此外，资源图可以帮助你识别不合适或不准确的配置，例如与 NAT 网关分离的私有子网，或具有直接路由到互联网网关的私有子网。你可以从资源图界面选择特定的资源，如路由表，并修改其设置。该功能目前正在开发中。

示例 VPC 流日志

这是一个示例 VPC 流日志及流日志中捕获的属性。理解每个流日志中捕获的元素是至关重要的。

流日志是在时间间隔之间记录的，期间网络流量被聚合成一个日志：

2 65179142xxxx eni-035e09cd5e22e5515 45.79.132.41 172.31.5.217 41340 636 6 1 44 1682678411 1682678469 REJECT OK

让我们深入了解流日志中每个元素的详细信息：

  • 2：该字段表示 VPC 流日志格式的版本。

  • 65179142xxxx：这是拥有网络接口的 AWS 账户的 ID。目前由于隐私原因，此 ID 被隐藏。

  • eni-035e09cd5e22e5515：这是网络接口的 ID（弹性网络接口（ENI））。请注意，该日志与图 4.2配置匹配，反映了 EC2 资源的网络连接。

  • 45.79.132.41：这是流量的源 IP 地址。

  • 172.31.5.217：这是流量的目标 IP 地址。

  • 41340：这是源端口号。

  • 636：这是目标端口号。

  • 6：这是协议号。在这种情况下，它是 TCP（6）。端口 6 目前未分配。

  • 1：这是在流期间传输的包的数量。

  • 44：这是在流期间传输的字节数。请注意，在此流会话期间传输的字节数。

  • 1682678411：这是流的开始时间，采用纪元时间（自 1970 年 1 月 1 日起的秒数）。

  • 1682678469：这是流的结束时间，采用纪元时间。

  • REJECT：由安全组或 NACL 对流量采取的行动。行动包括 ACCEPT/REJECT/NO DATA/SKIPDATA。NO DATA 和 SKIPDATA 是极端情况，NO DATA 表示记录为空，流日志事件没有数据。而 SKIPDATA 表示由于容量限制，网络聚合间隔期间无法捕获日志，导致无法捕获流日志条目。SKIPDATA 记录条目意味着由于内部配置错误，无法捕获多个网络日志。

  • OK：这是操作的状态。

DFIR 在 VPC 流日志中的应用场景

DFIR 团队在调查 AWS 资源时，应该利用 VPC 流日志的原因有很多。以下是 VPC 流日志对 DFIR 团队至关重要的一些应用场景：

  • 威胁检测与监控：VPC 流日志可以用来检测可疑或恶意的网络流量。DFIR 团队通过分析流日志，可以识别出表示已知威胁或潜在入侵的流量模式。例如，他们可以利用流日志来检测端口扫描、暴力破解攻击、命令和控制流量，以及通过查看流日志中的活动峰值来识别数据外泄。

  • IR：DFIR 团队可以利用 VPC 流日志重建事件的时间线，并在安全事件中确定攻击源。通过分析流日志，他们可以确定受影响的系统和应用、攻击的持续时间，以及攻击者使用的 IP 地址和端口。

  • 取证分析：VPC 流日志还可以用于数字取证调查，以识别攻击源并追踪数据通过网络的访问路径。DFIR 团队可以使用流日志来确定源 IP 地址、目标 IP 地址以及网络连接期间使用的协议。这些信息可以帮助他们确定数据泄露或其他安全事件的源头。

  • 合规性监控：VPC 流日志可用于监控是否符合安全政策和法规要求。DFIR 团队或安全运营中心 (SOC) 可以使用流日志来检测未授权访问敏感数据和安全违规行为。这些信息可以用来生成合规审计报告或支持法律调查。

  • 异常检测：最后，VPC 流日志可以用来检测异常的网络流量。DFIR 团队可以使用机器学习 (ML) 技术来识别与网络预期行为不符的流量模式。这可以帮助他们在安全事件或系统故障变得更严重之前发现潜在问题。

S3 访问日志

Amazon S3 是一种非常流行的云存储服务，具有高度可扩展性和可靠性，适用于数据存储和检索。S3 提供了高可用性 (HA)、存储性能和全球任何位置数据的可访问性。

在 AWS 中，S3 是基于 存储桶 操作的，存储桶中包含 对象。对象是任何文件、文档、图片和视频。每个对象都使用唯一的标识符，即键，来标识并服务于存储桶中的对象。存储桶可以视为包含所有对象的文件夹。

日志选项

访问日志记录关于对 Amazon S3 存储桶的请求信息，包括请求详情、具体的资源请求以及请求的时间和日期。Amazon S3 使用特定的内部账户来写入服务器访问日志，这要求 AWS 账户所有者在其 IAM 模块中配置显式权限，以允许 S3 记录服务器访问请求。

注意

请注意，S3 访问日志默认未启用，需显式设置。

DFIR 用例：S3 监控

由于 S3 存储用于数据的传输和托管，大多数 DFIR 用例都围绕数据分析和移动展开。一些特定的 DFIR 用例包括：

  • 数据泄露：由于 S3 存储桶的配置错误，可能会发生数据泄露或数据暴露。通过访问日志，可以帮助识别未经授权访问 S3 存储桶中的数据。通过监控存储桶访问日志并执行异常检测，可以识别出大规模数据传输、意外访问模式或未经授权尝试访问特定对象等可疑活动。

  • 恶意软件和勒索软件检测：S3 存储桶可能成为攻击者用来存储和分发恶意软件或勒索软件的目标。DFIR 团队可以通过监控 S3 文件完整性变化、意外文件类型或可疑行为，帮助识别此类恶意文件。与 威胁情报（TI）的集成可以增强检测能力。

  • IR 和取证调查：S3 监控可以为 IR 和取证调查提供洞察。通过访问日志，DFIR 团队可以帮助重建事件、识别事件源并理解泄露的范围。监控访问日志、对象元数据和版本控制有助于分析导致安全事件的活动。

  • 数据外泄检测：攻击者可能试图通过从 S3 存储桶复制或下载敏感数据来进行数据外泄。监控 S3 访问日志并进行内容分析，有助于识别可能表明数据外泄尝试的大规模或意外数据传输。这也可以通过与 CloudTrail 和 CloudWatch 的集成以及开发日志模式洞察来实现，从而使 DFIR 团队能够确定文件访问的偏差并识别外泄活动。

AWS CloudTrail

AWS CloudTrail 记录在 AWS 管理控制台上执行的活动，访问任何 AWS 资源—例如，创建或终止 EC2 实例、修改 VPC 设置等。AWS 管理控制台上的任何活动都会作为事件记录在 CloudTrail 中。

CloudTrail 将详细的操作日志事件汇总在一个集中位置，并提供关于账户活动的全面统一视图，使得在整个 AWS 基础设施中更容易搜索、分析、下载并响应账户活动。它还可以识别哪些用户执行了哪些操作，以及任何有助于 DFIR 团队分析和响应 AWS 事件的其他细节。

CloudTrail 日志可以与 CloudWatch 集成，以便查询活动并进行进一步分析。我们将在下一节讨论 CloudWatch。

以下截图展示了一个 CloudWatch 仪表盘的示例：

图 4.8 – CloudWatch 仪表盘

图 4.8 – CloudWatch 仪表盘

在撰写本文时，我们看到事件记录在mgmt-event跟踪中。它汇总了在每个 AWS 账户下执行的所有管理活动。事件以 CloudTrail JavaScript 对象表示法（JSON）日志格式记录。

CloudTrail 可以记录三种类型的事件：管理事件、数据事件和 CloudTrail 数据洞察事件。让我们详细了解一下这些事件：

  • 管理事件：顾名思义，这些事件记录了 AWS 账户管理级别的活动，包括对 AWS 账户所执行的操作。AWS 称这些为控制平面操作。示例包括应用程序编程接口（API）操作、AWS IAM、创建新的 EC2 实例、编辑 VPC 配置、配置路由操作、创建子网以及在 CloudTrail 下创建新的跟踪。

  • 数据事件：记录有关对资源执行的操作的信息。AWS 称这些为数据平面操作。通常，数据事件数据量庞大，您需要配置它们以确保 AWS 资源能够提供这些数据。

注意

数据事件日志默认未启用，管理员需要显式允许它。

以下是提供这些数据事件的 AWS 资源列表：

数据事件 资源 具体事件
DynamoDB AWS::DynamoDB::Table API 级别活动，包括PutItem、DeleteItem和UpdateItem
DynamoDB Streams AWS::DynamoDB::Stream 在流上的 Dynamo API 调用
Lambda AWS::Lambda::Function Lambda 函数执行活动，包括Invoke API 调用
S3 AWS::S3:Object S3 对象级别活动，包括对 S3 存储桶的GetObject、DeleteObject和PutObject API 调用
S3 访问点 AWS::S3::AccessPoint Amazon S3 API 活动，涉及访问 点（APs）
S3 Object Lambda AWS::S3ObjectLambda::AccessPoint S3 Object Lambda 访问点的 API 活动，例如调用CompleteMultipartUpload和GetObject
CloudTrail AWS::CloudTrail::Channel 在 CloudTrail 湖中PutAuditEvents用于记录 AWS 外部的事件
Cognito AWS::Cognito::IdentityPool 在身份池上的 Cognito API 活动
亚马逊 弹性块存储 (EBS) 直接 API AWS::EC2::Snapshot 在 Amazon EBS 快照上使用的直接 API，如 PutSnapshotBlock、GetSnapshotBlock 和 ListChangedBlocks
GuardDuty AWS::GuardDuty::Detector GuardDuty 检测器的 API 活动

表 4.1 – AWS 数据事件收集器

  • CloudTrail 数据洞察事件：CloudTrail Insights 提供对异常活动的洞察，例如大量或突发的 API 调用或 AWS 账户内的高错误率。当 CloudTrail 发现 API 使用和错误率在 AWS 账户内出现偏差时，会记录洞察事件。

创建追踪

在 AWS 中创建账户时，CloudTrail 并不会自动启用。安全团队必须定义一个追踪，以便收集 AWS 账户中所有必要的信息/活动，用于审计、合规性和调查目的。

您首先需要定义一个追踪并为其提供唯一标识，以便将其与其他 AWS 资源集成，例如 mgmt-events，以表示该追踪中收集的事件类型。然后，您需要选择该追踪存储的位置。您可以创建一个新的 S3 存储桶；但是，如果您的安全运营团队拥有一个 S3 存储桶，也可以将追踪放在该存储桶中。出于安全原因，我们已隐藏了与此追踪关联的账户号码：

图 4.9 – 设置 CloudTrail 日志记录

图 4.9 – 设置 CloudTrail 日志记录

在配置 CloudTrail 日志时，您可以启用将其自动馈送到 CloudWatch。我们将在本章的后续部分讨论 CloudWatch。实际上，将 CloudTrail 日志提供给 CloudWatch 允许 DFIR 团队将他们的调查和日志审查集中在一个控制台中，提供 单一视窗 (SPOG) 查看日志：

图 4.10 – AWS CloudWatch 与 AWS CloudTrail

图 4.10 – AWS CloudWatch 与 AWS CloudTrail

在定义 CloudTrail 日志时，您还应该配置在 CloudTrail 中收集哪些类型的数据事件。在本节前面，我们提到了三种类型的数据事件：管理事件、数据事件和数据洞察事件。

以下屏幕截图定义了启用的配置，以便追踪收集记录。正如截图中所示，CloudTrail 将收集与 AWS 资源管理相关的事件，例如访问/查询、创建、修改或删除资源。例如，AWS IAM 管理员创建具有特权的另一个账户时，会触发一个管理事件，并记录在此追踪下：

图 4.11 – CloudTrail 管理事件的配置

图 4.11 – CloudTrail 管理事件的配置

另一方面，数据事件专门收集与 AWS 资源内数据级活动相关的事件，例如跟踪存储在 S3 存储桶中的文件更改。监控数据事件使 DFIR 团队能够确认数据是否在这些 AWS 服务中被访问、修改或删除。下一个截图显示了启用数据事件所需的配置。它反映了 DFIR 团队配置并允许适当 CloudTrail 日志记录的选项：

图 4.12 – CloudTrail 数据事件配置

图 4.12 – CloudTrail 数据事件配置

日志文件验证

当您创建追踪时，还需要保护其完整性，以确保没有未经授权的更改。因此，我们还启用了日志文件验证复选框，以在生成追踪时强制执行完整性检查，确保其过程没有被篡改，并且在调查时准确。完整性检查结果将传送到与摘要相同的 S3 存储桶中。DFIR 团队可以利用日志文件摘要来验证日志文件的完整性。每个日志文件都会进行哈希处理并进行数字签名。CloudTrail 日志数据摘要文件使用 RSA 进行签名，每个区域生成一个私钥，使用私钥对 SHA-256 数据进行签名，产生数字签名。SHA-256 数据是从日志文件的协调世界时（UTC）时间戳、S3 路径、当前摘要文件的 SHA-256 哈希值（以十六进制格式表示）以及前一个摘要文件的签名（以十六进制格式表示）中生成的。这些元素共同构成了哈希字符串，用于生成数据的 SHA-256 哈希值，然后进行签名。

一旦签名生成，它会进一步以十六进制格式进行编码。十六进制签名随后会记录在存储在 S3 上的摘要文件的x-amz-met-signature标签中。

DFIR 团队可以选择稍后通过 AWS 管理控制台、API 或 AWS 命令行启用日志文件验证：

图 4.13 – 启用日志文件验证

图 4.13 – 启用日志文件验证

事件数据存储

由于 CloudTrail 是一个审计工具，用于记录 AWS 账户内的事件/更改，安全团队必须指定数据湖，供过滤和存储这些事件用。一旦创建了追踪，AWS 将这些事件的数据湖称为事件存储。您可以根据跨 AWS 账户的不同区域过滤器创建一个或多个事件存储，用于存储管理或数据事件。事件存储提供最长 7 年的长期保留。组织可以将这些日志发送到集中管理的安全信息和事件管理（SIEM）解决方案。

一旦创建了事件存储，它实际上使 DFIR 团队能够立即使用它，并查询特定 AWS 资源（模块/服务）上的相关活动及事件详情。

以下截图展示了配置事件存储并应用过滤器所需的步骤。在本例中，我们选择了同一事件存储中的所有管理和数据事件：

图 4.14 – 在 AWS CloudTrail 中配置事件存储

图 4.14 – 在 AWS CloudTrail 中配置事件存储

查询 CloudTrail 事件存储

CloudTrail 允许 DFIR 团队查询事件存储，所有管理和数据事件都存储在其中，类似于任何日志工具。简而言之，CloudTrail 事件可以使用 SQL 进行查询。

请注意，在 CloudTrail 中，由于事件是不可变的，只有 SQL SELECT 语句被允许。您可以使用 WHERE 子句应用过滤器。然而，CloudTrail 不允许用户在事件存储中操作数据。

虽然事件存储可以命名，DFIR 团队必须注意 AWS 生成的唯一事件数据存储 ID，以便执行 SQL 查询。以下截图展示了一个 SQL 查询及其相关查询结果。在本例中，我们查询以返回存储在事件存储中的全部值。然而，一旦熟练，DFIR 专家可以直接查询事件存储，以从存储中获取必要的信息：

图 4.15 – 在 AWS CloudTrail 上进行简单 SQL 查询及结果

图 4.15 – 在 AWS CloudTrail 上进行简单 SQL 查询及结果

另一个例子是查询事件存储以识别最活跃的用户。在 DFIR 案例中，这可能像大海捞针一样，涉及多个用户和交互点。然而，您要寻找的是一个特定的异常值，从这个点开始进行调查。

调查 CloudTrail 事件

任何 DFIR 专家都希望能访问充满日志的事件存储，这些日志为调查提供了宝贵的信息。本节将探讨 DFIR 专家可以采取的一些调查策略，来调查 CloudTrail 事件。请注意，在 CloudTrail 事件存储上执行的任何查询也会记录在相同的事件存储中。

在事件存储中直接调查

DFIR 团队可以直接选择调查事件存储中的日志。例如，我们将调查事件存储，以识别哪些用户最频繁地从控制台访问 AWS 资源。

默认情况下，当您登录 CloudTrail 时，CloudTrail 会在其仪表盘中自动提供事件摘要，其中包括一些近期的用户活动。它还会记录其他 AWS 资源执行的任何 API 调用。它包含任何 AWS 内部资源间的 API 调用，以及通过 AWS 网络浏览器的用户交互。

例如，以下截图展示了该演示实验室中的一些近期事件。该仪表盘还允许 DFIR 团队点击并获取关于特定事件条目的更详细信息。仪表盘中的每个条目反映了每个事件：

图 4.16 – 按时间倒序排列的事件仪表盘视图

图 4.16 – 按时间降序排列的事件仪表板视图

例如，在第一个事件中，cf_user1 用户与 AWS EC2 资源进行了交互。我们从本书的 第三章 中了解到，每个 EC2 实例在 AWS 中都有一个唯一的实例 ID。因此，DFIR 团队更容易追溯并记住用户与哪个实例进行过交互，并收集特定的配置信息。通过总结视图，我们可以了解到，cf_user1 用户在 2023 年 5 月 10 日 05:55:49（UTC-04:00）停止了一个名为 i-09c02a7e1ff652c13 的 EC2 实例。如果 DFIR 团队需要更多信息，可以通过点击事件名称字段下的链接来获取。以下截图展示了捕获事件的详细信息：

图 4.17 – 记录在 CloudTrail 中的事件的附加信息

图 4.17 – 记录在 CloudTrail 中的事件的附加信息

需要注意的是，附加信息捕获了源 IP 地址，它记录了可能已入侵并访问此 AWS 账户的威胁行为者的 IP 地址。DFIR 团队可以进一步调查该 IP 地址，识别该用户或此源 IP 地址执行的其他活动，从而提供事件的时间线。在附加信息部分，DFIR 团队还可以捕获以 JSON 格式记录的原始事件数据。AWS 称之为事件负载。通常，事件负载可以通过事件历史下拉菜单访问。事件负载使 DFIR 团队能够查看原始日志，并确定用户或攻击者可能在受影响资源上执行的更具体操作。具体来说，它还识别了其他可能对进一步调查有用的元数据。以下是停止实例的原始事件日志或事件负载，如前述截图所示：

{
    "eventVersion": "1.08",
    "userIdentity": {
        "type": "IAMUser",
        "principalId": "AIDAZPQOL4P2OUQxxxxx",
        "arn": "arn:aws:iam::xxxxxxxx6548:user/cf_user1",
        "accountId": "xxxxxxxx6548",
        "accessKeyId": "xxxxxxxxxxxxMBCSD6",
        "userName": "cf_user1",
        "sessionContext": {
            "sessionIssuer": {},
            "webIdFederationData": {},
            "attributes": {
                "creationDate": "2023-05-10T09:55:05Z",
                "mfaAuthenticated": "true"
            }
        }
    },
    "eventTime": "2023-05-10T09:55:49Z",
    "eventSource": "ec2.amazonaws.com",
    "eventName": "StopInstances",
    "awsRegion": "ca-central-1",
    "sourceIPAddress": "184.147.70.116",
    "userAgent": "AWS Internal",
    "requestParameters": {
        "instancesSet": {
            "items": [
                {
                    "instanceId": "i-09c02a7e1ff652c13"
                }
            ]
        },
        "force": false
    },
    "responseElements": {
        "requestId": "1497712b-d47d-462a-a3a0-048d82463a96",
        "instancesSet": {
            "items": [
                {
                    "instanceId": "i-09c02a7e1ff652c13",
                    "currentState": {
                        "code": 64,
                        "name": "stopping"
                    },
                    "previousState": {
                        "code": 16,
                        "name": "running"
                    }
                }
            ]
        }
    },
    "requestID": "1497712b-d47d-462a-a3a0-048d82463a96",
    "eventID": "5ecd20de-1c37-41f1-b200-8660fe5d5eed",
    "readOnly": false,
    "eventType": "AwsApiCall",
    "managementEvent": true,
    "recipientAccountId": "xxxxxxxx6548",
    "eventCategory": "Management",
    "sessionCredentialFromConsole": "true"
}

在前述的原始事件负载中，我们已突出显示了日志中的一些关键元素或属性，DFIR 团队通常应注意这些内容：

  • {"arn": "arn:aws:iam::xxxxxxxx6548:user/cf_user1"}：在此实例中，我们有一个 IAM 普通用户使用唯一标识符（xxxxxxxx6548）登录到 AWS 账户。出于安全考虑，我们已对账户编号进行了标记。

  • {userName": "cf_user1"}：用于验证此会话的实际用户名。

  • "attributes": {"creationDate": "2023-05-10T09:55:05Z", "mfaAuthenticated": "true"}：在用户通过多因素身份验证成功登录到 AWS 会话后创建的会话时间。这条记录表明用户已成功登录 AWS 控制台，并验证了其双因素令牌以完成身份验证过程。

  • {"eventTime": "2023-05-10T09:55:49Z"}：记录事件的实际日期和时间，使用 UTC 时间。

  • {"sourceIPAddress": "184[.]147[.]70[.]116"}：执行此事件的用户或威胁行为者的源 IP 地址。出于安全考虑，IP 地址已被隐藏。

  • "instanceId": "i-09c02a7e1ff652c13", "currentState": {"code": 64, "name": "stopping"}, "previousState": {"code": 16, "name": "running"}：特定的事件条目反映了实例的当前和先前状态，确认执行了哪些具体操作。在此示例中，我们有一个正在运行的实例，用户登录后停止了该实例。

从 DFIR 调查的角度来看，可以推断和总结在此案例中执行的活动，并确定与调查相关的下一步行动。

下载并离线调查事件存储结果

由于 CloudTrail 事件日志采用 JSON 格式，您可以根据需要查询、过滤和提取结果进行调查，我们始终可以查询事件存储并下载日志以便离线查看。这在 DFIR 团队无法访问 AWS 的情况下特别有用。然而，从调查的角度来看，调查 CloudTrail 事件是至关重要的。

使用前面示例中捕获的源 IP 地址，我们将查询事件数据存储以识别来自该 IP 地址的活动。为此，我们将执行以下查询：

SELECT * FROM d4f86c5e-2518-46a4-b751-943e266f3c49 WHERE eventTime > '2023-04-30 00:00:00' AND sourceIPAddress='184.147.70.116'

请记住，事件数据存储是通过事件数据存储 ID 唯一标识的；我们根据我们的事件调查筛选日期，并进一步筛选 sourceIPAddress 属性。

虽然查询结果以表格形式显示，但您可以使用复制选项复制整个原始记录。您确实需要选择要复制的事件记录或所有内容：

图 4.18 – 搜索查询结果

图 4.18 – 搜索查询结果

使用任何第三方工具（例如 CyberChef），您可以解析此 JSON 日志以进行进一步调查。或者，您可以使用任何日志解析工具来解析并进一步调查日志。

或者，您可以直接从关联的 Amazon S3 存储桶下载整个日志集。您可以通过导航到 CloudTrail 仪表盘并选择相关的轨迹名称来找到该 S3 存储桶的位置。请参见下一个截图以查看示例：

图 4.19 – 导航到 CloudTrail S3 存储桶

图 4.19 – 导航到 CloudTrail S3 存储桶

当您导航到 S3 存储桶时，您会注意到 CloudTrail 详情存储在两个不同的对象存储库中；一个包含摘要（我们在本章前面部分已经讨论过），其中包括用于验证日志完整性的信息，而另一个对象存储库是实际日志存储的位置。

日志进一步按区域存储，基于每个 AWS 区域中资源的操作位置，并将日志发送到 CloudTrail。DFIR 团队需要理解，AWS 按照日历天分解日志存储。在下载 S3 日志时，您需要在收集 S3 日志之前了解这些信息。下载 S3 上托管的所有数据可能非常庞大，并且从调查的角度来看可能没有什么帮助。然而，这取决于调查的具体情况。下一张截图提供了位于 ca-central-1 区域的 2023 年 5 月 1 日的日志样本集概览，以及 AWS 如何存储 CloudTrail 日志：

图 4.20 – 从 CA-Canada 中央区域获取 CloudTrail 日志

图 4.20 – 从 CA-Canada 中央区域获取 CloudTrail 日志

如果您拥有 AWS 的 API 访问权限，您可以同时下载多个文件。然而，AWS 限制了从 Web 控制台一次只能下载一个文件，这可能会使下载变得非常耗时。

虽然 CloudTrail 将其日志存储为 gzip 格式以节省存储空间，但 AWS 在下载时会以未压缩格式提供日志。

CloudTrail 日志的 DFIR 使用案例

以下是启用 CloudTrail 的一些使用案例及其如何支持 DFIR 团队：

  • 事件调查：CloudTrail 可以支持您的事件调查。可以调查一些常见的主题，如 AWS 账户被接管，其中攻击者创建了一个未经授权的账户，以在 AWS 内创建/修改资源。您可以使用 CloudTrail 日志来确定用户名、源 IP 地址以及他们是如何在 AWS 中进行身份验证的。CloudTrail 日志还提供了有关攻击者是否进行了特定修改以及以前设置的配置的关键信息。其他调查领域包括：

    • 查找恶意或非法的 EC2 实例：通过 CloudTrail 日志，您可以判断攻击者是否创建了 EC2 虚拟机 (VM)，以访问特定的生产环境。CloudTrail 可以提供实例类型、实例 ID 等信息——这些信息可以用于进一步的调查追踪——以及这些非法 EC2 实例创建的日期和时间。由于 CloudTrail 记录跨多个区域的活动，DFIR 团队还可以利用 CloudTrail 日志来判断攻击者在多个 AWS 资源和不同区域间的横向移动。

    • 未经授权的 API 调用：由于 CloudTrail 跟踪 AWS 内部从一个资源到另一个资源的所有 API 调用，以及用户发起的 API 调用，CloudTrail 日志可以用来确定是否存在未经授权的 API 资源使用。例如，使用特定访问令牌的 API 调用突然激增，可以帮助 DFIR 团队快速判断相关账户是否被攻击者入侵，导致未经授权的访问。

  • 安全性和合规性审计：由于 CloudTrail 的主要功能之一是创建所有活动的审计跟踪，CloudTrail 可用于监控与安全政策和法规的合规性。例如，在医疗保健行业，用户访问必须得到严格监控并基于最小权限原则提供，CloudTrail 日志可以帮助根据记录的活动微调这些权限，从而确保合规性。

  • 基础设施监控与故障排除：除了 DFIR，CloudTrail 还可以为开发人员和应用程序测试人员提供帮助，确保他们的应用程序有效运行。CloudTrail 允许开发人员查看 API 调用并确定任何意外后果的原因。

AWS CloudWatch

AWS CloudWatch 实时监控您的 AWS 资源。您可以在 SPOG 视图中收集和监控资源使用情况和关键指标。CloudWatch 会在其仪表板上显示每个资源的指标，方便快速查看。然而，对于 DFIR 团队，CloudWatch 可以查询特定日志以支持调查。

从安全角度看，CloudWatch 是一款日志管理解决方案，可以集中收集和监控来自系统、应用程序和资源的日志。它提供基于日志分析的交互式搜索和分析功能。与 CloudTrail 类似，CloudWatch 提供通过 S3 存储桶导出日志的功能。请注意，CloudWatch 中的日志永不过期，并且会无限期保留。管理员可以更改保留策略，并选择日志保留一天或最多 10 年。或者，组织可以通过 API 将 CloudWatch 日志发送到 SIEM 解决方案，以实现日志的集中监控和管理。

CloudWatch 是一项允许您交互式搜索和分析日志数据的服务。您可以监控来自 Amazon EC2 实例和 CloudTrail 记录事件的日志，创建警报，并接收特定 API 活动的通知以进行故障排除。此外，您还可以审计和屏蔽敏感数据，调整日志保留策略并归档日志数据。CloudWatch Logs 还可以记录 Route 53 接收到的 DNS 查询信息。它使用专门的查询语言，配有示例查询、命令描述、查询自动补全和日志字段发现功能，帮助您快速入门。

您可以通过以下任何方法访问 CloudWatch：

  • AWS CloudWatch 控制台：直接访问 CloudWatch 仪表板和日志

  • AWS 命令行界面 (CLI)：使用 Amazon 提供的模块通过常用终端或流行操作系统中的命令行控制台连接到 AWS

  • CloudWatch API：通过 API 使用您的技术发布或监控 AWS CloudWatch 日志

  • AWS SDK：构建应用程序，将日志发布到 CloudWatch

注意

从 DFIR 的角度来看，重要的是要注意，启用 CloudWatch 日志时，只会记录在 AWS 账户中执行的活动，而不会捕捉每个资源内具体执行的操作。（例如，CloudWatch 不会捕捉到用户/威胁行为者在 EC2 实例内执行的事件/记录。但它会记录威胁行为者是否登录到 AWS 控制台并进行更改、删除 EC2 实例等操作。）

下图展示了一个典型的日志配置，这些日志被记录到 CloudWatch 中：

图 4.21 – 带有 VPC 的 EC2 实例的 CloudWatch 日志架构示例

图 4.21 – 带有 VPC 的 EC2 实例的 CloudWatch 日志架构示例

接下来的章节将回顾 CloudWatch 和 CloudTrail 之间的区别，以及 DFIR 团队如何为事件调查配置它们。

CloudWatch 与 CloudTrail 比较

接下来，让我们看看 CloudWatch 和 CloudTrail 之间的一些关键区别。DFIR 团队需要认识到它们功能上的差异，以及它们如何互补事件调查：

  • CloudWatch 是一个日志管理工具：CloudWatch 提供监控和可观察性功能，专门收集和展示来自各种 AWS 产品的资源使用情况和指标。它提供了一个 实时 的日志视图。

  • CloudTrail 记录 API 交互：CloudTrail 记录用户与内部 AWS 资源之间的 API 交互，创建 AWS 账户内所有活动的记录。与 CloudWatch 不同，CloudTrail 仅记录与 API 相关的活动，并允许针对应用程序故障排除或安全调查进行特定查询。

由于 CloudWatch 本质上是一个日志管理工具，它能够接收 CloudTrail 事件，因此可以通过一个单一控制台查看不同的日志来源。DFIR 团队可以使用 CloudWatch API 将日志拉入本地 SIEM 解决方案，以进行进一步的监控和调查。

设置 CloudWatch 日志记录

一旦组织建立了 AWS 账户，就可以启用 CloudWatch 日志记录。然而，启用该功能需要经过一些步骤，包括配置其他 AWS 资源的权限，以允许它们将日志发送到 CloudWatch。CloudWatch 是区域性的，因此最佳做法是在大多数 AWS 资源所在的区域创建 CloudWatch 配置。对于 DFIR 团队来说，启用 CloudWatch 可以加速事件调查过程。因此，如果组织没有 CloudWatch，设置适当的策略可以使流日志立即可用，这对调查至关重要。

配置 VPC 流日志

每个类别的日志都作为日志组记录在 CloudWatch 中。日志组是相似类型日志的集合。例如，所有 VPC 流日志将位于一个 CloudWatch 的日志组下；类似地，所有 CloudTrail 事件将位于一个单独的日志组中。在下一个示例中，创建了两个日志组，并为每个日志组启用了特定的日志记录。每个 AWS 资源将在每个日志组内以日志流的形式发布其流日志。例如，假设您有五个运行中的 EC2 实例，随后您再创建另外五个 EC2 实例。最终，当您登录到 CloudWatch 控制台时，您将看到一个日志组，其中包含多个日志流，通过网络接口 ID 唯一标识每个 EC2 资源。

请注意，日志流是一个网络流日志流，只捕获流中的特定元素。我们在本章的VPC 流日志部分中讨论了流日志包含的内容。每个日志流包含与网络接口相关的多个流日志条目，随后可以对其进行查询或分析以获取进一步的洞察。以下截图描述了 CloudWatch 如何按类别对所有流日志进行分组。在截图中，您会看到 VPC 流日志被分组在 vpcgrp1 下，而 CloudTrail 日志则被分组在 aws-cloudtrail-logs-vb77-569383a0 下：

图 4.22 – CloudWatch 日志组

图 4.22 – CloudWatch 日志组

VPC 流日志访问要求

由于 AWS 正在发布每个 EC2 实例的流日志，发布或发送到其他 AWS 资源，因此 AWS 要求帐户具有适当的 IAM 配置，以允许服务之间进行交互。默认情况下，AWS 不会自动启用日志发布到 CloudWatch（因为它是一个单独的订阅）。与流日志相关的权限必须具有适当的权限，以允许 VPC 将其发布到 CloudWatch。

从高层次来看，通常需要以下权限：

  • CreateLogGroup：请记住，如图 4.22所示，日志按类别进行分组。这允许写入权限创建具有特定名称的新日志组。

  • CreateLogStream：每个 EC2 资源将在日志组中以日志流的形式发布其 VPC 日志。这允许写入权限来为每个资源创建一个新的日志流。

  • PutLogEvents：允许在每个日志流内批量写入日志事件的权限。

  • DescribeLogGroups：描述或列出与 AWS 帐户关联的日志组。

  • DescribeLogStream：类似于日志组，它允许列出与帐户关联的特定日志组中的所有日志流。

  • GetLogRecord：允许读取单个日志事件中的所有字段。

  • GetQueryResults：允许读取/返回特定查询的查询结果。

CloudWatch 角色被分配了额外的权限：

  • DescribeQueries：允许列出最近执行的 CloudWatch Logs Insights 查询。

  • StopQuery: 允许停止 CloudWatch Logs Insights 查询执行的权限

  • DeleteQueryDefinition: 删除已保存的 CloudWatch 查询的权限

  • PutQueryDefinition: 创建和更新查询的权限

  • GetLogDelivery: 允许读取特定日志的日志交付信息

  • ListLogDeliveries: 类似于 GetLogDelivery，它允许列出与 AWS 账户相关的所有日志交付信息

  • CreateLogDelivery: 允许创建新的日志交付权限

  • UpdateLogDelivery: 允许编辑日志交付配置

除了 IAM 权限外，你还必须配置策略，允许流日志在你的 AWS 账户中承担特定角色。在此情况下，我们明确设置一个策略，允许 VPC 流日志在 AWS 账户内承担角色。策略将角色和资源分配与特定的资源访问条件组合在一起。策略是 IAM 通过将其附加到特定 IAM 用户或身份配置文件来管理权限的方式。策略在与身份、用户或资源关联时定义其权限。

接下来是一个 IAM 策略示例，使用 AWS 提供的可视化工具专门创建，以允许发布 VPC 流日志，并允许用户访问和查询日志：

{
    "Version": "2022-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            «Action»: [
                "logs:DescribeQueries",
                "logs:GetLogRecord",
                "logs:StopQuery",
                "logs:TestMetricFilter",
                "logs:DeleteQueryDefinition",
                "logs:PutQueryDefinition",
                "logs:GetLogDelivery",
                "logs:ListLogDeliveries",
                "logs:Link",
                "logs:CreateLogDelivery",
                "logs:DeleteResourcePolicy",
                "logs:PutResourcePolicy",
                "logs:DescribeExportTasks",
                "logs:GetQueryResults",
                "logs:UpdateLogDelivery",
                "logs:CancelExportTask",
                "logs:DeleteLogDelivery",
                "logs:DescribeQueryDefinitions",
                "logs:DescribeResourcePolicies",
                "logs:DescribeDestinations"
            ],
            "Resource": "*"
        },
        {
            "Sid": "VisualEditor1",
            "Effect": "Allow",
            "Action": "logs:*",
            "Resource": "arn:aws:logs:*:xxxxxxxx6548:log-group:*"
        },
        {
            "Sid": "VisualEditor2",
            "Effect": "Allow",
            "Action": "logs:*",
            "Resource": [
                "arn:aws:logs:*:xxxxxxxx6548:destination:*",
                "arn:aws:logs:*:xxxxxxxx6548:log-group:*:log-stream:*"
            ]
        }
    ]
}

从高层次来看，下面是该策略的分解。该策略包含三个条目，形式为数组项：

  • 声明 1: 允许的 CloudWatch Logs 操作列表。这些操作包括各种 CloudWatch Logs 的管理和数据检索操作。

  • logs:* 实例（CloudWatch Logs 操作）在特定的 AWS 账户内。这将包括与 AWS 账户相关联的所有日志组。

  • logs:* 与特定 AWS 账户相关联的实例，以及 AWS 账户内指定的所有日志流。

记住——策略允许用户访问、编辑或查询 CloudWatch 日志。然而，你需要在 AWS 资源之间设置信任关系，以便其能够首先共享/发布日志。通常，在你首次设置并启用 CloudWatch 时，这个过程会自动完成。但你也可以为特定的资源之间的信任关系制定详细的信任策略。以下是一个在 IAM 模块中配置的信任关系示例：

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "vpc-flow-logs.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

上面的 JSON 代表了一个 IAM 角色信任策略，允许 Amazon VPC 流日志服务（vpc-flow-logs.amazonaws.com）承担该角色。此信任策略用于在 IAM 角色与信任实体之间建立信任关系（在此情况下是 VPC 流日志服务）。AssumeRole 安全令牌允许相关 AWS 资源获得一组临时安全凭证，在此情况下，VPC 服务可以使用这些凭证与其他 AWS 服务（如 CloudWatch）进行通信，传递流日志。AssumeRole 允许跨账户访问，并可用于向任何 AWS 服务发出 API 调用。

在 AWS 控制台上查询 CloudWatch 日志

对于在 AWS 内手动查询 CloudWatch，DFIR 团队可以利用 Logs Insights 构建特定的调查查询。Logs Insights 提供交互式查询功能，用于搜索和分析日志数据。CloudWatch 自动从各种日志源（包括以 JSON 格式发送到 CloudWatch 的任何自定义日志）中识别相关字段。您还可以创建包括图形在内的视觉输出作为 Logs Insights 查询的一部分。

在下一个示例中，我们正在查看 VPC 流日志。然而，在查询时，您可以选择所有日志组。以下屏幕截图展示了在 CloudWatch Logs Insights 中查询的示例。该查询针对vpcgrp1日志组，以识别生成流日志的LogStream（源网络标识符），以及日志（在查询多个日志组时，识别日志所在的账户和日志组非常有用）。选择适当的时间范围，以便 CloudWatch 查找日志：

图 4.23 – CloudWatch 的样本查询

图 4.23 – CloudWatch 的样本查询

当您在 Logs Insights 中查询时，CloudWatch 将生成结果和直方图，允许调查人员根据直方图中确定的异常拖动和选择时间线。下一个屏幕截图是这样一个查询结果的示例，其中直方图概述了基于时间戳的事件及每个日期和时间条目的记录数量：

图 4.24 – CloudWatch 生成的 VPC 流量样本可视化

图 4.24 – CloudWatch 生成的 VPC 流量样本可视化

通过仅使用样本查询来确定所有 VPC 日志观察到的流量模式，您可以进一步开始筛选进行调查。如果调查对象被钉定为与特定日志流连接的 EC2 实例，则可以按日期（通过选择选项）和特定的 VPC 日志流进行筛选。每个查询还将为您提供日志的摘要详情（作为简单字符串），以及如图 4.24所示的可视化。

CloudTrail 还提供预定义的查询，以帮助 DFIR 团队开始；他们可以使用这些基本查询来修改并应用必要的过滤器，以获取他们调查所需的结果。

我们使用了样本查询来确定所有被标记为ACCEPT的网络流量，这意味着被 VPC 和 EC2（通过安全组配置）允许，并检查了每个会话的流量量：

filter action="ACCEPT" | filter bytesTransferred > 100 | stats sum(bytes) as bytesTransferred by srcAddr, srcPort, dstAddr, dstPort, action

前述查询针对所有 VPC 日志流运行；然而，如果我们不指定limit结果选项，AWS 将限制结果为 1,000 条记录，以避免拉取结果时的资源限制。

下一个屏幕截图概述了我们运行前述查询后获得的结果：

图 4.25 – CloudWatch 查询结果

图 4.25 – CloudWatch 查询结果

让我们来看一个通过 SSH 进行的数据外泄示例。我们想要确定 AWS EC2 实例与远程威胁行为者控制的服务器之间的出站网络流量。你可以使用 CloudWatch 查询来过滤特定 IP 地址或仅使用源端口（srcPort）来识别哪个其他 EC2 实例被这个 IP 地址访问。在下一个示例中，我们特别关注所有的出站网络连接。如果你对某个特定端口的入站网络活动感兴趣，可以在过滤器中设置目标端口（dstPort）：

filter action="ACCEPT" | filter bytesTransferred > 100 | filter srcPort=22 |stats sum(bytes) as bytesTransferred by srcAddr, srcPort, dstAddr, dstPort, action

我们可以通过 CloudWatch 提供的结果和相关可视化查看网络峰值。如前所述，由于 CloudWatch 提供交互式查询功能，你可以点击并选择特定的流量峰值，从而过滤出与这些网络出站峰值相关的时间范围。在下一个截图中，我们深入分析了 CloudWatch 识别出的网络峰值：

图 4.26 – 初始查询结果

图 4.26 – 初始查询结果

为了继续常规调查，我们通过交互式选择峰值来选择日期/时间，这样可以提供更细致的可视化。请注意，过滤器中的日期/时间现在已转换为小时：

图 4.27 – 出站网络流量的细粒度视图

图 4.27 – 出站网络流量的细粒度视图

通过这次深度分析，我们可以将网络流量浓缩为三个大的峰值，这些峰值归因于出站网络活动。请注意，流量模式仍然表明多个 IP 地址，其中一些可能仍然是合法的。为了确定潜在的威胁行为者 IP 地址，同时，在同一屏幕上应用时间过滤器，我们将编辑查询，以识别数据传输量从最多到最少的 IP 地址。在数据外泄场景中，威胁行为者通常会从服务器中外泄大量信息。在这个示例中，我们将出站网络流量过滤为超过 1,000,000 字节（大约 1MB）传输的数据，并按降序排列：

filter action="ACCEPT" | filter bytesTransferred > 1000000 | filter srcPort=22 |stats sum(bytes) as bytesTransferred by srcAddr, srcPort, dstAddr, dstPort, action | sort bytesTransferred desc

结果，我们在 3 个网络峰值事件中大约获得了 19 个数据传输事件，这些事件可能与数据外泄活动有关。由于我们已经过滤了结果，DFIR 团队现在可以使用目标 IP 地址字段执行某种形式的开源情报（OSINT），以确定 IP 地址的合法性，从而进一步锁定或应用必要的过滤器：

图 4.28 – 超过 1MB 的数据外泄查询结果

图 4.28 – 超过 1MB 的数据外泄查询结果

正如我们在按字节传输量排序的结果中看到的那样，我们可以立即开始查看这些峰值，并将其与其余的调查进行对比关联。这只是一个 IP 地址过滤器的示例，用于识别与特定 IP 地址相关的网络活动：

filter action="ACCEPT" | filter bytesTransferred > 1000000 | filter srcPort=22  | filter dstAddr="72.137.104.5" |stats sum(bytes) as bytesTransferred by srcAddr, srcPort, dstAddr, dstPort, action | sort bytesTransferred desc

我们在下一个截图中看到查询的结果：

图 4.29 – 基于 IP 地址的网络活动

图 4.29 – 基于 IP 地址的网络活动

如我们所知，VPC 流日志类似于 NetFlow 日志；我们可以利用提取的结果进一步查询以确定网络流量的来源——即，流量来自哪一个 EC2 实例。你可以通过关联源 IP 地址字段（srcAddr）并将其映射回在事件期间分配给该 IP 的 EC2 实例来实现这一点。我们修改此查询以获取以下字段：

  • timestamp：事件的日期和时间

  • message：以消息格式呈现的 NetFlow 摘要

  • logStream：负责该消息的 VPC 日志流

下一个查询旨在获取整个数据外泄活动的消息和日志流信息：

filter action="ACCEPT" | filter srcPort=22 | filter dstAddr="72.137.104.5" | fields @timestamp, @message, @logStream

基于先前所示的查询，我们可以在截图中看到每个事件的详细信息。这使得 DFIR 团队能够获得网络流日志的具体信息及其他元数据：

图 4.30 – 前述查询结果的截图

前述结果为每一行的日志信息提供了超链接，并展示了其他关键数据。通过每一行的下拉选项，提供了进一步调查所需的附加信息。在下一个截图中，我们展开了一个示例日志事件，突出了 VPC 流日志捕获的字段：

图 4.31 – 额外的 VPC 流日志信息

图 4.31 – 额外的 VPC 流日志信息

你可以使用预设的 CloudWatch 查询添加额外的过滤器，以进一步推进你的调查。通过前面截图中反映的附加信息，我们可以将出站网络流量的源头锁定到特定的 EC2 实例，通过关联 ENI ID 与 EC2 实例来实现。总的来说，我们从 89,827 条记录开始，经过适用的时间过滤器后，筛选出了数据外泄最多的 3 条记录。作为 DFIR 团队，你们必须进一步对其他 IP 地址进行切片和分析；这演示了 CloudWatch 如何为调查提供支持。

CloudWatch 的 DFIR 使用案例

通过本章的各个部分，我们现在知道了 CloudWatch 在 DFIR 角度中的重要性。接下来是一些使用案例，展示 CloudWatch 如何用于取证调查和异常检测：

  • 日志审查：正如我们所知，CloudWatch 提供了一个集中式的日志仓库，包括 CloudTrail 日志。因此，它提供了一个 SPOG，DFIR 团队可以快速查询所有日志并得出调查结果。你可以利用 CloudWatch 来检测异常活动和未经授权的访问，并关联来自各个日志源的事件，这些日志源已被引入 CloudWatch。

  • 异常检测：DFIR 团队可以根据特定的指标（例如 CPU 利用率、网络流量或存储）定义阈值和警报，以识别异常模式或与正常行为的偏离。异常指标可以作为安全漏洞或实例被入侵的早期指示。

  • IR 自动化：CloudWatch 原生集成其他基于工作流的服务，包括 AWS Lambda 和 AWS Systems Manager Automation，用于在特定事件警报发生时自动化执行隔离、快照创建和用户账户变更。工作流基于触发器，可以实现自动修复和隔离操作。

  • 合规性和审计：由于 CloudWatch 提供集中化的日志记录和监控功能，这也支持合规性监控和审计支持。DFIR 团队可以利用 CloudWatch 日志和指标来证明遵循安全政策、跟踪用户活动，并生成合规性审计报告。

亚马逊 GuardDuty

GuardDuty 是一项威胁检测服务，旨在通过持续监控恶意活动和未经授权的行为，帮助保护 AWS 资源和工作负载。请注意，这是一项检测服务，而不是响应服务。它检测并通知用户 AWS 资源中的潜在威胁。然而，与自动化服务（如 Lambda）的集成将增强 GuardDuty 基于已建立的响应计划，针对每个检测到的威胁进行响应。GuardDuty 使用机器学习（ML）、异常检测和集成的 TI 来识别 AWS 环境中的潜在安全威胁。

一些 DFIR 使用案例如下：

  • 威胁检测：GuardDuty 分析 CloudTrail 日志、VPC 流日志和 DNS 日志，以检测 入侵指标（IOCs）和潜在威胁。它应用机器学习算法来识别可能表示恶意活动的模式和异常，例如未经授权的访问尝试、侦察行为或表现出与恶意软件或僵尸网络相关的行为的实例。这些 IOCs 通过 AWS 的 TI 合作伙伴和第三方供应商工具收集，并提供给其客户。DFIR 团队无法控制或管理这些 IOCs。

  • TI：GuardDuty 利用来自 AWS、合作伙伴组织和开放源情报（OSINT）的 TI 数据流来增强其威胁检测能力。它将 AWS 环境中的网络活动与已知的恶意 IP、域名和其他指示符进行比较，以识别潜在的安全风险。

  • 集中式安全监控：GuardDuty 提供一个集中视图，显示跨 AWS 账户和区域的安全发现。它汇总并优先排序安全警报，使安全团队能够专注于最关键的威胁。合并的仪表板和事件流可以快速检测和响应潜在的安全事件。

  • 自动化修复：GuardDuty 与其他 AWS 服务（如 AWS Lambda 和 AWS Systems Manager）集成，便于自动响应安全事件。您可以编排自定义动作，或使用预构建的响应手册来自动化修复操作，例如隔离被攻陷的实例、阻止恶意 IP，或更新安全组。

  • 安全操作和 IR：GuardDuty 在安全操作和 IR 工作流中至关重要。它提供实时警报和发现，帮助安全团队快速调查并响应潜在的安全事件。与 AWS 服务如 Amazon CloudWatch 和 AWS Lambda 的集成，使得自动化 IR 和安全团队能够立即采取行动。

权限和信任

要利用 GuardDuty 的功能，DFIR 团队必须确保至少允许以下权限：

  • ec2:DescribeInstances：描述 EC2 实例

  • ec2:DescribeImages：描述 EC2 实例的镜像

  • ec2:DescribeVpcEndpoints：识别 VPC 端点名称

  • ec2:DescribeSubnets：识别 VPC 子网信息

  • ec2:DescribeVpcPeeringConnections：识别并列举 VPC 对等连接信息

  • ec2:DescribeTransitGatewayAttachments：识别 VPC 中继网关（如果有）

  • organizations:ListAccounts：列出 AWS 账户（组织）下配置的用户账户

  • organizations:DescribeAccount：描述 AWS 账户类型（用户/根账户）

  • s3:GetBucketPublicAccessBlock：检查桶是否有 S3 公共访问阻止

  • s3:GetEncryptionConfiguration：获取 S3 数据加密配置信息

  • s3:GetBucketTagging：获取 S3 桶标签

  • s3:GetAccountPublicAccessBlock：检查 AWS 账户是否有 S3 公共访问阻止

  • s3:ListAllMyBuckets：列举 AWS 账户拥有的所有 S3 桶

  • s3:GetBucketAcl：列举 S3 桶的访问控制列表（ACL）

  • s3:GetBucketPolicy：列举 S3 桶策略

  • s3:GetBucketPolicyStatus：获取当前桶策略状态

此外，Amazon GuardDuty 服务要求其假设特定的 IAM 角色。这些角色可以配置附加的策略，并可能附加到角色上。Amazon GuardDuty 通常需要sts:AssumeRole角色来委派访问权限。允许 GuardDuty 假设此角色，使其能够代表角色执行基于分配权限的授权操作。

亚马逊 GuardDuty 恶意软件扫描

在 EC2 实例和其他资源上启用恶意软件扫描是开始寻找恶意软件的一个好方法。GuardDuty 提供了一个内置服务，可以修改现有的 EC2 实例，使其原生地扫描 EC2 端点以寻找妥协或恶意软件的证据。它会检查数据存储，如 Amazon EBS 卷以及附加到特定 EC2 实例的其他存储形式。如果发现恶意软件的证据，还可以获取相关存储卷的快照。

根据 AWS 账户及其运营区域，Amazon GuardDuty 通过以下供应商提供恶意软件扫描功能：Bitdefender、CloudHesive、CrowdStrike、Fortinet、Palo Alto Networks、Rapid7、Sophos、Sysdig、Trellix。对于 DFIR 团队来说，这意味着他们无需在受影响的 AWS 资源（如 EC2）上集成或部署软件；相反，他们只需在特定的 AWS 账户上启用 GuardDuty 并启动恶意软件扫描，这些解决方案会自动提供，并允许扫描 EBS 中是否存在恶意软件。

注意

Amazon GuardDuty 在以下情况下特别有益：当安装在 EC2 实例内的防病毒软件可能已被威胁者禁用或篡改时。GuardDuty 对 EC2 实例的恶意软件扫描可以提供有关恶意活动或威胁者下载恶意软件的深入信息，从而执行任何恶意行为，而无需额外的安全工具部署。这一点特别有用，因为威胁者通常不会去禁用 GuardDuty。

GuardDuty 还与 CloudWatch 集成，无需特别配置，DFIR 团队可以根据恶意软件扫描查询其他遥测数据。以下截图展示了 GuardDuty 与 CloudWatch 集成的示例，特别是恶意软件扫描事件：

图 4.32 – Amazon GuardDuty 恶意软件扫描的 CloudWatch 查询示例

图 4.32 – Amazon GuardDuty 恶意软件扫描的 CloudWatch 查询示例

除了恶意软件扫描外，GuardDuty 还根据 TI（威胁情报）提供有关威胁的见解，并检测 AWS 账户内各种资源执行的活动。以下是 GuardDuty 生成的示例集，展示了不同的检测结果。请注意，每个检测结果都由 GuardDuty 评估，并标记为高风险、中风险或低风险：

图 4.33 – Amazon GuardDuty 内的样本威胁检测

图 4.33 – Amazon GuardDuty 内的样本威胁检测

一旦启动恶意软件扫描，GuardDuty 会生成一个独特的检测器 ID 来唯一标识每次扫描。我们在其中一台 EC2 实例上启动了扫描，以确定是否存在恶意软件的迹象。接下来是该 EC2 实例上恶意软件扫描的 JSON 输出，展示了一个正在进行的扫描示例：

{
  "DetectorId": "26c440764b66ddeb7ff50f0881fc5e52",
  "AdminDetectorId": "26c440764b66ddeb7ff50f0881fc5e52",
  "ScanId": "b9d0d5771729105b69012dcd71190e81",
  "ScanStatus": "RUNNING",
  "ScanStartTime": "2023-06-03T11:53:24.000Z",
  "TriggerDetails": {},
  "ResourceDetails": {
    "InstanceArn": "arn:aws:ec2:ca-central-1:xxxxxxx6548:instance/i-00229ce2dd123a2e6"
  },
  "ScanResultDetails": {},
  "AccountId": "xxxxxxxx6548",
  "AttachedVolumes": [
    {
      "VolumeArn": "arn:aws:ec2:ca-central-1:xxxxxxxx6548:volume/vol-061392d9abebf9433",
      "VolumeType": "gp2",
      "DeviceName": "/dev/sda1",
      "VolumeSizeInGB": 30,
      "EncryptionType": "UNENCRYPTED"
    },
    {
      "VolumeArn": "arn:aws:ec2:ca-central-1:xxxxxxxx6548:volume/vol-06c47b3cf15b2d6ae",
      "VolumeType": "gp3",
      "DeviceName": "xvdb",
      "VolumeSizeInGB": 30,
      "EncryptionType": "UNENCRYPTED"
    }
  ],
  "ScanType": "ON_DEMAND"
}

扫描完成后，GuardDuty 会生成一份扫描报告，可以通过 恶意软件扫描 页面访问，并获取唯一的 GuardDuty 恶意软件扫描检测 ID。下一张截图展示了 Amazon GuardDuty 在磁盘（Amazon EBS 存储）上识别到潜在的恶意软件：

图 4.34 – Amazon GuardDuty 恶意软件扫描检测

图 4.34 – Amazon GuardDuty 恶意软件扫描检测

这使得 DFIR 团队可以确认恶意软件的存在并进一步追踪威胁。接下来是检测结果的示例。我们看到扫描已在磁盘上发现了八个威胁，以下是其中一个威胁的样本检测摘要：

图 4.35 – Amazon GuardDuty 恶意软件扫描检测

图 4.35 – Amazon GuardDuty 恶意软件扫描检测

如你所见，恶意软件扫描识别了检测到的样本名称，通常由扫描此二进制文件的供应商分配。磁盘上文件的 SHA-256 哈希值对于 DFIR 团队在进一步的威胁狩猎和检测中非常有用。文件路径和名称标识文件的位置，并允许 DFIR 团队手动收集该文件所在的 AWS 卷信息。在 AWS 方面，这是 AWS 资源命名约定的一部分，用于确定账户所有者和此检测发生在哪个卷上的信息（arn:aws:ec2:ca-central-1:xxxxxxxx6548:volume/vol-061392d9abebf9433）。

DFIR 团队还可以通过摘要页面识别扫描此实例的合作伙伴。在我们的例子中，Bitdefender 扫描了这个检测：

图 4.36 – Amazon GuardDuty 扫描器

图 4.36 – Amazon GuardDuty 扫描器

一旦 Amazon GuardDuty 完成扫描，它允许 DFIR 团队也可以进入 Amazon Detective 服务：

图 4.37 – Amazon Detective 在 Amazon GuardDuty 检测中的操作手册

图 4.37 – Amazon Detective 在 Amazon GuardDuty 检测中的操作手册

Amazon Detective

Amazon Detective 帮助 DFIR 团队分析、调查和可视化来自各种 AWS 服务的安全数据。它自动收集并分析来自 AWS CloudTrail、Amazon VPC 流日志和 Amazon GuardDuty 的日志数据，提供有关 AWS 环境中潜在安全漏洞和可疑活动的见解。Amazon Detective 的一些功能如下：

  • 安全图谱：Amazon Detective 采用基于图形的方法，通过创建 AWS 资源、账户及其关系的图形表示，来可视化和分析与安全相关的数据，使得 DFIR 团队能够快速识别模式、异常和潜在的安全威胁。

  • 自动数据摄取：Amazon Detective 自动收集并摄取来自 AWS CloudTrail、Amazon VPC 流日志和 Amazon GuardDuty 的数据，以便聚合和处理，提供洞察和建议。

  • 威胁狩猎：Amazon Detective 为 DFIR 团队提供预构建的查询和分析工具，帮助他们主动寻找安全威胁和异常。这些查询利用机器学习算法和统计模型来识别可疑活动和潜在的安全问题。

  • 安全发现：Amazon Detective 根据其对收集数据的分析结果呈现安全发现。这些发现被优先排序，并包括关于账户、资源、活动和潜在威胁的详细信息。它还包括支持证据和物证，以便进行进一步调查。

注意

请注意，要启用 Amazon Detective，必须先拥有 Amazon GuardDuty。

总结

总结一下，AWS 提供了 API 日志和通用事件日志的集成，并提供了一个 SPOG（单一管理界面）来确定 AWS 账户中的威胁行为者活动或内部威胁。通过 CloudWatch 和 CloudTrail，DFIR 团队可以使用 AWS 的工具本地调查 AWS，并以细粒度识别未经授权的用户执行的活动。此外，诸如 EC2 和 S3 之类的资源提供了有关配置的更多信息，这些信息使 DFIR 团队能够推断并获取进一步的调查数据。请记住，一些安全解决方案，例如 VPC 流日志，默认情况下未启用，需要账户所有者或管理员显式地允许它们。将 CloudTrail 日志与 CloudWatch 集成，并启用 Amazon GuardDuty，为 DFIR 团队提供了对 AWS 账户和资源内威胁的深入洞察，而无需显式部署安全工具。启用 GuardDuty，随后启用 Amazon Detective，可以提供遥测信息，使 DFIR 团队能够定位威胁并执行额外的威胁狩猎。组织和 DFIR 团队必须意识到，启用任何安全功能会单独收费，并会反映在下一个账单中。

在接下来的几章中，我们将类似地探索 Microsoft Azure 和 Google Cloud 的原生调查能力，并最终将它们与其他开源和商业工具结合，以从这些云实例中提取取证文物，供离线调查使用。总体目标是确保 DFIR 团队拥有足够的信息和来自多个日志源的数据，这些数据能够验证威胁行为者的活动，并使团队能够通过这些工具确认未经授权的活动，达到毫无疑问的程度。

进一步阅读

第二部分：法医准备：云法医的工具、技术和准备工作

在本部分中，我们将调查云中的事件，特别是利用云原生工具来调查威胁并分析工件。我们将为云调查建立前提条件，识别一个场景，并使用云原生工具进行调查。

本部分包含以下章节：

  • 第四章，DFIR 调查 – AWS 中的日志

  • 第五章，DFIR 调查 – Azure 中的日志

  • 第六章，DFIR 调查 – GCP 中的日志

  • 第七章，云生产力套件

第五章：DFIR 调查 – Azure 中的日志

在上一章中，我们讨论了如何响应 Amazon Web Services（AWS）中的事件。本章将重点介绍如何在微软 Azure 中响应事件，Azure 是全球第二大流行的云计算产品。在 Azure 中响应事件的一个关键方面是分析来自不同 Azure 服务的日志数据。在本章中，我们将探索 Azure 中可用的各种日志来源，如何获取这些日志，以及分析这些数据的最佳实践，以检测、控制和解决 Azure 中的安全事件。通过了解 Azure 中可用的工具和技术，事件响应专家可以更好地保护并响应组织的云基础设施，以应对安全事件。

类似于 AWS，了解 Azure 中哪些日志是默认可用的，哪些需要防御者和调查员启用，对于云取证至关重要。本章概述了第三章中讨论的一些重要 Azure 服务和产品可用的各种日志，并探讨了如何在调查过程中利用这些日志来源。具体而言，我们将讨论以下 Azure 数据来源：

  • Azure Log Analytics

  • Azure 虚拟网络

  • Azure 存储

  • Azure 虚拟机

  • Microsoft Sentinel

Azure Log Analytics

Azure Log Analytics 是 Azure 提供的一项基于云的服务，允许组织收集、分析并从日志和操作数据中获取洞察。它提供了一个集中式平台，用于监控、故障排除和检测跨各种云和本地环境中的异常。通过 Azure Log Analytics，组织能够深入了解其系统和应用，帮助他们做出明智的决策，并采取主动措施以维持最佳的性能和安全性。

Azure Log Analytics 可以视为 AWS CloudTrail（在第四章中讨论）的等效物，专门用于收集和分析来自各种 Azure 服务的日志。通过收集这些服务的日志，组织可以深入了解其性能、可用性和安全性。它为监控和故障排除 Azure 资源提供了一个统一的平台。

Azure Log Analytics 至关重要，因为它作为 Azure 生态系统中的日志记录支柱，提供了关于虚拟网络环境、存储服务和 EC2 实例的全面洞察。因此，我们将在此简要介绍 Azure Log Analytics 在主要 Azure 产品和服务中的作用，并在本章的 Azure 产品部分演示如何集成 Log Analytics。

为了有效地管理和优化云操作，组织依赖 Azure Log Analytics 提供关于各种 Azure 服务的全面洞察：

  • Azure 虚拟网络：Azure 日志分析与 Azure 网络观察器集成，后者提供虚拟网络流量、网络安全组和流量日志的深入洞察。通过分析这些日志，组织可以监控网络活动，检测可疑行为，并确保遵守安全政策。

  • Azure 存储：Azure 日志分析可以收集来自 Azure 存储服务的日志，例如 Blob 存储和表存储。这使组织能够监控和分析与存储相关的活动，例如读写操作、访问模式和存储容量利用率。

  • Azure 实例：Azure 日志分析代理可以安装在 Azure 虚拟机上，以收集这些实例的日志数据。这包括与操作系统事件、应用程序日志以及自定义日志文件相关的日志。

日志分析的理念是让你能够查询和/或可视化来自所有 Azure 资源的遥测数据。事故响应人员可以查询这些日志，寻找任何潜在的安全威胁。下图展示了 Azure Monitor 中日志查询的示例，我们将在本章稍后讨论 Azure Monitor：

图 4.1 – 日志查询示例

图 4.1 – 日志查询示例

Azure 中的查询语言基于 Kusto 查询语言（KQL）。KQL 提供了一套语法和操作符，使事故响应人员能够检索、分析和可视化存储在 Azure 中的大量数据。理解 KQL 对事故响应人员至关重要。

尽管 Azure 日志分析通过其 KQL 提供了强大的功能，可以解析大量数据集并提取关键信息，但当考虑它所监控的网络基础设施时，它的作用变得更加重要。作为微软云环境的基石，Azure 虚拟网络具有自己的一套复杂性。理解这些网络及其相互作用至关重要，而日志分析提供了监控这些网络的工具。

Azure 虚拟网络

虚拟网络与你在自己组织数据中心中操作并搭建的传统网络非常相似。就像网络允许你组织的资产和资源相互通信一样，Azure 的虚拟网络服务允许你为 Azure 资源和服务建立一个网络，使它们能够相互通信，或者与公共互联网、组织的本地网络和资源进行通信。

与 AWS 的 VPC 类似，当你在 Azure 中创建虚拟机资源时，你可以创建一个 Azure 虚拟网络或使用已有的虚拟网络（如果已经创建）。你的虚拟网络就像 Azure 管理的任何其他实体（被称为 Azure 资源），例如虚拟机、数据存储、数据库或我们之前在第三章中讨论过的其他服务。

为了演示目的以及本节内容的需要，我们在 Azure 中创建了一个名为 CloudForensicsTestVM-vnet 的虚拟网络。所有虚拟网络都可以通过 Azure 主页页面上的 虚拟网络 服务直接访问：

图 4.2 – 虚拟网络示例

图 4.2 – 虚拟网络示例

根据组织的规模，可能会存在为测试和开发创建的未使用虚拟网络——事件响应人员应考虑从调查包含生产服务器/服务或关键资源的虚拟网络开始，或者根据虚拟机是否被报告为已受损来调查虚拟网络。

调查人员可以扩展到虚拟网络并确定其网络属性和配置，如下所示：

图 4.3 – 虚拟网络属性示例

图 4.3 – 虚拟网络属性示例

所有 Azure 中的虚拟网络包含五个关键标签：

  • 拓扑：这是您的虚拟网络拓扑。可以将其视为 Azure 自动生成的网络图。对于调查人员来说，这一点特别有用，因为它使调查人员能够了解组织的云基础设施，而无需依赖 IT 团队是否维护了网络图和文档。以下截图显示了包含网络接口和单个虚拟机实例的网络拓扑示例——接口和虚拟机周围的轮廓代表虚拟网络和默认子网：

图 4.4 – 虚拟网络拓扑示例

图 4.4 – 虚拟网络拓扑示例

  • 属性：此标签将包含您虚拟网络的所有网络配置属性。这包括您的 IP 地址空间、子网和虚拟网络 ID。调查人员应注意地址空间和子网 IP，因为了解网络的 IP 地址范围和子网可以帮助响应人员识别和追踪可疑活动或恶意流量的来源。此外，了解您的地址空间可以让您与可能捕获资源 IP 的其他日志源（例如，EDR 日志）进行关联：

图 4.5 – 网络属性示例

图 4.5 – 网络属性示例

  • 功能：此选项卡包含可用于进一步增强虚拟网络的 Azure 产品和服务。例如，组织可以启用 Azure 的 DDoS 保护或 Azure 防火墙，而不是配置自己的负载均衡器或防火墙。这些功能不仅为 Azure 资源和资产提供额外的安全保护，还在事件中充当额外的日志来源。例如，启用 Microsoft Defender for Cloud 将为您的虚拟机、容器、数据库、存储应用服务等提供威胁保护。Cloud Defender 将生成额外的安全警报/日志，以便检测到您 Azure 资源中的任何恶意活动。我们将在本章后续内容中更深入地探讨 Microsoft Defender for Cloud：

图 4.6 – 虚拟网络功能示例

图 4.6 – 虚拟网络功能示例

  • 推荐：推荐选项卡提供基于成本、安全性、可靠性、性能和运营卓越性的 Azure 推荐列表。威胁管理团队可以利用推荐选项卡，根据微软自动化顾问引擎定义的个性化最佳实践，启用任何安全态势和可靠性方面的快速改进。此外，事件响应者可以利用此选项卡获取任何推荐，以确定在事件发生时可能存在的任何漏洞，并将其纳入他们的推荐报告中，以便威胁管理团队采取行动：

图 4.7 – 微软虚拟网络推荐示例

图 4.7 – 微软虚拟网络推荐示例

  • 教程：此选项卡提供微软的免费培训列表。微软、亚马逊和谷歌都持续更新其云服务中的功能和产品。因此，事件响应者可以利用此选项卡快速了解任何新添加的功能。

一个与这些属性互补且确保网络安全态势稳健的关键工具是 Azure 的网络安全组（NSG）流日志。这些日志提供了对网络流量的细粒度可见性，弥补了网络配置与实际网络活动之间的差距。

NSG 流日志

在 Azure 中，NSG 和虚拟网络是两个不同的概念，分别在网络安全和网络基础设施管理中发挥着不同的作用。NSG 是 Azure 网络安全架构的基本组件。它充当虚拟防火墙，用于控制进入和离开虚拟机、子网或网络接口的流量。NSG 允许您定义入站和出站安全规则，基于协议、端口、源 IP 地址和目标 IP 地址过滤网络流量。它们通过允许或拒绝基于规则配置的流量，提供细粒度的网络安全控制。

Azure 虚拟网络是 Azure 网络中一个基础性的构造，它代表了 Azure 云中的一个独立网络环境。正如我们在本章前面所看到的，Azure 虚拟网络允许组织定义 IP 地址范围、子网和网络拓扑，以构建他们的网络基础设施。

在 Azure 中为 NSG 定义访问控制列表（ACLs）涉及配置规则，这些规则控制与虚拟网络中相关资源的进出网络流量。ACLs 作为虚拟防火墙提供对网络通信的精细控制。通过 NSG 规则，您可以根据源/目标 IP 地址、端口和协议指定允许或拒绝的流量。这些规则有助于执行安全策略并限制对虚拟机或子网的未经授权访问，从而使管理员能够有效地定义和管理网络流量。以下截图展示了一个 NSG 的示例：

图 4.8 – NSG 示例

图 4.8 – NSG 示例

在 Azure 和 AWS 中定义 ACLs 在其目的和功能上有相似之处。两个平台都允许用户创建规则，通过源/目标 IP 地址、端口和协议来控制进出网络流量。下面的截图展示了 Azure NSG 的 ACL 规则示例。在此示例中，网络仅允许来自一个公共源 IP 地址的传入（入站）连接到端口 22（SSH），该源 IP 地址已出于安全原因被隐去：

图 4.9 – 访问控制列表（ACLs）

图 4.9 – 访问控制列表（ACLs）

事件响应者可以分析 ACLs 以识别任何未经授权的入站连接规则（例如，RDP 端口开放，允许来自任何 IP 地址的入站连接），或创建新的 ACL 规则以阻止任何网络攻击迹象（例如，命令与控制 IP）。

如在 第四章 中讨论的，(网络) 流量日志是网络流量流动信息的记录，捕捉诸如源和目标 IP 地址、端口、协议以及其他与网络流量相关的元数据。在 Azure 的背景下，NSG 流量日志特指由 Azure 中的 NSG 生成的流量日志。NSG 流量日志提供了对虚拟网络中流经 NSG 的网络流量的可视性。

通过启用 NSG 流量日志，组织能够深入了解网络通信模式，帮助他们监控和分析流量行为，检测异常，排除连接问题，并增强网络安全分析。这些日志可以用于法医分析，提供有关安全漏洞的全面信息，有助于保护 Azure 网络环境。

与 AWS 的 VPC 流日志类似，Azure 默认没有启用 NSG 流日志。因此，需要进行显式的设置。要启用 NSG 流日志记录，必须在 Azure 中创建一个 NSG 流日志资源。接下来，Azure 提供了将 NSG 日志下载到本地、将其转发到其他工具（例如，安全信息和事件管理（SIEM）系统）或使用 Microsoft 的 Azure Network Watcher 流量分析解决方案的选项。流量分析在 Azure 内部分析您的 Azure NSG 流日志，允许组织可视化和查询网络活动，并识别威胁和关注领域（开放端口、不寻常的网络流量等）。启用和查看 NSG 流日志需要以下三个连续步骤：

  1. 创建 Azure 存储帐户：要启用并创建 NSG 流日志记录，必须创建并分配存储空间以保存这些日志。这可以在创建 Azure 中的流日志时完成。请参见以下截图，以更直观地了解如何在 Azure 中设置示例存储帐户，特别是在创建 NSG 流日志过程中：

图 4.10 – 创建存储帐户

图 4.10 – 创建存储帐户

以下截图展示了如何在 Azure 中创建流日志：

图 4.11 – 创建流日志

图 4.11 – 创建流日志

  1. 创建 NSG 流日志：这包括填充资源以及与流日志记录相关的其他属性。您可以使用 Microsoft 的流量分析、Splunk、Grafana 或任何其他 SIEM 工具导出、处理、分析和可视化 NSG 流日志。在本示例中，我们将启用 Microsoft 的流量分析，因为它已与 Microsoft 集成，且可以快速轻松地处理日志。以下截图展示了如何启用流量分析并将您的网络流量发送到 Azure 日志分析工作区：

图 4.12 – 创建流日志并启用流量分析

图 4.12 – 创建流日志并启用流量分析

  1. 转到在步骤 2中创建的流量分析工作区，以查看并查询在步骤 1和步骤 2中创建的 NSG 流日志。

    Microsoft 提供了以下预构建查询，用于查询 NSG 流日志：

    AzureNetworkAnalytics_CL
| where SubType_s == "FlowLog"
| extend FlowDirection = iff(FlowDirection_s == 'O', 'Outbound', 'Inbound')
| extend AllowedOrDenied = iff(FlowStatus_s == 'A', 'Allowed', 'Denied')
| extend SourceIP = iff(isempty(SrcIP_s), extract_all(@"(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})", SrcPublicIPs_s), SrcIP_s)
| extend DestinationIP = iff(isempty(DestIP_s), extract_all(@"(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})", DestPublicIPs_s), DestIP_s)
| extend Protocol = case(L4Protocol_s == 'T', "TCP", L4Protocol_s == 'U', "UDP", L4Protocol_s)
| project-rename NSGFL_Version = FASchemaVersion_s
| project TimeGenerated, FlowDirection, AllowedOrDenied, SourceIP, DestinationIP, DestPort_d, Protocol, L7Protocol_s, NSGList_s, NSGRule_s, NSGFL_Version
| limit 100

以下是 KQL 查询的详细说明：

  • 表格选择：AzureNetworkAnalytics_CL指定查询从中获取数据的数据表—在本例中是 Azure 网络分析日志。

  • 过滤：| where SubType_s == "FlowLog"用于过滤数据，使其仅包括SubType列值为FlowLog的记录。

  • 使用extend进行数据转换：extend命令多次使用，用于向数据中添加新列：

    • FlowDirection = iff(FlowDirection_s == 'O', 'Outbound', 'Inbound')：这行代码添加了一个新的列FlowDirection，它根据FlowDirection_s中的值将流向分类为'Outbound'或'Inbound'。

    • AllowedOrDenied = iff(FlowStatus_s == 'A', 'Allowed', 'Denied')：用于确定流量是允许还是拒绝

    • SourceIP 和 DestinationIP：这些行处理 IP 地址提取和格式化

    • Protocol = case(...)：根据条件将协议设置为 TCP 或 UDP，或者保留原始值

  • 重命名列：| project-rename NSGFL_Version = FASchemaVersion_s 将 FASchemaVersion_s 列重命名为 NSGFL_Version

  • 选择特定列：project 命令用于选择要包含在最终输出中的特定列

  • 限制结果：| limit 100 将输出限制为前 100 条记录

一般来说，KQL 查询将具有以下通用结构：

  • 表格选择：查询开始时通过指定数据表（例如，网络事件）来进行

  • |）：用于将不同命令串联，其中一个命令的输出作为下一个命令的输入

  • 过滤（where）：用于仅包括符合特定条件的记录

  • 数据转换（extend）：添加新列或修改现有列

  • sum、count、avg 和 group by 用于数据聚合

  • 投影（project）：指定最终输出中应包含哪些列

  • sort by 和 limit 控制输出中记录的顺序和数量

查询结果如下截图所示。如你所见，所有允许和拒绝的入站/出站流量都被捕获并以表格格式展示。在这种情况下，包含允许的入站连接的条目是我们通过 SSH 连接到虚拟机资源的条目（SourceIP 已因隐私原因被屏蔽），它标志着可能的入口点和未经授权访问虚拟机的风险：

图 4.13 – 流日志查询结果

图 4.13 – 流日志查询结果

数字取证和事件响应用例在从 AWS 流日志过渡到 Azure 流日志时不会发生显著变化，因为它们的基础目的是捕获网络流量数据。尽管日志格式、用户界面和命名约定可能有所不同，但这两种解决方案都能为网络活动提供有价值的洞察，便于调查、威胁检测和事件响应，无论云服务提供商是谁。

在 Azure 虚拟网络领域，我们已经深入探讨了如何创建流日志及其后续查询，揭示了网络数据的动态交互。接下来的重点将是 Azure 存储——Azure 生态系统中一个至关重要的部分，它不仅存储这些日志，还提供了丰富的功能来无缝管理和访问海量数据。

Azure 存储

Azure 存储是由 Azure 提供的云存储服务。Azure 存储提供了不同的存储选项，其中之一是 Azure Blob 存储。

Azure Blob，即 Azure 二进制大对象，是 Azure 存储中的特定存储类型，专为存储非结构化数据如文档、图像、视频和其他文件类型而设计。它提供了一种简单且具有成本效益的方式来存储大量数据，并提供高可用性、耐久性和可扩展性等功能。Azure Blob 常用于备份与恢复、内容分发、媒体流以及作为云中应用程序的数据源。

在 Azure 存储帐户内，事件响应者可能首先希望查看给定存储帐户的访问权限级别（并由此查看其所包含的数据）。这可以通过导航到存储帐户的 访问控制（IAM） 页面并检查所有有权访问数据的用户来完成：

图 4.14 – 访问控制（IAM）面板

图 4.14 – 访问控制（IAM）面板

接下来，调查人员可以利用存储帐户中的 活动日志 页面——此页面可以在左侧面板中找到。活动日志 将显示 Azure 租户范围内在订阅/Azure 租户级别的活动（例如，我们可以确定某个存储帐户在 Azure 中的创建时间以及创建者）。通过以下截图，我们展示了活动日志的示例：

图 4.15 – 活动日志

图 4.15 – 活动日志

虽然前面的截图提供了存储活动日志的初步概览，捕捉了其固有的结构和关键数据点，但以下截图深入探讨了特定查询的结果，展示了可以从这些日志中提取和分析的信息类型：

图 4.16 – 活动日志（续...）

图 4.16 – 活动日志（续...）

调查人员可以将日志导出为他们选择的日志格式（例如 JSON、CSV 等），并分析任何异常活动——例如，哪些帐户修改了您的 Azure 资源（包括存储资源），以及发生了哪些操作。活动日志包含所有活动，因此可以捕捉到所有已启用和/或更新的新功能或能力。

Azure 监控

Azure 监控是 Azure 提供的全面监控解决方案，允许组织收集、分析并根据来自各种 Azure 资源（包括 Azure 存储和 Azure Blob）的遥测数据采取行动。它提供了有关这些资源的性能、可用性和健康状况的洞察，帮助组织获得可见性并做出明智的决策。

事件响应者可以利用 Azure 监视器产生的数据进行法医调查。例如，在 Azure 存储的背景下，事件响应者可以使用 Azure 监视器绘制 Azure 存储帐户或 Blob 的出口（外发）数据。事件响应者可以利用出口数据可视化来缩小外发数据的异常峰值——也就是在某个时间点，组织的云存储中有异常量的数据流出。这对于涉及数据外泄的安全事件尤为有用，因为它不仅能帮助事件响应者缩小感兴趣的日期/时间范围，还能了解可能被恶意行为者窃取的数据量。以下屏幕截图展示了 Azure 监视器如何用于可视化和绘制 30 天内的出口数据：

图 4.17 – Azure 监视器的出口数据可视化

图 4.17 – Azure 监视器的出口数据可视化

与我们之前讨论的虚拟网络日志类似，组织的资源日志（包括存储帐户和存储 Blob）也必须连接到 Azure 日志分析工作区，以启用 Azure 监视器日志的功能，并对这些数据执行查询。我们之前已将 VPC 日志连接到流量分析工作区，这意味着将 VPC 网络数据发送到后端的日志分析工作区，以便读取和写入流量日志。以下是来自微软 Azure 门户的屏幕截图，展示如何启用所有与存储相关的资源的日志分析：

图 4.18 – 开始使用日志分析

图 4.18 – 开始使用日志分析

以下屏幕截图展示了如何将 Azure 存储帐户（及其资源）连接到日志分析工作区。在左侧窗格中，导航到 诊断设置，以启用将日志发送到日志分析：

图 4.19 – 将日志分析连接到存储资源

图 4.19 – 将日志分析连接到存储资源

接下来，你应该能看到所有与你的存储帐户相关的资源。要启用日志分析，点击存储帐户或任何其他资源：

图 4.20 – 将日志分析连接到存储资源（续…)

图 4.20 – 将日志分析连接到存储资源（续…）

过渡到下一个屏幕截图，我们将聚焦于连接日志分析的具体过程，这次特别关注某个存储帐户的诊断设置：

图 4.21 – 将日志分析连接到存储资源（续…)

图 4.21 – 将日志分析连接到存储资源（续…）

最后，以下屏幕截图详细展示了这些诊断设置，突出显示了用户可以利用和配置的细节和参数：

图 4.22 – 将 Log Analytics 连接到存储资源（续…)

图 4.22 – 将 Log Analytics 连接到存储资源（续…）

类似的过程可以应用于 Azure Blob 级别，将所有读/写/删除和事务日志发送到 Log Analytics 工作区：

图 4.23 – 将 Log Analytics 连接到存储资源（续…)

图 4.23 – 将 Log Analytics 连接到存储资源（续…）

最终的诊断设置面板应如下所示，诊断状态设置为启用：

图 4.24 – 将 Log Analytics 连接到存储资源（续…)

图 4.24 – 将 Log Analytics 连接到存储资源（续…）

事件响应者现在可以使用监视下的日志功能查询 Azure 存储日志，这将打开 Azure 中的查询面板。请参见以下示例查询，以获取 Azure 存储帐户中所有 Blob 的操作：

StorageBlobLogs
| where TimeGenerated > ago(7d)
| project TimeGenerated, OperationName, AuthenticationType, Uri, _ResourceId, CallerIpAddress

上述查询可以用来显示存储帐户表（即AzureMetrics和StorageBlobLogs）中的其他列/字段，并缩小到感兴趣的事件（即匿名登录、感兴趣的操作等）。以下屏幕截图展示了所有存储帐户 Blob 活动的查询结果：

图 4.25 – Blob 存储活动的查询结果

图 4.25 – Blob 存储活动的查询结果

现在我们已经理解了 Azure 存储的细微差别以及查询 Blob 存储活动的复杂性，可以清楚地看到，Azure 在数据管理和分析方面的能力是巨大的。接下来，我们将深入探讨 Azure 基础架构的另一个重要组成部分：Azure 虚拟机。这不仅与存储解决方案相辅相成，还通过为各种工作负载提供动态计算资源来增强它们。

Azure 虚拟机日志分析

我们在第三章中讨论了 Azure 虚拟机。在 Azure 中，虚拟机广泛用于部署和运行各种应用程序和服务。为了确保这些虚拟机的安全性和稳定性，事件响应者和管理员必须分析虚拟机生成的日志。这些日志提供了关于系统活动、性能、安全事件和潜在漏洞的宝贵见解。在本节中，我们将探讨 Azure 中不同的日志源，事件响应者可以分析这些日志以进行有效的虚拟机日志分析。

  • Azure Log Analytics：Azure Log Analytics 是一个强大的工具，用于集中来自不同来源的日志数据，包括 Azure 虚拟机。它提供了一个全面的日志管理解决方案，并提供先进的查询和可视化功能。通过将 Azure 虚拟机与 Log Analytics 集成，事件响应人员可以以统一的方式收集和分析来自多个虚拟机的日志。收集的日志可以包括性能数据、系统事件、安全事件和自定义应用程序日志。事件响应人员可以通过利用其强大的查询功能（使用 KQL）来使用 Log Analytics。通过构建针对虚拟机的 KQL 查询，事件响应人员可以搜索通过 Azure Monitor 收集的日志和遥测数据，识别潜在的妥协指标（IoC），例如可疑的 IP 地址、不寻常的网络流量模式或与已知威胁相关的特定事件日志。这些查询可以定制以筛选和关联相关的数据源，从而实现主动的威胁狩猎和快速识别 Azure 环境中的被攻破系统或恶意活动。

  • Windows 事件日志：在 Windows 操作系统上运行的 Azure 虚拟机会生成 Windows 事件日志，这些日志捕捉到重要的系统事件和错误。事件响应人员可以分析这些日志，识别系统崩溃、应用程序故障、登录尝试以及其他关键事件。Windows 事件日志被分为不同的事件日志通道，如系统、安全、应用程序等，这使得过滤和分析特定类型的事件变得更加容易。

  • Azure 活动日志：Azure 活动日志提供了对 Azure 资源（包括虚拟机）上执行的操作的审计跟踪。这些日志捕捉有关资源创建、更新和删除的信息，以及用户和 Azure 服务执行的管理操作。事件响应人员可以利用 Azure 活动日志跟踪虚拟机配置的变更，识别潜在的配置错误，并调查可疑活动。

  • Azure Monitor：Azure Monitor 也可以用来捕捉虚拟机的性能指标、诊断日志甚至自定义应用程序日志。事件响应人员可以利用 Azure Monitor 可视化虚拟机中的异常情况，如异常的 CPU 使用率或磁盘带宽，这可能表明有未经授权的访问。Azure Monitor 还与Azure Kubernetes 服务（AKS）集成，提供对任何 AKS 容器的监控和日志记录功能。在创建 AKS 集群时，或者将其添加到现有集群时，你可以启用监控。此外，Azure Monitor 还将其功能扩展到 Azure 中的无服务器计算资源，如 Azure Functions 和 Azure Logic Apps。通过利用 Azure Monitor 的一个功能——应用程序洞察，事件响应人员可以深入了解无服务器组件。

  • Windows Defender 日志：对于运行 Windows Defender 的虚拟机，事件响应人员可以分析由该防病毒软件生成的日志。这些日志包含有关已检测威胁、被拦截的恶意软件以及其他安全相关事件的信息。通过分析 Windows Defender 日志，响应人员可以识别潜在的安全漏洞，调查恶意软件感染，并采取适当的措施来降低风险。Windows Defender 是端点级别的安全防病毒工具（即安装在虚拟机上的）。

  • Azure Linux 虚拟机与 Linux 日志：对于 Microsoft Azure 上的 Linux 基础虚拟机，事件响应人员可以分析由系统的 syslog 服务和 Microsoft 安全工具生成的日志。事件响应人员可以利用 Azure 与 Linux 虚拟机的集成，获取通过 syslog 提供的系统事件，如系统警报、错误、用户登录活动以及其他系统级消息。这些日志对于追踪系统异常、安全事件和潜在的未授权访问至关重要。除了基本的 syslog 功能外，Azure 还提供与其安全工具套件的集成，如 Microsoft Defender，这可以用来增强 Linux 虚拟机的安全监控。Microsoft Defender 提供了先进的威胁防护功能，能够检测并分析 Linux 资源的潜在威胁和漏洞。

探索了 Azure 虚拟机上可用的各种日志来源，从 Azure 日志分析到 Windows Defender 日志，可以明显看出，Azure 提供了全面的工具，帮助事件响应人员跟踪和分析虚拟机活动。在这个基础上，我们可以将重点转向 Azure 生态系统中的一个更加集成的安全解决方案：Microsoft Defender for Cloud。这个解决方案协同利用这些日志，提供全面的安全洞察和主动的威胁防护。

Microsoft Defender for Cloud

Microsoft Defender for Cloud（前身为 Azure 安全中心）为 Azure 资源提供先进的威胁检测和安全监控，包括虚拟机。它分析与安全相关的事件，进行行为分析，并提供安全建议。事件响应人员可以利用 Microsoft Defender for Cloud 来识别潜在的安全漏洞、调查安全事件，并有效应对威胁。以下截图展示了 Microsoft Defender for Cloud 报告的安全警报示例。在这个示例中，我们可以看到 Mimikatz 的凭证窃取工具在虚拟机资源中被检测到。事件响应人员可以在更大范围的调查中利用这些警报，确定恶意行为者使用的攻击战术：

图 4.26 – Microsoft Defender for Cloud 警报

图 4.26 – Microsoft Defender for Cloud 警报

Microsoft Defender for Cloud 还提供基于持续监控的配置建议，这可以帮助事件响应人员识别任何未解决的安全漏洞。以下截图展示了 Microsoft Defender for Cloud 中 建议 面板的示例：

图 4.27 – Microsoft Defender for Cloud – 建议

图 4.27 – Microsoft Defender for Cloud – 建议

虽然 Microsoft Defender for Cloud 提供了全面的监控和安全建议，但 Azure 也提供了用于深入分析虚拟机网络流量的工具。最有价值的工具之一就是 NSG 流日志。这个功能为管理员提供了对网络活动的详细洞察，补充了 Microsoft Defender for Cloud 提供的保护。

NSG 流日志

NSG 流日志捕获了通过与 Azure 虚拟机关联的 NSG 的网络流量信息。这些日志提供了有关允许和拒绝的网络连接的洞察，包括源和目标 IP 地址、端口和协议。事件响应人员可以分析 NSG 流日志，检测可疑的网络活动，识别潜在的攻击，并有效地执行网络安全策略。我们在本章前面已经讨论过 NSG 流日志。

重要提示

Azure 中的虚拟网络、存储和虚拟机等产品和服务通过 Azure Log Analytics、Azure Monitor 和 Azure 活动等服务共享共同的监控和日志记录功能。这些服务为在 Azure 中部署的资源提供了有关健康状况、性能和活动的全面洞察。

无论您是在监控虚拟网络、存储还是虚拟机，基本的方法都是类似的。Azure Log Analytics 允许您收集、集中和分析来自不同来源的日志和度量数据。Azure Monitor 提供了统一的监控体验，提供警报、仪表板和可视化功能，以便实时洞察资源的性能和可用性。Azure 活动日志捕获订阅级别的事件和操作，用于审计和追踪。

经过对 Azure 虚拟机日志信息的深入分析，特别是对 Microsoft Defender for Cloud 和 NSG 流日志功能的探讨，显然 Azure 提供了强大的安全性和流量分析工具。然而，Azure 的工具包并不止于此。在接下来的部分中，我们将探讨 Microsoft Sentinel 的全面威胁情报功能。

Microsoft Sentinel

Microsoft Sentinel 是 Azure 提供的强大云原生 SIEM 解决方案。它通过实时收集、分析和可视化来自不同来源的大量安全数据，帮助组织检测、调查和应对安全威胁。

SIEM 是一个全面的软件解决方案，结合了 安全信息管理 (SIM) 和 安全事件管理 (SEM) 功能。它作为一个中央集成平台，用于获取和关联来自不同来源的日志和事件，提供组织安全状况的统一视图。

在安全事件发生期间，事件响应人员可以利用 Microsoft Sentinel 的高级功能有效响应并减轻威胁。以下是事件响应人员可以利用 Microsoft Sentinel 的具体方式：

  • 日志收集与集成：Microsoft Sentinel 支持从多种来源获取数据，包括 Azure 服务、本地基础设施、安全解决方案和第三方工具。事件响应人员可以配置数据连接器来收集日志和事件，确保整个环境的全面可视化。

  • 威胁检测和分析：Microsoft Sentinel 运用机器学习算法和先进的分析技术来检测和优先处理潜在的安全威胁。其内置的分析模板和检测规则有助于识别可疑活动、异常行为或已知的攻击模式。事件响应人员可以利用这些功能识别IoC（入侵指示器）并检测新兴威胁。

  • 实时监控和警报：Microsoft Sentinel 提供安全事件的实时监控，并根据预定义的规则和分析生成警报。事件响应人员可以配置警报规则，当发生表明安全事件的特定条件或行为时触发通知。这些警报可以自定义，以优先处理关键事件，并与其他事件响应系统集成。

  • 调查与猎杀：Microsoft Sentinel 提供强大的搜索和查询功能，以便彻底调查安全事件。事件响应人员可以查询和探索大量数据，基于不同的属性过滤结果，并在不同数据维度之间切换。Sentinel 的交互式工作空间允许响应人员可视化和关联数据，从而实现深入调查和主动的威胁猎杀。

  • 自动响应与编排：Microsoft Sentinel 提供预定义的自动化工作流程——剧本，以便于事件响应操作。事件响应人员可以创建剧本来自动化重复的手动任务，例如通过附加上下文信息丰富警报、屏蔽可疑的 IP 地址或隔离受损资产。此功能有助于简化事件响应流程并缩短响应时间。

  • 与安全解决方案的集成：Microsoft Sentinel 无缝集成了各种 Microsoft 安全解决方案和第三方工具。事件响应人员可以利用这些集成来丰富调查、收集额外的上下文信息，并在安全生态系统中协调响应行动，提供统一且协调的事件响应方法。

以下截图显示了启用警报并连接数据的 Microsoft Sentinel：

图 4.28 – Microsoft Sentinel – 事件

图 4.28 – Microsoft Sentinel – 事件

Microsoft Sentinel 并不会自动为客户启用；它需要手动设置和配置。组织必须主动选择在其 Azure 环境中实施和配置 Microsoft Sentinel，才能利用其安全分析和威胁情报功能。随着我们对 Microsoft Sentinel 探索的结束，可以明显看出，其先进的威胁情报和安全分析能力在强化 Azure 云生态系统中发挥着至关重要的作用。通过将 Microsoft Sentinel 用作 SIEM，安全分析师和事件响应人员可以充分利用 Sentinel 的潜力，在不断变化的威胁环境中保护其数字环境。

概述

本章深入探讨了日志分析在 Azure 环境中事件响应中的关键作用。强调了理解 Azure 中可用日志来源、如何获取这些日志以及分析数据的最佳实践，以便有效地检测、遏制和解决安全事件的重要性。通过让事件响应专业人员熟悉特定于 Azure 的工具和技术，他们可以增强在云基础设施环境中保护和响应安全事件的能力。

本章强调了区分默认日志可用性与需要启用某些日志之间的重要性，并与 AWS 进行了类比。然后，概述了 Azure 重要服务和产品提供的各种日志，如在第三章中讨论过的，并检查了它们在调查过程中的使用。特别是，本章探讨了 Azure 日志分析、Azure 虚拟网络流日志、Azure 存储、Azure 虚拟机以及其他 Azure 工具，如 Microsoft Sentinel，作为事件响应的重要数据来源。

在下一章中，我们将把注意力转向谷歌云平台（GCP），并探索在事件期间可以启用和使用的各种日志来源。

进一步阅读

若想了解更多本章所涉及的主题，请查看以下资源：

第六章：DFIR 调查 – GCP 中的日志

你一定已经注意到每个云服务提供商的常见资源和元素了。在本章中，我们将深入探讨Google Cloud Platform（GCP）的安全功能、可用的日志来源以及如何进行调查。请注意，云服务提供商可能使用相似的术语，但日志的应用和可用性在每个云服务提供商之间可能有所不同。因此，了解在事件调查过程中哪些日志是可用的是至关重要的。

在第三章中，我们简要介绍了 GCP 中的一些特定云服务；在本章中，我们将深入探讨其一些核心组件和数字取证。本章概述了第三章中讨论的部分关键 GCP 服务和产品的日志，并探讨在调查过程中如何利用这些日志来源。

本章我们将讨论以下主题：

  • GCP 核心服务

  • GCP 身份与访问管理

  • 策略分析器

  • GCP 日志资源浏览器

  • VPC 流日志

  • 数据包镜像

  • 计算引擎日志

  • 日志数据流管道

  • GCP 存储日志

  • 云安全指挥中心

  • GCP Cloud Shell

我们将在第七章中讨论 Google Workspace，以及 Microsoft 365（M365），因为它们与电子邮件和云托管的协作服务相关。

GCP 核心服务

GCP 是 Google 提供的一套云计算服务，提供一系列工具和服务，用于在云端构建、部署和管理应用程序和基础设施。它提供类似于其他云服务提供商（如 AWS 和 Microsoft Azure）的服务。

这里是 GCP 的一些关键服务：

  • 计算服务：GCP 提供几种计算选项，包括Google Compute Engine（GCE）（虚拟机[VM]）、Google Kubernetes Engine（GKE）（托管 Kubernetes）和App Engine（应用程序的托管平台）

  • 存储服务：GCP 提供多种存储选项，如Google Cloud Storage（GCS）（对象存储）、Cloud SQL（关系型数据库服务）、Cloud Bigtable（NoSQL 数据库）和Cloud Firestore（文档数据库）

  • 网络：GCP 提供网络服务，如用于创建私有网络的虚拟私有云（VPC）、用于分配流量的Cloud Load Balancing和用于内容传输的Cloud CDN

  • 大数据和机器学习：GCP 包括诸如BigQuery（无服务器数据仓库）、Cloud Dataflow（数据处理）、Cloud Pub/Sub（消息传递与事件流）和Cloud Machine Learning Engine（托管机器学习）等服务

  • 身份与访问管理（IAM）：IAM 允许你管理对 GCP 资源和服务的访问，定义用户和组的角色与权限

  • 管理和监控：GCP 提供管理和监控资源的工具，如 Cloud Console（基于 web 的管理界面）、Cloud Logging（集中式日志管理）、Cloud Monitoring（性能和健康监控）和 Cloud Trace（请求延迟分析）。

  • 安全与合规性：GCP 融入了各种安全特性，包括静态和传输加密、IAM 角色和政策、VPC 服务控制以及合规认证，以满足行业标准。

  • 开发者工具：GCP 提供如 Cloud SDK（命令行工具）、Cloud Build（持续集成和交付）和 Cloud Source Repositories（版本控制系统）等开发者工具。

  • AI 和 ML 服务：GCP 提供通过如 Cloud Vision API、Cloud Natural Language API 和 Cloud Translation API 等服务预训练的 AI 模型和 API，使开发者能够将 AI 功能集成到他们的应用程序中。

  • 无服务器计算：GCP 提供无服务器服务，如 Cloud Functions（事件驱动函数）、Cloud Run（无服务器容器）和 Cloud Scheduler（定时任务调度器）。

现在我们已经了解了 GCP 提供的核心服务，可以深入探讨一些调查人员可能感兴趣的特定服务。重点将放在 GCP 的特定服务上，这些服务构成了任何调查的基础，包括身份、来自计算引擎的日志等。我们将从 GCP 的 IAM 控制台开始，它是让用户访问 GCP 资源的核心。

GCP IAM

IAM 提供了一个框架，通过定义身份、角色和相应资源之间的关系来控制 GCP 范围内的资源访问。在这个系统中，资源的概念扩展到包括广泛的实体，如 GCE 虚拟机实例、GKE 集群、Cloud Storage 存储桶，以及由组织、文件夹和项目组成的组织结构。

IAM 基于一个原则：不直接授予最终用户访问权限；相反，权限被组织成角色，并将这些角色分配给经过身份验证的主体或成员（如 Google 帐号、服务帐号、Google 群组、经过身份验证的用户、云身份域等）。

IAM 功能的核心是允许策略，或称IAM 策略，它作为指定和强制分配角色给主体的机制。每个允许策略都与特定资源关联。当经过身份验证的主体尝试访问某个资源时，IAM 会检查关联的允许策略，从而根据其规定确定预定操作的可行性。虽然允许策略让你设置准则以允许访问特定资源，GCP 还允许你设置拒绝策略，指定哪些用户或角色无法访问。拒绝策略让你根据特定条件设置拒绝规则，来决定资源的可行性。拒绝策略的示例包括限制定义新 API 密钥或删除或编辑 GCE 资源或配置的权限。

通过在 GCP 生态系统中采用 IAM，组织可以对访问权限进行精细控制，确保身份只被分配与指定资源交互所需的角色。这种访问管理方法可以增强安全性，并有效地管理 GCP 环境的治理。

GCP 的 IAM 角色和身份

从事件响应和取证的角度来看，了解云服务提供商如何组织和分配身份及其权限是至关重要的。需要注意的是，每个云服务提供商处理身份的方式通常不同。

对于 GCP，最终用户不会直接获得权限。相反，权限会被分配给角色。你可以把角色想象成一组权限，授予对 GCP 环境中各种服务的访问权限。需要访问这些资源的用户或 API 服务被 GCP 称为主体。因此，权限被分配给角色，角色附加到主体。策略是角色的集合，可以附加到一个或多个主体。

以下图示总结了如何通过 GCP 的 IAM 模块定义、分配、强制执行并最终管理 IAM 策略：

图 6.1 – GCP 的 IAM 强制执行架构

图 6.1 – GCP 的 IAM 强制执行架构

前面的图示仅展示了如何将权限分配给每个 GCP 资源的通用版本，GCP 还提供了与活动目录的联合集成功能来管理对 GCP 资源的访问。然而，这使用了类似的概念来强制执行 IAM 策略。你可以创建精细的允许和拒绝策略来强制执行特定的资源元素。例如，你可以允许访问 GCE 中的某个实例，同时限制对其他实例的访问。

策略分析器

考虑到 IAM 分配是通过角色实现的，其中主体通过角色将访问权限分配给资源，GCP 提供了额外的工具来排查和调查 IAM 策略配置。策略分析器允许 DFIR 团队分析分配给用户或角色的过度权限，这些权限可能导致滥用。策略分析器还可以确定用户是否具有执行特定操作所需的权限，例如删除表、GCE 资源等。

以下是策略分析器输出的示例。我们可以在查询结果中看到为某个用户配置的 GCP 资源的角色和权限。请注意，资源分配给项目，且 GCP 将其标记为资源：

图 6.2 – 策略分析器查询结果及每个角色的权限列表

图 6.2 – 策略分析器查询结果及每个角色的权限列表

DFIR 使用案例：策略分析器

在 GCP 的 DFIR 环境中使用策略分析器可以帮助组织评估各种 GCP 资源的合规性和安全性。以下是 GCP 策略分析器的一些使用案例：

  • IAM 策略：分析 IAM 策略包括评估分配给用户、服务账户和组的角色，识别潜在的配置错误或权限过度的访问。

  • 网络安全策略：审查防火墙、网络配置和路由策略，以确保适当的网络分段、可靠的连接性，并保护防止未经授权的访问。

  • 数据加密和密钥管理策略：验证是否对静态和传输中的敏感信息实施数据加密策略。这包括评估加密密钥的使用、密钥轮换实践及加密标准的合规性。

  • 日志记录和监控策略：评估日志配置和监控实践，确保生成并保留适当的日志，并确保日志分析工具正确配置，以检测安全事件和异常活动。

  • 服务账户和 API 访问策略：验证服务账户和 API 访问配置的安全性。这包括评估授予服务账户的权限，审计服务账户的使用，并确保适当管理和撤销 API 访问凭证。

如您所见，GCP 策略分析器有助于识别策略违规和不合规资源。然而，它并不提供因策略偏差而执行的活动信息；我们需要日志浏览器来识别具体的执行动作。我们将查看 GCP 日志浏览器，它采集并托管详细日志，具有高级过滤选项和实时日志流功能，使其成为任何调查人员必备的工具。

GCP 日志浏览器

GCP 设计了日志浏览器，通过查看日志来排查应用程序和系统的性能问题。日志浏览器的用户界面包含一个直方图，显示日志速率及相关的峰值。然而，只要有日志，你总是可以利用它们来调查事件。Google 还提供了日志浏览器 API，允许通过 Python 程序或其他方式通过 API 密钥进行自动化或查询日志。以下截图展示了 GCP 日志浏览器中的直方图，突出显示了按时间划分的活动：

图 6.3 – GCP 日志浏览器直方图

图 6.3 – GCP 日志浏览器直方图

然而，日志浏览器仅按时间段显示日志；它不会量化或将日志与系统内的其他活动相关联。你可以设置你希望查看日志的时间范围，默认的日志保留期限为 30 天。为此，GCP 提供了日志分析，这是一项独立的服务，允许对日志进行实时分析，以便进行日志聚合和日志量化。这是一项独立的服务，需要显式地升级你的日志存储桶，以便 GCP 执行日志分析。GCP 日志分析使用户能够在日志上使用BigQuery。BigQuery 是一个数据仓库，用户可以在其上对大规模数据集进行查询并执行分析。GCP 将 BigQuery 作为一项独立的服务提供，默认情况下不可用。例如，你可以运行 BigQuery 来查询你的日志，查找已知的恶意域名，来源于威胁情报源。

为了让 DFIR 团队访问日志浏览器，团队必须被分配以下角色：

  • roles/logging.viewer：用于查看_Required 和 _Default 存储桶下的所有日志。

  • roles/logging.privateLogViewer：用于查看所有日志，包括数据访问日志。

  • roles/logging.viewAccessor：基于条件的日志查看权限，允许访问用户定义的日志。如果没有指定条件，则此角色允许访问用户定义的存储桶中的日志。

  • Roles/logging.fieldAccessor：用于查看日志条目存储桶中的受限字段。你需要配置字段级访问。

日志存储桶概览

每当资源生成日志时，它都会被云日志基础设施所接收，该基础设施确定日志存储的条件和准则，称为日志接收器。日志接收器是 GCP 日志基础设施的一部分，负责确定如何将日志路由到相关的日志存储桶。GCP 还允许你通过 Pub/Sub 主题将这些日志导出到第三方日志聚合工具，帮助第三方日志聚合工具订阅 Pub/Sub 来授权和导入日志。

GCP 提供了两个预定义的日志存储桶，分别是_Required和_Default。这些存储桶相互独立，并作为每个 GCP 账户的默认日志存储目标。用户/管理员还可以创建自己的日志存储桶，这些存储桶被归类为用户定义的存储桶。当日志条目被传送到日志基础设施时，日志路由开始执行。在此过程中，根据配置的包含和排除过滤器，日志会被路由到相应的存储桶，或者被重定向到 Pub/Sub 主题供外部使用，或者完全丢弃。日志还可以被重定向到 BigQuery 数据集，以便用户执行日志分析，进行相关性分析和进一步的分析。

如前所述，云日志条目默认会被路由到以下其中一个日志存储桶：

  • _Required：_Required 日志存储桶会收集以下类型的日志：

    • 管理员活动日志：这些日志包含用于读取资源元数据或配置的 API 调用日志条目。例如，读取 GCE 配置的 API 调用会记录在这个子类别下。

    • 系统事件日志：任何对云资源的更改，例如 GCE，都会记录在此子类别下。用户/管理员不能通过创建排除过滤器关闭此类型日志的记录；它始终会被记录。

    • 访问透明度日志：任何 Google Cloud 成员在 GCP 账户内执行的操作都会记录在此日志中。这使得可以透明地查看云服务提供商执行的任何操作——在本案例中是 Google。

  • _Default：任何不符合 _Required 存储桶条件的日志会被路由到 _Default 存储桶。以下类型的日志会自动被重定向：

    • 数据访问日志：这些日志条目包括对 GCP 资源的元数据或配置信息的 API 调用。数据访问日志通常数量庞大，默认情况下是禁用的。如果您运行 BigQuery，则会启用数据访问日志。因此，理解操作资源和是否启用日志至关重要。

    • 策略拒绝日志：顾名思义，当 GCP 根据定义的条件或策略拒绝访问某个资源时，日志条目会被归类为策略拒绝日志。策略拒绝日志默认启用，且无法禁用。不过，您可以配置排除过滤器来避免记录这些日志。

  • 用户定义的存储桶：这些是用户创建的日志存储桶，用于收集 GCP 资源生成的日志子集。您可以在任何云项目中创建用户定义的存储桶。当您创建日志存储桶时，必须指定日志存储桶将存储的区域。

DFIR 使用案例，使用日志资源管理器

以下是一些 DFIR 使用案例，利用 GCP 的本地日志资源管理器：

  • 事件调查：在事件发生期间，日志探索器使您能够在多个 GCP 服务中搜索和分析日志。您可以关联来自不同日志的事件，重建事件时间线，识别根本原因，并确定事件的影响范围。

  • 威胁狩猎：日志探索器允许您根据已知威胁或妥协指标（IOCs）的特定标准或模式查询和过滤日志。通过分析来自 GCP 服务（如 Cloud Storage、Cloud Functions 或 Cloud Pub/Sub）的日志，您可以主动搜索可疑活动或异常行为。

  • 用户活动监控：日志探索器提供了 GCP 服务中用户活动的可见性。您可以追踪用户登录、管理操作、API 调用和资源访问，以识别未经授权或可疑的行为。这些信息有助于检测内部威胁或被妥协的用户账户。

  • 数据泄漏和暴露检测：日志探索器可以用于识别潜在的数据泄漏或外泄尝试。通过分析来自相关服务（如 Cloud Storage 或 BigQuery）的日志，您可以搜索到表明未经授权的数据访问、大规模数据传输或异常数据外泄的模式。

  • 取证分析：日志探索器可以在取证调查中作为宝贵的证据来源。通过查询和分析日志，您可以重建事件，识别攻击者的行为，或追踪对手在 GCP 环境中的活动。

熟悉日志探索器

我们来看一个查询日志探索器的示例。日志探索器拥有方便的功能，允许调查人员点击并过滤相关的证据。让我们熟悉一下日志探索器的多个区域：

图 6.4 – 日志探索器概览

图 6.4 – 日志探索器概览

如我们在日志探索器仪表板中看到的，几个关键元素对于安全团队来说非常有帮助。我们已经为您标注了数字，方便参考：

  1. 日期/时间过滤器：这使得团队能够锁定特定时间范围内可能发生的事件和活动。

  2. 查询面板：这个文本栏允许团队手动搜索查询。请注意，当您点击并更新过滤器时，搜索查询词会自动更新。

  3. 查询过滤字段：这使得团队可以过滤特定的 GCP 资源、对象或日志及日志类型。请注意，在此示例中，我们过滤了与 VM 实例相关的记录，且严重性标为错误。

  4. 日志字段面板：此视图为用户提供了更细致的视角，展示每种日志过滤器类型或严重性评级下的事件数量。如前所述，每条记录在被路由到相关的日志存储目的地之前都会进行分类。

  5. 查询结果窗格：此视图允许用户更深入地查看日志。每个条目都允许用户展开并查看日志条目中的所有字段，并根据调查线索进行额外的过滤。

我们接下来的部分将通过 Logs Explorer 进行一个示例调查，但首先，让我们先看一下 VPC 流量日志。

VPC 流量日志

与 AWS 类似，GCE 默认没有启用 VPC 流量日志。启用 VPC 流量日志相对简单，所需的工作量也很小。需要注意的是，VPC 流量日志按分钟汇总，并在一个包含相关信息的仪表盘中显示。VPC 流量日志在子网级别启用，这意味着每个流量日志都与 GCE 所在的子网相关联。这通常指的是 GCP 的内部子网架构。为一个繁忙的服务器启用 VPC 流量日志可能会生成大量日志，从而影响成本。

启用 VPC 流量日志

要分析流量，首先必须在 GCE 中启用 VPC 流量日志。由于 GCE 默认创建时，区域 VPC 作为虚拟服务器访问互联网或其他 GCP 资源的网络网关。如果创建了自定义 VPC 节点，必须确保启用 VPC 流量日志选项，才能将日志发送到 Logs Explorer。我们将查看其中一个 GCE 的网络详情示例。

与 AWS 类似，VPC 流量日志并不会自动启用，需要手动激活。GCP 提供了一系列可定制的网络设置，包括创建子网、设定防火墙规则和设置 VPC 连接的功能。下图显示了为某个区域配置的 VPC 网络，其中包含名为 test-lab1 的自定义 VPC 网络：

图 6.5 – GCE 的网络子网详情

图 6.5 – GCE 的网络子网详情

VPC 流量日志是子网特定的；因此，启用 VPC 流量日志时，必须对 VPC 子网进行更改，并允许收集流量日志。如果 GCE 实例连接了多个 VPC，你必须逐一验证并启用每个 VPC 子网，以便收集流量日志。在下图中，我们查看了名为 test-lab1 的自定义 VPC 和名为 subnet-lab1 的 VPC 子网：

图 6.6 – VPC 子网信息

图 6.6 – VPC 子网信息

点击并编辑子网名称，选择开启或关闭 FLOW LOGS 的选项。启用后，指定网络数据包的聚合频率。请记住，VPC 流量日志只收集头信息，而不包括完整的数据包详情。因此，必须权衡聚合频率，并确定最合适的聚合时间间隔。数据包聚合可以在 5 秒、30 秒、1 分钟、5 分钟、10 分钟和 15 分钟的间隔内进行。

假设 GCP 资源在一天之内产生大量网络流量；在这种情况下，可以设置更高频率的流日志聚合，以便获得更细粒度的网络流量可见性。低频率流日志聚合适用于那些没有大量网络流量活动的情况。下图展示了设置流日志的选项：

图 6.7 – 在 VPC 子网下启用 VPC 流日志

图 6.7 – 在 VPC 子网下启用 VPC 流日志

在设置流日志时，选择将被聚合到流日志并报告到 Logs Explorer 的数据包采样率，理想情况下设置为 100%。这意味着 100% 的观察到的流量将发送到 Logs Explorer，而不是缩小为特定比例的流量活动。下图展示了子网配置，采样率为 100% 的观察到的网络流量，聚合间隔为 5 秒：

图 6.8 – 流日志网络聚合配置

图 6.8 – 流日志网络聚合配置

一旦 VPC 配置完成，流日志会自动发送到 Logs Explorer，调查员可以开始进行威胁狩猎。接下来的部分将展示一个使用 Logs Explorer 和狩猎 VPC 流日志以发现恶意活动的示例用例。

狩猎 VPC 流日志中的恶意活动

在这个场景中，我们有一个名为 app-data1 的 GCP Cloud Storage 存储桶，其中包含一些对组织至关重要的备份。基础设施设置使得任何内部 GCP 资源或应用程序都可以访问 GCP Cloud Storage，但不会对用户或互联网上的其他人公开。下图显示了存储在 app-data1 存储桶中的 Cloud Storage 对象列表：

图 6.9 – Cloud Storage 视图

图 6.9 – Cloud Storage 视图

我们有一个威胁行为者，他正在使用 GCE 虚拟机 cf1-ta-vm（内部 IP 地址为 10.0.0.15，外部 IP 为 34.152.3.1）从 Cloud Storage 中抓取这些文件，并最终将数据外泄到一个由威胁行为者控制的远程服务器，IP 地址为 3.98.136.11。

现在我们将使用 Logs Explorer 来追踪与此 GCE 资源相关的威胁行为者活动：

  1. 作为第一步，我们首先选择 Logs Explorer 仪表板中的合适事件时间，以捕捉最相关的事件。

  2. 然后，我们查看与该文件上传到 GCS 存储桶时关联的日志条目。调查员必须注意 methodName 属性中的 storage.objects.create 值，表示该对象是在特定存储桶中创建的。下图展示了上传到存储桶时创建的日志记录，以及在 resourceName 属性中识别的完整文件路径：

图 6.10 – 上传到 GCS 存储桶的对象日志条目

图 6.10 – 上传到 GCS 存储桶的对象日志条目

  1. 下一步是查找任何访问该资源的 GCE 虚拟机。使用日志字段面板（如 图 6.4 所示），我们将过滤与调查目的相关的日志。当日志被过滤时，src_ip（源 IP）、dest_ip（目标 IP）和 bytes_sent（发送字节）将在日志条目摘要中进行可视化。右键点击并访问这些选项进行字段标记。请注意，以下图示演示了如何为更方便的可视化和调查标记关键字段：

图 6.11 – 日志浏览器字段过滤器

图 6.11 – 日志浏览器字段过滤器

  1. 一旦应用了相关的过滤器以支持调查，我们可以在日志浏览器中查看日志条目，并识别威胁行为者的活动。从日志浏览器视图中，我们可以看到威胁行为者首先将文件从 GCS 复制到带有 cf1-ta-vm 主机名和关联 IP 地址（10.0.0.15）的 GCE 虚拟机。由于该传输发生在 GCP 的基础设施内，传输是通过 GCP 的后端网络基础设施进行的。请注意以下片段中的发送字节大小，标签顺序为 src_ip、dest_ip 和 bytes_sent：

图 6.12 – GCS 数据传输到 GCE 的查询结果

图 6.12 – GCS 数据传输到 GCE 的查询结果

  1. 综合分析后，我们确定 GCS 存储对象被复制到本地 GCE 主机。现在，我们将目标 IP 地址进行反转，检查该 GCE 主机是否负责出站连接。我们以 10.0.0.15 作为源 IP 地址应用过滤器，并立即看到与远程服务器的出站连接，以及 bytes_sent 值，我们将其归因于威胁行为者控制的服务器。

图 6.13 – 日志浏览器寻找出站连接

图 6.13 – 日志浏览器寻找出站连接

正如我们通过一系列步骤所展示的，调查人员可以通过交互式过滤功能和点击过滤器，提取归因于威胁行为者活动的相关事件日志。始终可以选择提取所有日志，进行离线分析，并进一步切分以确定威胁行为者执行的特定操作。然而，命令行条目的提取有多种方式。调查团队可以使用这些信息获取 GCE 的完整快照。我们将在 第十章 中探讨这一机制。

注

日志浏览器在记录 GCE 中输入的命令方面有一定限制；用户或威胁行为者输入的任何命令都不会被记录在日志浏览器中。

扩展网络监控功能，我们来深入探讨 GCP 的数据包镜像（Packet Mirroring）功能，它补充了 VPC 流日志提供的见解。

数据包镜像

GCP 的数据包镜像功能允许安全团队收集虚拟机（VM）上的网络数据包，并识别与这些虚拟机关联的安全威胁或活动。GCP 的包镜像仅镜像虚拟机与外部接口之间的流量，不会镜像集群节点之间的流量，如 GKE。在第十一章中，我们将深入了解容器，包括Docker和Kubernetes。

要进行数据包镜像，请确保主体附加了compute.packetMirrorUser和compute.packetMirroringAdmin角色。

内部负载均衡器必须部署具有网络通透功能的能力，将流量传递到收集器实例以启用数据包镜像。负载均衡器必须指向后端的托管实例组，该组具有预先配置的实例模板，允许 GCP 自动创建收集器实例。收集器实例可以是通过内部负载均衡器捕获和接收网络数据包的虚拟机。

设置内部负载均衡器时，请确保其创建在与被镜像实例相同的区域内，，并且后端子集未启用。同时，在配置负载均衡器时，请确保在负载均衡器上创建数据包转发规则，以便转发所有被镜像的数据包。此设置一旦配置完成无法更改。

创建内部负载均衡器时，必须创建一个托管实例组，并为该组分配虚拟机。GCP 将把该虚拟机确定为包镜像和捕获的收集器实例的一部分。

下图演示了一个内部网络负载均衡器的简单配置。我们创建了一个示例负载均衡器lb2，并将其配置在test-lab1 VPC 下的subnet-lab1子网中。我们还创建了一个托管实例组instance-group1，该组会自动创建收集网络数据包的收集器虚拟机：

图 6.14 – 内部负载均衡器配置

图 6.14 – 内部负载均衡器配置

创建负载均衡器后，配置数据包镜像策略并指定数据包捕获源的目标 VPC 和子网。或者，选择一个可疑的 GCE 作为网络数据包的收集源。请注意，目标 VPC 和收集器实例必须创建在同一网络区域内，才能成功镜像数据包。

在下图中，我们配置了数据包镜像策略（pkt-mirror1），该策略定义了收集器虚拟机或 VPC 网络（此处为test-lab1）以及将附加到策略上的负载均衡器（通过转发规则lb2-forwarding-rule指定）。策略执行必须开启才能启用数据包镜像。

图 6.15 – 数据包镜像策略

图 6.15 – 数据包镜像策略

也配置了数据包镜像策略，以转发和镜像与 test-lab1 VPC 关联的数据包，嫌疑虚拟机附加到 subnet-lab1。

现在，在收集器虚拟机中，我们通过运行 tcpdump 开始收集网络数据包。在启动网络数据包捕获之前，请注意嫌疑虚拟机的 IP 地址：

$ sudo tcpdump -i INTERFACE_NAME -f "host IP_ADDRESS" -w dump.pcap

运行 tcpdump 时提供以下参数：

  • -i INTERFACE_NAME：收集器实例的网络接口名称，用于监听网络数据包（ens33、enp03 等）

  • -f "IP_ADDRESS"：根据嫌疑虚拟机特定 IP 地址应用数据包捕获的过滤标志

tcpdump 的输出也可以写入文件。在示例中，我们使用 -w 标志转储数据包，并提供文件位置。

调查人员更喜欢通过 VPC 网络捕获记录所有威胁行为的完整数据包，然后再专注于特定的 GCP 服务进行调查。

将数据包写入磁盘后，可以使用以下 GCP 命令行选项访问 GCP 存储并上传工件：

$ gcloud auth login

假设调查团队将拥有自己的身份和附加到这些身份（主体）的角色。首先，必须输入前述命令并按屏幕上的说明操作以登录。

完成后，您可以使用以下命令访问 Google Cloud Storage 并复制工件：

$ gsutil cp [SOURCE_FILE] gs://[BUCKET_NAME]/[DESTINATION_PATH]

以下是成功上传工件所需的关键参数：

  • SOURCE_FILE：团队希望调查的源工件

  • BUCKET_NAME：Google Cloud Storage 存储桶名称

  • DESTINATION_PATH：存储桶内目标文件夹路径

正如我们所见，由 GCP 提供的 VPC 流日志提供了与网络流量模式相关的大量数据，这可以显著增强安全性和故障排除工作。数据包镜像不仅增加了监视和分析网络流量的潜力，还能实时识别潜在的安全威胁。

以下部分将更详细地检查 GCE 日志，提供有关活动的深入洞察，并通过日志资源管理器实现相关性功能。

计算引擎日志

GCE 是 GCP 提供的一项服务，允许用户在 GCP 基础设施内创建虚拟机。这些虚拟机可以在 GCP 运营的任何地方托管。它提供了灵活性和可扩展性选项，提供多种预配置的虚拟机实例。它可以根据需求按需创建或调整虚拟机大小。用户可以通过 GCE 实例组管理器 创建 VM 实例或一组 VM，该管理器管理 VM 的部署和配置。

GCP 的日志平台

GCP 的 Cloud Logging 平台通过 Logs Explorer 自动收集和汇总来自各种 GCP 资源的日志。它提供一个单一视图的所有日志和过滤器，允许调查人员追踪特定的警报或威胁，并用于监控。它收集的日志类型如下：

  • 平台日志：通过 GCP 的服务生成，这些日志用于调试和故障排除。平台日志的示例包括 VPC 流量日志。

  • 组件日志：与平台日志类似，这些日志由 GCP 的基于软件的组件生成，例如 Kubernetes 集群。GKE 日志被归类为组件日志。

  • 安全日志：GCP 内收集两种类型的安全日志；第一种是Cloud Audit 日志，它提供管理员执行的管理信息和活动，支持云审计和合规性要求。第二种是Access Transparency 日志，它记录 Google 员工在 Google Cloud 租户上直接执行的任何操作，以确保透明度和合规性。

  • 用户自定义日志：顾名思义，这些日志记录任何自定义应用程序日志，可以通过 OpsAgent、Logging Agent、Cloud Logging API 和其他库发送到 Cloud Logging。我们将在本章的后面部分学习 OpsAgent。

  • 多云和混合云日志：这些日志包括来自其他云提供商（如 Microsoft Azure）和本地基础设施的日志。它们可以与 GCP 日志一起收集；然而，基于日志数量可能会有成本影响。

GCP 的默认日志

GCP 中的每个虚拟机都预先配置为将默认日志发送到Cloud Logging 平台。这些日志包括 CPU 使用率、内存使用率、网络带宽消耗等。尽管收集的遥测数据是基础性的，但它在确定是否在监控控制台中检测到任何异常活动以进行深入调查时至关重要。

特别说到日志代理，Google 主要依赖于OpsAgent、遗留代理和自定义日志包。

OpsAgent

GCP 使用 OpsAgent 作为 Windows 和 Linux 系统上监控和收集遥测数据的主要来源。OpsAgent 基于 FluentBit，这是一个第三方但轻量级的日志和遥测数据提供者，允许以Prometheus格式收集指标。FluentBit（fluentd）在将数据发送到日志平台之前，负责自动标记和指标解析。

Google 还依赖于OpenTelemetry Collector，这是另一个开源服务，用于特定的指标收集。

GCP 用户还可以配置他们的 fluentd 配置，用于特定的应用程序级日志记录，这些日志将自动发送到 Google 的 Cloud Logging 平台。

通过使用 OpsAgent 并部署自定义配置文件（fluentd 配置），调查人员可以从各种第三方应用程序收集指标和日志，例如 Microsoft Active Directory、Apache Tomcat、Internet Information Services（IIS）、MySQL、MariaDB 等。OpsAgent 还允许从 GKE 收集日志。

以下是 OpsAgent 默认收集的一些日志源：

  • Linux 中的 /var/log/syslog 和 /var/log/messages

  • Journald 守护进程和 Systemd 日志

  • TCP 端口：监听 TCP 端口并收集日志

  • Windows 事件日志：来自 Windows 操作系统的日志

  • Fluentd Forward：通过 Fluentd Forward 通过 TCP 收集的日志

以下是 OpsAgent 默认报告的指标，无需对主机虚拟机进行额外配置。这些指标有助于识别基准偏差，并且如果发生违规事件，安全团队可以立即响应：

  • CPU 指标：CPU 状态（空闲、处理中断、系统和用户）、CPU 负载、CPU 使用时间和 CPU 利用率

  • 磁盘指标：磁盘使用量（字节）、磁盘 I/O 时间、磁盘操作数、磁盘待处理操作数、磁盘利用率（百分比）、磁盘读取字节数和磁盘写入字节数

  • IIS 指标（Windows）：IIS 打开的连接数、IIS 传输字节数、IIS 连接数和 IIS 请求数

  • 网络接口指标：网络错误、数据包和流量（字节）

  • 内存指标：内存使用量、内存状态（缓冲、缓存、空闲、内核缓存和已用）、内存利用率（百分比）

  • MSSQL 指标：SQL 服务器打开连接数、SQL 服务器事务速率以及 SQL 服务器写事务速率

  • 交换分区指标（仅限 Linux）：交换分区使用量、交换分区 I/O 操作数和交换分区利用率（百分比）

  • 网络指标：TCP 连接数

  • 进程指标：按状态分类的进程数（运行、休眠和僵尸进程）、进程 CPU 时间、进程磁盘读取 I/O、进程磁盘写入 I/O、fork 数量、进程驻留内存（分配量）和进程虚拟内存（使用量）

  • 代理自我指标：代理 API 请求数、代理日志条目数、代理内存使用量、代理指标点数、代理启用的接收器数和代理正常运行时间

传统日志代理

Google 当前已弃用传统日志代理。然而，仍然有需要传统代理的虚拟机，因此 Google 仍然会提供支持。尽管 fluentd 仍在使用，但该应用程序采用了较旧的方法收集指标并将其路由到日志资源管理器。

日志记录 Dataflow 管道

Dataflow 管道提供大规模的数据流或批处理能力。GCP 的 Dataflow 管道基于 Apache Beam。日志可以通过 Dataflow 应用程序以可变的流量在接近实时的情况下进行流式传输。

在 GCP Dataflow 上执行的任何操作默认都会记录在日志资源管理器（Logs Explorer）中。通过日志资源管理器，调查人员可以检测 Dataflow 参数的任何变化，或者是否有未经授权的用户更改了管道。

请注意，Docker 实例是任何 Dataflow 管道操作的基础。因此，调查人员还需要调查 GKE 集群和 GCE 实例组管理器发出的日志。GCP 依赖实例组管理器创建多个受管虚拟机来运行容器（GKE），以处理实例资源并自动部署虚拟机。

以下图表概述了成功执行 Dataflow 管道所需的一些示例资源。像Syslog一样，Dataflow 事件会被标记为严重性评级；它还会生成发出日志条目的作业的确切名称。使用 Logs Explorer 中的过滤器，可以针对 Dataflow 作业或管道中的相关日志进行具体的定位和调查：

图 6.16 – Dataflow 管道执行的资源类型

图 6.16 – Dataflow 管道执行的资源类型

of a log stream that outlines the sequence and flow of the logs emitted by the Dataflow service that triggers other resources such as Kubernetes, GCE Instance Group Manager, and so on:

图 6.17 – GCP Dataflow 发出的日志流

图 6.17 – GCP Dataflow 发出的日志流

总结来说，监控和调查 Dataflow 日志与分析任何其他由相关 GCP 资源发出的活动日志没有区别。需要理解的是，当资源被访问时，GCP 后台可能会访问其他相关资源或依赖项以提供服务，从而影响相关依赖服务发出的日志数量或日志内容。

GCP 存储日志

与 AWS 的 S3 存储桶类似，GCP 存储也将存储容器称为存储桶。每个存储桶可以包含任何文件格式，称为对象。可以为主体分配细粒度的权限并访问每个存储桶或对象。根据使用场景，存储桶也可以设置为公开可访问。存储元数据以键/值对的格式记录在存储桶级别，以管理对象生命周期。分配给键的值可以是存储桶名称字符串或对象生命周期管理配置的数组。

一旦创建了存储桶，就无法更改桶的名称、位置（存储桶所在的位置）、与存储桶关联的项目或元数据生成编号，这些唯一标识了存储桶的状态。

存储权限

类似于 IAM 权限，访问对象所需的特定权限由资源或主体所需。在 GCP 的 IAM 范围内，权限被分配给角色，角色则附加到主体。

以下表格概述了访问存储对象所需的权限列表：

权限名称 描述
storage.buckets.create 在项目中创建存储桶
storage.buckets.delete 从项目中删除存储桶
storage.buckets.get 读取与存储桶相关的元数据，包括存储桶配置
storage.buckets.list 列出项目中的存储桶
storage.buckets.update 更新与存储桶相关的元数据和存储桶配置
storage.buckets.getObjectInsights 读取与存储桶中对象关联的元数据

表 6.1 – 创建和管理存储桶所需的最小 IAM 权限

存储对象日志记录

与 GCP 中的所有资源一样，存储桶上的活动会生成日志，并记录在日志浏览器中；与对象相关的存储日志或访问日志也会记录在日志浏览器中。因此，调查人员应该考虑审查与存储相关的日志，以确定数据外泄的证据和任何针对 GCP 存储桶的威胁。

调查 GCP 云存储日志

在设置 GCP 云存储时，确保已设置适当的权限。这也包括必须根据使用场景开启或关闭的公共访问防止策略。

以下示例将检查日志以确定是否有特权提升尝试访问 GCP 的云存储。为此，我们创建了一个临时存储文件夹test_cf1_test1，并设置该文件夹为非公共访问；我们没有为此目的启用任何细粒度访问控制：

图 6.18 – GCP 云存储配置摘要示例

图 6.18 – GCP 云存储配置摘要示例

我们将检查日志浏览器中的存储日志。我们评估使用 GCP 的gsutil iam get gs://test_cf1_test1命令配置的 IAM 策略，并请求此存储桶配置的 IAM 策略。这相当于向https://storage.googleapis.com/storage/v1/b/<bucket>/iam发送GET请求，但作为已认证用户：

图 6.19 – 云存储文件夹的 IAM 策略示例

图 6.19 – 云存储文件夹的 IAM 策略示例

请注意，以下是为存储文件夹配置的主要角色。当所有者创建统一桶级访问（即桶内所有对象具有相似的访问权限）时，GCP 会自动将遗留角色应用于存储桶：

  • roles/storage.legacyBucketOwner：具有roles/editor或roles/owner角色的主体被授予此访问权限

  • roles/storage.legacyBucketReader：具有roles/viewer角色的主体被授予此访问权限

  • roles/storage.legacyObjectOwner：具有roles/editor或roles/owner角色的主体被授予此访问权限

  • roles/storage.legacyObjectReader：具有roles/viewer角色的主体被授予此访问权限

现在我们知道，访问此文件夹仅限于具有roles/editor或roles/owner权限的用户或主体。总之，任何其他主体或普通公众都无法访问此文件夹。

我们将审查日志浏览器，以确定当已认证用户或主体尝试使用非标准方法访问存储桶时所做的访问请求，例如通过 Python 程序访问云存储桶。

我们将查看一个已认证用户尝试访问存储桶的日志条目。在authorizationInfo部分，我们特别关注突出显示的区域：CallerIP，它指的是试图访问存储桶的用户的 IP 地址，以及callerSuppliedUserAgent（用户代理字符串），它反映了用户尝试访问存储的浏览器和操作系统版本。最后，我们还会查看请求的是哪个资源，以及该存储桶和对象所分配的权限，并检查 IAM 是否授予了此访问权限：

{
  [...]
    "requestMetadata": {
 "callerIp": "184.147.94.133",
 "callerSuppliedUserAgent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.0.0 Safari/537.36,gzip(gfe),gzip(gfe)",
     [...]
     [...]
      {
 "resource": "projects/_/buckets/test_cf1_test1",
 "permission": "storage.buckets.getIamPolicy",
 "granted": true, }

让我们来看一个未认证的用户尝试在 GCP 的 Cloud Storage 存储桶和对象外部访问的情况。与之前的示例类似，我们将查看类似形式的日志条目，并寻找authorizationInfo部分。请求是访问test_cf1_test1存储桶。在这种情况下，请注意用户代理字符串和 IP 地址。鉴于用户尝试以所有者/主体身份进行认证，并且由于访问尝试是通过 Python 命令行应用程序而不是浏览器访问存储桶，因此由于存储桶外没有公共访问权限，GCP 控制台、GCP CLI 或 GCP API 都不允许此权限。

{
  [...]
    "status": {
 "code": 7,
 "message": "PERMISSION_DENIED"
    },
   [...]
    "requestMetadata": {
      "callerIp": "12.47.194.133",
 "callerSuppliedUserAgent": "python-requests/2.25.1,gzip(gfe)"}
      [...]
    "authorizationInfo": [
      {
 "resource": "projects/_/buckets/test_cf1_test1",
 "permission": "storage.buckets.get",
        [...]
 "severity": "ERROR",
  [...]
    }

下图概述了在允许访问 GCP API 工具时的尝试系列：

图 6.20 – 多次尝试访问非 GCP 应用时拒绝访问，仅允许 API 访问

图 6.20 – 多次尝试访问非 GCP 应用时拒绝访问，仅允许 API 访问

如我们所见，日志浏览器是用户或外部资源执行的活动调查洞察的基础。

接下来，我们将查看一些 GCP 的仪表盘，这些仪表盘提供了对在 GCP 中配置的资源的安全状态的洞察。

Cloud Security Command Center（Cloud SCC）

Cloud SCC 就像一个仪表盘，用于通知组织和安全团队关于可能的威胁或漏洞。只有在 GCP 账户设置为组织时，Cloud SCC 才可用。个人 GCP 用户无法访问 Cloud SCC。当发现异常时，它会生成一份特定威胁或错误配置的报告，称为发现。Cloud SCC 提供了一个集中视图，展示了在云服务中检测到的所有发现和异常，比如 GCE。

请注意，有两个激活级别；默认情况下，组织在注册时会被分配到标准服务层级，该层级功能有限，包括查看 GCE 的整体安全健康状态及其配置。它还包括诸如错误报告、持续导出到 Pub/Sub 以及访问其他集成点（如 Cloud Data Loss Prevention、Cloud Armor 等）等功能。

Google 还提供了高级服务层级，该服务层级有一定费用，包含额外的功能，如以下截图所示，功能包括事件威胁检测、网页安全扫描器、容器威胁检测、虚拟机威胁检测、安全健康分析和快速 漏洞检测：

图 6.21 – Cloud SCC Premium 订阅

图 6.21 – Cloud SCC Premium 订阅

接下来的部分将更深入地探讨 Cloud SCC 的一些功能。

IAM 角色

现在我们知道 GCP 使用 IAM 角色来为主体分配访问权限，因此了解团队访问 Cloud SCC 仪表盘及其他详细信息所需的各种访问权限至关重要。

从 DFIR（数字取证与事件响应）角度来看，访问 Cloud SCC 控制台需要以下角色：

  • roles/resourcemanager.organizationAdmin：提供组织级别的管理员访问权限。一个组织可以拥有多个项目。

  • roles/securitycenter.admin：对 Cloud SCC 和 Cloud SCC 内其他资源的管理或超级用户访问权限。提供对项目级检测的访问权限。

  • roles/securitycenter.adminViewer：对安全中心的管理员只读访问权限。用户可以查看扫描结果并查看威胁检测，但不允许进行更改。提供对项目级检测的访问权限。

  • roles/securitycenter.findingsViewer：提供对特定项目在 Cloud SCC 中生成的发现内容的限制性查看权限。

  • roles/cloudsecurityscanner.editor：提供项目级别的访问权限，具有管理控制（读写控制），用于运行云端网页扫描。提供对网页扫描模块内所有资源的访问。

威胁与发现仪表盘

GCP 的威胁和发现仪表盘提供了潜在威胁和安全事件的可见性，允许组织在其 GCP 环境中管理安全威胁和发现。这些仪表盘是监控和分析安全事件的核心中心，通过聚合来自 GCP 内各种服务和工具的数据，主动检测和响应威胁。

威胁仪表盘显示每个虚拟机实例的威胁以及在整体 GCP 环境中识别的威胁。这包括任何潜在的配置错误以及由此引发的 GCP 环境中的漏洞。以下图示为识别威胁的示例仪表盘：

图 6.22 – 威胁仪表盘

图 6.22 – 威胁仪表盘

发现页面详细记录了已识别威胁的细节。发现提供了关于威胁、严重性、事件检测时间（事件时间）、事件报告时间（创建时间）、GCP 资源、GCP 项目和资源类型的详细信息。发现还允许调查员使用筛选器进一步调查已识别的发现并了解威胁的情况。以下是在 发现 部分识别威胁的详细截图：

图 6.23 – 发现仪表板

图 6.23 – 发现仪表板

请注意，发现被分类为 威胁、配置错误 或 漏洞。默认情况下，如果调查员导航到 发现 页面，它将显示所有未静音且在前七天内处于活动状态的发现。

在 发现 页面上，在 快速筛选器 面板内，调查员可以快速筛选出他们感兴趣且与调查相关的发现类型：

图 6.24 – 快速筛选器的发现

图 6.24 – 快速筛选器的发现

一旦应用了筛选器，发现结果将可供审查，调查员可以获取更多信息。在以下截图中，我们已经筛选出 Open RDP port 并确定了两个涉及暴露的 RDP 端口的发现。GCP 将此检测分类为高严重性发现：

图 6.25 – 基于快速筛选器的发现

图 6.25 – 基于快速筛选器的发现

每个发现都提供了一个链接，可获取有关检测结果的更多详细信息，包括 人工智能生成摘要、描述、受影响资源、安全标记、建议的下一步操作以及与各种标准和检测服务相关的链接。它还允许调查员静音此检测，以确保发现不会报告类似的暴露。

当我们深入探讨 Cloud SCC 资产的复杂性时，我们将探讨此功能如何赋予调查员和安全团队详细的 GCP 资源清单，识别漏洞、配置错误和潜在威胁。这种可见性为实际风险评估和积极的安全措施奠定基础，最终促进更具弹性和安全的云基础设施。现在让我们浏览 Cloud SCC 资产为云安全之旅带来的关键功能。

Cloud SCC 资产

调查人员总是希望看到所有资产，并了解环境中配置的内容。同样，GCP 的 Cloud SCC 提供了一种名为 Cloud SCC 资产的功能，提供所有资产类别的高级视图，包含它们的详细信息和为这些资产设置的配置信息。了解环境布局在调查复杂案件时至关重要。调查人员可以使用此资产管理页面获取相关信息，并可能确定调查的下一步。

以下图表概述了我们样本 GCP 实例中配置的资产摘要及相关资源类型：

图 6.26 – Cloud SCC 资产视图

图 6.26 – Cloud SCC 资产视图

资产视图中仅显示与当前项目或资源相关的资产。每个资产的更多信息会在resourceProperties.name字段下显示。例如，我们可以在过滤器中选择compute。Instance资源类型，然后点击第一个项目。下图总结了配置了什么类型的资源及其各种配置元素（或属性）。它还以 JSON 格式展示资源属性，并包括该资产的任何附加元数据。最后，本页面还提供了关于该特定资产的任何发现：

图 6.27 – 资产详细视图

图 6.27 – 资产详细视图

配置漏洞

平台配置漏洞是 GCP 的一项功能，原生扫描各种 GCP 服务和 GCP 虚拟机的配置，并识别基础设施中的漏洞。虽然非常简化，但此仪表板为每个配置漏洞提供了详细的发现。如果 GCP 发现与可接受标准的偏差，它会将某些事项视为漏洞或威胁。由于每个组织不同，某些变化对业务而言是可以接受的。

从调查角度来看，漏洞发现功能提供了有关 GCP 何时观察到漏洞或偏差的历史见解、相关发现的严重性、受影响的服务或端点数量，并提供与各种常见安全标准的映射。

注意

GCP 的漏洞发现可用于确定潜在的根本原因，并通过数字取证确认威胁行为者是否利用了这些漏洞。

以下图表展示了漏洞列表，包括第三方应用程序漏洞。每个发现还将提供详细描述，说明偏差是在哪里被识别的：

图 6.28 – 漏洞列表

图 6.28 – 漏洞列表

从数字取证的角度来看，配置漏洞可以为调查人员提供有关基础设施潜在漏洞的线索，并指示是否有任何漏洞可能是事件的根本原因。

在接下来的部分，我们将进入命令行环境，该环境允许访问各种 GCP 资源。对于熟悉命令行工具的事件响应者来说，GCP Cloud Shell 非常有用。它可以用于快速访问和调查 GCP 资源。

GCP Cloud Shell

Cloud Shell 是 GCP 的原生命令行工具，允许通过命令行界面访问各种 GCP 服务。GCP Cloud Shell 是一个基于浏览器的 Shell 环境，可用于调查和识别潜在的安全事件，适用于威胁狩猎活动。调查人员还可以使用 Cloud Shell 开启或关闭像数据包镜像这样的服务。它还拥有一个交互式代码编辑器，供用户或调查人员导入自定义代码，使 Cloud Shell 执行某些操作。GCP 的 Cloud Shell 还可以通过 Google Cloud SDK 或浏览器会话本地访问。

GCP 提供了基本的命令行工具，特别是 gcloud 和 gsutil。gcloud 提供对 GCP 一般服务的访问，而 gsutil 是一个专门的工具，用于访问存储桶。

通过 gcloud，调查人员可以访问日志资源管理器（Logs Explorer），并收集所有相关日志以供离线分析。调查人员还可以列出用户订阅的服务或所有 VPC 策略：

图 6.29 – GCP Cloud Shell

图 6.29 – GCP Cloud Shell

GCP Cloud Shell 为调查人员提供了一个基于浏览器的命令行界面，用于调查事件。它允许访问 GCP 资源，执行日志分析、内存检查和恶意软件评估等任务。Cloud Shell 帮助保存证据、协作和自动化，使数字取证和事件响应操作更加高效、可扩展且安全。

总结

深入了解 GCP 后，我们知道 GCP 的基础设施与其他流行的云服务提供商非常相似。我们强调了理解 GCP 服务所生成的日志详细程度的重要性，强调调查人员需要寻找佐证证据来确认事件的发生。GCP 的集中式日志系统，流入日志资源管理器（Logs Explorer），是管理员排查常见问题的有力工具，也是调查人员深入了解 GCP 生态系统中事件关联的有力工具。

我们了解了 GCP 如何组织其存储桶和对象，这与 AWS 在概念上非常相似。Cloud SCC 提供了一个仪表盘或基础设施的安全评分卡，供管理员使用。与此同时，对于调查人员来说，它是一个宝贵的发现金矿，提供了关于调查启动时应该查找哪些信息的详细内容。Cloud SCC 提供了对漏洞的独特洞察，无需在主机内部署特定的代理。最后，我们了解了 Cloud Shell，它为调查人员提供了更多自由，使其能够从命令行执行调查活动。

在下一章中，我们将深入探讨电子邮件工作区，特别是 Microsoft 365 和 Google Workspaces，并识别调查云电子邮件工作区的方法论。

进一步阅读

第七章：云生产力套件

到目前为止，您已经熟悉了作为 云服务提供商（CSPs）的 亚马逊 Web 服务（AWS）、Azure 和 谷歌云平台（GCP）的核心组件和日志来源。当我们转向办公套件时，必须认识到这些平台——特别是 Microsoft 365 和 Google Workspace——通常是组织数据和活动的中心。这些环境中的事件调查具有独特的挑战和可能性，因为这些服务不仅提供计算和存储，还提供广泛的协作工具，所有这些都通过 软件即服务（SaaS）模型提供。尽管 SaaS 模型对组织来说非常方便，但这也意味着分析将依赖于产品为调查人员提供的日志来源。

需要注意的是，AWS 并没有类似于 Microsoft 365 或 Google Workspace 的云端办公套件。尽管 AWS 提供了大量的云基础设施和平台服务，但它并未深入进入基于云的办公生产力市场。另一方面，微软和谷歌在生产力软件方面有着长期的市场存在，并自然将其产品扩展到了云端。而 AWS 则更专注于后端基础设施（基础设施即服务，或 IaaS），并未优先考虑在这一领域推出竞争性的套件。在本章中，我们将深入探讨 Microsoft 365 和 Google Workspace 的功能，研究它们的核心组成部分，以及在法证调查中相关的日志和数据类型。

本章将讨论以下主题：

  • Microsoft 365 和 Google Workspace 核心服务概述

  • 身份与访问管理（IAM）在 Microsoft 365 和 Google Workspace 中的应用

  • Microsoft 365 和 Google Workspace 中的审计和合规功能

  • Google Workspace 管理控制台和安全功能

理解这些办公套件对于全面和有效的调查至关重要。尽管它们与传统的云服务有一些相似之处，但用户活动的深度和广度要求采取专门的法证调查方法。本章结束时，您将了解 Microsoft 365 和 Google Workspace 的法证能力与局限性，帮助您在这些环境中进行更有效的调查。

重要说明

本章将重点关注 Microsoft 365 和 Google Workspace 的核心服务、审计和合规功能。第十二章 将重点讨论如何应对被破坏的云办公套件，包括本章讨论的各种服务和日志的收集与分析。

在第十二章中，我们将讨论如何在 Microsoft 365 调查中收集和分析统一审计日志。

Microsoft 365 和 Google Workspace 核心服务概览

Microsoft 365 和 Google Workspace 是强大的云生产力套件，提供一系列旨在促进企业协作、沟通和无缝数据管理的服务。这些生产力套件与其母云平台——微软的 Azure 和 Google 的 GCP——直接相关，这使它们在云取证的背景下尤为重要。了解它们的核心服务以及如何与各自的云平台相关联，将为你提供进行取证调查所需的全面视角。

Microsoft 365

Microsoft 365 是一个集成的基于云的生产力工具套件，包括 Word、Excel 等 Office 应用程序，以及 SharePoint、Teams 和 OneDrive 等用于协作和安全数据管理的高级服务。对于数字取证与事件响应（DFIR）专业人员来说，了解 Microsoft 365 至关重要。它在现代企业中的普遍使用意味着关键证据和数据轨迹通常存在于其生态系统中，掌握其架构和安全特性是进行有效调查和确保网络弹性的关键。让我们深入了解该平台及其功能：

  • 许可证：在组织安全性方面，Microsoft 365 的许可证至关重要，因为不同的许可证级别提供不同的安全功能。例如，E5 许可证提供高级威胁防护功能，如威胁情报（TI）和高级威胁分析（ATA），这些功能在 E3 或 E1 等低级别许可证中不可用。许可证是按用户级别分配的，这意味着每个员工可以根据他们在组织中的角色获得不同的工具和安全功能。这种细分方法使公司能够优化成本，同时确保员工具备适当的安全措施。例如，IT 管理员可能需要 E5 许可证，以获得其强大的安全功能，而销售代表可能只需要 E3 许可证。因此，选择正确的 Microsoft 365 许可证不仅仅是功能问题，也是实施分层安全策略的重要考虑。

    安全专业人员应考虑分配更高级别的许可证，如 E5，以利用微软的所有先进安全和电子发现工具。

  • Office 应用程序：Microsoft 365 包括行业标准的 Office 应用程序，如 Word、Excel 和 PowerPoint，这些应用程序已经从独立的软件转变为深度集成到云生态系统中。这些应用程序现在提供实时协作和云存储功能。

  • Microsoft Teams：Teams 是一个协作中心，支持聊天、视频会议和文件存储。它与其他 Microsoft 服务集成，并提供强大的审计和日志记录功能，对于取证非常有价值。

  • SharePoint 和 OneDrive：SharePoint 用于创建网站和门户，且与 OneDrive 深度集成，OneDrive 是 Microsoft 的云存储解决方案。这些服务提供详细的访问和修改日志。

  • Exchange Online：这是 Microsoft 的基于云的电子邮件解决方案，与 Outlook 集成，提供广泛的日志记录和审计功能，这对于取证调查至关重要。

  • 高级安全性与合规性：Microsoft 365 提供一系列高级安全措施，包括威胁防护、数据丢失防护（DLP）等。安全与合规中心是一个统一的界面，用于管理和审计这些功能。

重要提示

Microsoft 合规中心现已更名为 Microsoft Purview。可以通过 compliance.microsoft.com/homepage 访问。

以下截图展示了 Microsoft 365 门户以及 365 中提供的一些核心服务。登录后可以通过 www.microsoft365.com/ 访问：

图 7.1 – Microsoft 365 应用程序和核心服务

图 7.1 – Microsoft 365 应用程序和核心服务

Google Workspace

Google Workspace 是 Google 开发的一系列云计算、生产力和协作工具、软件及产品。与 Microsoft 365 类似，它已经成为各种规模的企业和组织首选的解决方案，因为它易于使用、可扩展，并且具有协作性质。对于从事 IT 管理、网络安全或 DFIR 的人员来说，深入了解 Google Workspace 至关重要，因为它的广泛应用和独特架构，尤其在中小型企业中更为突出。以下是该平台及其功能的概述：

  • 许可：Google Workspace 基于订阅模式运营，类似于 Microsoft 365，但两者的许可方式存在一些关键差异。Google Workspace 的许可通常更简单、更直观。Google 提供不同的许可层级，如 Business Starter、Business Standard、Business Plus 和 Enterprise，每种层级的功能和存储容量不同。

    另一方面，微软提供不同的企业许可证，分别标记为 E1、E3 和 E5，每个类别内都有一系列选项，包括各种微软产品和服务。而 Google Workspace 的许可主要专注于扩展核心的 Google 服务，微软的 E# 许可证则可能包括更广泛的产品，如高级安全与合规包、电话功能等。因此，在选择 Google Workspace 和 Microsoft 365 之间时，组织需要仔细评估它们在功能、安全性和合规性要求方面的具体需求。

  • Google Drive：类似于微软的 OneDrive，Google Drive 是一项云存储服务，用户可以将文件存储在线并从任何设备访问它们。Google Drive 与其他 Google 服务无缝集成，并且允许轻松的共享与协作。

  • Google Docs、Sheets 和 Slides：这些是 Google 相当于微软 Word、Excel 和 PowerPoint 的工具。它们提供了生产力软件所需的基本功能，并强调团队成员之间的实时协作。

  • Google Meet：作为微软 Teams 的对等平台，Google Meet 提供了视频会议服务，并与其他 Google Workspace 应用程序紧密集成。它允许轻松安排会议、共享屏幕，并提供强大的安全功能。

  • Gmail：微软有 Exchange Online，而 Gmail 是 Google 的电子邮件平台。通过 Google Workspace 的企业订阅，组织可以获得企业电子邮件地址和额外的管理员控制功能。

  • Google Calendar：这是 Google 的时间管理和日程安排工具，可以与微软的 Outlook Calendar 相比较。它与 Gmail 和 Meet 紧密集成，简化了日程安排和事件规划。

  • Google Chat：这是 Google 的即时消息平台，相当于微软 Teams 的聊天功能。它提供了直接消息和团队聊天室，以及文件共享和任务管理功能。

  • Google Forms 和 Google Sites：虽然这两者并不是微软某个单一应用程序的直接对等物，但 Google Forms 和 Google Sites 提供了易于创建表单和构建网站的功能，分别在 Google 生态系统内集成。这些可以成为内部或外部互动的有价值工具。

  • 高级安全性与合规性：Google Workspace 提供了一系列旨在保护数据安全的安全功能，如 两步验证（2FA）、单点登录（SSO）以及用户访问的管理员控制。它还拥有 Vault 服务用于电子发现（eDiscovery），这一功能对法律和合规性至关重要。

    DLP（数据丢失防护）和端点管理是 Google Workspace 中的其他高级安全功能，允许对数据共享进行规则执行，并管理在移动设备上的数据访问方式。

以下截图展示了 Google Workspace 提供的一些应用程序和核心服务：

图 7.2 – Google 应用及核心服务

图 7.2 – Google 应用及核心服务

在深入了解 Microsoft 365 和 Google Workspace 提供的功能和服务概述后，理解这些平台如何确保用户数据的安全性和完整性至关重要。接下来的部分将重点探讨 Microsoft 365 和 Google Workspace 中的 IAM，了解这些平台如何通过身份验证、授权和管理用户身份的机制，确保只有正确的人才能访问特定资源。

Microsoft 365 和 Google Workspace 中的 IAM

身份和访问管理（IAM）是任何组织网络安全战略的基石。它控制谁可以访问哪些资源，以及如何安全地授予和跟踪这些访问权限。在 Microsoft 365 和 Google Workspace 这两个平台中，IAM 扮演着至关重要的角色，因为这些平台是基于云的，且管理着大量的数据。

Microsoft 365

理解 Azure Active Directory (Azure AD) 的 IAM 功能对于云安全至关重要，尤其是在 Microsoft 365 套件中。Azure AD 提供详细的 基于角色的访问控制 (RBAC) 和 多因素身份验证 (MFA) 功能。它还支持 条件访问 (CA) 策略，根据用户的位置、设备状态和风险评估来调整安全性，有效阻止潜在的不安全访问尝试。此外，Azure AD 的审计功能通过对各种活动（如登录和密码更改）生成日志记录，并与 Azure Sentinel 等工具集成以进行日志聚合，为事件响应人员提供关键数据。这种全面的访问和审计管理方法是保持安全性和进行云环境取证调查的基础。以下是 Microsoft 365 的 IAM 功能概述：

  • Azure AD：Microsoft 365 IAM 的核心是 Azure AD，这是一个企业级的 身份服务提供商 (IDSP)。Azure AD 支持复杂的 RBAC，允许对 Microsoft 套件服务以及任何集成的第三方或内部应用进行访问控制。安全专业人员可以创建自定义角色、定义细粒度的访问权限，并强制执行 MFA。

  • CA 策略：Azure AD 还支持 CA 策略，根据用户的位置、设备状态和风险评估来执行安全协议。例如，可以设置一个策略，阻止组织外部网络的登录访问。

  • 审计日志和警报：事件响应人员可以利用 Azure AD 强大的审计能力。对于多种事件，如用户登录、密码重置和权限提升，都会生成日志记录。Azure Sentinel 可以用于聚合来自 Azure AD 和其他来源的日志，从而实现更全面的 威胁检测与响应 (TDR)。登录活动也会被记录在 Microsoft 统一审计日志中，稍后在本章中会进行详细讨论。

Google Workspace

更深入地探讨 Google Workspace 的身份验证功能，让我们了解其在身份和访问管理（IAM）方面的做法，确保数据访问对用户无缝且对未经授权的访问具备安全防护：

  • Google 身份平台：Google Workspace 的 IAM 聚焦于 Google 的身份平台，其中包括基本身份服务，如单点登录（SSO）和多因素认证（MFA）。虽然不像 Azure AD 那样广泛，Google 身份平台仍提供了确保访问安全的基本功能。

  • 上下文感知访问：与微软的 CA 类似，Google Workspace 提供了上下文感知访问功能。它们可以根据用户的设备和位置等因素强制执行访问策略，允许安全专家制定基于情境的细粒度规则。

  • 工作洞察与警报中心：Google Workspace 提供了工作洞察工具和警报中心 API，这些工具提供监控和警报服务。工作洞察可以配置以跟踪有助于发现异常模式的各种指标，异常模式可能表明发生了安全事件。警报中心 API 提供可疑活动的实时警报，并可以与安全信息与事件管理（SIEM）解决方案集成，以便进行集中监控。

  • OAuth 应用程序白名单：Google Workspace 允许管理员将 OAuth 2.0 应用程序列入白名单或阻止，防止未经授权的数据访问。这对于减轻与请求广泛权限但未经审核的第三方应用程序相关的风险尤其有用。

对于安全专家和事件响应人员来说，了解这些平台的 IAM 功能对于保护组织数据并迅速响应安全事件至关重要。

微软 365 和 Google Workspace 的审计和合规功能

确保组织数据的安全性和合规性是安全专家和事件响应人员的首要任务。微软 365 和 Google Workspace 都提供了一套强大的功能，旨在监控、审计和保护数据，同时帮助组织满足合规要求。接下来，我们将讨论它们各自的能力。

微软 365 的安全与合规中心（微软 Purview）

接下来，我们将讨论微软 365 安全机制的核心，重点介绍安全与合规中心（现称为微软 Purview）。Purview 功能丰富，包括电子发现（eDiscovery）、数据丢失防护（DLP）和审计日志等，这些都是在数字取证调查中可以利用的重要功能。让我们更详细地了解这些功能：

  • 电子发现（eDiscovery）：微软 365 配备了电子发现管理器，这一功能使组织能够搜索、保存、分析和导出其生态系统中的内容，如电子邮件、文档和聊天记录。在调查和诉讼过程中，特别需要对特定数据集进行隔离和审查时，这一功能特别有用。接下来是微软电子发现（标准版）的截图：

图 7.3 – 微软电子发现

图 7.3 – Microsoft eDiscovery

  • DLP：Microsoft 365 的 DLP 功能允许管理员识别敏感信息，如信用卡号码或社会保险号码（SINs）/社会安全号码（SSNs），并设置策略以检测、控制和阻止数据共享。

  • 审计日志：Microsoft 365 中的详细审计日志可以配置为跟踪各种活动，包括文件和文件夹访问、修改以及用户行为。这些日志被称为 Microsoft 统一审计日志。Microsoft 统一审计日志是 Microsoft Purview 中的一个关键功能，旨在提供跨多个 Microsoft 365 服务（如 SharePoint Online、Exchange Online、OneDrive、Azure AD、Microsoft Teams 等）的活动的综合记录。这些日志作为宝贵的数据存储库，对安全专业人员和事件响应人员来说至关重要。

    统一审计日志记录了各种活动。这些活动可能包括 SharePoint 和 OneDrive 中的文件访问和修改，Azure AD 中的用户登录活动，以及添加或删除用户等管理操作，甚至是 Teams 和 Outlook 中的特定数据共享事件。这些日志的统一性意味着组织不必访问每个单独的服务来查看日志。在第十二章中，我们将讨论如何在 Microsoft 365 调查中收集和分析统一审计日志。

重要提示

统一审计日志可以在 Microsoft Purview 中的审计选项卡下找到。审计日志必须由组织启用，才能开始记录用户和管理员的活动。默认情况下，这些日志是未启用的。

以下截图显示了默认的审计搜索面板：

图 7.4 – Microsoft 365 合规中心（Microsoft Purview）中的审计搜索面板

图 7.4 – Microsoft 365 合规中心（Microsoft Purview）中的审计搜索面板

  • 威胁保护功能：微软的威胁保护套件与微软 Purview 集成，提供先进的威胁分析和人工智能（AI）驱动的洞察力。对于事件响应人员，这些工具可以自动化检测和修复各种威胁。微软已将此产品重新命名为 Microsoft 365 Defender。未来，微软可能会通过集成 Microsoft Security Copilot 等技术来增强此套件。Microsoft Security Copilot 被设想为一款先进的 AI 工具，作为微软更广泛 AI（Microsoft Copilot）计划的一部分，旨在增强组织的安全专业知识和对安全事件的响应能力。

重要提示

Microsoft 365 Defender 可以通过security.microsoft.com访问。

  • 合规性管理器：该工具帮助组织评估和管理其合规性状况，通过提供合规性评分、评估和建议，帮助安全专业人员将组织流程与行业标准和法规对齐。

Google Workspace 管理控制台及安全功能

转到 Google Workspace 的管理中心，接下来的部分将介绍管理控制台。这个中央仪表板不仅仅是管理员的控制面板，还包含了如警报中心 API、Google Vault、DLP 和审计日志等关键功能，这些功能共同在监控、保存、取证和确保环境安全方面发挥着至关重要的作用，作为事件响应者。让我们仔细看看：

  • 警报中心：Google Workspace 的警报中心 API 提供实时的安全警报，使管理员能够迅速对潜在问题（如钓鱼攻击或可疑登录尝试）做出反应。警报中心可以与第三方 SIEM 解决方案集成，以便更好地进行事件响应（IR）。

  • Vault：Google Vault 允许保留、归档和进行电子发现（eDiscovery）操作，类似于 Microsoft 的电子发现功能。这个工具对于合规性、诉讼或内部调查至关重要。

  • 数据丢失防护（DLP）：类似于 Microsoft 365，Google Workspace 也具有 DLP 功能，可以配置为检测敏感数据，并对用户发出警告或完全阻止交易。

  • 审计日志：Google Workspace 提供了各种服务（如 Gmail、Drive 和移动设备）的详细日志。这些日志可以导出到 BigQuery 或第三方 SIEM 系统进行高级分析和报告，从而更快响应事件。这些日志可以通过 Google 管理控制台中的报告部分访问。

重要提示

通过 Google 管理控制台菜单中的报告 | 报告 | 用户报告访问报告。

  • 安全健康：Google Workspace 中的安全健康功能概述了安全设置及其与推荐最佳实践的匹配情况。它提供了潜在漏洞的仪表板视图，使管理员能够根据需要加强安全措施。

以下截图展示了 Google Workspace 管理控制台的中央界面，Workspace 管理员可以访问前面讨论的各种功能：

图 7.5 – Google Workspace 管理控制台

图 7.5 – Google Workspace 管理控制台

Microsoft 365 和 Google Workspace 都提供了一系列旨在审计、合规和安全的功能。Microsoft 365 通过其 Microsoft Purview 提供了更为先进和精细的控制，尤其对具有复杂需求的大型企业特别有用。而 Google Workspace 则通过其管理员控制台提供了更简洁但同样强大的功能集。对于安全专业人员和事件响应人员来说，了解这些平台的能力对于有效的事件管理（IM）、审计和确保合规性至关重要。

总结

你已经掌握了核心服务和 IAM（身份和访问管理）功能，以及 Microsoft 365 和 Google Workspace 中的审计和合规性能力。这些不仅仅是普通的云服务；它们是组织数据和活动的支柱，提供在 SaaS 模型下的广泛协作工具。由于依赖这些平台提供的日志源，SaaS 架构使得调查变得更为复杂。

你已经了解了像 Microsoft 的统一审计日志和 Google Workspace 的警报中心 API 这样的功能，它们是事件响应人员不可或缺的工具。我们深入探讨了 IAM，讨论了如何利用 Azure AD 和 Google 身份平台来构建更安全、更可监控的环境。最后，我们还简要讨论了这两套套件中的安全和合规功能，赋予你确保组织遵守各种法律框架的知识。

在下一章中，我们将把焦点转向云环境中的 DFIR（数字取证与事件响应）流程。虽然本章为你提供了对两大主流生产力套件的理解，但下一章将加深你对 DFIR 流程关键方面的洞察。我们将深入探讨 DFIR 流程如何在云基础设施中应用，提供你有效管理、分析和响应组织中具有较大云存在的安全事件的知识。

进一步阅读

第三部分：云取证分析 – 应对云中的事件

在这一部分，我们将进一步揭示云中取证获取的复杂性，包括内存和磁盘证据、理解网络日志，并将其获取用于离线分析和调查。我们还将探讨基本的取证证据及其在调查中的重要性。本节将研究托管在云中的容器以及云生产力套件。

本部分包含以下章节：

  • 第八章，数字取证与事件响应过程

  • 第九章，常见攻击向量与 TTPs

  • 第十章，云证据获取

  • 第十一章，分析被攻陷的容器

  • 第十二章，分析被攻陷的云生产力套件

第八章：数字取证与事件响应过程

到目前为止，我们主要研究了云原生工具，用于调查人员查看日志和进行分析。在接下来的章节中，我们将介绍一些补充云原生工具的第三方工具——这些工具可以帮助收集和分析取证证据，结合云原生和第三方工具集，每个调查人员在处理云取证案件之前都应该熟悉。具体而言，本章将重温数字取证和事件响应过程的基础知识。我们还将介绍一些核心概念，并介绍我们通常在云取证案件中使用的工具。

本章我们将学习以下内容：

  • 事件响应过程的基础

  • 常用的主机和内存取证工具与技术

  • 执行实时取证的选项

  • 网络取证

  • 恶意软件分析复习

  • 传统取证与云取证

本章假设你已经熟悉大多数这些主题；这只是对常见的事件响应技术和工具的复习，这些工具通常在案件中使用。

事件响应过程的基础

事件响应过程是一个全面的流程，它允许调查人员以结构化的方式处理事件响应案件。事件响应过程中的七个阶段使调查人员能够理解每个阶段所需的行动。以下图示概述了事件响应过程中的关键步骤：

图 8.1 – 事件响应过程

图 8.1 – 事件响应过程

这里是关键阶段：

  • 准备阶段：这是事件前的阶段，组织与事件响应团队合作，记录并规划在事件发生时的活动。通常，组织会建立其处理事件的目标，并通过事件响应计划的形式，解决事件引发的关键网络安全问题。

    事件响应计划通常包括事件发生期间各个行动的角色和责任、需要通知的关键利益相关者等内容。事件响应计划还会包括组织在处理多个事件时的目标。一旦计划被文档化，组织会定期开展演练，以便进行训练、测试，并定期更新其计划。

  • 检测：此阶段明确指的是安全团队利用工具识别事件的过程。通常，这将是组织的安全事件和事件监控（SIEM）工具或其终端检测与响应（EDR）工具。这些工具由专门的团队进行监控，以提供有关事件发生的早期警告。组织会设置常规的安全监控和警报系统，以便立即识别漏洞或事件。这也是安全团队一旦收到通知，必须对事件进行分类的阶段。分类是指数字取证与事件响应（DFIR）团队评估漏洞、漏洞的范围以及由此带来的影响，并决定是否需要进一步调查的过程。这是安全团队将漏洞识别为事件的步骤。

注意

安全团队需要正确界定事件的范围，识别有多少系统受到影响，漏洞传播的规模大小等等；否则，调查中可能会缺少关键元素。

  • 遏制：在安全团队确认发生了事件并重新组织各安全团队后，典型的第一步是遏制事件。想象一下一个水管爆裂，水流如洪水般涌出；你的第一步行动就是在修复之前先堵住漏水点。在网络安全事件的情况下，第一步总是先遏制漏洞或泄露，接着确定发生了什么，事件是如何发生的，等等。安全团队可以部署特定的安全工具来遏制事件，或者使用已经在组织 IT 环境中部署的工具。

    示例包括断开主机与网络的连接、使用 EDR 工具对主机进行网络隔离，以及关闭某些服务（不允许用户访问）。这一阶段也是安全团队必须在证据被消除之前保存任何证据的阶段。我们在第二章中学习了证据保存及其在调查和潜在法律行动中的重要性。在大多数情况下，缺乏保存证据能力的组织通常依赖提供 DFIR 服务的第三方专业人员。

  • 根除与恢复：在我们看来，根除与恢复以及调查与分析阶段是并行进行的，前提是必要的法医证据已经被保存。在根除与恢复阶段，事件响应团队与组织内的其他安全团队或授权的第三方协作，以修复事件。这可能包括配置更改、打补丁或从备份或零起点重新构建整个系统。修复完成后，这些系统将恢复正常运行。

  • 调查与分析：一旦事件不再进一步升级，调查团队将接手案件。调查团队负责分析发生了什么；这包括审查日志和取证证据，了解事件是如何发生的，哪些数据受到影响，损害的程度等。这一阶段还为检测、根除和恢复阶段提供输入，以便发现任何相关事件并采取额外的补救措施或进行安全加固，确保恢复活动的顺利进行。通常，在这一阶段，调查团队会识别事件的根本原因。在事件响应术语中，我们称之为零号病人。调查团队将利用威胁情报来识别威胁行为者、他们的动机，并识别可能指向其他调查方向的入侵指示器（IoCs）。

  • 报告：一旦调查结束，关键事实被确定，并且根本原因已经明确，调查团队进入报告阶段。理想情况下，事件报告会涵盖所有事件的各个方面、审查过的证据、事件发生的时间线、已执行的操作等内容。报告完成后，将会发送给各相关利益相关者。根据事件的性质和严重程度，事件报告可能只会与有限的群体共享，有时还包括一个突破教练（外部法律顾问），以支持和帮助组织应对由事件引发的潜在诉讼风险。

  • 事后回顾：一旦一切处理完毕，组织恢复到正常运营阶段，组织和安全团队通常会进行一次总结，或者称为事后回顾。安全团队会回顾在事件发生期间及之后准备的文档和调查笔记，并识别出在检测或缓解此类事件再次发生的过程中存在的程序性漏洞。安全团队会根据他们从处理此次事件中获得的经验教训，更新其事件响应计划。

在建立了事件响应过程的基本方面之后，让我们深入探讨在数字取证调查中使用的实际工具和技术。这些工具在揭示数字证据、分析易失性内存、剖析文件系统以及拼凑事件时间线方面发挥着至关重要的作用。

数字取证调查的工具和技术

在任何事件调查中，获取证据并以取证合规的方式快速完成是一个挑战。在某些情况下，调查人员可能需要收集证据以进一步调查事件并确定根本原因。快速收集证据和相关材料对于调查至关重要。本节将探讨一些在调查中有价值的主机和内存证据。

先决条件

在调查人员开始从云控制台收集日志之前，我们可以利用上一章节中探讨的一些先决条件（启用日志、审计轨迹等），以及此处列出的条件。这些先决条件将帮助调查人员更加顺利地进行事件响应工作：

  • 实例保护：一些云服务提供商在事件声明后允许对实例进行保护。例如，在 AWS 中，你可以配置实例以防止其被终止。这样可以确保在实例关闭后你不会终止或删除实例，并且所有的证据和相关的卷都会被保存供调查使用。调查人员甚至可以应用标签作为视觉标记，提醒安全管理员不要更改或更新其配置。

  • 停用：在可能的情况下，将实例从自动扩展组中取消注册并停用。

  • 隔离实例：在可能的情况下，如果有必要，调查人员应更新主机防火墙（云服务提供商的防火墙），以限制流量仅限于外部 IP 和端口。调查人员可以通过云控制台访问实例，而无需从互联网连接。

  • 盘点相关卷：当事件被声明时，且调查人员已确定实例后，需盘点附加到主机的卷，因为可能需要为所有连接的卷创建快照。

  • 在隔离实验室中重建：如果情况需要，根据调查线索，调查人员应考虑制作实例的副本或快照，然后在云中托管的专用隔离取证实验室中重新启动该实例，以捕获必要的证据。

云主机取证

主机取证或数字取证涉及收集、处理、分析和保存基于主机的数字证据。它要求发现通常无法通过安全工具获取的证据、痕迹和信息，并且这些信息通常对普通用户是隐藏的。主机取证在网络安全和执法调查中起着至关重要的作用，提供了有关攻击者或用户采取的某些行动、活动时间线等的洞察。它在知识产权盗窃、数据泄露、恶意软件感染和内部威胁等案件中非常有用，并且在勒索软件案件中也得到了广泛应用。

认识到本书是为 DFIR 专业人员编写的，我们将探讨调查人员可以在高水平上执行的各种取证元素。我们还将花时间识别在调查过程中可能有用的关键工件来源。收集来自云实例的工件类似；工件和事件日志在部署模型中是一致的。因此，数据中心中部署的物理主机与运行在云上的主机之间没有区别。

关键工件来源

我们想了解一些在调查中有时可以参考的关键工件来源。这些来源通常提供证据，揭示用户或威胁行为者（调查对象）在系统中可能执行的活动。通过查询这些工件存储库，你将了解威胁行为者以及操作系统在用户操作计算系统时通常保留的大量信息。

然而，请注意，随着每次 Windows、Linux 或任何其他操作系统的迭代，工件或工件存储库本身收集的信息可能会发生变化，或者可能不再可用。务必注意操作系统的版本，包括主版本和次版本，以便为调查人员做好准备，了解给定版本可用的工件。

在下一小节中，我们将研究两个重要且常用的操作系统，这些操作系统通常用于服务器和 IT 基础设施环境。你还将在云中看到类似的部署（无论云提供商如何）。

Windows 操作系统

Windows 是最受欢迎的操作系统之一，它收集了大量可以在调查中非常有帮助的工件。以下是 Windows 通常记录的工件存储库列表。然而，如前所述，根据操作系统的主要版本和次要版本，某些工件可能会出现在不同的文件夹路径中，或不再可用。请注意，以下日志并非详尽无遗，第三方工具可能会收集额外的记录和工件，这些对于调查可能至关重要：

  • C:\Windows\System32\Tasks\*：包含与任务调度程序相关的 XML 文件，记录了任务定义、任务作者、触发条件以及任何任务定制。它们是根据特定条件或时间触发的自动化进程。威胁行为者使用任务调度程序隐藏并规避检测，同时保持持久性。在一些遗留系统中，你可能还会看到与任务调度程序相关的文件，创建在 C:\Windows\Tasks\* 下。

  • C:\Windows\Prefetch\*：Prefetch 是 Windows 的一项功能，允许应用程序通过预加载常用的数据文件和库来优化加载时间。它提供了法医证据或证明，表明某个应用程序曾被执行过，包括是否有任何代码或脚本在应用程序中被注入（例如，通过 PowerShell 执行代码）。当一个应用程序第一次执行时，它会创建一个预取文件，记录所有可以在执行前从磁盘加载到内存中的文件和库。Prefetch 包括诸如可执行文件名、执行次数和次数等信息。

  • C:\Windows\System32\winevt\Logs\*：Windows 事件日志是每个调查员最需要查看的日志来源。不同类别的日志有专门的日志文件，用于记录相关事件。以下是一些重要的日志文件：

    • Security.evtx：登录/注销、目标主机名和 IP 地址、备用用户名、登录会话 ID 和登录类型。

    • System.evtx：Windows 系统的启动/关闭时间、服务安装、驱动程序故障/安装、硬件更改以及任何与系统相关的活动。

    • Windows PowerShell.evtx：PowerShell 脚本执行和 cmdlet 调用，通常与Microsoft-Windows-WinRM%4Operational.evtx一起核对，用于获取远程会话身份验证和会话信息，及与Microsoft-Windows-PowerShell%4Operational.evtx一起核对，用于获取脚本块日志。

    • Microsoft-Windows-PowerShell%4Operational.evtx：记录 PowerShell 执行的详细信息，包括脚本块、模块加载和脚本策略。

    • Microsoft-Windows-TerminalServices-RDPClient%4Operational.evtx：Security.evtx。

    • Microsoft-Windows-TerminalServices-RemoteConnectionManager%4Operational.evtx：RDP 源 IP 地址和用户名的证据（证明横向移动发生的位置）。这可以与Microsoft-Windows-TerminalServices-LocalSessionManager%4Operational.evtx、Microsoft-Windows-RemoteDesktopServices-RdpCoreTS%4Operational.evtx和Security.evtx进行核对。

    • Microsoft-Windows-TaskScheduler%4Operational.evtx：关于计划任务执行、创建和注册的信息，并与Security.evtx核对，以提供管理员权限使用的证据。

    • Microsoft-Windows-WMI-Activity%4Operational.evtx：Microsoft-Windows-WinRM%4Operational.evtx：C:\Windows\System32\Logfiles\W3SVC1\*：包含关于C:\Windows\appcompat\Programs\Amcache.hve的信息：Amcache.hve记录应用程序的安装和执行情况。它包括完整的应用程序元数据和可执行文件的 SHA1 哈希值。

    • C:\Windows\System32\config\SAM：Windows 的SAM数据库及在主机上创建的任何本地帐户。访问SAM数据库需要提升权限，威胁行为者通常会尝试攻击SAM数据库，以窃取凭证并利用其进行其他形式的攻击。

    • C:\Windows\System32\config\SOFTWARE：这是一个重要的注册表文件，用于收集关于系统状态、已安装软件以及 Windows 各种其他配置元素的信息。调查人员可以使用SOFTWARE注册表文件调查是否安装、修改或删除了未经授权的软件。调查人员还可以识别是否修改了任何核心元素，例如启动程序（以保持持久性）、系统配置（以降低防御）等。

    • C:\Windows\System32\config\SECURITY：SECURITY注册表文件负责记录与操作系统安全相关的所有配置。这包括用户帐户、关联的帐户组、密码哈希、注册表项的权限以及安全策略。调查人员可以分析这个注册表文件，以重建威胁行为者、未经授权的用户活动和安全策略违规行为。与SAM数据库类似，SECURITY文件也受到 Windows 操作系统内核的保护，需要提升权限才能进行修改。

    • C:\Windows\System32\config\*.LOG1：LOG1文件是一个事务日志文件，确保相关注册表文件（包括SOFTWARE、SAM和SECURITY）的完整性。当系统配置发生更改时，更改会被写入相关的事务日志LOG1文件，并且当更改被提交到注册表文件时，事务日志会标记为已完成。

  • C:\Users\*\AppData\Roaming\Microsoft\Windows\PowerShell\PSReadline\ConsoleHost_history.txt：提供用户在 PowerShell 控制台执行命令的历史记录。

  • C:\Users\*\NTUser.DAT：Windows 会自动为每个用户创建一个NTUser.DAT文件，包含关于用户特定配置或偏好、用户与各种应用程序的交互、采取的行动以及最近访问的资源的信息。

  • C:\Users\*\NTUser.DAT.LOG1：类似于注册表文件，这个事务日志文件记录所有事务（更改），在将更改提交到NTUser.DAT文件之前。调查人员可以利用该日志文件进一步关联用户活动。

  • %SYSTEMDRIVE%\$Recycle.Bin\**：%SYSTEMDRIVE%指的是根驱动器分区的命名方式，其中包含RecycleBin文件夹。该文件夹包含所有标记为删除的文件和子文件夹。调查人员可以利用这一点来确定用户或威胁行为者是否尝试删除任何文件。* %SYSTEMDRIVE%\$LogFile：$LogFile是与文件系统相关的特殊 Windows 文件，特别是$LogFile记录元数据，以及目录和文件的创建、修改和删除。调查人员可以解析$LogFile来识别系统随时间变化的变动，并获取允许从文件存储中恢复与调查相关的信息。* %SYSTEMDRIVE%\$MFT：指的是 NTFS 文件系统的主文件表（MFT）。它提供与文件和目录相关的元数据，包括时间戳、文件大小以及目录与文件之间的关系。调查人员可以使用 MFT 来重建与文件系统变化相关的事件顺序。

Linux 操作系统

鉴于大多数 Linux 生态系统是开源的，并且在各个行业领域中得到广泛应用，包括在云中的应用，Linux 为调查人员提供了极大的取证价值。在收集 Linux 的取证证据或执行实时取证时，应该优先考虑以下证据：

  • /etc/passwd：一个纯文本文件，包含诸如用户名、用户 ID（UID）、组 ID（GID）、主目录路径和默认 Shell应用程序等信息。

  • /etc/group：与/etc/passwd文件类似，它存储有关系统中用户组的信息。

  • /etc/crontab：Cron 是一个作业调度程序，它按照预定义的时间表自动执行命令或脚本。威胁行为者可以利用 Cron 作业在环境中维持持久性。

  • /etc/fstab：包含有关文件系统、驱动器和分区的信息，包括设备如何在启动时挂载。

  • /etc/rc.d/**：包含服务的启动和关闭脚本。威胁行为者可以利用该目录保持持久性并避免检测。

  • /etc/init.d/**：类似于/etc/rc.d/**，该目录包含初始化 脚本或系统服务的初始化脚本。威胁行为者可以利用该目录在系统初始化过程中注入恶意脚本。

  • /etc/systemd.d/**：包含用于初始化脚本的额外配置。它还允许您覆盖或扩展脚本的范围和服务。

  • /var/log/**：该目录包含由系统进程和应用程序生成的事件日志文件，具有重要的价值。

  • /home/<username>/*：主目录是用户的目录（在/etc/passwd中定义），允许用户存储文件、配置和用户特定数据。

  • /home/*/.ssh/known_hosts：包含用户之前使用过的远程服务器的公钥列表，提供关于通过 SSH 连接这些远程服务器的尝试的证据。

  • /home/*/.ssh/authorized_keys：它包含了允许通过公钥认证进行远程访问的公钥列表。当用户想要使用基于 SSH 密钥的认证登录远程服务器时，他们的公钥会被添加到服务器上的 authorized_keys 文件中。

其他证据/元数据

一旦我们收集了特定于主机的证据，调查云实例的调查人员还应收集 实例元数据，包括实例配置、IP 地址分配、VPC 子网分配、策略配置等。

如我们所见，主机取证涉及对计算机或设备的存储、操作系统和文件进行仔细检查，以识别并收集关键的数字证据。这个过程会揭示出诸如日志文件、用户配置文件、注册表项和系统日志等信息，帮助重建事件、用户活动和潜在的安全漏洞。

将注意力从主机取证转移，我们来讲讲内存取证。内存取证通过检查系统的易失性内存，揭示出重要的线索，提供对正在进行的进程、活跃应用程序和可能被隐藏的证据的深入了解。

快速取证采集工具

快速取证是指在数字取证调查中使用精简高效的方法和工具。传统的取证过程可能非常耗时，导致调查延迟。快速取证旨在通过优先考虑速度，而不妥协调查的完整性来解决这个问题。调查人员应考虑采用快速取证方法，以提高响应速度，快速识别和缓解网络威胁，及时响应事件，并最小化事件的影响。

一些工具已经被开发出来以支持快速取证。快速取证通常在处理大型跨地区组织的终端时非常实用。以下是一些著名的快速取证工具：

  • CyLR：CyLR 是一个实时响应工具，可以从多个来源收集证据，并创建一个可以离线分析的包。CyLR 包可以通过 Magnet Axiom 或 Sleuthkit Autopsy 工具进行分析。CyLR 可以通过 EDR 或流行的脚本部署技术进行自动化采集。它可以用于从 Windows 和 Linux 操作系统收集数据。

  • KAPE：由 Eric Zimmerman 开发的Kroll Artifact Parser and Extractor（KAPE）以其模块化和可扩展的框架而闻名，使其能够灵活应对各种数字取证场景。该工具特别受到重视，因为它能够从操作系统中的各个来源收集证据，帮助调查人员高效提取关键证据。KAPE 利用配置文件定义特定的证据和相关位置，允许取证专家根据特定调查的需求定制数据收集。

  • PowerForensics：另一方面，PowerForensics 是一个专门用于取证的 PowerShell 模块。它提供了一套 cmdlet，允许用户与 NTFS 文件系统进行交互，从 Windows 机器中提取有价值的取证信息。PowerForensics 可用于分析文件元数据、文件内容及其他文件系统结构。

  • Kansa：Kansa 是一个开源的事件响应和威胁狩猎框架，使用 PowerShell 编写。它简化了从 Windows 系统收集和分析证据的过程，帮助安全调查。Kansa 提供了一套 PowerShell 脚本和模块，可以自动化事件响应过程的各个方面。该框架允许安全专业人员和事件响应人员在多个终端上运行预定义或自定义的 PowerShell 脚本。

我们在进一步 阅读部分中包含了更多细节。

内存取证

内存取证是一种高级数字调查技术，它分析计算机或设备的易失性内存（随机访问内存 – RAM）。与传统的主机取证不同，后者主要检查存储和文件，内存取证深入研究系统的实时状态，揭示活跃的进程、运行的应用程序以及隐藏的遗留物，这些都能为网络攻击、恶意活动和可能未存储在磁盘上的易失性数据提供宝贵的线索。在主机的操作系统中执行的所有内容都必须经过主机的内存。这种方法为数字环境提供了独特的视角，使调查人员能够发现本可能被隐藏的关键证据。

内存取证捕获的信息包括：正在运行的进程和线程、恶意软件或根套件、打开的文件句柄、缓存和剪贴板内容、加密密钥、硬件和软件配置、注册表键、访问过的网站和在控制台上输入的命令。

云环境中的内存取证呈现出一系列独特的挑战和机遇。随着组织越来越多地将系统迁移到云平台，理解和分析易失性内存对于检测安全漏洞、内部威胁和未授权访问变得至关重要。

尤其是在云环境中，内存取证面临的挑战包括资源共享、动态配置和对物理硬件的有限访问。虚拟化和容器化增加了复杂性，使得必须调整传统的内存取证方法。然而，云环境也提供了一些优势，如日志集中化、可扩展性和能够同时捕获多个实例的内存快照。这有助于识别可能针对云环境中多个实例或用户的复杂攻击。

让我们看看一些调查人员通常应该收集和分析的主要证据。这些证据类似于在云中或服务器上运行的 Windows 操作系统。鉴于内存取证值得单独成书，我们假设你已经熟悉计算机内存及其各种元素和功能的基本知识。

内存获取工具

在云取证的背景下，调查人员有几种选择：收集和分析实时系统的内存映像，或收集和分析离线主机写入磁盘的内存遗迹。下图展示了实时系统和死机系统之间的区别以及用于从中收集内存映像的工具：

图 8.2 – 内存获取来源/工具

图 8.2 – 内存获取来源/工具

让我们看看一些可以在实时系统中获取内存的工具集，同时查看可以为取证调查收集的死机系统的内存遗迹：

  • dd 是一个在 Linux/Unix 平台上常用于低级数据复制和转换的命令。在数字取证的背景下，dd 被用于在 Linux/Unix 系统中获取内存或 RAM 的副本。请注意，由于潜在的风险和挑战，通常不推荐使用它。错误使用 dd 进行内存获取可能导致内存捕获不准确或不完整，并可能干扰目标系统的操作。

  • pagefile.sys) 是虚拟内存扩展，允许内存使用此存储来临时存储数据。在较旧的 Windows 版本中，此文件被称为 swapfile.sys。通常，当物理 RAM 空间达到上限并且应用程序排队等待执行时，Windows 会通过 pagefile.sys 自动将内存页卸载到磁盘。从取证的角度来看，pagefile.sys 可能包含敏感或有价值的信息的残留数据，包括文件碎片、注册表数据，甚至是密码。这些残留数据可能在主内存或传统磁盘存储中不存在，因此页面文件可能成为潜在的证据来源。请注意，页面文件是易失性的，这意味着其内容在系统关闭或重启后不会保留。然而，如果系统进入休眠状态，页面文件的内容可以保留在休眠文件（hiberfil.sys）中，供潜在恢复使用。在进行内存获取时，捕获页面文件是一个好习惯。* MEMORY.DMP 位于 Windows 操作系统的 %SystemRoot% 文件夹中。根据转储文件的大小，调查人员可以确定它是完整的内存转储（也称为 内核内存转储）还是在崩溃时转储的内存页面快照（活动内存转储）。无论如何，现有的内存分析工具应该能够让调查人员解析和分析这些崩溃转储。请注意，在 Linux 系统中，写入磁盘的内存页称为 交换文件，仅在分配的内存不足时才会使用。调查人员只能收集交换文件。当 Linux 系统重新启动时，交换文件不会保留在磁盘上。请注意，如果 Linux 系统处于休眠状态，调查人员可能会在磁盘上看到交换文件，但这种情况很少发生；Linux 系统通常不会进入休眠状态。

尽管有许多收集内存映像（无论是活跃系统还是死机系统）的方法，但需要注意的是，从云取证的角度来看，收集磁盘上的内存交换文件或页面与死机系统中的收集方法没有区别。调查人员必须收集与各个云实例相关的正确磁盘副本。现在，我们已经获得了内存快照或映像，让我们来看看分析这些映像的工具。

内存分析工具

在本节中，我们将介绍一些在调查中常用的工具，尤其是用于分析系统内存伪影的工具。一旦收集了内存映像，就有一些特殊工具可以从内存中提取信息：

  • Volatility：Volatility 是最受欢迎的开源内存取证框架之一，也是调查人员进行内存分析的首选工具。它完全用 Python 编写，允许分析内存快照，并支持多种操作系统。它提供多个插件，用于提取有关正在运行的进程、网络活动、注册表数据等的信息。Volatility 支持多种内存转储格式，广泛应用于该领域的专业人士。Volatility 还可以本地分析较旧版本 Windows 中的hiberfil.sys和pagefile.sys。然而，为了解决挑战并处理随着 Windows 操作系统变化的休眠文件，开发了各种其他特定工具，从而以更好的方式应对这些变化。

  • Velociraptor：Velociraptor 是一个开源的终端监控和数字取证平台，旨在提供跨网络终端的高保真数据收集和分析能力。Velociraptor 的一个关键特性是能够在终端上执行实时内存分析，以揭示洞察、检测异常并收集事件响应和取证调查的证据。分析人员可以根据特定的调查需求定制内存分析任务，支持自定义查询和插件。除了内存分析，Velociraptor 还通过预定义的指示器和模式促进主动威胁检测。其集中管理、工作流自动化、可扩展性和活跃的用户社区使其在不同环境（物理、虚拟和云环境）中表现出色。

  • Rekall：Rekall 是 Volatility 的一个分支，增强了其通过启用实时内存取证的功能。与 Volatility 类似，Rekall 包括 Volatility 的大部分功能，并能分析不同操作系统中的hiberfil.sys、pagefile.sys和交换文件。

  • GRR：GRR 是另一个基于代理的开源事件响应平台。调查员必须部署一个代理来捕获遥测数据或进行实时内存取证。虽然有更强大的内存分析工具可用，如 Velociraptor 和 Volatility，但由于 GRR 独特的优势和能力，它仍然是任何组织 DFIR 工具库中的一个有价值的工具。GRR 明确设计用于收集终端数据，包括对内存文件的实时分析，使其成为任何网络安全团队的多功能工具。

  • Magnet AXIOM：Magnet AXIOM 是由 Magnet Forensics 开发的一款商业工具，专为帮助执法机构、企业调查员和数字取证与事件响应（DFIR）专业人士设计。它是一款基于许可的工具，专注于高效地从各种来源收集、分析和展示数字证据。Magnet AXIOM 支持从计算机、智能手机和云服务等多种来源进行数据采集。它还支持分析文件、电子邮件和聊天信息等文物。Magnet AXIOM 支持从各种操作系统捕获的内存映像，包括hiberfil.sys、pagefile.sys和交换文件。它还能够解析通过多个第三方工具收集的快速取证包。Magnet AXIOM 支持时间轴分析，并能重建来自数字证据的事件。它还支持关键词搜索、数据雕刻和高级过滤功能，帮助调查员迅速定位相关信息。最后，它简化了报告生成、支持协作，并专注于移动设备分析。

总结来说，主机和内存取证是数字调查中不可或缺的支柱。对操作系统中的文物进行分析，并结合提取挥发性内存数据，使数字取证调查员能够重建数字痕迹，揭示隐藏证据，并解密网络事件背后的故事。主机取证全面解释了系统的历史和用户活动。

相比之下，内存取证可以捕捉实时快照，揭示进程的内部工作原理和潜在威胁。与先进的工具和方法相结合，这些学科共同推动了在数字取证领域追求真相与正义的努力。我们将在第十章中学习如何从云端获取磁盘和内存映像。以下部分将重点介绍使用各种工具进行实时取证分析和威胁狩猎的技术，因为威胁行为者已经演变，采用复杂的技术将恶意软件隐藏在明面上。

实时取证分析和威胁狩猎

数字取证调查员的操作原则是恶意软件必须始终在内存中运行；它们没有可以隐藏的地方。然而，近年来，技术的发展使内存变得更加庞大且不易挥发，从而催生了无文件恶意软件——即不接触磁盘的恶意软件——它在执行前保持隐蔽。以下各节将介绍一些现代企业调查员用来识别恶意软件并进行威胁狩猎的工具，帮助你了解恶意软件使用的常见持久性机制。

基于 EDR 的威胁狩猎

计算技术、云基础设施的进步以及对大规模磁盘和内存容量的支持，使得有必要推出一系列新工具，这些工具能够持续监控主机并收集磁盘和内存上的实时遥测数据，捕获每个应用程序的痕迹，发现恶意软件，并在攻击变得更严重之前阻止它。这个被称为 EDR 的技术是一类新的安全工具（商业工具），它收集高级遥测数据，并使用超越标准基于签名的检测的多种技术来识别和检测恶意软件，并战术性地响应威胁。我们通常将 EDR 称为“超级增强版的杀毒软件”，因为它能做的事情远超过简单的杀毒软件，而后者往往很容易被威胁者关闭或躲避，难以被检测到。

EDR 通常在操作系统内核级别运行，并能够识别磁盘和内存上的各种活动，超出用户能看到的范围。EDR 能追踪进程调用、子进程信息、Windows 应用程序编程接口（API）的使用情况、传递给每个进程的命令行、网络连接、进程线程信息、动态链接库（DLLs）、文件句柄、注册表句柄等等。

请注意，EDR 并不是法医工具。然而，EDR 通过提供高保真遥测数据来增强法医调查，如果在组织内没有部署 EDR，这些信息通常会被错过。大多数流行的 EDR 还允许法医团队对主机进行实时查询。你可以使用预设的命令行参数查询主机系统，甚至运行自定义脚本以收集更多的信息或证据。法医调查员通常使用实时查询来下载证据、日志，或甚至快速的法医包进行离线分析。

深入探索 EDR 追踪

假设我们作为调查员，部署了 EDR 工具来响应安全事件。我们正在使用 SentinelOne Singularity 平台（经许可使用）来展示使用此方法进行的威胁追踪。

一旦 SentinelOne 代理安装到受感染的系统上，它通常会扫描系统并启动漏洞隔离，意味着任何检测到的恶意软件都会被隔离。警报会在中央 Singularity 控制台上触发。这成为调查或追踪的起点，调查员可以通过这个 EDR 工具继续进行他们的调查。在以下截图中，注意到在 Threats 仪表板下有更多的详细信息，同时提供了启动威胁追踪的选项。SHA1 哈希值还允许调查员查看其他威胁情报来源，如 VirusTotal：

图 8.3 – SentinelOne EDR 上的示例警报（经许可发布）

图 8.3 – SentinelOne EDR 上的示例警报（经许可发布）

一旦调查人员能够获得足够的关于威胁情况的信息，他们就可以开始执行威胁狩猎。SentinelOne 提供了多种方式来进行威胁狩猎。最简单的一种方式是通过其 Singularity tgt.file.sha1 = "41e8db9bb005fce152e08c20e6392e0a5d44bb6e" SHA1 条目：

图 8.4 – 基于 SHA1 哈希的 SentinelOne Singularity XDR 模块狩猎

图 8.4 – 基于 SHA1 哈希的 SentinelOne Singularity XDR 模块狩猎

请注意，每个结果都有一个复选框，提供有关收集到的数据的更多信息。这包括事件本身的信息、执行该事件的账户、SentinelOne 代理的名称和终端构成、以及检测的详细信息，包括进程信息和提供的命令行参数。每个条目还可以进一步用于深入狩猎，这在复杂的威胁场景中尤其有用。

SentinelOne Singularity XDR 本地呈现所有遥测数据字段的集合。字段视图使调查人员能够快速进入并调查，而无需浪费时间去适应界面。以下是字段列表的示例，它是导航选项的一部分。它还为调查人员提供了聚合的字段结果，以便识别任何异常。每个结果都可以点击，应用相关的搜索过滤器进行狩猎：

图 8.5 – SentinelOne Singularity XDR 的字段

图 8.5 – SentinelOne Singularity XDR 的字段

一旦使用 Singularity XDR 模块执行了初步的狩猎，调查人员可以基于结果快速转换，以获取更多关于检测到的威胁活动的信息。通过遥测数据，我们知道威胁行为者使用 PowerShell 尝试访问并执行恶意软件。样本截图显示了识别该威胁行为者行为的事件数据，使得调查人员能够进一步获取有关该事件的更多情况信息。

调查人员可以在访问相关事件条目时使用事件详情标签（参见图 8.3）。事件详情提供有关事件的更多信息，包括调用恶意软件的命令：

图 8.6 – 基于 SingularityXDR 搜索结果的事件详情

图 8.6 – 基于 SingularityXDR 搜索结果的事件详情

如我们所见，EDR 增强了检测和防止恶意软件执行的过程。在云取证的背景下，拥有一个 EDR/XDR 工具来调查云端终端并结合在云控制台生成的日志，可以增强调查人员分析和识别威胁发生方式的能力。此外，从法律角度来看，这使得调查人员能够从不同来源 corroborate 事件，确保已识别的调查在法医上是可靠的，并且在法律上是可接受的。

恶意软件狩猎

寻找恶意软件是一种主动发现宿主中恶意应用程序/软件的方法。这种技术超越了传统的安全措施，通过主动寻找妥协迹象、识别根本原因并防止未来的事件。事件响应人员分析系统行为，利用威胁情报和内存分析来揭示妥协的迹象。通过仔细审查日志、进行沙箱测试以及利用自动化工具，他们可以检测与恶意软件相关的异常和模式。以下是一些恶意软件常用的躲避检测的方法：

  • 服务劫持：服务劫持指的是恶意行为者控制系统服务，从而在合法进程的上下文中执行任意代码。通过攻陷受信任的服务，攻击者可以执行恶意命令或有效载荷，绕过检测。一个实际案例是Zeus银行木马，它利用 WMI 服务执行恶意代码，并在感染的系统上保持持久性。

  • 进程注入：进程注入是一种恶意软件将其代码插入到合法进程中的技术，有效地将其隐藏在受信任应用程序的内存空间中。常见的注入方法包括 DLL 注入、反射 DLL 注入和进程空洞注入。检测进程注入涉及监控内存区域的意外修改，分析进程内存中的代码不一致性，并检查 API 调用以识别注入代码执行的迹象。TrickBot恶意软件使用了反射 DLL 注入等进程注入技术，将恶意代码注入到合法进程中，从而避开了安全解决方案的检测。

  • 备用数据流 (ADS)：ADS 提供了一种通过附加额外数据流将数据隐藏在合法文件中的方法。恶意软件可以利用 ADS 存储其代码或配置，从而使检测变得困难。寻找 ADS 涉及分析文件元数据、检查文件内的多个数据流，并监控异常的数据流关联。

  • Web Shell：Web Shell 是嵌入在 Web 应用程序或服务器中的恶意脚本或代码片段，允许攻击者获得远程访问和控制权限。Shellshock漏洞允许攻击者将恶意代码注入到 Web 服务器环境中，从而有效部署 Web Shell 并获得未经授权的访问。

  • 打包：打包涉及压缩或加密恶意软件文件，以掩盖其内容并防止直接分析。恶意软件通常在运行时在内存中解包，这使得调查人员很难对其进行采样并识别其真实性质。检测打包技术包括识别打包的可执行文件头，分析文件的熵值，并利用解包工具或技术揭示原始代码。一个常见的应用打包工具是UPX，它被合法应用程序和恶意软件广泛使用。

  • 代码签名：恶意软件作者可能使用窃取或欺骗获取的数字证书对其代码进行签名，以显示合法性并避免安全软件的检测。检测用有效证书签名的代码涉及检查证书的真实性，检查证书链，并监视吊销的证书或证书使用中的异常。最近的历史中有多个例子，攻击者窃取组织的代码签名证书，用于签署恶意软件，并用于下游供应链攻击。

  • 无文件恶意软件：无文件恶意软件在内存中运行，不在磁盘上留下痕迹，使检测变得困难。这种技术通常涉及利用脚本语言或利用系统工具。检测这些技术需要收集特定的日志，如 PowerShell，并获取内存镜像。EDR（终端检测与响应）是检测这些攻击的好方法，因为它们监视和跟踪文件系统变化和内存活动。流行的无文件恶意软件方法使用 PowerShell 的IEX cradle，在内存中下载应用程序或额外脚本，并在运行时执行，从未接触磁盘。最近，威胁行为者已被发现使用 PowerShell Empire，这是一个允许无文件恶意软件交付技术的框架。

正如我们所见，威胁行为者可以以各种方式隐藏和逃避主机上的检测。虽然我们讨论了最常见和明显的方式，但高级威胁行为者组织使用创新技术。在某种程度上，云基础设施中运行的恶意软件可能会使调查员的工作更加轻松，因为云服务提供商已经集成了各种安全工具，用于识别和检测恶意活动。

此外，大多数云服务提供商与多个安全供应商合作，提供工具和对主机的可见性，从而帮助调查员比传统调查方法更快速地识别恶意软件。例如，AWS GuardDuty 可以直接扫描虚拟机而无需任何代理安装，并提供恶意软件检测能力的可见性。同时，GCP 的 CloudSCC 和 Azure 的安全中心具有类似功能，监视虚拟机并通知管理员有关恶意程序的信息。在任何情况下，这些检测都是由云服务提供商的合作伙伴提供的，但可在各自的云服务提供商安全控制台中供调查员使用。我们将在第 4、5和6章中详细介绍这些工具。

常见的持久化机制

我们现在将研究恶意软件通常可以采用的常见持久化机制。无论云环境下的基础设施如何，恶意软件都会运行：

  • Windows 注册表的Run键在每次用户登录时启动应用程序或脚本，允许特定用户应用程序自动启动。一些常见的注册表键包括：

    Computer\HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run
Computer\HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce

  • 启动文件夹：放置在用户或系统的启动文件夹中的应用程序会在用户登录时自动启动，从而实现用户特定的启动行为定制。威胁行为者最常用来保持持久性的文件夹之一如下所示：

    %AppData%\Roaming\Microsoft\Windows\Start Menu\Programs\Startup

  • 计划任务：在系统启动或用户登录时配置的计划任务由 Windows 任务计划程序管理，可以执行各种操作，例如更新或维护任务。

  • 组策略对象（GPOs）：GPOs 是威胁行为者在组织内部保持持久性的最常见方式之一。它们通过在公司域控制器上创建恶意 GPO 来准备和派发恶意软件副本以保持持久性并执行。此外，威胁行为者可以调整 GPO 来控制恶意软件如何在企业中集中部署。威胁行为者还可以在满足特定条件时创建计划任务，下载脚本或触发恶意软件执行。大多数勒索软件运营商使用 GPOs 来集中控制和部署勒索软件，确保安全管理员没有时间阻止攻击。* DLL 劫持：DLL 劫持是攻击者通过操控 Windows 加载 DLL 的方式来实现恶意软件持久性的技术。在 DLL 加载过程中，Windows 按特定顺序定位所需的 DLL，包括应用程序文件夹和系统目录等标准目录。攻击者识别出一个易受攻击的应用程序，并将一个与所需 DLL 同名的恶意 DLL 放入应用程序搜索的路径中。当应用程序启动时，恶意 DLL 会代替合法的 DLL 被加载，从而在应用程序的上下文中执行攻击者的代码。这使得攻击者能够建立持久性，运行任意代码，并可能获得对受感染系统的控制。由于目标应用程序的常规使用，恶意代码会持续执行，确保即使系统重启后仍能保持持久性。* WMI 事件消费者：通过 WMI 事件消费者实现恶意软件持久性，涉及利用 WMI 的功能，在特定触发事件发生时执行恶意操作。以下是攻击者可能采取的步骤，以实现这种形式的持久性。这些步骤最终存储在 管理对象格式（MOF）文件中，该文件用于在 WMI 库中注册新类：

    1. 创建恶意事件消费者：攻击者创建一个 WMI 事件消费者，一个脚本或可执行文件，旨在在特定 WMI 事件发生时执行。系统事件，如启动、登录或其他自定义触发事件，都可能触发此事件。恶意事件消费者包含执行攻击者负载的指令。

    2. 事件过滤器和绑定：攻击者创建一个事件过滤器，定义恶意事件消费者执行的条件。这个过滤器与特定的触发事件相关联。接着，攻击者将事件过滤器绑定到恶意事件消费者，从而在过滤器和包含脚本或可执行文件的有效载荷之间建立连接。

    3. 触发事件执行：当定义的触发事件发生时，相关的事件过滤器将评估条件是否满足。如果条件符合，WMI 事件消费者将执行有效载荷，可能是恶意软件、脚本或可执行文件。这个有效载荷在 WMI 服务的上下文中运行，使攻击者能够建立持久性、执行任意代码，并可能控制被攻陷的系统。

    调查人员应参考以下命令查询 WMI 存储库并确定恶意 WMI：

    > Get-WmiObject -Class __FilterToConsumerBinding -Namespace root\subscription
> Get-WmiObject -Class __EventFilter -Namespace root\subscription
> Get-WmiObject -Class __EventConsumer -Namespace root\subscription
strings -q C:\windows\system32\wbem\repository\objects.data

总结来说，现场取证、EDR 解决方案、主动恶意软件狩猎和高级持久性机制的结合，强调了一种全面的现代网络安全方法。借助先进的工具和技术，现场取证可以实时洞察正在进行的威胁，从而实现快速的事件响应。

我们现在正在进入网络取证的领域。网络取证在揭示网络威胁方面至关重要，因为它允许我们检查网络活动、流量模式和通信行为。通过深入分析网络数据，我们将获得对潜在安全漏洞、恶意活动以及敌对方使用的更广泛战术的宝贵洞察。在云取证的背景下，这尤为重要。

网络取证

正如本节标题所示，网络取证是一种对网络协议、数据包和线缆上的任何证据进行取证分析的方法。在云环境中进行网络取证，涉及分析网络流量、通信模式和 CSP 服务与外部用户之间的数据流，以揭示潜在的安全漏洞、数据外泄和未授权访问。通过检查云基础设施中的网络数据，我们可以绘制事件的全面图景，识别异常，并检测网络威胁留下的痕迹。从根本上讲，调查人员必须访问网络数据才能进行此类分析。这种深入的审查让我们能够有效应对事件，降低风险，并保持强大的云安全防御能力。

基本网络概念

在网络取证中，调查人员必须始终记住，任何网络通信都可以分解为网络通信模型所定义的层次结构，模型可以是开放系统互联（OSI）模型或传输控制协议/互联网协议（TCP/IP）模型。这些模型为调查人员提供了明确的视图，帮助他们了解威胁行为者如何访问主机以及威胁行为者使用了哪些协议。让我们更详细地了解这两种模型。请注意，我们假设你对该领域已有一定了解，以下内容仅为复习：

  • OSI 模型：该模型是一个框架，用于标准化各种网络协议的功能和交互，作为设计和理解不同网络技术如何通信的指南。该模型被分为七层，每一层负责特定的任务和功能。下图概述了七层及其所使用的协议。在云环境中，较低层由 CSP 进行管理，包括物理层和数据链路层。相对而言，网络层是云客户和 CSP 的共同责任，因为该层允许客户创建他们的 VPC。某种程度上，传输层也是共同责任，例如如果需要配置特定的 IPsec。另一方面，会话层、表示层和应用层则由云客户负责。虽然 CSP 扮演使能者的角色，但云客户需要负责配置和确保这些层的安全性：

图 8.7 – OSI 模型与云责任

图 8.7 – OSI 模型与云责任

  • TCP/IP 参考模型：该模型是一个广泛使用的框架，用于理解和描述支持互联网以及许多其他网络的网络协议功能。与七层的 OSI 模型不同，TCP/IP 模型由四层组成，每层有自己的协议和责任；然而，它与 OSI 模型紧密对齐。下图展示了 TCP/IP 参考模型的层级划分以及支持的协议。在云环境中，参考模型的较低层，即链路层和CSP，通常处理互联网层。相对而言，客户和 CSP 共同负责传输层，允许客户创建他们的 VPC 子网。通常，管理应用层是客户的责任：

图 8.8 – TCP/IP 参考模型与云责任

图 8.8 – TCP/IP 参考模型与云责任

在下一部分中，我们将探讨对于调查目的至关重要的日志来源，并且还将介绍一些方便的网络分析工具。

云网络取证 – 日志来源与工具

让我们来看一下可以从 CSP 和云实例中获取的一些网络痕迹：

  • VPC 流日志：在前几章（第四章、第五章 和 第六章）中，我们讨论了如何开启和启用 VPC 流日志。这些是调查人员可以访问的最重要的网络调查日志。虽然 VPC 流日志不会捕获完整的网络流量数据包，但分析和确定恶意活动的源节点和目标节点是至关重要的。

  • tcpdump 输出：在 VPC 流日志无法提供帮助的情况下，例如在检查数据外泄和揭示威胁行为者导出的数据时，调查人员需要完整的数据包转储。tcpdump 是一个广泛使用的网络捕获框架，用于收集完整的网络数据包，对于识别网络中的威胁行为者活动至关重要。通过 tcpdump 输出，调查人员可以追踪威胁行为者的活动和会话，确定传输的文件或恶意软件，甚至可以从数据包捕获中重建文件或恶意软件进行进一步分析。通过完整的数据包，调查人员还可以重播并识别环境中被利用的漏洞。

  • 来自云防火墙和 Web 应用防火墙（WAF）的日志：大多数基于云的组织也可能部署云防火墙，即虚拟防火墙实例，或者使用 CSP 的原生防火墙功能（其功能有限）。云防火墙生成详细的网络流量日志，包括允许和拒绝的连接，而 WAF 主要关注与 Web 应用相关的流量，过滤掉恶意请求。分析这些日志可以帮助识别未授权访问、攻击和潜在的漏洞。通过将防火墙和 WAF 日志与其他取证数据（如系统日志和数据包捕获）关联，调查人员可以重建事件，确定漏洞，并了解攻击者的战术。这些日志是云网络取证中的重要证据来源，能够促进迅速、准确的事件检测、响应和缓解措施。

现在我们已经了解了可以用来捕获网络流量信息的工具，让我们来看一个使用其中一种流行网络调查工具的示例。

网络调查工具

DFIR 中的网络调查工具是必不可少的资源，它们使得调查员能够深入分析网络活动、分析流量模式并发现潜在的安全漏洞。例如，调查员可以通过网络识别数据外泄或在云实例上使用恶意代码。这些工具为调查员提供了审查网络数据、识别异常、追踪威胁来源以及重建安全事件发生过程的手段，而无需在事件发生中期直接访问主机。

网络调查不仅可以深入挖掘，还能提供关键的 IoC（Indicators of Compromise，妥协指示器），使调查员能够将其与多个来源进行关联，例如通过使用威胁行为者控制的远程服务器的 IP 地址来进行数据外泄，这些信息随后可以在 SIEM（安全信息和事件管理）工具中追踪，以确定是否存在任何其他的外泄证据。让我们来探索那些在现代 DFIR（数字取证与事件响应）实践中不可或缺的多样化网络调查工具和技术。

Arkime

Arkime（前身为 Moloch）是一个强大的开源网络调查工具，旨在捕获、存储和分析大量网络流量数据。Arkime 为调查员和事件响应人员提供了一个全面的平台，帮助他们调查和理解网络活动、检测异常，并发现潜在的安全威胁。由于其注重可扩展性和灵活性，Arkime 特别适用于在本地和云环境中分析大量的网络流量。

Arkime 提供了多个关键功能，使其成为网络调查中的宝贵工具：

  • 数据包捕获和存储：Arkime 以可扩展和高效的方式捕获和存储网络数据包，使得可以保留大量的历史流量数据供后续分析。

  • 搜索和分析：该工具提供了先进的搜索和过滤功能，允许用户根据各种属性（如 IP 地址、端口、协议和时间范围）查询和分析网络数据。

  • 会话重建：Arkime 可以从捕获的数据中重建网络会话，提供网络节点之间的对话和交互的全面视图，并帮助理解通信的背景。

  • 元数据提取：Arkime 从网络流量和数据包中提取元数据，提供更高级别的通信概览，并促进高效的数据分析。

  • 可视化和报告：该工具可视化网络流量模式，帮助分析师识别趋势和异常。它还支持定制化报告，用于记录调查结果。

  • 定制化和可扩展性：Arkime 允许用户开发自定义插件和解析器，以适应特定的网络协议或应用程序，增强了灵活性和适应性。

  • 与其他工具的集成：Arkime 可以与其他网络和安全工具集成，实现信息的无缝共享和增强的分析能力。

Arkime 能够处理大规模数据分析，并专注于帮助网络调查，使其成为 DFIR 工具包中不可或缺的工具。通过利用其功能，调查人员可以有效地检测、响应并缓解与网络相关的威胁，从而最终增强组织的网络安全态势。让我们来看一个使用 Arkime 从云实例摄取并分析一个示例完整数据包捕获的案例。

使用 Arkime

使用 Arkime 非常简单；它有一个直观的http://<Arkime.ipAddress>:8005：

  1. 下图展示了与 Arkime 一起提供的二进制文件，该文件专门用于离线 PCAP 文件导入——capture：

图 8.9 – Arkime “捕获”用于离线处理 PCAP 文件

图 8.9 – Arkime “捕获”用于离线处理 PCAP 文件

  1. 基于可用选项，我们将使用以下命令行参数将 PCAP 文件上传到 Arkime 进行进一步处理：

    ipv4-address-space.csv (representing IPv4 address space ranges per Regional Internet Registries (RIR)) and manuf files (list of MAC address allocations per the Network Interface Controller (NIC) manufacturers). MAC addresses are unique identifiers that are assigned to NICs for network communication. In incident response, the MAC address helps identify the make of the NIC controller and ultimately determine what computing systems this may have been used, taking it a step closer to the threat actor device.

  2. 一旦上传到 Arkime，我们可以进入 web 浏览器进行调查。下图展示了一个实际的勒索软件攻击案例，该攻击被捕获在云实例上。组织通过镜像其主机的网络流量并将其发送到另一台主机进行记录，捕获了网络流量数据包。下图概述了 UI 和一般功能集。我们可以看到每个会话的活动高峰；你可以按时间切片条目并执行额外的搜索。在页面下半部分的每个条目中，都有一个+选项，可以让你深入挖掘特定的 TCP 会话。它还提供了整个 TCP 流的对话（前提是 TCP 流量是明文的，而不是通过 SSL 流量）：

图 8.10 – Arkime 主界面 – PCAP 文件导入和处理后

图 8.10 – Arkime 主界面 – PCAP 文件导入和处理后

  1. 如下截图所示，调查人员还可以根据要求或流量本身的性质选择解析数据包。它还提供了对数据包进行解码的机会：

图 8.11 – Arkime TCP 会话详情（对话）

图 8.11 – Arkime TCP 会话详情（对话）

如我们从会话的详细视图中看到的，调查人员通常可以查看构成该会话的单个数据包。这包括有关数据包大小、时间戳和数据包负载的信息，这种详细程度对安全分析人员调查网络活动至关重要。现在，让我们转到 Arkime 中的会话感知和过滤功能。

会话感知 – 过滤

本节将介绍会话感知和过滤功能。Arkime 具有 会话和协议信息（SPI）视图。该视图是 Arkime 基于 Web 的界面的关键组成部分，允许用户分析和解析网络会话及其相关协议。以下是调查人员可以利用 SPI 视图的一些用例：

  • 会话列表：SPI 视图提供了 Arkime 捕获并索引的网络会话列表。会话表示源 IP 地址和目标 IP 地址及端口之间的网络数据包序列。

  • 会话详情：点击列表中的特定会话，可以查看该会话的详细信息。这些信息包括源和目标 IP 地址、源和目标端口、使用的协议、数据包捕获细节等。

  • 协议分析：Arkime 的 SPI 视图通常提供协议特定的信息。这意味着你可以根据协议分析网络会话，包括 HTTP、DNS 和 FTP。这有助于识别可疑或恶意活动。

  • 过滤器和搜索：就像 Arkime 的其他视图一样，SPI 视图允许你应用过滤器和搜索条件来缩小你感兴趣的会话范围。当你处理大量捕获的网络数据时，这非常有用。通过 SPI 视图和 IP 地址列表，调查人员可以导出属性的详细信息，并对每个指标执行威胁情报搜索，以获得更多信息。以下是一些过滤功能：

    • 简单过滤器：你可以基于简单的属性（如 IP 地址、端口、协议和时间戳范围）来过滤会话。例如，你可以过滤出涉及特定 IP 地址的所有会话，或者过滤出发生在特定时间范围内的会话。

    • 组合过滤器：Moloch 的查询语言允许你使用逻辑运算符（AND、OR、NOT）组合多个条件，以创建更复杂的过滤器。这帮助你将注意力集中在特定场景上。

    • 正则表达式：你可以使用正则表达式匹配会话属性中的模式。例如，你可能希望过滤出包含特定关键字的 URL 会话。

    • 自定义字段：Arkime 允许你定义并使用自定义字段，这些字段可以从会话数据中提取，或在数据导入过程中添加。然后，你可以根据这些自定义字段过滤会话。

    • 保存的查询：一旦你构建了一个有用的过滤器，你可以将其保存为一个命名查询，以便将来轻松重用。

  • 会话图：根据 SPI 视图的功能，你可能还可以访问会话数据的可视化表示，例如显示主机间通信流的图表。

  • 威胁检测：安全分析人员经常使用 Arkime 的 SPI 视图来检测网络流量中的潜在威胁或异常。异常模式、意外协议或可疑有效载荷可能表明恶意活动。

以下截图显示了一个示例 PCAP 文件。这里，Arkime 会分解会话和协议，并深入分析每个数据包。如我们所见，SPI 视图分解了目标 IP 和其他协议。每个结果都可以点击，进行进一步分析：

图 8.12 – Arkime 的 SPI 视图，用于会话和协议分析

图 8.12 – Arkime 的 SPI 视图，用于会话和协议分析

总结来说，Arkime 是一个强大的工具，可以帮助调查人员解析网络流量。它还具备强大的数据增强功能。例如，Arkime 可以集成 IP 地理位置数据库来确定源 IP 的位置。Arkime 还允许与其他威胁情报源进行集成。另一个特点是，它提供内容提取功能，意味着你可以从 Arkime 下载文件进行进一步的人工分析。

Wireshark/tcpdump

tcpdump 和 Wireshark 是在 DFIR 中常用的强大工具，用于捕获和分析网络流量。这两款工具具有相似的用途，但在特性和使用场景上有所不同。通常，这些工具用于从网络调查的角度反向工程网络协议。

tcpdump

tcpdump 是一个命令行数据包分析工具，能够实时捕获网络数据包或从先前捕获的文件中提取数据包。它在网络栈的较低层运行，能够以非常细致的方式捕获数据包，包括以太网帧、IP 数据包、TCP/UDP 段等。它通常用于网络监控、故障排除和安全分析。在 DFIR 中，tcpdump 对于事件响应期间的实时数据包捕获特别有用，能够捕获网络流量并供后续分析。

从网络调查的角度来看，有时调查人员没有完整的云访问权限来设置数据包镜像服务，无法将受感染的云实例的所有数据包镜像到该组织租户下的另一实例。如果对这些工具有了解，确实有助于在访问配置元素受到限制时准备和启动网络捕获。

调查人员可以使用 sudo tcpdump 命令启动完整的数据包转储（你需要管理员权限）。图 8.13 显示了没有任何过滤器的 tcpdump 转储的示例输出，展示了以下字段：

  • HH:MM:SS.微秒。

  • t2.lan.ssh 是发送数据到 dfirlab.lan.27018 的源 IP/端口，而 dfirlab.lan.27018 是发送数据到 t2.lan.ssh 的源 IP，作为响应。

  • [P.] 表示数据包携带应用数据（PUSH 标志已设置），而 [.] 表示常规确认（ACK 标志已设置）。

  • seq 188:440 表示数据包中数据的序列号范围从 188 到 440。这个序列号用于跟踪数据包的顺序。seq 6000:6256 表示后续的序列号范围。

  • ack 1 表示下一个预期字节的确认号。ack 1148 是已接收数据的确认。

  • win 4097 和 win 501 表示接收窗口大小，即接收方可以缓冲的数据量。

  • length 252 表示数据包的负载长度。

请注意，你必须明确指定文件名，将数据包捕获到磁盘中的 PCAP 格式文件中以供离线分析：

图 8.13 – tcpdump 实际操作

图 8.13 – tcpdump 实际操作

  • TCP dump 过滤器：调查人员应熟悉 tcpdump 过滤器。当在捕获过程中应用这些过滤器时，它们将仅收集符合过滤条件的网络数据包。对于 tcpdump，使用的是 Berkeley 数据包过滤器（BPF），它允许进行低级过滤，并指定捕获特定数据包的要求。

    下图展示了使用 BPF 过滤器捕获特定网络数据包的示例——即，sudo tcpdump -i <interface_name> proto 17。在这个示例中，我们根据协议号 17 过滤数据包，协议号 17 指的是 UDP 流量：

图 8.14 – 使用 BPF 过滤器的 tcpdump

图 8.14 – 使用 BPF 过滤器的 tcpdump

让我们来看一下一个更直观的数据包捕获软件——Wireshark。它具有非常相似的功能；然而，你可以在捕获数据包时进行实时分析。

Wireshark

另一方面，Wireshark 是一个用户友好的图形化网络协议分析工具。它提供了详细、丰富的视觉界面，用于检查捕获的数据包。Wireshark 可以直接打开并分析 tcpdump 捕获文件和来自网络接口的数据包。它比 tcpdump 在更高的抽象层次上操作，以更易于理解的格式呈现解剖和解码后的网络协议。调查人员广泛使用 Wireshark 来分析网络流量，寻找恶意活动、网络异常和数据泄露的证据。下图展示了 Wireshark 用户界面的简易视图：

图 8.15 – Wireshark 用户界面

图 8.15 – Wireshark 用户界面

Wireshark 提供了许多功能来过滤数据包并通过其 UI 解析它们，且有清晰的信息说明如何处理和过滤数据包信息。某些备忘单已在本章的 进一步阅读 部分提到。

CyberChef

CyberChef 是一个强大的基于 Web 的工具，广泛应用于各种数据处理任务，尤其在网络安全和数字取证中有着重要作用。它提供了一个用户友好的界面，并包含用于编码、解码、转换和分析各种格式数据的配方。在网络调查的背景下，CyberChef 对于处理和分析与网络相关的数据非常有用。以下是 CyberChef 在网络调查中的应用：

  • 数据转换：网络调查人员经常会在网络流量中遇到编码或混淆的数据。CyberChef 提供了多种数据转换操作，例如 base64 编码/解码、URL 编码/解码、XOR 操作等。这些转换可以帮助调查人员揭示网络数据包中隐藏的信息。

  • grep 函数可以在流量中搜索特定的模式、头信息或关键词。这有助于识别重要的细节，如 IP 地址、域名或文件路径。

  • 哈希和加密：CyberChef 支持各种哈希和加密/解密技术。调查人员可以对字符串或文件进行哈希处理，检查是否与已知的恶意哈希匹配。此外，如果能够访问所需的密钥，他们还可以尝试解密加密的数据。

  • 解析和解码协议：通过自定义配方，CyberChef 的功能可以扩展。调查人员可以创建配方，解析和解码网络协议，如 HTTP、DNS 和 SMTP。这有助于从协议头信息和负载中提取有意义的信息。

  • 文件切割：如果网络流量包含文件传输，CyberChef 可以用于检索和重建文件。这在调查潜在的数据外泄或恶意软件传播时特别有用。

  • 数据可视化：CyberChef 可以帮助可视化数据转换和处理，使我们更容易理解数据在网络中传输过程中是如何变化的。数据可视化有助于识别异常或可疑的模式。

  • 自动化工作流：CyberChef 允许用户创建并保存配方，从而实现重复数据处理任务的自动化。这可以显著加快调查过程，并确保数据处理的一致性。

  • 协作与共享：CyberChef 配方可以在调查人员之间共享，允许团队成员之间进行协作和知识共享。这可以帮助经验较少的团队成员从其他成员的专业知识中受益。

  • 快速分析：对于小规模数据的快速分析，CyberChef 的简易界面可以提供即时的洞察，无需复杂的脚本或编程。

下图展示了 CyberChef 使用的一个示例。如前所述，CyberChef 提供了预定义的食谱（算法）来解析给定的数据集。它是网络调查人员和数字取证调查人员的一个有用工具。在这个示例中，我们从 AWS 导出了日志，并在 CyberChef 中解析它。日志导出为 JSON 格式；如果导出的数据需要正确格式化，阅读起来可能会有些棘手。一旦定义了食谱，调查人员可以拖放证据并查看输出结果：

图 8.16 – CyberChef 使用示例

图 8.16 – CyberChef 使用示例

正如我们所看到的，CyberChef 是一个使调查人员能够扩展其能力和创造力的工具，用于解决调查挑战。CyberChef 自带预定义的食谱，而其他调查人员也发布了一些食谱组合，可以应用于应对复杂的取证情况。我们在本章的进一步阅读部分中为您提供了备忘单，供参考。

在接下来的部分，我们将转向恶意软件调查。虽然关于这个话题可以写一本书，但下一部分的目的是为恶意软件调查概念提供一个快速复习，并说明如何在通过主机或网络取证调查捕获一些证据后，探索其中的部分信息。我们将介绍如何设置实验室环境，以及一些在调查过程中可能会用到的基本工具。

恶意软件调查

恶意软件调查是任何事件响应中的关键组成部分，涉及识别、分析和应对环境中恶意软件的系统化过程。恶意软件调查的主要目标是了解恶意软件的性质、潜在影响及其渗透的程度。这些信息对于做出有关隔离、根除和恢复的决策至关重要。

恶意软件分析师进行深入分析，剖析恶意软件的代码和行为，以揭示其功能、通信方式以及可能被利用的漏洞。这些信息有助于了解危害的程度，并帮助制定相应的对策。影响评估评估恶意软件造成的损害，包括被侵害的数据和受影响的系统，以便优先处理响应行动。

随后是消除阶段，即使用定制的病毒特征码清除恶意软件、删除文件和修补漏洞。消除后，恢复工作开始，并对事件响应过程进行评估，将经验教训整合到未来的策略中。对于需要法律行动或更深入理解的情况，法医分析保留证据，记录攻击细节，并促进与执法部门的潜在合作。这个全面的过程确保了对恶意软件事件的彻底和有效应对，保护了组织的完整性和安全性。

在云环境中，恶意软件分析引入了独特的挑战和考虑因素，因为云计算具有分布式和动态的特性。基于云的恶意软件分析是在云平台上托管的虚拟化或容器化环境中检查恶意软件。

如我们所见，恶意软件分析紧跟事件响应过程，提供对遏制和消除威胁至关重要的关键指标。

然而，为了进行恶意软件分析，你需要一套专门的工具和完全隔离的环境，以确保调查人员不会在其设备上引爆恶意软件，从而泄露调查信息的工作文件。因此，恶意软件分析总是在实验室环境中进行。

搭建你的恶意软件分析实验室

在本节中，我们将讨论如何搭建恶意软件分析实验室的基本架构。对于本地实验室，恶意软件分析师通常使用虚拟基础设施，以便于拆除和重建新的设置。一旦恶意软件在实验室中被引爆，它会留下痕迹或遗留物，必须仔细研究。同样，调查人员也可以在云中搭建恶意软件实验室。然而，如果你在云中引爆恶意软件，必须确保它不会危及到其他租户，并确保恶意软件实验室是被封锁的。

以下图示展示了搭建恶意软件分析实验室的示例和一些关键组件。如前所述，调查人员在处理恶意软件及其相关遗留物时必须格外小心。恶意软件是活跃的，也可能感染或危及调查人员的计算机。因此，大多数调查人员将在实验室中操作恶意软件。这类似于处理炸丨药并确保它不会造成损害。在下图中，每个连接都通过防火墙进行保护，并且不允许直接访问引爆虚拟机。这是逆向工程师可以探索恶意软件并理解其功能的地方：

图 8.17 – 恶意软件分析实验室架构

图 8.17 – 恶意软件分析实验室架构

以下是实验室的一些关键组成部分：

  • 防火墙：任何防火墙，无论是物理的还是虚拟的，都应该是有效的。所有通往恶意软件托管虚拟机的网络连接都应得到安全保护和过滤。在我们的示例中，我们使用 pfSense，它是一个流行的防火墙设备，也可以进行虚拟部署。如果你计划在云中设置实验室，可以部署类似的防火墙。在此示例中，防火墙及其子网确保恶意软件实验室仅能通过特定的端口转发访问，而不能在内部网络中广泛访问。

  • 恶意软件库：一个专用的应用程序，带有一个数据库，可以安全地存储恶意软件。我们使用基于 Python 的 Viper 框架应用程序，它支持文件和静态恶意软件分析。它还包含一个数据库，用于存储恶意软件，并帮助整理恶意软件和漏洞样本。

  • 引爆虚拟机：这些是专用虚拟机，托管在一个独立的子网中，用于引爆恶意软件或允许逆向工程师探索恶意软件的内部工作原理。需要注意的是，调查人员必须安全配置恶意软件虚拟机，所有网络连接都必须小心允许。例如，在引爆恶意软件时，如果需要连接到互联网，在允许互联网访问恶意软件时必须谨慎。引爆虚拟机可以是预先构建的；你可以使用任何免费的开源恶意软件分析虚拟机，例如基于 Linux 的Remnux或SANS SIFT 工作站，或者你可以根据自己的工具来构建一个。你还可以基于 Windows 构建，如 Mandiant 的Flare VM，它提供脚本来设置必要的软件并加强虚拟机的安全性。你还可以直接从微软下载 Windows 10 或 Windows 11 的限时版本，免费提供 90 天许可证，到期后可以重新安装。这样可以确保你的 Windows 和恶意软件分析工具始终保持最新。

  • Apache Guacamole：Apache Guacamole 是一个开源的远程桌面网关，提供基于 Web 的远程桌面和应用程序访问。它允许用户通过网页浏览器会话访问桌面环境和应用程序，而无需在客户端安装额外的软件。Guacamole 支持多种远程桌面协议，如 VNC、RDP 和 SSH。使用 Apache Guacamole 的最大好处是可以实施额外的控制措施，例如限制复制粘贴以及限制网络驱动器和打印机的访问权限。这一点至关重要，因为你不希望恶意软件扩散或跳出虚拟机的安全网络区域。

  • 恶意软件分析虚拟机：这是专门用于通过 Apache Guacamole 通过网页浏览器会话安全访问恶意软件网络的。访问恶意软件实验室时，始终建议使用专用工作站来访问该实验室环境，并且不得用于其他任何目的。

调查人员还可以选择通过利用免费的开源工具，在云中部署类似架构进行恶意软件分析。如果需要搭建一个更大的恶意软件分析工作台，也可以部署不同版本的恶意软件分析架构。一个例子是日本的 JPCERT 团体，他们开发了一种架构，将实验室部署到云端进行内存取证和分析。JPCERT 的内存取证实验室的链接可在 进一步 阅读 部分找到。

让我们深入探讨一些调查人员在处理打包恶意软件及同一恶意软件的多个版本时经常遇到的常见特征。

处理打包恶意软件

恶意软件逆向工程师遇到的主要挑战之一就是打包恶意软件。打包工具是企业和威胁行为者用来压缩和加密代码的工具。在威胁背景下，恶意软件代码被打包并部署在一个环境中，使得逆向工程师更难分析。请注意，我们使用了 更难 而不是 不可能。威胁行为者的目标是让检测和研究变得更加困难，从而使得调查人员无法在威胁对组织造成严重影响之前，创建出检测包。这些打包工具有助于混淆代码，使得理解恶意软件的功能变得困难。历史上，一些打包工具被调查人员频繁观察到，并且是威胁行为者的首选：

  • Ultimate Packer for eXecutables（UPX）：这是一款非常流行且广为人知的可执行文件打包工具。UPX 是一个开源工具，可以保护可执行文件包。解包 UPX 打包的可执行文件相对简单。任何常用的 便携式可执行文件（PE）分析器都能检测到一个给定的可执行文件是否被打包。以下图示展示了一个现实世界恶意软件的左右对比；左侧是 UPX 打包的文件，右侧则是未打包或未压缩的文件。请注意每个部分的大小。记住，UPX 会压缩恶意软件二进制文件；因此，未打包的二进制文件的大小和内存地址位置会有所不同。虽然这是一个简化的版本，但复杂的威胁行为者可以通过应用多个打包层次或多种打包工具使其变得更加复杂：

图 8.18 – UPX 打包与未打包恶意软件对比

图 8.18 – UPX 打包与未打包恶意软件对比

  • Armadillo: Armadillo 是一种商业打包工具，采用了代码加密、虚拟化、反调试措施和动态解包等技术，以防止可执行代码被逆向工程和分析。尽管其目的是用于合法用途，但威胁行为者利用其功能来模糊恶意软件，使得安全研究人员的研究和检测工作变得更加具有挑战性。

  • Themida：Themida 是一款商业软件保护工具，通常由软件开发人员用于保护他们的应用程序免受逆向工程和未经授权的访问。像 Armadillo 一样，它采用了复杂的技术，如代码混淆、加密和反调试措施，使研究人员很难破解打包代码的功能。此外，Themida 还提供了反篡改机制和虚拟化技术，进一步增强了保护功能。尽管最初是为了合法目的设计的，但我们已经看到威胁行为者将 Themida 重新用于隐藏恶意软件并使安全解决方案的检测更加复杂。

尽管处理恶意软件打包工具可能会很棘手，但调查人员必须记住，无论什么样的代码在内存中执行，打包过的代码总有一个解包和解码的过程，然后才会在内存中运行。无论威胁行为者使用什么打包工具，逆向工程师可能选择手动调试打包的恶意软件，揭示其解包后的代码，并调整其他相关参数，以便进一步分析恶意软件。

调查人员常常遇到的另一个具有挑战性的情况是同一二进制文件的多个版本。这引发了关于威胁行为者可能部署了多少版本以逃避检测的担忧；处理同一二进制文件的不同版本增加了调查的复杂性。

二进制比较

二进制比较是计算机科学和软件工程中用于确定两个二进制文件之间差异的过程，这些文件包含编译后的代码或机器可读的数据。此比较涉及分析文件的各个字节或位，以识别内容、结构和代码序列的变化，或通过评估控制流图（CFG）来进行比较。二进制比较通常用于版本控制、软件调试、恶意软件分析和数字取证等任务。通过识别二进制文件之间的差异，开发人员、分析师和研究人员可以了解代码的变化、跟踪修改、检测篡改，并发现恶意软件能力的潜在变化。以下屏幕截图展示了一个 Windows 程序的 CFG 格式示例，展示了程序中的各种决策树、跳转点、网络访问和复杂性。我们使用一款名为 ProcDot 的免费开源工具来进行此操作。以下截图仅供说明，展示代码的复杂性：

图 8.19 – 应用程序 CFG 的压缩视图，包含读写路径

图 8.19 – 应用程序 CFG 的压缩视图，包含读写路径

CFG 是计算机科学和软件工程中用于可视化程序或软件应用程序中控制流的图形表示。它通过描绘程序的基本块（具有单一入口点和单一出口点的代码段）及其之间的连接，展示程序执行可能采取的各种路径。每个基本块通常对应一系列按顺序执行且没有分支的指令。CFG 使用节点表示基本块，使用边表示基本块之间的控制流，指示程序可以根据条件或循环结构在不同的代码部分之间进行分支或跳转。CFG 特别有助于理解程序行为、分析代码路径、检测潜在的错误或漏洞，尤其在比较可执行文件的相似版本时非常有用。它们通常用于程序分析、优化、调试和安全研究。接下来，我们将看看一些用于比较二进制文件的专业工具。

BinDiff

BinDiff 是由 Zynamics 开发的软件比较工具，Zynamics 是一家被 Google 收购的公司。BinDiff 主要用于分析和比较二进制文件，如可执行文件、库文件以及其他编译后的代码。它广泛应用于逆向工程和恶意软件分析，用于识别软件版本之间的相似性与差异，或在不同的二进制文件中寻找共同的代码模式。

总结来说，虽然我们回顾了一些用于恶意软件调查的基本工具，研究人员开发了各种工具，调查人员必须保持与时俱进，以便在发现需要专门工具的复杂恶意软件时能够利用它们。了解市场上有这些工具，比单纯了解工具本身更为重要。鉴于威胁行为者不断改变恶意软件的创建方式以使我们难以应对，保持对恶意软件开发者所使用的技术、方法和概念的跟进非常重要。在接下来的部分，我们将比较传统取证与云取证，并揭穿一些常见的误解。

传统取证与云取证

传统取证与云取证在事件响应中扮演着关键角色，但由于其所针对的环境不同，它们在重点和方法上存在差异。

它们的相似之处如下：

  • 证据收集：传统和云取证都涉及收集和保存数字证据，以重建导致事件的过程。这可能包括收集内存转储、日志文件、网络流量和文件系统痕迹。调查人员通常使用云存储来存储大量的痕迹，无论底层的 CSP 是什么，因为大多数数据泄露事件都涉及 CSP 的云租户。在怀疑底层 CSP 已被攻破的情况下，建议调查人员将所有必要的痕迹保存到不同 CSP 的存储中或离线进行分析。

  • 分析技术：这两个领域采用类似的技术来分析数字证据，如检查文件结构、元数据、时间戳和内存内容，以了解事件的时间线和范围。

  • 证据链：在两种情况下，维护证据链至关重要，以确保证据的完整性和在法律程序中的可接受性。

以下是它们的区别：

  • 环境：传统取证涉及物理设备，如计算机、服务器和移动设备。与此不同，云取证侧重于虚拟化和分布式环境，包括基础设施即服务（IaaS）、平台即服务（PaaS）和软件即服务（SaaS）。

  • 证据位置：在传统取证中，证据通常存储在物理设备上。云取证中，证据可能分布在多个虚拟实例和存储服务中，需要采用不同的收集和保存技术。

  • 数据所有权：由于云中的共享资源，数据的所有权和控制可能变得复杂。确定哪一方负责维护和提供证据访问可能更加具有挑战性。

  • 数据驻留：数据可能存储在云中的不同地理位置，这可能影响不同司法管辖区的法律和监管考虑。

  • 网络流量：在传统取证中，捕获网络流量相对简单。由于虚拟化网络和第三方服务的存在，在云环境中可能更难访问网络流量。

  • 日志和审计：云环境通常提供广泛的日志记录和审计功能，提供更详细的活动信息。然而，访问和解读这些日志可能会很复杂。

  • 资源共享：在云环境中，多个租户可能共享相同的物理硬件，这会影响证据的隔离和保存。

  • 事件响应工具：由于架构差异以及需要专门针对云取证定制的工具，传统事件响应工具可能无法完全适用于云环境。

  • 法律和合规性：由于司法管辖区问题、跨境数据传输和不同云服务提供商的条款，云取证可能涉及额外的法律和合规性挑战。

总结来说，尽管传统取证和云取证在证据收集和分析的基本原则上是相似的，但云取证引入了与云环境虚拟化和分布式特性（如容器化和无服务器架构）、共享资源以及与云相关的法律问题等方面的复杂性。事件响应人员和数字取证专家必须调整他们的实践，以有效应对传统系统和基于云的系统中的事件。

总结

正如我们在本章中所见，事件响应过程和威胁狩猎的基本原则大致相同，主要集中在寻找环境中的恶意行为。根据操作系统的不同，调查人员可以自定义应该收集哪些日志和证据，以及必须调查哪些内容。我们还看到，EDR（端点检测与响应）部署如何加速安全事件的控制和响应过程。请记住，事件响应过程是一项严谨的工作，调查人员需要严格遵循，以确保执行所有调查步骤。与此同时，事件被控制，并且不会对组织或被调查的终端设备带来进一步的风险。虽然本章的目的是介绍各种数据泄露调查的要素，但无疑建议调查人员保持对最新调查工具和技术的了解。

在下一章中，我们将探讨如何从云环境中收集这些证据。考虑到从云环境中收集必要证据的难度，我们将查看各种云服务提供商及其对收集取证包的支持。我们还将探讨在云中导出完整磁盘镜像与快速取证收集的选项。

深入阅读

第九章：常见攻击向量和 TTP

随着组织日益依赖云基础设施，安全团队和事件响应人员发现自己面临云中一些独特的漏洞和攻击模式。攻击者利用这些漏洞，并使用有时特别针对云环境定制的 战术、技术和程序 (TTPs)。

本章深入探讨云中的这些常见攻击向量，提供了有助于提升和完善我们应对日益演变的威胁的响应策略的见解。配置错误的虚拟机实例和存储桶、未保护的 API 端点以及不充分的身份验证协议仅仅是威胁行为者所针对的一些漏洞。为了利用这些弱点，攻击者使用从权限提升和服务器端请求伪造到针对云基础设施量身定制的零日漏洞等多种 TTP。理解这些特定的威胁对于云安全和有效的事件响应至关重要。

具体而言，本章将讨论以下主题：

  • MITRE ATT&CK 框架

  • 取证初步收集

  • 主机基础的取证

  • 配置错误的虚拟机实例

  • 配置错误的存储桶

  • 云管理员门户漏洞

云中的攻击向量和 TTP 在大多数情况下与本地环境中的攻击向量和 TTP 相似。然而，云的去中心化特性引入了独特的漏洞。配置错误的虚拟机实例可能暴露整个虚拟环境，而未妥善保护的存储桶可能成为数据泄露的入口。云的可访问性带来了诸如身份验证机制薄弱等问题，这可能导致未经授权的访问。虽然网络安全的核心原则保持一致，但这些以云为中心的问题需要特别的关注和理解。

重要提示

我们将在第十二章中更详细地讨论云生产力套件的常见攻击向量和 TTP（战术、技术和程序）。

MITRE ATT&CK 框架

MITRE ATT&CK 框架是一个基于安全研究人员的实际观察构建的攻击者战术和技术的知识库。它是安全团队用来更好地理解攻击行为，并改进防御和响应策略的工具。在云环境的背景下，MITRE ATT&CK 框架列出了对 云服务提供商 (CSPs) 如 AWS、Azure 和 GCP 等进行攻击时对手使用的特定技术。

MITRE ATT&CK 框架对于云取证特别有用，因为它使响应人员能够预见攻击者的行为，并据此规划他们的取证调查。通过与此框架对齐，组织可以识别其防御态势中的空白，更好地了解如何检测、响应和缓解特定于云的威胁。

在云基础设施范围内，MITRE ATT&CK 框架提供了一张已知攻击者 TTP（战术、技术和程序）矩阵，其中包括但不限于以下内容：

  • 初始访问：通过各种入口向量进入云环境的技术。例如，利用公共应用程序漏洞（T1190）可能与云中托管的 Web 应用程序的漏洞相关。

  • 执行：执行阶段包括导致对手控制的代码在本地或远程系统上运行的技术。这可能涉及服务器软件组件（T1505），其中攻击者可能通过 Web 服务器插件执行代码。

  • 持久性：在云中，攻击者通常利用某些功能保持在环境中的登录状态，例如在创建云实例（T1578）中，攻击者会在现有帐户中创建一个新实例以维持其操作。

  • 特权升级：允许对手在系统或网络中获得更高权限的技术。例如，滥用提升控制机制（T1548）可能涉及攻击者利用过度宽松的身份和访问管理（IAM）角色。

  • 防御规避：这涉及对手使用的技术，以避免在整个入侵过程中被检测到。诸如禁用安全工具（T1562）之类的技术，可能用于关闭云中的监控和日志记录功能。

为了进一步说明 MITRE ATT&CK 框架如何适用于云攻击场景，考虑以下示例：

  • 配置错误和未授权访问（T1580）：正如本章后面讨论的那样，攻击者通常会利用云存储服务中的配置错误，例如 AWS S3 桶或 Azure Blob 存储。通过枚举这些服务并利用开放权限，攻击者可以读取、修改或删除存储在这些资源中的敏感数据。

通过将 MITRE ATT&CK 框架融入云安全实践中，组织可以更有效地构建应对事件的策略，并使其取证工作与行业标准的命名法和战术保持一致。这样做不仅增强了事件响应计划，还与全球最佳实践接轨，帮助确保对云攻击的防御更加坚韧。

事件响应人员可能需要将所有取证结果映射到 MITRE 编号，并以易于理解的表格形式呈现，帮助防御团队更好地了解攻击是如何在其环境中发生的。例如，以下表格展示了一个假设云被攻破的 MITRE ATT&CK 表格示例：

MITRE ATT&CK 技术编号 技术名称 描述
T1190 利用面向公众的应用程序 攻击可以从互联网访问的服务器或服务，以获得访问权限。例如，攻击者可能会针对暴露在互联网上的特定 Web 应用程序或服务，如托管在云中的 Web 门户或 API 网关。重点通常是利用 Web 模块或应用程序代码中的漏洞，获得对底层云资源或敏感数据的未授权访问。
T1136.003 使用服务主体 创建或破坏云身份以维持对云资源的访问。可能涉及创建或劫持云身份服务，例如 Azure AD 服务主体或 AWS IAM 角色。攻击者可能创建虚假身份或破坏现有身份，以获得持久的云资源访问权限，从而能够访问或操控工作负载和服务。
T1580 云基础设施发现 扫描云服务和资产的信息，以规划进一步的攻击。攻击者通常会对云环境进行侦察，针对特定的云服务，如 AWS EC2 或 Azure 虚拟机。他们会扫描暴露的 API、不安全的存储桶或配置错误的云资源，以识别潜在的入口点或有价值的数据。
T1078 有效账户 使用被盗账户凭证访问云系统，获取未授权访问权限。
T1090 代理 利用中介系统掩盖恶意流量的来源。攻击者使用基于云的中介服务或虚拟机作为代理，隐藏其来源。这种技术可能涉及启动云实例来转发恶意流量，使其更难追溯到源头。
T1526 云服务仪表板 访问云服务管理界面进行控制或侦察。通过访问云管理界面，例如 AWS 管理控制台或 Azure 门户，攻击者可以监控和控制云资源。这可能涉及跟踪工作负载、修改配置或获得有关安全控制的见解。
T1548.004 云服务滥用 利用云服务或资源来支持恶意操作。
T1562.007 禁用或修改云防火墙 修改或禁用基于云的防火墙，以允许恶意流量或阻止安全响应。攻击者修改或禁用基于云的防火墙，如 AWS WAF 或 Azure 防火墙，以允许恶意流量或阻碍安全响应。这可能涉及更改规则以允许访问特定端口或服务，或禁用关键云资产的保护措施。
T1578 修改云计算基础设施 对云计算服务（如实例和虚拟机）进行更改，以建立持久性或提升特权，并对云计算服务进行未经授权的修改，如修改虚拟机配置或向容器化应用程序注入恶意代码。此技术旨在建立持久性、提升特权或在云环境中创建后门。
T1583 获取基础设施：云账户 购买或以其他方式获取云账户以用于恶意目的。
T1608.001 数据外泄阶段：云存储 将被盗数据放入云存储服务以准备外泄，以及将被盗或非法获取的数据放入云存储服务，如 Amazon S3 存储桶或 Azure Blob 存储，以准备外泄。这个步骤通常在大规模数据泄露或数据盗窃操作之前进行，利用云服务进行妥协数据的暂存和传播。

表 9.1 – 事件 MITRE ATT&CK 表示例

重要说明

所有攻击者的 TTP（战术、技术和程序）都可以在 ATT&CK 框架中映射到相应的编号。可以在 MITRE 组织网站找到：attack.mitre.org/。

法医筛查数据收集

事件响应者面临的最大痛点之一是个体主机级别的数据获取，尤其是当涉及到操作系统的相关痕迹时。像 Azure、AWS 和 GCP 这样的云服务平台（CSPs）提供了各种日志机制，帮助监控和审计其资源上的操作。然而，这些日志通常只捕获与基础设施或服务相关的活动。默认情况下，它们不会捕获与用户活动或操作系统级别的系统操作相关的细节（除非使用连接到云生态系统的 EDR 代理，如 Microsoft Defender for Endpoint）。即使是在涉及云资源的网络事件中，实际情况是，大多数事件的妥协指示符（IoCs）将来自主机级别的痕迹。

正如我们在本书中所看到的，云日志源主要关注云资源的交互。这意味着像特定的 Windows 事件日志、文件修改、内存操作和用户命令执行等详细的主机级活动，默认情况下并不会被捕获（即无法从云中访问）。唯一的例外是，如果主机文物和日志已被设置为转发到如 AWS CloudWatch 或 Azure Log Analytics 工作区等云服务中。很可能，事件响应者会遇到一个需要捕获所有主机级取证文物的事件（即托管在云环境中的虚拟机实例）。操作系统文物提供了虚拟机实例上发生的事件的更详细画面，通过分析多个虚拟机实例，可以帮助事件响应者理解其云基础设施在事件中受影响的程度。

这些文物可能包括以下内容：

  • 文件系统元数据：有关文件创建、修改或删除的详细信息

  • 内存文物：有关正在运行的进程、网络连接和加载模块的信息

  • 注册表文物（适用于 Windows）：关于已安装应用程序、用户活动和系统配置的详细信息

  • Shell 历史记录（适用于 Linux）：命令执行历史记录，可以提供用户活动的线索

  • 应用程序日志：特定的应用程序可能会生成日志，但这些日志未被 CSP 捕获或汇总

由于这些文物在 CSP 中缺失，因此必须使用像Kroll Artifact Parser and Extractor（KAPE，www.kroll.com/en/services/cyber-risk/incident-response-litigation-support/kroll-artifact-parser-extractor-kape)或Collect Your Logs Remotely（CyLR）这样的工具进行分类和取证分析。

KAPE 和 CyLR 都是免费的分类工具，能够快速收集和处理取证相关文物。它们具有高度可定制性，使事件响应者能够根据网络事件的性质有针对性地捕获特定文物。它们轻量级，不需要太多计算能力即可在系统上运行。

重要提示

KAPE 在用于第三方网络和/或作为付费合作的一部分时需要企业许可证。对于任何地方、州、联邦或国际政府机构，以及教育和研究用途，KAPE 是免费的。

您可以在www.kroll.com/en/services/cyber-risk/incident-response-litigation-support/kroll-artifact-parser-extractor-kape/下载 KAPE 并查找其使用说明。

你可以下载 CyLR 并在 GitHub 上找到其使用说明，地址为github.com/orlikoski/CyLR/。

基于主机的法医

在云环境中，主机指的是运行用户应用程序并作为用户和应用程序活动终端的虚拟或物理机器。它可以是单个服务器、虚拟机或容器，具体取决于所使用的云模型。在传统的本地环境中，主机通常指的是有形的物理服务器或机器，但在云中，主机可能是临时的，并会根据需求和要求快速创建或销毁。

重要提示

本章我们将集中讨论基于 Windows 的系统。Linux 系统将具有不同的主机相关文物，可以进行收集和分析。

基于主机的云法医聚焦于从这些单独的主机或终端获取并分析数据，旨在识别入侵迹象、横向移动、恶意代码执行和其他 TTP（战术、技术和程序）。由于主机是应用程序执行的主要点，并且通常是攻击者的入口或枢纽点，因此它是一个丰富的法医数据来源。

Windows 操作系统中的几个文物可以提供关于主机上活动的大量信息：

  • 预取：这用于加速 Windows 启动过程和应用程序启动时间。通过检查预取文件，事件响应者可以确定主机上执行了哪些程序以及何时执行。

  • AmCache：AmCache 包含有关已执行应用程序的信息，可以提供有关程序执行和用户活动的见解。

  • ShimCache：也称为应用程序兼容性缓存，ShimCache 包含最近执行的应用程序列表。它对于了解系统上运行了什么，特别是在系统重启后，因为一些其他文物可能已经被清除，非常有价值。

  • Windows 事件日志：这些日志，尤其是安全、系统和应用程序日志，可以提供关于安全相关事件、系统启动、关机、应用程序崩溃等的大量信息。它们对识别与潜在安全事件相关的模式至关重要。

还有许多其他文物可以进行分析，但从事件响应者的角度来看，这些是最有用的。我们将利用这些文物分析本章中讨论的云资源上的常见入侵。

重要提示

预取、AmCache、ShimCache 和 Windows 事件日志是 KAPE 和 CyLR 收集的众多文物之一。

分析基于主机的日志过程可以分解为以下几个步骤：

  1. 日志收集：收集目标主机的数据。这是提取所有必要条目以供分析的初步步骤。这些日志在生成法医筛查包时也会被捕获。

  2. 数据准备：使用解析工具将原始数据转换为可读和可分析的格式。

  3. 分析与关联：这包括考虑用户活动、文件路径、执行标志、文件修改时间以及文件大小/属性等关键方面，以识别任何异常或警示信号。将日志数据与其他取证物证交叉引用，以便在更广泛的调查范围内将发现进行背景化。

  4. 结果：记录分析结果，识别任何潜在的入侵指示。根据发现，确定适当的响应措施，这可能包括进一步的详细调查、系统修复或启动安全协议以防止未来的安全漏洞。

这些步骤可以通过以下流程图来可视化：

图 9.1 – 基于主机的取证分析过程

图 9.1 – 基于主机的取证分析过程

入侵证据

确定执行证据通常是确定主机系统入侵证据的关键初步步骤。在寻求系统妥协和随后的利用过程中，威胁行为者经常试图执行未经授权的应用程序，特别是恶意软件，以建立立足点或获取提升的权限。这些应用程序的未经授权执行可以作为泄露或入侵的明确指示。

为了确定这种未经授权的执行，事件响应者依赖于某些内在的物证，如 Prefetch、AmCache 和 ShimCache。这些物证存储有关已执行程序的数据，为应用程序执行历史提供了宝贵的见解。通过细致分析这些物证，专业人员可以发现任何指向未经授权执行的差异或异常，从而揭示潜在的恶意行为者入侵系统的证据。关注点不仅仅在于识别恶意软件，还在于理解入侵的广度和深度，从而能够采取更全面的安全响应。

2013 年，一家大型美国零售商遭遇了重大数据泄露事件，攻击者窃取了数百万客户的信用卡和个人信息。在这一事件中，取证数据如预取文件、AmCache、ShimCache 和 Windows 事件日志在调查中起到了至关重要的作用。预取文件可能提供了有关恶意软件和攻击者使用的黑客工具执行情况的洞察，揭示了恶意活动的模式。AmCache 条目记录了已执行的程序，可能有助于识别与泄露事件相关的未经授权的二进制文件。ShimCache 可能提供了恶意可执行文件运行的额外证据，这对于理解恶意软件在零售商系统中的兼容性策略非常有帮助。Windows 事件日志记录了广泛的系统活动，对于重建泄露事件的时间线至关重要，包括登录尝试、系统更改和网络活动。这些数据结合起来，帮助调查人员拼凑出攻击者的行动轨迹，确认泄露事件中使用的方法，并全面理解入侵的范围，从而在揭示零售业最重大网络攻击之一中发挥了关键作用。

预取分析

预取是一个优化技术，由 Windows 操作系统用于加速应用程序的启动。它通过预测应用程序将需要哪些文件，并提前将其加载到内存中来实现这一点。在应用程序的首次执行后，系统会将相应的 .pf 文件填充到 Prefetch 目录中。这些文件可以在标准 Windows 安装的 C:\Windows\Prefetch 目录中找到。该目录将包含以 .pf 扩展名结尾的文件，每个文件的名称与其对应的可执行文件相同。例如，如果你运行了 notepad.exe，你可能会在 Prefetch 目录中找到一个名为 NOTEPAD.EXE.pf 的文件。

分析这些预取文件能够提供有关系统上运行过的应用程序的信息，这使得它们在性能诊断和取证调查中都具有重要价值。这些文件是由缓存管理器生成的，缓存管理器跟踪应用程序在运行过程中引用的所有文件和目录。因此，这些 .pf 文件成为了关于应用程序执行的历史数据的重要容器。

预取文件的取证重要性：

  • .pf 文件记录了相应应用程序的初次执行日期和最后执行日期。这些时间戳在取证调查中至关重要，因为它们有助于追溯潜在恶意应用程序首次引入并在系统上执行的时间。

  • .pf 文件本身也可以提供取证线索。虽然创建日期通常与应用程序首次执行的时间相符，但修改日期通常与最后一次执行日期相对应。通过比较这些日期，调查人员可以确定应用程序使用的连贯性和频率。

最受欢迎的开源 Prefetch 分析工具之一是 PECmd，它由 Eric Zimmerman 编写和维护。该工具解析 Prefetch 文件，并提供详细的输出，包括文件路径、时间戳、运行次数等。另一个常用的（但有许可要求的）Prefetch 文件解析工具是 Magnet AXIOM。

重要提示

你可以下载 PECmd，并在github.com/EricZimmerman/PECmd找到其使用详情。

假设有一个名为 malicious.exe 的可疑文件在组织的云租户上托管的 Windows 虚拟机实例中被执行。获取相应的 Prefetch 文件（可能来自我们之前讨论的某个初步检查工具），MALICIOUS.EXE.pf，并用 PECmd 分析后，输出可能如下所示：

> PECmd.exe -f C:\Users\Mansoor\Downloads\MALICIOUS.EXE.pf
Processing C:\Users\Mansoor\Downloads\MALICIOUS.EXE.pf
---------------------------------
Source File: C:\Users\Mansoor\Downloads\MALICIOUS.EXE.pf
---------------------------------
Executable: C:\Users\Mansoor\Downloads\MALICIOUS.EXE
Run Count: 3
Volume Info:
    Volume Path: \\?\Volume{abcd1234-efgh-5678-ijkl-1234567890ab}\
    Creation Date: 2023-09-15 15:34:21 UTC
    Serial Number: 3A2B1C4D
Directories accessed:
    C:\Users\Mansoor\Downloads\
    C:\Windows\System32\
    C:\Temp\
Files accessed:
    C:\Users\Mansoor\Downloads\MALICIOUS.EXE
    C:\Windows\System32\somefile.dll
    C:\Temp\tempfile.tmp
Last Run Time: 2023-10-24 12:23:45 UTC
Trace Chains (Last 8 executions):
    1\. 2023-10-24 12:23:45 UTC
    2\. 2023-10-23 10:20:30 UTC
    3\. 2023-10-22 14:15:15 UTC

在分析 Prefetch 文件（例如 MALICIOUS.EXE.pf）后，PECmd 提供的输出是一个丰富的取证数据源。PECmd 解码存储在 Prefetch 文件中的信息，并以易于阅读的格式呈现，包括应用程序首次和最后一次运行的时间戳、执行的总次数以及执行过程中访问的文件。

在分析 Prefetch 输出时，以下是一些攻击者的 TTPs（战术、技术和程序）需要注意：

  • 时间戳：Prefetch 文件包含时间戳，表示特定应用程序上次运行的时间。这有助于调查人员将应用程序执行时间与系统上的其他事件进行关联。

  • 应用程序频率：通过检查 Prefetch 文件中的运行计数，分析人员可以确定应用程序的执行频率。不寻常的频率可能表明存在异常或恶意活动。

  • 卷信息：Prefetch 文件还会存储关于应用程序执行来源卷的详细信息。这对于追溯潜在的恶意外部设备或卷非常有用。

  • 应用程序源路径：识别应用程序执行的位置（例如，来自 USB 设备或特定目录）可以帮助拼凑出攻击者在主机上的行动或移动路径。

  • 文件和目录引用：Prefetch 文件列出了在应用程序启动过程中访问的其他文件和目录。这可以突出任何依赖或关联的文件，这些文件可能也是恶意或已被攻破的。

Prefetch 文件，尽管设计上是为了性能优化，但它们已经成为事故响应人员不可或缺的取证工具。

AmCache 分析

AmCache 类似于 Prefetch，是 Windows 系统（特别是 Windows 8 及以上版本）特有的取证遗留物。AmCache.hve文件是一个 Windows 注册表 hive，主要服务于 Windows 应用程序体验程序，这是一个旨在确保软件兼容性的功能。通常位于C:\Windows\AppCompat\Programs\Amcache.hve，该 hive 记录了执行过的应用程序的详细元数据，以及关于连接硬件的信息，例如 USB 设备。虽然它的主要功能是软件兼容性，但它所包含的丰富数据使其成为取证调查中不可或缺的工具。

它的取证重要性如下：

  • 二进制元数据：AmCache 包含了关于执行二进制文件的详细元数据，如文件路径、最后修改时间、创建时间、SHA-1 哈希等。这帮助取证分析师追溯系统中可执行文件的来源和历史。

  • 硬件痕迹：该 hive 还记录了插入的硬件设备，可能帮助调查人员追踪恶意 USB 设备或外部存储设备的插入时间。

  • 与执行的关联：通过分析 AmCache，取证专家可以将二进制元数据与其他证据中的执行痕迹进行关联，从而提供系统活动的完整时间线。

解析 AmCache 的常用工具之一是 AmcacheParser，它也是 Eric Zimmerman 的取证工具套件的一部分。像 PECmd 一样，它是开源的，并提供了对AmCache.hve文件的详细解析。另一个提供强大 AmCache 解析功能的授权工具是 Magnet AXIOM。

重要提示

你可以在github.com/EricZimmerman/AmcacheParser下载 AmcacheParser 并查看其使用说明。

假设在云端托管的 Windows 虚拟机上执行了一个名为malicious_mansoor.exe的恶意文件。当获取AmCache.hve文件并用 AmcacheParser 解析时，输出可能会类似于以下内容：

> > AmcacheParser.exe -f C:\Users\Mansoor\Downloads\Amcache.hve
Processing C:\Users\Mansoor\Downloads\Amcache.hve
---------------------------------
Source File: C:\Users\Mansoor\Downloads\malicious_mansoor.exe
SHA-1: a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4
File Created: 2023-09-14 12:01:12 UTC
File Last Modified: 2023-09-15 13:05:10 UTC
Run Count: 2
Associated Files:
    C:\Windows\System32\somefile.dll
    C:\Temp\tempfile.tmp
---------------------------------

以下是分析 AmCache 时需要注意的一些关键 TTP：

  • 二进制哈希：AmCache 中的 SHA-1 哈希提供了一个机会，用于与威胁情报源中的已知恶意哈希进行匹配。

  • 文件路径：不寻常或可疑的文件路径，尤其是位于临时文件夹或不常见目录中的路径，可能暗示着恶意活动。

  • 文件创建与修改：时间戳可以与其他系统事件相关联，从而描绘出攻击者的行为。

  • 关联文件：像 Prefetch 一样，AmCache 也提供了与可执行文件相关联的文件引用，有助于绘制出潜在的恶意依赖关系。

AmCache hives 虽然是为了兼容性而创建的，但却具有重要的取证潜力。与 Prefetch 一起，AmCache 已经证明了它在事件响应和数字取证中的重要价值。

ShimCache 分析

ShimCache，正式名称为应用兼容性缓存，是 Windows 操作系统的一部分，旨在允许为旧版本 Windows 设计的应用程序提供向后兼容性。当 Windows 执行一个程序时，它会检查 ShimCache 以确定该应用程序是否需要任何“修补程序”或兼容性修复才能正确运行。ShimCache 在此过程中会保持一个已在系统上运行的可执行文件列表，这使其成为数字取证分析师的重要资源。ShimCache 信息存储在 Windows 注册表中，路径为 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatibility\AppCompatCache。

这是它的取证重要性：

  • 执行历史：ShimCache 维护着最近执行的应用程序列表，帮助取证分析师追踪哪些可执行文件曾在系统上运行。此列表包括文件路径、最后修改时间和文件大小。

  • 持久性机制检测：恶意软件通常会利用各种持久性机制。观察 ShimCache 中不常见或可疑路径的重复条目，可以提示存在此类持久性机制。

  • 与其他证据的关联：类似于 AmCache，ShimCache 中的数据可以与其他取证证据交叉参考，从而提供系统执行历史和潜在事件的全面视图。

提取和解析 ShimCache 条目的流行工具是 ShimCacheParser，它也是 Eric Zimmerman 的取证工具套件的一部分。它提供了 ShimCache 条目的结构化输出，方便快速的取证分析。

重要提示

你可以下载 ShimCacheParser，并在 github.com/mandiant/ShimCacheParser 查找其使用详情。

假设在 Windows 系统中发现了一个名为 malicious_mansoor.exe 的恶意文件。通过提取 ShimCache 数据并使用 ShimCacheParser 进行分析，输出结果可能如下所示：

> ShimCacheParser.exe -f SYSTEM
Processing SYSTEM hive...
---------------------------------
Source File: C:\Users\Mansoor\Downloads\malicious_mansoor.exe
File Last Modified: 2023-09-15 13:05:10 UTC
File Size: 24576 bytes
Execution Flag: Executed
---------------------------------

根据此输出，事件响应者和取证专家可以高度确认恶意文件已经被执行，并能够推断恶意二进制文件 malicious_mansoor.exe 可能是在文件系统中何时创建或最后一次更改的。

以下是分析 ShimCache 时需要注意的一些关键 TTPs：

  • 文件路径：ShimCache 中出现来自不常见或可疑目录的可执行文件通常是一个警示信号。

  • 执行标记：虽然 ShimCache 记录了可执行文件，但并非所有文件都必然被执行。执行标记区分了仅存在与实际执行之间的差异。

  • 文件修改时间：文件修改时间的异常，特别是如果它们与已知的入侵事件相关联，可能具有重要意义。

  • 文件大小和属性：文件大小或属性偏离已知的正常基线可能暗示潜在的篡改或恶意替换。

ShimCache 是为应用程序兼容性而设计的，已经发展成为一个重要的取证工件。与 Prefetch 和 AmCache 等其他工件配对使用，ShimCache 提供了对系统活动的宝贵见解，有助于彻底的事件响应和调查。

Windows 事件日志

Windows 事件日志是微软 Windows 系统固有的集中式系统日志记录设施。它提供了系统、安全、应用程序和其他事件的详细记录。无论是跟踪用户活动、诊断系统问题、监视安全事件还是确保合规性，事件日志都发挥着至关重要的作用。

这里是位置：

  • C:\Windows\System32\winevt\Logs

  • C:\Windows\System32\winevt\Logs

这里有一些重要的 Windows 事件日志：

  • 安全日志：捕获与安全相关的事件，如登录、注销、对象访问、账户管理等

  • 系统日志：反映系统组件的活动，包括驱动程序和服务，捕获系统故障、资源耗尽或其他系统范围事件的警报

  • 应用程序日志：记录安装的应用程序和服务的应用程序事件、错误、警告和信息消息

  • PowerShell 日志：专门记录与 PowerShell 命令、脚本和模块相关的活动

  • 终端服务（RDP）：涉及远程桌面协议（RDP）会话，捕获登录成功和失败、断开连接以及其他 RDP 特定事件

这里是取证的重要性：

  • 安全日志：

    • 账户登录：显示账户何时被验证

      • 事件 ID 4624：成功登录

      • 事件 ID 4625：账户登录失败

    • 账户管理：显示用户账户或组何时被创建、更改或删除：

      • 事件 ID 4720：用户账户已创建

    • 权限使用：指示特权的使用

      • 事件 ID 4672：为新登录分配特权

    • 对象访问：详细说明何时访问特定对象（文件、目录）

      • 事件 ID 4663：尝试访问对象

  • 终端 服务（RDP）：

    • 事件 ID 4778：会话重新连接到窗口站

    • 事件 ID 4779：会话从窗口站断开连接

  • PowerShell 日志：

    • 事件 ID 4103：指示已执行 PowerShell 命令或脚本块

  • 横向移动：

    • 事件 ID 5140：已访问网络共享

    • 事件 ID 5145：检查网络共享对象以查看是否可以授予所需访问权限

  • 通过计划任务实现持久性：

    • 事件 ID 4698：已创建计划任务

  • 进程/代码执行：

    • 事件 ID 4688：已创建新进程

要分析事件日志，您可以使用 Eric Zimmerman 开发的开源工具 evtxECmd，该工具提供了广泛的解析功能。

重要提示

您可以在github.com/EricZimmerman/evtx下载 evtxECmd 并找到其使用详细信息。

这里有一个快速示例，说明如何确定哪些账户已登录到主机：

> evtxECmd.exe -f Security.evtx --csv out.csv
---------------------------------

输出将是一个包含解析的安全事件日志和对应字段的列的 CSV 文件：

图 9.2 – 解析的安全事件日志示例（out.csv）

图 9.2 – 解析的安全事件日志示例（out.csv）

在分析 Windows 事件日志时，以下是一些关键的 TTPs 要注意：

  • 账户枚举：大量的登录失败尝试，特别是使用各种用户名，可能表明账户枚举尝试。查找具有事件 ID 4625 的多个事件。

  • 可疑的 RDP 活动：频繁的远程登录，特别是在奇怪的时间，可能表明恶意活动。事件 ID 4778 和事件 ID 4779 可以提供帮助。

  • 横向移动：从陌生系统访问网络共享日志的激增可能表明横向移动。关注事件 ID 5140 和事件 ID 5145。

  • 异常的 PowerShell 执行：执行意外或很少使用的 PowerShell 命令，通过事件 ID 4103 跟踪，可能暗示潜在的恶意活动。

  • 任务调度以实现持久性：事件 ID 4698 指示任务调度。如果任务反复调度，特别是来自陌生来源或频率很高，可能表明存在持久性机制。

  • 代码执行异常：进程创建事件中的异常，特别是来自不常见目录或未知二进制文件的，可能是一个警示信号。使用事件 ID 4688 进行检查。

Windows 事件日志是非常丰富的数据源，可以提供系统上几乎所有活动的详细视图。结合合适的工具和对关键事件和指标的理解，它们在任何严肃的取证调查或事件响应中都是不可或缺的。

分析内存转储

内存转储取证涉及分析系统易失性内存的快照。它可以揭示关于系统在快照时刻的状态的大量证据，从运行中的进程到打开的网络连接，内存中的工件，甚至未写入磁盘的加密密钥或恶意软件载荷。

有三种类型的内存转储：

  • 完整内存转储：捕获物理内存（RAM）的全部内容

  • 内核内存转储：仅包含内核模式的读/写页面

  • 小内存转储：记录最小一组有用数据，使其更快保存和更容易管理

通常，内存转储首先保存在主机的本地磁盘上，这是出于本地存储的速度和可靠性考虑，尤其是考虑到转储文件可能很大的情况。这对于完整内存转储尤为重要，因为完整内存转储捕获了物理内存（RAM）的全部内容，因此与系统中的 RAM 量成正比。例如，一个拥有 16 GB RAM 的系统将导致大致相同大小的完整内存转储，需要大量的存储空间。

内核内存转储仅包含内核模式的读/写页面，因此它们较小，因为它们排除了用户模式的应用程序和进程。其大小取决于内核占用的内存，通常远小于总内存，但仍然相当可观。另一方面，小型内存转储显著更小，通常只有几 MB，只记录最关键的数据。它们更快保存和管理，尽管提供的信息较为有限。

这是法医重要性：

  • 活动进程：列出系统上运行的所有进程，提供转储时的实时视图。

  • 网络连接：确定该机器与哪些远程系统通信。

  • 加载的模块：识别加载到内存中的所有驱动程序和动态链接库（DLL）。这可以揭示被注入的 DLL 或根套件（rootkits）。

  • 解密数据：可能在磁盘上加密的敏感数据（如密码、加密密钥）可以在内存中以未加密形式出现。

  • 恶意软件痕迹：发现可能仅存在于内存中的恶意软件残留物，这些恶意软件不会被写入文件系统。

威胁行为者越来越多地利用如无文件恶意软件等技术，这些恶意软件完全在内存中运行，从而避开传统的基于文件的检测方法。这使得内存取证成为事件响应的关键组成部分，尤其是在不是所有的妥协证据都写入文件系统或捕获到如 Prefetch、AmCache、ShimCache 和事件日志等痕迹的情况下。内存转储分析的重要性取决于妥协的性质：对于复杂的攻击，尤其是使用高级持续性威胁（APT）的攻击，内存分析通常是揭示妥协程度及攻击者使用技术的关键。内存取证的一个警告是，由于它们运行在由 RAM 分配的内存中，而不是文件系统（因此也不是硬盘上），如果设备断电，这些数据将被清除。

开源工具Volatility是内存转储取证中的热门选择。它提供广泛的插件支持，使其适应各种事件响应任务。

重要提示

你可以下载 Volatility 并在www.volatilityfoundation.org/releases查看其使用详情。

让我们来看一个使用 Volatility 的示例分析：

  1. 识别映像配置文件：

    > volatility -f memdump.raw imageinfo

    这将为进一步分析建议合适的配置文件——例如，如果有 Windows 10 架构的配置文件。

  2. 列出进程：

    > volatility -f memdump.raw --profile=Win10x86 pslist

    这将显示活动进程。请查找不寻常或意外的进程。

  3. 查看网络连接：

    > volatility -f memdump.raw --profile=Win10x86 netscan

    审查已建立的连接是否有任何可疑活动。

以下是分析内存转储时需要注意的关键 TTP（战术、技术和程序）：

  • 进程注入：不寻常的子进程或意外的父子进程关系可能表示进程注入。

  • 隐藏的进程：恶意软件通常会尝试隐藏其进程。检测这些进程可以指示 rootkit 活动或规避技术。

  • 意外的网络连接：留意这些连接，特别是那些指向已知恶意 IP 或不熟悉的外国地址的连接。

  • 钩子：某些类型的恶意软件使用钩子来拦截系统调用。检测这些钩子可能表明存在 rootkit 或某些类型的间谍软件。

  • 字符串分析：从内存转储中提取并分析字符串可以揭示路径、命令、URL 和其他恶意软件指示符。

  • 内存中的文件提取：提取仅存在于内存中的文件可以揭示恶意负载，这些负载避免了文件系统或任何已从磁盘删除但仍在内存中存在的工件。

内存转储取证提供了从基于磁盘的取证中无法获得的独特见解。这种分析形式对于处理使用内存规避或仅存在于易失性内存中的高级威胁尤其重要。正确的工具和对异常的敏锐观察使得内存取证成为每个事件响应者手中的强大武器。

配置错误的虚拟机实例

云环境中攻击者常见的入侵点之一是通过配置错误的虚拟机实例。云的优点在于虚拟机部署的快速性。然而，这也带来了缺点，即配置可能被忽视或设置不当。此类疏忽会无意间为威胁行为者提供访问权限，或提供进一步入侵的信息。我们来看看一些常见的配置错误。

不必要的端口保持打开状态

打开的端口作为虚拟机的通信端点。每个端口允许特定类型的通信，例如端口 80 上的 HTTP 流量。然而，保持不必要或未使用的端口开放会扩大潜在的攻击面。攻击者可以通过识别与这些端口上服务相关的漏洞来利用开放端口。确保只有必需的端口开放和可访问是至关重要的。

以下是一些需要留意的指标：

  • 主机 级别（Windows）：

    • Windows 事件 ID 5156（Windows 过滤平台已允许连接）可以被监控，用于检测已允许的网络连接

    • Windows 事件 ID 5157（Windows 过滤平台已阻止连接）可以提醒用户连接尝试已被阻止

  • CSP：

    • AWS：如前所述，VPC 流日志可用于观察到达虚拟机的流量

    • Azure：如前所述，NSG 流日志可以提供有关针对虚拟机的网络流量的洞察

默认凭证未更改

虚拟机通常在初始设置和访问时带有默认管理员凭据。虽然这在部署时很方便，但如果不更改这些默认凭据，会带来巨大的安全风险。攻击者很清楚许多系统的默认凭据，如果不进行更新，他们可以轻松获得未经授权的访问权限。

这是一个需要关注的指示器：

  • 主机级别（Windows）： Windows 事件 ID 4625（账户登录失败）可以用于监控并响应失败的登录尝试。

过时或未打补丁的软件

定期更新和打补丁软件及操作系统是基本的安全实践。随着时间的推移，软件中的漏洞会被发现，并发布补丁来修复它们。运行过时或未打补丁的软件会暴露虚拟机于已知漏洞之下，为攻击者利用这些漏洞创造了机会。

以下是一些需要关注的指示器：

  • 主机级别（Windows）：

    • Windows 事件 ID 4375（Windows 安装程序更新已安装的产品）可以提供补丁安装和软件更新的洞察

    • 使用 Nessus 等工具进行软件清单和/或漏洞扫描

  • CSP：

    • AWS： AWS Systems Manager Patch Manager 可以根据设定的策略进行自动化补丁管理。

    • Azure： Azure 安全中心突出显示未打补丁的虚拟机，并建议相关的安全补丁。

    • GCP： GCP 的操作系统补丁管理服务 Patch 允许在 Google Cloud 中的虚拟机实例之间调度和自动化补丁部署。它提供了补丁合规性报告和补丁发布计划的配置功能，确保虚拟机更新到最新的安全补丁。

公开暴露的敏感数据（或元数据）

数据暴露是一个关键问题，尤其是在涉及敏感或个人数据时。无论是由于访问控制不当、疏忽还是配置错误，敏感数据的公开暴露都可能导致数据泄露、声誉损害以及潜在的监管后果。确保严格的访问控制和定期审核对于防止无意的数据暴露至关重要。让我们仔细看看：

  • 主机级别（Windows）：

    • Windows 事件 ID 4663（尝试访问对象）可以用于监控异常或意外的敏感文件访问尝试

    • 在软件应用程序级别的应用程序日志

  • CSP：

    • AWS： 亚马逊提供了额外的服务，旨在发现、分类和保护 AWS S3 中的敏感数据——例如，Amazon Macie。

    • Azure： 通过 Azure Monitor 的 Azure 存储日志可以帮助监控和分析对存储资源的请求，确保只有授权访问。

    • GCP：GCP 的敏感数据保护服务套件有助于发现并分类 GCP 服务中的敏感数据。Google Cloud Storage 还通过 Cloud Audit Logs 提供详细的日志记录和监控功能，允许跟踪和分析对存储资源的请求。

通过了解这些配置错误领域并积极监控相关指示，组织可以大大增强其云中虚拟机的安全态势。

配置错误的存储桶

配置错误的存储桶已成为云环境中的一个重大漏洞。像 Amazon 的 S3 存储桶或 Azure Blob 存储这样的云存储解决方案通常以简便和快速为设计目标。然而，如果没有严格的安全配置，它们可能会无意中变得公开可访问或容易被攻破。此类配置错误会暴露敏感数据，导致潜在的数据泄漏，并危害组织的完整性。让我们来看一些可能允许未经授权访问的常见配置错误。

公共权限

存储资源通常以默认的私有设置创建，确保只有经过适当认证和授权的实体可以访问存储的数据。然而，有时为了方便或因误操作，这些权限可能会被更改，导致无意中的公开曝光。

以下是需要注意的一些指示：

  • AWS：

    • 进入 Amazon S3 控制台，检查每个存储桶的访问列。如果有任何存储桶标记为公开，则可能存在曝光风险。

    • 可以按如下方式使用 AWS CLI：

       aws s3api get-bucket-acl --bucket YOUR_BUCKET_NAME

    如果Grantee: Group的 URI 为http://acs.amazonaws.com/groups/global/AllUsers，则该存储桶具有公共权限。

  • Azure：

    • 在 Azure 门户中，导航至Blob 服务 | 容器，检查每个容器的公共访问级别属性。

    • 我们可以按如下方式使用 Azure CLI：

       az storage container show --name YOUR_CONTAINER_NAME --account-name YOUR_STORAGE_ACCOUNT --query 'properties.publicAccess'

    如果输出为Blob或Container，则表示具有公共访问权限。

曝露的 API 密钥或凭据

存储桶有时错误地包含敏感文件，这些文件可能包含 API 密钥、凭据或其他机密。如果攻击者获取这些文件，他们可能会危及与这些密钥相关的系统或数据。

以下是需要注意的一些指示：

  • 在你的 S3 存储桶中，查找*.pem、*.json、credentials、keys等文件。

  • 你可以使用以下 AWS CLI 示例列出存储桶中的所有文件：

    *.pfx, *.json, credentials, keys, and so on

  • 你可以使用以下 Azure CLI 示例列出容器中的 Blob：

     az storage blob list --container-name YOUR_CONTAINER_NAME --account-name YOUR_STORAGE_ACCOUNT --output table

IAM 策略的错误使用

IAM 控制谁或什么可以在特定资源上执行操作。不当的 IAM 配置可能会给予用户或角色超过其所需的权限，从而违反最小权限原则。

以下是需要注意的一些指示：

  • s3:*操作针对s3:::YOUR_BUCKET_NAME/*。

  • 你可以使用以下 AWS CLI 示例列出用户的策略：

     aws iam list-attached-user-policies --user-name YOUR_USERNAME

  • Azure：

    • 审查存储帐户的基于角色的访问控制（RBAC）分配。确保没有将如“所有者”或“贡献者”等权限过高的角色分配给不需要这些角色的身份。

    • 您可以使用以下 Azure CLI 示例列出存储帐户的角色分配：

       az role assignment list --assignee YOUR_OBJECT_ID --scope /subscriptions/YOUR_SUBSCRIPTION_ID/resourceGroups/YOUR_RESOURCE_GROUP/providers/Microsoft.Storage/storageAccounts/YOUR_STORAGE_ACCOUNT

通过定期检查并确保存储桶和相关权限的正确配置，组织可以降低数据暴露和潜在泄露的风险。

云管理员门户被攻破

获取对云管理员门户的访问权限就像是把整个云王国的钥匙交给了攻击者。拥有此类访问权限的攻击者不仅可以查看敏感数据，还可以修改配置、删除关键资源，并通过启动大量资源来可能引发巨额费用。让我们来仔细看看可能执行的攻击：

  • 暴力破解攻击：攻击者使用软件尝试尽可能多的组合以获取访问权限

    指示器：来自同一 IP 地址的多个失败登录尝试，且时间间隔很短

  • 凭证填充攻击：攻击者使用以前泄露的用户名和密码

    指示器：来自同一 IP 地址的多个用户名的登录尝试

  • 钓鱼攻击：攻击者欺骗用户提供其登录凭证

    指示器：用户通过不熟悉的引荐 URL 访问云门户或从不熟悉的地点登录

  • 令牌窃取：攻击者窃取身份验证令牌或会话 cookies。

    指示器：异常的用户代理字符串或与熟悉的用户帐户配对的意外位置

AWS 检测：

  • eventName 如 ConsoleLogin 与 errorMessage 如 Failed authentication 结合显示失败的登录尝试

  • 同一 userIdentity 在短时间内有多个 sourceIPAddresses 可能表示可疑活动

  • AWS 管理控制台登录 URL 重定向，这可能是钓鱼攻击的指示器

  • UnauthorizedAccess:IAMUser/ConsoleLogin，这表明可疑的控制台登录。

Azure 检测：

  • Azure 活动日志：为事件响应者提供对在资源上执行的操作的洞察。请查找以下内容：

    • 与登录操作关联的状态为失败的活动

    • 与成功登录关联的异常 IP 地址或地区

  • Azure AD 登录：这为事件响应者提供了租户内登录活动的访问权限。请查找以下内容：

    • 多次失败的登录尝试

    • 来自不熟悉的地点或异常设备的登录尝试

通过了解 TTPs（战术、技术和程序）并定期监控相关日志，事件响应者和防御者可以检测并可能防止由于云环境中的弱身份验证引发的安全漏洞。即使安全的多因素身份验证已变得更加普及，网络安全领域也在快速发展，新的威胁可能会出现，可能需要事件响应者应对完整的管理员门户接管。

总结

在这一章中，你了解了云安全所面临的挑战和风险。我们讨论了尽管云环境有其优势，但也存在独特的安全问题。从配置错误的虚拟机实例到未保护的存储桶，我们强调了可能发生错误的领域，以及这些错误如何被攻击者利用。

你还了解了基于主机的取证，深入探讨了关键指标，如预取（prefetch）、AmCache、ShimCache、Windows 事件日志和内存转储。我们提到了确保虚拟机安全的重要性，涵盖了开放端口、默认凭证和过时的软件。还讨论了存储桶配置及其潜在的风险。最后，我们深入探讨了身份验证这一关键话题，强调了云管理员门户被突破所可能带来的严重后果。

在我们过渡到下一章关于云证据采集的内容时，我们将重点关注在云环境中收集证据。

进一步阅读

MITRE ATT&CK 矩阵：面向云的技术：attack.mitre.org/matrices/enterprise/cloud/.

第十章：云证据获取

到目前为止，我们已经在云内使用 云服务提供商（CSP）提供的工具来调查取证。我们看了 AWS GuardDuty CloudTrail 从日志和调查的角度来看。我们还研究了 GCP 的云日志功能，以调查各种服务发出的云日志，Azure Monitor 为托管在 Microsoft Azure 内的服务提供了类似的功能。

本章将在我们的云调查旅程中进一步探讨，并探讨安全地收集核心服务的取证或离线分析取证图像的方法和技术。调查人员将认识到，并非所有调查都可以使用本地云工具完成。调查人员可能需要使用他们在取证环境中可以访问的专业工具，挑战将是以取证合规和法律可接受的方式从云中收集图像。我们将在本章后面的部分探索这些工具。我们将研究三大 CSP 提供的取证收集：

  • AWS 实例的取证获取

  • Azure 实例的取证获取

  • GCP 实例的取证获取

请注意，在本章中，我们将依赖一些标准步骤来收集取证图像，当调查人员可以访问 Windows 或 Linux 操作系统时，这些步骤是标准的，无论底层的云平台是什么。

AWS 实例的取证获取

让我们直接深入安全和取证上的细节。我们假设一个组织收到了有关在 弹性计算云（EC2）实例上部署勒索软件的警报。因此，这个实例已被停止。取证人员需要安全地从 EC2 实例中提取取证图像。

任何与 EC2 实例相关联的磁盘在 AWS 中称为 卷。为了收集证据，调查人员必须按照特定的步骤顺序操作。首先，调查人员必须记录受感染实例的 实例 ID（唯一标识符）。

在本案例中，受感染的实例名称为 CF2，其实例 ID 为 i-00229ce2dd123a2e6。

第一步 – 创建 EC2 卷快照

我们将按照实例 ID 引用这些 EC2 实例进行以下步骤：

  1. 调查人员必须注意与 i-00229ce2dd123a2e6 (CF2) 关联的存储卷及其卷 ID（每个卷的唯一标识符）：

图 10.1 – 与 00229ce2dd123a2e (CF2) 关联的卷（磁盘）

图 10.1 – 与 00229ce2dd123a2e (CF2) 关联的卷（磁盘）

  1. 我们看到有两个卷附加到 i-00229ce2dd123a2e (CF2)。AWS 总是将根驱动器 (C:\) 分配给 /dev/sda1。这是调查人员的参考点，如果他们只想收集根驱动器的取证图像。

  2. 我们选择附加到实例i-00229ce2dd123a2e (CF2)的根驱动器 vol-061392d9abebf9433，这将带我们到卷页面，页面截图如下：

图 10.2 – 选择需要取证成像的卷

图 10.2 – 选择需要取证成像的卷

  1. 在操作标签下，选择创建快照选项。快照会创建原始卷的副本，但不会修改该卷。我们在图 10.3中演示了这一过程。调查人员必须注意，附加到 EC2 实例的卷不能直接下载或导出。建议始终在原始卷的副本或快照上进行取证，以保护证据。

图 10.3 – 选择用于快照的 AWS 卷

图 10.3 – 选择用于快照的 AWS 卷

  1. 根据卷的大小，创建快照可能需要几秒钟到几分钟的时间。调查人员必须等待，直到确保快照成功创建后才能继续。在图 10.4中，我们看到快照成功创建。所有快照将在snap-0857fc1efa85ae0ff下可用。

图 10.4 – 创建的 AWS 卷快照 (vol-061392d9abebf9433)

图 10.4 – 创建的 AWS 卷快照 (vol-061392d9abebf9433)

第 2 步 – 获取操作系统内存映像

现在，让我们来看一下如何通过取证方法获取 EC2 实例的内存映像。如果需要在调查中获取内存映像，DFIR 团队可以考虑一些常见步骤，只要受感染的实例仍在运行。调查人员可以通过命令行与受感染的实例进行某种形式的交互访问（AWS AmazonSSMFullAccess 策略允许通过 Amazon SSM 完全访问 EC2 实例）。

获取内存映像比获取磁盘映像更复杂。最简单的方法之一是将 EC2 实例切换到休眠模式，这会强制将所有内存内容写入磁盘，形成 hyberfil.sys 文件，然后才能进行完整的磁盘证据采集，从而允许调查人员利用内存的快照。

第 2a 步 – 通过休眠获取内存映像

AWS 在其 EC2 控制台中允许的一项选项是休眠。选择实例，点击实例状态，然后选择休眠。但是，为了让 AWS 休眠 EC2 实例（无论是 Windows 还是 Linux），它必须满足以下条件：

  • AWS 仅在部分实例家族中支持云原生休眠功能。

  • 在启动 EC2 实例时，管理员应在高级设置下启用休眠功能以启用此行为。EC2 实例创建/启动后无法更改此设置。

  • EC2 实例必须拥有足够的根存储空间以容纳内存内容。

  • 仅支持特定的 gp2 和 gp3 类型或预配置 IOPS SSD (io1 和 io2)

如果未配置前述条件，AWS 不支持云原生的休眠功能。

一旦启用休眠，调查员可以通过云控制台将系统休眠并收集磁盘映像进行法医分析，从而捕获内存内容。

步骤 2b – 从操作系统直接获取内存映像的常见步骤

内存采集的过程相当简单，但安全地获取法医图像是一个手动过程。你会注意到有多种方法可以实现自动化；然而，这取决于调查员的访问权限和角色（外部（一次性）调查员或内部公司调查员）。如果是内部调查，且组织在云中的规模较大，他们可以考虑以各种方式自动化法医数据采集并上传到云存储。在进一步阅读部分，我们已经包含了一些利用其他云服务的想法。然而，这些步骤为你提供了一个指南，使法医数据采集变得更加简便。

以下步骤将提供一个从相关操作系统收集内存映像的概述。调查员必须确保他们能够连接到实例，无论是通过交互式 RDP 会话，还是通过使用云原生命令行功能的命令行：

从 Windows 操作系统实例收集内存映像

一旦调查员登录到感染的 Windows 实例，他们可以开始进行数据采集：

  1. 特别是在 AWS 中，这可以通过直接登录到受影响的虚拟机或通过 Amazon SSM 实现。

  2. 使用具有 Windows 管理员权限的 powershell.exe，创建一个文件夹，将所有的内存转储和工件存放在其中。

  3. 然后，我们使用以下命令下载最新版本的 winpmem.exe（我们在第八章中提到过这个工具）：

    > Invoke-WebRequest -Uri https://github.com/Velocidex/WinPmem/releases/download/v4.0.rc1/winpmem_mini_x64_rc2.exe -OutFile "winpmem.exe"

  4. 一旦下载完成，我们在同一个 PowerShell 窗口中运行它。我们运行工具并提供一个文件名作为参数，将内存保存到一个文件中。请注意，我们正在以 RAW 格式捕获内存：

    > winpmem.exe memory.raw

  5. 以下截图展示了正在进行的内存采集过程。根据内存的大小，这可能需要几秒钟到几分钟不等：

图 10.5 – 使用 winpmem.exe 进行内存转储

图 10.5 – 使用 winpmem.exe 进行内存转储

一旦内存采集完成，调查员必须将内存转储导出到远程服务器或云原生存储区域，以便离线访问和处理。或者，根据调查员的偏好，你也可以关闭操作系统并拍摄完整的磁盘快照，通过法医磁盘成像，内存映像可以在离线处理磁盘映像时作为工件导出。

从 Linux 操作系统获取内存映像

调查人员必须了解的关键区别是，Linux 和 Windows 操作系统在内存获取方面的不同工具。在某些情况下，调查人员必须先从源代码编译专门的工具来收集内存的取证图像。这是因为这些工具使用特定于 Linux 内核版本的低级库。为此，我们使用 LiME，它允许在 Linux 中进行完整的易失性内存获取。

以下是收集内存映像的步骤：

  1. 一旦获得相关访问权限，调查人员必须确保可以从源代码下载并编译工具。他们还需要访问 sudo 命令。在本例中，我们将使用 LiME 工具进行内存捕获。我们将通过 GitHub 下载它们并使用命令进行编译。最好所有以下命令都以 sudo 权限（即以 root 身份）运行：

    # git clone https://github.com/504ensicsLabs/LiME.git
# cd LiME/src
/home/ubuntu/ir_forensics/ as memory.dump

    src 文件夹，因为编译后的版本保存在此文件夹中：insmod：此命令将内核模块插入正在运行的 Linux 内核中。lime-$(uname -r).ko：此命令部分指定要加载的内核模块。它使用命令替换（$(uname -r)）动态地将当前内核版本插入文件名中，从而加载适用于当前运行内核版本的 LiME 模块。path=/home/ubuntu/ir_foreniscs/memory.dump：此参数指定保存内存转储的路径。format=lime：此参数指定内存转储的保存格式，此处为 lime。

  2. 一旦命令完全执行并生成内存转储，调查人员可以导出数据并使用他们选择的工具（包括 volatility）离线分析它们。

第三步 – 创建取证收集器实例

成功创建快照后，调查人员必须准备一个取证收集器实例。一些 DFIR 团队可能已经预先创建了实例，或者使用了为此目的创建的模板虚拟机。上述任何方法都适合进行取证数据的收集。然而，调查人员必须注意，在创建取证收集器实例时，收集器实例的存储大小必须适当配置。通常，建议为取证数据配置至少原始磁盘空间的 120% 或更多的存储空间。

我们正在创建一个 dd 工具和 Windows 及 Linux 文件系统。此演示中，Ubuntu 上没有安装其他实时取证工具，仅用于取证收集。然而，调查人员必须考虑为实例分配更高的 CPU 和内存，因为它将进行大规模的逐位复制，这需要更多的 CPU 周期。

一些调查员可能会创建大量存储空间，并将所有取证镜像保存在同一存储空间中，将其当作 USB 驱动器使用，或者为特定的卷创建独立存储。无论哪种方式，只要有足够的空间来保存取证镜像，那就是最重要的。我们创建了一个 100 GB 的存储卷，用于在目标取证收集器实例中捕获取证镜像，尽管我们知道原始受感染系统只有 30 GB 的磁盘空间。这个存储空间足以进行所有的逐位复制到目标存储中。

图 10.6 – 为取证收集创建新存储

图 10.6 – 为取证收集创建新存储

一旦实例创建完成（i-00747860d682ac481 (EC2_FORENSIC_CAPTURE)）并且额外的存储已设置好，我们按照以下截图的指示挂载磁盘。请查看/dev/nvme1n1p1，它被挂载为/forensic：

图 10.7 – 为取证收集创建额外存储（已初始化并挂载）

图 10.7 – 为取证收集创建额外存储（已初始化并挂载）

请参考进一步阅读部分，了解如何在 Ubuntu Linux 中初始化和挂载磁盘的相关信息。

注意

一旦目标 EC2 实例（取证收集器）创建完成，调查员必须记录该实例的可用区。我们将在第 4 步中解释这一点的重要性。

在我们的案例中，取证收集器实例托管在ca-central-1d。该信息只有在创建 EC2 实例后才能获取。

第 4 步 – 从快照创建并附加受感染的卷

专门用于取证目的，我们将从第 1 步中创建的快照创建一个卷，并将其附加到我们在第 2 步中创建的目标卷：

  1. 第一步是从快照启动卷创建过程。如以下截图所示，我们选择在第 1 步中创建的快照，然后使用操作选项来从快照创建卷：

图 10.8 – 从快照创建卷（在第 1 步中创建）

图 10.8 – 从快照创建卷（在第 1 步中创建）

  1. 如第 2 步所示，取证收集器实例是在ca-central-1d可用区创建的。调查员需要这一信息，因为卷是分配给特定的可用区的。如果没有选择适当的可用区，创建的卷将无法附加到目标 EC2 实例。我们按照屏幕上的指示创建卷；但是，确保将卷映射到我们在第 2 步中记录的可用区（ca-central-1d）。一旦卷创建完成，不能更改其可用区，因此选择正确的可用区至关重要。

  2. 在从快照创建卷时，请记录卷 ID。在我们的案例中，卷 ID（如以下截图所示）为vol-09ba3e6ad9ed12e5b：

图 10.9 – 从快照成功创建卷

图 10.9 – 从快照成功创建卷

  1. 一旦卷成功创建，我们将新卷附加到取证收集器 EC2 实例（i-00747860d682ac481 (EC2_FORENSIC_CAPTURE)）。我们根据其唯一标识符过滤新卷，选择该卷，并在操作下选择附加卷。对于 EC2 实例，可以附加的卷数量没有限制：

图 10.10 – 将卷附加到 EC2 实例

图 10.10 – 将卷附加到 EC2 实例

  1. 如下截图所示，我们按照屏幕上的指示进行操作。然而，有一个特别需要调查人员注意的地方是将卷映射到正确的实例；因此，调查人员必须记录唯一的实例 ID，以确保卷正确附加。在我们的案例中，我们将卷（vol-09ba3e6ad9ed12e5b）附加到 EC2 实例（i-00747860d682ac481 (EC2_FORENSIC_CAPTURE)）。如你所见，关键元素在下图中已被高亮显示。这就是一切汇聚的地方：我们从快照（snap-0957fc1efa85ae0ff）中创建的 vol-09ba3e6ad9ed12e5b，在步骤 1 中记录的 ca-central-1d，以及在步骤 2 中创建 EC2 实例时记录的，卷创建时记录的，还有 i-00747860d682ac481 (EC2_FORENSIC_CAPTURE)：

图 10.11 – 为取证将卷附加到 EC2 实例

图 10.11 – 为取证将卷附加到 EC2 实例

  1. 请注意，AWS 将附加的卷引用为挂载点；在这种情况下，对于 AWS，设备名称挂载点是 /dev/sdf，在 Ubuntu Linux 操作系统中访问卷时，可能会有所不同。

  2. 现在我们切换到 Ubuntu Linux，作为我们的取证收集器系统（i-00747860d682ac481 (EC2_FORENSIC_CAPTURE)）。

步骤 4a – 获取实例磁盘映像的常见步骤

无论云服务提供商是谁，以下步骤是收集操作系统取证数据的常见步骤。在开始取证收集之前，请确保已完成先决条件，包括拍摄快照、创建取证收集器实例等：

  1. 一旦在云控制台中创建了感染的卷快照，调查人员可以执行完整的磁盘取证数据收集。我们将利用 Linux Ubuntu 上本地可用的 dd 命令来执行此操作。

  2. 我们将在同一个云平台上创建一个取证收集器实例，将快照附加为磁盘卷到取证收集器实例中。

  3. 我们验证新卷是否已正确附加；请参阅以下截图。我们通过运行 lsblk 命令并通过运行 sudo file -s /dev/nvme2n1p1 来验证已识别磁盘的文件系统信息：

图 10.12 – 验证附加到 EC2 实例的卷

图 10.12 – 验证附加到 EC2 实例的卷

  1. 对于整个磁盘的取证映像，无需将磁盘挂载到实例（操作系统内）；dd 会直接映像整个卷。但是，如果调查人员希望提取特定的证据（如第八章所述），他们可以手动将磁盘挂载到挂载点并提取相关证据。

  2. 在启动 dd 命令之前，调查人员还必须确保目标存储已经创建，并且该存储具备读写权限。我们运行以下命令启动取证数据收集。确保你有 sudo 命令的权限，因为这将是低级别的取证收集：

    $ sudo dd if=/dev/nvme2n1p1 of=/forensic/cf2.raw bs=4M status=progress

    下面是为 dd 命令提供的参数详细信息：

    • if=/dev/nvme2n1p1：这是你需要复制的源磁盘。

    • of=/forensic/cf2.raw：我们将取证映像以原始格式转储到 /forensic 挂载点。你可以根据工具的支持将取证映像以任何格式转储。取证映像保存为 cf2.raw（类似于受感染 EC2 实例的主机名），并存储在 /forensic/ 文件夹下。

    • bs=4M：此设置将块大小设置为 4MB；你可以根据需求调整该值。

    以下截图显示了通过 dd 命令完成的取证获取：

图 10.13 – dd 命令输出

图 10.13 – dd 命令输出

  1. 可选地，取证成像完成后，调查人员可以通过对源和目标点进行哈希验证，来确认准确性。例如，在下面的片段中，我们通过运行 md5sum 命令验证哈希，并确认获取的准确性：

    ubuntu@ip-172-31-45-98:~$ sudo md5sum /forensic/cf2_image.raw
e24806611c969189ec53a013e143f883  /forensic/cf2_image.raw
ubuntu@ip-172-31-45-98:~$ sudo md5sum /dev/nvme2n1p1
e24806611c969189ec53a013e143f883  /dev/nvme2n1p1

完成这些步骤后，调查人员必须确定他们的导出选项。简而言之，调查人员可以将这些证据上传到云托管存储（如 AWS S3、Azure Blob Storage、GCP Cloud Storage），或上传到由调查人员控制的远程服务器进行离线分析。

第 5 步 – 将收集到的映像导出到 AWS S3 进行离线处理

现在我们已经完成了步骤 1–4，我们的取证映像可以进行离线或异地处理。但是，在离线处理之前，你必须先导出它。调查人员最常用的导出方法之一是通过 S3 存储桶进行导出：

  1. 调查人员必须确保创建了 S3 存储桶，并且他们的帐户已配置 AWS 访问密钥和秘密密钥，以便通过 EC2 内的命令行访问 S3 存储桶。默认配置将不允许访问 S3 存储桶。

  2. 一旦创建了桶并配置了 AWS S3 访问权限，你就可以开始导出了。你可以通过运行以下命令进行导出：

    aws s3 cp /forensic/ s3://forensicbucket1/ --recursive

    以下是通常与 aws s3 命令一起提供的参数：

    • cp：启动复制功能，类似于大多数 Linux 变种中的命令。

    • /forensic/：你想要导出的源文件夹名称。

    • S3://foreniscbucket1/：需要上传文件的目标 S3 存储桶；命令行参数需要使用 s3:// 的命名法

    • --recursive：将源文件夹中的所有内容（包括子文件夹）复制到目标存储桶

    下图反映了复制过程：

图 10.14 – 从命令行界面（CLI）导出文件到 AWS S3

图 10.14 – 从命令行界面（CLI）导出文件到 AWS S3

  1. 如果 aws s3 命令不可用，请运行 sudo apt install aws-cli，然后运行 aws configure 命令，并按照屏幕上的指示配置 AWS 访问密钥和秘密密钥。

  2. 一旦上传完成，你可以通过在线的 S3 控制台验证上传情况。调查人员可以直接在取证工作站上下载文件以进行进一步分析。下图确认了从 EC2 实例成功上传到 S3 存储桶：

图 10.15 – 将取证映像上传到 AWS S3

图 10.15 – 将取证映像上传到 AWS S3

  1. 大多数取证工具可以访问 RAW 文件；调查人员可以将此取证映像添加到他们的取证案例库中，并开始离线处理。

如我们所见，在 AWS 控制台中有一些步骤需要执行，以确保能够访问操作系统和内存来捕获映像。然而，当你导出这些 AWS 实例的证据或完整磁盘映像时，会遇到一些复杂情况，这需要遵循特定的步骤。

Microsoft Azure 实例的取证获取

与 AWS 类似，Microsoft Azure 在收集 Azure 虚拟机 (VM) 实例的完整磁盘映像时提供了类似的方法。你需要专门创建一个快照，然后导出该快照。让我们详细查看这些特定的步骤。

步骤 1 – 创建 Azure 虚拟机快照

如前所述，每个云平台在执行整个磁盘和内存映像的步骤上会有所不同；熟悉这些差异将极大地帮助调查人员，以至于如果取证获取的虚拟机数量较多，他们可以自动化基本任务：

  1. 第一步是确保调查人员获取有关感染的 Azure 虚拟机的信息，包括虚拟机名称和操作系统。

  2. 调查人员可以创建该感染 Azure 虚拟机的完整磁盘快照。调查人员可能更倾向于在拍摄快照前完全关闭虚拟机。快照可以通过虚拟机的导航页面访问。一旦进入快照页面，我们将选择 创建快照 选项，如下图所示：

图 10.16 – 创建 Azure 虚拟机快照

图 10.16 – 创建 Azure 虚拟机快照

  1. 按照屏幕上的指示，创建受感染的 Azure 虚拟机快照。如下一个截图所示，请确保选择正确的资源组，其中包含受感染的虚拟机，以及特定的实例详细信息（我们之前收集的）：

图 10.17 – 创建 Azure 虚拟机快照（详细信息）

图 10.17 – 创建 Azure 虚拟机快照（详细信息）

  1. 在同一屏幕上，选择完整（图 10.18）。微软 Azure 还提供增量快照，它只会捕捉文件系统内所做的更改。由于我们打算完整捕获磁盘镜像，因此我们将选择完整快照以获取完整副本：

图 10.18 – Azure 虚拟机快照选项

图 10.18 – Azure 虚拟机快照选项

  1. 随后，系统会要求你选择将为其创建快照的源磁盘。如以下截图所示，请确保选择正确的磁盘。通常，调查员会对操作系统的根驱动器进行快照；但在某些情况下，调查员可能希望对所有附加到虚拟机的磁盘进行快照。在这些情况下，每个附加到受感染虚拟机的磁盘都需要单独进行快照操作。

图 10.19 – Azure 虚拟机快照磁盘

图 10.19 – Azure 虚拟机快照磁盘

  1. 一旦填写完所有必需的详细信息，你可以让 Azure 创建磁盘快照。完成后，快照将在托管受感染虚拟机的 Azure 订阅内可用。你将在快照仪表板中看到快照的详细信息，如下一个截图所示：

图 10.20 – Azure 虚拟机快照成功完成

图 10.20 – Azure 虚拟机快照成功完成

接下来，我们来看一下如何导出新创建的快照。

步骤 2 – 直接导出 Azure 虚拟机快照

一旦我们完成了步骤 1，调查员可以通过创建新磁盘，连接虚拟机并运行 dd 命令，或者使用第八章中讨论的任何常用工具来附加该快照。然而，微软 Azure 提供了一个选项，在快照创建后可以直接下载：

  1. 在导航菜单中，点击设置选项卡，选择导出快照；此部分提供通过浏览器直接导出任何快照的功能：

图 10.21 – 直接导出 Azure 快照

图 10.21 – 直接导出 Azure 快照

  1. 根据感染卷的大小，调查人员可能需要选择导出快照所需的时间，导出后安全 URL 将过期，无法继续恢复或下载任何内容。微软 Azure 允许的最大时间为 10 小时（36,000 秒）。在我们的示例中，我们正在下载一个 30 GB 的文件，下载时间少于一个小时；因此，我们将其保持在默认值 3,600 秒。Azure 管理员也可以配置特定的身份验证要求，而不是允许安全的唯一 URL 在网上公开可用。调查人员必须记录下 URL，这些 URL 仅显示一次，且离开页面后无法再次访问。尽管这些 URL 在公开的情况下可用，但它们不会通过搜索引擎广泛传播，需要调查人员知道完整的 URL 才能访问这些文件。

  2. 微软 Azure 通常生成两个 URL，一个用于 虚拟硬盘（VHD）文件导出，另一个用于 VM 客户状态 VHD 导出。这两个链接提供不同的文件；然而，调查人员应当下载 VHD 文件用于调查目的。

第 3 步 – 连接到 Azure 虚拟机进行内存映像获取

微软 Azure 提供几种访问虚拟机的选项，其中最常见的是通过 RDP 或 SSH 访问 Azure 虚拟机。或者，Azure 提供一个名为 Bastion 的服务，提供浏览器内访问虚拟机的能力。请参见下方截图，显示了通常可用的选项。左侧选项提供 Bastion，通过浏览器会话代理 RDP 连接到 Azure 虚拟机。右侧选项则是传统的连接方式。为了收集内存映像，我们将通过 Bastion 访问 Azure 虚拟机：

图 10.22 – 连接选项到 Azure 虚拟机

图 10.22 – 连接选项到 Azure 虚拟机

选择 Go To Bastion 后，Azure 会自动创建一个代理隧道服务，允许连接到 Azure 虚拟机。调查人员必须提供用户名和密码才能连接到 Bastion 服务以访问 Azure 虚拟机，如下图所示。此服务类似于 Amazon 的 SSM 服务，后者提供对虚拟机的命令行访问：

图 10.23 – 通过 Bastion 服务连接到 Azure 虚拟机

图 10.23 – 通过 Bastion 服务连接到 Azure 虚拟机

一旦连接到 Azure 虚拟机，调查人员可以按照 第 2b 步 和 第 4a 步 中为 AWS 提供的步骤进行操作。

一旦收集完所有相关文件，调查人员可以选择导出机制，通过第三方文件共享服务或通过 Azure Blob 存储导出内存映像或操作系统文件。

在接下来的章节中，我们将回顾 GCP 的方法，允许调查人员获取并收集快照和内存映像以进行离线取证分析。

GCP 实例的取证获取

就像我们在 AWS 和 Microsoft Azure 中看到的步骤一样，对 GCP 计算实例的取证获取遵循相同的步骤。我们将首先对 计算引擎 实例进行快照，然后将快照作为独立的磁盘附加到另一个取证收集计算实例上，这样我们就可以在通过云存储或其他数据传输方式导出磁盘映像之前进行逐位复制。

步骤 1 – 创建计算引擎实例的快照

那么，让我们来看一下获取计算实例取证映像的前提步骤：

  1. 第一步是创建计算引擎实例的磁盘快照；这可以通过访问 存储 下的导航菜单并选择 快照 来完成。GCP 提供两种类型的快照。第一种是常规快照，包括计算引擎实例的完整磁盘快照；第二种是即时快照，更像是用于快速创建新磁盘卷的磁盘就地备份。即时快照是增量的，这意味着在第一次完整快照之后，只有磁盘的变化会被记录在即时快照中。这通常用于更简便的文件恢复。我们需要一个完整的快照，以便从操作系统层面复制所有内容进行取证。

  2. 在创建快照时，我们必须选择与原始感染实例关联的正确磁盘，如下图所示。与 AWS 和 Microsoft Azure 类似，每个快照都会与一个磁盘关联，因此，当对附加了多个磁盘的计算引擎进行快照时，调查人员必须注意实例附加的磁盘数量，并考虑是否需要对所有其他磁盘进行快照。如果没有其他要求，至少必须选择实例的根驱动器（C:\）进行快照：

图 10.24 – 选择用于快照的磁盘

图 10.24 – 选择用于快照的磁盘

步骤 2 – 附加快照磁盘以进行取证获取

一旦快照完成，调查人员可以在同一 GCP 租户内创建一个新的取证实例，并将该快照作为磁盘源附加。以下是调查人员需要注意的关键步骤：

  1. 创建新实例时，调查人员必须选择附加磁盘并选择最近保存的快照。如以下截图所示，调查人员必须确保在拍摄了多个磁盘快照的情况下，附加正确的快照：

图 10.25 – 在 GCP 中附加磁盘并从快照恢复

图 10.25 – 在 GCP 中附加磁盘并从快照恢复

  1. 一旦磁盘附加，类似于之前列出的 AWS 步骤，调查人员可以通过运行 lsblk -a 命令来验证磁盘是否正确附加，以下截图展示了这一过程：

图 10.26 – 快照作为磁盘附加到 GCP 计算实例

图 10.26 – 快照作为磁盘附加到 GCP 计算实例

  1. 一旦磁盘成功附加，我们将按照 AWS 的步骤 4a通过 dd 命令进行操作。

步骤 3 – 连接到 GCP 计算引擎实例进行内存采集

由于所有云服务提供商的操作方式相同，每个云服务提供商都提供类似 Cloud Shell 或通过 IP 直接连接等远程连接工具。本节将使用 GCP Cloud Shell 连接到感染主机进行内存采集：

  1. 连接到 GCP 的 Cloud Shell 后，它将请求交互式登录以将身份验证令牌传递给 Cloud Shell 会话。或者，管理员可以为调查人员创建适当的服务账户，以便在命令行级别处理身份验证过程，而无需交互式传递凭据。

  2. 在创建服务账户时，调查人员必须确保为服务账户配置了适当的权限，特别是计算管理员和存储对象管理员权限。计算管理员权限将允许调查人员根据需要访问和修改实例，以进行取证采集。相反，存储对象管理员权限将允许具有该权限的服务账户将工件上传到 GCP 的云存储桶。要创建服务账户，必须采取以下步骤：

    1. 在 GCP 控制台内，导航到IAM & 管理员部分。

    2. 点击服务账户，然后点击创建服务账户按钮。

    3. 给服务账户命名并选择授予其必要权限的角色。

    4. 点击创建以创建服务账户。

    对于取证采集，我们创建了一个服务账户，如下截图所示，将用于与计算引擎实例交互：

图 10.27 – 为取证采集创建服务账户

图 10.27 – 为取证采集创建服务账户

  1. 接下来，我们生成密钥以使用服务账户访问计算引擎实例：

    1. 在 GCP 控制台内，导航到IAM & 管理员部分。

    2. 点击服务账户，然后点击需要生成密钥的服务账户名称。

    3. 在密钥标签下，选择添加密钥，然后点击创建新密钥。

    4. 选择JSON作为要创建的密钥文件选项。您将看到一次性显示的详细信息，并可以选择将其下载并保存在计算机上。

  2. 调查人员可以在通过 Cloud Shell 连接到计算引擎实例时，使用此服务账户或其交互账户。本质上，服务账户提供了一组容器化的角色，调查人员可以用它来安全地访问计算实例。

  3. 一旦我们通过 Cloud Shell 或直接通过 RDP 获得计算实例的访问权限，我们将按照 AWS 的步骤 2b进行操作，以进行内存采集。

  4. 要导出内存镜像，调查人员可以将文件上传到由 DFIR 团队托管的远程服务器或 GCP 的云存储桶。为此，可以使用已创建的服务帐户。我们将以在 Windows 设备上使用 PowerShell 导出内存镜像为例。我们将首先下载 JSON 文件或将内容复制到我们在步骤 3中生成的 JSON 文件中。

  5. 使用 PowerShell，我们将运行以下命令；您必须确保gcloud：

    gcloud auth activate-service-account forensic-collector@vaulted-timing-390314.iam.gserviceaccount.com --key-file=./KEY.json --project=vaulted-timing-390314

    gcloud是我们用于连接 GCP 控制台的命令。以下参数用于成功建立与 GCP 的连接：

    • gcloud auth activate-service-account：此命令用于激活服务帐户进行身份验证。

    • forensic-collector@vaulted-timing-390314.iam.gserviceaccount.com：这是需要激活的服务帐户的完整电子邮件地址（在 Google IAM 下创建）。

    • key-file=./KEY.json：此参数指定与服务帐户相关联的 JSON 密钥文件的路径。确保 JSON 文件路径存在。

    • --project=vaulted-timing-390314：表示 GCP 分配的项目名称，服务帐户与该项目关联。

    一旦服务帐户通过身份验证，调查人员可以使用以下命令将内存镜像和其他工件上传到GCP 云存储（GCS）桶中：

    gsutil cp <memory.img> gs://<bucket_name>

    以下是用于将内存镜像导出到存储区域的参数：

    • cp：gsutil的子命令，用于将文件和对象复制到 GCS 桶以及从 GCS 桶复制

    • <memory.img>：存储在主机实例上的内存镜像的文件名和完整路径

    • gs://<bucket_name>：文件将被导出的目标 GCS 桶

一旦内存镜像或任何其他工件通过gsutil导出，调查人员就可以继续从存储中获取这些工件进行离线分析。他们可以继续将这些镜像保留在存储区域，只要它不公开访问，并且访问控制被严格定义。

总结

总结一下，当调查人员可以访问操作系统时，收集法医工件、磁盘镜像和内存转储的基本原则是相似的。如果他们在调查过程中可以访问计算机或设备，过程也非常相似。更重要的是要学习在事件响应情况下如何安全地访问操作系统的步骤。

破解云端法医数据采集的难题；然而，调查人员必须熟悉如何在不对实例进行重大修改的情况下获取完整磁盘访问权限，例如添加新的空磁盘或仅安装工具来创建完整磁盘镜像，并克服导出过程中的各种挑战。大多数云服务都提供快照整个磁盘的选项，这使得数据收集更加便捷。至于内存转储，遗憾的是，目前没有比直接进入感染机器并使用工具转储内存更好的选择。调查人员需要尽量减少在易变内存中的法医痕迹。

下一章将讲解容器化实例，如 Docker 和 Kubernetes。在法医领域，容器化实例带来了不同的挑战，尤其在云端托管时，挑战更为复杂，调查人员需要进行分析。下一章将深入探讨云端容器法医分析。

进一步阅读

第十一章：分析受损容器

到目前为止，我们已经了解了一些标准方法和技术，用于获取和分析 虚拟机（VM）和云服务的取证镜像。然而，开发和分析一个容器化环境带来了全新的挑战。

在今天的技术环境中，容器化和 Kubernetes 协调已成为现代应用程序部署的基础；因此，确保这些容器的安全至关重要。容器在效率和可扩展性方面提供了巨大的好处，但也带来了新的挑战，其中安全性是最重要的关注点。

本章旨在了解容器的架构以及如何通过 Kubernetes 管理和协调容器。

在本章中，我们将讨论以下主题：

  • 什么是容器？

  • 检测和分析受损容器

什么是容器？

容器是轻量级的、独立的、可执行的包，包含运行软件所需的所有内容，包括代码、运行时、系统工具、库和设置。它们被设计用来在不同的计算环境中提供一致性，从开发和测试到生产部署，通过将应用程序及其依赖项封装在容器化环境中。

容器化部署的一些关键优势包括以下几点：

  • 隔离性：容器使用操作系统级虚拟化来创建隔离的环境。每个容器与主机共享相同的操作系统内核，但独立运行，确保与同一系统上其他容器的隔离。

  • 可移植性：容器具有高度的可移植性，允许你在各种平台上（如 Linux 发行版或云服务提供商）一致地运行相同的应用程序。Docker 和容器运行时等容器化技术实现了这种可移植性。

  • 轻量级：与传统虚拟机相比，容器更加轻量。它们消耗更少的系统资源，因为它们不需要完整的操作系统，只包含应用程序及其依赖项。

  • 资源效率：容器启动和停止速度快，使得它们在根据工作负载变化动态地扩展和缩减应用程序时更为高效。

  • 不可变基础设施：容器通常是从预定义的镜像创建的。当你需要更新应用程序时，可以构建一个新的容器镜像并加入更改，从而确保基础设施的一致性和可重复性。

  • 协调：像 Kubernetes 这样的容器协调平台提供了容器化应用程序的自动化管理，包括扩展、负载均衡和自愈，使其适用于部署和管理基于微服务的架构。

  • 版本控制：容器镜像可以进行版本控制，这使得在出现问题时可以轻松回滚到之前的版本。这支持更可控的软件开发和部署过程。

  • 安全隔离：容器提供一定程度的安全隔离。然而，正确配置和管理容器是至关重要的，只有这样才能确保遵循适当的安全实践。

  • DevOps 与 CI/CD：容器是DevOps实践中的基础工具，因为它们促进了持续集成与持续部署（CI/CD）流程，使软件开发和交付过程更加高效和自动化。

  • 微服务：容器通常用于微服务架构，其中应用被拆分成小型、独立的服务，能够单独部署和扩展。

Docker 与 Kubernetes

尽管 Docker 和 Kubernetes 是最流行的容器化技术，但它们各自服务于不同的目的：

  • Docker：Docker 是一个容器化平台，允许开发者将应用及其依赖打包成一个单一、可移植的容器单元。容器轻量且高效，为在不同系统上运行应用提供了一致的环境。Docker 通过封装应用运行所需的一切，简化了开发过程，确保应用从开发者的笔记本电脑到生产服务器的运行一致性。

    Docker 的易用性和用户友好的命令行界面（CLI）使得它在开发者和运维团队中极为流行。它是本地开发、创建容器镜像以及通过 Docker Hub 或私有注册表共享镜像的宝贵工具。Docker 的主要关注点是应用打包和分发，通常被用作构建可以在不同环境中运行的容器镜像的基础。

  • Kubernetes：Kubernetes，常简称为K8s，是一个开源的容器编排平台，负责管理容器化应用的部署、扩展和运行。虽然 Docker 主要关注单个容器的打包和运行，Kubernetes 则通过将多个容器编排成组或服务，采用更高层次的方式进行管理。它自动化了负载均衡、扩展、滚动更新和自愈等任务，非常适合复杂和分布式的应用架构。

    Kubernetes 对于基于微服务的应用特别有价值，尤其是在多个容器需要无缝协作的情况下。它抽象了底层基础设施，并提供了一个统一的 API 来管理不同环境中的容器，比如本地服务器、公有云或混合环境。Kubernetes 确保高可用性（HA）、容错性（FT）和资源效率，使其成为现代容器化应用部署的基石。

简而言之，Docker 和 Kubernetes 是相辅相成的技术。Docker 非常适合创建和打包单个容器，而 Kubernetes 是用于协调、扩展和管理这些容器在更大生态系统中的理想解决方案。它们可以一起使用，Docker 提供的容器镜像由 Kubernetes 部署和协调，帮助组织构建和管理具有弹性、可扩展且高效的容器化应用。选择 Docker 还是 Kubernetes 主要取决于你的具体需求以及你所处的应用生命周期阶段。

容器已经彻底改变了应用程序的开发、部署和管理方式，提供了一种一致且高效的方式来打包和运行跨多个环境的软件。在下一节中，我们将深入探讨容器的类型及其应用场景。

容器类型及其使用场景

如前一节所示，容器是以各种形式打包的应用程序。接下来是一些容器的形式及其潜在的使用场景：

  • Docker 容器：Docker 容器可能是最著名且最广泛使用的类型。Docker 提供了一个平台，用于开发、传输和运行容器应用。Docker 容器具有高度的可移植性且易于管理，使其适用于各种使用场景。

  • Linux 容器（LXC）：LXC 是一种操作系统级虚拟化方法，利用 Linux 内核的组和命名空间来创建隔离的环境。LXC 容器不如 Docker 容易使用，但提供更多的灵活性和控制，因此适合需要定制的特定场景。

  • rkt（发音为 rocket）是一个侧重于安全性和简洁性的替代容器运行时。它设计得比 Docker 更加安全和轻量，在某些 Kubernetes 部署中被使用。

  • containerd 是一种行业标准的核心容器运行时，广泛应用于各种容器平台和编排系统。它旨在成为一个简单且可靠的容器运行时。

  • Podman 容器：Podman 是一款开源容器管理工具，兼容 Docker，但提供更安全、无 root 权限的容器体验。它适用于需要 Docker 兼容性并且增加了安全性的场景。

  • OpenVZ 容器：OpenVZ 是一种提供轻量级虚拟化的容器化技术。它与传统容器不同，因为它使用共享内核，提供比典型容器更多的隔离性，但比完全虚拟化少。

  • FreeBSD Jail：FreeBSD Jail 与 Linux 容器类似，但它是专为 FreeBSD 操作系统设计的。它为 FreeBSD 系统提供了轻量级的虚拟化。

  • Windows 容器：Windows Server 也支持容器化，尽管大多数容器与 Linux 相关联。Windows 容器能够在隔离的环境中运行基于 Windows 的应用程序。

  • systemd-nspawn是systemd init系统提供的一种容器化工具。它提供轻量级的操作系统级虚拟化，通常用于 Linux 系统中的开发和测试环境。

  • Kata 容器：Kata 容器是一个开源项目，它结合了虚拟机的安全性优势和容器的高效性与速度。它旨在处理需要高等级隔离的工作负载。

以下是企业通常利用容器化环境部署的一些使用案例：

  • 应用打包和分发：容器将应用程序及其所有依赖项打包成一个单一的、可移植的单元。这确保了在不同环境中（从开发到生产）的应用程序部署的一致性和可靠性。

  • 微服务架构：容器是微服务的核心，在微服务架构中，应用程序被拆分成小的、独立的服务。每个微服务都在自己的容器中运行，从而实现可扩展性、灵活性和易于维护。

  • 开发和测试：开发人员使用容器创建隔离的开发和测试环境，以模拟生产条件。这确保了应用程序按预期运行，并消除了“在我 的机器上工作”的问题。

  • CI/CD：容器支持流畅的 CI/CD 管道。开发人员将代码及其依赖项打包到容器中，进行自动化测试、部署和扩展，从而提高软件交付速度和可靠性。

  • 多云和混合云部署：容器可以在不同的云服务提供商和本地环境中保持一致的运行。这使得容器适用于多云和混合云策略，从而实现云无关的应用程序部署。

  • 隔离和安全性：容器提供了轻量级的应用程序隔离，增强了安全性，并减少了应用程序之间发生冲突或出现漏洞的风险。

  • 传统应用程序现代化：容器可以封装传统应用程序，使其更加可移植且易于管理。这帮助组织在不重写代码的情况下实现现有系统的现代化。

  • 可扩展性和负载均衡：容器可以根据工作负载的变化快速进行扩展或缩减，这使它们非常适合需要弹性扩展和高效资源利用的应用程序。

  • 有状态和无状态：容器可以用于有状态和无状态应用程序。像数据库这样的有状态应用程序可以在容器中运行，而无状态服务可以水平扩展。

  • 资源效率：容器是轻量级的，相比传统虚拟机（VM），它们需要更少的系统资源，从而提高了资源利用率并节省了成本。

  • 编排：如 Kubernetes 等容器编排平台提供了容器的自动化管理。它们处理扩展、负载均衡和自我修复，非常适合复杂的应用程序架构。

  • 高可用性（HA）和灾难恢复（DR）：容器可以在多个节点和数据中心之间进行编排，以确保 HA 和 DR 能力，从而减少停机时间和数据丢失。

  • 服务发现和负载均衡：容器可以轻松与服务发现和负载均衡解决方案集成，以确保服务之间的高效通信和流量分配。

  • 内容交付和内容交付网络（CDNs）：CDN 使用容器来缓存和全球分发内容，从而减少延迟并提升内容交付性能。

  • 数据处理和分析：容器用于运行数据处理和分析工作负载，为与数据相关的任务提供可扩展和隔离的环境。

  • 物联网（IoT）和边缘计算：容器可以用于在边缘设备和物联网设备上部署和管理应用程序，将计算带到数据源附近。

  • 桌面虚拟化：容器可用于桌面虚拟化，使用户能够运行具有特定应用程序和配置的隔离桌面环境。

在接下来的几节中，我们将探讨如何分析被破坏的容器，所需的步骤，以及可以应用于安全地收集容器化环境取证镜像的取证收集机制。

检测和分析被破坏的容器

大多数组织通过 Kubernetes 运营容器架构，因为它提供了更多可扩展的选项和灵活性。在深入探讨容器分析之前，理解 Kubernetes 的组成部分至关重要，因为它们在调查过程中将发挥关键作用。

关于 Kubernetes 编排平台

以下截图展示了 Kubernetes 集群的基本架构；总的来说，正如我们所知，Kubernetes 是一个编排框架，管理一个或多个运行容器的节点：

图 11.1 – 简单的 Kubernetes 架构

图 11.1 – 简单的 Kubernetes 架构

对于 Kubernetes 集群，你需要一个主节点来控制和协调集群的操作，以及运行由主节点分配的 Pod 和任务的工作节点。以下是 Kubernetes 集群中的一些关键组件：

  • kubectl 命令。API 服务器作为 RESTful API 服务器运行，这意味着它是一个无状态协议，服务器不会保留之前请求的信息。

  • 调度器：调度器负责确定将 Pod 调度到集群中可用节点的最优位置。其主要功能是根据资源需求、节点亲和性以及用户定义的约束条件做出智能调度决策。通过评估每个节点上可用的资源，调度器旨在平衡集群中的工作负载，确保资源的高效利用。调度器还支持 Pod 优先级、抢占、亲和性规则和污点/容忍等功能，为工作负载分配提供灵活性和定制化。此外，Kubernetes 还允许创建自定义调度器，以满足特定的部署需求。

  • 控制器管理器：Kubernetes 架构的核心组件之一，负责管理各种控制器，这些控制器调节集群的状态。每个控制器是一个独立的进程，负责监控并调和集群对象的实际状态与其在 Kubernetes API 服务器中定义的期望状态。控制器管理器管理的关键控制器包括以下内容：

    • 复制控制器，确保指定数量的 Pod 副本正在运行

    • 节点控制器，负责节点生命周期和服务账户

    • 令牌控制器，管理服务账户和 API 访问令牌的生命周期

    控制器管理器通过持续监控并调整集群以保持期望配置，从而增强 Kubernetes 的自愈能力，确保容器化应用的高可用性和弹性。

  • etcd 是一个分布式键值存储，Kubernetes 的核心，作为集群配置和状态的主要数据仓库。使用etcd可以确保跨分布式节点的强一致性和高可用性（HA），提供可靠性和容错（FT）。它在集群协调中扮演着至关重要的角色，允许 API 服务器和控制器管理器等组件同步并共享实时信息。etcd还支持数据备份、安全通信以及动态更新的监视机制，为 Kubernetes 集群的弹性和效率做出贡献，是管理容器化应用的关键基础。

  • containerd）用于管理节点上的容器，实施 Pod 规格中描述的期望状态。此外，kubelet 会对容器进行健康检查，并在必要时重启失败的容器，同时将节点的状态报告回控制平面。

  • localhost。这一设计使得它们可以轻松共享数据和依赖关系。Pods 是在 Kubernetes 上部署应用程序的基本构建块，它们封装一个或多个容器，包含共享的存储资源以及如何运行这些容器的选项。Kubernetes API 服务器管理 Pods，并可以根据容器化应用程序的动态需求对其进行复制、扩展和更新。

  • kube-proxy 是 Kubernetes 中一个至关重要的组件，负责网络代理和负载均衡。它在服务层面运行，通过维护网络规则并根据集群服务和端点的变化进行更新，促进 Pods 和服务之间的通信。kube-proxy 具备服务发现、负载均衡和管理 NodePort 服务的功能，确保集群内的高效和可靠的网络连接。它抽象了网络的复杂性，在 Kubernetes 环境中，kube-proxy 扮演着实现容器化应用程序各个组件之间无缝通信的关键角色。

你可以通过运行以下命令来探索 Kubernetes 架构：

kubectl get pods -n kube-system --show-labels
see various parts of Kubernetes architecture, such as the kube-dns, kube-proxy, the gke for Google Kubernetes Engine (GKE):

图 11.2 – 与 GKE 集群系统相关的 Pods 列表（无应用程序 Pods）

图 11.2 – 与 GKE 集群系统相关的 Pods 列表（无应用程序 Pods）

在下一节中，我们将重点讨论如何提取日志进行调查。现在我们已经了解了 Kubernetes 架构，访问这些日志将变得更加容易和简便。

获取法医数据和容器日志进行分析

现在我们已经了解了 Kubernetes 架构的关键组件，让我们看看调查人员如何从集群中获取日志/证据。

容器日志

Kubernetes 集群内通常可以找到各种日志；其中一些是操作日志，意味着它们与集群的健康状态相关，而另一些则与容器内运行的应用程序相关。这些日志对于数字取证与事件响应（DFIR）团队来说特别有用，可以帮助调查涉及 Kubernetes 集群的恶意活动。

为了理解日志，我们将其分为两类——操作日志和安全日志——以及它们的使用场景。你会注意到，有些日志提供了操作性见解，安全日志则：

操作日志：

  • API 服务器日志：从 Kubernetes 架构的角度来看，API 服务器在确保 Kubernetes 集群高效运行中起着至关重要的作用。API 服务器日志提供有关 API 活动的见解，包括请求、响应和身份验证详细信息。具体而言，API 服务器日志有助于监控 API 服务器的健康状态、跟踪用户活动并排查与 API 相关的问题。

    你可以使用以下命令访问 API 服务器日志：

    kubectl logs -n kube-system <api-server-pod-name>

  • 控制器管理器日志：提供与控制器活动相关的日志，如节点、复制和集群交互。对于监控控制器健康状况、跟踪控制器决策和理解复制及服务相关事件非常有用。您可以通过以下命令访问与控制器管理器相关的事件：

    kubectl logs -n kube-system <controller-manager-pod-name>

  • 调度器日志：记录与 Kubernetes 调度器所做调度决策相关的日志，如 Pod 放置。此日志有助于理解和监控工作负载分配、调度决策和节点利用率。您可以通过以下命令访问 Kubernetes 控制器的特定日志：

    kubectl logs -n kube-system <scheduler-pod-name>

  • kubelet 日志：提供有关 Pod 生命周期事件、容器运行时交互和心跳的详细信息；与 kubelet 相关的日志提供关于 Pod 健康状况和运行时问题的见解。您可以通过以下命令访问与特定 Pod 相关的日志；请注意，此命令将获取与运行 Pod 相关的操作事件，而不是 Pod 内运行的应用程序日志：

    kube-proxy contains logs associated with proxying operations, network rules, and load-balancing activities. kube-proxy logs help monitor network-related issues and understand load-balancing issues. To access kube-proxy logs, the following command is utilized:

    etcd 节点。etcd 日志为监控 etcd 健康状况、跟踪集群状态变化以及理解与 etcd 相关的问题提供了关键的见解。您可以使用类似的命令访问 etcd 日志：

    journalctl -u docker or journalctl -u containerd. However, if you are running Kubernetes on a cloud platform such as GCP, the best way to access container runtime logs is via Logs Explorer or an equivalent log viewer offered by the cloud service provider (CSP).

  • kubectl 命令：

    kubectl logs -n kube-system <network plugin pod name>

  • Ingress 控制器日志：在外部网络流量无法连接到预期的 Kubernetes Pod 时，调查问题非常重要。常见原因可能是 ingress 控制器本身的配置错误。Ingress 控制器还负责终止 SSL/TLS 连接；监控这些事件可以提供关于因证书过期导致的服务中断的重要信息。类似于访问其他日志，您可以通过以下命令访问 Ingress 控制器日志：

    kubectl logs -n kube-system <ingress controller pod name>

安全日志：

  • API 服务器日志：从 DFIR 的角度来看，调查人员可以查看 API 服务器日志，以识别未经授权的访问尝试或身份验证失败。您还可以使用 API 服务器日志监控关键资源（如通过 API 服务器日志的 Pods）的可疑变化。

  • kubelet 日志：您可以使用 kubelet 日志来查找容器异常。kubelet 日志可以提供有关意外行为或网络活动的见解。您还可以使用 kubelet 日志来调查节点级别的活动、资源耗尽或异常活动。

  • 使用 etcd 日志来识别数据损坏或不一致性。

  • 使用 tcpdump 命令来验证网络流量活动：

    kubectl exec -it <pod-name> -- tcpdump -i eth0

    网络插件日志提供有关 Pod 之间恶意网络流量的见解，并识别横向移动的证据。

总的来说，Kubernetes 提供了一个框架，可以访问每个 Pod 内的日志；然而，如果集群运行在云平台上，调查人员还可以利用每个 CSP 提供的原生日志查看器，快速访问日志，而无需直接通过集群访问日志。在接下来的部分，我们将从两个角度来看待访问日志：通过集群直接访问和使用 CSP 的日志控制台访问 Kubernetes 集群日志进行调查。

检查容器运行时

假设你现在有一个运行在云上的 Kubernetes 集群和一个暴露给互联网、接受用户连接的 Pod（应用程序）设置。为了说明调查方法，我们定义一个场景。我们在 Google Cloud 上部署了一个 Kubernetes 集群，WordPress 和 MySQL 服务器作为 Pod 部署。正如下图所示，我们有三个 Pod 组成了应用的一部分：

图 11.3 – GKE 集群下的 Pod

图 11.3 – GKE 集群下的 Pod

这些 Pod 被配置为 MySQL 存储 WordPress 博客的内容和认证信息。作为调查人员，我们的任务是调查 MySQL 服务器上的暴力破解尝试。

现在，有多种方法可以解决这个问题。最流行的方法是使用 Google 的 Log Explorer。在我们使用云工具进行调查时，你也可以使用其他 CSP 执行类似的任务，只要 Kubernetes 日志被配置为在 CSP 的云日志工具中获取。目前，有两种方法可以调查/访问日志。一种是通过 Log Explorer，另一种是通过命令行。调查人员可以选择提取日志并进行分析。我们将探索这两种方法并确定结果。在调查 Kubernetes 之前，调查人员必须了解组织是如何部署 Kubernetes 集群及其架构的。

选项 1 – Log Explorer

  1. 一旦调查人员可以访问 Log Explorer，我们就可以直接开始定位与 WordPress 和 MySQL 服务器相关的活动。请记住，WordPress 是一个前端工具，而 MySQL 服务器提供后端数据库，是完整应用栈的一部分。

  2. 通过初步筛查，我们知道发生了暴力破解尝试；资源使用仪表板可以验证这一点。以下是一个示例屏幕截图，显示了与 Kubernetes 集群相关的总体资源度量，突出了资源使用的增加：

图 11.4 – Kubernetes 集群资源使用

图 11.4 – Kubernetes 集群资源使用

  1. 一旦我们建立了基础知识，我们就进入 Log Explorer 页面。如果你熟悉查询 Log Explorer，你可以查询集群中 default 命名空间的日志，并且容器名称不是 wordpress。接下来是收集所有与 WordPress 无关的日志的搜索查询代码：

    resource.labels.namespace_name="default"
-resource.labels.container_name="wordpress"

  2. 通常，暴力破解尝试可以通过一系列失败的登录尝试后跟成功的登录尝试来识别。我们将修改前面的查询，以准确定位调查员失败的 MySQL 访问尝试。作为调查员，如果我们不熟悉 Google 的 Log Explorer 查询功能，我们可以随时点击并选择适当的过滤器，查询会自动更新：

    resource.labels.namespace_name="default"
-resource.labels.container_name="wordpress"
--Show similar entries
textPayload=~"(\d{4}-(0[1-9]|1[0-2])-(0[1-9]|[12][0-9]|3[01])) ((\d{2}):(\d{2})(?::(\d{2}(?:\.\d*)?))?(?:(+-:?(?:\d{2})?|Z)?)) ((?:\d[,.]?)*\d) \[Warning\] Access denied for user '[^ =\t\n\r\f\"\(\)\[\]\|']+'@'localhost' \(using password: [^ =\t\n\r\f\"\(\)\[\]\|']+"
--End of show similar entries

  3. 一旦过滤掉日志，你可以迅速定位到与暴力破解攻击相关的日志。下一张截图展示了使用 Log Explorer 分析的结果。在截图中，你可以看到多次对 MySQL 的失败登录尝试后，才有一次成功登录。根据所部署的容器，某些日志还可能收集更详细的信息。在这种情况下，我们可以看到攻击者尝试使用不同的用户名进行登录，直到成功通过 wp-admin 账户连接到服务器。

图 11.5 – Kubernetes Pod 上暴力破解攻击的分析

图 11.5 – Kubernetes Pod 上暴力破解攻击的分析

接下来，我们将探讨如何通过命令行直接访问日志。

选项 2 – 直接命令行访问（kubectl）

在无法访问 CSP 日志服务的情况下，作为调查员，你可以始终使用 kubectl 来访问这些独立的基于 Pod 的日志。

从 Pod 中访问日志相对容易。一旦列出了所有的 Pod，你可以使用kubectl logs <pod name>来访问完整的日志。日志默认打印到控制台；然而，你也可以将日志写入磁盘以供离线分析。在这种情况下，让我们提取与 MySQL Pod 相关的日志——kubectl logs wordpress-1-mysql-0。接下来的截图展示了与暴力破解攻击相关的日志：

图 11.6 – MySQL Pod 的日志摘录，证明暴力破解攻击

图 11.6 – MySQL Pod 的日志摘录，证明暴力破解攻击

作为调查员，我们了解日志的重要性；在 Kubernetes 中，每个 Pod 都会有与其运行的应用程序相关的日志，以及其他操作日志。然而，了解如何访问这些日志至关重要，因为调查员对 CSP 日志控制台的访问也会极大地帮助他们，因为这些日志通常会保存得比查找 Pod 本身更久。

总结

本章探讨了 Docker 和 Kubernetes 之间的区别，强调了它们在全面的容器管理中的协作使用。我们深入研究了各种类型的容器及其具体应用场景，突出了它们在微服务架构等场景中的高效性。

此外，我们还研究了在 Kubernetes 环境中获取取证数据和日志以供分析，重点介绍了日志机制、工具和最佳实践，便于实际的取证分析，包括识别安全漏洞和事件调查。然而，访问 Kubernetes 日志是最直接的调查之一。如果 Kubernetes 部署在云端，云服务提供商（CSP）对于提供集中式日志浏览器进行长期日志访问至关重要。

在我们下一章中，我们将回顾 Microsoft 365 和 Google Workspace 托管的云生产力套件的分析。本章的重点是了解如何分析生产力套件中的常见威胁向量，以及调查人员可以访问哪些日志。

深入阅读

第十二章：分析被妥协的云生产力套件

现实情况是，组织内部的大多数基于云的安全事件都发生在生产力套件层面。正如我们在 第七章中讨论的那样，Microsoft 365 和 Google Workspace 是行业中最受欢迎的基于 SaaS 的平台。组织依赖 Microsoft 365 和 Google Workspace 来处理业务应用程序和服务，如电子邮件、存储、办公应用程序等。随着越来越多的公司采用基于 SaaS 的电子邮件解决方案，Microsoft 365 和 Google Workspace 已成为企业邮箱诈骗攻击的主要目标。由于这些电子邮件账户与 365 和 Workspace 内的其他服务密切相关，因此这些妥协行为也会对与用户账户连接的任何其他服务构成风险，放大了更广泛的安全漏洞和更大影响的可能性。

本章将深入探讨被妥协的生产力套件，特别是 Microsoft 365 和 Google Workspace，从头到尾。我们将在本章中讨论以下主题：

  • 企业邮箱诈骗解析

  • 初步范围界定与修复步骤

  • Microsoft 365 事件响应

  • Google Workspace 事件响应

企业邮箱诈骗解析

企业邮箱诈骗（BEC）是一种复杂的网络欺诈类型，通过涉及电子邮件通讯的欺骗行为，针对组织实施攻击。此类威胁利用企业依赖电子邮件进行公司通讯的特性，操纵信任和权威执行某些未经授权的资金转移、获取敏感信息或在 IT 网络中进行横向移动。

BEC 攻击阶段

攻击者利用的 BEC 攻击阶段在图 12.1 中展示：

图 12.1 – BEC 攻击阶段

图 12.1 – BEC 攻击阶段

在观察了图中列出的阶段后，我们将深入分析每个阶段，并进行详细分解：

  • 侦察：在此阶段，攻击者仔细研究受害组织的层级结构、沟通模式以及使用的特定行话。如果攻击者已经访问了某个账户，他们只需在电子邮件系统内进行搜索，以了解该组织的沟通模式和行话。否则，攻击者会利用来自 LinkedIn 或受害组织网站等各种来源的公开信息。攻击者可能会使用公开可得的信息、社会工程学策略，甚至以前的数据泄露来收集数据。这个侦察阶段使他们能够制作出模拟组织内部用户的可信邮件，并伪装或锁定特定的目标账户。

    BEC 攻击通常不是随机的大规模邮件发送，而是针对组织中的特定个人，如具有财务权限或可以访问机密数据的人。例如，组织的首席财务官（CFO）通常是攻击者的目标，因为他们不仅能访问机密的财务信息，还拥有批准交易的权限。

  • 电子邮件伪造或账户接管：攻击者通过伪造合法的电子邮件地址或非法访问合法账户来发起攻击，通常是通过网络钓鱼攻击或利用薄弱的安全措施。

    攻击者常常创建“假”网站，这些网站看起来与流行生产力套件（如 Microsoft 365 或 Google Workspace）的登录页面相同。他们通过修改 HTML 和 CSS，复制这些合法站点的样式来实现这一点。这些假网站的域名通常是对真实域名的轻微修改，旨在让它们看起来像是属于组织的生产力套件租户。例如，微软 365 的假域名可能是microsoft365-login.com，而不是合法的microsoft.com；Google Workspace 的假域名可能是googledocs-signin.com，而不是google.com。这些欺诈页面通常包含设计用来收集并将用户凭证传送给攻击者的表单。未察觉的用户如果在这些假页面上输入登录信息，就无意中将他们的个人或企业账户的访问权限交给攻击者，从而导致账户被盗。

    如果攻击者无法访问组织中的账户，他们通常会购买看起来与组织名称非常相似的域名。例如，攻击者可以从域名注册商处购买AMCE.com，而不是ACME.com，从而创建共享这些域名的电子邮件账户，这些账户与受害组织中合法用户的电子邮件地址非常相似。举个例子，攻击者可能会设置并使用Alice@AMCE.com，以模拟来自 ACME 的合法用户和账户。大多数用户在电子邮件往来中不会注意到ACME和AMCE之间的微小差别。

  • 准备阶段：在这个阶段，攻击者准备他们将用于执行攻击的工具和方法。这可能包括制作具有说服力的网络钓鱼邮件、创建假发票或设置银行账户以接收欺诈性付款。这一过程取决于他们的目标和攻击的 BEC 类型，我们将在下一部分讨论这一点。

  • 利用阶段：在这个阶段，受害者与电子邮件进行互动，导致攻击者实现他们期望的结果。对于 BEC 攻击，这通常意味着按照邮件中的指示操作，比如转账或提供机密信息。

  • 恶意软件安装（如果适用）：虽然不一定是 BEC 的一部分，但在某些情况下，攻击者可能会利用这一机会在受害者系统上安装恶意软件。这可能是为了长期访问、数据外泄，或为了促进进一步的攻击。这就是攻击者如何从云端托管和保护的生产力套件账户转向实际设备并侵入组织 IT 网络。

  • 目标行动：攻击者的最终目标在这一阶段得以实现。对于 BEC 而言，通常涉及将资金未经授权地转移到攻击者的账户，或获取敏感信息。一旦攻击者获得了他们寻求的资金或信息，他们的目标就达成了。

  • 持久性和反取证（如果适用）：在复杂的 BEC（商业电子邮件攻击）方案中，攻击者可能会尝试保持对受害者系统的访问，以便进行未来的攻击或隐藏其活动的证据。这可能包括在网络外设置自动转发规则、删除电子邮件证据、通过应用程序许可创建后门，或使用其他技术来掩盖他们的存在。

常见的 BEC 类型

现在我们已经探讨了 BEC 攻击的各个阶段，接下来让我们讨论组织常遇到的 BEC 类型：

  • 发票欺诈：骗子冒充目标公司的供应商或卖家，要求为服务或商品向一个虚假账户支付款项。

  • 高层管理人员欺诈：攻击者冒充公司首席执行官或其他高层管理人员，向员工发送电子邮件，通常是财务部门的员工，指示他们将资金转账到攻击者控制的账户。

  • 律师冒充：攻击者冒充公司相关律师或法律代表，通常以紧急和机密事务为幌子，误导资金或获取敏感信息。

  • 数据盗窃：这里的目标不一定是立即获得财务收益，而是盗取敏感数据，这些数据可能是员工的税务信息、知识产权或客户数据。

  • 账户妥协：员工的电子邮件账户被黑客入侵，之后被用来向其电子邮件联系人列表中的供应商请求付款。

  • 凭证收集：员工的电子邮件账户被黑客入侵，之后被用来从公司外部进一步收集更多的凭证，如信任的合同和供应商。

  • 攻击者的动机：BEC 攻击的主要动机是财务获利。攻击者利用商业通信渠道中的信任关系，转移资金或获取可变现的敏感信息。此外，从这些攻击中收集到的数据，如凭证、员工个人信息或知识产权，可以在暗网出售，或用于进一步的攻击，包括重复的 BEC 攻击和勒索病毒。由于这些攻击的复杂性和针对性，它们往往具有更高的成功率，并可能为攻击者带来更大的财务回报，使 BEC 成为一种有利可图的网络犯罪形式。

深入了解各种 BEC 攻击类型，从发票欺诈到数据盗窃，对于有效防御这些复杂且具有财务动机的网络威胁至关重要。识别 BEC 攻击的类型可以让技术和业务控制措施共同防止这些事件的发生。例如，组织可以实施控制措施，通过口头验证超过特定金额的交易批准，以防止发票欺诈和高层管理人员欺诈。

初步范围界定和响应

在作为事件响应者应对 BEC 攻击时，初步范围界定阶段对于了解事件的广度和深度至关重要。这个阶段涉及尽可能多地收集信息，以便准确评估情况。初步范围界定包括与云生产力套件（Microsoft 365 或 Google Workspace）的 IT 管理员、公司总法律顾问、高层管理人员和会计人员进行沟通，以便在进行任何技术取证分析之前，更好地了解以下内容：

  • 攻击时间线：了解攻击开始的时间至关重要。询问何时首次发现安全漏洞的迹象，以及用户在何时注意到可疑活动。这可能包括异常的电子邮件活动、来自组织内外的可疑电子邮件报告，或被标记为异常的财务交易。如果攻击者成功转移了任何未经授权的资金，请在时间线上注明这些日期。

  • 妥协的范围：确定哪些账户已被妥协。这涉及检查是否存在未经授权访问的迹象，例如来自不熟悉位置或设备的登录尝试，以及账户设置或权限的变更，这些变更并非由账户所有者发起。如果攻击者成功入侵，生产力套件的 IT 管理员应已经缩小了受影响的账户范围。我们将在Microsoft 365 事件响应和Google Workspace 事件响应部分讨论如何确定妥协的证据。

  • 攻击向量：调查攻击者是如何获得访问权限的。是通过钓鱼邮件、凭证填充，还是利用安全漏洞？了解攻击向量对于防止未来的安全漏洞至关重要。在某些情况下，用户可能记得他们在什么时刻将凭证输入到钓鱼网站。此外，组织和/或个人用户过去是否遭受过数据泄露？如果是，用户名和凭证可能已经在暗网中流通。员工使用公司电子邮件地址进行个人服务并不罕见。如果这些个人服务遭遇数据泄露，员工的公司信息可能会暴露。

  • 数据外泄：评估已被访问或外泄的信息。这包括敏感的电子邮件、附件以及任何存储在受损账户中的数据。了解暴露的数据类型有助于理解泄露的潜在影响。

  • 与受影响方的沟通：确定哪些人受到了泄露事件的影响，包括内部和外部人员。这可能包括员工、客户或与受损账户有过通信的业务合作伙伴。

  • 现有安全措施：回顾现有的安全措施。是否有任何安全协议被绕过或无效？这可能包括多因素身份验证、定期更换密码和员工培训以识别钓鱼攻击。

  • 之前的事件：询问是否有类似的历史事件。了解过去的事件可以为发现潜在的弱点或重复的攻击模式提供线索。重复攻击变得越来越常见，尤其是在攻击者曾经成功转移资金的情况下，他们可能会把一个组织视为容易重复攻击的目标。

  • 当前响应措施：检查在发现攻击后已采取的措施。这可能包括更改密码、将可能受损的系统从网络中断开连接或通知受影响的个人。

  • Microsoft 365 访问权限：这是作为事件响应者实际启动响应和调查的最重要步骤。您将需要组织的 Microsoft 365 管理员在他们的 365 租户中创建一个具有以下角色的账户。大多数情况下，响应 Microsoft 365 入侵所需的访问权限如下：

    • Azure AD：

      • 全局读取者

      • 安全读取者

    • Exchange 在线管理员，一个自定义角色，具有以下权限：

      • 邮件收件人

      • 安全组创建和成员资格

      • 仅查看审计日志

      • 仅查看配置

      • 仅查看收件人

    • Microsoft Purview（合规性）：

      • 合规性管理员

      • eDiscovery 管理员

这些角色名称可能会在 Microsoft 生态系统中发生变化；然而，关键在于，您将需要某种全局读取者或安全读取者角色，以便在审计日志中进行搜索。

初步范围界定阶段通过提供攻击的清晰概览，为有效的事件响应奠定了基础。接下来，我们将深入探讨微软 365 和 Google Workspace 的分流和取证工作。

修复步骤

在事件的初步范围界定阶段，无论是微软 365 还是 Google Workspace，组织可以遵循一些步骤，确保攻击者在事件响应人员开始取证前已经被清除出环境。用户界面和生产力套件可能会发生变化；然而，以下步骤始终适用：

  1. 重置所有受到影响或疑似被泄露的账户密码。

  2. 启用多因素身份验证（MFA）在整个组织中，或至少对于特权账户启用。

  3. 移除任何可疑的自动化设置（例如，域外的电子邮件转发规则）以及邮箱中设置的可疑收件箱规则。我们将在接下来的章节中进一步讨论这一点。

  4. 从任何特权或提升角色中移除被泄露的账户。例如，属于 IT 管理员的被泄露账户应暂时限制其访问权限，以防止进一步的未经授权活动。

尽管生产力套件如微软 365 或 Google Workspace 发生了变化，这些高层次的步骤，包括密码重置和访问限制，在保护生产力套件环境免受网络威胁方面具有普遍适用性且至关重要。产品的用户界面和细节可能会变化；然而，步骤始终不变。

微软 365 事件响应

在初步范围界定以了解事件后，下一步是确定泄露的指标并开始威胁狩猎。本节深入探讨了事件响应人员可以使用的工具和技术，来自动化日志采集和分析过程，特别是对于使用微软 365 作为其云生产力套件的组织。一个关键的重点是利用微软 365 内建的安全和合规工具，如微软 Purview，快速收集日志并跟踪可疑活动。

工具

在第七章中，我们讨论了微软 365 中的各种审计和合规功能，其中之一是微软统一审计日志。这些日志提供了微软 365 活动的汇总视图，对于调查和理解泄露的程度至关重要。以下是事件响应人员如何利用微软 365 中的审计日志搜索界面来实现这一目的：

  1. 访问审计日志搜索：审计日志搜索可以通过微软 Purview 访问。事件响应人员需要导航到审计部分以开始。

  2. 定义事件范围：在运行搜索之前，必须完成事件的初步定义，如前一节所讨论的。这是因为初步定义涉及理解事件的时间线、怀疑被泄露的账户，以及感兴趣活动的性质。这一初步定义有助于应用正确的筛选器。否则，事件响应者将不得不运行一般搜索，这可能需要一段时间才能执行，并且在之后分析和分类时可能会很困难。

  3. 应用筛选器：审计日志搜索提供多种筛选器，用于缩小搜索结果范围：

    • 日期和时间：指定事件的时间范围

    • 活动：按特定活动筛选，如文件访问、用户登录和管理操作

    • 用户：将搜索集中在怀疑被泄露的特定用户账户上

    • 文件、文件夹和站点：如果相关，可以缩小范围到特定的文件、文件夹或 SharePoint 站点

  4. 运行搜索：应用必要的筛选器后，运行搜索。图形用户界面将显示与条件匹配的事件列表。可以使用经典搜索或新搜索；然而，需要注意的是，经典搜索不会保存你进行的搜索历史。此外，经典搜索仅限于运行并行搜索任务。

  5. 导出日志进行详细分析：对于更深入的分析，用户可以将搜索结果导出为 CSV 文件。这可以通过外部工具进行额外的分析并用于归档。导出的数据包括有关每个事件的详细信息，如源 IP 地址、用户代理和执行的具体操作。

重要说明

通过审计搜索用户界面导出的结果限制为仅 10,000 条。因此，确保搜索结果精炼至 10,000 条以内，或将搜索任务拆分成多个批次，以确保导出所有条目是很重要的。

  1. 利用外部工具：日志导出后，事件响应者可以利用各种数据分析工具筛选数据。可以使用 Excel、Power BI 或专门的取证工具分析模式、创建时间线并关联不同日志中的事件。

  2. 分析结果：检查结果，识别任何异常或未授权的活动。寻找可能表明恶意行为的模式或异常。我们将在下一节进一步讨论分析。

搜索并导出 365 审计日志

以下图示展示了如何运行搜索并导出 CSV 格式的审计日志：

  • 以下截图展示了审计日志搜索标签页，并列出了可用的筛选器以进一步精炼查询：

图 12.2 – Microsoft 365 审计搜索日志标签

图 12.2 – Microsoft 365 审计搜索日志标签

  • 搜索任务在执行时创建，并列在审计日志筛选器下方，如下所示：

图 12.3 – 审计日志搜索作业

图 12.3 – 审计日志搜索作业

  • 一旦搜索作业完成，结果将按表格形式组织，如下所示：

图 12.4 – 审计日志搜索结果（UI）

图 12.4 – 审计日志搜索结果（UI）

  • 下一图展示了成功登录和失败登录事件的示例：

图 12.5 – 审计日志搜索结果 – 登录事件

图 12.5 – 审计日志搜索结果 – 登录事件

  • 下图展示了一个事件的详细信息窗格示例：

图 12.6 – 审计日志事件详情

图 12.6 – 审计日志事件详情

  • 所有搜索结果可以导出为 CSV 文件，如下所示：

图 12.7 – 审计日志导出过程

图 12.7 – 审计日志导出过程

生成的文件是一个 CSV 文件；然而，大多数字段将以 JSON 格式存储在 AuditData 列中。导出的 CSV 如下所示：

图 12.8 – 审计日志导出（CSV）

图 12.8 – 审计日志导出（CSV）

使用 PowerShell 提取审计日志

统一审计日志也可以通过 PowerShell 程序化提取：

  1. 以管理员身份打开 PowerShell，并导航到您选择的文件夹；例如，C:\Incident Response\。

  2. 使用以下命令连接到 Microsoft 365 租户：

    Install-Module ExchangePowerShell
Install-Module AzureAD
Import-Module AzureAD
Import-Module ExchangePowerShell
Connect AzureAD

  3. 定义日志时间范围（根据需要修改；在此，我们将从 30 天开始）：

    $StartDate = (Get-Date).AddDays(-30)
Search-UnifiedAuditLog cmdlet:

    $AuditLogs = Search-UnifiedAuditLog -StartDate $StartDate -EndDate $EndDate

  4. 将日志导出为 CSV：

    $AuditLogs | Export-Csv -Path "AuditLogs-last30.csv" -NoTypeInformation

  5. 释放 365 会话（即断开连接）：

    Disconnect-MsolService

生成的 CSV 将与通过用户界面导出的数据非常相似，如图 12.8所示。

使用 Microsoft Power Query

无论是通过 Purview 用户界面导出，还是通过编程方式导出，大部分数据和有用字段将以 JSON 格式存储。因此，事件响应人员必须完成额外的步骤，以解析这些数据使其可用（或易于搜索）。事件响应人员可以使用他们选择的 JSON 解析工具，但在此示例中，我们将使用 Microsoft Power Query。Power Query 可用于深入分析大量的 JSON 数据。该过程涉及将 CSV 文件导入 Excel，然后使用 Power Query 的高级数据转换功能解析 JSON 字段。此解析将 JSON 数据转换为与 Excel 的传统列和行对齐的结构化格式。用户可以将 JSON 字段展开为单独的列，使数据更易于访问和分析。此转换对于需要深入剖析并理解审计数据列中记录的用户活动、安全事件和系统更改细节的事件响应人员至关重要。通过利用 Microsoft 的 Power Query，组织可以有效地将复杂的 JSON 数据转换为更易管理和分析的格式。

使用 Microsoft Power Query 的步骤如下：

  1. 从统一审计日志 CSV 开始，我们的下一步是在 Microsoft Excel 中创建一个新工作簿：

图 12.9 – 审计日志结果待转换

图 12.9 – 审计日志结果待转换

  1. 创建一个新工作簿：

图 12.10 – 新 Excel 工作簿

图 12.10 – 新 Excel 工作簿

  1. 接下来，您需要进入数据标签页，点击获取数据 | 来自文件 | 来自文本/CSV。

图 12.11 – 导入审计数据导出

图 12.11 – 导入审计数据导出

  1. 接下来，您将导入统一审计日志 CSV 并点击包含 JSON 的 AuditData 列。请注意，Power Query 有每个工作表最大行数限制（即 1,048,576 行）。

图 12.12 – Power Query 加载数据选项

图 12.12 – Power Query 加载数据选项

  1. 接下来，使用转换数据选项转换审计数据。结果显示在下图中：

图 12.13 – Power Query 结果

图 12.13 – Power Query 结果

  1. 接下来，右键点击 AuditData 列并点击转换 | JSON。

图 12.14 – 转换 JSON 数据列

图 12.14 – 转换 JSON 数据列

如下所示，您的 JSON 数据已成功转换为 CSV 列（例如，AuditData.ClientIP）：

图 12.15 – 结果 CSV 列

图 12.15 – 结果 CSV 列

下图展示了在 Power Query 中列转换后的数据结果：

图 12.16 – 展开转换后的列

图 12.16 – 展开转换后的列

结果是一个 CSV 文件，其中包含您所有的审计数据，格式友好且易于阅读，您可以使用 Excel（或您选择的其他工具）进行进一步分析。

使用 HAWK 进行云取证

事件响应人员还可以利用一些基于 Microsoft 365 API 的开源工具，如 HAWK（Github.com/T0pCyber/hawk）。

HAWK 是一个基于 PowerShell 的工具，用于收集与 Microsoft 365 安全事件相关的信息。它从 365 配置和审计日志中搜索并解析出许多与 365 安全事件相关的有用信息，如新收件箱规则的创建、授权批准、所有具有管理员访问权限的用户列表等。通过这种方式，事件响应人员可以在各自的 CSV 文件中找到所有信息，而无需进入 365 配置或通过审计日志手动提取信息，这大大简化了事件响应过程。

重要提示

HAWK 工具可以在 GitHub 上找到：

github.com/T0pCyber/hawk

这里是 HAWK 模块 PowerShell Gallery 下载链接：

www.powershellgallery.com/packages/HAWK/3.1.0

这里是 HAWK 文档：

cloudforensicator.com/

要运行 HAWK，您的系统需要具备管理员权限的 PowerShell 和互联网连接：

  1. 以管理员身份打开 PowerShell，并使用 cd 命令导航到 C:\Incident Response\ 文件夹。

  2. 安装 HAWK 模块：

     (Install-Module -Name Hawk)

  3. 安装并导入 Microsoft 365 Exchange Online 管理模块和 Microsoft 365 模块：

    Install-Module -Name ExchangeOnlineManagement
Install-Module MSOnline
Install-Module AzureAD
Install-Module ExchangePowerShell
Import-Module AzureAD
Import-Module ExchangeOnlineManagement
Import-Module ExchangePowerShell

  4. 使用以下命令登录受影响的 365 租户，并使用你的 Microsoft 365 用户名和密码进行身份验证：

    Connect-AzureAD
C:\Incident Response\.

  5. 运行 HAWK 工具：

     Start-HawkTenantInvestigation

生成文件的示例如下所示：

图 12.17 – HAWK 结果

图 12.17 – HAWK 结果

如 HAWK 的 GitHub 所述，HAWK 旨在快速为事件响应人员提供所需的数据。它并不意味着为您完成分析。所有生成的日志文件的完整分析可以在 HAWK 文档页面找到。

分析

我们分析的目标是识别任何妥协的证据。进行的第一个分析步骤是确定未授权访问的证据。这最好通过使用 Microsoft 365 中统一审计日志的 Activity 或 Operation 列来识别登录事件来确定。此列记录了在环境中执行的具体操作。本质上，它充当活动的详细账本，涵盖从文件访问和共享到管理更改和登录事件等各种操作。Operation 列中的每个条目都附有描述性标签，用于标识操作的性质，因此它是事件响应人员的重要资源。

重要说明

所有审核活动（即操作）可以在 Microsoft 的文档中找到，网址为 learn.microsoft.com/en-us/purview/audit-log-activities。

确定是否发生妥协的第一步是筛选 UserLoggedIn 事件，这是监控和调查未授权访问的关键。通过分析这些事件，事件响应人员可以跟踪用户何时以及如何登录系统，从而提供关于威胁行为者行为的重要洞察。

例如，异常的登录活动模式，如在不寻常的时间或从意外位置登录，可能是未授权访问的早期迹象。这将使事件响应人员能够确定与妥协相关的任何指示，例如登录用户代理字符串和 IP 地址。

登录活动中的最强指示因素不是分析异常的登录时间，而是分析与登录事件相关的 IP 地址的位置。这可以通过筛选 Microsoft 365 中统一审计日志中的 UserLoggedIn 事件，并使用任何批量 IP 地址查询软件（如 ipinfo.io）查找相关的 IP 地址（在 AuditData 中的 ClientIP 字段）来完成。有关示例，请参见 图 12.18 和 图 12.19：

图 12.18 – 客户端 IP 审计数据

图 12.18 – 客户端 IP 审计数据

这些 IP 可以复制到一个 IP 查询服务中，该服务会提供与每个 IP 相关的具体城市、地区和国家。例如，在 IPinfo 上查找以 69 开头的某个 IP，会显示用户是从美国明尼苏达州的一个 IP 地址登录的。

Figure 12.19 – IPInfo.io 查询结果

Figure 12.19 – IPInfo.io 查询结果

地理信息可以从您选择的地理 IP 查询服务中导出，并与审计日志中的所有用户进行比较。作为事件响应者，您的下一步是确定地理位置是否与组织的业务运营相符，或者用户是否在该日期确实位于该 IP 的位置。如果用户没有前往该位置，则可以认为该用户账户已被泄露。事件响应者还可以分析其他 IP 信息，如 VPN/代理使用情况，或者查看托管提供商是否与用户的正常（基线）IP 地址不符。

延续分析异常登录位置的思路，事件响应者的另一个关键威胁猎杀任务是检查邮箱规则的变化。邮箱规则是由收到的邮件触发的自动操作。如果攻击者进入用户账户，他们可以悄悄创建或修改规则。这些未经授权的规则可能会将邮件转发到其他账户、删除特定邮件，或者管理钓鱼邮件以避免被捕获。需要关注的关键操作如下：

  • New-InboxRule：当创建新的邮箱规则时，该操作会被记录。事件响应者应仔细审查任何此类操作实例，特别是关注那些将邮件转发到外部域、自动删除邮件或以可疑方式分类邮件的规则。新规则创建的突然增加，特别是那些具有不寻常条件的规则，应引起警惕。

  • Set-InboxRule：表示对现有邮箱规则的修改。特别是那些更改规则动作或条件的修改，可能是攻击者试图巧妙操控邮件流的迹象。

  • Remove-InboxRule：删除邮箱规则的操作会被记录在此操作中。虽然这看起来无害，但删除某些规则，特别是与安全相关的规则，可能是攻击者用来减少其活动被检测到的一种策略。

  • New-TransportRule 和 Set-TransportRule：这些操作与传输规则的创建和修改相关，传输规则更加复杂，可以在组织级别控制邮件流。这里的未经授权的更改可能会产生广泛的影响。

例如，下一个截图来自一起 Microsoft 365 被攻破的事件，其中威胁行为者创建了一个名为zz的新收件箱规则。这个收件箱规则会自动删除任何在主题行或正文中包含以下词汇的电子邮件：“骗局”、“欺诈”、“网络钓鱼”，以及一个为了隐私原因已被清理的电子邮件地址。这是因为攻击者试图掩盖其行踪，使得任何与其目标相关的电子邮件或警告——也就是“骗局”或“欺诈”组织的钱财——都会被自动删除，从而威胁攻击者可以在不被察觉的情况下完成攻击。

图 12.20 – 恶意收件箱规则示例

图 12.20 – 恶意收件箱规则示例

除了监控这些特定操作外，将这些信息与其他登录数据（例如登录地点和时间）进行关联，可以更全面地了解攻击者的活动。例如，从一个不寻常的地理位置登录后立即创建新的收件箱规则，可能是账户被攻破的有力迹象。

在处理 Microsoft 365 泄露数据问题时，事件响应者需要关注审核日志中的特定操作，这些操作可能表明未经授权的数据移动或访问。数据外泄可以通过多种方式发生，比如通过 Outlook 同步、通过 Web 浏览器访问数据或其他活动。理解这些细节对于识别潜在的安全漏洞至关重要：

  • Outlook 客户端同步（通过 SyncFolderItems 操作）：当用户的 Outlook 客户端与邮箱同步时，会记录此操作。过度或异常的同步活动，尤其是来自不熟悉的设备或位置，可能表明有人试图下载大量数据。将这些同步操作的数量和频率与典型用户行为进行比较，可以揭示异常。

  • MailItemsAccessed事件，尤其是来自攻击者 IP 地址的事件，不仅表明未经授权的访问，还表明威胁行为者查看了这些邮件项目的内容。

  • FileDownloaded、FileCopied、FileMoved和FileDeleted在 SharePoint 或 OneDrive for Business 中的操作是关键指标。这些行为，尤其是在高频次或来自不寻常位置的情况下，可能表明有人正在进行数据外泄。

  • 电子邮件转发规则（New-InboxRule, Set-InboxRule）：与邮箱被攻破类似，创建或修改自动将电子邮件转发到外部地址的收件箱规则可能是一种数据外泄的手段。

  • eDiscovery 搜索与导出操作（SearchQueryInitiated, SearchQueryPerformed, ExportStarted）：这些操作表明有人正在进行搜索，可能还在导出 eDiscovery 中的数据，这可能是恶意提取大规模数据集的一种复杂方式。

  • 异常发送模式（发送和 SendAs 操作）：电子邮件发送活动的激增，尤其是带有大附件或发送给外部收件人的邮件，可能表明试图通过电子邮件窃取数据。

重要提示

所有邮箱审计活动（即操作）可以在微软的文档中找到，learn.microsoft.com/en-us/purview/audit-mailboxes。

在生产力套件发生泄露时，组织必须回答的一个关键问题是数据是否被攻击者窃取。通过分析列出的操作，事件响应人员可以更好地理解从数据泄露角度来看事件的范围。

事件响应人员还应考虑在 365 环境遭到攻击时，审查以下有价值的信息来源：

  • 冒充权限：这些权限允许用户代表其他用户执行操作。事件响应人员应检查是否有任何意外或未经授权的冒充权限分配。这可以通过审查每个用户的角色分配来完成。

  • Azure Active Directory 管理员列表：审查当前的 Azure Active Directory（AD）管理员非常重要。你可以在 Azure AD 管理中心查看此列表。查找任何不熟悉的帐户或管理员角色的变化，因为攻击者可能通过提升权限来获得更广泛的访问权限，在 365 环境中进行攻击。

  • Azure AD 用户列表：事件响应人员应审计 Azure AD 中的所有用户列表。特别关注新创建的用户，尤其是拥有高权限的用户。通过 Azure AD 管理中心检查此列表。意外的用户帐户可能是攻击者创建后门的迹象。

  • 同意授权：这些是授予应用程序访问用户数据的权限。请在 Azure AD 管理中心查看同意授权，检查是否有授予未知或可疑应用程序的异常或广泛权限。过多的权限可能会被滥用，用于数据访问和窃取。

  • eDiscovery 角色：拥有 eDiscovery 角色的用户可以从邮箱和网站中搜索并导出内容。检查谁被分配了这些角色。虽然不太可能，未经授权的 eDiscovery 角色分配可能表明试图非法访问并导出敏感数据。

  • Exchange 在线管理员：定期审查谁拥有 Exchange Online 的管理员权限非常重要，因为这些帐户对电子邮件操作具有重要控制权。检查 Exchange 管理中心中的任何意外更改或添加。

  • 传输规则（邮件流）：这是在 Exchange Online 中设置的控制邮件流的规则。审查传输规则，查看是否有任何将电子邮件重定向或复制到外部域的规则，这可能是数据窃取的方法。

所有这些分析来源可以通过 HAWK 工具生成的 CSV 文件进行查看，如图 12.17所示。

Google Workspace 事件响应

在我们已经讨论的初步范围确定和响应部分中，理解事件的基本情况之后，使用 Google Workspace 的事件响应人员面临着识别安全事件和启动威胁狩猎的挑战。与 Microsoft 365 不同，Google Workspace 提供的工具较少，主要集中在审计和报告功能上。尽管这些工具没有那么全面，但对于收集日志和发现异常活动至关重要。这意味着响应人员通常需要结合外部资源和更深入的分析，才能有效追踪和调查 Google Workspace 环境中的潜在安全漏洞。

工具

与我们在 Microsoft 365 上的讨论类似，让我们探讨事件响应人员如何利用 Google Workspace 中的审计日志来调查和了解安全事件的范围：

  1. 访问审计日志：在 Google Workspace 中，可以通过管理员控制台访问审计日志。事件响应人员可以通过导航到报告部分，然后进入审计子部分来查找这些日志。

    与 Microsoft 365 一样，第一步是了解事件的时间线，识别可能被攻击的账户，并确定可疑活动的性质。这种理解有助于在审计日志中应用正确的过滤器，使搜索更加高效和专注。

  2. 在审计日志搜索中应用过滤器：Google Workspace 的审计日志搜索提供了各种过滤器来细化搜索：

    • 日期和时间：设置特定的时间范围

    • 事件：从一系列活动中选择，如发送电子邮件、共享文件、管理员活动等

    • 用户：关注可疑的特定用户账户

    • 应用程序：如果相关，可按特定的 Google Workspace 应用程序进行过滤，例如 Gmail、Drive 和 Calendar

  3. 运行搜索：设置过滤器后，运行搜索。结果将显示符合条件的事件列表，然后可以审查其中的可疑活动。

  4. 导出日志以进行分析：Google Workspace 允许导出搜索结果以便进行更详细的分析。这些导出内容可以包括全面的事件信息，如 IP 地址、采取的行动和受影响的资源。

  5. 利用外部工具进行分析：一旦导出，日志可以使用 Excel 或其他数据分析软件进一步分析。此步骤对于发现模式、创建时间线并关联不同日志中的事件至关重要。

  6. 分析结果：仔细检查审计日志条目中是否有异常或未经授权的活动。寻找可能表明恶意行为的异常或模式，例如大规模下载文件、异常的登录时间或意外的外部文件共享。更多内容将在接下来的分析部分中讨论。

重要提示

类似于 Microsoft 365，从 Google Workspace 审计日志导出结果可能在可导出的条目数量上有限制。重要的是确保你的搜索足够精确，以便捕捉到所有相关数据而不超过这些限制（通常为 100,000 条记录）。

搜索并提取 Google Workspace 日志

正如在 第七章 中讨论的那样，Google Workspace 提供了一系列审计日志，每种日志针对不同的应用和活动。主要日志包括以下内容：

  • 管理员活动日志：跟踪管理员操作，如设置更改或用户管理

  • 登录日志：监控用户登录尝试，无论成功与否，这对于识别未经授权的访问尝试至关重要

  • Drive 审计日志：对于跟踪 Google Drive 中的文件共享和访问至关重要

  • Gmail 日志：监控异常的电子邮件活动，例如大规模删除或转发规则

要导出 Google Workspace 的审计日志，事件响应者可以按照以下步骤操作：

  1. 在 Google Workspace 管理控制台（admin.google.com）中，进入 报告，然后选择 审计 和 调查。

  2. 选择特定的审计日志（例如，管理员日志事件、用户日志事件和组日志事件）。

  3. 应用必要的过滤器并执行搜索。

一旦结果显示出来，使用 下载 或 导出 选项保存数据以便进一步分析。

导出的日志可以是 CSV 格式，便于导入数据分析工具。使用如 Excel 等工具时，响应者可以排序、筛选，并使用函数更有效地分析数据。

以下图示展示了导出审计事件的步骤。首先导航至 报告，然后进入 审计与调查 标签，如下所示：

图 12.21 – 报告标签页

图 12.21 – 报告标签页

下图展示了在 Google Workspace 管理控制台中，审计与调查标签下所有可用的日志：

图 12.22 – 审计与调查

图 12.22 – 审计与调查

与 Microsoft 365 审计日志搜索类似，可以设置过滤器，如图所示：

图 12.23 – 用户事件

图 12.23 – 用户事件

这里展示了导出数据的示例：

图 12.24 – 导出的用户事件

图 12.24 – 导出的用户事件

接下来，我们将深入分析 Google Workspace 被攻击的部分。与 Microsoft 365 分析相似的过程也适用于 Google Workspace，但审计日志及其语法有所不同。验证异常登录的原则是相同的。

分析

对被入侵的 Google Workspace 环境的分析需要主要关注用户和管理员事件。事件响应人员需要彻底调查这些日志，以识别未授权访问的证据和其他入侵指标，类似于 Microsoft 365，但这次是在 Google 生态系统中。

  • 登录审计日志分析（用户 日志事件）：

    • 关键事件：关注成功登录和登录失败事件。这些事件表明登录尝试的成功与失败。

    • 需要注意的模式：重复的登录失败后接成功，特别是来自不同 IP 地址或地理位置的登录，可能表示暴力破解攻击。

    • IP 和地理位置分析：将日志中的 IP 地址与用户的典型登录位置进行比较。地理位置数据的差异可能是未授权访问的强烈指示。

  • Gmail（邮件） 日志调查：

    • 关键事件：查看邮件发送、邮件阅读和邮件删除活动。

    • 需要检测的异常：大量发送邮件到未知地址、大量删除邮件或在短时间内打开大量邮件，可能表示账户被接管。此外，还需查看任何收件箱规则的创建和修改，类似于我们在Microsoft 365 事件 响应部分中讨论的内容。

  • 管理员活动 日志审查：

    • 重要事件：监控用户创建、用户角色更改和服务 设置更改。

    • 警示信号：未授权创建新用户、权限提升或安全设置更改是需要重点关注的关键问题。

  • OAuth 令牌 活动监控：

    • 关键事件：跟踪令牌授予和令牌撤销操作。

    • 关注观察：向不熟悉的第三方应用授予令牌或令牌撤销的异常模式可能表明攻击者正在试图访问数据或服务。

  • 组审计 日志检查：

    • 关键事件：监控组成员添加和组设置更改。

    • 入侵指标：一个指标是将未知成员添加到关键组中，或对组设置进行未经授权的更改，特别是在访问敏感信息的组中。

对于这些领域，事件响应人员应采用基于上下文的方法。这意味着不仅要关注事件的发生，还要理解它们在用户行为和组织规范的更广泛背景下的相关性。分析事件的频率、时间和模式偏差至关重要。我们在Microsoft 365 事件响应部分中看到，如何通过 IP 查询服务查看登录 IP 以更好地理解未授权访问——同样的过程也可以应用于 Google Workspace。

重要提示

Google Workspace 的用户界面和语法未来可能会发生变化，因为这些是由其团队开发的活跃产品。因此，一些事件名称可能会发生变化，但其原理保持不变（例如，成功登录可能会改为登录成功，反之亦然）。

摘要

在本章关于分析被妥协的云生产力套件中，我们探讨了如何应对在两个最流行的基于云的生产力套件——Microsoft 365 和 Google Workspace 中的安全事件。这些平台在电子邮件、存储和办公应用程序中至关重要，经常成为 BEC 攻击的目标。BEC 是一种复杂的网络欺诈形式，通常涉及攻击者通过电子邮件欺骗或账户接管获得未授权访问，从而导致更广泛的安全漏洞。

本章节提供了关于了解 BEC、其各阶段和攻击者方法的指南。接着，概述了初步评估和修复的关键步骤，这是有效应对事件的关键。针对 Microsoft 365，重点介绍了使用统一审计日志和 Microsoft Purview 进行日志分析的工具。还讨论了一个基于 PowerShell 的开源工具 HAWK，用于简化数据收集。

相比之下，讨论了 Google Workspace 的事件响应，其审计和报告工具虽然功能有限，但仍至关重要。该过程涉及使用 Google Workspace 的审计日志来识别可疑活动。本章为您提供了在 Microsoft 365 和 Google Workspace 中有效应对事件的知识。

进一步阅读

posted @ 2025-07-07 14:37  绝不原创的飞龙  阅读(5)  评论(0)    收藏  举报