View the VMRay Analyzer Report for ZeroCleare
“ZeroCleare” is a new strain of malware discovered by IBM X-Force Incident Response and Intelligence Services (IRIS) this past December. In the 28-page report, the IRIS Team revealed that ZeroCleare was used to execute an attack on Middle East organizations in the energy and industrial sectors. Based on the IRIS team’s analysis, they attributed this attack to Iran-based nation-state adversaries.
ZeroCleare is a wiper, designed to erase the hard drive of the computer it infects. In this blog post, we will analyze ZeroCleare’s behavior in a sandbox (VMRay Analyzer).
First, we know that the payload is ClientUpdate.exe. But by running ClientUpdate.exe first independently, we will see that it tries to load another file, fails, then crashes. That file is soy.exe.
We will submit ClientUpdate.exe and soy.exe as a ZIP file and set ClientUpdate.exe as the entry point.
Figure 1: Submitting ClientUpdate.exe & soy.exe as a ZIP file. ClientUpdate.exe is set as the entry point.
In the VMRay Analyzer Report, we see in the process graph, ClientUpdate.exe calls soy.exe to install the RawDisk driver, then controls the driver after the installation is finished.
Figure 2: ClientUpdate.exe calls soy.exe to install the RawDisk driver
Figure 3: Dropped RawDisk driver detected by YARA
On 64-bit Windows versions, a driver can only be loaded if it signed – a security feature called Driver Signature Enforcement (DSE).
Soy.exe is a modified version of the open-source Turla Driver Loader (TDL). TDL is a tool to bypass DSE by first loading a genuine and signed, but old and vulnerable Virtualbox driver released in 2008, which it then exploits it to gain kernel-mode code execution.
Figure 4: TDL installing the vulnerable Virtualbox driver
The vulnerability exploited by TDL is CVE-2008-3431, an old Virtualbox vulnerability published by Core Security in 2008.
The vulnerability was caused by two combined issues. First, the driver defined that Windows should not do any input validation on incoming IOCTLs by setting the transfer type to METHOD_NEITHER instead of the usual buffered or direct transfer types, where incoming pointers would have been validated. This essentially transferred the responsibility of input validation from the system to the driver. The second issue is the driver, itself, didn’t do any input validation. The data provided by user-mode was written to any pointer that was also provided by user-mode, therefore triggering the write-what-where condition.
To demonstrate the issue, Core Security released a POC that created a blue screen of death. Later, APT Turla turned the POC into a privilege escalation exploit and created a loader around it. An analysis of Turla-used exploits including this one was published by F-Secure in Virus Bulletin in May, 2014. In 2016, a reverse-engineered version of the Turla Driver Loader was uploaded to Github, which is available as an offensive tool. This is likely the base of the soy.exe binary used by ZeroCleare.
Drilling down to the “Behavior” section of the VMRay Analyzer Report, we can see the DeviceIoControl calls used to trigger the Virtualbox exploit. The exploit consists of five DeviceIoControl calls, and TDL uses an extra call to clean up after the exploit is complete and the malicious driver is loaded.
Figure 5: DeviceIoControl calls triggering the exploit.
Because VMRay monitors from the hypervisor we are able to see all the kernel-mode calls made by the sample. This means that for each DeviceIoControl call we can drill down further to see how the resulting IOCTL is handled by the vulnerable driver in kernel-space and observe each step of the exploit.
The first DeviceIoControl call uses the SUP_IOCTL_COOKIE control code to create a cookie to start a session with the driver. In kernel space we see that the Virtualbox driver validates that the cookie uses the correct format, checking the “The Magic Word!” constant. By browsing the source code of VirtualBox, we see that this is the string is the SUPCOOKIE_MAGIC constant.
At this point, the exploit has a session and can send further calls.
Figure 6: The first DeviceIoControl call using SUP_IOCTL_LDR_LOAD to start a session
The second DeviceIoControl call is used to allocate memory in kernel space that will store the shellcode. To get the driver to allocate memory, this IOCTL instructs the driver to allocate memory for an image if it doesn’t exist yet. It is implemented by function supdrvIOCtl_LdrOpen in the VirtualBox source code. In the VMRay function log we see the memory allocations as ExAllocatePoolWithTag calls.
At this point, the exploit has kernel-space memory allocated.
Figure 7: The second DeviceIoControl call using SUP_IOCTL_LDR_OPEN to allocate memory in kernel-space
The third DeviceIoControl call instructs the driver to copy the shellcode to the allocated memory. The call would normally be used to copy the VM image data to memory and is implemented in the supdrvIOCtl_LdrLoad function in Virtualbox.
Since Virtualbox expects the memory buffer to contain a VM image some properties need to be set. One of these is the entry point which will be called by Virtualbox when entering the VM — in the exploit, this entry point should point to the shellcode.
At this point, the exploit has the shellcode in memory, with the entry point set in the structure the driver expects.
Figure 8: The third DeviceIoControl call, using SUP_IOCTL_LDR_LOAD to copy the shellcode to kernel memory
The fourth DeviceIoControl call sets the VM image for which the entry point will be called in the next step. The implementation changed between Virtualbox versions, but the purpose is the same: “Set the VM handle for doing fast call ioctl calls.”. To accomplish this the driver does not need to do additional function calls, it only needs to change a variable.
Now the driver is ready to receive the instruction that the shellcode needs to be executed.
Figure 9: The fourth DeviceIoControl call using SUP_IOCTL_SET_VM_FOR_FAST to set the VM image to be executed
The fifth DeviceIoControl calls the shellcode. The Virtualbox implementation is in function supdrvIOCtlFast. After the shellcode is called, we see the shellcode allocating memory, and creating a driver called elRawDsk from the same memory region with the name “elRawDsk”. This is the loaded Rawdisk driver.
Figure 10: The fifth DeviceIoControl call using SUP_IOCTL_FAST_DO_NOP to call the shellcode and load the driver
The VirtualBox driver is no longer needed so the loader covers up its tracks by deleting its service and driver file.
Figure 11: VirtualBox’s service and drivers being deleted
To use the Rawdisk driver, ZeroCleare first opens a special file handle. According to the IBM report, the hexadecimal string after the hashmark is the license key used to start the software. Once soy.exe loads the driver, ClientUpdate.exe starts using it.
Figure 12: ZeroCleare opening a special file handle.
Finally, we see ZeroCleare instructing the Rawdisk driver to overwrite contents of the hard drive in chunks with junk bytes. For each DeviceIoControl call we see the malware using the same control code, but the first few bytes of the data passed to the driver are slightly different, likely signifying the address to write the random data to. The DeviceIoControl calls are repeated over and over again until the function finally fails.
Figure 13: ZeroCleare instructing the Rawdisk driver to overwrite contents of the hard drive
Figure 14: DeviceIoControl calls with slightly different data over and over again until the function finally fails.
The function log also shows the behavior of the driver triggered by the DeviceIoControl codes in kernel-land: the RawDisk driver allocates some memory with the MmProbeAndLockPages and MmMapLockedPagesSpecifyCache commands, then creates and sends an IRP to the Hard Drive’s driver via the calls IoBuildSynchronousFsdRequest and IofCallDriver.
Figure 15: Rawdisk driver creating the IRP and sending it to the hard drive’s driver
To summarize, the payload of the malware is functional but quite simple for the attacker to build: ZeroCleare uses an open-source project (TDL) to execute a commercial tool (RawDisk) and wipe the disk.
References
ZeroCleare Sample Information
VMRay Analyzer Report for the ZIP of ClientUpdate.exe and soy.exe
ClientUpdate.exe SHA256:
becb74a8a71a324c78625aa589e77631633d0f15af1473dfe34eca06e7ec6b86
soy.exe SHA256:
563653399b82cd443f120eceff836ea3678d4cf11d9b351bb737573c2d856299
