How do attackers use SDelete?

How attackers use SDelete to hinder incident response

SDelete is attractive because it does more than remove a file from view, it can overwrite deleted content and wipe free space so recovery is harder during forensic analysis. That makes it useful to an attacker who wants to reduce evidence after staging, exfiltration, or log tampering, especially when they know defenders may rely on post-incident disk recovery.

Its value is not in privilege escalation or initial access, but in erasing traces after the operator has already achieved something worth hiding. In that sense, SDelete fits the same post-compromise pattern as other anti-forensics utilities: it tries to collapse the defender’s timeline by making deleted material less recoverable and by creating ambiguity about what was present before cleanup.

The behaviour often matters most near the end of an intrusion, when the attacker is trying to leave behind less investigable state on endpoints, file servers, jump hosts, or other systems that may retain recoverable artifacts. Because secure-delete tools are legitimate in some administrative workflows, the security signal comes from context, timing, target volume, and whether the action aligns with expected operational activity.

What SDelete changes in the attacker playbook

SDelete does not create the compromise, it changes the quality of the evidence left behind. If the environment already has weak logging, short retention, or limited disk forensics capability, secure deletion can make it much harder to reconstruct what was accessed, copied, or staged before cleanup. That is why it is most concerning when paired with exfiltration, destructive changes, or attempts to delay detection.

Defenders should think about two practical questions: first, whether the utility was used on a system that should never need it; second, whether its use appears after suspicious activity rather than as part of a known maintenance window. A single secure-delete invocation may be benign, but repeated or scripted use across multiple systems is much more consistent with adversarial cleanup.

If you want a broader view of how attackers combine cleanup with theft and lateral movement, NHIMG’s The State of NHI & AI Agent Breach Report 2026 is useful because it places credential theft, exfiltration, and post-compromise behaviour in the same operational sequence.

Detecting misuse and preserving evidence before cleanup succeeds

Because SDelete is often run late in an intrusion, defenders get the best chance of seeing it by watching for process execution, command-line use, and unexpected deletion bursts on sensitive hosts. Pay special attention to systems that hold logs, forensic material, shared data, build artifacts, or files that would be valuable for later investigation.

• Look for secure-delete binaries executed by unusual users, scheduled tasks, remote administration tooling, or scripts that touch many paths at once.
• Correlate file deletion with recent authentication anomalies, unusual archive creation, outbound transfer, or administrative activity outside normal change windows.
• Preserve volatile and remote evidence early, because once free space is overwritten, local recovery options can drop sharply.
• Treat secure-delete use on servers with regulated or sensitive records as a higher-priority review than the same activity on a user workstation.

Risk and Threat Considerations

Secure-delete utilities are a classic anti-forensics capability because they reduce the amount of recoverable evidence available to defenders. The threat is highest when attackers already have a foothold and want to hide what they staged, copied, or changed before defenders can image the host or collect logs.

Failure mechanism: The attacker uses a legitimate cleanup tool to overwrite deleted data and free space, which can remove recoverable remnants that would otherwise support timeline reconstruction, file recovery, or artifact correlation.

Impact: Investigators may lose the ability to recover key files, confirm staging paths, or prove how far the intrusion progressed, which can delay containment and weaken root-cause analysis.

Practitioner Guidance

What to verify: Confirm whether the execution fits an approved sanitisation workflow, or whether it occurred after suspicious file movement, log tampering, or privileged access. If the tool ran on systems that should not routinely require it, treat that as a review trigger rather than a standalone alert.

Decision rule: If secure-delete activity appears on a sensitive host outside a known maintenance process, prioritise evidence preservation and scope assessment before assuming the deletion was routine. If it is part of sanctioned sanitisation, verify change approval and target scope so you can separate legitimate cleanup from adversarial use.

Practitioner takeaway: SDelete is dangerous to defenders because it targets recoverability, not just visibility, so the key judgement is whether the execution is consistent with authorised hygiene work or with an attacker trying to erase the investigation trail.

Related resources from NHI Mgmt Group

• How do attackers use list planting?
• How do attackers use invisible Unicode?
• How do attackers turn a supply-chain incident into wider NHI compromise?
• How do attackers operationalise stolen OAuth tokens at scale?