- Home
- SIEM use cases
- Network Share Tampering Detection
Network Share Tampering Detection
In this page
- Threat snapshot
- How this attack works
- Attack chain
- Real-world scenario
- Business impact: What can go wrong
- Indicators of compromise and detection signals
- Prerequisites for detection using Log360
- Detecting with Log360
- Investigating an alert
- Responding and remediating
- False positive guidance
- Hardening and prevention
Threat snapshot
Network shares are the connective tissue of most enterprise environments. They host shared drives, departmental file repositories, backup destinations, and the mapped drives that employees rely on daily. Their availability is assumed. Their deletion is not a routine administrative action and in the context of an active intrusion or an insider threat, it is almost always intentional. When an attacker or a malicious insider deletes network shares using net.exe, the built-in Windows network command utility, they are not making a configuration change. They are destroying access, covering tracks, or preparing the environment for a destructive final act.
The net share delete command removes a shared folder from the network without deleting the underlying data, but the operational and investigative consequences are immediate. Users lose access. Backup jobs fail silently. Audit trails tied to share-level access controls are severed. And because net.exe is a legitimate Windows binary used by administrators every day, the command itself does not trigger most security tools. Detection depends entirely on monitoring process creation events for net.exe invocations carrying share deletion arguments, correlated against the user context and the host from which they originated.
At a glance:
| Category | Network Threat |
|---|---|
| SOC maturity level | L2 - Investigation |
| MITRE ATT&CK® tactic | Defense Evasion, Impact |
| MITRE ATT&CK technique | T1070.005 | Indicator Removal: Network Share Connection Removal |
| Severity | High |
| Affected platforms | Windows |
| Detection rule | Windows Network Share Deletion via net.exe |
| Compliance mapping | PCI-DSS 10.6, NIST SP 800-53 SI-3, ISO 27001 A.12.2, HIPAA §164.312(b) |
How this attack works
The Windows net.exe utility is a command-line tool that manages a wide range of network resources: user accounts, services, sessions, and shared folders. The net share command controls the creation, modification, and deletion of network shares on a Windows host. The deletion syntax is straightforward:
net share <ShareName> /delete
net share * /delete (removes all shares on the host)
In an attack context, share deletion via net.exe serves several distinct purposes. During ransomware pre-staging, attackers remove network shares to prevent users from accessing clean copies of files and to destroy backup destinations before deploying the encryptor, maximising ransom leverage. In insider threat scenarios, a departing employee or a compromised privileged account may delete shares to disrupt operations, remove evidence of data access, or cause maximum damage before detection. In post-exploitation cleanup, an attacker who used shared folders for lateral movement may delete those shares to eliminate the network path and complicate forensic reconstruction.
The technique is low-effort and high-impact. It requires only that the executing account holds local administrator rights or has been granted explicit share management permissions. It takes seconds to execute across multiple shares. And because net.exe is a standard Windows binary, its execution alone does not trigger AV or EDR alerts. The detection surface is the command-line argument passed to net.exe, which is only visible if process creation auditing with command-line logging is enabled.
Attack chain
| Stage | Phase | Action | MITRE Technique |
|---|---|---|---|
| 1 | Initial Access / Privilege Escalation | Attacker gains access via phishing, stolen credentials, or insider misuse of a privileged account with share management rights | T1078 — Valid Accounts |
| 2 | Discovery | Attacker enumerates existing network shares using net share or net view to identify target shares before deletion | T1135 — Network Share Discovery |
| 3 | Collection (optional) | Attacker stages or exfiltrates data from target shares before deletion, ensuring they retain copies of sensitive files | T1039 — Data from Network Shared Drive |
| 4 | Defense Evasion / Impact | net share <name> /delete executed to remove one or more shares. Severs user access, disrupts backup jobs, and removes share-level audit trails | T1070.005 — Network Share Connection Removal |
| 5 | Impact | Ransomware encryptor deployed, additional destructive commands run (vssadmin, bcdedit), or attacker exits leaving disruption in place | T1485 — Data Destruction / T1486 — Data Encrypted for Impact |
| 6 | Persistence / Continued Access | Attacker maintains access via other vectors while share deletion causes operational disruption and distracts the response team | T1078 — Valid Accounts |
Real-world scenario
A regional healthcare organisation operates a Windows Server file server that hosts departmental shared drives for clinical, finance, and administration teams. The server is accessible from any domain-joined workstation and is backed up nightly to a dedicated backup share on the same server.
A threat actor who gained access to the network two weeks earlier via a phishing email has been moving laterally using a compromised IT helpdesk account. Having identified the file server as the primary data repository, they begin preparing a ransomware deployment. Forty minutes before running the encryptor, they log into the file server remotely using the helpdesk account and execute a sequence of net share commands deleting the backup share first, then the clinical and finance shares in succession.
The nightly backup job fails silently. Clinical staff arriving the next morning cannot access patient records. The finance team cannot reach their shared reporting drive. IT receives a flood of access complaints. By the time the team investigates the share deletion events, the encryptor has already run. Because the backup share was deleted before the backup job ran, no clean recovery point exists on the server. The organisation faces a choice between paying the ransom and rebuilding from an older offsite tape.
Why this happens
Network share deletion via net.exe succeeds as a pre-ransomware step because it is operationally invisible until users attempt to access the share. No alert fires when a share is removed. No user receives a notification. Backup software logs a failed job rather than raising an immediate alarm. Without real-time process creation monitoring tied to net.exe command-line arguments, the deletion goes unnoticed until the damage is complete. By the time the access complaints reach the IT team, the encryptor has already run.
Business impact: What can go wrong
Network share deletion has immediate operational and downstream security consequences:
- Operational disruption: removal of shared drives severs access to files, tools, and data repositories that teams depend on for daily operations. In environments where shared drives are mapped at login, users may be unable to perform core functions at all until shares are restored.
- Backup destruction: attackers routinely target backup shares specifically before deploying ransomware. Deletion of the backup share eliminates the primary recovery mechanism, maximising ransom leverage and extending recovery time from hours to days or weeks.
- Audit trail severance: share-level access control logs and auditing configurations are removed along with the share. Forensic reconstruction of who accessed what data before the deletion becomes significantly harder, complicating breach notification assessments.
- Ransomware amplification: net share deletion is a documented pre-stage of multiple ransomware families including Conti, BlackCat, and LockBit. Detection of share deletion provides a critical window to interrupt a ransomware deployment before the encryptor runs.
- Regulatory exposure: destruction or unavailability of shared clinical, financial, or personal data records triggers notification obligations under HIPAA, GDPR, and PCI DSS. The inability to demonstrate data integrity following share deletion may constitute a reportable breach regardless of whether exfiltration occurred.
- Reputational and financial damage: extended operational outages caused by share deletion, particularly when combined with a ransomware deployment, carry direct financial costs in recovery labour, ransom payments, and reputational consequences with customers and regulators.
Indicators of compromise and detection signals
The following signals should be collected and correlated to detect network share deletion activity in your environment:
| Signal Type | What to look for | Notes |
|---|---|---|
| Process name | net.exe, net1.exe | net1.exe is a legacy alias for net.exe that executes identically. Attackers specifically use net1.exe to evade rules that only monitor net.exe. Both must be covered. |
| Command-line argument | net share <name> /delete | net share * /delete | The /delete flag is the primary detection anchor. Any invocation of net share with /delete warrants immediate investigation regardless of the share name. |
| Preceding enumeration | net share (no arguments) or net view executed in the same session before deletion | Share enumeration immediately before deletion is a strong indicator of deliberate targeting rather than accidental or scripted administrative deletion. |
| Event ID (Windows Security) | 4688 with ProcessCommandLine containing net share and /delete | 5142 (Network Share Object Added) | 5144 (Network Share Object Deleted) | Event ID 5144 is the direct share deletion audit event but requires Object Access auditing. Event ID 4688 with command-line logging is the primary detection path via Log360. |
| Event ID (Sysmon) | Event ID 1: Image contains net.exe or net1.exe, CommandLine contains share and /delete | Sysmon provides ParentImage and ParentCommandLine, identifying whether the command was executed interactively, via a script, or from a remote session. |
| User context | net share /delete executed under a non-administrator account, or an admin account operating outside normal hours or from an unusual host | Share deletion by a standard user account is immediately suspicious. Admin account execution outside business hours or from a workstation rather than a server is elevated risk. |
| Volume and velocity | Multiple net share /delete commands executed within a short window (under 60 seconds) on the same host | Sequential share deletion in rapid succession is a ransomware pre-staging indicator. A single deletion may be administrative error; multiple deletions in sequence is almost certainly intentional. |
Prerequisites for detection using Log360
Before Log360 can detect network share deletion via net.exe, the following must be in place:
| Requirement | Detail | |
|---|---|---|
| 1 | Windows Process Creation Auditing | Enable via Group Policy: Computer Configuration > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Detailed Tracking > Audit Process Creation, set to Success. Enable 'Include command line in process creation events' to populate the ProcessCommandLine field in Event ID 4688. Without this, net.exe execution is visible but the share name and /delete argument are not. |
| 2 | Object Access Auditing (recommended) | Enable Audit File Share and Audit Detailed File Share under Advanced Audit Policy > Object Access. This generates Event ID 5144 (Network Share Object Deleted), a direct share-specific audit record independent of process creation logging. |
| 3 | Sysmon Deployed | Deploy Sysmon capturing Event ID 1 (Process Create). Sysmon provides enriched context including ParentImage, ParentCommandLine, and ProcessGuid — particularly important for identifying whether the net share deletion was executed interactively or via a remote session. |
| 4 | Logs Forwarded to Log360 | Forward Windows Security and Sysmon logs via the Log360 agent installed on all file servers and domain controllers, or via Windows Event Forwarding (WEF). File servers are the primary target and must be in scope. Confirm agent status is active under Log360 > Settings > Log Source Configuration. |
Detecting with Log360
Step 1: Enable the Rule
Navigate to Log360 > Security > Manage Rules > Rule Library. Search for Windows Network Share Deletion via net.exe. The rule monitors windows_process_started events for net.exe or net1.exe executions where the command line contains share and /delete arguments. Enable the rule and confirm the alert is configured to notify the SOC queue immediately upon firing.
Step 2: Tune the Rule
Before going live, review the following configuration options:
- Scope: apply the rule to all file servers, domain controllers, and any server that hosts shared drives. Desktop endpoints hosting ad hoc shares are lower priority but should not be excluded entirely.
Step 3: Read the Alert
When the Windows Network Share Deletion via net.exe rule fires, the alert surfaces the following fields. Review each in sequence:
| Field | What to look for |
|---|---|
| HOSTNAME | Which host the net.exe command ran on. Cross-reference against your file server inventory. A net share command run from a workstation rather than a server may indicate lateral movement to a host used to delete shares on connected servers. |
| USERNAME / SECURITYID | The account that executed the deletion. A standard user account executing net share /delete is immediately high confidence. An admin account warrants verification against the change management log and the account owner's on-call status. |
| COMMANDLINE | The full net share command including the share name and /delete argument. Note the specific share targeted. Deletion of a backup share or an IT administration share is significantly higher risk than a routine departmental share. |
| PARENTPROCESSNAME | What spawned net.exe. cmd.exe or powershell.exe as parent in a remote session context is a strong indicator of scripted or remotely executed deletion. explorer.exe as parent suggests interactive local execution. |
| PROCESSID / PARENTPROCESSID | Use these to load the full process tree in the Incident Workbench. Identify what ran before net.exe in the same session to determine whether share enumeration preceded the deletion and whether other destructive commands followed. |
Investigating an alert
When a Windows Network Share Deletion via net.exe alert fires, follow these steps to establish scope and intent:
- Open the Incident Workbench from the alert panel. Load the process tree for the affected host and session window. Determine the full execution chain: what spawned net.exe, what other commands ran in the same session before and after the deletion, and whether net share or net view was executed with no arguments before the deletion — which indicates deliberate enumeration prior to targeting.
- Identify the specific share or shares deleted from the COMMANDLINE field. Cross-reference against your shared drive inventory. Prioritise the investigation if a backup share, an IT administration share, or a share hosting regulated data was among those deleted.
- Query Log360 for all net.exe and net1.exe executions across the environment in the same 30-minute window. Determine whether the deletion was isolated to a single host or whether the same command pattern appears across multiple hosts simultaneously, which indicates a scripted or worm-style campaign.
- Check Windows Security Event ID 4624 logon events for the executing account in the 60 minutes before the deletion. Determine the logon type: type 3 (network logon) indicates a remote session. Identify the source IP address. If the logon originated from outside the user's normal workstation or from an external address, this is a strong indicator of credential compromise.
- Verify with the account owner or their manager whether the deletion was an authorised administrative action. Check your change management system for an approved change ticket covering share removal on this host at this time. If no ticket exists and the account owner cannot confirm the action, treat the event as confirmed malicious.
- Assess the current state of the deleted shares. Determine whether the underlying data is still present on disk. A net share deletion does not delete the directory or its contents — restoration is possible by recreating the share if the data has not been subsequently encrypted or destroyed.
Escalation trigger
Escalate immediately to L3 and invoke your incident response plan if any of the following are observed: more than one share deleted in rapid succession on the same host; deletion of a backup share or an IT infrastructure share; net share /delete executed under a compromised or non-administrative account; or net.exe execution followed within 5 minutes by vssadmin.exe delete shadows, bcdedit.exe, or wbadmin.exe delete catalog. These combinations are consistent with active ransomware pre-staging and require immediate host isolation.
Responding and remediating
Immediate containment
- Isolate the affected host from the network immediately using EDR host isolation or by disabling the network adapter. If the share deletion is confirmed as a ransomware pre-stage, isolation must occur before the encryptor can be deployed or spread to additional hosts.
- Disable the executing user account in Active Directory: Disable-ADAccount -Identity [username]. If the account is a service account or shared admin account, coordinate with the account owner, but prioritise containment over convenience.
- Suspend any active remote sessions to the affected host. Query active sessions using query session and terminate suspicious remote desktop or network logon sessions from unrecognised source IPs.
- Block the source IP address of any remote logon used to execute the deletion at the perimeter firewall and on the host's Windows Firewall if the IP is external or unrecognised.
Forensic preservation
- Export the Windows Security event log and Sysmon operational log from the affected host before any remediation. These are the primary forensic record of the deletion sequence, the account used, and the session context.
- Capture a disk image or at minimum a volume shadow copy snapshot of the affected host before any share restoration or remediation activity. This preserves the file system state and any artefacts left by the attacker.
- Document which shares were deleted, their original paths, the permissions configured on them, and the time of deletion. This is required for restoration and for breach notification assessments.
Eradication and recovery
- Restore deleted shares using your documented share configuration. If share configurations are not documented, reconstruct them from Windows Security Event ID 5142 (Network Share Object Added) records, which capture share creation with path and permissions.
- Verify the underlying data directories are intact and have not been encrypted, deleted, or modified. Check file modification timestamps across the directories that were shared.
- Reset credentials for the compromised or misused account and conduct a full review of all actions taken by that account in the 72 hours preceding the deletion.
- If ransomware deployment was confirmed or attempted, follow your ransomware-specific incident response playbook. Do not reconnect isolated hosts until a forensic review confirms a clean bill of health.
False positive guidance
net share /delete is used in legitimate administrative contexts. The following scenarios commonly produce false positive alerts:
| Scenario | Description | How to differentiate |
|---|---|---|
| Planned server decommission | IT administrators removing shares as part of a planned server decommission or infrastructure migration will execute net share /delete commands deliberately. | Verify against an approved change ticket. Decommission activity will be scheduled, executed during a change window, and performed by a named administrator. It will not be preceded by share enumeration or followed by destructive commands. |
| Automated deployment scripts | Software deployment and provisioning scripts sometimes create and delete temporary shares as part of their workflow, particularly during OS imaging or application packaging. | The parent process will be a known deployment tool (SCCM, Ansible, Intune management agent) and execution will occur on known build or imaging hosts during scheduled deployment windows. Exclude these hostnames explicitly in the rule configuration. |
| Home drive cleanup during offboarding | Administrators removing stale user home directory shares as part of account offboarding workflows may delete individual shares using net share /delete. | Offboarding deletions are single-share operations tied to a specific user, executed during business hours by a known admin account with a corresponding change ticket. They will not be followed by further destructive commands. |
| Test environment teardown | Lab and test environment administrators routinely clean up test shares after completing testing cycles. | Execution will originate from known lab server hostnames during business hours by admin accounts documented as owning those environments. Add lab server hostnames to a named exclusion group with documented justification. |
Key differentiator
Legitimate net share /delete operations are singular, deliberate, and documented. They are performed by a known administrator during business hours with a corresponding change record, and they are not preceded by share enumeration or followed by further destructive commands such as shadow copy deletion, bcdedit modification, or file encryption activity. Any net share /delete that lacks all three of these characteristics: an authorised account, business hours, and a change ticket should be treated as suspicious until confirmed otherwise.
Hardening and prevention
The following controls reduce the risk of network share tampering in your environment:
- Apply the principle of least privilege to share management permissions. Only named server administrators with a documented business need should hold the rights to create or delete network shares. Standard user and helpdesk accounts should not be able to execute net share /delete on production file servers.
- Enable Windows Object Access auditing for file shares on all production file servers. Event ID 5142 (share created) and Event ID 5144 (share deleted) provide a direct, tamper-evident audit record of share lifecycle changes independent of process creation logging.
- Implement network segmentation to restrict which hosts can establish administrative sessions to file servers. File servers should not accept RDP or SMB administrative connections from general-purpose workstations. Require jump server access for all file server administration.
- Protect volume shadow copies and backup integrity using immutable backup solutions or offsite tape rotations. Ensure backup shares are hosted on separate infrastructure from production file servers so that a single compromised host cannot destroy both production data and its backup simultaneously.
- Restrict execution of net.exe and net1.exe via AppLocker or WDAC policies on servers where net share management is not an operational requirement. On file servers where net.exe must be available, create an allow list of approved parent processes and alert on any execution outside those parents.
- Enable Windows Defender Credential Guard on domain controllers and file servers to prevent LSASS credential harvesting, which is the most common mechanism by which attackers obtain the privileged account credentials needed to execute net share /delete.
- Conduct quarterly reviews of all configured network shares on production file servers. Identify and remove stale or undocumented shares. A smaller share surface reduces the operational impact of share deletion and makes anomalous deletion easier to detect.
