ATT&CK for ICS T0836 Modify Parameter: Setpoint Attacks

Modify Parameter (T0836) is the attack that changes what a control system is told to do without changing its program: a setpoint, a run time, a speed limit or a threshold rewritten to a value the operators never intended. ATT&CK for ICS places it under Impair Process Control because the result is a physical process running outside its intended envelope, sometimes with no malware left on the controller at all. This guide covers what counts as a parameter, the procedure examples ATT&CK records from Stuxnet to FrostyGoop, the engineering controls that stop unsafe values reaching a device, the detection analytics ATT&CK attaches to T0836, and how to respond with process safety first. It is written for control engineers, OT security engineers, process safety staff and SOC analysts. For the tactic see the ATT&CK for ICS Impair Process Control Tactic Guide; for the matrix see the MITRE ATT&CK for ICS Guide.

Key takeaways

Parameters are data the program trusts. ATT&CK's example is a motor program whose parameter sets how many seconds the motor runs; change the value and the same logic produces a different physical result.
Most parameter writes look legitimate on the wire. FrostyGoop read and wrote registers over Modbus, the same protocol the plant uses every day, so detection depends on who wrote what value, not on spotting malware.
The best defence is in the device and the program. ATT&CK's mitigations include role-based write restriction, write protection and validating every remote parameter change against limits.
ATT&CK's analytics hinge on two baselines. An approved list of write sources and a documented safe operating range for each critical parameter; without both, alerts are guesswork.
Response starts with the process. Restore safe values through the normal operator path, confirm with operations and safety staff, then investigate how the write happened.

What T0836 covers

ATT&CK for ICS v20 describes Modify Parameter as modifying parameters used to instruct industrial control system devices. Devices run programs that decide how and when to act based on these parameters, which can set the extent of an action and specify options. An adversary can change them to produce an outcome the operators did not intend, turning them into dangerous, out-of-bounds or unexpected values, for example making a process run for more or less time than it should, or setting an unusually high, low or invalid value. The technique applies to Embedded, Windows and Linux platforms.

Parameter changes sit beside several related techniques. Telling them apart helps decide which control and which log to look at.

Technique	What changes	Example	Where to look
T0836 Modify Parameter	Values the program uses: setpoints, limits, timers, drive settings	A temperature setpoint written above its normal range	Protocol writes, HMI and historian audit trails, device change logs
T0889 Modify Program	The control logic itself	A new logic block added to a PLC	Program downloads, logic comparison against a golden copy
T0835 Manipulate I/O Image	The input or output image table the controller reads and writes	Forcing an output regardless of logic	Controller diagnostics, force status
T0858 Change Operating Mode	The controller's mode, such as run, program or remote	Switching a PLC to program mode to allow changes	Mode change events, key switch position
T0838 Modify Alarm Settings	Alarm thresholds and alarm configuration	Raising a high alarm limit so a fault goes unannounced	Alarm management audit logs

An attack can combine them: change the mode, write a parameter, and suppress the alarm that would have flagged it. See the T0889 Modify Program, T0835 Manipulate I/O Image and ICS T0858 Change Operating Mode guides.

Procedure examples ATT&CK records

ATT&CK v20 lists seven procedure examples for T0836. They are summarised here at the level ATT&CK describes them.

Procedure example	What ATT&CK records	Lesson for defenders
Stuxnet (S0603)	Sent instructions to frequency converter drives over Profibus that changed drive parameters, including the maximum frequency at which the motor operates	Drive and field device parameters are targets, not only PLC values
Industroyer2 (S1072)	Modifies specified information object addresses for specified ASDU addresses to ON or OFF	In IEC 60870-5-104 environments, a parameter write can be a switching command
INCONTROLLER (S1045)	Can use HTTP CGI scripts on Omron PLCs to modify parameters on EtherCAT-connected servo drives	Embedded web interfaces on controllers are a parameter write path
FrostyGoop (S1165)	Allows modification of system settings by reading and writing registers via Modbus	Ordinary protocol writes are enough; no controller implant is needed
FrostyGoop Incident (C0041)	The adversary caused victim controllers to report incorrect measurements by modifying parameters	Parameter changes can corrupt what operators see as well as what the process does
Maroochy Water Breach (C0020)	Remote access to the control system and altered data so pumping station functions did not occur or occurred differently, leading to 800,000 litres of raw sewage being spilled	Configuration software in the wrong hands is a parameter attack tool
2026 U.S. Water Utilities Attacks (C0066)	The adversary changed the IP addresses of internet-facing MicroLogix controllers, altering their network configuration outside normal operations	Network settings on a controller are parameters too, and changing them can cut off monitoring

ATT&CK does not attribute the 2026 U.S. Water Utilities Attacks campaign to a named group. On FrostyGoop, Dragos reported that the malware communicates over Modbus TCP on port 502, that Modbus commands sent to ENCO controllers caused inaccurate measurements and system malfunctions, and that a Ukrainian district energy company's customers lost heating for about two days. Dragos assessed with moderate confidence that the controllers were reachable because Modbus TCP was exposed to the internet. See the FrostyGoop Modbus Malware Guide and the PIPEDREAM (INCONTROLLER) ICS Toolkit Guide.

Which parameters matter most

Not every tag needs the same protection. Rank parameters by consequence with process engineers, using the plant's hazard analysis, and protect the top tier first.

Parameter class	Examples	Why it matters	Protection to prioritise
Process setpoints	Temperature, pressure, flow, level, dosing rate	Directly moves the process; may approach design limits	Engineering limits in logic, operator confirmation, write source allowlist
Drive and motor settings	Maximum speed or frequency, acceleration, run time	Can damage rotating equipment; Stuxnet targeted this class	Drive parameter write protection, local lock where available
Timers and sequence values	Run duration, valve open time, batch step times	Small changes accumulate into large effects	Range checks in logic, change control
Calibration and scaling	Sensor offsets, scaling factors	Corrupts measurements, as in the FrostyGoop incident	Restrict to engineering role, compare against calibration records
Device configuration	IP address, communication settings	Can cut off monitoring or control, as in C0066	Disable remote configuration, monitor configuration changes
Safety-related limits	Trip points held in the basic process control system	Overlaps with protection functions	Keep safety functions in an independent safety system. See the Safety Instrumented Systems Security Guide

A cyber-informed hazard review links each high-consequence parameter to the physical outcome it can cause. See the OT Cyber Physical Risk and Safety Guide.

Prevention: stopping unsafe values reaching the device

ATT&CK lists four mitigations for T0836: M0947 Audit, M0804 Human User Authentication, M0800 Authorization Enforcement and M0818 Validate Program Inputs. The joint DOE, CISA, NSA and FBI advisory on INCONTROLLER (AA22-103A, 13 April 2022) adds network and host measures that cut the paths writes travel on.

Validate inputs in the program (M0818): ATT&CK says devices and programs should validate the content of any remote parameter change, including those from HMIs, control servers and engineering workstations. In practice, clamp critical setpoints to engineering limits in the controller logic, so an out-of-range value is rejected wherever it comes from. Test this in a simulator or during an outage before relying on it.
Restrict who can write (M0800): ATT&CK says field controllers should restrict parameter changes to certain users, such as engineers and field technicians, preferably with role-based access, and should restrict online edits and enable write protection for parameters. Use controller and drive write protection features where the product supports them.
Authenticate every session (M0804): ATT&CK says field controllers should require authentication for all remote and local management sessions. Where a protocol has no authentication, compensate at the network layer.
Limit write sources on the network: AA22-103A recommends allowing connections to ICS devices only from approved engineering and management workstations, and isolating ICS networks from corporate and internet networks. Only the SCADA servers and engineering workstations should be able to send write traffic to controllers. See the Modbus TCP and Modbus Security Guide and the OPC UA Security Guide.
Remove internet exposure: the FrostyGoop incident and the C0066 campaign both involved controllers reachable from the internet. Dragos recommends not exposing Modbus services such as port 502 directly to the internet.
Audit changes (M0947): ATT&CK says to provide the ability to verify the integrity and authenticity of changes to parameter values. Keep HMI and historian audit trails, and compare critical parameters regularly against an approved baseline. AA22-103A also recommends checking controller configurations with hashing and integrity checks.

Choosing controls by situation

Situation	Preferred control	Trade-off
Controller supports role-based access and write protection	Enable both, restrict online edits to engineering roles	Engineers need a process to unlock for maintenance
Legacy controller with no authentication	Range checks in logic plus a network allowlist of write sources	Logic change needs testing and an outage window
Drives configurable over the fieldbus	Drive parameter lock where available, fieldbus not reachable from wider networks	Local changes need a site visit
Small site with few staff	Remove internet exposure, change default passwords, weekly comparison of key setpoints	Manual comparison relies on discipline

See the PLC Security Guide for controller hardening in depth.

Detection: ATT&CK's analytics for T0836

ATT&CK v20 attaches a detection strategy, Detection of Modify Parameter, with three analytics. Their fidelity gate differs from the access techniques: alert only when the action is not attributable to an authorised operator or engineering source for that target and function, and is either outside an approved change or maintenance window or lacks matching change control context; where telemetry allows, require a corroborating device, configuration or process-state effect. Activity that fully matches approved maintenance, commissioning, failover, recovery or tested control procedures is suppressed.

Platform	What it looks for	Data you need
Embedded	An ICS protocol write to a parameter or setpoint register where the value is outside the documented safe operating range, or the write comes from a source not on the approved write-source list, correlated with later historian tag drift	Protocol-aware network monitoring that decodes writes, the safe range for each critical tag, historian data
Linux	A process calling ICS vendor write APIs or OPC UA write calls to setpoint tags from a user ID not associated with the authorised control application, with values beyond the safe range	Process and user attribution on the host, OPC UA server audit logs
Windows	A process writing setpoint values to OPC DA or OPC UA tags or historian writable tags without being the recognised SCADA or DCS application, with values outside the normal range	Process telemetry on SCADA and historian hosts, OPC server audit logs

ATT&CK's embedded analytic cites FrostyGoop's direct modification of Modbus holding register values on heating controllers in Lviv, Ukraine, followed by a two-day remediation outage.

Building the baselines

Approved write sources: list the hosts allowed to write to each controller. In most plants this is a short list of SCADA servers and engineering workstations. A write from anywhere else is high fidelity.
Safe operating ranges: take them from the process design and operating procedures, agreed with process engineers. The security team should not invent them.
Change windows: feed planned maintenance and recipe changes to the monitoring team, so legitimate tuning is suppressed by the gate.
Process effect: pair network writes with historian trends. A write followed by tag drift away from normal is the corroborating signal ATT&CK describes.

See the OT Network Security Monitoring Guide and the T0801 Monitor Process State guide.

Where identity fits

ATT&CK's detection depends on attributing every write to an authorised source, which is impossible when operators share one HMI login or engineers share one controller password. Named accounts on HMIs and engineering software, distinct service accounts for SCADA and historian applications that write to devices, and changed default device passwords turn an anonymous write into an accountable one. See the OT and ICS Identity and Access Guide and NHIs in OT.

Safety-aware response

Make the process safe first: operations decide, using normal procedures, whether to restore values, move to manual control or shut down. Security staff support but do not drive process changes.
Restore known-good values through the normal path: use the approved HMI or engineering tool, against the documented baseline, and confirm the process responds as expected.
Block the write source: once the source host is known, isolate it or block its path to controllers, after confirming it is not needed for control.
Check for related changes: compare other parameters, controller programs, operating modes and alarm settings on the same and neighbouring devices.
Preserve evidence: network captures, historian data, HMI and OPC audit trails, and controller change logs. See the OT Incident Response Guide.
Review the hazard: feed the incident into the cyber hazard analysis and decide whether limits should move into logic or a safety system.

Metrics that show it is working

Critical parameters with logic-enforced limits: share of top-tier parameters clamped in controller logic. Target 100%.
Controllers reachable for writes only from approved sources: share of controllers where the network enforces the write-source allowlist.
Unexplained parameter changes: changes found in baseline comparison with no change record. Target zero; investigate every one.
Coverage of protocol-aware monitoring: share of controllers whose write traffic is decoded by monitoring.
Time to restore a safe value: measured in exercises, from detection to confirmed restoration.

Framework mapping

Control area	NIST SP 800-53 Rev 5	NIST CSF 2.0	ATT&CK for ICS mitigation
Input validation and engineering limits	SI-10 Information Input Validation	PR.PS-01	M0818 Validate Program Inputs
Role-based write restriction	AC-3 Access Enforcement; AC-6 Least Privilege	PR.AA-05	M0800 Authorization Enforcement
Session authentication	IA-2 Identification and Authentication (Organizational Users)	PR.AA-03	M0804 Human User Authentication
Change control and audit	CM-3 Configuration Change Control; AU-6 Audit Record Review, Analysis, and Reporting	PR.PS-01	M0947 Audit
Restricting write paths	SC-7 Boundary Protection	PR.IR-01	Network segmentation (see AA22-103A)
Detection	SI-4 System Monitoring	DE.CM-01; DE.CM-09	ATT&CK detection strategy for T0836

NIST SP 800-82 Rev. 3 (final, 28 September 2023) is the OT tailoring reference; NIST notes an initial public draft of Revision 4 is open for comment until 30 November 2026. See the NIST SP 800-82 OT Security Guide and the IEC 62443 Guide.

Common failure patterns

Limits only on the HMI: range checks in the HMI screen do nothing against a write sent straight to the controller, which is how FrostyGoop worked.
Controllers on the internet: both the FrostyGoop incident and the C0066 campaign involved controllers reachable from outside.
Shared logins on HMIs and controllers: without named accounts, a malicious write cannot be told apart from an operator's.
No baseline of normal values: teams discover a changed setpoint weeks later because nobody compares running values with approved ones.
Treating network settings as out of scope: a changed controller IP address can cut off monitoring as effectively as a denial of service.

Practitioner checklist

Rank parameters by consequence with process engineers and list the top tier with safe ranges.
Enforce engineering limits for top-tier parameters in controller logic, tested before go-live.
Enable role-based access and parameter write protection on controllers and drives where supported.
Restrict network write paths to approved SCADA servers and engineering workstations.
Remove controllers and their protocols from the internet and change default passwords.
Compare running values of critical parameters against the approved baseline on a schedule.
Deploy the ATT&CK T0836 analytics with a write-source list, safe ranges and change windows.
Write a response runbook that puts operations in charge of restoring safe values.

MITRE ATT&CK for ICS T0836 Modify Parameter: Detecting Unsafe Setpoint and Parameter Changes