While some people still speculate that amateurs could be behind Stuxnet, we can rule this possibility out by insights from code analysis. Let’s look at what the code says about the attackers’ capabilities, and remember that we are only talking about the control system related code here, not about the much-hyped multiple zero day MS Windows vulnerabilities. As most people who follow this blog will know, operation Myrtus was a team effort. Here we try to use intelligence gathered by code analysis to focus on the developers of the control system related part, who we will refer to as the Myrtus Control Systems Unit, or CSU. Actually we can even break the CSU further down to different sub-units, which we call CSU-GEN, CSU-315, and CSU-417. The first sub-unit we focus on, CSU-GEN, was tasked with the generic exploitation of features of the Siemens automation products (WinCC, Simatic Manager, S7). Their job was to make it possible for arbitrary ladder logic, developed by CSU-315 and CSU-417, to be executed on the controllers. The product knowledge demonstrated by CSU-GEN is listed below, along with remarks:
1. WinCC default database password. This was the first discovered control system related exploit in the Stuxnet saga. Although not published, the password was available in the community; it doesn’t say much about the attackers.
2. Internals of Step7 project structure, exploitable to have rogue code executed by Simatic Manager. This information is extremely difficult to reverse engineer.
3. Internals of WinCC project structure, exploitable to have rogue code executed by WinCC. Very hard to reverse engineer.
4. Functional knowledge of the s7otbxdx.dll that is used both by WinCC and Simatic Manager. Easy to reverse engineer, given you have good product knowledge and a suitable test environment.
5. Knowledge of s7otbxdx.dll API calls along with parameters. As with any DLL, its exported functions can be determined easily. Understanding the behavior of these undocumented functions is another thing. The most difficult part is to get parameters straight – this is very difficult to re-engineer reliably.
6. Injecting code at the beginning of an operational block (OB). This is one of the most lucid aspects of Stuxnet as it had never been demonstrated before. Reverse engineering therefore was not possible; it took a very good understanding of the product to invent and implement this exploit.
7. Disabling alarms (cycle time monitoring in this case) by writing an EB instruction to the respective operation block. Easy to figure out.
8. Hooking S7 system functions, DP_RECV in this case. Again, reverse engineering was not possible as it had never been demonstrated before. Few people with a very good understanding of Step7 knew that it could be done.
9. System data block (SDB) interpretation. As part of its fingerprinting, Stuxnet checks SDB content. This is unpublished information and extremely difficult to reverse engineer.
That’s quite impressive knowledge, with some of it almost impossible to re-engineer within a reasonable amount of time and normal budgets for test equipment. It matches the idea of unlimited resources that we have already got from the performance of other Stuxnet units. Since such an attack has never been seen before, it must even be suspected that CSU-GEN consisted of at least two people. If you invent such a sophisticated attack plan without precedence, you want someone to discuss with; someone who challenges your tactics to make sure they have a chance in the real world, in an environment that you don’t have physical access to.
The sole purpose of CSU-GEN was to pave the way for CSU-315 and CSU-417, which developed the attack code that actually destroys stuff. While many people still say that Stuxnet attacks control systems, or, even worse: SCADA systems, this is a misconception. Stuxnet attacks physical processes. CSU-315 and CSU-417 figured out and implemented the logic to do just that. What they did has little functional relation to the work of CSU-GEN; they wouldn’t even have to know each other personally. However, both CSU-315 and CSU-417 demonstrate extreme insider knowledge. Both units know:
1. The original Step7 project running on the attacked controllers
2. The exact logical and physical configuration of the attacked installation
3. The exact characteristics of the attacked process, including physical process vulnerabilities
4. How to exploit the physical process vulnerabilities using the control systems given.
In other words, these guys are not undergraduate students, and their background is not in computer games and hacking but in the real world of engineering and material science. Hacking skills wouldn’t have helped them a bit. Comparing the 315 code with the 417 code shows considerable differences in structure and coding, leading us to assume that they were coded by different sub-units. Again we assume that both sub-units consist of at least two people, suggesting that the Myrtus CSU has a size of at least six people who REALLY know their stuff, each of them with multi-year experience in their special area of expertise. Don’t forget that reliability was a major problem for the developers of Stuxnet. They couldn’t do a site acceptance test, and their FAT will have been fairly basic. They had to rely on their skills, on having it figured all out right. They had to get it right in the first attempt.
Since the CSU members threw in all their insider knowledge, they took the risk of being identified easily by crime fighters. While the risk of imprisonment is high for the attackers, there is another form of punishment that they even have to fear more: Having guys with beards, sent from Tehran, knocking at their door sometime. It can be assumed that the attackers would try to mitigate such risk by operating under the cover of an intelligence or military organization. Let’s discuss how this fits into the characteristics of the 5+1+1 nations (with the last +1 representing Israel):
Israel: The best source for intelligence on Iranian nukes (Mossad). They are also good in software security & hacking, but we don’t see the I&C know-how required for Stuxnet’s digital warheads.
USA: Very good capabilities in software security & hacking, plus the engineering know-how in enrichment centrifuges (ORNL) and in things like how to blow up generators. What they lack is the required Siemens automation product know-how.
Germany: Without doubt the best source for I&C know-how, and nuclear expertise extending into Uranium enrichment. Mediocre capabilities in software security & hacking; the days of the legendary Captain Hagbard and his gang are long gone.
Russia: Their background in nukes and power generation is comparable to the US, it’s more than what is needed for Stuxnet. Interestingly, their understanding of German automation products is much better than you would think, as documented here. If you manage to read the boring engineering stuff carefully, you will even find hints that suggest they are in fact integrating TPS and TCS.
China, France, Great Britain: We have not enough intelligence about the capabilities of these countries to make an informed assessment.