“实战 Windows 取证”之时间线分析

发表于 2019-01-08  161 次阅读


 在这里,我们将介绍下应急响应中非常重要的一环——时间线分析。 我们将学习一些使用 The Sleuth Kit 和 Plaso Framework 进行时间线分析的不同方法。 我们还将介绍一些特定于某些文件系统的理论问题,以及它们如何与文件时间相关的属性协同工作。 此外,我们将演示如何在实践中使用 Plaso。 简而言之,我们将涵盖以下主题: 

  • 时间线
  • The Sleuth Kit(TSK)
  • Plaso 架构
  • Plaso 实战

时间线介绍 

在取证方面非常突出的一个问题是“什么时候?” 

       换句话说,时间是在取证分析过程中的一个非常重要的因素。 我们在调查中使用了许多具有时间特征的工件(artifacts)。这些特征使我们能够构建事件的全貌。

       此外,时间线分析可以帮助我们分析不同类型的证据。时间线分析可以建立在任何具有时间戳的源的基础上。这可以是文件系统,注册表,事件日志文件,应用程序的日志文件,内存,网络流量等的元数据。

       当然,时间线是数字取证中最有用的技术之一。 但是,这是基于对特定工件的分析,因此了解如何分析时间线事件供应商的工件(artifacts)非常重要。

       尽管时间线背后的想法显而易见,但在实践中,并非如此简单。 其中一个困难是必须分析大量数据。运行系统的问题在于,有少数用户和许多系统服务会产生大量事件。我们需要从普通用户中过滤掉这些活动。

       时间线的想法并不是很新。它自2000 年以来一直存在,当时Rob Lee 和其他一些取证人员开始将其应用于数字取证。最初,文件系统充当时间线的数据源。 我们将会考虑NTFS文件系统 作为我们评论中最流行的文件系统。

       NTFS文件系统的时间线基于文件系统对象的某些属性中的时间戳。 文件系统的每个对象都有以下时间戳:

⚫ M:这是数据修改的日期 

⚫ A:这是数据访问的日期 

⚫ C:这是元数据更改的日期 

⚫ B:这是元数据创建的日期 

       根据对此数据的分析,我们可以确定何时创建,复制,移动文件等。 NTFS 文件系统使用 FILETIME 作为UTC中的时间格式。UTC 是协调世界时。 FILETIME 包含一个 64 位值,表示自 1601 年 1 月 1 日(UTC)以来 100 纳秒间隔的数量。MS Windows 还使用其他时间格式。 它们是 UNIX 时间格式,DOS 日期格式和 SYSTEMTIME 格式。

      此外,我们应该强调一些文件在不同文件系统中移动的情况,例如,文件被复制到 USB key。 在大多数情况下,USB 使用 FAT32 文件系统,因此 FAT32 系统 上的文件具有不同的属性,并且时间戳位于 NTFS 和 FAT32 文件系统上。

       让我们考虑在 NTFS 文件系统上创建文件,然后被复制到使用 FAT32 文件系统的 USB 的情况。 在这种情况下,修改日期保持不变,但 USB 驱动器上的 C 日 期会发生变化,并且符合 USB 上的文件创建的日期。 微软已经解释了在不同的情况下如何改变属性: http://support.microsoft.com/kb/299648。

       以下是与日期和时间戳有关的文件属性: 

⚫ 在将文件从 C:\fatfolder 复制到 C:\fatfolder\subfolder 的情况下,它保持相同的修改日期和时间,但将创建的日期和时间更改为当前日期和时间

⚫ 如果文件从 C:\fatfolder 移动到 C:\fatfolder\subfolder,它会保留相同的修改日期和时间,并保持相同的创建日期和时间 

⚫ 如果文件从 C:\fatfolder 复制到 D:\NTFSfolder,它会保留相同的修改日期和时间,但会将创建的日期和时间更改为当前日期和时间 

⚫ 如果文件从 C:\fatfolder 移动到 D:\NTFSfolder,它将保留相同的修改日期和时间,并保持相同的创建日期和时间 

⚫ 如果文件从 D:\NTFSfolder 复制到 D:\NTFSfolder\SUBfolser,它会保留相同的修改日期和时间,但会将创建的日期和时间更改为当前日期和时间 

⚫ 如果文件从 D:\NTFSfolder 移动到 D:\NTFSfolder\SUBfolder,它会保留相同的修改日期和时间,并保持相同的创建日期和时间 

       在所有情况下,除非文件的属性已更改,否则修改文件的日期和时间不会更改。

       创建文件的日期和时间会根据文件是复制还是移动而更改。 

       以下是与日期和时间戳有关的文件夹属性: 

⚫ 如果在NTFS分区上创建了两个名为D:\ NTFSfolder1和D:\NTFSfolder2的新文 件夹,则创建和修改的日期和时间都相同。

⚫ 如果将 D:\NTFSfolder2 文 件 夹 移 动 到 D:\NTFSfolder1 文件夹,创建 D:\NTFSfolder1\NTFSfolder2,则会发生以下情况: 

    1. D:\NTFSfolder1:这是创建的文件夹相同且修改后的 stamp 更改的时间。

    2. D:\NTFSfolder1\NTFSfolder2:这是创建的文件夹(时间)更改并且修改的 文件夹保持不变时。 出现此问题的原因即使您移动了文件夹,新文件夹被视为由主文件表(MFT) 在 D:\NTFSfolder1 文件夹中创建。 

⚫ 如果将 D:\NTFSfolder2 文件夹复制到 D:\NTFSfolder1 文件夹,则创建 D:\NTFSfolder1\NTFSfolder2 文件夹,并且 D:\NTFSfolder2 文件夹仍然存在(复 制后):

     1. D:\NTFSfolder1:这是创建的文件夹相同,并且修改后的文件夹时间和日期标记更改的时间。 

    2. D:\NTFSfolder2:这是因为它是原始文件夹而没有发生更改。 

    3. D:\NTFSfolder1\NTFSfolder2:这是当创建的文件夹和修改后的文件夹都更改为相同的标记时,即移动时的标记。

    出现此问题的原因即使您复制了文件夹,新文件夹被视为由 MFT 创建,并给 出一个新的创建和修改时间戳。 

       FAT 文件系统在修改的时间戳方面具有不同的行为。 在 FAT 文件系统上,如果文 件夹的内容发生更改,则文件夹的修改日期不会更改。例如,如果将 D:\FATfolder2 复制或移动到 D:\FATfolder1 中,则 D:\FATfolder1 的创建日期和修改日期保持不变。

       下表根据文件操作反映了属性的更改: 

  当我们谈论移动动作时,我们的意思是使用 Windows 资源管理器移动文件以及剪切和粘贴过程,而不是命令行中的移动命令。 

      我们要提到的另一件事是,一些调查人员错误地认为禁用上次访问的时间将停止对文件上次访问时间的任何更新(默认情况下为 Vista +)。 这是不正确的。 在 复制或移动命令的情况下,最后访问的时间将被更改; 只有文件打开时它才会保持不变。 

       此外,通过在文件系统边框中的 Windows 资源管理器中剪切和粘贴来移动文件不会更改创建时间。 但是,如果使用 move 命令在命令行上移动文件,则会更改它。 

The Sleuth Kit 

让我们考虑创建文件系统时间线的各个阶段。创建时间线的第一步是构建正文文件。 

       要收集三种类型的数据: 

⚫ 存在于文件系统文件中,我们可以使用 dir 或 ls 命令列出。 

⚫ 已删除的文件,但它们的结构仍然存在。这允许恢复文件的完整路径和其他属性。 但是,这取决于文件系统,因为并非所有文件系统都允许这样做。

⚫ 未分配的 inode($ Orphan 文件),它们是不再存在的文件结构。 

       要构建一个 bodyfile,我们将使用 TSK 的 fls 工具。 fls 工具允许与文件系统交互取证镜像,并从文件系统级别提取时间线数据。 这将获取 inode 目录的值,处理其内容,并显示目录中文件的名称(包括已删除 的文件)。 如果 inode 的值不存在,它将显示根目录的内容: 

在我们的例子中,最重要的选项之一是-m,它允许以与 mactime 工具一起使用 的格式输出: 

因此,如果您有 image.dd 并且想要创建时间轴,则应输入以下三个命令: 

mmls image.dd 

fls -m -o <offset of fs partition> -r images.dd >body.txt 

mactime -b body.txt -z TZ > timeline.txt 

超级时间线 - Plaso 

文件系统不是包含系统中事件时间戳的唯一数据源。 当计算机工作时,即使用户不做任何事情,也会发生很多事件在系统中。 例如,Windows XP 每 24 小时 创建一个系统还原点,每三天运行一次磁盘碎片整理,以便重写已删除文件的扇区。 Windows 7 具有卷影复制机制,该机制还可以创建备份文件等 。 所有这 些操作都自动发生,无需任何用户活动。所以,即使在空闲模式下, Windows 有很多事件。 如系统有活跃用户,我们会看到更多的事件。 有关这些事件的信 息将反映在不同的地方:在注册表,事件日志文件,应用程序的日志文件,浏览 器历史记录等。 

       如果我们可以在时间线中使用所有这些来源,我们可以全面了解系统中发生的事情,并在逻辑链中关联不同的事件。 这种方法被称为超级时间线。

      要分别从不同来源构建超时间轴,然后合并结果可能是一个复杂而长期的过程。 但是,因为很酷的工具,例如 Plaso 框架,这项任务变得更加容易。

       Kristinn Gudjonsson 创建了 log2timeline 工具,允许以自动方式创建超级时间线。 最初,它是用 Perl 编写的,但后来用 Python 重写。 Python 版本现在称为 Plaso。 它具有许多功能和灵活的架构。它允许添加新的解析器和插件来处理新 类型的数据。 

Plaso 架构 

      我们来看看 Plaso 架构。 Plaso 有一些核心组件可以执行独立的角色: 

⚫ 预处理 

⚫ 采集 

⚫ Worker 

⚫ 存储 

       让我们更详细地看一下。 

预处理 

      在此阶段,应在所有其他处理之前完成一些预处理任务。例如,在安装映像并确定磁盘上安装了哪个 OS 之前,请收集一些将在下一阶段使用的信息。 

       预处理过程应收集以下内容: 

⚫ 操作系统的版本 

⚫ 主机名 

⚫ 时区信息 

⚫ 默认应用程序,例如默认浏览器等 

⚫ 枚举所有用户及其路径 

采集阶段 

      在采集阶段,该过程遍历图像,目录或装入点,并查找该工具可以处理的所有文件。 该集合可分为三种不同的场景: 

⚫ 在最简单的情况下,收集过程递归地通过挂载点或映像文件,并收集发现的每个文件。 

⚫ 在递归扫描期间,如果要解析 VSS,则基于每个文件的四个时间戳计算散列。 在收集阶段,从 VSS 映像中,将散列值与该文件的现有散列进行比较。 如 果以前没有收集过该文件,则包含该文件; 否则,它被跳过。 

⚫ 在目标集合的情况下,定义了一组文件路径,并且仅收集适合该模式的文件。

Worker 

       Worker 是 Plaso 的主要部分。 Worker 应该监视进程队列,并处理进入那里的每个文件。 在处理文件期间,Worker 将执行以下操作: 

⚫ 确定文件类型 

⚫ 确定应该将哪些解析器应用于它 

⚫ 解析文件并从中提取所有事件 

⚫ 将一些已定义的过滤器应用于文件 

⚫ 将提取的事件发送到存储队列 

⚫ 确定此文件是否包含可以处理/提取的其他文件,并处理它们 

存储 

       在存储阶段,来自存储队列的事件将写入磁盘。 现在,让我们考虑一下 Plaso 框架中的主要工具: 

⚫ log2timeline:这是 Plaso 后端的主命令行前端。 此工具可用于从图像,装入点或文件中提取事件,并将其保存在 Plaso 存储文件中以供将来处理和分析。

⚫ Pinfo:此工具允许提取包含在 Plaso 存储中的信息。 它是一个简单的工具, 可以从存储文件中打印出信息。 

⚫ pprof:这是一个小工具,对于开发人员和那些有兴趣尝试优化某些解析器的 人来说非常有用。

⚫ preg:此工具为注册表解析器提供了不同的前端。 它解析映像或注册表配置 单元,并为用户提供控制台或 shell 以使用注册表。 

⚫ pshell:这是 Plaso 后端的 iPython 控制台。 该 shell 为用户提供了对 Plaso 所 有库的访问,并提供了对输出,调试和实验的更高级分析的访问。 

⚫ psort:Plaso 的存储格式不是人类可读的格式,psort 允许将它转换为更方便 的格式。 它用作后处理工具来过滤,排序和处理 Plaso 存储文件。 

实战 Plaso 

       让我们来看看我们如何在实践中使用 Plaso。 

       让我们假设我们有一张来自受感染 PC 的硬盘驱动器映像,现在我们需要调查这 个案例来弄清楚感染是如何发生的。 

       首先,我们需要观察映像并确定需要分析的分区。 为此,我们需要使用 TSK 的 mmls 工具。 

       然后,我们可以使用 log2timeline 构建 bodyfile:

现在,我们将使用动态格式输出。 动态输出格式允许将过滤规则设置为类似 SQL-SELECT 的请求。 我们将根据以下事件属性构建规则: 

当我们浏览已执行文件的列表时,我们发现了一个带有可疑名称的文件 ZkPECED.exe。 我们现在可以将它作为时间线调查的关键点。 

因此,我们可以过滤所有文件,其中包含文件名中的 ZkPECED 字符串。 

 下图显示了搜索与名称中包含 ZkPECED 关键字的文件相关联的事件的结果,从中 可以清楚地看到 2014 年 4 月 8 日,UTC 时间 12:39:08(16:39:08 UTC + 4) ,在 \Users\Alina\AppData\Local\Temp 目 录 中 创 建 了 两 个 名 为 ZkPECED.tmp 和 ZkPECED.exe 的文件: 

使用--sliceDateTime 和 -  slice_sizeMinutes 参数以及 psort.py 实用程序,我 们可以将样本数据从文件存储(timeline.body)限制为在[DateTime-Minutes, DateTime + Minutes]时间范围内发生的事件。

由于我们不知道 ZkPECED.exe 文件可执行文件的来源,我们搜索在 12:39:08 UTC 的 10 分钟内创建或修改的所有可执行文件:

请注意,就在 ZkPECED.exe 文件出现之前,systemhost 目录中具有可疑名称24FC2AE3CB0.exe(inode 46912)的文件的元数据已更改(意味着该文件已重命 名或在本地移动),尽管其他时间戳记 (创建,上次修改和上次访问)请参阅 2010 年:

使用TSK套件中的istat实用程序,我们获取有关24FC2AE3CB0.exe文件(inode 46912)的属性的信息:

上面的屏幕截图显示$ STANDARD_INFORMATION 和$ FILENAME 属性中包含 的时间戳不匹配,这可能表示 24FC2AE3CB0.exe 文件(inode 46912)的时间戳已 手动更改。

因此,可以假设 24FC2AE3CB0.exe 文件(inode 46912)是在 4 月 8 日 12:31:44 UTC(16:31:44 UTC + 4)创建的,并且它的时间戳(创建,最后修改,和 最后一 次访问)被“手动”更改,这是恶意软件的迹象之一。

分析结果 

       对 WinRegistryParser 处理模块结果的分析确定,两个可疑可执行文件的链接都存储在 Windows 注册表项中,这些注册表项负责在系统启动时自动运行程序:

屏幕截图还显示了每个注册表项的最后修改时间。 

由于24FC2AE3CB0.exe文件的来源是未知的,我们搜索在UTC时间12:31:49之前创建的文件, 不包括搜索结果中包含安全扩展名的文件:

该命令的结果如下:

屏幕截图显示,在 24FC2AE3CB0.exe 文件出现前几秒,jp2launcher.exe 文件 进程已启动。 它启动 Java applet 和.jnlp 文件的 Java 虚拟机。 因此,在此之后, 创建了两个名为 7d088b-2be562b3.idx(inode 48067)和 57ebc62f-6dfa622f.idx (inode 48074)的 Java.idx 文件。 JavaIDXParser 处理模块的结果为我们提供了有关 Java 虚拟机中加载的对象 的一些信息:

    屏幕截图中显示的信息显示从 URL http://finansial.gov(IP 85.17.137.151)下 载了名为 utisl.jar 的 Java 存档,并从 URL h t t p : / / w 2 8 2 d 1 w b . a t h l e t i c s d r y c l e a n e r . p w / f / 1 3 8 9 9 3 1 6 2 0 / 4 0 6 7 1 1 4 5 2 4 / 下载了名为 2 的未 知对象。

     utisl.jar Java 文档保存在 

/Users/Alina/AppData/LocalLow/Sun/Java/Deployment/cache/6.0/11/7d088b-2 中 be562b3 文件(inode 48068 ),以 及 中 名 为 2 的 未 知 对 象 / Users/Alina/AppData/LocalLow/Sun/Java/Deployment /cache/6.0/47/57ebc6 2f-6dfa622f(inode 48075)。 

      在The Sleuth Kit套件中的icat实用程序的帮助下,我们可以获取两个Java IDX 文件的内容,从中我们提取 Java 虚拟机下载的对象的大小: 

屏幕截图中显示的输出表明 utisl.jar 文件(«7d088b-2be562b3»)的大小为 14,052 字节:

      图中显示的输出表明对象 2(57ebc62f-6dfa622f)是 411,648 字节。 

这是因为,根据 istat 和 icat 实用程序的输出,/ sysystem / 24FC2AE3CB0.exe(inode 46912)和/ Users / Alina / AppData / LocalLow / Sun / Java /的大小和内容 Deployment/cache/6.0/47/57ebc62f-6dfa622f(inode 48075)文件匹配:

可以假设在 2014 年 3 月 13 日,从 URL h t t p:/ / f i n a s s a l 下载了一个 Java applet. gov(IP 85.17.137.151),在启动时,下载了一个大小为 411,648 字节的可 执行文件。 该文件的正文保存在/systemhost/24FC2AE3CB0.exe 文件中。 指向可 执行文件的链接已添加为 HKCU \ Software \ Microsoft \ CurrentVersion \ Run 注册 表项中的 YI9B2F0F6EXG1Y1ZLMA 参数,该注册表项负责在操作系统启动时自动 运行程序。

MsiecfParser 解析器的结果表明,在 2014 年 4 月 8 日 UTC 时间 12:31:13 使 用 Internet Explorer 时,用户可能在不知不觉中访问了资源 http://finansial.gov, 其中包含 utisl.jar Java applet 随后被下载并执行:

接下来,在分析 WinEvtxParser 处理模块的结果时,我们在 2014 年 4 月 8 日出现Java .idx 文件后,从系统中的 Windows 安全日志(Security.evtx)中选择成功的身 份验证事件(EventId 4624), 12:31:13 UTC: 

要以更方便的形式显示结果,我们可以使用以下命令进行转换:

sed -r "s/^([^\[]+),.+Strings: \[(.+)\]$/\1\ \2/" | 

sed -r "s/\s*u'([^']+)'\s*/\|\1\|/g" | 

sed -r "s/\|+/\|/g" | 

awk 'BEGIN {FS="\\|"; OFS=", "}; {print $1, $7, $8, $6,$10, $20, $21}' 

您可以在以下屏幕截图中看到它们:

请注意,身份验证类型(LogonType)10 表示目标系统通过 RDP 协议建立连接。

      屏幕截图显示,在 4 月 8 日,用户 SYSTEMERVICE 创建了几个 RDP 协议连接。 注 意两个特性:连接是使用 IP 地址 127.0.0.1(环回)进行的,即有效地从被调查 的计算机到自身; 并且用户 SYSTEMSERVICE 的安全标识符(SID)是不同的,即, 用户在指定的时间间隔内重建了几次。 

      通过过滤 WinEvtxParser 模块的 EventId 4720(用户创建)和用户名 SYSTEMSERVICE 的结果,我们得出结论,指定的用户最初是在 4 月 8 日 12:40:52 UTC 创建的,之 后又进行了三次尝试 重新创建它:

 因此,现在我们可以为事件建立一个可能的场景:2014 年 4 月 8 日,用户 Alina 可能在不知不觉中访问了资源:h t t p : / / f i n a n s i a l . g o v,其中包括,下载 并执行了 utisl.jar 这个 Java applet。

   接下来,从 URL

http://w282d1wb.athleticsdrycleaner.pw/f/1389931620/4067114524/下载了一个 大小为 411,648 字节的未知对象,其主体保存在/ systemhost / 24FC2AE3CB0.exe文件中。 指向可执行文件的链接已添加为 HKCU \ Software \ Microsoft \ CurrentVersion \ Run 注册表项中的 YI9B2F0F6EXG1Y1ZLMA 参数,该注册表项负责 在系统启动时自动运行程序。

此后,系统重复创建名为 SYSTEMSERVICE 的可疑用户,在该用户下通过 RDP 协议与系统建立本地连接。 

本站文章基于国际协议BY-NA-SA 4.0协议共享;
如未特殊说明,本站文章皆为原创文章,请规范转载。

0

Follow my heart. Ожидающий вас.