49 20 6b 6e 6f 77 20 73 6f 6d 65 74 68 69 6e 67 20 62 75 74 20 49 20 64 6f 6e 27 74 20 63 Live Forensic Analysis 6c 61 69 6d 20 74 6f 20 6b 6e Searching for Altered and Unaltered 6f 77 20 65 76 65 72 79 74 68 Encrypted Volume 1/5/2014 69 6e 67 49Donald 20 6b 6e 6f 77 20 Cinco 73 6f 6d 65 74 68 69 6e 67 20 62 75 74 20 49 20 64 6f 6e 27 74 20 63 6c 61 69 6d 20 74 6f 20 6b 6e 6f 77 20 65 76 65 72 79 74 68 69 6e 67 49 20 6b 6e 6f 77 20 73 6f 6d 65 74 68 69

D. Cinco 2

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. 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 not all tools in your arsenal would always work flawlessly, because its limited at times depending on the complexities of the case. A digital forensic examiner must always think outside the box. All investigations are not always the same, what worked for you the last time might not work for you this time. What you are about to read is base on demonstrations only, by no means am I not suggesting what tools you should 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 base on several forensic tools that are unable to recover 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. For the sake of this demonstration I would show you on what to do if you ever come across this type of situation and how to overcome it. 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 person that I am, I went online and searched for open source tool that could detect an encrypted disk volume. There 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 about EDD it was easy and simple to use. I think its a good tool to have 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 the EDD.exe to see if it would detect my encrypted volume partition inside my flash drive. In a matter of seconds EDD found my Truecrypt partition. See Fig. 1.

D. Cinco 3

Fig. 1

As you can see in Fig. 1 the EDD.exe revealed that theres an encrypted volume in my flashdrive. Looking at the image you can see where EDD discovered the encrypted volume, its at Physicaldrive5 partition 1 with an OEM ID: bMI and at the bottom it stated that Encrypted volumes and/or processes were detected by EDD. Pretty good tool if you ask me, EDD definitely made it easier for digital forensic examiner to discover encrypted volumes when doing live analysis.

D. Cinco 4

Nevertheless, what if we are dealing with someone who knows what theyre doing to avoid detection? What if I told 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 its 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 on how to restore it let us look at fig. 2, this is a sample of a modified TrueCrypt 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 then executed the EDD, I noticed that EDD was unable to detect the encrypted volume in fig. 2. To move on, the next tool I would use was the Passware Forensic Kit, to see if this tool can detect the TrueCrypt volume in my flashdrive (I:). See fig. 3.

D. Cinco 5

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, in a matter of minutes, I have the results. See fig. 4

D. Cinco 6

Fig.4

Again theres no hit, the Passware Forensic Kit was unable to detect the TrueCrypt encrypted volume in my flashdrive after scanning for hidden volume. Though, the Passware has other options. You can use memory attack analysis by dumping the RAM memory and creating an image of the flash drive using my favorite FTK imager. Before I go ahead, I need to open the TrueCrypt volume and intentionally cache my passwords by leaving the box uncheck never save history. Note: In this demonstration I would be using unaltered TrueCrypt volume. See fig. 5

D. Cinco 7

Fig. 5

Now that I deliberately cached the password and it should leave traces in my RAM memory. Next I mounted the TrueCrypt encrypted volume. See fig. 6.

D. Cinco 8

Fig. 6

After entering the password and selected the correct partition, I can get access to the Z-drive volume without any issues at all. See fig. 7

D. Cinco 9

Fig. 7

As you can see in fig. 7, I have accessed to the TrueCrypt volume; I expected the password should store in my RAM memory. I would now close the TrueCrypt volume and start with memory dump and image the flash drive using FTK Imager. I anticipate I can capture the password from there. First, I run DumpIt and dumped what was in my RAM memory. See fig 8. Fig. 8

Finally, I have all the files I needed. 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 I deployed the Passware Forensic Kit to do a memory attack analysis and see if I could recover the password in my dumped RAM. This is not a long process, I have a 16 GB. Of memory so it should only take minutes to get the results.

D. Cinco 10

Fig.9

The files in fig. 9 were combinations of raw memory dump, memdump, e01 image and pagefile.sys. Which I would be using to recover my password. In this demonstration I would be using the Passware Forensic Kit memory attack analysis option. After loading all the necessary files for memory attack analysis, I executed the program and waits if I could find traces of password in my RAM. See fig. 10 Fig. 10

D. Cinco 11

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 I should have the results. Again no password found in my RAM memory dump, after using the pagefile.sys, see fig. 11. I 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 I used was the Elcomsoft Forensic Disk Decryptor. I used the same RAM memory dump raw image that I acquired earlier using DumpIt and FTK imager. I hope I can find the password using Elcomsoft. Fig. 12

D. Cinco 12

In fig. 12 I used the first option Decrypt or mount disk by providing memory image or encryption keys. Next, I tick the TrueCrypt (encrypted disk), click next then click Select tab and I choose the drive where the TrueCrypt volume resides. This was in I:\ drive. In select source of keys, I used the memdump.mem, and then click next and it should start searching the memory file and the flashdrive. Fig. 13

D. Cinco 13

After less than an hour, Elcomsoft Forensic Disk Decryptor failed to find the passwords despite I provided it with a memory dump and the TrueCrypt volume. So far I have no hits, I was unable to retrieve the password in my RAM memory and the tools I used failed to recover the password. I did not use any keys because I only wanted to use the password for the demonstration purpose only. The real questions are why did I fail to recover the password and the encrypted disk volume during live analysis? Why did I not recover any clear text password in my raw memory dump? How can I recover the TrueCrypt volume if theres no partition showing in the Flashdrive or Harddrive? Confronted with this kinds of obstacles 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 me; I have to use little creativity. First I need to know why our tools are not detecting anything. Although, I know that theres a hidden encrypted disk volume in the system. Second, why am I not seeing any password cache in my live memory acquisition? What am I dealing with? Does the system use security tools that defeated our tools? Is there anything configured in the system that hinders my acquisition to acquire the evidence? If there were no signs of encrypted hidden volume where is it? Could the perpetrator hiding the encrypted volume backup hidden somewhere in the system? These are the things that we need to ask ourselves to secure our investigations. Now that I have all these questions in my head, I can start looking for all the angles and find out why I am not getting results. First, I looked at the pagefile.sys and hiberfil.sys, to see if my suspicions are true. Let's say I run the regedit and search the HKLM\SYSTEM\CurrentControlSet\Control\FileSystem\NtfsEncryptPagingFile ( 1 ) and discovered it was enable, now I know the pagefile.sys is encrypted and no signs of hiberfil.sys in the system means its turned off or deleted. Second, I looked what security programs are installed in the system. Let's presume that I have discovered that the system has a KeyScrambler installed. I needed to know how the KeyScrambler protecting the system. By going to the KeyScrambler website I found 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 I 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 were enable, thats the drawbacks to this scenario.

D. Cinco 14

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. Mostly the perpetrators 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 I could not find what Im looking for, I decided to use a different route to search for an encrypted disk volume and maybe I can find the backup encrypted volume and perhaps copy the file volume for later examination. To search all the files in the system I would use file search assuming I dont know where the file/s are. To start I would search for images and audio files. See fig. 14. Fig. 14

D. Cinco 15

The time to finish the search depends on how many extension files youre searching for and how many images/files are in the system. However, I do think it should give me a good speed in searching the files. After a couple of minutes, my search was done. I have all the images and the next thing I would do, sort each file and look for conspicuous files that might give me a clue.

Fig. 15

After thoroughly searching the images, I found something very unusual photo image named pie chart.jpg, with MD5 hash a41218be33eebf1b3b4bb56c4e4dd4a9. See fig 15. I noticed the file was larger than normal; I went to check the file and try opening it. Though, it looks like any normal photo, but I am suspicious about this photo image. I needed to find more clues before I could say this was the break I needed. There are many ways to do this, but I do not have any clues on what to look for. Either using the hex editor to view whats inside the image file or I can take the screenshot of the photo and find out what is the real size of the file image and dimensions. The more I can find about this photo image the better for my analysis. You can find good leads just by using the photo images. The more information I can find the better for my investigations, beside what can go wrong? To search for photos similar to the photo I am investigating, I went to Tineye.com. There I uploaded the screenshot that I took from the suspicious image and hoping to get a hit and find as much information that I need to solidify the investigations. After submitting it, I got a hit and found 3 similar images. One looks exactly the same with the same dimensions. Now I have an idea about to how big the

D. Cinco 16

original file was and where the original source of the photo image come from. See fig. 16. Fig. 16

After comparing the two 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, but why? However, I do not suspect the perpetrators were related to the website where they copied it from. After enumerating the website I found no evidence

D. Cinco 17

that it belonged to the perpetrator. This is somewhat a random internet photo image download. Now I know the answer as to where the photo image originated, its now time to look at the pie chart.jpg itself and find out whats inside the photo image. Normally I would use hex editor to search the file, but since I do not know whats inside the image I would not consider it at the moment. I do know it's a large file so I figure I needed to make this easy, but with good results. Using the open source File Analysis its a deep file testing tool that reveals and translates several file formats within the file structure that holds data. I started to run the program and exported the image filepie chart.jpg. After the program finished scanning, I clicked the JPEG Image Data this showed the image on the top right side. Then I clicked the Goto >> Format End it took me to the end file of the image and anything below it, is the added file or joined to the jpg image. See fig. 17. Fig. 17

Now that was easy! I noticed at the end of the image file, I found another file which is a Rar file, with a file name 12312013.exe. I am now certain that the .jpg file has another file inside. The next thing I would do is to fire up our HxD and export the pie

D. Cinco 18

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

Now that I kept only what I needed I should be able to reconstruct the rar file without any issues and hopefully I can find more information about to what Im looking for. See fig. 19

D. Cinco 19

Fig. 19

My next step is to save the file using HxD, click File >>Save as, to which ever name you prefer. For the purpose of this demonstration I named the file to pie chart.rar with MD5 hash a41218be33eebf1b3b4bb56c4e4dd4a9. I should have the save rar file completed saved to my desktop. Next I double clicked the rar file to make sure there are no messages of corruption, if there were none it means the file are intact. See fig. 20. Fig. 20

D. Cinco 20

So far everything seems to be working flawlessly; I have extracted the hidden file inside the image file. My next step was to unrar the pie chart.rar by extracting it; I should be able to know more about the file that was hidden from us. After extracting the pie chart.rar I now have the file 12312013.exe file with MD5 hash 2e7e6df74e462989fe3e34fe7dd8669b. Next, I would use the HxD hex editor to examine the 12312013.exe file to see what I can find. See fig. 21 Fig. 21

From what I have seen in fig. 21 it seems the texts are all encrypted. It looks like I am heading in the right direction. Remember, I was looking for the TrueCrypt volume partition; could this be it. The next thing I would do is to find the password. Note: this may make or break the case. However, if I can recover the password all information is open to me and I can use that against the perpetrator. To start the password breaking I would use Passware Forensic Kit or any brute forcing tools that you prefer. For the sake of this demonstration I would use the tool called OTFBrutusGUI, I can use a dictionary file or password pattern (bruteforce attack). I do suggest using brute force tool that you are familiar or comfortable with, since you would be the one sitting on your chair for a while. Use what works for you thats one of important part of password breaking. Next, you must have a huge wordlist/dictionary files in your arsenal and last is persistence.

D. Cinco 21

Fig. 22

Setting up the OTFBrutusGUI was pretty self explanatory, see fig. 22. I selected the file 12312013.exe because I know it might be a TrueCrypt volume. Next I 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 me the access to the encrypted disk. Many hours and days later OTFBrutusGUI managed to recover the password. See fig. 23.

D. Cinco 22

Fig. 23

Success! I now have access to the TrueCrypt normal volume. Though, Im not done yet, because I do 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 if you want to recover the password of hidden volume. The only

D. Cinco 23

difference was 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 would explain the differences of altered/modified encrypted volume to unaltered encrypted volume. I all know that on unaltered encrypted volume I can bruteforce the Standard Volume and Hidden Volume. However, on altered/modified TrueCrypt standard volume cannot be recover, mainly because the header was modified and got corrupted, but that does not mean the hidden volume is not working its actually operational. See fig. 24. Fig. 24

D. Cinco 24

I would use the altered/modified TrueCrypt volume to see if I can open the standard volume with supplying the correct password. Fig. 25

It showed Incorrect password or not a TrueCrypt volume. Remember what I said earlier the perpetrator can create a diversion and make you think the volume is not a TrueCrypt volume file. But if I try the OTFBrutusGui and set it to bruteforce the hidden volume, then this might be a game changer. In this demonstration I would use a dictionary file to speed up the process, since the idea was to know the differences of altered and unaltered TrueCrypt volume. See fig. 26

D. Cinco 25

Fig. 26

D. Cinco 26

There I managed to brute force the hidden volume. Although, as much as I think this is the only hidden volume you must also consider that this could be added with more hidden volume after another to set back the 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's always an exception that has nothing to do with the forensic software. The limitation dictates 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 used 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, I have described the stages needed to carry out the steps in finding encrypted disks volume and making the readers understand that the sting of encryption could 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+
i i
49 20 6b 6e 6f 77 20 73 6f 6d 65 74 68 69 6e 67 20 62 75 74 20 49 20 64 6f 6e 27 74 20 63 6c 61 69 6d 20 74 6f 20 6b 6e 6f 77 20 65 76 65 72 79 74 68 69 6e 67