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

Nico Falliere was hunched over his desk on the eighth floor of the forty-story Tour Egée, a triangular glass-and-concrete building in the La Défense business district of Paris. Outside, a grim forest of office towers rose in front of his window, obscuring his view of the pigeons and summer tourists ambling toward the steps of La Grande Arche. But Falliere wasn’t focused on the view. He was focused intently on making his first foray into Stuxnet’s complicated payload.

It was early in August 2010, a mere two weeks into the Symantec team’s analysis of Stuxnet, before Chien and O’Murchu discovered the unprecedented number of zero days that were hiding in the worm. During these first two weeks, Falliere had been working with O’Murchu to analyze the malware’s large Windows .DLL, but he knew Stuxnet’s real secrets lay in its payload, and he was anxious to get at them.

He had just returned from lunch with friends when he began digging through the payload files, separating each one out and trying to understand its format and structure. He noticed that one of them was a .DLL file with a familiar name. The Symantec researchers had by this point obtained copies of the Siemens Step 7 software, so Falliere scrolled through
the Step 7 program files installed on his test system. It didn’t take long to find what he was looking for—a Siemens Step 7 .DLL that had the same name as the Stuxnet file. Hmm, he thought, that’s interesting.

He quickly determined that anytime Stuxnet found itself on a computer with the Siemens Step 7 or WinCC software installed, it unpacked its .DLL file with the matching name from inside its larger Windows .DLL and decrypted it.

Falliere used the key embedded in the malware to decrypt the .DLL and found that it contained all of the same functionality as the legitimate Step 7 .DLL. But it also contained some suspicious code that included commands like “write” and “read.” Falliere had seen enough malware in his career to know exactly what he was looking at—Stuxnet’s Step 7 .DLL was acting as a rootkit, lurking on the system silently, waiting to hijack, or hook, these functions anytime the system attempted to read or write code blocks to or from the targeted PLCs. Similar to the rootkit in the missile portion of Stuxnet, this one was hooking the read function to hide something that Sutxnet was doing to the PLCs. It was the first time, as far as he knew, that anyone had created a rootkit for an industrial control system. It was another first in the growing list of Stuxnet firsts.

Falliere couldn’t tell if Stuxnet’s rogue .DLL was hooking the read function to simply monitor the PLCs passively and gather intelligence about their operations, or if it had more sinister aims in mind. But the fact that it was also intercepting the “write” function suggested it was probably the latter and was attempting to halt the operation of the PLCs or change their operation in some way. He glanced at his watch and noted that it was around five a.m. in California—too early to call Chien—so he decided to keep digging.

He continued for several more hours, and when he had all the pieces of the puzzle he needed—it was exactly what he’d suspected. Stuxnet was indeed intercepting commands passing from the Siemens .DLL to the PLCs and replacing them with its own. He couldn’t say for sure what it was instructing the PLC to do—he couldn’t find the code blocks that Stuxnet
injected into the PLC—but he was pretty sure it wasn’t good. By now it was nine a.m. in California, so he picked up the phone and called Chien.

Normally the two of them spoke once a week to exchange a quick update about whatever Falliere was working on; the calls were efficient and to-the-point and lasted no more than a few minutes. But this time Falliere recounted everything he had found in detail. Chien listened intently, amazed at what he heard. The attack kept getting more and more complex. Every corner they turned with Stuxnet they found a new surprise.

Chien agreed that Falliere should drop everything to find the code blocks that Stuxnet injected into the PLC. They also decided Falliere should make a brief announcement on their blog about the PLC rootkit. The rest of the information they would keep under wraps, for the time being, until Falliere could determine the nature of what Stuxnet was injecting into the PLC.

That night on the Métro on his way home from work, Falliere was charged with nervous energy. For four years he’d been deconstructing viruses and worms and had seen so many malicious programs during that time that it was hard to get excited about them anymore. But this one was different. An attack on a PLC was unprecedented and had the potential to usher in an entirely new breed of malicious attacks.

Despite his excitement, he knew the road ahead was filled with hurdles. The Siemens .DLL that Stuxnet replaced was huge, and the structure of the Step 7 software and the PLCs it controlled was largely undocumented. Falliere and Chien were completely in the dark about how the system worked, and the technical challenges of deciphering the payload were going to be formidable. What’s more, there was no guarantee they’d even crack it. There were so many things Falliere didn’t know at this point. But one thing he did know was that he was in for a long and exhausting ride.

FALLIERE WAS TWENTY-EIGHT,
with the dark, Gallic looks of someone who seemed like he’d be more at home DJing trance music in an
underground Paris nightclub than poring over reams of printed computer code during a commute on the Métro. In reality, he was fairly shy and reserved, and sifting through dense computer code was in fact a much bigger draw to him than spending sweaty nights in a throbbing club.

Falliere was a master reverse-engineer who specialized in deep-dive analysis of malicious code. Reverse-engineering is a bit of a dark art that involves taking the binary language of ones and zeroes that a computer can read and translating it back to a programming language that humans can read. It requires a lot of intense focus and skill, particularly with code as complex as Stuxnet. But Falliere didn’t mind. The more complicated the code, the more satisfying it was when he finally cracked it.

He first honed his skills as a teenager in France breaking “crackme” files—code games that programmers wrote for one another to test their reverse-engineering skills. Coders would write small programs coated in an encrypted shell, and reverse-engineers would have to crack it open and bypass other protections to unearth the secret message hidden inside, then send it back to the author to prove that they had solved it. Viruses and worms were just another type of crackme file in one sense, though some were more sophisticated than others. The only difference now was that Falliere got paid to crack them.

Falliere was born and raised near Toulouse in southern France, home of the Airbus aerospace corporation and a center for satellite technology. In a region dominated by engineers, aeronautical and otherwise, it seemed natural that Falliere would be drawn to technology. But his early influences actually veered toward the mechanical. His father was an automobile mechanic who owned and operated his own garage. Falliere’s introduction to computers in high school, however, led him in a different direction—to study computer science at the National Institute for Applied Sciences in France. The spread of the prolific Code Red worm in 2001, which struck more than 700,000 machines, got him interested in computer security. While still in college, he wrote several security articles for a small French technical magazine, as well as a paper for SecurityFocus, a security website
that Symantec owned.
¹
In late 2005 while doing his master’s program in computer science, he was told he needed a six-month internship under his belt to complete it. So he reached out to his contacts at SecurityFocus, who referred him to Chien. The timing couldn’t have been more fortuitous. Symantec was still in the midst of its Dublin hiring spree, and Chien was desperate to find experienced reverse-engineers. He told Falliere that rather than a six-month internship at Symantec he could offer him a full-time job instead. “How much do you want to make?” he asked Falliere.

“I don’t need any money,” Falliere told him. “Just an internship.”

“Are you crazy?” Chien replied. “I’ll send you an offer in an e-mail. Just accept it.”

A few weeks later, Falliere was settled in Dublin. He adjusted to his new life fairly quickly, but after two years of constant plane rides back to France to see his girlfriend, he asked for a transfer to Paris, where Symantec had a sales and marketing office. He turned out to be the only technical person in the office, which left him feeling isolated at times, but also helped focus him on his work.

His desk, in an office shared with two colleagues, was an orchestrated mess of technical papers and books scattered around a test machine that he used to run malware and a laptop containing the debugger software that he used to analyze code. A cylinder-shaped Rubik’s puzzle was the only personal item on the desk, which he fingered like worry beads whenever he butted up against an unwieldy patch of code that resisted cracking.

Though Falliere was a whiz at reverse-engineering, he was actually doing very little of it when Stuxnet came along. Over time, he’d become Symantec’s de-facto tool guy, whipping together programs and tools to make deciphering malware more efficient for other analysts. The job snuck up on him over time. He began by tweaking forensic tools for himself that he found clunky and inefficient, then began doing it for colleagues as well, even creating new tools after they began submitting requests. Eventually, he was spending more time working on tools than deciphering code. He
only jumped on the occasional malware threat if Chien made a special request, which he did in the case of Stuxnet.

FALLIERE BEGAN HIS
analysis of the payload by studying the Siemens Step 7 software. The Step 7 software that Stuxnet attacked was Siemens’s proprietary application for programming its S7 line of PLCs. It ran on top of the Windows operating system and allowed programmers to write and compile commands, or blocks of code, for the company’s PLCs. The system wasn’t complete without the Simatic WinCC program, a visualization tool used for monitoring the PLCs and the processes they controlled. PLCs, connected to monitoring stations via a facility’s production network, were in a constant state of chatter with the machines, sending frequent status reports and updates to give operators a real-time view of whatever equipment and operations the PLC controlled. The Siemens .DLL was central to both the Step 7 and WinCC programs, serving as middleman to create commands for the PLCs or receive status reports from them. That’s where Stuxnet’s rogue .DLL came in. It did everything the real .DLL was designed to do, and more.

To understand how the doppelgänger .DLL worked, Falliere had to first understand how the Step 7 system and the legitimate .DLL worked. He searched online for experts to consult, and even thought about reaching out to Siemens for help, but he didn’t know whom to call there. The Step 7 .DLL was just one in a galaxy of .DLLs the Siemens software used, and to locate the two or three programmers behind the code who knew it well enough to help would take just as long as it would take for him to figure it out on his own. And in the end, there was a certain amount of pride to be had in cracking it himself.

To reverse the .DLL files—the original and the doppelgänger—Falliere opened them in a disassembler, a tool designed for translating binary code into assembly language, which was one step back from binary. The disassembler allowed him to add notations and comments to the code or rearrange sections to make it easier to read. He worked on small bits
of code at a time, labeling each with a description of the function it performed as he went along.

As researchers typically did when examining complex malware like this, Falliere combined static analysis (viewing the code on-screen in a disassembler/debugger) with dynamic analysis (observing it in action on a test system, using the debugger to stop and start the action so he could match specific parts of the code with the effect it was having on the test machine). The process could be excruciatingly slow under the best of circumstances, since it required jumping back and forth between the two machines, but it was all the more difficult with Stuxnet due to its size and complexity.

It took two weeks of documenting every action the .DLL took before Falliere finally confirmed what he’d suspected all along, that Stuxnet was kidnapping the Siemens .DLL and putting the doppelgänger in its place to hijack the system. It did this by changing the name of the Siemens .DLL from s7otbxdx.DLL to s7otbxsx.DLL and installing the rogue .DLL with the original’s name in its place, essentially stealing its identity. Then when the system called up the Siemens .DLL to perform any action, the malicious .DLL answered instead.

Once the rogue .DLL was in place, what it did was quite remarkable.

Whenever an engineer tried to send commands to a PLC, Stuxnet made sure its own malicious command code got sent and executed instead. But it didn’t just overwrite the original commands in a simple swap. Stuxnet increased the size of the code block and slipped its malicious code in at the front end. Then to make sure its malicious commands got activated instead of the legitimate ones, Stuxnet also hooked a core block of code on the PLC that was responsible for reading and executing commands. A lot of knowledge and skill were required to inject the code seamlessly in this way without “bricking” the PLCs (that is, causing them to seize up or become nonfunctional), but the attackers pulled it off beautifully.

The second part of the attack was even more ingenious. Before Stuxnet’s malicious commands went into action, the malware sat patiently on the PLC for about two weeks, sometimes longer, recording legitimate operations
as the controller sent status reports back to monitoring stations. Then when Stuxnet’s malicious commands leapt into action, the malware replayed the recorded data back to operators to blind them to anything amiss on the machines—like a Hollywood heist film where the thieves insert a looped video clip into surveillance camera feeds. While Stuxnet sabotaged the PLC, it also disabled automated digital alarms to prevent safety systems from kicking in and halting whatever process the PLC was controlling if it sensed the equipment was entering a danger zone. Stuxnet did this by altering blocks of code known as OB35 that were part of the PLC’s safety system. These were used to monitor critical operations, such as the speed of a turbine the PLC was controlling. The blocks were generated every 100 milliseconds by the PLC so that safety systems could kick in quickly if a turbine began spinning out of control or something else went wrong, allowing the system or an operator to set off a kill switch and initiate a shutdown. But with Stuxnet modifying the data the safety system relied on, the system was blind to dangerous conditions and never had a chance to act.
²