APT 33, 34, 35, 39, Destructive ZeroClear

SonicWall Capture Labs Threat Research Team has been actively monitoring APT33, APT34, APT35, APT39, and tracking destructive malware in the Middle East and has found ZeroClear along with other destructive malware this week. The groups above are primarily focused on financial, energy, telecom, and SCADA/ICS computer systems. Most recently, APT33, Iran’s most potent cyber-criminal group, was found probing physical control systems used in electric utilities, manufacturing, and oil refineries using password-spraying attacks.

APT 33 is associated with Elfin, APT33 is a suspected Iranian threat group that has carried out operations since 2013. The group has targeted organizations across multiple industries in the United States, Saudi Arabia, and South Korea, with a particular interest in the aviation and energy sectors.

The ZeroClear trojan is a disk-wiping virus. When executed, it will try to overwrite the Master Boot Record (MBR) and disk partitions on Microsoft Windows based systems. It can execute on x86 or x64 computer systems, today we will focus on the x86 version as most industrial controllers are still running older operating systems. ZeroClear goes by two names on the world wide web. One is called ZeroClear and the other is called ZeroCleare with an e. We will be using the .pdb name below with no e added to the end.

Other related samples to ZeroClear are Dustman, and Shamoon.

As we look through the PE File format in your favorite tool. We are searching for data that is corrupted. This will be highlighted in red in CFF Explorer. Within the GIF below we see no red. This tells us we have a complete sample that has no corruption from a memory dump. This makes analysis easier. As we don’t have to rebuild a memory dump.

The solution is named: ZeroCeare32 and the project is named zeroclear as stated below:

If we translate the solution name we get:

Some comedy is in order: “What’s the matter did you loose all your files?”

As we open the sample in Ida Pro we are confronted with one call and one jump. This code is obfuscated so we just have to manually step through it.

After manually stepping the file you will start to see the malware unpack itself and reach human readable code:

The elrawdsk.sys driver is a software component of EldoS RawDisk by EldoS. The EldoS RawDisk is a tool that allows applications direct access to hard-drive and flash-disk partitions. EldoS RawDisk enables user-mode application processes to bypass security restrictions laid down by Microsoft and access raw disk data sector by sector, access files and folders with restricted security settings. The application was designed to assist the development of forensic, and data recovery software.

ElRawDsk stands for EldoS RawDisk Driver

The application name parameter of CreateProcess is built as follows:

The command that will be built for application cmd is as follows:

We can see the completed CreateProcess call and its parameters in IDA Pro:

At last we start the service:

Next, it will activate the disk management device driver by opening a file handle via a unique filename using the logical drive name. The file names format requested by the API CreateFileW must start with a # character followed by the license key issued to the developer by EldoS. The format will look like:
\\?\ElRawDisk\??\(physical drive):#[EldoS License Below].

Gathering the currently available disk drives such as Drive A, and Drive C:

One of the secrets to knowing what’s inside the buffers when the user-mode application speaks with a kernel driver is the associated I/O control code (also known as an IOCTL Code).

Control codes used in this malware:

• 0x70000 – IOCTL_DISK_GET_DRIVE_GEOMETRY – Retrieves information about the physical disk’s geometry: type, number of cylinders, tracks per cylinder, sectors per track, and bytes per sector.
• 0x700A0 – IOCTL_DISK_GET_DRIVE_GEOMETRY_EX – Retrieves extended information about the physical disk’s geometry: type, number of cylinders, tracks per cylinder, sectors per track, and bytes per sector.
• 0x7405C – IOCTL_DISK_GET_LENGTH_INFO – Retrieves the length of the specified disk, volume, or partition.
• 0x560000 – IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS – Retrieves the attributes for a volume.
• 0x227F80 – UNKNOWN – ???

We can decode the values further by looking into what the driver communication method and access will be:

0x70000

0x700A0

0x7405C

0x560000

0x227F80

What does this mean, well this gives us the format of the associated buffer in user-mode and kernel-mode.

METHOD_BUFFER: (Input vs Output)
Input Buffer = Irp->AssociatedIrp.SystemBuffer
Output Buffer = Irp->AssociatedIrp.SystemBuffer

Input Size = Parameters.DeviceIOControl.InputBufferLength
Output Size = Parameters.DeviceIOControl.OutputBufferLength

The samples wiping behavior functioned by creating a buffer of random bytes and used the API DeviceIoControl to send the buffer to the RawDisk driver to write data what would wipe the victim’s logical drives. Other functionality included overwriting the MBR, partitions, and files on the system with random junk data.

• GAV: Zeroclear.PB.

Sample Hash: 2fc39463b6db44873c9c07724ac28b63cdd72f5863a4a7064883e3afdd141f8d