So I am currently traveling for work but one of my colleagues emailed me about the following problem: getting different results for memory analysis based on the tool he used. He specifically mentioned volatility and Mandiant's Redline. Here is his email:I've been scratching my head on this memory image because when I do a connscan and sockscan [using volatility], I noticed some WEIRD activity, specifically, high PIDS and one with a PID of 0 and their offsets are just "-------". These PIDS have strange IPs associated with them, some of which are "blacklisted" according to www.robtex.com. Also, when doing a sockscan, one of the strange listings doesn't have a Protocol, instead of TCP or UDP it just shows a hyphen "-" . More importantly, these PIDS don't show up in pslist, psscan or psxview!!
Has anyone else ran into this issue? I am assuming it is because each program parses memory a different way. For example, does Mandiants tool show terminated connections when Volatility's connscan can do exactly that? I am not 100% sure-- so I ask the collective out there. And do not worry, you will not be thrown into a volcano or anything like that regardless of your answer :)
5 comments:
With respect to Volatility, have you asked Jamie Levy?
Was the memory dump from a 64bit or 32bit machine ?
This is a question that often comes up, but has been covered before and the answer can be found if one searches well enough:
http://lists.volatilesystems.com/pipermail/vol-users/2010-March/000175.html
http://code.google.com/p/volatility/wiki/CommandReference#connscan
http://code.google.com/p/volatility/wiki/CommandReference#sockscan
The "connscan" and "sockscan" plugins carve out residual information. This is important to understand and explains why one can sometimes get "unexpected" results. As my colleague MHL has explained to someone previously:
"
A connection is a data structure just like everything else. For example:
struct conn {
int ip;
ushort port;
int protocol;
};
Many structures will be fully accurate like this:
conn {1.2.3.4, 80, TCP};
Some structures will be partially overwritten after being disconnected
and the memory is released to the OS for another purpose:
conn {X.X.X.X, 80, TCP};
conn {1.2.3.4, XX, TCP};
conn {1.2.3.4, 80, XXX};
"
So sometimes various fields will be overwritten as seen above. It is also possible that the connection information is just a false positive that fits the pattern of a connection or socket (remember we are carving data here).
There are other things one can do in order to verify if any of the output is correct. For example, one can use the strings command to check for the same IP address in any other context: http://code.google.com/p/volatility/wiki/CommandReference#strings
, one can dump PEs or vads and see if the IP addresses show up there as well.... or various other things...
One can't really say that "all output with PIDs that are not in pslist/psscan etc are false positives", however, because this is residual information, parts of it can be correct. It is up to you as the analyst to verify and argue your findings.
I hope that helps :-)
Oh and I forgot to add that the two tools have different constraints for what is shown. Sometimes residual information is useful, so we (Volatility) have options to collect it with plugins like connscan and sockscan.
Whoa guys-- thanks for the comments! I had a feeling it was the commands and how each parses (carves) thru the memory. Each tool is different and has its pros and cons. As an analyst we have to be aware of the shortcomings and nuances of our toolkit and respond accordingly (corroborate with other data, run different plug-ins, LOGS (gasp))
I am not sure what my friend did for research into the issue. However thanks to your comments I am sure he now will be set on the right path... much Mahalo! :)
Post a Comment