DET0314: Detection Strategy for Network Sniffing Across Platforms
This detection strategy matters because it is tied to ATT&CK technique T1040, Network Sniffing, where an adversary may passively capture traffic to learn a...
Analyst context for executives and security teams
This detection strategy matters because it is tied to ATT&CK technique T1040, Network Sniffing, where an adversary may passively capture traffic to learn about the environment or obtain authentication material in transit. For leaders, the key issue is not just whether a tool can alert on sniffing, but whether the organization can prove it has visibility into the network locations and systems where passive capture could expose credentials or sensitive operational traffic.
Executive priority
Prioritize this as a visibility and resilience question: do security teams know where packet capture, promiscuous interface use, or span-port access would be legitimate, and can they distinguish that from unauthorized monitoring? This supports incident decision-making, identity risk reduction, audit evidence for monitoring controls, and cyber-physical risk management where network devices or infrastructure traffic are in scope. Because the supplied detection strategy has no official detection text, leadership should ask for evidence of actual telemetry collection and tested use cases rather than assuming ATT&CK mapping equals coverage.
Technical view
DET0314 is a detection strategy object for Network Sniffing Across Platforms and is related to T1040 Network Sniffing. The related technique is in credential-access and discovery, with related platforms listed as IaaS, Linux, macOS, and Network Devices. SOC and detection engineering teams should validate whether they can observe signs of packet capture or passive monitoring in those environments, especially interface state changes, packet capture tooling execution where logged, network device configuration changes involving span or mirror ports, and cloud or infrastructure events that could enable traffic capture. IR teams should prepare to answer whether captured traffic could have included authentication material or sensitive environment data.
Likely telemetry
- Endpoint process and command execution logs for packet capture utilities where available
- Operating system or EDR telemetry showing network interface mode changes, including promiscuous mode where available
- Network device configuration logs for span, mirror, or traffic monitoring port changes
- Cloud or IaaS control-plane logs related to traffic mirroring or packet capture capabilities where applicable
- Asset and admin activity records identifying systems or users authorized to perform packet capture
Detection direction
- Inventory approved packet capture, monitoring, and troubleshooting workflows so detections can distinguish authorized diagnostics from suspicious activity.
- Validate coverage separately for the related platforms: IaaS, Linux, macOS, and Network Devices; do not infer coverage from one platform to another.
- Tune detections around unauthorized interface promiscuous mode changes, unexpected packet capture processes, and network device span or mirror configuration changes.
- Correlate suspicious sniffing indicators with credential-access and discovery context, such as proximity to authentication flows or sensitive network segments.
- Account for false positives from network engineering, troubleshooting, monitoring appliances, security tools, and approved incident response collection.
Mitigation priorities
- Define and document who is authorized to perform packet capture or configure traffic mirroring across endpoints, cloud infrastructure, and network devices.
- Restrict administrative access to network devices, IaaS traffic mirroring features, and systems capable of broad packet capture.
- Segment sensitive authentication and management traffic so passive capture opportunities are reduced where feasible.
- Maintain change-control and logging for span ports, mirror sessions, and monitoring configurations.
- Use encrypted protocols for sensitive traffic to reduce the value of captured network data.
Analyst notes and limits
The supplied object is a detection strategy, not the underlying technique. Its only substantive relationship is that it detects T1040 Network Sniffing. The practical value for Glexia customers is to turn that relationship into evidence questions: where could sniffing occur, who is allowed to do it, what telemetry proves it happened, and whether detections are tested against legitimate and unauthorized monitoring scenarios.
The ATT&CK object provides no official description, no official detection text, and no platforms or tactics directly on the detection strategy. Platform and tactic context is taken only from the related T1040 technique. Local architecture, logging, and approved administrative practices are required to determine real detection coverage and risk.
Detection Strategy for Network Sniffing Across Platforms
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 |
|---|---|---|---|
| Enterprise | T1040 | 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 | a067b0db238f… |
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 DET0314Open 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.