Rootkits have become the most devious method of hiding malware on a system.
They are being employed to every sector from the home user to government to private industry.The monetary and information losses along with infrastructure disruption will continue to rise unless some way is developed to stop them.
What is a Rootkit ?
According to Wikipedia.
“A rootkit is a stealthy type of software, typically malicious, designed to hide the existence of certain processes or programs from normal methods of detection and enable continued privileged access to a computer.”
How do we stop them?
To stop them we have to understand how they work.
They, depending on how sophisticated they are can install a Windows service, Windows user mode driver, or a Windows kernel mode driver. They can also Infect the boot sector of a disk(boot kit), they can also create a hidden partition or volume to hide there files or even encrypt files so they are not easily identified about what they contain. They can also create task , either normal or WMI task to start at a given time or as a result to some action.I almost forgot about alternate data streams.
The basic idea is to install the driver or service so it can “Hide” itself and the other files registry keys and processes it needs to operate.
How it does this is by intercepting calls to list files or registry setting or process info or even disk info and can therefore remove from the results a predetermined set of files or registry or process entries effectively hiding there existence so no one knows they are there by using normal means.
How do you find them?
They can be very difficult to find, again depending on how sophisticated they are.
First off you need to understand like in network analysis what is “Normal” for a system.
The first step would be to determine if there is a process(s) running that do not conform to “Normal”, like multiple system process that should only have 1 copy of itself running, then you could check to see if there are items set to auto start on reboot that do not conform to “Normal” or any extra task that may have been added or network traffic to places it shouldn’t be going, also there are tools to check for encrypted files on the system.
Given what we know of the capability’s of these bad boys we can not be certain a system is “Clean” just because the system looks “Normal”. It could have these “Cloaking” drivers/ services running in the background.
The next step would start to delve into the world of computer forensics, where you would take a system off line and scan it for the traits previously mentioned, registry keys that shouldn’t be there, files that used to be hidden are now there or encrypted files where none should be, partitions that were not previously showing up thru the normal methods.
All of these and more could be a sign of some form of infection.(Or DRM Software)
I have been looking into service security and other information involved with them for over a year.
After reading several reverse engineering papers on different Rootkits and other malware one thing became clear and I developed a theory(educated guess).
The theory is a simple one . The implementation of it is not.
To the best of my knowledge every service or driver “Has” to “Register” with the system before it can do was it was intended to do. Whether or not it drops a file to disk or loads its code into memory and never touches the disk.
This is where I believe the weak point is.
The “Theory” is to have a service or driver “Listen” for services and drivers being “Registered” with the system and, either scan it or at the very least log it and possibly send a administrator alert before it has a chance to infect a system and hide itself. The location of the log file would need to be well protected to keep anyone from removing it or changing its contents and thus continue to hide itself. Although the missing file itself would be a red flag that that system would need to be investigated further.If the file was changed or edited then it might prove difficult to verify what got changed in it and thus back to the possible need to send an alert out also.
This way there will be a trail of what and when they got “Registered” with the system and possibly make the detection and removal faster. If it was somehow incorporated in a antivirus solution it may be even better as they already have a driver on the system.
The down side is if the system is already infected anything before that point would not be logged and any future ones may get filtered out by the Virus/Rootkit. You could also make a list of drivers not to be logged in order to keep down the log size but that would need to be protect also.
So far this is still a “Theory”, I still need to create a proof of concept program and build my malware lab to test against this “Theory” looking for any holes in it.
There are at least a few ways I can think of doing this and they start from the hard way to the very difficult as there seems to be no built in way to do this.
Lets see a little demonstration on how difficult it can be just to find a driver under normal conditions without being infected (that I know of ).
Have you ever wondered how Sysinternals Process Explorer works ?
In its most basic sense it just installs a device driver and listens for system calls and events and can report them back to the user application, Process Explorer, such as process start or process end and information about each individual process and it’s threads and can give you a stack trace also for that moment in time and much more.
The question is how do you find this process or driver that it is using?
The driver does not show up in the MMC Services or in Device manager.
When using Process Monitor to view the launch of Process Explorer the driver name does not show up if it has already been launched once, it is still loaded into memory. Upon reboot run Process Monitor then run Process Explorer and then you can see the driver dropped to disk, loaded to memory then delete the file on disk.
On a 64 bit system Process Explorer starts the 32 bit version then extracts the 64 bit version to a temp folder then starts it and then extracts the driver to the system drivers folder to be loaded to memory before being deleted from disk.
So again how do we figure out what driver it is using. The easiest way it to also use the lower pane option of Process Explorer. If on a 64 bit system select the process “procexp64” and select the view handles option on the toolbar.
Next sort by type then scroll down to the type “File” then look for an entry that starts with “\Device\drivername”.
In this case it is easy to spot. We are looking for “Device\PROCEXP 152” used with version 15.42 at least of Process Explorer.
Ok so how else can we find out what this driver name is.
If it is a normal driver install you can look into 2 places for the physical file.
“C:\Windows\System32\drivers” or if it is a 64 bit system “C:\Windows\SysWOW64\drivers” or one of the sub directory located in those folders but it could be dropped anywhere on the system, in the program files folder, in a temp folder, anywhere it may have read/write or read/execute access.
During my investigations I have created several tools to help with getting information more easily out of the registry and a system.
When a service or driver is registered it gets registered in the system registry under the keys:
The same name could possibly be loaded into both keys depending on the type of driver it is.
Lets start with what you see as the system normally shows you. The places that give information on installed services are thru the MMC utility “Services” Which on my system shows 173 services(counting by hand). Using a program that utilizes the Service Process class also return 173 services, using WMI also returns the same number.
Then for the drivers you have Device Manager you also need to select the show hidden devices to show the Non Plug and play devices or “Legacy Devices’.
Viewing it this way in Device Manager is difficult to get a count on how many are there but what I want to relay is that using WMI Win32_SystemDriver only returns a list of 248 found on my system, but using the service process class again and selecting the type of driver instead of service it returns a list of 271 a difference of 23. I have created a new program to find the difference in what is missing. I can only assume that they are not listed thru WMI because there is no physical file on disk for them (so far that I have found). Perhaps they are the ones that were uninstalled. I still have to track down each one and see what they do then build a database to log the information in.
Also the Process Explorer driver did not show up in either my regular tools or Device Manager to reveal the name of the driver
Using this tool though:
Here we see that there were in fact three different versions of this driver registered with the system. All this tool does is enumerate the registry key. I have made it to be able to enumerate any control set numbers that it finds to check for any possible differences.
While writing this I had CurrentControlSet, Controlset001 and Controlset002. When I enumerated them the count was “1” different between CurrentControlSet, Controlset001 and Controlset002(diff). Viewing the list of both side by side I could not see the difference so I saved a copy of the list for each and then rebooted into another OS partition loaded the registry key for this partition and then dumped it just in case something was hidden. Using my new List Diff tool with the first 2 list I saved before the reboot I was able to track the difference to a driver that I recently uninstalled .
Upon rebooting into this OS I then discovered there was no longer a ControlSet002 listed, instead there was a ControlSet003 and no ControlSet002 most likely because I did the uninstall and the list changed.
After a small test searching the system for files by name, the names that appears here in the list seems to be the actual name of the driver without the “LEGACY_” tacked on to the beginning.
Another tool I found while researching this, called DevManView from NirSoft, can get the same information from the registry once you enable the show non plug and play devices under the options tab.
I also tested if a Administrator could delete one of the entries. The current Security settings does not allow a “User” to change the security, take ownership or delete the key.
So in conclusion the best I can tell once a service or driver is installed on a system then it will stay on this list unless advanced methods are used to remove it or it gets uninstalled/unregistered and then system is rebooted. As long as the results of the enumeration are not filtered it should give a good history of what was loaded on the system and not uninstalled.
I am adding a link to my SkyDrive where I will have a zip files containing several tools the file name is BlogTools.zip. It will also have a readme file with the files names,description, and a how to use, most are pretty self explanatory on how to use.
Once this post gets consumed by the “RootAdmin” site I will try and add them there also.
I look forward to any comments or feedback.
Filed under: RootAdmin