T0821: Modify Controller Tasking
Adversaries may modify the tasking of a controller to allow for the execution of their own programs. This can allow an adversary to manipulate the execution flow and behavior of a controller.
According to 61131-3, the association of a Task with a Program Organization Unit (POU) defines a task association. [1] An adversary may modify these associations or create new ones to manipulate the execution flow of a controller. Modification of controller tasking can be accomplished using a Program Download in addition to other types of program modification such as online edit and program append.
Tasks have properties, such as interval, frequency and priority to meet the requirements of program execution. Some controller vendors implement tasks with implicit, pre-defined properties whereas others allow for these properties to be formulated explicitly. An adversary may associate their program with tasks that have a higher priority or execute associated programs more frequently. For instance, to ensure cyclic execution of their program on a Siemens controller, an adversary may add their program to the task, Organization Block 1 (OB1).
Analyst context for executives and security teams
Modify Controller Tasking matters because it targets the execution schedule and priority of industrial controller logic, not just the code itself. If an adversary can change which programs are associated with controller tasks, or how often and at what priority they run, they may alter PLC, PAC, DCS controller, or safety controller behavior in ways that can affect process reliability and safety-critical operations. For leaders, this is a control-governance issue: the organization must know who can change controller tasking, how those changes are approved, and whether changes can be independently verified against a known-good state.
Executive priority
Treat this as a high-consequence ICS integrity risk where controller change control, privileged access, and audit evidence are decisive. Priority questions include: are controller program/task changes restricted to authenticated and authorized users; are downloads, online edits, appends, and task association changes reviewed; and can operations prove controller logic and configuration match approved baselines after reboots, downloads, or restarts? This technique is especially material for environments with PLCs, PACs, DCS controllers, or safety controllers because unauthorized changes may influence operational execution flow.
Technical view
SOC, IR, and OT engineering teams should validate monitoring and governance around controller task associations, program downloads, online edits, program appends, task priority, interval, and frequency changes. ATT&CK provides no official detection text for this technique, but relationship context identifies DET0741, Detection of Modify Controller Tasking, as a relevant detection strategy. Defensive validation should focus on whether controller engineering activity and controller integrity states can be compared to approved baselines. Relationship context also links this behavior to Stuxnet, PLC-Blaster, and Triton, so defenders should treat controller-tasking changes as a high-value investigation pivot when reviewing ICS malware or unauthorized engineering workstation activity, without assuming those tools are present locally.
Likely telemetry
- Controller program and configuration baselines, including task-to-program associations where available
- Engineering workstation activity related to program downloads, online edits, and program appends
- Controller change logs or audit records showing task interval, frequency, priority, or association changes
- Authentication and authorization logs for users or systems permitted to read, manipulate, or execute controller operations
- Integrity check results using hashes, signatures, or known-valid controller firmware, software, program, and configuration states
Detection direction
- Confirm whether DET0741-style detection can identify changes to controller tasking, not only full program downloads.
- Tune alerting around unauthorized or unexpected controller task association changes, especially changes that increase execution frequency or priority of a program.
- Correlate controller changes with authenticated user identity, approved maintenance windows, and documented change tickets to reduce false positives from legitimate engineering work.
- Include online edits and program appends in detection scope; focusing only on complete downloads may miss relevant modification paths described by ATT&CK.
- Validate visibility across targeted ICS asset classes named in ATT&CK: PLCs, safety controllers, DCS controllers, and PACs.
Mitigation priorities
- Enforce authorization so only authenticated users with approved roles can read, manipulate, or execute controller operations.
- Require human user authentication before accepting commands or access to controller data, while accounting for ICS feasibility constraints.
- Use code signing or digital signature verification where supported to prevent untrusted code from executing.
- Perform periodic audits and integrity checks of controller firmware, software, programs, configurations, and tasking against known-valid states.
- Prioritize integrity validation after device reboots, program downloads, and program restarts, as highlighted by the related Audit mitigation.
Analyst notes and limits
The supplied ATT&CK object is an ICS technique, T0821 Modify Controller Tasking. It has no specified ATT&CK tactics or platforms in the object, but relationship context identifies embedded ICS assets as targets: PLCs, safety controllers, DCS controllers, and PACs. MITRE also relates this technique to Stuxnet, PLC-Blaster, and Triton software entries, and to mitigations for authorization enforcement, human user authentication, code signing, and audit. The IEC 61131-3 reference is important because the technique centers on task associations with Program Organization Units and task properties such as interval, frequency, and priority.
Official ATT&CK detection text is not provided, and the related detection strategy details are limited to the supplied relationship name. Local controller models, vendor capabilities, engineering tools, logging availability, and approved operating procedures are required to determine actual detection coverage and control feasibility. This summary does not assert active exploitation, attribution, customer exposure, or guaranteed detection.
Modify Controller Tasking
Adversaries may modify the tasking of a controller to allow for the execution of their own programs. This can allow an adversary to manipulate the execution flow and behavior of a controller.
According to 61131-3, the association of a Task with a Program Organization Unit (POU) defines a task association. [1] An adversary may modify these associations or create new ones to manipulate the execution flow of a controller. Modification of controller tasking can be accomplished using a Program Download in addition to other types of program modification such as online edit and program append.
Tasks have properties, such as interval, frequency and priority to meet the requirements of program execution. Some controller vendors implement tasks with implicit, pre-defined properties whereas others allow for these properties to be formulated explicitly. An adversary may associate their program with tasks that have a higher priority or execute associated programs more frequently. For instance, to ensure cyclic execution of their program on a Siemens controller, an adversary may add their program to the task, Organization Block 1 (OB1).
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.
Groups, software, and campaigns
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]
S1009: Triton
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]
All related ATT&CK context
Mitigation direction
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.2 | Current bundle | 901e96723972… |
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]
IEC February 2013
IEC 2013, February 20 IEC 61131-3:2013 Programmable controllers - Part 3: Programming languages Retrieved. 2019/10/22
Open source URL -
[2]
mitre-attack T0821Open 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.