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

One of the first things Stuxnet did was determine if the computer was a 32-bit or 64-bit Windows machine; Stuxnet only worked with 32-bit Windows machines. It also determined if the machine was already infected with Stuxnet. If it was, Stuxnet made sure the resident malware was up to date and simply swapped out any old files for the latest ones. But if Stuxnet found itself on a new machine, it began an elaborate infection dance, racing rapidly through a succession of steps to scope out the landscape of the machine and determine the best way to proceed.

During this process, one of its rootkits quickly took up position on the machine to blind the system to Stuxnet’s files on the USB flash drive. It did this by hooking the system so the file names couldn’t be seen by virus scanners—the equivalent of hiding them in a scanner’s shadow. If the scanner tried to read the contents of the flash drive, the rootkit intercepted the commands and served back a modified list that didn’t include Stuxnet’s files. But some scanners couldn’t be bypassed in this way. Stuxnet knew which scanners were trouble and modified its methods accordingly
if it found one of these on a machine. If Stuxnet determined it couldn’t bypass a scanner at all, it halted the infection and shut itself down.

But if Stuxnet decided to proceed, the second driver then got activated. This one had two tasks—the first was to infect any USB flash drive that got inserted into the machine, which it would do for only twenty-one days after Stuxnet infected the machine.
⁵
The second, and most important, task was to decrypt and load the large .DLL, and its various components, into the machine’s memory using the novel techniques O’Murchu had documented. First it unwrapped and decompressed the .DLL to release the smaller .DLLs inside, then it loaded them into memory. Because the files were running in memory, any time the machine rebooted, the files got wiped away, so the driver also had to reload them in memory after each reboot.

Once the large .DLL and its contents were all unpacked and loaded into memory, Stuxnet searched for new machines to infect and called home to the command-and-control servers to report its new conquest—but unless it found the Siemens Step 7 or WinCC software installed on the machine, Stuxnet would go dormant on the machine once these steps were done.

So now the Symantec researchers knew how Stuxnet propagated and loaded its files, but they still didn’t know why it was created or what it was designed to do. The answers to these questions were still buried within its payload.

As O’Murchu reflected on what they had uncovered so far in the missile portion of the code, he couldn’t help but admire the artful handiwork the attackers had put into their attack—the clever ways they solved problems they expected to encounter, and the numerous scenarios they had to test before releasing their code. Not all of Stuxnet’s features were impressive on their own, but as a whole the attack posed a formidable threat.

Aside from the complex ways Stuxnet loaded its files and bypassed security software, it used an extensive checklist to ensure all conditions were
ideal on a machine before unleashing its payload. It also carefully tracked all of the resources it used on a machine and made sure to free up each as soon as it was no longer needed to reduce the amount of processing power Stuxnet consumed on the machine—if Stuxnet used too much power, it ran the risk of slowing the machine down and being discovered. It also overwrote many of the temporary files it created on a machine once they were no longer needed. All software programs create temporary files, but most don’t bother to delete them, since they’d just be overwritten by the temporary files other applications create. The attackers didn’t want Stuxnet’s files lingering on a system for long, however, because it raised the risk that they’d be seen.

But despite all the extra effort the attackers put into their code, there were several parts that seemed oddly underdesigned. O’Murchu wasn’t the only one who thought so. As the Symantec researchers published their findings about Stuxnet over several weeks, members of the security community began grumbling online about the code’s many failings, insisting that its authors weren’t nearly the elite cadre of hackers original reports made them out to be. Their technical prowess was inconsistent, some said, and they made a number of mistakes that allowed investigators to see more easily what they were trying to do.

Stuxnet, for example, would have been much more difficult to decipher had the attackers used better obfuscation to thwart the researchers’ forensic tools—such as more sophisticated encryption techniques that would prevent anyone except the target machines from unlocking the payload or even identifying that Stuxnet was targeting Siemens Step 7 software and PLCs. Stuxnet also used weak encryption and a standard protocol to communicate with its command-and-control servers instead of custom-written ones that would have made it more difficult for researchers to establish their sinkhole and read the malware’s traffic.

Cryptographer Nate Lawson’s comments dripped with disdain when he wrote in a blog post that Stuxnet’s authors “should be embarrassed at their amateur approach to hiding the payload” and their use of outmoded
methods that criminal hackers had long since surpassed. “I really hope it wasn’t written by the USA,” he wrote, “because I’d like to think our elite cyberweapon developers at least know what Bulgarian teenagers did back in the early 90s.”
⁶
The mix of state-of-the-art tactics and Hacker 101 techniques made Stuxnet seem like a “Frankenstein patchwork” of wellworn methods, others said, rather than the radical skunkworks project of an elite intelligence agency.
⁷

But O’Murchu had a different take on Stuxnet’s inconsistencies. He believed the attackers deliberately used weak encryption and a standard protocol to communicate with the servers because they wanted the data traveling between infected machines and the servers to resemble normal communication without attracting unusual attention. And since communication with the servers was minimal—the malware transmitted only limited information about each infected machine—the attackers didn’t need more advanced encryption to hide it. As for securing the payload better, there may have been limitations that prevented them from using more sophisticated techniques, such as encrypting it with a key derived from extensive and precise configuration data on the targeted machines so that only those machines could unlock it.
⁸
The targeted machines, for example, may not have had the same exact configuration, making it difficult
to use a single payload encryption key, or there may have been concerns that the configuration on the machines could change, rendering such a key useless and preventing the payload from triggering.

Stuxnet’s failings may also have been the consequence of time constraints—perhaps something caused the attackers to launch their code in a rush, resulting in last-minute work that seemed sloppy or amateurish to critics.

But there was another possible explanation for the patchwork of techniques used in the threat—Stuxnet was likely created by different teams of coders with different skills and talents. The malware’s modular nature meant development could have been done by different teams who worked on various parts simultaneously or at different times. O’Murchu estimated it took at least three teams to code all of Stuxnet—an elite, highly skilled tiger team that worked on the payload that targeted the Siemens software and PLCs; a second-tier team responsible for the spreading and installation mechanisms that also unlocked the payload; and a third team, the least skilled of the bunch, that set up the command-and-control servers and handled the encryption and protocol for Stuxnet’s communication. It was possible the division of responsibilities was so well defined and the teams so compartmentalized that they never interacted.

But although each of the teams had varying levels of skill and experience, they were all at least uniform in one thing—none of them had left any clues behind in the code that could be easily used to track them. Or so it seemed.

ATTRIBUTION IS AN
enduring problem when it comes to forensic investigations of hack attacks. Computer attacks can be launched from anywhere in the world and routed through multiple hijacked machines or proxy servers to hide evidence of their source. Unless a hacker is sloppy about hiding his tracks, it’s often not possible to unmask the perpetrator through digital evidence alone.

But sometimes malware writers drop little clues in their code, intentional
or not, that can tell a story about who they are and where they come from, if not identify them outright. Quirky anomalies or footprints left behind in seemingly unrelated viruses or Trojan horses often help forensic investigators tie families of malware together and even trace them to a common author, the way a serial killer’s modus operandi links him to a string of crimes.

Stuxnet’s code was more sterile than the malware Chien and O’Murchu usually saw. But two things about it did stand out.

Chien was sifting through the notes they had taken on Stuxnet’s initial infection dance one day, when something interesting caught his eye—an infection marker that prevented Stuxnet from installing itself on particular machines. Each time Stuxnet encountered a potential new victim, before it began the process of decrypting and unpacking its files, it checked the Windows registry on the machine for a “magic string” composed of a letter and numbers—0x19790509. If it found the string, Stuxnet withdrew from the machine and wouldn’t infect it.

Chien had seen “inoculation values” like this before. Hackers would place them in the registry key of their own computers so that after unleashing attack code in a test environment or in the wild, it wouldn’t come back to bite them by infecting their own machine or any other computers they wanted to protect. Inoculation values could be anything a hacker chose. Generally, they were just random strings of numbers. But this one appeared to be a date—May 9, 1979—with the year listed first, followed by the month and day, a common Unix programming format for dates. Other number strings that appeared in Stuxnet, and that the researchers knew for certain were dates, were written in the same format.

Chien did a quick Google search for the day in question and was only half surprised when one of the results revealed a connection between Israel and Iran. The 1979 date was the day a prominent Iranian Jewish businessman named Habib Elghanian was executed by firing squad in Tehran shortly after the new government had seized power following the Islamic Revolution. Elghanian was a wealthy philanthropist and respected leader of the Iranian Jewish community until he was accused of spying for
Israel and killed. His death marked a turning point in relations between the Jewish community and the Iranian state. For nearly forty years, while Mohammad Reza Shah Pahlavi had been in power, Iranian Jews had enjoyed a fairly amicable relationship with their Muslim neighbors, as did the Islamic nation with the state of Israel. But Elghanian’s execution, just three months after the revolution ousted the shah, was a “Kristallnacht” moment for many Persian Jews, making it clear that life under the new regime would be very different. The event sparked a mass exodus of Jews out of Iran and into Israel and helped fuel hostility between the two nations that persists today.

Was the May date in Stuxnet a “Remember the Alamo” message to Iran from Israel—something like the missives US soldiers sometimes scribbled onto bombs dropped on enemy territory? Or was it an effort by non-Israeli actors to implicate the Jewish state in the attack in order to throw investigators off their trail? Or was it simply a case of Chien having an active imagination and seeing symbols where none existed? All Chien could do was guess.

But then the Symantec team found another tidbit that also had a possible link to Israel, though it required more acrobatic leaps to make the connection. This one involved the words “myrtus” and “guava” that appeared in a file path the attackers left behind in one of the driver files. File paths show the folder and subfolders where a file or document is stored on a computer. The file path for a document called “my résumé” stored in a computer’s Documents folder on the C: drive would look like this—c:\documents\myresume.doc. Sometimes when programmers run source code through a compiler—a tool that translates human-readable programming language into machine-readable binary code—the file path indicating where the programmer had stored the code on his computer gets placed in the compiled binary file. Most malware writers configure their compilers to eliminate the file path, but Stuxnet’s attackers didn’t do this, either by accident or not. The path showed up as b:\myrtus\src\objfre_w2k_x86\i386\guava.pdb in the driver file, indicating that the driver was part of a project the programmer had called “guava,” which was stored on
his computer in a directory named “myrtus.” Myrtus is the genus of a family of plants that includes several species of guava. Was the programmer a botany nut, Chien wondered? Or did it mean something else?

Chien searched further for information about myrtus and found a tangential connection to another prominent event in Jewish history, when Queen Esther helped save the Jews of ancient Persia from massacre in the fourth century BCE. According to the story, Esther was a Jewish woman who was married to the Persian king Ahasherus, though the king did not know she was Jewish. When she learned of a plot being hatched by the king’s prime minister, Haman, to kill all the Jews in the Persian Empire with the king’s approval, she went to the king and exposed her identity, begging the king to save her and her people. The king then had Haman executed instead and allowed the Jews in his empire to battle all the enemies that Haman had amassed for their slaughter, resulting in a victory for the Jews and 75,000 of their enemies dead. The Purim holiday, celebrated annually by Jewish communities around the world, commemorates this deliverance of Persian Jews from certain death.

On its face, the story appeared to have no relevance to Stuxnet at all. Except that Chien found a possible connection in Esther’s Hebrew name. Before changing her name and becoming the queen of Persia, Esther had been known by the name Hadassah. Hadassah in Hebrew means myrtle, or myrtus.