通过有针对性的DNS日志记录改进防御
这篇文章的目的是向您介绍如何在Microsoft Windows平台上收集日志。我们将首先演示Windows纯源日志部署，然后从日志样例中收集所选字段，并简要描述这些源。最后一部分将讨论审计日志记录，因为它在确保基础设施防御方面发挥着重要作用。
Windows日志部署场景
为了开始本文第二部分所述的调查，分析人员和事件响应人员需要配备相关的DNS和域日志，从而使他们能够看到网络上发生的相关事件。您的组织可能已经在某种程度上部署了类似于下面所示的集中式日志记录形式。如果没有，那么总是有改进的空间!
从源头到SIEM
左边是可能的日志源。我定义了一个示例日志部署的一小部分，尽管惟一日志源端点的实际数量比这里所演示的多得多。然后，当我们移到图的右侧时，我们可以看到日志如何通过日志管理服务器或数据湖转发，然后转发到SIEM进行进一步操作。
从这些事件源…
左边图表的源端说明了一些潜在的源。客户端机器表示客户端发生了需要收集的事件。我添加了一些标签来显示要收集的事件类型的一些示例—例如由Windows Sysinternals System Monitor (Sysmon)生成的事件、对高值eventid的任何订阅和通道。还有一些其他的日志源没有使用Windows Event log遥测技术，比如基于文件的日志记录，还有一些日志源被分组在“其他预定义的收集过程”区域中，比如(用图标表示)Windows防火墙、Powershell日志记录、入口日志记录。
在这个例子中定义了三个服务器:
- 内部邮件服务器，即Exchange服务器。设置它是为了收集Exchange Message Tracking Logs(在元数据中包含IP和主机名信息)。
- Windows DNS服务器。日志收集设置在DNSServer Windows EventLog Analytic通道上，以及审计日志。收集也可以手动启用并设置为收集DNS调试日志事件。
- Active Directory服务器。由于许多原因，该服务器是一个高价值的目标。设置日志收集是为了收集GPO或组策略对象日志，以及审计日志。
还有许多其他日志源为DomainTools调查和集成提供有价值的情报，如来自防火墙事件的日志、Windows IIS服务器日志、入站身份验证尝试等。您甚至可以部署基线集合以及启用可疑基线集合的选项，这将需要对可疑目标机器进行更详细或扩展的集合。
.．.到SIEM进行集成、自动化和分析
Windows订阅可以部署为只拉出Windows EventLog事件(通过WEF, Windows事件转发)。从这些客户端/服务器源，这些事件被转发到Windows事件收集器。
还将部署另一个由SIEM或第三方提供的收集器，以收集更多的事件，以扩大可见性，并确保不遗漏其他类型的日志——例如基于文件的日志记录。
这些事件最终可能被转发到数据湖或日志管理服务器。由于存储、基础设施和许可成本等原因，并不是所有事件都没有SIEM支持的用例，所以不会将所有日志都发送到SIEM中。
日志规范化的过程很重要，因为条目不是用标准格式写的。除了规范化日志之外，还应用了对这些事件的解析和丰富。这些过程在传输过程中由收集器和/或在源本身的磁盘上或在日志管理服务器上完成。
一旦日志到达SIEM，它们将用于额外的集成，提供要完成的任何其他操作(分类)，丰富分析，触发警报，等等。
Windows事件日志
到目前为止，我们已经介绍了一个日志部署示例。以下是来自所选Windows DNS日志的示例字段，可以让您了解所提供的信息类型。请注意，这些已经被丰富/写入到另一种格式，它们只是片段，而不是完整的日志本身。
Windows DNS Client来源
针对DNS事件的Windows DNS客户端事件源包括:
- Windows事件日志通道(DNS客户端事件-正常运行)
- Sysmon事件ID 22 dns查询
- Windows事件跟踪(Microsoft-Windows-DNS-Client ETW Provider)
Sysmon事件ID 22 DNSQuery样本
“主机名”:“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)(或用户id 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 Event ID 22日志记录的示例应用程序是什么?
假设example.com是一个非常有趣的环节。该应用程序的一个特点是用风险评分丰富结果，在这种情况下，example.com获得了90分的高风险评分。通过收集到的日志，我们可以追溯到日期、时间、主机名、帐户、实用程序等。进一步的事件响应操作(如查找原始源)可以帮助对实例采取隔离/遏制措施，并提供一个用例，以便作为目标机器开始更广泛的日志记录。假设每天收集6亿个事件，然后将这些事件隔离到特定的时间范围内，这也有助于减少MTTD/MTTR，以获取和查找其他IOC eventid。
进一步阅读:
有一项有趣的研究逃避Sysmon DNS监控而且使用Sysmon和ETW进行二进制防御其中包含了利用DNS和Sysmon事件的部分。
Windows DNS Server来源
DNS服务器事件的来源包括:
- Windows事件跟踪(Microsoft-Windows-DNS-Server-Service, Microsoft-Windows-DNSServer ETW Providers)
- DNS调试日志
- Windows事件日志通道
ETW / Windows DNS服务提供程序源
以下是来自Microsoft-Windows-DNSServer/事件ID 260分析通道的一个片段。它只是键值对中的事件跟踪示例的一部分。
"Source": "Microsoft-Windows-DNSServer" "ProviderGuid": "{eb7906a1 - a566 -4698-9119- 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. IP"tld”“QTYPE”:“28”“XID”:“17271”“端口”:“0”“旗帜”:“0”“RecursionScope”:“。”"CacheScope": "Default" PolicyName": "NULL" "BufferSize": "76" "PacketData": " 0x437700000001000000000001096c6f63616c686f73740975732d656173742d320d6563322d7574696c6969657309616d617a6f6e61777303636f6d00001c00010000290fa0000080000000 "
- QTYPE表示这是一个A记录，一个IP地址。
- QNAME:来自我自己的实例。
- AAAA: 28表示128位IPv6地址记录。最常用的是将主机名映射到主机的IP地址。
如果您正在比较事件ID 260和同一事件的WireShark DNS请求报文，您会注意到，当与完整的事件文本(如PacketData、QNAME、DestinationIP等)比较时，在DNS负载中捕获了相同的字段。
ETW还可以使用其他来源记录其他相关事件。F-Secure咨询公司的实验室请注意另一个ETW Provider, Microsoft-Windows-WebIO，它为分析人员提供了由某些系统进程发出的web请求的可见性。
关于ETW / Windows DNS服务提供商
简而言之，ETW有四个主要组成部分:
- 提供者——为windows会话的事件跟踪提供信息的提供者。
- 会话—内存中缓冲区的集合，通过Windows ETW Provider API接受事件。
- 控制器—启动和停止ETW会话。
- 使用者——从日志文件接收来自ETW会话的事件。
ETW拥有Windows遥测技术的宝贵资源。这超出了本文的范围，但是你可以在他们的文档门户．
Windows DNS Server调试
下面是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日志。
DNS Server ec2-xx-xxx-xxx-xx.us- east2.compute.amazonaws.com
Windows审计日志
在我们还包括DNS基础设施上的审计日志之前，还没有完成对涉及DNS的日志收集的讨论。审计日志记录不仅有助于实现审计和遵从性目标，而且还为防御者提供事件数据，以帮助事件响应者获得关于DNS基础设施攻击的更多信息。对服务器进行日志记录还可以满足涉及基础设施的任何其他操作和故障排除问题的需要。
这些事件源包括:
- Windows增强的DNS服务器审计事件(Windows- dnsserver /Audit通道- .Windows DNS日志和诊断—审计事件页面)
- Windows DNS服务器分析事件(参见Windows DNS日志和诊断-分析事件页面)
- 微软活动目录(参见监控资源的AD事件而且Microsoft审计策略建议）
- Microsoft DNS Windows组策略日志记录(参见DNS Windows组策略设置与DNS Client服务关联)
增强的Windows DNS事件日志选项
这些事件的来源包括Microsoft-Windows-DNSServer/Audit EventLog通道，以及Windows提供程序的事件跟踪。DNS服务器上的审计日志所涵盖的事件类型包括:
- 缓存操作—清除缓存。
- DNSSEC操作—密钥翻转事件、导出/导入DNSSEC、信任点相关事件。
- 策略操作—创建、删除或更新客户端子网记录、分区级别策略、转发策略、客户端子网记录的事件。
- 服务器操作—重新启动服务器、清除调试日志、清除统计信息、监听事件的更改。
- 资源记录更新—资源记录(RR)创建事件，如删除或记录被修改。
- 区域操作—删除或更新了区域，删除或更新了区域作用域。
最后的问题
注意:从Source to SIEM图中您可能注意到的一项是，我包含了本文中没有涉及的日志源——例如，Exchange日志以及来自其他收集过程的日志。我们将在本系列的最后一篇文章中更详细地讨论这些内容。
通过这篇文章，您已经了解了一个示例Windows日志收集部署、可以在Windows DNS服务器和客户端上收集的事件类型以及日志类型。请随意回到开头，检查您的部署是否涵盖了以下内容:
- 从现有的资源中可以获得哪些关于DNS和域活动的监控信息?
- 为了提高日志记录的可见性，特别是包含域和DNS日志的元数据，需要扩展哪些方面?
- 还有什么其他机会可以总体上增加您的日志收集范围?
- 这些来源中哪一个为您自己的用例带来了更好的智能?
- 您当前的日志部署是否满足针对威胁搜索、事件响应、编排、自动化等的情报方面的最终阶段需求。
虽然深入了解实际的部署细节(例如配置示例，或关于如何启用审计日志记录的说明)超出了讨论范围，但是您可以查看Microsoft文档以及您自己的日志代理和SIEM文档，以了解需要应用哪些配置以及有哪些选项可用。
使用域工具集成和api，通过DNS和域智能(域风险评分)进一步丰富相关事件，以及使用域ioc与Iris平台。使用DomainTools作为您的主动和被动防御的一部分，除了有针对性的日志记录。