{ "id": "c84be4ef-01a0-44c6-893e-00798fbc9cb9", "created_at": "2026-04-06T00:12:40.714375Z", "updated_at": "2026-04-10T13:12:06.561014Z", "deleted_at": null, "sha1_hash": "05005048baf66e1cc14d11e2b3de96afd3173099", "title": "AcidBox: Rare Malware Repurposing Turla Group Exploit Targeted Russian Organizations", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 676320, "plain_text": "AcidBox: Rare Malware Repurposing Turla Group Exploit\r\nTargeted Russian Organizations\r\nBy Dominik Reichel, Esmid Idrizovic\r\nPublished: 2020-06-17 · Archived: 2026-04-05 12:39:55 UTC\r\nExecutive Summary\r\nWhen the news broke in 2014 about a new sophisticated threat actor dubbed the Turla Group, which the Estonian\r\nforeign intelligence service believes has Russian origins and operates on behalf of the FSB, its kernelmode\r\nmalware also became the first publicly-described case that abused a third-party device driver to disable Driver\r\nSignature Enforcement (DSE). This security mechanism was introduced in Windows Vista to prevent unsigned\r\ndrivers from loading into kernel space. Turla exploited the signed VirtualBox driver, VBoxDrv.sys v1.6.2, to\r\ndeactivate DSE and load its unsigned payload drivers afterward.\r\nThere is some confusion about this exploit, however, as it’s often generally referred to as CVE-2008-3431. The\r\nexploit used by Turla actually abuses two vulnerabilities -- of which, only one was ever fixed in the\r\naforementioned CVE. The other vulnerability was found by Turla and is used in the first version of their exploit,\r\nalong with CVE-2008-3431. The second version of their exploit, presumably introduced in 2014 of their\r\nkernelmode malware, only uses the unpatched vulnerability, which we discuss in greater detail later.\r\nIn February 2019, Unit 42 found that a yet-to-be-known threat actor -- unbeknownst to the infosec community --\r\ndiscovered that the second unpatched vulnerability can not only exploit VirtualBox VBoxDrv.sys driver v1.6.2,\r\nbut also all other versions up to v3.0.0. Furthermore, our research shows that this unknown actor exploited\r\nVirtualBox driver version 2.2.0 to target at least two different Russian organizations in 2017, which we are\r\nrevealing for the first time. We anticipate this was done because the driver version 2.2.0 wasn't known to be\r\nvulnerable and thus most likely is not on the radar of security companies being exploited. Since no other victims\r\nhave been found, we believe this is a very rare malware used in targeted attacks only.\r\nThe actors used a previously unknown malware family that we have dubbed AcidBox due to the first part being an\r\nanagram of the malware’s driver device name and the second part taken from VirtualBox. Because of the\r\nmalware’s complexity, rarity, and the fact that it’s part of a bigger toolset, we believe it was used by an advanced\r\nthreat actor for targeted attacks and it's likely that this malware is still being used today if the attacker is still\r\nactive. However, we anticipate that it was rewritten to a certain extent. Based on the information we have, we\r\ndon’t believe this unknown threat actor is tied to Turla, except for the used exploit.\r\nPalo Alto Networks customers are protected from this threat. Our threat prevention platform with WildFire\r\nidentifies this malware as malicious. AutoFocus customers can track malware activity by using the AcidBox tag.\r\nWe also created an Adversary Playbook for this attack, which can be found here.\r\nThe Unknown Threat Actor\r\nhttps://unit42.paloaltonetworks.com/acidbox-rare-malware/\r\nPage 1 of 16\n\nIn February 2019, we discovered a sample of AcidBox (SHA256:\r\neb30a1822bd6f503f8151cb04bfd315a62fa67dbfe1f573e6fcfd74636ecedd5) uploaded to VirusTotal, which\r\ncontained a string known to be used in Turla’s VirtualBox exploit. A deeper analysis of the sample revealed it’s the\r\nmain worker module as part of a sophisticated malware that we couldn’t tie to any known threat actor.\r\nIn collaborating with our colleagues at Dr.Web, we learned that this sample was used in a targeted attack on an\r\nunspecified entity in Russia back in 2017. Thankfully, they shared three additional samples of the same malware\r\nfamily. Two of those usermode samples are modules that load the main worker from the Windows registry and one\r\nis the kernelmode payload driver embedded in the main worker sample. Moreover, we contacted Kaspersky since\r\nthe company is headquartered in Russia, which found only one additional sample in their databases that was also\r\nthe usermode loader version. We also contacted ESET, which didn’t find any victims infected with this malware,\r\njust like in our own case. For this reason, we conclude it’s a very rare malware used in targeted attacks only.\r\nWhat all the samples have in common are the compilation timestamps of May 9, 2017. This date seems legitimate,\r\nas the sample found by Kaspersky appeared in June 2017 in their databases. Therefore, we conclude that the\r\ncampaign which involved this malware took place in 2017. We couldn’t find any newer samples and thus it’s\r\nunknown if AcidBox is still in use or has been further developed.\r\nWe compared the specific characteristics of the samples to all publicly-known malware, but couldn’t find any\r\nclear overlaps. There are some very loose similarities to Remsec malware attributed to ProjectSauron, like:\r\nDWORD size data marker values\r\nExport function names made of 2/3 words\r\nMS Visual C/C++ compiler used\r\nVarious import API functions overlaps\r\nUse of vulnerable 3rd party driver to load own unsigned driver\r\nZlib compression used\r\nSensitive data encrypted in the resource section\r\nHowever, based on these facts alone, it’s not possible to attribute the samples to the ProjectSauron threat actor. We\r\nthink it’s more likely this is a yet unknown threat actor.\r\nThe VirtualBox Exploit and Turla’s Versions\r\nThe original vulnerability described in CVE-2008-3431 was found by Core Security in 2008 and affected\r\nVBoxDrv.sys less or equal version 1.6.2. It was fixed in version 1.6.4 and thus couldn’t be exploited anymore.\r\nhttps://unit42.paloaltonetworks.com/acidbox-rare-malware/\r\nPage 2 of 16\n\nFigure 1. Vulnerable and patched VirtualBox device dispatch handler routines on the left and right,\r\nrespectively\r\nThe vulnerability is located in the dispatch device control routine called VBoxDrvNtDeviceControl. On versions\r\nprior to 1.6.4, you can call the usermode DeviceIoControl API function and send one of the following control\r\ncodes together with a kernel address you want to overwrite as the input/output buffer:\r\nSUP_IOCTL_FAST_DO_RAW_RUN\r\nSUP_IOCTL_FAST_DO_HM_RUN\r\nSUP_IOCTL_FAST_DO_NOP\r\nThe kernel address is passed down to the control handler (see Figure 1 left, line 28) without any check or\r\nvalidation and is filled with the return value of supdrvIOCtlFast (see Figure 1 left, line 24). This is where the\r\nvulnerability digging from CoreSecurity stops and where Turla continues. In the original exploit, the return value\r\nfrom supdrvIOCtlFast isn’t controlled and thus it will be a random value written to your kernel address. Turla’s\r\nexploit controls the return value by overwriting the function pointer of supdrvIOCtlFast to redirect execution to a\r\nsmall shellcode, which returns the needed value. This was described in great detail in a couple of articles and the\r\ncomplete reverse-engineered exploit code is also available.\r\nThe patched version 1.6.4 (see Figure 1 right) doesn’t use the UserBuffer pointer anymore, which could be abused\r\nby passing a kernel address. Additionally, it checks if the rc variable is equal or bigger than zero -- which isn’t\r\nneeded for the patch, but more like a sanity check.\r\nWith this patch, the original vulnerability to overwrite a kernel address was fixed. The other vulnerability that lets\r\nyou control the function pointer of supdrvIOCtlFast remained unpatched. Of course, that’s because it wasn’t\r\ndiscovered by Core Security at the time, but only a few years later by the Turla threat actor.\r\nWhile Turla still uses the vulnerable VirtualBox driver v.1.6.2 to date, it only makes use of the unpatched\r\nvulnerability. The reason why and how it uses it was described by Lastline, and also the reverse-engineered\r\nexploit code is available in a project named Turla Driver Loader.\r\nhttps://unit42.paloaltonetworks.com/acidbox-rare-malware/\r\nPage 3 of 16\n\nThe secret is the exact same exploit, with only a small modification -- which we won’t disclose here -- can be used\r\non all VBoxDrv.sys versions up to 3.0.0. This was also figured out by an unknown threat actor. While VirtualBox\r\nversions smaller than 4.0 aren’t available on the official website anymore, they can still be found on some\r\nsoftware download sites.\r\nStarting from version 3.0.0, some structures and routines have changed so the exploit does not work anymore.\r\nHowever, it can’t be ruled out that in later versions it’s still possible to exploit the same vulnerability with some\r\nmore adjustments.\r\nWhat’s also interesting is that not even the Turla authors themself seem to have realized that. They still use the old\r\nVBoxDrv.sys v.1.6.2 in their otherwise stealthy exploit. This driver is widely known to be used for malicious or\r\nvarious otherwise dubious purposes, for example, in-game cheats.\r\nTechnical Analysis of AcidBox\r\nThe malware is a complex modular toolkit of which we have only a part of it. In total, we have found four 64-bit\r\nusermode DLLs and an unsigned kernelmode driver (SHA256:\r\n3ef071e0327e7014dd374d96bed023e6c434df6f98cce88a1e7335a667f6749d). Three out of the four usermode\r\nsamples have identical functionality and are loaders for the main worker module. They only differ in their file\r\ndescriptions and the embedded and encrypted registry path. These loaders are created as security support providers\r\n(further SSP). A SSP is a DLL that exports at least the function SpLsaModeInitialize and usually provides security\r\nmechanisms such as authentication between client/server applications. There are a couple of standard SSPs\r\nprovided in Windows such as Kerberos (kerberos.dll) or NTLM (msv1_0.dll). You can abuse the SSP interface for\r\nmalware persistency and also for injection purposes. In order to maintain persistency, you have to put your SSP\r\nDLL into the Windows system directory and add the name of your DLL to a certain registry value. Upon a system\r\nrestart, your DLL gets loaded into the Windows lsass.exe process and is executed. If you just want your SSP DLL\r\nto be injected into lsass.exe, you can call the API function AddSecurityPackage which triggers immediate loading.\r\nOf course, you need at least admin privileges for both of these methods. The first case of a malware abusing the\r\nSSP interface was mentioned by Matt Graeber in 2014. Since then, this persistence and injection trick has become\r\nwider known, but it’s still rarely used in malware.\r\nIn case of the three AcidBox SSP DLLs, they don’t make use of any security related operations, but purely abuse\r\nthis interface for injection purposes and most likely also for persistence. The three SSPs have different file names\r\nthat are similar to the standard packages provided in Windows (msv1_0.dll, pku2u.dll, wdigest.dll):\r\nmsv1_1.dll (SHA256:\r\nb3166c417d49e94f3d9eab9b1e8ab853b58ba59f734f774b5de75ee631a9b66d)\r\npku.dll (SHA256: 3ad20ca49a979e5ea4a5e154962e7caff17e4ca4f00bec7f3ab89275fcc8f58c)\r\nwindigest.dll (SHA256:\r\n003669761229d3e1db0f5a5b333ef62b3dffcc8e27c821ce9018362e0a2df7e9)\r\nhttps://unit42.paloaltonetworks.com/acidbox-rare-malware/\r\nPage 4 of 16\n\nFigure 2. Standard SSP DLLs provided in Windows 7 present in the “Security Packages” value\r\nFor this reason, we conclude the AcidBox SSPs also abuse the interface for persistence. However, as we don’t\r\nhave the component which installs the SSP DLLs, we don’t know for sure. What we know is that the SSP interface\r\nis used for injection into lsass.exe, as they check at the beginning whether the process path they're loaded into\r\nmatches the one which is embedded into every sample in the resource section\r\n(C:\\WINDOWS\\SYSTEM32\\lsass.exe). This process path is contained in the resource 4097 which we describe\r\nlater how it is hidden via steganography.\r\nThe purpose of the AcidBox SSP DLLs is to load the main worker module from a registry value contained in\r\nresource 256 of each sample. We don’t know how the main worker DLL was stored in the registry, but we believe\r\nit was done by the same missing component which installed the SSP DLLs. We also assume that the three SSP\r\nDLLs are from three different systems as one of those samples has a different registry key embedded. Also, as\r\nthese modules are the only visible part on a system -- with the main worker module being loaded remains\r\nencrypted in the registry -- they likely differ in some way like their chosen file name. The main worker is stored in\r\nthe registry encrypted within a data blob that contains various other metadata such as the CRC32 hash of the data\r\nblob or magic byte sequences which indicate different types of contained data.\r\nAfter the main worker DLL gets decrypted by a SSP DLL from the registry via simply XORing the data with key\r\n0xCA, it gets prepared to be loaded from memory. It does so by creating a thread for the module and uses the\r\nexported function UpdateContext of the main worker as its start address. The main worker module then loads the\r\nunsigned malware driver via the VirtualBox exploit and waits for commands from one or more components that\r\nwe don’t have. These commands include the loading of additional payloads from the registry from kernel space\r\nvia the driver or the installation of new SSP DLLs.\r\nThe main worker has 2 export functions named InitMainStartup and UpdateContext. The following strings are\r\npresent in cleartext:\r\nhttps://unit42.paloaltonetworks.com/acidbox-rare-malware/\r\nPage 5 of 16\n\nhttps://unit42.paloaltonetworks.com/acidbox-rare-malware/\r\nPage 6 of 16\n\n1\r\n2\r\n3\r\n4\r\n5\r\n6\r\n7\r\n8\r\n9\r\n10\r\n11\r\n12\r\n13\r\n14\r\n15\r\n16\r\n17\r\n18\r\n19\r\n20\r\n21\r\n22\r\n23\r\n24\r\n25\r\n26\r\n%s\\%s\r\n%s\\%s{%s}\r\n%s\\[[%s]]\r\n%s.dll\r\n%s%s%s.dll\r\n\\\\.\\PCIXA_CFGDEV\r\nInitEntry\r\nInitExit\r\nThe Magic Word!\r\nntoskrnl.exe\r\nntkrn\r\nntkrp\r\nhal.dll\r\nntoskrnl\r\nntkrnlpa.exe\r\n%s%s%s\r\nGroup\r\nCount\r\nNextInstance\r\nRoot\\LEGACY_NULL\\0000\r\nhttps://unit42.paloaltonetworks.com/acidbox-rare-malware/\r\nPage 7 of 16\n\nThe following additional strings are stack obfuscated:\r\n1\r\n2\r\n3\r\n4\r\n5\r\n6\r\n7\r\n8\r\n9\r\n10\r\n11\r\n12\r\n13\r\n14\r\n15\r\n16\r\n17\r\n18\r\n19\r\nSeLoadDriverPrivilege\r\n%s\\%c*.dll\r\nSystem\\CurrentControlSet\\Control\\\r\nNtQueryInformationThread\r\nBFE_Notify_Event_\r\nMicrosoft\\Cryptography\r\nntdll.dll\r\n\\Registry\\Machine\\\r\nSOFTWARE\r\nGlobal\r\n%s\\%s\r\nSecurity Packages\r\nkernel32.dll\r\nSOFTWARE\r\n\\Registry\\Machine\\\r\nMachineGuid\r\nntdll.dll\r\nThere are also XOR-encoded DLL and function names, which later get dynamically resolved and used:\r\n1\r\n2\r\n3\r\nntdll.RtlGetVersion\r\nntdll.ZwLoadDriver\r\nntdll.ZwUnloadDriver\r\nhttps://unit42.paloaltonetworks.com/acidbox-rare-malware/\r\nPage 8 of 16\n\n4\r\n5\r\n6\r\n7\r\n8\r\n9\r\n10\r\n11\r\n12\r\n13\r\n14\r\n15\r\n16\r\n17\r\n18\r\n19\r\n20\r\n21\r\n22\r\n23\r\n24\r\n25\r\n26\r\n27\r\n28\r\n29\r\nntdll.ZwQuerySystemInformation\r\nkernel32.DeviceIoControl\r\nkernel32.GetSystemDirectoryA\r\nntdll.RtlAnsiStringToUnicodeString\r\nntdll.ZwClose\r\nntdll.ZwCreateFile\r\nntdll.ZwQueryInformationFile\r\nntdll.ZwReadFile\r\nntdll.ZwWriteFile\r\nkernel32.GetSystemDirectoryA\r\nkernel32.GetSystemDirectoryW\r\nkernel32.BaseThreadInitThunk\r\nkernel32.LZDone\r\nadvapi32.CryptAcquireContextA\r\nadvapi32.CryptGenRandom\r\nadvapi32.CryptReleaseContext\r\nntdll.RtlRbInsertNodeEx\r\nntdll.RtlRbRemoveNode\r\nntdll.RtlAcquireSRWLockExclusive\r\nntdll.RtlReleaseSRWLockExclusive\r\nntdll.RtlEnterCriticalSection\r\nntdll.RtlPcToFileHeader\r\nntdll.RtlGetVersion\r\nntdll.RtlUpcaseUnicodeChar\r\nntdll.RtlAnsiStringToUnicodeString\r\nntdll.LdrLockLoaderLock\r\nhttps://unit42.paloaltonetworks.com/acidbox-rare-malware/\r\nPage 9 of 16\n\n30\r\n31\r\n32\r\n33\r\n34\r\nntdll.LdrUnlockLoaderLock\r\nntdll.ZwClose\r\nntdll.ZwCreateSection\r\nntdll.ZwMapViewOfSection\r\nntdll.ZwUnmapViewOfSection\r\nAll the functionality is contained in the two export functions, while DllMain does not contain any relevant code.\r\nWhat stands out is the extensive use of custom DWORD-size status codes throughout the code. Decompiled code\r\nexample with status codes in result variable:\r\n1\r\n2\r\n3\r\n4\r\n5\r\n6\r\n7\r\n8\r\n9\r\n10\r\n11\r\n12\r\n13\r\n14\r\n15\r\n16\r\n17\r\n18\r\n…\r\nif ( !a1 || !a2 || !(_DWORD)v3 )\r\n{\r\n     result = 0xA0032B02;\r\n     goto LABEL_45;\r\n}\r\nif ( strlen(a1) \u003c= 1 )\r\n     goto LABEL_65;\r\nresult = get_kernel32_path(a1, \u0026v43, \u0026v37, \u0026v41);\r\nif ( result )\r\n     goto LABEL_45;\r\nif ( (unsigned int)v3 \u003c 0x1C )\r\n{\r\n     LABEL_65:\r\n     result = 0xA0032B02;\r\n     goto LABEL_45;\r\n}\r\npBuffer = allocate_buffer(v13, (unsigned int)v3, 0i64, v11, 0, 1);\r\nhttps://unit42.paloaltonetworks.com/acidbox-rare-malware/\r\nPage 10 of 16\n\n19\r\n20\r\n21\r\n22\r\n23\r\n24\r\n25\r\n26\r\n27\r\n28\r\n29\r\n30\r\n31\r\n32\r\nbuffer = pBuffer;\r\nif ( !pBuffer )\r\n{\r\n     LABEL_9:\r\n     result = 0xA0032B04;\r\n     goto LABEL_45;\r\n}\r\nif ( memcpy_s(pBuffer, v3, a2, v3) )\r\n{\r\n     LABEL_11:\r\n     result = 0xA0032B06;\r\n     goto LABEL_45;\r\n}\r\n…\r\nThe main worker sample contains five icon resources with valid icons named 16, 256, 4097, 8193 and 12289. The\r\nnames indicate different icon resolutions, but the icons only differ in the encrypted data appended to them which\r\ncan be considered as a form of steganography. This data is encrypted with a custom algorithm and additionally\r\nzlib compressed. The same method is used within the SSP DLLs. A Python script for decryption and\r\ndecompression can be found in the Appendix. After decryption, the data blob has the following structure:\r\nstruct data_blob {\r\n     DWORD marker;    // Marker bytes (0x9A65659A)\r\n     DWORD crc32;    // CRC32 value of decrypted or zlib uncompressed\r\nbytes\r\n     DWORD size;     // Size of decrypted or zlib uncompressed bytes\r\n     DWORD option;    // Information if data is encrypted or zlib\r\ncompressed; 0x1 = encrypted, 0x2 = zlib compressed\r\nhttps://unit42.paloaltonetworks.com/acidbox-rare-malware/\r\nPage 11 of 16\n\nchar data[];    // Encrypted or zlib compressed data\r\n};\r\nThe decrypted data is as follows.\r\nResource 16:\r\nSystem\\CurrentControlSet\\Control\\Class\\{4D36E97D-E325-11CE-BFC1-08002B\r\nE10318}\\0003\\DriverData\r\nResource 256:\r\nSystem\\CurrentControlSet\\Control\\Class\\{4D36E96A-E325-11CE-BFC1-08002B\r\nE10318}\\0000\\DriverData\r\nResources 16 and 256 are the Windows registry keys that contain the decryption key for the embedded driver in\r\nresource 8193 and additional payloads that are likely going to be injected by the AcidBox driver.\r\nResource 4097:\r\nC:\\WINDOWS\\SYSTEM32\\lsass.exe\r\nThis resource contains the path of the process each sample uses to verify it is being loaded into the correct\r\nprocess. Resource 8193 contains the unsigned kernelmode payload driver, which is also encrypted with RSA. The\r\ndriver is realized as a kernelmode DLL with two export functions InitEntry and InitExit. It contains the following\r\ncleartext strings:\r\nntoskrnl.exe\r\nntkrn\r\nntkrp\r\nhal.dll\r\nntoskrnl\r\nntkrnlpa.exe\r\nhttps://unit42.paloaltonetworks.com/acidbox-rare-malware/\r\nPage 12 of 16\n\ncsrss.exe\r\nPsCreateSystemThread\r\n\\Device\\VBoxDrv\r\n\\DosDevices\\PCIXA_CFGDEV\r\n\\Windows\\ApiPort\r\n\\Sessions\\%u\\Windows\\ApiPort\r\n\\Sessions\\xxxxxxxx\\Windows\\ApiPort\r\n\\Device\\PCIXA_CFG\r\n\\DosDevices\\PCIXA_CFGDEV\r\nResource 12289 contains the VirtualBox VBoxDrv.sys driver v2.2.0.0 signed by Sun Microsystems, which we\r\npreviously described is also vulnerable.\r\nFigure 3. Signed vulnerable VBoxDrv.sys driver version 2.2.0.0\r\nA Little Forensic Tidbit in the PE header\r\nWhile studying the samples, PE header characteristics -- an often overseen forensic indicator -- caught our\r\nattention. This little known fact can be found in the export directory and can be helpful for attributing malware\r\nsamples. All of the AcidBox samples contain gaps between the single exported function entries:\r\nhttps://unit42.paloaltonetworks.com/acidbox-rare-malware/\r\nPage 13 of 16\n\nFigure 4. Export directories of AcidBox samples with gaps between the export function entries\r\nEvery AcidBox sample has a NumberOfFunctions value in the export directory that is bigger than the\r\nNumberOfNames value. This isn’t something unusual, as not every exported function has to have a name too.\r\nUnnamed functions can be also called by their ordinal values. What is uncommon, however, is that the function\r\nentries which are unnamed are also zeroed out, thus not used.\r\nThis is the result when you use your own DEF file instead of __declspec(dllexport) to describe the attributes of\r\nyour DLL file. When you use a DEF file, you can choose which ordinal your export function will have. This is not\r\npossible with __declspec(dllexport) as the Visual Studio compiler always counts your functions starting from one.\r\nUsing a DEF file instead of __declspec(dllexport) has some advantages. You are able to export functions by\r\nordinals and you can also redirect functions among other things. The disadvantage is that you have to maintain an\r\nadditional file within your project.\r\nIn the case of the AcidBox samples, we can conclude a couple of things. First, the author uses a DEF file, although\r\nhe doesn’t make use of its advantages. This could indicate it’s a habit of the author to use DEF files. Second, the\r\nfunction ordinals seem to be chosen in steps of two integers. A possible explanation could be that the unused\r\nordinals were once used for functions too. And last, if we assume the author really has chosen to make two integer\r\nsteps, then in the usermode DLLs, one export function was removed. We can see that ordinal 3 is unused, leaving\r\na bigger gap than one integer. All this information can be useful for malware attribution.\r\nConclusion\r\nA new advanced malware, dubbed AcidBox, was used by an unknown threat actor in 2017 that went undetected\r\nuntil now. It uses a known VirtualBox exploit to disable Driver Signature Enforcement in Windows, but with a\r\nnew twist: While it’s publicly known that VirtualBox driver VBoxDrv.sys v1.6.2 is vulnerable and used by Turla,\r\nthis new malware uses the same exploit but with a slightly newer VirtualBox version.\r\nSometimes, you are still able to find a technically interesting Windows malware that uses a new technique. This\r\nhas become quite a rarity in today’s threat landscape where everything is either a copy of a copy of a copy or\r\nhttps://unit42.paloaltonetworks.com/acidbox-rare-malware/\r\nPage 14 of 16\n\ntechnically underwhelming. While AcidBox doesn’t use any fundamentally new methods, it breaks the myth that\r\nonly VirtualBox VBoxDrv.sys 1.6.2 can be used for Turla’s exploit. Appending sensitive data as an overlay in icon\r\nresources, abusing the SSP interface for persistence and injection and payload storage in the Windows registry\r\nputs it into the category of interesting malware.\r\nThe samples we dubbed AcidBox are only part of a bigger toolkit which we, unfortunately, could not identify.\r\nHowever, we provide two Yara rules for detection and threat hunting. Additionally, if you happen to find an\r\nadditional sample, or are even infected, you can use the provided Python script to extract the sensitive data\r\nappended to the icon resources. All of these can be found here at Unit 42’s GitHub repository.\r\nIf you have any further information about this threat, don’t hesitate to contact us.\r\nPalo Alto Networks customers are protected from this malware. Our threat prevention platform with WildFire\r\nidentifies this malware as malicious. AutoFocus customers can investigate this activity with the tag AcidBox.\r\nWe would like to thank Dr.Web, Kaspersky, ESET and hFireF0X for their collaboration.\r\nIOCs\r\nFiles in Windows system32 directory\r\nmsv1_1.dll\r\npku.dll\r\nwindigest.dll\r\nMutexes\r\nGlobal\\BFE_Event_{xxxxxxxxxxxx--xxxx-xxxxxxxx-xxxxxxxx}\r\nGlobal\\{xxxxxxxxxxxx--xxxx-xxxxxxxx-xxxxxxxx}\r\nThe malware takes the MachineGuid stored in the registry and reshuffles the single characters alternating from the\r\nend to the beginning and vice versa in steps of two. For example, the MachineGuid string a9982d3e-c859-4702-\r\nc761-df7eea468ade gets transferred into e9a86daeecf5--67c2-07419d87-e34289da and appended to the above\r\ntemplates.\r\nWindows Registry\r\nHKEY_LOCAL_MACHINE\\System\\CurrentControlSet\\Control\\Class\\{4D36E97D-E325-11CE-BFC1-\r\n08002BE10318}\\0003\\DriverData (REG_BINARY type)\r\nHKEY_LOCAL_MACHINE\\System\\CurrentControlSet\\Control\\Class\\{4D36E96A-E325-11CE-BFC1-\r\n08002BE10318}\\0000\\DriverData (REG_BINARY type)\r\nhttps://unit42.paloaltonetworks.com/acidbox-rare-malware/\r\nPage 15 of 16\n\nHKEY_LOCAL_MACHINE\\System\\CurrentControlSet\\Control\\Class\\{4D36E969-E325-11CE-BFC1-\r\n08002BE10318}\\0000\\DriverData (REG_BINARY type)\r\nSample Hashes\r\nMain worker DLL:\r\neb30a1822bd6f503f8151cb04bfd315a62fa67dbfe1f573e6fcfd74636ecedd5\r\nKernelmode driver:\r\n3ef071e0327e7014dd374d96bed023e6c434df6f98cce88a1e7335a667f6749d\r\nSSP DLL modules:\r\n003669761229d3e1db0f5a5b333ef62b3dffcc8e27c821ce9018362e0a2df7e9\r\nb3166c417d49e94f3d9eab9b1e8ab853b58ba59f734f774b5de75ee631a9b66d\r\n3ad20ca49a979e5ea4a5e154962e7caff17e4ca4f00bec7f3ab89275fcc8f58c\r\nBenign VirtualBox VBoxDrv.sys driver v2.2.0 (signed by “Sun Microsystems, Inc.”):\r\n78827fa00ea48d96ac9af8d1c1e317d02ce11793e7f7f6e4c7aac7b5d7dd490f\r\nSource: https://unit42.paloaltonetworks.com/acidbox-rare-malware/\r\nhttps://unit42.paloaltonetworks.com/acidbox-rare-malware/\r\nPage 16 of 16", "extraction_quality": 1, "language": "EN", "sources": [ "ETDA", "Malpedia", "MITRE" ], "origins": [ "web" ], "references": [ "https://unit42.paloaltonetworks.com/acidbox-rare-malware/" ], "report_names": [ "acidbox-rare-malware" ], "threat_actors": [ { "id": "8aaa5515-92dd-448d-bb20-3a253f4f8854", "created_at": "2024-06-19T02:03:08.147099Z", "updated_at": "2026-04-10T02:00:03.685355Z", "deleted_at": null, "main_name": "IRON HUNTER", "aliases": [ "ATK13 ", "Belugasturgeon ", "Blue Python ", "CTG-8875 ", "ITG12 ", "KRYPTON ", "MAKERSMARK ", "Pensive Ursa ", "Secret Blizzard ", "Turla", "UAC-0003 ", "UAC-0024 ", "UNC4210 ", "Venomous Bear ", "Waterbug " ], "source_name": "Secureworks:IRON HUNTER", "tools": [ "Carbon-DLL", "ComRAT", "LightNeuron", "Mosquito", "PyFlash", "Skipper", "Snake", "Tavdig" ], "source_id": "Secureworks", "reports": null }, { "id": "99845f58-2c39-46f7-8369-bb621ebb7002", "created_at": "2022-10-25T16:07:24.238844Z", "updated_at": "2026-04-10T02:00:04.90851Z", "deleted_at": null, "main_name": "Strider", "aliases": [ "G0041", "ProjectSauron" ], "source_name": "ETDA:Strider", "tools": [ "Backdoor.Remsec", "ProjectSauron", "Remsec" ], "source_id": "ETDA", "reports": null }, { "id": "c1ac2a5e-0225-47a4-8ac5-5fa898c96bde", "created_at": "2023-01-06T13:46:38.472883Z", "updated_at": "2026-04-10T02:00:02.989134Z", "deleted_at": null, "main_name": "ProjectSauron", "aliases": [ "Sauron", "Project Sauron", "G0041" ], "source_name": "MISPGALAXY:ProjectSauron", "tools": [], "source_id": "MISPGALAXY", "reports": null }, { "id": "a97cf06d-c2e2-4771-99a2-c9dee0d6a0ac", "created_at": "2022-10-25T16:07:24.349252Z", "updated_at": "2026-04-10T02:00:04.949821Z", "deleted_at": null, "main_name": "Turla", "aliases": [ "ATK 13", "Belugasturgeon", "Blue Python", "CTG-8875", "G0010", "Group 88", "ITG12", "Iron Hunter", "Krypton", "Makersmark", "Operation Epic Turla", "Operation Moonlight Maze", "Operation Penguin Turla", "Operation Satellite Turla", "Operation Skipper Turla", "Operation Turla Mosquito", "Operation WITCHCOVEN", "Pacifier APT", "Pensive Ursa", "Popeye", "SIG15", "SIG2", "SIG23", "Secret Blizzard", "TAG-0530", "Turla", "UNC4210", "Venomous Bear", "Waterbug" ], "source_name": "ETDA:Turla", "tools": [ "ASPXSpy", "ASPXTool", "ATI-Agent", "AdobeARM", "Agent.BTZ", "Agent.DNE", "ApolloShadow", "BigBoss", "COMpfun", "Chinch", "Cloud Duke", "CloudDuke", "CloudLook", "Cobra Carbon System", "ComRAT", "DoublePulsar", "EmPyre", "EmpireProject", "Epic Turla", "EternalBlue", "EternalRomance", "GoldenSky", "Group Policy Results Tool", "HTML5 Encoding", "HyperStack", "IcedCoffee", "IronNetInjector", "KSL0T", "Kapushka", "Kazuar", "KopiLuwak", "Kotel", "LOLBAS", "LOLBins", "LightNeuron", "Living off the Land", "Maintools.js", "Metasploit", "Meterpreter", "MiamiBeach", "Mimikatz", "MiniDionis", "Minit", "NBTscan", "NETTRANS", "NETVulture", "Neptun", "NetFlash", "NewPass", "Outlook Backdoor", "Penquin Turla", "Pfinet", "PowerShell Empire", "PowerShellRunner", "PowerShellRunner-based RPC backdoor", "PowerStallion", "PsExec", "PyFlash", "QUIETCANARY", "Reductor RAT", "RocketMan", "SMBTouch", "SScan", "Satellite Turla", "SilentMoon", "Sun rootkit", "TTNG", "TadjMakhal", "Tavdig", "TinyTurla", "TinyTurla Next Generation", "TinyTurla-NG", "Topinambour", "Tunnus", "Turla", "Turla SilentMoon", "TurlaChopper", "Uroburos", "Urouros", "WCE", "WITCHCOVEN", "WhiteAtlas", "WhiteBear", "Windows Credential Editor", "Windows Credentials Editor", "Wipbot", "WorldCupSec", "XTRANS", "certutil", "certutil.exe", "gpresult", "nbtscan", "nbtstat", "pwdump" ], "source_id": "ETDA", "reports": null }, { "id": "a97fee0d-af4b-4661-ae17-858925438fc4", "created_at": "2023-01-06T13:46:38.396415Z", "updated_at": "2026-04-10T02:00:02.957137Z", "deleted_at": null, "main_name": "Turla", "aliases": [ "TAG_0530", "Pacifier APT", "Blue Python", "UNC4210", "UAC-0003", "VENOMOUS Bear", "Waterbug", "Pfinet", "KRYPTON", "Popeye", "SIG23", "ATK13", "ITG12", "Group 88", "Uroburos", "Hippo Team", "IRON HUNTER", "MAKERSMARK", "Secret Blizzard", "UAC-0144", "UAC-0024", "G0010" ], "source_name": "MISPGALAXY:Turla", "tools": [], "source_id": "MISPGALAXY", "reports": null }, { "id": "d11c89bb-1640-45fa-8322-6f4e4053d7f3", "created_at": "2022-10-25T15:50:23.509601Z", "updated_at": "2026-04-10T02:00:05.277674Z", "deleted_at": null, "main_name": "Turla", "aliases": [ "Turla", "IRON HUNTER", "Group 88", "Waterbug", "WhiteBear", "Krypton", "Venomous Bear", "Secret Blizzard", "BELUGASTURGEON" ], "source_name": "MITRE:Turla", "tools": [ "PsExec", "nbtstat", "ComRAT", "netstat", "certutil", "KOPILUWAK", "IronNetInjector", "LunarWeb", "Arp", "Uroburos", "PowerStallion", "Kazuar", "Systeminfo", "LightNeuron", "Mimikatz", "Tasklist", "LunarMail", "HyperStack", "NBTscan", "TinyTurla", "Penquin", "LunarLoader" ], "source_id": "MITRE", "reports": null }, { "id": "a0d369c1-f0b7-4c70-a3a5-77aabbd17979", "created_at": "2022-10-25T15:50:23.311311Z", "updated_at": "2026-04-10T02:00:05.407733Z", "deleted_at": null, "main_name": "Strider", "aliases": [ "ProjectSauron" ], "source_name": "MITRE:Strider", "tools": [ "Remsec" ], "source_id": "MITRE", "reports": null } ], "ts_created_at": 1775434360, "ts_updated_at": 1775826726, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/05005048baf66e1cc14d11e2b3de96afd3173099.pdf", "text": "https://archive.orkl.eu/05005048baf66e1cc14d11e2b3de96afd3173099.txt", "img": "https://archive.orkl.eu/05005048baf66e1cc14d11e2b3de96afd3173099.jpg" } }