DET0804: Detection of Remote Services
DET0804 is an ATT&CK for ICS detection strategy for identifying use of Remote Services behavior. The business significance is not the existence of remote a...
Analyst context for executives and security teams
DET0804 is an ATT&CK for ICS detection strategy for identifying use of Remote Services behavior. The business significance is not the existence of remote administration itself, but whether the organization can distinguish expected operator access from remote movement between industrial assets and network segments. In ICS environments, that visibility can affect incident triage, operational continuity, and confidence that remote access pathways are governed and monitored.
Executive priority
Security leaders should treat this as a validation point for remote access governance in industrial networks: which remote services are permitted, who is allowed to use them, where they can traverse, and what evidence exists for audit or incident response. Because the ATT&CK object provides no official detection logic, platforms, or tactics, priority should be on confirming local telemetry and controls rather than assuming coverage from the ATT&CK entry alone.
Technical view
This detection strategy is linked to ICS technique T0886, Remote Services, where adversaries may leverage services such as RDP, SMB, SSH, and similar mechanisms to move between assets and network segments. SOC, detection engineering, and IR teams should validate visibility into remote service authentication, session establishment, lateral network connections, and segmentation crossings. Baselines should separate routine operator or administrator activity from unusual source/destination pairs, unexpected protocol use, new remote access paths, or access outside approved operational patterns.
Likely telemetry
- Remote service authentication and session logs where available
- Network flow records showing source, destination, port, protocol, and timing
- Firewall, segmentation, jump host, or remote access gateway logs
- Asset inventory and network zone mapping for ICS assets and supporting systems
- Account and privilege context for users or service accounts initiating remote sessions
Detection direction
- Inventory approved remote service paths first; detection quality depends on knowing which remote access is normal and authorized.
- Correlate remote service activity with asset criticality and network segment boundaries, especially connections that cross expected ICS zones.
- Tune for deviations such as new source systems, new destination assets, unusual timing, unexpected accounts, or protocols not normally used for operations.
- Account for false positives from legitimate operator, engineering, maintenance, or administrative workflows.
- Validate whether telemetry exists on both sides of segmentation controls; network-only visibility may miss user context, while host-only visibility may miss lateral paths.
Mitigation priorities
- Define and document approved remote service use cases for ICS and supporting environments.
- Restrict remote services to necessary systems, accounts, and network paths using segmentation and access control.
- Centralize remote administration through monitored pathways where operationally feasible.
- Review privileged and remote access permissions for users and service accounts.
- Ensure logs needed for incident response and compliance evidence are retained and correlated.
Analyst notes and limits
The ATT&CK detection strategy has no official description, detection text, platforms, or tactics in the supplied fields. The practical guidance is therefore derived from its relationship to ICS technique T0886, Remote Services, and the supplied examples of RDP, SMB, SSH, and similar mechanisms. Local architecture, remote access design, and operational procedures are required to make this actionable.
This take does not assert active exploitation, adversary attribution, affected products, or guaranteed detection coverage. ATT&CK does not specify platforms or detection analytics for DET0804 in the supplied object, so teams must validate telemetry and control coverage in their own environment.
Detection of 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 | T0886 | Remote Services | This object detects 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 | d5ef006545ee… |
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 DET0804Open 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.