Wednesday, January 05, 2005

Windows Rootkit Detection

I recently received an email from a fellow blogger asking about rootkit detectors for Windows. This was interesting, because there are quite a few for Linux/*nix, but almost (notice that I say "almost") none for Windows.

One such tool is RKDetect,a VBS script that launches both sc.exe (queries SCM) and a WMI query to get information about services on a system, and then by comparing the output of both queries, claims to be able to detect HackerDefender v1.0. (Note: I say "claims" because I haven't tested it myself).

The rootkit detection script I presented in my book takes a similar approach, but goes a bit further. The basic idea is that several methods of querying the "victim" system are used, in the hopes that one tool may use a different API to obtain it's information, and that one may not be masked by the rootkit. For example, I took a look at AFX Rootkit 2003 in my book, and while Microsoft's tlist.exe didn't "see" the hidden process, SysInternals' pslist.exe did. By using Perl to obtain the output of both tools and then compare them, the "hidden" process was located.
Another example of a technique used by my script was to query the Registry, in particular, the ubiquitous HKLM\..\Run key. Using psexec.exe from SysInternals, an admin can run a local query on the system for the contents of the key. Then, he could run a remote query for the contents of the same key from another system...a system not infected with the rootkit and therefore one without it's API calls (in the case of a DLL injection-type rootkit) being intercepted. Comparing the output of these two queries will reveal the "hidden" key entry.

Additional thoughts on rootkit detection techniques include scanning the "victim" system with nmap, saving the output to XML format. Run port-to-process mapping tools such as openports.exe and netstat.exe (on XP and above - I recommend that you use the'-o' and '-b' switches) and then parse the output with Perl. Perl modules exist forparsing the nmap output, specifically Nmap::Parse and Nmap::Parse::XML (and yes, Virginia, these modules are available for Windows via ActiveState's PPM)...and this can then be compared to the openports/netstat output to look for any disparities.

The point is that most of the currently available rootkits (I haven't seen or worked with them all) have design or implementation flaws that allow them to be detected, or perhaps even have their installation completely prevented. The AFX Rootkit 2003, for example, did nothing to hide its DLL files, which were visible in the file system, as well as in the output of listdlls.exe for the explorer.exe process.

Commercial tools (we've looked at freeware solutions so far) such as ProDiscover and EnCase have incident response capabilities, and use techniques for detecting rootkits. One such technique includes walking through the raw MFT (on NTFS drives) and then performing a directory listing via the operating system's utilities, and looking for disparities.

If you go to Rootkit.com, you'll not only find several rootkits, but there are also rootkit detection tools available, as well. I haven't tried tools like VICE yet, but I am looking into methods for detecting rootkits that implement direct kernelobject manipulation (DKOM).
Some other links for information regarding rootkit detection on Windows include Scheinsicherheit and RKDScan (here, or here).

At this point, you're probably asking yourself, "how prevalent are rootkits, or rootkit-like functionality?" Well, a quick look at SARC.com today revealed Backdoor.Zins and W32.Protoride.B. A thread on the Full-Disclosure list from Sept, '04, discussed the use of rootkits to hide spyware. Perhaps the real question should be, when will we see the next bit of malware with rootkit functionality?

No comments: