Stuxnet: The worlds first digital weapon.

ICS-CERT has confirmed the malware installs a trojan that interacts with installed SIMATIC® WinCC or SIMATIC® Siemens STEP 7 software and then makes queries to any discovered SIMATIC® databases. The full capabilities of the malware and intent or results of the queries are not yet known.

ICS-CERT Advisory ICSA-10-238-01B

What is Stuxnet?

In 2010, a computer in Iran started repeatedly rebooting itself, seemingly without reason. Suspecting some kind of malicious software, analysts at VirusBlokAda, an antivirus-software company in Minsk, examined the misbehaving machine over the Internet, and soon found that they were right. Disturbingly so: the code they extracted from the Iranian machine proved to be a previously unknown computer virus of unprecedented size and complexity. On June 17th, 2010, VirusBlokAda issued a worldwide alert that set off an international race to track down what came to be known as Stuxnet: the first ever cyber warfare weapon.

Not only was Stuxnet much more complex than any other piece of malware seen before, it also followed a completely new approach that’s no longer aligned with conventional confidentiality, integrity, and availability thinking. Contrary to initial belief, Stuxnet wasn’t about industrial espionage: it didn’t steal, manipulate, or erase information. Rather, Stuxnet’s goal was to physically destroy a military target-not just metaphorically, but literally.

Stuxnet is believed to be the first malware targeted specifically at critical infrastructure systems. It’s thought to have been designed to shut down centrifuges at Iran’s Natanz uranium enrichment plant, where stoppages and other problems reportedly occurred around that time. A New York Times report cited sources who said that Stuxnet was part of a U.S.-Israeli operation dubbed “Operation Olympic Games,” that was begun while President George W. Bush was in office as an attempt to sabotage Iran’s nuclear program. The sophisticated worm spreads via USB drives and through four previously unknown holes, known as zero-day vulnerabilities, in Windows. It used two stolen digital certificates, was aimed at Siemens supervisory control and data acquisition (SCADA) systems that were configured to control industrial processes, and infected programmable logic controllers.

Stuxnet represents the first of many milestones in malicious code history – it is the first to exploit four 0-day vulnerabilities, compromise two digital certificates, and inject code into industrial control systems and hide the code from the operator. Whether Stuxnet will usher in a new generation of malicious code attacks towards realworld infrastructure—overshadowing the vast majority of current attacks affecting more virtual or individual assets—or if it is a once- in-a-decade occurrence remains to be seen.

“I think it’s pretty clear that the United States government did the Stuxnet attack… I think that the attack proved what I was saying before the attack was known, which is that you can cause real devices—real hardware in the world, in real space, not cyberspace—to blow up.”

Richard ClarkeFormer National Coordinator for Security, Infrastructure Protection, and Counter-terrorism for the U.S. State Department.

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.

David AlbrightInstitute for Science and International Security

“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.”

Ralph LangnerThe Langner Group, independent cyber defense consultancy.

The target: Natanz Fuel Enrichment complex

The Natanz Fuel Enrichment complex is the primary site of Iran’s gas centrifuge program. It contains two primary facilities: the Pilot Fuel Enrichment Plant (PFEP) and the Fuel Enrichment Plant (FEP). It also houses a centrifuge assembly area.

On March 30, 2005, then President Mohammad Khatami toured the Natanz site accompanied by the media.This tour produced the first publicly available ground images of Natanz. A subsequent visit by President Mahmoud Ahmadinejad in 2008 led to many images of the complex and centrifuges in the pilot plant. The Natanz facility was first publicly identified by the National Council for Resistance of Iran (NCRI) in August 2002. At that time, NCRI identified the facility as a nuclear fuel fabrication plant. In December 2002, ISIS released satellite photos of the facility for the first time and correctly identified the site as a gas centrifuge enrichment facility.

The Natanz Fuel Enrichment Plant (FEP) is Iran’s largest gas centrifuge uranium enrichment facility. It consists of three large underground buildings, two of which are designed to be cascade halls to hold 50,000 centrifuges. The buildings started as 70 foot deep holes, and satellite imagery showed the construction of thick concrete walls. The FEP began operating in February 2007, and construction on centrifuge cascades is ongoing. The FEP ostensibly exists to produce enriched uranium for light water reactors in Iran, including the Bushehr facility and others that Iran has not yet built.

Iran uses the FEP to produce 3.5 percent low-enriched uranium (LEU) for its nuclear program. Until early 2013, it installed only IR-1 centrifuges in single 174- and 164- machine cascades. Iran announced to the IAEA on January 23, 2013 that it intended to install IR-2m advanced centrifuges at the FEP.

The Pilot Fuel Enrichment Plant (PFEP) is Iran’s centrifuge research and development facility which uses uranium hexafluoride. Iran has other facilities, mostly unknown publicly, which conduct important tests of centrifuges without introducing uranium hexafluoride. More is known about the PFEP than other centrifuge manufacturing facilities because its use of uranium hexafluoride requires inspections by the IAEA, which then reports publicly on activities there.

In 2002, Iran moved gas centrifuge research, development, and assembly operations to this facility from Kalaye Electric, its then secret site near Tehran. The PFEP is an above-ground building at the Natanz Fuel Enrichment complex. Iran tests centrifuges of various models, including its deployed IR-1 and IR-2m, but also more advanced designs, in single machine, small cascades, and production-scale cascades at the PFEP. Typically, in the test cascades, Iran recombines the product and tails from these cascades, so no enriched uranium is produced.

Since February 2010, Iran has produced 19.75 percent enriched uranium in a set of two, 164-machine IR-1 cascades oriented in tandem, ostensibly for the Tehran Research Reactor (TRR). One of these cascades enriches from 3.5 percent LEU to almost 20 percent low enriched uranium (LEU), while the second one takes the tails from the first and outputs roughly 10 percent LEU and a tails of natural uranium. The ten percent material is fed into the first cascade in addition to 3.5 percent LEU. This process allows Iran to more efficiently use its 3.5 percent LEU stock.

Stuxnex: Under the hood


There is abundant evidence confirming that the Stuxnet attack was a carefully prepared attack.The ultimate goal of Stuxnet is to sabotage facilities by reprogramming programmable logic controllers (PLCs) to operate as the attackers intend them to, most likely out of their specified boundaries. Stuxnet contains many features such as:

Self-replicates through removable drives exploiting a vulnerability allowing auto-execution.

Spreads in a LAN through a vulnerability in the Windows Print Spooler.

Spreads through SMB by exploiting the Microsoft Windows Server Service.

Copies and executes itself on remote computers through network shares.

Copies and executes itself on remote computers running a WinCC database server.

Copies itself into Step 7 projects in such a way that it automatically executes when the Step 7 project is loaded.

Updates itself through a peer-to-peer mechanism within a LAN.

Exploits a total of four unpatched Microsoft vulnerabilities, two of which are previously mentioned vulnerabilities for self-replication and the other two are escalation of privilege vulnerabilities that have yet to be disclosed.

Contacts a command and control server that allows the hacker to download and execute code, including updated

Contains a Windows rootkit that hide its binaries.

Attempts to bypass security products.

Fingerprints a specific industrial control system and modifies code on the Siemens PLCs to potentially sabotage the system.

Hides modified code on PLCs, essentially a rootkit for PLCs.

The main module is represented as a large DLL packed with UPX. Its unpacked size is 1233920 bytes (1.18 MB). There are four ways the rootkit can distribute itself: by means of flash drives, through network shares, through an RPC vulnerability and through the recently patched MS10-061 Print Spooler vulnerability.

The timestamp in the file ~wtr4141.tmp indicates that the date of compilation was 03/02/2010. Version 9.0 of the linker indicated that attackers used MS Visual Studio 2008 for developing Stuxnet’s components. File ~wtr4141.tmp is digitally signed, and the timestamp indicates that the signature on the date of signing coincides with the time of compilation.Examination of the driver is even more interesting, since the timestamp of MRXCLS.sys indicates that it was compiled on 01/01/2009. An 8.0 version of the linker used to build it suggests that MS Visual Studio 2005 was for development. Using different versions of the linker may indicate as well that this project was developed by a group of people with a clear division of responsibilities. The digital signature shows a later date 25/01/2010, indicating that this module, was available very early on, or was borrowed from another project.

On July 17th, ESET identified a new driver named jmidebs.sys, compiled on July 14th 2010, and signed with a certificate from a company called “JMicron Technology Corp”. This is different from the previous drivers which were signed with the certificate from Realtek semiconductor Corp. It is interesting to note that both companies whose code signing certificates were used have offices in Hsinchu Science Park,Taiwan. The physical proximity of the two companies may suggest physical theft, but it’s also been suggested that the certificates may have been bought from another source. For instance, the Zeus botnet is known to steal certificates, though it probably focuses on banking certificates.

The file jmidebs.sys functions in much the same way as the earlier system drivers, injecting code into processes running on an infected machine. As Pierre-Marc Bureau pointed out in a blog at the time, it wasn’t clear whether the attackers changed their certificate because the first one was exposed, or were simply using different certificates for different attacks. Either way, they obviously have significant
resources to draw on. The well-planned modular architecture that characterizes the Stuxnet malware, and the large number of modules used, suggests the involvement of a fairly large and well-organized group.The number of modules included in Stuxnet and the bulkiness of the developed code indicate that this malicious program was developed by a large group of people.

While Stuxnet exploits several Windows vulnerabilities, at least four of them described as 0-day:

MS08-067 RPC Exploit

MS10-046 LNK Exploit

MS10-061 Spool Server Exploit

Two privilege escalation (or Elevation of Privilege) vulnerabilities:

MS10-073 Win32k.sys Exploit

MS10-092 Task Scheduler Exploit

However, it also targets PLCs (Programming Logic Controllers) on sites using Siemens SIMATIC WinCC or STEP 7 SCADA (Supervisory Control And Data Acquisition) systems.

To access a PLC, specific software needs to be installed; Stuxnet specifically targets the WinCC/Step 7 software used for programming particular models of PLC. With this software installed, the programmer can connect to the PLC via a data cable and access the memory contents, reconfigure it, download a program onto it, or debug previously loaded code. Once the PLC has been configured and programmed, the Windows machine can be disconnected and the PLC will function by itself.

The Step 7 software uses a library file called s7otbxdx.dll to perform the actual communication with the PLC. The Step7 program calls different routines in this DLL when it wants to access the PLC. For example, if a block of code is to be read from the PLC using Step 7, the routine s7blk_read is called. The code in s7otbxdx.dll accesses the PLC, reads the code and passes it back to the Step7 program.

Let’s now take a look at how access to the PLC works when Stuxnet is installed. When executed, Stuxnet renames the original s7otbxdx.dll file to s7otbxsx.dll. It then replaces the original DLL with its own version. Stuxnet can now intercept any call that is made to access the PLC from any software package.

Stuxnet ’s modified s7otbxdx.dll file contains all potential exports of the original DLL – a maximum of 109 – which allows it to handle all the same requests. The majority of these exports are simply forwarded to the real DLL, now called s7otbxsx.dll, and nothing untoward happens; in fact, 93 of the original 109 exports are dealt with in this manner. The trick, however, lies in the 16 exports that are not simply forwarded but are instead intercepted by the custom DLL. The intercepted exports are the routines to read, write, and locate code blocks on the PLC. By intercepting these requests Stuxnet is able to modify the data sent to or returned from the PLC without the operator of the PLC ever realizing it. It is also through these routines that Stuxnet is able to hide the malicious code that is on the PLC.

Target objects: overpressure relief valves, which hold a protective rather than productive function. They do not act as inter-stage shutoffs that would isolate individual stages, allowing the machine to continue to operate after infection.

SCADA control screen for the next-generation IR-2 cascade with 15 enrichment stages, connected to Siemens S7-417 PLCs, which play a major role in the Stuxnet 417 attack sequence.

To understand how Stuxnet accesses and infects a PLC we will first mention the types of data present. PLCs work with blocks of code and data which are loaded on to the PLC by the operator. For the sake of understanding, we will briefly explain what the most common types of blocks are and what they do:

Data Blocks (DB) contain program-specific data, such as numbers, structures and so on.

System Data Blocks (SDB) contain information about how the PLC is configured; these are created depending on the number/type of hardware modules that are connected to the PLC.

Organization Blocks (OB) are the entry point of programs. They are executed cyclically by the CPU. In regards to Stuxnet, two notable OBs are:

OB1 is the entry-point of the PLC program. It is executed cyclically, without specific time requirements.

OB35 is a standard watchdog Organization Block, executed by the system every 100ms. This function may contain any logic that needs to monitor critical input in order to respond immediately or perform functions in a time critical manner.

Function Blocks (FC) are standard code blocks. They contain the code to be executed by the PLC. Generally, the OB1 block references at least one FC block.

The following sections detail the previously mentioned four main aspects of the threat.

1. Determining which PLCs to infect.

Stuxnet infects PLCs with different code depending on the characteristics of the target system.
An infection sequence consists of PLC blocks (code blocks and data blocks) that will be injected into the PLC to alter its behavior. The threat contains three infection sequences.Two of these sequences are very similar, and functionally equivalent. We dubbed these two sequences A and B. The third sequence was named sequence C. Stuxnet determines if the system is the intended target by fingerprinting it. It checks:

The PLC type/family: only CPUs 6ES7-417 and 6ES7-315-2 are infected

The System Data Blocks: the SDBs will be parsed, and depending on the values they contain, the infection process will start with method of infection A, B or none. When parsing the SDBs the code searches for the presence of 2 values (7050h and 9500h), and depending on the number of occurrences of each of these values sequence A or B is used to infect the PLC. The code also searches for the bytes 2C CB 00 01 at offset 50h in the SDB blocks, which appear if the CP 342-5 communications processor (used for Profibus-DP) is present. If these bytes are not found then infection does not occur. Infection conditions for sequence C are determined by other factors.

The function ADD_AC, FC1874 returns the magic value 0xDEADF007 to signal a successful infection.

2. Method of infection

Stuxnet uses the code-prepending infection technique. When Stuxnet infects OB1 it performs the following sequence of actions:

Increases the size of the original block

Writes malicious code to the beginning of the block

Inserts the original OB1 code after the malicious code

As well as infecting OB1, Stuxnet also infects OB35 in a similar fashion. It also replaces the standard coprocessor DP_RECV code block with its own, thereby hooking network communications on the Profibus (a standard industrial network bus used for distributed I/O).

The overall process of infection for methods A/B is as follows:

Check the PLC type; it must be an S7/315-2
Check the SDB blocks and determine whether sequence A or B should be written
Find DP_RECV, copy it to FC1869, replace it with a malicious copy embedded in Stuxnet
Write the malicious blocks (in total, 20 blocks) of the sequence, embedded in Stuxnet
Infect OB1 so that the malicious code is executed at the start of a cycle
Infect OB35, which will act as a watchdog

3. Infection code

The code inserted into the OB1 function is responsible for starting infection sequences A and B. These sequences contain the following blocks:

Code blocks: FC1865 though FC1874, FC1876 through FC1880
(Note that FC1869 is not contained within Stuxnet but is instead a copy of the original DP_RECV block found on the PLC)

Data blocks: DB888 through DB891.
Sequences A and B intercept packets on the Profibus by using the DP_RECV hooking block. Based on the values found in these blocks, other packets are generated and sent on the wire. This is controlled by a complex state machine (implemented in the various FC blocks mentioned above). This machine can be partially controlled by the DLL via the data block DB890.

Under certain conditions the sequence C is written to a PLC. This sequence contains more blocks than A/B:

FC6055 through FC6084
DB8062, DB8063
DB8061, DB8064 through DB8070, generated on the fly
Sequence C is meant to read and write I/O information (Input/Output) to the memory-mapped I/O areas of the PLC, as well as the peripheral I/O.

4. The rootkit

The Stuxnet PLC rootkit code is contained entirely in the fake s7otbxdx.dll. In order to achieve the aim of continuing to exist undetected on the PLC it needs to account for at least the following situations:

Read requests for its own malicious code blocks

Read requests for infected blocks (OB1 , OB35, DP_RECV)

Write requests that could overwrite Stuxnet’s own code

Stuxnet contains code to monitor for and intercept these types of requests The threat modifies these such requests so that Stuxnet’s PLC code is not discovered or damaged. The following list gives some examples of how Stuxnet uses the hooked exports to handle these situations:

s7blk_read: read requests are monitored, and Stuxnet will return:
The real DP_RECV (kept as FV1869) is requested
An error if the request regards its own malicious blocks
A cleaned version (disinfected on the fly) copy of OB1 or OB35
s7blk_write: write requests to OB1/OB35 are monitored to make sure the new versions of these are infected.
s7blk_findfirst / s7blk_findnext: these routines are used to enumerate blocks on a PLC. Malicious blocks will be voluntarily “skipped”.
s7blk_delete: deletion of blocks is also monitored

Stuxnet is thus able to ensure its continuing presence on the PLC.

Flame, Duqu & Gauss

The Stuxnet cyber weapon that was designed to cripple control systems in Iran’s nuclear plant was just one of five weapons engineered in the same lab according to Kaspersky’s director of global research, Costin Raiu. These Lego-like weapons work as modules, in that they are designed to fit together with each having different functions. They were developed on a single platform whose roots trace back at least to 2005; the creators have used the same software development environment ever since.

The Duqu worm emerged in September 2011, and researchers say it shares a lot of code with Stuxnet but is designed for a different purpose: stealing data for surveillance or other intelligence efforts. It hit computers in Iran but did not appear to be directed at industrial or critical infrastructures specifically. Duqu exploits zero-day Windows kernel vulnerabilities, uses stolen digital certificates, installs a backdoor, and captures keystrokes and information that could be used to attack industrial control systems.

“We believe it could be a cyberespionage operation to gauge the status of Iran’s nuclear program,” Roel Schouwenberg, senior researcher at Kaspersky Lab.

The Gauss surveillance malware was launched around September 2011. The malware was found on computers mostly in Lebanon, Israel, and Palestine, followed by the U.S. and the United Arab Emirates. Gauss is capable of stealing browser passwords, online banking accounts, cookies, and system configurations. Kaspersky says it comes from the same nation-state “factories” that produced Stuxnet, Duqu, and Flame.

Flame was discovered in May 2012 during Kaspersky Lab’s investigation into a virus that had hit Iranian Oil Ministry computers in April. Kaspersky believes the malware, which is designed for intelligence gathering, had been in the wild since February 2010, but CrySyS Lab in Budapest says it could have been around as far back as December 2007.

Most of the infections were in Iran, but other countries hit were Israel, Sudan, Syria, Lebanon, Saudi Arabia, and Egypt. Flame uses a fraudulent digital certificate and spreads via USB stick, local network, or shared printer spool vulnerability and leaves a backdoor on computers. It can sniff network traffic and record audio, screenshots, Skype conversations, and keystrokes, as well as download information from other devices via Bluetooth. It appears to be designed for general espionage and not targeted at any particular industry. Most of the infections were reported to be in Iran and appeared to involve stealing PDF, text, and AutoCAD files . Flame shares characteristics with Stuxnet and Duqu. It also was developed as part of the Olympic Games project along with Stuxnet, according to a report in The Washington Post.

The Stuxnex source code

The Win32/Stuxnet worm: perhaps the most technologically sophisticated malicious program developed for a targeted attack to date.


The data contained within is to be used for research purposes only!

© Copyright - Dave Schull - Anchorage, Alaska
// Remove image name on Hover