T0820: Exploitation for Evasion
Adversaries may exploit a software vulnerability to take advantage of a programming error in a program, service, or within the operating system software or kernel itself to evade detection. Vulnerabilities may exist in software that can be used to disable or circumvent security features.
Adversaries may have prior knowledge through Remote System Information Discovery about security features implemented on control devices. These device security features will likely be targeted directly for exploitation. There are examples of firmware RAM/ROM consistency checks on control devices being targeted by adversaries to enable the installation of malicious System Firmware.
Analyst context for executives and security teams
Exploitation for Evasion is an ICS-focused behavior where an adversary abuses software or firmware vulnerabilities to bypass or disable security features. Its business significance is that evasion can occur on systems that support operations directly, including HMIs, PLCs, safety controllers, control servers, historians, gateways, firewalls, VPN servers, and jump hosts. If these assets cannot reliably enforce or report security controls, incident responders may lose visibility at the same time operational risk is increasing.
Executive priority
Treat this as a resilience and assurance issue, not only a patching issue. Leaders should ask whether critical ICS assets have known vulnerable software or firmware, whether security-feature integrity is monitored, and whether maintenance windows allow updates without disrupting operations. Because the technique targets a broad set of control, network, remote-access, and safety-related assets, prioritization should focus on systems where loss of detection, firmware integrity, or boundary control would materially affect safe and continuous operations.
Technical view
SOC, detection engineering, and IR teams should validate coverage around vulnerability exploitation attempts that alter or bypass security features on ICS assets. The ATT&CK object provides no official detection text, but it is related to detection strategy DET0795 and mitigations for threat intelligence, application isolation/sandboxing, exploit protection, and software updates. Defensive validation should include firmware and software integrity checks, monitoring for unexpected security-control state changes, and investigation paths for assets that may have been profiled through Remote System Information Discovery before exploitation.
Likely telemetry
- Asset inventory for targeted ICS asset classes, including workstations, HMIs, PLCs, IEDs, historians, control servers, application servers, data gateways, safety controllers, VPN servers, jump hosts, routers, switches, firewalls, DCS controllers, and PACs
- Software and firmware version data mapped to vulnerability intelligence
- Security-feature configuration and status records from control devices and supporting systems
- Firmware RAM/ROM or integrity-check results where available
- Endpoint, server, network, and embedded-device logs for abnormal crashes, exploit-protection events, or security-control failures
Detection direction
- Confirm whether DET0795-style logic is implemented locally; the supplied ATT&CK object does not include detection details, so coverage must be proven with environment-specific tests and telemetry review.
- Correlate vulnerability exposure with attempts to change, disable, or bypass security features rather than relying only on generic exploit signatures.
- Prioritize monitoring for assets that enforce trust boundaries or safety/operations functions, including firewalls, VPN servers, jump hosts, safety controllers, PLCs, and HMIs.
- Tune for expected maintenance activity to reduce false positives, especially during approved software or firmware updates.
- Look for gaps on embedded and network devices where endpoint-style logging may be limited or unavailable.
Mitigation priorities
- Maintain a threat intelligence program to track vulnerability and adversary-trend information relevant to ICS assets and use it to prioritize defensive work.
- Apply regular software and firmware updates, scheduled around operational downtime where required.
- Use exploit protection capabilities where supported to detect or block conditions associated with exploitation.
- Apply application isolation and sandboxing where feasible to restrict code execution on or in transit to endpoint systems.
- Prioritize compensating controls for embedded or legacy assets that cannot be updated quickly, using asset criticality and operational impact to sequence remediation.
Analyst notes and limits
The object is ICS technique T0820, Exploitation for Evasion. ATT&CK explicitly notes possible targeting of device security features and firmware RAM/ROM consistency checks, including enabling installation of malicious system firmware. Triton is listed as software using this technique, but no additional attribution or current activity should be inferred from the supplied data.
MITRE provides no official detection text, no tactic assignment, and no technique-level platforms for this object. Asset relationships provide relevant ICS asset context and some asset platforms, but local asset inventory, firmware/software versions, logging capability, and change-management records are required to determine real exposure and coverage.
Exploitation for Evasion
Adversaries may exploit a software vulnerability to take advantage of a programming error in a program, service, or within the operating system software or kernel itself to evade detection. Vulnerabilities may exist in software that can be used to disable or circumvent security features.
Adversaries may have prior knowledge through Remote System Information Discovery about security features implemented on control devices. These device security features will likely be targeted directly for exploitation. There are examples of firmware RAM/ROM consistency checks on control devices being targeted by adversaries to enable the installation of malicious System Firmware.
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
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.1 | Current bundle | 288f35a6a5d7… |
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 T0820Open 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.