1. /
  2. Security Response/
  3. W32.Stuxnet


Risk Level 2: Low

July 13, 2010
February 26, 2013 7:15:33 PM
Also Known As:
Troj/Stuxnet-A [Sophos], W32/Stuxnet-B [Sophos], W32.Temphid [Symantec], WORM_STUXNET.A [Trend], Win32/Stuxnet.B [Computer Associates], Trojan-Dropper:W32/Stuxnet [F-Secure], Stuxnet [McAfee], W32/Stuxnet.A [Norman], Rootkit.Win32.Stuxnet.b [Kaspersky], Rootkit.Win32.Stuxnet.a [Kaspersky]
Infection Length:
Systems Affected:
Windows 2000, Windows 7, Windows 95, Windows 98, Windows Me, Windows NT, Windows Server 2003, Windows Server 2008, Windows Vista, Windows XP
CVE References:
1. Prevention and avoidance
1.1 User behavior and precautions
1.2 Patch operating system and software

1.3 Address blocking

1.4 Network Shares and Removable Drives
2. Infection method
Remotely exploitable vulnerabilities
2.2 Network Shares
3. Functionality
3.1 System modifications
3.2 Network activity
3.3 Targetting SCADA software
3.4 Rootkit functionality
3.5 Additional functionality
4. Additional information

The following actions can be taken to avoid or minimize the risk from this threat.

1.1 User behavior and precautions
As Stuxnet spreads through removable drives, users are advised to take caution when connecting a removable drive to their computer. While this threat does not use the AutoRun feature in Windows to spread, it is a good security practice to disable this feature so that removable devices do not execute when they are inserted into a computer. It should be noted that the AutoRun feature is disabled by default for non-optical removable drives in recent versions of Windows and on systems with certain updates applied.

Removable drives should also be disconnected when not required and if write access is not required, enable the read-only mode if the option is available on the drive.

1.2 Patch operating system and software
Users are advised to ensure that their operating systems and any installed software are fully patched, and that antivirus and firewall software is up to date and operational. Users should turn on automatic updates if available, so that their computers can receive the latest patches and updates when they are made available.

This threat is known to be spread by exploiting certain vulnerabilities. Installation of the following patches will reduce the risk to your computer.

1.3 Address blocking
Block access to the following addresses using a firewall, router, or add entries to the local hosts file to redirect the following addresses to
  • www.mypremierfutbol.com
  • www.todaysfutbol.com

1.4 Network Shares and Removable Drives
This threat is also known to spread by copying itself to removable drives and inside large network by using shares, the following steps can help protect your computer against this threat.

  • Users are advised to ensure that all network shares are only opened when they are necessary for use.
  • Use a strong password to guard any shared folders or accounts. A strong password is a password that is of sufficient length of 8 or more characters. The password should also use a combination of numeric, capital, lowercase characters and symbols. Commonly used words from everyday language should not be used as they may easily be defeated by a dictionary attack. This blog provides some ideas on how to construct a strong yet memorable password.
  • Its worth noting that while disabling the AutoRun feature will not prevent the threat from running in this case, it is good security practice to prevent dropped files from running automatically when a network drive is opened.
  • Other mitigation strategies such as enabling read only or not leaving unused USB keys plugged in.


2.1 Remotely exploitable vulnerabilities
Stuxnet was the first worm to exploit the Microsoft Windows Shortcut 'LNK/PIF' Files Automatic File Execution Vulnerability (BID 41732) in order to spread; in fact when Stuxnet was first discovered, this vulnerability was an unknown, or zero-day, vulnerability and it wasn’t until Stuxnet was analyzed that we discovered this vulnerability. Normally when one thinks of a vulnerability in software, one would think of a coding error that an attacker discovers and then exploits. However, while this does indeed fit the definition of a vulnerability, specifically it is a design flaw as Windows is doing exactly what it was designed to do.

The worm copies itself to removable drives as the following files:
  • %DriveLetter%\~WTR4132.tmp
  • %DriveLetter%\~WTR4141.tmp

Both file names are hardcoded and they are actually .dll files.

It also copies the following files to the above drives:
  • %DriveLetter%\Copy of Shortcut to.lnk
  • %DriveLetter%\Copy of Copy of Shortcut to.lnk
  • %DriveLetter%\Copy of Copy of Copy of Shortcut to.lnk
  • %DriveLetter%\Copy of Copy of Copy of Copy of Shortcut to.lnk

When the drive is accessed by an application that can display icons, such as Windows Explorer, instead of displaying the icon for the .lnk files, it runs code that executes the file %DriveLetter%\~WTR4132.tmp. This file’s main purpose is to execute the other file that is copied to the removable drive, DriveLetter%\~WTR4141.tmp, which is then loaded into memory. Its worth noting that this file has a valid signature issued to and signed by well-known companies.

It also uses a remote procedure call (RPC) exploit to spread. This exploit is only effective against computers that have not applied the patch for the Microsoft Windows Server Service RPC Handling Remote Code Execution Vulnerability (BID 31874).

Furthermore, it exploits the Microsoft Windows Print Spooler Service Remote Code Execution Vulnerability (BID 43073) to copy itself from one compromised computer to another. The vulnerability allows for a file to be written to the %System% directory of a vulnerable computer. Stuxnet first uses this vulnerability to plant a copy of itself on a vulnerable machine and later it uses a feature of WBEM to achieve execution of that file on the remote computer.

2.2 Network Shares
Stuxnet also attempts to spread via network shares by copying itself to network shares as the following file:
%DriveLetter%\ “DEFRAG[RANDOM NUMBER].tmp

Note: This file is in fact a .dll file.

It then attempts to create a job to run the .dll file.


3.1 System modifications

File creation
The following file(s) may be seen on the compromised computer.
  • %System%\drivers\mrxcls.sys
  • %System%\drivers\mrxnet.sys
  • %DriveLetter%\~WTR4132.tmp
  • %DriveLetter%\~WTR4141.tmp
  • %DriveLetter%\Copy of Shortcut to.lnk
  • %DriveLetter%\Copy of Copy of Shortcut to.lnk
  • %DriveLetter%\Copy of Copy of Copy of Shortcut to.lnk
  • %DriveLetter%\Copy of Copy of Copy of Copy of Shortcut to.lnk
  • %Windir%\inf\oem6C.PNF
  • %Windir%\inf\oem7A.PNF
  • %Windir%\inf\mdmcpq3.PNF
  • %Windir%\inf\mdmeric3.PNF

File deletion

File modification

Registry entries created
  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MRxCls\"ImagePath" = "%System%\drivers\mrxcls.sys"
  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MRxNet\"ImagePath" = "%System%\drivers\mrxnet.sys"

Registry subkeys/entries deleted

Registry subkeys/entries modified (final values given)

  • iexplorer.exe (injection)
  • lsass.exe (injection)

Once an infected removable drive is attached to a clean computer, the worm copies itself to the clean computer as the following files:

Next, the worm registers the file mrxcls.sys as a service with the following characteristics:
Display Name: MRXCLS
Startup Type: Automatic
Image Path: %System%\drivers\mrxcls.sys

The worm creates the following registry entry for the above service:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MRxCls\"ImagePath" = "%System%\drivers\mrxcls.sys"

It also registers the file mrxnet.sys as a service with the following characteristics:
Display Name: MRXNET
Startup Type: Automatic
Image Path: %System%\drivers\mrxnet.sys

The worm creates the following registry entry for the above service:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MRxNet\"ImagePath" = "%System%\drivers\mrxnet.sys"

It also creates the following files, which are encrypted copies of the worm:
  • %Windir%\inf\oem6C.PNF
  • %Windir%\inf\oem7A.PNF
  • %Windir%\inf\mdmcpq3.PNF
  • %Windir%\inf\mdmeric3.PNF

The file %System%\drivers\mrxcls.sys decrypts these files to reinfect the compromised computer if attempts are made to remove the worm.

3.2 Network activity
The threat may perform the following network activities.

The worm is able to download a payload executable on to the compromised computer from the C&C server and execute it.


The worm 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:
http://[C&C SERVER ADDRESS]/index.php?data=[DATA]

Note: DATA represents the system information that has been gathered.

Other network activity
The worm contacts the following URLs through port 80, which are the worm's C&C servers, to test Internet connectivity:
  • www.mypremierfutbol.com
  • www.todaysfutbol.com

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 data sent from the compromised computer to the C&C server contains the following information:
  • 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. For example, the .dll file to be injected into lsass.exe is passed to the client from the server inside response type 1.

3.3 Targetting SCADA software
Stuxnet is specifically targeting systems with supervisory control and data acquisition (SCADA) software installed. The threat performs many database queries on the database used by the Siemens Step 7 software and interacts with the .dll files belonging to that product. It tries to extract specific data from the database. For example, it tries to access files with the following characteristics, created by the Step 7 software:
  • GracS\cc_tag.sav
  • GracS\cc_alg.sav
  • GracS\db_log.sav
  • GracS\cc_tlg7.sav
  • *.S7P
  • *.MCP
  • *.LDF

By accessing these files, Stuxnet steals code and design projects.

Industrial control systems consist of Programmable Logic Controllers (PLCs), which can be thought of as mini-computers that can be programmed from a Windows system. These PLCs contain special code that controls the automation of industrial processes. Programmers use software (e.g., on a Windows PC) to create code and then upload their code to the PLCs.

Stuxnet has the ability to take advantage of the programming software to also upload its own code to the PLC in an industrial control system that is typically monitored by SCADA systems. In addition, Stuxnet then hides these code blocks, so when a programmer using an infected machine tries to view all of the code blocks on a PLC, they will not see the code injected by Stuxnet. Thus, Stuxnet isn’t just a rootkit that hides itself on Windows, but is the first publicly known rootkit that is able to hide injected code located on a PLC.

In particular, Stuxnet hooks the programming software, which means that when someone uses the software to view code blocks on the PLC, the injected blocks are nowhere to be found. This is done by hooking enumeration, read, and write functions so that you can’t accidentally overwrite the hidden blocks as well. Thus Stuxnet introduces the first known rootkit for industrial control systems.

By writing code to the PLC, Stuxnet can potentially control or alter how the system operates. To date, no industrial facility has been knowingly compromised. What any attacker hopes to achieve by compromising an industrial facility is not known, but one thing is for sure: nothing good can come from a facility being compromised.

3.4 Rootkit functionality
In an attempt to avoid detection the file %DriveLetter%\~WTR4132.tmp hides threat related files by hooking the following APIs from kernel32.dll and Ntdll.dll:
From Kernel32.dll
  • FindFirstFileW
  • FindNextFileW
  • FindFirstFileExW

From Ntdll.dll
  • NtQueryDirectoryFile
  • ZwQueryDirectoryFile

It replaces the original code for these functions with code that checks for files with the following properties:
  • File names ending with ".lnk"
  • File names beginning with "~WTR" and ending in ".tmp" (which explains why the file names on the removable drive are hardcoded and cannot change significantly)

If a request is made to list a file with the above properties, the response from these APIs is altered to state that the file does not exist, thereby hiding all files with those properties.

After the kernel32.dll APIs are hooked, the file %DriveLetter%\~WTR4132.tmp loads the other .dll file, %DriveLetter%\~WTR4141.tmp. However, to achieve this Stuxnet uses a different approach from what one would normally expect. Rather than calling the "LoadLibrary" API to load a .dll file into memory, which is what one would normally expect, Stuxnet hooks certain Ntdll.dll functions, then calls the “LoadLibrary” with a specially crafted file name. The file requested to be loaded does not exist on disk, therefore normally LoadLibrary would fail. However, W32.Stuxnet has hooked Ntdll.dll to monitor for requests to load specially crafted file names. If a specially crafted file name is encountered, the hooked ntdll.dll functions know to load a .dll file from another location instead; a location specified by Stuxnet and that location is generally an area in memory where a .dll file has been decrypted and stored by the threat previously.

The functions hooked for this purpose in Ntdll.dll are:
  • ZwMapViewOfSection
  • ZwCreateSection
  • ZwOpenFile
  • ZwCloseFile
  • ZwQueryAttributesFile
  • ZwQuerySection

Once a .dll file has been loaded, GetProcAddress is used to find the address of a specific export from the .dll file and that export is called, handing control to that new .dll file.

3.5 Additional functionality

Lowering security settings
It injects its code into iexplorer.exe in order to bypass firewalls.

Next, it ends the following security-related processes:
  • vp.exe
  • Mcshield.exe
  • avguard.exe
  • bdagent.exe
  • UmxCfg.exe
  • fsdfwd.exe,
  • rtvscan.exe
  • ccSvcHst.exe
  • ekrn.exe
  • tmpproxy.exe

For more information relating to this threat family, please see the following resource:
Blog entries on W32.Stuxnet
W32.Stuxnet Dossier (White paper - September, 2010)
W32.Stuxnet Timeline (Infographic - June, 2011)
Stuxnet 0.5 – The Missing Link (Video - February, 2013)
Stuxnet 0.5: The Missing Link (White paper - February, 2013)


Symantec Security Response encourages all users and administrators to adhere to the following basic security "best practices":

  • Use a firewall to block all incoming connections from the Internet to services that should not be publicly available. By default, you should deny all incoming connections and only allow services you explicitly want to offer to the outside world.
  • Enforce a password policy. Complex passwords make it difficult to crack password files on compromised computers. This helps to prevent or limit damage when a computer is compromised.
  • Ensure that programs and users of the computer use the lowest level of privileges necessary to complete a task. When prompted for a root or UAC password, ensure that the program asking for administration-level access is a legitimate application.
  • Disable AutoPlay to prevent the automatic launching of executable files on network and removable drives, and disconnect the drives when not required. If write access is not required, enable read-only mode if the option is available.
  • Turn off file sharing if not needed. If file sharing is required, use ACLs and password protection to limit access. Disable anonymous access to shared folders. Grant access only to user accounts with strong passwords to folders that must be shared.
  • Turn off and remove unnecessary services. By default, many operating systems install auxiliary services that are not critical. These services are avenues of attack. If they are removed, threats have less avenues of attack.
  • If a threat exploits one or more network services, disable, or block access to, those services until a patch is applied.
  • Always keep your patch levels up-to-date, especially on computers that host public services and are accessible through the firewall, such as HTTP, FTP, mail, and DNS services.
  • Configure your email server to block or remove email that contains file attachments that are commonly used to spread threats, such as .vbs, .bat, .exe, .pif and .scr files.
  • Isolate compromised computers quickly to prevent threats from spreading further. Perform a forensic analysis and restore the computers using trusted media.
  • Train employees not to open attachments unless they are expecting them. Also, do not execute software that is downloaded from the Internet unless it has been scanned for viruses. Simply visiting a compromised Web site can cause infection if certain browser vulnerabilities are not patched.
  • If Bluetooth is not required for mobile devices, it should be turned off. If you require its use, ensure that the device's visibility is set to "Hidden" so that it cannot be scanned by other Bluetooth devices. If device pairing must be used, ensure that all devices are set to "Unauthorized", requiring authorization for each connection request. Do not accept applications that are unsigned or sent from unknown sources.
  • For further information on the terms used in this document, please refer to the Security Response glossary.
Writeup By: Jarrad Shearer
Summary| Technical Details| Removal

Search Threats

Search by name
Example: W32.Beagle.AG@mm
STAR Antimalware Protection Technologies
Internet Security Threat Report
Symantec DeepSight Screensaver