T0838: Modify Alarm Settings
Adversaries may modify alarm settings to prevent alerts that may inform operators of their presence or to prevent responses to dangerous and unintended scenarios. Reporting messages are a standard part of data acquisition in control systems. Reporting messages are used as a way to transmit system state information and acknowledgements that specific actions have occurred. These messages provide vital information for the management of a physical process, and keep operators, engineers, and administrators aware of the state of system devices and physical processes.
If an adversary is able to change the reporting settings, certain events could be prevented from being reported. This type of modification can also prevent operators or devices from performing actions to keep the system in a safe state. If critical reporting messages cannot trigger these actions then a Impact could occur.
In ICS environments, the adversary may have to use Alarm Suppression or contend with multiple alarms and/or alarm propagation to achieve a specific goal to evade detection or prevent intended responses from occurring. [1] Methods of suppression often rely on modification of alarm settings, such as modifying in memory code to fixed values or tampering with assembly level instruction code.
Analyst context for executives and security teams
Modify Alarm Settings matters because alarms are part of how industrial operators know when a process, device, or safety condition needs attention. If an adversary can change reporting or alarm behavior, the organization may lose the warning signs that normally trigger operator response or automated safety actions. For leaders, this is not just an alerting issue; it is an operational resilience and safety assurance issue for environments that depend on HMIs, controllers, RTUs, IEDs, gateways, and safety-related devices.
Executive priority
Prioritize this behavior where ICS processes rely on alarms for safe operations, incident escalation, or compliance evidence. Executives should ask whether alarm configuration changes are authorized, logged, reviewed, and recoverable across critical control assets. Budget and governance decisions should focus on access control, authentication, segmentation, and account management around systems that can alter reporting settings. The ATT&CK relationship to the Maroochy Water Breach highlights that alarm and control-system manipulation has historical relevance in real-world ICS disruption, but local exposure must be assessed from the organization’s own architecture and evidence.
Technical view
SOC, OT engineering, and incident response teams should validate visibility into alarm configuration and reporting-setting changes on the targeted asset classes: Human-Machine Interfaces, PLCs, RTUs, IEDs, Data Gateways, Safety Controllers, DCS Controllers, and PACs. MITRE provides no official detection text for T0838, but the object is associated with detection strategy DET0777. Defenders should focus on whether configuration changes, memory/code changes affecting fixed values, instruction-level tampering, alarm suppression relationships, and changes to reporting paths can be observed and correlated with authenticated users, source systems, engineering workstations, and approved change windows.
Likely telemetry
- Alarm configuration change records from HMI, SCADA, controller, gateway, and safety-system tools
- User authentication and authorization logs for accounts able to read, manipulate, or execute changes
- Engineering workstation activity and change-management records tied to controller or alarm logic updates
- Network communications involving HMIs, PLCs, RTUs, IEDs, DCS/PAC controllers, safety controllers, and data gateways
- Device or process authentication events where supported
Detection direction
- Confirm whether DET0777-style coverage is implemented locally, since the ATT&CK object itself does not include official detection guidance.
- Baseline approved alarm settings and reporting behavior, then alert on deviations outside authorized maintenance or engineering change windows.
- Correlate alarm-setting changes with identity context, source host, device target, and change ticket or operational approval.
- Tune for false positives from legitimate engineering work, commissioning, maintenance, and process changes; the suspicious condition is unauthorized, unexpected, or safety-relevant modification.
- Look for relationship-driven context with Alarm Suppression: alarm changes may be one part of a broader attempt to avoid operator awareness or prevent intended responses.
Mitigation priorities
- Enforce authorization so only authenticated users with approved roles can manipulate alarm and reporting settings.
- Use access management controls or gateways where field devices cannot provide sufficient user identification and authentication themselves.
- Require human user authentication for systems that accept commands or configuration changes, recognizing that MFA may not always be feasible in ICS environments.
- Apply user account management to govern creation, modification, use, and permissions of accounts with alarm or controller access.
- Require device and software process authentication where systems access APIs or communicate remotely.
Analyst notes and limits
This technique is especially material for OT environments because alarms are part of both operator awareness and process protection. The supplied relationships show broad targeting across HMI, controller, gateway, and safety-related asset types, and multiple mitigations centered on authorization, access management, authentication, allowlisting, account governance, and segmentation. Detection engineering should be co-owned by SOC and OT engineering because legitimate alarm tuning can look similar to malicious modification without asset context and change-control evidence.
The ATT&CK object does not specify tactics, platforms, or official detection text. Platform details are only available through related ICS asset objects, not the technique’s own platform field. This take does not assert active exploitation, current threat activity, or existing detection coverage. Local architecture, logging capability, vendor/device behavior, and change-management records are required to determine actual risk and coverage.
Modify Alarm Settings
Adversaries may modify alarm settings to prevent alerts that may inform operators of their presence or to prevent responses to dangerous and unintended scenarios. Reporting messages are a standard part of data acquisition in control systems. Reporting messages are used as a way to transmit system state information and acknowledgements that specific actions have occurred. These messages provide vital information for the management of a physical process, and keep operators, engineers, and administrators aware of the state of system devices and physical processes.
If an adversary is able to change the reporting settings, certain events could be prevented from being reported. This type of modification can also prevent operators or devices from performing actions to keep the system in a safe state. If critical reporting messages cannot trigger these actions then a Impact could occur.
In ICS environments, the adversary may have to use Alarm Suppression or contend with multiple alarms and/or alarm propagation to achieve a specific goal to evade detection or prevent intended responses from occurring. [1] Methods of suppression often rely on modification of alarm settings, such as modifying in memory code to fixed values or tampering with assembly level instruction code.
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
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.2 | Current bundle | 46da882f095e… |
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]
Jos Wetzels, Marina Krotofil 2019
Jos Wetzels, Marina Krotofil 2019 A Diet of Poisoned Fruit: Designing Implants & OT Payloads for ICS Embedded Devices Retrieved. 2019/11/01
Open source URL -
[2]
mitre-attack T0838Open 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.