Unwrap Your Malware
Updated: Oct 4, 2017
*This blog entry was originally published on June 23, 2015 on the original Polito Blog. It was re-posted on October 3, 2017 due to migrating to a new blog platform.
Intro to Wrappers
Wrapped files have a script or executable in their body, which they drop and run upon execution; e.g., an EXE file drops a batch script in the case that follows. Typically wrappers (EXE converters) create EXE files from Python scripts, batch scripts, AutoIt scripts, and JAR files. Wrapping is used as a mild form of obfuscation because the script or executable to be wrapped is usually encoded or encrypted within the resulting file, which can aid in bypassing antivirus.
Wrapped files often use the %TEMP% folder to drop the file, execute the dropped file, and then delete it. The biggest challenge for analysts is that the dropped file usually gets deleted before they can copy it. I’ll go through some basic ways to circumvent this situation with and without OllyDbg.
The easiest, but less reliable solution to our problem is simply changing the permissions of the folder where the file is dropped. Instructions for doing so on Windows 7:
Right-click the folder, click on Properties
Click on the Security tab
If the Security tab is not present, you need to go to the folder options and uncheck "Use simple file sharing"
In the Security tab, click Edit then Add
Enter "Everyone" into the object name box, click OK
Click on Advanced. Select "Everyone", then click on the Edit button
Place a checkmark in the deny column for "Delete" and "Delete subfolders and files".
Click OK until all windows are closed.
This is a quick way to get the job done, but it is not very reliable. This option will not work if the wrapper creates a temp file to unpack it, then deletes the temp file and creates a folder with the same name.
A second solution would be to create a batch file to intercept the wrapper before it executes. It would look something like this:
Figure 1: Batch script to intercept the wrapper. Replace <filename> with the name of the file. Photo: Author
You should run this script prior to executing your malware sample. The problem with this method is that you already have to know the name of the file you are going to intercept. If the malware sample creates a random name (which is common) then this method will fail and you will need to use a different method to obtain the file, such as modifying the script to copy all dropped files although that approach will likely also collect unrelated temporary files. The solutions above are quick if you already have all the information you need about the malware sample, but if you are analyzing malware samples from "the wild,” these solutions may be useless or require a lot of trial and error.
This is the hash for the sample I used in this analysis:
I take a look at the executable with a text editor first. There are two things that point to this being a wrapped file.
Plaintext in the executable hints to the use of a batch to EXE converter.
Antivirus detection contains BAT as a platform. (We can see this by running the sample through VirusTotal.)
The plaintext from the analyzed sample looks like this:
Figure 2: Plaintext from malware sample. Photo: Author
We have the plaintext now, but it is only part of the batch code, not the complete batch script that we want. It is time we run this malware sample in a lab environment for dynamic analysis.
Figure 3: Running the malware sample in a lab environment. Photo: Author
Running the sample in the lab we find that the desktop is not functional anymore: any attempts to open task manager or the command prompt will fail, and Windows Explorer disappears. Restarting the lab environment, we will run into the same situation after logging in. This is seemingly typical behavior for a system locker (ransomware), but there is no ransom message presented to us at all. This sample also makes any attempts to obtain the batch script more difficult. Having Process Explorer open, we will be able to kill the process that terminates the explorer.exe process. We will also be able to see that a batch file was created in a randomly named subfolder in the TEMP directory. This batch file disappears immediately after the execution of the malware sample.
Unwrapping Our Sample in OllyDbg
We start this on a fresh lab environment and open up our malware sample in OllyDbg. OllyDbg will break as usual at the entry point of the executable.
Note: Make sure you have created a snapshot of your lab environment before you start debugging.
Figure 4: Malware sample in OllyDbg. Photo: Author
The first thing this malware sample does before it executes the batch script is write a file to the TEMP directory. Knowing this we can set a breakpoint on WriteFile to halt before the file is written in the TEMP directory. OllyDbg will break in this area within kernel32 once we continue with the execution of the sample.
Figure 5: After adding the breakpoint in OllyDbg. Photo: Author
Looking at the registers, we can clearly see a reference to the batch string is in the EDX register.
Figure 6: Reference to the batch string in the EDX register. Photo: Author
We can right-click on the address (EDX 003B56B8) and follow this in dump.
Figure 7: Following the batch string reference we found in the EDX register. Photo: Author
The batch string will show up in the dump window.
Figure 8: Dump window in OllyDbg. Photo: Author
This is a good time to create a dump of the process. We can use Process Explorer to achieve this.
Figure 9: Using Process Explorer to create our dump. Photo: Author
Now we can open the memory we dumped in a hex editor and search for the beginning of the batch file. Search for "echo off" in ASCII as this will help get you to the beginning of the batch file quickly.
Figure 10: Beginning of the batch file in the hex editor. Photo: Author
From here we can copy and paste the batch file string to a new file. We now have the entire batch script from our sample. We can then open the script in a text editor like Notepad++ and review the script.
Figure 11: The malicious batch script in Notepad++. Photo: Author
This sample turns out to be a complete fail. It is definitely intended to be a system lock (ransomware), but it will never show a ransom note because the command prompt is disabled and the random message is set to be shown in the command prompt.
OllyDbg is a great tool to use when you are analyzing samples from the wild and need to unwrap EXE converters. The other methods shown tend to only help if you already have all the pieces to the puzzle and are not as reliable without preexisting knowledge of the sample you are analyzing.
Polito, Inc. offers a wide range of security consulting services including penetration testing, vulnerability assessments, incident response, digital forensics, and more. If your business or your clients have any cyber security needs, contact our experts and experience what Masterful Cyber Security is all about.