Hi Steve, 

The plugin may have encountered a bad size field, causing it to read too much data into memory at once. Can you do the following for me, please:

* Run zeusscan2 -p PID where PID is the process id for explorer.exe (we know Zeus injects explorer, so this will let us focus on just one process first)

* If you get the same memory-consumption behavior, run vadinfo -p PID and send me the output (offlist is fine)

* If you don't see the same behavior on explorer.exe, please run vadinfo across all processes (just vol.py vadinfo > results.txt) and send me that instead. 

Thanks!
Michael


On Tue, Jan 28, 2014 at 8:06 AM, <shorejsi2@mmm.com> wrote:
Michael;

 Thanks for putting me straight on that one. Seems I had read somewhere (the Internet? Can't be; everything written there is true...) that zeusscan/zeusscan2 couldn't run in Volatility versions  beyond 2.0. Obviously not true.  As it happens, I already have 2.3.1 installed and typically use it first.

 Running under 2.3.1 gave a different result, but not necessarily a 'better' different result:

$ python vol.py --plugins=contrib/plugins/malware  zeusscan2 -f ~/Images/CA005040-HP8460/CA005040-HP8460-RAM.dd4.001 --profile=Win7SP1x86
Volatility Foundation Volatility Framework 2.3.1
Killed

 Seems it used up all 20GB of installed ram, then consumed the 10GB of available swap space before it bailed.

 I'll have my hands on a drive image in a day or so (it's an off-site machine) and then if anyone's interested in looking at the malware itself I'll certainly provide copies.


                        -=[ Steve ]=-



>> I would recommend grabbing a 2.3.1 install, the 2.0 version is more than 3 years old now. 

>> $ svn checkout http://volatility.googlecode.com/svn/trunk/ volatility-read-only
>> $ cd volatility-read-only
>> $ python vol.py --plugins=contrib/plugins/malware -f mem.dmp zeusscan2

>> Give that a shot...
>> MHL