在本系列的这一点上，我们了解到攻击技术是抽象的概念，必须以工具或软件应用程序的形式实例化。我们还了解到，在（子）技术、OS Credential Dumping： LSASS Memory 和 Mimikatz 工具之间存在许多抽象层。在本系列的过去几篇文章中，我们探讨了这些层，特别是功能层和操作层。例如，在下面，我们看到与 mimikatz 的命令相对应的“操作链”或“程序”。在这里，我们看到形成链的操作是 .sekurlsa::logonPasswordsProcess Enumerate -> Process Access -> Process Read

在本文中，我希望演示操作层如何成为那些有兴趣创建行为检测分析的人的适当分析层。

注意： 在这种情况下，行为检测分析侧重于恶意软件的行为，而不是恶意软件是什么。它将动作与演员解耦。这并不是说根据已知的恶意恶意软件来检测它是一个坏主意;我们只是试图采取下一个合乎逻辑的步骤。

相关视频教程

恶意软件开发（更新到了155节）

在她2009年出版的《水果、树和蛇》一书中，琳恩·伊斯贝尔（Lynne Isbell）探讨了她的观点，即人类的视觉感知是由于我们的祖先和蛇之间的关系而发展起来的。一般的建议是，直到最近，人类还以蛇为主要捕食者，这意味着“蛇检测”对我们的感官发展起到了选择性压力的作用。如果人类无法识别蛇，那么它们很可能会屈服于捕食，因此不太可能繁殖。这意味着随着时间的流逝，我们的视觉感知发展到更适应检测蛇，这通常不是一件容易的事。你看，蛇在地面上滑行，通常是在高高的灌木丛中，并伪装成它们的环境。伊斯贝尔提出，为了适应这一事实，人类的视觉感知最终对运动中的物体而不是静态物体变得更加敏感。这个提议是，选择的作用是确保现代人看到他们需要看到的东西才能生存。世界上有太多的信号让我们无法关注这一切，因此我们必须优先考虑最有可能重要的信号。这就是为什么我们使用“注意”这个词。这个想法是，注意力是一种有限的资源，我们必须明智地使用;归根结底，参加的过程是下意识地完成的。

虽然这在生物世界中可能行之有效，但同样的原则是否适用于网络领域并不明显。我们在网络世界中的感知是人造的或人为的，因此假设它通过选择得到适当的适应可能是一个巨大的飞跃。一个值得问的问题是，你是否相信反馈是以足够有效的方式产生的，可以磨练我们在网络空间中的感知能力。如果端点检测和响应 （EDR） 传感器在这个空间中相当于我们的眼睛的功能，我们如何知道它正在优先考虑那些与我们的检测能力最相关的事件？

在本文中，我希望将我们的概念模型（操作链）与我们感知 EDR 事件的能力联系起来。我们将探讨操作链如何提供一个公式来预测执行特定样本或操作链后应该遇到的事件类型。我们还将比较和对比两种 EDR 解决方案，以了解它们感知某些操作的能力的差异。最重要的是，我们将证明我们对操作的感知。

我们收集的事件是操作的同义词。这意味着，在我们能够证明并非如此之前，在抽象中，恶意软件样本的最佳分析级别是操作级别。我一直在使用“使你的概念与你的感知保持一致”这句话来帮助我们的团队了解如何思考攻击者的行为。在这句话中，“概念”表示你思考行为的模型，“感知”表示你用来理解环境中的活动的事件。如果这两个概念不一致，那么你一开始就处于劣势。

让我们深入研究一下吧！

一个好的检测工程师应该了解他们如何看待他们的网络环境。人类存在于生物环境中，并具有硬件（感觉器官，如眼睛、耳朵、皮肤等），使他们能够接收来自环境的信号以感知它。尽管人类有五种感官，这意味着他们有能力感知五种不同类型的信号，但我们知道世界上存在一些我们无法自然感知的信号。例如，我们知道鲨鱼有能力通过一种称为电感应的感觉来感知电流。不幸的是，我们的生物感官在人工网络环境中无法提供任何自然的感知价值。因此，我们构建了传感器来捕获信号并以我们可以摄取和处理的方式转换它们。随着时间的推移，这些传感器已经发展，可以说，变得更加复杂。那么，在网络环境中，我们用什么作为我们的眼睛和耳朵呢？答案很简单，我们使用硬件和软件传感器（如 EDR 代理和网络监控传感器）来捕获来自环境的信号，并以我们可以使用的方式将它们呈现给我们。由于 EDR 是检测工程中使用的遥测数据的重要来源，因此我想重点讨论 EDR 传感器如何以及究竟能看到什么。

为了回答这个问题，我认为从多个 EDR 中挖掘一些事件是很有价值的，只是为了证明为什么我声称我们以事件的形式看到的实际上是正在执行的操作。下面是描述经典远程线程注入的一系列操作（即操作链）。我们看到操作链由四个操作组成，下面将更详细地讨论每个操作：

进程打开

我们看到的第一个操作是 Process Open。进程是 Windows 操作系统上的安全对象，其结构位于内核中。这意味着用户模式应用程序没有直接与它们交互的自由支配权。相反，请求应用程序（在本例中为恶意软件）必须打开一个句柄，然后可以使用该句柄以多种不同的方式与进程进行交互。句柄的打开是基于请求进程的令牌和目标进程的自由访问控制列表 （DACL） 进行访问检查的点。如果访问检查失败，请求者将收到错误作为响应。ACCESS_DENIED

内存分配

获得进程句柄后，有必要在远程进程中分配一个内存缓冲区，该缓冲区将用于保存注入的 shellcode。此操作取决于 Process Open 操作生成的句柄。具体来说，必须使用访问权限打开句柄。此步骤是必需的，因为源（注入）进程必须使代码在目标（注入）进程可访问的位置可用。PROCESS_VM_OPERATION

进程写入

在目标进程中分配缓冲区后，可以将恶意 shellcode 写入该缓冲区。同样，使用生成的进程打开操作的进程句柄;但是，在这种情况下，需要访问权限。进程写入操作是操作链的组成部分，它使此操作被视为“注入”。一旦代码被写入目标进程的内存空间，最后一步就是找到一种方法来强制目标进程执行代码。PROCESS_VM_WRITE

线程创建

最后的操作侧重于执行注入的代码。执行代码的传统方法是创建一个新线程，该线程设置为执行位于内存分配操作期间分配的缓冲区中的代码。多年来，已经发现了许多替代的执行机制，但为了简单起见，我们将在本文中坚持使用 Thread Create 操作。

一旦建立了操作链，检测工程师就拥有了开始考虑检测的实际组成部分所需的信息。具体而言，操作链提供识别与相关行为相关的事件或日志所需的详细信息。在本节中，我们将探讨两个常见的 EDR 平台生成的相关事件，并演示我们收集的事件侧重于操作级别。这意味着，如果可以识别恶意软件示例实现的操作，则可以将它们与 EDR 平台捕获的遥测数据相关联。这有利于有意的检测工程。

注意：需要注意的是，有许多独特的操作链实现了工艺注入技术。在本文中，我们将重点介绍一个操作链，该操作链被认为是该技术的原型。我发现，与我们教授数学等复杂主题的方式类似，最好先教检测工程师为单个操作链构建检测。一旦他们适应了单操作链的工程检测，他们就可以开始考虑多链检测工程的后果。然而，如果他们缺乏单链基本面，他们将不可避免地难以为多链找到有效的解决方案。

Microsoft Defender for Endpoint （MDE）

现在，假设你为使用 Microsoft Defender for Endpoint （MDE） 作为 EDR 的组织工作。如果我问您哪些 MDE 事件可用于此特定操作链，您可能会立即想到许多不同的选项。事实上，我之所以选择 MDE，是因为它为这个链中的每个操作生成一个事件，我认为这恰恰说明了本文的观点。我希望演示的一般经验法则是 EDR 产品感知操作。让我们看一下每个操作，并考虑哪些 MDE 事件报告了它们。

将 MDE 事件与操作相关联的第一步是熟悉可用的事件类型。首先，我建议参考 Microsoft 的数据表文档。虽然 MDE 中提供了许多补充表，但我发现下面屏幕截图中显示的表是我用作检测工程工作基础的主要表。

分析此列表后，您可能会想，“我没有看到与进程打开、内存分配、进程写入或线程创建相关的任何内容”，您是完全正确的。这里的诀窍是这张桌子隐藏着一个事件的宝库，所以下一步就是深入研究它。当我们浏览到该表的文档页面时，我们发现该列是发现该表中存在的所有不同事件类型的关键。请注意“提示”标注，其中建议使用 MDE 中的内置模式引用来发现支持的值。如果您的组织使用或有权访问 MDE，我强烈建议您花一些时间来做这件事。DeviceEventsDeviceEventsActionTypeActionType

但是，如果您无法访问 MDE，那么我们将人为地进行此探索。在他的博客文章中，他将 Sysmon 的遥测生成功能与 MDE 的遥测生成功能进行了比较：

奥拉夫·哈通

提供了这个很棒的电子表格，其中包含他在发布帖子时（2021 年 10 月）可用的所有操作类型。该列表可能在随后的几年中有所增加，但对于本文而言已经足够了。我们将使用此列表将值与链中的相关操作相关联。ActionType

进程打开 -> OpenProcessApiCall

如本文前面所述，Process Open 操作是链中的第一个操作。当我们引用 Olaf 在表中可用的值列表时，我们看到了一个突出的值。以 API 函数命名的 Process Open 事件。重要的是要了解，尽管名称与特定的 API 函数相关，但事件本身是在内核中生成的，因此对功能更改具有弹性。这意味着无论是否调用 、 、 或 函数，都会生成事件。有关如何在内核中生成此事件的更多信息，我建议查看 Jonathan Johnson 关于该主题的优秀博客文章。ActionTypeDeviceEventsActionTypeOpenProcessApiCallActionTypeOpenProcessActionType’skernel32!OpenProcesskernelbase!OpenProcessntdll!NtOpenProcesssyscall!NtOpenProcess

下面是用于查找这些事件的 Kusto 查询示例：

DeviceEvents |
where ActionType == "OpenProcessApiCall"

注意：特别是 MDE 对此事件实施了一定程度的过滤。虽然实际的 Windows 事件跟踪 （ETW） 提供程序捕获所有进程打开，但 MDE 将仅转发 lsass.exe 是目标进程的事件。虽然此决定不会影响某些技术，例如操作系统凭据转储：LSASS 内存，但它将严重影响其在进程注入方面的实用性，因为不能保证目标进程是 lsass.exe。

内存分配 -> NtAllocateVirtualMemoryRemoteApiCall

按照类似的过程，我们发现有两个与内存分配操作相关的操作：和 。同样，尽管名称侧重于特定函数名称，但这些事件是在内核中生成的，因此会捕获内存分配函数调用堆栈中的所有用户模式函数。ActionTypesNtAllocateVirtualMemoryApiCallNtAllocateVirtualMemoryRemoteApiCall

乔纳森·约翰逊

再次帮助我们完成了他出色的 TelemetrySource 项目，他在该项目中显式映射了如何通过 Microsoft-Windows-Thread-Intelligence ETW 提供程序生成这些事件。

我们的下一个问题是这两个事件是否与我们的特定用例相关。我们发现，第一个事件 ，是在本地（在调用进程内）分配内存时生成的;而第二个事件 ，是在远程进程中完成内存分配时生成的。由于我们特别关注进程注入，这意味着注入发生在远程进程中，因此我们可以肯定地说，我们只对事件的版本感兴趣。NtAllocateVirtualMemoryApiCallNtAllocateVirtualMemoryRemoteApiCallNtAllocateVirtualMemoryRemoteApiCall

DeviceEvents |
where ActionType == "NtAllocateVirtualMemoryRemoteApiCall"

进程写入 -> WriteToLsassProcessMemory

第三个操作是进程写入。此时，链中已打开一个句柄，并在远程进程中分配了一个缓冲区。现在是时候将恶意 shellcode “注入”或写入该缓冲区了。同样，此操作需要在第一步中获取的目标进程的句柄，并且这次句柄必须具有访问权限。Process_VM_READ

在查阅MDE表中的ActionTypes列表后，我们发现 WriteToLsassProcessMemory 。从技术上讲，此事件与进程写入操作一致，但不幸的是，范围比我们希望的要窄一些。DeviceEventsActionType

注意：这个事件曾经被称为 ;但是，在 2021 年 2 月，Microsoft 根据消费者反馈对其进行了重命名，以便事件名称更接近地表示存在的筛选条件。WriteProcessMemoryApiCall

虽然 MDE 仅限于目标进程为 lsass.exe 的进程写入操作，但用于生成这些事件的基础机制提供了更大的覆盖范围。根据 Jonny 的遥测源项目，这些事件由 Microsoft-Windows-威胁-情报 ETW 提供程序生成。任何EDR都可以订阅此提供商，只要它们满足Microsoft提出的某些标准，并且这些供应商可以做出自己的过滤决策。通常，ETW 提供程序用于标识本地进程写入 （Windows 事件 ID 12） 和远程进程写入 （Windows 事件 ID 14） 。在工艺注入的背景下，我们对后者更感兴趣。WriteToLsassProcessMemoryActionType

DeviceEvents |
where ActionType == "WriteToLsassProcessMemory"

线程创建 -> CreateRemoteThreadApiCall

最后一个操作是线程创建操作。此步骤需要两个基本输入，首先是目标进程的句柄。此句柄必须包括 、 、 和 访问权限。此外，还必须提供包含 shellcode 的内存缓冲区的地址。执行此操作后，将创建一个新线程，该线程将执行 shellcode 并完成“注入”例程。PROCESS_CREATE_THREADPROCESS_QUERY_INFORMATIONPROCESS_VM_OPERATIONPROCESS_VM_WRITEPROCESS_VM_READ

让我们检查一下 Olaf 的列表，看看我们是否能找到与线程创建相关的列表。如果你找到了 ，你就走在正确的轨道上。ActionTypesCreateRemoteThreadApiCallActionType

DeviceEvents |
where ActionType == "CreateRemoteThreadApiCall"

MDE 事件/操作关系

下图将 MDE 事件与其关联的操作相关联：

系统兽

重要的是要了解每个 EDR 将提供略有不同的视角。为了演示这一点，我们可以求助于 Sysmon：一个免费的传感器，作为 SysInternals 工具套件的一部分提供。虽然 Sysmon 可能不完全符合 EDR 产品的资格，但遥测生产并不是阻碍它的功能。在撰写本文时，Sysmon 提供了 28 个不同的事件，可用于检测恶意或未经授权的活动。我们可以使用上面链接的事件列表来开始识别与操作链中的操作相对应的事件。在本例中，我们发现 Sysmon 与 MDE 不同，它没有为链中的 EACH 操作提供相应的事件。相反，我们发现 Sysmon 事件 ID 8 对应于 Thread Create 操作，而 Sysmon 事件 ID 10 对应于 Process Open 操作。 CreateRemoteThreadProcessAccess

Sysmon 事件/操作关系

当谈到 Sysmon 时，我们发现事件与操作一致的说法仍然是正确的;但是，我们还发现，并非所有传感器都支持所有操作的遥测生成。与 MDE 不同，Sysmon 目前仅支持 Process Open 和 Thread Create 操作。Sysmon 和 MDE 之间一个有趣的功能区别是，虽然 Sysmon 没有用于内存分配和进程写入操作的事件，但它确实允许对它收集的事件进行过滤的自定义配置。这意味着用户可以选择 Sysmon 捕获和记录上述相关操作的条件。因此，由于透明过滤，遗漏相关事件的可能性较低。

在检测工程方面，我遵循两个口头禅。首先，“我们无法察觉到我们不理解的东西”，这意味着我们检测一个动作的能力取决于我们对动作本身的理解。如果我们对过程注入的理解相对肤浅，那么我们很可能仅限于检测什么而不是如何。那么，我们如何发展这种理解，在什么时候我们可以确信我们对这种现象的理解足以产生足够的解决方案呢？

第二个口头禅是，“我们必须使我们的概念与我们的感知保持一致。本文的目的是证明，特别是从终结点遥测的角度来看，我们看到的是操作，因此，我们应努力了解操作上下文中的行为才有意义。这有助于在工程检测规则方面做出正确的决策。

如果您发现自己正在构建检测分析，并且您依赖于不在相应操作链中的事件，我鼓励您问问自己，您是在为“什么”而不是“如何”构建检测。换句话说，您检测的是工具而不是行为吗？也许检测工具是你的目标，这很好，但这应该是一个深思熟虑的选择。

• 果子、树和蛇：为什么我们看得这么清楚

• 什么是电接收，鲨鱼如何使用它？

• Jonathan Johnson 的遥测源项目

• 二进制漏洞课程(更新中)

• windows网络安全防火墙与虚拟网卡（更新完成）

• windows文件过滤(更新完成)

• USB过滤(更新完成)

• 游戏安全(更新中)

• ios逆向

• windbg

• 还有很多免费教程(限学员)

• 更多详细内容添加作者微信