Malware and the Self-Deleting Batch File Method
Wednesday, January 1, 2014
Data destruction is an anti-forensic technique where data is deleted to limit the amount of forensic evidence left on a system. One data destruction anti-forensic technique leveraged by malware are self-deleting droppers and downloaders. The use of this technique can be seen in the Damballa paper Behind Today's Crimeware Installation Lifecycle: How Advanced Malware Morphs to Remain Stealthy and Persistent which outlines the malware installation lifecycle. In Windows, a program cannot delete itself so malware has to use other avenues to accomplish this. The article Self-deleting Executables: Techniques which allow an executable file to delete itself whilst running goes into detail about these avenues while the article ZeroAccess's Way of Self-Deletion discusses another one. A common avenue used by malware to limit the available forensic evidence is the self-deleting batch file method. If this method is used then there may be evidence of this activity in the Windows prefetch files and NTFS Change Journal.
The Catch22 Self-deleting Executables article discusses the self-deleting batch file method. The article states the method "works because MS-DOS batch files are able to delete themselves." All an executable has to do if it wants to delete itself is to create a batch file with code to delete its executable." Next the executable needs to spawn off the batch file using CreateProcess, and then should exit immediately". The batch script will proceed to delete the executable then itself. On a system this action removes valuable information about the infection vector.
To see how this method works I'll use the following Zbot sample MD5 0dc43fa765b042c13b51667e9c05d6e7. The image below shows the malware (bot.exe) creating a batch script named tmp1d2cc71c.bat.
The purpose of the tmp1d2cc71c.bat batch script is to delete the bot.exe executable and then to delete itself as shown in the image below. Notice the "if exist" statement creates a loop to force the bot.exe deletion.
Shortly after the tmp1d2cc71c.bat batch script creation the malware proceeds to launch a command prompt to execute the script.
Looking at the "Process Create" event details shows the command-line the malware used to start the command prompt.
The command prompt proceeds to load; one activity that occurs during process creation is the creation and/or reading of the command prompt prefetch file.
The command prompt uses the SetDispositionInformationFile function to delete the bot.exe file. The ZwSetInformationFile routine with the FileDispositionInformation parameter "sets the DeleteFile member of a FILE_DISPOSITION_INFORMATION to TRUE, so the file can be deleted when ZwClose is called to release the last open handle to the file object." In other words, the bot.exe file gets deleted when it is closed. The images below show this event in process monitor and the properties of this event where the DeleteFile member is set to True.
Remember the "if exist" statement in the batch script? The image below shows cmd.exe checking to see if the bot.exe exists. The result is "no such file" so the script exits the loop and continues its execution.
Again, the command prompt uses the SetDispositionInformationFile function to delete the tmp1d2cc71c.bat batch script before it exits.
The self-deleting batch file method used by downloaders and droppers limits the amount of forensic evidence left on a system. Specifically, it removes the downloaders and droppers themselves so they can't be analyzed in a method similar to the process above. However, this method leaves traces on a system to help determine that this method was used. I've seen these traces numerous times left in the Windows prefetch files and the NTFS Change Journal.
Windows prefetch files contain file paths to the files accessed when the application was starting. Sometime ago Harlan touched on this in his post Prefetch Analysis, Revisited...Again... and I did as well in my post Second Look at Prefetch Files. Traces of the self-deleting batch file method may be left in the command prompt (cmd.exe) prefetch file; this is usually my first indication that this method was used.
Again, let's illustrate this with the Zbot sample MD5 0dc43fa765b042c13b51667e9c05d6e7. The image below shows some suspicious executables (bot.exe and anku.exe) prefetch files followed by a modification to the cmd.exe prefetch file. Note: the modification to the cmd.exe prefetch file may not always align with the malware prefetch files if the command prompt has been used since the initial infection.
The indication that the self-deleting batch file method was used are references to batch scripts located in temporary folders. Looking closer at the cmd.exe prefetch file - as shown below - contains a reference to the tmpccc11cdb.bat batch script which is located in the temp folder.
The NTFS Change Journal ($UsnJrnl) contains a wealth of information about file system activity which can provide more context about what occurred on a system. I discussed the importance of this artifact in the post Re-Introducing $UsnJrnl and I even showed how it can help identity the self-deleting batch file method. The $UsnJrnl can help provide more context about the tmpccc11cdb.bat batch script found in the cmd.exe prefetch file.
The image below shows how the $UsnJrnl recorded the creation of the malware with the file name bot.exe.
The $UsnJrnl even records activity for other malware that gets dropped onto the system such as for the executable anku.exe as shown below.
The image below shows the traces of the self-deleting batch file method in the $UsnJrnl. First the batch script (tmpccc11cdb.bat) is created which is followed by the deletion of an executable (bot.exe) and the batch script itself (tmpccc11cdb.bat).
When we are confronted with systems impacted by malware it is a given we will encounter numerous anti-forensics techniques. Most likely we will see less forensic evidence left on a system due to data destruction. As the Locard's exchange principle states when two objects come into contact, something from one is exchanged to the other. This principle applies to anti-forensics and traces of this activity may be left on the system. Together, prefetch files and the NTFS Change Journal can shed light on the activity for the self-deleting batch file method.
Self-Deleting Batch File Method
The Catch22 Self-deleting Executables article discusses the self-deleting batch file method. The article states the method "works because MS-DOS batch files are able to delete themselves." All an executable has to do if it wants to delete itself is to create a batch file with code to delete its executable." Next the executable needs to spawn off the batch file using CreateProcess, and then should exit immediately". The batch script will proceed to delete the executable then itself. On a system this action removes valuable information about the infection vector.
To see how this method works I'll use the following Zbot sample MD5 0dc43fa765b042c13b51667e9c05d6e7. The image below shows the malware (bot.exe) creating a batch script named tmp1d2cc71c.bat.
The purpose of the tmp1d2cc71c.bat batch script is to delete the bot.exe executable and then to delete itself as shown in the image below. Notice the "if exist" statement creates a loop to force the bot.exe deletion.
Shortly after the tmp1d2cc71c.bat batch script creation the malware proceeds to launch a command prompt to execute the script.
Looking at the "Process Create" event details shows the command-line the malware used to start the command prompt.
The command prompt proceeds to load; one activity that occurs during process creation is the creation and/or reading of the command prompt prefetch file.
The command prompt uses the SetDispositionInformationFile function to delete the bot.exe file. The ZwSetInformationFile routine with the FileDispositionInformation parameter "sets the DeleteFile member of a FILE_DISPOSITION_INFORMATION to TRUE, so the file can be deleted when ZwClose is called to release the last open handle to the file object." In other words, the bot.exe file gets deleted when it is closed. The images below show this event in process monitor and the properties of this event where the DeleteFile member is set to True.
Remember the "if exist" statement in the batch script? The image below shows cmd.exe checking to see if the bot.exe exists. The result is "no such file" so the script exits the loop and continues its execution.
Traces of the Self-Deleting Batch File Method
The self-deleting batch file method used by downloaders and droppers limits the amount of forensic evidence left on a system. Specifically, it removes the downloaders and droppers themselves so they can't be analyzed in a method similar to the process above. However, this method leaves traces on a system to help determine that this method was used. I've seen these traces numerous times left in the Windows prefetch files and the NTFS Change Journal.
Prefetch Files
Windows prefetch files contain file paths to the files accessed when the application was starting. Sometime ago Harlan touched on this in his post Prefetch Analysis, Revisited...Again... and I did as well in my post Second Look at Prefetch Files. Traces of the self-deleting batch file method may be left in the command prompt (cmd.exe) prefetch file; this is usually my first indication that this method was used.
Again, let's illustrate this with the Zbot sample MD5 0dc43fa765b042c13b51667e9c05d6e7. The image below shows some suspicious executables (bot.exe and anku.exe) prefetch files followed by a modification to the cmd.exe prefetch file. Note: the modification to the cmd.exe prefetch file may not always align with the malware prefetch files if the command prompt has been used since the initial infection.
The indication that the self-deleting batch file method was used are references to batch scripts located in temporary folders. Looking closer at the cmd.exe prefetch file - as shown below - contains a reference to the tmpccc11cdb.bat batch script which is located in the temp folder.
NTFS Change Journal
The NTFS Change Journal ($UsnJrnl) contains a wealth of information about file system activity which can provide more context about what occurred on a system. I discussed the importance of this artifact in the post Re-Introducing $UsnJrnl and I even showed how it can help identity the self-deleting batch file method. The $UsnJrnl can help provide more context about the tmpccc11cdb.bat batch script found in the cmd.exe prefetch file.
The image below shows how the $UsnJrnl recorded the creation of the malware with the file name bot.exe.
The $UsnJrnl even records activity for other malware that gets dropped onto the system such as for the executable anku.exe as shown below.
The image below shows the traces of the self-deleting batch file method in the $UsnJrnl. First the batch script (tmpccc11cdb.bat) is created which is followed by the deletion of an executable (bot.exe) and the batch script itself (tmpccc11cdb.bat).
Wrapping Things Up
When we are confronted with systems impacted by malware it is a given we will encounter numerous anti-forensics techniques. Most likely we will see less forensic evidence left on a system due to data destruction. As the Locard's exchange principle states when two objects come into contact, something from one is exchanged to the other. This principle applies to anti-forensics and traces of this activity may be left on the system. Together, prefetch files and the NTFS Change Journal can shed light on the activity for the self-deleting batch file method.
Labels:
antiforensics,
malware,
malware analysis
Posts
Great post, Corey! This is exactly why I recommend the addition of intel to tools!
What tools were used to analyze the prefetch and change journal?
Excellent write-up!
@Kevin,
I parsed the prefetch files with Nirsoft Winprefetchview
http://www.nirsoft.net/utils/win_prefetch_view.html
I parsed the NTFS Change Journal with TZWorks Windows Journal Parser with the csvl2t output to put it into a timeline
https://www.tzworks.net/prototype_page.php?proto_id=5
I also use usnjrnl2csv to parse the Change Journal (this one is open source)
https://code.google.com/p/mft2csv/wiki/UsnJrnl2Csv
Excellent post, Corey!
KP