Introduction to Live Kernel Dissection for Forensics Purposes - Skinning a Cat For Meta Data 
By efi on Nov 20, 2007
Proper data gathering methodologies are a vital part of conducting a forensics analysis. This article will give a quick overview of some non-intrusive advanced data gathering techniques that involve running kernel dissection without tainting evidence. Data gathered in such a way can serve multiple purposes ranging from immediate evidence of intrusion to future event time line reconstruction.
Main topics discussed in this first installment of the article are:
- Why we choose the kernel as a metadata source
- Specific considerations for collecting reliable data.
IntroductionIn this article I will briefly describe a forensics data gathering technique using an underused data source, namely "The Operating Environment Kernel”. Almost all metadata we usually gather during a forensic analysis session exists in the OE Kernel. By using the OE Kernel as our primary data source we are gathering the most reliable metadata set available.
Metadata can broadly be described as the “data about the data”. In the current context we will use metadata as the data describing the current state of the system.
Live system data gathering is an important part of the overall data gathering process for forensics. During this stage of the forensics investigation the target machine is still up and running and we want to gather volatile data from it which otherwise, will disappear if the machine is shut down. Some of the most important and really volatile data we want to gather is metadata about processes, files and network connections.
The data gathering process should provide reliable data, and the process of gathering this type of data should not taint or alter in any way the remaining data.
In order to trust the data we should ensure the data source is reliable, meaning that it has not be corrupted, and that the tools we use to gather the data are trusted (i.e., The data will be interpreted in a predictable and expected way).
Making "sure" that the kernel is not tamperedBefore we go on we must make sure that the data we gather from the kernel has not been tampered with or been corrupted in any way. In some cases an advanced attacker might install and hide a Loadable Kernel Module (LKM) rootkit with the intent to hide his activities on the target machine.
(Some current techniques include advanced anti forensics such as hiding from ksysms and even dtrace but i will safe that for the future. Hey you cannot get all the fun at once!)
There are a lot of publicly available programs and tutorials dealing with the problem of detecting LKM rootkits. Some examples include :
- Checkrootkit : http://www.chkrootkit.org/
- RootkitHunter: http://www.rootkit.nl/
There is some current, but yet unpublished work, on Solaris specific kernel root kit detection tools. I hope to be able to speak more about them soon.
We should use all the tools,in the arsenal, in order to test the system in order to double check the result, but here comes a word of caution:
On a live crime scene you shall use only tools you know like the palm of your hand, you used and tested before! Even then, you should be able to describe and detect eventual footprint form the use of such tools, so use that ones you know best first!
Using these tools do not guarantee that the kernel was not "hotpatched" and there is no LKM installed but hey that is the fun part.
If a LKM is found proceed with extreme caution, having this in mind. Even if crying evidence is found on the kernel structures (hint - caches :-) do not feel tempted to touch hidden processes (dtracing ot truss'ing them) or list hidden files on the file system. The system might be trapped and you will see the evidence evaporate in your very face.
In the next installment of this article I will discuss more about safe tools and their safe usage.
See you soon!