SDelete is a command-line utility that securely deletes files and frees space by overwriting data rather than just removing references. Attackers use it to destroy evidence and hinder recovery after intrusion. Defenders look for unusual deletion activity, especially against logs, staging folders, and backup targets, and restrict its execution to authorised administration.
What SDelete is doing when it “securely deletes” data
SDelete is a destructive file-handling utility, not a normal delete command with a different label. Its core behaviour is to overwrite file contents or free space so that removed data is harder to recover from disk-level tools, forensic analysis, or ordinary undelete workflows. That makes it useful both for privacy-preserving disposal and for post-compromise cleanup.
The important distinction is that SDelete acts on data remnants, not just file system references. A standard delete often only marks space as reusable, while secure deletion tries to reduce the chance that old content can be reconstructed from slack space, free space, or previously allocated file regions. That is why it is treated as a high-impact utility in administration and incident response.
Why attackers and defenders care about it
Attackers value tools like SDelete because they can erase traces quickly, especially where logs, staging folders, dropped tooling, scripts, or recovered archives might otherwise reveal what happened. In practice, secure deletion can be part of anti-forensics, cleanup after lateral movement, or attempts to frustrate recovery and post-incident scoping.
Defenders care for the same reason in reverse. If a host starts running secure deletion against log locations, backup targets, quarantine folders, or other evidence-rich paths, that is a strong signal that the system may be in a containment or concealment phase. The control problem is not just the delete itself, but the combination of deletion utility use, targeting of sensitive directories, and the timing relative to unusual access or privilege use.
How to use the result safely in practice
SDelete should be treated as an administration-only capability with tight command execution controls. When it is legitimate, the strongest use case is controlled data sanitisation, decommissioning, or cleanup where the organisation already understands the storage medium and retention requirements. When it is not legitimate, the same capability becomes a rapid evidence-destruction tool.
For that reason, the operational question is not only whether the binary exists, but who can launch it, where it can run, and what paths it can touch. A host-based control that merely watches for file deletion volume is usually too weak on its own. You want to combine execution restriction, alerting on suspicious target paths, and review of parent process context so that deletion activity can be interpreted as either approved sanitisation or possible tampering.
Risk and Threat Considerations
SDelete creates a clear anti-forensics risk because it can turn a routine cleanup action into deliberate evidence destruction. The main exposure is not the overwrite mechanism itself, but the loss of recoverability when logs, temporary work areas, or copied tools are wiped before defenders can collect them.
Failure mechanism: An attacker with sufficient execution rights runs secure deletion against evidence-bearing files or free space, reducing the chances of later recovery and obscuring the intrusion timeline.
Impact: Incident responders may lose logs, artefacts, and historical context needed for containment decisions, root-cause analysis, and downstream legal or disciplinary action.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1070 — Indicator Removal on Host | SDelete is used to remove traces and hinder analysis on a host. |
| Recommendation — Map secure-deletion events to T1070 and investigate evidence-removal activity quickly. | ||
| NIST SP 800-53 Rev 5 | AU-11 — Audit Record Retention | Secure deletion threatens the retention of logs and records needed for investigation. |
| AU-9 — Protection of Audit Information | The utility can target logs and other audit data, weakening integrity and availability. | |
| Recommendation — Preserve required audit records and restrict deletion paths that could erase them. Protect audit data from deletion, overwrite, and unauthorised modification. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Deletion of logs is a direct operational threat to detection and response evidence. |
| Recommendation — Centralise and protect logs so local secure deletion cannot erase all evidence. | ||
Practitioner Guidance
What to verify: Confirm whether the deletion event is tied to an approved administration task, a maintenance window, or a decommissioning workflow. If not, treat it as suspicious until you can explain the actor, process, host, and target path.
Decision rule: If the utility is used against logs, backup locations, investigation staging areas, or security tooling output, prioritise containment and evidence preservation over local cleanup. If it is used on a planned disposal task, verify the approval trail before accepting it as benign.
What good looks like: Execution is restricted to authorised administrators, deletion activity is logged with process context, and unusual target paths trigger review fast enough to preserve remaining evidence.
Practitioner takeaway: Secure deletion is legitimate only when the organisation can justify the action, bound the scope, and still preserve enough telemetry to tell routine sanitisation from anti-forensics.