Countdown to Zero Day: Stuxnet and the Launch of the World's First Digital Weapon

by Kim Zetter

  WITH THE DISCOVERY of this last module, Kaspersky’s work on code created by the Stuxnet gang began to wind down—in part because the detailed work that Raiu and his team had done to expose all of these covert nation-state tools was starting to bring the researchers unwanted attention.

  As they released one finding after another, there were some in the security community who began to question their motives. Just as Symantec had been criticized for disloyalty to the United States in exposing Stuxnet and harming US national security interests, some wondered if the Moscow-based Kaspersky Lab was doing the bidding of Russian intelligence by exposing and sabotaging Western spy operations.

  Raiu says, however, that they were never influenced or guided in their work by any government or intelligence agencies. He and his team considered their work above and beyond politics, and their only aim, like those of the Symantec researchers, was to exercise their reverse-engineering skills in the service of defending customers and contributing to the security of the computing community. In fact, their work exposing the Stuxnet and Flame gangs actually conflicted with their company’s own business interests. Kaspersky Lab was in the midst of a major push to expand into the US market, and founder Eugene Kaspersky had been making a concerted effort to cultivate friends in Washington and Israel to this end. It was no help, then, that while he was courting these two governments, his researchers were busy exposing their covert operations.

  But it wasn’t just the company’s business interests that were at risk of being affected by their work. The Symantec researchers had been worried during their analysis of Stuxnet that their work might be secretly monitored by Israel and the United States, or even by Iran, though they never saw any concrete signs that this actually occurred. Raiu, however, became certain that he was being followed while in Munich for a conference in the spring of 2012. It was shortly after they had discovered Flame, but before they’d gone public with the news. Raiu noticed someone lurking at the front desk of his Munich hotel when he checked in, as if trying to discover his room number. Later he noticed others tailing him when he went to the restroom or his hotel room. When he mentioned his concern to colleagues, they noticed it too. He suspected the people shadowing him were from a foreign intelligence agency, but he couldn’t be sure. Then he was approached by three Israelis who wanted to speak with him about his work on Duqu, and by a woman who wanted to know if Kaspersky had the ability to recover wiped files from a hard drive. The latter question was a bit unsettling, since Kaspersky was in the midst of trying to recover files from systems in Iran that had been trashed with the Wiper malware.

  It was yet another stark reality check that the world of virus hunting had changed dramatically with Stuxnet. Previously the only risk researchers faced from exposing digital threats was the wrath of cybercriminals who might take issue with them for interfering with their livelihood. But the dismantling of nation-state threats introduced a whole new world of concerns, and Raiu decided, for the sake of his young family, that he should lower his profile. After the incidents occurred at the Munich conference, he withdrew from speaking publicly about Kaspersky Lab’s nation-state work and left it to colleagues to handle the media duties thereafter.

  It was no coincidence then, when, not long after this, the Kaspersky researchers turned their attention away from the Stuxnet-Duqu-Flame family of threats to focus on other projects—in particular one believed to be the work of Russian actors. The operation, dubbed “Red October,” targeted diplomats, governments, and research institutes, primarily in eastern Europe and central Asia, with the principal aim of collecting confidential documents and geopolitical intelligence. Raiu and his colleagues suspected it was the work not of nation-state actors but of Russian cybercriminals or freelance spies who were seeking the intelligence to sell it.

  With the Red October operation, the Kaspersky team seemed to put the Stuxnet gang behind them for good. But this didn’t mean that everyone had heard the last from Stuxnet. It turned out that the digital weapon still had one more surprise waiting to be revealed.

  IT WAS NOVEMBER 2012, more than two years after Stuxnet had been discovered, when even Duqu and Flame were becoming distant memories, that the Symantec researchers stumbled upon a missing link that they had long given up hope they would ever find—an early version of Stuxnet that preceded all other known variants.

  They found it while scouring their archive for any malicious files that had fingerprints matching Stuxnet’s—something they periodically did with malware signatures to make sure they hadn’t missed anything important. In doing this, a component popped up that they hadn’t seen before. It had been sitting in their archive since November 15, 2007, when someone had submitted it to VirusTotal, which meant the first Stuxnet attack had been unleashed much earlier than previously believed.28 As noted previously, they had always suspected other versions of Stuxnet existed, due to gaps in the version numbers of the 2009 and 2010 variants—1.001, 1.100, and 1.101. They had even suspected there might be an early version of Stuxnet that had preceded all other known ones. Now they had found it—Stuxnet version 0.5.

  As they uncovered more files associated with the component, however, they discovered that this wasn’t just any version of Stuxnet. It was one that contained the complete 417 attack code, fully intact and enabled.

  Their previous attempt to unravel Stuxnet’s attack against the Siemens S7-417 PLC had failed because the code was incomplete and disabled in later versions of Stuxnet. Symantec’s Nicolas Falliere had thought perhaps the attackers had disabled it because they were waiting for a critical bit of configuration data to complete their attack. But now it was clear they had disabled it because they had decided to change their tactics. Although the later versions contained both the 315 and the disabled 417 attack codes, this early variant had no sign of the 315 attack code in it, just the code that attacked the Siemens 417 PLC. It was clear from this that the attackers had first focused their assault on 417 PLCs at Natanz and then for whatever reason—the attack hadn’t achieved their aim or was taking too long to achieve it—had recalibrated and turned their sights on the 315 PLCs instead.

  Now that the Symantec team—minus Falliere, who had left Symantec for a job at Google—had their hands on this early variant, they were finally able to determine what the 417 PLCs were controlling and what Stuxnet was doing to them. It turned out this version was targeting the valves that managed the flow of uranium hexafluoride gas into and out of the centrifuges and cascades at Natanz.29 Stuxnet was opening and closing the valves to increase the pressure inside the centrifuges to five times its normal level. At that pressure, the gas would likely begin to solidify, ruining the enrichment process, and causing the centrifuges, spinning at high speed, to careen dangerously off balance and crash into other centrifuges around them. Or at least this was likely the plan. It may not have worked as well or as quickly as the attackers had hoped, so in 2009 they changed tactics and focused on attacking the frequency converters instead—a more direct method of damaging the centrifuges.

  Although Stuxnet 0.5 had no kill date and should have still been active when later versions of Stuxnet were released, researchers never found this version on any machines when Stuxnet was discovered in 2010.30 This may have been because it got erased. One of the first things later versions of Stuxnet did when they landed on a machine was check for earlier versions of Stuxnet on the machine and replace them. So it was likely that Stuxnet 0.5 got automatically replaced on infected machines when the June 2009 version was launched.31

  It’s also possible that samples of Stuxnet 0.5 were never found because this version was much more tightly controlled than later ones and only infected a limited number of machines. Instead of using zero-day exploits to spread, it spread in just one way—by infecting Siemens Step 7 project files. These were the files that programmers shared among themselves that were used to program the Siemens S7 line of PLCs, making them ideal for getting Stuxnet onto the targeted PLCs. The fact that this version only spread via Step
7 files suggested the attackers had an inside track to get it onto core systems at Natanz. Stuxnet 0.5 was therefore likely never caught because patient zero—the first machine it infected—may have been one of the very programming machines the attackers were targeting. With later versions of the malware, they may have lost this access, which forced them to bulk up Stuxnet with extra spreading power to increase the odds of reaching their target.32 Unfortunately, this spreading power in later versions, and the location of patient zero in an office outside of Natanz, were the factors that got Stuxnet caught.33

  Stuxnet 0.5 was completely autonomous once unleashed, so the attackers had no need to control it. But if it found itself on a machine that was connected to the internet, it still contacted one of four command servers, from which the attackers could send new code to update the digital weapon if needed.34 Stuxnet was programmed to stop communicating with the servers on January 11, 2009, but by then the attackers were already preparing the next version of their assault—a driver they compiled January 1, 2009, for use with the next version of Stuxnet, which they unleashed five months later.

  The submission of Stuxnet 0.5 to VirusTotal in 2007, along with other dates associated with the code, forced the researchers to revise their estimate of when work on Stuxnet began.35 It appeared that preliminary work on the attack had begun as early as November 2005. This is when some of the domains for the command-and-control servers used with Stuxnet 0.5 were registered. Code for other command servers later used in the 2009 and 2010 Stuxnet attacks—the todaysfutbol.com and mypremierfutbol.com domains—was compiled in May 2006. Though Stuxnet itself wasn’t unleashed in 2006—Bush’s advisers proposed it to him only that year—the command infrastructure for controlling it was already being set up during this time. It’s possible the command servers were initially set up to communicate with Flame, Duqu, or another spy tool the attackers used to collect intelligence for the operation, then were used again for Stuxnet. These early dates certainly coincided with when the Kaspersky researchers believed work on Flame began.

  The dates also coincided with the period when the political situation over Iran’s nuclear program was reaching a breaking point: In August 2005, two months after Ahmadinejad was elected president, international talks over Iran’s nuclear program collapsed, and Iran announced it was withdrawing from the suspension agreement. Three months later, the attackers registered the command-and-control servers for Stuxnet 0.5.

  Iran did have centrifuges installed at Natanz during this time, but only in the pilot plant. In February 2006, three months after the command servers were registered, Iran attempted to enrich its first batch of uranium in a small cascade at the pilot plant. But the operation didn’t go well, since fifty of the centrifuges exploded. It’s possible an early version of Stuxnet was responsible for this; Iranian authorities attributed the sabotage to UPSes from Turkey that they said had been manipulated to cause a sudden power surge.

  Iran quickly recovered from that setback and in May announced that technicians had achieved 3.5 percent enrichment in a full-size cascade at the pilot plant. Plans to begin installing the first of 3,000 centrifuges in one of the underground cascade halls commenced. It took until early 2007, however, for the first centrifuges to be installed in the hall. By November that year, about 3,000 centrifuges were in place. That same month, Stuxnet showed up in the wild for the first time when someone submitted Stuxnet 0.5 to VirusTotal.

  WITH THE DISCOVERY of this early version of Stuxnet, the researchers now had what was likely to be the most complete picture they were ever going to have about what occurred with this groundbreaking attack against Iran.

  It had been a long and improbable ride that was made possible only by a series of unfortunate events and flubs that should never have occurred—from the zero-day exploits that launched Stuxnet on its wild odyssey through thousands of machines around the world to the crashing machines in Iran that first gave it away; from the green researchers in Belarus who lacked the skill and experience to tackle a threat like Stuxnet to the Symantec researchers who bumbled their way through the PLC code; from the Wiper tool in Iran that led the Kaspersky team to uncover Flame to the server in Malaysia that locked the attackers out and preserved a mountain of forensic evidence for the researchers to find. There were so many things that had to go wrong for Stuxnet and its arsenal of tools to be discovered and deciphered that it’s a wonder any of it occurred.

  When it was all done, the Kaspersky and Symantec researchers looked back over the two years of work they had put into reverse-engineering and analyzing the Stuxnet gang’s malicious tools and were left to marvel at the level of skill and craftsmanship that went into building them. But they were also left scratching their heads at the shocking rapidity at which operations that had remained stealth for so many years had unraveled so quickly in their hands—like the errant string of a sweater that when yanked causes the entire garment to disintegrate.

  The attackers had no doubt assumed, even counted on, the Iranians not having the skills to uncover or decipher the malicious attacks on their own. But they clearly hadn’t anticipated that the crowdsourced wisdom of the hive—courtesy of the global cybersecurity community—would handle the detection and analysis for them.

  With Stuxnet, a new world order was born in which security researchers and reverse-engineers became the unwitting draftees in a new kind of militia—one enlisted to dismantle and defend against the digital weapons that nations lobbed at one another. This new order created a host of new ethical and national security dilemmas for researchers caught between the needs of computer users and the interests of intelligence agencies and governments. If Stuxnet signaled the beginning of the militarization of cyberspace, it also signaled the beginning of the politicization of virus research.

  “There’s a new good guy/bad guy question here that puts us potentially in a very difficult position,” Eric Chien said in 2012 after their analysis of Stuxnet was done. Their work on Stuxnet had been unmarred and unimpeded by political influences, and he hoped to never be in a position where they were forced to choose between customers and the interests of national security. But he wasn’t so naïve to think that it would never come to that.

  “It sounds a little cheesy, but we’re just trying to help people and do what’s right,” he says. “If we get to a point where we have to ask that question, it’s going to be a very hard question [to answer]. I think we’ll be in a bad place if we get to that point.”36

  * * *

  1 Another clue uncovered from the ravaged system also seemed to point to the attackers behind Stuxnet and Duqu. The clue indicated that the first thing Wiper did when it landed on a system was hunt down and obliterate any file that had a .PNF extension. Raiu recalled that the payload file in Stuxnet as well as some of its other files all had .PNF extensions. Duqu also had files with a .PNF extension, an extension that was rarely used in malicious tools.

  2 The log also contained the internal computer names of systems in Iran that had been infected.

  3 Microsoft patched it on June 9, about two weeks before the June version of Stuxnet was released on June 22, 2009.

  4 With regard to whether Flame was connected to Wiper, there was some confusion between the two attacks after the Kaspersky researchers uncovered a Flame module that was named Viper. But the job of this module was to transmit stolen data to a command server, not to wipe the hard drive of infected machines. Its existence, though, raised questions initially about whether the Wiper malware the Iranians found was actually a component of Flame. It didn’t help that some Iranian reports identified Wiper as Viper, due to a transliteration error from Persian to English. But in the end, Kaspersky found no direct connection between Wiper and Flame.

  5 Most of the machines that were infected had the 6 MB version installed on them. But they also found a smaller starter kit that was about 900 KB with no extra modules included with it and that may have been used to infect machines over slow network connections, since the 6 MB module would take for
ever to install remotely in countries with slow and unreliable internet connections.

  6 The malware’s configuration file contained a list of five static domains—among them traffic-spot.biz, dailynewsupdater.com, and bannezone.in—as well as another list that could be altered at random whenever the attackers added new command servers.

  7 The attackers were more careful with Flame to alter timestamps in files to prevent researchers from dating the work. Although some of the timestamps appeared to be accurate, others that indicated files had been compiled in 1994 and 1995 were clearly incorrect because the files contained code from libraries that hadn’t been created until 2010.

  8 The server code actually had a liner note the programmers had inserted to identify the authors and date of creation. The note read: “@author OCTOPUS in 12/3/2006; @author DeMO (modifications).” The names were likely code names for the individuals or teams that set up the servers.

  9 While Kaspersky had been examining the Flame files it obtained, Symantec had been examining the one it received from Bencsáth as well as other modules they obtained from the machines of infected customers after adding detection to their antivirus tools. Neither of the teams communicated with each other about their work, though each secretly learned that the other was researching the code. When the Symantec researchers discovered that the Kaspersky researchers planned to publish their results on Memorial Day, they rushed to complete their analysis to publish the same day. The author was contacted by both companies separately—first by Kaspersky and then by Symantec—in advance of the announcements. See Kim Zetter, “Meet Flame, the Massive Spy Malware Infiltrating Iranian Computers,” Wired.​com, May 28, 2012, available at wired.​com/​threatlevel/​2012/​05/​flame.