|Home||Switchboard||Unix Administration||Red Hat||TCP/IP Networks||Neoliberalism||Toxic Managers|
May the source be with you, but remember the KISS principle ;-)
Bigger doesn't imply better. Bigger often is a sign of obesity, of lost control, of overcomplexity, of cancerous cells
Copyright: Dr. Nikolai Bezroukov 1994-2013. Unpublished notes. Version 0.80.October, 2013
Contents : Foreword : Ch01 : Ch02 : Ch03 : Ch04 : Ch05 : Ch06 : Ch07 : Ch08 : Ch09 : Ch10 : Ch11 : Ch12 : Ch13
Chapter 13: Destructive Viruses and Trojans
Stuxnet is malware that completely changed our understanding of this area. It was the first malware signed with Microsoft keys. Stuxnet demonstrated the ways in which critical infrastructure can be attacked and removed any taboo that existed before that might have prevented such attacks. One of the real "innovations" of Stuxnet was that it not only infected windows machines, but also PLCs by a dedicated PLC rootkit (en.wikipedia.org/.../Stuxnet). It also represents the first example of state-written or state sponsored malware.
As Ian Wallace noted in The National Interest (Commentary Militarizing the Internet, July 17, 2013)
The Snowden leaks have brought Stuxnet, the U.S.-Israeli program allegedly used to attack Iranian computer systems, back into public debate—and reminded us that the real damage of the Snowden revelations will be international. President Obama looks set to weather the domestic storm, and after a round of outrage—some real, some feigned—the diplomatic fallout from the various spying allegations will eventually subside. Susan Rice, the new national-security adviser, might have been a little optimistic when she said, “I don’t think the diplomatic consequences, at least in the foreseeable future, are that significant.” She will have some difficult conversations with European leaders, annoyed at the reigniting of previous domestic controversies about the privacy implications of U.S. counterterrorism policy. But other priorities, including the economy, will ensure that U.S.-European relations remain firm. So it is difficult to imagine she will lose much sleep over Chinese complaints on the subject of cyber espionage.
Yet the perception that the United States has become a danger to the global internet is a cause for concern. In their understandable anger at the considerable damage Snowden has done (in the near term at the very least) to the operations of NSA and their allies, U.S. security officials should not lose sight of this fact. Snowden’s claims build on the Stuxnet revelations. In doing so, they reinforce an impression of overbearing U.S. cyberpower (military and commercial) being used irresponsibly. That is strikingly at odds with the U.S. self-image as a standard bearer of internet freedom and “borderless” exchange, but it is a view that resonates around the world.
At the most basic level, that sense of double standards legitimizes bad behavior directed back at the United States. Many in the U.S. private sector believe that the distributed denial of service attacks that they are suffering from Iranian-backed groups are a response to Stuxnet. So you can imagine how little sympathy such attacks elicit in parts of the world where there are already high levels of anti-U.S. sentiment. More practically, Stuxnet demonstrated the ways in which critical infrastructure can be attacked and removed any taboo that existed that might have prevented it. Not surprisingly, many researchers fear that it is only a matter of time before this country suffers a taste of its own medicine.
But a more subtle and damaging effect relates to how the internet operates. The United States and its allies are currently engaged in a low-profile but highly consequential tussle for the future of the internet. Although out of day-to-day public view, this matters, as the internet now underpins the global economy. While it is self-evident to us that minimizing government involvement is precisely what ensures the success of the internet, it is equally clear to authoritarian states like Russia and China that the internet (including the content it carries) must to be controlled. This latter view is exemplified by the desire of Russia, China and others to see the International Telecommunications Union, an adopted member of the United Nations family, expand its role into setting international rules for the internet.
Despite alarmist concerns to the contrary, there is no practical way in which the United Nations (or any other organization) could “take over” the internet. But if the United States starts to be seen as a danger to others, new barriers will emerge and everyone will lose.
Good introduction into Stuxnet saga can be found at How Stuxnet Came Back to Haunt the U.S.
Q. What is Stuxnet, anyway?
Stuxnet first made headlines when it burrowed into computers that controlled uranium centrifuges in Iran's renegade nuclear program. Its self-replicating computer code is usually transmitted on flash drives anyone can stick into a computer. Once activated, the virus made Iran's centrifuges spin out of control while making technicians think everything was working normally. Think of a scene in a bank heist movie where the robbers loop old security camera footage while they sneak into the vault.
Q. Who created it?
Whoever knows the answer to this isn't telling, but if cybersecurity researchers, the Iranian government and vocal Internet users are to be believed, the two prime suspects are the U.S. and Israeli governments.
Q. How does it work?
Stuxnet seeks out little gray computers called programmable logic controllers, or PLCs. The size and shape of a carton of cigarettes, PLCs are used in industrial settings from pretzel factories to nuclear power plants. Unfortunately, security researchers say the password requirements for the devices are often weak, creating openings that Stuxnet (or other viruses) can exploit. Siemens made the PLCs that ran Iran's centrifuges; other makers include Modicon and Allen Bradley. Once introduced via computers running Microsoft Windows, Stuxnet looks for a PLC it can control.
Q. How big is the problem?
Millions of PLCs are in use all over the world, and Siemens is one of the top five vendors.
Q. After Iran, did Siemens fix its devices?
Siemens released a software tool for users to detect and remove the Stuxnet virus, and encourages its customers to install fixes Microsoft put out for its Windows system soon after the Iran attack became public (most PLCs are programmed from computers running Windows.) It is also planning to release a new piece of hardware for its PLCs, called a communications processor, to make them more secure. though it's unclear whether the new processor will fix the specific problems Stuxnet exploited. Meanwhile, the firm acknowledges its PLCs remain vulnerable, in a statement to ProPublica, Siemens said it was impossible to guard against every possible attack.
Q. Is Siemens alone?
Logic controllers made by other companies also have flaws, as researchers from NSS labs, a security research firm, have pointed out. Researchers at a consulting firm called Digital Bond drew more attention to the problem earlier this year when they released code targeting commonly used PLCs using some of Stuxnet's techniques. A key vulnerability is password strength. PLCs connected to corporate networks or the Internet are frequently left wide open, Digital Bond CEO Dale Peterson says.
Q. What makes these systems so tough to protect?
Like any computer product, industrial control systems have bugs that programmers can't foresee. Government officials and security researchers say critical systems should never be connected to the Internet, though they frequently are. But having Internet access is convenient and saves money for companies that operate water, power, transit and other systems.
Q. Is cost an issue?
System manufacturers are reluctant to patch older versions of their products, government and private sector researchers said. Utility companies and other operators don't want to shell out money to replace systems that seem to be working fine. Dan Auerbach of the Electronic Frontier Foundation, formerly a security engineer at Google, says the pressure on tech companies to quickly release products sometimes trumps security. "There's an incentive problem," he said.
There are multiple versions of when Stuxnet was written and released (NY Times claims US released Stuxnet with Israel and it accidentally escaped ZDNet). One, more recent paper suggests that code was ready in 2005, five years before it was discovered, although this was a different version of the code (Symantec2013).
Stuxnet is interesting not only because of unprecedented complexity and targeted attack on industrial systems, but also because it clearly demonstrated that governments are behind the efforts to develop malware:
Now widely believed to have been a project of U.S. and Israeli intelligence (U.S. officials have yet to publicly acknowledge a role but have done so anonymously to the New York Times and NPR), Stuxnet was carefully designed to infect multiple systems needed to access and control industrial equipment used in Iran’s nuclear program. The payload was clearly the work of a group with access to government-scale resources and intelligence, but it was made possible by four zero-day exploits for Windows that allowed it to silently infect target computers. That so many precious zero-days were used at once was just one of Stuxnet’s many striking features.
The whole idea was pretty reckless and did not take into account possible "blowback". Those who have homes made of glass should not throw stones! As such it was a gross failure of parties involved as it. Here are several points often discussed:
Flame circulated on the Web for at least four years and evaded detection by the big antivirus operators like McAfee, Symantec, Kaspersky Labs and F-Secure — companies that are vital to ensuring that law-abiding consumers can go about their business on the Web unmolested by the army of malware writers, who release nasty computer code onto the Internet to steal our money, data, intellectual property or identities. But senior industry figures have now expressed deep worries about the state-sponsored release of the most potent malware ever seen.
During the cold war, countries’ chief assets were missiles with nuclear warheads. Generally their number and location was common knowledge, as was the damage they could inflict and how long it would take them to inflict it.
Advanced cyberwar is different: a country’s assets lie as much in the weaknesses of enemy computer defenses as in the power of the weapons it possesses. So in order to assess one’s own capability, there is a strong temptation to penetrate the enemy’s systems before a conflict erupts. It is no good trying to hit them once hostilities have broken out; they will be prepared and there’s a risk that they already will have infected your systems.
Once the logic of cyberwarfare takes hold, it is worryingly pre-emptive and can lead to the uncontrolled spread of malware.
There was probably a better use of those billions of dollars which will be spend on upgrading and installing new security measures on all vulnerable systems and hiring (often clueless) personnel to protect those systems (few competent people want to bury their talent in the job, which is essentially a cleaning job, no matter what money are offered).
As government and large industrial organization involve a large measure of blatant incompetence and bureaucratic perversions the effectiveness of measures undertaken can't be guarantied. So vulnerabilities remains no matter what measures will be attempted to minimize its impact. This "open windows of vulnerabilities" especially on more infused with computer hardware Western industrial systems is one of the most striking Stuxnet consequences.
Also while sabotage is just one aspect of the worm, a very similar architecture can be used (and were used, see Flame and Dudu) for information collection, so the real danger now is much greater that just industrial systems with vulnerable computer components. For example, built-in "lights off" systems such as HP ILO and Dell DRAC are now in play. And they are installed on the millions of servers worldwide.
Stuxnet also had shown that the trade of “zero-day” vulnerabilities is boosted and probably controlled by government agencies.
Information about such flaws can command prices in the hundreds of thousands of dollars from defense contractors, security agencies and governments.
This trade in zero-day exploits is poorly documented, but it is perhaps the most visible part of a new industry that in the years to come is likely to swallow growing portions of the U.S. national defense budget, reshape international relations, and perhaps make the Web less safe for everyone.
It became clear that era of a "regular PCs" is over. Really draconian measures are needed to minimize chances of repeated attacks of the same style. For more or less security sensitive organization only vetted software components can be installed and integrity of the system needs to be continuously checked during its operation as well as on each boot, possibly using an independent bootable disk with a different OS.
As such worms can sneak via unknown network vulnerability the set of protocols that a sensitive PC supports should be severely limited either via external firewall and web proxy or internally via virtual machine environment. All drivers should be cryptographically signed and only cryptographically signed drivers should be allowed to load in the system.
The size of Stuxnet is just several hundred of kilobytes. So it is very small in comparison with Flame (20 megabytes).
Nevertheless despite that modest size it contains so many "innovations" in malware design, that it opened a new era of malware. And what is unforeseen externality (aka blowback), it presents the greatest danger for rich industrialized nations, not to Iran or other small and relatively poor countries where such systems are used mainly by military and foreign companies. So boomerang launched by Stuxnet now returned back in a form of billions of dollar that the USA and other Western countries need to spend and thousands of additional of people (let's say at least one for each organization that have such systems) that they need to hire to ensure even minimal level of security of their industrial control systems:
Since then, more Stuxnet-like malware has been uncovered, and it’s involved even more complex techniques (see “The Antivirus Era Is Over”). It is likely that even more have been deployed but escaped public notice. Meanwhile, governments and companies in the United States and around the world have begun paying more and more for the exploits needed to make such weapons work, says Christopher Soghoian, a principal technologist at the American Civil Liberties Union.
“On the one hand the government is freaking out about cyber-security, and on the other the U.S. is participating in a global market in vulnerabilities and pushing up the prices,” says Soghoian, who says he has spoken with people involved in the trade and that prices range from the thousands to the hundreds of thousands. Even civilian law-enforcement agencies pay for zero-days, Soghoian says, in order to sneak spy software onto suspects’ computers or mobile phones.
Exploits for mobile operating systems are particularly valued, says Soghoian, because unlike desktop computers, mobile systems are rarely updated. Apple sends updates to iPhone software a few times a year, meaning that a given flaw could be exploited for a long time. Sometimes the discoverer of a zero day vulnerability receives a monthly payment as long as a flaw remains undiscovered. “As long as Apple or Microsoft has not fixed it you get paid,” says Soghioan.
No law directly regulates the sale of zero-days in the United States or elsewhere, so some traders pursue it quite openly. A Bangkok-based security researcher who goes by the name The Grugq tweets about acting as a middleman and has spoken to the press about negotiating deals worth hundreds of thousands of dollars with government buyers from the United States and western Europe. In an argument on Twitter last month, he denied that his business is equivalent to arms dealing, as critics within and outside the computer security community have charged. “An exploit is a component of a toolchain,” he tweeted. “The team that produces & maintains the toolchain is the weapon.”
Some small companies are similarly up-front about their involvement in the trade. The French security company VUPEN states on its website that it
“provides government-grade exploits specifically designed for the Intelligence community and national security agencies to help them achieve their offensive cyber security and lawful intercept missions.”
Last year, employees of the company publicly demonstrated a zero-day flaw that compromised Google’s Chrome browser, but they turned down Google’s offer of a $60,000 reward if they would share how it worked. What happened to the exploit is unknown.
Reproduced from Analyzing a Stuxnet Infection with the Sysinternals Tools, Part 1
Mark Russinovich’s technical blog covering topics such as Windows troubleshooting, technologies and security.View Profile
30 Mar 2011 1:00 AM
Though I didn’t realize what I was seeing, Stuxnet first came to my attention on July 5 last summer when I received an email from a programmer that included a driver file, Mrxnet.sys, that they had identified as a rootkit. A driver that implements rootkit functionality is nothing particularly noteworthy, but what made this one extraordinary is that its version information identified it as a Microsoft driver and it had a valid digital signature issued by Realtek Semiconductor Corporation, a legitimate PC component manufacturer (while I appreciate the programmer entrusting the rootkit driver to me, the official way to submit malware to Microsoft is via the Malware Protection Center portal).
I forwarded the file to the Microsoft antimalware and security research teams and our internal review into what became the Stuxnet saga began to unfold, quickly making the driver I had received become one of the most infamous pieces of malware ever created. Over the course of the next several months, investigations revealed that Stuxnet made use of four “zero day” Windows vulnerabilities to spread and to gain administrator rights once on a computer (all of which were fixed shortly after they were revealed) and was signed with certificates stolen from Realtek and JMicron. Most interestingly, analysts discovered code that reprograms Siemens SCADA (Supervisory Control and Data Acquisition) systems used in some centrifuges, and many suspect Stuxnet was specifically designed to destroy the centrifuges used by Iran’s nuclear program to enrich Uranium, a goal the Iranian government reported the virus at least partially accomplished.
As a result, Stuxnet has been universally acknowledged as the most sophisticated piece of malware created. Because of its apparent motives and clues found in the code, some researchers believe that it’s the first known example of malware used for state-sponsored cyber warfare. Ironically, I present several examples of malware targeting infrastructure systems in my recently-published cyber-thriller Zero Day, which when I wrote the book several years ago seemed a bit of a stretch. Stuxnet has proven the examples to be much more likely than I had thought (by the way, if you’ve read Zero Day, please leave a review on Amazon.com).
Malware and the Sysinternals Tools
My last several blog posts have documented cases of the Sysinternals tools being used to help clean malware infections, but malware researchers also commonly use the tools to analyze malware. Professional malware analysis is a rigorous and tedious process that requires disassembling malware to reverse engineer its operation, but systems monitoring tools like Sysinternals Process Monitor and Process Explorer can help analysts get an overall view of malware operation. They can also provide insight into malware’s purpose and help to identity points of execution and pieces of code that require deeper inspection. As the previous blog posts hint, those findings can also serve as a guide for creating malware cleaning recipes for inclusion in antimalware products.
I therefore thought it would be interesting to show the insights the Sysinternals tools give when applied to the initial infection steps of the Stuxnet virus (note that no centrifuges were harmed in the writing of this blog post). I’ll show a full infection of a Windows XP system and then uncover the way the virus uses one of the zero-day vulnerabilities to elevate itself to administrative rights when run from an unprivileged account on Windows 7. Keep in mind that Stuxnet is an incredibly complex piece of malware. It propagates and communicates using multiple methods and performs different operations depending on the version of operating system infected and the software installed on the infected system. This look at Stuxnet just scratches the surface and is intended to show how with no special reverse engineering expertise, Sysinternals tools can reveal the system impact of a malware infection. See Symantec’s W32.Stuxnet Dossier for a great in-depth analysis of Stuxnet’s operation.
The Stuxnet Infection Vector
Stuxnet spread last summer primarily via USB keys, so I’ll start the infection with the virus installed on a key. The virus consists of six files: four malicious shortcut files with names that are based off of “Copy of Shortcut to.lnk” and two files with names that make them look like common temporary files. I’ve used just one of the shortcut files for this analysis, since they all serve the same purpose:
In this infection vector, Stuxnet begins executing without user interaction by taking advantage of a zero-day vulnerability in the Windows Explorer Shell (Shell32.dll) shortcut parsing code. All the user has to do is open a directory containing the Stuxnet files in Explorer. To let the infection succeed, I first uninstalled the fix for the Shell flaw, KB2286198, that was pushed out by Windows Update in August 2010. When Explorer opens the shortcut file on an unpatched system to find the shortcut’s target file so that it can helpfully show the icon, Stuxnet infects the system and uses rootkit techniques to hide the files, causing them to disappear from view.
Stuxnet on Windows XP
Before triggering the infection, I started Process Monitor, Process Explorer and Autoruns. I configured Autoruns to perform a scan with the “Hide Microsoft and Windows Entries” and “Verify Code Signatures” options checked:
This removes any entries that have Microsoft or Windows digital signatures so that Autoruns shows only entries populated by third-party code, including code signed by other publishers. I saved the output of the scan so that I could have Autoruns compare against it later and highlight any entries added by Stuxnet. Similarly, I paused the Process Explorer display by pressing the space bar, which would enable me to refresh it after the infection and cause it to show any processes started by Stuxnet in the green background color Process Explorer uses for new processes. With Process Monitor capturing registry, file system, and DLL activity, I navigated to the USB key’s root directory, watched the temporary files vanish, waited a minute to give the virus time to complete its infection, stopped Process Monitor and refreshed both Autoruns and Process Explorer.
After refreshing Autoruns, I used the Compare function in the File menu to compare the updated entries with the previously saved scan. Autoruns detected two new device driver registrations, Mrxnet.sys and Mrxcls.sys:
Mrxnet.sys is the driver that the programmer originally sent me and that implements the rootkit that hides files, and Mrxcls.sys is a second Stuxnet driver file that launches the malware when the system boots. Stuxnet’s authors could easily have extended Mrxnet’s cloak to hide these files from tools like Autoruns, but they apparently felt confident that the valid digital signatures from a well-known hardware company would cause anyone that noticed them to pass them over. It turns out that Autoruns has told us all we need to know to clean the infection, which is as easy as deleting or disabling the two driver entries.
Turning my attention to Process Explorer, I also saw two green entries, both instances of the Local Security Authority Subsystem (Lsass.exe) process:
Note the instance of Lsass.exe immediately beneath them that’s highlighted in pink: a normal Windows XP installation has just one instance of Lsass.exe that the Winlogon process creates when the system boots (Wininit creates it on Windows Vista and higher). The process tree reveals that the two new Lsass.exe instances were both created by Services.exe (not visible in the screenshot), the Service Control Manager, which implies that Stuxnet somehow got its code into the Services.exe process.
Process Explorer can also check the digital signatures on files, which you initiate by opening the process or DLL properties dialog and clicking on the Verify button, or by selecting the Verify Image Signatures option in the Options menu. Checking the rogue Lsass processes confirms that they are running the stock Lsass.exe image:
The two additional Lsass processes obviously have some mischievous purpose, but the main executable and command lines don’t reveal any clues. But besides running as children of Services.exe, another suspicious characteristic of the two superfluous processes is the fact that they have very few DLLs loaded, as shown by the Process Explorer DLL view:
The real Lsass has many more:
No non-Microsoft DLLs show up in the loaded-module lists for Services.exe, Lsass.exe or Explorer.exe, so they are probably hosting injected executable code. Studying the code would require advanced reverse engineering skills, but we might be able to determine where the code resides in those processes, and hence what someone with those skills would analyze, by using the Sysinternals VMMap utility. VMMap is a process memory analyzer that visually displays the address space usage of a process. To execute, code must be stored in memory regions that have Execute permission, and because injected code will likely be stored in memory that’s normally for data and therefore not usually executable, it might be possible to find the code just by looking for memory not backed by a DLL or executable that has Execute permission. If the region has Write permission, that makes it even more suspicious, because the injection would require Write permission and probably isn’t concerned with removing the permission once the code is in place. Sure enough, the legitimate Lsass has no executable data regions, but both new Lsass processes have regions with Execute and Write permissions in their address spaces at the same location and same size:
VMMap’s Strings dialog, which you open from the View menu, shows any printable strings in a selected region. The 488K region has the string “This program cannot be run in DOS mode" at its start, which is a standard message stored in the header of every Windows executable. That implies that the virus is not just injecting a code snippet, but an entire DLL:
The region is almost devoid of any other recognizable text, so it’s probably compressed, but the Windows API strings at the end of the region are from the DLL’s import table:
Explorer.exe, the initially infected process, and Services.exe, the process that launched the Lsass processes, also have no suspicious DLLs loaded, but also have unusual executable data regions:
The two Mrx drivers are also visible in the loaded driver list, which you can see in the DLL view of Process Explorer for the System process. The only reason they stand out at all is that their version information reports them to be from Microsoft, but their signatures are from Realtek (the certificates have been revoked, but since the test system is disconnected from the Internet, it is unable to query the Certificate Revocation List servers):
At this point we’ve gotten about as far as we can with Autoruns and Process Explorer. What we know so far is that Stuxnet drops two driver files on the system, registers them to start when the system boots, and starts them. It also infects Services.exe and creates two Lsass.exe processes that run until system shutdown, the purpose of which can’t be determined by their command-lines or loaded DLLs. However, VMMap has given us pointers to injected code and Autoruns has given us an easy way to clean the infection. The Process Monitor trace from the infection has about 30,000 events, and from that we’ll be able to gain further insight into what happens at the time of the infection, where the injected code is stored on disk, and how Stuxnet activates the code at boot time. Read more in Part 2.
Mark Russinovich is a Technical Fellow on the Windows Azure team at Microsoft and is author of Windows Internals, The Windows Sysinternals Administrator’s Reference, and the cyberthriller Zero Day: A Novel. You can contact him at firstname.lastname@example.org.
30 Mar 2011 10:01 AM
It would be really cool if VMMap could then dump the memory, say to a DMP file for use in WinDBG or other further analysis. Any chance that will be added?
30 Mar 2011 10:03 AM
"Sure enough, the legitimate Lsass has no executable data regions, but both new Lsass processes have such regions in their address spaces at the same location and same size"
From the VMMap screen shot, we can see two other data sections marked executable (at 0x002F0000 and 0x004E0000). Furthermore, from what I can tell, Csrss.exe maps a Shareable section at 0x7F6F0000 (CsrSrvSharedSectionBase) that is marked executable into just about every process (something I've wondered about for a while).
I suppose the thing that makes it suspicious in this case is that the section is marked executable *and* writable.
30 Mar 2011 10:11 AM@Bob Good point, and it was the Execute+Write that really made those regions suspcious. I've updated the text to make that more clear.
Alex Ionescu30 Mar 2011 11:33 AM
How about adding a feature for VMMap to "extract data" -- similar to Strings, but it would just let you dump the selected memory region to a .bin file. Could be very useful for something like this (extracting the DLL for later analysis) or just dumping out bitmaps and other resources that might be in memory (or even parts of a .doc file).
30 Mar 2011 12:05 PM
Steve Gibson had a pretty good podcast episode about Stuxnet:
- Matt Thomson
30 Mar 2011 1:44 PM
Interesting analysis of Stuxnet here; www.ted.com/.../ralph_langner_cracking_stuxnet_a_21st_century_cyberweapon.htmlEd
30 Mar 2011 6:43 PMAnother interesting analysis...
VijaySaradhi Samavedam30 Mar 2011 9:34 PM
If this is rumored to me state sponsored cyber warfare, how can we be sure that what ever we use is safe? Thank you for the In depth Analysis! This will be my second favorite article of your's after Inside Windows Vista series.
31 Mar 2011 5:30 AM
Excellent article! I remember using such techniques at my former employer to disinfect Windows Xp installations (c 2006) rather than the "easy" approach of downloading shareware to do the job. I didn't know it was called reverse engineering.
- Stefan Woe
1 Apr 2011 2:58 AM
It is not totally correct that "...code reprograms Siemens SCADA (Supervisory Control and Data Acquisition) systems used in some centrifuges"
The centrifuges themselves are controlled by programmable logic controllers (PLC) which vice versa are controlled remotely by a SCADA System (thats the whole nature of a SCADA). One of the real "innovations" of Stuxnet was that it not only infected windows machines, but also PLCs by a dedicated PLC rootkit (en.wikipedia.org/.../Stuxnet).
Here is some info from Wikipedia (should be taken with a grain of salt):
- 1 History
- 2 Affected countries
- 3 Operation
- 4 Removal
- 5 Control system security
- 6 Speculations about the target and origin
- 7 Duqu
- 8 Flame
- 9 See also
- 10 References
- 11 Further reading
Discovered in June 2010, Stuxnet initially spreads via Microsoft Windows, and targets Siemens industrial software and equipment. While it is not the first time that hackers have targeted industrial systems, it is
- the first discovered malware that spies on and subverts industrial systems,
- the first to include a programmable logic controller (PLC) rootkit.
The worm initially spreads indiscriminately, but includes a highly specialized malware payload that is designed to target only Siemens supervisory control and data acquisition (SCADA) systems that are configured to control and monitor specific industrial processes. Stuxnet infects PLCs by subverting the Step-7 software application that is used to reprogram these devices.
Different variants of Stuxnet targeted five Iranian organizations, with the probable target widely suspected to be uranium enrichment infrastructure in Iran. Symantec noted in August 2010 that 60% of the infected computers worldwide were in Iran. Siemens stated that the worm has not caused any damage to its customers, but the Iran nuclear program, which uses embargoed Siemens equipment procured secretly, has been damaged by Stuxnet.
Kaspersky Lab concluded that the sophisticated attack could only have been conducted "with nation-state support". This was further supported by the F-Secure's chief researcher Mikko Hyppönen who commented in a Stuxnet FAQ, "That's what it would look like, yes". It has been speculated that Israel and the United States may have been involved.
In May 2011, the PBS program Need To Know cited a statement by Gary Samore, White House Coordinator for Arms Control and Weapons of Mass Destruction, in which he said, "we're glad they [the Iranians] are having trouble with their centrifuge machine and that we – the US and its allies – are doing everything we can to make sure that we complicate matters for them", offering "winking acknowledgement" of US involvement in Stuxnet. According to The Daily Telegraph, a showreel that was played at a retirement party for the head of the Israel Defense Forces (IDF), Gabi Ashkenazi, included references to Stuxnet as one of his operational successes as the IDF chief of staff.
On 1 June 2012, an article in The New York Times said that Stuxnet is part of a U.S. and Israeli intelligence operation called "Operation Olympic Games", started under President George W. Bush and expanded under President Barack Obama.
On 24 July 2012 an article by Chris Matyszczyk from cnet reported how the Atomic Energy Organization of Iran e-mailed F-Secure's chief research officer Mikko Hypponen to report a new instance of malware.
The worm was at first identified by the security company VirusBlokAda in mid-June 2010. Journalist Brian Krebs's 15 July 2010 blog posting was the first widely read report on the worm.
Its name is derived from some keywords discovered in the software. The reason for the discovery at this time is attributed to the virus accidentally spreading beyond its intended target (the Natanz plant) due to a programming error introduced in an update; this led to the worm spreading to an engineer's computer that had been hooked up to the centrifuges, and then spread when the engineer returned home and hooked his computer up to the internet.
Kaspersky Lab experts at first estimated that Stuxnet started spreading around March or April 2010, but the first variant of the worm appeared in June 2009. On 15 July 2010, the day the worm's existence became widely known, a distributed denial-of-service attack was made on the servers for two leading mailing lists on industrial-systems security. This attack from an unknown source but likely related to Stuxnet, disabled one of the lists and thereby interrupted an important source of information for power plants and factories.
The second variant, with substantial improvements, appeared in March 2010, apparently because its authors believed that Stuxnet was not spreading fast enough; a third, with minor improvements, appeared in April 2010. The worm contains a component with a build time-stamp from 3 February 2010. In the United Kingdom on 25 November 2010, Sky News reported that it had received information from an anonymous source at an unidentified IT security organization that Stuxnet, or a variation of the worm, had been traded on the black market. However, other security experts disagreed.
A study of the spread of Stuxnet by Symantec showed that the main affected countries in the early days of the infection were Iran, Indonesia and India.
Country Infected computers Iran 58.85% Indonesia 18.22% India 8.31% Azerbaijan 2.57% United States 1.56% Pakistan 1.28% Others 9.2%
“ [O]ne of the great technical blockbusters in malware history. ”
—Vanity Fair, April 2011
Unlike most malware, Stuxnet does little harm to computers and networks that do not meet specific configuration requirements; "The attackers took great care to make sure that only their designated targets were hit...It was a marksman’s job."
While the worm is promiscuous, it makes itself inert if Siemens software is not found on infected computers, and contains safeguards to prevent each infected computer from spreading the worm to more than three others, and to erase itself on 24 June 2012.
For its targets, Stuxnet contains, among other things, code for a man-in-the-middle attack that fakes industrial process control sensor signals, so that an infected system does not shut down due to abnormal behavior. Such complexity is very unusual for malware.
The worm consists of a layered attack against three different systems:
- The Windows operating system,
- Siemens PCS 7, WinCC and STEP7 industrial software applications that run on Windows
- One or more Siemens S7 PLCs.
Stuxnet attacked Windows systems using an unprecedented four zero-day attacks (plus the CPLINK vulnerability and a vulnerability used by the Conficker worm).
- It is initially spread using infected removable drives such as USB flash drives,
- then uses other exploits and techniques such as peer-to-peer RPC to infect and update other computers inside private networks that are not directly connected to the Internet.
- The number of zero-day Windows exploits used is unusual, as they are valued, and crackers do not normally waste the use of four different ones in the same worm.
- Stuxnet is unusually large at half a megabyte in size, and written in several different programming languages (including C and C++) which is also irregular for malware.
- The Windows component of the malware is promiscuous in that it spreads relatively quickly and indiscriminately.
The driver signing helped it install kernel-mode rootkit drivers successfully and therefore remain undetected for a relatively long period of time. Both compromised certificates have been revoked by VeriSign.
Two websites in Denmark and Malaysia were configured as command and control servers for the malware, allowing it to be updated, and for industrial espionage to be conducted by uploading information.
Both of these websites have subsequently been taken down as part of a global effort to disable the malware.
Step 7 software infection
Overview of normal communications between Step 7 and a Siemens PLC
Overview of Stuxnet hijacking communication between Step 7 software and a Siemens PLC
According to researcher Ralph Langner, once installed on a Windows system Stuxnet infects project files belonging to Siemens' PCS 7 SCADA control software (Step 7), and subverts a key communication library of WinCC called
s7otbxdx.dll. Doing so intercepts communications between the WinCC software running under Windows and the target Siemens PLC devices that the software is able to configure and program when the two are connected via a data cable. In this way, the malware is able to install itself on PLC devices unnoticed, and subsequently to mask its presence from WinCC if the control software attempts to read an infected block of memory from the PLC system.
The malware furthermore used a zero-day exploit in the WinCC/SCADA database software in the form of a hard-coded database password.
PLC infectionSiemens Simatic S7-300 PLC CPU with three I/O modules attached
The entirety of the Stuxnet code has not yet been disclosed, but its payload targets only those SCADA configurations that meet criteria that it is programmed to identify.
Stuxnet requires specific slave variable-frequency drives (frequency converter drives) to be attached to the targeted Siemens S7-300 system and its associated modules. It only attacks those PLC systems with variable-frequency drives from two specific vendors: Vacon based in Finland and Fararo Paya based in Iran. Furthermore, it monitors the frequency of the attached motors, and only attacks systems that spin between 807 Hz and 1210 Hz. The industrial applications of motors with these parameters are diverse, and may include pumps or gas centrifuges.
Stuxnet installs malware into memory block DB890 of the PLC that monitors the Profibus messaging bus of the system. When certain criteria are met, it periodically modifies the frequency to 1410 Hz and then to 2 Hz and then to 1064 Hz, and thus affects the operation of the connected motors by changing their rotational speed.
It also installs a rootkit—the first such documented case on this platform—that hides the malware on the system and masks the changes in rotational speed from monitoring systems.
Siemens has released a detection and removal tool for Stuxnet. Siemens recommends contacting customer support if an infection is detected and advises installing Microsoft patches for security vulnerabilities and prohibiting the use of third-party USB flash drives. Siemens also advises immediately upgrading password access codes.
The worm's ability to reprogram external PLCs may complicate the removal procedure. Symantec's Liam O'Murchu warns that fixing Windows systems may not completely solve the infection; a thorough audit of PLCs may be necessary. Despite speculation that incorrect removal of the worm could cause damage, Siemens reports that in the first four months since discovery, the malware was successfully removed from the systems of twenty-two customers without any adverse impact.
Control system securityMain article: Control system security
Prevention of control system security incidents, such as from viral infections like Stuxnet, is a topic that is being addressed in both the public and the private sector.
The U.S. Department of Homeland Security National Cyber Security Division (NCSD) operates the Control System Security Program (CSSP). The program operates a specialized computer emergency response team called the Industrial Control Systems Cyber Emergency Response Team (ICS-CERT), conducts a biannual conference (ICSJWG), provides training, publishes recommended practices, and provides a self-assessment tool.
As part of a Department of Homeland Security plan to improve American computer security, in 2008 it and the Idaho National Laboratory (INL) worked with Siemens to identify security holes in the company's widely used Process Control System 7 (PCS 7) and its software Step 7. In July 2008 INL and Siemens publicly announced flaws in the control system at a Chicago conference; Stuxnet exploited these holes in 2009.
Several industry organizations and professional societies have published standards and best practice guidelines providing direction and guidance for control system end-users on how to establish a control system security management program. The basic premise that all of these documents share is that prevention requires a multi-layered approach, often referred to as "defense-in-depth". The layers include policies and procedures,
- awareness and training,
- network segmentation,
- access control measures,
- physical security measures,
- system hardening, e.g., patch management, and system monitoring,
- anti-virus and intrusion prevention system (IPS).
The standards and best practices also all recommend starting with a risk analysis and a control system security assessment.
Speculations about the target and origin
Experts believe that Stuxnet required the largest and costliest development effort in malware history. Its many capabilities would have required a team of people to program, in-depth knowledge of industrial processes, and an interest in attacking industrial infrastructure.
Eric Byres, who has years of experience maintaining and troubleshooting Siemens systems, told Wired that writing the code would have taken many man-months, if not years.
Symantec estimates that the group developing Stuxnet would have consisted of anywhere from five to thirty people, and would have taken six months to prepare.
The Guardian, the BBC and The New York Times all claimed that (unnamed) experts studying Stuxnet believe the complexity of the code indicates that only a nation-state would have the capabilities to produce it.
The self-destruct and other safeguards within the code imply that a Western government was responsible, with lawyers evaluating the worm's ramifications.
Software security expert Bruce Schneier condemned the 2010 news coverage of Stuxnet as hype, however, stating that it was almost entirely based on speculation. But after subsequent research, Schneier stated in 2012 that "we can now conclusively link Stuxnet to the centrifuge structure at the Natanz nuclear enrichment lab in Iran".
Iran as target
Ralph Langner, the researcher who identified that Stuxnet infected PLCs, first speculated publicly in September 2010 that the malware was of Israeli origin, and that it targeted Iranian nuclear facilities.
However Langner more recently, in a TED Talk recorded in February 2011, stated that, "My opinion is that the Mossad is involved, but that the leading force is not Israel. The leading force behind Stuxnet is the cyber superpower—there is only one; and that's the United States."
Kevin Hogan, Senior Director of Security Response at Symantec, reported that the majority of infected systems were in Iran (about 60%), which has led to speculation that it may have been deliberately targeting "high-value infrastructure" in Iran including either the Bushehr Nuclear Power Plant or the Natanz nuclear facility.
Langner called the malware "a one-shot weapon" and said that the intended target was probably hit, although he admitted this was speculation. Another German researcher, Frank Rieger, was the first to speculate that Natanz was the target.
Natanz nuclear facilities
According to the Israeli newspaper Haaretz, in September 2010 experts on Iran and computer security specialists were increasingly convinced that Stuxnet was meant "to sabotage the uranium enrichment facility at Natanz – where the centrifuge operational capacity has dropped over the past year by 30 percent."] On 23 November 2010 it was announced that uranium enrichment at Natanz had ceased several times because of a series of major technical problems. A "serious nuclear accident" (supposedly the shutdown of some of its centrifuges) occurred at the site in the first half of 2009, which is speculated to have forced the head of Iran's Atomic Energy Organization Gholam Reza Aghazadeh to resign.
Statistics published by the Federation of American Scientists (FAS) show that the number of enrichment centrifuges operational in Iran mysteriously declined from about 4,700 to about 3,900 beginning around the time the nuclear incident WikiLeaks mentioned would have occurred. (ISIS) suggests in a report published in December 2010 that Stuxnet is "a reasonable explanation for the apparent damage" at Natanz and may have destroyed up to 1000 centrifuges (10 percent) sometime between November 2009 and late January 2010. The authors conclude:The attacks seem designed to force a change in the centrifuge’s rotor speed, first raising the speed and then lowering it, likely with the intention of inducing excessive vibrations or distortions that would destroy the centrifuge. If its goal was to quickly destroy all the centrifuges in the FEP, Stuxnet failed. But if the goal was to destroy a more limited number of centrifuges and set back Iran’s progress in operating the FEP, while making detection difficult, it may have succeeded, at least temporarily.
The (ISIS) report further notes that Iranian authorities have attempted to conceal the breakdown by installing new centrifuges on a large scale.
The worm worked by first causing an infected Iranian IR-1 centrifuge to increase from its normal operating speed of 1,064 hertz to 1,410 hertz for 15 minutes before returning to its normal frequency. Twenty-seven days later, the worm went back into action, slowing the infected centrifuges down to a few hundred hertz for a full 50 minutes. The stresses from the excessive, then slower, speeds caused the aluminum centrifugal tubes to expand, often forcing parts of the centrifuges into sufficient contact with each other to destroy the machine.
According to The Washington Post, (IAEA) cameras installed in the Natanz facility recorded the sudden dismantling and removal of approximately 900–1000 centrifuges during the time the Stuxnet worm was reportedly active at the plant. Iranian technicians, however, were able to quickly replace the centrifuges and the report concluded that uranium enrichment was likely only briefly disrupted.
On 15 February 2011 (ISIS) released a report concluding that:Assuming Iran exercises caution, Stuxnet is unlikely to destroy more centrifuges at the Natanz plant. Iran likely cleaned the malware from its control systems. To prevent re-infection, Iran will have to exercise special caution since so many computers in Iran contain Stuxnet. Although Stuxnet appears to be designed to destroy centrifuges at the Natanz facility, destruction was by no means total.
Moreover, Stuxnet did not lower the production of LEU during 2010. LEU quantities could have certainly been greater, and Stuxnet could be an important part of the reason why they did not increase significantly. Nonetheless, there remain important questions about why Stuxnet destroyed only 1,000 centrifuges.
One observation is that it may be harder to destroy centrifuges by use of cyber attacks than often believed.
The Associated Press reported that the semi-official Iranian Students News Agency released a statement on 24 September 2010 stating that experts from the Atomic Energy Organization of Iran met in the previous week to discuss how Stuxnet could be removed from their systems. According to analysts, such as David Albright, Western intelligence agencies have been attempting to sabotage the Iranian nuclear program for some time.
The head of the Bushehr Nuclear Power Plant told Reuters that only the personal computers of staff at the plant had been infected by Stuxnet and the state-run newspaper Iran Daily quoted Reza Taghipour, Iran's telecommunications minister, as saying that it had not caused "serious damage to government systems". The Director of Information Technology Council at the Iranian Ministry of Industries and Mines, Mahmud Liaii, has said that: "An electronic war has been launched against Iran... This computer worm is designed to transfer data about production lines from our industrial plants to locations outside Iran."
In response to the infection, Iran has assembled a team to combat it. With more than 30,000 IP addresses affected in Iran, an official has said that the infection is fast spreading in Iran and the problem has been compounded by the ability of Stuxnet to mutate. Iran has set up its own systems to clean up infections and has advised against using the Siemens SCADA antivirus since it is suspected that the antivirus is actually embedded with codes which update Stuxnet instead of eradicating it.
According to Hamid Alipour, deputy head of Iran's government Information Technology Company, "The attack is still ongoing and new versions of this virus are spreading." He reports that his company had begun the cleanup process at Iran's "sensitive centres and organizations." "We had anticipated that we could root out the virus within one to two months, but the virus is not stable, and since we started the cleanup process three new versions of it have been spreading," he told the Islamic Republic News Agency on 27 September 2010.
On 29 November 2010, Iranian president Mahmoud Ahmadinejad stated for the first time that a computer virus had caused problems with the controller handling the centrifuges at its Natanz facilities. According to Reuters he told reporters at a news conference in Tehran, "They succeeded in creating problems for a limited number of our centrifuges with the software they had installed in electronic parts."
On the same day two Iranian nuclear scientists were targeted in separate, but nearly simultaneous car bomb attacks near Shahid Beheshti University in Tehran. Majid Shahriari, a quantum physicist was killed. Fereydoon Abbasi, a high-ranking official at the Ministry of Defense was seriously wounded. Wired speculated that the assassinations could indicate that whoever was behind Stuxnet felt that it was not sufficient to stop the nuclear program. In January 2010, another Iranian nuclear scientist, a physics professor at Tehran University, had been killed in a similar bomb explosion. On 11 January 2012, a Director of the Natanz nuclear enrichment facility, Mostafa Ahmadi Roshan, was killed in an attack quite similar to the one that killed Shahriari.
An analysis by the FAS demonstrates that Iran’s enrichment capacity grew during 2010. The study indicates that Iran’s centrifuges appear to be performing 60% better than in the previous year, which would significantly reduce Tehran’s time to produce bomb-grade uranium. The FAS report was reviewed by an official with the IAEA who affirmed the study.
European and U.S. officials, along with private experts, have told Reuters that Iranian engineers were successful in neutralizing and purging Stuxnet from their country's nuclear machinery.
Given the growth in Iranian enrichment capability in 2010, the country may have intentionally put out misinformation to cause Stuxnet's creators to believe that the worm was more successful in disabling the Iranian nuclear program than it actually was.
Israel, through Unit 8200, has been speculated to be the country behind Stuxnet in many media reports and by experts such as Richard A. Falkenrath, former Senior Director for Policy and Plans within the U.S. Office of Homeland Security.[ ] Yossi Melman, who covers intelligence for the Israeli daily newspaper Haaretz and is writing a book about Israeli intelligence, also suspected that Israel was involved, noting that Meir Dagan, the former (2011) head of the national intelligence agency Mossad, had his term extended in 2009 because he was said to be involved in important projects. Additionally, Israel now expects that Iran will have a nuclear weapon in 2014 or 2015—at least three years later than earlier estimates—without the need for an Israeli military attack on Iranian nuclear facilities; "They seem to know something, that they have more time than originally thought”, he added. Israel has not publicly commented on the Stuxnet attack but confirmed that cyberwarfare is now among the pillars of its defense doctrine, with a military intelligence unit set up to pursue both defensive and offensive options. When questioned whether Israel was behind the virus in the fall of 2010, some Israeli officials[who?] broke into "wide smiles", fueling speculation that the government of Israel was involved with its genesis. American presidential advisor Gary Samore also smiled when Stuxnet was mentioned, although American officials have indicated that the virus originated abroad. According to The Telegraph, Israeli newspaper Haaretz reported that a video celebrating operational successes of Gabi Ashkenazi, retiring IDF Chief of Staff, was shown at his retirement party and included references to Stuxnet, thus strengthening claims that Israel's security forces were responsible.
In 2009, a year before Stuxnet was discovered, Scott Borg of the United States Cyber-Consequences Unit (US-CCU) suggested that Israel might prefer to mount a cyber-attack rather than a military strike on Iran's nuclear facilities. And, in late 2010 Borg stated, "Israel certainly has the ability to create Stuxnet and there is little downside to such an attack, because it would be virtually impossible to prove who did it. So a tool like Stuxnet is Israel's obvious weapon of choice."
Iran uses P-1 centrifuges at Natanz, the design for which A. Q. Khan stole in 1976 and took to Pakistan. His black market nuclear-proliferation network sold P-1s to, among other customers, Iran. Experts believe that Israel also somehow acquired P-1s and tested Stuxnet on the centrifuges, installed at the Dimona facility that is part of its own nuclear program. The equipment may be from the United States, which received P-1s from Libya's former nuclear program.
Some have also referred to several clues in the code such as a concealed reference to the word "MYRTUS", believed to refer to the Myrtle tree, or Hadassah in Hebrew. Hadassah was the birth name of the former Jewish queen of Persia, Queen Esther. However, it may be that the "MYRTUS" reference is simply a misinterpreted reference to SCADA components known as RTUs (Remote Terminal Units) and that this reference is actually "My RTUs"–a management feature of SCADA. Also, the number 19790509 appears once in the code and might refer to the date "1979 May 09", the day Habib Elghanian, a Persian Jew, was executed in Tehran. Another date that appears in the code is "24 September 2007", the day that Iran's president Mahmoud Ahmadinejad spoke at Columbia University and made comments questioning the validity of the Holocaust. Such data is not conclusive, since, as written by Symantec, "Attackers would have the natural desire to implicate another party" with a false flag.
There has also been speculation on the involvement of the United States, with one report stating that "there is vanishingly little doubt that [it] played a role in creating the worm." It has been reported that the United States, under one of its most secret programs, initiated by the Bush administration and accelerated by the Obama administration, has sought to destroy Iran's nuclear program by novel methods such as undermining Iranian computer systems.
A diplomatic cable obtained by WikiLeaks showed how the United States was advised to target Iran's nuclear capabilities through 'covert sabotage'. A Wired article claimed that Stuxnet "is believed to have been created by the United States".
The fact that John Bumgarner, a former intelligence officer and member of the United States Cyber-Consequences Unit ([US-CCU), published an article prior to Stuxnet being discovered or deciphered, that outlined a strategic cyberstrike on centrifuges and suggests that cyber attacks are permissible against nation states which are operating uranium enrichment programs that violate international treaties gives some credibility to these claims. Bumgarner pointed out that the centrifuges used to process fuel for nuclear weapons are a key target for cybertage operations and that they can be made to destroy themselves by manipulating their rotational speeds.
In a March 2012 interview with CBS News' "60 Minutes," retired USAF general Michael Hayden - who served as director of both the Central Intelligence Agency and National Security Agency - while denying knowledge of who created Stuxnet said that he believed it had been "a good idea" but that it carried a downside in that it had legitimized the use of sophisticated cyberweapons designed to cause physical damage. Hayden said, "There are those out there who can take a look at this... and maybe even attempt to turn it to their own purposes." In the same report, Sean McGurk, a former cybersecurity official at the Department of Homeland Security noted that the Stuxnet source code could now be downloaded online and modified to be directed at new target systems. Speaking of the Stuxnet creators, he said, "They opened the box. They demonstrated the capability... It's not something that can be put back."
Joint effort and other states and targets
! This article is outdated. Please update this article to reflect recent events or newly available information. (June 2012)
In April 2011 Iranian government official Gholam Reza Jalali stated that an investigation had concluded that the United States and Israel were behind the Stuxnet attack. According to Vanity Fair, Rieger stated that three European countries' intelligence agencies agreed that Stuxnet was a joint United States-Israel effort. The code for the Windows injector and the PLC payload differ in style, likely implying collaboration. Other experts believe that a US-Israel cooperation is unlikely because "the level of trust between the two countries’ intelligence and military establishments is not high."
China, Jordan, and France are other possibilities, and Siemens may have also participated. Langner speculated that the infection may have spread from USB drives belonging to Russian contractors since the Iranian targets were not accessible via the internet.
Sandro Gaycken from the Free University Berlin argued that the attack on Iran was a ruse to distract from Stuxnet's real purpose. According to him, its broad dissemination in more than 100,000 industrial plants worldwide suggests a field test of a cyber weapon in different security cultures, testing their preparedness, resilience, and reactions, all highly valuable information for a cyberwar unit.
The United Kingdom has denied involvement in the virus's creation.
Stratfor Documents released by Wikileaks suggest that the International Security Firm 'Stratfor' believe that Israel is behind Stuxnet - "But we can't assume that because they did stuxnet that they are capable of doing this blast as well."
DuquMain article: Duqu
On 1 September 2011, a new worm was found, thought to be related to Stuxnet. The Laboratory of Cryptography and System Security (CrySyS) of the Budapest University of Technology and Economics analyzed the malware, naming the threat Duqu. Symantec, based on this report, continued the analysis of the threat, calling it "nearly identical to Stuxnet, but with a completely different purpose", and published a detailed technical paper. The main component used in Duqu is designed to capture information such as keystrokes and system information. The exfiltrated data may be used to enable a future Stuxnet-like attack. On 28 December 2011, Kaspersky Lab's director of global research and analysis spoke to Reuters about recent research results showing the platform, Stuxnet and Duqu both were built on, originated in 2007 and is being referred to as Tilded, due to the ~d at the beginning of the file names. Also uncovered in this research was the possibility for three more variants based on the Tilded platform.
FlameMain article: Flame (malware)
In May 2012, the new malware "Flame" was found, thought to be related to Stuxnet. Researchers named the program "Flame" after the name of one of its modules. After analysing the code of Flame, Kaspersky said that there is a strong relationship between Flame and Stuxnet. An early version of Stuxnet contained code to propagate infections via USB drives that is nearly identical to a Flame module that exploits the same vulnerability.
May 25, 2015 | Sputnik InternationalThe United States unleashed a version of the Stuxnet computer virus five years ago in an unsuccessful attack on North Korea's nuclear weapons program, people familiar with the covert campaign said.
The operation began at the same time as a successful US-Israeli joint effort in which the Stuxnet virus was deployed to destroy a thousand or more Iranian centrifuges that were enriching uranium, Reuters reported.
For the attack against North Korea's nuclear program, Stuxnet's developers produced a related virus that would be activated when it encountered Korean-language settings on an infected machine, one US intelligence source told Reuters.
US agents, however, were unable to access the core machines that ran Pyongyang's nuclear weapons program, said another source, a former high-ranking intelligence official who was briefed on the program.
As one of the most insular countries in the world, North Korea's utter secrecy, as well as the extreme isolation of its communications systems, foiled the National Security Agency-led campaign, the official told Reuters.
North Korea's communications networks are similarly isolated. One needs police permission just to own a computer, and the open Internet is unknown except to a tiny elite. Furthermore, the country has one main conduit for Internet connections to the outside world, through China, Reuters reported.
Iran, on the other hand, engages in widespread Internet use and had interactions with companies from around the globe.
Experts who spoke with Reuters said there are similarities between North Korea and Iran's nuclear programs, and the two countries continue to collaborate on military technology. Because of that overlap, the NSA would not have had to modify Stuxnet much to make it capable of destroying centrifuges in North Korea.
Despite the subtle differences between the programs, the NSA attack was thwarted by the inability to infiltrate North Korea's program in the first place.
David Albright, founder of the Institute for Science and International Security and an authority on North Korea's nuclear program, told Reuters that US hackers probably tried to get to North Korea by compromising technology suppliers from Iran, Pakistan or China.
As for the successful attack on Iran, a leading theory is that Stuxnet was placed by a sophisticated espionage program developed by a team close to the virus' authors, known as the Equation Group.
August 19, 2013 Antiwar.com
Internal State Department documents, which the department initially denied existed but were finally forced by the courts to reveal show that the high-level “leaks” at the core of David Sanger’s book “Confront and Conceal” came straight from the White House itself.
The book, which praises Obama’s “secret wars,” offers extremely specific details about the US creation of the Stuxnet computer worm to attack Iranian industrial computers, and the aftermath when the worm broke out of Iran and started attacking computers worldwide.
According to the State Department emails, Sanger was given direct access to an array of high level officials, repeatedly meeting with National Security Adviser Tom Donilon and then-Secretary of State Hillary Clinton, as well as top aides across the administration.
Bizarrely, the Justice Department spent a solid year after the publication of Sanger’s book investigating how he obtained the information, one of its efforts to “crack down” on leaks. Of course, it’s not illegal for the White House to leak information.
That doesn’t mean it isn’t unseemly though. Sen. John McCain (R – AZ) was particularly critical about the leaks, saying the book’s release was timed to portray Obama is a “strong leader” and that the leaks were primarily about cashing in on the details of Stuxnet politically.
July 8, 2013 | The Register
NSA whistleblower Edward Snowden has confirmed that the Stuxnet malware used to attack Iranian nuclear facilities was created as part of a joint operation between the Israelis and the NSA's Foreign Affairs Directorate (FAD).
"The NSA and Israel cowrote it," he told Der Spiegel in an email interview conducted before he publicly outed himself as the NSA mole. Snowden is currently in Russia and a "free man" according to Vladimir Putin – as long as there are no further NSA leaks.
The Stuxnet code, which has been deployed since 2005, is thought to be the first malware aimed specifically at damaging specific physical infrastructure*, and was inserted into the computer networks of the Iranian nuclear fuel factory in Natanz shortly after it opened.
Early variants attempted to contaminate uranium supplies by interfering with the flow of gas to the fuel being processed, potentially causing explosive results in the processing factory. Later a more advanced variant attacked the centrifuges themselves, burning out motors by rapidly starting and stopping the units and contaminating fuel production, although it may actually have encouraged the Iranians.
Last year an unnamed US official said that Stuxnet was part of a program called Operation Olympic Games, started under President Bush and continued under the current administration, aimed at slowing down the Iranian nuclear effort without having to resort to risky airstrikes. General James Cartwright, a former vice-chairman of the Joint Chiefs of Staff, is currently under investigation by the US government for allegedly leaking details of Operation Olympic Games.
The second failure is related to discovery. After Minsk-based hackers uncovered Stuxnet, the worm was exposed and therefore subject to dissection. And dissect they certainly did. Stuxnet, you see, did not self-destruct in 2009 as its designers intended. Buried in the code was a self-kill switch that did not go off as planned, and so Stuxnet stayed around long enough to be "interrogated," experts told ABC. It even spread far and wide outside of Natanz to places like India and the U.S., where it was largely harmless due to the fact that it was custom-coded to affect only the Siemens hardware found in Iran's nuclear testing facility.
In the years after exposure, hackers loyal to Iran or its allies are now changing Stuxnet code to suit their own cyberterrorism needs. As far as U.S. interests are concerned, this is a very bad thing indeed:
Moreover, the Obama Administration's policy is that the hundreds of privately owned companies that run those networks have to defend them by themselves. Our new military Cyber Command is not allowed to protect our electric power grid, banking system, railroads, or pipelines. Nor is the Department of Homeland Security. Given the fact that Stuxnet may turn into a boomerang, we may want to rethink whether our tax dollars might buy us some defense of the computer networks that we need to make the country run.
One would hope that the U.S., should it have been involved with Stuxnet (never officially confirmed or acknowledged), would have failsafes in place should the Stuxnet worm be compromised or turned back against its infrastructure in the future. Otherwise, uh, who likes reading by candlelight