T0866: Exploitation of Remote Services
Adversaries may exploit a software vulnerability to take advantage of a programming error in a program, service, or within the operating system software or kernel itself to enable remote service abuse. A common goal for post-compromise exploitation of remote services is for initial access into and lateral movement throughout the ICS environment to enable access to targeted systems. [1]
ICS asset owners and operators have been affected by ransomware (or disruptive malware masquerading as ransomware) migrating from enterprise IT to ICS environments: WannaCry, NotPetya, and BadRabbit. In each of these cases, self-propagating (wormable) malware initially infected IT networks, but through exploit (particularly the SMBv1-targeting MS17-010 vulnerability) spread to industrial networks, producing significant impacts. [2]
Analyst context for executives and security teams
Exploitation of Remote Services matters in ICS because a vulnerability in a remotely reachable service can become the bridge from ordinary IT compromise into operational technology. The supplied ATT&CK description specifically highlights ransomware or disruptive malware moving from enterprise IT into industrial networks, including wormable spread through SMBv1/MS17-010 in past cases. For leaders, the key issue is not only patching one CVE; it is whether remote services that connect business, engineering, vendor access, and control environments can allow rapid lateral movement into systems that support operations.
Executive priority
Prioritize this as an operational resilience and segmentation governance issue. The relationship context shows this technique can target many ICS assets, including workstations, HMIs, PLCs, RTUs, IEDs, historians, control servers, application servers, gateways, VPN servers, jump hosts, routers, switches, firewalls, and safety controllers. Executives should ask whether vulnerability scanning, patch scheduling around downtime, privileged account management, threat intelligence, network segmentation, and unnecessary service removal are evidenced for the ICS environment—not just for corporate IT.
Technical view
SOC, detection engineering, and IR teams should validate coverage around exploitation attempts against remote services that provide access into or across ICS networks. Because ATT&CK provides no official detection text for T0866, teams should anchor validation to the related detection strategy DET0767 and to the targeted asset set. Practical review should focus on exposed or reachable services on ICS workstations, HMIs, historians, control servers, application servers, VPN servers, jump hosts, gateways, and network infrastructure, with special attention to IT-to-ICS pathways and services that could support wormable propagation or lateral movement. Treat embedded and safety-related assets cautiously: direct host telemetry may be limited, so network and boundary evidence may be decisive.
Likely telemetry
- Network flow records and firewall logs between enterprise, DMZ, remote access, and ICS segments
- VPN server and jump host authentication/session logs
- Service exposure and vulnerability scan results for ICS-facing systems
- Endpoint logs from Windows/Linux-based ICS workstations, HMIs, servers, historians, and application servers where available
- IDS/IPS or exploit-protection alerts associated with remote service abuse
Detection direction
- Confirm whether DET0767 or equivalent analytics exist for exploitation of remote services in the ICS monitoring stack.
- Tune detection around cross-boundary movement from enterprise IT into ICS, especially unusual service connections to HMIs, historians, control servers, jump hosts, VPN servers, and gateways.
- Correlate vulnerability exposure with observed network reachability; a critical vulnerability is more material when the service is reachable from business, remote access, or less trusted zones.
- Account for false positives from authorized engineering, vendor maintenance, vulnerability scanning, and patching activity by using approved windows and known source systems.
- Identify blind spots on embedded devices, PLCs, RTUs, IEDs, safety controllers, routers, switches, and firewalls where endpoint telemetry may be absent and network monitoring may be the primary evidence source.
Mitigation priorities
- Start with network segmentation: restrict enterprise and other business-network access to critical process control systems and use DMZ patterns for services that must bridge environments.
- Maintain vulnerability scanning appropriate for ICS to identify remotely exploitable software before it becomes an incident path.
- Schedule software updates around operational downtime, recognizing that ICS patching often requires production-aware planning.
- Remove or disable unnecessary remote services, features, and programs that increase exploit surface.
- Apply privileged account management to limit what compromised services or accounts can do after exploitation.
Analyst notes and limits
This object is an ICS ATT&CK technique, version 1.0, mapped to mitigation relationships M0916, M0919, M0926, M0930, M0942, M0948, M0950, and M0951 and detection strategy DET0767. The most decision-relevant relationship context is the broad set of targeted ICS assets and the explicit description of IT-originating disruptive malware migrating into ICS environments through remote service exploitation.
ATT&CK does not provide platforms or tactics directly on this technique and provides no official detection text. Asset platforms are inferred only from the related target asset objects. Local architecture, service exposure, vulnerability inventory, patch constraints, and monitoring coverage are required to determine actual risk and detection confidence.
Exploitation of Remote Services
Adversaries may exploit a software vulnerability to take advantage of a programming error in a program, service, or within the operating system software or kernel itself to enable remote service abuse. A common goal for post-compromise exploitation of remote services is for initial access into and lateral movement throughout the ICS environment to enable access to targeted systems. [1]
ICS asset owners and operators have been affected by ransomware (or disruptive malware masquerading as ransomware) migrating from enterprise IT to ICS environments: WannaCry, NotPetya, and BadRabbit. In each of these cases, self-propagating (wormable) malware initially infected IT networks, but through exploit (particularly the SMBv1-targeting MS17-010 vulnerability) spread to industrial networks, producing significant impacts. [2]
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
S0606: Bad Rabbit
Bad Rabbit is a self-propagating ransomware that affected the Ukrainian transportation sector in 2017. Bad Rabbit has also targeted organizations and consumers in Russia. [1][2][3]
S0368: NotPetya
NotPetya is malware that was used by Sandworm Team in a worldwide attack starting on June 27, 2017. While NotPetya appears as a form of ransomware, its main purpose was to destroy data and disk structures on compromised systems; the attackers never intended to make the encrypted data recoverable. As such, NotPetya may be more appropriately thought of as a form of wiper malware. NotPetya contains worm-like features to spread itself across a computer network using the SMBv1 exploits EternalBlue and EternalRomance.[1][2][3][4]
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]
S0366: WannaCry
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.0 | Current bundle | cac9f59899ff… |
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]
Enterprise ATT&CK
Enterprise ATT&CK Exploitation of Remote Services Retrieved. 2019/10/27
Open source URL -
[2]
Joe Slowik April 2019
Joe Slowik 2019, April 10 Implications of IT Ransomware for ICS Environments Retrieved. 2019/10/27
Open source URL -
[3]
mitre-attack T0866Open 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.