数字取证与事件响应(二)
原文:
annas-archive.org/md5/6e10f6c7f0b8273cfd80f246668d8d89译者:飞龙
第八章:法医成像
事件响应分析师通常必须执行的一个关键任务是成像数字证据。正如我们在前几章中讨论的那样,与事件相关的大量证据可以在日志文件、内存和其他区域中找到,并且可以相对迅速地获取。在某些事件中,如内部恶意活动(例如欺诈、工业间谍活动或数据泄漏),可能需要更详细的证据搜索。这些证据包括主文件表条目、文件以及包含在嫌疑系统硬盘上的特定用户数据。如果事件响应分析师遇到这种情况,他们将需要获取嫌疑驱动器的图像。与数字取证的任何方面一样,获得一个可用且可供法庭辩护的图像,依赖于使用适当的工具、技术和文档。
本章将探讨数字成像的基本概念,以及获取物理驱动器或其他逻辑卷的法医影像所需的准备工作和工具。更具体地,我们将涵盖以下主题:
-
理解法医成像
-
成像工具
-
准备暂存驱动器
-
使用写保护器
-
成像技术
虽然本章介绍了一些非常技术性和过程驱动的内容,但响应人员必须理解成像过程。这个过程对于生成能够用于根本原因分析(RCA)和潜在法庭使用的图像至关重要。
理解法医成像
成像存储驱动器是一个注重细节的过程。本节为法医成像提供了坚实的基础,介绍了如何完成成像、各种数字成像过程以及各种专有文件格式。
对法医成像各个方面有透彻理解,对于事件响应分析师来说至关重要。了解涉及的工具、技术和程序可以确保证据得到妥善处理,并且分析师对其所获取的证据充满信心。此外,了解必要的术语使分析师能够准确地准备报告,并在需要时就其发现提供证词。
图像与复制
首先应理解的一个概念是法医成像与复制之间的区别。从嫌疑人硬盘或其他介质中复制文件,只能为分析师提供与该文件相关的实际数据。另一方面,成像允许分析师捕捉整个驱动器的数据。这包括如空闲空间、未分配空间以及可能访问已删除文件的区域。成像还会保留卷上的元数据,包括文件时间戳。如果进行时间线分析以确定特定文件何时被访问或删除,这一点至关重要。
经常会将克隆和影像这两个术语互换使用。这在 IT 领域中是一个常见的术语误用。在克隆一个驱动器时,会制作一个一对一的驱动器副本。这意味着该驱动器可以插入系统并启动。克隆驱动器通常是为了对关键驱动器进行完全备份而进行的。虽然克隆的驱动器包含所有必要的文件,但在使用取证工具时它比较笨重。因此,会制作一个影像文件。驱动器的影像包含所有必要的文件;其配置允许在使用取证工具时进行详细的检查。
逻辑卷与物理卷
需要理解的第二个概念是可以被影像化的卷类型。卷可以分为物理卷和逻辑卷。物理卷可以被认为包含整个硬盘。这包括任何分区以及D:驱动器。当影像化一个逻辑卷时,分析员只会捕获D:驱动器中的数据。
以下图表说明了在影像化物理卷或逻辑卷时所捕获的数据:
图 8.1 – 物理卷与逻辑卷
正在调查的事件类型在很大程度上决定了所进行的影像类型。例如,如果分析员能够识别出从D:驱动器执行的潜在恶意文件,并且仅打算捕获该数据,那么获取该卷的逻辑影像可能会更快。此外,在使用全盘加密(FDE)的情况下,可能需要进行逻辑获取。没有加密密钥的情况下,在系统运行时进行文件的逻辑获取通常是唯一可用的选项。
逻辑影像的一个关键缺点是,它不会捕获未分配的数据或不是文件系统一部分的数据。已删除的文件和其他痕迹证据不会成为逻辑影像的一部分。在怀疑如员工不当行为等活动的情况下,分析员需要尽可能追踪所有活动,因此将对物理卷进行完整影像。时间不是一个必要因素。
在第五章中,我们讨论了从正在运行或开机的系统中获取证据,例如日志文件和内存。以类似的方式,事件响应分析员能够从运行中的系统获取逻辑卷。这个技术被称为实时影像。如果一个潜在被入侵的系统无法下线——比如在高可用性(HA)的生产服务器中——而潜在证据位于逻辑卷中,那么实时影像可能是最好的选择。
死机影像是对已经断电并移除硬盘的系统进行的影像。在这种影像类型中,分析师可以捕获整个磁盘,包括所有卷和 MBR。这在分析师希望确保捕获源证据的完整性时变得必要,确保没有任何未被检查的区域。
图像文件的类型
取证影像的另一个方面是分析师需要了解的图像文件类型,这些文件可以在调查过程中创建并被利用。图像文件有多种类型,其中一些非常专业,但本书的目的在于重点讨论分析师在事件处理中最常创建和使用的三种最常见的证据文件类型:
-
.raw、.img和.dd扩展名。一些软件,如 Linux 中的dd命令,在速度和与取证工具的兼容性可能成为问题时提供了灵活的选项。 -
高级取证文件格式(AFF4):AFF4 是一种开源图像文件格式。该格式首次在 2009 年提出,用于支持多个工具,如 Google 快速响应(GRR)。
-
EnCase 证据文件:EnCase 证据文件,或 E01 或 EX01 文件,是 OpenText 于 1998 年作为其 EnCase 取证工具的一部分开发的专有文件格式。该格式基于 专家证人格式(EWF),该格式在 ASR Data 的专家证人压缩格式中被发现。E01 文件包含有关影像的元数据。存储在头部和尾部的元数据记录并保存有关驱动类型、操作系统和时间戳的信息。E01 文件的另一个关键特性是包含 循环冗余校验(CRC)。该 CRC 是在每写入 64 KB 数据到影像文件后进行的文件完整性验证。CRC 确保了整个影像文件中前一个数据块的完整性。最后,E01 文件在文件尾部包含一个 信息摘要算法 5(MD5)哈希。下图展示了在影像处理过程中,E01 文件的哪些组件会被创建:
图 8.2 – E01 文件格式
SSD 与 HDD
事件响应分析师需要理解的另一个关键影像概念是如何对特定存储介质进行影像——特别是理解 硬盘驱动器(HDD)与 固态硬盘(SSD)之间的区别。随着 SSD 在笔记本电脑和台式机等终端设备中变得越来越普遍,理解这一差异变得至关重要。
两者之间的主要区别在于信息存储的最细节部分。传统的旋转硬盘(HDD)通过改变实际旋转磁盘上的磁极来存储信息。因此,数字取证和事件响应分析师在处理证据时需要了解磁场,以及为什么掉落 HDD 往往会对磁盘造成致命损害。
硬盘驱动器(HDD)中一个让数字取证检查员感兴趣的方面是数据的处理方式。数据写入磁盘后会停留在分配给该数据的扇区中。当用户删除一个文件时,数据并不会被移除。数据可能会被完全或部分覆盖,使用适当的镜像工具,这些数据可以被定位并重建进行分析。
由于硬盘驱动器(HDD)的工作原理以及数据重建的可能性,创建物理磁盘镜像是一个很好的实践。这包括通过切断电源而非通过操作系统关闭系统来关闭设备。这可以保留分析人员访问硬盘时的状态。在无法做到这一点的情况下,可以从正在运行且已开机的系统中获取逻辑镜像。
另一方面,SSD 通过存储在单元中的电子状态来保存信息。这种数据存储方式使用命令fsutil behavior query disabledeletenotify,如果操作系统使用的是 SSD,Windows 命令提示符会返回以下输出:
图 8.3 – 启用 TRIM 操作
固态硬盘(SSD)芯片组的另一个让数字取证和事件响应分析师关心的特点是“磨损均衡”。SSD 中的电子有有限的生命周期,不能持续不断地开关。如果操作系统只使用硬盘的前 100GB,它可能会损坏这一部分,导致硬盘无法使用。为了防止这种情况,SSD 采用磨损均衡技术,将数据不断地移动到硬盘的不同位置,从而减少使硬盘无法使用的可能性。
这两个特性意味着传统的写保护器无法确保在镜像过程中不对硬盘做出任何更改,因为 PCB 管理着数据的写入和在 SSD 上的均衡方式。虽然可以进行镜像,但分析人员无法确保在过程中没有对硬盘进行更改。为了限制这些更改,分析人员应在找到硬盘时就开始镜像。如果系统已经关闭,应移除硬盘并进行镜像。如果系统仍在运行,必须进行实时镜像。
镜像工具
正如我们之前讨论的内容一样,响应人员有多个工具可用于镜像硬盘。了解这些工具能帮助响应人员知道在事件中应用哪个工具。
虽然没有法院或法律机构认证数字取证成像工具,但有几种方法和相关工具代表了获取磁盘证据时的最佳实践。让我们现在来看看这些方法:
-
FTK Imager:FTK Imager 是由 Access Data 提供的免费软件应用程序。这个基于 GUI 的应用程序允许法医学上可靠地获取逻辑和物理卷、内存以及其他受保护的文件,并以各种格式输出这些镜像。此外,FTK Imager Lite 是一个自包含的应用程序,可以在可移动介质上运行,用于从运行中的系统中获取数字证据(稍后将在本章中详细介绍)。
-
EnCase Imager:由 Guidance Software 提供,EnCase Imager 是另一个取证应用程序,允许响应者从各种系统中获取数字证据。与 FTK Imager 一样,EnCase Imager 也可以在外部驱动器上运行,以便获取运行中的系统。
-
AFF4 Imager:AFF4 Imager 是一个命令行可执行文件,是 WinPmem 等工具的基础。AFF4 Imager 可以用于获取逻辑和物理磁盘,如 EnCase 或 FTK Imager。AFF4 Imager 的一个优点是,它可以根据创建时间提取文件,拆分卷,并通过压缩减少成像时间。
-
使用基于 Linux 的取证平台进行证据获取时的
dd命令。 -
虚拟化工具:随着虚拟化的广泛采用,响应者很可能需要从虚拟系统中获取至少一部分证据。然而,这也有一个优点:整个系统可以转储以供分析。根据虚拟化软件的不同,可以通过暂停系统并转储包含系统的整个目录来实现证据获取。这也可以通过许多虚拟化软件平台的快照功能来完成。
你决定使用的成像工具将取决于组织、你的培训和经验以及使用的其他取证工具。例如,如果一个组织使用Forensic Toolkit(FTK)进行分析,可能最好将 FTK Imager 作为过程的一部分使用。使用任何成像工具时,确保工具正常工作,并且响应者已经充分培训如何使用该工具是一个好习惯。
一旦选择了成像工具,下一步是确保其他硬件已准备好。这包括确保存储介质的目标位置已正确准备。
准备暂存驱动器
与学习如何处理证据驱动器一样,拥有一个法医学上可靠的暂存驱动器,将证据成像到此驱动器上同样至关重要。响应者将学习如何准备这个设备。
除了具备进行取证影像所需的硬件和软件外,至关重要的是提前准备一个存储影像或证据文件的位置。对于事件响应团队来说,最适合作为证据存储库的是外部 USB 或 FireWire 硬盘驱动器。这使得具备一定的便携性,因为事件响应人员可能需要在场外或多个地点进行事件调查,而没有取证实验室的帮助。
在使用证据驱动器之前,需要执行两项任务。第一项任务是确保存储库没有任何数据。事件响应团队应有一个政策和程序,要求在每次使用之前擦除证据驱动器。这包括全新的驱动器,因为一些制造商出厂时会在驱动器上附带备份软件或其他数据,这些数据需要在使用之前移除。
擦除还进一步确保先前使用过的驱动器不包含其他事件的任何痕迹数据。这确保了在经过正确擦除的驱动器上收集到的证据不会与不相关的数据混淆。
这可以通过擦除程序轻松完成。有几个程序,无论是免费还是商业的,都可以用于此。例如,Heidi Computers 的 Eraser 程序是一个免费的擦除工具,可以用于文件和磁盘分区的擦除(Eraser 可以从 eraser.heidi.ie/ 下载)。
在以下示例中,将擦除一个 2 TB 的外部硬盘驱动器,并将其准备好作为证据驱动器使用。以下过程应该在每次将驱动器置于可以用于事件调查的状态时重复:
- 启动 Eraser 应用程序。在图形用户界面中,点击擦除计划,然后选择新任务。然后您应该会看到如下窗口:
图 8.4 – 设置 Eraser 任务
- 现在,可以分配任务名称。这在您希望正确记录证据驱动器擦除时非常有帮助。点击添加数据按钮。这将打开另一个窗口:
图 8.5 – Eraser 驱动器选择
- 对于目标类型,选择驱动器/分区。在设置区域,将出现一个包含分区和驱动器字母的下拉列表。请特别注意分配给不同驱动器的驱动器字母,并确保选择需要擦除的外部驱动器。在此案例中,使用的是一款新的 Seagate 外部硬盘驱动器。最后,选择擦除方法。有几种不同的擦除驱动器选项。在这种情况下,选择了**美国国防部 5220.22-M (8-306./E) (3 Pass)**擦除选项:
图 8.6 – 擦除方法选择
- 点击确定。现在,擦除任务将在擦除 计划部分列出:
图 8.7 – 擦除计划
- 右键点击分区:Seagate 扩展驱动器 (E:)任务并点击立即运行。这将启动擦除过程。如前所述,请确保擦除的是正确的证据驱动器。
根据驱动器的大小和执行擦除操作的系统,整个过程可能需要数小时甚至几天。完成后,事件响应分析师应捕捉任何验证证据驱动器已正确擦除的信息。这些信息在书面法医分析报告中至关重要,因为它证明事件响应分析师采取了适当措施,确保所有证据文件未被破坏或与其他文件混淆。
建议事件响应分析师准备多个驱动器,并在任何事件发生之前将这些驱动器预先擦除。这将使事件响应分析师能够立即使用已擦除的驱动器,而无需现场擦除驱动器,这样可以节省本应用于事件相关活动的时间。
另一项可以采取的准备步骤是加密证据驱动器。可以使用如 VeraCrypt 或其他磁盘加密平台加密包含证据文件的证据驱动器分区。处理敏感信息(如信用卡或医疗记录)的事件响应分析师应加密证据驱动器,无论证据是否需要离开设施。
有两种方法可以加密证据驱动器。第一种方法是使用法医工作站上的加密软件进行加密,这些工作站在成像过程中使用。这种方法仅限于对已从系统中移除并在安装了加密软件的专用系统上成像的驱动器进行成像。第二种方法是将加密软件安装在证据驱动器上。在前一节中,证据驱动器被划分为两个分区,一个分区留作证据文件,另一个分区用于存储工具,例如用于转储内存文件或成像的工具。在这种情况下,加密软件可以加载到工具分区,并且在证据成像过程中对驱动器进行加密。这可以限制对待调查系统进行的更改数量。
一旦驱动器准备就绪,就需要另一层保护,确保在成像过程中不会对嫌疑系统进行任何更改。为确保没有更改发生,响应人员应该熟悉并知道如何使用写保护器。
使用写保护器
写保护器是关键组件,确保在成像过程中证据不被篡改。在本节中,响应人员将接触到物理和软件写保护器。
数字取证的一个关键原则是确保在处理和检查数字证据时不对其进行任何更改。任何变化,无论多么微小,都有可能使整个检查过程受到质疑。如果响应人员无法清楚阐明如何确保证据在检查过程中未被污染,则证据很可能会被排除在法律程序之外。因此,理解写保护器如何保持数字证据的完整性至关重要。
写保护器有两种类型。第一种是软件写保护器。这种软件位于操作系统和证据之间。它们通常是任何在检查阶段使用的数字取证工具的一部分。它们确保对证据文件仅具有只读访问权限,并且在检查过程中不会对证据进行任何更改。例如,本章将深入探讨的 FTK Imager 工具,确保数字证据的采集不会对磁盘进行任何写入。
另一种写保护器是物理或硬件写保护器。顾名思义,这是一种物理硬件,位于证据驱动器和执行采集的系统之间。数据可以从证据磁盘传输到分析系统,但不能反向传输。使用该设备可以清楚地表明,在采集阶段没有修改证据。
使用哪种类型的写保护器主要取决于正在进行的采集类型。理想情况下,响应人员应选择能够清晰证明他们采取了一切合理预防措施,确保证据未被篡改的工具和技术。这样做能显著降低证据被排除在任何法律程序之外的风险,同时也使响应人员能够在做出根本原因判定时依赖该证据。
在适当配置好驱动器和写保护器后,响应人员现在可以继续进行证据驱动器的镜像操作。
镜像技术
本节是本章的主要部分,我们将重点介绍响应人员在需要对证据驱动器进行镜像时可用的技术。
一旦为镜像文件配置了适当的存储库,事件响应分析师就可以准备获取所需的证据。响应人员可能会遇到已经开机或已关闭的可疑系统。根据他们发现可疑系统的状态,必须使用以下技术之一。在任何事件中,无论使用哪种技术,事件响应人员都应准备好妥善记录他们的操作,以便后续的取证报告。
死亡镜像
死机成像是对未通电的媒体进行的,对于硬盘来说,就是将其从可能被破坏的系统中移除。在证据准备方面,这种方法是最全面的,因为它允许完整保留和分析物理卷。有多种方法和工具可以用来进行适当的成像,既有商业软件也有免费软件。除了软件,事件响应分析员通常还会使用硬件写保护器。这些设备确保对嫌疑媒体不会进行任何更改。正如我们在第一章中讨论的那样,能够向法庭证明没有对原始证据进行任何更改是至关重要的。
以这种方式成像硬盘或其他数字媒体的一个优点是,该过程可以预定义并可重复。拥有一个已预定义的过程,并将其正式纳入事件响应计划和程序本身,确保证据以法医学上可靠的方式处理。
一个在死机成像中非常有用的工具是 FTK Imager。这个工具由 Access Data 提供,是一个法医学上可靠的磁盘映像获取平台。
使用 FTK Imager 进行成像
以下过程使用硬盘和 FTK Imager 生成一个法医学上可靠的映像供分析。匆忙或偏离这些步骤可能会导致响应者无法依赖证据的完整性,从而使潜在的证据变得不可靠:
-
第一步是对证据进行实物检查。应该检查两个主要焦点。第一个是链条证据表。每次你接管证据时,应该能访问该表,确保所有步骤都已正确记录,并用你的信息完成条目。
-
然后,你需要检查证据包装,以确保没有封印被破坏。记录这一点的一个快速方法是拍摄证据在原包装中的照片:
图 8.8 – 包装完整性检查
- 在前面的照片中,我们捕捉了所有与该证据相关的信息,并表明在成像之前,证据的完整性得到了保持。在封印被破坏后,你需要拍摄包装内容的照片:
图 8.9 – 示例磁盘照片
- 一旦拍摄了证据的照片,您应确保它与链条证据表格一致。在事件处理中可能会发生错误,这是确保尽早纠正链条证据错误的一种方式。通过确认链条证据,任何混乱都可以得到纠正。下一步是配置物理写保护器。在这种情况下,使用 Tableau TK35u USB 3.0 Forensic IDE/SATA 桥接套件作为物理写保护器。嫌疑驱动器通过附带的 SATA 驱动器适配器连接,并通过 FireWire 与成像笔记本连接。使用物理写保护器时,确保设备显示正常工作,如下所示:
图 8.10 – 物理写保护器设置
在安装物理写保护器后,嫌疑驱动器现在可以进行镜像。在这个示例中,将使用 FTK Imager 免费应用程序。FTK Imager 需要管理员权限才能运行。打开可执行文件后,将显示以下界面:
图 8.11 – FTK Imager 主菜单
- 点击文件,然后选择创建磁盘镜像。这将打开一个窗口,您可以在其中选择媒体源。在这种情况下,选择物理驱动器,以便将整个驱动器(包括 MBR)捕获用于进一步分析。然后,点击下一步:
图 8.12 – FTK Imager 源选择
- 下一窗口允许分析员选择要进行镜像的驱动器。事件响应分析员应密切注意,确保正在镜像正确的设备,因为所有操作系统可见的设备都会列出。在这里,您需要注意驱动器的存储空间,以区分嫌疑驱动器和镜像驱动器。在这种情况下,列出了四个独立的驱动器。两个是成像笔记本内的驱动器。另一个驱动器是目标驱动器。在这种情况下,第三个驱动器,标记为
\\.\PHYSICALDRIVE2,是正确的嫌疑驱动器。高亮显示该驱动器并点击完成:
图 8.13 – 嫌疑驱动器选择
- 一旦选择了嫌疑驱动器,设置目标驱动器。点击添加…:
图 8.14 – FTK Imager 创建图像窗口
- 此时,选择您要创建的图像文件类型。提供四个选项。在这种情况下,需要选择E01。点击下一步 >:
图 8.15 – FTK Imager 选择图像类型窗口
- 在下一个窗口中,输入与映像相关的具体信息。我们将在第十三章讨论报告。目前,分析员应该尽可能详细地填写这些字段,因为这些信息将包含在法医报告中。填写完字段后,点击下一步 >:
图 8.16 – FTK Imager 证据项信息窗口
- 在下一个窗口中,验证映像目标和文件名是否正确。除此之外,您还可以设置映像的碎片化大小和压缩。碎片化大小可以设置为
0,因为整个磁盘映像将包含在一个文件中。现在,默认设置将被使用,因为挂载一个碎片化的磁盘映像不是问题。验证输入的信息无误后,点击完成:
图 8.17 – FTK Imager 选择映像目标窗口
- 现在,创建映像窗口将打开。这是最后阶段,分析员可以在此取消映像文件的创建。此外,根据使用场景,分析员应启用两个选项。第一个是 FTK Imager 在创建映像后验证映像。在此功能下,FTK Imager 将验证映像文件未被修改,并且是完整且无错误的。第二个是 FTK Imager 可以创建映像中所有文件的列表。如果特定文件具有证据价值,这对分析员来说可能非常有用。分析员将能够确定该文件是否存在于该系统中。如果需要检查多个驱动器,这可以节省时间。验证所有设置无误后,点击开始:
图 8.18 – FTK Imager 创建映像窗口
- FTK Imager 接下来将开始映像驱动器的过程。根据被映像驱动器的大小、映像系统的可用处理速度以及与映像系统的连接类型(如 FireWire、USB 等),此过程可能需要数小时甚至数天。在此过程中,将会出现以下窗口:
图 8.19 – FTK Imager 创建映像窗口
- 一旦 FTK Imager 完成成像过程,一个窗口将会弹出。在此窗口中,FTK Imager 会向事件响应分析员提供详细信息。分析员应关注的是,已为硬盘和镜像计算的哈希值。在此案例中,MD5 和 安全哈希算法 1(SHA1)哈希值匹配,表明成像过程正确地捕获了硬盘,并且从嫌疑硬盘提取的证据没有发生任何更改。将这些信息作为取证报告的一部分记录下来是一个良好的做法:
图 8.20 – FTK Imager 结果验证
-
导航到证据驱动器。在这里,可以找到整个镜像文件。根据 FTK 配置的碎片大小,可能会有多个文件或一个单一的证据文件。除了证据文件外,FTK Imager 还提供了硬盘上所有文件的完整列表。
-
最后,FTK Imager 会提供一个文本文件,详细说明成像过程中的信息。这些信息应被捕获并随后续的取证报告一起提供。此时,成像过程已经完成,证据驱动器需要返回安全存储。
死机成像提供了最为取证可靠的采集方式;然而,在某些情况下,响应人员可能需要对开机的系统进行成像。这就需要响应人员对嫌疑系统执行实时成像。
实时成像
在实时成像中,系统正在运行,分析员使用 USB 存储驱动器来存放成像程序和存储区域。一种简单的技术是将安装在成像工作站上的 FTK Imager 目录复制到 USB 上,并从那里执行目标系统的操作。但在此之前,分析员应对系统进行一些检查。
Exterro FTK Imager 指导
FTK Imager 可以轻松配置为从 USB 设备运行。建议分析员至少准备一两个这样的设备。有关如何配置 USB 设备的详细信息,请参考 Exterro 网站:exterro.freshdesk.com/support/solutions/articles/69000765662-run-ftk-imager-from-a-flash-drive-imager-lite。
成像前检查
十多年前,微软 BitLocker 被引入,成为 Windows 操作系统的本地全盘加密(FDE)解决方案。除了 BitLocker,还有许多 FDE 产品。这些解决方案使得事件响应分析员难以对系统进行分析。一个方便的工具,可以帮助判断系统是否启用了 BitLocker,那就是 Magnet Forensics 的加密磁盘检测工具,工具可通过以下网址获取:www.magnetforensics.com/resources/encrypted-disk-detector/。
只需下载工具并通过命令行运行。例如,以下截图显示目标系统正在运行 BitLocker:
图 8.21 – 加密磁盘检测器
还应进行的一项额外检查是确定系统是使用 HDD 还是 SSD,并检查是否启用了 TRIM。请参阅前一节关于 SSD 的内容,获取可以运行的具体命令。
虚拟系统
事件响应者在调查过程中通常会遇到虚拟服务器甚至工作站。通过简单地将暂停的虚拟机(VM)导出到可移动驱动器,可以获取虚拟化系统。在其他情况下,响应者可以利用虚拟系统的快照功能。这会创建一个独立的文件,可以在拍摄快照的日期和时间进行分析。在这两种情况下,响应者应确保驱动器已正确清理,并且适当的文档已经处理。
要获取虚拟机,只需暂停系统,然后将整个目录移至外部介质。(在某些情况下,甚至可以远程完成此操作。)在 Windows 虚拟平台(如 VMware)中,多个文件构成虚拟映像:
图 8.22 – ESXi 虚拟机文件
让我们来看一下其中的一些文件:
-
.vmdk:这是虚拟磁盘映像文件。这是虚拟操作系统和文件所在的逻辑卷。获取这些文件就像是在物理系统上获取C:驱动器的镜像一样。 -
.vmem:.vmem文件是虚拟内存文件。它是虚拟 RAM 或物理内存的存储区域。此文件可以导出,并与其他文件结合进行分析,方法将在第十章中讨论。 -
.vmss:VMware 暂停状态文件保存暂停虚拟机的运行配置。这包括进程和网络连接数据。该文件与.vmem文件结合提供系统内存。 -
.vmsn:这是虚拟快照状态文件。此文件包含拍摄快照时系统的状态。
事件响应者可以通过多种方式使用这些文件。首先,.vmdk文件可以像图像文件一样挂载在各种数字取证软件平台中。这些将在第九章中讨论。其次,.vmsn文件可以通过简单地复制文件并处理副本来重建系统。之后,响应者可以查看系统的行为或提取证据,而不影响原始的.vmsn文件。
最后,通过 .vmem 和 .vmss 文件捕获的运行内存可以以类似分析其他内存捕获数据的方式进行分析。为了获取正确的取证数据,必须将这两个文件合并。这可以通过使用 vmss2core.exe 工具来完成,该工具作为 VMware 工具套件的一部分。合并这些文件时,需要使用以下命令语法:
C:\VirtualTools\vmss2core.exe -W "InfectedServer.vmss" "InfectedServer.vmem"
上述命令将生成一个内存转储文件,存放在包含这两个文件的目录中。
尽管虚拟化在大型企业中非常常见,但它不应构成一个重大挑战。从某种意义上来说,能够简单地暂停系统并提取所有必要的文件,使得提取必要证据的速度更快。
到目前为止,重点一直在 Windows 工具上进行影像处理。事件响应人员的另一种选择是使用 Linux 影像工具。有多种工具提供写保护和影像处理功能,且许多工具是开源的。
Linux 影像
第三章概述了可供事件响应分析师使用的各种取证工具。这些工具中有些包括可以在事件处理中使用的 Linux 发行版,执行各种数字取证任务。以下示例将演示如何部署带有取证应用程序的 Linux 发行版,以捕获潜在被攻破计算机的取证影像。
使用 Linux 发行版和可启动 USB 设备的组合是一种可以用来对潜在被攻破系统进行取证影像的选项。事件响应分析师可能会遇到多个系统需要被取证影像的情况,而分析师只有一个写保护器。如果分析师必须按顺序对每个系统进行影像处理,将会浪费大量时间。在这种情况下,分析师可以通过为每个系统创建一个可启动的 USB 驱动器,并同时对每个系统进行影像处理来避免这种浪费。分析师只需要一个证据驱动器和每个证据来源的可启动 USB 驱动器。使用这种技术可以让分析师同时对每个系统进行影像处理,节省出可以用于其他活动的时间。
在这个场景中,将使用 计算机辅助调查环境 现场版 (CAINE) Linux 发行版来对潜在被攻破系统的硬盘进行影像处理。首先,系统关闭,并安装包含 CAINE 操作系统的可启动 USB 设备。然后启动嫌疑系统。事件响应分析师应当了解如何更改系统的启动顺序,以确保系统从 USB 设备启动。分析师还应准备好在系统试图从原生操作系统启动而非 USB 设备时,立即关闭系统。我们开始吧:
-
确保怀疑硬盘所在的系统已关闭电源。将取证操作系统硬盘插入一个可用的 USB 端口。现在,打开计算机并进入 BIOS。这通常是通过按功能键(fn)和 F2、F8 或 F12 键组合来实现。如果系统启动了主机操作系统,请关闭系统并重试。在开始过程之前,最好了解如何进入系统的 BIOS 设置。
-
启动进入取证操作系统后,将证据硬盘插入另一个可用的 USB 端口。打开终端并输入以下命令:
caine@caine:~$sudo fdisk -l
fdisk -l 命令列出了所有 CAINE 操作系统可见的分区。输出将如下所示:
图 8.23 – fdisk 输出数据
在上面的截图中,第一个硬盘是 SDA,存储容量为 447.13 GB。往下看,SDA 硬盘被划分为三个单独的分区。标为 SDA2 的分区是启动分区。SDA3 分区的大小为 387.7 GB,正如光标所示。这是存储大部分数字证据的数据存储区域。将对该 SDA 硬盘进行成像。
向下滚动输出内容,可以看到证据硬盘和 CAINE 操作系统硬盘也可见:
图 8.24 – fdisk 输出数据
在上面的截图中,有三个独立的硬盘,每个硬盘有自己的分区。标为 /dev/sdc 的硬盘是包含 CAINE 操作系统的 USB 驱动器,系统从该驱动器启动。/dev/sdb 硬盘是系统将要进行成像的证据硬盘。最后,目标系统标记为 /dev/sda。
- 在识别出系统的目标硬盘后,我们需要确认成像过程不会改变数据。CAINE 操作系统内置了一个软件写保护器。在桌面上,你会看到 Block on/off,这是指向实际软件写保护器路径的标题。点击后会打开用于此过程的写保护器。在检查设备列表时,你会看到唯一可以写入的硬盘是 SDB,这就是我们之前确认的证据硬盘。其他硬盘都设置为只读。这可以确保事件响应分析人员,成像过程不会改变目标硬盘(分析人员最好截取该信息的屏幕截图,以便后续报告):
图 8.25 – 解锁设备选择
-
在确认证据硬盘已就位并且目标系统已设置为只读后,配置证据硬盘以确保其正确挂载。使用以下命令创建一个名为
Disk_Images或类似名称的目录,作为此及任何后续磁盘镜像的存储库:caine@caine:~$ sudo mkdir /mnt/Disk_Images -
接下来,使用以下命令将 SDB 磁盘挂载到上一步中创建的挂载目录。请注意,在这种情况下,它是证据驱动器的较大磁盘分区:
caine@caine:~$sudo mount /dev/sdb2 /mnt/Disk_Images
现在,证据驱动器已经挂载到创建的挂载点上。
-
接下来,使用以下命令切换到证据驱动器的目录:
caine@caine:~$ cd /mnt/Disk_Images -
为系统的特定映像文件创建一个目录。在这种情况下,目录将包含事件编号
Incident2022-034,作为目录名。最好将此目录与事件间接关联。以下命令将创建正确的目录:caine@caine:~$ mkdir Incident2022-034 -
通过执行以下命令,切换到在步骤 7中创建的目录:
caine@caine :/ mnt /Disk_Images$ cd Incident2022-034 -
现在,您已经进入了正确的目录,接下来要做的就是对嫌疑人驱动器进行成像。现在有多个工具可用于此操作。在此示例中,将使用 Dc3dd 工具。该工具是由国防部网络犯罪中心(DC3)的取证专家 Jesse Kornblum 开发的。此应用程序具有 dd Linux 映像应用程序中没有的附加功能。这些功能包括错误报告和可以即时使用的多种哈希算法。要开始成像过程,输入以下命令:
caine@caine:/mnt/Disk_Images/Incident2022-034$ dc3dd if=dev/sda of=ACMELaptop056.img hash=md5 log=ACMELaptop56.txt
上面的命令包含dc3dd。首先,将 sda磁盘映像到证据驱动器,并输出一个名为ACMELaptop056的映像文件:
该命令还使 Dc3dd 使用 MD5 算法对映像文件进行哈希计算。最后,创建一个名为ACMELaptop56.txt的日志文件,可以用于报告目的。运行该命令会生成以下输出:
图 8.26 – dc3dd 命令和输出
- 根据驱动器的大小,这个过程可能需要几个小时。在此期间,分析师可以跟踪所做的进展。完成后,应用程序将产生一些输出,指示输入使用了多少个扇区,输出到映像文件中使用了多少个扇区。理想情况下,这两个数字应该相同。最后,计算并利用映像文件的 MD5 哈希值,作为输出的一部分:
图 8.27 – Dc3dd 成像完成
- 从 Windows 系统检查证据驱动器,可以看到使用 Dc3dd 创建的映像和日志文件:
图 8.28 – Dc3dd 输出文件
-
检查日志文件可以揭示以下信息,所有这些信息都应该纳入后续报告中:
dc3dd 7.2.646 started at 2022-05-24 22:17:14 +0200compiled options:command line: dc3dd if=/dev/sda of=ACMELaptop056.img hash=md5 log=ACMELaptop56.txtdevice size: 937703088 sectors (probed), 480,103,981,056 bytessector size: 512 bytes (probed)480103981056 bytes ( 447 G ) copied ( 100% ), 11176,1 s, 41 M/sinput results for device `/dev/sda':937703088 sectors in0 bad sectors replaced by zeros9fc8eb158e5665a05875f4f5f2e6f791 (md5)output results for file `ACMELaptop056.img':937703088 sectors outdc3dd completed at 2022-05-25 01:23:30 +0200
Linux 是获取磁盘证据时一个可行的选择。它的一个重要优势是易于扩展。如果必须获取多个系统,响应者可以使用多个 USB 存储驱动器和 Linux USB 设备,并行进行获取,而不是等待软件可用。CAINE 是一个极好的选择,因为它包含的写保护器还为过程中提供了一定的证据完整性。
成像是响应者必须了解的关键过程。事件通常会决定应该使用哪种技术。然而,在任何事件中,响应者应确保该过程以可靠的方式进行,因为后续调查往往依赖于从这些系统中获取的数据。
总结
并不是每个事件都会要求从潜在受损的硬盘或其他存储卷中获取镜像。无论如何,事件响应分析员应该熟悉并能够在需要时执行此功能。硬盘上找到的证据可能对确定事件的顺序或获取有助于查明事件根本原因的实际文件至关重要。这也是响应者需要了解成像基础知识、相关工具和流程的核心原因,包括如何创建舞台驱动器、如何使用写保护器,以及如何执行本章中提到的任何成像技术。与任何法证学科中执行的过程一样,成像应该以系统的方式进行,确保所有步骤都得到遵循并得到适当的文档记录。这将确保所获取的任何证据都能在法庭上被接受并具备法律效力。
在下一章中,我们将讨论与事件相关的网络活动相关的网络证据检查。
问题
-
写保护器有哪两种类型?(选择两个)
-
硬件
-
数字
-
软件
-
法院批准
-
-
响应者应确保每次使用前,任何用于成像的存储驱动器都已正确消毒。
-
正确
-
错误
-
-
哪种成像方法用于获取驱动器的整个物理卷?
-
死机成像
-
实时成像
-
远程成像
-
硬件成像
-
-
哪种成像应用程序仅在 Linux 系统上找到?
-
FTK Imager
-
EnCase Imager
-
AFF4
-
dd
-
进一步阅读
请参考以下资源,了解本章涵盖的主题:
-
FTK Imager 指南:
d1kpmuwb7gvu1i.cloudfront.net/Imager/4_7_1/FTKImager_UserGuide.pdf -
NIST 计算机取证工具与技术 目录:
toolcatalog.nist.gov/search/index.php?ff_id=1 -
计算机取证中磁盘映像工具概述:
www.sans.org/reading-room/whitepapers/incident/overview-disk-imaging-tool-computer-forensics-643
第三部分:证据分析
完成第二部分的数字证据获取后,第三部分将重点讲解数字取证的正确分析技巧。本部分将专注于使用合适的工具和技术来确定事件的根本原因。
本部分包括以下章节:
-
第九章*,分析网络证据*
-
第十章*,分析系统内存*
-
第十一章*,分析系统存储*
-
第十二章*,分析日志文件*
-
第十三章*,撰写事件报告*
第九章:分析网络证据
第五章探讨了事件响应人员和安全分析师如何获取基于网络的证据以供后续评估。该章节主要关注了两种证据来源:网络日志文件和网络数据包捕获。本章将展示可用于检查已获取证据的工具和技术。将这些技术融入事件响应调查,可以为事件响应分析师提供对潜在威胁的网络活动的洞察。
本章将重点讨论以下主要内容:
-
网络证据概述
-
分析防火墙和代理日志
-
分析 NetFlow
-
分析数据包捕获
网络证据概述
攻击者被同样的网络协议约束,这些协议控制着正常的网络流量。本文将探讨通过正确分析网络数据来识别的对抗技术。
在第五章中,我们重点关注了网络设备产生的各种证据。大多数这些证据包含在交换机、路由器和防火墙生成的各种日志文件中。根据响应人员所处的环境类型,这些证据来源可以通过 NetFlow 数据和完整的数据包捕获进行补充。
一旦了解了各种来源,重要的是要关注日志、NetFlow 和数据包捕获能告诉我们关于事件的哪些信息。以下是几个关注点,在这些领域中,适当的日志记录和证据收集可以为事件提供额外的背景信息,以及在分析根本原因时可能的数据点:
-
侦察与扫描行为:攻击者可以利用众多工具来自动化扫描外围设备(如防火墙和路由器)的过程。这些扫描工具试图确定开放端口、漏洞或可以被利用的认证协议,如安全外壳(SSH)。这些扫描会留下痕迹,因为它们通常需要与设备建立连接。根据日志记录的级别和保留期限,响应人员可能能够识别出尝试破坏外围系统的外部基础设施。
-
初始感染:攻击者在入侵系统方面变得非常复杂。他们通常会利用多阶段的漏洞利用和恶意软件。第一阶段将通过 URL 调用外部基础设施并下载其他漏洞。Web 代理和防火墙的日志文件中可能包含记录此活动的连接数据。
-
横向移动:一旦进入网络,攻击者通常会尝试进行侦察、利用其他系统并移动数据。NetFlow 日志可以提供对这种行为的洞察。
-
指挥和控制:一旦在网络中站稳脚跟,攻击者就需要能够维持对受损系统的控制。日志、数据包捕获和 NetFlow 数据可以用来识别这种行为。
-
数据泄漏:攻击者的目标之一可能是破坏并窃取数据。代理日志可能会识别这些数据的目的地。NetFlow 可能会显示从内部系统到外部系统的数据流动。最后,数据包捕获可以用来识别泄露的文件、数据源以及目的地。
在第五章中,我们讨论了在事件中可以利用的三种主要类型的网络证据。对于不了解网络流量的响应者来说,理解网络流量的各个方面往往是困难的。可以将网络流量看作是从一个人发送到另一个人的信件。日志数据记录了发送者和接收者的地址以及在一个中央位置(如本地邮局)的邮箱号码。这类似于源 IP 地址和目标 IP 地址以及端口。
NetFlow 记录了关于信件的许多相同信息,但还可以告诉个人信件的重量或相对大小,以及发送者和接收者的地址和邮箱号码。最后,数据包捕获提供了通过日志和 NetFlow 获得的所有信息,还会告诉个人信件的内容,包括(只要它没有加密)实际的数据。
通过网络证据识别根本原因在很大程度上取决于证据本身。像数据包捕获和日志文件这样的证据的一个主要缺点是,正常网络操作所产生的数据量巨大。通常,事件发生后几天甚至几周才会被识别。在此期间,这些日志文件和数据包捕获可能变得无法获取。因此,响应者必须充分理解他们组织在网络证据方面的能力。
分析防火墙和代理日志
攻击者需要与其基础设施建立初始连接并保持持续连接。网络设备如防火墙和代理可能提供日志文件作为证据来源。
第五章包含了有关获取基于网络的证据以及对事件响应者或安全分析师重要的日志文件类型的大量信息。除了之前讨论的数据包捕获外,我们还重点关注了从多种来源获取日志文件。这些日志文件可以为可能的入侵指示提供一些线索,帮助事件调查。然而,分析师面临的主要挑战是从大量无关的日志中筛选出那些具有证据价值的日志。
日志文件分析可以通过多种方式进行。使用的具体方法通常取决于事件的类型、可用的工具和需要分析的日志数据量。以下是一些可以使用的方法:
-
手动日志审查:在手动日志审查中,原始日志文件会被导入到像文本编辑器这样的工具中。之后,分析人员将逐行审查日志。这是一种低成本的解决方案,但仅在数据量有限时有用。例如,分析人员无法在大型企业防火墙连接日志上执行此类分析。然而,它可能对确定某个特定日期有哪些用户登录到不常用的 Web 应用程序有帮助。
-
过滤日志审查:日志审查工具允许分析人员根据特定参数过滤日志文件。这可以包括显示已知恶意活动的列表。一个缺点是,日志可能不会立即指示已知的恶意活动,而是在最初阶段看起来无害。
-
日志文件搜索:大多数日志分析工具的另一个关键功能是能够搜索日志文件中的特定表达式。搜索工具可以利用正则表达式和布尔表达式,并允许分析人员将日志限制在特定的时间段、源 IP 地址或其他特定条件下。这使得分析人员可以迅速定位特定的日志文件。根据搜索词的不同,这可能返回大量的信息,需要手动进一步审查。
-
日志文件关联:可以根据预配置的规则或算法将不同的日志活动与其他日志进行关联。日志关联通常是日志管理工具或安全信息和事件管理(SIEM)平台的一部分,这些工具带有已创建的规则集。这种方法非常强大,因为它自动化了过程,但也需要大量的前期劳动来配置和调整特定环境。
-
日志文件数据挖掘:比关联更进一步的是能够从日志文件中提取有意义的信息。这为特定活动提供了更多的上下文和洞察力。在撰写本文时,已有多个工具(如 Elasticsearch 和 Logstash)可以集成到平台中,以提供更有用的信息。
网络中每月产生的日志数量可能是惊人的。随着新来源的增加,这一数量只会进一步增加。手动筛选这些日志几乎是不可能的。在日志审查方面,最好有一个能够提供一定自动化程度的解决方案,即使是在小型网络中。这些工具使分析人员能够在成千上万的日志中找到那根关键的针。
SIEM 工具
SIEM 工具对于获得网络活动的态势感知至关重要。这些平台不仅充当来自网络设备的日志文件的聚合点,还允许分析员对已聚合的日志进行查询。例如,假设在分析数据包捕获文件时,发现了与潜在恶意活动相关的 IP 地址。这个文件仅限于内部网络上的一台主机。分析员希望回答的一个问题是,其他多少台主机可能已经被感染?如果 SIEM 聚合了来自外部防火墙和 Web 代理等设备的连接日志文件,分析员就能够确定是否有其他内部主机连接到这些可疑的 IP 地址。
有多种 SIEM 平台可供选择,从免费的解决方案到企业级安全管理平台。这些平台大多数允许分析员进行过滤搜索和关联日志审查。许多更强大的商业平台提供了检测特定类型攻击的规则集,并随着新攻击的出现更新这些规则集。分析员还可以查询 SIEM 工具,以获取主机 IP 地址与其他系统的连接日志。这通常是恶意软件感染机器后,攻击者试图攻破其他机器时的行为表现。
在事件响应人员与负责维护 SIEM 工具的人员分开的组织中,最好审查一下通信结构,以确保事件响应分析员可以访问这些平台。可用的大量信息和数据可以帮助确定内部网络上哪些活动与可能的事件相关,以及可以用来确定根本原因的证据。
Elastic Stack
除了 SIEM 技术外,事件响应分析员还可以利用一系列应用程序进行日志分析。这一系列工具被称为 Elastic Stack,它结合了三种工具,能够分析大量数据。第一个工具是 Elasticsearch。Elasticsearch 是一个日志搜索工具,允许对日志数据进行近实时搜索。这是通过 Lucene 驱动的全文搜索实现的。这使得分析员能够针对日志文件中的元素(如用户 ID、IP 地址或日志条目编号)执行查询。Elasticsearch 的另一个关键特性是平台能够随着企业的增长和数据源的增加,扩展解决方案。这对于那些可能希望先测试此功能,然后逐步添加数据源和日志文件的组织来说非常有用。
Elastic Stack 中的下一个组件是 Logstash。Logstash 是处理来自网络各个来源的日志文件输入、处理日志条目,并最终通过可视化平台输出它们的机制。Logstash 可以轻松配置和部署。Logstash 与 Elasticsearch 的集成使得事件响应分析师能够对大量日志数据进行快速查询。
Elastic Stack 的最终组件是 Kibana。Kibana 作为 Elastic Stack 的可视化界面或仪表板,允许分析师通过仪表板洞察数据。Kibana 还允许分析师深入到特定的关键数据点进行详细分析。事件响应分析师可以自定义这些仪表板,以便最重要的信息,如入侵检测日志或连接日志,能够立即供审阅。
例如,Kibana 仪表板利用多个饼图来展示日志活动。利用这些图表可以概览分析师可用的信息。
增强日志的一个好工具是 NetFlow 分析,我们将在接下来介绍。
分析 NetFlow
NetFlow 描述了网络中设备之间连接的数据。NetFlow 主要用于故障排除连接性和带宽问题,事件响应人员可以使用 NetFlow 获得数据流动的洞察,从而引发事件。
NetFlow 是由 Cisco Systems 在 1990 年代首次推出的一个功能。NetFlow 收集关于数据包的特定数据,当它们进入或退出路由器或交换机的接口时。这些数据随后通过 NetFlow 导出器发送到 NetFlow 收集器,NetFlow 导出器通常作为交换机或路由器的一部分。NetFlow 收集器随后汇总并存储流数据以供分析。网络和系统管理员通常利用这些数据来排查带宽问题、识别网络拥堵以及观察数据流动情况。
以下截图中可以看到一个 NetFlow 输出的示例。流数据包含的内容在网络设备制造商之间可能有所不同,因为商业市场上有多个版本。以下截图显示了作为 NetFlow 数据集一部分所捕获的一些基本信息:
图 9.1 – 示例 NetFlow 数据
以下是前面截图中可以看到的 NetFlow 记录的组成部分:
-
Src Addr:这是启动连接或发送流量的源地址。
-
Dst Addr:连接的目标地址。
-
Sport:这是源地址的源端口。
-
Dport:这是目标端口。在将 NetFlow 作为事件调查的一部分进行分析时,这是需要关注的关键数据点之一,因为它通常能告诉响应人员源地址正在连接的服务。
-
Proto:这是使用的协议。
-
数据包:作为流的一部分所生成的数据包数量。
-
字节:字节的总数。
-
流:这表示已记录的流的数量。流可以视为独立的 TCP 连接。例如,使用像 Wireshark 这样的工具分析数据包捕获时,会显示单独的数据包。流指示已建立的 TCP 会话。在这种情况下,如果 SSH 会话中断并重新建立,则会记录两个流。
在检查前面的 NetFlow 数据时,两个重要的数据点可能值得关注。第一个是设备之间的 SSH 连接数量。安全外壳(SSH)是系统之间常用的通信方式,但如果它超出了正常网络行为的范围,则需要进一步调查。此外,通过 SMB(端口445)的连接常常被攻击者滥用,用于访问其他系统、传播勒索软件或访问文件共享。即使在这个简短的示例中,也可以清楚地看到,响应人员通过仅查看内部网络上发生的连接,就能获得大量的洞察信息。
分析数据包捕获
事件发生时,最好的证据来源之一是数据包捕获。分析这些数据包可以揭示数据外泄、漏洞利用以及命令和控制。
第五章详细介绍了从各种来源和不同位置获取数据包捕获的多种方法。数据包捕获包含大量潜在对事件响应分析员有价值的信息。其中一些信息包括源和目的地 IP 地址、域名和端口,以及主机之间通信的内容。在某些情况下,事件响应分析员可以重建实际文件,例如文本文件和图像。主要的缺点是涉及的数据量非常庞大。
示例数据包捕获
本章提到了一些预先配置好的数据包捕获。这些数据包捕获直接来源于malware-traffic-analysis.net/,并得到了作者的许可。该网站包含多个数据包捕获练习,事件响应分析员可以在这些练习中练习定位妥协迹象。不过需要注意的是,这些捕获可能包含恶意软件。你应该仅在正确配置的沙盒环境中(见第十六章)或其他不与生产环境连接的系统中检查实时数据包捕获。
命令行工具
分析网络数据包捕获时可以使用多个命令行工具。在更深入或较长时间的事件响应工作中,分析员可能会收集多个数据包捕获文件。将这些多个数据包捕获文件合并成一个文件可以使分析变得更加简便。Mergecap 应用程序正是通过将多个数据包捕获文件合并来实现这一点。Mergecap 是 SANS SIFT 工作站的一部分,可以通过以下命令执行:
sansforensics@siftworkstation: ~$ mergecap packetcapture1.pcap packetcapture2.pcap
另一个在分析数据包捕获时非常有用的命令行工具是 Editcap。Editcap 允许分析员将数据包捕获文件分割成更小的段,便于审查。例如,分析员可能只希望查看被拆分成 50,000 个数据包段的捕获文件。如果分析员有一个很大的数据包捕获文件,分割文件会使得搜索更加高效。为此,分析员可以在命令行中输入以下命令:
sansforensics@siftworkstation: ~$ editcap -F pcap -c evidence.pcap split.pcap
在上面的命令中,editcap 将 evidence.pcap 证据文件分割成了 50,000 个数据包段。Editcap 还可以用来将较大的数据包捕获文件按时间段进行分割。例如,如果分析员希望将数据包捕获文件按 10 分钟为一个段来分割,他们可以输入以下命令:
sansforensics@siftworkstation: ~$ editcap -F pcap-t+600 evidence.pcap split.pcap
分析员还可能会发现,在某些情况下,他们可能希望隔离域名注册流量。这在很大程度上是由于各种对抗性行为,如 C2 流量、数据外泄,以及可能通过利用 DNS 系统中的漏洞重定向到受损网站。dnstop 应用程序解析数据包捕获文件并确定来自内部主机的 DNS 查询的来源和数量。要在 Linux 系统上安装它,可以使用以下命令:
dfir@ubuntu:~$ sudo apt-get install dnstop
此命令将下载并安装 dnstop。在以下示例中,数据包捕获是从位于 www.malware-traffic-analysis.net/2022/03/21/index2.html 的恶意软件流量分析网站获取的。如果事件响应分析员想要确定是否有任何 IP 地址正在发送外发的 DNS 查询,他们只需执行以下命令:
dfir@ubuntu:~/Documents/Packet Captures$ dnstop 2022-03-21-Hancitor-with-Cobalt-Strike-and-Mars-Stealer.pcap
上述命令的输出结果如下:
图 9.2 – DNS 查询计数
实时威胁情报分析
使用数据包捕获时的一个挑战是涉及的数据量非常庞大。即使是来自中型网络的 24 小时数据包捕获也会带来问题。一种方法是使用关注关键数据点的工具。例如,与命令和控制(C2)相关的信标流量是需要查找的重要数据,因为它是对手与内部网络之间的连接。
一个可以提供帮助的工具是 Active Countermeasure 的实时智能威胁分析(RITA)工具。这个命令行工具利用行为分析来识别表明信标行为的模式,以便分析师能够专注于特定的 IP 地址或域名。这个工具的一个关键特性是它能够处理大型数据包捕获文件,例如通过 24 小时内的捕获得到的文件。这使得分析师能够找到即便是非常低速的命令与控制流量。
安装 RITA 非常简单。在这个案例中,RITA 已安装在 Ubuntu 桌面上。首先,创建一个 RITA 目录。其次,从 GitHub 网站下载安装脚本:github.com/activecm/rita/releases/tag/v4.5.1。接下来,运行以下命令使文件可执行:
dfir@ubuntu:~/rita$ sudo chmod +x ./install.sh
接下来,通过运行以下命令执行安装脚本:
dfir@ubuntu:~/rita$ ./install.sh
安装脚本会安装必要的依赖项,例如 Mongo 数据库结构和数据包捕获分析工具 Zeek。
Zeek
Zeek 是一个网络监控和分析工具,它与 RITA 一起使用。如需了解有关 Zeek 的更多信息,请访问docs.zeek.org/en/lts/。
下一步是处理数据包捕获。在这种情况下,两个数据包捕获文件来自malware-traffic-analysis.net/2022/01/27/index.html上的恶意软件流量分析帖子,并已合并为一个文件。这个文件被移动到 RITA 目录中。以下命令将 Zeek 指向数据包捕获文件,以便它能够处理成各种日志文件:
dfir@ubuntu:~/rita$ zeek -C -r IcedId.pcap
检查目录中的文件,显示已处理的日志文件:
图 9.3 – Zeek 日志文件
在使用 Zeek 处理数据包捕获后,日志文件需要导入到 RITA 可以读取的数据库IcedID中,使用以下命令:
dfir@ubuntu:~/rita$ rita import *.log IcedID
一旦运行该命令,结果应如下所示:
图 9.4 – RITA Zeek 日志导入
要访问 RITA 的帮助菜单,请输入以下命令:
dfir@ubuntu:~/rita$ rita
这将产生以下命令及相关结果:
图 9.5 – RITA 功能
让我们继续查看是否有任何数据包表明信标行为。运行show-beacons命令,针对之前通过运行IcedID数据库创建的数据库进行操作:
dfir@ubuntu:~/rita$ rita show-beacons IcedID
这会产生以下结果:
图 9.6 – RITA 信标分析
在图 9.6中,RITA 指示内部 IP 地址10.1.28.101已与 IP 地址149.255.35.174建立了 234 个连接。值得注意的一个结果是结果行开头的第一个数字0.838。这个分数表示 RITA 对这些结果的置信度,范围从 0 到 1。在这种情况下,几乎有 84%的置信度认为该流量是信标行为。
另一个选项是运行show-beacons-fqdn命令,它将显示系统的域名:
dfir@ubuntu:~/rita$ rita show-beacons-fqdn IcedID
这产生了类似的结果,但表明命令与控制服务器的域名为driverpackcdn.com,如下所示:
图 9.7 – RITA Beacon 完全限定域名
如我们所见,RITA 允许分析人员专注于特定的 IP 地址和域名,作为潜在的恶意目标,而无需挖掘数以 GB 计的数据包信息。从这里,他们可以直接转到关键的连接,这些连接在基于 GUI 的工具中是至关重要的,我们接下来将重点讨论这一部分。
NetworkMiner
与命令行工具相比,分离数据包捕获数据的基于 GUI 的工具更容易操作。一个这样的工具是 NetworkMiner,可以在www.netresec.com/?page=NetworkMiner找到。该工具有商业版和社区版,社区版功能更有限。尽管如此,社区版仍具备一些在分析数据包捕获时非常有用的关键特性。
在本演示中,我们将查看与 Hancitor 感染相关的 PCAP 文件,可以从 malware-traffic-analysis.net/2022/03/21/index2.html 下载。通过选择 文件 并点击 打开 来加载 PCAP 数据。导航到数据包捕获文件并点击 打开。NetworkMiner 会处理 PCAP 文件并显示数据包捕获中找到的主机:
图 9.8 – NetworkMiner GUI
下一个标签页,文件,显示了数据包捕获中包含的文件:
图 9.9 – NetworkMiner 的文件标签页
如果你进一步深入查看从bor4omkin.ru下载的b123.exe文件,源 IP 地址为45.8.124.233:
图 9.10 – 可疑文件
除了可视化数据包捕获中的文件外,NetworkMiner 还会提取它们并将它们放入按 IP 地址分类的AssembledFiles目录中。这使得分析人员可以快速识别可疑文件并进行分析。
NetworkMiner 是一个非常有用的工具,用于初步查看数据包捕获。它提供有关文件、DNS 查询、会话和其他关键数据点的详细信息。它的主要优势在于能够快速聚焦于关键数据点,从而使分析人员可以集中精力查看特定领域,而无需挖掘整个数据包捕获来寻找关键证据。
Arkime
Arkime 是一个开源的数据包捕获与搜索系统,允许分析师和响应者检查大量的网络数据包捕获。默认情况下,Arkime 会将数据包捕获按捕获中包含的各个会话进行组织。Arkime 可以作为网络监控系统使用,通过将数据包导入到 Elasticsearch 基础架构中,响应者可以实时查看网络活动。另一个 Arkime 的使用方式是加载离线数据包捕获进行索引。
Arkime 的安装说明可以在 GitHub 上找到,网址为 raw.githubusercontent.com/arkime/arkime/master/release/README.txt。Arkime 可以安装在各种 Linux 桌面或服务器平台上。服务器选项为较大的团队提供了共享数据包捕获数据和评估正在运行的捕获的能力。桌面安装适用于处理离线数据并且不需要共享结果的响应者。
在本节中,我们将使用 Arkime 分析来自与钓鱼攻击相关的系统的一个数据包捕获。该数据包捕获文件可以在malware-traffic-analysis.net/2022/02/25/2022-02-25-Emotet-epoch4-with-spambot-activity.pcap.zip找到。
首先,在 Arkime 中为离线数据包捕获创建一个目录。这可以在 home 目录中完成。接下来,使用 SFTP 将数据包捕获文件传输到离线数据包捕获目录中。最后,使用位于 /opt/arkime/bin 目录中的 Arkime 捕获二进制文件,使用以下命令处理数据包捕获:
arkime@arkime:/opt/arkime/bin$ sudo ./capture -r /home/offlinecaps/2022-02-25-Emotet-epoch4-with-spambot-activity.pcap
上述命令处理2022-02-25-Emotet-epoch4-with-spambot-activity.pcap文件,使其可以通过 GUI 进行查看。需要注意的一点是-r参数,它只处理单个数据包捕获。如果有多个捕获,可以使用-R参数运行二进制文件,这将递归处理目录中的所有数据包捕获。图 9.11 显示了正在处理的数据包捕获:
图 9.11 – Arkime PCAP 导入
完成后,打开浏览器并导航到服务器或工作站的 IP 地址,并指定端口 8005。这将打开 Arkime 界面。在左上角,将时间设置为全部。设置时间后,将显示以下视图:
图 9.12 – Arkime GUI 仪表板
Arkime 是一个功能丰富的平台。以下步骤概述了在检查离线数据包捕获时可用的一些功能:
- 仪表板中对数据包捕获的检查识别出几个不同的会话,其中
10.2.25.101的内部系统正在与外部 IP 地址进行通信。为了将搜索结果缩小为 HTTP 上的互联网流量,应该在搜索栏中输入以下查询:
图 9.13 – HTTP 端口 80 查询
- 这表明有两个目标端口为
80的 TCP 会话。这些会话可以通过仪表板中显示的任何字段进行排序。一个有用的关键数据是会话中传输的字节数。如果发送和接收的字节数之间存在较大差异,可能表明存在数据外泄,如果发送的字节数较大,或者在本次捕获中,接收的字节数较大,则可能表示文件传输,如以下条目所示:
图 9.14 – HTTP 会话数据
- 仪表板的最右侧包含关于会话的 URI 及相关信息。例如,检查 HTTP 上的会话表明本地主机访问了一个看起来像是 Windows 更新站点的页面:
图 9.15 – Arkime URI 数据
- Arkime 在与 Windows 更新相关的信息 URI 所在的同一会话行中提供了额外的信息。点击绿色加号框,将打开以下页面:
图 9.16 – 会话数据
- 更下方,在HTTP标题下,是有关连接的有价值数据:
图 9.17 – HTTP 会话数据
- Arkime 的另一个有用功能是能够可视化连接。在 Arkime web 应用程序的顶部有连接选项。如果点击连接,将出现以下内容:
图 9.18 – Arkime 连接图
接下来,让我们看看如何重置 Arkime。
我该如何重置 Arkime?
在分析结束时,有两种方法可以清除现有数据,为后续分析做准备。第一种方法是在虚拟化平台(如 VMware)上部署 Arkime。在此,你可以创建一个新的安装,并捕获新安装的快照。一旦分析完成,你可以恢复到新的安装快照。
另一种方法是重新运行init或wipe命令。步骤如下:
-
保持 Elasticsearch 运行。
-
关闭所有正在运行的查看器或捕获进程,以确保不会录制新的数据。
-
要删除存储在 Elasticsearch 中的所有 SPI 数据,请使用
db.pl脚本,并使用init或wipe命令。两个命令之间的唯一区别是,wipe保留已添加的用户,以便它们不需要重新添加:/opt/arkime/db/db.pl http://ESHOST:9200 wipe -
删除 PCAP 文件。PCAP 文件以
raw格式存储在文件系统中。你需要在所有捕获机器上执行此操作:/bin/rm -f /opt/arkime/raw/*
Arkime 的主要优势是能够以流视图查看网络流量。对于更详细的逐包视图,最好的工具是 Wireshark,接下来我们将介绍它。
Wireshark
Wireshark 是事件响应分析人员最受欢迎的数据包捕获分析工具之一。除了捕获数据包的功能外,还有许多其他功能可用。由于大量的书籍和培训课程围绕这个平台构建,因此很难列出所有的功能。因此,本章将重点介绍一些在事件调查中最为适用的 Wireshark 关键功能。
Wireshark 资源
可以说,Wireshark 是 IT 和安全专业人员首选的数据包分析工具。由于该应用的普及,市场上有大量资源可用于深入学习 Wireshark 及其功能。Wireshark 官网www.wireshark.org/提供了丰富的信息。此外,www.chappell-university.com/网站提供了练习和培训数据包捕获,以帮助提升分析技能。
此外,《Learn Wireshark》一书的作者 Lisa Bock 在她的书中对 Wireshark 进行了深入的讲解,该书可在www.packtpub.com/product/learn-wireshark-fundamentals-of-wireshark/9781789134506上找到。
由于 Wireshark 是一款功能丰富的工具,一些设置更适合用于网络流量分析,而不适用于事件响应活动。因此,需要进行一些更改,以更好地帮助事件响应分析人员执行有关事件调查的数据包捕获分析:
-
时间:Wireshark 中的时间设置提供了多个选项。包括自 1970 年 1 月 1 日起或自数据包捕获开始起的时间。这些选项中有一个在事件调查中非常有用的功能,即单个数据包捕获的日期和时间。这使得分析人员能够将其他可疑或恶意活动的日期和时间与数据包捕获中特定流量的日期和时间进行关联。要启用此功能,请导航到 视图,然后选择 时间显示格式。从中选择一个时间选项,如 日期和时间 或 日期或一天中的时间。另一个可以考虑的选项是使用 UTC 时间选项。如果内部网络使用 UTC 而非本地时间,这将非常有用。时间还可以设置为纳秒级。
-
名称解析:名称解析设置允许分析人员在查看源主机和目标主机的 IP 地址与主机名解析之间切换。如果分析人员正在检查数据包捕获并希望确定是否发现了任何可疑的主机名,这将非常有用。例如,如果打开数据包捕获,你将看到各种 IP 地址:
图 9.19 – Wireshark IP 地址视图
要确定主机名,请导航到 查看 然后选择 名称解析。点击 解析网络地址。Wireshark 将解析 IP 地址为主机名:
图 9.20 – Wireshark 域名视图
- 数据包列表着色:此功能允许分析人员在数据包列表的空白背景和让 Wireshark 为数据包上色之间切换:
图 9.21 – Wireshark – 经典着色规则
在本章中,将使用位于 malware-traffic-analysis.net/2022/04/14/index.html 的恶意软件流量分析中的数据包捕获进行 Wireshark 探索。该数据包捕获包括下载 Qakbot 恶意软件副本以及 Cobalt Strike。对于本章,将识别数据包捕获中的几个关键元素。在检查数据包捕获之前,Wireshark 已配置为显示日期和时间,并识别主机名。
以下是 Wireshark 中的一些功能,它们提供了从数据包捕获中获得的关键信息:
ip.src==10.4.14.101语法,显示以下内容:
图 9.22 – 源地址过滤器
- 主机识别:分析数据包捕获的另一个关键方面是识别本地主机(如果适用)。考虑到这个数据包捕获来自单一主机,识别主机名、IP 地址和 MAC 地址是直接的。通过双击单个数据包,可以找到大量信息:
图 9.23 – 数据包数据
-
80。 -
http。在输入此过滤器时请注意,因为将有多个不同的过滤器可用。一旦输入了过滤器,点击对话框右侧的右箭头。Wireshark 将限制显示仅使用 HTTP 协议的数据包:
图 9.24 – HTTP 数据包视图
geobram.com可能是一个可疑的 URL。Wireshark 的另一个功能是能够跟踪源主机与目标主机之间的 TCP 或 HTTP 通信流。如果你右键点击rozhan-hse.com主机名,将会出现以下内容:
图 9.25 – 跟踪 HTTP 流
将会出现第二个窗口;点击HTTP 流,第三个窗口将会出现。此窗口以可以读取的格式显示 HTTP 数据包。事件响应分析员可以查看此输出,确定可能已发送或接收的文件类型:
图 9.26 – HTTP 数据包信息
GET命令正在访问NO_2950435796.zip文件。分析员可能需要提取该文件进行分析。点击文件,然后点击导出对象,再点击HTTP;会出现一个窗口,列出所有与 HTTP 连接相关的文件。此列表可以根据窗口顶部的任意字段进行排序。在这种情况下,选择主机名并向下滚动,直到找到可疑的 URL:
图 9.27 – Wireshark – 导出 – HTTP 对象列表
从这里,分析员可以点击文件并将其保存到本地系统以供后续分析。第十二章将选择文件并评估其中的恶意代码。
Wireshark 是一个强大的工具,用于对数据包捕获进行详细分析。能够深入查看每个数据包并对其进行剖析,帮助分析员非常详细地了解流向外部主机和内部主机之间的流量内容。这种可见性可以为分析员提供潜在的洞察,了解受感染的主机如何与外部主机通信,甚至识别其他可能已被攻陷的主机。
总结
安全事件不仅会在主机系统上产生痕迹,还会在网络中的设备和流量流经的路径上留下痕迹。分析这些痕迹证据将帮助事件响应分析员更好地理解他们正在调查的事件类型,以及可以采取的潜在措施。本章讲解了如何通过快速的黑名单对比、DNS 分析以及使用 Elastic Stack 或其他 SIEM 系统进行日志分析来评估日志文件。为了增强这一主要的网络证据评估方法,我们还介绍了 NetFlow 分析,并使用 Arkime 和 Wireshark 进行了数据包捕获分析。网络证据是事件调查中的关键组成部分。结合从可能被攻陷的网站获取的证据,这些痕迹证据有助于分析员重建事件的发生过程。
下一章将把焦点从网络流量转向主机,接着会探讨内存分析。
问题
回答以下问题,测试你对本章内容的掌握:
-
过滤日志审查是指响应者或分析员根据设定的参数过滤特定日志。
-
正确
-
错误
-
-
Elastic Stack 的组成部分不包括什么?
-
Elasticsearch
-
日志转发器
-
Logstash
-
Kibana
-
-
哪个数据包分析工具默认将数据包捕获按会话进行分类?
-
Wireshark
-
NetFlow
-
Elastic Stack
-
Arkime
-
-
Wireshark 不支持 DNS 名称解析。
-
正确
-
错误
-
进一步阅读
请参考以下链接,获取本章所涉及主题的更多信息:
-
Elasticsearch 7.0 Cookbook - 第四 版:
www.packtpub.com/big-data-and-business-intelligence/elasticsearch-70-cookbook-fourth-edition。 -
恶意软件流量 分析:
www.malware-traffic-analysis.net。 -
Arkime:
arkime.com/。 -
查普尔大学:
www.chappell-university.com/。 -
思科 IOS NetFlow:
www.cisco.com/c/en/us/products/ios-nx-os-software/ios-netflow/index.html。
第十章:分析系统内存
长时间以来,执法部门和其他执行与事件调查相关的数字取证任务的组织常常依赖于专注于计算机硬盘中证据的方法论。程序要求关闭系统并拆卸硬盘以进行成像。虽然这种方法论及其相关程序有效地确保了证据的完整性,但它忽略了目标系统中随机存取内存(RAM,即内存)中包含的大量信息。因此,事件响应分析师开始将大量注意力集中在确保采用适当的方法来保持这些证据的完整性,同时为他们提供一个平台,从中获取具有证据价值的信息。
本章将重点介绍可以在系统内存中定位的证据类型,事件响应分析师可用的工具和技术,最后,如何分析这些信息以清楚地了解系统是如何被入侵的。此外,这些技术还可以与其他证据的分析结合使用,例如网络日志文件和存储在目标系统上的文件。
本章将涉及以下主要内容:
-
内存分析概述:本节讨论通过适当的内存分析可以发现的关键数据点。
-
内存分析方法论:结构化的方法非常重要,确保响应人员能够提取必要的数据。
-
Volatility 内存分析:通常被认为是内存分析的黄金标准,这个命令行工具具有广泛的数据采集和分析功能。
-
字符串内存分析:一个简单但有效的工具,使响应人员能够从其他工具可能遗漏的内存区域中提取数据。
在本章结束时,您将掌握必要的方法论和工具,能够找到数据点,分析它们,并提取其他证据以供后续分析。
内存分析概述
在讨论如何分析系统内存时,两个术语通常互换使用。术语 RAM 和内存用于描述计算机内部系统中的一部分,在该部分中,操作系统放置被应用程序和系统硬件在使用时所需的数据。RAM 或内存与存储的区别在于数据的易失性。通常,如果系统关闭,数据会丢失。
操作系统的一个变化,直接影响了内存分析,那就是 64 位操作系统的出现。使用 64 位寄存器使操作系统可以引用总共 17,179,869,184 GB 的内存。与 32 位操作系统相比,这个数据量是以前可用数据的几百万倍。因此,系统运行时,RAM 中包含了大量有价值的数据,这些数据在事件调查中具有重要作用。包括以下内容:
-
正在运行的进程
-
加载的 动态链接库 (DLL)
-
加载的设备驱动程序
-
打开注册表键
-
网络连接
-
命令历史记录
随着分析系统内存的必要性增加,分析师有几种工具可供使用。本章将重点介绍三种工具;它们都是开源或免费软件,且可以轻松部署。这些工具使分析师能够深入了解利用漏洞和恶意软件对系统造成的影响。
在本章中,将使用两个内存捕获文件。第一个内存捕获文件来自一台被 Cridex 病毒感染的 Windows 系统。内存镜像可以从 files.sempersecurus.org/dumps/cridex_memdump.zip 下载。
第二部分是另一个 Windows 系统,属于一个可供训练使用的练习,文件可以通过 dfirmadness.com/case001/DC01-memory.zip 下载。
尽管这两种恶意软件感染相对较旧,但它们有助于突出我们将要分析的工具集的特定功能。
内存分析方法论
在检查系统内存时,分析师应遵循一定的方法论。这可以确保所有潜在证据被发现,并且可以在事件调查中加以利用。我们将探讨两种方法论。其中一种是 SANS 六部分方法论,旨在识别与恶意软件执行相关的妥协指标。另一种方法论则侧重于利用 IP 地址或其他网络物品来识别与该 IP 地址相关的恶意代码。
内存分析的主要目标之一是识别潜在的恶意进程或可执行文件,这些文件可以提取出来进行检查。本章中的大部分内容将在 第十六章 中继续探讨,其中提取的数据将进一步分析。
SANS 六部分方法论
SANS 机构采用六部分方法论来分析内存镜像。该过程旨在从全面了解正在运行的程序开始,直到识别和访问恶意软件。SANS 方法论包括以下步骤:
-
识别恶意进程:恶意软件常常将其行为隐藏在表面上看似合法的进程后面。揭示这些进程需要识别当前运行的进程,找到它们在操作系统中的位置,并验证只使用了合法的进程。有时,进程会明目张胆地隐藏起来,攻击者通过修改进程名称中的一个字母来掩盖其踪迹。其他时候,他们会尝试从不合法的来源执行一个进程。
-
分析进程的 DLL 和句柄:一旦识别出某个进程或多个进程为恶意进程,下一步是检查与该进程相关的 DLL 文件,以及其他因素,如账户信息。恶意软件编程人员常常利用 DLL 文件隐藏其活动。利用 DLL 文件来攻破系统的技术包括恶意软件编程人员将自己的恶意 DLL 文件作为恶意软件的一部分插入系统。其他技术则包括 DLL 注入,即将恶意 DLL 文件的路径写入进程中。
-
审查网络痕迹:恶意软件,尤其是多阶段恶意软件,需要与互联网建立连接。即使完全被攻破的系统,通常也会向 C2 服务器发送信号。活动和监听中的网络连接存在于这些系统的内存中。识别外部主机的 IP 地址可能有助于洞察已发生的入侵类型。
-
寻找代码注入的证据:进程空洞化和内存中未映射的区域等技术通常被高级恶意软件编程人员使用。内存分析工具帮助分析人员找到这些技术的证据。
-
检查根套件的迹象:持久性是许多外部威胁行为者的目标。如果他们最初能够攻破系统,他们必须保持这种控制。因此,攻击者可能会使用根套件或嵌入到操作系统深处的恶意软件。这种恶意软件使攻击者能够持续、常常是以更高权限的方式访问系统,同时保持未被发现。
-
转储可疑的进程和驱动程序:在定位到任何可疑的进程或可执行文件后,分析人员需要能够获取它们,以便使用额外的工具进行后续分析。
接下来,我们将了解网络连接的方法。
网络连接方法
在许多事件中,系统被攻破的第一个迹象是尝试或完成与外部主机的连接。防火墙或 Web 代理等检测机制可能表明系统正在尝试与可疑的外部主机通信。基于此起点,可能能够识别出系统上潜在的恶意软件:
-
可疑的网络连接:对与外部连接相关的主机上的网络连接进行审查,通常能提供尝试进行通信的进程。
-
进程名称:通过网络连接检查进程可以让分析员执行 SANS 方法中类似的操作。建议分析员还应该判断所识别的进程是否是一个通常需要网络连接的进程。
-
父进程 ID:深入了解父进程有助于判断该进程是否是合法的,并且是否有合法的需求通过网络连接进行通信。
-
关联实体:最后,检查关联的 DLL 和其他遗留物将引导我们到达一个阶段,届时可以获取并分析它们。
现在,让我们来看一些内存分析工具。
内存分析工具
分析员可以使用多个工具来查看内存映像。一些工具提供图形用户界面(GUI)以便使用,而其他工具则通过命令行操作,这使得它们对于脚本编写非常有用。本章将检查三种工具。第一种是 Mandiant Redline,它是一个基于 GUI 的内存分析工具,能够检查内存映像中的恶意进程迹象,并根据几个因素对其进行评分。第二种工具是 Volatility,它是一个命令行工具,允许分析员深入分析内存映像的细节,并识别潜在的恶意代码。最后将检查的是 Linux 中可用的 Strings 工具。Strings 允许通过 GREP 进行关键字搜索,帮助响应人员识别出可能不容易通过其他工具看到的 IOC。
使用 Volatility 进行内存分析
Volatility 是一个高级的开源内存取证框架。该框架中的主要工具是 Volatility Python 脚本,它利用多种插件来分析内存映像。因此,Volatility 可以在任何支持 Python 的操作系统上运行。此外,Volatility 还可以用于分析来自大多数常见操作系统的内存映像文件,包括从 Windows XP 到 Windows Server 2016 的 Windows 系统、macOS 以及常见的 Linux 发行版。
Volatility 提供了一系列插件,且正在开发更多插件。为了检查系统内存,我们将检查几个插件,确保你拥有足够的信息进行正确的分析。不过,在使用 Volatility 之前,建议确保你的软件是最新的,并且已探索任何新插件,以判断它们是否适用于当前的事件调查。
Volatility 版本
Volatility 当前是版本 3,但版本 2 仍然在使用,尤其是对于那些可能仍需分析来自 Windows XP 或 Server 2003 系统的内存镜像的分析人员。两者之间的主要区别在于,版本 3 不再要求分析人员为 Volatility 设置系统配置文件,以便正确解析内存镜像。此外,插件的语法也发生了变化。Ashley Pearson 的 Volatility 备忘单博客,地址为 blog.onfvp.com/post/volatility-cheatsheet/,展示了这两者的差异。
安装 Volatility
Volatility 可用于 Linux、Windows 和 macOS。在 www.volatilityfoundation.org/releases 网站上可以找到关于如何在不同操作系统上安装它的信息。本章中,Volatility 被安装在 Windows 10 操作系统下的 Linux Ubuntu 子系统上。以下命令将在 Ubuntu 子系统及其他 Linux 操作系统上安装 Volatility:
forensics@ubuntu:~$ git clone https://github.com/volatilityfoundation/volatility3.git
这将生成以下输出:
图 10.1 – 安装 Volatility
运行 ls 命令显示了 Volatility 框架中各种脚本和文件:
图 10.2 – 验证 Volatility 安装
你可以通过运行以下命令来访问 Volatility 的帮助菜单:
图 10.3 – Volatility 帮助菜单
Volatility 命令
Volatility 使用简单的命令结构。当使用 Python 文件时,像我们这里一样,使用 Python 3 然后是 Volatility Python 文件。接下来,指明文件路径,最后是插件。附加参数取决于插件;你将在我们接下来讨论的几个插件中看到这一点。命令行应该如下所示:
forensics@ubuntu:~/volatility3$ python3 vol.py -f <Memory Image File> <operatingsystem.plugin>
让我们继续介绍一些可以在 Volatility 中使用的插件。
Volatility 图像信息
首先,我们将通过获取一些关于内存镜像及其来源系统的初步信息开始。即使分析人员确定了操作系统,运行内存镜像并使用 Volatility 的 windows.info 插件仍然是一种良好的实践。该插件的输出会识别出内存镜像的潜在配置文件,这对于使用其他插件至关重要。一般来说,Volatility 的语法由内存镜像的路径和特定插件组成。在这种情况下,使用以下命令:
forensics@ubuntu:~/volatility3$ python3 vol.py -f /home/forensics/EvidenceFiles/MemoryImages/cridex.vmem windows.info
这将生成以下结果:
图 10.4 – windows.info 插件
在这种情况下,NTBuildLab 字段表明该内存镜像来自 Windows XP 计算机。接下来,让我们开始分析 Windows 进程信息。
Volatility 进程分析
根据 SANS 六步法,首先讨论的是那些提供有关系统在内存捕获时运行进程数据的插件。目标是识别那些看起来可疑的进程,并识别与其相关的任何数据。
进程列表
第一个插件是windows.pslist插件。这个插件列出了当前在内存中运行的进程。它输出偏移量、进程名称、PID、线程和句柄的数量,以及进程启动和退出的日期和时间。由于pslist插件遍历的是由PsActiveProcessHead指示的双向链表,因此无法检测到隐藏或未链接的进程。要执行此插件,可以在命令提示符中输入以下内容:
forensics@ubuntu:~/volatility3$ python3 vol.py -f /home/forensics/EvidenceFiles/MemoryImages/cridex.vmem windows.pslist
这将产生以下输出:
图 10.5 – 进程列表
对输出的初步分析确实显示了一个可疑的条目。根据粗略检查,执行了一个名为reader_sl.exe的文件。这个怀疑主要基于非标准的文件名,但随着我们进一步深入分析,我们将获得更多关于这个文件的上下文和洞察。
进程扫描
windows.psscan插件允许分析员检查已终止的进程。正如我们之前所讨论的,pslist仅显示活动进程。psscan可以提供关于是否存在根套件的可能性,特别是在检查那些已经被取消链接或隐藏的进程时。执行以下命令可以启动插件:
forensics@ubuntu:~/volatility3$ python3 vol.py -f /home/forensics/EvidenceFiles/MemoryImages/cridex.vmem windows.psscan
这个命令将产生以下输出:
图 10.6 – 进程扫描
从这个插件的输出来看,似乎没有额外的进程已退出。响应人员可以开始查看现有进程,找出可能看起来是恶意的进程。
进程树
通常,响应人员需要查看子进程是在哪些父进程下执行的。系统被入侵的一个标志是识别出一个在正常父进程之外执行的进程。windows.pstree插件为检查人员提供了一个树状结构,能够识别执行潜在可疑进程的父进程。使用以下命令,可以在运行 Cridex 映像时启用这个插件:
forensics@ubuntu:~/volatility3$ python3 vol.py -f /home/forensics/EvidenceFiles/MemoryImages/cridex.vmem windows.pstree
这个命令将产生以下输出:
图 10.7 – 进程树
对这三个插件结果的分析显示了一个有趣的条目。PID 1640 与reader_sl.exe可执行文件相关联。响应人员可以集中关注这个进程,因为它可能看起来不像是应该运行的应用程序。此外,父 PID 显示它是通过 Windows 资源管理器运行的:
图 10.8 – 可疑进程
在此,响应者可以用额外的数据补充现有的进程数据,例如加载了哪些 DLL 和其他辅助数据。
DLL 列表
响应者还可以检查与进程相关的加载 DLL 文件。这允许分析员确定可疑进程在执行时是否访问了这些文件。例如,如果响应者想检查作为可疑进程一部分加载的 DLL 文件(PID 1640),可以运行以下命令:
forensics@ubuntu:~/volatility3$ python3 vol.py -f /home/forensics/EvidenceFiles/MemoryImages/cridex.vmem windows.dlllist --pid 1640
该命令生成以下输出:
图 10.9 – 关联的 DLL 文件
从这里开始,分析员可能通过分析加载的各种 DLL 文件来确定进程的一些功能。稍后在本章中,将获取这些 DLL 文件以供进一步检查。
windows.handles 插件
windows.handles插件允许分析员查看现有进程中打开的句柄类型。这些句柄是操作系统管理的资源的引用。该数据为响应者提供了应用程序或进程使用的特定内存块的理解。此数据包括广泛的信息,例如与该进程相关的注册表键和文件。要识别先前确定的 PID 1640 的打开句柄,可以使用以下命令:
forensics@ubuntu:~/volatility3$ python3 vol.py -f /home/forensics/EvidenceFiles/MemoryImages/cridex.vmem windows.handles --pid 1640
该命令生成以下输出:
图 10.10 – 句柄输出
如输出所示,嫌疑进程有多个打开的句柄进程、线程和注册表键。这些可能成为未来重要的数据点,并提供一些关于reader_sl.exe可执行文件行为的线索。
LDR 模块
恶意软件编写者常用的一种做法是尝试隐藏恶意软件的活动。一种技术是试图隐藏与恶意代码相关的 DLL 文件。这可以通过将可疑的 DLL 从 windows.ldrmodules 插件中取消链接来实现,该插件会比较进程列表并确定它们是否存在于 PEB 中。以下命令在 Cridex 镜像文件上运行 windows.ldrmodules:
forensics@ubuntu:~/volatility3$ python3 vol.py -f /home/forensics/EvidenceFiles/MemoryImages/cridex.vmem windows.ldrmodules –pid 1640
这将生成以下输出:
图 10.11 – LDR 模块输出
审查输出时,顶部行显示了一个有趣的条目。从该输出中,reader_sl.exe文件需要进一步调查。
Malfind
对手使用各种代码注入技术来运行恶意软件。Volatility 的windows.malfind插件显示可能包含注入代码的内存范围。运行以下命令:
forensics@ubuntu:~/volatility3$ python3 vol.py -f /home/forensics/EvidenceFiles/MemoryImages/cridex.vmem windows.malfind
这将生成以下简化的输出:
图 10.12 – Malfind 输出
在此屏幕截图中,两个进程 explorer.exe 和 reader_sl.exe 被标识为可执行文件,因为两个文件都有 MZ 头。malfind 插件不会自动标识这些进程是恶意软件,但表示应该进行进一步的分析。在这种情况下,我们将查看如何从内存中提取与 reader_sl.exe 相关的代码,并提取相关的 DLL 文件。
Dumpfiles
现在我们已经识别出疑似文件 reader_sl.exe,接下来使用 windows.dumpfiles 插件。在这种情况下,插件需要一个输出文件。在这里,我们将输出 /home/forensics/EvidenceFiles/PID1640Dump 目录。最后,使用进程 ID 1640 而不是文件名。整体命令如下所示:
forensics@ubuntu:~/volatility3$ python3 vol.py -f /home/forensics/EvidenceFiles/MemoryImages/cridex.vmem -o /home/forensics/EvidenceFiles/PID1640Dump/ windows.dumpfiles --pid 1640
该命令输出以下内容:
图 10.13 – Dumpfiles 输出
在这种情况下,reader_sl.exe 可执行文件有 .dat 和 .img 文件,以及相应的 DLL 文件。通过使用十六进制编辑器查看 reader_sl.exe 图像文件,我们可以看到头信息:
图 10.14 – reader_sl.exe 的十六进制视图
接下来,获取文件的 MD5 哈希值可以让我们在 VirusTotal 上搜索文件的任何信息。可以通过运行以下命令来获取哈希值:
forensics@ubuntu:~/EvidenceFiles/PID1640Dump$ md5sum file.0x821ccf90.0x82137c08.ImageSectionObject.reader_sl.exe.img
这将输出 2a63509ad62eeeed0564dcb0981d90e1 哈希值。通过 VirusTotal 检查,得到以下输出:
图 10.15 – VirusTotal 结果
尽管仅有反病毒公司指出文件哈希值是恶意的可能看起来有些奇怪,但这确实提出了一个要点:Volatility 只会输出内存中包含的代码,而不是整个文件。在提取代码时,必须牢记这一点。即使反病毒提供商指出它不是恶意的,与该代码关联的文件可能仍然是恶意的。根据调查情况,提取的数据必须经过更详细的恶意软件分析。
Volatility 工作台
使用 Volatility 的一个方面是使用命令行。使用命令行运行 Volatility 的主要优势是能够创建自动化命令的脚本并将输出保存为文本文件。对于不习惯使用 Volatility 和命令行的分析人员来说,缺点是他们可能需要不断参考命令或与正确的语法作斗争。
对于希望使用图形界面版本的 Volatility 的分析师,可以选择 PassMark Software 的 Volatility Workbench。该工具可以从 www.osforensics.com/tools/volatility-workbench.html 下载并安装在 Windows 平台上。安装后,图形界面允许分析师导航到映像文件并设置windows.pslist插件,以便对 Windows 内存捕获进行分析:
图 10.16 – Volatility Workbench
该工具还具有其他功能,例如记录所有命令和输出,并能够将它们复制到剪贴板,以便将输出包括在事件报告中。如前所述,这是一个非常适合那些不需要命令行额外功能和灵活性的分析师的可靠选项。
接下来,我们将介绍如何使用简单的 Strings 工具和 GREP 来增强内存分析。
使用 Strings 进行内存分析
在上一节中,我们查看的 Volatility 工具集中于内存映像中已映射的区域。如果数据未正确映射,这些工具将无法提取数据并正确显示。这是这些内存分析工具的一个缺点。很多数据会变得无结构,并且对这些工具不可见。这可能发生在网络连接被关闭或进程退出时。即使这些数据在通过 Volatility 检查 RAM 时无法显示,痕迹证据仍然可能存在。其他证据,例如页面文件,也包含未映射且可以搜索的证据。
一个有用的工具,用于提取这些痕迹的是字符串(Strings)命令,它在许多 Linux 和 Windows 操作系统中都可用。Strings 允许响应者搜索可读的字符字符串。给定一组关键字或全局正则表达式打印(GREP)命令,响应者可能能够提取更多的相关数据,即使是来自可能由于恶意软件或不当采集而损坏的 RAM 捕获。
安装 Strings
Strings 经常会在许多 Linux 发行版中预装。Windows 提供了一个独立的可执行文件,用于字符串搜索,地址为 docs.microsoft.com/en-us/sysinternals/downloads/strings。如果 Strings 在响应者选择的 Linux 平台上未安装,可以使用以下命令进行安装:
forensics@ubuntu:~$ sudo apt install binutils
对于一个相当简单的工具,Strings 是一种强大的方法,可以在大量数据中搜索特定的基于关键字的字符串。在本书中,重点将放在使用以下 Strings 语法提取特定数据点:
forensics@ubuntu:~$ strings <file name> | grep <Regular Expression>
常见的 Strings 搜索
网络痕迹,如 IP 地址和域名,通常可以在页面文件或内存中找到。要查找 IP 地址,请使用 strings 命令,并添加以下参数:
forensics@ubuntu:~$ strings pagefile.sys | grep -oE "\b([0-9]{1,3}\.){3}[0-9]{1,3}\b"
要查找 URI 和 URL,请分别使用http或https:
forensics@ubuntu:~$ strings pagefile.sys | grep "^https?://" | sort | uniq | less
也可能会发现电子邮件地址的残留痕迹。这在调查可能的网络钓鱼攻击时非常有用。要查找电子邮件地址,请使用以下命令:
forensics@ubuntu:~$ strings pagefile.sys | egrep '([[:alnum:]_.-]{1,64}+@[[:alnum:]_.-]{2,255}+?\.[[:alpha:].]{2,4})'
搜索词和参数的种类繁多,本章无法覆盖所有内容。主要的收获是,分析师可以通过内存镜像和交换文件进行字符串搜索,作为整体内存分析的一部分。
小结
本章讨论了内存分析的两个主要主题。首先,我们介绍了可用的数据点和可以遵循的方法论。此外,还探讨了多个工具,如 Volatility、Volatility Workbench 和 Strings。除了对这些工具的概述外,还探讨了它们的一些功能。这仅仅是每个工具为事件响应分析师提供的功能的冰山一角。这些工具结合系统 RAM 分析方法论,可以为分析师提供强大的工具,以确定系统是否已被攻破。随着恶意软件变得更加先进,包括完全在 RAM 中执行的恶意软件,分析师必须将内存分析纳入其能力范围。将这些技术与网络证据收集相结合,可以为分析师及其组织提供强大的工具,帮助识别和修复安全事件。
在下一章中,我们将深入探讨系统的永久存储检查。
问题
请回答以下问题以测试您对本章内容的掌握情况:
-
通过内存分析可以找到哪些数据点?
-
正在运行的进程
-
网络连接
-
命令历史
-
上述所有内容
-
-
什么不属于网络连接方法的一部分?
-
进程名称
-
父进程 ID
-
检查是否有 Rootkit 迹象
-
相关实体
-
-
转储与进程相关的文件永远不会将恶意软件引入响应者的系统。
-
正确
-
错误
-
-
内存分析的主要目标之一是获取恶意进程或可执行文件以便进一步分析。
-
正确
-
错误
-
进一步阅读
要了解本章涉及的主题,参见以下内容:
-
SANS 内存取证备忘单:
digital-forensics.sans.org/blog/2017/12/11/updated-memory-forensics-cheat-sheet -
内存取证的艺术:
www.memoryanalysis.net/amf
第十一章:分析系统存储
迄今为止,已分析的证据主要集中在网络流量或系统内存中获得的元素。尽管通过这些证据来源可能会揭示事件的根本原因,但理解如何从系统存储中获取证据材料仍然很重要,无论是从可移动存储设备如 USB 设备,还是从更大的连接磁盘驱动器。这些存储容器携带着大量的数据,事件响应分析师可以利用这些数据来确定根本原因。需要注意的是,本章只能粗略介绍这一主题,因为已有整本书籍专门探讨存储中可用的法医证据的深度。
为了更好地理解系统存储分析,本章将重点介绍以下主题:
-
法医平台:我们可以使用各种商业和开源平台进行系统存储分析。本节将介绍我们可以使用的关键特性和潜在选项。
-
Autopsy:为了提供一个可以在系统存储分析中利用的开源平台,本章的大部分内容将使用 Autopsy 工具。通过利用测试镜像,我们将突出其一些功能。
-
主文件表(MFT)分析:主文件表包含系统中所有文件的完整列表,是响应人员的关键数据来源。本节将介绍如何提取和分析 MFT。
-
预取分析:确定一个潜在恶意文件是否被执行是事件调查中的关键环节。本节将介绍如何提取 Windows 预取文件、处理并进行分析。
-
注册表分析:注册表是恶意软件编写者和其他攻击者的常见目标,响应人员应熟悉注册表分析。本节将概述如何提取和分析注册表。
系统存储分析是一个复杂的过程。其深度和广度无法在一个章节中全面探讨;因此,我们希望本章能提供一些具体的关注领域,帮助响应人员更好地理解一些可以使用的工具,以及了解一些关键数据的作用。
法医平台
在过去 15 年中,磁盘法医平台的能力得到了增强。对于事件响应分析师来说,可以选择不同类型的平台来检查磁盘驱动器。通常,使用这些平台的限制因素是更强大系统的成本,而低成本的替代方案对于事件响应团队来说也能同样有效。
在进行磁盘分析时,应该考虑几个因素。首先,平台是否经过测试?一些组织会测试平台的有效性,比如国家标准与技术研究院计算机法医工具测试项目(www.cftt.nist.gov/)。其次,必须审查该工具在刑事和民事诉讼中的使用情况。虽然没有统一的法院公认标准,但工具应遵循证据规则。使用未经测试或不符合证据规则的平台,可能导致证据在法律程序中被排除。在其他更严重的后果中,可能导致分析人员得出错误结论。
法医工具的可靠性
一个未经测试且法医上不可靠的工具集的例子出现在康涅狄格州诉 Amero 一案中。在这个案件中,一家执法机构使用了不可靠的法医方法和工具,将一名女性定罪,指控她允许儿童看到色情的弹出广告。对此案件方法和事实的后续审查表明,法医检查存在严重缺陷。对此案件的详细审查也可以通过《数字法医、安全与法律期刊》访问,链接为:commons.erau.edu/jdfsl/vol7/iss2/5/。
最后一个考虑因素是工具如何融入整体的事件响应规划。例如,商业磁盘法医工具在定位图像和网页证据方面非常出色。它们也非常擅长从嫌疑人的硬盘中提取数据。这通常是因为法医软件被执法机构用作调查儿童剥削犯罪的工具。因此,这一能力对对付此类嫌疑人的刑事案件至关重要。虽然这些功能非常优秀,但事件响应人员可能更关注能够用于关键词搜索和时间线分析的工具,以便重建事件发生前、发生中和发生后的系列事件。
虽然大多数商业和免费法医平台都具有多种功能,但有几个常见功能对事件响应人员非常有用:
-
文件结构视图:通常,能够查看正在检查的磁盘的文件结构非常重要。法医平台应该具备查看文件结构的能力,并允许响应人员快速查看嫌疑系统中已知位置的文件。
-
十六进制查看器:能够以十六进制查看文件使得响应人员能够更细致地审视正在检查的文件。在涉及恶意软件或其他定制化攻击的案件中,这可能会非常有帮助。
-
网页痕迹:由于大多数数据都存储在与网页搜索相关的磁盘上,法医平台应具备检查这些数据片段的能力。这在检查社会工程攻击时非常有用,尤其是在用户访问恶意网站时。
-
电子邮件提取:事件响应人员可能会被召集到涉及恶意员工参与非法活动或违反政策的案件中。通常,这类行为的证据存在于嫌疑系统的电子邮件中。拥有一个能够提取这些数据并立即查看的平台,有助于分析人员查看嫌疑系统与其他系统之间的通信。
-
图像查看器:通常,需要查看系统中保存的图像。如我们之前提到的,执法部门可能会利用此功能判断系统中是否存在儿童性虐待的证据。事件响应人员可以利用这些功能判断是否存在政策违规行为。
-
元数据:关于文件的关键数据,如创建日期和时间、文件哈希值以及嫌疑文件在磁盘上的位置,对于检查与事件相关的系统非常有用。例如,结合恶意软件分析,某个应用程序运行的时间与网络活动相结合,可以帮助分析人员确定实际执行的可执行文件。
在商业选择方面,以下三个平台被普遍认为是可靠的,并被世界各地的商业和政府机构使用。每个平台都采用了我们之前描述的功能,以及其他一些更专业的工具:
-
OpenText EnCase:EnCase 无疑是最著名的法医平台,具有长期历史,常用于重大刑事调查中,例如 BTK 杀手案件。EnCase 是一个功能丰富的平台,在训练有素的分析人员手中,它是一个强大的工具。除了磁盘取证,EnCase 还集成了针对移动设备的功能。这对于可能需要分析不仅是磁盘,而且是与事件相关的移动设备的组织来说,是一个强大的能力。
-
AccessData 法医工具包:在第六章中,FTK Imager 工具被用来获取磁盘和内存证据。这个工具是 AccessData 提供的一系列专门为磁盘取证设计的工具的一部分。除了 Imager 工具,AccessData 还提供一个功能齐全的法医平台,允许响应人员执行与事件相关的一系列任务。FTK 被联邦调查局(FBI)等执法机构使用,并且在协助响应人员进行事件调查方面已证明非常有效。
-
X-Ways Forensics:FTK 和 EnCase 的一个缺点是价格昂贵。这些平台每年可能需要数千美元。对于大型组织,如政府机构和大企业,成本与功能的权衡可能不是问题。但对于小型组织来说,这些平台可能会因成本过高而无法使用。一个功能丰富的法医平台替代方案是 X-Ways。这个平台可以执行各种任务,但成本仅为商业平台的一小部分。X-Ways 的另一个好处是它对资源的需求较低,可以通过 USB 设备运行,这使它成为一个理想的替代平台,尤其适用于事件响应。
这些平台中的每一个都具有丰富的功能集,并为响应者提供了强大的工具,用于执行各种法医任务。这些平台中的具体工具超出了本书的范围。因此,建议响应者接受这些平台的使用培训,以确保他们充分了解这些工具的功能。
Autopsy
另一个商业法医程序的替代方案是 Autopsy。Autopsy 是一个基于图形用户界面(GUI)的法医平台,基于开源工具集 The Sleuth Kit。这个开源平台提供了商业平台中常见的功能,包括时间线分析、关键字搜索、网页和电子邮件文物,以及根据已知不良文件哈希值过滤结果的能力。其主要特点之一是易于使用。这使得事件响应者能够拥有一个轻量级平台,专注于关键任务并获取所需的关键证据。
安装 Autopsy
我们之前讨论过的几种 Linux 发行版已经预装了 Autopsy。响应者应确保他们使用的平台是最新的,这是一项良好的实践。对于 Windows 操作系统,可以下载位于www.sleuthkit.org/autopsy/download.php的 Microsoft 自安装程序文件。下载后,执行 MSI 文件并选择安装位置。完成后,应用程序就可以开始使用了。
开始一个案件
一旦安装了 Autopsy,分析员可以在几乎不需要预先配置的情况下打开案件。以下步骤将介绍如何打开一个新案件的过程:
- 在开始分析之前,确保整个磁盘映像文件位于一个单独的目录中。这将使整个映像在分析过程中都能被使用:
图 11.1 – E01 文件
在上面的截图中,已经从一个嫌疑系统中获取了一个映像文件。该映像已被分割成两个独立的文件。回顾第八章,像 FTK Imager 这样的成像应用程序会将映像分割成多个文件。只要这些分割后的文件位于同一目录中,Autopsy 就能够将这两个文件合并并重建整个成像的卷。
示例映像文件
对于我们的 Autopsy 检查,可以在 cfreds.nist.gov/all/MagnetForensics/2022WindowsMagnetCTF 找到一个来自 Windows 10 系统的示例镜像文件。为了更多的练习,可以从位于 www.cfreds.nist.gov/ 的计算机取证参考数据集下载额外的测试镜像。
- 打开 Autopsy,以下窗口将出现;选择 New Case:
图 11.2 – Autopsy – 创建新案件
- 将会出现第二个窗口,分析师将在其中输入案件标题。此外,还可以设置存储与案件相关文件的 Autopsy 路径。这在某些情况下非常有用,例如当分析师必须将文件放置在特定容器中时,包括外部硬盘。完成后,点击 Next:
图 11.3 – Autopsy – 新案件信息
- 在下一个窗口中,响应者应输入案件编号、姓名、联系方式以及案件的简要描述,填写在 Notes 中。点击 Finish:
图 11.4 – 新案件信息 – 可选信息
添加证据
可以将案件视为一个容器,包含与事件相关的所有案件数据和证据。Autopsy 还允许分析师添加多个数据源,例如磁盘镜像和虚拟机磁盘。在此阶段,我们将加载 E01 文件作为数据源:
- 输入案件详细信息后,分析师需要加载之前创建的镜像文件。点击 Autopsy 窗口左上角的 Add Data Source 按钮:
图 11.5 – 添加数据源 – 选择主机
Autopsy 可以自动检测主机名。如果分析师知道主机名,可以在 Specific new host name 字段中添加。根据最佳实践,如果已知,应始终输入主机名。完成后,点击 Next。
- 选择适当的数据源类型。在这种情况下,检查将针对一个法医获取的图像文件进行。Autopsy 也可以检查
.vmdk文件。这在虚拟化环境中非常方便,因为可以对虚拟机文件进行检查,而无需通过 FTK Imager 等工具获取它:
图 11.6 – 添加数据源 – 选择数据源类型
- 选择数据源类型后,浏览到图像所在位置。该文件夹包含多个图像文件;选择以
E01结尾的文件。加载此文件后,将包括该文件夹中所有随后的图像文件。接下来,选择适当的时区。作为最佳实践,分析师应选择在整个调查过程中统一的时区。在这种情况下,最佳选择是选择 UTC。完成后,点击下一步:
图 11.7 – 选择 E01 文件
- 下一屏幕允许分析师定制正在使用的模块。根据调查的类型,其中一些选项可以取消勾选。然而,刚开始时,分析师应选择所有选项,以确保所有必要的信息都能进行检查。
另一个选项是处理未分配空间(这非常重要!)。这将捕捉硬盘上当前未分配给数据的所有信息。有些方法可以利用未分配空间来隐藏信息。完成后,点击下一步:
图 11.8 – 添加数据源 – 配置数据导入
这将开始处理过程:
图 11.9 – 数据源处理
- 在下一屏幕上,确认数据源已加载,然后点击完成。这将开始将 E01 文件作为数据源添加的过程:
图 11.10 – 数据源完成
Autopsy 现在将开始分析来自图像的文件。根据图像的大小,这个过程可能需要几分钟到几个小时不等。屏幕右下角的进度条会显示处理进度。这个过程的时间通常取决于计算机的处理速度以及图像文件的大小。此时,即使额外的处理仍在进行,Autopsy 也会开始填充左侧面板中的特定字段。GUI 的右下角将显示处理的进度:
图 11.11 – 证据源处理
如前所述,处理可能需要一些时间,具体取决于取证系统的规格和文件的大小。分析师可以在了解可能并非所有数据都可用的情况下进行一些分析。
浏览 Autopsy
Autopsy GUI 分为三个主要部分。这些部分显示与系统和特定文件相关的详细信息。当 Autopsy 完成处理新案件或打开现有案件时,分析师将看到以下窗口:
图 11.12 – Autopsy GUI
如前所示,Autopsy 分为三个主要窗格。其中第一个是左侧窗格,它包含数据源、文件结构以及搜索结果。点击加号(Program Files目录,位于系统上):
图 11.13 – Autopsy 的中央窗格
最后,底部窗格包含有关中央窗格中单个文件的元数据和其他信息。在这个例子中,选择了desktop.ini文件。点击文件元数据标签,显示该文件的特定信息:
图 11.14 – 文件元数据
最后,通过点击十六进制标签,可以查看文件的十六进制内容:
图 11.15 – 十六进制视图
如果分析员希望检查一个应用程序或其他疑似恶意软件的文件,这个视图非常适合。
Autopsy 提供了一些可以在其他商业平台上找到的操作和分析功能。然而,需要注意的是,在更复杂的调查中,可能需要使用更先进的平台。Autopsy 还为新手提供了一个更易于使用的平台,使他们可以在使用更先进的商业解决方案之前,先积累一些磁盘取证的经验。
审查案件
一旦案件处理完成,左侧窗格将显示系统中找到的工件数量:
图 11.16 – Autopsy 的工件窗格
在前面的截图中,数据工件部分列出了几个项目。这些项目包括查看已安装的程序、操作系统信息以及最近的文档。Autopsy 的另一个关键功能是能够检查镜像文件的整个文件夹结构。点击数据源旁边的加号(+)可以展开整个文件夹结构。如果分析员通过其他来源确定了嫌疑文件的位置,这一点非常有用:
图 11.17 – 数据源
通过使用 Autopsy,可以检查不同的数据点。具体搜索什么内容以及如何搜索,通常由调查中的事件类型或检查内容来决定。例如,源自被攻陷网站的恶意软件感染可能涉及检查系统中用户可能输入或通过浏览器访问的 URL。此外,还可以通过检查系统内存来获取信息,进而找到实际的文件,我们在上一章中有提到这一点。例如,如果分析员能够定位到一个可疑进程,并且随后能够找到可执行文件,他们可以使用 Autopsy 查找该可执行文件最后一次被启动的时间。这样可以为响应人员提供一个时间点,以便他们检查其他系统是否存在被攻陷的证据。
在另一种情况下,响应人员可能需要确定员工是否访问了机密文件,以便将其传递给竞争对手。这可能涉及检查系统中访问文件的时间和日期、可能使用的电子邮件地址、访问过的外部云存储站点或连接到系统的 USB 存储设备。最后,所有这些文件的完整列表可能为移出的机密文件提供一些线索。
Web 工件
在某些情况下,可能需要检查系统是否存在用户进行的恶意活动证据。之前,我们提到过访问基于云的存储,在那里一个恶意内部人员上传了机密文件。在其他情况下,社交工程攻击可能使一个毫无防备的员工访问一个被攻陷的网站,随后下载恶意软件。在这两种情况下,Autopsy 为我们提供了检查多个网页工件区域的能力。
这些网页工件中的第一个是Web 历史。如果发生涉及用户访问恶意软件交付网站的社交工程攻击,这些数据可能为访问的特定 URL 提供一些线索。然后,可以提取该 URL 并与来自内部或外部来源的已知恶意网站列表进行比较。在其他情况下,如果内部人员访问了外部云存储网站,Web 历史记录可能提供这一活动的证据。让我们详细看一下这个案例:
- 点击左侧窗格中的Web 历史部分将打开中间窗格,并显示系统访问过的 URL 的详细信息:
图 11.18 – Web 历史
- 在前面的截图中,Autopsy 显示该系统访问了网站 hacker-simulator.com。Autopsy 提供的进一步信息使分析人员能够评估其他信息,如工件的位置和使用的浏览器类型。通过数据工件选项卡,可以在下方的结果面板中访问这些信息:
图 11.19 – 网络历史元数据
- 调查中另一个有用的数据来源是数据工件部分中的网络下载。威胁行为者常用的一种技术是引导用户或脚本下载二次利用或恶意软件。这可能包括黑客工具和其他脚本,通常利用系统从网站下载的功能。在这种情况下,如果点击网络下载,我们可以看到下载文件的路径,以及文件来源的网址:
图 11.20 – 网络下载
- 此外,Autopsy 还提供了正在检查的特定下载文件的元数据。点击文件元数据选项卡后,会显示以下数据:
图 11.21 – 网络下载元数据
如前面的截图所示,有一些关于已下载文件的更多细节。例如,分析人员可以收集时间信息、文件位置和 MD5 哈希值,这些信息可用于比较进一步检查的任何提取文件。在某些情况下,嫌疑人可能决定从系统中删除浏览历史以隐藏任何恶意活动。另一个可能提供恶意内部人员访问网站证据的位置是网络 Cookie。这些可以通过左侧面板中的网络 Cookie访问。点击该选项后,会显示仍然保留在系统中的 Cookie 列表:
图 11.22 – 网络 Cookie
根据事件的类型,网络工件可能会发挥重要作用。Autopsy 对此提供了一些功能,但应急响应人员可能会发现其他商业解决方案提供了更为强大的平台。Magnet Forensics 提供的 Evidence Finder (www.magnetforensics.com) 会扫描整个系统的网络工件,并以易于分析人员查看的方式展示这些数据。此类商业解决方案的另一个主要优势是其功能不断更新。根据互联网和网络工件搜索的频率,使用此类工具可能会带来益处。
电子邮件
定位可疑电子邮件继续是事件响应者经常进行的任务。这可能包括外部引起的事件,如社会工程,响应者可能被要求定位带有恶意软件的可疑电子邮件。在其他情况下,恶意内部人员可能已发送或接收到违反公司政策或不当通信。在这些情况下,响应者可能被要求恢复这些电子邮件,以便包括在解雇程序或法律行动中。
Autopsy 可以定位系统中包含的电子邮件。通过这些电子邮件,他们可能能够识别一个或多个可疑的电子邮件和域,进一步研究是否与社会工程或其他恶意活动相关。只需单击关键字命中,然后单击左侧窗格中的电子邮件地址选项卡。从那里,分析师可以看到系统中的电子邮件地址:
图 11.23 – 电子邮件地址
接下来,让我们看一下已连接的设备。
已连接的设备
对分析师有用的另一个关键证据是关于特定设备何时连接到系统的数据。在恶意内部人员试图窃取机密文件的情况下,了解他们是否使用了 USB 设备将会很有帮助。Autopsy 利用系统上的注册表设置来识别连接的设备类型及其最后使用时间。在这种情况下,单击左侧窗格中的连接的设备将产生以下结果:
图 11.24 – USB 设备
进入数据工件选项卡后,分析师可以识别设备类型以及 USB 设备连接的日期和时间:
图 11.25 – USB 设备工件
最后,对源文件元数据区域进行更详细的检查将显示可用于重建系统上访问 USB 设备的时间的其他数据:
图 11.26 – 设备条目元数据
接下来,让我们看一下已删除的文件。
已删除的文件
已删除的文件也可以部分或完全重建。当用户选择删除时,Windows 操作系统不会删除文件。操作系统将标记删除文件在主文件表(MTF)中占用的空间为可用于写入新文件。因此,响应者可能能够查看未被覆盖的已删除文件。
固态驱动器
如在第八章中讨论的,记住法医分析员在检查固态硬盘(SSD)时面临的挑战。传统的硬盘驱动器即使在系统关闭后,仍然可以恢复已删除的文件。而在 SSD 上,操作系统通常会删除已删除的文件,以提高文件存储效率。如果您想了解更多信息,可以访问以下网站,它提供了关于这一点的详细分析:www.datanarro.com/the-impact-of-ssds-on-digital- forensics/。
要查看系统中的已删除文件,点击左侧面板中的已删除文件。在这里,分析员可以看到所有已标记为删除的文件:
图 11.27 – 已删除文件
从这里,分析员可以搜索已删除的文件。这些文件可能具有证据价值。例如,在恶意内部人员活动的案例中,如果在已删除的文件中发现多个敏感文件,并且这些文件都在相同的时间内被删除,这可能表明内部人员试图通过删除可疑文件来掩盖其痕迹。
关键字搜索
法医应用程序的一大优势是能够执行关键字搜索。随着磁盘驱动器容量的增大,响应者需要处理大量数据,这使得关键字搜索尤为重要。关键字通常来源于调查的其他元素或外部来源。例如,如果分析员正在调查恶意软件事件,他们可能会使用通过内存镜像分析得到的可疑 DLL 或可执行文件名称。在其他情况下,例如怀疑恶意内部人员访问了机密信息时,可以使用那些文档中的关键字(无论是秘密的还是机密的)来检查嫌疑人是否使用系统访问了这些文件。
Autopsy 可以执行关键字搜索,同时使用精确匹配或子字符串匹配。例如,假设分析员的任务是确定与 ZeroTier One 可执行文件有关的证据,该文件已在Web Downloads条目中找到。分析员的任务是定位任何可以表明该文件已被执行的痕迹证据,并尽可能识别用户。
分析员需要导航到右上角,在字段中输入ZeroTier One。在这种情况下,将使用精确匹配。一旦选择后,他们点击搜索按钮。左侧面板将指示该文本是否有命中结果。在这种情况下,定价决策有 82 次命中:
图 11.28 – 关键字搜索命中
如前面的截图所示,中央窗格将包含一个文件列表,这些文件包含了命中项。一个突出的文件是 主文件表 条目。该条目显示了文件首次放置在系统上的日期和时间,以及任何修改和更改:
图 11.29 – 主文件表条目
进一步审查显示了一个 Windows PowerShell 事件日志条目,表明该应用程序是由用户账户 Patrick 执行的,依据文件路径:
图 11.30 – 关键词搜索结果
深入查看命中项,Windows PowerShell 操作事件日志中有一个条目,表明该可执行文件与通过 PowerShell 脚本建立的网络连接相关联:
图 11.31 – 关键词 PowerShell 脚本
条目中进一步的内容是一个 Base64 编码的 PowerShell 脚本条目:
图 11.32 – Base64 PowerShell 脚本
综合来看,这可能指向一些可疑活动。例如,ZeroTier One 是一个商业 VPN 解决方案,因此它建立连接并不罕见。可疑的是 Base64 编码的 PowerShell 脚本,攻击者常用它下载额外的恶意软件或执行恶意操作。我们将在 第十六章 中详细了解一些这些脚本。
接下来,我们将看看 Autopsy 如何构建系统活动的时间线。
时间线分析
在调查事件时,了解应用程序或文件何时执行至关重要。时间戳有时可以在调查的其他方面找到,例如检查内存镜像时。此外,识别内存镜像中的特定 DLL 文件或可执行文件,可以与它们的访问日期和时间进行比较,以关联系统上观察到的其他活动。
时间归一化
数字取证中的一个方面需要重复强调的是,确保所有系统使用相同的时区。对于网络系统,这通常通过 网络时间协议 (NTP) 来实现。有时系统无法通过 NTP 实现时间归一化。响应人员应特别注意理解应该使用的时区和同步方式。关于时间的最佳实践是将所有系统设置为 UTC,特别是当一个组织具有地理多样性时,这一点至关重要。
Autopsy 提供了专门用于时间线分析的功能。只需点击窗口顶部的 时间线 按钮,Autopsy 就会开始解析时间线数据的过程。根据被分析镜像文件的大小,这可能需要几分钟。完成后,以下窗口将打开:
图 11.33 – 时间轴查看器
从这里,分析人员可以使用几个功能。首先是屏幕左侧的文本筛选器。使用此功能,分析人员可以搜索文件中的特定文本。例如,分析人员已经确定名为 ZeroTier One 的可执行文件已在正在调查的系统上执行。如果分析人员想知道该文件是否在其他时间被访问过,他们可以将“定价”输入到 文本筛选器 框中,然后点击 应用,这将产生以下结果:
图 11.34 – 关键字时间轴
从这个图表中,分析人员可以通过点击彩色条形图,进一步深入查看文件被访问的具体时间。响应人员现在可以看到,这个可执行文件仅在某个特定日期和时间从该系统中被访问过。
接下来,我们将了解如何从磁盘镜像中提取特定的证据项,并使用附加工具进行处理。
主文件表分析
另一种可以用于时间轴分析的技术是利用外部工具分析 MFT。Autopsy 允许分析人员导出 MFT 并使用第三方工具进行分析。在此案例中,我们将使用 MFT Explorer,这是 Eric Zimmerman 开发的多个工具之一。
Eric Zimmerman 的工具
Eric Zimmerman 是一位前 FBI 特工、SANS 课程开发者以及数字取证专家。他开发了一套用于数据提取和分析的工具,工具可在 ericzimmerman.github.io/#!index.md 获取。此外,SANS 机构还创建了一个关于这些工具的备忘单,链接地址为 www.sans.org/posters/eric-zimmerman-tools-cheat-sheet/。
在此情况下,我们将处理通过 Autopsy 检查的镜像中的 MFT。MFT 文件可以在文件系统的根目录中找到。找到 $MFT 文件,右键点击它,选择 提取文件,然后将文件保存到证据驱动器中。作为良好的实践,请将文件名更改为与案件相关的名称。
接下来,找到 MFTECmd.exe 可执行文件。以下命令处理 MFT,并将结果输出到 逗号分隔值 (CSV) 文件:
C:\Users\forensics\Documents\ZimmmermanTools>MFTECmd.exe -f "D:\Suspect_$MFT" --csv "D:" --csvf SuspectMFT.csv
现在可以打开并检查 CSV 文件。在这种情况下,CSV 文件已通过 Microsoft Excel 打开。这样可以进行关键字搜索,并检查文件的时间和日期,以识别文件或文件在系统上的放置时间。回到之前的关键字搜索,我们可以使用 Excel 中的筛选选项。ZeroTier 关键字已被输入:
图 11.35 – ZeroTier 筛选 MFT 结果
MFT 的工作处理可能会因为数据量的原因变得复杂。在这种情况下,MFT 有超过 410,000 个单独的条目,可能需要逐一排序。最好有一个起点,比如日期和时间,或者文件名进行搜索。这样可以让分析人员只处理相关的结果。其他工具,如 Eric Zimmerman 的 Timeline Explorer,也可以用于处理和提取对调查有重要意义的数据点。
现在我们已经查看了系统中文件的存在情况,接下来可以查看执行的证据。
Prefetch 分析
分析人员常常需要回答的一个问题是如何确定一个可执行文件是否运行过。回答这个问题的最佳数据来源之一是 Prefetch 文件。当一个应用程序或其他可执行文件被运行时,会创建一个文件并将其存储在C:\Windows\Prefetch目录中。如果程序在多个位置运行,则会为每个位置创建一个条目。Prefetch 文件的另一个关键特点是,当应用程序或程序被删除时,Prefetch 文件不会被删除。因此,如果攻击者试图清理系统中的恶意可执行文件或 DLL 文件,仍然可以在Prefetch目录中找到它们执行的证据。
Prefetch 文件确实存在一些需要理解的特性。首先,即使程序执行不成功,也可能产生 Prefetch 文件。需要注意的是,Prefetch目录专门限制为最多 1,024 个单独的文件。较旧的文件会被新文件覆盖。在大多数终端用户系统上,如果分析人员能够及时捕获证据,这通常不会造成问题。第三,之前执行过的程序仍然可以创建新的 Prefetch 文件。最后,Prefetch 文件存在时间延迟。一般来说,文件的创建时间可能比分析人员发现的其他时间戳晚 10 秒。
获取Prefetch目录非常简单。像在第六章中讨论的那样,分类工具可以收集该目录。也可以通过 Autopsy 直接提取该目录。只需导航到Prefetch目录,右键点击并选择提取文件。选择要输出文件的目录。最好将输出放在证据驱动器中,或使用 Autopsy 的默认导出目录。一旦提取,Prefetch 条目将如下所示:
图 11.36 – Prefetch 文件条目
然后可以使用以下命令通过 Prefetch 解析器处理该输出目录:
C:\Users\forensics\Documents\ZimmmermanTools>PECmd.exe -d D:\Suspect_Prefetch -q --csv D:\ --csvf suspect_prefetch.csv
上一个命令输出了两个文件。第一个是包含预取条目的 CSV 文件,第二个包含时间线分解。我们来看看时间线版本。CSV 文件的输出允许使用与上一节中相同类型的搜索和筛选,主文件表分析。在这种情况下,我们将使用ZeroTier进行筛选。此时,搜索显示了几个条目,显示了ZEROTIER_DESKTOP_UI.EXE可执行文件的执行:
图 11.37 – ZeroTier 预取条目
注册表分析
Windows 操作系统下有大量活动在后台进行。这些活动的一部分会在 Windows 注册表中进行记录。Windows 注册表是一个存储 Windows 操作系统低级系统设置的数据库。它包括设备、安全性、服务以及用户帐户安全设置存储在安全帐户管理器(SAM)中的信息。
注册表由两个元素组成。第一个是键。键是一个容器,存储第二个元素——值。这些值包含特定的设置信息。最高级别的键称为根键,Windows 操作系统有五个根键,这些根键都存储在磁盘上的注册表 Hive 中。这些注册表 Hive 位于 Windows 文件结构中的%SystemRoot%\system32\config文件夹下:
-
HKEY_CURRENT_USER -
HKEY_USERS -
HKEY_CLASSES_ROOT -
HKEY_LOCAL_MACHINE -
HKEY_CURRENT_CONFIG
在五个根键中,事件调查中最有价值的是HKEY_LOCAL_MACHINE或HKLM键。该键包含以下子键(这些子键在调查中最为关键):
-
SAM:这是 Windows 操作系统存储用户密码(以 LM 或 NTLM 哈希形式)的地方。SAM 子键的主要功能是维护 Windows 帐户密码。
-
Security:这个子键包含系统连接的域的安全信息。
-
Software:软件子键是软件和 Windows 设置的存储库。这个子键通常会被软件或系统安装程序修改。这是一个检查恶意软件可能添加或修改软件的好位置。
-
System:这个子键存储有关 Windows 系统配置的信息。系统子键中包含的一个重要证据是当前挂载的文件系统设备。
另一个可能对事件调查至关重要的数据源是HKEY_CURRENT_USER键。攻击者可能会在特权升级攻击中修改用户帐户或配置文件。对用户数据所做的更改会记录在该用户的NTUSER.dat文件中。每个系统用户帐户都会创建一个NTUSER.dat文件,该文件位于C:\Users\*UserName*。此文件包含用户的个人设置,并可能提供有关连接的系统、网络连接或其他设置的附加数据。HKEY_CURRENT_USER键中的数据可能在一些怀疑用户活动或用户帐户修改系统的事件中起到帮助作用。
响应人员可以使用 Autopsy 访问各种注册表数据。只需从左侧窗格中的文件结构中导航到Windows/System32/config文件夹:
图 11.38 – 注册表位置
SAM 注册表文件位于中间窗格:
图 11.39 – SAM 位置
注册表项设置的实际检查和证据价值,像数字取证的许多方面一样,非常详细。虽然在本章中,甚至在本书中,不可能涵盖所有的注册表取证方面,但响应人员需要能够获取注册表项进行评估,同时还需要对一些工具有所了解,这些工具可以帮助响应人员获得评估注册表设置的实践经验。
在这种情况下,系统、SAM、安全性和软件注册表项将被获取以进行分析。为此,分析人员可以使用 Autopsy 获取适当的注册表项,然后使用第三方工具对其进行检查。我们来看看如何操作:
-
首先,导航到系统映像的适当卷中的
/System32/config文件夹。 -
接下来,使用右键和Ctrl键选择四个注册表项。右键单击其中一个文件并选择导出文件。
-
选择一个文件夹以输出注册表项。在这种情况下,创建了一个单独的文件夹来容纳这些项。选择保存。
-
验证注册表项是否已保存:
图 11.40 – 可疑注册表
Windows 操作系统记录并维护有关何时连接 USB 设备(如大容量存储设备、iOS 设备、数码相机和其他 USB 设备)的信息。这是由于 Windows 操作系统中的即插即用(PnP)管理器。PnP 接收到 USB 连接的通知并查询设备以获取信息,以便加载正确的设备驱动程序。完成后,Windows 操作系统将在注册表设置中为该设备创建一条条目。
要确定连接了哪些 USB 设备,请执行以下步骤:
-
打开注册表浏览器。
-
点击文件,然后选择加载 Hive。
-
导航到系统注册表的 hive。(根据文件的不同,可能会出现与“脏 hive”相关的错误。看到这种情况是正常的,可以使用注册表浏览器进行处理。)
加载后,将显示以下窗口:
图 11.41 – 注册表浏览器视图
- 从这里,导航到正确的 USB 注册表位置:
ROOT\ControlSet001\Enum\USB\:
图 11.42 – USB 注册表键位置
- 点击第一个注册表值
VID_05C8&PID_0815&MI_00,然后点击6&a631fef&0&000。以下信息将显示在右上角窗格中:
图 11.43 – 注册表值
从这里,分析人员需要审查大量信息。特别重要的是硬件 ID。点击输出中的这一部分将会在右下角窗格中显示以下内容:
图 11.44 – HardwareID 数据
如前所述,注册表分析本身就是数字取证的一个深层子集。已经有大量的著作讨论注册表项和设置中的证据价值。至少,响应人员应该准备好为他人获取这些证据以供进一步检查。也就是说,随着响应人员经验和技能的不断提升,注册表应该成为在检查磁盘镜像时可以利用的证据来源。
总结
在许多方面,本章只是触及了通过利用磁盘取证工具可以发现的信息的表面。使用 Autopsy 工具探索磁盘镜像展示了响应人员可以使用的一些功能。从这里,提取其他数据存储,如 Windows 注册表和 MFT,旨在为响应人员提供在事件分析过程中可以获得的数据的概念。
特定工具和技术在很大程度上取决于所使用的工具。重要的是要理解,现代操作系统会在磁盘上留下活动痕迹,从 MFT 中的文件更改证据到新用户账户添加时的注册表键设置。事件响应人员应具备理解现代操作系统如何存储数据的专业知识,并且能够利用商业或免费工具查找这些数据。结合来自网络源和内存中的其他证据,磁盘证据可能为事件提供更多的清晰度,并帮助确定其根本原因。在系统存储分析时,提取和检查日志文件是一个重点。日志文件是重要的数据点,能为响应人员提供大量信息。
下一章将接着本章的工作,讨论如何在事件调查中利用日志文件。
问题
请回答以下问题以测试你对本章内容的理解:
-
商业和开源取证平台提供的一些功能是什么?
-
十六进制查看器
-
邮件提取
-
元数据查看器
-
上述所有
-
-
事件响应员可以在什么注册表项中找到已连接到系统的 USB 设备?
-
SAM
-
安全
-
系统
-
用户配置文件
-
-
网络历史记录可能提供系统访问的钓鱼网址的数据。
-
正确
-
错误
-
-
以下哪项不是 Windows 注册表项?
-
系统
-
SAM
-
存储
-
软件
-
进一步阅读
有关本章所涵盖主题的更多信息,请参考以下资源:
-
Autopsy GitHub:
github.com/sleuthkit/autopsy -
Eric Zimmerman 工具:
ericzimmerman.github.io/#!index.md -
Eric Zimmerman 工具备忘单:
www.sans.org/posters/eric-zimmerman-tools-cheat-sheet/ -
使用 FTK 注册表查看器进行注册表分析:
subscription.packtpub.com/book/networking_and_servers/9781784390495/6/ch06lvl1sec37/registry-analysis-with-ftkregistry-viewer -
Windows 注册表分析 101:
www.forensicfocus.com/articles/windows-registry-analysis-101/
第十二章:分析日志文件
第三章详细讨论了埃德蒙·洛卡尔博士及其交换原理。为了复习,洛卡尔交换原理的核心前提是,当两个物体接触时,它们会留下痕迹。在数字取证的世界中,我们讨论了响应者如何利用各种位置和技术,从内存、硬盘和网络流量中发现这些痕迹。一个可以提供大量数据并可供利用的位置是日志文件。广泛的硬件和软件都会记录操作。所需的是响应者理解如何获取这些日志,如何检查它们,以及它们详细记录了什么。在这样做时,他们可能能够找出事件的根本原因。
本章将重点讨论日志和日志管理,使用日志聚合工具,如安全信息与事件管理(SIEM)系统、Windows 事件日志,最后——分析 Windows 事件日志。希望通过讨论这些技术,响应者能够清晰地阐明日志在事件调查中的重要性,并能够将其作为更大范围事件调查的一部分进行分析。
本章将涵盖以下主题:
-
日志和日志管理
-
与 SIEM 配合工作
-
Windows 事件日志
-
分析 Windows 事件日志
日志和日志管理
一次良好的事件调查的核心是来自多种来源的证据。即使是主机系统上的恶意软件感染,也需要从多个来源获得证据。一项常见的挑战,尤其是在较小的网络中,是组织如何处理日志管理。为了进行全面的调查,事件响应分析师需要访问尽可能多的网络数据。然而,许多组织没有投入足够的资源,以便从网络设备和其他系统收集全面的日志。
在任何事件发生之前,明确组织将如何记录以及如何维护这些日志是至关重要的。这应该在日志管理政策及相关程序中进行定义。计算机安全事件响应团队(CSIRT)的人员应参与讨论哪些日志是必要的,因为他们通常能够深入了解某个日志来源相较于其他日志来源的价值。
NIST 日志管理指南
国家标准与技术研究院(NIST)已发布一份简短的日志管理指南,可通过以下链接访问:nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-92.pdf。
除了日志管理的技术问题外,还有法律问题必须解决。以下是 CSIRT 及其法律支持团队在任何事件发生前应当解决的若干问题:
-
将日志记录作为常规商业实践:根据业务类型和管辖区域,用户可能有合理的隐私期待,除非有明确声明的监控政策。此外,如果日志仅用于确定用户是否存在恶意活动,可能会涉及法律问题。因此,日志政策应当明确,日志记录网络活动是正常商业活动的一部分,且用户不应期望有隐私保护。
-
事件发生时近距离记录日志:这在自动化日志记录中不是问题,因为日志通常会在事件发生时几乎同时创建。从证据角度来看,未在事件发生时近距离创建的日志,在法庭上的证据价值会大打折扣。
-
有经验的人员:日志的价值通常取决于谁创建了日志条目,以及他们是否了解事件。在网络设备的日志情况下,日志软件会解决这个问题。只要能够证明软件正常运行,就不应该存在问题。
-
全面日志记录:企业日志记录应当尽可能覆盖整个企业。此外,日志记录应该保持一致。随机的日志记录模式在法庭上的价值不如在整个企业中保持一致的日志记录模式。
-
合格的保管人:日志政策应当指定一名数据保管人。该人员将代表日志处理程序和用于创建日志的软件类型。他们还将负责证明日志的准确性以及所用日志软件的正确性。
-
记录故障:持续的故障或在记录事件时的历史性故障,可能会降低它们在法庭上的价值。记录故障必须被文档化,并且需要附上故障的原因。
-
日志文件发现:组织应当意识到,在法庭程序中使用的日志将会提供给对方的法律顾问。
-
来自被攻破系统的日志:来自已知被攻破系统的日志存在可疑性。如果这些日志要作为证据提交,日志的保管人或事件响应者通常需要对日志中包含数据的真实性进行详细的证词陈述。
-
优先使用原始副本:日志文件可以从日志源复制到存储介质。作为进一步的步骤,任何日志应该从系统中归档。事件响应者应为每个日志文件建立证据链,并在案件处理过程中保持这些日志,直到获得法院指令允许销毁这些日志。
日志管理过程解决了识别组织认为必要的事件所需的基础元素。从这里开始,适当的日志管理策略的下一个关键组成部分是用于汇总和审查的技术。这涉及将 SIEM 系统集成到日志管理过程的整体结构中。
使用 SIEM
许多组织面临的一个重大挑战是网络设备日志的管理。由于空间有限,日志文件通常会被覆盖,新日志会覆盖旧的日志文件。结果是,在某些情况下,组织可能只保留几天,甚至几小时的重要日志。如果潜在的事件发生在几周前,事件响应人员将无法获得关键证据。
一种被广泛接受的工具是 SIEM 系统。这个设备可以汇总来自网络来源的日志和事件数据,并将其合并到一个位置。这使得 CSIRT 和其他安全人员能够观察整个网络的活动,而无需检查单个系统。
下图展示了 SIEM 系统如何集成到整体网络中:
图 12.1 – SIEM 与日志架构
各种来源,从安全控制到 SQL 数据库,都被配置为将日志发送到 SIEM。在这种情况下,位于10.100.20.18的 SQL 数据库显示USSalesSyncAcct用户帐户被用来将数据库复制到远程主机,位于10.88.6.12。SIEM 可以快速检查此类活动。例如,如果确定USSalesSyncAcct帐户已被入侵,CSIRT 分析人员可以迅速查询 SIEM 中该帐户的任何使用记录。然后,他们可以查看日志条目,显示数据库被复制到远程主机的情况。
如果没有 SIEM,CSIRT 分析人员必须检查可能已被访问的每个系统,这一过程可能非常耗时。
从 SIEM 平台,安全和网络分析人员可以执行与事件响应相关的几项任务,如下所示:
-
日志汇总:典型的企业内部网络中有几千台设备,每台设备都有日志;SIEM 可以部署来将这些日志汇总到一个中心位置。
-
日志保留:SIEM 平台提供的另一个关键功能是日志保留平台。合规性框架,如支付卡行业数据安全标准(PCI-DSS),规定系统日志应保持 1 年,且 90 天的日志应立即可用。SIEM 平台可以通过提供一个系统来有序存档日志并允许立即检索来帮助进行日志管理。
-
常规分析:在使用 SIEM 平台时,建议定期审查信息。SIEM 平台通常提供一个仪表盘,突出显示关键要素,如连接数、数据流量和任何重要的警报。SIEM 平台还允许生成报告,以便利益相关者了解活动情况。
-
警报:SIEM 平台可以在特定条件下发出警报,这些条件可能表示恶意活动的存在。这可以包括来自安全控制的警报,例如防病毒软件和入侵防御或检测系统。SIEM 平台的另一个关键特性是事件关联。该技术检查日志文件,并确定事件之间是否存在关联或共同点。SIEM 随后可以对这些类型的事件发出警报。例如,如果一个用户账户在多个系统中尝试多次登录,SIEM 可以识别这一活动并向相关方发出警报。
-
威胁狩猎:现代对手可以潜伏在目标网络中或利用之前未被发现的漏洞。威胁狩猎是利用数字取证技术揭露这些长期攻击的做法。SIEM 平台允许威胁狩猎者搜索妥协指示器(IOCs)。
-
事件响应:随着 SIEM 成为日志聚合和分析的单一平台,CSIRT 分析师通常会在事件发生时使用 SIEM。CSIRT 分析师常常会在平台上进行查询,并下载日志进行离线分析。由于日志文件的集中管理,进行搜索和事件收集的时间显著减少。例如,假设 CSIRT 分析表明一个用户账户已经被妥协。没有 SIEM 的情况下,CSIRT 分析师需要检查各个系统,查看与该用户账户相关的活动。而有了 SIEM,分析师只需在 SIEM 平台上搜索该用户账户,SIEM 已经汇总了来自企业各系统的用户账户活动日志。结果是,分析师能够在极短的时间内清楚地了解该用户账户的活动,而无需查看企业各系统中的日志。
SIEM 平台的购买和实施确实需要投入大量的时间和金钱。除此之外,还有持续的维护、保养以及必须修改的规则。从事件响应的角度来看,配置和维护得当的 SIEM 对于及时收集基于网络的证据至关重要。此外,SIEM 平台的功能和能力能够显著减少在检测到事件后,确定事件根本原因所需的时间。
SIEM 用例
以下文章提供了 SIEM 平台在企业环境中的应用案例的详细解析:www.sumologic.com/blog/why-modern-siem/。
Splunk
Splunk 是一个商业工具,广泛应用于各种类型的企业和组织。该平台利用日志转发应用程序来聚合日志,并将其发送到中央服务器,可以是本地服务器也可以是云实例。从这里,分析人员可以审查日志并创建警报,以识别和升级潜在的恶意活动。Splunk 的一个缺点是需要商业许可。这些许可基于发送到平台的数据和日志量。大多数组织无法将网络中每个系统的每一条日志都发送到平台。因此,组织需要在发送日志时谨慎选择:
图 12.2 – Splunk 平台
Elastic Stack
另一个开源的 SIEM 选项是 Elastic Stack(或常称为 ELK Stack)。Elastic Stack 是三个工具的组合。开源工具 Elasticsearch、Logstash 和 Kibana 合并在一起,为威胁猎人提供一个开源平台,用于摄取数据并将其转化为可以通过 Kibana 图形界面查看和分析的格式。这使得威胁猎人可以同时可视化来自多个系统的日志数据。Elastic Stack 被集成到多个不同的开源安全工具中,包括我们接下来将讨论的 Security Onion 平台。Elastic Stack 也可以配置为独立的 SIEM 解决方案,并结合如 Winlogbeat 等工具,后者将 Windows 事件日志转发到 Elastic Stack。
以下是 Elastic Stack 中最直观的部分——即 Kibana 界面。这个界面允许数据可视化和搜索,正如在这里所见:
图 12.3 – Kibana 平台
SIEM 平台是响应人员检查来自多个系统的各种日志的绝佳方式。一个至关重要的方面是检查 Windows 事件日志。下一节将探讨各种 Windows 事件日志及其为响应人员提供的关于账户和应用程序使用的洞察。
Security Onion
Security Onion 是一个开源的多工具平台,可以作为网络 入侵检测系统(IDS)和 SIEM。Security Onion 将多种安全工具(如 OSSEC、Suricata 和 Zeek)集成到一个平台中。
Security Onion 还具有仪表板和用于深入分析日志文件的工具。以下屏幕截图显示了可用的详细程度:
图 12.4 – Security Onion 平台
虽然安装和部署 Security Onion 平台可能需要一些时间和资源,但它是一个强大的、低成本的替代方案,适用于那些无法部署全功能 SIEM 解决方案的组织(Security Onion 平台及其相关文档可在 securityonion.net/ 获取)。
Windows 日志
响应人员最常需检查的端点操作系统是 Windows 操作系统。由于微软在市场上的巨大份额,大多数企业端点将是微软的桌面/笔记本电脑、服务器或虚拟系统。因此,响应人员必须充分了解如何利用 Windows 事件和系统监视器日志进行事件分析。
Windows 事件日志
Windows 事件日志提供了操作系统的活动、来自其他系统的连接、凭证使用情况以及 PowerShell 使用的广泛数据。
从初始入侵使用恶意软件或其他漏洞、凭证访问,以及使用 Windows 操作系统内部工具进行权限提升和横向移动的对抗性战术,通常通过 Windows 事件日志进行捕获。
操作系统活动中捕获的具体日志在很大程度上取决于组织如何配置它们。大多数企业利用组策略设置来配置系统记录哪些操作,以及为日志文件分配的存储空间。根据组织的日志管理实践,Windows 操作系统可以配置为记录 PowerShell 使用、服务器消息块(SMB)使用、应用程序活动、DHCP 客户端管理以及任务调度程序维护。
日志管理配置通常通过 Windows 组策略来管理。在这里,管理员可以通过一项策略管理多个系统。
Windows 操作系统包括了事件查看器,用户或系统管理员可以通过它查看系统上可用的日志,并进行初步审查。
要访问 Windows 事件查看器,可以使用 Windows 搜索功能查找“事件查看器”,然后点击图标。这将打开事件 查看器窗口:
图 12.5 – 微软 Windows 事件查看器
通过这个查看器,响应人员可以清楚了解哪些内容正在被记录,甚至可以搜索特定的日志条目。要直接访问日志以进行离线分析,可以导航到日志存储的默认文件路径C:\Windows\System32\winevt\logs。这将显示可记录的各种事件,具体如下:
图 12.6 – Windows 事件日志目录
如前所述,Windows 事件日志记录了操作系统执行的广泛活动。在本章中,将重点介绍三种更相关的 Windows 事件日志类型。这些类型涵盖了广泛的活动,并在确定潜在被入侵系统上发生了哪些操作时非常有用。详细说明如下:
-
安全日志:这些日志包含与系统安全相关的数据条目,包括登录、注销、安全组成员身份以及程序执行。
-
应用程序日志:应用程序开发者决定应用程序会记录哪些类型的活动。这些活动被汇总到应用程序日志文件中。
-
系统日志:系统日志通常用于排除非恶意活动的故障,记录的是 Windows 操作系统创建的数据。
Windows 事件日志 ID 总共有 100 多种。根据操作系统的使用方式,某些事件在系统上很少甚至从未出现过。另一些则非常常见,即使在正常情况下也会频繁出现。以下是响应者可能需要用到的一些更有用的 Windows 事件日志类型:
-
4624 和 4634 – 登录与注销:这些事件日志条目显示了在潜在被入侵的系统上使用凭证的情况。此外,4624 事件 ID 可以显示登录是本地系统执行的还是通过远程连接进行的,这对于通过 Windows SMB 协议寻找横向移动非常重要。
-
4625 – 账户登录失败:一两条此类日志条目可能没有太大意义。几条此类条目可能表示偶尔的登录错误,但大量此类日志条目则表明攻击者正在尝试暴力破解凭证。
-
4672 – 特权分配给新登录:这是 Windows 操作系统中用户账户尝试提升到根权限或管理员权限的等价物。可以用来判断攻击者是否通过被入侵的账户提升了权限。
-
PsExec、CMD.EXE或Whami.exe,用以深入分析潜在的恶意行为。 -
4768-4773 – Kerberos 服务:攻击者使用一些著名的漏洞,利用 Kerberos 票证授予票证(TGT)来提升权限。这种攻击,通常被称为 Kerberoasting,尤其具有破坏性,因为它允许攻击者在网络中通过有效凭证横行。
-
5140 – 网络共享对象已访问:当用户账户首次登录到网络共享时,会记录此活动。时间或用户活动的异常可能表明攻击者试图获取机密数据,或者勒索软件试图感染网络共享。
-
7045 – 安装了新服务:当用户在日志条目中指明的用户安装了新服务时,会记录此日志条目。某些恶意软件会将自己作为服务安装。检查这些日志条目可能会揭示恶意代码的存在。
Windows 事件日志参考
每个事件日志 ID 的具体细节超出了本章的范围。有关具体 ID 的良好参考资料可以访问 www.ultimatewindowssecurity.com/securitylog/encyclopedia/default.aspx。
如前所述,Windows 事件类型超过 100 种。使用的特定类型通常由组织决定,并且需要在可用存储空间和事件调查期间特定日志条目的实用性之间进行权衡。
可以利用多个资源来更好地理解 Windows 事件日志。第一个是 ultimatewindowssecurity.com 网站。该网站提供了一个可搜索的数据库,按事件 ID 列出了各种 Windows 事件日志类型。当响应者可能遇到较为晦涩的事件 ID 时,这一点非常有用。MITRE 公司还提供了 ATT&CK 知识库。可以在该知识库中搜索与调查相关的 Windows 事件日志 ID——例如,响应者正在检查某个系统,寻找是否有系统感染 Carbanak 恶意软件的迹象。在 ATT&CK 知识库中,响应者可以确定 Carbanak 已经创建了一个账户,而相关的 Windows 事件 ID 是 4720。然后,响应者可以在系统中搜索该特定事件 ID,查看是否有其他账户显得可疑。
如上所示,Windows 操作系统有大量的日志事件类型和 ID。以下部分将为响应者提供收集和分析这些日志文件的方法。
分析 Windows 事件日志
分析 Windows 事件日志是一个详细的过程。响应者经常遇到的一个挑战是,事件发生时可能需要分析的日志数量。对于多个系统,响应者可能需要处理数百万条独立的事件日志条目。减少这些日志的数量需要使用专门的工具和流程,从获取开始,进入分诊阶段,最后聚焦于分析与事件调查相关的关键事件日志。
获取
响应者在获取 Windows 事件日志时可以使用几种方法。理想情况下,日志文件应发送到 SIEM,以便响应者能够在整个企业范围内搜索日志条目。不幸的是,许多组织面临着存储成本的重大障碍,无论是使用商业平台,还是开源平台。结果是,它们往往不得不通过让本地系统处理存储来权衡聚合这些日志的成本。
由于大多数日志位于本地系统中,响应者需要使用技术手段来收集它们。第一种技术是直接将事件日志从本地系统复制到某种可移动媒体。只需导航到默认目录 C:\Windows\System32\winevt\Logs,并复制相关日志。此方法确实需要本地访问,并且与本地系统的互动较多。响应者有责任记录他们在系统上采取的每个操作,以便进行适当的报告。
响应者还可以选择通过简单的批处理脚本编写日志文件采集脚本。此采集可以与其他本地系统证据采集操作一起进行。例如,以下屏幕截图展示了从本地系统获取四种 Windows 事件日志类型的操作:
图 12.7 – 事件日志 CMD 采集
这些类型的脚本可以通过 USB 设备或远程会话运行,从而减少与系统的互动。
第六章介绍了用于本地采集证据的 CyLR.exe 工具。CyLR.exe 获取的关键证据之一是 Windows 事件日志。如前所述,这些日志文件可以从本地系统中获取并导出到 USB。此部分将探索的另一个选项是使用 CyLR.exe 获取 Windows 事件日志并将其转发到 Skadi 日志审查平台。稍后会讨论 Skadi,但首先,CyLR.exe 将针对一个系统运行,并将输出发送到 Skadi 服务器。
要从本地系统获取日志文件并将其发送到 Skadi 实例,请按以下步骤操作:
-
以管理员身份打开 Windows 命令提示符。
-
导航到存放
CyLR.exe文件的目录。 -
在命令提示符中输入以下命令:
C:\Users\JSmith\Desktop>CyLR.exe -s 192.168.207.130:22 -u admin -p password
在之前的命令中,-s 是远程系统的 IP 地址或域名,CyLR.exe 的输出会发送到该系统。在此情况下,该压缩的证据文件将通过 SFTP 发送到系统 192.168.207.130。-u 是用于访问远程系统的帐户的用户名,最后,-p 是与远程系统相关的帐户的密码。与本地采集一样,CyLR.exe 将运行,命令提示符中将显示以下内容:
图 12.8 – CyLR.exe 执行输出
这种远程捕获技术可以通过任何可用的远程访问工具来实现。此方法的一个显著优点是能够获取日志数据和CyLR.exe捕获的其他证据,并自动将其转发到中央存储库。该中央存储库可以是 Skadi 实例,也可以是一个已配置为接受此数据的 SFTP 服务器。
根据事件的类型和涉及的系统数量,可能会有大量数据。有时,对于响应人员来说,手动检查这些数据可能过于繁琐。在这种情况下,需要对数据进行初步筛选,以确定哪些日志条目最为重要。
初步筛选
如前所述,响应人员可能需要检查多个 Windows 系统。每个系统可能包含数千条,甚至数十万条事件日志条目。响应人员或响应小组不可能检查那么多单独的条目。这就像人们常说的大海捞针。为了处理 Windows 事件日志分析中常遇到的大数据集,响应人员可以使用 DeepBlueCLI 工具。由 Eric Conrad 开发的这个 PowerShell 脚本能够检测可疑的 Windows 事件日志条目,例如服务创建、账户创建、大量登录失败和恶意 PowerShell 使用。通过关注这些更为关键的事件类型,响应人员将能够分析更多的日志文件,并有可能识别出可疑的活动。
要运行 DeepBlueCLI,请按以下步骤操作:
-
从其 GitHub 网站下载 PowerShell 脚本:
github.com/sans-blue-team/DeepBlueCLI。下载后,解压该文件。 -
打开 PowerShell 并导航到包含
DeepBlue.ps1的目录。 -
通过将
DeepBlue.ps1PowerShell 脚本指向特定的 Windows 事件日志文件(在此案例中为 Windows 安全事件日志)来执行该脚本,如下所示:PS C:\Users\madno\Desktop\DeepBlueCLI-master\DeepBlueCLI-master> .\DeepBlue.ps1 -log security C:\Users\madno\Desktop\Logs\Security.evtx
参考截图如下:
图 12.9 – DeepBlueCLI 可疑的安全事件日志
-
Windows 事件日志还可能包含表示恶意活动的条目。使用以下命令运行 DeepBlueCLI PowerShell 脚本,检查系统日志:
PS C:\Users\madno\Desktop\DeepBlueCLI-master\DeepBlueCLI-master> .\DeepBlue.ps1 -log system C:\Users\madno\Desktop\Logs\System.evtx
这将生成以下输出:
图 12.10 – DeepBlueCLI 可疑的系统事件日志条目
-
正如我们之前讨论过的,Windows 事件日志的数量是庞大的。其中一个经常提供关键数据点的日志来源,特别是在勒索软件攻击中,是 Windows PowerShell 操作日志。该日志通常会捕捉到作为多阶段勒索软件攻击一部分使用的恶意 PowerShell 脚本。使用以下命令对 PowerShell 日志进行初步筛选:
PS C:\Users\madno\Desktop\DeepBlueCLI-master\DeepBlueCLI-master> .\DeepBlue.ps1 C:\Users\madno\Desktop\Logs\Microsoft-Windows-PowerShell%4Operational.evtx
此命令生成以下输出:
图 12.11 – DeepBlueCLI PowerShell 事件日志条目
在前面的截图中,我们可以看到一个超过 1,000 字节的 PowerShell 脚本,这可能表明它是恶意的。对该脚本的审查表明,它打开了一个网络套接字,连接到一个 IP 地址,并且端口设置为 4443:
图 12.12 – PowerShell 网络套接字
这种行为可能是合法的,但应当进一步跟进,因为诸如PowerSploit和Cobalt Strike等各种后渗透工具广泛使用 PowerShell。我们将在后续章节中讨论勒索软件攻击。
DeepBlueCLI 是进行事件日志初步分析的一个优秀工具。它的两个缺点是分析人员仍然需要使用其他工具检查初始日志条目,并且 DeepBlueCLI 可能会漏掉实际的恶意活动。建议从这个工具开始,然后过渡到更详细的检查方法和工具。在这些情况下,像 Event Log Explorer 和 Skadi 这样的工具非常有助于进行更详细的分析。
详细事件日志分析
如前所述,使用初步筛查工具是一个有用的第一步,但任何可以访问事件日志的事件调查都需要使用专业工具深入挖掘它们提供的数据。Windows 操作系统有一个本地的事件日志查看器。根据许多响应者的经验,这个查看器更适合于有限的故障排除,而不适合深入分析事件日志。有几个工具,无论是开源的还是商业的,都可以用于事件日志分析。SIEM 工具提供了最好的工具类型之一,特别是当它们能够分析离线事件日志或通过脚本或其他工具获取的日志时。本章将讨论两个工具:Event Log Explorer 和 Skadi。这些工具都适用于事件日志分析,但具有独特的功能,使其适合不同方面的事件日志分析。
例如,Event Log Explorer 提供了更好的结果筛选功能,并具有字符串搜索能力。Event Log Explorer 还可以合并多个来源。其他工具,如 Skadi,允许远程获取日志文件,并可以将日志条目与其他数据(如 MFT 条目和注册表键设置)结合起来。Skadi 的一个缺点是需要一定的时间来获取和处理数据以供审查。因此,具体使用哪个工具取决于调查人员选择最适合当前事件的工具。
事件日志浏览器
事件日志浏览器是一款功能更强大、易于操作的事件日志分析工具。作为一款商业工具,Event Log Explorer 的开发者 FSPro Labs 提供了一个 30 天的试用期供用户测试。该工具可以从eventlogxp.com/官网下载安装,并可安装在 Windows 操作系统上。
在本节中,我们将继续分析在上一章节中分析的存储中获取的日志文件:
- 打开事件日志浏览器,以下窗口将会出现:
图 12.13 – 事件日志浏览器图形用户界面
图形用户界面有三个主要区域。中间窗格包含 Windows 事件日志类型中的单个日志条目。下方窗格包含每个日志条目中的详细信息。最后,左侧窗格包含正在分析的 Windows 事件日志类型。
-
事件日志浏览器将自动导入本地主机的 Windows 事件日志。要移除这些日志,右键点击计算机名称并点击移除计算机。点击是。这将移除现有的 Windows 事件日志。
-
要导入事件日志文件或多个文件,请点击文件 | 打开日志文件 | 标准。导航到已提取事件日志的相应文件夹。从这里加载日志文件。此处,我们将查看 Windows 安全事件日志。选择并点击打开,如下所示:
图 12.14 – 打开 Windows 事件日志
- 这将加载该日志文件的所有日志条目。在此示例中,我们将查看 DeepBlueCLI 筛查中识别出的 新用户添加 条目。该输出不仅识别了事件 ID,还识别了账户,这是我们可以用来筛选的两项数据。要打开筛选器,请查找任务栏上的漏斗图标:
图 12.15 – 事件日志浏览器 – 创建筛选器
- 然后会显示筛选器屏幕。在这里,我们可以根据多种特定属性过滤事件日志,包括事件类型、事件 ID,甚至在日志文件条目的文本中进行关键字搜索。在本例中,我们将查看
minecraftsteve的日志条目。这是通过 DeepBlueCLI 筛查脚本识别出来的。输入事件 ID 为4720,并在minecraftsteve中如下所示:
图 12.16 – 事件日志浏览器筛选器参数
- 点击确定后,输出将显示与输入筛选条件匹配的事件日志条目。事件日志条目的详细信息包括有关账户创建的附加细节:
图 12.17 – 事件日志详情
- 再次回到 DeepBlueCLI 脚本的结果,发现有一个附加条目,事件 ID 为 4732,表示
minecraftsteve账户具有提升的权限。通过返回筛选器,将事件 ID 从 4720 更改为 4732,并移除minecraftsteve账户,我们可以看到该账户的 SID 不仅被移动到管理员组中,还被移动到 远程管理 用户组中:
图 12.18 – 事件日志条目描述
在这个简短的示例中,我们能够将新用户账户的创建与其权限提升到管理员组和远程管理用户相关联。虽然这可能不是恶意的,但如果无法将这个新账户与合法用户联系起来,它可能表明有攻击者创建了一个账户并将其加入管理员组。
一个可能对分析员可用的 Windows 事件日志是 Windows Defender 操作事件日志。这些条目包含有关 Windows Defender 恶意软件防护的信息,并且可以提供有关更新和检测的额外信息。打开文件后可以看到几个警告:
图 12.19 – Windows Defender 条目
对其中一个警告的回顾表明,Defender 已检测到 Meterpreter 的使用,这是一个著名的后期利用工具:
图 12.20 – Windows Defender Meterpreter 检测
Event Log Explorer 拥有很多功能,无法在本书中详细讲解。它的其他一些功能包括构建自定义视图、对特定数据点进行筛选,以及在多个事件日志文件中查找日志条目中的文本。即使有这些功能,Event Log Explorer 仍然存在一些小的局限性。首先,响应人员必须将日志收集到系统中进行分析,并手动加载它们。其次,视文件大小而定,Event Log Explorer 可能会出现性能问题,包括卡顿。响应人员应确保不会过度加载该应用程序。尽管如此,Event Log Explorer 仍然是响应人员工具包中非常优秀的工具。
Skadi 和 Kabana
事件通常涉及企业网络中的多个系统。没有分析多个系统的事件日志,相关联这些活动往往非常困难。这时,之前讨论的 SIEM 设备就非常有用。如果 SIEM 没有预配置以获取和分析事件日志,另一种选择是 Skadi 平台。这个开源平台可以从 GitHub 获取,网址是 github.com/orlikoski/Skadi,它是一组安装在 Ubuntu 16.04 LTS 服务器基础镜像上的应用程序和取证工具。
本章将重点介绍的主要工具是 Elastic Stack,它是 Skadi 平台的一部分。Skadi 还提供的另一个主要功能是能够接收通过CyLR.exe获取的日志和其他取证数据。如前所述,CyLR.exe可以配置为通过 SFTP 将输出发送到远程系统。Skadi 将一个附加工具与CyLR.exe结合,生成一个可由 Skadi 上的 Elastic Stack 接收的数据集。此功能允许响应者在多个不同系统上运行CyLR.exe,并直接将其发送到 Skadi,之后可以对其进行处理、索引、搜索和关联。
在CyLR.exe完成后,响应者将登录到 Skadi 控制台。从这里,Cold Disk Quick Response(CDQR)工具将运行,将已获取的数据转换为 Elasticsearch 工具可以接收的格式。以下命令启动 CDQR 处理:
skadi@skadi:~$ cdqr in:DESKTOP-SKPTDIO.zip out:Results -p win --max_cpu -z --es_kb DESKTOP-SKPTDIO
CDQR 从CyLR.exe接收输入文件jsmith-pc.zip,并将其输出到Results文件夹。-p参数选择解析器。在此情况下,由于DESKTOP-SKPTDIO是一个 Microsoft Windows 系统,因此选择win解析器。接下来的参数是--max_cpu。此参数允许分析人员限制 Skadi 机器的 CPU 使用率。如果正在处理多个CyLR.exe输出,分析人员应省略此参数。接下来的-z参数表示文件是一个 ZIP 文件。最后,--ex_kb参数告诉 CDQR 将结果输出到 Kibana,索引名称为DESKTOP-SKPTDIO。这个索引允许分析人员在 Kibana 应用程序中区分不同的系统:
图 12.21 – CDQR 执行
处理完成后,结果可以在 Kibana GUI 中查看,如下所示:
- 导航到 Skadi 服务器的 IP 地址,并输入用户名和密码。默认是
skadi:skadi。这将打开如下截图所示的门户:
图 12.22 – Skadi 门户
- 点击Kibana,以下屏幕将会出现:
图 12.23 – Kibana GUI
- 从这里,点击Discover。在右上角,设置日期为合适的时间范围。Kibana 默认显示过去 15 分钟的数据。对于离线数据,设置适用的时间范围,或者直接点击过去 2 年,如下所示:
图 12.24 – Kibana 的 Discover 仪表板
- Kibana 功能丰富,提供了广泛的数据分析选项。这包括使用自定义查询、事件 ID、关键字和 XML 字符串。在这种情况下,响应者将专注于事件 ID 4104,该事件 ID 指示远程运行 PowerShell 命令。然后,查看在与 DeepBlueCLI 输出关联的 IP 地址上添加 XML 筛选器。在这种情况下,选择
4104并单击 保存。这将运行命令:
图 12.25 – 根据事件 ID 筛选
- 这将产生 176 个总共的带有该事件标识的条目。为了进一步减少这个数量,让我们继续添加第二个用于 XML 数据的筛选器,
192.168.191.253:
图 12.26 – 根据 IP 地址筛选
这样就产生了两个结果。对结果的分析确认了在 DeepBlueCLI 中显示的结果。
- 看到是否有与该 IP 地址相关的额外结果可能会有所帮助。通过深入研究具有事件 ID 600 的条目,可以看到额外的 PowerShell 条目显示,这是 PowerCat 的一个版本,PowerCat 是一款具有类似于流行黑客工具 Netcat 功能的 PowerShell 脚本:
图 12.27 – Meterpreter 事件条目
Skadi 结合 CyLR.exe,为响应者提供了从涉及事件的几个系统中获取和分析日志文件的能力。通过特定的事件 ID 或关键字进行透视,使 Skadi 成为在识别事件调查中重要的特定日志条目的强大工具。通过分析这些事件,我们可以看到攻击者能够远程执行 PowerShell 并安装远程网络服务。
摘要
在日志分析的核心是一种假设,即攻击者的行动会留下痕迹。正如在物理世界中一样,响应者能够看到这些痕迹的能力基于所使用的工具和技术。本章探讨了日志和日志管理的基础元素,以及诸如 SIEM 之类的工具来聚合和审查这些日志,最后还审视了用于检查源自 Windows 操作系统的最常见日志的工具和技术。本章仅仅是浅尝辄止,介绍了日志在事件调查中起着重要作用的一部分。
符合理解对手攻击痕迹主题的要求,下一章将探讨恶意软件分析在事件响应中的作用。
问题
回答以下问题来测试你对本章的了解:
-
为了有效的日志管理,组织应将日志记录作为正常的业务实践。
-
True
-
False
-
-
下列哪项不是 SIEM 的功能之一?
-
日志保留
-
自动响应
-
Alerting
-
日志聚合
-
-
下列哪个不是 Elastic Stack 的一部分?
-
Kibana
-
Elasticsearch
-
日志响应
-
Logstash
-
-
洛卡尔交换原理指出,当两个物体相互接触时,它们会留下痕迹。
-
真
-
假
-
进一步阅读
有关本章所涵盖主题的更多信息,请参考以下资源:
-
Windows 安全日志事件:
www.ultimatewindowssecurity.com/securitylog/encyclopedia/ -
Graylog:
github.com/Graylog2 -
Skadi:
github.com/orlikoski/Skadi -
应用事件响应 Windows 事件日志分析:
forwarddefense.com/media/attachments/2021/05/15/windows-event-log-analyst-reference.pdf
第十三章:撰写事故报告
事件响应团队的功能与消防部门相同。两个团队都需要通过培训掌握各自的技术、工具和实践,并能在火灾或事件发生时随时做出反应。在对火灾进行响应时,消防员会记录笔记并记录他们的行动,确保关键决策被记录,个人贡献被注意到。一旦火势得到控制,他们会从残骸中查找火灾的原因和起源。一旦准备好适当的文档,消防部门会进行事后行动审查,评估他们的表现并寻找改进途径。其他报告允许消防部门和安全专家更新建筑法规,并提高建筑物在火灾发生时的生存能力。
事件响应团队利用了类似的工作流程。在事件期间,记录笔记并记录行动。从系统中获取证据,并以法医学的方式保留。利用事件期间获得的笔记、观察和证据进行根本原因分析。信息技术人员利用这种根本原因分析来修补漏洞并进一步加固系统。最后,团队进行自己的事后行动审查,详细列出事件序列,并对团队的流程、工具和技术进行评价,并对事件响应计划进行任何更正。
为了最大化根本原因分析和事后行动简报的好处,事件响应者需要确保所有操作都以适当的方式记录下来。在考虑 IT 基础设施未来状态时,高级领导和决策者需要使用准备好的多个文档。
为了更好地准备响应者起草必要的文档,将讨论以下主题:
-
文档概述
-
执行摘要
-
事件调查报告
-
司法报告
-
准备事件和司法报告
文档概述
这将是事故文档的概述。在本节中,我们将看看要捕捉哪些数据,不同的受众,以及如何正确地来源报告内容。
与事故相关的文档有多种形式。任何文档的长度通常取决于事故类型。简单的事故可能在现有的票务系统中非正式记录,调查时间很短,影响有限。然而,对于更复杂的事故调查,例如导致机密信息(如医疗记录或信用卡信息)泄露的数据漏洞,可能需要详细的书面报告和支持证据。
要记录的内容
在记录事件时,判断应该记录什么并不是非常困难。遵循五个W(谁、什么、哪里、何时和为什么),有时还包括如何,是考虑在事件发生过程中记录内容时的一个很好的基础。当讨论文档时,特别是讨论安全事件的法律影响时,另一个好的智慧就是,如果你没有写下来,它就没有发生。这句话用来强调正确的文档记录通常包含尽可能详细的信息,以便事件响应分析员提供。这些分析员可能会参与到最终涉及民事诉讼的事件中。司法程序通常进展缓慢,分析员可能在 18 个月后被召唤到证人席上,而这期间可能已经发生了 10 起其他事件。拥有尽可能详细的事件报告将帮助分析员能够以正确的方式重建事件。
使用这五个 W(和一个 H)结构记录文档的一个极好的例子是查看数字取证任务,例如硬盘镜像。在第八章中,当我们讨论对嫌疑硬盘进行镜像的实践时,部分涉及了适当的文档记录。以下是该事件的更详细记录:
-
谁:这是最容易记录的细节。简单地说,谁参与了这个过程?例如,参与的人是分析员简·史密斯。
-
何时:记录镜像开始的日期和时间,以及结束的日期和时间。例如,镜像过程在 2022 年 6 月 16 日 21:08 UTC 开始,在 2022 年 6 月 16 日 22:15 UTC 结束。时间至关重要,您应该确保在整个调查过程中使用标准化的时区,并在报告中加以说明。
-
哪里:应该提供详细的地点信息,例如某个办公室。
-
什么:所执行的动作;例如,获取内存或防火墙日志,或对硬盘进行镜像。
-
为什么:为所执行的动作提供合理的解释有助于理解该动作为何被执行。
-
如何:应包括对动作执行方式的描述。此外,如果事件响应团队在其计划中使用了操作手册或标准操作程序,也应包括此内容。任何偏离标准操作程序的行为也应以类似方式记录。
将所有这些信息结合起来,可以在报告中填写以下示例语言:
2022 年 6 月 16 日,分析员 Jane Smith 作为调查的一部分,抵达位于美国 Anytown Maple 街 123 号企业办公园区的 217 号办公室。到达后,Smith 接管了戴尔笔记本电脑,资产标签号为#AccLT009,序列号为#7895693-862。来自防火墙 IDS/OPS 的警报显示该笔记本电脑与一个已知的指挥与控制服务器进行了通信。为了确定该电脑是否感染了恶意软件,决定对其进行镜像处理。2022 年 6 月 16 日 21:08 UTC,Smith 按照标准操作程序 IR-002 使用实时镜像技术对硬盘进行镜像。该过程于 22:15 UTC 完成。
本条目提供了足够的细节以重建发生的事件。结合其他文档,如照片和链条管理,分析员能够清楚地了解整个过程及其结果。
文档类型
没有统一的标准规定如何记录事件,但有几个明显的分类。如前所述,文档的深度通常取决于事件的类型、规模和范围;然而,一般来说,以下几类适用:
-
故障单系统:大多数企业组织都有现成的故障单系统,用于跟踪系统故障和当前网络基础设施中常见的其他问题。这些系统会捕获与事件相关的大量数据。通常,一个条目会记录开始和结束的日期与时间、最初报告的人员、执行的操作,并提供一个备注区域。故障单系统的一个主要缺点是它们最初是为支持企业基础设施的一般操作而设计的。因此,更复杂的事件将需要比这些系统所能提供的更多的文档。因此,这些系统通常仅用于处理小规模事件,如孤立的恶意软件感染或其他能迅速解决的小事件。
-
安全编排与自动化(SOAR)平台:一些组织认识到需要专门的事件响应平台,并开发了支持事件响应团队的应用程序和其他基础设施。这些事件响应编排平台允许分析员输入数据、附加证据文件、与其他团队成员协作,并调用外部资源,如恶意软件逆向工程和威胁情报馈送。
市面上有几种这类平台可供选择,既有商业平台,也有免费软件。这些平台的主要优势是可以自动捕获信息,例如日期、时间和分析员的操作。
另一个明显的优势是,它们可以限制特定群体查看信息。在票务系统中,有可能出现未经授权的人员查看到组织可能希望保密的细节。而拥有协调系统可以提供一定程度的保密性。另一个关键优势是团队成员可以看到采取了哪些行动以及获得了哪些信息。这减少了通话数量和误解的可能性。
-
书面报告:即使在使用自动化平台的情况下,某些事件仍然需要进行详细的书面报告。通常,这些书面报告可以分为三种主要类型。以下每种类型将在本章后续内容中展开说明:
-
执行摘要:执行摘要是一个一到两页的报告,旨在概述事件的高层次要点,供高级管理人员参考。通常,简短的事件概述、根本原因(如果能够确定)以及修复建议就足够了。
-
事件调查报告:这是组织内多方人员都会查看的详细报告。该报告包括调查的详细情况、根本原因分析,以及防止事件再次发生的详细建议。
-
取证报告:最详细的报告是技术报告。当对日志文件、捕获的内存或磁盘镜像进行取证检查时,会生成这类报告。这些报告通常非常技术性,因为它们常常会被其他取证人员审查。报告内容可能很长,因为工具输出和证据部分(如日志文件)通常会被包括在内。
-
了解构成事故报告的各类内容,可以帮助响应人员妥善组织资料。即使是较小的事件,也会生成文档,这意味着响应人员可能会感到不堪重负。再加上数据来源繁多,报告过程可能变得十分繁琐。为了让流程更加顺畅,响应人员应该准备好在事件发生之初就处理各类内容,并相应地组织文档。
来源
在准备报告时,无论事件规模大小,都有多个数据来源需要包含在文档中,从仅需在票务系统中输入一个条目的小型事件,到需要广泛事故和取证报告的复杂数据泄露。以下是一些常见的数据来源:
-
个人观察:用户可能拥有与案件相关的信息。例如,他们可能点击了一个来自合法地址的邮件中的文件。其他时候,分析人员可能会观察到系统中的某些行为,并记录下来。
-
应用程序:某些应用程序会生成日志文件或其他可能需要包含在报告中的数据。
-
网络/主机设备:本书的大部分内容都涉及从企业环境中的多个系统获取和分析证据。这些系统中的许多还允许输出报告,可以与整体事件或取证报告一起包含。
-
取证工具:取证工具通常具有自动化报告功能。这可以是对一些操作的概述,正如前几章所讨论的那样,或者是可以包含在取证报告中的实际输出,如文件哈希值。
无论材料来源何处,一个好的规则是尽可能多地在报告中捕捉和包含信息。拥有更多信息总比信息不足要好。
受众
准备文档时,最后一个需要考虑的问题是,谁会阅读事件报告而不是详细的取证报告。通常,以下是可能阅读与事件相关报告的部分人员,这些人员既包括组织内部,也包括外部人员:
-
高层管理人员:高调的事件可能会引起首席执行官(CEO)或首席财务官(CFO)的关注,尤其是当事件涉及媒体时。执行摘要可能就足够了,但如果高级领导要求更详细的报告和在事件期间及结束时的简报,请不要感到惊讶。
-
信息技术人员:这些人可能是最关注事件响应分析人员发现的内容的人。他们很可能会非常认真地审查根本原因分析和补救建议。
-
法律:如果预计会有诉讼或其他法律行动,法律部门将审查事件报告,以确定是否存在安全漏洞或需要澄清的相关程序。如果需要进行修订,请不要感到惊讶。
-
市场营销:市场营销部门可能需要审查执行摘要或事件报告,以便在发生外部数据泄露时向客户传达信息。
-
监管机构:在受监管的行业,如医疗保健和金融机构,监管机构通常会审查事件报告,以确定组织是否存在潜在的责任。如果泄露的机密记录数量较多,或者看起来组织存在疏忽,可能会对其进行罚款。
-
网络保险公司:网络保险是一项近年来应对勒索软件爆发而发展的新兴业务。网络保险公司可能会要求检查分析师或响应人员的任何书面报告,以配合客户提交的索赔。
-
执法:某些事件需要执法部门介入。在其他情况下,执法部门可能希望捕捉与调查相关的任何 IOC(指标)或其他数据点,因为这些信息可能有助于未来潜在事件的处理。在这些情况下,执法机构可能需要事件和取证报告的副本进行审查。
-
外部支持:有时需要外部取证或事件响应支持公司。在这种情况下,现有的报告将大大帮助这些人员迅速了解情况。
了解受众能够帮助事件响应分析员了解谁会阅读他们的报告。需要明白的是,报告需要清晰简洁。此外,技术细节可能需要为没有相关知识或经验的受众进行一些澄清。
执行摘要
高层管理人员需要了解事件的关键细节,而不需要查看所有的技术或调查材料。本节将探讨如何准备一份有效的执行摘要,捕捉高层管理人员及其他关键利益相关者所需的细节和建议。
如前所述,执行摘要捕捉的是事件的宏观视角。这包括事件的总结、根本原因的描述以及为修复问题和防止类似事件再次发生所提出的建议。在金融机构或医院等有强制报告要求的受监管行业中,最好说明是否需要通知,如果需要,暴露了多少机密记录。这可以帮助高层管理人员理解事件的深度,并确保适当的法律和客户沟通措施得到处理。
这个报告的名称可能会有些误导。人们通常认为该报告仅面向 C 级高管。虽然这是报告的主要受众之一,但还有其他群体通常也需要阅读执行摘要。法律和营销部门可能需要至少对相关事实有一个粗略的了解,以便能够准确地制定向客户或第三方的沟通方案。其他外部监管机构也可能需要在完成完整的事件和技术分析报告之前获得事件的摘要。
让我们扩展一下之前关于执行摘要应包含哪些内容的讨论。虽然没有硬性规定,但以下内容是编写摘要的良好基础:
-
事件概述:这是一个简短的,可能只有半页的事件摘要,概述事件发生期间的关键事件。它不是逐小时的完整记录,而是涵盖了关键事件,例如最初的检测、事件被控制的时间、威胁完全从环境中清除的时间,以及最终操作恢复正常的时间。
-
图形时间轴:图形时间轴有助于将关键事件放置在适当的日期和时间。保持图形在 8 到 12 个具体条目之间,这些条目应能捕捉到高层次的事件。
-
根本原因概述:事件的根本原因将在事件调查报告中详细记录,但简短的概述对高层了解事件性质很有帮助。这可以是简短的陈述、几句话或一段话。例如,以下内容足以作为根本原因陈述:
事件调查确定,一名仍然未知的对手利用一个脆弱的 Web 服务器,使用特别制作的漏洞利用程序。由此,对手能够通过网络配置错误进入企业网络,并在系统上执行勒索软件 。
-
高层建议:应包括一张表格,其中列出战略和战术建议,并与事件调查报告相关联。
-
额外报告:简要说明将要准备的任何其他文档。例如,作者可能想包含一段说明,指出事件和相关的取证报告正在准备中,预计将在两周内完成。这让读者知道,如果他们需要额外的背景或细节,相关资料即将提供。
从工作流程的角度来看,执行摘要通常是关于事件的第一份书面文档。例如,一个需要两周时间来分析和修复的重大事件,将产生大量文档。执行摘要可以作为临时措施,用来弥补编写完整报告所需的时间。这使得领导层和其他利益相关者能够制定信息发布、立即对环境进行调整并做出其他决策,而不必等待完整报告。
准备执行摘要时有一些指导原则。首先,保持语言的高度简洁。特定的技术术语可能会让某些读者感到困惑,因此语言应尽可能非技术性。第二,保持简短,并为后续文档提供引导。第三,讨论应保持高层次,关注对组织的宏观影响。通常,两页是最大限制。在某些情况下,使用 PowerPoint 演示文稿代替书面摘要可能更有益。
事件调查报告
一次全面的事件调查涉及由各类人员执行的各种行动。这些行动会被记录在叙事报告中,报告详细描述了调查的顺序,并提供了事件的时间线。
事故报告可能是组织内外范围最广的文档。尽管会有一些技术技能有限的人会审查这份报告,但使用正确的术语和相关数据仍然很重要。对于那些可能感到困惑的人,总会有时间解释技术细节。
以下是一些应当捕捉并纳入报告的关键数据:
-
背景:背景部分概述了从发现到最终处理的整个事件过程。事件的背景应包括 CSIRT 首次得知事件的方式以及最初可用的信息。接下来,应该得出关于事件类型和严重程度的结论。报告还应包括对系统的影响,以及可能已泄露的机密信息。最后,它应概述采取了何种遏制策略,并且系统是如何恢复到正常运行状态的。
-
事件时间线:当报告从背景部分转向事件时间线时,重点将更加关注细节。事件时间线最好采用表格格式。每个执行的动作都应该在时间线中记录一项条目。下表展示了应包括的详细程度:
| 日期 | 时间(UTC) | 描述 | 执行者 |
|---|---|---|---|
| 6/17/22 | 19:08 | 防火墙 IPS 传感器警告可能的 C2 活动。SOC 将其上报给 CSIRT 进行分析和响应。 | Bryan Davis |
| 6/17/22 | 19:10 | 检查了防火墙日志,并确定主机 10.25.4.5 已连接到已知的恶意软件 C2 服务器。 | John Q. Examiner |
| 6/17/22 | 19:14 | 使用 Carbon Black EDR 隔离了 10.25.4.5 端点,防止其继续进行网络通信。 | John Q. Examiner |
| 6/17/22 | 19:16 | 通过 Velociraptor 从 10.25.4.5 检索预取文件以进行分析。 | John Q. Examiner |
表 13.1 – 事件时间线日志
时间线中的一个关键方面需要牢记的是,条目将按顺序排列在 CSIRT 行动之前。在之前的表格中,预取文件将被分析,目的是展示恶意软件的执行。这些条目显然会出现在 CSIRT 活动之前。
该日志可能包含多页条目,但理解事件的顺序和某些操作所需的时间至关重要。这些信息可以用于重建事件的顺序,同时也可以通过审查响应和处理时间来改进事件响应流程。
-
网络基础设施概览:如果发生的事故涉及跨网络的多个系统,良好的做法是包括受影响系统的网络拓扑图,以及系统如何连接和相互通信的概述。其他信息,如与事故直接相关的防火墙规则,也应包括在内。
-
取证分析概览:对于包括日志、内存或磁盘驱动器取证分析的事故,应在事故报告中包括该过程的概述及结果。这使得利益相关者能够理解执行了哪些类型的分析,以及这些分析的结果,而无需深入了解数字取证的技术细节。分析人员应确保通过取证分析得出的结论被纳入此部分。如果事故响应团队广泛使用了取证技术,这些内容可以在本章稍后的独立报告中记录。
-
遏制措施:事故响应团队的关键任务之一是在检测到事故后,限制对其他系统的损害。本报告的这一部分将说明采取了哪些类型的遏制措施,例如关闭系统、断开与网络的连接或限制其访问互联网。分析人员还应确保这些措施的有效性被纳入报告中。例如,如果通过访问交换机管理网络访问变得困难,且必须采取手动处理方式,了解这一事实将帮助 CSIRT 创建新的流程,简化此操作并限制受损主机访问网络的其他部分。
-
发现/根本原因分析:报告的核心部分对于高级领导层和信息技术人员最为重要的是发现内容,以及如果已发现的话,根本原因。报告的这一部分应全面并包含事件时间线的相关内容。应指出在主机、软件、硬件和用户中,哪些因素导致了事故的负面或正面结果。如果已确定攻击者使用的具体漏洞或被利用的漏洞,也应包括在内。本部分报告的总体目标是描述威胁是如何破坏基础设施的,并为后续的修复和建议提供可信依据。
-
补救措施:如果在事件发生期间采取了补救漏洞或其他不足的措施,应将其纳入报告。这使得 CSIRT 能够全面向其他 IT 人员简报所做的更改,以限制对网络其他部分的损害,从而将这些更改纳入正常的变更控制程序,并进行验证。这确保这些更改在未来不会对其他系统造成不良影响。
-
最终建议:报告中应包括对基础设施改进、漏洞修补或其他控制措施的任何建议。然而,这些建议应基于观察结果和对根本原因的深入分析。
-
定义:报告中应包括任何能帮助技术人员理解事件的特定定义。技术术语,例如服务器消息块(SMB),如果某个系统存在对 SMB 协议漏洞的利用,也应包含在报告中。
需要特别注意的是,这份报告最有可能传递到组织内部和外部的各个部门。报告还应经过至少一次质量控制审查,以确保其没有错误或遗漏,并且能够被目标受众阅读。
法医报告
数字证据的审查会产生大量的技术细节。调查过程中得出的观察结果和结论需要通过数据来支撑。技术报告捕捉了关于数字证据分析的相关细节,这些细节构成了整体事件报告的核心。
法医报告是三类主要报告中技术性最强的一种。分析师应该尽量保持技术的准确性,而不是为了非技术人员而简化报告。分析师还应意识到,如果法医报告能够确定特定个体(如恶意内鬼),它对整体事件报告至关重要。
在已经识别出犯罪嫌疑人或事件可能引发法律后果的情况下,法医报告将会受到严格审查。因此,分析师必须非常仔细地完成报告,确保其准确和全面,具体要求如下:
-
审查员的背景/经历:对于法律人员或外部审计员等受众,了解法医分析师的背景和资格非常重要。背景应包括正式教育、培训、经验以及分析师在法庭上的经历概述,特别是是否被认定为专家证人。如果预计该报告将作为法庭案件的一部分使用,可以将完整的简历附加到法医报告中。
-
使用的工具:报告应包括一个完整的硬件和软件工具列表,这些工具在分析证据时被使用。此信息应包括硬件的品牌、型号和序列号,例如物理写保护器,或任何软件的名称和版本号。报告中还可以进一步补充所有工具在使用前都已更新的信息。
-
证据项:全面的证据项列表应包括分析师在事件中收集的任何磁盘镜像、内存捕获或日志文件。应包括收集证据的日期、时间、地点和分析师的姓名。如果是物理证据,可能还需要附上证据链表格。如果证据项很多,报告的这一部分可以作为附录提供,以便更好地引导读者阅读。
-
取证分析:在这一部分,分析师将非常具体地说明在调查过程中采取的行动。诸如日期和时间等细节至关重要,以及所采取行动的详细描述。
-
工具输出:在前面的章节中,已经介绍了许多用于调查事件的工具。其中一些工具,如 Volatility 或 Rekall,无法生成报告。因此,分析师有责任捕捉这些工具的输出。分析师可以包含这些命令行工具的屏幕截图或文本输出,并应将其纳入报告中。如果这些工具产生了与事件相关的输出,这一点尤其关键。
事件报告模板
关于如何撰写事件报告,没有明确和简洁的指导。尽管主要信息是统一的,但对于如何编写报告以及报告应是什么样子,缺乏具体的说明。对于刚入门的人来说,一个不错的模板是 Lenny Zelster 提供的模板,下载地址为zeltser.com/media/docs/cyber-threat-intel-and-ir-report-template.pdf。这个模板可以作为一个很好的起点。
其他工具,如 Autopsy,可以输出报告以供纳入取证分析报告。例如,要运行前一章节中进行的分析的报告,请执行以下步骤:
-
在 Autopsy 中打开案件。
-
在顶部栏,点击生成报告。这将打开以下窗口:
图 13.1 – Autopsy 报告生成
根据报告类型,某些信息需要输入。在此案例中,选择了HTML 报告,并需要设置头部和尾部的值。
- 输入信息后,点击在第十一章中使用的
Laptop1Final.E01文件:
图 13.2 – 死因报告生成数据源选择
- 在下一屏幕上,分析员可以选择报告中要包含的结果类型。例如,如果分析员只想报告标记的结果,可以选择该数据集。在这种情况下,所有数据都将被包含,然后点击完成:
图 13.3 – 死因报告生成结果选择
这将开始输出分析的过程:
图 13.4 – 死因报告生成进度
一旦输出完成,它将被保存在与相关案件文件关联的Reports目录中。分析员可以在这里审查信息。其他技术,如打印为 PDF 文件,允许分析员将输出直接附加到报告中。分析员应该熟悉他们的工具集,因为能够直接从工具中导出报告将减少错误,并且在审查时表现得更好。以下是报告的三个重要方面:
-
结论:根据证据得出的结论可以包含在报告中。例如,如果分析员通过将哈希值与已知的恶意软件匹配,判断某个特定的可执行文件是恶意软件,且该恶意软件窃取凭证,那么他们完全有权得出这个结论。然而,分析员应谨慎推测,并且不要在没有充分证据支持的情况下得出结论。响应人员应小心,绝不做出假设或在报告中加入个人观点。
-
定义:由于法医报告非常技术性,包含必要的定义至关重要。内部利益相关者,如法律代表,通常会审查报告,如果预期将采取法律行动,他们可能需要进一步澄清一些技术细节。
-
附件:那些输出内容太长,无法包含在报告正文中的工具输出可以作为附录包含。例如,如果 Volatility 命令的输出有几页长,但最相关的数据只是其中的一行;分析员可以将这一行提取出来并包含在法医分析部分,同时明确说明完整的输出位于附录中。重要的是要将工具的完整输出包含在报告中,以确保其经得起审查。
取证报告的一个关键因素是,在报告作为事件文档的一部分发布之前,必须进行同行评审。这是为了确保所执行的操作、分析和结论与证据相符。这也是分析师应尽可能包括工具输出数据或通过审查所得到的数据的原因之一。如果取证报告进入法庭,分析师需要明白,一个同样或更具资格的取证专家可能会审查报告并对工作提出批评。另一个响应人员或分析师应能够审查报告,查看响应人员的工作描述,并得出相同的结论。知道这一点可能会使分析师更专注于准备他们的报告。
无论一个组织是否选择将文档分开处理或准备一份主报告,报告中都应该包含一些特定的数据。了解这些数据的构成,可以帮助事件响应人员确保在事件调查过程中,正确地做笔记并记录他们的观察结果。如果未能做到这一点,可能意味着所采取的任何行动或观察到的内容未被记录在报告中。此外,如果案件最终进入法庭,证据可能会被排除。与其少做记录,不如多做记录。
准备事件和取证报告
报告的内容可以来自各种来源和形式。将这些信息整合在一起,同时准备实时的笔记记录,有助于确保所有相关事实都被捕捉并报告。
为了全面讨论报告过程,还有两个额外的主题影响整体报告流程。这两个话题分别是做笔记和确保报告中使用正确语言的方式。分析师应特别关注这两个主题,因为它们直接影响报告的质量以及报告的使用方式。
做笔记
经常被忽视,做笔记是分析和报告过程中至关重要的一部分。未能在分析过程中实时做笔记,将使得重新构建事件的详细信息变得不可能,或者在某些情况下,分析师将需要重复过程以捕获必要的数据和证据。
正确的笔记应包括什么内容需要记录部分中提到的具体事项。例如,分析师正在对嫌疑系统的 Prefetch 文件进行检查。以下是一个样本笔记条目:
在 20220617T19:13 UTC 时,通过预取解析器发现系统 DS_453.local 的预取条目,表明在 20220617T02:31 UTC,执行文件 7dbvghty.exe 从 C:\ 目录运行。
前面的条目包含了制作报告详细部分所需的所有必要数据。事实上,任何阅读该笔记条目的人都能重建分析师所做的工作。以下的事件或法医报告条目可以根据该笔记编写:
在 20220617T19:13 UTC,G. Johansen 对系统 DS_453.local Prefetch 文件进行了分析,利用 Prefetch 解析器确定是否执行了任何潜在恶意程序。分析表明,在 20220617T02:31 UTC,文件名为 7dbvghty.exe 的可执行文件从系统 C:\ 目录执行。
在调查过程中,记笔记的重要性不可低估。分析师可能在多个系统上进行分析,并从各种来源获取证据。想象一下,在 12 小时内对 20-30 个系统进行日志审查。在这种情况下,跟踪所有关键数据点和发生的操作几乎是不可能的。
在事件发生时,记笔记有多种选择。有简单的云解决方案,比如 Google Docs,可以利用,但需要注意保持适当的安全性。也可以使用简单的 Word 文档或文本编辑器。此外,还有专门设计用于记笔记的平台。在本例中,我们将看看 Monolith Forensics 的 Monolith Notes。这个应用程序可以在分析机上本地运行,如果团队需要一个协作环境,还有一个专业版,可以部署在云环境中或本地。在这种情况下,我们将查看该工具的开源版本,网址为 monolithforensics.com/case-notes/。
该下载适用于 Windows 或 macOS 操作系统,设置简单。下载文件并执行。一旦安装完成,打开应用程序,下面的屏幕将出现:
图 13.5 – Monolith Notes 主屏幕
作为示例,我们将继续使用该应用程序来汇总笔记,并展示如何导出这些笔记:
- 点击 新建案件,将打开以下窗口:
图 13.6 – 新案件信息
- 输入与案件相关的详细信息。Monolith Notes 可以同时处理多个案件。在此实例中,输入以下信息,完成后点击 提交 按钮:
图 13.7 – 新案件信息
- 要从主屏幕添加笔记,点击 添加笔记 按钮,打开以下自由文本字段:
图 13.8 – 自由文本笔记字段
- 在前面的屏幕中,分析师可以添加自由文本笔记以及屏幕截图。在这个例子中,输入了一个可疑笔记本电脑的 Prefetch 条目的屏幕截图,并附上一条简短的说明。完成后,点击 提交,笔记即被记录:
图 13.9 – 完整的笔记
Monolith Notes 的一个便捷功能是能够对每个笔记条目应用特定标签。例如,在前一截图中,应用的标签是 Execution,它与 MITRE ATT&CK 框架中的一个技术相关(MITRE ATT&CK 框架将在 第十五章 中详细讨论)。这些标签可以在添加新笔记时应用。标签的优势在于,当分析师需要回过头查看与应用程序执行相关的所有证据项目时:
图 13.10 – Monolith Notes 筛选器
最后,Monolith Notes 可以将笔记导出为 Microsoft Word 文档。这使得移动屏幕截图以及剪切和粘贴特定数据(如时间戳、代码块或其他工具输出)变得更加容易。
报告语言
为了完善报告部分的讨论,重要的是要特别说明如何构建报告的语言,尤其是法医报告。执行摘要和事件报告通常会采用叙述性的语气,具体来说,描述事件发生的步骤和顺序。真正的根本原因分析才会根据证据给出结论。
技术报告中的陈述可以分为三类,这三类陈述描述了数据以及最终结论是如何呈现的:
-
C:\Windows\Prefetch目录。 -
C:\Windows\Prefetch目录。Prefetch 目录中的条目表明某个可执行文件 已被执行。 -
C:\Windows\Prefetch目录。Prefetch 目录中的条目表明某个可执行文件已被执行。这表示在 20220617T1913 UTC 时,sample.exe* 文件被执行的可能性非常高。*
除了所使用的语言外,分析师在准备报告时还应确保遵循一些额外的指南:
-
基于数据的结论:正如我们在制定评估性陈述时看到的那样,分析师得出结论是可以的,但必须有数据支持。任何在分析及随后的报告过程中得出的结论,都需要有坚实的数据来支持。
-
PSEXEC.exe或远程桌面协议与被攻破的凭据一起使用,但由于缺乏日志记录,他们无法确定精确的横向移动方法。 -
可重复性:一份全面且写得好的技术报告应该是那种,在给定相同证据的情况下,分析员在没有事先了解该事件的前提下,也能重建你的发现。这对于执法部门或需要作证的分析员尤其重要,因为报告及相关证据将提供给另一方。
报告中使用的语言与其中所有分析工作同样重要。写得不好的报告,结论错误且语言不当,可能给读者留下负面印象。如果证据将作为民事或刑事诉讼的一部分被提交,可能所有的工作都不能被接受。分析员应该在掌握技术技能的同时,培养良好的记笔记和写作能力。
摘要
事件响应团队在准备和执行处理事件所需任务方面投入了大量精力。同样重要的是要适当记录事件,以便决策者和事件响应团队自身能够清楚了解所采取的行动以及事件发生的原因。正是通过使用这些文档并分析根本原因,组织可以提高其安全性,并降低未来发生类似事件的风险。事件响应者和取证分析员关注的一个重要领域是恶意软件在事件中的作用。
问题
请回答以下问题,以测试你对本章的理解:
-
什么不属于取证报告的内容?
-
使用的工具
-
检查员简历 / CV
-
注意事项
-
展品清单
-
-
在准备事件报告时,需要考虑到阅读该报告的受众。
-
正确
-
错误
-
-
以下哪项是可以在准备事件报告时利用的数据源?
-
应用程序
-
网络/主机设备
-
取证工具
-
上述所有
-
-
事件响应者绝不应将根本原因分析包含在事件报告中。
-
正确
-
错误
-
深入阅读
请参考以下内容,了解本章所涵盖的更多信息:
-
数字取证报告写作简介:
digital-forensics.sans.org/blog/2010/08/25/intro-report-writing-digital-forensics/ -
理解数字取证报告:
www.legalexecutiveinstitute.com/understanding-digital-forensics-report/ -
数字取证报告,Ryan Nye:
rnyte-cyber.com/uploads/9/8/5/9/98595764/exampledigiforensicsrprt_by_ryan_nye.pdf -
磁力取证技术层面发现指南:
www.magnetforensics.com/resources/reporting-findings-at-a-technical-level-in-digital-forensics-a-guide-to-reporting/
第四部分:勒索软件事件响应
勒索软件是一种持续的威胁,需要结合前三个部分的内容。接下来的两个章节将重点讲解如何使用之前章节中提到的工具和技术来应对勒索软件事件。同时,还会补充一些额外的工具和技术,帮助调查勒索软件事件。
本部分包括以下章节:
-
第十四章*,勒索软件准备与响应*
-
第十五章*,勒索软件调查*