S0603: Stuxnet
Stuxnet was the first publicly reported malware to specifically target industrial control systems devices. Stuxnet is a large and complex malware that utilized multiple behaviors, including numerous zero-day vulnerabilities, a sophisticated Windows rootkit, and network infection routines.[1][2][3][4] Stuxnet was discovered in 2010, with some components being used as early as November 2008.[1]
Analyst context for executives and security teams
Stuxnet matters because it shows how Windows malware can bridge from enterprise-style compromise into industrial control system manipulation. For leaders, the decision value is not the historical malware name alone; it is the control question it raises: can the organization prove that engineering workstations, removable media paths, remote services, project files, and controller changes are governed and monitored well enough to prevent or investigate unsafe process manipulation?
Executive priority
Treat this as a cyber-physical resilience benchmark. The ATT&CK relationships connect Stuxnet to removable media replication, remote services, project file infection, rootkit behavior, controller program and parameter modification, manipulation of operator view, and manipulation of control. That makes it relevant to business continuity, safety-adjacent operational risk, compliance evidence for change control, and incident response readiness in environments where Windows systems interact with ICS assets.
Technical view
MITRE lists the supported platform as Windows and provides no official detection text for this malware object. SOC and IR teams should therefore validate coverage through the related ICS techniques: removable media use, command-line activity, remote service access, lateral file transfer, common application-layer protocol traffic, masquerading, rootkit or hooking indicators, Siemens project file integrity, and controller-side changes such as program download, tasking changes, parameter changes, I/O image manipulation, and control/view manipulation. Detection should be tested across both Windows engineering hosts and ICS process/control telemetry, because host-only monitoring may miss controller or process effects.
Likely telemetry
- Windows endpoint process, command-line, service, driver, file, and removable media events from engineering and operator workstations
- Network telemetry for remote services, SMB or other lateral file transfer, common ports, and standard application-layer protocols used in the ICS environment
- Engineering workstation and project repository evidence, including Siemens Step 7/WinCC project file access and modification history where applicable
- Controller change evidence, including program downloads, online edits, tasking changes, parameter changes, and I/O image or override-related events where available
- Process monitoring sources such as OPC tags, historian data, PLC block information, and control network traffic
Detection direction
- Do not rely on a single malware signature or Windows alert; the object has no official ATT&CK detection guidance and includes rootkit, masquerading, native API, and hooking-related behaviors that can reduce host visibility.
- Validate whether removable media introduction, project file modification, and engineering workstation activity are logged with enough user, host, device, and timestamp context to support an investigation.
- Tune remote service and lateral transfer detections against known engineering workflows to reduce false positives while still surfacing unusual source systems, timing, destinations, or file types.
- Correlate controller program or parameter changes with approved maintenance windows and change tickets; unexplained downloads or online edits should be high-priority review items.
- Compare operator view and historian/process data against independent process or controller evidence where possible, because related techniques include manipulation of view and control.
Mitigation priorities
- Prioritize asset inventory and segmentation between enterprise Windows systems, engineering workstations, and control networks.
- Govern removable media and contractor/supplier transfer paths with approval, scanning, and logging appropriate to ICS operations.
- Harden and monitor remote services and file-sharing paths used for engineering access and lateral movement.
- Maintain vulnerability and patch governance for Windows systems and remote services, recognizing the official description notes use of numerous zero-day vulnerabilities historically.
- Protect engineering project files and controller logic with version control, integrity checks, backups, and formal change approval.
Analyst notes and limits
This take is based on the official Stuxnet software object S0603 and its supplied relationships to ICS ATT&CK techniques. The most important defensive lesson is cross-domain validation: Windows endpoint evidence, engineering project evidence, network evidence, and controller/process evidence must be reviewable together.
MITRE provides no official detection text, no enterprise tactics for this object, and only Windows as the platform on the supplied software object. Local architecture, controller products, engineering tools, logging maturity, and safety constraints are required to turn this into a precise detection or mitigation plan.
Stuxnet
Stuxnet was the first publicly reported malware to specifically target industrial control systems devices. Stuxnet is a large and complex malware that utilized multiple behaviors, including numerous zero-day vulnerabilities, a sophisticated Windows rootkit, and network infection routines.[1][2][3][4] Stuxnet was discovered in 2010, with some components being used as early as November 2008.[1]
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
All related ATT&CK context
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.5 | Current bundle | 744741682439… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
Nicolas Falliere, Liam O Murchu, Eric Chien February 2011
Nicolas Falliere, Liam O Murchu, Eric Chien 2011, February W32.Stuxnet Dossier (Version 1.4) Retrieved November 17, 2024.
Open source URL -
[2]
CISA ICS Advisory ICSA-10-272-01
CISA. (2010, September 10). ICS Advisory (ICSA-10-272-01). Retrieved December 7, 2020.
Open source URL -
[3]
ESET Stuxnet Under the Microscope
Matrosov, A., Rodionov, E., Harley, D., Malcho, J.. (n.d.). Stuxnet Under the Microscope. Retrieved December 7, 2020.
Open source URL -
[4]
Langer Stuxnet
Ralph Langner. (2013, November). To Kill a Centrifuge: A Technical Analysis of What Stuxnet's Creators Tried to Achieve. Retrieved December 7, 2020.
Open source URL -
[5]
W32.Stuxnet
(Citation: Nicolas Falliere, Liam O Murchu, Eric Chien February 2011)
-
[6]
mitre-attack S0603Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.