Modify Controller Tasking (T0821) changes when and how often code runs inside a PLC or safety controller, so an adversary's program executes every cycle alongside, or ahead of, the legitimate logic. MITRE ATT&CK for ICS places it in the Execution tactic and ties it to the IEC 61131-3 model, where a task association links a task to a program organisation unit (POU). Changing those associations, or adding new ones with a higher priority or shorter interval, lets an adversary alter the controller's execution flow without necessarily touching the original program. This guide is for control engineers, OT security engineers and SOC analysts. It covers what tasking is, the three recorded cases, how to detect tasking changes, the four mitigations ATT&CK maps, and how to respond without endangering the process. For the matrix as a whole see the MITRE ATT&CK for ICS Guide.
Key takeaways
- Tasking decides what runs. Task interval, frequency and priority control execution; attaching a program to a high-priority or cyclic task guarantees it runs.
- The original logic can stay untouched. PLC-Blaster added its own block and left the user program unchanged, so comparing only the main program misses it.
- The three recorded cases span PLCs and a safety system. Stuxnet (Siemens OB1 and OB35), PLC-Blaster (Siemens S7-1200) and Triton (Triconex Tricon safety controller).
- Detection is about baselines. ATT&CK v20 analytics compare the task-to-block table with a known-good baseline and watch for scan cycle time deviations after a change.
- Integrity and authorisation are the mitigations. ATT&CK maps role-based authorisation, user authentication, cryptographic integrity checks and code signing.
What controller tasking is
In IEC 61131-3 terms, a controller runs programs (POUs) under tasks. ATT&CK describes tasks as having properties such as interval, frequency and priority, and notes that some vendors fix these properties implicitly while others let the engineer set them. Vendors use their own names for the same idea. The task types in the table below are general engineering practice, not ATT&CK text.
| Concept | What it controls | Why an adversary cares |
|---|---|---|
| Cyclic or continuous task | Runs the program on every scan | Code attached here runs constantly; ATT&CK gives Siemens Organization Block 1 (OB1) as the example |
| Periodic or timed task | Runs at a fixed interval | Stuxnet used OB35, which the Symantec dossier describes as a watchdog block run every 100 ms |
| Priority | Which task wins when two are due | Higher priority means adversary code can pre-empt or starve legitimate logic |
| Task association | Which POU runs under which task | Changing the association reroutes execution without editing the program text |
| Cycle time limit | Maximum allowed scan time before a fault | Added code must fit inside it; on many controllers exceeding it raises a fault or stops the controller, a denial of service |
ATT&CK notes that tasking can be modified through Program Download (T0843) and through other forms of program change such as online edit and program append. Changes to the program content itself are covered by T0889 Modify Program; T0821 is about the execution schedule and entry points. The tactic context is in the ATT&CK for ICS Execution Tactic Guide.
Real cases recorded by ATT&CK
| Case | Tasking change (as ATT&CK and its cited sources record) | Lesson for defenders |
|---|---|---|
| Stuxnet (S0603) | Infected OB1 so its code ran at the start of each cycle, and infected OB35, which can stop OB1 from executing under certain conditions. The Symantec dossier describes code prepended to the original blocks, and a replaced Step 7 communication library that hid the changes from engineering software | Engineering software on a compromised workstation may show you clean logic; verify blocks from a clean environment |
| PLC-Blaster (S1006) | Research worm for Siemens S7-1200 that stored its code in an added block (OB9999), which the PLC detects and executes automatically; the original user program is untouched | Check for added blocks and task entries, not just changes to existing ones |
| Triton (S1009) | Argument-setting code and a shellcode payload were added to the program table on the Tricon so the firmware executed them once each cycle | Safety controllers have tasking too; protect their program loading path as carefully as the logic |
What the cases teach about entry conditions
- Stuxnet: the Symantec dossier records that it targeted specific Siemens S7-300 CPUs (6ES7-315-2) with particular configurations, and intercepted read, write and enumerate routines so operators did not see the infected blocks. It also notes an infected PLC can still be identified by examining OB1 and OB35 from a clean environment.
- PLC-Blaster: the authors found that of the S7-1200's protection features, only access protection with a password (disabled by default on the tested firmware) blocked the worm's code changes. They also note the controller stops for about 10 seconds during infection and that this is logged.
- Triton: Midnight Blue's analysis records that the targeted Tricon 3008 controllers were left in PROGRAM mode on the key switch, which normally permits loading control programs. It identifies the unauthenticated TriStation protocol as the core weakness, so restricting which hosts can reach the controller matters more than protocol passwords.
Platform hardening is covered in the Siemens SIMATIC S7 and TIA Portal Hardening Guide and safety systems in the Safety Instrumented Systems Security Guide. Operating mode abuse is covered in ICS T0858 Change Operating Mode.
Detection: the ATT&CK v20 analytic in practice
ATT&CK v20 has one analytic for T0821, for embedded devices. It looks for an industrial protocol write to a controller's task or organisation block configuration from a source not on the engineering workstation list, and correlates it with scan cycle timing deviation afterwards. Like other ICS analytics it alerts only when the change cannot be attributed to an authorised source and falls outside an approved change window or lacks change-control context.
| Signal | Source named by ATT&CK | How to implement |
|---|---|---|
| Task-to-block assignment differs from the last known-good baseline with no change ticket | Asset inventory program comparison | Scheduled read of controller projects by an OT asset or change management tool, compared against the approved version |
| Task or organisation block modification service from an unapproved source outside a change window | OT network sensor content | Protocol-aware monitoring that decodes program download, online edit and block write services |
| Scan cycle time or interrupt latency deviates from baseline after a task change | Device vendor log | Collect cycle time statistics from controller diagnostics; set a per-controller baseline and deviation threshold |
Practical points
- Baseline the task table, not only the code: record each controller's tasks, their intervals and priorities, and which blocks or POUs each runs. An added block or new association is the PLC-Blaster pattern.
- Compare from a trusted host: Stuxnet shows that engineering software on an infected workstation can lie. Run integrity comparisons from a separate, hardened system. See the Engineering Workstation Security Guide.
- Watch cycle time: ATT&CK names baseline cycle time and a deviation threshold as tuning values. Added code consumes cycle time, and a sudden step change after a download is worth checking.
- Alert on controller stop and mode changes around downloads: program loads often coincide with a mode change or brief stop that controllers record in diagnostics.
- Feed change tickets to the SOC: without them, every legitimate engineering change becomes a false positive.
Sensor placement is covered in the OT Network Security Monitoring Guide; collecting projects for comparison relates to T0845 Program Upload, which defenders use legitimately for the same purpose.
Prevention: the four mitigations ATT&CK maps
| Mitigation | ATT&CK guidance (paraphrased) | How to apply it |
|---|---|---|
| M0800 Authorization Enforcement | Restrict modification of controller tasks to certain users such as engineers and field technicians, preferably role-based | Use controller and engineering software roles; separate view-only operators from engineers who may download |
| M0804 Human User Authentication | Require authentication for all remote and local management sessions on field controllers | Turn on controller access protection passwords (often off by default, as PLC-Blaster's authors found); unique per controller |
| M0947 Audit | Provide a way to verify the integrity of controller tasking; prefer cryptographic hashes such as SHA-2 or SHA-3 over CRCs and checksums, which can collide | Hash approved project and task configurations and compare on a schedule and after every change |
| M0945 Code Signing | Use code signatures to verify the integrity and authenticity of programs on safety or control assets, including tasking | Use signed program features where the controller supports them; otherwise rely on M0947 comparisons |
Supporting controls
- Physical mode controls: where controllers have a key switch, keep it in RUN and manage the key. The Triton case shows the cost of leaving safety controllers in PROGRAM mode.
- Restrict the download path: only approved engineering hosts should reach controller programming services; use allowlists at zone boundaries. See the OT Network Segmentation, Purdue Model and IEC 62443 Zones and Conduits Guide.
- Project file hygiene: store approved projects in version control with hashes, so the comparison baseline itself is trustworthy. See T0873 Project File Infection.
- Supplier checks: PLC-Blaster's authors warn infected PLCs could arrive through suppliers; verify the program on new or returned controllers before commissioning.
Choosing what to do first
A small site with a few PLCs gets most value from controller passwords, key switch discipline and a monthly comparison against a hashed baseline. Larger plants add protocol-aware monitoring of download services, automated project comparison across the fleet, and cycle time trending in the historian.
Where identity fits
Tasking can only be changed by something the controller accepts as an engineering session. Shared engineering logins, controller passwords reused across a plant, and vendor accounts used for remote support all widen that set. Make engineering access individual, keep controller passwords unique and vaulted, and time-limit vendor sessions so the "source not on the engineering workstation list" check means something. See NHIs in OT and the OT and ICS Identity and Access Guide.
Safety-aware response
- Do not download over a suspect controller in a hurry: stopping a controller to reload logic changes the process. Operations decide the timing and whether to move to manual or a safe state.
- Confirm the safety system: if a safety controller may be affected, treat it as a process safety event and involve the safety engineer. See the Safety Instrumented Systems Security Guide.
- Collect the controller's current project from a clean host: upload the running configuration and compare tasks and blocks with the approved baseline.
- Find the source: identify which engineering host or session performed the download and isolate it; assume its engineering software may be untrustworthy.
- Restore from a verified baseline: reload the approved project with matching hashes during an agreed window, then verify cycle time and behaviour with operations.
The full process is in the OT Incident Response Guide and recovery in the OT Backup, Recovery and Golden Image Guide.
Metrics that show it is working
- Baseline coverage: share of controllers with a hashed, approved project including the task table.
- Comparison frequency: share of critical controllers compared against baseline in the last 30 days.
- Unmatched downloads: program downloads or online edits with no matching change ticket, and the share investigated within a shift.
- Access protection enabled: share of controllers with password protection or equivalent write protection on.
- Key switch compliance: share of controllers with physical mode switches found in RUN during audits.
Framework mapping
| Control area | NIST SP 800-53 Rev 5 | NIST CSF 2.0 | ATT&CK for ICS mitigation |
|---|---|---|---|
| Who may change tasking | AC-3 Access Enforcement; CM-5 Access Restrictions for Change | PR.AA-05 | M0800 Authorization Enforcement; M0804 Human User Authentication |
| Integrity of programs and tasking | SI-7 Software, Firmware, and Information Integrity | DE.CM-09 | M0947 Audit; M0945 Code Signing |
| Approved baselines and change control | CM-3 Configuration Change Control; CM-6 Configuration Settings | PR.PS-01 | Basis of the ATT&CK baseline analytic |
| Download path restriction | SC-7 Boundary Protection | PR.IR-01 | Not mapped to T0821 in ATT&CK v20 (NHI Mgmt Group addition) |
| Monitoring | SI-4 System Monitoring | DE.CM-01 | Detection strategy for T0821 |
For OT tailoring see the NIST SP 800-82 OT Security Guide and the IEC 62443 Guide.
Common failure patterns
- Comparing only the main program: added blocks and new task associations go unnoticed, which is exactly how PLC-Blaster stayed hidden.
- Trusting the engineering workstation's view: Stuxnet showed the engineering software itself can be made to hide changes.
- Controller passwords off: write protection exists but was never enabled, so any host reaching the programming port can change tasking.
- Safety controllers left in program mode: the Triton case is the reference example.
- Checksums treated as integrity: ATT&CK notes CRCs and checksums are not cryptographically secure; use proper hashes.
Practitioner checklist
- Record each controller's tasks, intervals, priorities and task-to-POU associations in the approved baseline.
- Hash approved projects with SHA-2 or SHA-3 and compare running controllers on a schedule and after every change.
- Run comparisons from a hardened host separate from day-to-day engineering workstations.
- Enable controller access or write protection with unique, vaulted passwords.
- Keep key switches in RUN and control the keys, especially on safety controllers.
- Allow programming services only from approved engineering hosts, and monitor download and online edit services.
- Trend scan cycle time per controller and alert on step changes after downloads.
- Verify programs on new and returned controllers before commissioning.
Standards and references
- MITRE ATT&CK for ICS: Modify Controller Tasking (T0821)
- MITRE ATT&CK for ICS: Audit (M0947)
- NIST: SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security
- Symantec: W32.Stuxnet Dossier
- Midnight Blue: Analyzing the TRITON industrial malware
- Spenneberg, Bruggemann and Schwartke: PLC-Blaster, A Worm Living Solely in the PLC
Related NHI Mgmt Group resources: MITRE ATT&CK for ICS Guide · PLC Security Guide · ICS Malware History Guide · T0835 Manipulate I/O Image · OT Security Guide