Open Sesame

Sometimes little gems come across mailing lists. Like this little
footnote announcement in Microsoft’s MSDN email this
week
:

Open Specifications
<
http://go.microsoft.com/?linkid=9252946>

Microsoft is providing
open connections to its high-volume products –
Windows Vista (including the .NET Framework), Windows Server 2008, SQL
Server 2008, Office 2007, Exchange Server 2007, and Office SharePoint
Server 2007. As a developer, you now have full access to information
about protocols, binary file formats, and other specifications for
these products that can be used to create solutions

Microsoft? Open protocols? Sure enough the Microsoft
protocol program
section details the initiative including this
quick link
to the major sections including user forums, docs,
etc. To quote the page:

Documentation
for the Open Protocols will be made available without
charge and without restriction on the MSDN Library in the Open Protocol
Specifications area.

Patent licenses for
patents on Open Protocols will also be made available at low royalty
rates.

So there are docs for free and patent licenses if you plan on making
something implementing the protocols (alternative exchange clients,
etc). What does this mean to forensics? Most likely two things

  1. An increase in the number of open source tools that can
    work with Microsoft data stores and protocols
  2. An increase in the accuracy of existing open source tools
    that work with the protocols.

For example, I recently worked an email investigation where I only had
outlook .msg files and no good way to decode them. I used the ruby program msgtool
for a quick conversion of the files to rfc2822 format for analysis. This tool
is by no means complete but worked well for my purposes. A quick look at the TODO
tells you the known issues and not surprisingly a good deal of these have to do with
reverse engineering the protocol for .msg files.

Let’s hope that this initiative granting access to the protocol
documentation (even version 1) will yield some fixes and new tools for decoding these common files and protocols.

Jeff Bryner, GCFA Gold #137, also holds the CISSP and GCIH certifications, occasionally teaches for SANS and performs forensics, intrusion analysis, and security architecture work on a daily basis.

Putting Disk Imaging in the Fast Lane

When it comes to imaging a hard disk, I believe that keeping it simple is best. I also believe that faster is better. The less time it takes to prepare for imaging, and the faster the imaging speed, the sooner I can begin analysis.

I’ve imaged disks using many different methods. A few of the more common methods are:

For ease of use and imaging speed, when circumstances allow for it, I much prefer using the HardCopy 2.

HardCopy 2

Imaging appliances expedite the imaging process
Imaging appliances expedite the imaging process

The HardCopy 2 contains everything needed to image a 3.5” IDE drive, without needing a computer. Simply pick up a couple SATA adapters, and a 1.8” and 2.5” drive adapter, and you’re ready to image most hard drives you’ll encounter.

Features of the HardCopy 2 include:

  • The IDE port labeled “Read Only Suspect Drive” uses built-in write block functionality that can’t be disabled (I appreciate this feature, as it reduces the possibility of making a mistake)
  • Its “Wipe Drive” feature overwrites the entire destination disk with zeros –handy for sanitizing your destination disk
  • Its “Format Drive” feature will format the destination disk (you can choose NTFS or FAT32)
  • Its “Image Drive” feature performs a bit-level image of the source drive, saving it as a file onto the (pre-formatted) destination drive (It also records critical information about the source drive, including its make/model, geometry, serial number, and an MD5 hash of the drive as calculated during the imaging process)
  • Its “Clone Drive” feature will perform a bit-level copy of the source drive onto the destination drive

Summary

Because the Hard Copy 2 (with the help of a few inexpensive adapters) can quickly image hard drives in a forensically sound manner, with very little prep time, it has become my tool of choice. I use it to sanitize my destination drive, format it with NTFS, then image the source drive to a file. It’s compact size lets me keep it, the needed adapters and accessories, and a couple hard drives in a Pelican 1450 case.

Brian Eckman, GCFA Silver #434, is currently the lead Forensic Analyst at the University of Minnesota. In addition to the GCFA, Brian holds the EnCE certification, and serves on the REN-ISAC Technical Advisory Group.

Hex Dumping Flash From a Mobile

Most mobile phone manufacturers sell or provide tools allowing for the management of data. There are some exceptions with the very low cost devices. The problem that arises is that few of these tools are forensically sound. Hence the need for an alternative, hex dumps from a flasher.

Model: UN-0412100 Flasher by Twister
A Hex dump of the device is a physical acquisition of the device’s memory. In the majority of devices available this will necessitate the use of a “flasher” or “twister” device. These are specialist support tools that are designed for the repair and servicing of mobile devices. The benefit to the forensic examiner is that these devices allow for the dumping of the device’s memory. These are called “flashers” as they enable the manipulation of the flash memory on the device.
A number of specialist software offerings have been developed that can analyze a hex dump or “flash file” in order to produce a report or extract data from the image. Some of the better known products include:
  • Pandora’s Box for Nokia
    • hex dump analysis
    • Date and Time Decoding
    • PDU encoding/decoding
    • Hex conversion functions
  • Cell Phone Analyzer (CPA).

Flashers allow one to capture a phone’s memory (the Flash) as an image. This image may then be examined in the same way any computer image would be examined. When securing a mobile phone, always obtain the PIN code for the SIM if possible. Also record the make, model, colour and condition of the device. Other areas to note include:

  • IMEI, SIM card number
  • Hardware/Software Used
  • Data recovered

The forensic process is highly dependent on the make and model of the device. Any process should include an attempt to obtain the following:

  • Call Logs, Phonebook
  • Calendar
  • Text, Audio, Video
  • Messages sent/received
  • Internet cache, settings
  • Hex dump of the devices filesystem

Where possible, a hex dump of the system is the most important thing to obtain. With this information, a standard forensic analysis may be conducted and in many cases the filesystem can be checked for known malware signatures. On newer phones such as the iPhone and Mio A701, the GPS logs can provide information about the movement of the device.

Craig Wright (GFCA Gold #0265) is an author, auditor and forensic analyst. He has nearly 30 GIAC certifications, several post-graduate degrees and is one of a very small number of people who have successfully completed the GSE exam.

Why Mobile Device Forensics is the new “Killer” field

I have just completed work on a forensics chapter of a book on mobile malicious code (MMC). What researching this topic has made me do is to think just how many things that an attacker can do with a mobile phone. In this post I am going to address just three of the many reasons why it is important to ensure that these devices are not overlooked in forensic examinations.

Using a Mobile to Locate and Track People

A number of services already exist that can locate a mobile phone. These services are nowhere near as accurate as a GPS (which is now being included in phones), but they allow for a parent to monitor where their children go or a spouse to monitor their wayward partner. SIM based tracking can target a phone to within 500 meters. In a phone with an integrated GPS (such as some iPhones) the accuracy can be as good as within 5 meters.

Intercepting and recording voice calls

Java applets designed to intercept and record all voice calls can be installed onto a SIM remotely through Malcode. An attacker can then eavesdrop on any voice call either made or received on that phone without having ever been in the same physical location of the target phone.

Using the mobile as listening Device

Rumors abound that mobile phones can be used as a remote listening device. These go as far as saying that this will work even if the phone is off. There is some exaggeration and some truth in this statement. The truth is that this will not work when a phone is off…

However, a phone can be made to appear to be off. All this from a Java applet!

If you are in Law Enforcement, Endoacoustica (http://www.endoacustica.com) sells phones that are preconfigured to do this. Java based Malcode designed to attack the SIM can also cause a phone to act in this way.

Why a Killer new Field?

Basically, most people do not think about what wrongs can be committed using a mobile phone. With banks starting to use these devices as an authentication token the worst is just around the corner.

Next time…

Hex Dumping flash from a mobile.

Craig Wright, GFCA Gold #0265, is an author, auditor and forensic analyst. He has nearly 30 GIAC certifications, several post-graduate degrees and is one of a very small number of people who have successfully completed the GSE exam.

You will be hacked, will you be prepared?

“Hope for the best, prepare for the worst.” — English proverb

“Before anything else, preparation is the key to success.” — Alexander Graham Bell

Forensic analysts and the organizations employing them can simplify and expedite the forensic analysis process with preparation. If you accept that system compromise is a matter of when not if, then prepare your systems in advance for forensic analysis.

Before moving systems into production, grab a copy of Jesse Kornblum’s MD5Deep from http://md5deep.sourceforce.net and create MD5 checksums of all the files on the system. Have your desktop folks incorporate this into their image building process. If you’re really diligent, update your hashes after applying patches.

Astute readers will say, “I can download known hashes from NIST’s National Software Reference Library (http://www.nsrl.nist.gov/). Why create my own?” NSRL is an amazing resource, but their collection contains millions of hashes and most of them will not pertain to your environment.

Taking advantage of your hash file requires using hfind from Brian Carrier, available from http://www.sleuthkit.org, to create an index of the MD5 file. When a system based on your image is compromised, run Carrier’s sorter utility using your hash file and its index file against a copy of the system’s image. Sorter will exclude all the known-good files that match your original system image.

Here’s sample syntax:

sorter –h –x devbox.std_img.md5 –d ./sorter_results –m / hacked_devbox_sda1.img

sorter command with verbose output
sorter command with verbose output

This sorter command produces html output (-h), excludes (-x) any file with an MD5 sum matching one found in devbox.std_img.md5, saves results to the existing sorter_results directory (-d) and finally processes hacked_devbox_sda1.img. The –m flag specifies the mount point for the partition image being processed. In this case, the image was mounted at / so all files in our report will have path information relative to that. For Windows images, provide a drive letter (i.e. –m C:).

In our example the devbox partition contained 40945 files as reported by sorter. Our devbox.std_img.md5 file contained MD5 hashes for 40340 files. Sorter reduced the amount of data we need to investigate from 40K plus files to 605.

Commercial applications have similar capabilities. Consult your product’s documentation for details.

Remember, preparation is the first phase of incident handling. Maintaining MD5s of the standard images your organization deploys is an easy step you can take that will save you hours or days when the inevitable happens.

Dave Hull, GCFA Silver #3368, is an aspiring maker and technologist specializing in information security. He is the principal consultant and founder of Trusted Signal.

Known plaintext analysis of encoded strings

As a child, my first introduction to ciphers came in the form of Edgar Allen Poe’s The Gold Bug. The tale of pirates, treasure, and ciphers gripped my ten-year-old imagination and held me spellbound — sparking an interest in puzzles and codes that would later make computer science the obvious choice for my career.

Recently the Gold Bug returned to my thoughts while digging through a new bit of malware. Our team obtained an email from “IRS.com” with an attached Microsoft Word document. Inside that attachment seemed to be an embedded PDF document, but opening that embedded document actually extracted a trojan executable (C__Adobe_Acrobat_Reader.exe).

Looking at printable strings found in this executable, I came across some text that looked like gibberish (shown here). One line in particular jumped off the screen: iuuq;0075/28/292/770dq0r/fyf. I remembered seeing similar strings in the past and with help from Google, was able to find a posting at the Internet Storm Center that mentioned the string iuuq;.

As I was staring at the portion of the packet trace in the ISC posting containing the string, it occurred to me that iuuq; could be read as http: and that this data was encoded using ROT-1, a Caesar substitution cipher.

0a69 7575 713b 3030 3836 2f32 3337 2f33    .iuuq;0086/237/3
322f 3237 3330 6267 6730 656a 7330 6d70    2/2730bgg0ejs0mp
686a 2f66 7966 0a0d 0a30 0d0a 0d0a         hj/fyf...0....

Shifting i one letter to the left in the ASCII “alphabet” produced h, u became t, and so on.

After writing a very small perl script (to which I added a line to also translate hex-encoded characters), I was able to decode the strings from the captured executable.

#!/usr/bin/perl
#
# Ridiculously simple script to reverse ROT-1 encoding
# and HEX-escaped characters.
#
# Example input:  MisdpMpoh!>!#iuuq;00xxx/mjkjo/hpw/do0uphbp0xjo43/fyf#
# Example output: LhrcoLong = "http://www.lijin.gov.cn/togao/win32.exe"

while (  ) {
      s/(.)/chr(ord($1)-1)/ge;
      s/%(..)/chr(hex($1))/eg;
      print;
}

After writing this script, I found it useful in other situations. For example, using it on strings extracted from a dump of Windows physical memory turned up interesting information. Since not every piece of malware uses ROT-1 to encode data, it occurred to me that I should generalize the approach.

In the Gold Bug, frequency analysis was used to crack the cipher. In the case of the data contained in malware samples, more than 26 letters are used, and some non-alphabetic characters are used frequently.

Instead of frequency analysis of letters, my new script focused on frequency of common strings. I picked three that appear frequently in malware:

  • http:
  • IP addresses in the form W.X.Y.Z
  • .exe

To keep things simple, I focused only on ROT encoding and wrote a new perl script to try a range of ROT encodings and count matches against those three strings. The script returned this output for me on a bit of malware that I analyzed:

Statistics:

ROT(1) \.[Ee][Xx][Ee]\b = 14
ROT(1) \b\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}\b = 1
ROT(98) \b\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}\b = 1
ROT(1) \bhttp:// = 6

The result: with fourteen .exe matches, an IP address, and six apparent URLs, it looks like the strings in this malware sample are encoded with ROT-1. It’s also possible that some data is encoded ROT-98, but with only one match… pretty unlikely. This script is just a start. The next step would be to add other encoding schemes, such as XOR. This is my favorite kind of script because it simply mines data for interesting patterns, leaving me with more time for other tasks.

–john

John Jarocki, GCFA Silver #2161, is an Information Security Analyst specializing in intrusion detection, forensics, and malware analysis.  He also holds GCIA, GCIH, GCFW and GSEC certifications and is a board member of NM InfraGard.