Stuxnet: First Physical Weapon in Cybered Conflict Age

Cyber Warfare

Stuxnet is the first publicly known crossover cyber-to-concrete weapon and, with its success, the era of cybered conflict has officially arrived.  This malicious software hit Iran’s nascent contested nuclear reactors in situ this year, disrupting their final completion into full operations.

In so doing, and unlike other viruses and malware, Stuxnet has shown the path of preference of future attackers.  The sophisticated bundled modules in the application harnessed the delivery and stealth skills of exquisitely good cybercriminals to the intents and probably state-sized funding of cybered warriors, all to produce a targeted physical effect.  Stuxnet matters globally because this clear demonstration of what I call fire and forget cyber ‘DNA swarming’ is the first salvo of the future era where every fight will be cybered at key points, some long before any active hostility or crisis. 

From here on, it will not be safe to assume the seemingly innocuous code that floats into your system is safe because it has no history of being malicious. What is safe in your neighbor’s systems might find its designed trigger, the computer DNA it was targeting, in your system, and then issue its disable, disrupt, deceive, or destroy command.  The innocence of the utopian cyber prophets from the 1990s is now firmly gone.

How did it happen? Someone, a very wealthy group or nation, adapted techniques from or hired the best cybercriminals to cripple a nuclear reactor via an internationally distributed malware.  The delivery method was a classic input well used by criminals, the infected thumbdrive – possibly found laying about or given as a gift.  Once the drive was inserted, the immensely intricate malicious program used the zero day exploits of cybercrime to wander around inside the networks of nuclear plants, looking for the targeted combination of command functions and machines.

Since nuclear reactors are generally offline and physically secure, the delivery was designed to eventually end up inside anyway. The application floated around mostly the Middle East and Asia from arguably mid2009 to mid2010.  Being upgraded sequentially in four variations, the malware copied itself from thumbdrive to printer spooler software to thumbdrive, occasionally calling home and being updated if possible. Not really noticed other than as a curiously inactive bit of viral code, it infected thousands of such facilities, and, not finding what it was meant to find, declined to infect untold others. Eventually, however, in various iterations and from various sources, Stuxnet wormed around inside infrastructure intranets to finally encounter the specific configuration, the software-hardware ‘DNA’, of the computers it was designed to seek, and delivered the disable commands to Iranian nuclear reactors. 

The malware’s innovation, in part, is its unselective delivery but highly discriminating design in harm. Stuxnet was programmed not to harm the Windows systems it passed through on the way to the key command software on the central Siemens control system. It also declined to infect Windows 64 machines or those using some minor antivirus companies’ software suites.  Perhaps it was hard enough to program for all conceivable Windows 32bit variations that the originators needed to skip these other outliers. Maybe they just knew enough about Iran and its nuclear reactor systems to know what systems were exceptionally unlikely to be in these facilities.  Iran is a government-sponsored hive of unlicensed software and it is not hard to imagine that Win64 and its stronger intellectual property controls by Microsoft would make the upgrade to Win64 slower to spread across the nation.

At the end of the day, there is no downside to this delivery method, code structure, or the effects for its designers.  Over time Stuxnet copied itself often enough to end up where the iterative designers wanted – inside otherwise non-internetted largescale nuclear energy plants specifically in Iran.  If it traveled to an internetted machine, the code would try to open a backdoor to two URLs and request an update. For those infected systems without internet connection, of course, the program needed to be able to deliver its final payload anyway. So the disable command was buried in the traveling code itself.  It did not need an internet update to deliver on target, and, as Symantec’s analysis noted, it probably was delivered as planned.  But the malware was not only fire and forget with no fingerprints; it was also a great generator of data on other internetted systems until the two URLs were closed down in mid2010.  If the call for an update was all that happened until then, the designers certainly received information on other industrial plants that certainly could prove useful later.

Irrespective of who did it, the cybered conflict box is now officially open. The same people who orchestrated this industrial level of sophisticated application development are still out there, able to do it again, for whatever reason or for whichever employer.  And Stuxnet is in the wild now, being reverse engineered all over the world where it landed by thousands of computer hackers or scientists or warriors or consultants.  ‘Son of Stuxnet’ is inevitable as an employed tool, along with its cousin or distantly related code attempting to replicate the demonstration event of the original.  While it is now relatively easy to find a Stuxnet infection, its children and look-alikes will not be so easy. Stuxnet floated around for up to two years, one year for sure before being noted by the major anti-virus firms.  The rise of cyber DNA swarming will begin with all sorts of actors and reasons.  Who made the original Stuxnet will shortly not matter much.  For the curious, however, the next blog will organize the available public evidence to make a plausible case for who is more likely to have been behind Stuxnet.

Chris Demchak is an Associate Professor at the US Naval War College and at the University of Arizona. The views expressed are her own and do not reflect those of the Navy or the U.S. government. This article is the third in a series titled Cybered Conflict

Image: cyber_warfare.jpg