如何滥用Windows库文件实现本地持久化-安全客

一、前言

想象一个，如果有个攻击者在我们的电脑上释放了一个恶意文件，每当我们访问系统中最喜欢的目录（如Documents目录）时就会执行恶意文件，并且我们对此一无所知，这是多么恐怖的一件事。攻击者可以利用鲜为人知的一种持久化技术：Windows库文件（Library File）来完成这个任务。

Windows系统中的库文件可以帮助用户在单个视图中查看多个目录的内容。Windows库可以包含存在本地或者远程存储位置中的文件及目录。

对这些文件的恶意使用最早可以追溯到维基解密公布的Vault 7相关材料，该方法与滥用Junction目录的方法有许多相似之处。这两种技术检测起来较为困难，因此攻击者可以选择这些方案，即便是最好的检测团队也会面临巨大的挑战。

本文以较短的篇幅介绍了如何滥用库文件实现本地持久化，也介绍了如何针对性寻找这类攻击特征。

二、何为库文件

默认情况下，Windows库文件的具体路径为%APPDATA%\Microsoft\Windows\Libraries，文件扩展名为library-ms。这些文件采用XML格式，遵循公开可用的schema。

举个例子，我们来分析Documents库文件（即Documents.library-ms），该文件对应的是Documents目录。观察该文件，其中最有趣的部分是SimpleLocation元素的URL值。这个元素定义了基于文件系统或者协议处理程序的“search connectors”（搜索连接器）的具体位置。

在这个例子中，该库文件中的URL元素使用GUID（global unique identifiers，全局唯一标识符）指向了两个不同的目录，具体的GUID及文档目录如下所示：

GUID	目录
{FDD39AD0-238F-46AF-ADB4-6C85480369C7}	%USERPROFILE%Documents
{ED4824AF-DCE4-45A8-81E2-FC7965083634}	%PUBLIC%Documents

由于使用了这两个位置，因此打开这个库时，用户可以在一个视图中查看两个不同目录的内容。这两个目录各自的内容如下图所示：

然而，如果我们以库方式来查看时，这些子元素都会在同一个目录中列出：

三、创建恶意库文件

那么我们如何利用这一功能实现本地持久化呢？

最简单的技术是添加另一个URL元素，用来加载恶意的COM对象，这样每当用户访问该目录或者系统呈现该目录时，我们的COM对象就会被执行。

在如下例子中，我们创建了一个COM对象，该对象引用了名为beacon.dll的一个载荷。

然后在库文件中添加一个searchConnector，其URL元素引用的是我们创建的CLSID。

最后，将库文件保存到用户桌面，这样看起来像是一个人畜无害的Documents目录。如果用户打开该目录，则会显示正常Documents目录的内容。然而在后台我们的COM对象同样会被执行，利用rundll32.exe运行我们的载荷，进程的PID值为5392.

有趣的是，rundll32看上去似乎没有父进程。这是因为父进程dllhost.exe（COM Surrogate进程）会在运行COM对象后退出。在Sysmon中，我们可以看到如下图所示的类似事件，显示dllhost.exe为父进程，rundll32.exe为子进程。

观察Process Monitor，我们可以看到dllhost.exe会查询我们创建的CLSID，然后加载我们的beacon.dll，最后执行rundll32.exe。

虽然这个过程中使用的这些数据点可作为检测特征，但合法的活动也会用到这种方式，因此很可能出现误报，然而，通过数据点关联我们可以得出更为准确的结果。

四、本地持久化

为了实现本地持久化，我们需要系统在启动时能够执行我们的library-ms文件，那么怎样才能达到这个目的呢？

除了常见的本地持久化技术以外，还有更为隐蔽的一种方法，那就是利用Windows Explorer，在用户查看包含该文件的目录时就会自动执行该文件。因此用户无需实际点击文件，只需要简单查看某个目录就足以达到同样的效果。比如，我们可以将库文件放在桌面上，这样当系统启动时，Explorer会自动呈现桌面，我们的COM对象就得以执行。

从检测角度来看，在启动时执行和在用户点击时执行的区别在于，启动执行的父进程为explorer.exe，因为Explorer是呈现库文件的根本原因。