一般来说，恶意软件payload是从哪里来的呢？一般来说都是在攻击者控制的服务器上，有时候也会在被入侵的合法网站上。研究人员最近发现，这些恶意payload还可能会出现在Dropbox、Google Drive这样的云服务上。

其实，谷歌对这类恶意软件是零容忍的。当你尝试从Google Drive上下载恶意软件时，一般都会看到如下信息：

迁移到云成为一种攻击的趋势

谷歌这样的厂商既然对恶意软件是零容忍的，那么为什么攻击者仍然选择迁徙到云呢？因为云服务其实并不知道这些payload是恶意的。

如下所示，是一个展示给用户的诱饵图像：

图 1 – 展示给用户的诱饵图像

每个payload都是用唯一的加密密钥加密的，释放器在硬编码的配置中有一个内置的选项，允许系统在重启后下载payload。

图 2 – 释放器参与的感染流

为了避免被发现，恶意payload会保存在内存中，而不是保存在硬盘中。这被称之为fileless（无文件技术）。攻击者的想法是：谷歌和其他安全厂商首先寻找文件，然后对比熟悉的签名和哈希。因此，无文件感染技术可以绕过安全厂商的检测模型。

其实谷歌云服务并非唯一被用于保存加密payload的载体，攻击者使用的其他服务还有：

图 3 – 用于下载payload的云服务

技术分析

研究人员最开始发现的是一个传播Legion加载器恶意软件的攻击活动。研究人员发现VirusTotal的行为分析报告发现该恶意软件家族含有到drive.google.com 的DNS请求。研究人员分析样本发现释放器可以下载和执行恶意软件。

图 4 – 释放器执行流

Shellcode解密器

释放器伪造成一个合法的VB6应用的，其中含有一些垃圾代码混杂着混淆的代码、防止反汇编的措施等。

图 5 – 释放器中的Jump混淆

图 6 – IDA分析代码失败

图 7 –shellcode解密密钥计算

释放器会对明文和密文的前4个字节进行XOR来恢复前4个字节的key：

plaintext_prefix = 0x0200EC81;
key = ((DWORD *)ciphertext)[0] ^ plaintext_prefix;

Shellcode

Shellcode也是混淆的，IDA无法自动分析。其中含有一些反调试的技术，以防止被调试器自动分析。

图 8 –shellcode中的反调试技术

比如，上面提到的恶意软件的代码隐藏了当前进程。调试的应用在碰到隐藏进程中的任意断点就会奔溃。

释放器会通过hook DbgUiRemoteBreakin函数、重定向到未初始化的变量指向的无效地址的执行到防止调试器附加到运行的进程。释放器还会用NOP操作替换DbgBreakPoint 函数主体。这可以防止调试器在其加入进程中后被打破。DbgUiRemoteBreakin和DbgBreakPoint是调试器加入进程时被调用的两个函数。

图 9 – 释放器中使用的反调试技术

Shellcode还会检查是否运行在沙箱中，如果是就拒绝运行。

图 10 – 释放器释放的沙箱扫过技术

释放器会动态解析API 函数，函数名保存在没有返回值的步骤之后的代码中。

图 11 – 解析API 函数地址

在解析完API函数地址后，释放器会其中另一个处于暂停状态的进程。恶意软件会根据其子进程与图像解除映射，映射到msvbvm60.dll库，在子进程中分配内存，复制解密的shellcode到分配的内存中，并转移执行。

图 12 – 复制shellcode到子进程内存

该点的父进程此时会中止执行。

下载payload

Shellcode会从硬编码的URL处下载加密的payload。其中72%的样本中使用了drive.google.com 来下载payload：

图 13 – shellcode中下载恶意payload的URL

Payload是用函数InternetOpenUrlA 和 InternetReadFile下载的：

图 14 – Payload下载路径

使用的硬编码的用户代理如下所示：

Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko

释放器检查下载的payload的唯一方式就是将其大小与硬编码的值进行比较。释放器会不断尝试循环下载payload指导下载的文件大小等于期望值。

在大多数例子中，该模式用于命名云存储中的加密文件：

_encrypted_.bin

图 15 – 加密的文件名

加密的payload是以64个十六进制数字序列开始的，用于解密过程：

图 16 – 加密的payload的部分

为了从下载的数据中恢复出工作的二进制文件， 释放器用唯一的常委上百字节的key进行XOR操作。

图 17 –payload解密密钥部分

Payload的解密路径也是混淆的：

图 18 – payload解密路径部分

这等价于循环XOR解密，python脚本如下：

decrypted_data = [data[i] ^ key[i % len(key)] for i in range(len(data))]

解密的payload会手动加载到payload PE header的图像基地址中。

然后释放器会创建一个新的进程在没有创建单独进程的情况下运行payload。然后，恶意软件会隐藏payload执行的线程，中止另一个负责解密的线程。

图 19 – 隐藏payload的主进程

诱饵图像

研究人员还发现含有2个URL的样本。其中第二个URL用于下载展示给用户的诱饵图像。

图 20 – 下载诱饵图像的URL

下载的图像保存在硬编码名的用户描述文件。然后图像会使用ShellExecuteW API函数展示。攻击者当前使用的部分图像如下所示：

图 21 – 诱饵图像

在不同的样本中，研究人员发现了用于下载图像的以下URL：

表1 – 用于下载诱饵图像文件的URL

延迟下载

根据释放器的配置，可以设置在系统重启后再下载payload。

如果该选项启用了，释放器会进入注册表的autorun key：

图 22 – 注册表 autorun记录

释放器会被复制到%USERPROFILE%\subfolder1\filename1.exe，并使用以下内容创建一个小的VBS脚本(C:\{USERPROFILEPATH}\subfolder1\filename1.vbs)：

Set W = CreateObject("WScript.Shell")
Set C = W.Exec ("C:\Users\User\subfolder1\filename1.exe")

“User”部分会是系统中适当的用户名。系统重启后，释放器会从%USERPROFILE%\subfolder1\filename1.exe 开始运行。只有那时，才会下载和执行payload。

研究人员在从云端下载和分析恶意样本时遇到了一个问题。当从不同的Google Drive URL下载了多个文件后，谷歌将研究人员IP 地址加入了黑名单：

谷歌的保护机制使得研究人员地分析过程更加艰难……但是，因为释放器只从一个云存储地址下载一个文件所以不受该问题的影响。

结论

研究人员惊奇地发现黑客也开始在攻击活动中释放云服务。在迁移到微软和谷歌这样的云服务后，服务器维护的成本就降低了。此外，在运行过程中也不会留下任何痕迹，使得分析人员很难溯源。

本文翻译自：https://research.checkpoint.com/2020/threat-actors-migrating-to-the-cloud/如若转载，请注明原文地址