Summary
Stuxnet, uncovered in June 2010, was the first malware built to break things in the physical world, and it rewrote the rules of conflict between states. Widely understood to be a joint US and Israeli operation codenamed "Olympic Games," it had one target: the air-gapped industrial controllers running the gas centrifuges at Iran's Natanz uranium-enrichment plant. Stuxnet crossed the air gap on USB drives, used four Windows zero-days to spread, and signed its kernel drivers with code-signing certificates stolen from two Taiwanese hardware makers so Windows loaded them without complaint. Once it found a machine running Siemens Step7 software, it reprogrammed the controllers to spin the centrifuges to destructive speeds while replaying recorded "everything is normal" readings back to the engineers watching the screens. It quietly wrecked roughly a thousand centrifuges, set Iran's program back about a year, and then escaped to infect more than 100,000 computers worldwide, proving once and for all that an isolated network is not an immune one.
How it worked
Stuxnet's genius was patience, and it ran in two stages.
The first stage was getting in and spreading. Natanz was air-gapped, so Stuxnet was built to travel on removable media: a single infected USB drive was enough. It exploited a zero-day in how Windows rendered shortcut (.LNK) files (CVE-2010-2568), so simply viewing the contents of an infected drive in Windows Explorer triggered remote code execution, with no clicks required. From that first machine it used three more zero-days (a Print Spooler flaw and two privilege-escalation bugs) plus a hard-coded password in Siemens' WinCC database to move quietly across the internal network and burrow into engineering workstations. To slip past antivirus, its kernel drivers were signed with valid certificates stolen from the chipmakers Realtek and JMicron.
The second stage was sabotage, and it only fired on the exact system it was hunting. Stuxnet ignored everything until it found Siemens Step7 software talking to a specific model of programmable logic controller (PLC) wired to a specific arrangement of centrifuge frequency-converter drives: the fingerprint of Natanz. Only then did it act. It injected its own code between the control software and the PLC, becoming a man in the middle, and hid behind a rootkit that concealed both its Windows files and the rogue logic it loaded onto the controller itself. Stuxnet actually carried two sabotage routines over its lifetime: an earlier one that quietly over-pressurised the centrifuges by manipulating their isolation valves, and the better-known one that attacked rotor speeds. The speed attack drove the rotors far outside their safe band, briefly up to 1,410 Hz, which spins an IR-1's aluminium rotor at roughly 443 metres per second, past the metal's structural limit, and then slammed them down toward a near-stop, all while recording about 21 seconds of normal sensor data and replaying it on a loop to operators and safety systems. The engineers saw green dashboards while their centrifuges shook themselves to pieces.
The damage
Iran never confirmed the full toll, but the numbers leaked out anyway. In late 2009 and early 2010, inspectors from the International Atomic Energy Agency watched Iran quietly decommission and replace about 1,000 IR-1 centrifuges at the Natanz Fuel Enrichment Plant, roughly a fifth of the machines in operation. Analysts at the Institute for Science and International Security tied the breakage to Stuxnet and estimated it set the enrichment program back by around a year. The attack was effective precisely because it was slow and deniable: instead of one dramatic explosion, centrifuges failed at an unusual rate over months, and Iran's engineers spent that time chasing ghosts, blaming bad parts, bad operators, and bad luck. That misdirection was worth as much as the broken hardware.
Stuxnet's one real mistake was getting out. A later, more aggressive variant spread beyond Natanz and onto the public internet, which is how the rest of the world found it. By the time it was catalogued it had infected well over 100,000 machines across more than 150 countries, with roughly 60% of the infections in Iran. None of those collateral infections did anything; the payload stayed inert outside Natanz. But the escape is what turned a secret operation into the most studied piece of malware in history.
Who built it, and why
Officially, no government has claimed Stuxnet. Unofficially, the consensus is firm. In 2012 The New York Times reported that Stuxnet was the centerpiece of a US-Israeli program codenamed "Olympic Games," begun under President George W. Bush around 2006 and accelerated under President Obama, built jointly by the US National Security Agency and Israel's signals-intelligence Unit 8200. The strategic logic was to set back Iran's nuclear ambitions without an airstrike that could ignite a regional war: a weapon that left no fingerprints and could be plausibly blamed on faulty equipment.
It was discovered almost by accident. In June 2010 a small Belarusian antivirus firm, VirusBlokAda, was called in to investigate Iranian computers that kept crashing and rebooting, and its engineer Sergey Ulasen traced the fault to an anomalous but validly signed driver, the loose thread that unravelled the whole operation. What they found was unlike anything before it, and as Symantec, Kaspersky, and the German control-systems researcher Ralph Langner pulled it apart over the following months, the picture sharpened into a precision-guided digital weapon aimed at a single facility.
Why Stuxnet still matters
Stuxnet is the line that divides cybersecurity into a before and an after. Before, a "cyberattack" meant stolen data or downtime. After, it meant a machine could be made to physically destroy itself. Stuxnet proved that code can have the effect of a bomb, and that the most isolated, most critical systems in the world, the ones running power grids, pipelines, water treatment and factories, were reachable.
The descendants arrived on schedule. Industroyer cut power in Kyiv in 2016; Triton (also called Trisis) reached into the safety-instrumented systems of a Saudi petrochemical plant in 2017, the systems whose entire purpose is to prevent an explosion; Industroyer2 was aimed at Ukraine's grid again in 2022. An entire discipline, operational-technology (OT) and industrial-control-system (ICS) security, exists in its current form largely because Stuxnet showed what was at stake. And it left a lesson that keeps getting relearned: an air gap is a control, not a force field. Anything a human can carry across it, a worm can ride.
How to fix it
- Re-image any controller or engineering workstation suspected of infection from known-good media; against a rootkit this capable, on-disk integrity cannot be trusted.
- Revoke and reissue any code-signing certificates and keys that may have been stolen, and rebuild and re-sign artifacts from a clean pipeline.
- Compare PLC and controller logic against a trusted, offline baseline and restore verified Step7 or ladder code; assume the live controller is lying about its own state.
- Reconstruct the intrusion path (which USB, which workstation) from host and removable-media logs before reconnecting any OT segment.
How to avoid it
- Treat an air gap as one layer, not a guarantee: control and scan removable media, disable USB autorun on OT hosts, and assume something will eventually cross the gap.
- Allowlist exactly which signed code may run on engineering workstations, and alert on drivers or binaries signed by unexpected vendors.
- Segment and monitor the OT network, and alert when controller logic, setpoints, or drive frequencies change outside an approved maintenance window.
- Keep verified offline backups of PLC programs and HMI configurations, so tampered logic can be caught by comparison and rolled back.
- Patch the IT systems on the OT boundary promptly; Stuxnet reached the controllers by riding ordinary Windows zero-days through the engineering network.
References
Related vulnerabilities
All Infra →- CRITICALCVE-2025-1974
IngressNightmare was a chain of five vulnerabilities in the Ingress-NGINX Controller for Kubernetes disclosed on 24 March 2025 by the Wiz Research team, the most severe being CVE-2025-1974 (CVSS 9.8), which enabled unauthenticated remote code execution from the pod network. Wiz estimated about 43% of cloud environments were vulnerable and identified over 6,500 publicly exposed clusters, including Fortune 500 organizations. The controller's validating admission webhook ran as an unauthenticated HTTP endpoint reachable by any workload on the pod network, accepting attacker-supplied AdmissionReview requests containing crafted Ingress objects. The supporting CVEs (CVE-2025-24514 auth-url, CVE-2025-1097 auth-tls-match-cn, CVE-2025-1098 mirror UID, CVE-2025-24513 path bypass) injected unsanitized NGINX configuration directives via annotations into a temporary config the controller validated with nginx -t. The attacker uploaded a shared-library payload by abusing NGINX client-body buffering (an oversized Content-Length keeps the request file descriptor open in ProcFS) and then used the injected ssl_engine directive to load that library during validation, achieving code execution in the controller pod whose service account could read all cluster secrets across namespaces, enabling full cluster takeover.
- HIGHCLOUD-ENVFILE-EXTORTION-2024
On August 15, 2024, Palo Alto Networks Unit 42 detailed a large-scale extortion campaign that compromised cloud environments by harvesting exposed environment variable files. Attackers scanned at least 110,000 domains and collected over 90,000 unique variables, including roughly 7,000 cloud service credentials and 1,515 social media credentials, with their infrastructure probing around 230 million targets. The vector was a web server misconfiguration: .env files inside the web root were served as plaintext over HTTP because the servers had no rule denying access to dotfiles, exposing the long-lived AWS IAM access keys hardcoded inside. The initial IAM principals lacked full admin but retained permission to create roles and users, so attackers called CreateRole and attached AdministratorAccess to escalate, then spun up Lambda functions across regions to automate further internet-wide scanning. They used the victims' own AWS accounts to exfiltrate and delete S3 objects, then uploaded ransom notes demanding payment. The failure chain combined exposed dotfiles, long-lived hardcoded credentials, and over-permissioned IAM, not any cloud-provider flaw.
- CRITICALCLOUD-BUCKET-MONOPOLY-2024
In research disclosed to AWS on February 16, 2024 and presented at Black Hat USA and DEF CON 32 in August 2024, Aqua Security's Nautilus team described a class of S3 bucket-name takeover attacks they called Bucket Monopoly, affecting CloudFormation, Glue, EMR, SageMaker, Service Catalog, and CodeStar. These services auto-created S3 buckets with predictable names built from static prefixes plus the account ID and region, such as cf-templates-{hash}-{region}, aws-glue-assets-{account-id}-{region}, and sagemaker-{region}-{account-id}, where account IDs are discoverable from ARNs, access keys, and public repos. Because S3 bucket names are globally unique, an attacker could pre-create a victim's predictably named bucket in a region the victim had not yet used (a Shadow Resource), then the victim's service would later read attacker-controlled content from it. This enabled data tampering, information disclosure, remote code execution by injecting malicious Glue or CloudFormation content, and in some cases full account takeover via planted admin roles; AWS remediated by adding randomized suffixes to bucket names and enforcing aws:ResourceAccount conditions. The class also covers reuse of abandoned or dangling bucket names that a victim configuration still references.
- HIGHCVE-2024-6387
A signal-handler race condition in OpenSSH's server (sshd) on glibc-based Linux. If a client fails to authenticate within the LoginGraceTime window, the SIGALRM handler calls async-signal-unsafe functions, which an attacker can interrupt at a precise moment to corrupt the heap and achieve unauthenticated remote code execution as root. It is a regression of the 2006 CVE-2006-5051, reintroduced in OpenSSH 8.5p1. Exploitation is non-trivial, requiring thousands of race attempts, but Qualys reported roughly 4.8 million internet-exposed instances as potentially affected.
- CRITICALCONTAINER-EXPOSED-DOCKER-API
Exposed Docker API is a recurring misconfiguration class in which the Docker remote API (default TCP 2375 plaintext, 2376 TLS) is published to untrusted networks without TLS or authentication, granting anyone who reaches it full control of the daemon. Because dockerd runs as root and the unauthenticated API permits arbitrary container creation, an attacker can launch a privileged container that bind-mounts the host root filesystem and then chroots into it to escape to the host. The Commando Cat campaign, reported in 2024 by Cado Security and analyzed by Trend Micro (advisory dated 13 June 2024), abused exactly this exposure: it deployed a benign image (cmd.cat/chattr) generated by the open-source Commando project, then used chroot and volume binding of the host's root directory into the container to break out and run host-level payloads. The delivered payloads installed cryptocurrency miners, registered persistence and a stealthy backdoor (including DropBear SSH on TCP 3022), and exfiltrated host and cloud-service-provider credentials. Shell-script and command-and-control infrastructure overlapped with the TeamTNT cryptojacking group.
- HIGHCVE-2024-21626
Leaky Vessels was a set of container-escape vulnerabilities disclosed on 31 January 2024 by Rory McNamara of Snyk Security Labs, the headline flaw being CVE-2024-21626 (CVSS 8.6, runc 1.1.11 and earlier). It was an order-of-operations file-descriptor leak in runc's handling of the process working directory (WORKDIR / process.cwd). During container setup runc left an internal file descriptor referencing the host filesystem namespace open before all privileged descriptors were closed, so a malicious image or a build using a malicious Dockerfile or upstream FROM could set the working directory to that leaked descriptor via a path like /proc/self/fd/7. Because chdir occurred before the descriptor was closed, the container process gained a working directory in the host filesystem and could read and write host files, breaking container isolation and escaping to the underlying host. Related Docker BuildKit issues were disclosed alongside it: CVE-2024-23651 (mount cache race), CVE-2024-23652 (build-time arbitrary delete), and CVE-2024-23653 (GRPC SecurityMode privilege check bypass). The flaw was fixed in runc 1.1.12.