DET0800: Detection of Network Sniffing
DET0800 is a detection strategy for identifying Network Sniffing in ICS environments. The business significance is that sniffing can let an adversary obser...
Analyst context for executives and security teams
DET0800 is a detection strategy for identifying Network Sniffing in ICS environments. The business significance is that sniffing can let an adversary observe operational communications and gather information that may support later disruption, manipulation, or unauthorized access. Because the ATT&CK object provides no platform, tactic, or detection-detail fields, the value for leaders is to verify whether the organization can prove visibility into network monitoring or capture activity in sensitive operational network segments, rather than assuming coverage exists.
Executive priority
Prioritize this as an assurance question for operational resilience: can the security and OT teams demonstrate evidence that unauthorized traffic capture or monitoring would be noticed in the environments that matter most? This is relevant to SOC readiness, incident response scoping, compliance evidence, and cyber-physical risk governance, but the supplied ATT&CK fields do not justify claims about specific affected platforms, adversaries, or active exploitation.
Technical view
SOC, detection engineering, and IR teams should treat DET0800 as a validation prompt tied to ICS technique T0842 Network Sniffing. Confirm what telemetry exists to observe suspicious packet capture, promiscuous network monitoring behavior, unexpected network interface activity, and unusual visibility into traffic not destined for a host. Because MITRE did not provide official detection logic or platform scope here, detections should be built and tested against local architecture, authorized monitoring tools, and known administrative workflows.
Likely telemetry
- Network sensor records or packet metadata from ICS/OT segments
- Host or endpoint evidence of packet capture or network monitoring tools where host telemetry exists
- Network interface configuration or state changes, including promiscuous-mode indicators where available
- Asset inventory and authorized monitoring-tool baselines
- Change records and administrative activity logs for systems with legitimate traffic-capture responsibilities
Detection direction
- Map which ICS network zones and critical assets have telemetry capable of showing traffic capture or unauthorized monitoring behavior.
- Baseline legitimate engineering, troubleshooting, and monitoring activity to reduce false positives from approved packet captures.
- Validate alerting around unexpected sniffing behavior against the local asset inventory, because the ATT&CK object does not specify platforms or detection analytics.
- Use the relationship to T0842 Network Sniffing to prioritize detection in places where captured communications could expose operational information or support follow-on activity.
- Document blind spots where encrypted traffic, passive taps, unmanaged hosts, or limited OT host logging prevent confident detection.
Mitigation priorities
- Start with visibility: identify critical ICS network segments, authorized capture points, and systems permitted to monitor traffic.
- Restrict and govern packet-capture capabilities through administrative controls, access management, and change approval where applicable.
- Segment and monitor sensitive operational communications so unexpected observation paths are easier to identify.
- Maintain an approved-tool and approved-user baseline for troubleshooting and monitoring activity.
- Include Network Sniffing scenarios in IR playbooks so responders can quickly determine what traffic may have been exposed and what operational processes are at risk.
Analyst notes and limits
The supplied ATT&CK object is a detection strategy with a relationship to ICS technique T0842 Network Sniffing. MITRE did not provide an official description, detection text, tactics, or platforms for DET0800, so this take focuses on defensible validation questions and telemetry classes rather than specific analytics or vendor controls.
This assessment is limited to the provided official STIX fields, the external reference, and the stated relationship to T0842. It does not establish active exploitation, actor usage, affected products, specific platforms, or guaranteed detection coverage. Local network architecture, OT asset inventory, logging depth, and authorized monitoring practices are required to make this operational.
Detection of Network Sniffing
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 | T0842 | Network Sniffing | This object detects Network Sniffing. |
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 | 50b752ce71db… |
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 DET0800Open 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.