Stuxnet logbook, Oct 11 2010, 1100 hours MESZ
Clear and present danger: Open letter to Symantec
Dear Liam O’Murchu,
I have now managed to read your Stuxnet dossier. It’s a solid piece of good technical analysis — except for the summary where you draw dangerously misleading conclusions.
1. You fail to understand that contemporary S7 installations are network connected. The picture of your improvised test equipment tells me that a salesperson was smart enough to sell you an old-style USB-to-MPI adapter, thereby blinding you on the wire. One reason why we were so much quicker in our analysis than you was the simple fact that we could relate debugger breakpoints to decoded wire traffic. Every hacker can — and will — do just that if he wants to figure out how Stuxnet injects code.
2. You fail to understand that the protocol manipulations required for code injection are technically not difficult and cannot be ‘patched’, since they are protocol-conformant. You also seem not to be aware of the fact that anybody who intends to duplicate this part of Stuxnet will find handy tools for free on the Internet.
3. You fail to understand that with the tools mentioned, it is possible to create an attack tool that completely bypasses the vendor’s software and directly attacks PLCs on the network. You fail to understand that in modern installations in the private sector, up to several thousand PLCs per installation are connected to flat networks.
4. You fail to understand that with the basic attack technology copied from Stuxnet, it is even possible to write malicious code that uses PLCs as a launch pad for carried-forward attacks against peer PLCs. You fail to understand that attempts to recover from such attacks require all process network stations to be shut down simultaneously.
5. You fail to understand that potential usage of the attack technology contained in Stuxnet is not limited to APT-style directed attacks with insider knowledge, but can also be used for non-directed attacks in hit-and-run scenarios where the emphasis is on brute-force process disruption, requiring zero insider knowledge.
6. You fail to understand that the hacker underground has been studying control systems for years without any success. You fail to understand that this community will eagerly dismantle Stuxnet as a blueprint for how to cyber-attack installations from the cookie plant next door to power plants.
7. You fail to understand that in typical installations, computer systems with access to above mentioned process networks, either fixed or temporary, cannot be equipped with antivirus software large-scale in short term.
8. You fail to understand that the threat posed by post-Stuxnet malware affects not only power plants, but also other critical infrastructure sectors, military installations, and the private sector across different industries. You fail to understand that with your outlook, you promote the dangerously misleading expectation of complacent asset owners that something like Stuxnet can’t happen to them if they are not high-value military targets.
Langner Communications GmbH
Fossredder 12, D-22359 Hamburg, Germany
~~~ 1988-2008: 20 Years Langner Communications ~~~
Stuxnet logbook, Oct 7 2010, 1430 hours MESZ
We continue our rant against the mainstream media for a short while. It is unbelievable how major publications give room to self-proclaimed security experts who have never come closer than 500 miles to a Stuxnet-infected installation, not to speak about having any clue of what an industrial controller is. We have also learned that the major interest of the media is the question who may be behind Stuxnet, which is usually answered by a mysterious ‘we will never know’ (meaning: I, the journalist, will never know, because I have no desire to figure it out). However, we will know. Stuxnet and its surroundings contain so many traces that sooner or later the organizations behind it will be identified beyond reasonable doubt. Let’s give some hints for those who are really interested in following the traces.
Anyone who develops the most sophisticated piece of malware in history in order to attack specific targets is not playing around. We’re talking about attackers who are really, really serious about achieving mission success. If operation Myrtus had failed because some geniuses in Hamburg, Germany figured out the plot too early, allowing some admins in Iran to defuse the cyber weapon in time, there was a plan B. It would not have been like ‘shoot, we missed it only a week before the blow, now let’s all get drunk quickly and forget about that whole Iranian nukes business’. The only logical plan B would have been an air strike, as had been practiced two years ago. Chances are preparations for such had been visible for someone looking for it in the middle East at the end of August: More tankers and AWACS airborne than usual, fighter jets out of the bunkers with crews strapped in their seats and ready to start engines, CSAR copters deployed etc. Plan B had involved two major players: Israel and the US.
Let’s get back to plan A, a.k.a. Stuxnet, or operation Myrtus. The main factors to analyze who is behind it are, as always, motivation and capability. Determining who has the motivation to cripple Iran’s nuclear program is not a big deal. Israel, for sure. Then look at the 5+1 talks on Iranian nukes that are going on. The US can be found here, too. Now let’s look at the second factor, capability. Some of the different pieces of Stuxnet could be developed by many. Many actors are able to steal digital certificates, or to buy these on the black market. Few actors are able to figure out the four zero-days vulnerabilities and to combine that with the peer-to-peer update functionality. The most telling part, however, is Stuxnet’s digital warhead, the PLC code injections.
When Ralph told a reporter from BBC Worldwide that presently, perhaps ten people on the globe would be able to invent and implement this attack vector, and three of them could be found in Langner’s office, the reporter was smart enough to ask: Did you do it? No, we didn’t. But the guy got the point here. Anyone who is interested in determining the forces behind Stuxnet has a good chance of success in following this trace. As another hint, as far as our experience and crystal ball goes, neither Israel nor the US presently have this capability. If you are a movie buff, think about that old black & white movie with Orson Welles, The third man. ‘There was a third man.’ But his name is not Harry Lime.
Stuxnet logbook, Oct 6 2010, 1130 hours MESZ
Working with the mainstream media is an interesting experience. Some journalists get the point quickly and ask very intelligent questions, others miss the point completely and even quote Ralph incorrectly. However, missing the point is easy in this case as understanding Stuxnet’s attack vector is barely possible with a high level of technical background knowledge. Let’s try to explain Stuxnet to the average computer user.
If Stuxnet was a conventional piece of malware as everybody knows it, it could have done this. It would have checked if a specific word processor is installed on your machine, let’s say Microsoft Word. It would then check if you have a specific printer model installed. Now comes the freaky part. Stuxnet would then check for the presence of one specific document on your hard disk. Not based on the document’s file name, but based on the document’s content. If no match is found, Stuxnet leaves you alone. If Stuxnet finds the document it is looking for and you print out the document, Stuxnet prints its own stuff rather than the original document content. What Stuxnet prints is not random garbage, but completely well-formed sentences in English language.
Let’s get back to the real Stuxnet. As everybody knows who accessed our web site, it is not about changing document content, it is about disrupting a physical process, thereby destroying machinery and equipment that is difficult to replace. If you are infected with Stuxnet but don’t have the specific machinery that Stuxnet is targeting, configured the exact way that Stuxnet is looking for, Stuxnet will ignore you. If you ARE Stuxnet’s target, don’t bother that you could somehow miss Stuxnet’s action. Stuxnet is so aggressive that there is no way to miss it. Others will see Stuxnet’s results, too. Of all the infected systems from all over the world, only two facilities have reported damage caused by Stuxnet: Bushehr’s nuclear power plant, and the uranium enrichment facility in Natanz. NO other infected facility has reported damage.
Now to the threat posed by Stuxnet. Stuxnet’s bullet is fired and hit its designated target. Stuxnet as such will do no more harm. However, Stuxnet will live on, it will be the zombie of our nightmares — for those who are responsible for industrial control systems that run something of any value. Stuxnet shows everybody who is interested HOW to manipulate process control on the PLC level (that’s where all the drives, valves, pumps, sensors etc. are electrically connected to). In order to explain what that means, let’s get back to Stuxnet’s virtual brother in office IT. After studying Stuxnet, we now know how to manipulate documents during printout, great! But why be as picky as the original Stuxnet? We can simply use this technology to print garbage in every document, or randomly in some documents, or only on Tuesdays (‘garbage Tuesday’). We can also use Stuxnet’s technology to slow down the printing process, or to make printing impossible. We can do whatever we want with document printing, without any insider knowledge. Unfortunately, our vendor is unable to fix this problem with a security patch, so we have to sweat it out until we have implemented a solution on our own.
That’s the real threat Stuxnet poses for all of us. It provides a blueprint for aggressive attacks on control systems that can be applied generically. Depending on where you live, such very same control systems may control the power plant that provides your electricity, the water utility that provides your water, the factory where you work in, and the traffic lights you see on your way home. The technology how to manipulate all such systems is now on the street, and don’t be so naive to assume that nobody would take advantage of it. Unfortunately, CERTs and similar organizations don’t have the guts to tell you this, even though it is their obligation and they’re paid for it with taxpayers’ money. However, now you know.
Stuxnet logbook, Oct 4 2010, 1100 hours MESZ
Ralph’s analysis, part 3
Following an interview with me in their Saturday edition, the Financial Times (European edition) contemplates about what will come after Stuxnet, setting the focus on ‘full-scale cyberwarfare in which major infrastructure is destroyed’. The reporters also speculate whether governments, especially those from the major powers, should sign treaties to ban the use of cyberoffensive weapons. I believe such concerns and speculations are misleading. Here’s my take.
First of all, the risk of a cyberwarfare attack is LOWER after Stuxnet than was before. The attackers behind Stuxnet had and used the element of surprise. Few people besides me had EXPECTED such an attack, and therefore defense was non-existent. This has now changed, or at least it should have. Any operator of an installation of strategic value who has NOT reviewed security policy during the last two weeks is doing the same thing that I said about the Bushehr plant: Begging to be cyber-attacked. The good news with critical infrastructure is, this is a manageable task, as the number of installations is comparatively low and the assets are worth significant investments in appropriately upgraded security.
Now let’s look at the second item: The major powers should ban the use of cyberoffensive weapons, similar to weapons of mass destruction. If you think about it long enough, it’s almost ridiculous. PROLIFERATION OF CYBER WEAPON TECHNOLOGY CANNOT BE CONTROLLED. So while governments may sign lengthy treaties addressing the issue, such treaties won’t be countersigned by rogue nation states, terrorists, organized crime, and hackers. Yet all of these will be able to possess and use such weapons soon. With Stuxnet providing a blueprint for a major aggressive cyber strike involving common automation equipment, it is now much easier for others to attempt something similar. It is also important to understand that with Stuxnet being in the wild, obtaining cyber weapons is no longer a question of technological capability, but a question of buying power.
Let’s focus on terrorists, for example. I have speculated that the development of Stuxnet may have cost several million dollars, somewhere in the upper seven-digits. The next cyber weapon will be considerably cheaper, since much of the attack vector and the specifics of how to use automation equipment will simply be copied. So let’s assume the next Stuxnet costs below one million dollar and is for sale on the black market (it’s just a question of time). It is then that some not-so well equipped nation states and well-funded terrorists will grab their checkbooks. Let the street price drop to the five-digit region and organized crime is in. Sabotage with the motivation of extortion will get a commonplace scenario. At this time targets are no longer limited to cricital infrastructure but will especially cover the private sector — a TARGET-RICH AREA where it cannot be assumed that organizations will install countermeasures large scale in a reasonable amount of time.
Last but not least, the average bored hacker will jump on, playing around with the latest control system exploit code in Metasploit, this time targeting industrial controllers, so what. It is then that widespread, non-directed attacks will occur, with the payload being distributed by conventional worms, and the attacker not even knowing, or bothering, whether his malware hit a wastewater facility in Podunk or a cookie plant in Denmark. Complete industry sectors with complex supply chains as in automotive break down due to a simple worm? Even better for bragging rights.
Summing up, my assessment of the threat posed by post-Stuxnet weaponized malware is as follows. Strategic high-value targets are least at risk, because they can be easily identified, are low in number, and justify high investments in countermeasures which should be in the process of being implemented as I write this. The greatest risk is with medium- and low-value targets, with the majority of such targets in the private sector, including production facilities as well as low-tech automated systems such as traffic lights, elevators etc. For such targets, culture shift and significant investments in cyber security countermeasures cannot be expected short-term. However, such targets are low-value only when viewed in isolation. If attacked more or less simultaneously and/or persistently, either coordinated or randomly, they may well cause as much or even more damage to economy and society than an attack on a power plant. After Stuxnet, cyberspace will never be the same.
Stuxnet logbook, Oct 1 2010, 1100 hours MESZ
Things are getting more and more bizarre at the communications front. CERTs are stretching their intellect in efforts to avoid frank talk without saying something provably incorrect. A good example is ICS-CERT’s most recent advisory on the Stuxnet malware from Sep 29, 2010 (www.us-cert.gov/control_systems/pdf/ICSA-10-272-01.pdf). Let’s look at it in detail.
1. The advisory refers to two different test settings: One with Siemens WinCC AND Simatic Manager (referred to as “Step7″ in the advisory) installed, the other with BOTH software products NOT installed. This test setting is incomplete and inappropriate.
2. What’s missing in the test setting? Correct: A P-L-C. As a matter of fact, both WinCC and Simatic Manager don’t do anything meaningful without a PLC attached. Therefore, it is impossible to make any reasonable statement on how Stuxnet may affect both applications with no PLC to talk to. It’s like analyzing the potential effects of a piece of malware on a printer driver with no printer attached.
3. An appropriate test setting for analyzing the Stuxnet malware would also provide for separate PC systems, one hosting the WinCC SCADA software, the other the Simatic Manager engineering software (= development environment). In real-world environments, both applications are rarely used simultaneously on one machine. Since Stuxnet behaves differently in a WinCC and in a Simatic Manager environment, it is mandatory to set up a lab environment with split systems, otherwise one will deliberately restrict analytic options, and traffic from both environments will be cluttered.
4. The advisory fails to mention the fact that an infected installation may interfere with process control if the following conditions are met: a) infected WinCC environment, b) PLC project has data block 890 configured, c) data block 890 exceeds a certain length, d) data block 890 contains the string “hnds” at a certain position. In this case, the compromised DLL will overwrite certain process variables in data block 890. It will do so every five seconds. But on the other hand, this is certainly not observable if no PLC is attached to the WinCC station.
5. The advisory fails to mention the fact that the actual attack routines are embedded in the file s7otbxdx.dll, and that this digital warhead can be defused by simply deleting s7otbxdx.dll and renaming the original DLL from s7otbxsx.dll to s7otbxdx.dll on a compromised system. Why explain in great length all the funny files that Stuxnet installs and not saying how to simply pull the plug by deleting one file?
6. The advisory fails to mention the fact that the main attack sequence of Stuxnet is executed not in the Windows environment but on the controllers.
7. The advisory fails to mention the fact that Stuxnet injects rogue ladder logic into PLCs. Even though this is proven in lab experiment and undeniable, this fact seems to be treated by some as a dare confession.
8. The advisory fails to mention the fact that the most significant threat posed by Stuxnet is not Stuxnet itself but the possibility that attack techniques used by Stuxnet, most prominently injecting rogue ladder logic into PLCs, will be copied and will get available within hacker toolkits. The advisory contains zero advice on how to address this threat.
What do we make out of this? Send suggestions to email@example.com.
Stuxnet logbook, Sep 29 2010, 1100 hours MESZ
Historical document: Ralph informs Joe Weiss what Stuxnet is. Note the date of the email.
Stuxnet logbook, Sep 28 2010, 1100 hours MESZ
While it feels good to be proven right, we would have wished it had happened somewhen later. In respect to the latest news from Iran we recommend to start IMMEDIATELY with developing countermeasures against post-Stuxnet malware. We suggest to follow Melissa Hathaway’s advice as expressed in her NYT interview (www.nytimes.com/2010/09/27/technology/27virus.html):
“Proliferation is a real problem, and no country is prepared to deal with it,” said Melissa Hathaway, a former United States national cybersecurity coordinator. The widespread availability of the attack techniques revealed by the software has set off alarms among industrial control specialists, she said: “All of these guys are scared to death. We have about 90 days to fix this before some hacker begins using it.”
Melissa had been briefed by Ralph on Stuxnet last week in Washington. Ralph agrees with Melissa’s assessment 100%.
Mobilize your A-teams.
Stuxnet logbook, Sep 23 2010, 1240 hours MESZ
For consulting requests on how to address the threat of post-Stuxnet malware in your organization please contact firstname.lastname@example.org.
Stuxnet logbook, Sep 22 2010, 0940 hours MESZ
INL replicates lab findings.
Stuxnet logbook, Sep 21 2010, 1200 hours MESZ
Ralph’s analysis, part 2
Many aspects of Stuxnet are so completely different from malware as we know it that it’s only natural that so many hard-working experts at some point in the analysis ended in frustration. The best way to approach Stuxnet is not to think of it as a piece of malware like Sasser or Zotob, but to think of it as part of an operation — operation myrtus. Operation myrtus can be broken down into three major stages: Preparation, infiltration, and execution.
Stage 1, preparation:
- Assemble team, consisting of multiple units (intel, covert ops, exploit writers, process engineers, control system engineers, product specialists, military liaison)
- Assemble development & test lab, including process model
- Do intel on target specifics, including identification of key people for initial infiltration
- Steal digital certificates
Stage 2, infiltration:
- Initial infiltration using USB sticks, perhaps using contractor’s comprised web presence
- Weapon spreads locally via USB stick sharing, shared folders, printer spoolers
- Contact to command & control servers for updates, and for evidence of compromise
- Update local peers by using embedded peer-to-peer networking
- shut down CC servers
Stage 3, execution:
- Check controller configuration
- Identify individual target controllers
- Load rogue ladder logic
- Hide rogue ladder logic from control system engineers
- Check PROCESS condition
- Activate attack sequence
What this shows is that the 0day exploits were only of temporary use during the infiltration stage. Quite a luxury for such sophisticated exploits! After the weapon was in place, the main attack is executed on the controllers. At that point, where the rogue ladder logic is executed, it’s all solid, reliable engineering — attack engineering.
Stuxnet logbook, Sep 19 2010, 1430 hours MESZ
Please understand that the German office will not be able to answer interview requests. Ralph about to board plane to DC soon, rest of the crew is busy feeding ICS-CERT with relevant information.
Stuxnet logbook, Sep 17 2010, 2300 hours MESZ
Recommendations for asset owners:
Define and enforce a high security level for your engineering stations, ESPECIALLY the mobile ones.
Do not allow staff to use these stations for private purposes (surfing on the Internet, using media player etc.).
Start securing these systems with whitelisting solutions.
Define and enforce a high security level for contractors that have network access to your systems either locally or remote.
Start removing shared folders.
Remove critical systems from the network if the network connection is used only for convenience.
Review your security policies for accessing systems with VNC and similar RDP products.
Develop a zoning concept for your network and implement it.
Use PLC version control systems.
Do not assume an attack could never originate from a PLC.
Enforce security policy even during commissioning.
Recommendations for vendors:
Test and certify whitelisting solutions for your products.
Make your products configurable so that they do not require file shares.
Arrange your next SCADA product version in a way that it is not scrambled over a myriad of DLLs.
Start developing product versions that support different channels for programming and SCADA.
Start developing product versions that support digital signatures for ladder logic and PLC firmware.
Recommendations for security companies:
Release whitelisting product versions for obsolete OS versions.
Release standalone versions of your whitelisting products that do not require a central administration server.
Stuxnet logbook, Sep 17 2010, 1500 hours MESZ
Press release – for immediate release
Langner sees increased threat level as Stuxnet analysis progresses
Ralph Langner, who successfully analyzed that Stuxnet is a directed attack against industrial control systems sees an increased threat level as the analysis of Stuxnet progresses. Langner points out that not only security researchers will analyse Stuxnet but also the underground. The analysis that Langner has conducted shows that it is not technically difficult to inject rogue ladder logic into PLC programs. It is important to understand that this vulnerability cannot be considered a bug, either technically or legally, so it should not be expected that vendors would be able to release a “patch”. Langner expects that exploit code for this vulnerability within several months in the known frameworks such as Metasploit. While Langner does not assume to see an attack as sophisticated as Stuxnet soon, he points out that the Stuxnet story will raise a lot of attention in the hacker community where people may now start to try using the attack vector for much more trivial motivations than we must assume for the Stuxnet writers. Langner suggests equipment vendors, asset owners and integrators start developing strategies to cope with this scenario quickly.
Ralph’s theory — completely speculative from here
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 (http://www.upi.com/News_Photos/Features/The-Nuclear-Issue-in-Iran/1581/2/) 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.
Stuxnet busters, from left to right: Ralf, Andreas, Ralph.
As can be seen, these guys are (almost) serious about what they’re doing.
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.
Stuxnet logbook, Sep 16 2010, 1200 hours MESZ
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.
Stuxnet is a directed attack — ‘hack of the century’
Hamburg, Sep 13, 2010
German IACS security researcher Ralph Langner has successfully analyzed the Stuxnet malware that appeared to be a miracle. Stuxnet is a directed attack against a specific control system installation. Langner will disclose details, including forensic evidence, next week at Joe Weiss’ conference in Rockville.
- EU calls Stuxnet ‘paradigm shift’ as U.S. responds more mildly (news.cnet.com)
- EU calls Stuxnet ‘paradigm shift’ as U.S. responds more mildly (news.cnet.com)
- Stuxnet (schneier.com)
- Stuxnet: Fact vs. theory (news.cnet.com)
- Windows Users Still Under Attack From Stuxnet, Halo, and Zeus (techrights.org)
- Stuxnet: Fact vs. theory (news.cnet.com)