一、概述

在攻击的早期阶段，我们其实很难深入了解攻击者的节奏。通常，在侦查（Reconnaissance）和武器化（Weaponization）阶段，如果研究人员想要确定攻击者大致需要多久才能与目标直接进行交互，他们用于分析的数据少之又少。我们在对2018年8月攻击中东地区政府并投递BONDUPDATER恶意软件的组织进行持续分析的同时，观察到OliRig的一系列测试活动。我们有证据表明，这些测试活动与攻击中所使用的武器化交付文件具有关联性。

由于我们此前已经观察到OilRig在他们的交付文档和TwoFace WebShell上进行测试活动，因此这次也成功发现，OilRig在他们的开发过程中使用了一个测试组件。这一测试组件用于对其交付文档进行部分修改，并将其提交到在线反病毒扫描工具，从而确定所提交文件的被检测情况，从而找出规避检测的方法。利用这些在线扫描程序，攻击者可以迅速了解哪些反病毒引擎能够检测到恶意软件，在侧面为攻击者提供了一个“质量保证服务”。

为了确定OilRig恶意组织的时间线，我们比较了测试文件的创建时间、交付文档的创建时间以及攻击过程中鱼叉式网络钓鱼邮件的发送时间。我们发现，OilRig在对目标发起攻击的6天前就开始进行测试工作，并且在8月20日、21日和26日尝试进行了三次测试。测试人员在交付文档创建的8小时前创建了最终的测试文件，随即在20分钟后将交付文档通过鱼叉式网络钓鱼邮件发出。

二、测试活动

在调查OilRig组织利用最新版本的Boudupdater进行攻击的过程中，研究人员查找了OilRig利用过的其他Microsoft Office文档，从而希望找到在同一时期内用于其他攻击的恶意软件。我们找到OilRig制作的原始Microsoft文档后，重点对其进行了功能性分析。

我们的研究人员共计发现了11个额外的样本，这些样本分别在几个反病毒测试平台提交，如下表所示。这些样本似乎都是OilRig在开发和测试阶段创建的，所有这些文件都与最终的交付文档有众多相似之处。此外，下表中也包含了OilRig最近针对中东政府攻击所使用的文件N56.15.doc（7cbad6b3f505a199d6766a86b41ed23786bbb99dab9cae6c18936afdc2512f00）。在此测试期间，我们发现文档的名称中包含我们在此前攻击中见过的C&C，特别是文档XLS-withyourface.xls和XLS-withyourface – test.xls。由于这些文档在元数据、宏代码和包含C&C域名的文件名中具有高度相似性，因此我们认为，这些文件实际上是OilRig在8月26日发动攻击前的测试文件。有趣的是，尽管所有测试文件都是Microsoft Excel文档，但在实际攻击中使用的是Microsoft Word文档。

根据上述表格中的元数据，可以看出OilRig开发人员在针对目标发动攻击的6天前（8月20日）就开始创建这些测试文档。OilRig进行的所有测试活动都发生在8月26日的攻击之前。我们通过查看测试活动和攻击活动中相关文件的“上次修改日期”，很容易绘制出完整恶意活动的时间轴，如下图所示。

8月20日，有22个反病毒引擎检测到XLS-withyourface.xls的第一次迭代版本存在威胁，如下面的图表所示。在接下来的7分钟内，测试人员创建了另外两个样本，其检出数量降低了16，仅有6个反病毒引擎能够成功检出。测试过程中，检测率的最低值出现在测试阶段的早期，也就是8月21日。在上图的时间轴中，展示了测试活动的详细情况。最后一次测试迭代发生在实际攻击所使用的Word文档创建前不到8个小时。

上图的图表展现了在每次测试迭代期间，测试人员修改Excel文档时检测率的升降趋势。检测率的这些变化，能够让测试人员清楚的了解这些对文件的修改是否能避免被检出。在分析他们的测试活动时，我们将每次迭代中执行的更改数量（基于GitHub文件的修改记录，主要关注插入和删除的行数）与检测率进行比较，从而确定改动的多少是否与检测率的升降有关。结果表明，迭代1和迭代2之间只有很小的变动，然而检测率却发生了大幅下降。而迭代3和迭代4都进行了大量改动，检测率分别小幅下降和大幅增加。

站在一个较高的层面上来看，改动的代码量对于测试者来说并不重要，他们真正关注的是这一改动是否能够带来检测率的降低，以及是否能够提供有关如何规避检测的有用信息。其中的一个例子是，在迭代2中他们删除了使用“wscript”运行已经交付的VBScript的代码行，从而将检测率从16降低到6。最终，测试人员使用了这些测试迭代过程中获得的知识，创建了一个更难检测且能够成功实现攻击的交付文档。

三、测试过程中的迭代分析

我们对该恶意组织测试过程中的每次迭代版本进行了分析。我们进行分析的大致思路如下：

1、文件变化：比较两个文件的SHA256哈希值，以确定恶意组织对文件是否做出了更改。

2、文件名变化：比较两个文件的文件名。

3、时间差：在每个文件的元数据中，找到“已修改”的时间戳，并比较其时间差。

4、检测率变化：比较两个文件的检测率，从而发现测试迭代之间的变化对整体检测所产生的影响。

在每个迭代版本的分析中，重点关注针对交付文档中宏所做的更改。在比较文件代码差异的截图中也能直观的看到这些变化，红色背景的代码是删除的部分，绿色背景的代码是添加部分。

3.1 迭代0

在测试过程中，我们所监测到的第一个文档似乎不是由恶意组织创建的原始文档。因为，该Excel中包含名为__SRP_0的流，该流中似乎包含交付文档早先版本中的工件。__SRP_0流中包含工件，特别是一系列Base 64编码的字符串。将这些字符串进行解码之后，我们发现它几乎就是名为“AppPool.ps1”的Boundupdater PowerShell Payload脚本，该脚本在此前OilRig对中东政府发动攻击时，作为恶意软件（（7cbad6b3f505a199d6766a86b41ed23786bbb99dab9cae6c18936afdc2512f00））的交付脚本。我们将__SRP_0中解码后的Base 64字符串与之前分析过的AppPool.ps1文件进行了比较，二者完全相同（包括withyourface[.]com这一C&C域名），唯一的区别是换行符和空格。

当我们分析这个特定的样本时，我们注意到测试人员已经对PowerShell Payload进行了修改。与之前由宏写入AppPool.ps1文件不同，在这里，恶意Excel文档中的宏只负责写入AppPool.vbs，随后将使用“wscript”运行宏。随后，VBScript负责将AppPool.ps1写入到系统之中。这一点，与我们之前分析的Word文档有很大不同。

此外，测试人员似乎彻底从样本中删除了Boundupdater Payload。AppPool.vbs脚本使用一个名为“mysrc”的空变量，该变量将用于存储Base 64编码后的Payload，该内容将会被解码，随后保存到AppPool.ps1文件中。

如前所述，我们认为这一测试活动先于我们此前分析的Word交付文档。此外，我们还认为这不是恶意组织进行的第一轮测试，因为__SRP_0流中存在的Boundupdater工具表明，测试人员在此之前已经创建了一个包含Payload的恶意文档。测试人员可能对PowerShell Payload进行了测试，并将其删除，从而防止交付文档中的宏被检测。

3.2 迭代1

文件变化：

· 6f522b1be1f2b6642c292bb3fb57f523ebedeb04f0d18efa2a283e79f3689a9f

· 9b6ebc44e4452d8c53c21b0fdd8311bac10dc672309b67d7f214fbd2a08962ce

文件名变化：XLS-withyourface.xls -> XLS-withyourface.xls

时间差：1分钟41秒

检测率变化：22 -> 16

在此迭代中，测试人员进行了一次简单的更改，其中包括删除字符串“powershell.exe”，使其不被写入到AppPool.vbs文件中。这一更改实质上会破坏安装过程，因为VBScript将无法再正确运行AppPool.ps1。测试人员之所以进行这样的更改，是想要测试删去该字符串是否能有效降低检测率。下图没有直观展现出“powershell.exe”字符串的变化，但仔细观察第24行Shell0的位置，可以在左侧看到“powershell.exe -exec bypass”（红色）和“-exec bypass”（绿色）字样。

3.3 迭代2

1、文件变化：

· 9b6ebc44e4452d8c53c21b0fdd8311bac10dc672309b67d7f214fbd2a08962ce

· a5bec7573b743932329b794042f38571dd91731ae50757317bdaf9e820ec8d5e

2、文件名变化：XLS-withyourface.xls -> XLS-withyourface.xls

3、时间差：6分钟57秒

4、检测率变化：16 –> 6

在这一迭代中，测试人员删除了运行AppPool.vbs脚本的代码，如下图所示。

3.4 迭代3

1、文件变化：

· a5bec7573b743932329b794042f38571dd91731ae50757317bdaf9e820ec8d5e

· a5bec7573b743932329b794042f38571dd91731ae50757317bdaf9e820ec8d5e

2、文件名变化：XLS-withyourface.xls -> XLS-withyourface.xls

3、时间差：10小时46分钟1秒

4、检测率变化：6 -> 4

在此迭代中，测试人员对宏进行了相当重要的更改。首先，他们加入了一行代码，在创建C:\ProgramData\WindowsAppPool文件夹后、将AppPool.vbs写入该文件夹前将睡眠10秒，这一变动可以在下图的第12行看到。此外，还将Base 64编码后的Boudupdater PowerShell Payload添加到DDDD变量中，而不是先前版本所看到的VBScript。在这里，Base 64编码后的Boudupdater与迭代0中提及的第一个测试样本缓存__SRP_0流中的Boudupdater完全相同。最后，这一版本还删除了设置Shell0变量以包含“wscript.shell”对象的相应行，这一行理论上是用来运行VBScript。

添加了Sleep代码：

对用于存储VBScript的变量进行更改：

删除了“wscript.shell”对象：

3.5 迭代4

1、文件变化：

· 6719e80361950cdb10c4a4fcccc389c2a26eaab761c202870353fe65e8f954a3

· 056ffc13a7a2e944f7ab8c99ea9a2d1b429bbafa280eb2043678aa8b259999aa

2、文件名变化：XLS-withyourface.xls -> sss.xls

3、时间差：1小时33分钟24秒

4、检测率变化：4 -> 18

在此迭代中，测试人员使用上一次迭代中替换的VBScript，来替换宏中Base 64编码后的PowerShell脚本。此外，还删除了一些实例化的Scripting.FileSystemObject以及Wscript.Shell对象（参见下图的第17-18行）。

下图展现了已经将VBScript：

在这一版本中，似乎测试人员将VBScript重新引入宏，并且略做修改。存储在DDDD变量中的VBScript有两处进行了修改，目的是模糊脚本中两个字符串的出现方式，特别是“powershell”（下图中第24行）和“cmd.exe”（下图中第25行）。这两个字符串使用每个字符的十六进制值，一次只构造一个字符，并且连接在一起。例如：“powershell”字符被替换成如下内容

Chr(CLng("&H70")) & Chr(CLng("&H6f")) & Chr(CLng("&H77")) &
Chr(CLng("&H65")) & Chr(CLng("&H72")) & Chr(CLng("&H73")) &
Chr(CLng("&H68")) & Chr(CLng("&H65")) & Chr(CLng("&H6c")) &
Chr(CLng("&H6c"))

测试人员还添加了一行（下图中第29行），使用内置的Shell函数，利用wscript应用程序运行“AppPool.vbs”脚本。在调用Shell函数时，使用了“vbHide”标志，该函数会在隐藏窗口中运行该命令。

下图展现了字符串混淆和内置Shell函数的使用：

3.6 迭代5

1、文件变化：

· 056ffc13a7a2e944f7ab8c99ea9a2d1b429bbafa280eb2043678aa8b259999aa

· 216ffed357b5fe4d71848c79f77716e9ecebdd010666cdb9edaadf7a8c9ec576

2、文件名变化：sss.xls -> sss.xls

3、时间差：5分钟6秒

4、检测率变化：18 -> 5

在这一迭代版本中，测试人员使用他们在上一次迭代中引入的wscript，替换对内置Shell函数的调用，该函数运行“AppPool.vbs”脚本。下图展示了新迭代用空行替换了第29行的代码。

3.7 迭代6

1、文件变化：

· 216ffed357b5fe4d71848c79f77716e9ecebdd010666cdb9edaadf7a8c9ec576

· 687027d966667780ab786635b0d4274b651f27d99717c5ba95e139e94ef114c3

2、文件名变化：sss.xls -> sss.xls

3、时间差：5分钟14秒

4、检测率变化：5 -> 17

在此迭代中，测试人员重新引入对先前迭代中删除的内置Shell函数的调用。但是，这里没有包含运行命令，省略了使用wscript运行“AppPool.vbs”脚本的字符串。下图展示了对Shell函数的调用，使用了空白的命令参数。这样一来，反病毒软件的检测率明显提升，由此说明普遍的检测机制并不是针对命令本身，而是检测对于内置Shell函数的泛型调用。

3.8 迭代7

1、文件变化：

· 687027d966667780ab786635b0d4274b651f27d99717c5ba95e139e94ef114c3

· 364e2884251c151a29071a5975ca0076405a8cc2bab8da3e784491632ec07f56

2、文件名变化：sss.xls -> sss.xls

3、时间差：10分钟

4、检测率变化：17 -> 9

在此迭代中，重新引入命令wscript来运行“AppPool.vbs”脚本，以调用内置的Shell函数。但是，这次测试人员使用了“vbNormalFocus”标志来替代“vbHide”标志，在可见的命令提示符窗口中运行该命令。这一更改，使检测率降低了8，这表明多个反病毒软件都将Shell函数中使用“vbHide”标志视为恶意。

3.9 迭代8

1、文件变化：

· 364e2884251c151a29071a5975ca0076405a8cc2bab8da3e784491632ec07f56

· 66d678b097a2245f60f3d95bb608f3958aa0f5f19ca7e5853f38ea79885b9633

2、文件名变化：sss.xls -> sss – Copy.xls

3、时间差：4天21小时24分钟31秒

4、检测率变化：9 -> 11

这一版本的迭代，在上一版本提交的5天之后才进行提交。在此期间，恶意组织可能进行了新一轮的测试活动。然而，这个新文件的文件名为“sss – Copy.xls”，而前一个文件名为“sss.xls”。这表明。测试人员可能复制了上一次迭代中生成的文件，并以此为基础进行本次迭代测试。

在此迭代中，对宏的多个部分进行了更改。首先，删除了宏中休眠10秒的代码行，这一行是在迭代3中首次引入的。这一版本的迭代中删除了这行代码，并使用“Application.Wait”函数来实现10秒的休眠。

下图展示了休眠功能的删除。

另一个修改是Shell函数内部运行的命令，使用了与此前迭代中相同的字符串混淆技术，对字符串“wscript”进行了混淆，将该字符串替换为连接在一起的十六进制形式的字符组合。

表示“wscript”的字符组合如下：

Chr(CLng(“&H77”)) & Chr(CLng(“&H73”)) & Chr(CLng(“&H63”)) & Chr(CLng(“&H72”)) & Chr(CLng(“&H69”)) & Chr(CLng(“&H70”)) & Chr(CLng(“&H74”)) & Chr(CLng(“&H20”))

下图展现了针对命令和修改后的变量名进行字符串混淆的具体过程：

3.10 迭代9

1、文件变化：

· 66d678b097a2245f60f3d95bb608f3958aa0f5f19ca7e5853f38ea79885b9633

· 70ff20f2e5c7fd90c6bfe92e28df585f711ee4090fc7669b3a9bd024c4e11702

2、文件名变化：sss – Copy.xls -> sss – Copy.xls

3、时间差：1分钟57秒

4、检测率变化：11 -> 7

在最后一次测试中，删除了用于调用Shell函数的整行代码，该函数用于调用包含混淆的“wscript”字符串的“AppPool.vbs”脚本。下图展示了测试人员直接删除了这一整行，并没有用任何代码替换它，这表明宏永远不会运行它保存到系统的VBScript文件。

四、恶意组织在测试中学到了什么

在开发过程中，恶意组织不断尝试、学习并调整他们的代码。我们看到，攻击者多次将文件提交到测试平台，并且多次更改并重新提交，从而确保反病毒引擎只检测他们修改的特定内容。OilRig恶意组织利用在这一测试过程中学到的知识，来创建一个可以逃避检测的交付文档，从而增加攻击成功的几率。

在对所有文档进行差异比较之后，我们的研究人员分析了每一次版本迭代，不仅掌握了恶意组织进行测试的方法，还掌握了恶意组织在努力降低检测率过程中所学到的内容。我们可以做出如下总结：

1、反病毒软件对于宏病毒的检测，取决于宏中是否包含内置Shell函数的泛型调用，这一调用用于运行已经交付的VBScript。

2、使用Shell函数在隐藏窗口（vbHide标志）中运行命令的检测率，比使用可见窗口（vbNormalFocus标志）的检测率要高。

3、如果在VBScript中包含宏将写入系统的字符串“powershell”，将会导致检测率的升高。

4、如果对“powershell”字符串以及“wscript”字符串（位于使用Shell函数运行的命令中）进行字符串模糊处理，将会导致检测率的下降。

五、我们学到了什么

借助这一样本，我们学会了一些恶意软件规避检测的方式，这将有助于我们更好的了解恶意软件所使用的技术和能力，从而更好的提升安全防护机制。

我们目前掌握关于OilRig恶意组织的信息如下：

1、对恶意文档进行快速迭代，并不断上传文件到反病毒平台进行测试，文件创建时间和测试时间平均间隔为33秒。

2、在测试过程中，不关注宏的原始功能是否能够保持，因为测试人员在多次迭代中的修改将使得宏无法再按照预期工作。

3、更改用于运行交付的VBScript的函数，特别是在检测率较高的情况下，他们将Shell对象修改为内置的Shell函数。

4、添加休眠函数，以试图逃避沙箱检测，特别是在这种情况下使用了Wait桉树。

5、掌握一个成熟的字符串混淆技术，使用十六进制形式的字符组合替换一个字符串，这些字符组合将连在一起。

在进行此分析后，我们认为OilRig恶意组织将恶意Excel文档中的宏作为恶意Word文档中宏的基础。我们认为，攻击者利用如下特点，创建了实际攻击中使用的交付文档：

1、使用了相同的字符串混淆技术，通过连接在一起的多个十六进制值来代表字符串，这种技术被发现用于测试Excel文档和实际攻击的Word文档中。

2、使用字符串混淆技术，对嵌入式VBScript中的“powershell”和“cmd.exe”字符串进行了模糊处理，该技术已经在测试迭代4中进行了测试。

3、利用字符串混淆技术，对内置Shell函数运行的命令进行模糊处理，该技术已经在测试迭代8中进行了测试。

似乎OilRig恶意组织修改了测试活动中所使用的宏，并利用它来创建武器化的交付文档。其改动包括：添加名为“HGHG”的函数，将混淆的Boundupdater PowerShell脚本保存到文件中。恶意组织还将用于存储VBScript的变量“DDDD”使用在武器化文档中，并将变量命名为“A”。最后，恶意组织从宏中删除了“AA”函数，因为该函数用于显示一个隐藏的表格，其中包含诱导内容，该函数特定于Excel中使用，无法在Word中使用。

六、总结

攻击者和恶意组织通常会利用文件和URL扫描服务来帮助其开发和修改恶意软件，从而逃避检测。目前，我们已经熟悉了OilRig开发技术的变化，深入了解他们的方法，拥有了一个更为完整的恶意组织画像。

只有仔细研究恶意组织的开发方式，研究人员才能拥有更大几率来深刻理解他们所使用的工具、策略和代码。我们将最终恶意活动所使用的软件与开发过程中的恶意软件进行比较，从而能了解每次恶意软件的迭代都进行了哪些调整和修改。此外，见证恶意软件自身的特定功能变化，并尝试在新旧功能之间建立关联，这也有助于我们的分析与理解。通过比较测试期间创建的文件的时间戳，并将其与实际攻击中的文件进行对比，还能够深入了解恶意组织的工作效率。我们已经确定，OilRig恶意组织在攻击前6天开始了他们的测试活动，并在发动正式攻击前8小时结束了测试。