VirtualBox Exploit Disables Driver Signature Enforcement in Windows

A new advanced malware called AcidBox was discovered targeting an unpatched vulnerability in the popular sandbox environment VirtualBox. A mysterious cyber gang, who has allegedly targeted Russian organizations since 2017, was linked to the new malware strain, researchers at Palo Alto Networks’ Unit 42 report. The dangerous malware uses a surprising set of well-forgotten vulnerabilities and techniques to target Windows systems through the popular open-source software.

The researchers report that AcidBox is a modular threat that is just a piece of a bigger malware toolkit. Only a small part of this kit has been analyzed, revealing four 64-bit usermode DLLs and an unsigned kernelmode driver.

Three out of the four usermode DLLs (msv1_0.dll, pku2u.dll, wdigest.dll) are loaders for the main worker module. These usermode DLLs are created as Security Support Providers (SSP), usually used as security mechanisms such as authentication between client/server apps. However, the malware abuses the SSP interference for persistence and injection purposes.

The three components are designed to load the main worker module stored in the registry and encrypted within a data blob that contains various other metadata. Researchers explain that an SSP DLL will decrypt the main DLL from the registry by XORing the data key 0xCA. The main DLL will then be prepared for loading in the memory by creating a thread for the module. It will also use the exported UpdateContext function as its start address.

Figure 1: Standard SSP DLLs
A  standard SSP DLLs provided in Windows 7 as part of the  “Security Packages” value. Source: Palo Alto Networks’ Unit 42

The main worker will then load the malware via a VirtualBox exploit and will remain inactive, waiting for commands from one of its components. Although just a small part of the malware’s components are available for analysis, the research team has discovered that the modules can instruct the worker to load additional payloads from kernel space via the driver or to install new SSP DLLs.

Interestingly, while analyzing the PE header, Palo Alto discovered that instead of __declspec(dllexport), the attackers used their own module-definition (DEF) files. The DFFs are text files that contain one or more module statements describing various attributes of a DLL. They allow the attacker to choose an ordinal for their export function, which is an option __declspec(dllexport) doesn’t support. In AcidBox’s case, the threat actor uses DFFs to instruct the DLL, which will start export/import operations.

Although the attackers use DEF files, they don’t take advantage of the files’ full potential. Researchers speculate that the use of this file format is merely due to the habits of the attackers. It is possible the unused ordinals could have been used for functions in previous versions of the malware.

Attack history

In 2008, after cybersecurity company Core Security, disclosed a flaw (CVE-2008-3431) in the Driver Signature Enforcement (DSE) on Windows Vista OS, malware attacks started targeting the vulnerability. The security bug allowed the attackers to exploit DSE and run rogue software on vulnerable versions of Oracle’s VirtualBox software.

Figure 2: VirtualBox Environment Vulnerability Patched

The CVE-2008-3431 vulnerability was located in the dispatch device control routine called VBoxDrvNtDeviceControl. Source: Palo Alto Networks’ Unit 42

In 2014 the infamous Russian cyber gang Turla Group developed malware that abused third-party drivers to disable DSE, successfully weaponizing the Core Security research. The attackers, who focused on VirtualBox drivers despite the 2008 patch, have managed to disable the DSE with their malware. According to Unit 42, the attack was successful because the 2008 patch fixed only one of two critical security issues.

“The exploit used by Turla actually abuses two vulnerabilities — of which, only one was ever fixed [with CVE-2008-3431],” the Unit 42 team wrote.

In 2019, Palo Alto Networks’ Unit 42 was able to trace back the malware after a sample of AcidBox was uploaded to VirusTotal. Researchers analyzed the available samples and concluded that, although the recent AcidBox campaigns share similarities with Turla Group attacks, the incidents are not linked and that the attackers are different.

Conclusion

Although AcidBox doesn’t use any new tricks, the malware is a reminder of how even known and fixed security bugs can still cause severe headaches. Researchers warn that this modular threat can be used for different malicious purposes. Depending on their needs, cyberattackers can load new modules and unload the old ones periodically, modifying the malware to be a perfect fit for specific operations. This flexible structure of the threat turns AcidBox into a highly potent malware that is a danger to both businesses and individual PC users.

Furthermore, the successful exploitation of a vulnerability in a sandbox environment, a technique that is usually used by high-profile criminal organizations, indicates that serious and capable actors are behind the threat. The criminals have managed to keep their malware under the radar for over two years, only recently being reported to the public. Researchers at Palo Auto warn that as AcidBox is a part of a bigger toolkit, this advanced malware is operated by a skilled threat actor who is likely to employ the threat in future attacks.