原文：https://enigma0x3.net/2018/06/11/the-tale-of-settingcontent-ms-files/

作为攻击者，当面临一个经过安全加固的目标系统时，撕开系统的第一个口子通常是一个非常大的挑战。因为在选择有效载荷时，攻击者在文件格式的选择上面面临这样的限制：只需最少的用户交互就能执行代码或shell命令。实际上，能够满足这些要求的文件格式不多，常用的有.HTA、Office宏、.VBS、.JS等。在Windows上，由于内置文件格式非常有限，并且安全措施也不少，所以，可选的有效载荷的范围会进一步缩小。

此外，攻击者只是把有效载荷传递给最终用户还远远不够，同时，还必须让其得到执行才行。同样，这也会带来非常大的限制，因为直接链接到有效载荷或以电子邮件附件形式传递的话，防病毒软件或浏览器的保护措施通常会阻止这些文件进一步执行。这就是攻击者使用对象链接和嵌入（OLE）、ZIP文件的原因。为了对抗这些攻击手段，Office 2016在默认情况下会拦截通过OLE嵌入的具有“危险”格式的所有文件。当试图运行具有被禁止的文件扩展名的文件时，Office将抛出错误并阻止其执行：

除了OLE拦截之外，微软还在Windows 10中引入了攻击面缩减（ASR）规则，当然，它依赖于Windows Defender AV。这些规则的目的是减少可供攻击者用来在系统上执行代码的各种功能。一个最受欢迎和最有效的ASR规则就是“阻止Office应用程序创建子进程”。该规则不允许将生成的进程作为Office应用程序的子进程：

将OLE拦截和ASR结合在一起时，通过Internet让端点执行代码的方法将变得更加有限了。也就是说，对于Office 2016来说，大多数原来有效的文件类型无法通过OLE进行传递，而且ASR的子进程创建规则可防止在Office应用程序下生成任何子进程实例。

我们怎样才能绕过这些限制呢？首先，让我们先来解决文件格式问题。我花了很多时间来考察注册表，希望能够找到一些“漏网的”文件格式。这些格式可以在 HKCR:\ registry hive的根目录中找到。为了找到所需的格式，首先，要提取出所有已注册的文件格式，然后，再对可能的格式进行检查。

读了无数个小时的文件规范后，我偶然发现了“.SettingContent-ms”文件类型。这种格式是在Windows 10中引入的，用于为各种Windows 10设置页面创建“快捷方式”。实际上，它们就是一些XML文件，用于存放Windows 10设置二进制文件的路径。下面给出一个.SettingContent-ms文件的例子：

这个文件的功能非常简单：为用户打开控制面板。在这个文件中，最让人感兴趣的是模式中的<deeplink>元素。该元素可以接收带有参数的二进制文件并执行它。问题来了，如果将“control.exe”替换为“cmd.exe /c calc.exe”之类的东西，会发生什么呢？</deeplink>

然后，如果我们双击该文件，将会看到：

有趣的是，当双击该文件时，没有出现“open”提示；相反，Windows直接就把命令给执行了。

太棒了！我们找到了一种只要打开文件就能执行shell命令的文件格式。现在，具体该如何实施呢？接下来，我们来看看如果通过链接直接从互联网投递这个文件，将会发生什么情况。

(视频链接)

好极了！当从互联网直接下载这个文件时，只要用户点击“open”按钮，还是会执行。通过考察文件的数据流，你会注意到，它实际上会抓取网页标记（Mark-Of-the-Web）：

在网上查ZoneIds后，发现“3”等于“URLZONE_INTERNET”。由于某些原因，文件仍然在没有任何通知或警告的情况下执行。

因此，我们现在找到了一种符合要求的文件类型：可以用来执行任意的shell命令，并且不会向用户显示警告或对话。当寻找系统的突破口的时候，使用不常见的文件类型容易引起人们的怀疑。在理想情况下，应将其植入更常见的文件类型中，例如Office文档。

如前所述，当利用OLE方式嵌入内容时，如果文件类型位于黑名单中的话，那么Office 2016就会将其拦截。但幸运的是，该黑名单并没有包括SettingContent-ms文件格式：

现在，我们可以通过OLE嵌入恶意的.SettingContent-ms文件来绕开针对Office 2016 OLE文件类型的限制：

当文档来自互联网并且其中嵌入了.SettingContent-ms文件时，用户只会看到“Open Package Contents”提示。如果用户点击了“Open”按钮，同样会导致文件执行。如果系统没有启用任何攻击面缩减规则，攻击者就可以在端点上执行代码了。关于如何启用ASR的子进程创建规则，请参考本文的开头部分。还需要注意的是，截至本文发布时，ASR规则似乎不适用于从Windows应用商店安装的Office。

启用这些规则非常简单，可以使用一个PowerShell命令来完成：“Set-MpPreference -AttackSurfaceReductionRules_Ids <rule id=""> -AttackSurfaceReductionRules_Actions Enabled”</rule>

<rule id="">参数是要启用的规则的GUID。读者可以从这里找到每个ASR规则的GUID。对于该测试，我想启用的是子进程创建规则，即GUID D4F940AB-401B-4EFC-AADC-AD5F3C50688A。</rule>

启用该规则后，效果如下所示：

由于该规则旨在阻止从Office应用程序生成子进程，因此，当我们的有效载荷仍旧会执行，但是前面设置的规则会将拦截该命令。这促使我思考ASR是如何在不破坏某些功能的情况下实现这一点的。刚开始的时候，我是通过在随机路径中随机测试二进制文件的方法来判断ASR是否是根据二进制文件的路径进行拦截的。不过，由于这种方法非常耗时，没过多久就坚持不下去了。

最后，我退了一步，转而考虑Office的哪些部分是必需正工作的。在运行ProcMon并在Word中点击一番之后，当查看Process Explorer时，发现系统中仍然存在由Word生成的子进程。

当然，这么做有道理的，因为Office需要用到一些依赖于其他程序的功能。我认为ASR规则可能是根据镜像路径来阻止子进程的，但是当激活某些功能时，仍然允许利用Office路径中的镜像来生成子进程。

为了检验这个假设，我将自己的.SettingContent-ms文件改为“Excel.exe”的路径：

然后将这个新文件嵌入到Word文档中，并查看ASR是否阻止生成“Excel.exe”进程。

有趣的是，ASR会允许Excel启动。因此，子进程创建ASR规则似乎是基于列入白名单的路径来进行决策的。

于是，我开始从“C:\Program Files\Microsoft Office”路径中寻找可用的二进制文件——又是一条漫长之路，我逐个测试，通过命令行将“C:\Windows\System32\cmd.exe”作为参数传递给它们。苍天不负有心人，经过一番努力之后，终于成功了：

太妙了！这意味着可以利用“AppVLP”来执行shell命令。通常，这个二进制文件是用于应用程序虚拟化的，但这里竟然可以用于绕过ASR文件路径规则。为了进行深入的测试，我更新了自己的.SettingContent-ms文件，具体如下所示：

现在，只需将该文件嵌入Office文档并执行即可：

如您所见，即使Office 2016启用了OLE拦截功能和ASR的子进程创建规则，在.SettingContent-ms文件与Office文件夹中的“AppVLP.exe”的配合下，仍然可以绕过这些限制，从而执行任意命令。

尽管Office文档通常会用MOTW进行标记，并在受保护的视图沙盒中打开，但某些文件格式仍然允许使用OLE，并且受保护的视图沙箱也拿它们没招。读者可以从这里找到更多这样的文件类型。

总结

---

在研究了ASR和Windows 10中的新文件格式之后，我意识到，对每个Windows版本中新增的二进制文件和文件类型进行严格的安全审查是非常重要的。就本文来说，攻击者可以利用SettingContent-ms扩展能够绕过ASR规则和Office 2016 OLE拦截技术，在最新版本的Windows上运行任意命令。此外，尽管应用了MOTW，某些文件类型似乎在打开后仍然可以立即执行（即使从互联网上下载的文件，也是如此）。

防御措施

---

那么，我们如何防御这种攻击方法呢？总之，不要允许.SettingContent-ms文件在“C:\Windows\ImmersiveControlPanel”路径之外的任何地方执行。此外，由于该文件格式只允许执行shell命令，因此，通过该文件做的任何事情，都会被记录到命令行日志中。

另外，还可以一直监视从Office应用程序创建的子进程。虽然有些应用程序进程应该是从Office应用程序派生的，但是数量很少，因此，监视异常情况将非常有用。要想完成这些工作，可以借助于Sysmon工具。

此外，还有一种防御方法，那就是通过杀死这种文件格式的处理程序来防止收到这种类型的攻击。不过，我没有对此进行广泛的测试，并且不能保证Windows内的某些内容不会因此而受影响。对于那些想要了解杀死.SettingContent-ms文件格式的处理程序会带来什么影响的读者，可以将“HKLM:\SettingContent\Shell\Open\Command”中的“DelegateExecute”键设置为空。同样，这也可能会破坏操作系统上的某些功能，因此，请大家三思而后行。

这里，我们提供了一个SettingContent-ms文件的PoC： https://gist.github.com/enigma0x3/b948b81717fd6b72e0a4baca033e07f8