通过有针对性的DNS日志记录提高防御
这篇文章的目的是向您介绍如何在Microsoft Windows平台上收集日志。我们将从演示Windows源日志部署开始，然后从日志示例中选择字段的集合，并对这些源进行简要描述。最后一部分将讨论审计日志，因为它在确保基础设施防御方面发挥着重要作用。
Windows日志部署场景
为了开始本文第二部分所述的调查，分析人员和事件响应人员需要配备相关的DNS和域日志，从而使他们能够看到网络上发生的相关事件。您的组织可能已经在某种规模上部署了类似于下面所示的集中式日志记录形式。如果没有，你总是有改进的空间!
从源头到SIEM
左侧为可能的日志源。我定义了一个样例日志部署的一小部分，尽管惟一日志源端点的实际数量比这里展示的要多得多。然后，当我们移到图的右侧时，我们可以看到如何将日志转发到日志管理服务器或数据湖，然后转发到SIEM以进行进一步的操作。
从这些事件来源…
图左侧的源端说明了几个潜在的源。客户端机器表示客户端发生了需要收集的事件。我已经添加了标签来显示要收集的事件类型的一些示例—例如由Windows Sysinternals System Monitor (Sysmon)生成的事件、对高值EventIDs的任何订阅和通道。还有其他不使用Windows事件日志遥测的日志源，例如基于文件的日志记录，以及分组在“其他预定义收集过程”区域中的其他日志源，例如(用图标表示)Windows防火墙、Powershell日志记录、入口日志记录。
本例中定义了三个服务器:
- 一个内部邮件服务器，Exchange服务器。设置它是为了收集Exchange消息跟踪日志，在元数据中包含IP和主机名信息。
- Windows DNS服务器。日志收集设置在DNSServer Windows EventLog Analytic通道上，以及审计日志。收集也可以手动启用并设置为收集DNS调试日志事件。
- Active Directory服务器。由于许多原因，该服务器是一个高价值的目标。日志收集设置用于收集GPO或组策略对象日志以及审计日志。
还有许多其他日志源为DomainTools调查和集成提供有价值的情报，如来自防火墙事件的日志、Windows IIS服务器日志、入口身份验证尝试等等。您甚至可以部署基线收集以及启用可疑基线收集的选项，这将需要对可疑目标机器进行更详细或扩展的收集。
SIEM的集成、自动化和分析
Windows订阅可以部署为仅提取Windows事件日志事件(通过WEF, Windows事件转发)。从这些客户端/服务器源，这些事件被转发到Windows事件收集器。
还将部署另一个由SIEM或第三方提供的收集器，以收集更多事件，以扩大可见性，并确保不会遗漏其他类型的日志(例如基于文件的日志记录)。
这些事件最终可能被转发到数据湖或日志管理服务器。由于存储、基础设施和许可成本等原因，并不是所有日志都能被SIEM接收，而且并非所有事件都没有SIEM支持的用例。
日志规范化的过程很重要，因为条目不是用标准格式编写的。除了规范化日志之外，还应用解析和丰富这些事件。这些进程在传输过程中由采集器和/或源本身的磁盘或日志管理服务器上完成。
一旦日志到达SIEM，它们将用于额外的集成，以提供要执行的任何其他操作(分类)、丰富分析、触发警报等等。
Windows事件日志
到目前为止，我们已经介绍了一个日志部署示例。以下是选定的Windows DNS日志中的示例字段，以便让您了解所提供的信息类型。请注意，这些已经被丰富/写入到另一种格式，它们只是片段，而不是完整的日志本身。
Windows DNS Client来源
Windows DNS客户端事件来源包括:
- Windows事件日志通道(DNS客户端事件-正常运行)
- Sysmon事件ID 22 DNSQuery
- Windows事件跟踪(Microsoft-Windows-DNS-Client ETW Provider)
Sysmon事件ID 22 DNSQuery Sample
“主机名”:“sld.tld。”"Severity": "INFO" "EventID": 22 "Source": "Microsoft-Windows-Sysmon" "ProviderGuid": "{5770385F-C22A-43E0-BF4C-06F5698FFBD9}" "Channel": "Microsoft-Windows-Sysmon/Operational" "Domain": "NTAUTHORITY" "AccountName": "SYSTEM" "UserID": "S-1-5-18" "AccountType": "User"
在上面的例子中，我们可以看到这个事件来自一个名为“sld.tld”的实例。既然我们知道这个事件的始作俑者，那么如果对IR进行调查，就有助于找到来源。域、帐户名和安全标识符(SID)(或UserID S-1-5-18)也可能有用。
"Message": Dns query: RuleName: UtcTime: 2020-10-29 11:32:43.274 ProcessGuid: {b3c285a4-5f1e-5db8-0000-0010c24d1d00} ProcessId: 5696 QueryName: example.com QueryStatus: 0 QueryResults:::ffff:93.184.216.34;图片:C:\Windows\System32\PING.EXE
Windows事件包括Message字段。从Message字段(这里已经解析过了)，我们可以看到Sysmon Event ID 22 DNSQuery事件是由于example.com使用的ping命令而发出的。
Sysmon事件ID 22日志记录的示例应用程序是什么?
假设example.com是一个很有意思的环节。该应用程序的一个功能是用风险评分丰富结果，在本例中，example.com获得了90分的高风险评分。通过收集到的日志，我们可以追溯到日期、时间、主机名、帐户、实用程序等。进一步的事件响应操作(如查找原始源)可以帮助对实例采取隔离/遏制措施，并提供一个用例，以便作为目标机器开始更广泛的日志记录。假设每天收集6亿个事件，那么将这些事件隔离到特定的时间范围内也可能有助于减少MTTD/MTTR以获取和查找其他IOC事件id。
进一步阅读:
有一项有趣的研究逃避Sysmon DNS监控而且使用Sysmon和ETW对二进制防御有更多的了解其中包含了利用DNS和Sysmon事件的部分。
Windows DNS Server来源
DNS服务器事件来源包括:
- Windows事件跟踪(Microsoft-Windows-DNS-Server-Service, Microsoft-Windows-DNSServer ETW提供商)
- DNS调试日志
- Windows事件日志通道
ETW / Windows DNS服务提供程序源代码
下面是来自Microsoft-Windows-DNSServer/分析频道的事件ID 260的片段。它只是键值对中的事件跟踪示例的一部分。
"Source": "Microsoft-Windows-DNSServer" "ProviderGuid": "{eb79065a - a566 -4698- 919 - 3ed2807060e7}" EventId": 260 "Severity": "INFO" "Domain": "NT AUTHORITY" "AccountName": "SYSTEM" "UserID": "S-1-5-18" "AccountType": "User" "TCP":"0" Destination": "Destination"。IP" InterfaceIP":接口。IP" "RD": "0" "QNAME": "subdomain.sld. "tld”“QTYPE”:“28”“XID”:“17271”“端口”:“0”“旗帜”:“0”“RecursionScope”:“。”"CacheScope": "Default" "PolicyName": "NULL" "BufferSize": "76" "PacketData": " 0x437700000001000000000001096c6f63616c686f73740975732d656173742d320d6563322d7574696c6974696d617a6f6e61777303636f6d00001c00010000290fa0000080000000 "
- QTYPE表示它是一个A记录，一个IP地址。
- QNAME:来自我自己的实例。
- AAAA: 28表示128位IPv6地址记录。最常用于将主机名映射到主机的IP地址。
如果您正在对同一事件的事件ID 260和WireShark DNS请求包进行比较，您将注意到当与完整的事件文本(例如PacketData, QNAME, DestinationIP等)进行比较时，DNS有效载荷中捕获了相同的字段。
ETW还可以使用其他来源来记录其他相关事件。来自F-Secure咨询公司实验室请注意另一个ETW提供商，微软- windows - webio，它为分析人员提供了一些系统进程发出的web请求的可见性。
关于ETW / Windows DNS服务提供商
简而言之，ETW有四个主要组成部分:
- 提供者——为windows会话的事件跟踪提供信息的提供者。
- 会话—内存缓冲区的集合，通过Windows ETW Provider API接受事件。
- controller -启动和停止ETW会话。
- 消费者-从日志文件中接收来自ETW会话的事件。
ETW拥有Windows遥测的宝贵资源。这超出了这篇文章的范围，但你可以在他们的文档门户．
Windows DNS服务器调试
以下是来自Windows DNS调试日志文件的示例测试片段。这种类型的日志记录应该只在一个临时的时间框架内运行，因为它的冗长特性会影响服务器的性能以及其他潜在的问题。必须对日志进行解析，以提取相关的元数据(如IP地址或协议)，作为日志收集的一部分。添加这个示例是为了说明原始日志本身还不能使用，需要进一步丰富才能使用。
10/30/2020 8:16:54 PM 0FC0 PACKET 000001E1A286DE90 UDP Rcv 172.31.21.66 16df Q [0001 D NOERROR] NS (0) 10/30/2020 8:16:54 PM 0FC0 PACKET 000001E1A34544B0 UDP Rcv 199.7.83.42 de78 R Q [0084 A NOERROR] NS (0)
XML格式的DNS服务器关闭事件片段
以下是Windows事件查看器中的XML视图中的Windows DNS关闭事件片段。虽然这是结构化数据，但您可以看到它如何偏离可以在其他系统(如SIEM)中使用的数据格式。需要事件源连接器，例如直接连接器、输入模块或日志代理，以规范化XML格式的XML日志。
<提供商名称="Microsoft-Windows-DNS-Server-Service" Guid="{71a551f5-c893-4849-886b-b5ec8502641e}" />
在我们还包括DNS基础设施上的审计日志记录之前，讨论涉及DNS的日志收集还没有完成。审计日志记录不仅有助于满足审计和遵从性目标，而且还为防御者提供事件数据，以帮助事件响应人员获得有关DNS基础设施攻击的更多信息。对服务器进行日志记录还可以满足涉及基础设施的任何其他操作和故障排除问题的需求。
这些事件源包括:
- Windows增强的DNS服务器审计事件(Windows- dnsserver /Audit通道-)Windows DNS日志和诊断-审计事件页面)
- Windows DNS服务器分析事件(请参见Windows DNS日志和诊断-分析事件页面)
- 微软活动目录(见AD事件监控资源而且微软审计政策建议）
- Microsoft DNS Windows组策略日志记录(请参阅DNS Windows组策略设置与DNS Client服务相关联)
增强的Windows DNS事件日志选项
这些事件的源包括Microsoft-Windows-DNSServer/审计事件日志通道，以及Windows提供程序的事件跟踪。DNS服务器上的审计日志所涵盖的事件类型包括:
- 缓存操作—清除缓存。
- DNSSEC操作-密钥翻转事件，导出/导入DNSSEC，信任点相关事件。
- 策略操作—创建、删除或更新客户端子网记录、区域级别策略、转发策略、客户端子网记录的事件。
- 服务器操作—重新启动服务器、清除调试日志、清除统计信息、更改侦听事件。
- 资源记录更新—资源记录(RR)创建事件，例如删除或修改记录。
- 区域操作—删除或更新区域，删除或更新区域作用域。
最后的问题
注意:从Source到SIEM图中您可能会注意到的一项是，我包含了本文未涉及的日志源——例如，Exchange日志以及来自其他收集过程的日志。我们将在本系列的最后一篇文章中更详细地讨论这些问题。
本文向您介绍了示例Windows日志收集部署、可以在Windows DNS服务器和客户端上收集的事件类型以及日志类型。请放心回到开头，检查您的部署是否涵盖了以下内容:
- 从现有的来源可以获得哪些关于DNS和域活动的监控信息?
- 为了提高日志的可见性(特别是包含域和DNS日志的元数据)，需要扩展哪些领域?
- 还有哪些其他机会可以总体上增加日志收集范围?
- 对于您自己的用例，这些来源中哪一个可以提供更好的情报?
- 您当前的日志部署是否满足您在威胁搜索、事件响应、编排、自动化等情报方面的最终阶段需求?
虽然深入研究实际部署细节(例如配置示例，或关于如何启用审计日志记录的说明)超出了范围，但您可以检查Microsoft文档以及您自己的日志代理和SIEM文档，以查看需要应用哪些配置以及有哪些可用选项。
使用DomainTools集成和api进一步丰富DNS和域智能(域风险评分)的相关事件，以及使用Iris平台的域IOCs。除了有针对性的日志记录外，还可以使用DomainTools作为主动和被动防御的一部分。
