ATT&CK for ICS T0874 Hooking: Detection in OT

Hooking (T0874) lets an adversary sit between OT software and the functions it calls, so a controller, an engineering tool or a safety system runs attacker code while still looking normal. In ATT&CK for ICS the technique sits under both Execution (TA0104) and Privilege Escalation (TA0111), and its two procedure examples are among the most consequential ICS malware ever analysed: Stuxnet and Triton. This guide explains what hooking looks like on engineering workstations, HMIs and embedded controllers, how to detect it with the ATT&CK v20 analytics, which controls reduce exposure, and how to respond without putting the process at risk. It is written for OT security engineers, control engineers and OT SOC analysts.

Key takeaways

Hooking hides in trusted code paths. The hooked function still returns an answer, so the operator, the engineering tool and often the network all see plausible results.
Two layers matter in OT. Hooks on Windows or Linux hosts that talk to controllers (Stuxnet) and hooks inside controller firmware in memory (Triton) need different evidence.
Baselines are the detection. ATT&CK's analytics compare loaded modules, preload settings and firmware measurements against signed vendor baselines, not against generic malware signatures.
Network anomalies only corroborate. ATT&CK states that a protocol response anomaly alone does not prove a firmware hook; you need independent integrity evidence.
Response starts with the process, not the host. A hooked engineering station may be feeding false values to operators, so verify process state by an independent path before acting.

What T0874 covers

ATT&CK for ICS describes hooking as redirecting calls to application programming interface (API) functions used by processes, for execution and privilege escalation. Windows processes rely on API functions exported from dynamic-link libraries (DLLs), and one form seen in ICS is import address table (IAT) hooking, which changes the pointers to imported functions stored in a process's IAT. ATT&CK v20 lists four platforms for the technique: Windows, Linux, Embedded and Network Devices, and targeted assets that range from PLCs, DCS and safety controllers to HMIs, historians, jump hosts and network equipment.

Where the hook sits	What it achieves	Evidence you can collect
Vendor communication DLL on an engineering workstation or HMI	Intercepts reads and writes between the engineering tool and the controller; can hide or alter what the operator sees	Module load events, file hashes against the vendor's signed baseline
Process IAT or API redirection on Windows	Runs attacker code inside a trusted ICS process	Cross-process access events, hooking API use by unexpected processes
Library preloading on Linux ICS services	Loads an attacker library ahead of the vendor's libraries	Audit records for LD_PRELOAD in the environment and writes to /etc/ld.so.preload
Function pointer in controller firmware (in memory)	Runs attacker code before a legitimate command handler	Independent firmware or memory integrity measurement; vendor attestation

Hooking overlaps with Enterprise techniques. If your team already tracks host-level hooking in IT, see the T1574 Hijack Execution Flow Defensive Guide, the T1055 Process Injection Defensive Guide and the MITRE ATT&CK T1056 Input Capture guide, which covers Credential API Hooking (T1056.004). This page concentrates on what is different in OT.

The procedure examples and what they teach

Stuxnet (S0603): hooking the engineering station

ATT&CK records Stuxnet modifying import address tables to hook APIs used to open project files. The Symantec W32.Stuxnet Dossier adds the wider picture: Stuxnet renamed the Siemens communication library s7otbxdx.dll to s7otbxsx.dll and installed its own DLL in its place. The replacement exported the same functions, forwarded most of them to the original, and intercepted 16, including the routines that read, write and enumerate code blocks on the PLC. Through these routines Stuxnet could change data sent to or returned from the PLC and keep its own blocks hidden from anyone inspecting the controller through the engineering software.

Lesson: on an infected engineering station, the engineering tool is no longer a trustworthy witness. Online comparison of the controller program from that station can report a clean controller. Program verification must come from a known-good host or from an integrity measurement the hooked software cannot influence.

Triton (S1009): hooking inside a safety controller

ATT&CK records Triton's injector (inject.bin) changing the function pointer of the TriStation "get main processor diagnostic data" command to the address of its payload (imain.bin), so the payload runs before the normal handler. CISA's HatMan malware analysis report (MAR-17-352-01) explains that the changes applied to firmware in memory, since stored firmware sat in read-only memory, and that the payload gave remote read, write and execute capability through a crafted form of that diagnostic command. The report also states that programming needs the controller key switch in PROGRAM, and that once the payload was installed its command interface worked regardless of key switch position.

Lesson: on embedded devices a hook can leave no file on disk to scan. Physical key switch discipline before compromise, network isolation of safety engineering stations and periodic integrity checks are what remain. See the Safety Instrumented Systems Security Guide for the wider SIS controls.

Detection: the ATT&CK v20 analytics

MITRE's detection strategy for T0874 (DET0722, Detection of Hooking) has four analytics. All of them carry ATT&CK's OT operational fidelity gate: alert only when activity breaks 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; suppress vendor-signed software, approved engineering utilities, diagnostics, patching, backup and documented maintenance.

Analytic	Platform	What it looks for	Data needed
AN1855	Windows	An unsigned or unexpected process calling hooking APIs (SetWindowsHookEx, SetWinEventHook) against an ICS engineering or HMI process, followed by that process loading a DLL that is not in the vendor's signed module baseline	Sysmon Event ID 7 (image loaded) with hashes; Sysmon Event ID 10 (process access) where the source image is outside the approved ICS process baseline; EDR process integrity alerts
AN2110	Linux	A process setting LD_PRELOAD before launching an ICS service binary, or writing to /etc/ld.so.preload, with a library path not in the vendor's package manifest	Linux audit SYSCALL, EXECVE and PATH records from rules on the ICS service binaries and the preload file
AN2243	Embedded	A firmware or module integrity measurement that differs from the approved baseline, corroborated by protocol responses that depart from the device's known behaviour	Independently acquired firmware hashes or vendor integrity measurements; network content inspection
AN2286	Network devices	ICS protocol responses whose timing or payload structure deviates from the device's per-function baseline in a way consistent with an intercepting relay or hook	OT protocol decoder or IDS transaction logs

Making the Windows analytic work

Build the module baseline. For each engineering and HMI application, record the DLLs it loads in normal use with their hashes and signers. Do this after each vendor update.
Turn on Sysmon image load logging selectively. Event ID 7 is noisy; scope the configuration to the ICS application images rather than every process on the host.
Watch the vendor communication libraries by name. A change of hash or a rename of a library such as a vendor's PLC communication DLL is a high-value alert on its own, because these files change only with a vendor update.
Correlate process access with module loads. Event ID 10 against an ICS process from an image outside the baseline, followed by a new module in that process, is the pattern AN1855 describes.

For the embedded case, ATT&CK is explicit that firmware versions, device state, communication faults and vendor behaviour can all produce response differences, so treat network anomalies as corroboration and escalate only with integrity evidence or vendor attestation. Feed the network side from your OT monitoring platform; see the OT Network Security Monitoring Guide.

Prevention: ATT&CK mitigations in practice

M0944 Restrict Library Loading: restrict untrusted or unknown libraries, such as remote or unknown DLLs. On Windows engineering stations, application control that permits only the vendor's signed modules for ICS applications is the practical form; on Linux hosts, lock down write access to library directories and the preload file.
M0947 Audit: run periodic integrity checks of firmware, software, programs and configurations, comparing cryptographic hashes or signatures with known-good states, especially after reboots, program downloads or program restarts.
Engineering workstation hardening: these hosts carry the vendor libraries an attacker wants to hook. See the Engineering Workstation Security Guide.
Controller-side protections: keep safety and process controllers out of program mode except during approved changes, and alarm on mode changes, as CISA's HatMan report recommends for Triconex controllers. See the PLC Security Guide.

Control	Framework reference	What it addresses in T0874
Software, firmware and information integrity checks	NIST SP 800-53 SI-7; ATT&CK M0947	Detects replaced DLLs and changed firmware measurements
Signed components and library restriction	NIST SP 800-53 CM-14; ATT&CK M0944	Stops unsigned modules loading into ICS processes
Least functionality	NIST SP 800-53 CM-7	Removes unneeded tools and services from engineering hosts
System monitoring	NIST SP 800-53 SI-4; NIST CSF 2.0 DE.CM-09	Module load, process access and preload monitoring on OT hosts
Configuration management	NIST CSF 2.0 PR.PS-01	Keeps the module and firmware baselines current after vendor updates

Where identity fits

Hooks are installed by something with rights on the host. Shared engineering accounts and local administrator rights on engineering stations make it hard to tell who placed a new DLL. Give engineers named accounts, remove standing local admin from daily use and treat vendor remote access credentials as high-risk machine credentials. See the OT and ICS Identity and Access Guide.

Responding safely

Confirm the process state independently. If an HMI or engineering host may be hooked, check critical values with field readings, a separate HMI or local panels before anyone acts on what the suspect host shows.
Agree actions with operations. Isolating an engineering station is usually safe for the process; restarting a controller or changing its mode is not a security decision alone.
Preserve evidence before reimaging. Capture memory and the ICS application directory, including the vendor libraries and their hashes.
Verify controller programs from a known-good host. Do not trust online comparison from the suspect station.
Escalate embedded suspicion to the vendor. Firmware memory integrity checks usually need vendor tools or support.
Rebuild from golden images. See the OT Backup, Recovery and Golden Image Guide and the OT Incident Response Guide.

Measuring coverage

Baseline coverage: share of engineering stations and HMIs with a current signed module baseline.
Library control coverage: share of ICS hosts where only signed vendor modules can load into ICS applications.
Integrity check cadence: share of controllers with a firmware or program integrity check in the last cycle you set, and after every program download.
Alert quality: proportion of module-load alerts explained by documented maintenance, which should fall as baselines mature.
Program mode exposure: hours per month that safety controllers spend outside run mode.

Common failure patterns

Trusting the engineering tool's view: verifying a controller from the host that may be hooked, the exact blind spot Stuxnet exploited.
Logging every image load everywhere: volume buries the few vendor DLL changes that matter. Scope to ICS applications.
No baseline refresh after vendor updates: every patch becomes an alert storm and analysts learn to ignore the rule.
Escalating network anomalies as firmware compromise: ATT&CK warns this is unreliable without integrity evidence.
Leaving safety controllers in program mode: HatMan required program mode to install; leaving the key there removes a physical barrier.

Practitioner checklist

List every engineering and HMI application and its vendor communication libraries.
Record signed module and file hash baselines, and refresh them after each vendor update.
Collect Sysmon Event IDs 7 and 10 scoped to ICS processes and forward them to the OT SOC.
Add Linux audit rules for LD_PRELOAD use on ICS services and writes to /etc/ld.so.preload.
Apply library loading restrictions on engineering stations and HMIs.
Schedule firmware and program integrity checks, plus checks after every program download.
Keep controller key switches in run mode and alarm on mode changes.
Write a response step that verifies process values independently of suspect hosts.

T0874 Hooking: Detecting API Hooks on OT Hosts and Controllers