Forensic Detection of Files Deleted via SDelete


Russian nation-state adversaries abuse the tool “sdelete” to perform file deletion of their attack files. Sdelete is still being used by IRON HEMLOCK (APT29) in 2022 as a part of defence evasion. The tool “sdelete” was created by Mark Russinovich and is used to securely prevent files from being recovered through deleting the file and overwriting the file data in unallocated portions of the disk. What's annoying about this tool is it shows artefacts with overwritten filenames "AAAAAA.AAA" instead of the original name.

This is a quick forensics write-up demonstrating that you can in fact, recover the original file names from analysis of $J. 

DETECTION METHODOLOGY

When sdelete is utilised, it leaves obvious traces in the USN Journal, $J file where 26 unique entries will be created in alphabetic order as pictured below. This is a dead giveaway that “sdelete” was utilised by the threat actors.


The best way to review the $J file is to parse by the Entry Number. This corresponds to the same number in the original MFT entry which will be created when the file is first created on disk. Please note, in the case where sdelete is utilised, the MFT record will likely be overwritten by another file (on busy disks).  

When you filter by the entry number, you will see the original file name that the threat actors utilised (pictured below). 


This is the methodology for analysing $J for the files deleted via “sdelete”:

1. Determine “sdelete” was utilised on the host
This can be done by looking at a series of artefacts of execution OR through analysis of $J and noting 26 alphabetical files created with the same timestamp corresponding to the operations:
  • RenameNewName / RenameNewName | Close
  • RenameOldName
2. Filter by the EntryNumber 
This is to make sure you are looking at the $J entries that map to the same file ;)

3. Determine the original file name
These will be listed under the following $J update operations:
  • FileCreate / FileCreate | Close
  • ObjectIDChange / ObjectID | Close
  • DataExtend | Close
  • DataOverWrite | Close
4. Check prefetch files  
If this is a workstation and the corresponding prefetch files haven’t been removed, this will also reveal the original file name:



What about $I30?
One question you might have is … what about filename artefacts that might be left in the directory file entry slack space? Typically, this is a good detection for other file wipers, but when I tested this and reviewed slack space and parsed out the $I30, this file had been fully purged #notUwU

References:

Comments

Post a Comment

Popular posts from this blog

Forensic Analysis of AnyDesk Logs

Image
Most threat actors during ransomware incidents utilise some type of remote access tools - one of them being AnyDesk. This is a free remote access tool that threat actors download onto hosts to access them easily and also for bidirectional file transfer.  There are two locations for where AnyDesk logs are stored on the Windows file system: %programdata%\AnyDesk\ad_svc.trace %appdata%\Anydesk\ad.trace The AnyDesk logs can be found under the appdata located within each users' directory where the tool has been installed. Forensic analysis of these logs reveal interesting pieces of information inside the "ad.trace" log: Remote IP where the actor connected from File transfer activity Locating the Remote IP Connecting to AnyDesk Inside the "ad.trace" log you can grep for the following term "External address" and this should reveal the following line pasted below. I have redacted the IP for privacy's sake: info 2021-02-04 23:25:10.500       lsvc   9988  
Read more

How to Reverse Engineer and Patch an iOS Application for Beginners: Part I

Image
So you want to reverse and patch an iOS application? I got you >_< If you’ve missed the blogs in the series, check them out below ^_^ Part 1: How to Reverse Engineer and Patch an iOS Application for Beginners Part 2: Guide to Reversing and Exploiting iOS binaries: ARM64 ROP Chains Part 3: Heap Overflows on iOS ARM64: Heap Spraying, Use-After-Free  This blog is focused on reversing an iOS application I built for the purpose of showing beginners how to reverse and patch an iOS app. No fancy tools are required (IDA O.o), it's just you, me & a debugger <3 The app is a simple, unencrypted Objective-C application that just takes in a password and the goal of this is to bypass the password mechanism and get the success code. This blog post will focus on reversing/debugging the application and will not cover aspects of static analysis. The reason I wanted to write this is because I realised this topic is confusing for a lot of people and I wanted to try and write a blog that a
Read more

Successful 4624 Anonymous Logons to Windows Server from External IPs?

Image
If you see successful 4624 event logs that look a little something like this in your Event Viewer showing an ANONYMOUS LOGON, an external IP (usually from Russia, Asia, USA, Ukraine) with an authentication package of NTLM, NTLMSSP, don't be alarmed - this is not an indication of a successful logon+access of your system even though it's logged as a 4624. If your server has RDP or SMB open publicly to the internet you may see a suite of these logs on your server's event viewer. Although these are showing up as Event ID 4624 (which generally correlates to successful logon events), these are NOT successful access to the system without a correlating Event ID 4624 showing up with an Account Name \\domain\username and a type 10 logon code for RDP or a type 3 for SMB. You can double check this by looking at 4625 events for a failure, within a similar time range to the logon event for confirmation. The reason for this is because when a user initiates an RDP or SMB c
Read more