2:35 p.m.
I'm dealing with what appears to be a new Zeus variant and on a whim I
tried to run zeusscan2 under a copy of Volatility 2.0 I still hang onto.
Perhaps not surprisingly, it ends unhappily
Volatile Systems Volatility Framework 2.0
Traceback (most recent call last):
File "vol.py", line 135, in <module>
main()
File "vol.py", line 126, in main
command.execute()
File "/home/a05p8zz/VolInstall/volatility-2.0/volatility/commands.py",
line 101, in execute
func(outfd, data)
File
"/home/a05p8zz/VolInstall/volatility-2.0/volatility/plugins/zeusscan2.py",
line 330, in render_text
for p, start, url, config_key, creds_key, decoded_config,
decoded_magic in data:
File
"/home/a05p8zz/VolInstall/volatility-2.0/volatility/plugins/zeusscan2.py",
line 221, in calculate
data = malware.get_vad_data(ps_ad, start, end)
File
"/home/a05p8zz/VolInstall/volatility-2.0/volatility/plugins/malware.py",
line 856, in get_vad_data
return ''.join(pages_one)
OverflowError: join() result is too long for a Python string
Now I strongly suspect that the new variant is just enough different that
it messes with the parsing and results in a runaway, but I just wanted to
make sure I'm not leaving something on the table here...
Should this work?
-=[ Steve ]=-
1:22 a.m.
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
On Mon, Jan 27, 2014 at 1:35 PM, <shorejsi2(a)mmm.com> wrote:
I'm dealing with what appears to be a new Zeus
variant and on a whim I
tried to run zeusscan2 under a copy of Volatility 2.0 I still hang onto.
Perhaps not surprisingly, it ends unhappily
Volatile Systems Volatility Framework 2.0
Traceback (most recent call last):
File "vol.py", line 135, in <module>
main()
File "vol.py", line 126, in main
command.execute()
File "/home/a05p8zz/VolInstall/volatility-2.0/volatility/commands.py",
line 101, in execute
func(outfd, data)
File
"/home/a05p8zz/VolInstall/volatility-2.0/volatility/plugins/zeusscan2.py",
line 330, in render_text
for p, start, url, config_key, creds_key, decoded_config,
decoded_magic in data:
File
"/home/a05p8zz/VolInstall/volatility-2.0/volatility/plugins/zeusscan2.py",
line 221, in calculate
data = malware.get_vad_data(ps_ad, start, end)
File
"/home/a05p8zz/VolInstall/volatility-2.0/volatility/plugins/malware.py",
line 856, in get_vad_data
return ''.join(pages_one)
OverflowError: join() result is too long for a Python string
Now I strongly suspect that the new variant is just enough different that
it messes with the parsing and results in a runaway, but I just wanted to
make sure I'm not leaving something on the table here...
Should this work?
-=[ Steve ]=-
_______________________________________________
Vol-users mailing list
Vol-users(a)volatilityfoundation.org
http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
9:06 a.m.
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
10:12 a.m.
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(a)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/*<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
10:40 a.m.
Michael;
Interesting:
$ python vol.py --plugins=contrib/plugins/malware zeusscan2 -f
~/Images/CA005040-HP8460/CA005040-HP8460-RAM.dd4.001 --profile=Win7SP1x86
-p 2928
Volatility Foundation Volatility Framework 2.3.1
[a05p8zz@W0147206 volatility-2.3.1]$
Ends relatively quickly with no output.
Looking at 'strings' for the malfind output relate to this process, I see
all of the things I have come to know and love about Zeus:
00008A40 tellerplus
00008A58 bancline
00008A6C fidelity
00008A80 micrsolv
00008A94 bankman
00008AA4 vantiv
00008AB4 episys
00008AC4 jack henry
00008ADC cruisenet
00008AF0 gplusmain
00008B04 launchpadshell.exe
00008B2C dirclt32.exe
00008B48 wtng.exe
00008B5C prologue.exe
00008B78 silverlake
00008B90 pcsws.exe
00008BA4 v48d0250s1
00008BBC fdmaster.exe
00008BD8 fastdoc
And our FireEye infrastructure is screaming Zeus as well.
Thoughts?
-=[ Steve ]=-
> 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
10:47 a.m.
Sure, if malfind identifies the injected code, but zeusscan2 doesn't dump
the RC4 keys, then you've just got a new Zeus variant (or not "new" per se,
but just one that we don't currently have a signature [1] for).
To fix that, the injected Zeus code would need to be extracted and reversed
a bit to determine the proper instruction sequences which reference the RC4
key.
Any chance you can still send the vadinfo output offlist, so I can look
into the memory consumption issue on the other process(es)?
[1].
http://code.google.com/p/volatility/source/browse/trunk/contrib/plugins/mal…
On Tue, Jan 28, 2014 at 9:40 AM, <shorejsi2(a)mmm.com> wrote:
Michael;
Interesting:
$ python vol.py --plugins=contrib/plugins/malware zeusscan2 -f
~/Images/CA005040-HP8460/CA005040-HP8460-RAM.dd4.001 --profile=Win7SP1x86
-p 2928
Volatility Foundation Volatility Framework 2.3.1
[a05p8zz@W0147206 volatility-2.3.1]$
Ends relatively quickly with no output.
Looking at 'strings' for the malfind output relate to this process, I see
all of the things I have come to know and love about Zeus:
00008A40 tellerplus
00008A58 bancline
00008A6C fidelity
00008A80 micrsolv
00008A94 bankman
00008AA4 vantiv
00008AB4 episys
00008AC4 jack henry
00008ADC cruisenet
00008AF0 gplusmain
00008B04 launchpadshell.exe
00008B2C dirclt32.exe
00008B48 wtng.exe
00008B5C prologue.exe
00008B78 silverlake
00008B90 pcsws.exe
00008BA4 v48d0250s1
00008BBC fdmaster.exe
00008BD8 fastdoc
And our FireEye infrastructure is screaming Zeus as well.
Thoughts?
-=[ Steve ]=-
> 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
2:59 a.m.
Steve,
I'm dealing with what appears to be a new Zeus
variant and on a whim I
tried to run zeusscan2 under a copy of Volatility 2.0 I still hang onto.
Are you willing/able to share the md5 of that Zeus variant, please?
Cheers,
Stefan.
--
Stefan Kelm <skelm(a)bfk.de>
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstrasse 100 Tel: +49-721-96201-1
D-76133 Karlsruhe Fax: +49-721-96201-99
3943
days inactive
3944
days old
vol-users@lists.volatilityfoundation.org
6 comments
3 participants
participants (3)
-
Michael Hale Ligh -
shorejsi2＠mmm.com -
Stefan Kelm