9:32 a.m.
Mike,
On Mon, Mar 12, 2012 at 10:30 PM, Mike Lambert <dragonforen(a)hotmail.com> wrote:
I have found an interesting result and have a fair
amount of data to share.
Bottom line is that connscan may have missed (and miss reported) some
connections (see memory image).
2 IPs are missing and note the ports recorded by cports and those reported
by V2.0 connscan. Check the attached xls search hits, where did port 1088
and 1064 come from?
First you should ask yourself why you're using connscan. Knowing these
things is a good idea. From the reference
(http://code.google.com/p/volatility/wiki/CommandReference#connscan)
it says:
"To find connection structures using pool tag scanning, use the
connscan command. This can find artifacts from previous connections
that have since been terminated."
So port 1088 and 1064 were used by fix_pack.exe. They are not detected
by cports because cports is a live tool running on the machine,
sometime after the 1088 and 1064 connections had closed.
For more information on the lifetime of socket and connection objects
(for example which APIs are involved in creating and freeing them),
see Chapter 18 of Malware Cookbook.
I can provide a copy of the memory image! Imager
is win32dd.exe.
Here is the IP connection record I have from cports:
Date Time Log action PID Program Name Proto Source
IP Destination IP
3/12/2012 3:53:10 PM Added 1344 fix_pack.exe TCP
192.168.1.44:1063 212.117.175.34:80
3/12/2012 3:53:10 PM Added 1344 fix_pack.exe TCP
192.168.1.44:1065 98.142.243.60:80
3/12/2012 3:53:10 PM Added 1344 fix_pack.exe TCP
192.168.1.44:1066 98.142.243.60:80
3/12/2012 3:53:11 PM Removed 1344 fix_pack.exe TCP
192.168.1.44:1065 98.142.243.60:80
3/12/2012 3:53:11 PM Removed 1344 fix_pack.exe TCP
192.168.1.44:1066 98.142.243.60:80
3/12/2012 3:53:45 PM Added 1344 fix_pack.exe TCP
192.168.1.44:1078 92.123.68.97:80
3/12/2012 3:54:06 PM Added 1344 fix_pack.exe TCP
192.168.1.44:1080 98.142.243.60:80
3/12/2012 3:54:06 PM Removed 1344 fix_pack.exe TCP
192.168.1.44:1078 92.123.68.97:80
3/12/2012 3:54:27 PM Removed 1344 fix_pack.exe TCP
192.168.1.44:1080 98.142.243.60:80
3/12/2012 3:54:30 PM Added 1344 fix_pack.exe TCP
192.168.1.44:1087 98.142.243.60:80
3/12/2012 3:54:31 PM Removed 1344 fix_pack.exe TCP
192.168.1.44:1063 212.117.175.34:80
3/12/2012 3:54:31 PM Removed 1344 fix_pack.exe TCP
192.168.1.44:1087 98.142.243.60:80
Here is the result of V2.0 connscan:
Scan for connection objects (connscan):
Offset Local Address Remote Address Pid
---------- ------------------------- ------------------------- ------
0x041484c0 192.168.1.44:1088 98.142.243.60:80 1344
0x04193278 192.168.1.44:1093 65.54.51.29:443 3756
0x041cdc40 192.168.1.44:1064 98.142.243.60:80 1344
Attached is search results of the memory image, with memory offsets. (A few
are dups and that may be the Win32dd imager)
Hmm, I'm not sure how you created this or what you expected to see in
the output. It looks like you searched for IP address strings in the
memory dump. There are a few things worth mentioning here. A lot of
the "noise" in the output appears to be from the live tool you ran
prior to capturing the memory dump (that's why you should always
capture volatility memory first - so your other tools don't pollute
the image). Also, if you're looking for connection objects this way,
you won't find them because the IPv4 addresses don't exist natively as
strings, they are just 32-bit numbers.
Hope that helps?
MHL
Where did ports 1088 and 1064 come from?
If anyone wants a copy of the memory image, it is 115 MB
Mike
_______________________________________________
Vol-users mailing list
Vol-users(a)volatilityfoundation.org
http://lists.volatilityfoundation.org/mailman/listinfo/vol-users