T0822: External Remote Services
Adversaries may leverage external remote services as a point of initial access into your network. These services allow users to connect to internal network resources from external locations. Examples are VPNs, Citrix, and other access mechanisms. Remote service gateways often manage connections and credential authentication for these services. [1]
External remote services allow administration of a control system from outside the system. Often, vendors and internal engineering groups have access to external remote services to control system networks via the corporate network. In some cases, this access is enabled directly from the internet. While remote access enables ease of maintenance when a control system is in a remote area, compromise of remote access solutions is a liability. The adversary may use these services to gain access to and execute attacks against a control system network. Access to valid accounts is often a requirement.
As they look for an entry point into the control system network, adversaries may begin searching for existing point-to-point VPN implementations at trusted third party networks or through remote support employee connections where split tunneling is enabled. [2]
Analyst context for executives and security teams
External Remote Services in ICS matter because remote access paths such as VPNs, Citrix-style access, vendor support links, jump hosts, and remote gateways can become the practical bridge from the outside world into control system networks. The business issue is not remote access itself; it is whether the organization can prove who can use it, where it terminates, what ICS assets it can reach, and whether activity is monitored well enough to support fast incident decisions.
Executive priority
Treat this as a resilience and governance priority for any environment where vendors, engineering teams, or remote employees administer control systems. Leaders should ask for evidence of approved remote access paths, third-party access ownership, account controls, MFA feasibility, segmentation between corporate and ICS networks, and monitoring around VPN servers, jump hosts, firewalls, routers, switches, data gateways, application servers, and data historians. The relationship to known ICS campaigns in ATT&CK makes this behavior material for incident readiness and audit evidence, but local exposure depends on the organization’s actual remote access architecture.
Technical view
SOC, detection engineering, and IR teams should validate coverage around externally reachable or corporate-to-ICS remote access mechanisms. ATT&CK provides no official detection text for T0822, but the related DET0803 detection strategy indicates this behavior has a detection focus. Practical validation should center on authentication events, remote session records, VPN and gateway logs, firewall and segmentation policy logs, jump host activity, and evidence of access from third-party or employee remote support paths. Give special attention to split tunneling, point-to-point VPNs through trusted third parties, and direct internet-enabled access where present. Because the technique has no platforms or tactics specified, detections should be scoped to locally identified assets rather than assumed endpoint coverage.
Likely telemetry
- VPN server authentication, connection, source IP, session duration, and tunnel assignment logs
- Remote access gateway, Citrix-style service, or concentrator logs where deployed
- Jump host logon, session, command/application access, and administrative activity records
- Firewall, router, and switch flow or policy decision logs at corporate-to-ICS and internet-facing boundaries
- Identity and account management records for vendor, engineering, remote support, and privileged accounts
Detection direction
- Inventory all sanctioned external remote services into the ICS environment and compare that inventory with observed network exposure and authentication logs.
- Tune alerts for remote access outside approved users, times, source locations, third-party networks, or maintenance windows, while accounting for legitimate vendor support activity.
- Correlate successful remote access with subsequent access to targeted ICS assets such as VPN servers, jump hosts, data historians, application servers, data gateways, firewalls, routers, switches, and controllers.
- Validate that monitoring covers both direct internet-enabled access and indirect access through the corporate network or trusted third-party VPN paths.
- Review split tunneling and point-to-point VPN scenarios because they can create visibility gaps if traffic bypasses monitored chokepoints.
Mitigation priorities
- Start with user account management: confirm every remote access account has an owner, business justification, current authorization, and appropriate permissions.
- Enforce password policies and account use policies, including controls such as login restrictions and lockouts where operationally appropriate.
- Use multi-factor authentication for remote access where feasible, while recognizing ATT&CK notes that some ICS assets with real-time operational and safety requirements may restrict MFA use.
- Segment networks so external or corporate remote access does not provide broad reachability to critical process control systems; use DMZ or controlled boundary designs for internet-facing services.
- Limit access over the network to only required systems and services, using controlled remote access paths such as concentrators or gateways where appropriate.
Analyst notes and limits
This object is an ICS ATT&CK technique, T0822, and is linked to mitigation guidance for account management, password policies, network segmentation, MFA, limiting network access, account use policies, and disabling unnecessary features. It also targets multiple ICS asset types, including VPN servers, jump hosts, data historians, application servers, data gateways, network infrastructure, firewalls, and DCS controllers. Campaign and software relationships show ATT&CK-documented use in ICS contexts, but they should be used for prioritization and scenario planning rather than as proof of current activity in any specific environment.
MITRE does not provide official detection text, tactics, or platforms for this technique in the supplied object. The assessment therefore depends on local architecture, asset inventory, remote access design, identity records, and available telemetry. No claim is made that a given organization is exposed, that detection coverage exists, or that any named campaign is active against the reader.
External Remote Services
Adversaries may leverage external remote services as a point of initial access into your network. These services allow users to connect to internal network resources from external locations. Examples are VPNs, Citrix, and other access mechanisms. Remote service gateways often manage connections and credential authentication for these services. [1]
External remote services allow administration of a control system from outside the system. Often, vendors and internal engineering groups have access to external remote services to control system networks via the corporate network. In some cases, this access is enabled directly from the internet. While remote access enables ease of maintenance when a control system is in a remote area, compromise of remote access solutions is a liability. The adversary may use these services to gain access to and execute attacks against a control system network. Access to valid accounts is often a requirement.
As they look for an entry point into the control system network, adversaries may begin searching for existing point-to-point VPN implementations at trusted third party networks or through remote support employee connections where split tunneling is enabled. [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
S1157: Fuxnet
C0028: 2015 Ukraine Electric Power Attack
2015 Ukraine Electric Power Attack was a Sandworm Team campaign during which they used BlackEnergy (specifically BlackEnergy3) and KillDisk to target and disrupt transmission and distribution substations within the Ukrainian power grid. This campaign was the first major public attack conducted against the Ukrainian power grid by Sandworm Team.
C0020: Maroochy Water Breach
Maroochy Water Breach was an incident in 2000 where an adversary leveraged the local government’s wastewater control system and stolen engineering equipment to disrupt and eventually release 800,000 liters of raw sewage into the local community.[1]
C0063: 2025 Poland Wiper Attacks
2025 Poland Wiper Attacks is a Russian state-sponsored campaign that conducted destructive cyberattacks against Polish energy infrastructure in December 2025. Targets included more than 30 wind and photovoltaic farms, a combined heat and power (CHP) plant, and a manufacturing sector company. The attacks on the distributed energy resources (DER) disrupted communications between affected facilities and the distribution system operator, but did not impact electricity generation or heat supply. Across the campaign, threat actors deployed two previously undocumented wiper tools, DynoWiper, a Windows-based wiper and LazyWiper, a PowerShell wiper, distributed via malicious Group Policy Objects. At the CHP plant, threat actors had maintained access since at least March 2025, using that foothold to obtain credentials and move laterally before attempting wiper deployment. Some reporting has assessed the activity to be consistent with Russian Federal Security Service (FSB) threat activity group Dragonfly, also tracked as STATIC TUNDRA, while other reporting attributes the destructive wiper activities to the Russian General Staff Main Intelligence Directorate (GRU) threat activity group ELECTRUM, also tracked as Sandworm Team.[1][2][3][4]
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 | 1b3484f3abaf… |
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]
Daniel Oakley, Travis Smith, Tripwire
Daniel Oakley, Travis Smith, Tripwire Retrieved. 2018/05/30
Open source URL -
[2]
Electricity Information Sharing and Analysis Center; SANS Industrial Control Systems March 2016
Electricity Information Sharing and Analysis Center; SANS Industrial Control Systems 2016, March 18 Analysis of the Cyber Attack on the Ukranian Power Grid: Defense Use Case Retrieved. 2018/03/27
Open source URL -
[3]
mitre-attack T0822Open 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.