With the forensics we now have it is evident and provable that Stuxnet is a directed sabotage attack involving heavy insider knowledge. Here is what everybody needs to know right now.

Fact: As we have published earlier, Stuxnet is fingerprinting its target by checking data block 890. This occurs periodically every five seconds out of the WinCC environment. Based on the conditional check in code that you can see above, information in DB 890 is manipulated by Stuxnet.

Interpretation: We assume that DB 890 is part of the original attacked application. We assume that the second DWORD of 890 points to a process variable. We assume that this process variable belongs to a slow running process because it is checked by Stuxnet only every five seconds.

Fact: Another fingerprint is DB 8062. Check for the presence of DB 8062 in your project.

Fact: Stuxnet intercepts code from Simatic Manager that is loaded to the PLC. Based on a conditional check, original code for OB 35 is manipulated during the transmission. If the condition matches, Stuxnet injects Step7 code into OB 35 that is executed on the PLC every time that OB 35 is called. OB 35 is the 100 ms timer in the S7 operating environment. The Step7 code that Stuxnet injects calls FC 1874. Depending on the return code of FC 1874, original code is either called or skipped. The return code for this condition is DEADF007 (see code snipplet).

Interpretation: Stuxnet manipulates a fast running process. Based on process conditions, the original code that controls this fast running process will no longer be executed. (Some people will now want to have their process engineers explain what the DEADF could mean.) After the original code is no longer executed, we can expect that something will blow up soon. Something big.

Ralph’s analysis

Now that everybody is getting the picture let’s try to make sense out of the findings. What do they tell us about the attack, the attackers, and the target?

1. This is sabotage. What we see is the manipulation of one specific process. The manipulations are hidden from the operators and maintenance engineers (we have the intercepts identified).

2. The attack involves heavy insider knowledge.

3. The attack combines an awful lot of skills — just think about the multiple 0day vulnerabilities, the stolen certificates etc. This was assembled by a highly qualified team of experts, involving some with specific control system expertise. This is not some hacker sitting in the basement of his parents house. To me, it seems that the resources needed to stage this attack point to a nation state.

4. The target must be of extremely high value to the attacker.

5. The forensics that we are getting will ultimately point clearly to the attacked process — and to the attackers. The attackers must know this. My conclusion is, they don’t care. They don’t fear going to jail.

6. Getting the forensics done is only a matter of time. Stuxnet is going to be the best studied piece of malware in history. We will even be able to do process forensics in the lab. Again, the attacker must know this. Therefore, the whole attack only makes sense within a very limited timeframe. After Stuxnet is analzyed, the attack won’t work any more. It’s a one-shot weapon. So we can conclude that the planned time of attack isn’t somewhen next year. I must assume that the attack did already take place. I am also assuming that it was successful. So let’s check where something blew up recently.

Ralph’s theory — completely speculative from here

Stuxnet busters, from left to right:
Ralf, Andreas, Ralph. As can be seen, these
guys are (almost) serious about what
they’re doing.

It is hard to ignore the fact that the highest number of infections seems to be in Iran. Can we think of any reasonable target that would match the scenario? Yes, we can. Look at the Iranian nuclear program. Strange — they are presently having some technical difficulties down there in Bushehr. There also seem to be indications that the people in Bushehr don’t seem to be overly concerned about cyber security. When I saw this screenshot last year I thought, these guys seem to be begging to be attacked. If the picture is authentic, which I have no means of verifying, it suggests that approximately one and a half year before scheduled going operational of a nuke plant they’re playing around with software that is not properly licensed and configured. I have never seen anything like that even in the smallest cookie plant. The pure fact that the relevant authorities did not seem to make efforts to get this off the web suggests to me that they don’t understand (and therefore don’t worry about) the deeper message that this tells.

Now you may ask, what about the many other infections in India, Indonesia, Pakistan etc. Strange for such a directed attack. Than, on the other hand, probably not. Check who comissions the Bushehr plant. It’s a Russian integrator that also has business in some of the countries where we see high infection rates. What we also see is that this company too doesn’t seem to be overly concerned about IT security. As I am writing this, they’re having a compromised web site (http://www.atomstroyexport.com/index-e.htm) that tries to download stuff from a malware site that had been shut down more than two years ago (www.bubamubaches.info). So we’re talking about a company in nukes that seems to be running a compromised web presence for over two years? Strange.

I could give some other hints that have a smell for me but I think other researchers may be able to do a much better job on checking the validity of all this completely non-technical stuff. The one last bit of information that makes some sense for me is the clue that the attackers left in the code, as the fellows from Symantec pointed out — use your own imagination because you will think I’m completely nuts when I tell you my idea.

Welcome to cyberwar.