During an engagement not long ago, the customer's IT staff had collected bits of the suspect network traffic, and then using the source IP address from the capture, located the system in question and ran "netstat -ano" on the system to prove that the traffic really did originate from that system. Task Manager and tasklist.exe also showed the process with the PID seen in the netstat output.

What does this have to do with rootkits? Well, for one...it proves that they didn't have one! I can't tell you the number of times someone's said to me, "I didn't see anything suspicious, so it must be a rootkit." Yeah, and if I turn my face toward the monitor and close my eyes, and don't see any unusual processes (or anything else for that matter), does that mean that there must be a rootkit on the system?

Well, all I can say is that the simplicity of that finding made it all the more awesome...

I received a comment to an older post from James (thanks, James!) yesterday who pointed me toward a very interesting article on Rootkit.com by Diablo. Diablo's article describes using the Windows CSRSS process as a built-in rootkit detection facility, and even provides some proof-of-concept code.

This is definitely worth a look, at least to get an understanding of the technique that Diablo is proposing. I've used RootkitRevealer and GMER as my primary tools for attempting to detect the use of rootkits on live systems, usually following some forensic analysis of the acquired image (feel free to ask me about this technique - but don't be afraid to share yours, as well).

Resources
How many csrss.exe process should be running in vista?
MS07-021
Default Processes in Windows 2000

Now that my book is available, I'll be posting things like updates and errata here in the blog.

As I mentioned before, one of chapters in the book addresses alternative analysis methods, and mentions the use of Mount Image Pro to mount the image as a read-only file system. I see this as a great opportunity for analysis for several different reasons...malware scanning, etc.

One of the things that didn't make it into the Registry Analysis chapter was a Registry key that controls the Recycle Bin. The following key is the one in question:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
\CurrentVersion\Explorer\BitBucket

If there is a value beneath this key named "NukeOnDelete" (DWORD) and the value is set to "1", then the Recycle Bin on the system is effectively disabled. This value isn't there by default, it must be added.

So how would we use this information in our analysis? Well, first off, just the fact that the value was added may indicate that (a) the user is sophisticated, or that (b) the user has used one of the privacy tools available on the Internet (we can correlate this to other data, as well).

Next, notice that the key is in the HKEY_LOCAL_MACHINE hive, meaning that it applies to the entire system, rather than just a single user. This doesn't mean that you should expect to see the Recycle Bin for each user (in the case of more than one user) empty, with a really small INFO2 (my book includes code for parsing the INFO2 file) file. Had the value been set after a user had sent files to their Recycle Bin, that INFO2 file should still contain the entries. We can then corrrelate those dates and times with the LastWrite time on the Registry key to determine approximately when the key was modified.

Okay, so does disabling the Recycle Bin slow down a forensic examiner? Not any more! We all know that deleted files aren't really gone.

Another update that I need to add for Chapter 7, Rootkits and Rootkit Detection is SysProt AntiRootkit. This one wasn't out before the book/chapter went to production, so I didn't have time to add it, but it's definitely worth looking at and adding to your toolkit.

One of the core concepts of my book is that by understanding how artifacts are created and modified, we see that the absence of an artifact where we expect to see one is, in itself, an artifact. Checking for this value and then correlating what you find to other findings on the system will provide clues not only to what happened on the system and when, but also to the technical sophistication of the user.

One final word...the book includes a DVD that contains an updated copy of my Registry spreadsheet, which contains several worksheets that list Registry keys and values of interest, why they are interesting for forensic analyists, and references to their function (where applicable). Be sure to add this one to your copy of the spreadsheet.

I picked this one up from the Securiteam blog this evening...it seems there's a new HaxDoor variant out. Symantec's technical write-up contains a lot of detail (useful to forensic analysts...the guys on the FIRST list should take note), and even though they do classify this one as a "backdoor", they do actually use the word "rootkit". For further reading:

• Trend Micro
• Sophos (probably the least useful)
  
• McAfee (click on "Symptoms")

This variant captures keystrokes, steals passwords, allows the attacker to download files, in addition to hiding itself, installing itself as a service, attempting to disable the Windows Security Center, and maintaining additional persistence by adding an entry to the following Registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Notify\

Here's some info from MS on that Winlogon\Notify entry.

One thing I think that's needed is an understanding of how clear, detailed write-ups on things like this are important to the IR/CF community. This sort of thing is very helpful when you're trying to ascertain the sophistication of an intrusion, and perhaps even develop some next steps. Remember, things such as NTFS ADSs and esoteric Registry key entries may be ho-hum boring to a lot of folks, but they're all pieces of the puzzle if you're doing IR/CF.

If you think you may have a rootkit, check out one of these tools.

I was browsing the F-Secure blog this morning and found something interesting...from last Friday, there was this post about reselling stolen information. Now, this is nothing new...this is just part of how organized online crime is becoming. Rather than one person doing everything, someone will purchase malware and use it to infect systems, then collect the data from Protected Storage, keystroke loggers, etc. This information is then sold to others for use...in fraud, identity theft, etc.

For a good example of this, take a look at Brian Krebs' story from 19 Feb 06.

What I thought was most interesting about the F-Secure blog entry was this:

These changing Haxdoor variants are generated with a toolkit known as "A-311 Death".

The toolkit itself is sold on the Internet by its author, known as "Corpse" or "Korpsov".

Okay, this is nothing new, either. Selling malware toolkits or custom rootkits is nothing new, either. This toolkit is based on Haxdoor. I started taking a look around and I found some interesting links. One was from the nmap-dev list...it's a discussion of a service detection signature for rootkits produced from this toolkit.

My post on Gromozon has some links to rootkit detection software.

Additional Resources:
AusCERT
McAfee Rootkits: The Growing Threat paper
Symantec C variant, D variant