Previously, I blogged about the installation control flow used by W32.Stuxnet. In this blog I would like to discuss the complexity of the threat a little further and particularly focus on the amount of different files used by the threat and the purpose of each of those files, along with which files are signed and which are not.
The main payload of the threat is a UPX packed .dll file that is contained in an encoded fashion inside one of the files that reside on an infected removable drive. When this UPX .dll file is decoded and unpacked it can be seen to contain many other files within itself as outlined below.
The packed UPX .dll file contains 13 different resources, these resources consist of various different files, both executable and data files, some encoded and some not.
Of the 13 resources shown above, 8 are encoded executable files, one is an encoded cabinet file that contains another executable file, there is also one non-encoded executable file in the resources, there is one .lnk template file for creating .lnk files on removable drives, and the last 2 resources consist of data files.
The files breakdown into the following categories:
-
Three .sys files used for the kernel mode root kit functionality (there is actually only one unique .sys file in the resources but it is embedded in triplicate. The other .sys file used for the rootkit is embedded elsewhere in the UPX .dll file)
-
One copy of ~WTR4141.tmp used when infecting removable devices
-
Two .dll files used for interacting with legitimate software
-
One .exe stub used as a template to inject into other processes
-
One .lnk template used to create custom .lnk files on removable devices
-
Two .dat files
The .sys files
The .sys files are device drivers used for the kernel mode rootkit that enables the threat to hide its own files. Both of these files have a legitimate signature. Both also have Microsoft version information included.
Although it is unusual to have a file signed by one company but have the file version information of another company, we have seen legitimate files like this before. However, these particular files are malicious and yet are signed. This is very unusual.
The two .sys files are dropped as Mrxcls.sys and Mrxnet.sys in the %System% directory. Their purpose is to hide files that have the extension “.lnk” or start with “~WTR” and end in “.tmp”. These are the file names that the threat uses when it infects removable drives. The .sys files are used to hide these files.
Copy of ~WTR4141.tmp
One of the resources is a copy of ~WTR4141.tmp, the loader file that is dropped onto removable drives when they are infected. The interesting aspect about this file is that as the file appears in the resources it has a valid signature.
However when the file is extracted from the resources and dropped onto removable devices, one byte in the header is changed as can be seen below. One byte of the TimeDateStamp is changed.
This change invalidates the signature and consequently when the file that is dropped to the removable device is checked it shows as unsigned:
The fake .dll files
Two of the files in the resources contain file information that reports them to be legitimate files.
However both of these files are not legitimate and both are not signed. Both files are .dll files, the smaller of the two .dll files is a .dll file that hooks APIs in Ntdll.dll in order to load another malicious .dll file and call a specific export from that malicious .dll file. This is the same technique that was outlined in my previous Stuxnet blog.
The larger of the two .dll files is a wrapper for a legitimate .dll file. The wrapper .dll file exports all the same functions as s7otbxsx.dll.
This wrapper .dll is used to intercept calls to the real .dll file and hook any functions it is interested in, and then to pass the call along to the real .dll file. In this way it is able to alter any data that is being accessed or requested by the application. To see how this works let’s look at the entry point of the wrapper .dll file.
As can be seen in the screenshot above the first action that the wrapper .dll takes is to decode an encoded string and call LoadLibrary with that decoded string. The decoded string is “s7otbxsx.dll”. The wrapper .dll file needs to load the real .dll file in order to pass the calls along to the real .dll file after the wrapper .dll file has changed whatever data it wants.
To see how the wrapper works in more detail let’s examine one of the exports from the wrapper .dll file.
We will examine the code that is executed when export “s7H_start_cpu” is called in the wrapper .dll file. The screenshot below shows the code for that export.
So the code for this export pushes 0x0Fh onto the stack and calls another function; let’s look at that function.
Here we can see that the export from the real .dll file is being called at address 1000BE56. So the wrapper .dll file is not intercepting or changing any data for this export, it is simply receiving the request and passing the request onto the real .dll file.
By examining each of the exports from the wrapper .dll file we were able to determine which exports were hooked and which were not. We have identified each hooked export and are currently analyzing them to determine the attacker’s intentions. Some of the exports that are hooked appear to relate to reading, writing, finding, and deleting blocks. These are the typical types of functions an attacker would hook if he were trying to hide some data from the legitimate user. We will follow up with more info on this aspect of the threat soon. The exports that appear to be hooked are:
-
s7_event
-
s7ag_bub_cycl_read_create
-
s7ag_bub_read_var
-
s7ag_bub_write_var
-
s7ag_link_in
-
s7ag_read_szl
-
s7ag_test
-
s7blk_delete
-
s7blk_findfirst
-
s7blk_findnext
-
s7blk_read
-
s7blk_write
-
s7db_close
-
s7db_open
-
s7ag_bub_read_var_seg
-
s7ag_bub_write_var_seg
We are still analyzing this aspect of the threat.
The .exe stub
The resources contain a template for injecting into other processes. This template is used to overwrite the memory of a legitimate process, the template is then filled out with the data that the attacker wants to inject and control is passed to the injected exe.
The .lnk template
The resources also contain a template for the .lnk files needed to initially load the threat from a removable device. Each .lnk file added to a removable drive is customized especially for that drive; there the resources contain a template .lnk file that the threat can modify to create unique .lnk files appropriate for the removable device being infected.
As you can see this threat contains many different files. We are still in the process of analyzing each file but will continue to publish information on the blog as our analysis continues. In this article I focused on the files involved and their purpose; in a later blog we will focus more on the functionality of the threat as outline specifics of its actions. There is a lot more information still to come.
Click
here for more information relating to W32.Stuxnet.
I’d like to thank Nicolas Falliere and Karthik Selvaraj for their analysis that was used for this blog.