DET0796: Detection of Internet Accessible Device
DET0796 matters because internet-accessible industrial devices can turn a control-system environment into a directly reachable target. Even without a softw...
Analyst context for executives and security teams
DET0796 matters because internet-accessible industrial devices can turn a control-system environment into a directly reachable target. Even without a software exploit, exposed remote-access or control-system interfaces may create a path into operations if they are intentionally or accidentally published without adequate protections. For leaders, the key decision is whether the organization can prove which ICS assets are internet reachable, why they are exposed, who owns the risk, and what compensating controls are in place.
Executive priority
Treat this as an operational resilience and governance question, not only a SOC alerting problem. Executives should ask for evidence of external exposure management for industrial environments, documented business justification for any internet-facing ICS device, ownership of remediation exceptions, and incident-response plans for direct access into control-system networks. This supports risk prioritization, audit readiness, and cyber-physical risk management where exposed devices could affect industrial operations.
Technical view
The supplied ATT&CK object is a detection strategy for T0883: Internet Accessible Device in the ICS domain. MITRE provides no official detection text, platforms, or tactics for this object, so defenders should validate coverage using local architecture and exposure data. SOC, detection engineering, and IR teams should focus on confirming whether any ICS-related device or remote-access interface is reachable from the public internet, whether exposure is expected, and whether access paths bypass normal remote-access controls. Detection logic should be tied to asset inventory, network boundary monitoring, external attack-surface discovery, firewall/NAT configuration review, and authentication/access logs where available.
Likely telemetry
- External attack-surface scan results for public IP ranges and domains associated with industrial sites
- Authoritative ICS asset inventory and network topology records
- Firewall, router, NAT, and remote-access gateway configuration data
- Network perimeter logs showing inbound connections to industrial or remote-access services
- DNS, certificate, and internet-facing service inventory evidence
Detection direction
- Compare external exposure findings against the approved ICS asset inventory; prioritize any device or service that is publicly reachable but not explicitly authorized.
- Tune detections to identify new, changed, or reappearing internet-facing services associated with industrial networks rather than relying only on known-bad indicators.
- Validate whether internet reachability provides a direct path into control-system networks, especially where access does not traverse expected external remote-service controls.
- Account for false positives from approved vendor support paths, test environments, cloud-hosted documentation portals, or non-ICS systems using similar naming; require asset ownership and network context to confirm relevance.
- Track blind spots caused by incomplete public IP ownership records, unmanaged site connectivity, undocumented temporary remote access, and lack of centralized firewall or authentication logging.
Mitigation priorities
- Establish and maintain an authoritative inventory of ICS assets, public IP space, remote-access paths, and business owners.
- Remove unintended internet exposure for industrial devices and require documented approval for any intentional exposure.
- Place remote access behind controlled access mechanisms with strong authentication, segmentation, monitoring, and change control appropriate to the environment.
- Review firewall, NAT, and routing rules for direct paths from the internet into control-system networks.
- Create an exception-management process that records business justification, compensating controls, review dates, and incident contacts for any remaining exposure.
Analyst notes and limits
This take is based on the detection strategy object DET0796 and its relationship to ATT&CK for ICS technique T0883, Internet Accessible Device. Because the official object does not include detection text, platforms, or tactics, the most defensible use is as a control-validation and exposure-management prompt: prove what is reachable, whether it is approved, and whether monitoring exists.
MITRE supplied no official description or detection guidance for DET0796, and no platforms or tactics are specified. The related T0883 description indicates internet exposure of industrial devices and possible direct movement into control-system networks, but local validation is required to determine actual exposure, business impact, and monitoring coverage. No active exploitation, attribution, or guaranteed detection coverage is implied.
Detection of Internet Accessible Device
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 | T0883 | Internet Accessible Device | This object detects Internet Accessible Device. |
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 | e1de3e0394cf… |
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 DET0796Open 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.