Category Archives: Evidence Acquisition

Helix 3 Pro: First Impressions

0
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.

Mounting Images Using Alternate Superblocks (Follow-Up)

Comments Off
Posted by Hal Pomeranz on October 5, 2009 – 2:16 pm
Filed under Computer Forensics, Evidence Acquisition, Evidence Analysis

Hal Pomeranz, Deer Run Associates

Several months ago, I blogged about using alternate superblocks to fake out the ext3 drivers so you could mount file system images read-only, even if they were needing journal recovery.  However, due to recent changes in the ext file system driver the method I describe in my posting is no longer sufficient.  Happily, there’s a quick work-around.

Let’s try the solution from the end of my previous posting under a more recent Linux kernel:

# mount -o loop,ro,sb=131072 dev_sda2.dd /mnt
mount: wrong fs type, bad option, bad superblock on /dev/loop0,
 missing codepage or helper program, or other error
 In some cases useful info is found in syslog - try
 dmesg | tail  or so

This looks like the original error output we got when using the primary superblock.  Looking at the relevant dmesg output we see something different, however:

[163135.527484] JBD: Ignoring recovery information on journal
[163135.795917] Buffer I/O error on device loop0, logical block 0
[163135.795931] lost page write due to I/O error on loop0
[163135.795944] Buffer I/O error on device loop0, logical block 1
[163135.795949] lost page write due to I/O error on loop0
[163135.795958] Buffer I/O error on device loop0, logical block 2
[163135.795963] lost page write due to I/O error on loop0
[163135.795973] Buffer I/O error on device loop0, logical block 3
[163135.795977] lost page write due to I/O error on loop0
[163135.795986] Buffer I/O error on device loop0, logical block 18
[163135.795991] lost page write due to I/O error on loop0
[163135.795999] Buffer I/O error on device loop0, logical block 32
[163135.796034] lost page write due to I/O error on loop0
[163135.796232] Buffer I/O error on device loop0, logical block 73
[163135.796238] lost page write due to I/O error on loop0
[163135.796248] Buffer I/O error on device loop0, logical block 74
[163135.796253] lost page write due to I/O error on loop0
[163135.796261] Buffer I/O error on device loop0, logical block 94
[163135.796267] lost page write due to I/O error on loop0
[163135.796275] Buffer I/O error on device loop0, logical block 96
[163135.796280] lost page write due to I/O error on loop0
[163135.796516] JBD: recovery failed
[163135.796520] EXT3-fs: error loading journal.

It would appear that even though we’re using an alternate superblock that’s marked as not requiring journal recovery, the ext file system driver is still finding the uncompleted journal entries and trying to apply them.  This is arguably “more correct” behavior than the old driver used, but it doesn’t help us very much.

The simple work-around is to tell the ext file system driver to ignore the journal by forcing the file system to be mounted as ext2:

# mount -t ext2 -o loop,ro,sb=131072 dev_sda2.dd /mnt
# ls /mnt
bin   dev  home    lib         mnt  proc  sbin  usr
boot  etc  initrd  lost+found  opt  root  tmp   var

Excellent!  With this small modification our trick is working again.  Hurrah!

You might well wonder what happens if you just try to mount our image as ext2 without using the alternate superblock.  Unfortunately, simply mounting as ext2 is not sufficient because the primary superblock is still marked as needing journal recovery.  Though I wonder why this flag should be relevant to an ext2 file system, it’s enough to prevent the mount from happening.  So the result is that you need to both mount using an alternate superblock and (at least on modern Linux kernels) mount the file system as ext2 to stop the file system driver from looking at the journal.

Hal Pomeranz is an independent IT/Computer Security consultant and a SANS Faculty Fellow.  He actually discovered this problem when attempting to give a live demo in the middle of a class.  Unfortunately, the solution only occurred to him after class was concluded.  This is one of the reasons why being a SANS Instructor can be so… invigorating.

The Failed Hard Drive, the Toaster Oven, and a Little Faith

3
Posted by jmbutler1 on September 30, 2009 – 1:46 pm
Filed under Computer Forensics, Evidence Acquisition

OK, everyone knows that heat kills electronic components, right?  Never subject any electronic component to heat.  Unless that makes the component work, that is…

Confession is good for the soul, they say, but bad for the reputation.  So I’ll tell the story this way.  You see, there was this “friend of mine” whose hard drive failed.  I mean, it was working fine the night before when I, er, he shut down his computer.  But the next morning he turned it on and all he got was “shicka, shicka, shicka, shicka, shicka,” then a pause, then five more attempts, then five more, and so on until the drive finally said “sorry…” and shut itself off.  Now this guy hasn’t been taking his own advice about backups for a while and – you guessed it – he hadn’t backed up his Quicken off drive since, oh, about December of 2008!

The first attempt was to unplug the power and let the hard drive sit and think about running all day long while he was at work.  One friend told him, “My drive does that all the time.  I just unplug it and plug it back in and it works.”  Sounds good, he thought.  So at the end of the work day, he came back home, plugged it in, held his breath, and powered up.  No joy!  Five more “shickas” and he powered it back off.  Now what?

The next thing, especially when one has theological training, is to have a prayer meeting with one’s wife!  (Seriously.)  He knew it was going to take a miracle at this point to avoid spending an inordinate amount of time and money to get this thing going.  After the prayer meeting, I decided…  ok, no more pretense – I’m the one that hadn’t been practicing what I preach when it comes to backing up…  I decided to try the freezer trick I keep hearing about.  Hadn’t really ever needed it before, but I was getting desperate.  So I put the drive in a zip lock with some silica gel, and stuck the drive in the quick freeze section of my freezer for about 30 minutes or so. 

 

Keep in mind, now, my electronics are good.  The BIOS recognizes and correctly identifies the drive as a 250 GB Western Digital model Wd2500jb-57gvc0.  And remember that I had NO trouble with it up until that morning.  I figured it was worth a shot, although I think Scott Moulton prefers freeze spray to icing down the whole drive.  This has got to work.  Perhaps with a little help from the almighty…  I plug it back in, turn on the computer, and – you guessed it – “shicka” some more.  So I power down.

 

Now, I start thinking – which is a very dangerous thing at times.  Last night when I shut down – when the drive was working just fine – it was warm.  Not cold.  Now, I am trying to get it to run but it is cold, not warm.  Do you see where this is going?

 

I set the toaster oven on about 150 degrees, or so – probably a normal running temp for a lot of devices – and let it warm up.  Then I took the drive and laid it on the rack with the top down and electronics up.  (I didn’t want to cook the circuit board from the bottom element!)  Then I stood by and opened the oven door every 30 seconds or so, and felt the drive with my hand to make sure it wasn’t getting too hot.  I know what a running drive feels like, so I figured I should be able to get it to the right temp without burning the casserole, if you know what I mean. 

After a few minutes, I determined that it felt just like a warm, running drive.  So I pulled it from the oven, took it to the computer, and let it sit for a couple of minutes to equalize.  I knew at that point that, while the outside was crisp, the inside was still warm and gooey.  After equalization of the heat, I plugged it in, powered up, and it ran PERFECTLY!  I was able to use Helix to image the entire 250GB drive over to a new 500GB drive without a single error!

So, here is my theory – If we are working with a drive that:

  • Has not given us a problem before
  • Its electronics are known to be good
  • Was running fine when it was warm and it powered down fine
  • Hasn’t been backed up since Christmas of last year
  • Desperately needs data recovery!

We may try this procedure with the following caveats –

  1. Preheat the oven
  2. Use bake, not toast or broil
  3. Turn the drive upside down when you put it on the rack
  4. Make certain that it does not get too hot!  (Too bad we can’t insert a meat thermometer)  It should never be hot enough to burn you!
  5. Let it sit and equalize the heat before you try plugging it in
  6. DISCLAIMER:  Neither the author of this blog, nor anyone the entire GCFA community or at SANS will be responsible if you end up with a burnt “casserole” and render your drive even worse than it was before you started!
  7. It might work

Please don’t tell my GCFA instructor Rob Lee, or SANS instructor Scott Moulton, that I suggested this.  I don’t want them to think I’ve totally lost my marbles!!!

By the way, Quicken is alive and well.  Oh, and I have 4 copies now of my data files.  (Just in case)  And, by the other way, what I always told my customers was:  a) “If you have done enough work that you would not want to have to do it over, it is time to make a backup,” and b) “You will never fully appreciate backups until you have a catastrophic failure.”  (And that isn’t “If” but “When” you have a catastrophe!)

OK, my soul is better now.  My reputation is probably back where it belongs.  And I have to thank God for the inspiration to even try this.  (For those who do not “believe,” I have to remind you that there are no atheists in foxholes.  At least, that is what I have always heard, although there are differing opinions on the topic.  For me, this computer stuff can be a real battle, sometimes.  I welcome all the help I can get!)

J. Michael Butler, GCFA Gold #00056 GSEC EnCE CISA, is an Information Security Consultant employed by a fortune 500 application service provider who processes approximately half of the $5 trillion of residential mortgage debt in the US. He is a certified computer forensics specialist. In addition, he authored the enterprise wide security incident management plan and information security policies for his corporation. Butler has authored a number of blogs and white papers.  He can be reached at jmbutler_1 at hotmail dot com.

Best Practices In Digital Evidence Collection

6
Posted by paulhenry on September 12, 2009 – 12:01 am
Filed under Computer Forensics, Evidence Acquisition, Memory Analysis

Evidence handling procedures are evolving

Evidence handling is clearly one of the most important aspects in the expanding field of computer forensics. The never-ending innovation in technologies tends to keep best practices in constant flux in effort to meet industry needs. One of the more recent shifts in evidence handling has been the shift away from simply “pulling the plug” as a first step in evidence collection to the adoption of methodologies to acquire evidence “Live” from a suspect computer.

The need for changes in digital evidence collection are being driven by the rapidly changing computing environment:

  • Applications are installed from removable media such as a USB stick and are then virtualized in RAM without a trace on the hard disk
  • Root kits hide within process undetected by the underlying operating system and when using local tools (binaries) – you must analyze memory with trusted binaries
  • Malware is fully RAM resident with no trace of existence on the hard disk
  • Users regularly utilize covert / hidden encrypted files or partitions – areas of the hard drive to hide evidence
  • Popular web browsers offer the user the ability to cover their tracks – log files of user activity are created but deleted when the browser is closed
  • Web 2.0 continues to change the landscape with web based email, blogs, wiki’s and twitter extending storage of user actions / communications beyond the traditional hard disk found on the users machine.

An Introduction to Live Digital Evidence Collection

Effectively Live forensics provides for the collection of digital evidence in an order of collection that is actually based on the life expectancy of the evidence in question. Simply put in all likelihood perhaps the most important evidence to be gathered in digital evidence collection today and for the foreseeable future exists only in the form of the volatile data contained within the computers RAM.

Order of volatility of digital evidence

  1. CPU, cache and register content
  2. Routing table, ARP cache, process table, kernel statistics
  3. Memory
  4. Temporary file system / swap space
  5. Data on hard disk
  6. Remotely logged data
  7. Data contained on archival media

An accepted best practice in digital evidence collection – modified to incorporate live volatile data collection.

Stand Alone Home Computer

For proper evidence preservation, follow these procedures in order (Do not use the computer or search for evidence)

  1. Photograph the computer and scene
  2. If the computer is off do not turn it on
  3. If the computer is on photograph the screen
  4. Collect live data – start with RAM image (Live Response locally or remotely via F-Response) and then collect other live data “as required” such as network connection state, logged on users, currently executing processes etc.
  5. If hard disk encryption detected (using a tool like Zero-View) such as full disk encryption i.e. PGP Disk – collect “logical image” of hard disk using dd.exe, Helix – locally or remotely via F-Response
  6. Unplug the power cord from the back of the tower – If the computer is a laptop and does not shut down when the cord is removed then remove the battery
  7. Diagram and label all cords
  8. Document all device model numbers and serial numbers
  9. Disconnect all cords and devices
  10. Check for HPA then image hard drives using a write blocker, Helix or a hardware imager
  11. Package all components (using anti-static evidence bags)
  12. Seize all additional storage media (create respective images and place original devices in anti-static evidence bags)
  13. Keep all media away from magnets, radio transmitters and other potentially damaging elements
    Collect instruction manuals, documentation and notes
  14. Document all steps used in the seizure
  • Note: * If computer is x64 the author recommends collecting the image of RAM using HBGary FastDump Pro

Live forensics of volatile computer evidence is not necessarily a new or recent development

The author’s first exposure to live forensics in digital evidence collection was nearly 10 years ago during his initial SANS GIAC Certified Forensic Analysis (GCFA) forensics training http://computer-forensics.sans.org/course/computer-forensics-investigation-and-response-98-1. The course included several hands on labs that allowed students to become familiar with tools such as the Windows Forensic Toolkit (WFT) http://www.foolmoon.net/security/ that automated the collection of the volatile data from the subject PC in a forensically sound manner:

  • Only utilizes trusted / know binaries
  • Minimized impact on the subject PC – any impact documented
  • Extensive logging
  • Creates hashes for all tools utilized as well as all data collected

Hence even a decade ago computer forensics evidence collection training went well beyond being limited to simply imaging a hard drive. It included the training necessary to perform the collection of “Live” evidence such as that found in RAM in a forensically sound manner. As an example the methodologies taught at SANS as part of the GCFA training enabled the forensics investigator to include the volatility of all data as part of their consideration in the planning for the evidence collection process. Hence using the training from SANS you were effectively enabled to collect all available and relevant evidence. Starting of course with that data which is most volatile first. Not simply focusing on the limited evidence available on the computer hard drive.

Live forensics resources

There are several other options that have become available that the author has become familiar with to acquire volatile digital evidence – live data including creating an image of RAM in a forensically sound manner (in no specific order):

In closing:

In digital evidence collection today live forensics has become a necessity. Among many forensic professionals both in law enforcement and private practice it has long been recognized that the tradition of first pulling the plug on a PC under examination is an outdated and overly conservative approach that can destroy valuable evidence. Our ability to reliability collect volatile evidence in a forensically sound manner has effectively rendered our legacy best practice of “pulling the plug” as an obsolete methodology.

Decrypting a PointSec Encrypted Drive Using Live View, VMWare, and Helix

4
Posted by jmbutler1 on September 11, 2009 – 2:10 pm
Filed under Computer Forensics, Drive Encryption, Evidence Acquisition, Evidence Analysis

Doing it the HARD way!

Perhaps you remember my previous blog on EnCase and PointSec, which included my plea for Guidance Software and CheckPoint to work together to create a seamless way to decrypt drives without having to go through 20 or 30 steps to get there.  I even wrote, out of desperation, A Case for Decryption of the Original, because it would save time consuming steps and not change the data relevant to an investigation.

Time for an update.  As noted in my last blog on decrypting the original, VMWare no longer recognizes a raw disk as a valid disk image.  Images have to be converted before VMWare will recognize them.

 Here is a new and “improved” method that will result in a COMPLETE decrypted image without changing the original.  It is more painful because more steps are involved, but it works.  (Today).  That being said, I STILL want PointSec, now called “End Point Security,” to work with Guidance to create a driver that could be used to directly access the disk image and decrypt it in EnCase.  This can’t be rocket science, right?  Let me add an encrypted image to the case, key in a password, and access the data.

In the mean time, gather your tools.  You will need the dcfldd for Windows, Live View application, VMWare Server, and Helix for imaging.  (Twice).

  1. Use Helix or your other favorite method to acquire a raw image of the drive to be decrypted.  (There is an open source version of Helix you can download for free, or you can purchase Helix Pro in order to have support, if your prefer.)  [Watch for my upcoming blog on using dcfldd to acquire a raw image.]
  2. Use Live View to convert the raw image to a VMDK file.  (You will have to have the correct versions of VMWare to read the VMDK.  Live View will inform you what version of VMWare you should be running.)
  3. Acquire the PointSec recovery file from the administrator.  (This whole process assumes that you have the administrator ID and password for an administrative install of PointSec.  If you don’t have that, you are reduced to a manual brute force attack.  Good luck!)
  4. Using the PointSec recovery file, create Recovery Media.  (Believe it or not, you need a real floppy disk to do this.  Can’t just create a raw floppy image.  Go figure.)
  5. Create a raw image of the floppy disk in a file on the Windows hard drive using the following command:
    dcfldd if=\\.\A: of=filename.img   
    (requires you have dcfldd installed – available from sourceforge.com
    If you use linux, refer to the floppy drive device (if=/dev/fd0 or as appropriate for your system) as the input file instead of the above syntax.)
  6. Copy the resulting floppy image to your VMWare server where you intend to decrypt the image.
  7. Open VMWare
  8. Select the VM created by Live View, but do NOT start the machine.  (Note that you will not have to create a new virtual machine.  Live View handles all that.  But also note that Live View creates a snapshot and other files as well, which cannot be read directly into EnCase Forensic.  That is why we must do the final acquisition with Helix in this process.)
  9. Add a floppy drive to the VM configuration and select the image created above as the floppy virtual drive.  Make sure it will “Connect on Power On” so that the machine will boot to the floppy

10.  Edit the CD Rom settings and set it to use an ISO image.  Point to a copy of the Helix ISO image.  (This is for acquiring the decrypted drive later, but will not be used for the decryption step.)

11.  Start the Virtual Machine – it will boot to the floppy image.

12.  Enter the requested PointSec administrator credentials and start the decrypt process.  The VMDK image will be decrypted.

13.  Once you have entered the credentials, the program begins decrypting the hard drive image, posting a % complete message as it goes.

14.  Once decrypted, reboot the VM

15.  Hit escape ONE TIME during boot to get Boot Menu.  (If you hit escape too many times, VMWare will blow by the boot menu, but not to worry, because we have left the floppy image set up as the boot drive.  That way the decrypted image will not boot and will, therefore, remain unchanged for maintaining Chain of Custody.)

16.  Select CD-Rom from the boot menu to boot to the Helix CD-Rom.

17.  Run Helix from the CD.

18.  Insert a USB drive with enough spare space to receive the image from the “target” machine.  You will mount it later.  Helix is able to mount NTFS in read/write mode, so your portable drive can be formatted using NTFS.

19.  Once Helix has booted up, use the VMWare toolbar option:  VM/Removable Devices/USB Devices to select the USB drive for writing the acquired decrypted image.

20.  Open a Terminal Session by clicking on the terminal icon in the Helix tool bar.

21.  Execute the following command in order to get root prompt:  sudo su –

22.  Execute the following command in order to determine drive designations:  fdisk –l   [note that is dash lower case L, not I or 1]

23.  Once the USB drive has been added to the VM, if it is formatted using NTFS, use the following command to mount the drive:
mount –t ntfs-3g /dev/sdx1 /media/sdx1 –o force  
(substitute correct letter for x based on the results of your fdisk –l listing)

24.  Create a directory on the USB drive to receive the image.

25.  Change to the directory you just created.

26.  Execute the following command in order to record disk parameters for the case:  fdisk –l > fdisk.txt

27.  Use the following command to acquire the image:
dcfldd if=/dev/sdx of=filename.img conv=noerror,sync hash=md5 hashlog=filename.img.md5

28.  Once completed, for the record, do the following command to save the history of commands into file:
history > history.txt, then save the mount config in case anyone asks about that with:
mount > mount.txt

29.  Now you have a raw, decrypted image that can be read into EnCase and properly acquired for analysis.  Using this method, the original disk is untouched, and the only change to the disk image is that it was decrypted.  This preserves proper Chain of Custody and avoids contamination of the evidence.

 

Whew, that was way too painful.  In my next blog, I will share a method of “slaving” the target drive so that it can be acquired directly into EnCase with the hard disk left in its original state.  Still not as easy as it ought to be, but much easier than the VMWare method.  The only caveat is that the “Slave” method will allow us to image the decrypted partition(s), but will not allow decryption of the entire hard drive.  So at some point, it may be necessary to use the method in this post, not the “Slave” method.

 J. Michael Butler, GCFA Gold #00056, is an Information Security Consultant employed by a fortune 500 application service provider who processes approximately half of the $5 trillion of residential mortgage debt in the US. He is a certified computer forensics specialist. In addition, he authored the enterprise wide security incident management plan and information security policies for his corporation. He can be reached at jmbutler_1 at hotmail dot com.

Acquiring Data from Windows Mobile Devices

5
Posted by eoghancasey on August 12, 2009 – 12:20 pm
Filed under Computer Forensics, Evidence Acquisition, Mobile Device Forensics

During the debut of SEC563 Mobile Device Forensics last week, Eugene Libster from ManTech brought to my attention the open source itsutils package for extracting from Windows Mobile devices. Components of this package, psdread and pdocread, can acquire more data from Windows Mobile devices than many commercial forensic tools, but there are several issues that forensic practitioners need to understand before using these utilities on an evidentiary device. 
 

First, acquiring data using these utilities creates files on the device, necessarily overwriting data. Specifically, an executable file named “itsutils.dll” is copied onto the device, and an error log “itsutils.log” is created on the device. Second, these tools acquire data through a hardware abstraction layer that does not provide direct access to flash memory on the device. Therefore, these utilities do not acquire a complete physical duplicate of flash memory on Windows Mobile devices. 

 

sec563_4_528x90

 

Acquisition of Windows Mobile devices using both pdocread and psdread are described below. The itsutils package requires ActiveSync to be installed on the acquisition system in order to connect with the device, and the Windows Mobile operating system on the target device must be configured to permit unsigned programs to run. To configure a Windows Mobile 6 device to run unsigned code, add the Registry value “HKLM/Security/Policies/Policies/0000101B” with DWORD = 1. The first time a Windows Mobile device is accessed using a component of the itsutils package, a prompt appears on the mobile device requesting that the code be permitted to run, and the message “Copying C:Toolsitsutilsitsutils.dll to WCE:windowsitsutils.dll” is displayed on the command line.

 

Once a Windows Mobile device is connected to an acquisition system, obtaining a copy of storage areas on the device using psdread is relatively straightforward, with a -l option to list the available disks as shown here on an HTC Dash.

 

    C:Toolsitsutils>psdread -l
    C: - VMware Virtual S
    Drive geometry: 0x7a6 cyls, 255 t/cyl 63 s/t 512 b/s -  15.00Gbyte
          disknr=0   fixed disk
    D: - NECVMWar VMware IDE CDR10
    remote disk 1 has 120456 sectors of 512 bytes -  58.82Mbyte
    SerialNr:  01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    remote disk 2 has 121464 sectors of 512 bytes -  59.31Mbyte
    SerialNr:  01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

     

The first two entries in the above list refer to the local disk and CD-ROM drive of the acquisition system. The two subsequent entries referring to remote disks are the system and data storage areas on the attached HTC Dash Windows Mobile device.  The following command options acquire the storage area that contains the most relevant data from a forensic perspective (remote disk 2 on this HTC Dash), starting at 0 and copying 62189568 bytes (121464 sectors x 512 bytes).

 

    C:Toolsitsutils>psdread -2 0 62189568 E:HTC-Dash-psdread.bin
    remote disk 2 has 121464 sectors of 512 bytes -  59.31Mbyte
    SerialNr:  01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    CopySDCardToFile(remote, 2, 0x0, 0x3b4f000, HTC-Dash-psdread.bin)

     

When psdread does not work with a given Windows Mobile device, it may still be possible to acquire data using pdocread. The pdocread utility only acquires individual partitions and sometimes must rely on the Windows disk API, which may restrict the amount of data that can be acquired. Using pdocread to list the available partitions is shown here.

 

    C:Toolsitsutils>pdocread -l
     58.82M (0x3ad1000) DSK1:
    |           2.09M (0x217400) Part00
    |           3.08M (0x313800) Part01
    |          53.65M (0x35a6000) Part02
     59.31M (0x3b4f000) DSK2:
    |          59.06M (0x3b0e800) Part00
    STRG handles:
    handle cfae68ca 59.06M (0x3b0e800)
    handle 2fb7ba2a 53.65M (0x35a6000)
    handle cfb7ba06  3.08M (0x313800)
    handle 2fb7b9be  2.09M (0x217400)
    <cut for length>

     

The first three partitions under DSK1 are related to the base image on the HTC Dash running Windows Mobile 6: Part00 contains an update kernel that is used when upgrading the operating system, Part01 contains the primary kernel, and Part02 stores the ROM image in LZX compressed format. User created files, Windows Mobile folders and files, and other data of interest in a forensic investigation are stored in the partition listed under DSK2.
 

The partition to be imaged can be specified by name or handle, and we generally prefer to use the unique handle specified with -h option. Using the following command and the handle from the previous command output, we start reading at byte zero and read the full length of the partition, which is 59.06M (0×3b0e800 in hexadecimal). 

 

    C:Toolsitsutils>pdocread -v -w -h 0xcfae68ca 0 0x3b0e800 E:HTC-Dash-Dsk2.raw

     

The -v option provides verbose information during the acquisition process, and the -w option specifies that the Windows disk API be used. Attempts to acquire data without the -w option failed the HTC Dash, but is reported to work on some other Windows Mobile devices like the HTC Touch. Additional options are available to specify the block sizes for reading data from the disk and transferring the data via ActiveSync.
 

The file acquired using pdocread contains a TFAT file system that can be loaded into a tool like TSK or EnCase as a raw image, specifying that it is a FAT volume. Similarly, the file acquired using psdread can be loaded into forensic tools as a disk image. The file system hierarchy on a HTC Dash running Windows Mobile 6 is shown below in EnCase. Although file system entries associated with deleted files can be recovered, the contents were overwritten as shown here for a deleted digital photograph stored in the “My DocumentsMy Pictures” folder.
 

Windows Mobile Volume Viewed Using EnCase

Windows Mobile Volume Viewed Using EnCase

 
The commercial forensic tool XACT can acquire the same information as itsutils from certain Windows Mobile devices as demonstrated through hands-on exercises in the SEC563 Mobile Device Forensics class (register now for NS2009 in San Diego, Sept 16 – 20). However, forensic tools have difficulty parsing the file system of certain Windows Mobile devices, and may not display all files and folders. As we emphasize in the class, processing the same mobile device using different methods and tools can have varied results, and processing similar mobile devices using the same tool can have varied results. Therefore, it is important to perform tool validation by comparing the results of multiple tools and examining data at a low level whenever feasible (e.g., using a hex viewer).

Tricking the “script” Command

Comments Off
Posted by Hal Pomeranz on July 29, 2009 – 12:29 pm
Filed under Computer Forensics, Evidence Acquisition, Incident Response, Linux IR

Keeping a record of all of the commands you type as well as their output is obviously useful during a forensic investigation.  On Unix and Linux systems, we have the “script” command which does precisely this.  You run “script <filename>” and the script command spawns a new shell: everything you type and all output you receive in return is automatically captured to the specified file.

From a forensic perspective, however, the classic problem is that script insists on writing its output to a file in the local file system.  This is particularly a problem during the initial stages of incident response when you’re operating on a live system trying to verify whether or not it has been compromised.  If you capture your session with the script command, you may be trampling important data as your output file grows.  Of course you could attach a portable storage device and write your output there, but that could be problematic on many levels.

This topic came up recently when Ed Skoudis and I were working on an article for our Command Line Kung Fu blog (a useful resource for Incident Response professionals, since we provide helpful command line short-cuts using both the Windows and Unix command shells).  During our conversation, I realized that there might be a work-around that allows the script command to send its output over the network.  Sure enough, after a little bit of hacking I came up with a devious little method to accomplish exactly this.

Suppose we had another machine on the same network as the host we are investigating.  Let’s suppose this other machine has IP address 192.168.100.1 and there’s a netcat process listening on port 9999 and redirecting its output to some file (”nc -l 9999 >myoutput”).  Now, on the machine you’re investigating, run the following commands:

$ mkfifo /tmp/fifo
$ cat /tmp/fifo >/dev/tcp/192.168.100.1/9999 &
[1] 1523
$ script -f /tmp/fifo
Script started, file is /tmp/fifo
$

Some explanation is clearly in order here:

  • The mkfifo command creates a special type of object in the file system called a FIFO (short for “first in, first out”).  The FIFO allows one command to write data into this “file” and another command to read data out of it.  This is perfect for our purposes.
  • The next command uses the cat to read data out of the FIFO and redirect that output into /dev/tcp/192.168.100.1/9999.  This “file name” is a specially recognized syntax in the bash shell that means “write the data over the network to host 192.168.100.1 on port 9999/tcp” (for more information see Ed’s excellent “Netcat Without Netcat” presentation).  We use “&” to put this command in the background where it will sit and wait for us to start putting data into the FIFO.
  • Finally we fire up the script command and tell it to write its data into the FIFO.  We also add the “-f” (”flush”) argument so that the script command doesn’t buffer its output– the remote side will see the commands being typed and get the output instantly.  We’re now in the subshell spawned by the script command and anything that happens from here on out should start appearing in the output file on the remote system.

The “/dev/tcp/…” syntax is a useful little bit of bash shell trickery.  But even if you didn’t have this, you could do something similar if your incident response kit included netcat.  Just change the second command in the output above to “cat /tmp/fifo | nc 192.168.100.1 9999″.

The real trick here is obviously knowing how to create and manipulate FIFOs, and for whatever reason this doesn’t seem to be something that’s commonly covered in most Unix classes.  But you have to admit it’s an impressively useful thing to know for situations such as this when you have a command like script that insists only on writing to a local “file”.

Obviously, on principles of strict forensic soundness it must be admitted that creating the FIFO does alter the file system slightly.  The FIFO itself requires an inode, though no data blocks will be consumed.  Also the contents of the directory the FIFO is placed in will be modified.  However, I will point out that many Unix systems are configured by default to use memory-based file systems for directories such as /tmp or /var/run.  If this is the case on the system you’re investigating, I would recommend creating your FIFO in one of these memory-based file systems to minimize any impact to the file system on disk.

Hope you find this little trick useful in future investigations!

Hal Pomeranz, Deer Run Associates, is an independent IT/Computer Security consultant and a SANS Faculty Fellow.  He spends far too much time hanging out in the sketchy parts of the Unix operating system.

Dealing with PC Guardian’s Encryption Plus Hard Drive (EPHD)

Comments Off
Posted by Keven Murphy on July 13, 2009 – 1:42 pm
Filed under Computer Forensics, Drive Encryption, Evidence Acquisition, Mobile Device Forensics

Dealing with EPHD, or PC Guardian’s Encryption Plus is not too bad provided it has been setup correctly. By being setup correctly, I mean that the PC administrators have created an account that anyone can use to get past the hard drive encryption. This account and password needs to be treated just like the admin account. Only those people who need to know it, should have the userid and password.

On a side note: If your corporation has not implemented for your laptops and mobile devices, I have to ask why not? Hard drive encryption is much cheaper to implement then letting your corporate secrets and customer data out into the public.

Before We Begin

Before doing anything talk with your management and legal with regard to how they want you to proceed with imaging the encrypted devices. They may feel that this methodology is not right for them. The other aspect to be aware of is do you image the drive in its encrypted state and then use the technique below to get a decrypted image or do you do the reverse? Either way has caveats. Let’s say the hard drive fails during the imaging. If you have imaged the encrypted drive in the encrypted state, the question is will it boot up so that you can decrypt it, or do you need to find another solution to decrypt what you have? As it stands there is not much you can do with an encrypted drive. If you imaged the drive using the method below and thus have a decrypted portion of the drive, will it be good enough for court? Will it have the evidence you are looking for?

For myself, I image the encrypted drive first. Then decrypt the hard drive.

Using LiveView

LiveView will create a VMWare machine from a dd image or physical disk drive hooked up to a read-only write blocker. This allows the forensics examiner to boot up the drive and see it from a user’s point of view. The big plus to this is that you can make an image of the decrypted drive. The downside is that you effectively can change data on the VMWare version of the drive while making an image. For example, Windows will start installing drivers for the “new” devices it sees after it boots up for the first time. Secondly, anything you do on the machine will change data on the VMWare version of the drive.

So why do it this way?

First, I have had issues getting the decrypter program that Guardian supplies to decrypt the drives to work correctly. Usually what happens is that I get a partial decryption. If I am using the original drive (a big forensic no-no), then I lost the data I need. Secondly, it takes an extremely long time to decrypt the drive. I have found that it saves some time by making a dd image of the original, then use the dd image and LiveView to get a decrypted version of the hard drive. The only thing left is to be able to explain any changes that occur while making the image.

Here is one way to configure LiveView:

LiveView

1) Configure your RAM size to 512+ if you machine has it. This helps with the virtual machine speed. The more RAM it has the faster it will be to a point.

2) Select your dd image

3) Select your output directory.

4) Click on Generate Config Only to only generate the config and not autostart VMWare.

5) Lastly, click on the start button.

VMWare Configuration

Since I am using VMWare Server, I need to add in a network interface so that I can send the image through the VMWare network. To do this just bring up VMWare Server, then:

1) Click on Edit virtual machine settings

2) Click on the Add button and click on Next

3) Click on Ethernet Adapter and click on Next

4) Select Host-Only and click on Finish

You want to use Host-Only as you have no idea what kind of software will kick off when the machine boots. Doing it this way will contain any malware to just your physical box. Think of it this way, if the machine has malware on it that starts scanning the network upon starting up, it could take down network devices or worse yet start reporting what it finds to a third party. The key here is isolation. Plus for the truly paranoid, you can install tcpdump/snort on you physical machine and monitor that while you create your images.

Imaging

Once the virtual machine is up and your logged in as an Administrator, you can start imaging the hard drive. There is a variety of methods to doing this. Since I am using VMware Server here is one of the methods I use:

Physical Machine

  1. On the physical machine bring up a DOS window and change directory  into the where you want to save the image.
  2. Execute: nc -l -p {port} | dcfldd of={image file} hash=sha512,md5 hashwindow=512 sha512log={image file}.sha512 md5log={image}.md5 status=on

Virtual Machine

  1. On the virtual machine, I use either a mounted ISO or CD-ROM with Helix on it and bring up a DOS window.
  2. In the DOS window (assuming D: is the CD-ROM drive): d:\IR\Cygwin\dcfldd if=\\.\C: hash=md5 hashwindow=0 bs=512 conv=noerror,notrunc,sync status=on | d:\IR\Cygwin\nc.exe -w30 {IP address of physical machine} {port}

Now it just a matter of waiting for the imaging process to complete. I usually screen lock the physical machine and come back the next day to check on it as I have a slow imaging machine. The time it takes to image this way really depends on the equipment you are using. For example, there have been times where the drive I am imaging is connected via a USB write-blocker and the drive I am saving the image to is USB. In that case it may take 12+ hours to do a 40 gig drive. I have found that saving the image off to a network drive via netcat/samba share to be faster than USB/Firewire.

Once the imaging is done, I take a screenshot of the VMWare session as the MD5 hash is shown in the DOS window and save it with the image. Then I compare the MD5hash from the screenshot with the MD5 hash from the image. The hashes should match.

Good luck. I know it is a slow process to decrypt the drive, but I have had good success with it.

Keven Murphy, GCFA Gold #24, is the Senior Forensics/Incident Handler to General Dynamics Land Systems.

System State Backup

1
Posted by craigswright on July 3, 2009 – 3:36 pm
Filed under Computer Forensics, Evidence Acquisition, Incident Response, Windows IR

The Windows system state backup is in effect a backup of the complete system. Everything that is present within the system will be copied as backup so that no data or information is lost whenever there is a system crash or corruption of the driver files, if certain system files stop the system from functioning properly. To perform a forensic analysis of evidence on a Windows system, backing up a system’s registry is insufficient. An extensive backup of data is essential so that the system can be secured against any malfunctions.

This is most commonly an issue when conducting a live analysis.

A full system state backup saves the:

  • Active Directory (NTDS),
  • Windows Boot files,
  • COM+ class registration database,
  • Registry,
  • System volume (SYSVOL), and
  • The IIS metabase.

The process to create a System State Backup is simple:

  • Go to Start > Programs > Accessories > System Tools > Backup,
  • In the Backup tab, check the System State box,
  • Select the Schedule Job tab and Select Add Job button,
  • Select Yes and choose “media options”
  1. Media type,
  2. Location, and
  3. Backup name.
  • Select Next and check that the Normal option is selected, and then Select Next again.
  • When backing-up to disk there is no need to verify data. Select Next.
  • Choose if you want to append to or replace an existing backup. Select Next.
  • Schedule the backup. Select Next.
  • Set the account to one that has the required permission to run the backup.
  • Select Finish.

A good deal of information is available from and is stored within the Windows system state. Don’t overlook it.

Craig Wright is a Director with Information Defense in Australia. He holds both the GSE-Malware and GSE-Compliance certifications from GIAC. He is a perpetual student with numerous post graduate degrees including an LLM specializing in international commercial law and ecommerce law as well as working on his 4th IT focused Masters degree (Masters in System Development) from Charles Stuart University where he is helping to launch a Masters degree in digital forensics. He is engaged in his second doctorate, a PhD on the quantification of information system risk at CSU.

Top 7 ways investigators catch criminals using Mobile Device Forensics

5
Posted by eoghancasey on July 1, 2009 – 11:59 am
Filed under Evidence Acquisition, Evidence Analysis, Mobile Device Forensics

Modern day mobile devices are a double-edged sword, creating new security risks while providing valuable sources of evidence for digital forensic investigators. Their ever expanding capabilities make mobile devices more like personal computers that accompany us as we navigate the world. Digital forensic investigators can use information stored on and generated by mobile devices to reconstruct our movements, communications, and other personal details.

 

If you need to extract information from cell phones, smart phones, and other mobile devices, or are concerned about the security of data on such devices, here are some important things you should know.

 

Bypassing Security Codes: Digital forensic investigators can extract the security code from some locked mobile devices using specialized tools. The screenshot below shows the security code “12345″ recovered from a Nokia 6230 using  .XRY (subscriber identifier redacted). Being able to bypass security mechanisms on a mobile device enables digital forensic investigators to acquire data from the device with forensic software. 

Nokia 6230 security code recovered using .XRY

 

Safe SIM Card: Inserting the wrong SIM card into a cell phone destroys some useful data in memory. To mitigate this issue, digital forensic investigators can create “safe” SIM cards designed for forensic examination purposes.

 

Live Acquisition: Removing the battery from a cell phone before performing a forensic acquisition may destroy valuable evidence. In some cases, to ensure that all available evidence is preserved, digital forensic investigators will leave a mobile device powered on until a forensic acquisition can be performed, taking precautions to prevent external influences from altering data on the device.

 

Trusted Time Source: Even if the clock on the evidentiary device is incorrect, some time stamps on the device may still be accurate because they are generated by system on the core network. For instance, the time stamp in a received SMS message is set by the Short Message Service Center, not by the phone.

 

Tracking Movements: Some mobile devices store location-based information associated with certain media and actions on the device. Digital forensic investigators can recover this information to determine the geographic location of the mobile device at a particular time. For instance, the following screenshot shows Exif metadata extracted using JPEGsnoop from a digital photograph taken using a G1 mobile device. This metadata includes the date and time the photograph was taken and GPS coordinates of the location (location details redacted).

JPEGsnoop used to extract Exif data from a GPS tagged digital photograph

 

Recovering Deleted Data: When the user clears the call log from a cell phone, it may still be recoverable with relative ease. Therefore, even when call logs are not displayed on the device, digital forensic investigators may be able to view details about dialed, received, and missed calls on the device using readily available tools.

 

Getting Physical: Digital forensic investigators can recover substantial amounts of deleted data from an increasing number of mobile devices by acquiring and analyzing the full contents of memory. This screenshot shows a physical memory acquisition of a Nokia 6610 using the Sarasoft application via a Twister flasher box.    

 

Physical memory dump of Nokia 6610 using Twister flasher box and Sarasoft

 

Deleted data like photographs, call logs, and traces of user activities (e.g., Web browsing and file viewing) recovered from a mobile device can provide digital forensic investigators with some of the most useful and incriminating evidence in a case. 

 

To learn how to perform these and other Mobile Device Forensics techniques, joins us for the debut of SEC563 Mobile Device Forensics in Baltimore, July 27 – 31 (register here). This is an intensive technical course with plenty of hands-on exercises to familiarize you with the inner workings of various mobile devices and show you the benefits and limitations of various approaches and tools. We not only demonstrate state-of-the-art mobile forensic tools and techniques, we peel back the layers of digital evidence on mobile devices to show what is going on behind the scenes. In this way, you obtain a deeper knowledge of the information you rely on when investigating cases involving mobile devices.

SEC563 - Mobile Device Forensics

 

Eoghan Casey is founding partner of cmdLabs (http://www.cmdlabs.com/) , author of the foundational book Digital Evidence and Computer Crime, and coauthor of Malware Forensics. He has been involved in a wide range of digital investigations, including network intrusions, fraud, violent crimes, identity theft, and on-line criminal activity. He has testified in civil and criminal cases, and has submitted expert reports and prepared trial exhibits for computer forensic and cyber-crime cases.