T0890: Exploitation for Privilege Escalation
Adversaries may exploit software vulnerabilities in an attempt to elevate privileges. Exploitation of a software vulnerability occurs when an adversary takes advantage of a programming error in a program, service, or within the operating system software or kernel itself to execute adversary-controlled code. Security constructs such as permission levels will often hinder access to information and use of certain techniques, so adversaries will likely need to perform privilege escalation to include use of software exploitation to circumvent those restrictions. [1]
When initially gaining access to a system, an adversary may be operating within a lower privileged process which will prevent them from accessing certain resources on the system. Vulnerabilities may exist, usually in operating system components and software commonly running at higher permissions, that can be exploited to gain higher levels of access on the system. This could enable someone to move from unprivileged or user level permissions to SYSTEM or root permissions depending on the component that is vulnerable. This may be a necessary step for an adversary compromising an endpoint system that has been properly configured and limits other privilege escalation methods. [1]
Analyst context for executives and security teams
This ICS technique matters because a foothold with limited permissions may become much more dangerous if an adversary exploits a software flaw to gain SYSTEM/root or otherwise higher privileges. In an operational technology environment, that can affect workstations, HMIs, control servers, historians, gateways, remote access systems, network devices, and embedded controllers, making patch discipline and exploit visibility business-continuity issues rather than purely IT hygiene.
Executive priority
Treat this as a control-prioritization and resilience question: which ICS assets would create the most operational, safety, remote-access, or recovery risk if a low-privileged compromise became a high-privileged compromise? Leaders should ask whether vulnerability intelligence, scheduled update windows, exploit protection, and isolation controls are applied first to jump hosts, VPN servers, HMIs, engineering/operator workstations, control servers, safety controllers, and boundary devices where compromise could complicate incident response or operational continuity.
Technical view
ATT&CK provides no official detection text, tactics, or platforms for T0890, but the technique is defined around exploitation of software, services, operating system components, or kernels to elevate privileges. SOC and IR teams should validate coverage around the targeted ICS asset classes in the relationships, especially Windows/Linux workstations, HMIs, servers, historians, gateways, VPN/jump hosts, firewalls, routers/switches, and embedded control or safety devices where telemetry may be sparse. Relationship context also links DET0738 as a detection strategy and notes use by Triton and INCONTROLLER, which supports prioritizing this behavior in ICS-focused threat modeling without claiming current activity.
Likely telemetry
- OT asset inventory with software, firmware, OS, and patch/update status
- Vulnerability and threat-intelligence records mapped to ICS assets and remote-access paths
- Endpoint security, exploit-protection, process, privilege, service, kernel, and crash/exception logs where available
- Authentication and authorization logs showing privilege changes or unusual high-privilege activity after lower-privilege access
- Application, control server, historian, HMI, and engineering workstation logs
Detection direction
- Validate whether DET0738-aligned logic exists locally for exploitation-driven privilege escalation rather than only generic malware or login detections.
- Tune detections for sequences where a low-privileged process, service, or user context is followed by unexpected privileged execution, service manipulation, crashes, or elevated access.
- Correlate exploit alerts with asset criticality: HMI, engineering workstation, control server, VPN, jump host, firewall, safety controller, PLC/PAC/DCS controller, IED, historian, and gateway systems should not be treated as ordinary endpoints.
- Account for ICS blind spots: embedded devices and network appliances may provide limited logs, and maintenance windows or vendor support activity can resemble privileged changes unless change records are integrated.
- Use threat intelligence to prioritize vulnerability monitoring and detection engineering, but do not assume exploitation from vulnerability presence alone.
Mitigation priorities
- Maintain a threat intelligence program to track exploitation trends and inform which ICS vulnerabilities and assets require priority action.
- Apply regular software updates where feasible, explicitly scheduling around operational downtime and change-control constraints.
- Use exploit protection capabilities to detect or block conditions associated with software exploitation where supported by the asset and operating environment.
- Use application isolation and sandboxing to restrict code execution paths on or in transit to endpoint systems where operationally compatible.
- Prioritize compensating controls for assets that cannot be quickly patched, especially remote-access systems, operator/engineering workstations, control servers, historians, gateways, and safety/control devices.
Analyst notes and limits
The relationship set makes this broader than a single endpoint issue: T0890 targets many ICS asset types, including workstations, HMIs, PLCs, IEDs, historians, control/application servers, gateways, VPN and jump hosts, network devices, firewalls, safety controllers, DCS controllers, and PACs. The external reference to ATT&CK T1068 indicates conceptual overlap with the enterprise technique name, but this take is limited to the supplied ICS object and relationships.
MITRE does not provide official detection guidance, tactics, aliases, labels, or technique-level platforms for this object. Telemetry and control recommendations therefore require local validation against the actual ICS architecture, vendor capabilities, maintenance constraints, logging depth, and approved operational procedures. The supplied relationships show Triton and INCONTROLLER use this technique, but they do not establish current exploitation or exposure in any specific environment.
Exploitation for Privilege Escalation
Adversaries may exploit software vulnerabilities in an attempt to elevate privileges. Exploitation of a software vulnerability occurs when an adversary takes advantage of a programming error in a program, service, or within the operating system software or kernel itself to execute adversary-controlled code. Security constructs such as permission levels will often hinder access to information and use of certain techniques, so adversaries will likely need to perform privilege escalation to include use of software exploitation to circumvent those restrictions. [1]
When initially gaining access to a system, an adversary may be operating within a lower privileged process which will prevent them from accessing certain resources on the system. Vulnerabilities may exist, usually in operating system components and software commonly running at higher permissions, that can be exploited to gain higher levels of access on the system. This could enable someone to move from unprivileged or user level permissions to SYSTEM or root permissions depending on the component that is vulnerable. This may be a necessary step for an adversary compromising an endpoint system that has been properly configured and limits other privilege escalation methods. [1]
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
S1009: Triton
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]
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 | 49996947a5bb… |
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]
The MITRE Corporation
The MITRE Corporation The MITRE Corporation ATT&CK T1068: Exploitation for Privilege Escalation Retrieved. 2021/04/12 ATT&CK T1068: Exploitation for Privilege Escalation Retrieved. 2021/04/12
Open source URL -
[2]
mitre-attack T0890Open 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.