ATT&CK for ICS Privilege Escalation (TA0111) Guide

In an industrial network the step from an ordinary foothold to supervisor rights on a controller or SYSTEM on an engineering workstation is what turns an intrusion into a threat to the physical process. MITRE ATT&CK for ICS describes the Privilege Escalation tactic (TA0111) as the adversary "trying to gain higher-level permissions", noting that attackers often enter and explore a network with unprivileged access but need elevated permissions to follow through on their objectives. The tactic is small: in ATT&CK v20 it holds only two techniques, T0890 Exploitation for Privilege Escalation and T0874 Hooking. Both are rare, and both appear in the most consequential ICS attack tools on record. This hub explains what the tactic means on embedded devices, Windows and Linux hosts and network devices in OT, how the recorded attacks chained it, and where detection and mitigation effort pays off. It is written for OT security engineers, ICS asset owners and SOC teams that monitor industrial sites.

Key takeaways

Two techniques, high consequence. TA0111 contains only T0890 and T0874, with four procedure records between them in the v20 dataset, all from Stuxnet, Triton and INCONTROLLER.
Escalation in OT often happens on the device itself. Triton exploited a firmware system call on the safety controller to gain supervisor privileges, a level no host EDR can see.
Engineering workstations are the Windows escalation target. INCONTROLLER loaded a known vulnerable signed ASRock driver to run code in the Windows kernel, which is why driver blocklisting matters on OT hosts.
Integrity evidence beats anomaly alerts. ATT&CK's v20 detection strategies for both techniques ask for firmware, module and DLL hashes compared with a signed vendor baseline, with protocol anomalies treated as corroboration only.
Most OT access needs no escalation at all. Default and shared credentials, and protocols without authentication, often give full control directly, so least privilege and authenticated engineering access sit alongside the two techniques here.

What the tactic means in OT

On an enterprise network, privilege escalation usually means moving from a user to local administrator or domain administrator. In an ICS environment there are more layers of privilege, and some of them are not operating system concepts at all.

Controller privilege modes: safety instrumented systems and PLCs separate normal operation from programming, often with a physical keyswitch or a mode setting. Code running with supervisor rights in controller firmware can bypass the device's own access model.
Host privilege on engineering workstations and HMIs: kernel or SYSTEM rights let an attacker load drivers, hook vendor communication libraries and tamper with what the operator sees.
Network device management planes: industrial switches, routers and protocol gateways can be pushed into a privileged management context through a management-plane flaw.

Both techniques carry the platforms Embedded, Windows, Linux and Network Devices in v20. T0874 Hooking is also listed under the Execution tactic, because hooking redirects code execution as well as raising its privilege. For the wider matrix, see the MITRE ATT&CK for ICS Guide.

Every technique in the tactic

The table lists every current (non-revoked, non-deprecated) technique mapped to TA0111 in ATT&CK for ICS v20, with counts computed from the v20 STIX dataset: procedure records are "uses" relationships from groups, software and campaigns, and mitigations are "mitigates" relationships.

ID	Technique	Also under	Procedure records	Mitigations	Detection strategy
T0890	T0890 Exploitation for Privilege Escalation	None	2 (Triton, INCONTROLLER)	4: M0950 Exploit Protection, M0948 Application Isolation and Sandboxing, M0951 Update Software, M0919 Threat Intelligence Program	DET0738, four analytics (Embedded, Linux, Network Devices, Windows)
T0874	T0874 Hooking	Execution	2 (Stuxnet, Triton)	2: M0944 Restrict Library Loading, M0947 Audit	DET0722, five analytics (Windows, Linux, Embedded, Network Devices)

The technique pages cover each one in depth. This hub concentrates on how they connect and what a defender should prioritise across both.

How recorded attacks chained it

The procedure records are few, so each is worth reading as a pattern rather than a statistic.

Software	Technique	What ATT&CK records	Defensive lesson
Triton (S1009)	T0890	Exploited a previously unknown vulnerability in Tricon MP3008 firmware through an insecurely written system call, gaining an arbitrary 2-byte write and then supervisor privileges.	Escalation happened inside the safety controller. Only controller mode monitoring, firmware integrity checks and strict control of who can talk to the controller would have shown it.
Triton (S1009)	T0874	Its injector changed the function pointer of a TriStation diagnostic command so that the implant ran before the normal handler.	Once privileged, the implant persisted by hooking a legitimate protocol handler, so protocol traffic alone looked normal.
INCONTROLLER (S1045)	T0890	Exploited the vulnerable ASRock driver AsrDrv103.sys (CVE-2020-15368) to load its own unsigned driver.	A signed but vulnerable driver gave kernel access on Windows. Blocklisting known vulnerable drivers and alerting on unusual driver loads close this path.
Stuxnet (S0603)	T0874	Modified import address tables to hook APIs used to open project files on engineering workstations.	Hooks in vendor libraries let attackers falsify what engineers and operators see. DLL hash baselines for vendor software catch this.

CISA's joint advisory AA22-103A on the tools later named INCONTROLLER and PIPEDREAM describes the driver exploit as a way to compromise Windows engineering workstations in IT or OT environments, enabling lateral movement and disruption of critical devices. The common thread in all four records is that escalation was a means to reach and manipulate controllers. In ATT&CK for ICS terms it typically sits between initial access to an OT host and techniques such as T0889 Modify Program or T0843 Program Download.

Where escalation is not needed

Many OT intrusions never use TA0111. T0859 Valid Accounts (listed under Persistence and Lateral Movement in ICS v20) and remote access through T0886 Remote Services can hand an attacker engineering rights directly, and many industrial protocols perform no authentication. A hub on privilege escalation that ignored this would point effort at the wrong place: the cheapest escalation an attacker can find is an account that already has the privilege.

Detection priorities

ATT&CK v20 attaches one detection strategy to each technique. Their analytics share an "OT operational fidelity gate": alert only when activity violates an approved signer, hash, path, parent process or tool allowlist, or comes from an unauthorised user or tool, and is tied to an OT asset. That is the right model for industrial sites, where false positives during maintenance cost trust quickly.

Platform	What to watch (from DET0738 and DET0722)	Data source
Windows engineering workstation or HMI	Load of a known vulnerable third-party driver before privilege indicators; special privileges assigned (Event ID 4672) to an ICS operator or service account without a matching administrative logon; a vendor communication DLL whose hash is not in the signed baseline; a process outside the vendor baseline opening a handle to an ICS application	Sysmon Event ID 6 (driver loaded), 7 (image loaded) and 10 (process access); Windows Security log
Linux OT host	setuid or setgid to root from a process owned by an ICS service account not invoked through sudo; LD_PRELOAD set before launching an ICS service binary; writes to /etc/ld.so.preload by a non-administrator	auditd SYSCALL, EXECVE and PATH records
Embedded controller	A protected function (firmware write, memory protection mode change) succeeding for a session that did not complete the documented authentication sequence; a device crash or restart followed by a privileged command from the same source; firmware or module hashes that differ from the approved image	Vendor device logs, network security monitoring, firmware integrity measurements
Network device	Management commands succeeding from outside the approved network management subnet after exploit-pattern traffic; protocol responses that deviate from the per-function baseline	Device syslog, OT protocol decoders

Two of these deserve to be first in any OT monitoring plan. Controller mode and program change events from passive OT network monitoring cover the embedded side, and driver and DLL load monitoring on engineering workstations covers the Windows side. The ATT&CK Embedded analytic for hooking is explicit that a protocol response anomaly alone does not prove a hook, because firmware versions, device state and communication faults also change responses: corroborate with independent integrity evidence before escalating an incident.

Mitigation priorities

ATT&CK lists six distinct mitigations across the two techniques, none shared between them. Grouped by where they act:

Close the access path first (outside TA0111): segment OT from IT, allow connections to controllers only from authorised engineering workstations, and require multi-factor authentication for remote access, as AA22-103A recommends. See the MITRE ATT&CK for ICS T0866 Exploitation of Remote Services page for the entry side.
M0951 Update Software and M0919 Threat Intelligence Program: track vendor advisories for controller firmware and workstation software, and plan updates into maintenance windows. Triton used a then unknown flaw, so patching alone does not cover this tactic.
M0950 Exploit Protection and M0948 Application Isolation and Sandboxing: on Windows engineering workstations turn on memory integrity (HVCI) and keep the Microsoft vulnerable driver blocklist enforced; Microsoft documents that the blocklist is on by default since the Windows 11 2022 update and enforced whenever memory integrity, Smart App Control or S mode is active, and that it is updated quarterly. Test App Control policies in audit mode before enforcement on vendor-certified hosts. See the Bring Your Own Vulnerable Driver and EDR Killers Guide.
M0944 Restrict Library Loading: allowlist the DLLs and shared libraries that vendor engineering and HMI software may load, and block loading from user writable paths.
M0947 Audit: perform periodic integrity checks of firmware, software, programs and configurations against hashes or signatures taken at a known good state, and keep offline backups of controller logic and firmware.
Controller hardening: keep controllers in RUN mode and remove programming access outside approved change windows, using the physical keyswitch or mode setting where the device provides one.

Small sites versus large estates

A small site with a handful of controllers and one engineering laptop gains most from strict physical and network control of who can reach the controllers, a hardened and dedicated engineering workstation, and offline backups with hashes. A large estate should add passive OT network monitoring with controller mode alerting, central collection of Sysmon and Security logs from every engineering workstation and HMI, and a firmware integrity programme tied to the asset inventory. Either way, rollout should start in monitoring mode: run driver and library allowlists in audit for at least one maintenance cycle, compare against vendor guidance, then enforce on a pilot cell before the rest of the plant, with a documented rollback (policy removal and reboot) agreed with operations.

Where identity fits

Privilege in OT is often held by accounts nobody owns: shared operator logins on HMIs, vendor service accounts on historians and engineering software, and default device credentials. These are non-human or shared identities, and an attacker who obtains one rarely needs either technique in this tactic. DET0738's Windows analytic shows the identity side clearly: it looks for an ICS operator or service account suddenly holding elevated privileges. Inventory every account on engineering workstations and controllers, remove shared logins where the vendor supports named accounts, and separate administrative accounts from daily operator use. See the Device and IoT Identity Guide and the Engineering Workstation Security Guide.

Measuring progress

Engineering host coverage: percentage of engineering workstations and HMIs sending driver load, image load and Security events to the SOC.
Driver control: percentage of Windows OT hosts with memory integrity on and the vulnerable driver blocklist enforced.
Firmware integrity: percentage of controllers whose firmware and logic hashes were checked against a known good baseline in the last quarter.
Mode discipline: number of controllers found in program mode outside an approved change window.
Shared privileged accounts: count of shared or default accounts with administrative rights on OT hosts and devices, trending down.

Framework mapping

Area	NIST SP 800-53 Rev. 5	NIST CSF 2.0	ISA/IEC 62443
Least privilege for operator, service and administrative accounts	AC-6 Least Privilege	PR.AA-05	62443-3-3 system requirements
Firmware, software and DLL integrity baselines	SI-7 Software, Firmware, and Information Integrity	DE.CM-09	62443-4-2 component requirements
Patching controllers and engineering hosts	SI-2 Flaw Remediation, RA-5 Vulnerability Monitoring and Scanning	ID.RA-01	TR62443-2-3 patch management
Restricting drivers and libraries	CM-7 Least Functionality	PR.PS-05	62443-3-3 system requirements
Monitoring for escalation indicators	SI-4 System Monitoring	DE.CM-09	62443-2-1 asset owner programme

NIST SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security, is the reference for applying these controls in OT. For the 62443 parts, see the IEC 62443 Guide.

Common failure patterns

Treating EDR as full coverage: host agents see the INCONTROLLER style driver path but nothing of a firmware exploit inside a controller.
Controllers left in program mode: remote programming access is left open after commissioning, so a privileged session needs no exploit.
No known good baseline: without hashes of firmware, logic and vendor DLLs taken at a trusted point, a hook cannot be proven or ruled out.
Driver blocklist disabled for compatibility: memory integrity is turned off on engineering hosts to suit older vendor software and never revisited.
Shared administrative logins: one account used by operators, integrators and vendors makes any escalation alert impossible to attribute.

Practitioner checklist

Confirm which controllers support mode or keyswitch protection and keep them in RUN outside change windows.
Take and store firmware, logic and vendor DLL hashes at a known good state, offline.
Turn on memory integrity and the vulnerable driver blocklist on engineering workstations, piloted in audit mode first.
Forward Sysmon Event IDs 6, 7 and 10 and Security Event ID 4672 from OT Windows hosts to the SOC.
Add auditd rules for setuid changes and /etc/ld.so.preload writes on Linux OT hosts.
Alert on controller mode changes and firmware writes from passive OT network monitoring.
Allow controller access only from named engineering workstations and require MFA for remote access.
Replace shared and default administrative accounts on OT hosts and devices where the vendor supports it.

ATT&CK for ICS Privilege Escalation Tactic Guide: Detecting and Containing Escalation in OT Systems