Here's what Wired is saying. An 8 page article. I'll post some excerpts beware of spin but the article is very through. Most of what I've skipped over was the drama and kept to the facts and a bit of the political speculations.
Quote:How Digital Detectives Deciphered Stuxnet, the Most Menacing Malware in History
It was January 2010, and investigators with the International Atomic Energy Agency had just completed an inspection at the uranium enrichment plant outside Natanz in central Iran, when they realized that something was off within the cascade rooms where thousands of centrifuges were enriching uranium.
Natanz technicians in white lab coats, gloves and blue booties were scurrying in and out of the “clean” cascade rooms, hauling out unwieldy centrifuges one by one, each sheathed in shiny silver cylindrical casings.
Any time workers at the plant decommissioned damaged or otherwise unusable centrifuges, they were required to line them up for IAEA inspection to verify that no radioactive material was being smuggled out in the devices before they were removed. The technicians had been doing so now for more than a month.
When you’ve seen as many viruses and worms as O Murchu has, you can glance at a piece of malware and know instantly what it does — this one is a keystroke logger, that one is a banking Trojan — and whether it was slapped together sloppily, or carefully crafted and organized. Stuxnet was the latter. It contained multiple components, all compartmentalized into different locations to make it easy to swap out functions and modify the malware as needed.
What most stood out, though, was the way the malware hid those functions. Normally, Windows functions are loaded as needed from a DLL file stored on the hard drive. Doing the same with malicious files, however, would be a giveaway to antivirus software. Instead, Stuxnet stored its decrypted malicious DLL file only in memory as a kind of virtual file with a specially crafted name.
It then reprogrammed the Windows API — the interface between the operating system and the programs that run on top of it — so that every time a program tried to load a function from a library with that specially crafted name, it would pull it from memory instead of the hard drive. Stuxnet was essentially creating an entirely new breed of ghost file that would not be stored on the hard drive at all, and hence would be almost impossible to find.
O Murchu had never seen this technique in all his years of analyzing malware. “Even the complex threats that we see, the advanced threats we see, don’t do this,” he mused during a recent interview at Symantec’s office.
Clues were piling up that Stuxnet was highly professional, and O Murchu had only examined the first 5k of the 500k code. It was clear it was going to take a team to tackle it. The question was, should they tackle it?
“Everything in it just made your hair stand up and go, this is something we need to look into,” he said.
They determined that each time Stuxnet infected a system, it “phoned home” to one of two domains — http://www.mypremierfutbol.com and http://www.todaysfutbol.com hosted on servers in Malaysia and Denmark — to report information about the infected machines. This included the machine’s internal and external IP addresses, the computer name, its operating system and version and whether Siemens Simatic WinCC Step7 software, also known simply as Step7, was installed on the machine. The command-and-control servers let the attackers update Stuxnet on infected machines with new functionality or even install more malicious files on systems.
The DNS providers for the two domains had already dead-lettered the incoming traffic to prevent it from reaching the attackers. Symantec had a better idea. The company contacted the providers and persuaded them to reroute any traffic to a sinkhole — in this case, a computer dedicated to receiving hostile traffic — that Symantec controlled. By Tuesday morning, Symantec was getting reports from machines as Stuxnet infected them. The company shared the data with other security firms.
Within a week of establishing the sinkhole, about 38,000 infected machines were reporting in from dozens of countries. Before long, the number would surpass 100,000. Stuxnet was spreading rapidly, despite signatures distributed by antivirus firms to stop it.
As Chien and O Murchu mapped the geographical location of the infections, a strange pattern emerged. Out of the initial 38,000 infections, about 22,000 were in Iran. Indonesia was a distant second, with about 6,700 infections, followed by India with about 3,700 infections. The United States had fewer than 400. Only a small number of machines had Siemens Step 7 software installed – just 217 machines reporting in from Iran and 16 in the United States.
The infection numbers were way out of sync with previous patterns of worldwide infections — such as what occurred with the prolific Conficker worm — in which Iran never placed high, if at all, in infection stats. South Korea and the United States were always at the top of charts in massive outbreaks, which wasn’t a surprise since they had the highest numbers of internet users. But even in outbreaks centered in the Middle East or Central Asia, Iran never figured high in the numbers. It was clear the Islamic Republic was at the center of the Stuxnet infection.
The sophistication of the code, plus the fraudulent certificates, and now Iran at the center of the fallout made it look like Stuxnet could be the work of a government cyberarmy — maybe even a United States cyberarmy.
This made Symantec’s sinkhole an audacious move. In intercepting data the attackers were expecting to receive, the researchers risked tampering with a covert U.S. government operation. Asked recently if they were concerned about this, Chien replied, “For us there’s no good guys or bad guys.” Then he paused to reconsider. “Well, bad guys are people who are writing malicious code that infects systems that can cause unintended consequences or intended consequences.”
Whether the “bad guy” was the United States or one of its allies, the attack was causing collateral damage to thousands of systems, and Symantec felt no patriotic duty to preserve its activity. “We’re not beholden to a nation,” Chien said. “We’re a multinational, private company protecting customers.”
The clock was ticking. All the researchers knew at this point was that Stuxnet had a foothold on more than 100,000 computers, and they had no real idea what it was doing to them.
he was back in the office digging through the code, focusing on the part that Stuxnet used to spread itself, and testing and documenting his findings. He came up for air midafternoon and passed his notes to Chien, who continued working through the evening. By the end of the weekend, they’d uncovered an astonishing three more zero-days.
In addition to the LNK vulnerability, Stuxnet exploited a print spooler vulnerability in Windows computers to spread across machines that used a shared printer. The third and fourth exploits attacked vulnerabilities in a Windows keyboard file and Task Scheduler file to escalate the attackers’ privileges on a machine and give them full control of it. Additionally, Stuxnet exploited a static password that Siemens had hard-coded into its Step7 software. Stuxnet used the password to gain access to and infect a server hosting a database used with Step7 and from there infect other machines connected to the server.
The attackers were ruthlessly intent on spreading their malware, but in a strangely limited way. Unlike most malware that used e-mail or malicious websites to infect masses of victims at once, none of Stuxnet’s exploits leveraged the internet; they all spread via local area networks. There was one primary way Stuxnet would spread from one facility to another, and that was on an infected USB thumb drive smuggled into the facility in someone’s pocket.
It appeared the attackers were targeting systems they knew were not connected to the internet. And given that they were using four zero-days to do it, the targets had to be high-value.
It was a messy and imprecise method of attack — a little like infecting one of Osama bin Laden’s wives with a rare virus, hoping she’d pass it to the Al Qaeda leader. It was bound to infect others beyond the target, increasing the chance that the plot would be discovered.
This is exactly what happened with Stuxnet. The Symantec researchers discovered that every sample of the worm contained the domain name and time stamp of every system it infected. This allowed them to trace every infection back to the original infected computer from which it started. They discovered that the attackers had focused their attack on computers at five organizations in Iran that they believed would be gateways to the target they were seeking. The five organizations were hit repeatedly in separate infections in June and July 2009 and again in March, April and May 2010. But due to the zero-day exploits in it, Stuxnet spread beyond these organizations, leaving a constellation of infections in its wake.
Symantec reported the additional zero-days it had found in the code to Microsoft and other AV firms, who searched their malware archives to see if anything similar to the exploits had appeared before.
Remarkably, they discovered that a LNK exploit attacking the same vulnerability in Windows Explorer had appeared in November 2008. It was used to spread a variant of Zlob, a family of Trojan horses that installed adware and malicious backdoors on infected computers. The Zlob variant had been picked up by AV firms via automated malware reporting systems from customer machines, but the zero-day exploit in it had gone unnoticed at the time. After its inaugural appearance, the exploit disappeared until reappearing in Stuxnet.
The exploit for the print spooler vulnerability had also previously been disclosed. In April 2009, a Polish security magazine published an article detailing the vulnerability and even provided source code for a working exploit to remotely attack it. Microsoft had never known about it, however, and thus never patched it.
Even the hard-coded Siemens database password had been previously exposed. In April 2008, someone using the name “Cyber” had posted it online to German and Russian technical forums devoted to Siemens products.
Had Stuxnet’s authors, or someone working with them, seen the LNK exploit in 2008 and collected it for use in their attack, hoping Microsoft would never patch it? Or had they purchased it from Zlob’s authors (believed to be East European criminal hackers) on the exploit black market, where zero-days can sell for as high as $50,000 to $500,000? Had they found the other vulnerabilities the same way?
Falliere determined that Stuxnet had three main parts and 15 components, all wrapped together in layers of encryption like Russian nesting dolls. Stuxnet decrypted and extracted each component as needed, depending on the conditions it found on an infected machine.
In addition to these, Stuxnet also had an extensive configuration file – mdmcpq3.pnf — with a menu of more than 400 items the attackers could tweak to control every aspect of the code, such as how long it should spread, and how long each exploit should work. It was here the researchers found an end-date — June 24, 2012. Each time Stuxnet would start to run on a machine, it would check the date on the machine’s internal clock; if it was later than the date in the configuration file, Stuxnet would shut down. Presumably this was the time frame by which Stuxnet was expected to have achieved all of its goals.
The most important part of Stuxnet, however, was its malicious payload. If Stuxnet determined that an infected system had Siemens Step7 software installed, the malware decrypted and loaded a DLL file — a library of functions — onto the machine. This DLL impersonated a legitimate DLL file — s7otbxdx.dll — that served as a common repository for functions used by different pieces of the Step7 software.
Step7 has a nice, Windows-based interface for programming and monitoring a device called a Programmable Logic Controller. PLCs are essentially small computers, generally the size of a toaster, that control everything from motors in packaging assembly lines to critical valves in gas pipelines. To communicate with and program a PLC, plant workers plug their Step7 Windows machines into the PLC and send commands to it or receive data reports.
This is where Stuxnet’s malicious DLL file came in. Falliere discovered that it would intercept commands going from the Step7 software to the PLC and replace them with its own malicious commands.
At the same time, another portion of Stuxnet disabled any automated alarms that might go off in the system as a result of the malicious commands. It also masked what was happening on the PLC by intercepting status reports sent from the PLC to the Step7 machine, and stripping out any sign of the malicious commands. Workers monitoring the PLC from the Step7 machine would then see only legitimate commands on the device — like a Hollywood heist film where jewelry thieves insert a looped video clip into a surveillance camera feed so that guards watching monitors see only a benign image instead of a live feed of the thieves in action.
The fact that Stuxnet was injecting commands into the PLC and masking that it was doing so was evidence that it was designed, not for espionage as everyone had believed, but for physical sabotage. The researchers were stunned. It was the first time anyone had seen digital code in the wild being used to physically destroy something in the real world. Hollywood had imagined such a scenario years earlier in a Die Hard flick. Now reality had caught up with fantasy.
“We were expecting something to be espionage, we were expecting something to steal credit card numbers; that’s what we deal with every single day,” Chien recalls. “But we weren’t expecting this.”
On Aug. 6, Symantec published a blog post saying that Stuxnet was a targeted attack aimed at hijacking the Programmable Logic Controller in a Siemens control system by injecting malicious code.
To illustrate the destructive capability of Stuxnet, the researchers referenced an oft-cited 1982 CIA digital attack on the Siberian pipeline that resulted in an explosion a fifth the size of the atomic bomb detonated over Hiroshima. According to the never-substantiated story, the United States discovered that Russia was stealing data on United States technology. So the CIA hatched a plot to insert a logic bomb into software that the agency knew the Russians were purchasing from a Canadian firm to operate pumps and valves on their natural gas pipeline. The equipment worked fine initially, but at a preprogrammed point, it caused valves in the pipeline to malfunction, creating a pressure buildup that exploded into a fireball so large it was captured by orbiting satellites.
The evidence that Stuxnet was sabotaging a PLC was a huge breakthrough. But there was one problem: None of the Symantec researchers knew enough about PLCs to figure out what exactly Stuxnet was doing to them. PLCs used a unique programming language, STL, that might as well have been Latin to antivirus researchers versed in Windows programs and PC assembly language. On their blog, they asked for anyone with knowledge of PLCs and STL to contact them. But they got no response.
Two weeks after Symantec published its post, traffic from infected machines in Iran suddenly stopped reporting to Symantec’s sinkhole. Iran had begun blocking outbound connections from infected machines. Someone there didn’t want anyone to know which machines in Iran were infected, or have an open channel back to them through Stuxnet.
Chien expected that once they published their post, other researchers would follow suit with more information. Generally, when they analyzed new malware, their competitors were analyzing it simultaneously, and they would all race to publish their findings first. The duplicate work served as an informal peer-review to help verify the accuracy of each firm’s findings. But this time there was no sign that any other researchers were seriously digging into the code.
“We were talking about blowing stuff up!” Chien recalled recently, still amazed at what appeared to be a lack of interest. Instead there was what Chien called “silence like crickets.”
Langner knew that thousands of Siemens customers had a potentially silent killer on their system, and they were waiting for Symantec or Siemens to tell them what Stuxnet was doing to their industrial controllers. But Siemens was, incredibly, quiet on the matter. Despite saying in July that it had assembled a team of experts to examine the malware, the company had been largely mum.
“If it is, after all, their controllers [being targeted], then it would be Siemens’s duty to analyze this,” Langner said. Stuxnet was already available on malware sites for anyone with malicious intent to download and tweak. In the wrong hands, it could become a more widespread and dangerous attack targeting other types of controllers in the United States and elsewhere.
Langner decided that he and his team would tackle Stuxnet themselves.
Langner’s computer knowledge was self-taught, but his mastery of Siemens’s products was so extensive, he and his fellow engineers, Ralf Rosen and Andreas Tim, sometimes trained Siemens employees on their own products. “There are probably only a handful of Siemens employees who know this stuff better than we do,” Langner said.
The three of them huddled around a panel of monitors in their small office, talking through theories and testing hypotheses about what the code might be doing. They also closely studied the configuration in which Stuxnet operated: What device was the code talking to and was there more than one? Were the devices coupled in a distinct way?
It took three weeks to reach a startling conclusion — Stuxnet wasn’t just aimed at attacking a specific type of Siemens controller, it was a precision weapon bent on sabotaging a specific facility.
Embedded in Stuxnet’s code was a dossier detailing the specific technical configuration of the facility it sought. Any system that didn’t match precisely this configuration would go unharmed: Stuxnet would shut itself down and move on to the next system until it found its victim. It was clear to Langner that Stuxnet was the product of a well-resourced government with precise inside knowledge of the target it was seeking.
“I was expecting some dumb DoS type of attack against any Siemens PLC,” Langner later recalled. “So this was absolutely freaking. To see that somebody built such sophisticated piece of malware — using four zero-day vulnerabilities, using two stolen certificates — to attack one single installation? That’s unbelievable.”
Although the exact facility in Stuxnet’s sights wasn’t spelled out, Langner had no doubts. “This is about taking out Bushehr,” he announced to Rosen and Tim one day, referring to a nuclear power plant in Iran that had been scheduled to begin operation in August 2010 but had been delayed. Langner’s colleagues stared at him dumbfounded. They weren’t eager to follow him down a path of state-sponsored cyberwarfare that seemed likely to lead to Israel and the United States, and possibly even Germany, as the suspected aggressors behind Stuxnet.
Langner called a German client of his, who works for a top maker of uranium-enrichment equipment.
“I have one question for you,” Langner said to him. “Is it possible to destroy a centrifuge just by manipulating the controller code?”
“I can’t tell you that, Ralph, it’s classified information,” the man replied.
Langner was certain he was on the right track. He published a blog post on Sept. 16 boldly asserting that Stuxnet was a targeted attack against Bushehr, and issued press releases to German and international media outlets.
“There was silence all around us,” Langner later recalled. “Everybody was thinking, This guy is nuts. We always knew that Ralph is an idiot, and now we have the proof for it.”
Frank Rieger, chief technology officer at German security firm GSMK, agreed with Langner’s assertion that Stuxnet was a targeted attack, but thought a different nuclear facility in Iran made more sense as the target. Natanz, he noted in an online post, was already enriching uranium and presented a greater risk for producing nuclear weapons.
He also noted that in July 2009 — a month after Stuxnet is believed to have been launched — the secret-spilling site WikiLeaks made an intriguing announcement. WikiLeaks said that an anonymous source claimed that a “serious” nuclear incident had recently occurred at Natanz. The site also pointed out that the head of Iran’s Atomic Energy Organization had recently resigned for unknown reasons.
Both men had been warning for years that industrial controllers were ripe for attack, but few took them seriously. Because the systems were obscure and proprietary, and were designed to run on isolated, standalone networks, vendors and network administrators believed that hackers had neither the knowledge nor ability to breach them. But in recent years, the systems had increasingly become connected to the internet or networked with other systems that were online, making them an open and attractive target.
Langner went public with his discoveries in a series of blog posts. “With the forensics we now have it is evident and provable that Stuxnet is a directed sabotage attack involving heavy insider knowledge,” he wrote. “Here is what everybody needs to know right now.”
What followed was a technical road map explaining the precise steps Stuxnet took to intercept and inject commands into the PLC, along with a checklist of immediate steps administrators could take to help secure them. More posts followed as Langner’s team made additional discoveries about what Stuxnet was doing to the PLCs. His web site was besieged with traffic from around the world, including from United States government domains. Langner was performing a huge public service to help protect critical infrastructures. But he was also potentially destroying a critical covert mission.
Stuxnet was different from all of these. It wasn’t an evolution in malware, but a revolution. The idea that someone would create such a sophisticated worm to slither blindly through networks in search of a single target was “leaps and bounds” beyond what the Symantec researchers had expected. “I could work in this industry for another twenty years and never see another project like this,” O Murchu said recently.
Falliere had reverse-engineered the code that Stuxnet was injecting into the PLC and knew the malware was resetting the value of something connected to the device, but he had no idea what was on the receiving end of these commands or what the changed values would do. It was like watching tracer bullets fly through the night sky without seeing what they hit.
They had already discovered that the specific system Stuxnet targeted used the Profibus standard to communicate. They also noticed that the virus searched for a specific value — 2C CB 00 01 — before deciding to attack its target PLC. They had a hunch this might be some kind of ID the Step7 system assigned to a hardware part, so they set up a simulated Step7 PLC environment, and began plugging in parts. The reference value finally popped up when they attached a Profibus network card.
But there were two numbers Stuxnet sought that were still a mystery — 9500h and 7050h. Neither showed up when they plugged in hardware parts to their simulated system, nor did Google searches on the numbers produce anything.
Then a breakthrough came in November 2010.
The researchers had put out a request on their blog asking for anyone with experience in Profibus and critical infrastructures to contact them, and a Dutch programmer named Rob Hulsebos wrote back. Most of his e-mail discussed information the researchers already knew, but one line stood out. Every Profibus component had to have a unique ID that was a word long, Hulsebos wrote. It suddenly occurred to Chien that the two mystery numbers were manufacturer IDs.
He and O Murchu searched online for Profibus documentation and found a PDF with a list of specs for devices used with Profibus network cards. At the bottom of the list were the two mystery numbers Stuxnet sought. They were product IDs for two types of frequency converters made in Finland and Iran. The first, 9500h, referred to Vacon NX frequency converters made by Vacon in Finland, and the second, 7050h, referred to an unspecified frequency converter made by Fararo Paya in Iran.
Frequency converters modulate the speed of motors and rotors in things like high-speed drills that are used to cut metal parts in factories and in paper mills to force pulp through a grate. Increase the frequency of the drive, and the rotor increases its spin. In the Profibus documentation the researchers found online, they discovered a list of commands to control frequencies; they matched exactly the commands that were written in Stuxnet.
“The STL code [in Stuxnet] was sending down things like ‘word 47F and 1′,” Chien recalls. “And you look at the frequency converter [manual], and it says, ‘To start the frequency converter, send down the word 47F and set this value to 1. We were speechless.”
Based on information in the code, Stuxnet was targeting a facility that had 33 or more of the frequency converter drives installed, all operating at between 807Hz and 1,210Hz.
The malware would sit quietly on the system doing reconnaissance for about two weeks, then launch its attack swiftly and quietly, increasing the frequency of the converters to 1,410Hz for 15 minutes, before restoring them to a normal frequency of 1,064Hz. The frequency would remain at this level for 27 days, before Stuxnet would kick in again and drop the frequency down to 2Hz for 50 minutes.
The drives would remain untouched for another 27 days, before Stuxnet would attack again with the same sequence. The extreme range of frequencies suggested Stuxnet was trying to destroy whatever was on the other end of the converters.
Chien did a search online and discovered that frequency converters that operated at 600Hz and above were regulated for export in the United States by the Nuclear Regulatory Commission.
“We realized, wait a second, these things, at this frequency, could be used for uranium enrichment,” Chien recalls. Langner had gone out on a limb in asserting that Stuxnet was targeting centrifuges at a nuclear plant, but now Symantec had strong evidence to back it up.
At this point, Chien says, “We were not immune to the fact that there was a bigger geopolitical picture going on. We were definitely thinking … do I really want my name to be put on this [work]?”
All along, as they’d reached significant milestones in their research, they’d discussed whether they should release information anonymously or even withhold some of it entirely. But in the end, they’d always fallen on the side of disclosure, thinking the more information people had, the better they’d be able to protect themselves against this and copycat attacks that were bound to follow.
Remarkably, none of the company’s executives ever tried to halt their work on Stuxnet or censor anything they released. “Even to this day, we haven’t brought in lawyers,” Chien said. The company, took the view that “it’s a threat, it’s affecting people, we gotta look at it. I think that’s the bottom line for us, no matter what it is,” he said.
There was one point, however, that O Murchu said they might have censored their information had they reached it. “If it had got to the point where we had found 100 percent attribution who was behind it, I think we would have had some really serious conversations about [publishing] that,” he said.
In fact, Symantec made a couple of controversial forays into attribution. The first concerned an infection marker the researchers found in Stuxnet. When Stuxnet first infected a system, before installing its malicious files, it checked the Windows registry for the number 19790509. If the number was there, Stuxnet passed over the system and didn’t infect it — like lamb’s blood marking the door frames of Jewish homes in ancient Egypt to ward off the Death of the Firstborn plague.
The technique wasn’t new. Symantec had seen so-called “inoculation values” in other malware. Attackers would place them in the registry keys of their own computers to prevent their wildly spreading malware from infecting themselves.
But the researchers noticed that in this case the number resembled a date – May 9, 1979 — and suggested it might refer to the day an Iranian Jewish businessman named Habib Elghanian was executed by firing squad in Tehran. The execution was significant in Jewish history because it ultimately launched a mass exodus of Jews out of the Republic.
Then there was the word “myrtus” that appeared in a file path the attackers had left in one of Stuxnet’s drivers. The path — b:\myrtus\src\objfre_w2k_x86\:386\guava.pdb — showed where Stuxnet’s developers had stored the file on their own computers while it was being created. It’s not unusual for developers to forget to delete such clues before launching their malware.
In this case, the names “guava” and “myrtus” suggested possible clues for identifying Stuxnet’s authors. Myrtus is the genus of a family of plants that includes the guava, so it was possible the attackers had a love of botany. Or Myrtus could conceivably mean MyRTUs — RTUs, or remote terminal units, operate similarly to PLCs. Symantec mentioned both of these but also pointed out that myrtus might be a sly reference to Queen Esther, the Jewish Purim queen, who, according to texts written in the 4th century B.C.E., saved Persian Jews from massacre. Esther’s Hebrew name was Hadassah, which refers to myrtle.
Suspicions of course were growing that Israel and the U.S. were behind Stuxnet and had used the malware as a devious alternative to bombing Iran’s nuclear plant.
It should have been no surprise to the researchers, then, when their work drew the attention of government agencies in and outside the United States, that began asking for briefings on their findings. Symantec put together a PowerPoint presentation for the Department of Homeland Security, Defense Department, Department of Energy and FBI to answer their questions. “I joke that they already had all the answers,” Chien said. Asked if anyone from the NSA or CIA attended the PowerPoint sessions, he smiled. “If we ever did brief the NSA, we wouldn’t know, right?”
The political ramifications of their work took on even starker dimensions when, two weeks after they published their findings on the frequency converters, assassins on motorbikes attacked two Iranian nuclear scientists simultaneously in Tehran. The men were commuting to work on a Monday morning in separate parts of the city when the assassins zipped by their cars and attached bombs to them. Majid Shahriari, the top scientist and senior manager of Iran’s nuclear program, was killed. Fereydoun Abassi, a specialist with expertise in separating isotopes, crucial for making uranium fuel, was injured. Iran accused Israel’s Mossad spy agency of being behind the attacks.
Although the researchers didn’t really believe their lives were at risk for exposing Stuxnet, they laughed nervously as they recalled the paranoia and dark humor that crept into their conversations at the time. O Murchu began noticing weird clicking noises on his phone, and one Friday told Chien and Falliere, “If I turn up dead and I committed suicide on Monday, I just want to tell you guys, I’m not suicidal.”
The day news of the assassination plots broke, Chien joked to his colleagues that if a motorcycle ever pulled alongside his car, he’d take out the driver with a quick swerve of his wheels. When he left work that day and stopped at the first intersection, he was shaken — just for a moment — as he glanced in the rear-view mirror and saw a motorcycle pull up behind him.
The evidence that Langner and Symantec uncovered about Stuxnet provided a compelling case that the malware had been aimed at Iran’s nuclear program. But other than the excessive number of centrifuges that technicians were spotted removing from Natanz in early 2010, there was little proof that Natanz was its specific target or that the malware was indeed responsible for damaging the centrifuges that were removed.
Iran’s only statement on the malware had indicated that Stuxnet had infected personal computers belonging to workers at Bushehr, but that computers operating this or its other nuclear facilities were unaffected.
Then, on Nov. 23, Ali Akbar Salehi, head of Iran’s Atomic Energy Organization, provided what appeared to be the first acknowledgement that the worm had hit Iran’s nuclear facilities. “One year and several months ago, Westerners sent a virus to [our] country’s nuclear sites,” he told Iranian reporters, without mentioning the virus by name. He downplayed the virus’s success, however, asserting that vigilant workers had swiftly discovered the malware at its point of entry and prevented it from harming equipment.
Six days later, however, as if to mock Salehi’s statement and Iran’s skills at defending its nuclear program, the assassins on motorbikes struck the two Iranian nuclear scientists. In a press conference that day, Iranian President Mahmoud Ahmadinejad appeared to reference the virus Salehi had mentioned, and contradict him when he said that “enemies” of the state had indeed sabotaged Iran’s centrifuges with a malicious software program. “They succeeded in creating problems for a limited number of our centrifuges with the software they had installed in electronic parts,” he said, without naming Stuxnet or the facility that was attacked.
Then David Albright at the Institute for Science and International Security, which closely monitors Iran’s nuclear program, supplied a crucial bit of information linking Natanz and Stuxnet.
After reading the reports from Langner and the Symantec team, Albright revealed in December that the nominal frequency at which Natanz’s centrifuges operated was 1,064Hz — the exact frequency Stuxnet restored converters to after drastically increasing and decreasing it during the malware’s attack. Albright found one other correlation. Data in Stuxnet indicated that it was targeting devices configured in groups of 164; Albright noted that each of Natanz’s cascades had 164 centrifuges.
The mystery of Stuxnet’s target, and of the damaged centrifuges, seemed to be solved.
It had been a year since the IAEA inspectors had first spotted the centrifuges disappearing from Natanz, and they finally had the closest thing to an answer they were ever likely to get about what had occurred.
One looming question remained, however. Had Stuxnet succeeded in its goal?
If the malware’s aim had been to destroy centrifuges in Iran and cripple the country’s ability to produce a nuclear weapon, the consensus is that it failed. A physical attack would have been much more effective, though obviously much less stealthy or politically expedient. But if its intent was simply to delay and sow uncertainty in Iran’s nuclear program, then it appeared to succeed — for a time.
Earlier this year, the outgoing head of Israel’s Mossad said that unspecified malfunctions had set back Iran’s ability to produce a nuclear weapon until 2015. United States Secretary of State Hillary Clinton also said Iran’s nuclear program had been “slowed,” but added “[W]e have time. But not a lot of time.” Albright has noted that Iran has material to build only 12,000-15,000 centrifuges, and if 1,000 to 2,000 were destroyed, this would hasten the demise of its stockpile.
But his and other organizations have also noted that after the centrifuges were replaced, Iran stepped up its enrichment program and its overall production of uranium had actually increased in 2010, despite any effects Stuxnet may have had.
Stuxnet required an enormous amount of resources to produce, but its cost-benefit ratio is still in question. While it may have helped set Iran’s program back to a degree, it also altered the landscape of cyberattacks. Stuxnet’s authors mapped a new frontier that other attackers are bound to follow; and the next target for sabotage could easily be a nuclear facility in the United States.
No one knows what Stuxnet might have achieved had it never been discovered by VirusBlockAda a year ago. The code contains one attack sequence that researchers say was never enabled in any of the versions of Stuxnet they found. It appeared the attackers were still developing the code when it was uncovered.
They will likely have no second chance to unleash their weapon now. Langner has called Stuxnet a one-shot weapon. Once it was discovered, the attackers would never be able to use it or a similar ploy again without Iran growing immediately suspicious of malfunctioning equipment.
“The attackers had to bet on the assumption that the victim had no clue about cybersecurity, and that no independent third party would successfully analyze the weapon and make results public early, thereby giving the victim a chance to defuse the weapon in time,” Langner said.
In the end, Stuxnet’s creators invested years and perhaps hundreds of thousands of dollars in an attack that was derailed by a single rebooting PC, a trio of naive researchers who knew nothing about centrifuges, and a brash-talking German who didn’t even have an internet connection at home.
After all of the effort put into deciphering Stuxnet, the code itself still holds a couple of mysteries — two small encrypted files that researchers have yet to crack. One file is 90 bytes, and gets copied to every system Stuxnet infects. The other is 24 bytes and gets copied to Step7 machines when Stuxnet’s malicious DLL file gets installed. The two files could hold additional clues to Stuxnet’s aims or origins, but we might never discover them. Symantec’s researchers have tried repeatedly to crack their encryption, but have never succeeded.
Looking back over the year that was Stuxnet, Langner has called it career defining. “We understood this is the biggest story in malware ever. It was the best work that I have ever done.”
Full Story: http://www.wired.com/threatlevel/2011/07...d-stuxnet/
They did not speculate on the following which is notable:
* It was an attack against nuclear energy in general to demonize it further with carbon taxes and manufactured energy shortages on the line to promote green energy alternatives. Many of which Siemens is directly involved in.
* The fact Japan was running the same Siemens software at Fukushima.
* This could be corporate espionage against windows to bring in something new.
* This may not be state sponsored at all.
* The hardware may have been pre-infected
Stuxnet Attack on Fukushima - TheUglyTruth - 2011.03.15
Power and Control: The Anti-Nuclear Energy Movement - Leveraging the Japan Tsunami and Other Disasters
Do a forum search
for Siemens full-text .. the mega corporation has a hand in a lot of threads. Too many to list. But bear mind they are just a shell and can be scrapped for another one leaving the rich creamy centre unscathed.
There are no others, there is only us.