Loading story…
Stuxnet emerged as a landmark cyberweapon that proved malware could move beyond data theft and disrupt physical industrial processes. Analysis of the worm showed it was built to target Siemens SCADA and PLC environments, with payload logic that reached past infected Windows hosts into industrial control systems, including the uranium enrichment facility at Natanz. Researchers described the malware as unprecedented for its time because its sabotage routines operated largely autonomously, showing that cyberattacks against critical infrastructure were practical and highly engineered rather than theoretical.
Technical reviews found that Stuxnet combined broad propagation with precise targeting, exploiting multiple Windows flaws including MS10-046/CVE-2010-2568, MS10-061, MS08-067, MS10-073, MS10-092, and the Siemens WinCC hard-coded password issue CVE-2010-2772. The worm used modular user- and kernel-mode components, signed malicious drivers with stolen Realtek and JMicron certificates, injected into processes, updated peers over RPC, and communicated over HTTP with command-and-control servers. Infection telemetry cited in the technical analysis showed the heaviest spread in Iran, accounting for 52.2% of observed infections, underscoring the operation’s apparent focus despite its wider self-propagation.
See affected versions and whether adversaries are exploiting it.
5 events from the most recent confirmed update back to the earliest known activity.
The report states that the Stuxnet file ~wtr4141.tmp had a compilation timestamp of 2010-03-02 and was digitally signed.
The analysis states that the MRXNET.sys driver had a compilation timestamp of 2010-01-25 and shared the same linker version as MRXCLS.sys.
The report says the MRXCLS.sys driver was signed on 2010-01-25, reflecting preparation of a trusted kernel component for the malware platform.
According to Ralph Langner, he and two colleagues decoded Stuxnet's payload in 2010 and found code that operated beyond Windows PCs against Siemens industrial control systems at Natanz.
The technical analysis states that the MRXCLS.sys kernel-mode driver used by Stuxnet carried a compilation timestamp of 2009-01-01.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
See whether adversaries are exploiting this yet, and where the affected versions run in your environment.
2 references tracked. Mallory keeps watching after this page renders.
Map indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
A researcher has reverse-engineered and published a reconstruction of **Stuxnet** source code on GitHub, making the inner workings of the landmark industrial-control-system worm available for study. Stuxnet infected Windows hosts through removable USB media, network propagation, and Siemens engineering-project files, then targeted Siemens PLC environments associated with Iran’s Natanz enrichment facility. It covertly changed centrifuge frequency-converter operations while feeding operators apparently normal process data, enabling physical sabotage through digital compromise. The reconstruction highlights Stuxnet’s use of multiple Windows exploits, including the historically significant `CVE-2010-2743`, and stolen Realtek and JMicron code-signing certificates. The worm, widely attributed to the U.S.-Israeli Operation Olympic Games, escaped its intended environment when infected engineering laptops moved beyond isolated networks; it contained a hard-coded self-delete date of June 24, 2012. Contemporary retrospectives are revisiting its exploitation techniques as examples of how legacy attack methods can retain relevance for modern OT and Windows environments.
Sep 10, 2026
Researchers disclosed **FAST16**, a previously undocumented sabotage malware framework whose core components were compiled around 2005, placing it years before **Stuxnet** and marking it as one of the earliest known cyber tools built to corrupt high-precision computational workloads. SentinelOne said the framework used a Lua-based carrier, `svcmgmt.exe`, alongside the boot-start driver `fast16.sys` to spread across Windows 2000/XP networks, evade monitored environments, and patch targeted applications in memory so they produced subtly altered floating-point results instead of overt failures. References in Shadow Brokers material linked the malware name to leaked deconfliction data, but researchers stopped short of definitive attribution while assessing the tooling as state-grade and likely tied to a covert sabotage campaign. Analysis of the malware’s rule-based patch engine indicates it targeted specialized software including **LS-DYNA 970**, **PKPM**, and **MOHID**, with Symantec concluding the strongest evidence points to tampering with LS-DYNA and **AUTODYN** simulations involving high explosives and possible nuclear detonation modeling. The hooks reportedly altered outputs only under narrow conditions, such as uranium-like densities and specific explosive equation-of-state models, suggesting an effort to quietly degrade the fidelity of weapons, engineering, hydrodynamics, and civil-structure simulations rather than trigger immediate disruption. Researchers said the framework’s worm-like lateral movement, credential impersonation, persistence, and long-term maintenance across multiple software builds indicate a sustained operation intended to spread consistent calculation corruption through an entire facility and potentially delay or derail sensitive scientific and engineering programs.
Jun 29, 2026
CERT-UA disclosed a targeted attack on a Ukrainian energy facility in which operators attempted to disrupt high-voltage substations and destroy Windows, Linux, and network infrastructure. The operation used **INDUSTROYER2** to issue hardcoded IEC 60870-5-104 (`IEC-104`) commands against specific substations, while **CADDYWIPER** targeted Windows systems and **ORCSHRED**, **SOLOSHRED**, and **AWFULSHRED** were prepared to wipe Linux hosts. CERT-UA said the attackers had access no later than February 2022, launched two attack waves, and planned the disruptive phase for April 8, but the intended impact was prevented; supporting tooling included **ARGUEPATCH**, **TAILJUMP**, PowerShell-based **POWERGAP**, SSH tunnel chains, and Impacket for remote execution and lateral movement. Technical analyses from Nozomi Networks, Netresec, and Splunk found that Industroyer2 was a tailored, standalone executable focused exclusively on `IEC-104`, with hardcoded station parameters, IP addresses, and Information Object Addresses (`IOAs`) for deterministic command execution against predefined substations. Researchers reported strong code and structural similarities to the original **Industroyer** used in the 2016 Ukraine grid attack, concluding the malware likely evolved from the same source code and reflects Sandworm’s continued refinement of OT attack capabilities. The payload was designed to run in a privileged environment with direct substation access, terminate selected processes, manage `IEC-104` sessions including `TESTFR` handling, and in some samples connect to specific targets over TCP port `2404`, underscoring detailed prior knowledge of the victim’s operational technology environment.
Aug 15, 2026