Masquerading in an industrial network means malware that looks like the vendor software operators and engineers expect to see, so nobody questions it. MITRE ATT&CK for ICS tracks this as T0849 Masquerading under the Evasion tactic (TA0103). It mirrors Enterprise T1036, but the ICS version has its own procedure examples: Stuxnet replacing a Siemens PLC communication library, Triton posing as Triconex log software, and Sandworm renaming tools during the 2016 Ukraine power attack. This guide covers what is different on engineering workstations, HMIs and safety system hosts, and how to detect and prevent it there. For general Windows and Linux masquerading techniques, see the T1036 Masquerading Defensive Guide; this page does not repeat it.
Key takeaways
- The disguise is vendor specific. In OT the target names are ICS vendor binaries, DLLs and project tools, so detection needs a baseline of the vendor software actually installed.
- Name is not integrity. ATT&CK's detection strategy DET0725 is built on one signal: the displayed name matches a known ICS application but the hash or path does not match the vendor-signed baseline.
- Three mitigations do most of the work. Code Signing (M0945), Execution Prevention by attributes other than file name (M0938) and Restrict File and Directory Permissions (M0922).
- The safety system host is a target. Triton was configured to masquerade as trilog.exe on a Triconex safety engineering workstation, so those hosts deserve the strictest allowlisting.
- Field devices can masquerade too. One ATT&CK analytic looks for a device whose protocol identity response conflicts with the asset inventory.
What T0849 covers in OT
ATT&CK describes the technique as disguising a malicious application or executable as another file to avoid operator and engineer suspicion: commonly found programs, expected vendor executables and configuration files, and ordinary naming conventions. It notes that applications commonly found on Windows systems or engineering workstations have been impersonated, and that this can be as simple as renaming a file. The platforms listed are Embedded, Windows, Linux and Network Devices.
What changes compared with an office network:
- Stable software estates: engineering workstations and HMIs change rarely, so a complete hash and path baseline is realistic in a way it seldom is on user laptops.
- Vendor names attackers can borrow: project tools, communication drivers and diagnostic utilities that staff see every day and would not question.
- Limited endpoint tooling: some hosts cannot run a full EDR agent under vendor support terms, which makes file integrity and application control more important.
Procedure examples and what they teach
| Example | What ATT&CK or its cited source states | Defensive lesson |
|---|---|---|
| Stuxnet (S0603) | Renames s7otbxdx.dll, the library that handles communication with the PLC, and replaces it with its own version that intercepts calls to the PLC. | Hash and signature checks on vendor DLLs in their install folder, not only on executables. |
| Triton (S1009) | Configured to masquerade as trilog.exe, the Triconex software for analysing SIS logs; its injector, inject.bin, masquerades as a standard compiled PowerPC program for the Tricon. Mandiant's report states the attacker reached the SIS through a Windows SIS engineering workstation. | Allowlist the safety engineering workstation by signer and hash, and do not dual-home it. |
| 2016 Ukraine Electric Power Attack (C0025) | Sandworm Team transferred executables as .txt and renamed them to .exe, likely to avoid detection through extension tracking. | Inspect file content type, not extension, at transfer points into OT. |
| EKANS (S0605) | Masquerades as a valid executable named update.exe, a name many legitimate programs use for background updates. | Generic update names in unusual paths deserve a hash check. |
| REvil (S0496) | Checks whether the Ahnlab autoup.exe service is running and injects its payload into that process. | Hiding inside a legitimate process defeats name based allowlists; behaviour and integrity monitoring is still needed. |
For the wider group context see the Sandworm Threat Actor Profile.
Detection: ATT&CK's analytics for masquerading
ATT&CK v20 attaches detection strategy DET0725 to T0849. Each analytic carries an OT operational fidelity gate: alert only when execution 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, and suppress vendor-signed software, approved engineering utilities, patching, backup and documented maintenance.
| Analytic | Platform | Signal | Log source named by ATT&CK |
|---|---|---|---|
| AN1858 | Windows | Process, service or scheduled task named like an ICS vendor application whose hash or path does not match the vendor baseline | Sysmon Event ID 1 (process create) and 11 (file create); Security 4698 and 4702 (scheduled task created or updated); System 7045 (service installed) |
| AN2123 | Linux | Executable named like an ICS daemon running outside vendor install directories, or failing the package manager checksum | auditd execve records; rpm -V or dpkg --verify results |
| AN2231 | Embedded | Device whose protocol identity response (vendor, product, model) conflicts with the asset inventory for that address | Network content inspection of identity responses |
| AN2287 | Network Devices | Traffic on an ICS protocol port, such as 502, 20000 or 44818, whose payload does not fit that protocol | OT protocol decoder or IDS |
Metrics that show it is working
- Baseline coverage: share of engineering workstations, HMIs and SCADA servers with a current hash and path baseline of vendor software.
- Enforcement coverage: share of those hosts with application control in enforce mode, by signer and hash rather than file name.
- Integrity exceptions: number of vendor-named binaries failing signature or checksum checks each month, and time to resolve each.
- Identity mismatches: devices whose protocol identity conflicts with inventory, from passive monitoring.
Prevention
- Baseline vendor software. Record signer, hash and install path for every binary and DLL the ICS vendor ships on each host type. Repeat after every vendor patch.
- Application control in audit mode (M0938). Build rules by publisher and hash, never by file name alone, run in audit for at least one full operating cycle including maintenance, then enforce. See the Application Allowlisting Guide.
- Require signed binaries (M0945). Where the vendor signs its software, block unsigned code in vendor folders. See the Code Signing Security Guide.
- Lock down folders (M0922). Ordinary operator accounts should not be able to write to vendor install and project directories.
- Control file transfer into OT. Scan by content type at the transfer point so a renamed executable is caught.
- Roll back safely. Keep the prior allowlist policy ready to redeploy and agree with the vendor which emergency maintenance tools may be temporarily allowed.
Where identity fits
Masquerading targets trust in names. The same applies to accounts: a service or scheduled task created under a shared engineering account is hard to attribute. Give engineering and vendor accounts individual identities, and alert when a new service or scheduled task appears on an OT host under any account. See the Engineering Workstation Security Guide.
Safe response
- Do not delete first: a suspect vendor-named file may be in use by the running HMI or project; agree with operations before stopping it.
- Verify against the vendor: compare hash and signature with vendor media or a known good host of the same build.
- Check what it touched: for a replaced communication library, compare the controller logic with the offline master copy, because a library like Stuxnet's can hide changes from the engineering view.
- Preserve evidence: the file, its hash, process and service creation events, and the transfer path into OT.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| ATT&CK for ICS mitigations | M0945, M0938, M0922 | The three mitigations ATT&CK lists for T0849 |
| ATT&CK Enterprise | T1036 Masquerading | Enterprise counterpart, with sub-techniques for IT hosts |
| NIST SP 800-53 Rev 5 | CM-7 Least Functionality; CM-14 Signed Components; SI-7 Software, Firmware, and Information Integrity; AC-3 Access Enforcement; SI-4 System Monitoring | Allowlisting, signed code, integrity checks, folder permissions, monitoring |
| NIST CSF 2.0 | DE.CM-09; PR.PS-02 | Monitoring software and runtime environments; maintaining software |
Common failure patterns
- Allowlisting by file name or path only, which a renamed binary passes.
- Checking executables but not the vendor DLLs they load, the gap Stuxnet's library replacement used.
- No baseline refresh after vendor patches, so genuine updates cause alert fatigue and the rule gets switched off.
- Safety engineering workstations with the same loose controls as general HMIs.
- File transfer checks that trust the extension.
Practitioner checklist
- Build signer, hash and path baselines of vendor software for each OT host type.
- Enforce application control by publisher and hash, after an audit period.
- Monitor service, scheduled task and process creation for vendor names with mismatched hashes.
- Run package integrity checks on Linux OT hosts.
- Restrict write access to vendor and project folders.
- Compare device identity responses with the asset inventory.
- Give the safety engineering workstation the strictest controls on site.
Standards and references
- MITRE ATT&CK: Masquerading (T0849)
- MITRE ATT&CK: Masquerading (T1036)
- MITRE ATT&CK: Triton (S1009)
- MITRE ATT&CK: 2016 Ukraine Electric Power Attack (C0025)
- Mandiant: Attackers Deploy New ICS Attack Framework TRITON
- MITRE ATT&CK: Execution Prevention (M0938)
- NIST: SP 800-53 Rev 5, Security and Privacy Controls
Related NHI Mgmt Group resources: T1036 Masquerading Defensive Guide · Engineering Workstation Security Guide · Application Allowlisting Guide · HMI and SCADA Server Hardening Guide · OT Security Guide