{
	"id": "0537d5a5-c2eb-4c2e-afbc-6f2eb19cee8f",
	"created_at": "2026-04-06T00:07:00.600303Z",
	"updated_at": "2026-04-10T03:24:30.158094Z",
	"deleted_at": null,
	"sha1_hash": "93687453fdfefd628d899533e887498fd4495bd7",
	"title": "SDelete - Sysinternals",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 59794,
	"plain_text": "SDelete - Sysinternals\r\nBy markruss\r\nArchived: 2026-04-05 20:23:01 UTC\r\nBy Mark Russinovich\r\nPublished: March 5, 2026\r\n Download SDelete (328 KB)\r\nIntroduction\r\nOne feature of Windows NT/2000's (Win2K) C2-compliance is that it implements object reuse protection. This\r\nmeans that when an application allocates file space or virtual memory it is unable to view data that was previously\r\nstored in the resources Windows NT/2K allocates for it. Windows NT zero-fills memory and zeroes the sectors on\r\ndisk where a file is placed before it presents either type of resource to an application. However, object reuse does\r\nnot dictate that the space that a file occupies before it is deleted be zeroed. This is because Windows NT/2K is\r\ndesigned with the assumption that the operating system controls access to system resources. However, when the\r\noperating system is not active it is possible to use raw disk editors and recovery tools to view and recover data that\r\nthe operating system has deallocated. Even when you encrypt files with Win2K's Encrypting File System (EFS), a\r\nfile's original unencrypted file data is left on the disk after a new encrypted version of the file is created.\r\nThe only way to ensure that deleted files, as well as files that you encrypt with EFS, are safe from recovery is to\r\nuse a secure delete application. Secure delete applications overwrite a deleted file's on-disk data using techniques\r\nthat are shown to make disk data unrecoverable, even using recovery technology that can read patterns in\r\nmagnetic media that reveal weakly deleted files. SDelete (Secure Delete) is such an application. You can use\r\nSDelete both to securely delete existing files, as well as to securely erase any file data that exists in the unallocated\r\nportions of a disk (including files that you have already deleted or encrypted). SDelete implements the Department\r\nof Defense clearing and sanitizing standard DOD 5220.22-M, to give you confidence that once deleted with\r\nSDelete, your file data is gone forever. Note that SDelete securely deletes file data, but not file names located in\r\nfree disk space.\r\nUsing SDelete\r\nSDelete is a command line utility that takes a number of options. In any given use, it allows you to delete one or\r\nmore files and/or directories, or to cleanse the free space on a logical disk. SDelete accepts wild card characters as\r\npart of the directory or file specifier.\r\nUsage:\r\nhttps://docs.microsoft.com/en-us/sysinternals/downloads/sdelete\r\nPage 1 of 4\n\nsdelete [-p passes] [-r] [-s] [-q] [-f] \u003cfile or directory [...]\u003e\r\nsdelete [-p passes] [-q] [-z|-c] \u003cdrive letter [...]\u003e\r\nsdelete [-p passes] [-q] [-z|-c] \u003cphysical disk number [...]\u003e\r\nParameter Description\r\n-c Clean free space.\r\n-f\r\nForce arguments containing only letters to be treated as a file/directory rather than a disk.\r\nNot required if the argument contains other characters (path separators or file extensions for\r\nexample).\r\n-p Specifies number of overwrite passes (default is 1).\r\n-q Quiet mode.\r\n-r Remove Read-Only attribute.\r\n-s Recurse subdirectories.\r\n-z Zero free space (good for virtual disk optimization).\r\n-nobanner Do not display the startup banner and copyright message.\r\nDisks must not have any volumes in order to be cleaned.\r\nFor drive letters, include : , for example D: .\r\nHow SDelete Works\r\nSecurely deleting a file that has no special attributes is relatively straight-forward: the secure delete program\r\nsimply overwrites the file with the secure delete pattern. What is more tricky is securely deleting Windows NT/2K\r\ncompressed, encrypted and sparse files, and securely cleansing disk free spaces.\r\nCompressed, encrypted and sparse are managed by NTFS in 16-cluster blocks. If a program writes to an existing\r\nportion of such a file NTFS allocates new space on the disk to store the new data and after the new data has been\r\nwritten, deallocates the clusters previously occupied by the file. NTFS takes this conservative approach for\r\nreasons related to data integrity, and in the case of compressed and sparse files, in case a new allocation is larger\r\nthan what exists (the new compressed data is bigger than the old compressed data). Thus, overwriting such a file\r\nwill not succeed in deleting the file's contents from the disk.\r\nTo handle these types of files SDelete relies on the defragmentation API. Using the defragmentation API, SDelete\r\ncan determine precisely which clusters on a disk are occupied by data belonging to compressed, sparse and\r\nencrypted files. Once SDelete knows which clusters contain the file's data, it can open the disk for raw access and\r\noverwrite those clusters.\r\nhttps://docs.microsoft.com/en-us/sysinternals/downloads/sdelete\r\nPage 2 of 4\n\nCleaning free space presents another challenge. Since FAT and NTFS provide no means for an application to\r\ndirectly address free space, SDelete has one of two options. The first is that it can, like it does for compressed,\r\nsparse and encrypted files, open the disk for raw access and overwrite the free space. This approach suffers from a\r\nbig problem: even if SDelete were coded to be fully capable of calculating the free space portions of NTFS and\r\nFAT drives (something that's not trivial), it would run the risk of collision with active file operations taking place\r\non the system. For example, say SDelete determines that a cluster is free, and just at that moment the file system\r\ndriver (FAT, NTFS) decides to allocate the cluster for a file that another application is modifying. The file system\r\ndriver writes the new data to the cluster, and then SDelete comes along and overwrites the freshly written data: the\r\nfile's new data is gone. The problem is even worse if the cluster is allocated for file system metadata since SDelete\r\nwill corrupt the file system's on-disk structures.\r\nThe second approach, and the one SDelete takes, is to indirectly overwrite free space. First, SDelete allocates the\r\nlargest file it can. SDelete does this using non-cached file I/O so that the contents of the NT file system cache will\r\nnot be thrown out and replaced with useless data associated with SDelete's space-hogging file. Because non-cached file I/O must be sector (512-byte) aligned, there might be some leftover space that isn't allocated for the\r\nSDelete file even when SDelete cannot further grow the file. To grab any remaining space SDelete next allocates\r\nthe largest cached file it can. For both of these files SDelete performs a secure overwrite, ensuring that all the disk\r\nspace that was previously free becomes securely cleansed.\r\nOn NTFS drives SDelete's job isn't necessarily through after it allocates and overwrites the two files. SDelete must\r\nalso fill any existing free portions of the NTFS MFT (Master File Table) with files that fit within an MFT record.\r\nAn MFT record is typically 1KB in size, and every file or directory on a disk requires at least one MFT record.\r\nSmall files are stored entirely within their MFT record, while files that don't fit within a record are allocated\r\nclusters outside the MFT. All SDelete has to do to take care of the free MFT space is allocate the largest file it can\r\n- when the file occupies all the available space in an MFT Record NTFS will prevent the file from getting larger,\r\nsince there are no free clusters left on the disk (they are being held by the two files SDelete previously allocated).\r\nSDelete then repeats the process. When SDelete can no longer even create a new file, it knows that all the\r\npreviously free records in the MFT have been completely filled with securely overwritten files.\r\nTo overwrite file names of a file that you delete, SDelete renames the file 26 times, each time replacing each\r\ncharacter of the file's name with a successive alphabetic character. For instance, the first rename of \"foo.txt\" would\r\nbe to \"AAA.AAA\".\r\nThe reason that SDelete does not securely delete file names when cleaning disk free space is that deleting them\r\nwould require direct manipulation of directory structures. Directory structures can have free space containing\r\ndeleted file names, but the free directory space is not available for allocation to other files. Hence, SDelete has no\r\nway of allocating this free space so that it can securely overwrite it.\r\n Download SDelete (328 KB)\r\nRuns on:\r\nClient: Windows 10 and higher.\r\nServer: Windows Server 2012 and higher.\r\nhttps://docs.microsoft.com/en-us/sysinternals/downloads/sdelete\r\nPage 3 of 4\n\nNano Server: 2016 and higher.\r\nSource: https://docs.microsoft.com/en-us/sysinternals/downloads/sdelete\r\nhttps://docs.microsoft.com/en-us/sysinternals/downloads/sdelete\r\nPage 4 of 4",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"ETDA",
		"MITRE"
	],
	"references": [
		"https://docs.microsoft.com/en-us/sysinternals/downloads/sdelete"
	],
	"report_names": [
		"sdelete"
	],
	"threat_actors": [
		{
			"id": "aa73cd6a-868c-4ae4-a5b2-7cb2c5ad1e9d",
			"created_at": "2022-10-25T16:07:24.139848Z",
			"updated_at": "2026-04-10T02:00:04.878798Z",
			"deleted_at": null,
			"main_name": "Safe",
			"aliases": [],
			"source_name": "ETDA:Safe",
			"tools": [
				"DebugView",
				"LZ77",
				"OpenDoc",
				"SafeDisk",
				"TypeConfig",
				"UPXShell",
				"UsbDoc",
				"UsbExe"
			],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775434020,
	"ts_updated_at": 1775791470,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/93687453fdfefd628d899533e887498fd4495bd7.pdf",
		"text": "https://archive.orkl.eu/93687453fdfefd628d899533e887498fd4495bd7.txt",
		"img": "https://archive.orkl.eu/93687453fdfefd628d899533e887498fd4495bd7.jpg"
	}
}