AN0875: Analytic 0875
Detects suspicious execution of network monitoring tools (e.g., Wireshark, tshark, Microsoft Message Analyzer), driver loading indicative of promiscuous mode, or non-admin user privilege escalation to access NICs for capture.
Analyst context for executives and security teams
This analytic matters because unauthorized packet capture on Windows systems can expose credentials, session data, internal protocols, and sensitive business communications. For leaders, the practical question is whether the organization can distinguish approved troubleshooting activity from suspicious use of network monitoring tools or driver/NIC access changes that enable traffic capture.
Executive priority
Prioritize this as a control-validation item for SOC readiness, incident response, and compliance evidence around sensitive network data handling. Executives should ask whether packet capture tools are approved, where they are allowed, who can run them, and whether security teams can prove visibility into Windows endpoints where network capture would create material confidentiality or investigation risk.
Technical view
For Windows environments, validate monitoring for suspicious execution of network monitoring tools such as Wireshark, tshark, or Microsoft Message Analyzer, as well as driver loading behavior indicative of promiscuous mode and non-admin privilege escalation to access network interface cards for capture. Because no ATT&CK detection logic is supplied, detection engineering should translate this analytic into local allowlists, endpoint telemetry checks, and correlation with user privilege context.
Likely telemetry
- Windows process execution telemetry for network monitoring tools
- Command-line and parent-process context for packet capture utilities
- Driver load events or endpoint telemetry showing capture-related driver activity
- User privilege and group membership context, especially non-admin attempts to access NIC capture capabilities
- Endpoint inventory or software inventory showing installed packet capture tools
Detection direction
- Build environment-specific baselines for approved packet capture activity by IT, network, and security teams.
- Tune detections around suspicious execution rather than tool name alone, since legitimate troubleshooting can generate false positives.
- Correlate tool execution with user role, host criticality, timing, parent process, and whether the user normally performs network diagnostics.
- Validate visibility into driver loading and NIC access attempts on Windows endpoints; this is a likely blind spot if endpoint telemetry is limited to process names.
- Review non-admin privilege changes or escalation paths that enable packet capture access.
Mitigation priorities
- Define and document approved packet capture tools, users, systems, and business purposes.
- Restrict packet capture capability to authorized administrators or approved support/security roles.
- Review endpoint control policies governing installation and execution of network monitoring tools on Windows systems.
- Monitor and control driver loading associated with network capture where feasible.
- Include packet capture activity in incident response triage playbooks, especially on systems handling sensitive data.
Analyst notes and limits
This object is a detection analytic, not a technique or intrusion report. The supplied ATT&CK fields identify Windows as the platform and describe detection intent around network monitoring tools, promiscuous-mode-related driver loading, and non-admin escalation to access NICs. No tactics, relationships, or formal detection query were supplied.
The official detection field is not provided, and no relationship context is supplied. This take therefore cannot assert specific ATT&CK tactics, coverage against a named technique, threat actor behavior, or guaranteed detection outcomes. Local endpoint logging, administrative practices, and approved troubleshooting workflows are required to determine effectiveness.
Analytic 0875
Detects suspicious execution of network monitoring tools (e.g., Wireshark, tshark, Microsoft Message Analyzer), driver loading indicative of promiscuous mode, or non-admin user privilege escalation to access NICs for capture.
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.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
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 | d3a9ec39a5df… |
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 AN0875Open 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.