Some Basic Options When Dealing with TrueCrypt (aka Finally a Forensics Post)

I’ve recently been working on a presentation I’ll be giving in a few weeks on the topic of memory forensics. I’ve learned a ton while working on it and the old adage of “The best way to understand something is to teach in to others” has proven extremely beneficial to me.

One of the topics that required me to do some digging was on the subject of memory analysis as it relates to TrueCrypt. A few years ago I was asked to examine a system within an extremely short time frame. I looked at the software installed on the system and saw TrueCrypt. I didn’t know a ton back then but I knew enough to know that there was nothing quick about dealing with TrueCrypt.

I’m writing the post that I wish I would have had on that day a few years back. If you see TrueCrypt installed on a system and aren’t quite sure what to do with that bit of information, hopefully this quick overview and some of the resources I’ll mention help. I’m not going to cover using artifacts like prefetch files to determine if TrueCrypt is installed and how frequently it’s been used, we’ll just cover hunting for and dealing with the containers.

Locating TrueCrypt:

One of the things that makes locating TrueCrypt files difficult is their lack of a standard file signature that one would normally use to locate all of a particular file format. There is a free tool called “TCHunt” that will scan a drive or directory and look for files that may be TrueCrypt containers. TCHunt looks for miles that meet specific size requirements (file size divisible by 512 and at least a minimum size), doesn’t have the file header of a known common type and appears to contain a higher than average randomness of data which is a key indicator that the contents may be encrypted.

tchunt

 

 

 

For everything that TCHunt does it’s also amazingly quick. I ran it against a 750GB Hard drive which had over 500GB of data and the complete scan took around three minutes. The tool correctly identified all four TrueCrypt containers on the drive.

Cracking TrueCrypt:

Using Memory:

Ideally you have a memory dump which was acquired while the TrueCrypt container was mounted. In lieu of that the hiberfil.sys may have been written while the container was mounted. TrueCrypt no longer stores it’s password in memory but it does store encryption keys in memory while the container is mounted so the password doesn’t need to be re-entered every time a file is accessed. These keys can be located using tools like bulk extractor and are the key to unlocking the container.

Michael Hale Ligh wrote a great blog post on Volatility Labs earlier this year discussing identifying and acquiring these keys. In the post he references a 2011 blog post by Michael Weissbacher  where he outlines patching TrueCrypt to allow an examiner to use acquired AES keys to mount a TrueCrypt container without knowing the password. There are commercial tools such as passware and elcomsoft which will also allow an examiner to access a TrueCrypt container using keys acquired from a memory dump.

Without Memory:

If no useable memory dump is available and you still want to access a locked TrueCrypt container you’re hoping for quite a few things.

• The user used a short password
• The user stuck to the default settings (RIPEMD-160 and AES) when creating the TrueCrypt container
• You have access to a system with a powerful graphics card

Modern graphics cards (GPUs) can crack passwords at a MUCH faster rate than a computer processor (CPU) can. I recently upgraded to an ATI 7950 3GB model ($230 at Newegg) and I’m able to crack passwords on a TrueCrypt container created with default settings at a rate of 77,000 guesses per second. That sounds like a lot and it’s great for wordlists (I can go through the entire 14,000,000 word rockyou list in under three minutes) but when you start crunching the numbers on a brute forcing attempt you’ll quickly become discouraged.

If standard wordlists don’t crack the password there could be multiple causes. The user could have changed the default settings when creating the container or could have used a password not in your word lists. You could try generating custom wordlists or using your wordlists with different encryption options.

I threw one of the TrueCrypt containers TCHunt found at oclHashcat to try to crack the password. oclHashcat has multiple TrueCrypt encryption options but I tried the default RipeMD160 and AES option first.

hashcat1

It turns out that the password (123mango) was in the rockyou wordlist I was using so the password was cracked in under a minute.

hashcat2

 

 

 

 

 

 

I can’t overstate the value of having some good wordlists for times like these. Brute forcing a password 8 characters or longer is a road nobody wants to go down.

I’ve been using john the ripper for a few years but am just now starting to seriously delve into GPU password cracking so I’d love to hear any tips, techniques or stories you have on these topics.

Samurai Skills Update #4

Between work, the holiday and other demands on my time (I’ve got another cert test coming up this week) I haven’t had a ton of time to play around in the attack-secure student labs but I wanted to give a quick update.

Video seven (there are eight total) is a five hour monster which I’m about two hours into so I’m getting close to the end of the videos.

My wife had to work on a late night project Thanksgiving evening so I had a few ‘free’ hours which I spent playing around in the lab. I decided to go SQL injection hunting and ended up finding a box which looked promising. I fired up the command line tool ‘sqlmap’ and fed it a tasty looking URL. Within a minute sqlmap came back and confirmed that the web app was indeed vulnerable to a SQL injection attack.

I was able to use sqlmap to enumerate the databases, to dump the content and even crack a password hash found in one of the databases.

NOTE: The initial password cracking attempt of sqlmap only takes a minute or so but when sqlmap asks you if you want to try common suffixes for the passwords and warns you that it will be slow, it means S L O W. I sat there for an hour wishing I had not pressed yes but not wanting to cancel the process.

I took the file grabbing options of sqlmap for a test drive and downloaded the /etc/passwd and /etc/hosts files. I tried to grab the /etc/shadow file but didn’t have rights to the file.

I ran into a hiccup trying to obtain shell using sqlmap and haven’t had a chance to go play on the box more but hopefully I can parlay progress on that box into shell and root.

As usual, the videos were quite helpful on this one. The penetration testing field requires a ton of Google searching and there are a lot of free video resources on sites like security tube but it’s still nice to have a course like this which is laid out in logical manor and lets you watch the tool being used while you listen to the author explain what’s happening.

I’ve learned a ton from the videos (with a ton more to learn) but the labs have remained the big draw for me. Having a student network to play in and work on my skills has been awesome.

There is a huge difference in knowing what an attack or a process is and actually trying to get it to work on a box. I’m not where I want to be yet but I’m very happy with the progress I’m making.