Today, Kim Zetter released her book, “Countdown to Zero Day”. The book recounts the story of Stuxnet’s attempt to sabotage Iran’s uranium enrichment program. The work that Eric Chien, Nicolas Falliere, and I carried out is featured in the book. During the process of writing the book, Kim interviewed us on many occasions and we were lucky enough to be able to review an advanced copy.
Figure 1. Kim Zetter’s new book, “Countdown to Zero Day”
In chapter 17 of the book, “The Mystery of the Centrifuges”, Kim talks about how Stuxnet infections began in Iran, identifying several companies where she believes the infections originated.
“To get their weapon into the plant, the attackers launched an offensive against four companies. All of the companies were involved in industrial control processing of some sort, either manufacturing products or assembling components or installing industrial control systems. They were likely chosen because they had some connection to Natanz as contractors and provided a gateway through which to pass Stuxnet to Natanz through infected employees.”
This is a different story from the one that David Sanger’s sources painted in his New York Times article and in his book “Confront and Conceal”. Sanger states:
“. . . an element of the program accidentally became public in the summer of 2010 because of a programming error that allowed [Stuxnet] to escape Iran’s Natanz plant and sent it around the world on the Internet.”
So which is right? Did Stuxnet originate outside of Natanz and spread all over the world with the hopes of eventually entering Natanz? Or did Stuxnet start inside of Natanz and accidentally escape due to a programming error?
Tracing the spread of Stuxnet
We actually covered how Stuxnet originated in a blog post in February 2011. Let’s start with whether it is possible to track Stuxnet’s origin back to specific companies in Iran.
Normally, it would not be possible to state with 100 percent accuracy where an infection started. However, in the case of Stuxnet version 1.x, the attackers left a trail behind which allows analysts to trace the specific genealogy of each sample. This is possible because every time Stuxnet executes, it records some information about the computer it is executing on and stores that within the executable file itself, creating a new unique executable in the process. As a result, every unique executable contains an embedded and ordered list showing the computers it has previously infected. As Stuxnet spreads from computer to computer, the list grows and grows. By examining this list, we can trace back from one entry to the next, extracting computer information from each entry. These are the breadcrumbs we can follow to get back to the original compromised computers.
What do the breadcrumbs look like?
Each entry in the list looks like the data shown in the following image. Although this may not make sense at first, by analyzing the code within Stuxnet, we can find out what each number represents.
Figure 2. List entry of compromised computers
Among other information, the computer name, domain name, date, and IP address are stored in each entry. We can extract information from previous data, which is shown in the following image.
Figure 3. Details stored in each entry
By looking at each entry in the list embedded in any sample, we can see how the threat moved from one computer to the next. The real computer names and domains have been anonymized.
Figure 4. List of compromised computers from one sample shows how Stuxnet spread
In the previous image, we can see Stuxnet’s path through the first six compromised computers. This information was extracted from one sample. When we look at the first six infections from a different sample, we get the following path.
Figure 5. List of compromised computers from another sample shows different movement pattern
The two samples’ first four entries are the same but after that, the samples moved in two different directions. At the fifth step, one sample compromised a computer on the WORKGROUP domain while the other sample compromised a computer on the MSHOME network.
Using this data, we graphed the spread of Stuxnet infections. See pages eight to ten of our Stuxnet whitepaper for more details.
Figure 6. Spread of Stuxnet infections
Many computers and domains used generic names that do not provide much insight into the targets. For example, WORKGROUP and MSHOME—two default workgroup names—appear very frequently in the breadcrumb logs. However, we were able to identify all of the places where Stuxnet infections originated, and they were all in Iran.
The verdict
So did Stuxnet spread into Natanz as Zetter says or escape out of Natanz as Sanger reported?
Based on the analysis of the breadcrumb log files, every Stuxnet sample we have ever seen originated outside of Natanz. In fact, as Kim Zetter states, every sample can be traced back to specific companies involved in industrial control systems-type work.
This technical proof shows that Stuxnet did not escape from Natanz to infect outside companies but instead spread into Natanz.
Unfortunately, these breadcrumbs are only available for Stuxnet version 1.x. There was at least one previous version of Stuxnet released, version 0.5 (which we analyzed in our whitepaper), for which this infection path information is not available.
While version 0.5, which did not spread as aggressively as version 1.x, could have been planted inside Natanz and then spread outwards, this version was no longer operational during the conversation timeframe (the summer of 2010) outlined in the Sanger article. As a result, it is unlikely the 0.5 version is the subject of his article.
To make up your own mind, you should read Kim Zetter’s “Countdown to Zero Day”, which is out today.