qwertyuiopasdfghjklzxcvbnmqwertyui opasdfghjklzxcvbnmqwertyuiopasdfgh jklzxcvbnmqwertyuiopasdfghjklzxcvb nmqwertyuiopasdfghjklzxcvbnmqwer tyuiopasdfghjklzxcvbnmqwertyuiopas Live Forensic Analysis dfghjklzxcvbnmqwertyuiopasdfghjklzx Searching for Altered and Unaltered cvbnmqwertyuiopasdfghjklzxcvbnmq

Encrypted Volume wertyuiopasdfghjklzxcvbnmqwertyuio 1/5/2014 pasdfghjklzxcvbnmqwertyuiopasdfghj Donald Cinco klzxcvbnmqwertyuiopasdfghjklzxcvbn mqwertyuiopasdfghjklzxcvbnmqwerty uiopasdfghjklzxcvbnmqwertyuiopasdf ghjklzxcvbnmqwertyuiopasdfghjklzxc vbnmqwertyuiopasdfghjklzxcvbnmrty uiopasdfghjklzxcvbnmqwertyuiopasdf ghjklzxcvbnmqwertyuiopasdfghjklzxc vbnmqwertyuiopasdfghjklzxcvbnmqw ertyuiopasdfghjklzxcvbnmqwertyuiop

The aim of this paper was to emphasize that crimes are occurring everyday in the digital world and cyber criminals are advancing their tools and tricks making it difficult for the forensic examiner to discover the evidence files. Perpetrators are becoming more knowledgeable by using a variety of tools and techniques to avoid detection. In fact this is becoming a growing challenge. Within the last decade the overall cyber crime scene has revolutionized significantly, with perpetrators developing more modern techniques and broader skills in technology. With todays technology forensic examiners must always be on top of their game. With that being said, digital forensics examiner must know the limits of their tools and their capabilities. Due to the fact that not all the tools in their arsenal would give them the results that they are seeking. A digital forensic examiner must always think outside the box. All investigations are not the same, what worked for you the last time might not work for you this time. What you are about to read is based on demonstrations only. By no means am I not suggesting what tools to use and what not to use. Before I start I would like to mention that in this demonstration I have tested several forensic tools, commercial and open source. This demonstration is based on several forensic tools not being able to collect all the evidence and how a perpetrator can hide their evidence. There are many ways a perpetrator can hide the file/s inside the system i.e., binding files together or just simply locking it with zip/rar. The question is what you would do if you ever came across this situation. You may have heard that several forensics programs are now claiming that they can detect or find encrypted disk volume and decrypt the password of an encrypted disk, mainly used by encryption programs such as TrueCrypt, PGP and Bitlocker. Being an inquisitive minded individual, I went online and searched for an open source tool that could detect an encrypted disk volume. I found EDD (Encrypted Disk Detector), I downloaded it and I wanted to see if this would really discover my hidden partition inside my flashdrive. The first thing I noticed EDD is easy and simple to use. I think it is a good tool for detecting encrypted disk volume and best of all, it is free. To my enthusiasm I inserted my flashdrive to my desktop with a TrueCrypt encrypted partition, as soon as my desktop recognized my flashdrive I then executed EDD to see if it would detect the encrypted volume inside my flashdrive. In a matter of seconds I have the results in front of me, See Fig. 1.

Fig. 1

As you can see in Fig. 1 as I started the EDD.exe it revealed that there is an encrypted volume in my flashdrive. By looking at the image you can see where EDD discovered the encrypted volume, it is located at Physicaldrive5 partition 1 with an OEM ID: bMI and at the bottom it says Encrypted volumes and/or processes were detected by EDD. Pretty good tool if you ask me, the tool definitely made it easier for a digital forensic examiner to discover encrypted volumes, used by encryption programs when doing a live analysis. Furthermore, what if we are dealing with someone who really knows they are doing to avoid detection? What if I tell you that I can make TrueCrypt encrypted

volume undetected from EDD? Can it be done? Is it possible? Absolutely! You have to understand how EDD works and how it looks for the signature. Anyone who understands reverse engineering in digital forensics knows it is not that difficult to achieve. If a perpetrator would like to hide the encrypted volume, they can simply copy the whole encrypted sector volume and hide it anywhere where it would be hard to find. When the perpetrator is ready to mount it, they can easily go back where they hid it and restore it back to any harddrive or flashdrive. Before I explain how it can it be restored let us look at fig. 2, this is a sample of a modified header making it undetected to EDD, PASSWARE FORENSIC KIT and ELCOMSOFT FORENSIC DISK DECRYPTOR. Fig. 2

After modifying the TrueCrypt header with hex editor and running the EDD, we can see that EDD is unable to detect the encrypted volume in fig. 2. To move on, the next tool I will use is a Passware Forensic Kit, to see if this tool can detects the TrueCrypt volume in my flashdrive (I:), See fig. 3.

Fig. 3

To begin I set the Passware Forensic Kit, checking the scan for encrypted containers and disk images including the (I:) where TrueCrypt disk resides. I then hit the search button and in just a matter of minutes, it gave me the results. See fig. 4

Fig.4

Again no hit, the Passware Forensic Kit did not detected the TrueCrypt encrypted volume in our flashdrive partition. Though, the Passware has other options. You can use memory attack analysis by dumping the RAM memory and creating an image of the flashdrive using FTK imager. Before we do all that, we need to open our TrueCrypt volume and possibly cache our passwords in our RAM memory, unchecked the never save history. Note: in this demonstration we will be using unaltered TrueCrypt volume, see fig. 5

Fig. 5

Now that we deliberately cache the password, leaving traces in our RAM memory and leaving the bottom box un-checked in Never save history. Next I mounted the TrueCrypt encrypted volume, see fig. 6.

Fig. 6

After entering the password and selected the correct partition, we now can access the Z-drive volume. See fig. 7

Fig. 7

As you can see we now have access to the TrueCrypt volume, I expected the password to stay in the RAM. I will now closes the TrueCrypt volume and start with memory dump and image the flash drive using FTK Imager. I hope we can capture the password from there. First, I will run DumpIt to dump what is in the memory, see fig 8. Fig. 8

Finally, I have all the files I need. The raw image RAM memory using DumpIt, the logical image file of the flashdrive, the pagefile.sys and memdump.mem using FTK imager see fig. 9. Next we will start the Passware Forensic Kit to do a memory attack analysis and perceive if we can recover the password from the RAM. This is not a long process, I have a 16 GB. Of memory so it should only take me minutes to get the results.

Fig.9

The files showing in fig. 9 are some of the files we will be using to recover the password that resides in the RAM memory, if there is any. In this demonstration we will be using the Passware Forensic Kit memory attack analysis option. After loading all the necessary files for memory attack analysis, we will execute the program and awaits if we can find traces of the password in RAM, see fig. 10 Fig. 10

The process should take less than 4 minutes, but again that depends on how big the RAM file you have acquired. In less than 4 minutes we should have the results. Again no password found in the RAM memory dump, after using the pagefile.sys, see fig. 11. We loaded the memdump.mem and the memory dump raw file from FTK imager and DumpIt. The results are the same, no password found. Fig. 11

The next tool we will use is the Elcomsoft Forensic Disk Decryptor. We will be using the same RAM memory dump that we acquired earlier using DumpIt and FTK imager. I hope we can find progress using Elcomsoft.

Fig. 12

In fig. 12 we will use the first option Decrypt or mount disk by providing memory image or encryption keys. Next, tick the TrueCrypt (encrypted disk), click next then click Select tab and choose the drive where the TrueCrypt volume resides. Which in this case ours is in I:\ drive. In select source of keys, I use the memdump.mem, and then click next and it should start searching the memory file and the flashdrive.

Fig. 13

After less than an hour, Elcomsoft Forensic Disk Decryptor failed to find the passwords even though we provided it with a memory dump and the TrueCrypt volume. So far we have no hits, we are unable to retrieve the password in RAM memory and the tools we used failed to recover traces of any password. We did not use any keys because we only want to use the password for the demonstration purpose only. The real questions are, why did we failed to recover the password and the encrypted disk volume during live acquisition? Why did we not recover any clear text password in raw memory dump? Where can we recover the TrueCrypt volume if there is no partition showing in the Flashdrive or Harddrive? Confronted with this kind of drawbacks during live acquisition, makes it only difficult for the examiner, leading to halting the analysis and most importantly jeopardizing the investigations. However, this is not a dead end for us; we just have to be a little creative. First we need to know why our tools are not detecting anything. Though, we know that there is a hidden encrypted disk volume in the system. Second, why is it we are not seeing any password cache in our live memory acquisition? What are we dealing with? Does the system use security tools that defeat our tools? Is there anything configured in the system that hinders us to acquire the evidence? If there is no sign of encrypted hidden volume where is it? Could the perpetrator have an encrypted

volume backup hidden somewhere in the system? These are the things that we need to ask ourselves. Now that we have all the questions in our hand, we can start looking for all the answers and find out why we are not getting any results. First, we need to look at the pagefile.sys and hiberfil.sys, to see if our suspicions are true. Let's say we run the regedit and search the HKLM\SYSTEM\CurrentControlSet\Control\FileSystem\NtfsEncryptPagingFile ( 1 ) and discover it was enabled, and then we know the pagefile.sys is encrypted and no sign of hiberfil.sys in the system means its turned off or deleted. Second, we need to know what security programs are installed on the system. Let's presume that we have discovered that the system has a KeyScrambler installed. We need to know how the KeyScrambler is protecting the system. By going to the KeyScrambler website we can find out the features of this program. According to their website KeyScrambler begins encrypting your keystrokes in real time at the keyboard driver level. Because KeyScrambler is located in the kernel, deep in the operating system, bypassing KeyScrambler's encryption is difficult. Now we know why our tools are ineffective to find the cache password in raw memory dump or pagefile.sys due to KeyScrambler is replacing the clear text with random keys and NtfsEncryptPagingFile is enabled, that is our drawbacks. In the beginning I demonstrated on how to bypass the EDD on detecting encrypted disk volume. In some cases, some users would not keep the encrypted disk volume in the harddrive partition or in a flashdrive, particularly if they are hiding an important data that could get them in trouble. Most likely the perpetrator would try to create a diversion and try to outsmart the digital forensic examiner by joining the encrypted volume with another file or renaming the extension file with some random extension. Since we could not find what we were looking for, we will use a different route to search for an encrypted disk volume and maybe we can locate the backup encrypted volume and perhaps copy the file volume for later examination. To search all the files in the system I will use file search assuming we dont know where the file/s are. To start we will search for images and audio files see fig. 14.

Fig. 14

The time to finish the searching depends on how many extension files you are searching for at the same time and how many images are in the system. However, I do think it should give you a good speed, since it took me less time than what I expected. After a couple of minutes our search is done, we now have all the images in front of us and the next thing to do is sort each file and look for a conspicuous file that might give us a clue.

Fig. 15

After thoroughly searching the images, I found something very unusual in one of the image named pie chart.jpg, with MD5 hash a41218be33eebf1b3b4bb56c4e4dd4a9 see fig 15. I noticed the file is larger than normal, so I went to check the file and try to open it. Though, it viewed like any normal photo I was suspicious about this image. I needed to find more clues before I could say this was the break we needed. There are many ways to do this but we do not have any clues on what to look for. Either we use the hex editor to view what is inside the image file or we can take the screenshot of the photo and find out what is the real size of the file image and dimensions. Next we need to locate the true source of this photo to see if the perpetrator is somewhat hosting/owning the website. The more information we can find the better for our investigations, beside what can go wrong? To search for photos similar to the photo we are investigating, I go to Tineye.com. There I upload the screenshot that I took from the suspicious image and I expect to get a hit and find as much information that we need to solidify our investigations. After submitting it, I got a hit and found 3 similar images. One looks exactly the same with the same dimensions. Now we have an idea on how big the original file is and where the original source of the photo image came from, see fig. 16.

Fig. 16

After comparing the images it looks exactly the same with the same dimensions. There is no doubt in my mind that the perpetrator copied it from the website. However, I do not see the perpetrator being related to the website where they copied it from. After enumerating the website I found no evidence that the website belonged to the perpetrator. This is somewhat a random internet photo download. Now that we have

the answer to where the photo image was originated, it is time to examine the photo image pie chart.jpg itself. Normally I would employ hex editor to search the file, but since I do not know what is inside the image I will not do that. We know it's a large file so I figured I needed to make this a search that would give us answers to our investigation immediately. Using the open source File Analysis, which is a deep file testing tool that reveals and translates several file formats within the file structure that holds data, we start to run the program and export the image file pie chart.jpg waiting for the program to finish scanning. As soon as the program has finished scanning, click the JPEG Image Data it should show the image on the top right side. Then click the Goto >> Format End it will take you to the end file of the image pie chart.jpg anything below it, is the added file or joined to the jpg image, see fig. 17. Fig. 17

Now that was easy. If you noticed at the end of the image file, we found another file which is a Rar file, with a file name 12312013.exe. We are now certain that the .jpg file has another file inside. The next thing we will do is to fire up our HxD and export

the pie chart.jpg. Now that we know what to look for, we will go to search box and type Rar. It should take us to the rar text. Anything above the rar we can delete it, so we can reconstruct the rar file for further examination, see fig. 18 Fig. 18

Now that we kept only what we needed we should be able to reconstruct the rar file without any issues and hopefully we can find more information in regard to what we are looking for, see fig. 19

Fig. 19

Our next step is to save the file using HxD, click File >>Save as, to which ever name you prefer. For our demonstration we would name the file to pie chart.rar with MD5 hash a41218be33eebf1b3b4bb56c4e4dd4a9. By now we should have the save rar file completed. Next double click the rar file to make sure there are no messages of corruption, if there are none, which means our file is intact see fig. 20. Fig. 20

If everything seems to be working flawless, than we have extracted the file hidden inside the image file. The next step is to open the pie chart.rar by extracting it and we should be able to know more about the file was hidden from us. After extracting the pie chart.rar we now have the file 12312013.exe file with MD5 hash 2e7e6df74e462989fe3e34fe7dd8669b. Once again we will use the HxD hex editor to examine the 12312013.exe file to see what we can find, see fig. 21 Fig. 21

From what we can see in fig. 21 it seems that all of the texts are encrypted. It looks like we are headed in the right direction. Remember, we are looking for a TrueCrypt volume partition; it seems we have found it. The next thing we will do is to find the password. Note: this may make or break your case. However, if we manage to break the password all information is open to us, and we can use that against the perpetrator. To start password breaking we can use Passware Forensic Kit or any brute forcing tools that you prefer. For the sake of this demonstration we will use the tool called OTFBrutusGUI, we can use a dictionary file or password pattern (bruteforce attack). I do suggest using a brute force tool that you are familiar and comfortable with, since you are the one who will be sitting at your desk for a while. Use what works for you. This is the third most important part of password breaking. Second is to have a huge wordlist/dictionary files in your arsenal and first is persistence. Now lets begin breaking the password.

Fig. 22

Setting up the OTFBrutusGUI is pretty self explanatory, see fig. 22. We selected the file 12312013.exe because we know it has TrueCrypt Volume. Next we selected password pattern using [a-z]{9-9} and leave the default check boxes and hit start. This should brute force the volume file and should give us the access to the encrypted disk. Many hours and days later OTFBrutusGUI managed to break the password, see fig. 23.

Fig. 23

Success! We now have access to the TrueCrypt normal volume. Though, we are not done yet because we all know that anyone who uses TrueCrypt also creates a hidden volume inside the normal volume using only the normal volume as a decoy. The process is the same when breaking the password of the hidden volume. The only difference is changing the setting Volume Type to Hidden instead of Standard and hit start.

Now that I demonstrated how to find unaltered encrypted volume, this time I will explain the difference in altered/modified encrypted volume to unaltered encrypted volume. We all know that in unaltered encrypted volume we can bruteforce the Standard Volume and Hidden Volume. However, altered/modified TrueCrypt volumes we cannot recover the password, due to fact that the header was modified, see below image. Fig. 24

Using the altered/modified TrueCrypt volume, to see if we can open the standard volume with supplying the correct password.

Fig. 25

We got a response of Incorrect password or not a TrueCrypt volume. Remember what I said earlier the perpetrator can create a diversion making you think the volume is not a TrueCrypt volume file. But if we try the OTFBrutusGui and set it to bruteforce the hidden volume, then this might be a game changer. In this demonstration I will use a dictionary file to speed up the process, since the whole idea was to know the difference of altered and unaltered TrueCrypt volume, see fig. 26

Fig. 26

There we managed to brute force the hidden volume. Although as much as we think this is the only hidden volume we must also consider that this can be added with another hidden and more hidden volume to set back our investigations. In conclusion, we all know that digital forensic technology software offers a huge advantage of support when it comes to searching, acquisition, recovery, reporting, etc.

Most digital forensic software has tools that can help any digital forensic examiners when it comes to analysis and investigations. However, it is not full proof because there is always an exception that has nothing to do with the forensic software. The limitations are dictated by the nature of human comprehension itself. That being said, this exploration highlights the problems that forensic professionals are dealing with which correlate the growing occurrence and functionality of solid encryption methods. In the same way that solid encryption is often successfully utilized to defend against accidental data leaks, this can also be applied by perpetrators to conceal clues of their unlawful acts. Breaking encryption passwords requires much patience, learning from mistakes, and understanding. There is absolutely no single definite route of retrieving the passwords that is going to work on nearly every system. Before seeking out these approaches, run it first on a controlled environment. Finally, we have described the stages needed to carry out the steps in finding encrypted disks volume. I must say that the sting of encryption can be eased with persistence.

Donald Cinco CEH, CHFI, ECSA, LPT, Linux +, Investigating High-Tech Crime, Internet Forensics, Computer Forensics, Network Security Management, Advanced Computer Forensics, GPS and Mobile Forensics, MCITP/MCTS Window Workstation OS 8, MCITP/MCTS Window Server OS 2012, Intro to Electronic Crime, Digital Crime Investigation, CCNA, Comptia A+