As we have mentioned in a previous blog W32.Stuxnet contains a complex nested structure of files and components inside. We were interested to discover if the different samples we have seen in the wild were different variants or just modifications to the wrapper with the same components embedded. To determine if there are different variants of W32.Stuxnet we unraveled each sample in order to determine what the payload of each sample consisted of. Here we present the results of that analysis.
From the samples we have we reviewed (we have only reviewed a subset of the total samples to date) we observed 4 distinct file sizes for the installer component as shown below. As you can see although there are 4 different types of installers, the first 3 types are actually the same just with added junk or nulls. However, the fourth type is significantly different from the other 3 types.
Types 1 -3 are equivalent; only Type 4 is different
This can be verified by extracting the payload .dll file from inside the installers and comparing them. As you can see below, the payload .dll file from within the first 3 types of installers has the same size. In fact they are identical. The fourth type is about 100kb larger than the other payloads.
Only the payload inside Type 4 installers is different
Although the payload .dll file in Type 1 and 4 are significantly different they both contain a resources section; analyzing the differences in the resources proves to be quite useful in determining the changes between the 2 different types. The date in the compile time for the payloads suggests that Type 4 is the older sample and Type 1 is the newer version. While the compile time cannot be used as a reliable factor, we will point to other information that also supports this. Generally threats grow larger over time so it is not unusual to see that the newer sample has more resources - 14 as opposed to 11 - but it is surprising to see that the newer samples are smaller than the older samples.
Type 1 is the latest version
So although the newer samples have more resources, their size is smaller. Let’s examine the resources more closely to see why this is the case. The figure below lists the resources for both types shown side by side. The resources in green were added in the latest version, the resources in red were removed from the older version, and the rest of the resources are constant between both new and old samples.
The reason for the difference in size is that Resource ID 207 is absent from the newer versions. Resource 207 is 520Kb, so although more resources were added in newer versions of W32.Stuxnet the sum total of the new resource is less than 520Kb.
To discover what are the functional changes that have occurred we can examine what each resource is used for and see which have been omitted in the latest version and examine the new resources to see what functionality has been added.
Red = resource removed, green = resource added
As you can see many of the components are actually identical or are close to identical having the same functionality with slight differences in the code. For example, the strings in Type 1 resources have been encrypted but the functionality of the component remains the same. This is a good indication that Type 1 samples are newer since more protection is generally added to threats over time.
It is also interesting to see that the only change to Resource 201 is that it is now signed, whereas in the Type 4 samples it was not. This is also a good indicator that Type 1 samples are newer.
Resource 207 and 231 have been dropped from the newer version of W32.Stuxnet. Resource 231 was used to communicate with the control servers and has the C&C server names stored in plain text within the file. The newer version of Stuxnet has moved the internet connection functionality inside the main payload .dll file and has moved the URLs from inside Resource 231 to the installer component and encrypted (if you want to call XOR FF encryption) the URLs. This gives the attacker the distinct advantage of updating the configuration of each sample without having to rebuild the entire package with a new resource inside.
Resource 207 has also been removed but at least part of its functionality has been retained. Resource 250 contains code that previously resided inside Resource 207, although as you can see from the sizes Resource 250 is much smaller so some of the functionality of Resource 207 has been removed.
So what has been added? Resources 240, 241, and 242 are actually all related to the same functionality and this may be the big difference between the two types of samples.
Resource 240 is the link file template that is used to generate link files that exploit the Microsoft Windows Shortcut 'LNK' Files Automatic File Execution Vulnerability (BID 41732). Resource 241 is used as the second part of that exploit to load and execute the Stuxnet installer and also contains the user mode rootkit code to hide files named “~WTR*.tmp”. Resource 242 is the kernel mode rootkit component used to hide the “~WTR” files. So all three of these components are new and all are related to the lnk file exploit shown above.
During analysis of the Type 4 samples we did not see any code to create or hide “~WTR” files or to create malicious formed .lnk files and, although analysis of the old samples is currently continuing, this appears to be one of the major differences between the new and old samples. Although the different types of Stuxnet samples used different methods to spread, their functionality remains the same that is to steal SCADA related design plans and to hook specific SCADA related functions to perform malicious tasks. This is the main goal of both types of samples. Both types of samples operate mostly the same way; just that the newer samples have additional resources added to enable the threat to spread through the .lnk vulnerability. In fact the samples using the .lnk vulnerability were the first samples to be named W32.Stuxnet so although the Type 4 samples predate the name W32.Stuxnet we identify both types of samples as W32.Stuxnet. The name W32.Stuxnet!lnk is used to identify malicious .lnk files used by the threat.
Analyzing the different types of samples we have observed to date has shed some light on how long this threat has been under development and/or in use. The development of the threat dates back to June of 2009 at least. The threat has been under continued development as the authors added additional components, encryption and exploits. The amount of components and code used is very large, in addition to this the authors ability to adapt the threat to use an unpatched vulnerability to spread through removable drives shows that the creators of this threat have huge resources available to them and have the time needed to spend on such a big task; this is most certainly not a “teenage-hacker-coding-in-his-bedroom” type operation.