T0849: Masquerading
Adversaries may use masquerading to disguise a malicious application or executable as another file, to avoid operator and engineer suspicion. Possible disguises of these masquerading files can include commonly found programs, expected vendor executables and configuration files, and other commonplace application and naming conventions. By impersonating expected and vendor-relevant files and applications, operators and engineers may not notice the presence of the underlying malicious content and possibly end up running those masquerading as legitimate functions.
Applications and other files commonly found on Windows systems or in engineering workstations have been impersonated before. This can be as simple as renaming a file to effectively disguise it in the ICS environment.
Analyst context for executives and security teams
Masquerading in ICS matters because a malicious file can look like an expected vendor tool, configuration file, or common workstation application. In environments where operators and engineers routinely handle specialized files on HMIs, engineering workstations, historians, control servers, jump hosts, and gateways, a simple rename can reduce suspicion and increase the chance that unsafe code is trusted or executed.
Executive priority
Treat this as an operational resilience and change-control issue, not only a malware issue. Leaders should ask whether critical ICS assets have clear software baselines, file integrity expectations, application control, and evidence that only approved tools can run. The ATT&CK relationships to ICS workstations, HMIs, historians, control servers, application servers, data gateways, and jump hosts make this relevant to audit evidence, incident triage, and cyber-physical risk governance.
Technical view
SOC, detection engineering, and IR teams should validate whether they can distinguish expected vendor-relevant files from renamed or misplaced executables. Because the object has no official ATT&CK detection text and no technique-level platforms, local asset context is essential. Use the DET0725 detection-strategy relationship as a prompt to build or review detections around unusual file names, unexpected paths, unsigned or untrusted binaries, changed hashes, and execution from directories where operators would not normally launch control-system software.
Likely telemetry
- Endpoint process execution events on ICS workstations, HMIs, historians, control servers, application servers, jump hosts, and gateways where available
- File creation, rename, modification, and deletion events on directories containing vendor tools, engineering software, configuration files, or operational scripts
- Binary metadata, digital signature status, file hash, original filename, and path information
- Application control or execution-prevention allow/block events
- File and directory permission change logs
Detection direction
- Validate whether detections compare filename, path, signer, hash, and observed execution context rather than relying on filename alone.
- Tune for ICS-specific false positives such as legitimate vendor updates, engineering tool upgrades, maintenance windows, and operator-created configuration files.
- Prioritize high-value assets identified in the relationships: Workstation, HMI, Data Historian, Control Server, Application Server, Data Gateway, and Jump Host.
- Correlate suspicious masquerading indicators with recent remote access, file transfer, permission changes, or new executable creation.
- Account for blind spots where legacy ICS hosts lack endpoint logging, where vendor directories are writable, or where approved software inventories are incomplete.
Mitigation priorities
- Establish and maintain approved software and file baselines for critical ICS assets before relying on alerts.
- Apply Restrict File and Directory Permissions (M0922) so ordinary users and non-privileged accounts cannot write to trusted vendor or operational directories unnecessarily.
- Use Execution Prevention (M0938), such as application control or script blocking, to limit execution to approved code where operationally feasible.
- Enforce Code Signing (M0945) and digital signature verification for binaries and applications when supported by the environment.
- Integrate changes to vendor tools, engineering applications, and configuration files into maintenance and change-management evidence so SOC and IR teams can separate legitimate work from suspicious masquerading.
Analyst notes and limits
ATT&CK links this technique to the 2016 Ukraine Electric Power Attack campaign and to software entries including REvil, Stuxnet, EKANS, and Triton. These relationships show the behavior has appeared in documented ICS-relevant contexts, but they should not be interpreted as current activity or exposure in any specific environment without local evidence.
The supplied ATT&CK object does not specify tactics, platforms, aliases, or official detection text. Platform references come from related targeted ICS assets and related software, not from the technique object itself. Practical coverage depends on local endpoint visibility, asset inventories, vendor software baselines, and operational constraints.
Masquerading
Adversaries may use masquerading to disguise a malicious application or executable as another file, to avoid operator and engineer suspicion. Possible disguises of these masquerading files can include commonly found programs, expected vendor executables and configuration files, and other commonplace application and naming conventions. By impersonating expected and vendor-relevant files and applications, operators and engineers may not notice the presence of the underlying malicious content and possibly end up running those masquerading as legitimate functions.
Applications and other files commonly found on Windows systems or in engineering workstations have been impersonated before. This can be as simple as renaming a file to effectively disguise it in the ICS environment.
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
S0603: Stuxnet
Stuxnet was the first publicly reported malware to specifically target industrial control systems devices. Stuxnet is a large and complex malware that utilized multiple behaviors, including numerous zero-day vulnerabilities, a sophisticated Windows rootkit, and network infection routines.[1][2][3][4] Stuxnet was discovered in 2010, with some components being used as early as November 2008.[1]
S1009: Triton
S0496: REvil
REvil is a ransomware family that has been linked to the GOLD SOUTHFIELD group and operated as ransomware-as-a-service (RaaS) since at least April 2019. REvil, which as been used against organizations in the manufacturing, transportation, and electric sectors, is highly configurable and shares code similarities with the GandCrab RaaS.[1][2][3]
S0605: EKANS
EKANS is ransomware variant written in Golang that first appeared in mid-December 2019 and has been used against multiple sectors, including energy, healthcare, and automotive manufacturing, which in some cases resulted in significant operational disruptions. EKANS has used a hard-coded kill-list of processes, including some associated with common ICS software platforms (e.g., GE Proficy, Honeywell HMIWeb, etc), similar to those defined in MegaCortex.[1][2]
C0025: 2016 Ukraine Electric Power Attack
2016 Ukraine Electric Power Attack was a Sandworm Team campaign during which they used Industroyer malware to target and disrupt distribution substations within the Ukrainian power grid. This campaign was the second major public attack conducted against Ukraine by Sandworm Team.[1][2]
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 | 07e403601eff… |
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 T0849Open 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.