$Secure:$SDS security descriptors

What it is

Since NTFS 3.0 (Windows 2000), security descriptors are no longer stored in each file's MFT record. They are deduplicated into a single system file, $Secure (MFT record 9), and each file only stores a 32-bit Security ID in its $STANDARD_INFORMATION attribute. $Secure has three parts:

• $SDS (data stream): the security descriptors themselves, each with its hash, Security ID and offset.
• $SII (index): maps a Security ID to the descriptor's offset and size in $SDS.
• $SDH (index): maps a descriptor hash to its offset, so NTFS can reuse an existing descriptor instead of storing a duplicate.

For an investigator, $SDS is how you answer "who owns this file and who could access it" from a disk image, without mounting the volume and asking Windows.

Location

$Secure is both a file (it has a $DATA stream) and a directory-like object (it has index attributes), which confuses some glob-based collectors. Collected copies are usually named $Secure_$SDS.

What it proves

• Ownership: the owner SID of any file whose Security ID you know from the $MFT. Resolve the SID to an account with the SAM or domain data.
• Permissions: the DACL (who may read, write, execute) and the SACL (auditing) that applied to the file.
• Unusual access control: files with explicit "Everyone full control" ACEs, or files owned by a user account in system folders.
• It does not prove that the owner created or opened the file. Ownership can be taken or changed, and files written by elevated or system processes are often owned by Administrators or SYSTEM rather than the logged-on user. There are no timestamps in $SDS.

Key fields

Timestamps

Retention and clearing

• One descriptor serves every file with the same owner and ACL, so the stream holds far fewer entries than the volume has files.
• Changing a file's owner or ACL gives it a different Security ID (an existing matching descriptor or a new one); the old descriptor stays in the stream if other files still use it.
• A deleted file's MFT record keeps its Security ID, so you can still attempt to look up the owner from $SDS.
• There is no user command to clear $SDS; it is rebuilt only by reformatting the volume.

Collection

• KAPE target: $SDS (collects $Secure:$SDS; also part of FileSystem)
• Velociraptor (Windows.Triage.Targets): $SDS. The dedicated Windows.Triage.SDS artifact uploads the stream by reading MFT record 9 directly, which avoids the glob issue mentioned above.
• Built-in: $SDS is not readable through the Windows API. On a live system, Windows can still tell you the current owner and ACL of a given file, which is useful to compare with offline results:

Get-Acl C:\Users\Public\tool.exe | Format-List Owner,AccessToString
icacls C:\Users\Public\tool.exe
cmd /c dir /q C:\Users\Public

Parsing tools

• MFTECmd (Eric Zimmerman): MFTECmd.exe -f E:\C\$Secure_$SDS --csv E:\out lists every descriptor with Id, owner and group SIDs, control flags and ACE counts and types. --ds 0x100 dumps one Security ID in full. Join the Id column with the SecurityId column of the MFTECmd $MFT output.
• Velociraptor: Windows.Triage.SDS to collect the stream from live endpoints for offline parsing.

Investigation tips

• For each suspicious file in the $MFT output, take its SecurityId, look up the owner SID in the $SDS CSV, then map the SID to a user profile: a quick way to attribute dropped tools to an account.
• Group files by Security ID: a malware folder where every file shares an unusual descriptor (for example owned by a standard user inside C:\Windows) stands out.
• Look for descriptors granting write access to Everyone, Users or Authenticated Users on executables or service binaries: a sign of weakened permissions used for persistence or privilege escalation.
• Date ACL tampering with SECURITY_CHANGE records in the USN journal.
• USN journal records also carry a SecurityId, so files seen only in the journal (already deleted, see $I30 slack for more names) can still be tied to an owner.