Wednesday, January 23, 2008

Speaking Engagement


I am presenting a two-day course on RAM Acquisition and RAM Analysis at the International Association of Computer Investigative Specialists (IACIS) 2008 CFCE Course between April 28, 2008 through May 9, 2008 in Orlando, Florida.

My sponsor is Digital Intelligence.


The following is a quick synopsis of the training:

RAM Analysis – Vista and Beyond
Everything run on a computer passes through the RAM at one time or another. The trick is being able to identify data found in a RAM capture and relate it back to the item that originally created it. This two day training session includes a very "hands-on" lab to train on different tools and using various methods for collecting RAM from a running machine.

For more information go to the IACIS Website

Tuesday, January 22, 2008

RAM Capture Methodology

Guillotine Steps and Conditions

Conditions:

Machine is On but Not Logged In.

Machine is On / Logged On / Not Running Encryption. (Bitlocker, Best Crypt…). (If running encryption make logical image immediately.)

You Have Physical Access to the Machine.

You Know What a Hard Drive Molex Cable Looks Like…

(Easiest Setup – the Computer Has a CD\DVD Drive and Empty USB Port …)

Steps:

  1. Open Cover to Computer to Access Hard Drive(s)
  2. Place a Knoppix Boot in the CD- Leave Tray Open (I used Damn Small Linux)
  3. Located Molex Power Cord to Hard Drive running OS.
  4. Pull Molex Cable from Hard Drive (If More then 2 Hard Drives - Consider Cutting Cables with Insolated Tools)
  1. Reset the Computer As Fast AS POSSIBLE. Use a Reset Button or Hit the “Off/On” Button. The Goal is get the Machine to Re-Boot to the Knoppix as Fast as Possible.
  2. Prior to the Re-Boot Insert the USB Drive to Capture Memory Dump (Format of USB: FAT32). Push in CD Tray if needed.
  1. Boot in Knoppix
  2. Boot Knoppix to Command Line (Option in Damn Small Linux is “dsl 2”).
  3. Mount the USB Drive (mount /dev/sda1).
  4. dd the Memory (for example if dd=/dev/mem of=/mnt/sda1/NAMEofDump.dd ) if=input file of=output file
  5. Unmount USB or Shutdown (shutdown –h now)
  6. Analyze DD with some Good Tools. (Like my RAM Enscript)

"Guillotine Method" for RAM Acquisition.


Scenario#1 You come up to a desktop computer that you have legal authority to forensically analyze. The computer is powered up but sitting at the Windows Login Screen. No chance to get an image of the RAM so you pull the plug from the back of the machine and retreat to the lab. At the lab you discover that the hard drive has been encrypted with BITLOCKER. What could you have done different at the scene to possibly obtain more information from the computer prior to shut down?


Scenario#2 A desktop computer running Vista is on and logged in with no apparent encryption. You attempt to dd the RAM (with any tool of your choice) to no avail, why? Because no matter the tool you use it requires an Administrator Username and Password that you do not have. So your choice is simple just pull the cord from the back of the case in frustration.

As you know, there are no currently available tools (or protocols) to acquire RAM while the machine is at the Windows Login Screen. There is also some VISTA Builds that require an Administrator Username and Password to make a image of the RAM. Here’s a new protocol that might work in these situtation and that I call the “Guillotine Method” for RAM Acquisition.

Basically GUILLOTINE runs on the following idea. Instead of pulling the power cord from the back of the machine, pull the power cord from the back of the hard drive running the OS, thereby stopping all writes to the drive. Then (fast as possible) reboot the machine into your favorite flavor of Knoppix (Command Line Mode) and dd the RAM Memory to USB.

Even if a USER had recently booted up the machine you still might find the SAM and SYSTEM files in the memory. If a USER recently logged out then you might have a ton of information including the NTUSER.DAT, $MFT and other files valuable to your investigation. (Remember if you have the SAM and SYSTEM (SYSKEY) files you have a chance to get the USERNAMES and PASSWORDS which could be another piece of the forensic puzzle)

According to Chow, Farmer and Venema- “…Computer People who know more then I!”

“Although most computers automatically zero main memory upon rebooting- many do not. This is generally independent of the OS”

“Motherboards fueled by Intel CPUs tend to have BIOS settings that clear main memory upon restart, but there is no requirement for this to happen”

So the Guillotine Method does not work in all cases but it works better then just pulling the plug from the back of the machine and calling it quits. So far I have had a laboratory success rate of approximately 60% on various machines (requires a more systematic approach to testing). It seems to work more frequently on higher-end machines with more RAM then on older machines with less RAM. Also machines with RESET buttons seem to work better then trying to hammer on the power buttons to get the computer to reboot.

You can also remove the cord from the back of the machine (after pulling the power on the hard drive) and reboot. But taking the power cord out and putting it back in (as fast as you can) usually degrades the data in the RAM (a number off the top of my head is 10-15% degradation – also needs a more systemic approach to testing). Which is still better chances then what we had before which was zero.

I came up with the term Guillotine because after you pull the power plug from the hard drive Windows will still respond for a second of two. “The lights are on but no one is home…”

This method is extreme and has not been thoroughly tested. It could be dangerous putting your hand into a live machine and removing the power from a live drive. For a great example ---When I tried this at home on my kids crappy little computer I stuck my hand into the motherboard fan while it was running. I didn’t hurt my hand but I bent the metal blades of my fan (Thanks to Steph B. for the replacement). BTW the Guillotine Method didn’t work on that machine.

I haven’t tried this method with any laptops (yet) .

Perform the “Guillotine Method” Ram Capture at Your Own Risk.

Not Responsible for any damage, problems or loss.

--------------------You make Your Own Choices- Take Responsibility for Them---------------

Thanks to Matt P. for his Help on This!!!

Saturday, December 1, 2007

User Assist Data in the RAM Dump

Lately some good information has been posted on the web regarding the importance of the USER ASSIST.

Especially by Didier Stevens (http://blog.didierstevens.com/programs/userassist/) and Harlan Carvey (http://windowsir.blogspot.com/)

Recently and completely by coincidence I found some USER ASSIST Remnants in the RAM Dumps I was analyzing. The information was obfuscated by ROT-13 but I found quite a bit of useful information. For more ROT-13 Fun (and a Microsoft Easter Egg) check out the shdoclc.dll from your system32 folder.

I used the good old dfrws2005-physical-memory1.dmp for this demonstration but all the RAM Dumps ( Vista , XPSP2, XPSP1 and WinServer2003) I reviewed appear to have similarities.

I started with a simple search of HRZR_EHACNGU (which is “UEME_RUNPATH”).

It returned 35 hits. The following is a partial sample of the search hits:

HRZR_EHACNGU:P:\Flfcerc\FLFCERC.RKR

HRZR_EHACNGU:P:\Cebtenz Svyrf\CbjreCnary\Cebtenz\CpsZte.rkre

HRZR_EHACNGU:P:\Cebtenz Svyrf\FBAL\Fbal Abgrobbx Frghc\FAFrghc.rkrv

HRZR_EHACNGU:P:\JVAAG\flfgrz32\zzp.rkr

HRZR_EHACNGU:P:\JVAAG\flfgrz32\pzq.rkr

HRZR_EHACNGU:P:\JVAAG\flfgrz32\ehaqyy32.rkr.RU0

HRZR_EHACNGU:P:\Cebtenz Svyrf\Fhccbeg.pbz\Pyvrag\ova\gtpzq.rkr

HRZR_EHACNGU:P:\Cebtenz Svyrf\Fbal\Wbt Qvny Hgvyvgl\WbtFrei2.rkr

HRZR_EHACNGU:Q:\0102901.FAP\Frghc.rkr

HRZR_EHACNGU:P:\fbalflf\purpxQZV.rkr

Decrypted using ROT13 (http://www.download.com/3001-2092_4-1535479.html)

UEME_RUNPATH:C:\Sysprep\SYSPREP.EXE

UEME_RUNPATH:C:\Program Files\PowerPanel\Program\PcfMgr.exer

UEME_RUNPATH:C:\Program Files\SONY\Sony Notebook Setup\SNSetup.exei

UEME_RUNPATH:C:\WINNT\system32\mmc.exe

UEME_RUNPATH:C:\WINNT\system32\cmd.exe

UEME_RUNPATH:C:\WINNT\system32\rundll32.exe.EH0

UEME_RUNPATH:C:\Program Files\Support.com\Client\bin\tgcmd.exe

UEME_RUNPATH:C:\Program Files\Sony\Jog Dial Utility\JogServ2.exe

UEME_RUNPATH:D:\0102901.SNC\Setup.exe

UEME_RUNPATH:C:\sonysys\checkDMI.exe

Another search of .yax (“.lnk”) is also proves to be useful

HRZR_EHACVQY:%pfvqy2%\Fbal Abgrobbx Frghc\Fbal Abgrobbx Frghc.yax

HRZR_EHACVQY:P:\Qbphzragf naq Frggvatf\Nyy Hfref\Fgneg Zrah\I N V B\INVB Fhccbeg Ntrag.yax

HRZR_EHACVQY:%pfvqy2%\Npprffbevrf\Flfgrz Gbbyf\Punenpgre Znc.yax

HRZR_EHACVQY:%pfvqy2%\Argfpncr Pbzzhavpngbe\Hgvyvgvrf\Thrfg.yax

Decrypted.....

UEME_RUNPIDL:%csidl2%\Sony Notebook Setup\Sony Notebook Setup.lnk

UEME_RUNPIDL:C:\Documents and Settings\All Users\Start Menu\V A I O\VAIO Support Agent.lnk

UEME_RUNPIDL:%csidl2%\Accessories\System Tools\Character Map.lnk

UEME_RUNPIDL:%csidl2%\Netscape Communicator\Utilities\Guest.lnk

You get the idea!

Now the follow-up is to try and find the same date/time stamps or counter information that is in the USER ASSIST Keys

Thursday, November 22, 2007

RAM Enscript


What will this ENSCRIPT find in a RAM Dump File?

1. Running and Exited Process Information
2. Operations System Information
3. USER ASSIST Remnants

See Output: OS Version Processes User Assist

BACKGROUND:

When I originally started I wanted to be able to search a RAM Dump file and find some of the important stuff like the EPROCESS Headers. I then wanted the OS information from the dump files I also wanted to use just one tool.

So this Enscript was redesigned from the guts of the Encase Example “File Finder Enscript”. Basically I took out most of what I didn’t need and added some complex magic numbers and specific decoding for the hits. Please see the CAUTIONS prior to copying and using this Enscript.

I could not have made this Enscript with out the prior work and help of Andreas Schuster and Harlan Carvey.

To affectively run the Enscript follow these steps:

1. Run Enscript and check box the “OS Version“ with the Bookmark Folder Name of ”OS Version”.
2. To find the Processes - Check the OS Version found in step #1 and re-run the Enscript choosing the correct OS(For Example “Vista Processes” to Find Vista Processes) and put in “Processes” Bookmark Folder
3. For USER Assist Remnants run the Enscript a third time checking “User Assist” to the User Assist Bookmark
4. Review your findings. Use the REPORT view for the “Best Look”.

You can check more then one item and the Enscript still runs properly but all of your information will be bookmarked into the same folder

Friday, November 2, 2007

RAM Enscript Download

Download RAM Enscript (SourceForge)

Concerns---Bugs---Caution

Concerns

1. Enscript is in BETA and still evolving!
2. VISTA Process Search String might not collect all processes (still researching to find out what is missed. An estimate of how many are found- probably 90-95% Solution AS IS.)

Known Bug

1. Microsoft Windows XP 2003 Edition is SP1 (Version 5.2600) reports as XPSP2 so check your findings

Caution- Caution-Caution-Caution-

Be Careful Not to Overwrite Your Default Enscripts --- the Best Plan is to Copy Your Enscripts Prior to Using the Ram Analysis Enscript and to run this Enscript form another location (like CD-ROM Drive )

This Script Does Not Play Well with Other Enscripts Because I have Modified Some of the Common Files………………You Are Warned……….