Sysmon是微软的一款轻量级的系统监控工具，最开始是由Sysinternals开发的，后来Sysinternals被微软收购，现在属于Sysinternals系列工具。它通过系统服务和驱动程序实现记录进程创建、文件访问以及网络信息的记录，并把相关的信息写入并展示在windows的日志事件里。

最近Sysmon的开发人员又对Sysmon进行了改进，在其中加入了一项新功能，允许Sysmon记录DNS事件。虽然这为安全管理人员提供了一个很好的事件追踪方式，但任何事物都有其两面性，如果我们作为攻击者，这意味着如果我们植入的恶意软件或有效载荷尝试通过DNS进行通信，则Sysmon就会出现许多DNS攻击的监控指标，攻击者就可以使用这些指标做文章。

这篇文章中，我将介绍一种如何逃逸 Sysmon （Sysmon 10.1版本）工具对 DNS 的监控的方法。

但在我们开始寻求具体的逃逸方法之前，我们需要首先部署一下测试环境。本文中，我使用的是@ SwiftOnSecurity的sysmon-config，并使用以下命令安装Sysmon：

sysmon.exe -accepteula -i rules.xml

随着我们的测试环境的启动和运行，你将开始看到事件正在进行。对事件ID 22的过滤集中在“DNS查询”上，如下图所示：

正常运行之后，让我们首先看看如何执行日志记录。

如何执行DNS日志记录？

为了理解逃逸检测时可用的选项，我想首先回顾一下一般的安全监控工具是如何工作的。以Sysmon为例， ETW被广泛用于网络连接监控等方面，ETW(Event Tracing for Windows)提供了一种对用户层应用程序和内核层驱动创建的事件对象的跟踪记录机制。因此，DNS监控也是以类似的方式执行。如果我们使用以下命令，首先会发现监控是从ETW开始的。

logman -ets

在安装Sysmon之后，我注意到的“Data Collector Set（Data Collector Set）”的名称很奇怪，被命名为“我的事件跟踪会话（My Event Trace Session）”。如果我们进一步深入研究，我们会发现这很可能是为Sysmon提供DNS数据的原因:

经过一些搜索之后，建议在许多位置使用microsoft – windows – dn – client provider作为显示DNS查询信息的合适位置。但在我们将其作为逃逸方法之前，我通常喜欢与执行套件的服务交叉引用。本文，我们使用了Ghidra，Ghidra是由美国国家安全局(NSA)研究部门开发的软件逆向工程(SRE)套件,用于支持网络安全任务。进入Ghidra后，搜索“我的事件跟踪会话”作为一个定义的字符串，以下就是我们发现的函数:

此时，我们在SysMon64.exe中有一个引用跟踪名称的函数（此函数和名称也与Microsoft文档中提供的示例代码非常相似）。上面的EnableTraceEx2调用的第二个参数提供了指向以下数据的指针：

当然，这与上面logman截图中显示的用于{1C95126E-7EEa-49A9-A3FE-A378B03DDB4D}的Microsoft-Windows-DNS-Client的GUID相同。因此，我们肯定知道这是DNS查询收集过程的执行方式。接下来，我们需要了解在请求DNS记录时如何触发这些事件。

如何知道DNS事件被记录？

让我们使用一个常见的DNS API调用DnsQuery_A，并尝试找出ETW数据可能出现的位置。显而易见的起点是dnsapi.dll，它承载API调用。将其与PDB一起加载到Ghidra中，我们可以开始查看可能突出显示正在使用的ETW的功能。由于我们已经知道GUID与DNS事件相关联，因此在尝试查找起点时，我们将使用这个GUID作为数据点。有点令人惊讶的是，我们是在DLL中找到了这个GUID，并引用了DNS_CLIENT的符号：

如果我们遵循对符号DNS_CLIENT的引用，我们可以看到它是在函数McGenEventRegister中分配的:

从DllMain调用此函数，这意味着创建了一个句柄(DNS_CLIENT_Context)来发送事件。

为了了解这个句柄在DLL中的实际使用情况，让我们创建一个小应用程序，它将为我们执行DNS查询:

#include <Windows.h>
#include <WinDNS.h>
int main()
{
DnsQuery_A("blog.xpnsec.com", DNS_TYPE_A, DNS_QUERY_STANDARD, NULL, NULL, NULL);
}

如果我们编译它并在WinDBG中将其旋转，我们可以使用以下命令添加一个断点，在读取DNS_CLIENT_Context的内存时触发它。

ba r4 DNSAPI!DNS_CLIENT_Context

恢复执行我们的应用程序后，不久我们就会遇到一个断点，调用堆栈如下所示。

具体来说，我们会发现以下相关的DNS事件被记录的指示。

这意味着什么呢?看起来事件是从DnsApi.dll中被发送到Microsoft-Windows-DNS-Client的，该事件是在攻击者进程中加载的。

怎样才能逃逸检测？

根据上面的解释，我们知道某些事件是从DnsApi.dll中发送的。如果在发送过程中调用DLL，我们就可以干预检测指标。

如何做到这一点取决于个人喜好，不过建议参考以下本文的示例，点此观看此视频，我们会尝试在运行时修补DNSAPI！McTemplateU0zqxqz以返回执行，而不通过EtwEventWriteTransfer发送事件。如果我们尝试执行我们的应用程序进行DNS查询，就会发现调用DNS客户端API时不会触发任何事件。