*********** The First 5 Steps are exactly the same as my last posted regarding Walk-Through: Volatility Batch File Maker and Volatility's ProcDump. The Walk-through Portion is repeated here for future discussions. Skip if applicable.******************
1. Download the following files from Hogfly (Website)
exemplar6.tar.gz.001
exemplar6.tar.gz.002
exemplar6.tar.gz.003
In my example I placed the files in e:\exemlar6\ directory
2. Add the downloaded files together and Extract with the following cmd prompt code:
Copy /b “exemplar6.tar.gz.001”+ “exemplar6.tar.gz.002”+” exemplar6.tar.gz.003” exemplar6.tar.gz
3. Extract using WinRAR (exemplar6.tar.gz to exemplar6.vmem)
4. Run PtfinderFE against extracted file(exemplar6.vmem) which creates exemplar6.txt
5.Run Volatility Batch File Maker.
-a. Select e:\exemlar6\xemplar6.vmem with “Browse for Memory Capture”.
-b. Select e:\exemlar6\exemplar6.txt (created by PtFinderFE) for your memory image with “Browse for Offset Text File”.
-c. Create Batch (Which is hidden until the previous listed fields are populated).
6. .Goto the directory containing exemplar6.vmem (e:\exemlar6\) and run e:\exemlar6\vaddump.bat file.
7.Browse the e:\exemlar6\vaddump folder.(The following images is a truncated view of the vaddump directory's content):
8. Drop the entire vaddump directory and the original exemplar6.vmem into ENCASE (or your forensic tool of choice).
9. Hash all the files (Search>Calculate hash value).
10. Compare Hash Values. First you will notice some duplicated hash values between VAD files from different processes. I believe this shows that there is possibility of some type of relationship between the different processes. Look at the three files with the hash of 2defb57866392bd7145b3b85894d3a4a
atsxyzd.sys.1b13b40.00af0000-00af7fff.dmp
dxonool32.sys.17fc678.00e90000-00e97fff.dmp
dw8.exe.17f7020.00a20000-00a27fff.dmp
In my last post atsxyzd.sys, dxonool32.sys and dw8.exe were identified as suspected malware.
Now look at the VAD contents that are the same for all three files. The following is a text tepresentation(truncated)of the similar VAD Files (Hash:2defb57866392bd7145b3b85894d3a4a):
Client UrlCache MMF Ver 5.2··€···P··€···U········Äý······ø······················CLUBCLEZ
····KPAN45MJ····0HEN0X2F····WTE74L2Z····················
We can then create search words out of CLUBCLEZ, KPAN45MJ, 0HEN0X2F and WTE74L2Z(which look like they might be folder names used by Internet Explorer). For every hit in the VAD files there is a hit in the original VMEM File. There is one additional hit in the VMEM file for each search term which we would then try and figure out.
11. Create search term like “http://” and go “cherry picking” you can find a lot of IP Addresses in the suspected malware. It is very easy to find the context to your search hits just by looking at the file they are located in.
There is approximately 107 megabytes of VAD files (without duplicates). The total size of the original VMEM is 256 megabytes. That is 2/5 context provided for this dump file. In less then 6 minutes.
A site for “Computer Crime” Investigators Where we can share our tips, tricks and mistakes…
Friday, October 16, 2009
Walk-Through: Volatility Batch File Maker and Volatility's ProcDump
1. Download the following files from Hogfly (Website)
exemplar6.tar.gz.001
exemplar6.tar.gz.002
exemplar6.tar.gz.003
In my example I placed the files in e:\exemlar6\ directory
2. Add the downloaded files together and extract with the following cmd prompt code:
Copy /b “exemplar6.tar.gz.001”+ “exemplar6.tar.gz.002”+” exemplar6.tar.gz.003” exemplar6.tar.gz
3. Extract using WinRAR (exemplar6.tar.gz to exemplar6.vmem)
4. Run PtfinderFE against extracted file(exemplar6.vmem) which creates exemplar6.txt
5.Run Volatility Batch File Maker.
-a. Select e:\exemlar6\xemplar6.vmem with “Browse for Memory Capture”.
-b. Select e:\exemlar6\exemplar6.txt (created by PtFinderFE) for your memory image with “Browse for Offset Text File”.
-c. Create Batch (Which is hidden until the previous listed fields are populated).
6. .Goto the directory containing exemplar6.vmem (e:\exemlar6\) and run e:\exemlar6\procdump.bat file.
7.Browse the e:\exemlar6\procdump folder.
8.Use an anti-virus tool against the reconstructed executable files in the e:\exemlar6\procdump directory
I decided to send the files to Virus Total for testing. Using their "Send to" Function.
PID 464 - “dw8.exe”(Virus Total Results: 13 of 40 Hits)
PID 648 ”tdctxte.exe” (Virus Total Results: 116 of 41 Hits)
PID 872 ”atsxyzd.sys” (Virus Total Results: 117 of 41 Hits)
PID 1056 ”dxonool32.sys” (Virus Total Results: 119 of 40 Hits)
PID 1876 ”sopidkc.exe” (Virus Total Results: 14 of 41 Hits)
PID 1932 ”afisicx.exe” (Virus Total Results: 119 of 40 Hits)
Some Additional Notes and Some Background:
I'm not sure why but it seems the executables that have unique icons instead of the generic executable icons have a high percentage of being malicious.
Until I created Volatility Batch File Maker I was using batch file, and changing input via a spreadsheet and some “find and replace” functions. One of the batch file I created attempted to use ProcDump on all the PIDs (-p option) from 0 to 6000. Reconstructed executables were only made for PIDs that were listed as running by Ptfinder. I also tried using Procdump offset (-o option) function with the same results(and ALOT more time!!!).
I was analyzing a “real world” machine which was running over 90 processes. I placed the executables created by ProcDump into a zip files, by groups of 10. I then sent them up to Virus Total for Scanning. Unfortunately when I found a hit there was no way to determine which file out of the group of ten was the suspected malware file.
I would like to start an ssdeep database of common executables created by Procdump.
exemplar6.tar.gz.001
exemplar6.tar.gz.002
exemplar6.tar.gz.003
In my example I placed the files in e:\exemlar6\ directory
2. Add the downloaded files together and extract with the following cmd prompt code:
Copy /b “exemplar6.tar.gz.001”+ “exemplar6.tar.gz.002”+” exemplar6.tar.gz.003” exemplar6.tar.gz
3. Extract using WinRAR (exemplar6.tar.gz to exemplar6.vmem)
4. Run PtfinderFE against extracted file(exemplar6.vmem) which creates exemplar6.txt
5.Run Volatility Batch File Maker.
-a. Select e:\exemlar6\xemplar6.vmem with “Browse for Memory Capture”.
-b. Select e:\exemlar6\exemplar6.txt (created by PtFinderFE) for your memory image with “Browse for Offset Text File”.
-c. Create Batch (Which is hidden until the previous listed fields are populated).
6. .Goto the directory containing exemplar6.vmem (e:\exemlar6\) and run e:\exemlar6\procdump.bat file.
7.Browse the e:\exemlar6\procdump folder.
8.Use an anti-virus tool against the reconstructed executable files in the e:\exemlar6\procdump directory
I decided to send the files to Virus Total for testing. Using their "Send to" Function.
PID 464 - “dw8.exe”(Virus Total Results: 13 of 40 Hits)
PID 648 ”tdctxte.exe” (Virus Total Results: 116 of 41 Hits)
PID 872 ”atsxyzd.sys” (Virus Total Results: 117 of 41 Hits)
PID 1056 ”dxonool32.sys” (Virus Total Results: 119 of 40 Hits)
PID 1876 ”sopidkc.exe” (Virus Total Results: 14 of 41 Hits)
PID 1932 ”afisicx.exe” (Virus Total Results: 119 of 40 Hits)
Some Additional Notes and Some Background:
I'm not sure why but it seems the executables that have unique icons instead of the generic executable icons have a high percentage of being malicious.
Until I created Volatility Batch File Maker I was using batch file, and changing input via a spreadsheet and some “find and replace” functions. One of the batch file I created attempted to use ProcDump on all the PIDs (-p option) from 0 to 6000. Reconstructed executables were only made for PIDs that were listed as running by Ptfinder. I also tried using Procdump offset (-o option) function with the same results(and ALOT more time!!!).
I was analyzing a “real world” machine which was running over 90 processes. I placed the executables created by ProcDump into a zip files, by groups of 10. I then sent them up to Virus Total for Scanning. Unfortunately when I found a hit there was no way to determine which file out of the group of ten was the suspected malware file.
I would like to start an ssdeep database of common executables created by Procdump.
Labels:
HogFly,
Malware Analysis,
PTFinder,
RAM Analysis,
Volatility
Volatility Batch File Maker
The Tool: VolatilityBatch File Maker Download
I wanted to take the text output of the various tools (Ptfinder, PtFinderFE and Volatility >PsScan2) which identifies all the offsets for (running) processes and input that offset data into several Volatility tools (ProcDump, MemDmp and VadDump). This program creates three batch files. After running the batch files I can quickly leverage additional investigation techniques at the output.
1.Run Ptfinder, PtFinderFE or Volatility >PsScan2 to create a text file that contains process offsets.
2.Run Volatility Batch File Maker.
-a.Select you memory image with “Browse for Memory Capture”.
-b.Select the Offset Text File for your memory image with “Browse for Offset Text File”.
-c.Create Batch (Which is hidden until the previous fields are populated)
Three Batch files are created,upon execution of the “Create Batch”, in the root folder where the memory capture resides. The three batch programs created are procdump.bat, memdmp.bat and vaddump.bat. When you run the batch files each one will create a folder in the residing directory and populate that directory with the selected Volatility Output. Each batch file also creates an additional text output showing any errors(procdumpinfo.txt, memdmpinfor.txt and vaddmpinfo.txt).
The following is an example of the procdump batch file with the following two inputs:
Location of Volatility = "C:\volatility"
Location of Memory Dump ="E:\exemplar\6\exemplar6.vmem"
mkdir procdump
cd procdump
python "c:\volatility\volatility" procdump -f "E:\exemplar\6\exemplar6.vmem" -u -o 0x00551b80>>procdumpinfo.txt
python "c:\volatility\volatility" procdump -f "E:\exemplar\6\exemplar6.vmem" -u -o 0x0166f7b0>>procdumpinfo.txt
python "c:\volatility\volatility" procdump -f "E:\exemplar\6\exemplar6.vmem" -u -o 0x01690920>>procdumpinfo.txt
python "c:\volatility\volatility" procdump -f "E:\exemplar\6\exemplar6.vmem" -u -o 0x016aa3c0>>procdumpinfo.txt
python "c:\volatility\volatili*****Truncated - You get the idea********************
Uses for the Ouput of the Batch Files:
After re-creating all the “executables” from the running processes you can run a virus scanner at the procdump folder. This can be another tool in the arsenal of defeating the Trojan Horse Defense.
Or how about one for the incident response guys... You could run this protocol at a full memory.dmp or on a converted hiberfil.sys (Converted with Suiche's Hibershell) created on a machine prior to your actual response and collection. How many times has someone “helped” you out by deleting the malware from the target machine just before you walked into the door. If the memory.dmp or hiberfil.sys is recent you might be able to “recreate” the malware executable. You could also show a machine has been compromised (or not) when the memory.dmp or hiberfil.sys was captured
The Vaddump folder now contains the output which can easily be used in a program like Encase to give you context to you memory image.
Some walk-through examples to be posted soon. Also I am in the process of updating PtFinderFE!!!
Labels:
PTFinder,
RAM,
RAM Analysis,
Sandman,
Schuster,
Volatility
Thursday, April 16, 2009
Sandman Shell: Batch files to Define environment variable _NT_SYMBOL_PATH
I had the following a question from Mr Anonymous about Matthieu Suiche's Sandman Shell Project:
“...the same happens with hibrshell. When I execute the command it crashes while "Retrieving Kernel Image base". I tried with 3 different hiberfil.sys files so I guess it's not the file. The bad thing is that I also tried with different pcs and it crashed too, this means that I have no idea of what it can be. Do I need any extra software? Has anyone the same problem?...”
I have had this problem too!!! I had the same errors because I didn't have the right Microsoft Symbols installed on my testing machine or I didn't define the environment variable _NT_SYMBOL_PATH everytime I opened a new command prompt to run Sandman Shell (ha.exe). So here is how to fix both problems.
First Make sure that you have the correct symbols installed on your test machine for the specific version of the Windows OS of the Hiberfil.sys you are testing. So if your Hiberfil.sys came from a Windows XP SP2 Machine make sure you have the Windows XP SP2 Symbols installed on your testing machine. Download symbols from Microsoft.
Second you have to make sure you define the path to the symbols everytime you open a command prompt. To help me I wrote the following two batch files:
__________________________________________
Batch File 1 Name: “CreateDD_HA.bat”
cmd /k _symbols_setup.bat
__________________________________
Batch File 2 Name: “_symbols_setup.bat”
set _NT_SYMBOL_PATH=SRV*C:\WINDOWS\Symbols*http://msdl.microsoft.com/download/symbols
echo %_NT_SYMBOL_PATH%
echo off
echo ****************************
echo ****************************
Echo FIRST
Echo To Obtain a DD Image of a Hiberfil.sys File...
Echo Type "ha.exe " and drag and drop your HiberFil.sys
Echo in the command lineto look like
Echo Example "ha.exe C:\dumpfiles\Hiber\hiberfil.sys"
echo off
echo ****************************
Echo Second
Echo Once you Hiberfil.sys file is loaded
Echo And you are at the Green Prompt just type
Echo Example "create output.dd"
__________________________________
Place the two batch files in the same directory as HA.exe
And run CreateDD_HA.bat.
If this doesn't help check with M Suiche. That guy is wicked smart and very helpful!
Rick
“...the same happens with hibrshell. When I execute the command it crashes while "Retrieving Kernel Image base". I tried with 3 different hiberfil.sys files so I guess it's not the file. The bad thing is that I also tried with different pcs and it crashed too, this means that I have no idea of what it can be. Do I need any extra software? Has anyone the same problem?...”
I have had this problem too!!! I had the same errors because I didn't have the right Microsoft Symbols installed on my testing machine or I didn't define the environment variable _NT_SYMBOL_PATH everytime I opened a new command prompt to run Sandman Shell (ha.exe). So here is how to fix both problems.
First Make sure that you have the correct symbols installed on your test machine for the specific version of the Windows OS of the Hiberfil.sys you are testing. So if your Hiberfil.sys came from a Windows XP SP2 Machine make sure you have the Windows XP SP2 Symbols installed on your testing machine. Download symbols from Microsoft.
Second you have to make sure you define the path to the symbols everytime you open a command prompt. To help me I wrote the following two batch files:
__________________________________________
Batch File 1 Name: “CreateDD_HA.bat”
cmd /k _symbols_setup.bat
__________________________________
Batch File 2 Name: “_symbols_setup.bat”
set _NT_SYMBOL_PATH=SRV*C:\WINDOWS\Symbols*http://msdl.microsoft.com/download/symbols
echo %_NT_SYMBOL_PATH%
echo off
echo ****************************
echo ****************************
Echo FIRST
Echo To Obtain a DD Image of a Hiberfil.sys File...
Echo Type "ha.exe " and drag and drop your HiberFil.sys
Echo in the command lineto look like
Echo Example "ha.exe C:\dumpfiles\Hiber\hiberfil.sys"
echo off
echo ****************************
Echo Second
Echo Once you Hiberfil.sys file is loaded
Echo And you are at the Green Prompt just type
Echo Example "create output.dd"
__________________________________
Place the two batch files in the same directory as HA.exe
And run CreateDD_HA.bat.
If this doesn't help check with M Suiche. That guy is wicked smart and very helpful!
Rick
Saturday, February 21, 2009
VMWare Running? Better Check for Different Windows Operating System's EPROCESS Blocks
Identify Multiple Windows OS Versions in a Single RAM Capture if the Host Machine is Running VMWare Machines.
I often run VMWare Machines, on my host machine,so I can easily grab the machine's RAM contents by suspending the machine and analyzing the VMEM file. Nothing new there. But what is cool is when you run several VMWare machines (or just one) and grab the RAM of the host machine. If you use other tools to determine which OS is running they will only identify what OS is running on the “Host” machine and not what OS(s) are being running on VMWare machines.
So to find out which different Windows OSs were running in your captured RAM use the following GREP search across your RAM acquisition
\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-\xFF]\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 GREP expression loosely translates to,
“N.T. .K.e.r.n.e.l. .&. .S.y.s.t.e.m........... F.i.l.e.V.e.r.s.i.o.n.....”.
This is the same GREP Expression in the RAM Enscript I created. (In the enscript the” \” is “\\”). The GREP expression is the magic number needed to find the metadata contained in the NTOSKRNL.exe. The following bytes after this GREP is the Windows OS File Version Number The file version can then be converted to the Specific Windows OS. The following is an example from the RAM Acquistion with the HOST OS (WinXPSP2) and Two VMWARE Machines (Vista and Win200) ________________________________________
Comment Operating System: Windows XPSP2 Internal Version Number = 5.1.2
File Offset 7209948
N·T· ·K·e·r·n·e·l· ·&· ·S·y·s·t·e·m·····r·)···F·i·l·e·V·e·r·s·i·o·n·····
________________________________________
Comment Operating System: Windows Vista Internal Version Number = 6.0.6
File Offset 445911836
N·T· ·K·e·r·n·e·l· ·&· ·S·y·s·t·e·m·····n·'···F·i·l·e·V·e·r·s·i·o·n·····
________________________________________
Comment Operating System: Windows 2000 Internal Version Number = 5.00.
File Offset 712069132
N·T· ·K·e·r·n·e·l· ·&· ·S·y·s·t·e·m·····8·····F·i·l·e·V·e·r·s·i·o·n·····
________________________________________
During my testing I also shutdown the VMWare Machines for approximately 10 minutes and re-acquired the RAM. I still found the OS Metadata, of one of the Machines in the second RAM acquisition. Showing there is some persistence of VMWARE' Machine's RAM in the HOST Memory. (No additional programs were started by the user during the ten minute waiting period-except the RAM acquisition tool).
Once you have the different OSs inside your RAM you can also use the same RAM Enscript to find the running/exited processes (EPROCESS Blocks) of each OS along with the other remnants. The Second RAM Acquisition did not contain the OS Metadata for the Vista VM but I still found 20 unique Vista EPROCESS Blocks. I also found about 7 unique EPROCESS Blocks from he Win2000 VM. Showing a little persistence in the RAM
So yeah... this is cool in the lab... but not sure how often anyone will need this information in the “Real World”.
Thanks to Eric at Digital Intelligence for idea of checking for this...
I often run VMWare Machines, on my host machine,so I can easily grab the machine's RAM contents by suspending the machine and analyzing the VMEM file. Nothing new there. But what is cool is when you run several VMWare machines (or just one) and grab the RAM of the host machine. If you use other tools to determine which OS is running they will only identify what OS is running on the “Host” machine and not what OS(s) are being running on VMWare machines.
So to find out which different Windows OSs were running in your captured RAM use the following GREP search across your RAM acquisition
\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-\xFF]\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 GREP expression loosely translates to,
“N.T. .K.e.r.n.e.l. .&. .S.y.s.t.e.m........... F.i.l.e.V.e.r.s.i.o.n.....”.
This is the same GREP Expression in the RAM Enscript I created. (In the enscript the” \” is “\\”). The GREP expression is the magic number needed to find the metadata contained in the NTOSKRNL.exe. The following bytes after this GREP is the Windows OS File Version Number The file version can then be converted to the Specific Windows OS. The following is an example from the RAM Acquistion with the HOST OS (WinXPSP2) and Two VMWARE Machines (Vista and Win200) ________________________________________
Comment Operating System: Windows XPSP2 Internal Version Number = 5.1.2
File Offset 7209948
N·T· ·K·e·r·n·e·l· ·&· ·S·y·s·t·e·m·····r·)···F·i·l·e·V·e·r·s·i·o·n·····
________________________________________
Comment Operating System: Windows Vista Internal Version Number = 6.0.6
File Offset 445911836
N·T· ·K·e·r·n·e·l· ·&· ·S·y·s·t·e·m·····n·'···F·i·l·e·V·e·r·s·i·o·n·····
________________________________________
Comment Operating System: Windows 2000 Internal Version Number = 5.00.
File Offset 712069132
N·T· ·K·e·r·n·e·l· ·&· ·S·y·s·t·e·m·····8·····F·i·l·e·V·e·r·s·i·o·n·····
________________________________________
During my testing I also shutdown the VMWare Machines for approximately 10 minutes and re-acquired the RAM. I still found the OS Metadata, of one of the Machines in the second RAM acquisition. Showing there is some persistence of VMWARE' Machine's RAM in the HOST Memory. (No additional programs were started by the user during the ten minute waiting period-except the RAM acquisition tool).
Once you have the different OSs inside your RAM you can also use the same RAM Enscript to find the running/exited processes (EPROCESS Blocks) of each OS along with the other remnants. The Second RAM Acquisition did not contain the OS Metadata for the Vista VM but I still found 20 unique Vista EPROCESS Blocks. I also found about 7 unique EPROCESS Blocks from he Win2000 VM. Showing a little persistence in the RAM
So yeah... this is cool in the lab... but not sure how often anyone will need this information in the “Real World”.
Thanks to Eric at Digital Intelligence for idea of checking for this...
Wednesday, January 28, 2009
Using Volatility (1.3_Beta), Volatility Plugin from Moyix, a test RAM Image (xp-laptop-2005-06-25.img) and a Windows Hash/Password Finder (SamInside or Cain and Abel) identify the passwords for the following users: Sarah, phoenix and the Administrator.
1. Run hivescan to get hive offsets
command: python volatility hivescan -f "C:\Dump\xp-laptop-2005-06-25.img"
Offset (hex)
42168328 0x2837008
42195808 0x283db60
47592824 0x2d63578
207677272 0xc60e758
207736840 0xc61d008
207759192 0xc622758
207822 ***** Truncated to save some space
2.Run hivelist with the first hivescan offset
command: python volatility hivelist -f "C:\Dump\xp-laptop-2005-06-25.img" -o 0x2837008
Address Name
0xe1ecd008 \Documents and Settings\Sarah\Local Settings\Application Data\Microsoft\Windows\UsrClass.dat
0xe1eff758 \Documents and Settings\Sarah\NTUSER.DAT
0xe1bf9008 \Documents and Settings\LocalService\Local Settings\Application Data\Microsoft\Windows\UsrClass.dat
0xe1c26850 \Documents and Settings\LocalService\NTUSER.DAT
0xe1bf1b60 \Documents and Settings\NetworkService\Local Settings\Application Data\Microsoft\Windows\UsrClass.dat
0xe1c2a758 \Documents and Settings\NetworkService\NTUSER.DAT
0xe1982008 \WINDOWS\system32\config\software
0xe197f758 \WINDOWS\system32\config\default
0xe1986008 \WINDOWS\system32\config\SAM
0xe197a758 \WINDOWS\system32\config\SECURITY
0xe1558578 [no name]
0xe1035b60 \WINDOWS\system32\config\system
0xe102e008 [no name]
3. Find Password Hash (-y System Hive Offset)(-s SAM Hive Offset) and Send to Text File.
Command: volatility hashdump -f "C:\Dump\xp-laptop-2005-06-25.img" -y 0xe1035b60 -s 0xe1986008>Password_Hash.txt
Administrator:500:08f3a52bdd35f179c81667e9d738c5d9:ed88cccbc08d1c18bcded317112555f4:::
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
HelpAssistant:1000:ddd4c9c883a8ecb2078f88d729ba2e67:e78d693bc40f92a534197dc1d3a6d34f:::
SUPPORT_388945a0:1002:aad3b435b51404eeaad3b435b51404ee:8bfd47482583168a0ae5ab020e1186a9:::
phoenix:1003:07b8418e83fad948aad3b435b51404ee:53905140b80b6d8cbe1ab5953f7c1c51:::
ASPNET:1004:2b5f618079400df84f9346ce3e830467:aef73a8bb65a0f01d9470fadc55a411c:::
Sarah:1006:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
4.Import Password_Hash.txt into a Password Finder (SamInside, Cain and Abel...).
User: Sarah Password: Empty
User: phoenix Password: Neon96
User: Administrator Password: Neon1996
1. Run hivescan to get hive offsets
command: python volatility hivescan -f "C:\Dump\xp-laptop-2005-06-25.img"
Offset (hex)
42168328 0x2837008
42195808 0x283db60
47592824 0x2d63578
207677272 0xc60e758
207736840 0xc61d008
207759192 0xc622758
207822 ***** Truncated to save some space
2.Run hivelist with the first hivescan offset
command: python volatility hivelist -f "C:\Dump\xp-laptop-2005-06-25.img" -o 0x2837008
Address Name
0xe1ecd008 \Documents and Settings\Sarah\Local Settings\Application Data\Microsoft\Windows\UsrClass.dat
0xe1eff758 \Documents and Settings\Sarah\NTUSER.DAT
0xe1bf9008 \Documents and Settings\LocalService\Local Settings\Application Data\Microsoft\Windows\UsrClass.dat
0xe1c26850 \Documents and Settings\LocalService\NTUSER.DAT
0xe1bf1b60 \Documents and Settings\NetworkService\Local Settings\Application Data\Microsoft\Windows\UsrClass.dat
0xe1c2a758 \Documents and Settings\NetworkService\NTUSER.DAT
0xe1982008 \WINDOWS\system32\config\software
0xe197f758 \WINDOWS\system32\config\default
0xe1986008 \WINDOWS\system32\config\SAM
0xe197a758 \WINDOWS\system32\config\SECURITY
0xe1558578 [no name]
0xe1035b60 \WINDOWS\system32\config\system
0xe102e008 [no name]
3. Find Password Hash (-y System Hive Offset)(-s SAM Hive Offset) and Send to Text File.
Command: volatility hashdump -f "C:\Dump\xp-laptop-2005-06-25.img" -y 0xe1035b60 -s 0xe1986008>Password_Hash.txt
Administrator:500:08f3a52bdd35f179c81667e9d738c5d9:ed88cccbc08d1c18bcded317112555f4:::
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
HelpAssistant:1000:ddd4c9c883a8ecb2078f88d729ba2e67:e78d693bc40f92a534197dc1d3a6d34f:::
SUPPORT_388945a0:1002:aad3b435b51404eeaad3b435b51404ee:8bfd47482583168a0ae5ab020e1186a9:::
phoenix:1003:07b8418e83fad948aad3b435b51404ee:53905140b80b6d8cbe1ab5953f7c1c51:::
ASPNET:1004:2b5f618079400df84f9346ce3e830467:aef73a8bb65a0f01d9470fadc55a411c:::
Sarah:1006:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
4.Import Password_Hash.txt into a Password Finder (SamInside, Cain and Abel...).
User: Sarah Password: Empty
User: phoenix Password: Neon96
User: Administrator Password: Neon1996
Labels:
Moyix,
Passwords,
RAM Analysis,
Registry,
Volatility
Subscribe to:
Posts (Atom)