Experts Confirm the Fast16 Malware Was Sabotaging Nuclear Weapons Tests, Likely in Iran

Researchers have confirmed that a remarkable piece of malware discovered years ago but analyzed only recently was designed to subvert nuclear weapons testing simulations with the aim of undermining those tests and slowing the progress of a nuclear program. The new information, from researchers at the security firm Symantec, confirms what has only previously been speculated about the code by the company that first discovered it — SentinelOne. 

The malicious code, known as Fast16, was designed to subvert at least two specialized software programs that were commonly used for simulating weapons explosions at the time the code was active in 2005. It cleverly swapped out legitimate data produced by the simulation software, replacing it with false data that was fed to engineers monitoring those simulated tests. Specifically, it waited until the simulation neared the point of “supercriticality,” when the chain reaction leading to a nuclear explosion would begin, and altered data pertaining to the pressure inside the uranium core to indicate to engineers that the pressure was insufficient to achieve supercriticality, even though the real data showed otherwise.

This appears to have been aimed at tricking the engineers into believing the tests were less successful than they actually were, in order create confusion and slow the progress of the nuclear program Fast16 was targeting.

Nuclear experts say that based on details contained in the code and the period in which it was active, they are certain the target was Iran’s nuclear weapons program.

“While we cannot exclude other target countries working on nuclear weapons in the early 2000s, such as North Korea or possibly Syria, the timing, the access required [to create the malware] and the focus on uranium, point to Iran’s nuclear weapons efforts being the target,” David Albright, a physicist and founder and president of the Institute for Science and International Security, told Zero Day.

The way the code acted is not very different from Stuxnet, a virus created by the US and Israel to subvert centrifuges used by Iran to enrich uranium gas. That code, too, fed false data to operators to trick them into believing the centrifuges were fine, when they weren’t.

Fast16 only predates Stuxnet by about a year. Fast16 was developed in 2005 according to evidence in the code, and there is evidence that Stuxnet was under development during this same period, though it wasn’t unleashed on systems in Iran until 2007. There is evidence that Fast16 was likely also created by the US, Israel or another ally.

“While we cannot exclude other target countries working on nuclear weapons in the early 2000s, such as North Korea or possibly Syria, the timing, the access required [to create the malware] and the focus on uranium, point to Iran’s nuclear weapons efforts being the target.” David Albright

Although Stuxnet wasn’t unleashed until two years after Fast16, domains used as command-and-control servers to communicate with it were registered in November 2005, and in early 2006, a sabotage test was conducted with Stuxnet in the US, showing proof of concept. The results from that test were presented to President George Bush at the time, who authorized the covert sabotage operation once he understood that it could succeed. In May 2006, the developers of Stuxnet made updates to their code, and sometime in the fall of 2007 it was secretly installed on machines in Iran by a Dutch mole.

All of this suggests that if Fast16 did target Iran in 2005, and if the US or Israel were behind it, it did not predate Stuxnet, but was contemporaneous with Stuxnet and was part of a multi-pronged campaign by the US and its allies to subvert and slow Iran’s nuclear ambitions.

Stuxnet increased the pressure inside centrifuges and caused them to spin out of control, while feeding false data to operators to make them think the centrifuges were working fine. Fast16 took a different approach and fed operators false data about nuclear warheads testing to make engineers believe the tests were not fine, while in fact they may have been.

All of this suggests that the story of Fast16 is a new chapter in the west’s two-decade campaign to halt or destroy Iran’s nuclear program. 

How Fast16 Was Discovered

It’s not clear if the victims of Fast16 ever discovered the code on their systems, but its existence first came to the attention of Juan Andres Guerrero-Saade, senior technical fellow for research and innovation at SentinelOne, when it was mentioned in an NSA tool leaked online in 2017. The tool was just one of a tranche of NSA tools stolen by a mysterious group known as the Shadow Brokers. Fast16 code itself wasn’t among the leaks, but the context in which it was mentioned implied that it was created by the NSA or an ally. The fact that it was mentioned in this leak also supports the belief that Fast16 wasn't just proof-of-concept code that was never been used, but it had actually been unleashed on systems. When it was unleashed to infect systems, isn't known. But in October 2017, someone uploaded a sample of the code to a site called Virus Total, where it sat unnoticed for two years. Virus Total is used by security firms and victims of cyberattacks to upload suspicious files, where they are scanned by multiple anti-virus engines to see if they are malicious.

Last month, Guerrero-Saade and Vitaly Kamluk, an independent security researcher working on behalf of SentinelOne, announced that in 2019, Guerrero-Saade had found the Fast16 sample, and after years of trying but failing to decipher the code, he and Kamluk used AI to finally determine what it was designed to do. The code, they said, was subverting software applications used for performing high-precision mathematical calculations, and concluded that it was likely targeting software used for conducting simulated tests of physical properties that required high precision.

All of this suggests that if Fast16 did target Iran in 2005, and if the US or Israel were behind it, it did not predate Stuxnet, but was contemporaneous with Stuxnet and was part of a multi-pronged campaign by the US and its allies to subvert and slow Iran’s nuclear ambitions.

Although Guerrero-Saade and Kamluk didn’t know which simulation software Fast16 was targeting or what tests it was attempting to disrupt, they speculated that it was most likely trying to undermine software being used for simulating nuclear weapons explosions. They suggested three possible software programs that could be the target: Modelo Hidrodinâmico, commonly used for modeling water systems, a program out of China called PKPM, and the US-made LS-DYNA. Iran is known to have used LS-DYNA to do work in explosives research, leading SentinelOne’s researchers to believe this was Fast16’s most likely target.

Now new analysis this week from researchers with the Threat Hunter Team at Symantec — who were also responsible years ago for determining that Stuxnet was designed to do — confirms that LS-DYNA was indeed one of the software programs targeted by Fast16 and that it was aimed at subverting simulated tests of nuclear explosions. The team are publishing their research today, which provides details on how Fast16 worked to subvert such tests. Albright’s Institute for Science and International Security is also posting analysis today.

According to Vikram Thakur, technical director for Symantec,  and Eric Chien, a fellow in Symantec's security technology and response division, Fast16 targets at least two software simulation programs — LS-DYNA and AUTODYN. It may also target one other program, though the Symantec researchers were unable to identify it from the code.

LS-DYNA was developed in the 1970s at Lawrence Livermore National Laboratory and turned into a commercial product in the 1980s. It’s used to evaluate physical phenomena such as the strength of metals and impact from collisions, such as car and plane crashes. But it’s also used to model the types of high compression needed for nuclear warheads. AUTODYN is a similar software distributed by Ansys, the same company that now owns LS-DYNA. Both programs are used to simulate the same kinds of things and, according to various academic publications, both were being used in Iran during the time that Fast16 would have been active, Albright says.

Although the programs can be used for various types of simulations, Fast16 is singularly focused, and is only interested in the programs when they are modeling high-explosive detonations. Fast16 determines which software is being used, and only engages when it’s sure the program is simulating a high-explosive detonation and using one of three models to do so.

Nuclear explosions can be simulated using a number of different mathematical models developed over the years by engineers and physicists. These models differ by the level of pressure, volume and density being simulated in them and the various states of change that occur as a result of the interaction between these elements. The LS-DYNA and AUTODYN programs allow users to choose which model they want for a particular simulation, and Fast16 only engages if one of three specific models is being used. Before going into what Fast16 does, it’s important to understand the context around which it was unleashed.

Iran’s Nuclear Program

In August 2002, the National Council of Resistance, an Iranian dissident group, held a press conference in Washington, DC, to reveal that Iran had an illicit nuclear weapons program, which involved secret facilities in a number of locations around the country. It’s believed that they received this information from western intelligence agencies who had been tracking the program.

The Atomic Energy Agency, the UN body responsible for monitoring nuclear programs around the world, demanded access to the locations, and in February 2003, were able to visit them for the first time. The inspectors determined that Iran had not fully revealed its nuclear program to the IAEA, as required under the Nuclear Non-Proliferation Treaty it had signed, and that the program was much further along than they had anticipated. The inspectors also suspected that Iran wasn’t just enriching uranium for a nuclear power plant, as Iran insisted, but had a nuclear weapons program. Although the inspectors did find some indications of a small nuclear weapons program during their visit, they didn’t know its scope and missed that Iran actually had a much large nuclear weapons effort in progress, codenamed the Amad Project. 

The US and other countries pressured Iran to suspend its nuclear program until the IAEA could gather more information about it, to determine how far along the program was and how far Iran might be from having a fully stocked enrichment hall, as well as enough enriched uranium to make a nuclear bomb.

In November 2004, Iran agreed to a suspension while it engaged in negotiations with the EU. But in early August 2005, the talks reached an impasse, and Iran announced that it was withdrawing from the suspension agreement and proceeding with its nuclear program, including enriching uranium gas for the first time at a centrifuge facility outside of Natanz.

By then, the Fast16 code had already been in development for a while, based on evidence in the code, as were plans for Stuxnet. On August 30, the Fast16 code was compiled, according to timestamps contained in it. Although earlier versions of the code may exist, this is the only one that’s been uncovered by researchers so far.

Albright notes that between 2003 and 2005, intelligence agencies believed that Iran had an active nuclear weapons program, and that simulation teams were engaged in modeling nuclear explosions. A US intelligence assessment would later assert in 2007 that Iran halted the weapons part of its nuclear program in 2003, but intelligence agencies in Israel and Germany have long insisted that while this was true, Iran revived the program in 2005.

Albright believes it was revived, but in a much different form. Funding for the program was mostly diverted to other things, and he says the program continued at a reduced scale. He believes research continued, but there was no kinetic testing — just computer simulations, such as those that could be conducted using the LS-DYNA software. This made the software simulations especially important in the absence of alternative means of testing, and it also made them a choice target for intelligence agencies.

According to Iranian documents Israel obtained in 2018, Iran’s nuclear weapons program had already been encountering problems before it stopped in 2003 due to design issues and insufficient scientific knowledge. Albright says these problems likely “persisted into the time when [Fast16] was active.” 

Fast16 at Work

SentinelOne has already described in their research some of what Fast16 does when it first infects a system. It looks for the presence of 18 different security products on the system, and if it finds one of these, it won’t infect the computer. It also automatically spreads to other computers on the same network so that any computer that’s used to run the simulations will produce the same manipulated results. Fast16 also contains support for 8 to 10 different versions of the LS-DYNA software, so that regardless of which version a computer is using, Fast16 will be able to subvert it. 

The Symantec researchers have added some new details around this. According to Thakur, code for these various versions was not added at the same time or even sequentially as new versions of the LS-DYNA software were released. Instead, it appeared to be added out of sequence, suggesting that the developers were adding support for different versions over time. This raises the possibility that they were receiving ongoing intelligence whenever engineers switched the version of the simulation software they were using. They believe as Fast16 did its work to manipulate test results, engineers may have believed the software was the problem and switched to older or newer versions of the LS-DYNA program to see if the results improved.

Once the malware determined that the right simulation software was running, it would wait for indications that a high-precision explosives test, matching various parameters, was running. Once the test began, Fast16 waited for a specific stage in the explosives simulation. 

At the time, Iran was developing and testing high-explosive components for a spherical implosion nuclear weapon. The way such weapons work is that high explosives are packed around a spherical uranium core and ignited. This which creates a shockwave that propels a so-called metal “flyer plate” to strike the uranium core like a hammer with tremendous force. This compresses the core into a highly pressurized and high-temperature state, which causes neutrons to leak from the uranium. In such a pressurized state, those neutrons collide with nuclei, and cause those nuclei to split and leak more neutrons. These neutrons in turn strike other uranium nuclei in a chain reaction, creating a nuclear explosion.

To test such explosions, Iran used simulation software to determine how many explosives and how much pressure was needed to achieve the “supercriticality” state that causes a chain reaction to occur.

Simulation software helps capture this extremely rapid process through streams of data and graphs, allowing engineers to study it and run different models to see how changing variables like pressure, density, and temperature increase as the compression occurs. This is where Fast16 came in. 

The malware would monitor the density of the uranium core, according to Symantec and Albright, and when that value reached 30 grams per cubic centimeters — a point slightly below the density at which compressed uranium starts to become liquid — Fast16 would begin to swap out real data about the density of the core, before it appeared on the graphs that engineers were monitoring, and replace it with false data that indicated that key variables, such as pressure, were lower than they should be. The engineers might conclude from this that their design had failed and that the uranium core had failed to reach supercriticality.

Albright says the changes on the graph would likely not have appeared unusual to engineers if the malware lowered the correct values by just 1 to 5 percent. But it would still cause them to believe there had been insufficient force applied to the core to achieve supercriticality. The engineers might think they needed to change mathematical calculations or apply more explosive force to compress the uranium core in a fruitless endeavor to achieve the results they were seeking.

But if they added explosives to apply more force against the core or changed other variables to increase the compression, this could have created more problems, Albright says. And any time they ran another simulation, they would still not get the results they expected. 

“We’re thinking it could have been very disruptive,” Albright says. “The effect would be to waste time, resources, and lower the overall morale of the program.”

What they likely would not have done, was think the computer or software had been subverted. Today, in the wake of Stuxnet, it might seem obvious for someone to suspect this. But back in 2005, Thakur notes, computers were still considered mostly trustworthy.

But even if they tried to use a different computer, because Fast16 spread to computers across the internal network they would get the same results.

Albright highly doubts that faulty calculations would have made their way into real systems causing something to explode in unintended ways. Instead, he says, the engineers would have noticed they were getting bad results and been frustrated by repeated failed attempts to resolve the issues. This could have undermined confidence in their designs and potentially created tension and conflict among team members as they tried to fix a problem that didn’t exist. Such frustration could have led to significant delays in the nuclear bomb-making program.

All of this suggests that the goal wasn’t to sabotage a completed bomb, but to prevent one from ever being made — at least long enough to bring Iran back to the negotiation table.

The latter was in fact the aim of Stuxnet. This malicious code wasn’t designed for one-time catastrophic damage to destroy all of Iran’s centrifuges; it was aimed at doing incremental damage over time, in a way that prevented engineers from pinpointing the problem — all with the aim of slowing down the enrichment program in order to buy time to get Iran back into negotiations.

Fast16 and Stuxnet in a League of Their Own

Although Fast16 is deceptively simple malware, the Symantec researchers say it’s in an “exclusive league,” because it required deep expertise and understanding of the software and nuclear process it was targeting as well as understanding of the materials being tested and the precise data changes needed to achieve their desired effect.

“The level of expertise required to [create it], and then of course the human effort to execute it, was massive,” Thakur says.

The knowledge and skill needed to pull it off would be unusual in any era, but the fact that it was developed in 2005, he says, is “mind-blowing.”

That said, Stuxnet is still the most advanced malware Thakur and his colleagues have every seen. But both Stuxnet and Fast16 share the same conceptual framework. The attackers needed to get into difficult-to-reach environments, they had to understand with certainty how that environment worked, and they had to implement precision changes to achieve their goal. They also had to do this without being detected.

The revelations about Fast16 are a reminder to Iranian decision makers and nuclear engineers that nothing in the program is out of reach or safe from digital sabotage.

Stuxnet remained undetected for three years. It was only after it began spreading to systems outside of Natanz, and causing those machines to crash, that it was discovered. 

Even after it’s discovery, however, it continued to undermine the nuclear program in a different way: it undermined the confidence Iranian engineers had in computers and equipment being used in the nuclear program and it made them suspicious, any time they experienced a glitch, that sabotage might be the cause. The same applies to Fast16.

The new revelations about it come at a significant time — when the US and Israel continue to try to eliminate Iran's nuclear program.

Kinetic attacks on Iran have so far not succeeded in completely eliminating the program, but as the US and Iran pressure Iran to make a deal to end, or at least pause the program for many years, the revelations about Fast16 are a reminder to Iranian decision makers and nuclear engineers that nothing in the program is out of reach or safe from digital sabotage.

For paid subscribers: To see a timeline of key dates and events around Stuxnet, Fast16 and Iran’s nuclear program click here

See also:

Countdown to Zero Day: Stuxnet and the Launch of the World’s First Digital Weapon

Leaked Files Show How the NSA Tracks Other Countries’ Hackers