原文标题：Maelstrom #7: Static OpSec Review
原文地址：
https://pre.empt.blog/2023/maelstrom-7-static-opsec-review
由于作者博客迁移的原因，原文中的图片已经失效，我在archive中找到了别人保存下来的网页：https://web.archive.org/web/20221126184800/https://pre.empt.dev/posts/maelstrom-static-review/
本文由本人用chatgbt翻译而成，Maelstrom是一个概念验证的命令与控制框架，具有Python后端和C++植入程序。

介绍

在之前的两篇博客中，我们讨论了Windows和第三方事件检测与响应（EDR）程序使用的五种关键机制，用于评估C2的植入物并通过检测行为干预其操作。这些技术相对较新，对于尚未被发现的植入物来说非常有效。
尽管这些技术可能非常复杂，特别是在攻击者和防御者都在不断深入研究和探索Windows本身以寻找新技术的前沿领域，但令人惊讶的是，植入物或可执行文件可以在没有太多努力的情况下运行。相比于花费数小时浏览WinAPI调用，开发一个独立的可移植可执行文件（PE）文件可能显得多余，你可以简单地使用PowerShell运行一个反向Shell。
我们经常遇到相同的问题：为什么基于StackOverflow答案上的“如何编写反向Shell”的全新可疑可执行文件有时候没有被检测到？为什么完全新的技术一旦上传到VirusTotal就立即被厂商检测到？这两个问题的答案基本上在于对这些文件的静态和动态分析。EDR和沙箱会随着时间评估植入物的内存和行为。如果你的新植入物看起来像之前的植入物，或者行为像之前的植入物，EDR很可能会将其识别为植入物。随着VirusTotal等工具的增长，EDR之间的数据共享以及不断增长的技术体系，即使是“全新”的植入物也可能无意间包含威胁指标。
在接下来的两篇博客中，我们将探讨如何使用静态和运行时分析来检测植入物，并考虑如何规避这些分析方法。
在本博客中，我们将通过分析我们的概念验证C2植入物"Maelstrom"来重点讨论静态审查。我们将查看植入物的可移植可执行文件（PE）和反射式DLL，并查看它们在操作安全性（OpSec）方面的问题，以及我们如何尝试解决这些问题。
为了进行静态审查，我们将查看PE结构和一些用于指标妥协的自动化工具。我们将比较一个没有任何有意义的OpSec实践的PE（标记为“unsafe”）和一个具有OpSec实践的PE（标记为“safe”），以说明良好的OpSec的影响。

目标

本文将涵盖以下内容：

• 审查PE和DLL的加载和导入情况
  • 我们如何检查这些文件
  • 寻找可疑属性
  • 如何查找和评估导入、函数和字符串
• 审查PE和DLL的功能
  • 使用CAPA根据MITRE ATT＆CK框架和其他目录查找它们的函数和行为
  • 新植入物在VirusTotal等平台上的行为
  • 简要讨论供应商和众包规则触发的属性
• 审查PE和DLL的元数据
  • 不引人注目的元数据可能具有可疑性
  • 熵和Authenticode如何影响检测
  • 查看自动检测工具，特别是Intezer

正如往常一样，我们不会直接发布这些技术的绕过方法。我们开发的植入物仅用于说明，并且作为本博客的一部分，我们已将这些文件上传到VirusTotal，并开发了YARA规则，将在下一篇博客中发布，可以检测植入物的运行。当然，本文并不详尽无遗，实际上在实际应用中还有更多高级的过滤器和行为。
最后，如果你想尽早获取我们的代码，请随意使用我们的VirusTotal样本！

重要概念

可移植可执行文件（PE）

在本系列的先前讨论中，我们已经讨论了可移植可执行文件（Portable Executable，PE），但为了快速回顾一下：
可移植可执行文件是Windows中常见的exe文件。Microsoft的网站上有一篇由Matt Pietrek撰写的很好的解释。简而言之，它是代码及其依赖项在Windows中存储的方式。
Ange Albertini的精美图形清楚地展示了PE的格式：

动态链接库（DLL）

类似地，我们之前也简要讨论过动态链接库（DLL），但简单来说，DLL也是基于可移植可执行文件（PE）文件格式的。DLL允许导出函数，然后可以通过使用LoadLibraryA调用或静态链接库将其加载到应用程序中。导出的函数可以用于任何功能，将功能隔离，使得代码更加模块化。这样可以更简单地将对象加载到内存中，而无需在可执行文件本身中使用复杂的解决方法。
关于DLL，James McNellis在CppCon 2017的演讲“Everything You Ever Wanted to Know about DLLs”是一个很好的入门资料。正如你所想象的，这个演讲深入介绍了DLL的相关内容。

审查PE模块和函数

在讨论PE结构时，我们实际上指的是进程执行块（Process Execution Block，PEB），我们在《Maelstrom: Writing a C2 Implant》中进行了讨论。在那篇文章中，我们链接了两篇文章 - ired.team的《Exploring Process Environment Block》和NtOpcode的《Anatomy of the Process Environment Block (PEB) (Windows Internals)》。如果你还没有阅读过这些文章，或者想要快速回顾一下，我们建议你在继续本节之前阅读它们！
当我们查看PEB时，我们的目标是审查加载的模块、导入的函数和与文件相关的字符串。在恶意软件中，这些是常见的妥协指标和妥协指标缺失的领域。
为了查找这些信息，我们将使用以下三个程序：

• Hasherzade的PEBear
• Marc Ochsenmeier的PEStudio
• Erik Pistelli的CFF Explorer

已加载的模块和导入的函数

首先，我们要评估的是植入物所需的模块。最简单的方法是使用CFF Explorer。安装后，右键单击PE文件，然后点击“使用CFF Explorer打开”：

EXE（两者）

由于两个加载器（PE文件）均没有导入项，因此导入目录应该为空。在CFF Explorer中导航到导入目录时，不会显示任何内容：

由于加载器被编写为位置无关的，我们在《Maelstrom: Writing a C2 Implant》中也详细介绍了这一点，所有函数都是在运行时动态解析的。
然而，值得记住的是，具有0个导入项的文件是植入物是恶意的一个很高的指标，而且反病毒厂商很早就知道这种技术。这是植入物避免触及磁盘的许多原因之一，但我们不是在教授红队战术。
在PE Bear中，我们可以通过打开文件并找到“Imports”选项卡来实现相同的功能：

反射式DLL

接下来是实际的植入物，即反射式DLL。它没有位置无关的代码，而是依赖于导入项。
所以，如果我们使用CFF Explorer打开它：

我们使用了所有这些库。要查看函数，只需点击一个模块的表行即可：

在较低的窗口中，我们可以看到模块的加载函数被识别出来，并且它们在PE中的位置。浏览这四个模块，我们可以看到它们为什么存在。
WinHTTP DLL存在是因为这个链接：

然后，ADVAPI32存在是因为：

最后，MSVCRT存在是因为malloc和sprintf的调用：

要获取“黑名单”函数和库的列表，PE Studio可以满足你的需求：


这个DLL从不接触磁盘，所以这些库的重要性并不是非常关键...然而，这仍然是运营人员应该考虑的事情。在DLL内部，可以使用简单的宏、类或函数来快速处理动态解析，而无需采取额外的混淆步骤。

字符串

字符串是检测恶意软件的经典手段，许多流行的YARA规则依赖于字符串来快速检测和归属样本。正如我们稍后将看到的，字符串被用于懒惰检测，这是正确的做法——它们快速、可靠，并且作为一种通用的检查方式。当工具直接从GitHub下载，或者样本来源于博客、代码片段或StackOverflow回答时，防御者可以使用静态字符串编写逻辑来检测它们。
举个例子，Rubeus汇编的GUID：

为什么不将其作为一种检测手段呢？这并不是说所有的检测都应该这样做，但是应该考虑低 hanging fruit（易于获取的目标）。即使是这样，这些检测的库也可以进一步分为不同的严重程度和置信度。
最近，Palo Alto发布了《When Pentest Tools Go Brutal: Red-Teaming Tool Being Abused by Malicious Actors》，发现Brute Ratel在野外被滥用。通过一些逆向工作，他们发现了以下字符串：

这些字符串现在将用于EDR的检测...再次强调，字符串不应该是样本或归属的唯一检测逻辑。但是，至少应该使用其中一条规则。由于恶意软件中某些函数和字符串的特定性，通过额外的检测措施可以获得更多的信息，而由此带来的误报损失相对较小。
这将我们带回到我们的Maelstrom不安全和安全的PE文件——它们包含哪些字符串？在Linux上，我们可以使用"strings"命令来查找字符串，在Windows上，可以使用SysInternals的"Strings"工具。但是，我们喜欢图形界面，因此我们将使用PE Studio进行此操作。

EXE

对于这个EXE文件，它是位置无关的，所以它不会有任何导入函数，但仍然会包含字符串。回想一下我们如何在运行时获取函数地址：

我们将字符串作为数组传递，以确保LoadLibraryA字符串出现在.text节中。这意味着我们仍然应该在我们的安全PE文件中看到一些字符串。在我们的不安全PE文件中（我们使用预处理器定义禁用保护，因此它在其他方面是相同的），我们可以看到一堆字符串：

解决方案在这里应该是相当明显的。对数据进行操作。这可以简单地将字符串进行哈希处理并存储为无符号整数，然后遍历模块中的每个函数并对它们进行哈希处理。当它们匹配时，跳出循环，因为已经定位到了函数，而无需在 implant 中存储字符串。《如何在C中编写djb2哈希函数？》展示了一个简单的DJB2哈希算法的实现。
另一种选择是对字符串进行加密。字符串掩码的关键在于创造力。PowerShell恶意软件中常见的策略是使用ComSpec构建IEX字符串：

这将生成：

在C语言中，可以使用堆栈字符串，其中字符串中的每个字符在运行时被追加到字符串中。但是，我们发现修改后的哈希算法是最容易实现的方法（hashdb有很多哈希算法）。
最后，请不要将字符串的混淆与implant的整体数据保护机制混淆。如果解决方案是对字符串进行异或运算，请不要同时使用异或运算保护数据传输过程中的数据...

反射式DLL

再次使用PEStudio，这次在DLL文件上进行分析：

正如你所看到的，这里有一些非常可疑的字符串。

在下一周的运行时博客中，我们将再次在内存区域中看到许多这些字符串。

正如我们所看到的，10.10.11.205的IP地址、初始化字符串、头部等都是可见的。
对于连接详细信息、凭据等，它们需要被隐藏/保护起来。可以使用类似ADVobfuscator的编译时混淆工具进行混淆。然而，使用在implant中公开可用的代码越多，给防御者提供的信息就越多，或者可能会被标记。
对于Vulpes，使用自定义的C++类来保存加密的字符串。在需要时进行解密，然后在析构函数中从堆栈中销毁字符串。目标是只在尽可能短的时间窗口内存在字符串。这是一个涉及创造力和可用性的实现方式之一。
在研究公开可用的C2和专有的C2时，完整的配置可以被提取出来，并找到明文信息。这是因为使用的算法通常是可识别的，例如异或、RC4和其他变种。为了使研究人员难以逆向，Vulpes仅嵌入了初始化请求所需的绝对最小信息。在implant加载到内存时，它识别出各种环境关键信息。这些密钥用于构建密码学，尽可能保护配置信息。

CAPA

我们已经查看了一些基本的静态信息，现在让我们来看看CAPA（Capability Analyser），这是一种能力分析工具。
有关此实用工具的更多信息，以下三篇博客提供了关于使用CAPA的良好入门指南：

• capa: Automatically Identify Malware Capabilities
• capa 2.0: Better, Stronger, Faster
• ELFant in the Room – capa v3

capa-rules存储库包含了数百个不同静态特征的规则，例如：

• PDB路径（PDB Path）
• 包含资源（Contains Resource）
• 使用缓解策略保护生成的进程（Protect spawned processes with Mitigation Policies）

这些规则用于检测和识别恶意软件的各种能力和特征。通过使用CAPA和这些规则，可以更好地理解恶意软件的行为和功能，从而加强对其的分析和防御。

EXE（不安全）

首先，让我们检查一下"unsafe"可执行文件。请记住，这个变种逻辑较少，因为它没有进行任何预执行检查。除了一般的PE信息之外，这是主要的匹配：

这里匹配的规则是"Contains obfuscated Stackstrings"，其中包含了以下内容：

这是我们预期的结果。虽然它匹配的原因与我们使用它的目的不符，但无论如何，它找到了一些内容。

EXE（安全）

CAPA能够识别出"safe"变种中的一些额外步骤。
首先，它识别了反调试检查，这是通过"检查PEB中的调试标志"规则找到的：

匹配的代码如下：

请注意，这只是一个简单的验证示例，实际上还有许多类似的代码，详见"逃避技术"。
有趣的是，CAPA没有发现使用CreateToolhelp32Snapshot来查看进程信息，也没有发现使用GetComputerNameA进行环境密钥识别。

反射式DLL

实际上，这个DLL提供了更多可用的数据:

通过加载器和DLL的所有这些信息，为可以/应该替换的内容提供了良好的基础。例如，"分配RWX内存"。这是一个相当大的威胁指示，我们将在下一篇博客中详细介绍。

Virus Total

我们不建议您将自己的植入物上传到VirusTotal，因为这样做会立即被检测出来。但是，考虑到这是一个临时项目，并且我们认为了解某些事物的微小指标是很重要的，我们可以尝试在VirusTotal上查看植入物的响应。

反射式DLL

让我们将我们全新的C2植入物上传到VirusTotal，使其变得毫无用处，除非进行适当的重构。maelstrom.x64.dll已被上传，以下是最初于2022年1月上传的结果：

从最初的上传开始，截至2022年1月，我们的DLL与一些众包的Yara规则匹配，但只有两个厂商检测到它，分别是卡巴斯基和微软。

让我们逐个检查这些检测，并看看它们是在哪些方面触发的。

Yara规则

在撰写本文时，我们被两个众包的Yara规则标记为问题，分别是Florian Roth的Reflective Loader和ditekshen的INDICATOR_SUSPICIOUS_ReflectiveLoader。
Reflective Loader的Yara规则如下所示：

同样地，INDICATOR_SUSPICIOUS_ReflectiveLoader规则包括以下内容：

我们可以看到这两个规则都匹配以下的DLL导出函数：

自然而然，您可以将其更新为以下内容之一：

或者简单地：

这样我们就可以规避Yara检测。

卡巴斯基的HackTool.Win32.Inject.heur签名

根据对HackTool.Win32.Inject.heur的查询结果:

该恶意程序系列会将其代码注入到受感染计算机上正在运行的程序的地址空间中，例如系统进程或具有Internet访问权限的程序。

因此，这与注入有一定的关联。由于该DLL没有调用VirtualAllocEx、VirtualProtectEx等函数，因此很可能也是因为与Yara规则相同的ReflectiveLoader导出而被标记为恶意。尽管也有可能是主线程运行Maelstrom()函数而引起的标记：

不过，这种可能性可能较小。

微软的Win32/Sabsik.TE.B!ml签名

然而，微软的Win32/Sabsik.TE.B!ml检测结果更加模糊，将大部分逻辑留给了想象力。因此，我们将把这留给读者作为一个练习。

启用云提交

最后，为了说明为什么作为操作员，在开发机器上关闭云提交功能可能是个好主意，我们在最初编写植入物之后几个月重新运行了VirusTotal扫描。
在2022年7月15日重新运行扫描后，检测厂商的数量增加到了25个，而在今年1月时只有2个：

将近一个月后的2022年8月8日，我们的DLL被27个厂商检测到：

EXE（不安全）

即使在2022年8月进行第三次重新扫描后，maelstrom.unsafe.x64.exe仍然只有2个检测结果：

EXE（安全）

maelstrom.safe.x64.exe在VirusTotal上仍然只有两个检测结果:

正如我们在介绍中讨论的那样，全新的代码如果不包含先前使用过的元素或可疑字符串，通常可以绕过市场上大多数防病毒和EDR解决方案的检测，即使操作员在其中并没有花费太多的工作。然而，正如我们将在下一篇文章中看到的那样，在运行时会有很多方式引起注意，而这还没有涉及到操作员的行为（本系列中我们不会涵盖此部分）。

Intezer

Intezer是一家公司，允许工程师通过尝试识别出现在其他恶意软件系列中的代码段来分析样本。例如，如果在一个流行的恶意软件系列中找到了一个用于枚举驱动程序的函数，并且在上传的样本中被识别出来，那么就会被标记出来。
有趣的是，Intezer提供了集成，并且两家EDR公司正在积极地从中获取信息：EDR集成

• SentinelOne
• CrowdStrike

以下是使用Intezer的一个示例流程的演示：

作为其工作原理的示例，这是一个已上传并进行分析的分段加载器（stager）：


在上述示例中，信息有些有限。然而，检测到了通用恶意软件，这可能是一个威胁指示器。
此外，Intezer试图识别能力、TTPS（战术、技术和程序）和一般的威胁指示器。显然，不要上传整个植入物，但可以评估植入物的某些方面，以了解哪些行为被认为是可疑的，这可能很有用。

熵

熵（Entropy）是物理学中的一个概念，主要用于衡量随机性的程度。在计算机领域，大多数程序的原始字节具有一定的"正常"随机性水平，而单词、短语和代码通常比随机字节串更具可预测性。C2植入物，特别是那些严重依赖于加密字符串的植入物，其熵值将呈现异常水平，因为这些加密区域将显得不太可预测。
由于计算熵值相对较快，它可以作为判断程序是否恶意的一种快速简单的度量标准。
根据《Practical Security Analytics》一文中的"使用文件熵进行威胁狩猎":

如上图所示，熵值在6.5以上的情况越来越可疑，而熵值在7以上的情况可以合理地认为是恶意的，需要进一步检查。在熵值的低端出现了一个有趣的峰值，毕竟，这只是一个粗略的指标，特别是与其他度量标准相比。可以猜测，这可能是由于较小的PowerShell或其他反向Shell脚本具有最小的加密量，或者加密字符串（如通道加密的初始化向量）只占据了一个相对较小的植入物的一部分。
Rad Kawar在他在SteelCon 2022的演讲《编写小型、高效、可靠的恶意软件》中对熵及其对恶意软件的影响进行了总结:

以下是一个bash单行命令，使用ent工具测量当前目录中exe和dll文件的熵：

值得庆幸的是，由于我们所有的库都相当简洁，并且没有过度使用除所需之外的加密，我们很幸运地能够将熵值保持在一个合理的水平：

Authenticode

Authenticode是Microsoft的代码签名方式，是验证在Windows设备上运行的代码的关键部分。说实话，这是一个庞大的领域，我们将在以后的博客中详细讨论，因为它非常复杂，并且存在许多绕过和注意事项。
然而，在基本层面上，Authenticode允许使用数字证书对代码进行签名。这可以在Visual Studio中本地包含，也可以作为编译步骤添加进去。在运行代码时，Windows将检查证书，以确保代码是由有效的证书颁发机构签名的，然后才会运行。
根据我们的经验，Windows环境通常还没有完全转向只允许运行已签名程序的模式，但EDR会将缺少有效证书作为可疑属性进行检查。供应商通常不直接提及这一点，但间接地提到过。Sophos在其威胁狩猎学院中将未签名的应用程序作为IOCs（指示恶意活动的指标）之一，MITRE也在其ATT&CK框架中强调了它作为一个IOC。
自然地，有一些公开的方法可以规避这一点，例如使用从某处获取的证书（即窃取的证书），或者使用因为驱动程序需要向后兼容而仍然被Windows信任的已吊销证书。
在我们没有进行详细分析的情况下，我们建议阅读以下文章：

• Authenticode数字签名
• 打破Microsoft Authenticode安全模型
• 利用NVIDIA代码签名证书签署恶意软件
• 检测证书签名的恶意软件
• DirtyMoe: 代码签名证书
• 劫持数字签名
• 在EDR雷达下飞行

结论

虽然还有很多检测可以对我们的植入物进行，以测试它们对检测的响应，但在本文中我们只展示了其中的一部分。
读者可以尝试一些练习，比如移除DOS消息和NT头，并评估植入物在其他众包Yara规则下的性能。当开发实际的植入物时，正如我们在随时间对VirusTotal的回顾中看到的那样，使用VirusTotal来测试你的植入物是限制其可用寿命的好方法。
本文讨论的许多检测都在Fennec中作为触发内存扫描和进一步检查的标志实施。虽然EDR供应商没有详细讨论通常触发这些更深层次检查的属性，但可以安全地假设，如果你的植入物与主机中的其他程序融为一体，并且在植入物及其元数据中的IOCs越少，那么这些更深层次的检查就越不太可能发生。
在我们的介绍中，我们讨论了一些植入物似乎只是运行，而一些环境似乎只是允许植入物而没有标记它们。使用我们今天所研究的技术，答案应该很简单——它们只是没有引起足够的怀疑。植入物中的很多代码并不恶意；而且一个新编写的植入物如果没有引用或包含之前可疑的作品，不一定就是可疑的。同样地，调用WinAPI或执行可疑行为（如反射加载器）的方式只有那么多，即使是刚刚编写的植入物也可能包含长期被标记为可疑的调用和函数。
不幸的是，答案就是不断测试和重新测试植入物，针对EDR和Yara规则，继续开发更多新颖或被忽视的技术来保持优势。对于防御者来说，环境中包含的规则和目录越多，早期发现植入物的机会就越高。
在我们接下来的文章中，我们将通过检查植入物在运行时的行为、内存和一般的操作安全性（OpSec）来对其进行分析。我们将再次探讨如何检测它，以及操作员如何开始考虑绕过这些检测。

[CTF入门培训]顶尖高校博士及硕士团队亲授《30小时教你玩转CTF》，视频+靶场+题目！助力进入CTF世界