现如今防御者所面临的信息不对称问题已经越来越凸显，特别是随着内存中的攻击和有针对性的恶意软件的出现，防御者已经不能仅仅依靠Windows默认提供的事件日志来进行防御了，因为攻击者可能会使用进程空当来将其代码隐藏在一个看似良性的进程中，并切Command＆Control流量通过DNS路由保持隐藏。
在通过Office 365红队练习我们的事件响应功能后，我们开始研究Windows安全事件日志之外的备用数据源。我们意识到，虽然我们可以看到一个可疑过程，但我们不知道这个进程查询了哪些域，或者发送到端点的数据量有哪些。此外，我们发现PowerShell.exe的实例是一个对手可以执行任意数量的未知命令的黑洞，因此我们需要比安全事件日志所能提供的更多信息。
挑战是什么？
想象一下这种情况：在查看事件日志时，你发现4688 Process Start事件有一个未知可执行文件—bad.exe：
不幸的是，当你使用此可疑进程研究机器时，bad.exe已经不再位于磁盘或任何位置。这时候你就会发现仅使用Windows安全事件日志中可用的内容，除了4688 Process Start事件中的上述内容之外，你可以获得的信息非常少。
关于bad.exe的哪些信息在检测和威胁评估中最有用？我们可能主要对以下三个问题感兴趣：
· 谁干的？比如用户名； · 他们做了什么？比如过程 - 如果使用过程中挖空/注射，这可能会导致出现误导； · 他们在哪里发送数据？比如目标网络地址和域名；
考虑到这些问题，我们想要了解的信息可能如下所示：
· 进程执行什么DNS查找？ · 该进程连接到哪个IP地址？ · 流程传输了多少数据？ · 过程“指向”哪里？即进程是否与Command＆Control基础架构通信？ · 加载了哪些DLL的进程？ · 过程是否在其他进程中创建线程？ · 该进程执行什么WMI操作？ · 进程调用了什么PowerShell函数？
要收集这种类型的数据，你可能需要内核驱动程序或某种hooking机制。幸运的是，Windows提供了现有的数据源，可以帮助我们回答这些题为ETW或Windows事件跟踪的问题。
ETW救援
Windows事件跟踪（ETW）是Windows 2000以后在Windows中可用的跟踪技术。它最初旨在帮助Microsoft工程师调试操作系统，例如性能测量和电源管理跟踪。很多Windows的工程师都会使用ETW进行性能测试和组件跟踪。
ETW可能和你遇到的其他跟踪技术并没有显着差异。一个组件（例如PowerShell）注册一个提供者，它会发出一个或多个类型的事件。每个事件都有一个描述事件有效载荷中包含的数据类型的模式。事件可能包含字符串，整数，浮点数，布尔值，甚至二进制数据。
要使用ETW提供者的事件，用户需要首先创建跟踪会话。每个跟踪会话可以消耗一个或多个提供者。在注册跟踪会话的提供者之后，用户必须注册一个可以处理来自任何提供者的任何事件的回调。当用户准备启用跟踪会话时，很重要的一点是要注意通过启动跟踪会话，用户将调用线程向ETW子系统提供泵送事件。
事件的流程如下图所示：
ETW的形状
为了更好地了解什么是ETW事件，我们将使用一个名为Microsoft Message Analyzer的工具。该工具允许你订阅操作系统上可用的ETW跟踪，并在事件进入时检查事件。
以下是注册PowerShell提供程序后Message Analyzer的主窗口：
在中心，我们看到一系列的事件与总结：
当我们选择其中一个事件时，就像上面突出显示的那些事件，我们在下半部分会得到一个详细的视图：
标有“ContextInfo”，“UserData”和“Payload”的前三个项目都是此事件的属性。我们可以看到“类型”列描述了所有这些都是字符串。如果我们选择其中一个属性，我们可以看到该属性的内容：
这是一个包含主机应用程序（“powershell.exe”），命令名称（“invoke-mimikatz”）和调用它的用户（“REDMOND zbrown”）的结构化字符串blob。
每个ETW提供者都可以使用自己独特的模式发送事件。除了唯一的模式，每个事件还有一些标准属性 - EventId，ProcessId，ThreadId，TimeStamp，ProviderId等等。这些属性对于所有ETW事件都是常见的。
如果你想了解更多有关使用Message Analyzer检查ETW事件的信息，可以参阅本指南。
ETW 可视性
ETW可以提供对大多数核心Windows子系统的可见性，包括：
· 网络活动 · 流程创建/终止 · 线程创建/终止 · 内存分配 · DLL加载/卸载 · PowerShell方法调用 · DNS解析（缓存和热） · 防火墙活动 · WMI活动 · WinINet请求/响应头 · 还有更多的...
在Windows 10中，有超过1000个提供者。如果你好奇你的Windows版本上提供哪些提供程序，则可以运行以下命令：
logman查询提供者> providers.txt
随着所有这些数据成熟，你可以假设我们可以简单地将这些ETW提供者打开，并立即开始从增加的信息中受益。然而，ETW仍然是一个调试流，但也因此输出了真正大量的数据。这就像从消防水带中喝水一样：
想象一下，你可以尝试将此数据发送到您的SIEM：
· 每个进程中的每个DLL加载 · 每个进程中的每个线程创建 · 每个进程从每个端点开始
如果我们以原始形式发送数据，可能无法有效地使用数据。要使用这个新的数据源，我们需要一些方法来过滤和/或汇总数据。
在ETW的下一篇博客文章中，我们将讨论如何以编程方式来消耗ETW，过滤投入以及如何对上述我们概述的那些问题进行解答。
还没有评论，来说两句吧...