探讨后渗透测试工具SILENTTRINITY的工作原理与检测技巧

.NET语言变量类型和方法在编译时绑定，而Python是一种解释型脚本语言。因此，如何在.NET环境中执行Python代码？答案就在于DLR(dynamic language runtime)。下图显示了DLR的架构视图（Microsoft 2017）。

DLR是一个运行时环境，允许像Python这样的动态语言在.NET上运行，并最终编译成相应的通用中间语言（CIL）格式。使这成为可能的DLR组件之一是“动态对象互操作性”。   Python的一个关键特性是它不必在编译时声明其变量类型。相反，变量类型解析在运行时执行，这与标准.NET语言（如C＃）的运行方式不同。为了解决这个问题，DLR提供了一种称为“动态”的数据类型。分配有“动态”数据类型的变量在运行时而不是编译时解析，从而允许Python保持其动态特性并仍然能够在.NET环境中运行。 在SILENTTRINITY中，IronPython代码嵌入并在C＃对象中执行，并且通过扩展，在.NET环境中执行。这意味着它将首先编译为CIL代码，随后通过使用JIT引擎成为本机代码。我们之前已经在博客中对此进行了更详细的讨论（第1 部分 和第2部分）。  

C＃implant实际上是“ST”类型的C＃类，它的一个实例是在运行时动态创建的。这可以通过.NET的“Reflection”和“Activator”库来实现，如下面的代码片段所示。

因此，我们可以尝试使用Python脚本跟踪此类函数调用的存在，如下图所示。

如图所示，我们可以观察到“GetType”和“CreateInstance”函数的JIT-Inlining失败，因此表明这些函数至少执行了一次。但是，我们也看到内存中的程序集负载与实例创建和SILENTTRINITY程序集本身相关:

一旦正确加载了程序集，C＃后门就能够利用IronPython引擎来执行Python代码，如下面的代码片段所示。

由于上述DLL的加载是SILENTTRINITY的关键部分，我们也可以尝试寻找这些装配负载的证据：

在这个例子中，我们可以通过“DomainModuleDCStart_V1”和“ModuleDCStart_V2”事件来观察正在加载的dll，从而表明IronPython的存在。它们也在内存中加载，没有文件支持。但是，重要的是要注意这些程序集的存在并不表示任何恶意行为本身。使用IronPython引擎的合法.NET应用程序也会加载这些，，不过它更有可能从磁盘加载这些文件。但是，在大多数企业环境中，很多应用程序不太可能合法地使用IronPython。与其他IronPython用法的另一个重要区别是，这里涉及的程序集用于SILENTTRINITY使用的IronPython的嵌入式使用。如果IronPython被用作一个独立的python解释器来运行在。net框架上调用的python脚本，那么可以看到ipy.exe独立解释器正在使用。

SILENTTRINITY包含一些后期开发阶段的模块。我们将看看其中一个模块SafetyKatz。这很像同名的GhostPack模块，它会转储lsass的进程内存，然后在内存中加载Mimikatz来提取凭据。下面的代码片段显示了Python中SafetyKatz的实现：

正如在动态语言运行时一节中提到的，可以通过使用.NET ETW提供程序来跟踪JIT和Interop事件来检测这一点。

正如所料，我们能够观察到来自SharpSploit模块的VirtualAlloc和MinDumpWrite函数调用的互操作事件所关注的事件。

除了查看.NET ETW事件，我们还可以跟踪可疑的流程活动。由于我们在此示例中使用了msbuild stager，因此我们显然会看到msbuild进程执行事件。

由于MSBuild负责执行xml文件，我们可以寻找由MSBuild执行的xml执行的迹象。大多数MSBuild事件遵循术语或父和参数的通用格式，因此在整个企业中，可以基线正常活动和点偏差。我们还可以寻找源自MSBuild的连接。C＃后门必须定期连接回C2服务器以检查待处理的操作，如下面的代码所示。

因此，即使没有挂起的作业，c#后门也必须定期与C2通信，或者直到MSBuild进程终止。因此，我们可以搜索流量，如下图所示。