A Nine-Year Retrospective and Reflections on the Stuxnet Incident

May 27, 2026 By Antiy PTA Team Security Response -

1. Preface

In July 2010, the Stuxnet worm attack came to light, drawing widespread attention from major international security vendors and researchers. Kaspersky, Symantec, Antiy, and other security companies, renowned security researchers like Ralph Langne, and emergency response organizations and research institutions from multiple countries all participated in a comprehensive analysis. This ultimately revealed numerous details of the attack: it was a long-planned, pre-planned, and covert intrusion operation; it utilized highly sophisticated malicious code and multiple zero-day vulnerabilities as its weapons; it targeted uranium centrifuges; and its effective mechanism was to cause overpressure leading to mass damage to centrifuges and to alter centrifuge speeds to prevent uranium from meeting weapons requirements, with the ultimate goal of disrupting Iran’s nuclear weapons program.

Nine years have passed, and this security incident is still in Antiy’s research field. Antiy started its analysis of Stuxnet on July 15, 2010, built a simulation environment, and released the “Comprehensive Analysis Report on the Stuxnet Worm Attack on Industrial Control Systems” [1] on September 27. Subsequently, it formed the “Follow-up Analysis Report on the Stuxnet Worm” [2], which analyzed its propagation mechanism, and the “What Happened After WinCC” [3] series of analysis reports, which analyzed its mechanism of action on industrial production processes.

Antiy Labs proposed the hypothesis that Stuxnet and Duqu share a common origin, and subsequently published two confirming reports. They also initiated a marathon-like modular analysis of the Flame malware. As their work progressed, Antiy Labs gradually realized that highly complex malware such as Stuxnet, Duqu, Gauss, and Flame shared common background connections. This research played a crucial role in Antiy Labs’ subsequent in-depth analysis of Equation Organization.

Due to historical reasons, some of the research literature has not been published, and some analytical progress is fragmented. Although it has been mentioned in our external technical presentations, it has not been released as literature. This is one of the reasons why Antiy Labs compiled this paper. The chapters that organize the relationships between Stuxnet, Flame, Poison, Gaussian, Fanny, and Flowershop, which illustrate the overall operational framework of Stuxnet, the USB ferry mechanism and propagation runaway analysis, as well as the relationship between the Tilded framework and the Flame framework, are a summary of these results.

In retrospect, our initial analysis of the Stuxnet incident revealed a lack of a truly framework-based methodology. We were still largely viewing the attack from our familiar anti-malware perspective. While we coined the term A2PT (Advanced Persistent Threat) to describe such a complex attack as Stuxnet, our analysis consistently lacked an operational-to-strategy perspective. Under the guidance of experts, we have gained new insights into cyber warfare and situational awareness, gradually shifting our methodology from a threat framework perspective to improve our capabilities. We also hope to interpret the seemingly still highly complex “war of yesterday”—the Stuxnet attack—through this threat framework lens.

This article also delves into a thought-provoking question: why does Stuxnet, a worm without infectious properties, have such a large number of samples? We discovered this principle in our earlier analysis: Stuxnet’s payload delivery program performs a self-update of embedded configuration data each time it lands on a machine. This results in a different hash for the main executable each time Stuxnet lands, while its actual attack payload is mostly wrapped within the main DLL and not actually landed. Stuxnet’s related domains are only exposed after it has achieved its main operational effect. This, in a sense, indicates that threat intelligence based on hashes and domains is already facing the risk of ineffectiveness against more sophisticated and covert attacks.

Figure 1-1 Stuxnet Timeline

2. Why Stuxnet?

Throughout the history of information technology development, numerous typical security incidents have occurred, but why is Stuxnet considered a landmark in terms of threat? Stuxnet is considered the first piece of malware to target critical industrial infrastructure in the real world and achieve its predetermined attack objectives. In other words, it was the first major attack in the “cyberspace” sense, rather than a traditional cyberattack. Although there had been previous rumors of information attacks affecting industrial facilities, these generally lacked empirical support at the technical level.

From the perspective of Antiy’s previous views, the milestone significance of Stuxnet is not its complexity and sophistication compared to other simple network attacks, but its demonstration that attacks through cyberspace can achieve equivalence with traditional physical space attacks (or even firepower strikes). In the 2016 report, Antiy researchers compared and analyzed the Stuxnet incident with the “Operation Withering Blade and Babylon” (an event in which Israel and the United States jointly launched a military strike against Iraqi nuclear reactors during the Iran-Iraq War between 1977 and 1981) in the 1970s and 1980s. They found that the physical attack effect that required a lot of complex military intelligence and cost investment could be achieved through cyberspace operations, and the cost was also greatly reduced. As Maren Leed, former senior advisor to the U.S. Army Chief of Staff, said, cyber weapons have many environmentally adaptable attributes, and from the perspective of life cycle cost, they are superior to other weapon systems[4].

Table 2-1 Comparative Analysis of Military and Paramilitary Actions Used in Two Targets of Middle Eastern Countries’ Nuclear Programs

	Withering Blade and Operation Babylon (Traditional Physical Attack on Iraq)	Operation Stuxnet (Cyberattack Against Iran)
Target of attack	Iraqi nuclear reactor	Iran’s Natanz uranium centrifuge facility
Time period	1977-1981	2006-2010
Personnel input	Israeli Air Force, intelligence agents, Iranian Air Force, US Air Force and intelligence agencies	Software and cybersecurity experts in the US and Israel’s intelligence and military fields, as well as experts in industrial control and nuclear weapons.
Combat preparation	Multiple rounds of preliminary reconnaissance and airstrikes, nuclear reactor intelligence	Battlefield prefabrication, virus transmission, and intelligence on related nuclear facilities.
Equipment deployment from all sides	Iraq: Two F-4 Phantoms bombed a hypothetical nuclear reactor construction site with 12 MK82 decelerated bombs; 10 F-4s attacked Iraq’s H-3 airbase. The aircraft consisted of: 2 F-4E(S) for reconnaissance missions; 8 F-16As (provided by the US), 4 F-15As, 2 F-15Bs, and 16 MK84 bombs for air strike reactors. Simulate the construction of a reactor Secret Service agents assassinate key Iraqi figures US: Strategic satellites and intelligence, aerial refueling tankers	Stuxnet virus development Simulate the construction of centrifuges and control systems
Upfront costs	During 18 months of simulated air raid training, two F-4 Phantom fighters crashed, killing three pilots.	Spanning two presidential terms, and undergoing five years of continuous development and improvement.
Damage effect	The destruction of the reactor deterred French suppliers from continuing to provide services, permanently halting Iraq’s nuclear weapons program.	This resulted in the malfunction of numerous centrifuges, leading to a shortage of uranium for weapons and virtually permanently halting Iran’s nuclear weapons program.
Cost-effectiveness	The operation is characterized by its rapid pace, long preparation period, huge cost, high consumption, complex nature, and high risk.	It takes longer and costs less than a military strike, but it is more precise, covert, and has less uncertain consequences.

The Stuxnet attacks also fully demonstrated the risk of industrial infrastructure being comprehensively compromised and even pre-positioned on the battlefield. Stuxnet’s success was built on the long-term operation and information gathering of the Flame and Poison malware. Before attacking Iran’s uranium centrifuge facilities, the attackers had already infiltrated and compromised several major Iranian defense and basic industrial companies, including equipment manufacturers, suppliers, and software developers. Table 2-2 lists several instances of these companies being compromised.

Table 2-2 Infiltration of Iran’s Basic Industrial System

Company	Geographical location	Attack time	Main business
FOOLAD Technic Engineering Co(FIECO)	Iran Isfahan	2009/6/23 2010/4/26	The company manufactures automation systems for Iranian industrial facilities (primarily steel and electricity production) and possesses data, drawings, and plans from many of Iran’s largest industrial enterprises.
Behpajooh Co. Elec & Comp. Engineering	Iran Isfahan	2009/6/28 2010/3/23 2010/5/13 2010/7	We develop industrial automation systems and have experts in SCADA/PLC .
Neda Industrial Group	Iran	2009/7/7	We provide industrial automation services for hydropower plants, cement plants, and the oil, gas and petrochemical industries.
Control-Gostar Jahed Company	Iran	2009/7/7	An Iranian industrial automation company has very deep cooperation with Iran’s largest oil production, metallurgy, and energy companies.
Kala Electric	Iran	2010/5/11	the main supplier of uranium enrichment centrifuge equipment IR-1 . Reports indicate that Iran assembled and tested IR-1 in Kala between 1997 and 2002 .
Mobarakeh Steel Company(MSC)	Iran	2010/4/24	The company is Iran’s largest steel manufacturer and operates one of the largest industrial parks in Iran.

3. Structure and Operational Logic of Stuxnet

Stuxnet has a very complex structure. It has undergone version iterations from 0.5 to 1.x, with its destructive mechanism changing from interfering with centrifuge valves and causing overpressure leading to mass damage to centrifuges to modifying centrifuge speeds. Its development framework has also changed. We will focus on the more widely used 1.x version to analyze its overall structure and operational logic. The core of Stuxnet is a DLL file (hereinafter referred to as the main DLL file) that exists only in memory after decryption. The DLL file contains 32 different exported functions and 15 different resources. Each exported function has different control functions, mainly involving exported function 15 (initial entry point), exported function 16 (installation), exported function 32 (infecting connected mobile devices and starting RPC services), and exported function 2 (hooking APIs to infect Step7 project files), etc. Each resource also performs different functions, mainly involving resource 250, resource 201, and resource 242, etc. The exported functions utilize these resources with different functions to control Stuxnet to perform different branch operations.

Table 3-1 List of Stuxnet Dropper Resources

Resource ID	Function
201	MRxNet.sys loads the driver, which is signed by Realtek.
202	DLL infected with Step 7
203	CAB files infected with WinCC
205	Data file of resource 201
207	Stuxnet’s auto-run version
208	Step 7: Replace the DLL
209	Data file ( %windows%\help\winmic.fts )
210	PE template file used for injection
221	MS08-067 transmitted via SMB utilizes
222	MS10-061 printer spooler vulnerability exploitation
231	Network connectivity check
240	LNK template file used to create LNK exploits
241	USB Loader DLL ~WTR4141.tmp
242	Mrxcls.sys rootkit driver
250	Exploitation of Windows Win32k.sys local privilege escalation ( MS10-073 )

The Stuxnet Dropper releases its resources during the installation and execution process. The Stuxnet drop file is shown in Table 3-2.

Table 3-2 Stuxnet Landing File List

Main name of landing file	File function / Resource ID
~WTR4141.tmp	USB loader
~DF540C.tmp	Status marker file
~wtr4132.tmp	Dropper name in USB infection
DEFRAG[RANDLNT].tmp	Dropper name in shared infection
Oem7a.pnf	Encrypted main DLL
mdmeric3.PNF	90- byte data file
mdmcpq3.PNF	Stuxnet configuration file
oem6C.PNF	Log
MrxCls.sys	Resource 242
MrxNet.sys	Resource 201
s7otbxdx.dll	The replaced Step7 file
s7hkimdb.dll	Resource 202 ( stuxnet loader )
cc_tlg7.sav	CAB file Bag Includes a DLL that loads and executes Stuxnet .
winmic.fts	Resource 209 (Data File)
winsta.exe	Stuxnet executable file released during the exploitation of a printer vulnerability
sysnullevnt.mof	Managed Object Format File
~WTR4141.tmp	USB loader
~DF540C.tmp	Status marker file

Based on resource type and their compilation timestamps, the version iterations of PE type resources are obtained, as shown in Figure 3-1. The figure shows that resources 202 and 210 each have three possible versions, resource 208 has two possible versions, and all other resources have only one version. Additionally, resources 207 and 231 had only a few samples and have been removed in subsequent versions of Stuxnet.

Figure 3-1 PE Resource Version Iteration

Antiy CERT, based on the analysis of Stuxnet sample set and existing data, has drawn up the overall operational framework of Stuxnet, which includes propagation and installation execution.

Figure 3-2 Stuxnet Overall Operational Framework Diagram

Stuxnet spreads primarily through two methods: mobile device infection, utilizing LNK vulnerabilities or spreading via the autorun.inf file; and network propagation, involving various methods such as WinCC database infection, network sharing propagation, printer spooler vulnerability propagation, and Windows server vulnerability propagation. Although these two propagation methods differ, they both ultimately release the main DLL file for subsequent installation and execution. After infecting a target system, Stuxnet starts an RPC server to listen on the network, connecting other infected computers on the network to the RPC server and querying the Stuxnet version installed on remote computers for peer-to-peer communication and updates. If the Stuxnet version on the remote computer is newer, the local computer requests the new version and updates itself; if the Stuxnet version on the remote machine is older, the local computer’s Stuxnet sends a copy of itself to the remote machine. In this way, Stuxnet can update on any infected machine and eventually spread to all machines.

During installation, when the main DLL file is first loaded, exported function 15 is called to perform a series of checks, including checking if the configuration data is up-to-date, if the operating system is 64-bit, and if the operating system version is compatible. If the installation requirements are not met, the process exits. In addition, it checks if the target system has administrator privileges. If not, it uses two zero-day vulnerabilities in resource 250 to escalate privileges and obtain the highest privileges. After that, it checks which antivirus software is installed on the target system and which process is suitable for injection. After exported function 15 completes the above-mentioned checks, Stuxnet calls exported function 16.

Export function 16 is the main installer for Stuxnet. First, it checks if the target system configuration matches, if the registry key value is a specific value, and if the current time is less than the termination time. If these installation requirements are not met, it exits. Execution continues. Stuxnet communicates with different components by creating a global mutex and checks the target system’s current time again to ensure execution only on target systems with a time less than the termination time. It reads the encrypted version from the disk, decrypts it, loads it into memory, calls export function 6 from the newly loaded file to obtain its own configuration data version information, and if it matches the version in the disk file, execution continues. Stuxnet extracts and decrypts resources 201 and 242 and writes the two driver files to the disk. These are used for persistence and hiding malicious files, respectively. To evade detection, Stuxnet modifies the timestamps of these two files to match the timestamps of other files in the target system directory. It creates a rootkit service and registry entries to achieve Stuxnet’s persistence and recreates a global mutex. To continue installation and propagation, Stuxnet transfers control to other exported functions. One method is to inject the main DLL file into the service.exe process and call exported function 32 to infect newly connected mobile devices and start an RPC server. Another method is to inject the main DLL file into the Step7 process and call exported function 2 to infect all specified Step7 files.

4. An Interpretation of Stuxnet from a Threat Framework Perspective

The ability to develop sophisticated malware like Stuxnet stems from the ample resources and cost support of advanced cyber threat actors. Their operations are supported by a massive engineering system and a large team of personnel, involving a series of complex actions. However, this complexity is not necessarily supported entirely by “advanced” attack methods and equipment. Basic configuration errors and unpatched vulnerabilities on the defending side can become entry points for threat actors; advanced cyber threat actors can also hijack and utilize resources such as botnets controlled by lower-level cyber threat actors, further complicating the situation.

Deciphering complex attack actions and driving defense improvements requires more ideal structured methods. Models such as kill chains are still insufficient for deconstructing complex attacks like Stuxnet and need further improvement. Threat frameworks, as a more structured and data-driven description of the attack process, are beginning to become the foundation for threat cognition in improving defense capabilities. Currently popular threat frameworks include MITRE’s ATT&CK and the NSA’s NSA/CSS Technical Cyber Threat Framework. The latter draws some inspiration from the former. Given the NSA/CSS Technical Cyber Threat Framework’s intelligence agency background, it is more suitable for extrapolating A2PT attacks similar to Stuxnet.

Starting from the threat framework, and deducing each stage and behavior of the threat, is a beneficial task for assessing the effectiveness and rationality of the current defense system and related security product capabilities, as well as for forming a systematic defense plan and construction goals. In June 2019, Antiy released a retrospective analysis report on the “Equation Group” attack on SWIFT service provider EastNets[5], which mapped the threat behaviors involved in the incident to the “NSA/CSS Threat Framework” V2 version.

The threat behaviors involved in the Stuxnet incident are mapped to the categories and actions of the threat framework, as shown in Figure 4-1.

Figure 4-1 Stuxnet Incident Mapped to Threat Framework

Operation Stuxnet involved 83 actions across 21 targets, including speculative and determined actions.

Table 4-1 Categories and Actions Involved in the Stuxnet Incident

Threat framework categories	Threat framework actions	Specific actions
Administration (Action management and resource support)	Plan	There may be analysis of the action process; before launching an attack, strategies and objectives may be determined, action plans may be developed in advance, target victims may be selected, and approval may be obtained to carry out the action.
	Resource development	Before the operation, a simulated firing range environment is set up for testing; prior to the operation, necessary infrastructure, funding, alliances and partners may be acquired, and relevant personnel may be trained.
	Research	This may involve collecting information about the target and studying its network capabilities;
Preparation (Target survey and environmental preparationt)	Reconnaissance	They may choose to investigate the network environment and devices of potential victims;
	Environment preset	Add exploitable points to the application data file; allocate the infrastructure required for the operation; pre-load the target;
Engagement (Target contact and offensive penetration)	Delivery	Payload delivery via removable media; payload delivery via exploitation of vulnerabilities; payload delivery via infected host; infection of WinCC machines via hard-coded database server passwords; potential intrusion into the target supply chain / trust source.
	Use	RPC remote execution vulnerability ( MS08-067 ); shortcut file parsing vulnerability ( MS10-046 ); printer spooler service vulnerability ( MS10-061 ); Kernel-mode driver vulnerability ( MS10-073 ); Task Scheduler vulnerability ( MS10-092 );
Presence (Persistent residence and latency)	Execute	Injecting into system processes such as lsass.exe and csrss.exe ; injecting itself in a special way; replacing Siemens STEP 7 driver files; running a fileless payload; using a DLLName like KERNEL32.DLL.ASLR.XXXX to call LoadLibraryA to load the main DLL file; utilizing remote services; writing to multiple PNF files;
	Internal reconnaissance	Enumerate accounts and permissions; detect security products; search for specific keys in the registry; enumerate processes; scan connected mobile devices;
	Privilege escalation	Shortcut file parsing vulnerability; RPC remote execution vulnerability; Printer spooler service vulnerability; Windows Win32K.sys local privilege escalation ( MS10-073 );
	Credential access	Transfer voucher, location voucher;
	Lateral movement	Utilizing peer-to-peer networks; employing password hash authentication; allowing automated execution of removable drives by exploiting a vulnerability; copying and executing itself on a remote computer via network shares; writing to remote file shares; infecting WinCC machines by hard-coding database server passwords;
	Persistence	The MrxCIs.sys driver file can be registered as a startup service; create new services; modify service configurations; and hijack services using library searches.
Effect (Application of effectiveness)	Monitor	Record information to the oem6c.pnf file; monitor inserted USB devices;
	Leakage	Leaking data or information; storing data in a designated location; sending basic information about the infected machine to attackers via HTTP ;
	Modify	Hiding modified code on the PLC is essentially a PLC rootkit ; modifying process results; reprogramming industrial control systems by modifying the programmable logic controller code; modifying inter-machine communication;
	Destroy	Centrifuges that damage industrial control systems;
Ongoing rocesses (Continuous support throughout the entire process)	Analysis, evaluation, and feedback	There may be an impact on the objectives that needs to be assessed;
	Command and Control	Establish a peer-to-peer network; send basic information about the infected machine to the attacker via HTTP ; utilize the peer-to-peer connection; update via the peer-to-peer network using RPC ; check network connectivity; execute encrypted binary code via command and control responses;
	Evasion	Employing anti-forensic measures; employing anti-reverse engineering measures; using rootkits ; encoding data; encrypting configurations and appending data; using digital signature certificates signed by JMicron and Realtek ; manipulating trusted processes; modifying malicious code to evade detection and obfuscate data; adjusting behavior based on configuration files;

For attacks of Stuxnet scale, the key focus should be on their decision-making and preparation processes. Such complex and sophisticated attacks are difficult to execute effectively without a fully equivalent simulated test environment. Simply focusing on the malware and exploit tools themselves, without conducting in-depth analysis of the preliminary stages such as action management and resource security, target reconnaissance and environment preparation, diminishes the significance of introducing a threat framework. Undoubtedly, this part of the analysis is more difficult and complex.

Re-examining Stuxnet from the perspective of threat framework also allows us to answer the “Michael question”. In March 2014, Michael, a senior researcher at Lockheed Martin, analyzed the intent and capabilities of the Stuxnet incident on his blog and raised the question “Why Stuxnet Isn’t APT?” [6]. In this paper, Michael argued that the uncontrolled spread of Stuxnet and the obvious physical spatial consequences did not conform to the high directionality and stealth of APT, and that Stuxnet was more advanced than common APT attacks. He was more inclined to believe that Stuxnet was a combat operation rather than an APT attack. Michael’s view that Stuxnet is more advanced than APT is similar to Antiy’s view that Stuxnet-level attacks are named A2PT. However, Michael’s fundamental concept is to map APT with CNE (cyber intelligence exploitation). Therefore, when Stuxnet aims to achieve CNA (cyber attack, combat), it is reasonable to raise such questions. However, in reality, it is difficult to separate CNE from CNA. CNE is usually the basis of CNA. The transformation of CNE into CNA may just be an adjustment of instructions and strategies. In the threat framework, CNA actions are several action links in the effective use of capabilities. This integrates CNE and CNA into a single framework, thereby better promoting the improvement of the analysis and defense system.

5. Reasons for the “Out of Control” of USB Transfer and Propagation in Stuxnet

Stuxnet is a malicious code designed to attack very specific industrial scenarios. In 2019, some media reported that the Stuxnet virus entered the physically isolated industrial network of Iran by recruiting “insiders” at the request of Dutch intelligence personnel [7]. In the internal network, Stuxnet mainly spreads by using USB slingshots and lateral movement based on vulnerabilities. Its preset attack scenario is an internal network isolated from the Internet. In its earliest analysis report [1], Antiy explained its propagation mechanism with Figure 5-1:

Figure 5-1 Multiple Propagation Modes of Samples

The overall propagation strategy is as follows: infected USB drives exploit shortcut file parsing vulnerabilities to spread to the internal network; within the internal network, propagation occurs between networked hosts via shortcut parsing vulnerabilities, RPC remote execution vulnerabilities, and printer spooler service vulnerabilities; finally, it reaches the host with WinCC software installed and launches an attack. During this process, there is also a possibility that the infected host will infect the inserted USB drive, but according to Antiy’s analysis, this action is not unconditional.

Figure 5-2 Configuration File Parsing During USB Flash Drive Infection Process

Computers infected with Stuxnet monitor connected devices. Once a USB drive is inserted and certain conditions are met, the computer begins writing files to the USB drive. These conditions are as follows:

· The USB drive is not currently infected;

· Infect the disk based on the configuration flag (not the default setting). If the default configuration does not infect, then the occurrence of infection depends on the date.

· The computer has been infected for less than 21 days.

· The USB drive must have at least 5MB of free space.

· The USB drive contains at least 3 files.

The USB file and loading attack logic are shown in Figure 5-3. It contains four LNK shortcut vulnerability (CVE-2010-2568) files applicable to different Windows versions and two TMP files (~WTR4141.tmp is the USB Loader, and ~WTR4132.tmp is the Dropper, both in DLL format, with hidden and system attributes). Stuxnet hides these six files through a rootkit, so the computers infected by Stuxnet cannot see these files on the USB drive.

The USB flash drive spoofing attack process is as follows: An infected USB flash drive is inserted into a new computer. When the user opens the USB flash drive, the system begins to traverse the USB flash drive’s directory files. When the traversal reaches the LNK file, the vulnerability triggers the loading and execution of ~WTR4141.tmp. ~WTR4141.tmp first hooks file-related functions to hide these 6 files (these 4 LNK files can be seen momentarily when the USB flash drive is opened; if the options to show hidden and system files are enabled, 2 TMP files can also be seen, but the vulnerability triggers and all 6 files are instantly hidden in the folder and cannot be seen). Subsequently, ~WTR4141.tmp loads and calls ~WTR4132.tmp in memory to complete the execution of the Stuxnet main module.

Figure 5-3 Schematic Diagram of USB File and Loading Attack Logic

Whether Stuxnet infects the USB drive depends on several values in the encrypted configuration file mdmcpq3.pnf, including:

· Flag bits at offsets 0x6c, 0x70, and 0xc8;

· The timestamp at offsets 0x78 and 0x7c;

· The values at offsets 0x80 and 0x84.

The USB drive will only be infected if all conditions corresponding to each value are met. The bit at offset 0xc8 is set to not be infected by default.

Stuxnet does not actively modify configuration data; configuration updates are accomplished through version updates. Therefore, we believe it attempts to connect to the internet to determine if it is on an internal network. If so, it spreads only through other means; it only infects USB drives after connecting to a server or other infected host for updates.

When Stuxnet infects a USB drive, it copies multiple .lnk shortcut files and two .tmp files to the root directory. One of the .tmp files is digitally signed and used to hide its own driver; the other contains the virus itself and a delivery program, with configuration information already present in the virus.

According to data from the Stuxnet attack monitored by Symantec from July to October 2010, computers in 155 countries around the world were infected, with about 60% of the affected hosts located in Iran[8]. Regarding the reason why an operation that was considered to be highly targeted exhibited a divergent propagation effect, various analysts have offered several different speculations:

The first hypothesis is that various factors led to the uncontrolled spread. Although Stuxnet’s USB ferret and lateral movement design limited its propagation to intranets, its propagation and attack strategies, based on isolated network targets, meant that unlike internet-based attacks, it couldn’t be remotely controlled or adjusted, often relying on preset stop times for propagation. The worm infected a laptop brought to the site by a vendor engineer, subsequently spreading to the vendor’s own network and other customers’ intranets. VPN connections within these intranets exacerbated the spread, ultimately causing Stuxnet’s uncontrolled propagation. This view contradicts some real-world examples; for instance, Stuxnet version 0.5, despite its longer operation cycle and the achievement of its attack objectives, did not experience widespread dissemination.

The second speculation is that this was done intentionally by the operators to obtain more information. The purpose was to further understand the situation of suppliers in Iran’s nuclear industry system based on the infection chain. In his book “Stuxnet’s Secret Twin” [9], German control system security consultant Ralph Langner speculated that this external spread was because the attackers wanted to take the opportunity to obtain intelligence on suppliers of facilities related to Iran. He pointed out that “given that Stuxnet reported the IP address, hostname and basic configuration information of the infected system to its C&C server, it seems that the attackers obviously expected (and accepted) the spread to non-military systems and were quite eager to monitor it closely—the attackers would eventually obtain information on contractors working in Natanz and their clients, and even information on Iran’s secret nuclear facilities”.

The third hypothesis is that the perpetrators wanted to conceal their intention to launch a targeted attack, thus increasing the difficulty of evidence collection and tracing by expanding the scope of the infection. This includes interfering with the more accurate identification and location of the true attack target.

The fourth speculation is that the attackers were demonstrating their capabilities to intimidate or even blackmail other countries. If the incident had occurred solely in Iran, it might have remained hidden. Only by allowing it to “escape” and spread could this effect be achieved more quickly. In his article “Stuxnet’s Secret Twin”, Ralph Langner similarly speculated that “the discovery of Stuxnet signifies the end of the operation, but its practicality does not necessarily end. It will demonstrate to the world what cyber weapons can do in the hands of a superpower. Unlike the display of physical military equipment, a USB drive cannot be displayed during a military parade. The attackers may also be targeting another country, or at worst, an adversary; and will be the first to demonstrate their capabilities in the digital domain—this scenario could be considered another Sputnik moment in the history of superpowers. All these reasons make it less worrying for the attackers to be detected”.

Whether the spread of Stuxnet was “out of control”, intentional on the part of the attackers, or a combination of both remains to be seen. The final outcome may not be due to a single cause, but rather a combination of factors.

6. Why Does Stuxnet Have Thousands of Samples?

As a highly targeted attack, one puzzling fact is that Stuxnet does not have the ability to infect other host files, yet a large number of samples exist.

In malware countermeasures, samples are considered a crucial foundational resource. Samples are viewed as a physical file representation of malware, including host files containing infectious viruses, files containing non-infectious malware, and file images of sectors or memory where malware resides. As the depth of threat countermeasures has expanded from initial detection and erasure to response, in-depth mechanism analysis, and attribution, we’ve observed changes in the demand for and definition of samples. Samples in the sense of investigation/hunting differ from samples in the traditional sense of detection. Samples in the traditional sense include files collected in real-world scenarios, as well as transformed samples constructed for testing antivirus engine capabilities and analysis. Such sample construction is essential for detection and removal capabilities. For example, sample specifications, especially for infectious viruses, require a specified number of infected files based on file sizes such as DOS_COM and DOS_MZ, to ensure the effectiveness of detection and removal. For polymorphic viruses, even more samples need to be constructed. For investigation/hunting purposes, the objective existence of something in an attack scenario becomes an important sample attribute that needs to be identified.

Antiy Labs captured thousands of Stuxnet samples, which can be categorized into several distinct dimensions: raw payloads transferred via USB drives, files stored on the host machine, and non-stored modules (requiring static extraction or dynamic dumping). One category consists of the final attack payloads extracted from these samples (most of which are not stored on the host in actual attacks) and auxiliary drivers. The majority of the physical files extracted from the disk media fall into three categories: attack payload droppers (original filename ~WTR4132.tmp), USB loaders (~WTR4141.tmp), and LNK exploit files. The number of dropper samples is dispersive, reaching thousands according to Antiy Labs’ data. The final attack module payloads and auxiliary drivers are in the hundreds, showing a convergence in total number.

The classification of the Stuxnet sample set is shown in Figure 6-1.

Figure 6-1 Stuxnet Sample Collection Classification

Antiy CERT analysis revealed that the large sample size of the Stuxnet dataset was due to the following reasons:

1. The Dropper Sample Writes the Target Configuration upon Deployment, Causing File Changes.

The attack payload dropper has a resource segment called “stub”, where the attack payload (i.e., the main DLL) resides. When the virus is deployed, the configuration data stored in the stub segment is updated with relevant information from the currently infected node. This is a primary reason for the large number of samples in the Stuxnet sample set. In other words, each deployment to Stuxnet creates a new dropper with a different hash. This results in a dispersed distribution of samples in terms of hash count. Furthermore, the actual “versions” of the dropper functionality within the sample set are limited. 98.84% of the import tables in the dropper are identical, and 91% of the samples have completely identical files extracted from their text segments, all with the MD5 hash 17e2270d82d774b7f06902fa7d630c74. This is a dominant dropper version used in large-scale infections.

Figure 6-2 Dropper Import Table Statistics

The stub segment is the location where the main DLL is stored, and its layout is shown in Table 6-1.

Table 6-1 Stub Segment Layout Analysis

Offset	Length	Explain
+00	Dword	Flag
+04	Dword	Main DLL is offset relative to the current position.
+08	Dword	Main DLL length

The function for decrypting the main DLL is as follows:

Figure 6-3 Decryption of Main DLL Functions

The data following the main DLL contains encrypted configuration information that can control Stuxnet’s behavior during the infection process. This allows Stuxnet to continue operating according to preset strategies even when remote control is unavailable, ensuring the success of its complex operations. Its configuration file also records information about the infected machine and time characteristics. The attackers likely intend for this information to be extracted and recorded during the infection process, allowing them to directly submit the relevant data to the C2 server once connected to the network, without requiring secondary extraction and reducing manipulation of the host environment to minimize the chance of exposure.

The partially decrypted configuration information is as follows:

Figure 6-4 Partial Decrypted Configuration Information

Table 6-2 provides a breakdown of some configuration values. These values control Stuxnet’s behavior on the victim host. Specifically, they include: controlling the infection start time via the +A4 value (if this value fails to meet infection requirements, the infection will terminate); controlling the termination time of USB infection via the +78 value; and values related to controlling Stuxnet propagation and version updates. The decrypted configuration information contains nearly a hundred such values controlling Stuxnet’s behavior; these values are what control Stuxnet’s complex actions.

Table 6-2 Partial Configuration Analysis

Offset	Length	Explain
+00	Dword	Configuration file start flag
+04	Dword	Configuration file header length
+08	Dword	Configuration file checksum
+0C	Dword	Configuration file length
+68	Dword	The flag bit, if it is 0 , checks the flag at +70 (if it is 1 , it directly infects the USB ).
+70	Dword	Flag If the value is 0 , then check the timestamp at +78.
+78	Qword	Termination of USB infection time
+80	Dword	Number of files required on the USB drive
+8C	Qword	End time
+A4	Qword	Infection start time (if more than 21 days have passed, infection of USB drives will cease ).
…	…	…

Dropper’s configuration file validation function:

Figure 6-5 Dropper’s Configuration File Validation Function

Key information about the configuration block, such as infection path, infection time, and configuration block length, was extracted and analyzed. It was found that Stuxnet updates its data configuration block after each new device infection, resulting in an additional dropper sample with the new configuration for each infected device. Figure 6-6 shows the distribution of the number of Stuxnet infection times. The infection times from 2008 to 2010 are considered to be of higher confidence, while the infection times from 2000 to 2007 are considered to be of lower confidence.

Figure 6-6 Distribution of the Number of Infections Starting at the Time of Infection (The Incorrect Start Time May Be Due to Clock Synchronization Issues Between Internal Network Hosts).

During the installation and execution of Stuxnet, the current time of the target system is checked multiple times. If the target system time is greater than the termination time, Stuxnet will exit the installation and execution process. Figure 6-7 shows the statistics of the termination time of USB drive infection in Stuxnet version 1.x. There are three termination times for USB drive infection: July 31, 2010, August 31, 2010, and December 31, 2010. The vast majority of the termination times for USB drive infection are December 31, 2010.

Figure 6-7 Statistics on the Time of Termination of USB Flash Drive Infection

2. Caused by the Analysis and Extraction Process

Extracting the various functional payloads of Stuxnet from the main DLL is a crucial task in Stuxnet analysis. This introduces a new factor to consider in sample statistics: what constitutes the original sample and what represents the processing data. The Stuxnet main DLL file is stored in the Dropper using UPX compression to prevent excessively large sample sizes and reduce propagation opportunities. In actual infection processes, the main DLL is not permanently stored on the disk. The sample set contains a UPX-packed main DLL file, and different versions exist due to dumping, including unpacked versions and versions generated using different unpacking methods.

In the samples used in A2PT’s organized operations, the use of shells was rarely observed. This may be related to some antivirus software issuing warnings about shells or outputting logs. However, the main DLL file of Stuxnet is compressed using UPX shell in Dropper (as is the case with Duqu), which is likely due to considerations of reducing file size.

Figure 6-8 Incompletely Unpacked File

3. Interference Data

In Stuxnet’s USB Loader sample set, hundreds of sample files had corrupted signatures, and many of these files also had other LNK files and alarm logs from some antivirus product appended to their ends. Based on current analysis, this is caused by a bug in a certain antivirus product. A certain version of the product would incorrectly append data to the end of the samples when scanning them, thus introducing hundreds of corrupted samples.

Figure 6-9 LNK File Appended to the End of USB Loader

7. Association Between a Malware Framework and Multiple A2PT Incidents

Before and after the Stuxnet incident, advanced malware such as Poison, Gauss, and Flame were successively exposed. Because these malware programs were unprecedentedly complex and were often found in Middle Eastern countries, it was a natural assumption that they were related to each other.

In early 2011, Antiy CERT proposed the speculation that there might be some kind of connection between Stuxnet and Duqu, but it was not until early the following year that a relatively systematic verification was completed. They published two papers, “Exploring the Mystery of the Origin of the Duqu Trojan” [10] and “From the Homology of Duqu Virus and Stuxnet Worm to See Industrial Control System Security” [11], which respectively confirmed the existence of a homology relationship between the two from the perspectives of module structure similarity analysis, compiler architecture similarity analysis, key function implementation similarity analysis, key and other key data similarity analysis, coding psychological characteristics analysis, and the analysis of the same program bugs.

Figure 7-1 Comparison of Code Fragments Between Stuxnet Worm and Duqu Virus

Figure 7-2 The Stuxnet Worm and the Duqu Virus Use the Same Key

Antiy Labs concluded at the time that “by comparing the key code structure, key usage methods, and code logic of the Stuxnet worm and the Poison Virus, we discovered a large number of identical or similar code fragments, indicating that there is a code reuse relationship between the two, or that they are developed based on the same code framework”. However, no definitive conclusion was reached at the time regarding whether it was a reuse relationship or development based on the same framework. Integrating the later analysis results and progress of other organizations, the conclusion that relevant A2PT attack groups maintained at least two malicious code frameworks, Tilded and Flame, can be drawn. Stuxnet, Poison Virus, Flame, and Gauss were developed based on the Tilded and Flame frameworks, respectively. On June 11, 2012, Kaspersky released a report stating that the early 2009 version (version 0.5) of the Stuxnet module (called “Resource 207”) was actually a Flame plugin. This finding also connected the two completely different frameworks, Flame and Tilded. Malicious code based on these two frameworks has unique techniques in infecting target systems and performing main tasks, and both are used to develop different cyberattack tools. Kaspersky concluded that the teams behind the two frameworks had shared the source code of at least one module, indicating that they had collaborated at least once and were two parallel projects belonging to the same organization [12]. Based on further clues, Fanny and Flowershop can be linked to the above events, and their relationship is shown in Figure 7-3.

Figure 7-3 Relationship Diagram Between Stuxnet and Duqu, Flame, Gaussian, Fanny, and Flowershop

7.1 Flamer Framework

The development of the Flamer framework can be traced back to December 2006. Flame and Gauss are based on the Flamer framework. Antiy Labs captured samples of the Flame worm starting from May 28, 2012[13] and established a special analysis team to conduct continuous analysis. They found that Flame is a type of malware that steals information using a complex multi-modal structure. Its main module file is over 6MB in size and contains a large amount of encrypted data, embedded scripts (such as Lua), vulnerability exploit code, module configuration files, multiple encryption and compression algorithms, and multiple modules for information theft.

Flame has two main versions, Flame 1.0 and Flame 2.0, both of which consist of multiple submodules that rely on a master coordinator that is embedded in the Lua VM. Flame and Gauss share some code and also share the MiniFlame malware plugin.

7.2 Tilded Framework

Stuxnet and PoisonQu are developed based on the Tilded framework. The Tilded framework’s infection method can generally be summarized as utilizing driver files to load a main module designed as an encryption library. Simultaneously, the entire malware complex has a separate configuration file, and an encrypted block in the system registry defines the location of the loaded module and the name of the injection process.

Known versions of Stuxnet include Stuxnet 0.5, Stuxnet 1.001, and Stuxnet 1.100. Stuxnet 0.5 was an earlier version of Stuxnet, but it was later discovered and exposed, and this variant ceased its attacks on computers on July 4, 2009. The main differences between Stuxnet 0.5 and Stuxnet 1.x versions include: Stuxnet 1.x versions significantly increased propagation and exploit capabilities; Stuxnet 0.5 was partially based on the Flamer framework, while Stuxnet 1.x versions were primarily based on the Tilded framework; Stuxnet 0.5 used overpressure to massively damage centrifuges, while Stuxnet 1.x versions adopted a new attack strategy, shifting from uranium enrichment valve sabotage to centrifuge speed modification.

Table 7-1 Comprehensive Comparison of Technical Details between Stuxnet Versions 0.5 and 1.x

Version	Time	Description	Vulnerability exploitation	Evolution of communication technology	Platform evolution	Evolution of attack strategies
0.500	2005/11/3	C&C Server Registration	CVE-2012-3015 — Step 7 : Loading the security library;	Step7 is executed via USB by infecting the Step7 project file and updating the peer-to-peer network via mailslot.	Based on Flamer platform	for S7-400 ( 417 ) PLCs (modification of cascade protection system valve operation during uranium enrichment)
0.500	2005/11/15	Date submitted to public scanning service
0.500	2009/6/4	Infection stop date
1.001	2009/6/12	Binary compilation timestamp update	CVE-2010-2729 — Print Service RCE; CVE-2008-4250 — Windows Server Service RPC RCE; CVE-2012-3015 — Step7 Security Library Loading; CVE-2010-2772 — WinCC Default Password MS09-025; NtUserRegisterClassExWow /NtUserMessagerCall EOP	This involves infecting Step7 project files to enable self-starting network sharing via USB , Windows Server RPC Printer spooler, and WinCC server updates to the peer-to-peer network via RPC.	Primarily based on the Tilded platform	Code for S7-300 ( 315 ) PLCs (controlling the speed of the rotary centrifuge) and incomplete code sequences for 417 PLCs.
1.100 1.001	2010/3/1 2010/4/14	Binary compilation timestamp update	CVE-2010-3888 — Task Scheduler EOP CVE-2010-2743 — LoadKeyboardLayout EOP CVE-2010-2729 — Print Service RCE CVE-2008-4250 — Windows Server Service RPC RCE CVE-2012-3015 — Step7 Security Library Loading CVE-2010-2772 — WinCC Default Password CVE-2010-2568 — Shortcut .lnk RCE	Step 7: Project files trigger CVE-2010-2568 network sharing via USB . Windows Server RPC Printer spooler WinCC server updates peer-to-peer network via RPC.	Primarily based on the Tilded platform

The main versions of Duqu include Duqu 1.0, Duqu 1.5, and Duqu 2.0. Duqu and Duqu 2.0 use the same algorithm and reuse a lot of the same code. There is a lot of overlap in attack targets between Duqu 1.0 and Duqu 2.0. Both Duqu 1.5 and Duqu 2.0 use the Pipe Backdoor plugin.

Stuxnet and Duqu share similarities in module structure, compiler structure, key functions, data structure, and the psychology of virus authors[14]. Furthermore, Stuxnet, Duqu1.0, and Duqu2.0 all use digital certificates stolen from IT vendors in Taiwan, China.

7.3 The Connection Between Stuxnet and Fanny and Flowershop

As can be seen from Figure 7-3, in addition to being associated with Poisonous Melody and Flame, Stunnet is also associated with Fanny and Flowershop.

Stuxshop was an early component of Stuxnet, used to manage early C2 servers. There is code overlap or sharing between Stuxshop and Flowershop (a malware platform active from 2002 to 2013).

Fanny, an early component of Equation, used two zero-day vulnerabilities from Stuxnet: the LNK vulnerability (CVE-2010-2568) and a privilege escalation vulnerability embedded in “Resource 207”. Furthermore, Stuxnet and Equation developers shared coding styles or used the same development guidelines.

8. Facing the Challenges of Detection Engines and Threat Intelligence

In previous analysis reports by Antiy, we discussed and explored the defense challenges posed by A2PT. However, in our review of Stuxnet, we hope to focus on a specific issue: the challenges that advanced malware poses to detection engines and threat intelligence.

Malicious code, serving as the attack payload, is the “warhead” of cyberattacks. It appears in almost every cyberattack, especially in the activities of high-capability cyber threat actors. From a threat framework perspective, high-capability cyber threat actors need to achieve target contact and penetration, persistent presence and covert operations, and continuous support throughout the entire process, further realizing various effective capabilities. This requires not only achieving operational intent tailored to specific business scenarios but also circumventing systematic defenses to achieve deep persistence and covert communication, necessitating the execution of highly complex logical functions. This has led to an increasing reliance on malicious code in APT attacks, with advanced malicious code exhibiting trends of increasingly large frameworks, numerous modules, and atomic instruction sets.

In its past analysis of cyber threats and tracking of cyber threat actors, Antiy has continuously monitored and analyzed attack activities by Stuxnet, Flame, Poison, and Equation, which possess complete and rigorous operational frameworks and methodologies, as well as the advanced malware they use. It has also analyzed targeted attack activities that combine “commercial weaponry” with open-source and free tools, i.e., lower-level self-developed malware. This analysis is long-term and costly, but it forms the foundation for more effective defense and targeting. Empowering clients to build dynamic and comprehensive defense systems is our goal; and the fight against attack tools (malicious code, exploits, and other tools) has always been a key focus.

In this confrontation, traditional antivirus engines and threat intelligence become two complementary mechanisms. The former possesses unparalleled depth in detecting and identifying massive amounts of malicious code, and utilizes deep preprocessing and virtual execution mechanisms to counter variants and variations of malicious code. Therefore, it offers unparalleled depth in payload detection and provides a precise judgment mechanism for massive payload objects. However, the shortcomings of traditional antivirus engines in threat countermeasures are also obvious. They are the easiest security resources for attackers to obtain. Most antivirus software can be publicly downloaded or purchased at low cost, and publicly available multi-engine scanning mechanisms like VirusTotal also become testing resources for attackers. Therefore, antivirus engines are inevitably susceptible to being bypassed by automated evasion tests. Furthermore, their mechanism of regularly updating local detection libraries, or the reliance of cloud engines on remote access, imposes deployment costs on internal network users. Another issue is that traditional antivirus engines operate based on sample detection rate as the core indicator, lacking a more specific focus on threat countermeasures in their information output. These shortcomings require threat intelligence to address. In the threat intelligence pyramid, “narrowly defined intelligence” such as hashes, IP addresses, and domain names are placed at the bottom, meaning they are easy to obtain and inexpensive to apply. They are relatively easy for the defending party to extract as attack indicators (beacons), and can also be integrated with various existing extension interfaces of security devices, management devices, and protection software.

Figure 8-1 Threat Intelligence Pyramid Model

While hash detection mechanisms are far less robust than traditional antivirus engines, their uniqueness, coupled with reliable knowledge base support, allows for precise targeting of attack organizations. For example, two different attack organizations might each create the same version of a commercial Trojan, attaching their respective C2 configurations to the end of the file. To an antivirus engine, this is the same sample, but hash intelligence, when analyzed, can differentiate them. However, the usability of hash intelligence hinges on the existence of reusable samples with unchanged binary form. The same applies to IP and domain name rules. When the intelligence provider can direct malicious activity to a specific communication infrastructure (C2) to perform heartbeats, control, upgrades, and data transmission, and then direct this malicious activity to a particular attack organization, the corresponding network IoC can be matched with other attack activities, thus establishing a link between the attack behavior and the organization. This low-level attack targeting mechanism, while simpler in its mechanism than antivirus and traffic detection engines, offers a rapid, widely expandable, and precisely defined capability, providing a fast and more universal monitoring and survey function. Therefore, the combination of traditional detection engines and IoC intelligence can create a complementary effect. This combination model is also the model that Antiy Labs has been promoting over the past few years.

However, a review of the Stuxnet incident nine years ago reveals that this level of intelligence is nearly ineffective against A2PT attacks. The hash of the Dropper file extracted from each host could not possibly match the equivalent file on another host. We cannot assume that Stuxnet’s self-writing update mechanism was primarily designed to circumvent hash detection mechanisms, but it objectively achieved this effect. More importantly, although the analysis shows that domains related to the Stuxnet attack were registered as early as 2005, Stuxnet’s attack effect was already achieved when the analysts used relevant communication characteristics as rules. In attacks like Poison, we also widely observe the existence of internal C2 mechanisms. If the antivirus engine is a heavily overloaded mechanism that attackers can easily bypass, and the attack indicator (beacon) is an intelligence mechanism with extremely low stability, the effectiveness of this double-layered protection will be greatly reduced.

Antiy, recognizing that traditional threat detection engines are often exploited by attackers in threat adversarial operations, began developing its next-generation threat detection engine in 2016. Antiy’s next-generation engine inherits and enhances the format recognition and deep analysis capabilities of its traditional engine, maintaining its ability to accurately classify and identify variants of massive amounts of malicious code. Furthermore, assuming no trusted formats or objects exist, it achieves full-format recognition of detected objects and deep analysis capabilities for more critical formats. Beyond simply outputting judgment results to the calling stage, it can also structure and output the vector decomposition results of detected objects, forming data resources to support analysis, correlation, and tracing in product scenarios and situational awareness scenarios.

Exploring a better integration of detection engines and threat intelligence, establishing more reliable basic identification capabilities and response mechanisms, more effectively supporting TTPs and even intelligence related to personnel and organizations, and building a more complete knowledge engineering operation system will be a direction that requires long-term efforts for us.