威胁检测与搜寻建模9.工具图

admin 2024年1月20日12:29:01评论13 views字数 6411阅读21分22秒阅读模式

威胁检测与搜寻建模1.了解函数调用堆栈

威胁检测与搜寻建模2.通过Mimikatz源代码审查发现 API 函数使用情况

威胁检测与搜寻建模3.基于Mimikatz重点分析函数正在执行的操作

威胁检测与搜寻建模4.扩展函数调用图

威胁检测与搜寻建模5.Mimikatz 分析-理解复合函数

威胁检测与搜寻建模6.基于Mimikatz 扩展操作图

威胁检测与搜寻建模7.基于Mimikatz解释什么是程

威胁检测与搜寻建模8.同义与相似性

数学家阿尔弗雷德·科兹布斯基(Alfred Korzybski)在他1931年的论文《非亚里士多德系统及其对数学和物理严谨性的必要性》中提出了一个想法,今天许多人在处理复杂系统时发现这个想法很有帮助。这个想法通常被称为“地图不是领土”,Korzybski 根据以下几点对其进行了布局:

A.)地图的结构可能与领土的结构相似或不同。
B.)两个相似的结构具有相似的“逻辑”特征。因此,如果在正确的地图中,德累斯顿被指定为巴黎和华沙之间,那么在实际领土上也会发现类似的关系。
C.)地图不是实际的领土。
D.)一张理想的地图将包含地图的地图,地图的地图的地图等等,无穷无尽......我们可以把这种特征称为自我反省。

当我们考虑攻击者的贸易时,我们倾向于抽象地考虑它。“从 LSASS 转储凭据”或“创建黄金票证”是什么意思?我们对这些抽象概念的理解取决于我们用来支撑它们的 MAP。如果像Korzybski的第二点所指出的那样,我们的地图与现实没有相似的结构,那么我们从地图中得出的任何结论,根据定义,都是不正确的。那么,我们应该如何绘制“贸易领土”的精确地图呢?

相关视频教程

新到了148节

威胁检测与搜寻建模9.工具图

我相信这个问题的答案可以从我们的老朋友柏拉图那里得到,他在对话《诡辩家》中通过对细节的分析来探索形式的定义。在我们的例子中,形式代表所讨论的工艺(技术或行为),例如,过程注入;具体是实现该技术的工具或示例。柏拉图提出,我们可以通过理解细节的共同点,即“同一性”,以及它们的区别,即“差异性”来理解形式。我们可以通过分析表面上执行流程注入的工具并“映射”它们以进行比较来做到这一点。这篇文章描述了我们目前映射工具实现的方法,以及这种映射如何促进细节的比较。

介绍

在过去的几个月里,我一直在与 一些同事合作开发我们的 Purple Team 服务产品。我们一直关注的任务之一是创建一个模型,使我们能够表示攻击技术的可能变体。我们计划在紫色团队评估期间使用此模型进行用例选择。为此,我们应用了本系列前面描述的许多概念,在此过程中,我们学到了很多关于如何教其他人实现这种方法的知识。帮助我了解如何将分析问题分解成一口大小的部分是内森·

当Nathan第一次与我合作时,他对本系列中描述的分析方法没有太多经验。他全新的视角帮助我确定了哪些领域在逻辑上实现了飞跃,或者没有很好地代表输出。因此,他帮助我创建了一个新的模型或图形布局,我认为这对那些刚入门的人来说很有帮助,而且更具体一些。

下面是工具图的图片(是的,这是我想出的真正有创意的名字)。这个想法是分析单个工具或“特定”样本的行为实现,以了解其工作原理,并将其用作枚举或发现其他变体的起点。随着时间的流逝,随着对更多工具的分析,这些图表或至少它们的一些组件可以组合在一起,以创建每种攻击技术的不同变体的鲁棒模型。这是一种将我们对这些变化的理解形式化的方法,而不是简单地在我们的脑海中保持一个瓦解的变体列表。

威胁检测与搜寻建模9.工具图

刀具图表

在这篇文章中,我想带你了解工具图的组件,颜色代表什么,以及如何制作自己的颜色。因此,让我们深入研究一下!

我们感兴趣的工具

在这篇博文中,我将引用 DGRonpa 在其 Process_Injection 存储库中共享的示例。该存储库是了解许多最常见的工艺注入变体的绝佳资源。今天我们将分析他们的 Shellcode_Injection.cpp 示例,该示例实现了我们大多数人都熟悉的经典远程线程 shellcode 注入变体。

选择样品或工具进行分析是令人震惊的一个重要来源。通过这一举措,我们确定了几个需要考虑的重要因素,特别是对于刚开始进行此类分析的分析师而言。我计划在本系列的后续文章中讨论这些因素。

Process_Injection/Shellcode_Injection.cpp 在主 ·DGRonpa/Process_Injection

通过在 GitHub 上创建帐户,为 DGRonpa/Process_Injection 开发做出贡献。

github.com

功能链

生成工具图的第一步是映射示例的 API 函数调用的顺序。此序列也称为“功能链”。在这篇文章中,我选择了一个相对简单的样本,以便尽可能容易地识别功能链。如果你想通过一个更复杂的例子来了解这个过程是如何工作的,我建议你查看本系列的第 1 部分,它着眼于 mimikatz sekurlsa::logonPasswords 模块的函数链。

现在,我在下面提供了示例关键片段的屏幕截图:

威胁检测与搜寻建模9.工具图

Shellcode_Injection.cpp源代码

请注意,该函数调用四个 Windows API 函数 、 、 和 。现在我们已经观察了示例调用的函数的特定序列,我们可以将它们绘制为函数链:InjectShellcodeOpenProcessVirtualAllocExWriteProcessMemoryCreateRemoteThread

威胁检测与搜寻建模9.工具图

功能链

注意:所有图形均使用 APC Jones 的箭头工具生成,https://arrows.app

在工具图中,函数链的圆圈和箭头是红色的。

函数调用堆栈

我记得当我刚进入这个行业时,我听说过这个功能链或模式。有人告诉我,“如果你看到 OpenProcess、VirtualAllocEx、WriteProcessMemory 和 CreateRemoteThread,则表示注入。随着时间的流逝,随着我对 API 编程越来越熟悉,我意识到这种视角的分辨率有些低。我发现,虽然这种特定的函数模式可能表示注入,但有(许多)替代函数链也表示注入。

这让我想起了“所有正方形都是矩形,但不是所有的矩形都是正方形”这句话,但这一次,它类似于“[函数链]的所有实例都是注入,但不是所有注入实例都是[函数链]”。我们可以扩展函数链变体图的一种方法是探索特定函数链中每个函数的函数调用堆栈,即 kernel32!OpenProcess,kernel32!VirtualAllocEx,kernel32!WriteProcessMemory 和 kernel32!CreateRemoteThread。如果您不熟悉函数调用堆栈,请查看我的 了解函数调用堆栈 博文,其中提供了对此现象的深入探讨。

注意: 在我们继续之前,我在原始文章中绘制函数调用堆栈的方式与将其集成到工具图中的方式之间存在重大变化。为了区分函数链(工具调用的函数的文字序列)和函数调用堆栈(作为更高级别的显式函数调用的后续操作在后台隐式调用/幕后调用的函数),我们水平表示“函数链”,垂直表示“函数调用堆栈”。

下面,您将看到集成到工具图中的第一个函数调用堆栈:kernel32!OpenProcess

威胁检测与搜寻建模9.工具图

包括 kernel32 的函数调用堆栈!开放进程

然后,我们可以为函数链中的每个附加函数集成函数调用堆栈,如下所示:

威胁检测与搜寻建模9.工具图

函数链和关联的函数调用堆栈

注意:某些函数比其他函数复杂得多,因为它们可能会调用多个后续函数。在某些情况下,我们在分析中包括所有后续函数,但在其他情况下,我们只有最相关的子堆栈。为了表示函数分析不完整,我们将函数的圆圈涂成橙色,如本例所示。kernelbase!CreateRemoteThreadEx

变化分析

一旦我们枚举了所有函数调用堆栈,我们就可以分析当前图所表示的所有可能的“功能变化”。通常,开发人员可以选择每个堆栈中的任何函数。例如,您可以从调用堆栈 1 中选择任何函数,并将其与调用堆栈 2、3 和 4 中的任何函数组合在一起,以创建正常运行的应用程序。我们看到调用堆栈 1 有五 (5) 个函数,调用堆栈 2 有六 (6) 个函数,调用堆栈 3 有五 (5) 个函数,调用堆栈 4 有六 (6) 个函数。因此,我们可以通过将每个调用堆栈中的函数数量相乘来计算总排列。在本例中,我们发现这些调用堆栈表示了 900 () 个可能的“函数链”或“功能变体”。5x6x5x6

同样,“函数链”被定义为实现行为的唯一函数序列。出于这个原因,我们原来的功能变体就是一个例子,而假设的功能链可能是第二个变体。从攻击者的角度来看,这两种变体是可以互换的,因为它们会产生相同的结果。从检测工程师的角度来看,这些微小的功能变化可能会导致样品逃避检测。下面我列出了四个没有函数突出显示(没有红色圆圈)的函数调用堆栈,以展示其工作原理的示例。kernel32!OpenProcess -> kernel32!VirtualAllocEx -> kernel32!WriteProcessMemory -> kernel32!CreateRemoteThreadkernel32!OpenProcess -> kernelbase!VirtualAllocEx -> ntdll!NtWriteVirtualMemory -> ntdll!NtCreateThreadEx

威胁检测与搜寻建模9.工具图

让我们看一下这些调用堆栈所代表的一些不同的函数链。

标准 Win32 API 函数

最有可能的函数链是使用记录的 Win32 API 函数的函数链。这些是 Microsoft 打算让开发人员在编写软件时使用的功能,因此它们在操作系统版本之间通常是一致的,有据可查,并且易于找到教程。出于这个原因,恶意软件也普遍使用这些功能,除非有特定的规避考虑导致开发人员使用堆栈中较低位置的鲜为人知的功能。

威胁检测与搜寻建模9.工具图

函数链变体 — Win32 API 函数

仅系统调用

在过去几年中越来越流行的第二种选择是跳过更高级别的 API 函数来进行直接系统调用(系统调用)。恶意软件开发人员之所以使用系统调用,是因为在某些情况下,EDR 传感器使用日志记录技术,这些技术仅允许他们查看高级用户模式函数调用。恶意软件开发人员可以通过直接调用系统调用来规避传感器或事件的子集。

威胁检测与搜寻建模9.工具图

函数链变体 — 仅限系统调用

任意示例变体

虽然前两个示例代表了一些最有可能被选中的函数链,但我们可以从这些调用堆栈中派生出许多其他函数链,而无需先在“真实”样本中观察它们。下面是任意函数链的两个示例,开发人员可以使用它们来创建替代工具,该工具在功能上与原始工具相同,但可能不同到足以规避某些检测规则。

威胁检测与搜寻建模9.工具图

威胁检测与搜寻建模9.工具图

函数链变体 — 任意选择函数

操作链(程序)

我们已经确定了 900 个可能的函数链,恶意软件开发人员可以使用这些函数链来实现此“经典远程线程 Shellcode 注入”变体。虽然更改函数链可能足以规避某些遥测生成或检测规则,但现有图描述的大多数函数链都非常相似,以至于从检测工程的角度来看,它们的差异无关紧要。换句话说,“从攻击者的角度来看,这些功能变化是可替代的,从防御者的角度来看,这些变化通常是可替代的。这是因为大多数现代 EDR 传感器从内核生成遥测数据,因此,捕获机制位于函数调用堆栈的底部。

如果开发人员可以使用调用堆栈中的任何函数来替换调用堆栈中的任何其他函数,那么检测工程师希望将调用堆栈中的函数集合视为相同是有道理的。这是抽象的基础,即虽然 和 是字面上不同的功能;它们足够相似,可以将它们视为相同。这使得检测工程师可以忽略功能链之间不相关的差异,并将精力集中在处理重要的差异上。使用此逻辑,我们可以派生一个抽象类别,该类别表示或可以替换调用堆栈中的任何可互换函数。例如,我们可以使用运算来引用它们,而不是在前面提到的函数之间进行细粒度的区分。要更深入地了解此“操作”概念,请参阅“检测时”系列的第 2 部分。kernel32!OpenProcessntdll!NtOpenProcessProcess Open

我在下图中添加了一个操作链。我们已将 的特定函数链转换为 的操作链。此分析已将恶意软件示例使用的特定功能链推广为表示 900 个功能链变体的操作链。抽象使我们免于进行小的/繁琐的区分。kernel32!OpenProcess -> kernel32!VirtualAllocEx -> kernel32!WriteProcessMemory -> kernel32!CreateRemoteThreadProcess Open -> Memory Allocate -> Process Write -> Thread Create

威胁检测与搜寻建模9.工具图

从函数链和调用堆栈派生操作链

注意:构成操作链的圆圈和箭头在“工具图”中为绿色。

我将在以后的文章中提出的一个论点是,在大多数情况下,我们看不到函数调用(尽管某些 EDR 命名约定可能会让我们相信)。相反,我们感知到更接近调用堆栈聚合的东西,我之前称之为操作。随着 EDR 传感器技术变得越来越复杂,这种操作重点变得越来越普遍。通常,EDR 传感器现在在系统调用(用户模式)函数调用堆栈的底层)下方的内核中生成大部分遥测数据。这意味着,无论工具调用堆栈中的哪个函数,EDR 传感器都应感知该操作。因此,我们可以将操作链用作工具图中所有 900 个函数链的抽象摘要。换句话说,操作链允许我们忽略不必要的复杂性,并将我们的概念与我们的感知保持一致。

结论

工具图允许通过函数调用堆栈将示例从函数链显式映射到操作链。这最终允许在不同的抽象级别上比较多个样本。首先,通过样本的功能链对样本进行功能比较。如果它们的函数链相同,那么可以安全地假设它们的操作链也相同。但是,在函数链不相同的情况下,工具图允许通过其操作链对样本进行操作比较。这是本系列第 7 部分中提出的前提。这个想法是,如果两个样本“在操作上是等效的”,那么它们几乎可以肯定是可以相互检测的。但是,如果两个样本在操作层面上不同,则该分析可能揭示了逃避的机会。

Operation Chain 最酷的方面是它提供了一个新的抽象级别。操作实际上并不存在。相反,它们是我们对功能链进行分类的方法,这些方法非常相似,以至于工具开发人员可以透明地切换它们。

威胁检测与搜寻建模9.工具图

最终操作链

请务必记住,这只是攻击者可用于实现此行为(进程注入)的一个操作链。该分析旨在为我们正在构建的抽象层提供具体的基础。虽然我对这个系列的最初计划包括一些预测,以发现以前未知的变体,但第一步应该明确地对已知变体或工具进行建模。因此,我建议从感兴趣的特定工具开始。工具提供了坚实的基础,并有助于促进此类分析的入门。您感兴趣的工具可能是开源工具(如我在此处展示的那样)、威胁报告中的工具,或者 C2 平台使用的组件或命令。很酷的是,我们将通过分析许多不同的工具,开始了解哪些差异和变化更深刻。例如,我们可能会分析两个声称有明显差异的工具。但是,它们只是实现了两个不同的功能链,可以用相同的操作链来概括(它们是同义词)。或者,我们可能会看到两个工具,从操作员的角度来看,它们声称是可以互换的,但它们实现了两个不同的操作链。随着时间的推移,我们的模型将不断增长,我们将对攻击者可以做出的更改有更深入的了解,以欺骗我们的检测规则。

如果你想提高你的分析能力,我建议你为DGRonpa的Process_Injection存储库中的每个样品创建工具图。这种做法不仅有助于加强构建工具图所需的技能,而且还将展示分析的滚雪球效应。当您分析多个样品时,尤其是实现相同或类似技术的样品,您将不断遇到相同的功能。如果您很好地组织了分析结果,则可以节省大量时间,因为您可以增加使用新样品和不同样品的经验。

洞课程()

威胁检测与搜寻建模9.工具图

windows

威胁检测与搜寻建模9.工具图

windows()

威胁检测与搜寻建模9.工具图

USB()

威胁检测与搜寻建模9.工具图

()

威胁检测与搜寻建模9.工具图

ios

威胁检测与搜寻建模9.工具图

windbg

威胁检测与搜寻建模9.工具图

()

威胁检测与搜寻建模9.工具图威胁检测与搜寻建模9.工具图威胁检测与搜寻建模9.工具图

威胁检测与搜寻建模9.工具图

威胁检测与搜寻建模9.工具图

原文始发于微信公众号(安全狗的自我修养):威胁检测与搜寻建模9.工具图

  • 左青龙
  • 微信扫一扫
  • weinxin
  • 右白虎
  • 微信扫一扫
  • weinxin
admin
  • 本文由 发表于 2024年1月20日12:29:01
  • 转载请保留本文链接(CN-SEC中文网:感谢原作者辛苦付出):
                   威胁检测与搜寻建模9.工具图http://cn-sec.com/archives/2413455.html

发表评论

匿名网友 填写信息