S1006: PLC-Blaster
PLC-Blaster is a piece of proof-of-concept malware that runs on Siemens S7 PLCs. This worm locates other Siemens S7 PLCs on the network and attempts to infect them. Once this worm has infected its target and attempted to infect other devices on the network, the worm can then run one of many modules. [1] [2]
Analyst context for executives and security teams
PLC-Blaster matters because it demonstrates malware that can live on Siemens S7 PLCs, find other Siemens S7 PLCs, attempt to spread, and then run additional modules. For executives and OT security leaders, the practical issue is not a generic IT infection; it is whether controller networks have enough segmentation, change visibility, and recovery discipline to prevent PLC-to-PLC propagation from becoming an operational disruption or unsafe process condition.
Executive priority
Treat this as an OT resilience and control-integrity scenario. Leaders should ask whether Siemens S7 controller environments are inventoried, segmented, monitored for controller logic and mode changes, and recoverable from trusted backups. Because the ATT&CK entry is proof-of-concept malware with no official detection guidance and unspecified platforms/tactics, prioritization should be based on local exposure: presence of Siemens S7 PLCs, network paths between PLCs, engineering workstation access, and evidence required for audit, incident response, and operational continuity decisions.
Technical view
SOC, OT, and IR teams should validate visibility around the related ATT&CK behaviors: port scanning for PLC discovery, program download, controller operating mode changes, controller tasking modification, program modification, I/O image manipulation, native API interaction, and denial-of-service symptoms. Since MITRE does not provide detection text for this object, detection engineering should be environment-specific and should focus on deviations from approved engineering activity, unexpected PLC-to-PLC communication, unauthorized controller program changes, and controller unresponsiveness or reboot conditions that align with DoS behavior.
Likely telemetry
- OT network traffic showing communication among Siemens S7 PLCs and possible PLC discovery or port scanning activity
- Engineering workstation and controller interaction logs, where available, for program downloads, online edits, or program append activity
- Controller mode/state change records, including transitions that enable engineering functions
- PLC project files, logic versions, task associations, and change-management records for comparison against approved baselines
- Controller diagnostics indicating unresponsive devices, reboots, stop states, or abnormal execution behavior
Detection direction
- Baseline normal engineering workflows and alert on controller program downloads, tasking changes, or operating mode changes outside approved maintenance windows.
- Monitor for unexpected PLC-to-PLC communication or scanning-like behavior, especially where controllers should not initiate discovery of peer devices.
- Correlate network observations with controller state and change records; network traffic alone may not prove malicious modification.
- Tune detections to account for legitimate commissioning, maintenance, online edits, and troubleshooting, which may resemble program download or mode-change activity.
- Investigate DoS-like symptoms together with recent controller communication, program changes, and mode transitions rather than treating outages as purely reliability events.
Mitigation priorities
- Prioritize accurate inventory of Siemens S7 PLCs and their authorized communication relationships.
- Restrict and segment controller-to-controller and engineering-to-controller network paths to what operations require.
- Enforce formal change control for PLC logic, tasking, program downloads, and mode changes, with retained evidence for audits and incident response.
- Maintain known-good controller logic and recovery procedures so operations can restore trusted states after suspected modification or disruption.
- Review access paths to engineering functions and controller APIs, including who or what can initiate program downloads or operating mode changes.
Analyst notes and limits
This take is based on the official ATT&CK description, external references, and relationships for PLC-Blaster. The relationship set is useful because it connects the malware to concrete defensive validation areas: discovery via port scan, controller program and tasking changes, operating mode changes, I/O manipulation, native API use, program download, and denial of service. The object should be used as a tabletop and detection-validation driver for Siemens S7 environments rather than as evidence of current activity.
MITRE provides no official detection text, no listed platforms field, no tactics field, no aliases, and no claim of active exploitation in the supplied object. Any assessment of exposure, likelihood, detection coverage, or business impact requires local asset inventory, network architecture, controller model details, engineering workflow evidence, and OT monitoring capability.
PLC-Blaster
PLC-Blaster is a piece of proof-of-concept malware that runs on Siemens S7 PLCs. This worm locates other Siemens S7 PLCs on the network and attempts to infect them. Once this worm has infected its target and attempted to infect other devices on the network, the worm can then run one of many modules. [1] [2]
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.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| ICS | T0821 | Modify Controller Tasking | PLC-Blaster's code is stored in OB9999. The original code on the target is untouched. The OB is automatically detected by the PLC and executed. CitationSpenneberg, Ralf, Maik Brggemann, and Hendrik Schwartke March 2016 |
| ICS | T0834 | Native API | PLC-Blaster uses the system function blocks TCON and TDISCON to initiate and destroy TCP connections to arbitrary systems. Buffers may be sent and received on these connections with TRCV und TSEND system function blocks. CitationSpenneberg, Ralf, Maik Brggemann, and Hendrik Schwartke March 2016 |
| ICS | T0843 | Program Download | PLC-Blaster utilizes the PLC communication and management API to load executable Program Organization Units. CitationSpenneberg, Ralf, Maik Brggemann, and Hendrik Schwartke March 2016 |
| ICS | T0814 | Denial of Service | The execution on the PLC can be stopped by violating the cycle time limit. The PLC-Blaster implements an endless loop triggering an error condition within the PLC with the impact of a DoS. CitationSpenneberg, Ralf, Maik Brggemann, and Hendrik Schwartke March 2016 |
| ICS | T0835 | Manipulate I/O Image | PLC-Blaster may manipulate any outputs of the PLC. Using the POU POKE any value within the process image may be modified. CitationSpenneberg, Ralf, Maik Brggemann, and Hendrik Schwartke March 2016 |
| ICS | T0889 | Modify Program | PLC-Blaster copies itself to various Program Organization Units (POU) on the target device. The POUs include the Data Block, Function, and Function Block. CitationSpenneberg, Ralf, Maik Brggemann, and Hendrik Schwartke March 2016 |
| ICS | T0858 | Change Operating Mode | PLC-Blaster stops the execution of the user program on the target to enable the transfer of its own code. The worm then copies itself to the target and subsequently starts the target PLC again. CitationSpenneberg, Ralf, Maik Brggemann, and Hendrik Schwartke March 2016 |
| ICS | T0846.001 | Port Scan Sub-technique | PLC-Blaster scans the network to find other Siemens S7 PLC devices to infect. It locates these devices by checking for a service listening on TCP port 102.CitationSpenneberg, Ralf, Maik Brggemann, and Hendrik Schwartke March 2016 |
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.1 | Current bundle | 845994ea400b… |
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]
Spenneberg, Ralf, Maik Brggemann, and Hendrik Schwartke March 2016
Spenneberg, Ralf, Maik Brggemann, and Hendrik Schwartke 2016, March 31 Plc-blaster: A worm living solely in the plc. Retrieved. 2017/09/19
Open source URL -
[2]
Spenneberg, Ralf 2016
Spenneberg, Ralf 2016 PLC-Blaster Retrieved. 2019/06/06
Open source URL -
[3]
mitre-attack S1006Open 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.