I was recently looking at a memory collection of about 4GB and started thinking about the order of volatility. A 4GB memory capture to a USB key can take an inordinate amount of time, and during that time the other volatile data on the system is not only changing, it's potentially disappearing. Take for instance a netstat command that shows a connection that's ESTABLISHED. While collecting memory and nothing else on the system that connection would go from ESTABLISHED to CLOSED, to disappearing all together from your state table. While this information can certainly be collected from memory, it's still collected when you run netstat (or other similar network state table collection software). So what's my point?
Well I suppose it requires more experimentation with the concept but is it necessary to collect network state information externally if you're already collecting ram contents which contains the same state information? My thoughts are no, although it does give you network state during two points in time, which may be a more accurate "smear". Would forking the memory capture process to collect network state at the same time make more sense? It would create a bigger footprint, but the network state would be captured independently of memory, at the same time.
What are your thoughts?
EDIT: 12/4/07 changed wording about ESTABLISHED connection.
Sunday, December 2, 2007
Subscribe to:
Post Comments (Atom)
5 comments:
This is an issue where informed discussion needs to take place.
The reality is that right now, there are no tools legitimately available to consultants to dump the contents of RAM from Windows systems, with the exception of old, no-longer-supported versions of Garner's dd.exe, and ProDiscover. License agreements rule out the use of tools like Nigilant32 for consultants. For Windows 2003 SP1 and above, there are no exceptions.
So, who else is going to collect the contents of RAM for analysis? Perhaps the very rare sysadmin.
Now, let's consider the acquisition of 4GB of RAM, to a thumb drive. Yes, this will take some time...therefore the Order of Volatility would suggest that you acquire the network connections first, and then dump the RAM.
"...although it does give you network state during two points in time, which may be a more accurate "smear""
I would agree that having both would be beneficial, if you had a way of parsing the network connections from the RAM dump in a way that would allow you to compare the two outputs.
Again, this needs to be looked and discussed in an informed manner.
I agree, there are no more *free* tools available. KntDD is available for use, as is Livewire.
Farmer and Venema state(ch.1 p6 table 1.2) that Main memory has a lifespan of nanoseconds while network state has a lifespan of milliseconds.
Rfc3227 states an example only. It does not once mention network state. It simply mentions the routing table and arp cache. Neither of these is state of network connections.
Even you have stated that memory should be captured first.
The OOV states that the more rapidly changing information should almost always be preserved first. While many are in agreement that memory should be captured first, I'm questioning whether or not that is accurate anymore if given the amount of memory and the time it can take to image, especially given that we may lose network state during the capture and potentially other information.
I'm also questioning if network state needs to be captured independently at all. It may hinge on how quickly network state is actually captured during the memory dump. Useful yes, required..I don't know.
I'm merely wondering if memory can be parsed as it's captured for network state tables so they can be timestamped and therefore be marked as a point in time capture to eliminate a step.
KntDD is available for use...
However, the availability is limited by the author, AND there is a cost associated with it.
Farmer and Venema state(ch.1 p6 table 1.2) that Main memory has a lifespan of nanoseconds while network state has a lifespan of milliseconds.
Sure, but to what level of granularity? There has been information to show that remnants of exited processes have remained in main memory until expressly overwritten, and in some cases, some have even survived reboots.
Now, consider dumping the contents of 4GB of RAM to a thumb drive...in the time it takes for that activity to complete, processes can exit and network connections can change state and even time out.
The OOV states that the more rapidly changing information should almost always be preserved first.
Agreed. However, one also needs to consider what is actually being addressed. There are a lot of principles we can quote, but I guess the real question is, how much does memory *really* change? I think that what Farmer and Venema were trying to point is that the contents of main memory can change in as little as a nanosecond, but does this really occur in practice? The same goes with network connections...they can change in milliseconds, but in reality, how long does it take a TCP/IP connection to time-out, or simply change state?
I'm also questioning if network state needs to be captured independently at all.
I would suggest that it does.
Right now, what tools are available, freely or otherwise, that will take a Windows 2003 (no SP) RAM dump and parse out the network connections?
I'm merely wondering if memory can be parsed as it's captured...
I'm sure that this is possible, but as there do not seem to be any applications created to this specification, I would think that it would be extremely expensive. For one, the app would need to work with all versions of Windows to extract the contents of memory. Next, there does not seem to be a great deal of documentation on network connection tables, as AW can attest to.
The reason why we capture network and other state information using user mode API's is because we found that it was impossible to prove that some resource was hidden unless we first documented what the "bad guy" wants us to see. KnTList uses the user system state programmatically to implement a cross-view detection algorithm. That's why the output is in XML. A smart attacker may use an existing ("legitimate") endpoint, anyway (rather than opening a new one). I have seen computers infected with spyware that used ZA's secure IM for command and control from within a legitimate process. The user mode API's don't display all of the network endpoints even in their known good state, in any event.
Harlan: Yes, we do vet our clients to ensure that they and the companies that they work for are reputable. But are you aware of anyone (reputable) who has sought to purchase the KnTTools (private consultant or otherwise) and been denied? We have even sold to private consultants associated with our (potential) competitors. If someone is making money off of our work it is not ureasonable that they should pass some of it along, particularly in consideration of the substantial investment in both time and money that it took to develop these tools.
- Rossetoecioccolato.
George,
But are you aware of anyone (reputable) who has sought to purchase the KnTTools (private consultant or otherwise) and been denied?
I would have hoped that you would have contacted me privately with this regard, but I'll respond to you here...
When I purchased the kntdd from you, after participating in the beta program, my understanding was that I was allowed to us the tool for my own private use, and that I could not use it in a consulting capacity when doing work for my employer.
At the time I made my purchase, my further understanding was that a license agreement for large public consulting firms hadn't been completed, and as yet I haven't become aware of one.
Thanks,
Harlan
Post a Comment