I was reading a thread over on the SecurityFocus Security-Basics list about hidden files and processes this morning...it seemed to address rootkits. It was very interesting to read through the thread and see the processes followed, given the information posted in the first post, by the respondants.
With regards to the hidden process, the original poster (OP) stated that he used nmap to detect an FTP server listening on a non-standard port...given that he didn't say which port it was, all we can assume at this point is that it wasn't port 21. The OP went on to say that he connected to the port using an FTP client, and when he sat at the console, he used several tools...Active Ports, Fport, and TCPView...but couldn't "see" the listening port.
At the final entry in the thread, the OP stated that he'd found the rootkit, but didn't say which one it was. I think it's interesting to see the process or methodology people (re: Windows administrators) use when they're in a situation like that...they know that a port is open, via nmap and connecting to it, but don't see it when they're at the console. There's nothing wrong with the tools that the OP used, but I would like to make some suggestions with regards to the methodology that was used...
In my book, I did some research using AFX Rootkit 2003 (other rootkits will be analyzed in the second edition) and found that there are subtleties that can be taken advantage of when looking to see if there is a rootkit installed. For example, the HackerDefender rootkit installs as a service, and can (allegedly) be detected by such tools as RKDetect. RKDetect enumerates services via WMI and the SCM, and compares the two for anomolies. This is the same sort of approach I used in the rootkit detection script I included in my book, though my approach looks at Registry keys, files, services, processes, etc.
Another tool to use would have been tlist.exe from the Microsoft Debugger Tools, as this tool lets you see which processes are associated with which services. I haven't worked specifically with the HackerDefender rootkit, but I have found that tools like pslist.exe from SysInternals can also be used as part of an anomoly detection methodology.
My point is that relying on one technique usually isn't enough, particularly in the face of rootkits. Use multiple tools...I prefer openports.exe over fport.exe for process-to-port mapping, for example. I'd also compare the contents of the HKLM\..\Run key when retrieved remotely to those retrieved locally...the same for the various subkeys under the Services key. This is due to the fact that when the enumeration is done remotely, the APIs on the remote system aren't being hooked by the rootkit. Looking for disparities will help you see if something untoward has been installed.
One final thing...one of the respondants recommended using a tool called "HideWindow" to see which windows were open on the desktop but not visible. This was an interesting response, because on the surface, it seems off-topic. What it really is is a lack of understanding of tools and rootkits in particular. I took a look at HideWindow when I wrote the No Stone Unturned series for SecurityFocus. This tool simply makes a window invisible to the desktop, but does nothing to hide the process.
So, I guess we continue down the road...
2 comments:
Interesting comments and a good read thanks :)
BTW Microsoft did not invent the use of the term rootkit the original writer of NTROOT Greg Hoglund was mainly responsible for the naming convention which has now well and truly stuck.
Post a Comment