T0836: Modify Parameter
Adversaries may modify parameters used to instruct industrial control system devices. These devices operate via programs that dictate how and when to perform actions based on such parameters. Such parameters can determine the extent to which an action is performed and may specify additional options. For example, a program on a control system device dictating motor processes may take a parameter defining the total number of seconds to run that motor.
An adversary can potentially modify these parameters to produce an outcome outside of what was intended by the operators. By modifying system and process critical parameters, the adversary may cause Impact to equipment and/or control processes. Modified parameters may be turned into dangerous, out-of-bounds, or unexpected values from typical operations. For example, specifying that a process run for more or less time than it should, or dictating an unusually high, low, or invalid value as a parameter.
Analyst context for executives and security teams
Modify Parameter is material because small changes to controller or device settings can change how a physical process behaves. In an ICS environment, this is not just a configuration issue; it can affect equipment, production, utilities, safety margins, and service delivery. The ATT&CK relationships show this behavior is relevant to PLCs, RTUs, IEDs, DCS Controllers, and PACs, so leaders should treat parameter integrity as part of operational resilience, not only cyber monitoring.
Executive priority
Prioritize this where control parameters directly affect safety, availability, quality, or public service delivery. Executives should ask whether critical setpoints, timing values, limits, and controller parameters are authenticated, authorized, range-checked, audited, and recoverable to a known-good state. This technique also supports audit and compliance evidence: organizations should be able to show who can change parameters, how changes are approved, how abnormal values are detected, and how integrity is verified after reboots, downloads, or restarts.
Technical view
SOC, OT engineering, and incident response teams should validate monitoring and control coverage around parameter writes and out-of-range values on targeted ICS assets: PLCs, RTUs, IEDs, DCS Controllers, and PACs. ATT&CK does not provide official detection text for T0836, but it identifies a related detection strategy, DET0776, and mitigations focused on authorization enforcement, human user authentication, input validation, and audit. Detection engineering should therefore center on authorized-vs-unauthorized parameter changes, values outside intended operational ranges, unusual timing or magnitude of changes, and post-change process deviations. IR playbooks should include comparison against known-good controller programs/configurations and coordination with operations before reverting values or placing processes into a safe state.
Likely telemetry
- Controller or device event logs showing parameter writes, configuration changes, downloads, restarts, or reboots
- Engineering workstation and control server activity associated with changing PLC, RTU, IED, DCS Controller, or PAC parameters
- ICS protocol or network records that show read/write activity to device registers, settings, or control variables where available
- Historian, SCADA, HMI, or alarm data showing unexpected process values, setpoint changes, timing changes, or invalid/out-of-bounds values
- Authentication and authorization records for users or systems permitted to read, manipulate, or execute commands
Detection direction
- Validate whether DET0776-style coverage exists for parameter modification, not only malware or network intrusion alerts.
- Baseline normal operational ranges and approved change windows so detection can distinguish legitimate tuning from suspicious or dangerous values.
- Correlate parameter changes with authenticated user identity, role, source system, engineering workstation activity, and operational approval records.
- Tune alerts for out-of-bounds, unusually high, unusually low, invalid, or unexpected parameter values, while accounting for maintenance and process startup/shutdown conditions.
- Look for blind spots where field devices lack logging, ICS protocols do not provide strong identity context, or changes occur through legitimate commands that appear operationally normal.
Mitigation priorities
- Enforce authorization so only authenticated users with approved operational need can read, manipulate, or execute parameter-related actions.
- Require human user authentication before devices accept data access or commands; use stronger authentication where feasible for the ICS environment.
- Validate program inputs so parameters are checked for format, content, and intended operational range, with safe defaults or safe-state behavior for problematic values.
- Perform periodic audits and integrity checks of firmware, software, programs, and configurations against known-valid states, especially after device reboots, program downloads, or restarts.
- Maintain recoverable known-good parameter baselines and coordinate cyber response actions with OT engineering to avoid unsafe restoration or process disruption.
Analyst notes and limits
The strongest business takeaway is that parameter integrity is a cyber-physical control objective. This behavior may use legitimate functionality, so prevention and detection depend heavily on identity, authorization, engineering change governance, device logging, process baselines, and OT-aware incident response. The supplied relationships support relevance to multiple embedded control assets and to historical ICS incidents/software, but local asset criticality and process design determine actual risk.
ATT&CK does not provide official detection text, tactics, aliases, labels, or platforms for this technique object. Platform context is inferred only from related targeted ICS assets and related software entries, not from the technique’s own platform field. This summary does not assert current exploitation, attribution, customer exposure, or guaranteed detection coverage.
Modify Parameter
Adversaries may modify parameters used to instruct industrial control system devices. These devices operate via programs that dictate how and when to perform actions based on such parameters. Such parameters can determine the extent to which an action is performed and may specify additional options. For example, a program on a control system device dictating motor processes may take a parameter defining the total number of seconds to run that motor.
An adversary can potentially modify these parameters to produce an outcome outside of what was intended by the operators. By modifying system and process critical parameters, the adversary may cause Impact to equipment and/or control processes. Modified parameters may be turned into dangerous, out-of-bounds, or unexpected values from typical operations. For example, specifying that a process run for more or less time than it should, or dictating an unusually high, low, or invalid value as a parameter.
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
S1165: FrostyGoop
FrostyGoop is a Windows-based binary written in Golang that allows for interaction with industrial control system (ICS) equipment via Modbus TCP over port 502. FrostyGoop allows for reading and writing data to holding registers on targeted devices, manipulating the operation of systems for malicious purposes. FrostyGoop is associated with the FrostyGoop Incident in Ukraine.[1][2]
S1045: INCONTROLLER
INCONTROLLER is custom malware that includes multiple modules tailored towards ICS devices and technologies, including Schneider Electric and Omron PLCs as well as OPC UA, Modbus, and CODESYS protocols. INCONTROLLER has the ability to discover specific devices, download logic on the devices, and exploit platform-specific vulnerabilities. As of September 2022, some security researchers assessed INCONTROLLER was developed by CHERNOVITE.[1][2][3][4][5]
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]
S1072: Industroyer2
Industroyer2 is a compiled and static piece of malware that has the ability to communicate over the IEC-104 protocol. It is similar to the IEC-104 module found in Industroyer. Security researchers assess that Industroyer2 was designed to cause impact to high-voltage electrical substations. The initial Industroyer2 sample was compiled on 03/23/2022 and scheduled to execute on 04/08/2022, however it was discovered before deploying, resulting in no impact.[1]
C0041: FrostyGoop Incident
FrostyGoop Incident took place in January 2024 against a municipal district heating company in Ukraine. Following initial access via likely exploitation of external facing services, FrostyGoop was used to manipulate ENCO control systems via legitimate Modbus commands to impact the delivery of heating services to Ukrainian civilians.[1][2]
C0020: Maroochy Water Breach
Maroochy Water Breach was an incident in 2000 where an adversary leveraged the local government’s wastewater control system and stolen engineering equipment to disrupt and eventually release 800,000 liters of raw sewage into the local community.[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.3 | Current bundle | 6db1871e00cf… |
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]
mitre-attack T0836Open 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.