评估一个新的安全数据源的有效性: Windows Defender 漏洞利用防护（上）

预警和检测策略开发

随着我们对可用事件日志、它们的上下文和限制的新理解，我们的CIRT工程师现在可以在构建警报和检测策略时使用这些信息。以下是一些假设的样本，这些假设被开发用来作为潜在的警报/威胁搜索查询的基础，这些查询被漏洞利用防御缓解机制分解。

非微软官方的二进制加载

此 WDEG 缓解记录由微软签名的进程加载非微软签名模块的任何尝试。 这可以作为一个潜在的有价值的数据源，而不是将应用程序作为白名单的审计或实施。

范围

系统级别。 与某些文档相反，这种缓解措施可以应用于所有进程。 可以在全系统范围内应用的审计日志非常理想，可以用来识别误报，并将其列入白名单。 当然，系统范围的审计日志以事件量为代价，在非微软官方模块加载的情况下，事件量会很大。

潜在的异常观测

· 不能从System32或进程可执行文件中的子目录加载的模块。

· 基本原理:通常期望dll从所期望的位置加载。

· 从%windir%内的任何子目录加载的未签名的模块(SignatureLevel: 1)=

· 理由:期望签署合法的第三方代码。当然也会有例外，但是事件量应该相对较低。

· 一个用非标准扩展加载的模块,而不是 .dll。

· 基本原理:加载到进程中的大多数模块都是dll。

· 一个加载时间远远大于主机进程启动时间的模块。

· 原理:这是一个潜在的注入指示器。尽管如此，还是要做好假阳性的准备。、

· 加载到受保护或受保护的进程光(PPL)进程中的模块，由 ProcessProtection 字段的非零值表示。

· 基本原理:这表示受保护进程所保证的安全性失败。这个事件的容量应该是非常低的。

已知的误报

· 从全局程序集缓存(GAC)加载的任何二进制文件(例如，以“\Windows\assembly”开头的)。 这些是 NGEN'd (为性能目的而构建的本地编译的的.Net 程序集)二进制文件，虽然没有签名，但l来自于已签名 .Net 程序集(假设 GAC 没有被篡改——需要管理员权限)。 任何 .Net 进程都将加载这些二进制文件。

减少误报的策略

· 将未签名的 DLL (SignatureLevel: 1)和已签名的 DLL(SignatureLevel: 4)分开。 虽然恶意软件肯定可以被签名，但它更有可能是未签名的。

· 将宿主进程为 windows 签名的事件(SignatureLevel: 9及以上)与 微软签名的事件分开(SignatureLevel: 8)

缺失的事件上下文

· 记录的 DLL 的哈希。

· 如果模块已签名(即 SignatureLevel: 4) ，则不会显示签名者信息。

远程镜像加载

每当从远程共享(SMB/WebDAV)加载镜像时，远程镜像会加载缓解日志。 建议在系统范围内记录这种缓解。

范围

系统级和进程级。 当处于审计模式时，理想情况下应该启用系统范围的设置，因为事件量应该相对较低。

减少误报的策略

· 识别从非 Palantir 远程资源加载的镜像的事件量。

缺失的事件上下文

· 镜像哈希

字体审核/阻塞

字体已经被频繁地用作获得直接的、任意的内核代码执行的手段。 由于它们的复杂性、渲染程序(Win32K 子系统)的复杂性，以及它们历来都是在内核中加载的，因此它们一直是被广泛滥用的攻击目标。 作为一个漏洞利用原语，字体最常被加载到内存中，为此，字体加载事件可以捕获特定的上下文。 任何非标准字体加载都应该仔细检查，并且应该是低容量事件。

范围

系统级

潜在的异常观测

· 最初，所有字体加载事件都应该在审计模式下检查，以验证事件量。

· 如果SourceType为1(加载在内存中)或2(远程加载)，则特别可疑。

· SourceProcessName是一个可能没有加载字体的进程。

· 一个来自%windir%\Fonts  以外任何地方的 FontSourcePath 

缺失的事件上下文

· 字体哈希

· 进程命令行值

· 字体元数据(版权等)

调优

我们给团队最重要的建议是，一些应用程序可能会失败，并且需要规则调优。在软件目录不被很好理解的环境中，或者在终端用户有能力安装他们自己的程序包的情况下，尤其如此。合理的LOB应用程序测试周期是评估影响的最佳方法(使用本指南中推荐的初始配置)。在这个阶段，非常宽容的“金丝雀”用户（译者注：可以理解为灰度用户）在这个阶段是非常宝贵的。

也就是说，当应用程序由于漏洞利用防护而失败时，第一个症状通常是应用程序根本无法启动。 在测试期间，我们在一些应用程序中观察到了这种行为。 其中一些比较值得注意的是 Firefox、 PowerShell ISE 和 Box 同步客户端。 (故障发生在我们启用 CFG 作为系统范围保护的时期)。

后来，当我们将策略推向生产环境时，我们在应用程序启动后的随机时间内观察到少量的 if 故障。 在我们自己的设备上采用与最终用户相同的策略，这使我们有机会以下面的几种方式快速重现和观察故障:

· 漏洞利用防护失败最明显的迹象是漏洞利用保护特定的日志条目，如本文档所述的。

· 我们还发现，崩溃应用程序的常规 Windows“应用程序日志”条目是一个很好的指示器。 日志条目没有直接指向漏洞利用防护，但是它们在一个非常明显的日志位置(默认应用程序日志)中留下了一个快速的、红色的、警告性的叉号。

· Another thing we tried on a few applications was running them inside a windbg session. We didn’t do anything fancy, simply started the debugger, launched the trouble making application inside the debugger, then hit “g” for go. Applications that failed at launch would immediately show a second chance exception “ 我们在一些应用程序上尝试的另一件事是在 windbg 会话中运行这些程序。 我们没有做任何奇特的事情，只是简单地启动调试器，在调试器中启动制造麻烦的应用程序，然后点击“g”就可以了。 在启动时失败的应用程序将立即显示第二次机会异常“安全检查失败或堆栈缓冲区溢出——错误码 c000409(! ! ! 第二次机会! !)”。那些需要一段时间才能崩溃的应用程序通常可以很正常的通过调试器启动，并且在由于漏洞利用防护而崩溃之前一直可以正常使用。

我们一般正在进行的方法是检查我们转发给 SIEM 的漏洞利用防护事件，以获得环境中新的应用程序故障的指示器，并在支持票据被记录之前尝试纠正故障。

总而言之，到目前为止，故障的比率低得惊人。 也许我们不够有侵略性，因为漏洞利用防护提供了更加自信的控制，但是我们会谨慎地平衡业务需求和安全结果。 我们将在接下来的六个月里进一步收紧策略，并计划联系那些努力支持漏洞利用防护的应用程序供应商。

现在，Github 中提供的保护措施是我们如何部署这项技术的一个合理的最新参考。 我们希望这将使你容易得到你的参考系统构建方案。 真正简短和直截了当的版本是，我们在系统范围内部署了 DEP、 BottomUp 和 SEHOP，然后我们进一步为核心应用程序集进行了日志记录。

总结

通过记录、配置、部署和调优 Windows Defender 漏洞利用防护提供的丰富的安全数据源，我们现在可以形成警报和威胁搜寻假设，这将作为开发健壮的警报和检测策略的基础。 我们希望通过这篇文章，你可以了解企业安全态势背后的人员和流程。

同样重要的是要承认，盲目地相信安全供应商会暴露这种光学信息或根据这种遥测信息提供高质量的警报并不总是可行的。 我们坚信，尽管终端安全产品在整体安全计划中发挥着重要作用，但它们永远不可能100% 地适应企业环境的独特需求。 这就是为什么与其等待其他人围绕一项新技术建立方法论，不如大家一头扎进去评估它可能提供的潜在价值，我们希望你也能这样做！

进一步阅读

· Windows Defender 安全漏洞防护主页

· 攻击面缩小

· 漏洞利用保护

· Palantir漏洞利用防护事件参考

本文翻译自：https://medium.com/palantir/assessing-the-effectiveness-of-a-new-security-data-source-windows-defender-exploit-guard-860b69db2ad如若转载，请注明原文地址： https://www.4hou.com/system/22278.html