ylm / volatility

Automatically exported from code.google.com/p/volatility
GNU General Public License v2.0
0 stars 0 forks source link

High Number Process ID (pslist) #485

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago

Summary Of Actions Taken: 
1. Obtained malware sample and executed sample on Windows XP SP3 machine 
running within a VM (VMWare 9.x).
2. Rebooted machine.
3. Captured memory dump using most current version of DumpIt as of 3/9/2014 
from a USB drive.
4. Ran pslist using Volatility standalone 2.3.

The following results returned:

0x01f31428 192.168.147.128:1060      199.27.79.184:80          2796
0x01f74438 3.0.80.2:29413            173.194.115.113:21608     2183112416
0x021a35a0 192.168.147.128:1082      50.97.236.98:80           2796
0x021f3e68 192.168.147.128:1088      199.27.79.184:80          2796
0x022139a0 192.168.147.128:1087      199.27.79.184:80          2796
0x022a1780 64.9.0.0:63361            0.0.0.0:2128              2183796632

What I do not understand is the meaning (if any) of the process ID 2183112416.  
Does this indicate anything in particular?  I just have not seen such a large 
number for a process ID before.  Source IP for that same process ID in question 
is also odd as it is not my source IP.  

Any insight/help is appreciated.  If any additional information is needed, 
please let me know.

-Jacob

Original issue reported on code.google.com by jacoboma...@gmail.com on 11 Mar 2014 at 4:24

GoogleCodeExporter commented 9 years ago
Hi Jacob, 

This is normal/expected. See the link:

https://code.google.com/p/volatility/wiki/CommandReference23#connscan

In particular:

"To find _TCPT_OBJECT structures using pool tag scanning, use the connscan 
command. This can find artifacts from previous connections that have since been 
terminated, in addition to the active ones. In the output below, you'll notice 
some fields have been partially overwritten, but some of the information is 
still accurate. For example, the very last entry's Pid field is 0, but all 
other fields are still in tact. Thus, while it may find false positives 
sometimes, you also get the benefit of detecting as much information as 
possible."

What you're seeing could indeed be a false positive, but it could also be a 
real _TCPT_OBJECT whose members have just been overwritten. Its difficult to 
tell, but due to the high pid, its probably not a connection associated with 
malware - just an artifact of how Windows reallocates pool memory and how 
Volatility scans for connections based on patterns.

Original comment by michael.hale@gmail.com on 11 Mar 2014 at 2:40

GoogleCodeExporter commented 9 years ago
I forgot to mention - if you *only* want active connections (i.e. no chance of 
false positives or overwritten structures), use the connections plugin instead 
of connscan.

Original comment by michael.hale@gmail.com on 11 Mar 2014 at 2:41