DET0803: Detection of External Remote Services
DET0803 matters because external remote services are a common boundary between business/IT networks and industrial control environments. Even without a det...
Analyst context for executives and security teams
DET0803 matters because external remote services are a common boundary between business/IT networks and industrial control environments. Even without a detailed MITRE detection description, the related ATT&CK technique makes the defensive question clear: can the organization prove who is connecting from outside, through which remote access mechanism, and to what internal control-system resources?
Executive priority
For ICS environments, externally reachable remote access paths can affect operational resilience and incident decision-making because they may provide initial access into networks that support control-system administration. Leaders should prioritize evidence of remote access governance: known gateways, accountable owners, authentication records, and monitoring that can support audit, investigation, and rapid containment decisions.
Technical view
This detection strategy is mapped to ICS technique T0822, External Remote Services. SOC and IR teams should validate coverage around remote service gateways and access mechanisms such as VPNs, Citrix, and other externally accessible services used to reach internal resources. Because the object does not specify platforms, tactics, or official detection logic, teams should avoid assuming coverage and instead test whether authentication events, connection records, and access paths into control-system resources are visible and reviewable.
Likely telemetry
- Remote access gateway logs for VPN, Citrix, and similar external access mechanisms
- Credential authentication records associated with remote service gateways
- Network connection or flow records showing external connections to internal remote access services
- Firewall or perimeter access logs for externally reachable remote service endpoints
- Asset or service inventory identifying remote administration paths into control-system resources
Detection direction
- Confirm that all approved external remote service gateways are inventoried and mapped to the internal resources they can reach.
- Validate that authentication and connection logs are collected with enough detail to identify user, source, time, gateway, and accessed resource where available.
- Tune detections around unusual or unauthorized use of remote services, while accounting for legitimate remote administration patterns.
- Look for blind spots where remote access is managed outside central logging, where gateway logs are retained for too short a period, or where internal resource access after login is not visible.
- Because MITRE provides no official detection text for this object, use local architecture and access policy to define testable detection logic.
Mitigation priorities
- Establish a current inventory of external remote services that can reach ICS or control-system administration resources.
- Assign ownership and approved-use expectations for each remote access path.
- Ensure remote service gateways produce authentication and connection evidence usable by SOC and IR teams.
- Review access controls and authentication requirements for externally reachable services that manage entry to internal resources.
- Include external remote service logs and access paths in incident response playbooks and compliance evidence collection.
Analyst notes and limits
The most useful value of DET0803 is as a coverage checkpoint for T0822 rather than as a ready-made analytic. It points defenders toward the remote access boundary: gateways, authentication, and sessions that allow external users to reach internal control-system resources.
The supplied ATT&CK object has no official description, no official detection text, no specified platforms, and no tactics. The related technique description supports remote access examples and initial-access relevance, but local network design, approved remote administration practices, and available logging are required to turn this into concrete detections.
Detection of External Remote Services
No official description is available in the imported ATT&CK source object.
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.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| ICS | T0822 | External Remote Services | This object detects External Remote Services. |
All related ATT&CK context
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 | ab158e565a12… |
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 DET0803Open 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.