Author Archives: jarocki

Helix 3 Pro: First Impressions

4
Posted by jarocki on November 20, 2009 – 11:16 am
Filed under Computer Forensics, Evidence Acquisition, Evidence Analysis, Incident Response, Linux IR, Memory Analysis, Registry Analysis, Windows IR

I have used several versions of Helix over the recent years.  I enjoy the tool set and recommend it to forensics colleagues, sysadmins, and even family members.

Quite a substantial ruckus was raised this year when e-fense announced that Helix 3 would no longer be free to download.  Instead, would-be users must pay to register as a forum user to get access to Helix 3 Pro updates for a year.

I took the plunge and purchased my forum membership.  Here are the first things I noticed:

  • Some of the highlights…
    • The forum allows access to the Helix 3 software the member applies a registration token.
    • After adding the token, I was able to download not only Helix 3 Pro, but also Helix 3, and contributed tools.
    • Helix 3 Pro is really nothing like the 1.8 and 1.9 versions that came before it.  Although it still provides a bootable live CD as well as executables that can be run in Windows in Linux, the interfaces for all the modes of use have been made more consistent and seamless.  Also, a Mac OS X set of tools have been added.
    • The Helix 3 Pro CD also provides a set of cell phone forensics tools (that I will cover in a follow-on posting).
    • One of e-fense’s goals with the Helix 3 release was to provide a forensics tool that did not touch the host computer in any way.  I have not tried to verify this yet, although I intend to do so soon.
  • And the lowlights…
    • On my Dell D630 laptop (and few other systems), the boot process generated a number of errors and — in some cases — would not detect a graphical interface mode correctly, leaving me with an unusable Helix environment.
    • The majority of the tools that made previous versions of Helix useful are just completely gone.  This is apparently done so that the Helix Pro 3 image can be trusted.  I spoke to a sales representative at e-fense who told me that several customers were using Helix 3 Pro in environments where open source software of questionable origins is, well, frowned upon.
    • Static binaries formerly found on the Helix 1.x CDs are now separate downloads.  They are still available through the Helix forums.

This is the first in a series of blog postings I plan to publish on Helix 3 Pro.  Please post comments if there are specific tools or features of the LiveCD you would like me to cover.

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 the Treasurer of NM InfraGard.  John recently co-authored a controversial paper on using LiveCDs to mitigate online banking risks.

Interview: Darrin Jones, Director of New Mexico RCFL

0
Posted by jarocki on July 27, 2009 – 1:31 pm
Filed under Computer Forensics, Digital Forensic Law

The Regional Computer Forensics Laboratory (RCFL) Program is a partnership between the FBI and local, state, and federal law enforcement agencies.  The Program provides forensics resources and advanced techniques that can be brought to bear on cases being worked by participating agencies.  The first RCFL was established in 1999 in San Diego, California.  This successful partnership between FBI and Southern California law enforcement led to fifteen more centers over the ten years that followed.  One of the most recent is in Albuquerque, New Mexico.

Supervisory Special Agent Darrin Jones is the Laboratory Director of New Mexico RCFL and was key to it’s establishment.  I interviewed him recently to find out more about the Program.

Q:  When and why did you get involved with the RCFL Program?

A:  I’ve been in Albuquerque for about two years, prior to this assignment I worked at Quantico within the FBI’s Operational Technology Division (OTD).  The national RCFL program is managed from within OTD.  So, I’ve been familiar with the program for many years and have always been incredibly impressed with how successful the RCFL program has been.  I starting trying to get an RCFL in New Mexico almost immediately when I arrived.  It’s a long process, usually taking several years from start to finish.

Q:  What does it take to start up a new RCFL?

A: As you would expect there are many requirements for starting an RCFL.  The Director of the FBI makes the final selection from among submitted proposals.  I will tell you though, I believe one of the most important factors is the demonstration of commitment from the proposed partnering agencies.  In short, are the partnering agencies, in additional to the executive management of the local FBI office, willing to support the RCFL by detailing their personnel on a full-time basis and through management of the RCFL by participation on the local executive board.

Q:  Do the RCFLs provide the same services, or do they have specialties?

A: All RCFLs are committed to providing examination of digital evidence at the highest possible standards.  Each RCFL handles the types of digital evidence you would expect; computers, cellular telephones, etc.  But, yes, some RCFL locations have developed centers of excellence for dealing with specific types of digital evidence.  For example, if we encounter a particularly complicated case dealing with a niche technology we have the option to exploit the expertise located in another RCFL by requesting their assistance or simply transferring the evidence to that facility for processing.

Q:  What sort of advanced techniques are used at the RCFLs?

A: We do employ sophisticated techniques at the RCFLs, in many cases we use tools that have been developed, tested and validated in-house for exclusive use by the FBI and within the RCFLs.  However, I would suggest that what makes the RCFLs so successful is not super sophisticated technologies that may be used occasionally, instead it’s the rigorous adherence to the every day processing of digital evidence.  From the moment the an item of evidence enters an RCFL facility it is processed according to strict protocols and requires extremely thorough documentation.  Another reason I think the RCFLs have done so well over the years is the training ALL examiners must complete before becoming a certified examiner.  This training includes hundreds of hours in both commercial and internal FBI classes at locations all over the United States.  A typical RCFL examiner can expect to spend a minimum of 18 months in this training process, and that’s assuming some knowledge coming into the program.

Q:  How can digital forensic analysts get involved with their nearest RCFL?

A: Generally speaking, the RCFLs don’t “hire” anyone, there are exceptions but normally a person must be detailed to an RCFL by their participating parent law enforcement agency.  In New Mexico’s case examiners will be detailed from the FBI, the Albuquerque Police Department, the Bernalillo County Sheriff’s Office, and the New Mexico State Police.

Q:  I’ve heard there are internships, what are the requirements for participation?

A: Most RCFL internships are managed via FBI Headquarters, for example, FBI Honors Interns (see fbijobs.gov for internship details) are selected via the national process then detailed to a specific RCFL.  However, RCFLs can create localized internship programs.  One of the most exciting things about the New Mexico RCFL is the fact that we are partnering with the University of New Mexico.  There is only one other RCFL in the country to have such a relationship and we anticipate the NMRCFL will be able to offer several different internships to UNM students.  We will be posting more details regarding these internships on the NMRCFL website, hopefully in the next several months.

Q:  Are there any well known cases where the RCFL involvement was key?

A: Yes, there are several readily recognized cases that have hinged on digital evidence processed at RCFLs.  The best thing to do is to take a look at the newsroom link on the national RCFL site, they post new cases there all the time.

References:

Introduction to RCFLs (Last Modified: 04/02/09), http://www.rcfl.gov/downloads/documents/intro_to_RCFLs.doc
National Program web site, http://www.rcfl.gov/
New Mexico RCFL web site, http://www.nmrcfl.org/

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 the Treasurer of NM InfraGard.

Forensics 101: Acquiring an Image with FTK Imager

0
Posted by jarocki on June 18, 2009 – 1:33 pm
Filed under Computer Forensics, Evidence Acquisition, Uncategorized

There are many utilities for acquiring drive images. I maintained my snobbish attachment to plain old dd for a long time, until I finally got tired of restarting acquisitions, forgetting checksums, and making countless other errors. The truth is: there are plenty of good tools that provide a high level of automation and assurance. The rest of this article will walk the reader through the process of taking a drive image using AccessData’s FTK Imager tool.

FTK Imager is a Windows acquisition tool included in various forensics toolkits, such as Helix and the SANS SIFT Workstation. The version used for this posting was downloaded directly from the AccessData web site (FTK Imager version 2.6.0).

Run FTK Imager.exe to start the tool.

FTK Imager GUI

From the File menu, select Create a Disk Image and choose the source of your image. In the interest of a quick demo, I am going to select a 512MB SD card, but you can select any attached drive. NOTE: FTK Imager does not guarantee data is not written to the drive, so it is important to use a write blocker like the Tableau T35es.

Select Image Source Select Device

Click Add… to add the image destination. Check Verify images after they are created so FTK Imager will calculate MD5 and SHA1 hashes of the acquired image.

Add Destination

Next, select the image type. The type you choose will usually depend on what tools you plan to use on the image. The dd format will work with more open source tools, but you might want SMART or E01 if you will primarily be working with ASR Expert Witness or EnCase, respectively.

Select Image Type

If your version of FTK requests evidence information, you can provide it. If you select raw (dd) format, the image meta data will not be stored in the image file itself.

Evidence Information

Select the Image Destination folder and file name. You can also set the maximum fragment size of image split files. Click Finish to complete the wizard.

Select Destination

Click Start to begin the acquisition:

Create Image

A progress window will appear. Now is a good time to refill that coffee cup! Once the acquisiton is complete, you can view an image summary and the drive will appear in the evidence list in the left hand side of the main FTK Imager window. You can right-click on the drive name to Verify the Image:

Verify Image

FTK Imager also creates a log of the acquisition process and places it in the same directory as the image, image-name.txt. This file lists the evidence information, details of the drive, check sums, and times the image acquisition started and finished:

Created By AccessData® FTK® Imager 2.6.0.49 090505

Case Information:
Case Number: Case-20090611-001
Evidence Number: 1
Unique description: John Doe SD Card 1
Examiner: John Jarocki
Notes:

--------------------------------------------------------------

Information for E:\Case-20090611-001\sdcard1.dd:

Physical Evidentiary Item (Source) Information:
[Drive Geometry]
Cylinders: 61
Tracks per Cylinder: 255
Sectors per Track: 63
Bytes per Sector: 512
Sector Count: 990,976
[Physical Drive Information]
Drive Model: SanDisk Cruzer USB Device
Drive Interface Type: USB
Source data size: 483 MB
Sector count: 990976
[Computed Hashes]
MD5 checksum: d116ed8d064ea3939ba650d6beca6efd
SHA1 checksum: 6951e57e929d48973df627cc4b39c7d950749a70

Image Information:
Acquisition started: Fri Jun 12 07:39:02 2009
Acquisition finished: Fri Jun 12 07:49:55 2009
Segment list:
E:\Case-20090611-001\sdcard1.dd.001

Image Verification Results:
Verification started: Fri Jun 12 07:49:56 2009
Verification finished: Fri Jun 12 07:50:00 2009
MD5 checksum: d116ed8d064ea3939ba650d6beca6efd : verified
SHA1 checksum: 6951e57e929d48973df627cc4b39c7d950749a70 : verified

That’s all there is to it!

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 the Treasurer of NM InfraGard.

Known plaintext analysis of encoded strings

0
Posted by jarocki on August 27, 2008 – 4:06 am
Filed under Computer Forensics, Malware Analysis, Memory Analysis
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.