This content is part of the Essential Guide: How air gap attacks challenge the notion of secure networks

After Stuxnet: Windows Shell flaw still most abused years later

A Windows Shell flaw used by the Stuxnet worm continues to pose problems years after it was patched. Nick Lewis explains how the flaw exposes enterprise security shortcomings.

The old adage about lies can aptly describe the information security industry: There are lies, damned lies, and statistics. The source of the data, how it is counted, and how it is analyzed can greatly impact the conclusions. Expecting peer-reviewed academic quality research from industry vendors is a very high expectation that may be unreasonable for such reports, and many times enterprises need to use the best information available at the time given the existing resources to make decisions. That doesn't necessarily change the conclusions for an enterprise, but might make the conclusions highly dependent on specific scenarios where the enterprises need to carefully evaluate the data to see how it applies to their environment. The Windows Shell flaw used by Stuxnet is one of those vulnerabilities that require such careful evaluation for enterprises. The Windows Shell flaw used by Stuxnet has been included in many exploit kits and used by many attackers since it become public, and it continues to cause problems despite Microsoft issuing a patch in 2010.

Windows Shell flaw

Vulnerabilities and exploits can be used by basically any attacker, and even zero-day vulnerabilities may not be limited to just one attacker. Once an exploit has been included in an exploit toolkit, attackers will continue to use it until it stops being effective. Attackers are not going to burn a valuable zero-day unless it's the only way to achieve their goal; as a result, working exploits will continue to be used for a long time given the difficulties with enterprise patching. Kaspersky Lab reported on exploits from 2015 and 2016 and found that the Windows Shell flaw, also known as CVE-2010-2568, is still being used in attacks. In fact, Kaspersky found this particular flaw ranked first among popular exploits in terms of the number of users attacked during the two-year period.

The specific vulnerability from 2010 used by Stuxnet is a Windows Shell vulnerability that allows unauthorized parties to remotely execute code; it is present in every version of Windows Explorer going back to Windows XP. Windows Explorer has functionality in .LNK files that can reference a different file and can include command-line options when executing the file. The .LNK file is treated like an executable file and in certain scenarios it will be automatically executed when browsing to a local or remote directory with Windows Explorer. This functionality is performing as designed and was developed prior to Microsoft's trustworthy computing efforts, which was specifically started to address insecure legacy Windows functionality like this. Since the exploit is abusing legitimate functionality, it has been difficult for enterprises and antimalware vendors to prevent it effectively without disabling the functionality. The loss of functionality may also be a factor for some enterprises to not apply the patch issued by Microsoft.

Enterprise responses

As reported by Kaspersky, the Windows Shell flaw wasn't the only aging vulnerability that's still being used against enterprises. There are several basic information security hygiene controls that need to be in place to protect against an attacker using flaws such as these. These are the same basic steps to protect against the Stuxnet malware. Enterprises should have effective vulnerability and patch management programs to make sure bugs that are actively being exploited are prioritized and remedied. They should also conduct regular risk/security assessments, security awareness training and implement anti-phishing and antimalware programs. These are all standard information security components that an enterprise should already have in place. Trying to implement advanced security controls and systems that assume the basics are already in place may be difficult, but critically evaluating the effectiveness of existing security controls and replacing modern security tools can have a significant impact.


Strong information security programs have feedback loops built in so that when problems are found, they can be remediated without needing to change the entire program. Drastic action might be needed to address a critical vulnerability or respond to a high-impact security incident, but strong information security programs will have the basics in place to support the necessary actions to manage the risk appropriately for the enterprise. These same programs will have the basics in place to ensure effective patching and vulnerability mitigation for persistent problems like the Windows Shell flaw used by Stuxnet.

Next Steps

Find out how NotPetya ransomware lived off the land in enterprise networks

Learn why applying an attacker mindset can help enterprise security

Read more on how to set up a security operations center

This was last published in September 2017

Dig Deeper on Application and platform security