Our investigations into Stuxnet started on June 17 of this year when the Symantec Security Response team began a journey full of surprises, wrong turns, frustrating moments, and moments of validation. Virusblokada, a security company in Belarus, announced they found a new interesting malware sample using an unpatched vulnerability to spread to removable drives and much of the media focused on the zero-day vulnerability. However, there was much more. Soon people began describing a threat now known as Stuxnet as a tool for cyber espionage stealing design data for industrial control systems, such as gas pipelines and power plants.
Stuxnet then had difficulty shedding those initial reports with most only noting its use of a zero-day exploit and its ability to potentially steal design documents. Only more recently did the general public realize Stuxnet’s ultimate goal was to sabotage an industrial control system.
Analyzing Stuxnet has been one of the most challenging issues we have worked on. The code is sophisticated, incredibly large, required numerous experts in different fields, and mostly bug-free, which is rare for your average piece of malware. Stuxnet is clearly not average. We estimate the core team was five to ten people and they developed Stuxnet over six months. The development was in all likelihood highly organized and thus this estimate doesn’t include the quality assurance and management resources needed to organize the development as well as a probable host of other resources required, such as people to setup test systems to mirror the target environment and maintain the command and control server.