- Vol-users - volatilityfoundation.org

by Michael Hale Ligh

Hey everyone, The 2.1 RC1 downloads are now available [1]. Per the usual, there are zip and tar archives of the source code, a windows module installer, and a standalone windows executable (with python and all dependencies build-in). We ask that you test vigorously over the next 2 weeks, especially with any x64 images, and let us know via the issue tracker [2] if you run into any bugs. At the end of July, we'll announce the official release of 2.1. Also, a lot of the documentation [3] has been updated, including the FAQ, command reference, features by plugin matrix, and roadmap, so that may be a useful resource to you when using 2.1. Thank you very much! [1]. http://code.google.com/p/volatility/downloads/list [2]. http://code.google.com/p/volatility/issues/list [3]. http://code.google.com/p/volatility/w/list

13 years, 9 months

2
3
0 0

understanding impscan and Zeus 1.0

by Michael Felber

Hi folks, Testing impscan with zeus.vmem I have a little question about the capabilities of impscan: Malfind finds 2 regions with injected code as seen many times: C:\Micha\Forensics\Volatility-2.1a>python vol.py malfind -f D:\X-Ways-Images\zeus.vmem -p 1724 Volatile Systems Volatility Framework 2.1_rc1 Process: explorer.exe Pid: 1724 Address: 0x1600000 Vad Tag: VadS Protection: PAGE_EXECUTE_READWRITE Flags: CommitCharge: 1, MemCommit: 1, PrivateMemory: 1, Protection: 6 0x01600000 b8 35 00 00 00 e9 cd d7 30 7b b8 91 00 00 00 e9 .5......0{...... . Process: explorer.exe Pid: 1724 Address: 0x15d0000 Vad Tag: VadS Protection: PAGE_EXECUTE_READWRITE Flags: CommitCharge: 38, MemCommit: 1, PrivateMemory: 1, Protection: 6 0x015d0000 4d 5a 90 00 03 00 00 00 04 00 00 00 ff ff 00 00 MZ.............. . Base 0x015d0000 is a "real" exe-module and impscan can detect the hooked calls very well: C:\Micha\Forensics\Volatility-2.1a>python vol.py impscan -f D:\X-Ways-Images\zeus.vmem -p 1724 --base 0x015d0000 Volatile Systems Volatility Framework 2.1_rc1 IAT Call Module Function ---------- ---------- -------------------- -------- 0x015d1000 0x77dea43c ADVAPI32.dll CryptGetHashParam 0x015d1004 0x77dd7535 ADVAPI32.dll RegCreateKeyExW 0x015d1008 0x77de8546 ADVAPI32.dll CryptReleaseContext 0x015d100c 0x77dd6fc8 ADVAPI32.dll RegQueryValueExW 0x015d1010 0x77dd778e ADVAPI32.dll InitializeSecurityDescriptor 0x015d1014 0x77df986b ADVAPI32.dll GetSidSubAuthorityCount 0x015d1018 0x77dd77b3 ADVAPI32.dll SetSecurityDescriptorDacl 0x015d101c 0x77df1285 ADVAPI32.dll SetNamedSecurityInfoW 0x015d1020 0x77dfcaf6 ADVAPI32.dll LookupPrivilegeValueW 0x015d1024 0x77dea2f9 ADVAPI32.dll CryptCreateHash 0x015d1028 0x77de2cde ADVAPI32.dll ConvertStringSecurityDescriptorToSecurityDescriptorW 0x015d102c 0x77dd6a78 ADVAPI32.dll RegOpenKeyExW . Base 0x01600000 contains jump instructions to other addresses: 0x1600000 b835000000 MOV EAX, 0x35 0x1600005 e9cdd7307b JMP 0x7c90d7d7 0x160000a b891000000 MOV EAX, 0x91 0x160000f e94fdf307b JMP 0x7c90df63 0x1600014 8bff MOV EDI, EDI 0x1600016 55 PUSH EBP 0x1600017 8bec MOV EBP, ESP 0x1600019 e9ef17c175 JMP 0x7721180d So it seems to be consistent that impscan is unable to find hooked calls there: C:\Micha\Forensics\Volatility-2.1a>python vol.py impscan -f D:\X-Ways-Images\zeus.vmem -p 1724 --base 0x01600000 Volatile Systems Volatility Framework 2.1_rc1 IAT Call Module Function ---------- ---------- -------------------- -------- Traceback (most recent call last): File "vol.py", line 185, in <module> main() File "vol.py", line 176, in main command.execute() File "C:\Micha\Forensics\Volatility-2.1a\volatility\commands.py", line 111, in execute func(outfd, data) File "C:\Micha\Forensics\Volatility-2.1a\volatility\plugins\malware\impscan.py", line 358, in render_text for iat, call, mod, func in data: File "C:\Micha\Forensics\Volatility-2.1a\volatility\plugins\malware\impscan.py", line 338, in calculate forward = True) File "C:\Micha\Forensics\Volatility-2.1a\volatility\plugins\malware\impscan.py", line 130, in _vicinity_scan start_addr = sortedlist[0] IndexError: list index out of range Or does the error message mean something other? Looked at the first jump target there is the "detoured" call as expected: C:\Micha\Forensics\Volatility-2.1a>python vol.py impscan -f D:\X-Ways-Images\zeus.vmem -p 1724 --base 0x7c90d7d7 Volatile Systems Volatility Framework 2.1_rc1 IAT Call Module Function ---------- ---------- -------------------- -------- 0x7c97d280 0x7c832b5c kernel32.dll BaseQueryModuleData So impscan is not able to directly handle such trampoline calls, is it? Following the trace of the jump targets there are two imports of BaseQueryModuleData: C:\Micha\Forensics\Volatility-2.1a>python vol.py impscan -f D:\X-Ways-Images\zeus.vmem -p 1724 --base 0x7c90df63 Volatile Systems Volatility Framework 2.1_rc1 IAT Call Module Function ---------- ---------- -------------------- -------- 0x7c97d280 0x7c832b5c kernel32.dll BaseQueryModuleData Also the next jump targets import the same api calls: C:\Micha\Forensics\Volatility-2.1a>python vol.py impscan -f D:\X-Ways-Images\zeus.vmem -p 1724 --base 0x7721180d Volatile Systems Volatility Framework 2.1_rc1 IAT Call Module Function ---------- ---------- -------------------- -------- 0x77261000 0x77dd761b ADVAPI32.dll RegOpenKeyExA 0x77261004 0x77dfd4c9 ADVAPI32.dll GetUserNameA 0x77261034 0x77dfc41b ADVAPI32.dll RegOpenKeyA . C:\Micha\Forensics\Volatility-2.1a>python vol.py impscan -f D:\X-Ways-Images\zeus.vmem -p 1724 --base 0x771c76bd Volatile Systems Volatility Framework 2.1_rc1 IAT Call Module Function ---------- ---------- -------------------- -------- 0x77261000 0x77dd761b ADVAPI32.dll RegOpenKeyExA 0x77261004 0x77dfd4c9 ADVAPI32.dll GetUserNameA 0x77261034 0x77dfc41b ADVAPI32.dll RegOpenKeyA . I have no clue why theses api-call are hooked twice. Does anybody have an idea? Regards Michael

13 years, 9 months

2
2
0 0

got a rootkit or what?

by phocean

Hi list, I believe that one of my lab VM is owned by a sophisticated rootkit. There are many signs of that: Rootkit in my lab? Rootkit in my lab? (part II) Live analysis was a dead end. Needless to say that common live analysis tools and AV found nothing. So I have been focussed for days on analyzing the RAM with Volatility. And I found absolutely nothing. I am just afraid that now it is beyond my skills at this moment. If some of you are curious, do not hesitate to have a look. Of course, I would love to learn more and get some tips and feedbacks. I can provide more volatility output if necessary, or even the dump. Thank you! --- phocean

13 years, 9 months

1
0
0 0

Windows Server 2008

by Mike Lambert

I know we can't work on Windows Server 2008 with Volatility at this time. What products are capable of examining Windows Server 2008? Thanks, Mike

13 years, 9 months

13
49
0 0

Impact on memory images when suspending a virtual machine

by Stefan Vömel

Hi everyone, in prior threads, Michael and Aaron pointed out changes in memory structures when suspending a virtual machine. I think this is an important observation and would therefore suggest moving the respective discussion to a separate thread. I have summarized the relevant passages below. ---- Michael H. Ligh (http://lists.volatilityfoundation.org/pipermail/vol-users/2012-June/000441.…) > Also, if you're analyzing a memory dump by suspending the VM, that has > significant impact on the lifetime and availability of network > structures. When you suspend/pause a VMware guest, VMware tools runs a > bat script on the guest (I think its vm-suspend.bat) which forcefully > closes TCP/UDP and frees the IP. Jesse Bowling (http://lists.volatilityfoundation.org/pipermail/vol-users/2012-July/000470.…) > This was a VMWare 4.1 virtual machine that was paused, and the vmss file > copied out. > Much later I head referenced that pausing the virtual machine actually > causes a lot of information to be removed from memory due to the way VMWare > prepares the OS to pause... :( (Can you or anyone speak to the truth-iness > of this?) AAron Walters (http://lists.volatilityfoundation.org/pipermail/vol-users/2012-July/000473.…) > This is definitely something to take in consideration with this particular > acquisition method. I think you are referring to a comment that MHL made > previously about vmware tools. A similar thing happens when people > attempt to use hibernation files. Intuitively, what does it mean to resume > a network connection that disappeared hours, if not days, earlier? In some > instances, it is possible to still extract associated artifacts from > unallocated regions, a technique most debuggers don't handle very well. ---- Last year, I wrote a survey article about memory acquisition and analysis techniques (http://www.sciencedirect.com/science/article/pii/S1742287611000508) and stated in a short section about virtual machines that, by suspending a system, a memory snapshot with a high level of atomicity and correctness could be produced. With respect to the issues raised by Michael, this statement is maybe a bit too optimistic now?! I have recently done a lot of research in the area of memory acquisition, specifically with regard to software-based utilities. We have tried to formalize criteria for sound memory imaging in a different paper (http://www.sciencedirect.com/science/article/pii/S1742287612000254) and I'm currently working on a platform that may help evaluating the correctness, impact, etc. of a utility more accurately. As the discussion about virtual machines roughly touches my research interests, I would like to know if there's any more information on this topic. Specifically: - Has anyone ever measured the impact on a memory image when suspending a system? - I have briefly looked at the vm-suspend-default.bat file which is located in the folder of the VMware tools. It just includes an "ipconfig /release" command, so it appears "only" network-related information would be affected. Is anyone aware of any other structures that would be changed/destroyed when going into suspensed mode? - Is the batch script (or similar operations) actually executed every time a machine is suspended? I have just run a quick google query on the file and only saw that its use was optional? I would very much appreciate if anyone had some more details on this or could share some references. Best regards, Stefan

13 years, 10 months

2
1
0 0

Stuxnet "Are you there?" mutant

by Mike Lambert

I want to check to see if my test computer is infected with Stuxnet. I have not finished the forensics on it and do not want to know any answers. I don't want to check the behaviorial data yet because that would give too much away. My hash and signature analysis says it is not infected. I don't want to waste time if it is not infected. I think the simplest way to determine if it is infected is to see if the "Are you there?" mutant is there. If you know the mutant, please let me know. There is a lot of analysis of it on the internet and I have kept away from it. No fun to get the answer from someone else. Thanks, Mike

13 years, 10 months

1
0
0 0

Option 2 for injected malware extraction

by Mike Lambert

I am looking at a sample of the Pilleuz worm that infects USB. I ran malfind and was not successful extracting a sample Is there another option for extracting injected code? Is there a way to dump threads? Thanks, Mike

13 years, 10 months

2
3
0 0

problems dumping a process

by Michael Felber

Hi all, still playing with fire (or a single "Flame" ;-)) I have tried to dump the possibly infected services.exe from a decompressed hiberil.sys but run into an error message: C:\Micha\Forensics\Volatility-2.1a>python vol.py pslist -f D:\X-Ways-Images\flame.mem | egrep -i "(PID|services)" Volatile Systems Volatility Framework 2.1_alpha Offset(V) Name PID PPID Thds Hnds Sess Wow64 Start Exit 0x84cae5a8 services.exe 912 868 37 966 0 0 2012-06-03 07:47:48 C:\Micha\Forensics\Volatility-2.1a>python vol.py procexedump -p 868 -f D:\X-Ways-Images\flame.mem -D C:\temp\VolDumpFlame Volatile Systems Volatility Framework 2.1_alpha ************************************************************************ Dumping winlogon.exe, pid: 868 output: executable.868.exe C:\Micha\Forensics\Volatility-2.1a>python vol.py procexedump -p 912 -f D:\X-Ways-Images\flame.mem -D C:\temp\VolDum pFlame Volatile Systems Volatility Framework 2.1_alpha ************************************************************************ Error: ImageBaseAddress not memory resident for process [912] C:\Micha\Forensics\Volatility-2.1a>python vol.py procexedump -o 0x84cae5a8 -f D:\X-Ways-Images\flame.mem -D C:\temp \VolDumpFlame Volatile Systems Volatility Framework 2.1_alpha ************************************************************************ Error: PEB not memory resident for process [-] Why the PEB header seems to be paged out? Isn't it a strange behavior for such an important process like services.exe? There is really no header: C:\Micha\Forensics\Volatility-2.1a>python vol.py volshell -f D:\X-Ways-Images\flame.mem Volatile Systems Volatility Framework 2.1_alpha Current context: process System, pid=4, ppid=0 DTB=0x39000 Welcome to volshell! Current memory image is: file:///D:/X-Ways-Images/flame.mem >>> cc (offset=0x84cae5a8) Current context: process services.exe, pid=912, ppid=868 DTB=0x13edc000 >>> db(0x84cae5a8) 0x84cae5a8 03 00 1b 00 00 00 00 00 b0 7c b6 84 b0 7c b6 84 .........|...|.. 0x84cae5b8 b8 e5 ca 84 b8 e5 ca 84 00 c0 ed 13 00 50 ee 13 .............P.. 0x84cae5c8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0x84cae5d8 ac 20 00 00 00 00 00 00 39 0a 00 00 4f 0c 00 00 ........9...O... 0x84cae5e8 e8 e5 ca 84 e8 e5 ca 84 00 00 00 00 00 00 00 00 ................ 0x84cae5f8 58 9f b8 84 d0 51 60 84 00 00 00 00 01 00 00 00 X....Q`......... 0x84cae608 14 00 09 06 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0x84cae618 00 f3 e8 2b 5d 41 cd 01 00 00 00 00 00 00 00 00 ...+]A.......... >>> dis(0x84cae5a8) 0x84cae5a8 0300 ADD EAX, [EAX] 0x84cae5aa 1b00 SBB EAX, [EAX] 0x84cae5ac 0000 ADD [EAX], AL 0x84cae5ae 0000 ADD [EAX], AL 0x84cae5b0 b07c MOV AL, 0x7c 0x84cae5b2 b684 MOV DH, 0x84 0x84cae5b4 b07c MOV AL, 0x7c 0x84cae5b6 b684 MOV DH, 0x84 0x84cae5b8 b8e5ca84b8 MOV EAX, 0xb884cae5 0x84cae5bd e5ca IN EAX, 0xca 0x84cae5bf 8400 TEST [EAX], AL 0x84cae5c1 c0ed13 SHR CH, 0x13 . The goal was to find hooks within the code but it seems to be a challenge to find the complete process itself.. What could I do? Regards Mic

13 years, 10 months

2
1
0 0

format of UDP record in memory

by Mike Lambert

I've used 1.3 and 2.0 but neither gives me any "old" UDP artifacts. I know they are there because I have the pcap, so I am looking for them in memory. Can someone tell me the format of a UDP artifact in memory please? For example I'm looking for from a connection UDP 192.168.136.129:1044 to 204.13.161.100:6600 I'm looking at 11 83 89 CO A8 88 81 CC 0D A1 64 04 14 19 C8 that looks like UDP Unk Unk 192.168.136.129 204.13.161.100 1044 6600 The "Unk" means I don't know what they are (the 83 (seems to be constant) and 89 (changes slightly)). I've found this in the kernel 01fb5017 [kernel:2180730903] UDP to 204.13.161.100 This may just be a parameter block that is passed to the OS, but it does show that there was such a packet sent. Tell me what I need to be looking for if I am in the wrong place. Thanks, Mike

13 years, 10 months

4
7
0 0

malware memory forensics using volatility

by malware monna

Hi All, I presented a topic on "malware memory forensics" using Volatility.....the ppt and video can be found in the below link....i hope you will like it :-) http://goo.gl/7bRFK Thanks, Monnappa

13 years, 10 months

3
2
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Vol-users