Winen.exe - RAM Imaging Tool Included in New Version of Encase

Today when I downloaded the latest version of Encase (6.11.0.43) I discovered winen.exe in the Encase Program Folder. Apparently winen.exe is the new RAM Acquisition Tool Provided by Guidance. Winen.exe is suppose to work on all variations of Windows higher then 2000.

A search of Guidance Support Portal and I was able to down Winen.pdf. (Guidance Forum Access Required - 3 pages).

The Winen Executable can run as a command line tool, user prompt or from a configuration file. You can run Winen.exe from a USB drive that you plug into the Target Machine. You do need Local Administrator Privilege (which can be difficult to get- sometimes!).

If you can run Winen.exe from a USB Drive and it will prompt you for the required information needed to create the image file.

If you set up a configuration (Config) file you can speed things up.

Setting Up a Configuration File.
I created the following Config File:


As you can see I really placed the name of the image(Evidence Name)in the Evidence Path. In the Evidence Name Path I also put in the Evidence Name. This is so when I run the program it will automatically save my image file to the USB Device I am running it from.

In my example I will create a RAM_ACQ.e01 file in the same directory as I have Winen.exe installed on.

Batch File
I then created a batch file with the following line:
winen -f winen.config

“winen” is the executable to run
“-f” is the option for a Config File
“winen.config” is the name of my Config File (Must be in same path as Winen.exe)

Run the Batch file from your USB and you will automatically save you image file to your USB Drive.

Final Tweak
You can also change the name of winen.exe to something benign sounding (e.g. “sys32.exe”) to make it more difficult to identify by your target.

Using your RAM Acquisition e01 File.
Once the RAM image is created you can get information out of it by Using my RAM Enscript.

You can also use PtfinderFE on the RAM Image but you have to strip the embedded e01 data from your image file. My favorite way is by opening the image up in FTK Imager and export the unallocated space out. You could do the same thing in Encase.


FootPrint

Winen.exe will use approximately 2.8 Mb of RAM which might also be found in the PageFile.

The following keys will be created or altered:

HKEY_LOCAL_MACHINE\SYSTEM\ \Enum\Root\ LEGACY_WINEN_
HKEY_LOCAL_MACHINE\SYSTEM\ \Services\ winen_
(Acording to the Winen.pdf)

Changes regarding adding a USB would also apply (e.g. USBStor in the Registry).

The batch file(cmd.exe) and Winen.exe (in the picture) as they appear in a PtfinderFE Graphic.

KntTools is still my RAM Acquisition tool of choice.

I am presenting a two-day course on RAM Acquisition and RAM Analysis at Digital Intelligence. The course is June 10-12, 2008 and is FREE.

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.

BIOS Magic Numbers in RAM (Beta)

A colleague of mine approached me after teaching a class on finding information in RAM. He asked me to prove a particular RAM acquisition came form a particular machine. My first thought was to run to the remnants from the registry. But do to paging of the registry and many false positives this proved a little more difficult then I originally thought... But as you guessed by the title I then found the information from the machine’s BIOS.

1. Using Encase create the following GREP Expression:

\x00\x14\x00\x00\x01\x02..\x03

2. Run against the DFRWS Dump and review your findings:

The information contained in the BIOS is pretty substantial often including make, model and serial number of the computer the data was collected

So far the BIOS Magic Numbers have found the BIOS Information on every RAM Acquisition I have tested it on. (Win2000 to Vista).

Future Work:
1. Find the Length of the BIOS Information or a Good Footer.
2. Place in RAM Enscript

RAM Enscript Version 1.0

RAM ENSCRIPT UPDATED!!! Download

The new RAM Enscript contains:
OS Identification
Processes (Exited / Running)
Registry Remnants (UserAssist)
MSHTML Remnants
MFT Parser.

Runs against RAM Dumps from Windows 2000 to Vista.

Many Thanks to the First RAM Analysis Advance Class at IACIS- Thanks for the Hard Work.

Practical of “15 Minute Virus Analysis”

I want to show a practical of my “15 Minute Virus Analysis”

You must download the RADA Virus if you want to “play” along. The RADA Virus is a REAL VIRUS SO BE CAREFUL…

The RADA VIRUS was created several years ago to test other geeks participating in the HONEYNET Project. Also download one of the best solutions to the RADA Challenge (But don’t read the solution, yet…).

Make three folders in you working directory called: Baseline, Infected and Start_and_Stop. Start your machine (After you clone your pristine VMWARE Win2000 Machine). When you machine completely boots suspend your machine. Another term often used for suspend is “pause” because the VMWARE “Suspend” Button looks just like a regular “Pause” button. . Copy the VMEM file from you VM Directory into your working directory titled” Baseline”.

In my example I am copying the VMEM file from my VMWARE Machine Called Win2000-Rada.VMEM to the working “Baseline” Folder.

Now Resume the machine and add the RADA Virus. I choose to originally copy the virus to a CD so I place the CD in the machine and copy RADA to a Folder called "Virus" on my Desktop.

Now double click on RADA. Wait a second and “Suspend” the machine.

If you did not run the Connection Wizard prior to infection you will probably see the following:


Copy the VMEM file to you “Infected” Folder. Resume your machine. Using your machine’s own functions restart the machine. Once the machine reboots suspend the machine again and copy the VMEM file to the Stop_and_Start Folder.

So now we have 3 VMEM files copied into our three working folders.

Run PTFinder or PTFinderFE against the “baseline” VMEM and review the chart.

Now run PTFinder or PTFinderFE against the “Infected” VMEM and review you chart. You should see something like the following:

In our example the Offset of RADA= 0x15a4d60

To make my life easier I just copy cmd.exe, lspm.exe and p2x588.dll (needed by lspm.exe to run) into my “Infected” working directory. Run cmd.exe which opens to your working folder and type the following:

lspm Win2000-Rada 0x15a4d60 (and Enter)

Rada.dmp is created and put in the “Infected” Working Folder. Rada.dmp is a copy of the RADA.Exe Program as copied out of volatile memory.

Open Rada.dmp with AnalogX’s TextScan and look for important information. The following is a truncated sample of the text taken from my exam.


72457 Unichar 42 http://10.10.10.10/RaDa/RaDa_commands.html
75214 Unichar 20 C:\RaDa\bin\RaDa.exe
95754 Unichar 42 http://10.10.10.10/RaDa/RaDa_commands.html
102470 Unichar 55 HKLM\Software\Microsoft\Windows\CurrentVersion\Run\RaDa
103114 Unichar 27 C:\WINNT\System32\wshom.ocx
105509 Unichar 49 C:\Program Files\Internet Explorer\iexplore.exe
112221 Unichar 29 pec=C:\WINNT\system32\cmd.exe
122742 Unichar 42 http://10.10.10.10/RaDa/RaDa_commands.html
188853 Char 40 !This program is the binary of SotM 32..
197922 Unichar 23 http://10.10.10.10/RaDa
197974 Unichar 18 RaDa_commands.html
198038 Unichar 12 download.cgi
198070 Unichar 10 upload.cgi
198098 Unichar 11 C:\RaDa\tmp
198150 Unichar 51 HKLM\Software\Microsoft\Windows\CurrentVersion\Run\
198294 Unichar 11 C:\RaDa\bin
198346 Unichar 51 HKLM\Software\VMware Inc.\VMware Tools\InstallPath
198454 Unichar 36 Starting DDoS Smurf remote attack...
198611 Char 15 Command_install
198643 Char 53 You can learn a lot playing funny security challenges
198747 Char 13 Command_usage
198763 Char 12 Command_exit
198779 Char 12 Command_conf
198835 Char 10 Command_go
198847 Char 17 Command_uninstall
199577 Unichar 15 http://192.168.
199613 Unichar 14 http://172.16.
199649 Unichar 10 http://10.
199685 Unichar 28 InternetExplorer.Application
199813 Unichar 11 about:blank
199985 Unichar 10 screenshot
200026 Unichar 11 Application
200096 Unichar 44 Scan Of The Month 32 (SotM) - September 2004
200240 Unichar 40 http://www.honeynet.org/scans/index.html
200328 Unichar 43 Copyright (C) 2004 Raul Siles & David Perez
200420 Unichar 25
200885 Unichar 41
201145 Unichar 38 "Content-Disposition: form-data; name="""
201257 Unichar 11 Submit Form
201297 Unichar 44 Content-Type: multipart/form-data; boundary=
201442 Unichar 18 application/upload
201486 Unichar 15 ADODB.Recordset
201634 Unichar 47 "Content-Disposition: form-data; name=""{field}"";"
201734 Unichar 18 " filename=""{file}"""
201778 Unichar 18 Content-Type: {ct}
202062 Unichar 50 Copyright (C) 2001 Antonin Foller PSTRUH Software
203147 Unichar 39 Authors: Raul Siles & David Perez 2004


Wow there is a lot of information in the little DMP File. Now go look at the Solution you downloaded. Our 15 minutes of research is not too shabby.

Fifteen Minute Malaware Analysis

Tools:
1. VMWARE Workstation or VMWARE Server (Sever=free)
2. Windows 2000 (Small$)
3. TextScan - Free (by AnalogX)
http://www.analogx.com/contents/download/program/textscan.htm
4. PtfinderFE - Free (PTFINDER by Andreas Schuster and Front-End by Richard McQuown)
5. LSPM (SourceForge)- Free (by Harlan Carvey)

Steps:
1. Create a VMWARE Windows 2000 Machine. Keep the RAM 256 MB or less (Saves Processing Time).
2. Start VMWARE 2000 Machine. Pause the machine.
3. Place a copy of the .VMEM file into a folder called "Baseline".
4. Restart your machine and add your virus. I like to run the virus from the desktop.
5. Pause your machine and place your .VMEM file into a new folder called "Infected".
6. Restart your machine. Now recycle your machine power(Turn it off and back on).
Pause your machine again and place your last .VMEM file into a folder called "Stop_and_Start".
7. Now point PTFINDERFE at the three .VMEM Files in the "Baseline", Infected" and "Stop_and_Start" Folders.
8. Review the Output JPEG image. and find your virus Process PED. Get the PED(0x#########).
9. Run LSPM using PED from Step 8.
10. Run TextScan at the LSPM created Image file.
11. Review the TextScan Text and find your gold.

“Lest We Remember: Cold Boot Attacks on Encryption Keys"

Seems like a team of Princeton students have put together a very well done website, research paper (pdf) and video regarding acquiring RAM. The jist of these items shows: Information stays in RAM after power loss and then degrades, cooling DRAM Chips will help prevent the decay of volatile memory and keys to Full Disk Encryption can be obtained by capturing RAM.

The online community has definitely weighed in:
Slashdot Replies: Over 300 Comments
Freedom-to-tinker.com Over 121 Comments
I even received an email message from Multimedia Forensics regarding this new information.

I think my prior blogpost regarding the “Guillotine Method” of RAM Acquisition is the perfect twin to their basic premises except the Guillotine Method is really a “HOT Boot”.

SO at least I can say, “…I remembered... RAM Capture can be Valuable to Forensic Examiners””

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.

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

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)

5. 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.
6. Prior to the Re-Boot Insert the USB Drive to Capture Memory Dump (Format of USB: FAT32). Push in CD Tray if needed.

7. Boot in Knoppix
8. Boot Knoppix to Command Line (Option in Damn Small Linux is “dsl 2”).
9. Mount the USB Drive (mount /dev/sda1).
10. dd the Memory (for example if dd=/dev/mem of=/mnt/sda1/NAMEofDump.dd ) if=input file of=output file
11. Unmount USB or Shutdown (shutdown –h now)
12. 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!!!