Probably not on day one, and that is not a failing. Stuxnet combined removable drives, four unpatched Windows flaws, two stolen signing certificates and infected engineering projects to reach one kind of controller. The useful question is which of those steps your controls would have noticed, and how quickly.
What did Stuxnet actually do?
Everything here comes from Symantec's W32.Stuxnet Dossier (version 1.4, February 2011), which we fetched and read. Its executive summary says the threat targeted a specific industrial control system, likely in Iran, and aimed to reprogram programmable logic controllers (PLCs). It says Stuxnet was discovered in July 2010 but had existed at least a year earlier.
The dossier lists the mechanisms. It spread through removable drives using a Windows shortcut flaw, across a LAN through a Print Spooler flaw and an older SMB flaw, through network shares, through WinCC database servers, and by copying itself into Step 7 projects so it ran when a project opened. It exploited four unpatched Microsoft vulnerabilities in total. It carried a Windows rootkit and what Symantec called the first PLC rootkit, which hid modified code from the operator.
The dossier's attack scenario section is labeled speculation, so treat the story of how it got in as a hypothesis. The technical features are the firm part.
Why is this a fair test and not a blame exercise?
The dossier says the build likely took months and a team of core developers, plus a mirrored hardware lab. Few organizations would face an adversary with that budget. Nobody is at fault for failing to stop it alone. The checklist is for finding the cheap steps that would have made the attack noisier.
What to do
Answer each question for your own sites. Mark anything you cannot answer with evidence as a gap.
- Removable media. Can a USB drive run code on an engineering workstation? Check autorun behavior and any device control policy, and ask who may plug what in. The dossier names a USB path as one propagation route and as a way to cross the last gap to machines never connected to a network.
- Patch gaps on Windows hosts near controllers. The dossier mentions an SMB flaw (MS08-067) that was about two years old when Stuxnet used it. List the oldest missing Windows patches in your OT-adjacent network. NIST SP 800-40 Rev. 4 frames patching as routine preventive maintenance and recommends an enterprise strategy, which applies here too, with change windows that respect plant safety.
- Signed does not mean trusted. Stuxnet drivers were signed with certificates belonging to Realtek and JMicron. The Realtek certificate was revoked by Verisign on July 16, 2010. Ask whether your endpoint controls rely on a valid signature alone, and whether you can allow list drivers by hash or publisher plus expected path.
- Engineering workstations as crown jewels. Stuxnet infected Step 7 and WinCC machines, because those machines program the PLCs. Treat them like domain controllers: dedicated, minimal software, no email or browsing, logged.
- Project and logic integrity. Because malware hid its PLC changes from the operator, comparing what the engineering tool shows against itself proves little. Keep known good copies of controller logic and compare from a separate, trusted path.
- Hardcoded and shared credentials. The dossier describes infection of WinCC databases through a hardcoded password. Search your vendor products for default or fixed credentials and track who has asked the vendor to remove them.
- Lateral movement paths. Which network shares, print services and SMB paths connect your business network to your control network? Remove the ones nobody can justify.
- Contractor and vendor devices. The dossier speculates that a third party or insider may have carried the first infection. Decide how laptops and media from outside enter a plant, and who inspects them.
- Software inventory. You cannot judge a Windows flaw you do not know applies. Keep a list of what runs on each engineering host. A tool such as the Safeguard CLI can build an SBOM from a directory or image with
safeguard scan --dir ., but it matches components against vulnerability data and does not replace OT specific monitoring. - Detection for the quiet parts. Stuxnet updated itself peer to peer inside a LAN. Ask whether you would see unusual traffic between workstations that rarely talk, not only outbound traffic.
NIST SP 800-82 Rev. 3 is the general reference for OT security. It covers OT topologies, common threats and vulnerabilities, and recommended countermeasures, with the performance, reliability and safety needs of these systems in mind.
What are the limits of this checklist?
It is based on one vendor's analysis from 2011. Techniques have moved on, and a clean checklist does not mean you are safe. It also covers controls, not response. Add a plan for what operators do when they cannot trust the display in front of them.
Quick check
Was Stuxnet only a USB problem?
No. The dossier lists several routes: removable drives, LAN and SMB flaws, network shares, WinCC servers and Step 7 project files. USB was one route, and Symantec's scenario suggests it covered the final hop to isolated machines.
Does patching alone stop this class of attack?
It removes the known flaws, which helps, but two of the four flaws were unpatched and undisclosed at the time. Layers such as segmentation, media control and logic integrity checks are what remain when a patch does not exist yet.
Sources
- W32.Stuxnet Dossier, version 1.4, Symantec Security Response, February 2011 (copy hosted by the University of Maryland, fetched 18 October 2026)
- NIST SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security
- NIST SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning
- Safeguard CLI documentation
Last reviewed: 18 October 2026.
