Disttrack’s payload has spread in waves, mainly targeting Saudi Arabia’s critical infrastructure, including, but not limited to: Saudi Aramco, Saudi Arabia’s General Authority of Civil Aviation (GACA), and the Saudi Electric Company, leaving critical systems unusable. It is relentless, stealthy, and persistent as it waits in the shadows of infected computers as a Windows service and attacks on hardcoded dates, like a ticking time-bomb waiting to go off every 90 seconds.
Campaigns using Disttrack are highly targeted and the dates associated with a given campaign are well-defined because of the malware’s destructive nature (Figure 1). Our analysis looks at some of the inner workings of Disttrack to see in fine detail how this malware carries out its destructive goals.
Figure 1: Timeline of Breaches Using Disttrack
The code within the new variants of Disttrack still shares common traits from the original version, which was first deployed in 2012. The author of the various versions compiled the code with Microsoft Visual C++ (version 9 or 10). The variants have been lettered A, B and C. Disttrack.A and Disttrack.B share the same compiled timestamp of 2/15/2009; however, the Disttrack.C variants contain compiled timestamps of 6/6/2011 and 9/14/2011. The Portable Executable (PE) section names and characteristics are the same across the Disttrack variants (Figure 2).
Figure 2: PE Section Similarities Across the Disttrack Variants
The Disttrack variants have leveraged a Windows native DLL called NETAPI32.dll. NETAPI32.dll provides Disttrack with network management functions such as NetScheduleJobAdd, which is used to submit a job to run at a specified future date and time. In Disttrack.B and Disttrack.C, several other functions have been incorporated, which include:
· NetUseAdd, which is used to create a connection between a local computer and a server.
· NetUseDel, which is used to end a connection to a shared resource.
· NetUseEnum, which is used to list all current connections between the local computer and resources on remote servers.
· NetUseGetInfo, which is used to return information about a connection to a shared resource.
The size of code has increased over time. Disttrack.A started at approximately 966 KB and has continued to increase. Figures 3 and 4 are representations of how the code has changed over time, as the payload size increased between versions A and B and then versions B and C.
Figure 3: Code Differences Between Disttrack.A and Disttrack.B
Figure 4: Code Differences Between Disttrack.B and Disttrack.C
The Disttrack variants are modular by design. The resources are a signature feature of Disttrack variants and contain encoded components masquerading as bitmap objects. A key distinguisher of the variants A, B and C are the resource names, with each name corresponding to a specific component (Figure 5).
Figure 5: A Mapping of Names From the Resource Directory to the Components of Disttrack
How Disttrack Works
Disttrack’s worm capabilities are enabled by the auxiliary component. This component leverages the Microsoft RPC Endpoint Mapper to discover other computers on the network. To do this, Disttrack needs to initialize the network adapter to build a socket connection. At offset 14002EED, Disttrack contains code to collect information about the host’s network adapter to build a socket connection and submit packets:
Figure 6: Initialization of the Network Adapter
Then, at offset 14002F40, the code checks for the RestrictAnonymous setting and then changes it to rely on default permissions or null (Figure 7). The RestrictAnonymous registry setting controls the level of enumeration that is granted to an anonymous user (Source: Technet).
Figure 7: This Function Will Check Restrict Anonymous Setting to Null
Once Disttrack completes these checks and sets up a network connection, the code will then broadcast an rpc-epmap packet to solicit responses from listening hosts on the network (Figure 8).
Figure 8: A Compromised System Broadcasting Network Traffic on Port 135 to Locate Other Hosts
Once a connection is made to another host, Disttrack will then attempt to pivot into the compromised hosts as Figure 9 shows at offset 3F4743E2 and offset 3F474424. The code calls GetWindowsDirectory to retrieve the path to the Windows directory on the remote host (in most cases this will be C:\Windows).
Figure 9: Disttrack Pivoting Into Another Host
Disttrack’s next move is to connect to the compromised host’s network share, by calling the NetUseAdd function, which is at offset 140003B87 in the dropper (Figure 10). The NetUseAdd function establishes a connection between the local computer and a remote server. If the UNC path is not specified, the function authenticates the client with the remote host for future connections (Source: MSDN).
Figure 10: Connecting to a Network Share
Once a connection has been authenticated with the use of stolen credentials, Disttrack connects to the remote registry of the compromised host and sets a registry key under HKLM\System\CurrentControlSet\Services that defines a Windows service to run the dropper (Figure 11).
Figure 11: Represents Disttrack Configuring a Windows Service
Some of these services have been identified on compromised computer systems with the following service names:
Once the windows service has been created, Disttrack will execute them using StartServiceW, which you can see at offset 14000349 of the payload (Figure 12).
Figure 12: Executing the Windows Service
Once the service executes, Disttrack extracts the malicious components out from its resource directory onto the compromised system into the c:\windows\system32 directory, which you can find at offset 140001B60 of the payload. Finally, the malware loads the malicious components into memory and the cycle starts over.
Figure 13: Disttrack Extracting its Modules From its Resource Directory
Now, we will move to a dynamic analysis of the malware running on an infected system. In Figure 14, the parent process ID (PID) of 1136 is the Disttrack dropper spawning a child process, PID 3128 that is the wiper payload. Then the wiper component loads kernel drivers into its stack.
Figure 14: The Dropper Spawning the Wiper Component
Figure 15: Disttrack Loading Kernel Drivers Into the Stack
In this case, we see it loading Vdisk911.sys, an outdated, but validly signed Eldos RawDisk driver that provides direct physical access to the master boot table. What’s interesting about the driver is that it contains a temporary license that expired in August of 2012. Disttrack modifies the system clock to use the driver (Figure 16).
Figure 16: Adjusted System Clock to Bypass Temporary License of the Raw Disk Driver
The kernel driver ultimately allows Disttrack to overwrite and destroy the master boot record. A distinguishing feature of Disttrack is the use of an image file to overwrite this area of the disk (Figure 17):
Figure 17: The JFIF Image File Which Was Used to Overwrite the MBR
We can observe the compromised host drive shrinking in size (Figure 18):
Figure 18: Compromised Host Beginning to Lose its Data
Then finally, this results in complete destruction (Figure 19):
Figure 19: Complete Destruction of the Master Boot Record
Figure 20: Operating System Not Found – Total Destruction Complete
Destructive malware such as Disttrack can bring an organization to its knees. Though deployments of this malware have been relatively limited, they’ve garnered significant interest from the media because of the malware’s targeted nature and seemingly political motivations. There can be no doubt about its effectiveness and the fact that Disttrack has the potential to cause harm to an organization’s bottom line.