Creating Malware Using the Stuxnet LNK Exploit

04 Dec 2016

Creating Malware Banner

When the Belorussian antivirus company, VirusBlokAda, first published the Stuxnet worm in 2010 the world of computer security was shaken. The cyber weapon included four zero-day vulnerabilities in the Windows operating system with the capability of compromising even a fully patched Windows 7 system.

Perhaps the most alarming of the OS vulnerabilities used was the LNK Windows Shortcut flaw which allowed the execution of code by merely opening the folder containing the malicious LNK file.

The LNK exploit, now denoted as MS10-046 and CVE-2010-2568, will be the focus of today’s discussion. With a few short steps we will be able to run our own executable code using the very same exploit that set back the Iranian nuclear program by an estimated 2 years.

The Stuxnet virus contains four LNK files that are placed into the root directory of a USB drive:

  • Copy of Shortcut to.lnk
  • Copy of Copy of Shortcut to.lnk
  • Copy of Copy of Copy of Shortcut to.lnk
  • Copy of Copy of Copy of Copy of Shortcut to.lnk

All LNK files specify a path to the same malicious DLL file. The reason why multiple LNK files exist is that different Operating Systems contain different symbolic path names to the USB directory where the malicious DLL file is dropped. Symbolic path names are efficient due to the unpredictability of the drive letter which the USB device will mount to.

(It is worth highlighting here that the exploit can still be implemented with path names using drive letters although more LNK files will need to be created. Search online for the "fanny.bmp" worm for an implementation example.)

An example of one of the malicious LNK files opened in a Hex Editor is shown below.

Hex Editor LNK File

As highlighted in red we may see that this particular LNK points to the following path:


The malicious DLL file in the Stuxnet case is the following file which has had its file extension renamed to help mask the threat from an observer:


When the LNK file is observed in Windows Explorer the Operating System will execute the “LoadLibrary” function on the DLL file. This will cause the “DllMain” function in our malicious file to execute.

There are two key steps in our reproduction of the exploit.

The first step is to ensure the symbolic link file path of the target USB directory is included in one of our LNK files. It is likely that on an un-patched machine the Stuxnet LNK files will suffice. We may troubleshoot a system refusing to trigger the exploit by downloading a Windows Object Manager Tool such as the one given below:

With “WinObj” we are able to obtain the name of the symbolic link to our USB drive by selecting the “GLOBAL” folder and browsing for the correct entry. The selected symbolic link shown in the image below appears when a USB is plugged into an XP machine.

Windows Object Symbolic Link

If the symbolic link observed is not present in one of our LNK files we will need to create a new LNK from one of the existing files and edit the path to the correct directory.

Once we have an LNK file correctly pointing to our malicious DLL it is time to write our executable code. An example DLL file written with the IDE Dev-C++ is given below which will display a “Hello World” popup box.

DLL File

Following compilation you must rename your DLL file to “~WTR4141.tmp” and place it in the root directory of your USB drive. The code should immediately execute and display the popup as shown below. If it does, congratulations. You have reproduced the foundation of the infamous Stuxnet cyber weapon.

Exploit Payload Executed


Ruby Devices

Share This Post

Share on Facebook Share on Twitter Share on Google Plus Share on Linked In Share Ruby Calculator on Pinterest

Sign Up Below for Notifications on new Blog Posts

More from the Blog:

BEST Exam Cheating Calculator!

Ruby Devices do not in any way condone the practice of illegal activities in relation to hacking. All teachings with regards to malware and other exploits are discussed for educational purposes only and are not written with the intention of malicious application.