<div dir="ltr">Sure, if malfind identifies the injected code, but zeusscan2 doesn&#39;t dump the RC4 keys, then you&#39;ve just got a new Zeus variant (or not &quot;new&quot; per se, but just one that we don&#39;t currently have a signature [1] for). <br>
<div><br></div><div>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.</div><div><br></div><div>Any chance you can still send the vadinfo output offlist, so I can look into the memory consumption issue on the other process(es)? </div>
<div><br></div><div>[1]. <a href="http://code.google.com/p/volatility/source/browse/trunk/contrib/plugins/malware/zeusscan.py#207">http://code.google.com/p/volatility/source/browse/trunk/contrib/plugins/malware/zeusscan.py#207</a></div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jan 28, 2014 at 9:40 AM,  <span dir="ltr">&lt;<a href="mailto:shorejsi2@mmm.com" target="_blank">shorejsi2@mmm.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<font face="sans-serif">Michael;</font>
<br>
<br><font face="sans-serif"> Interesting:</font>
<br>
<br><tt><font>$ python vol.py --plugins=contrib/plugins/malware
 zeusscan2 -f ~/Images/CA005040-HP8460/CA005040-HP8460-RAM.dd4.001
--profile=Win7SP1x86 -p 2928</font></tt>
<br><div class="im"><tt><font>Volatility Foundation Volatility Framework 2.3.1</font></tt>
<br></div><tt><font>[a05p8zz@W0147206 volatility-2.3.1]$</font></tt>
<br>
<br><font face="sans-serif"> Ends relatively quickly with no
output.</font>
<br>
<br><font face="sans-serif"> Looking at &#39;strings&#39; for the malfind
output relate to this process, I see all of the things I have come to know
and love about Zeus:</font>
<br>
<br><tt><font>00008A40  tellerplus</font></tt>
<br><tt><font>00008A58  bancline</font></tt>
<br><tt><font>00008A6C  fidelity</font></tt>
<br><tt><font>00008A80  micrsolv</font></tt>
<br><tt><font>00008A94  bankman</font></tt>
<br><tt><font>00008AA4  vantiv</font></tt>
<br><tt><font>00008AB4  episys</font></tt>
<br><tt><font>00008AC4  jack henry</font></tt>
<br><tt><font>00008ADC  cruisenet</font></tt>
<br><tt><font>00008AF0  gplusmain</font></tt>
<br><tt><font>00008B04  launchpadshell.exe</font></tt>
<br><tt><font>00008B2C  dirclt32.exe</font></tt>
<br><tt><font>00008B48  wtng.exe</font></tt>
<br><tt><font>00008B5C  prologue.exe</font></tt>
<br><tt><font>00008B78  silverlake</font></tt>
<br><tt><font>00008B90  pcsws.exe</font></tt>
<br><tt><font>00008BA4  v48d0250s1</font></tt>
<br><tt><font>00008BBC  fdmaster.exe</font></tt>
<br><tt><font>00008BD8  fastdoc</font></tt>
<br>
<br><font face="sans-serif"> And our FireEye infrastructure
is screaming Zeus as well. </font>
<br>
<br><font face="sans-serif"> Thoughts?  </font>
<br>
<br>
<br><font face="sans-serif">         
              -=[ Steve
]=-</font>
<br><div class="HOEnZb"><div class="h5">
<br>
<br>
<br><font size="3">&gt;&gt; Hi Steve,  </font>
<br>
<br><font size="3">&gt;&gt; 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:</font>
<br>
<br><font size="3">&gt;&gt; * 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)</font>
<br>
<br><font size="3">&gt;&gt; * If you get the same memory-consumption behavior,
run vadinfo -p PID and send me the output (offlist is fine)</font>
<br>
<br><font size="3">&gt;&gt; * If you don&#39;t see the same behavior on explorer.exe,
please run vadinfo across all processes (just vol.py vadinfo &gt; results.txt)
and send me that instead. </font>
<br>
<br><font size="3">&gt;&gt; Thanks!</font>
<br><font size="3">&gt;&gt; Michael</font>
<br></div></div></blockquote></div><br></div>