Skip to main content
Skip to main content

Defending Against Autorun Attacks

  • Tim Rains

Some of the most prevalent malware threats over the past couple of years have misused a feature in Windows commonly called Autorun to execute code and attack systems.  The top families of threats that use this technique include Win32/Taterf, Win32/Rimecud, Win32/Conficker, and Win32/Autorun.  If you have been using the Microsoft Security Intelligence Report as a source of information on threats, you’ll likely recognize this list of “usual suspects” and know that many of them can copy themselves to removable or network drives, and attempt to spread when the removable drive is attached, or the network drive is visited from a remote system supporting the Autorun feature.

To combat these threats Microsoft has taken several steps to help protect customers, including releasing updates for the Windows XP and Windows Vista platforms to make the Autorun feature more locked-down, as it is by default on Windows 7. 

The Microsoft Malware Protection Center (MMPC) just released new findings of a study they did on how effective these efforts have been. I’m happy to report that the infection rates of Autorun abusing malware on Windows XP and Windows Vista went down significantly; by May of 2011, the number of infections found by the Malicious Software Removal Tool (MSRT) per scanned computer was reduced by 59% on Windows XP and by 74% on Windows Vista in comparison to the 2010 infection rates.  There were even steeper reductions in these infection rates on systems running the latest service packs. 

You can read the details and other findings of the study in this MMPC blog post.

With data supporting the effectiveness of this mitigation, the clear call to action for IT Professionals and Security Professionals is to evaluate whether you already have the updates for the Autorun feature deployed  in your Windows XP and Windows Vista environments and if not, assess if you can deploy them.  More details on the updates themselves are available on this Microsoft Security Response Center (MSRC) blog post.