Password Recovery Can be Practical

Guidance Software’s Tableau Unit recently released Tableau™ Password Recovery, a hardware + software solution to accelerate password attacks on protected files, disks, and other containers.

It’s always fun to play with new toys, and when the new hotness is a purpose-built, linearly scalable, password-cracking behemoth, how can one not share? I did a bit of digging while running a two-server Tableau Password Recovery setup through its paces in our labs here in Pasadena, California, and while I found many good tools and tutorials for password cracking, I found it difficult to differentiate the theoretically possible from the actually practical. Here are some thoughts from that process.

Underestimate the Power of EnCase® and Volatile Data You Must Not

Jamey Tubbs

BOTs, BOTs, BOTs

While investigating a recent Java BOT I found some items that you might also find helpful in your battle against the dark side. (Yes, I will continue to make Star Wars quotes and puns throughout this blog). I enjoyed the investigation so much that I added it to one of our class lessons in the Host Intrusion Methodology and Investigations course at Guidance Software.

I could not have completed this task without the help of James Habben, a great friend of mine and fellow instructor at Guidance Software. When I use the word “I” in this blog, sometimes it is the royal “I,” meaning “we.” Thanks, James.

The first thing I did was take a snapshot of the volatile data using EnCase Version 7, and I saw that port 1000 was being held open by javaw.exe.

A little Google search resulted in the following information: “’"javaw.exe’ belongs to Java from Sun Microsystems, Inc. The javaw.exe command is identical to java.exe, except that with javaw.exe there is no associated console window.” This would be perfect for malware attempting to spawn a Java process and yet not display a console window while doing so.

Prior to examining the RAM, a quick “wookie” (WIKI) search tells us a little more data about the way Java works: Java executable files can be found in the form of .jar files. (http://en.wikipedia.org/wiki/JAR_%28file_format%29) “An executable Java program can be packaged in a JAR file, along with any libraries the program uses. JAR files are fundamental archive files, built on the ZIP file format and have the .jar file extension.”

So we ask ourselves, “What is the next step”? {Yoda voice} Truly wonderful, the mind of the RAM is…

A look at the process memory is warranted. I decided a simple search in the process memory of the Javaw.exe for the .jar filename was a longshot, but who knows? As seen in the image below, you can view the name of the .jar file along with the path to the file. (Server_1392852684035.jar)

This is all fine and good, but it does not help me track down the command-and-control server in charge of my little bot. Where then do we start to find that little nugget of information? Let’s look in the Server_1392852684035.jar file.

If you remember from my earlier quote of the “Wookie”-pedia, .jar files employ the .zip file format, so we can use WINRAR or WINZIP to unzip it as seen in the image below.

As you can also see there is a config.txt file located inside, which is where we would expect to find our configuration information for the death star inside R2D2… Sorry, I mean the configuration information for the BOT inside the .jar file. (I made a pun about a robot when talking about a BOT, get it?)

I went back to the process memory and searched for the Server_1392852684035.jar file and found something else very interesting. As you can see in the image below, just above the Server_1392852684035.jar file name there is a string of Unicode characters that looked a little strange to me.

Sure enough, it was 960 bytes long and that also struck a chord. Let’s take a look at the contents of the config.txt file. And as you can see, the 960 bytes represented in Unicode in RAM are the same as the 480 bytes of the config.txt file represented in ASCII.

What would you do at this point? Just before the contents of the config file in RAM is the text “AES/ECB/PKCS5Padding,” highlighted in yellow. I knew AES was the acronym for Advanced Encryption Standard and this might help in some small way, so I asked my friend Google what AES/ECB/PKCS5Padding was.

I found the following in the very first hit, which was entitled Cipher (Java Platform SE 7 ) - Oracle Documentation: Every implementation of the Java platform is required to support the following standard Cipher transformations with the key sizes in parentheses:

• AES/CBC/NoPadding (128)
• AES/CBC/PKCS5Padding (128)
• AES/ECB/NoPadding (128)
• AES/ECB/PKCS5Padding (128)
• DES/CBC/NoPadding (56)
• DES/CBC/PKCS5Padding (56)
• DES/ECB/NoPadding (56)
• DES/ECB/PKCS5Padding (56)
• DESede/CBC/NoPadding (168)
• DESede/CBC/PKCS5Padding (168)
• DESede/ECB/NoPadding (168)
• DESede/ECB/PKCS5Padding (168)
• RSA/ECB/PKCS1Padding (1024, 2048)
• RSA/ECB/OAEPWithSHA-1AndMGF1Padding (1024, 2048)
• RSA/ECB/OAEPWithSHA-256AndMGF1Padding (1024, 2048)

I highlighted the text above in yellow—that was really helpful to me. I was dealing with 128-bit AES encryption. I now knew I was looking for a 16-byte string of characters to use as the key. 1 byte = 8 bits, so 128 bits divided by 8 = 16 bytes. (I bet Darth Vader wished he had encrypted the Death Star plans much better.)

So, going back to look one more time at the image showing the contents of the config.txt file in RAM, you will see a 16-byte key just in front of the 960 Unicode bytes that make were loaded into the process memory from the config.txt file. What would the chances be that those 16 bytes (highlighted in orange in the image), “15af8sd4s1c5s511”, would be the key to unlocking the config.txt?

As it turned out, when I decrypted the file with the key the contents were still unreadable and I lost a little hope. Did I do something wrong? Was it the correct key? What was going on? (If you’re thinking I’m going to make a Star Wars pun quoting General Tarkin, “Evacuate in our moment of triumph? I think you overestimate their chances,” then you would be wrong and, as Darth Vader would say, “I find your lack of faith disturbing.”)

As it happens, I discovered that it was doubly encrypted with a second 16-byte key,which I also found in RAM and simply put into the decryption engine using Cryptool 2.0. I found the IP address of the command-and-control server was 172.21.12.121 with a password of 1234, and it utilized ports 1000 and 1001 to send and receive data.

We go into more detail in our class called Host Intrusion Methodology and Investigation on this exact bot and the decryption methodology used in this blog post.

My decryption engine built in Cryptool 2.0 is shown in the image below. In one of the best quotes of the Star Wars Film Episode IV - A New Hope coming from an intercom in the Death Star control room: “Stand by…….stand by….”. Here is the decryption model in Cryptool 2.0

To sum up, I’d like to say, when dealing with malware, volatile data is an absolute must. Imagine that we had not obtained the volatile data… Where would we have started? Of course, when someone lays it out like it this--play by the numbers--everything seems just a bit easier.

Comments? Ideas? I welcome your input in the comments section below.

Jamey Tubbs is a Director of Professional Development and Training at Guidance Software. He previously served as a CID Special Agent in the U.S. Army Criminal Investigation Command.