Forensic Data Solutions® 

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

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:

DetectionName=W32/Conficker.worm

DetectionType=0

EngineMajor=5200

EngineMinor=2160

DATMajor=8208

DATMinor=0

DATType=2

ProductID=12024

CreationYear=2016

CreationMonth=6

CreationDay=27

CreationHour=8

CreationMinute=24

CreationSecond=43

ComputerName=Redacted

UserName=Redacted

NumberOfFiles=2

NumberOfValues=0

[File_0]

OriginalName=c:\documents and settings\<User>\local settings\temporary internet files\content.ie5\g9az81mv\vcezd[1].gif

[File_1]

OriginalName=c:\windows\system32\imxrkp.dll

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.

XOR Process

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

Avira is another anti-virus program that stores the quarantined files in an “INFECTED” folder at the following location:

C:\ProgramData\Avira\Antivirus\INFECTED\

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.

Happy hunting.