Several different events in the Middle East (ME) region have escalated in the last several weeks between Iran and the United States.  After a series of  military operations between the two countries, several alerts were released from the U.S. government of a potential for cyberattacks.  

Traditionally there have been several high profile threat groups that have been suspected to have been backed by or acted on behalf of Iran.  Using the below image as a high level timeline we can see these Iranian threat groups have been active in cyber attacks for a considerable amount of time.  The recent tensions in the ME region have brought this threat to the forefront in the news. While the threat and capabilities of groups supporting Iran are very real, they have not just become active with the activity that has occurred recently.  From public reporting and internal research, many of these groups rely heavily on common tactics like spear phishing, brute force attacks, and internet facing systems with unpatched known vulnerabilities.    

Figure 1: Iranian Threat Group Timeline Overview

In the past week ,reports have surfaced of different attacks, where destructive malware have been used against victims in the Middle East.  Destructive malware is generally the coup de grâce, that follows a larger attack. From talking to IR partners in the region and from other published reports, this specific destructive malware has been used in conjunction with traditional lateral movement techniques.  Detecting and stopping the first stages of these types of attacks should continue to be the principal fundamentals that security practitioners refine in their organizations.  Focusing on spear phishing, user execution, credential dumping, and living off the land techniques will yield positive security returns that will help to combat numerous threat groups.

As a result of the recent increase in news coverage we would like to share a detailed analysis of common activity seen from Iranian threat actors, who have utilized this wiper.  Additionally, numerous customers and partners requested that we provide product specific detections.

The malware itself is a variant of a kernel driver loader, used extensively by the Turla group (Russian APT) as early as 2014.  The initial binary will create three files on the local system, which are embedded and encoded as resources.  The dropper will then create a service to run one of the files which is a legitimate VirtualBox driver file. 

This specific version is signed, but contains a known vulnerability (CVE-2008-3431) that allows the dropper to inject shellcode into the process, which will execute and load an unsigned driver which bypasses Microsoft’s driver signature execution protections.  This unsigned driver is a legitimate application that provides low level access to the disk and file system. The third file, which is the wiper, uses the raw disk driver to write junk data to different regions of the disk making the operating system crash and become unresponsive. 

Additionally some data originally present on the disk will be unrecoverable. The image below is an overview of how the files are dropped on the disk, and interact with each other as part of this attack.   

Figure 2: Overview of Wiper attack flow

Technical Details:

The following file was analyzed for this report.

Table 1: Wiper metadata

This file is a variant of a Turla driver loader.  The loader will initially create the mutex “Down With Bin Salman,” an obvious reference to Crown Prince Mohammad Bin Salman and the regions being targeted.   

Figure 3: Mutex creation

The dropper will then determine the version number of the operating system, highlighted in red in the image below.  If the operating system is 6.x or above (which correlates to Windows Vista or newer), it will then create the two initial files on the system.  This activity is highlighted in blue below. It should be noted that all of the embedded files are stored in the binary as resources, which have been encoded using a one byte XOR key of 0x70.  The first file which is written to disk is the raw disk driver, which is decoded and created in the same directory that the dropper is running out of (highlighted in blue). This file will be saved to disk as elrawdsk.sys.  If this file creation operation is successful then the binary will begin creating the second file, which is a legitimate VirtualBox driver, highlighted in green below.

Figure 4: RawDisk driver creation

The dropper will then decode the second payload, highlighted in red in the image below.  The dropper will then use API calls to query the service manager to stop several VirtualBox related services, which is highlighted in green in Figure 5.  This is done specifically using the ControlService API with the SERVICE_CONTROL_STOP parameter.  The decoded payload is then written to disk as assistant.sys, in the same directory that the loader is running from.  The loader will then create a new service, named VBoxDrv (highlighted in blue).  

Figure 5: VBox Driver Creation

The file, assistant.sys, is a VirtualBox (vbox) driver that has a known vulnerability which ultimately allows an attacker to execute a shellcode payload under the context of the vbox driver.  The shellcode is embedded in the loader itself and injected, via the exploit, into the now running vbox driver. The shellcode will then load the elrawdsk.sys file, highlighted in red below. The technique of passing shellcode to this vulnerable driver has been well documented publicly in 2014.

Figure 6: Shellcode

The dropper will then decode the final payload, highlighted in red in the image below.  The file will be saved to disk as agent.exe, in the same directory from which the loader is running.  This file is the executable that performs the wiping of the drive, leveraging the raw disk driver.  

Figure 7: VBox Driver Creation

The dropper will then enumerate the drives on the local system, and check that the drive types are either fixed or removable, highlighted in blue.  For any drive that matches those types, the loader will create a process, using cmd.exe to execute the agent.exe file with the drive letter passed as an argument.  For example, if targeting the C: drive the agent.exe file would be executed in the following manner.

Table 2: Wiper process creation command

The metadata for the payloads that the loaded extracts and writes to disk are listed in the table below.

Table 3: Dropped files’ metadata

The wiper itself ultimately leverages the loaded raw disk driver (elrawdsk.sys) to overwrite junk code to the MBR and other areas of the hard drive.  The image below shows the basic setup, where the wiper will open a handle to the logical drive via the driver. The license key that is visible has been referenced in previous analysis as well. 

Figure 8: Agent wiper functionality

For VMware Carbon Black product detections, click here.

Yara Rule