Previously in our series of blogs about Stuxnet we wrote about the installation details and the numerous files that are associated with the threat. In this installment I will discuss the network communication and command and control functionality of W32.Stuxnet. Although some of the tasks that the threat performs are automated, other tasks are performed only after the threat has connected to the command and control server and received specific instructions. It is this aspect of the threat that will be discuss here.
After the threat has installed itself, dropped its files, and gathered some information about the system it contacts the C&C server on port 80 and sends some basic information about the compromised computer to the attacker. Having analyzed all of the samples we have seen to date and extracted the C&C information from them, we have thus far seen only 2 C&C servers referenced:
www[.]mypremierfutbol[.]com
www[.]todaysfutbol[.]com
We also saw some samples that had hardcoded IP addresses inside, but the URLs shown in previous blogs resolved to the same hardcoded IP addresses. The two URLs above previously pointed to servers in Malaysia and Denmark; however they have since been redirected to prevent the attackers from controlling any compromised computers. The threat has the capability to update itself with new C&C URLs but we have not seen any files with updated configurations as yet. In order to update the configuration a file named %Windir%\inf\mdmcpq3.PNF is read. The updated configuration information from that file is written to the main dll and the checksum of the dll is recalculated to ensure it is still correct.
The first connection the threat makes is to establish whether internet access is possible from the compromised computer or not. The addresses of several well known clean sites are encoded in the configuration file for this purpose however we have not seen those URLs used; instead the threat checks for internet connectivity by connecting to one of the malicious URLs shown above.
After internet connectivity has been confirmed the threat sends an http request to the server containing information about the compromised computer. This information is sent by making a request to the following URL:
Hxxp://[C&C server address]/index.php?data=[DATA]
DATA represents the system information that has been gathered. The data is not sent in plain text though; instead it is encrypted with XOR using a 31-byte key. The data section also contains several fields describing the data. The response received back from the C&C server is also encrypted using XOR but using a different 31-byte key. Both of these keys are contained in the malicious .dll file on the compromised computer and can be used to decipher network traffic to and from the C&C server.
The initial encrypted data sent from an infected machine to the C&C contains the following information about the system as well as some small amount of additional data:
-
The Windows version information
-
The computer name
-
The network group name
-
Flag for whether SCADA software was installed or not
-
IP addresses of all network interfaces
When the C&C receives this information it can reply with 2 types of responses. The first type of response instructs the threat to execute one of the procedures already existing within the threats code. In fact the data from this type of response is forwarded to various RPC routines within the main .dll file. The second type of response delivers an additional .dll file to the client in the response and instructs the client to load that .dll file and call an ordinal one from within the downloaded .dll file.
The first type of response acts as a wrapper for RPCs that will be forwarded to the local machine. The RPC calls implemented on the client side can perform the following actions:
-
Read a file
-
Write to a file
-
Delete a file
-
Create a process
-
Inject a .dll into lsass.exe
-
Load an additional .dll file and executed export 1
-
Extract resource 210 from the main .dll file (this resource is used to inject into other processes)
-
Update the configuration data for the threat
The parameters for these RPC calls are passed to the client via response type 1 above. For example, the .dll file to be injected into lsass.exe is passed to the client from the server inside response type 1.
Since the C&C servers have been offline for some time we have been unable to monitor what commands were being actively sent to compromised computers. However as mentioned in our
last blog we have been able to monitor information sent from compromised computers and we are currently engaging the relevant authorities to identify/notify infected users.
In addition to communicating with the C&C server the threat also attempts to spread via network shares. In order to achieve this it copies itself to the root of network shares for which is has permission as “DEFRAG[RANDOM NUMBER].tmp”. It then attempts to create a job to start the .dll file.
The threat has been under continued development for at least a year and we are currently analyzing older samples we have received to understand what changes the threat has undergone during that time.
Click
here for more information relating to W32.Stuxnet.
----------------
Note: Thanks to Karthik Selvaraj and Nicolas Falliere for their help with the analysis of this threat.