AcidBox：Turla Group 开发的针对俄罗斯组织的恶意软件

AcidBox：Turla Group 开发的针对俄罗斯组织的恶意软件
2020-06-18 19:31:00 Author: paper.seebug.org(查看原文) 阅读量:631 收藏

原文链接：AcidBox: Rare Malware Repurposing Turla Group Exploit Targeted Russian Organizations
作者：知道创宇404实验室翻译组

未知的威胁者

在2019年2月，我们发现了一个上载到VirusTotal 的AcidBox（SHA256：eb30a1822bd6f503f8151cb04bfd315a62fa67dbfe1f573e6fcfd74636ecedd5）示例，其中包含一个已知用于Turla的VirtualBox字符串。在对样本进行更深入的分析后发现，它是复杂恶意软件的一部分，我们无法与任何已知威胁参与者进行联想。

通过与我们同事Dr.Web的合作了解到该样本已于2017年用于对俄罗斯未非实体组织进行有针对性的攻击。所幸，他们共享了同一恶意软件家族的另外三个样本。这些用户模式示例中有两个是从Windows注册表中加载的工作程序模块，另一个是嵌入在主工作程序示例中的内核模式有效负载驱动程序。此外，由于该公司总部位于俄罗斯，因此我们联系了卡巴斯基，该公司在其数据库中仅发现了一个额外的样本，该样本也就是用户模式加载程序版本。我们还联系了ESET，ESET没有发现任何感染了该恶意软件的受害者。因此，我们得出结论，这是仅用于有针对性的攻击的极少数恶意软件。

所有样本的共同点是在2017年5月9日的编译时间戳。此日期似乎是合理的，因为卡巴斯基发现的样本于2017年6月出现在其数据库中。因此，我们得出的结论是，与该恶意软件有关的攻击活动于2017年进行。由于找不到任何新的样本，因此不知道AcidBox目前具体情况如何。

我们将样本的特定特征与所有公开的恶意软件进行了比较，但找不到任何明显的重叠。与ProjectSauron的Remsec恶意软件有一些非常大致的相似之处，例如：

DWORD大小数据标记值
导出由2/3个单词组成的函数名称
使用了MS Visual C / C ++编译器
各种导入API函数重叠
使用易受攻击的第三方驱动程序加载自己的未签名驱动程序
使用Zlib压缩
在资源部分加密敏感数据

但是仅根据这些事实，并不可能将样本归因于ProjectSauron威胁参与者。我们认为这很可能是未知的威胁因素。

VirtualBox漏洞和Turla的版本

CVE-2008-3431中描述的原始漏洞是由Core Security在2008 年发现的，VBoxDrv.sys低于或等于1.6.2的版本受影响。由于它已在1.6.4版中修复，因此无法再利用。

该漏洞位于名为VBoxDrvNtDeviceControl的设备控制例程中。在1.6.4之前的版本上，可以调用usermode DeviceIoControl API函数，并发送以下控制代码之一以及要覆盖的内核地址作为输入/输出缓冲区：

SUP_IOCTL_FAST_DO_RAW_RUN
SUP_IOCTL_FAST_DO_HM_RUN
SUP_IOCTL_FAST_DO_NOP

内核地址无需进行任何检查或验证就可以向下传递到控制处理程序，并用supdrvIOCtlFast的返回值进行填充。在原始漏洞利用中，supdrvIOCtlFast的返回值不受控制，因此它将是一个写入内核地址的随机值。Turla的漏洞利用通过覆盖supdrvIOCtlFast的函数指针来控制返回值，以将执行重定向到小的Shellcode，该ShellCode返回所需的值。在几篇文章中对此进行了非常详细的描述，还提供了完整的反向工程利用漏洞代码。

修补的版本1.6.4不再使用UserBuffer指针，通过传递内核地址可能会滥用该指针。另外，它检查rc变量是否大于或等于零（补丁程序不需要此变量）。

使用此修补程序，修复了覆盖内核地址的原始漏洞，可以控制supdrvIOCtlFast的函数指针的另一个漏洞尚未修补。当然，这是因为当时Core Security尚未发现它，但几年后Turla才发现。

截止目前Turla仍使用易受攻击的VirtualBox驱动程序v.1.6.2，但它仅利用了未修补的漏洞。Lastline 描述了其使用方式以及使用方式的原因，Turla Driver Loader的项目中也提供了反向工程利用代码。

秘诀是完全相同，仅需进行很小的修改即可用于所有VBoxDrv.sys系统，最高达3.0.0的版本（我们在此将不进行披露）。虽然低于4.0的VirtualBox版本不再在官方网站上提供，但仍可以在某些软件下载站点上找到它们。

从3.0.0版开始，某些结构和例程已更改，因此该漏洞利用不再起作用。但是，不能排除在更高版本中仍然可以通过一些调整来利用同一漏洞。

有趣的是，即使Turla的操作者也似乎没有意识到这一点。他们仍然使用旧的VBoxDrv.sys v.1.6.2进行隐蔽的利用。众所周知，该驱动程序可用于恶意或其他可疑目的，如游戏中的作弊行为。

AcidBox技术分析

该恶意软件是一个复杂的模块化工具包，我们只拥有其中的一部分。总共，我们发现了四个64位用户模式DLL和一个未签名的内核模式驱动程序（SHA256：3ef071e0327e7014dd374d96bed023e6c434df6f98cce88a1e7335a667f6749d）。四个用户模式样本中有三个样本具有相同的功能，它们是主工作程序模块的加载器。它们的区别仅在于文件描述以及嵌入式和加密注册表路径。这些装载程序被创建为安全支持提供程序（其他SSP）。SSP是DLL，它至少导出SpLsaModeInitialize函数，并且通常提供安全性机制，如客户端/服务器应用程序之间的身份验证。Windows中提供了几个标准的SSP，如Kerberos（kerberos.dll）、NTLM（msv1_0.dll），用户可以滥用SSP界面来实现恶意软件的持久性以及用于注入目的。为了保持持久性，用户必须将SSP DLL放入Windows系统目录，并将DLL的名称添加到某个注册表值。系统重新启动后，用户的DLL将被加载到Windows lsass.exe进程中并被执行。如果只希望将SSP DLL注入lsass.exe中，则可以调用触发立即加载的API函数AddSecurityPackage。当然，这两种方法都至少需要管理员权限。

对于三个AcidBox SSP dll，它们不使用任何与安全性相关的操作，而是纯粹出于注入目的（并且很可能还出于持久性）滥用了此接口。这三个SSP具有与Windows中提供的标准软件包（msv1_0.dll，pku2u.dll，wdigest.dll）相似的不同文件名：

msv1_1.dll SHA256: b3166c417d49e94f3d9eab9b1e8ab853b58ba59f734f774b5de75ee631a9b66d)
pku.dll SHA256: 3ad20ca49a979e5ea4a5e154962e7caff17e4ca4f00bec7f3ab89275fcc8f58c)
windigest.dll SHA256: 003669761229d3e1db0f5a5b333ef62b3dffcc8e27c821ce9018362e0a2df7e9)

因此，我们得出结论，AcidBox SSP也滥用了接口以保持持久性。但是，由于我们没有安装SSP DLL的组件，因此我们不确定。我们知道的是，SSP接口用于注入到lsass.exe中，因为它们在开始时检查它们加载到的过程路径是否与嵌入到资源部分中每个示例中的过程路径（C：\WINDOWS\SYSTEM32\lsass.exe）。该处理路径包含在资源4097中，我们稍后将描述如何通过隐写术将其隐藏。

AcidBox SSP DLL的目的是从资源256中包含的注册表值加载主辅助模块。我们不知道主工作DLL是如何存储在注册表中的，但我们相信它是由安装SSP DLL的同一个丢失组件完成的。我们还假设这三个SSP DLL来自三个不同的系统，因为其中一个样本嵌入了不同的注册表项。另外，由于这些模块是系统上唯一可见的部分（加载的主工作模块在注册表中保持加密），它们可能在某些方面有所不同，例如它们选择的文件名。主工作程序存储在注册表中，该注册表已加密在一个数据blob中，该blob中包含各种其他元数据。

通过简单地对与密钥0xCA的数据进行XOR运算后，SSP DLL在从注册表中解密了主要工作程序DLL之后，就准备从内存中加载该文件。它通过为模块创建线程并使用主工作程序的导出函数UpdateContext作为其起始地址。然后，主工作程序模块通过VirtualBox漏洞加载未签名的恶意软件驱动程序，并等待组件的命令。这些命令包括通过驱动程序从内核空间注册表加载其他有效负载，或者安装新的SSP DLL。

主要工作程序具有两个名为InitMainStartup和UpdateContext的导出函数。以下字符串以明文形式出现：

%s\%s

%s\%s{%s}

%s\[[%s]]

%s.dll

%s%s%s.dll

\\.\PCIXA_CFGDEV
InitEntry
InitExit
The Magic Word!
ntoskrnl.exe
ntkrn
ntkrp
hal.dll
ntoskrnl
ntkrnlpa.exe
%s%s%s

Group
Count
NextInstance
Root\LEGACY_NULL\0000

以下其他字符串会被混淆：

SeLoadDriverPrivilege
%s\%c*.dll

System\CurrentControlSet\Control\
NtQueryInformationThread
BFE_Notify_Event_
Microsoft\Cryptography
ntdll.dll
\Registry\Machine\
SOFTWARE
Global
%s\%s

Security Packages
kernel32.dll
SOFTWARE
\Registry\Machine\
MachineGuid
ntdll.dll

还有XOR编码的DLL和函数名称，这些名称随后会动态解析并使用：

ntdll.RtlGetVersion
ntdll.ZwLoadDriver
ntdll.ZwUnloadDriver
ntdll.ZwQuerySystemInformation
kernel32.DeviceIoControl
kernel32.GetSystemDirectoryA
ntdll.RtlAnsiStringToUnicodeString
ntdll.ZwClose
ntdll.ZwCreateFile
ntdll.ZwQueryInformationFile
ntdll.ZwReadFile
ntdll.ZwWriteFile
kernel32.GetSystemDirectoryA
kernel32.GetSystemDirectoryW
kernel32.BaseThreadInitThunk
kernel32.LZDone
advapi32.CryptAcquireContextA
advapi32.CryptGenRandom
advapi32.CryptReleaseContext
ntdll.RtlRbInsertNodeEx
ntdll.RtlRbRemoveNode
ntdll.RtlAcquireSRWLockExclusive
ntdll.RtlReleaseSRWLockExclusive
ntdll.RtlEnterCriticalSection
ntdll.RtlPcToFileHeader
ntdll.RtlGetVersion
ntdll.RtlUpcaseUnicodeChar
ntdll.RtlAnsiStringToUnicodeString
ntdll.LdrLockLoaderLock
ntdll.LdrUnlockLoaderLock
ntdll.ZwClose
ntdll.ZwCreateSection
ntdll.ZwMapViewOfSection
ntdll.ZwUnmapViewOfSection

所有功能都包含在两个导出功能中，而DllMain不包含任何相关代码。突出的是在整个代码中广泛使用了自定义DWORD大小的状态代码。在结果变量中带有状态代码的反编译代码示例：

…
if ( !a1 || !a2 || !(_DWORD)v3 )
{
     result = 0xA0032B02;
     goto LABEL_45;
}
if ( strlen(a1) <= 1 )
     goto LABEL_65;
result = get_kernel32_path(a1, &v43, &v37, &v41);
if ( result )
     goto LABEL_45;
if ( (unsigned int)v3 < 0x1C )
{
     LABEL_65:
     result = 0xA0032B02;
     goto LABEL_45;
}
pBuffer = allocate_buffer(v13, (unsigned int)v3, 0i64, v11, 0, 1);
buffer = pBuffer;
if ( !pBuffer )
{
     LABEL_9:
     result = 0xA0032B04;
     goto LABEL_45;
}
if ( memcpy_s(pBuffer, v3, a2, v3) )
{
     LABEL_11:
     result = 0xA0032B06;
     goto LABEL_45;
}
…

主要工作者样品中含有名为有效图标5个图标资源16，256，4097，8193和12289。名称表示不同的图标分辨率，但是图标的区别仅在于附加在其上的加密数据，这可以视为隐写术的一种形式。使用自定义算法对该数据进行加密，并另外压缩zlib。在SSP DLL中使用相同的方法。可以在附录中找到用于解密和解压缩的Python脚本。解密后，数据Blob具有以下结构：

struct data_blob {
     DWORD marker;    // Marker bytes (0x9A65659A)
     DWORD crc32;    // CRC32 value of decrypted or zlib uncompressed 
bytes
     DWORD size;     // Size of decrypted or zlib uncompressed bytes
     DWORD option;    // Information if data is encrypted or zlib 
compressed; 0x1 = encrypted, 0x2 = zlib compressed
     char data[];    // Encrypted or zlib compressed data
};

解密后的数据如下。

资源16：

System\CurrentControlSet\Control\Class\{4D36E97D-E325-11CE-BFC1-08002B
E10318}\0003\DriverData

资源256：

System\CurrentControlSet\Control\Class\{4D36E96A-E325-11CE-BFC1-08002B
E10318}\0000\DriverData

资源16和256是Windows注册表项，其中包含资源8193中嵌入式驱动程序的解密密钥以及其他可能由AcidBox驱动程序注入的有效负载。

资源4097：

C:\WINDOWS\SYSTEM32\lsass.exe

此资源包含每个样本用来验证是否已将其加载到正确流程中的流程路径。资源8193包含无符号内核模式有效负载驱动程序，该驱动程序也使用RSA加密。该驱动程序被实现为具有两个导出功能InitEntry和InitExit的内核模式DLL 。它包含以下明文字符串：

ntoskrnl.exe
ntkrn
ntkrp
hal.dll
ntoskrnl
ntkrnlpa.exe
csrss.exe
PsCreateSystemThread
\Device\VBoxDrv
\DosDevices\PCIXA_CFGDEV
\Windows\ApiPort
\Sessions\%u\Windows\ApiPort
\Sessions\xxxxxxxx\Windows\ApiPort
\Device\PCIXA_CFG
\DosDevices\PCIXA_CFGDEV

资源12289包含由Sun Microsystems签名的VirtualBox VBoxDrv.sys驱动程序v2.2.0.0 ，我们先前描述的该漏洞也很容易受到攻击。

PE相关特征

在研究样本时，PE标头的特性（一种经常被监督的取证指标）引起了我们的注意。这个鲜为人知的事实可以在导出目录中找到，并有助于归因于恶意软件样本。所有AcidBox示例均在单个导出的函数条目之间包含间隙：

每个AcidBox示例在导出目录中都有一个大于NumberOfNames值的NumberOfFunctions值。这并不稀奇，因为不是每个导出的函数都必须有一个名称。未命名的函数也可以通过其序数值来调用。然而，不常见的是，未命名的函数项也被清零，因此不使用。

这是使用自己的DEF文件而不是declspec（dllexport）来描述DLL文件的属性时的结果。使用DEF文件时，可以选择导出功能的序号（使用_declspec（dllexport）无法实现此功能，因为Visual Studio编译器始终将函数从头计数）。

使用DEF文件代替_declspec（dllexport）具有一些优点。可以按常规导出函数，也可以重定向函数。缺点是必须在项目中维护其他文件。

对于AcidBox样本，我们可以得出两点结论。首先，作者使用了DEF文件，尽管他没有利用它的优点。这可能表明使用DEF文件是操作者习惯；其次，函数序数似乎以两个整数为单位进行选择；最后，如果我们假设作者确实选择执行两个整数步骤，那么在用户模式DLL中，一个导出函数被删除。我们可以看到序数3未使用，留下的间隙大于一个整数。所有这些信息对于恶意软件归属都可能很有用。

结论

2017年，一个名为AcidBox的新高级恶意软件被一个未知的威胁参与者使用，直到现在才被发现。它使用一种已知的VirtualBox漏洞来禁用Windows中的驱动程序签名强制执行，但有一个新的变化：VirtualBox驱动程序VBoxDrv.sys v1.6.2易受Turla的攻击并使用，这种新的恶意软件使用相同的漏洞，但VirtualBox版本相比之前有所更新。

在Windows威胁下所有内容都是副本的副本。尽管AcidBox并未使用任何新的方法，但它打破了只有VirtualBox VBoxDrv.sys 1.6.2可以用于Turla的利用这一神话。将敏感数据作为图标资源的覆盖物添加，滥用SSP接口进行持久性注入且Windows注册表中的有效负载存储，将其归为有趣的恶意软件类别。

我们猜测AcidBox的样本只是更大的工具包的一部分，如果您碰巧发现其他样本，甚至被感染，则可以使用提供的Python脚本提取附加到图标资源的敏感数据。

Palo Alto Networks客户受到此恶意软件的保护,AutoFocus客户可以使用标签为AcidBox来调查此活动。

IOCs

Files in Windows system32 directory
msv1_1.dll
pku.dll
windigest.dll

Mutexes
Global\BFE_Event_{xxxxxxxxxxxx–xxxx-xxxxxxxx-xxxxxxxx}
Global{xxxxxxxxxxxx–xxxx-xxxxxxxx-xxxxxxxx}

The malware takes the MachineGuid stored in the registry and reshuffles the single characters alternating from the end to the beginning and vice versa in steps of two. For example, the MachineGuid string a9982d3e-c859-4702-c761-df7eea468ade gets transferred into e9a86daeecf5–67c2-07419d87-e34289da and appended to the above templates.

Windows Registry

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Class{4D36E97D-E325-11CE-BFC1-08002BE10318}\0003\DriverData (REG_BINARY type)

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Class{4D36E96A-E325-11CE-BFC1-08002BE10318}\0000\DriverData (REG_BINARY type)

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Class{4D36E969-E325-11CE-BFC1-08002BE10318}\0000\DriverData (REG_BINARY type)

Sample Hashes

Main worker DLL:

eb30a1822bd6f503f8151cb04bfd315a62fa67dbfe1f573e6fcfd74636ecedd5

Kernelmode driver:

3ef071e0327e7014dd374d96bed023e6c434df6f98cce88a1e7335a667f6749d

SSP DLL modules:

003669761229d3e1db0f5a5b333ef62b3dffcc8e27c821ce9018362e0a2df7e9

b3166c417d49e94f3d9eab9b1e8ab853b58ba59f734f774b5de75ee631a9b66d

3ad20ca49a979e5ea4a5e154962e7caff17e4ca4f00bec7f3ab89275fcc8f58c

Benign VirtualBox VBoxDrv.sys driver v2.2.0 (signed by “Sun Microsystems, Inc.”):

78827fa00ea48d96ac9af8d1c1e317d02ce11793e7f7f6e4c7aac7b5d7dd490f

Paper 本文由 Seebug Paper 发布，如需转载请注明来源。本文地址：https://paper.seebug.org/1247/

文章来源: https://paper.seebug.org/1247/
如有侵权请联系:admin#unsafe.sh

相关背景

未知的威胁者

VirtualBox漏洞和Turla的版本

AcidBox技术分析

PE相关特征

结论

IOCs