AcidBox：Turla Group 開發的針對俄羅斯組織的惡意軟件

原文鏈接：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 發布，如需轉載請注明來源。本文地址：http://www.bjnorthway.com/1247/

Paper - 安全技術精粹