Sunday, January 27, 2008

XPSP3 - How this is going to affect RAM Analysis?

Well to sum up XPSP3 (for RAM Analysis) I’d say the prognosis is great.

The key offsets that I look for in the EPROCESS (Page Directory Base, Create Time Low, Create Time High, Exit Time Low, Exit Time High, PID, Image File Name) appear to be the same as XPSP2. The Kernel Program (NTOSKRNL.exe) I use to gauge the OS Version of the RAM is also similar to previous versions.

I tried to use Windbg (v6.8.0004.0) to confirm the EPROCESS Structure but I was unable to find the new Symbols at Microsoft.

The following is my Grep Search for determining the OS Version in a RAM Analysis:
\x4E\x00\x54\x00\x20\x00\x4B\x00\x65\x00\x72\x00\x6E\x00\x65\x00\x6C\x00\x20\x00\x26
\x00\x20\x00\x53\x00\x79\x00\x73\x00\x74\x00\x65\x00\x6D\x00\x00\x00\x00\x00[\x00-\xFF]
\x00[\x00-FF]\x00\x01\x00\x46\x00\x69\x00\x6C\x00\x65\x00\x56\x00\x65\x00\x72\x00\x73
\x00\x69\x00\x6F\x00\x6E\x00\x00\x00\x00\x00

The above GREP was run against a VMEM file running XPSP3 and returned the following:

N•T• •K•e•r•n•e•l• •&• •S•y•s•t•e•m•••••b•!•••
F•i•l•e•V•e•r•s•i•o•n•••••5•.•1•.•2•6•0•0•.•3•2•6•4• •(•x•p•s•p•.•0•7•1•1•3•0•-•1•4•2•7•)

The numeration is added below:
*** Fixed Thanks to Andreas Schuster****•

Windows 2000 = 5.0.2195.x
Windows XP 32bit = 5.1.2600.x
Windows XP 64bit and Server 2003 = 5.2.3790.x
Windows Vista = 6.0.6000.x


The following is a list of the EPROCESS Information for all current versions of Windows. The XPSP3 entries are tentative and identified from hex analysis of a RAM Acquisition and should be confirmed using WinDbg as soon as possible. PTFinder and PTfinderFE work on XPSP3 just use the XPSP2 option.

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!!!