Analyzing ZeroCleare’s Behavior Using a Malware Sandbox

Jan 22nd 2020

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.

 

Submitting ClientUpdate.exe & soy.exe

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.

 

ClientUpdate.exe calls soy.exe to install driver

Figure 2: ClientUpdate.exe calls soy.exe to install the RawDisk driver

 

Dropped RawDisk driver detected by YARA

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.

 

TDL installing the vulnerable Virtualbox driver

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.

 

DeviceIOControl - Triggers VIrtualBox exploit (1)

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.

 

Starting a session

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.

 

Allocating kernel memory

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.

 

Copying the shellcode to kernel memory

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.

 

Setting up the shellcode to be called

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.

 

Calling the shellcode and loading the 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.

 

VirtualBox driver deleted

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.

 

Controlling Driver from ZeroCleare

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.

 

Rawdisk driver to overwrite contents of the hard drive

Figure 13: ZeroCleare instructing the Rawdisk driver to overwrite contents of the hard drive

 

elRawDisk - Hex Dump

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.

 

Rawdisk handling the IOCTL

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

Autonomous Response to critical malware alerts

VMRay + Palo Alto Networks       JOINT WEBINAR