AN0286: Analytic 0286
Detects network share disconnection attempts using command-line tools like `net use /delete`, PowerShell `Remove-SmbMapping`, and correlation with process lineage and SMB session teardown activity.
Analyst context for executives and security teams
This analytic matters because deliberate network share disconnections can disrupt visibility into file access, break operational workflows that depend on mapped shares, or appear during cleanup after use of shared resources. For Windows environments, leaders should treat this as a validation point for whether endpoint and network telemetry can show not only that a share was disconnected, but which user, process, and host initiated it.
Executive priority
Prioritize this where Windows file shares support business operations, investigations, or compliance evidence. The decision value is confirming that SOC and IR teams can reconstruct network share teardown events during an incident, especially when command-line tools or PowerShell are used. Because ATT&CK provides no tactic or relationship context for this analytic, it should be used as a coverage check rather than as a standalone indicator of malicious activity.
Technical view
Validate detection for Windows command-line and PowerShell-driven network share disconnection activity, including patterns such as net use /delete and PowerShell Remove-SmbMapping. The strongest implementation should correlate process lineage with SMB session teardown activity so analysts can distinguish user-initiated administration from suspicious process-driven cleanup. Since the official detection logic is not provided, teams should define and test local logic against their endpoint process telemetry and SMB/session data.
Likely telemetry
- Windows process creation events with command line arguments
- PowerShell execution logs or script block/module logging where available
- Parent-child process lineage for command shells and PowerShell
- SMB client or server session teardown/activity logs
- User, host, and share mapping context from endpoint or Windows event sources
Detection direction
- Confirm command-line visibility captures arguments for network share deletion commands.
- Correlate share disconnection activity with process ancestry, user context, host role, and recent access to the share.
- Tune expected administrative or help desk activity to reduce false positives while preserving visibility into unusual parent processes or unexpected users.
- Look for gaps where PowerShell logging, process command lines, or SMB session data are not collected or not retained long enough for incident response.
- Do not treat a network share disconnect by itself as malicious; use surrounding behavior and local baselines because no ATT&CK tactic or relationship context was supplied.
Mitigation priorities
- Ensure Windows endpoint logging captures process creation and command-line parameters.
- Enable appropriate PowerShell logging where operationally acceptable.
- Centralize SMB/session-related telemetry from systems that host or consume important shares.
- Restrict unnecessary administrative access to shared resources and review who can manage mappings on sensitive systems.
- Document normal administrative procedures for share mapping and disconnection so SOC teams can tune and investigate consistently.
Analyst notes and limits
This is a detection analytic for Windows focused on network share disconnection attempts via command-line tools and PowerShell, with recommended correlation to process lineage and SMB session teardown activity. Its main value is as a telemetry and correlation coverage test for SOC and IR readiness.
The supplied ATT&CK object does not include official detection logic, tactics, relationships, threat actors, campaigns, or mitigations. Local baselines, logging configuration, and asset criticality are required to determine severity and detection fidelity.
Analytic 0286
Detects network share disconnection attempts using command-line tools like `net use /delete`, PowerShell `Remove-SmbMapping`, and correlation with process lineage and SMB session teardown activity.
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 | 987aa2b1fe1d… |
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 AN0286Open 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.