CSA has taken to set detected rootkit as Untrusted

[Patrick Laidlaw]

Hello,

So I have a machine with CSA 5.0 wich has detected a root kit is installed. My question is how do we figure out what kind of root kit it is and how to remove it?

Patrick

[tsteger1]

You may not want to remove or block what it finds. The rule sets any detected rootkits as untrusted by default. We have a file called kblock.sys that is part of the Novell client. We want to allow it so we created a rule to set it as trusted. You can use the wizard to do it.

Go through the events and see what is listed as a rootkit and make your decisions based on that.

Tom S

[Patrick Laidlaw]

Tom,

I appreciate your response but that isn't an acceptable thing to do. Under normal circumstances this wouldn't be a problem if it didn't have the root kit detected the actions would be valid and it wouldn't log these messages. By tuning them out if it happened to another machine we wouldn't know about it.

I was looking to see if someone knew a way to figure out what the root kit was and how to remove it.

Patrick

[tsteger1]

Hi Patrick, Maybe I didn't understand your question. I also don't know which rule found the rootkit or what it was.

The default kernel protection rule on my system sets all items it finds as untrusted rootkits (whether they are or not).

This way (in my opinion) it gives you the opportunity to see everything it finds and allow you to make exceptions for those you trust. It's kind of like a watchdog.

I also wasn't advocating tuning them out, only allowing those you trusted.

Hope this clears things up a bit.

Tom

[joseph.hamilton]

to further build on what Tom said, you can set the rule to log all instances of setting the root kit as trusted. Therefore, you will see every time a computer has that instance.

[villaen]

Hi Tom,

I ran into this at one of my installations, but was unable to determine what was triggering the rootkit detection. The Wizard didn't seem to help much either. And even Cisco TAC didn't seem to help either.

I don't have access to that system any more, but I may be installing 5.0 for another client, and want to find out what I can about these Untrusted Root Kit events.

Do you have any advice for me?

Thanks in advance.

Henry Villarreal

[joseph.hamilton]

Henry,

This isn't necessarily a problem on all computers. Untrusted root kits usually are modules loaded after boot time. In many cases, the root kit is something good (In our case, it was SYMEVENT.SYS, which is part of the Symantec virus suite). What you can do in these cases, is make an exception rule to specificly target the good root kits and have them marked as trusted. This will allow CSA to continue marking other root kits as bad, but take the known GOOD one and let it be trusted.

To do this, you should look through details of the event where the rootkit is set to Untrusted and try to determine a pattern in the code.

Patrick, your case might be a bit different, since TAC could not help resolve it. We had to use TAC for one of ours because the process triggering the rule was "unknown", so obviously we couldn't just set "unknown" root kits as Trusted. If you are concerned about someone hacking that file and doing something mischevious with it, you could try to put some extra file protections on it to prevent changes.

[tsteger1]

Hi Henry, it's tough to make exceptions if you don't know what's causing the alerts, eh? We have several systems getting the $_unknown:XXXX_$ error messages. Fortunately they are the same ones and are few compared with the number of installs we have. The ones I've been able to look at were caused by application failures and were usually accompanied by a Dr Watson error and a logged event.

If it comes up again I would look at the machine closely, especially the Windows app and system event logs, for clues. My experience has been that the machine is sick to begin with and this is just one of the symptoms.

As far as setting known post-boot modules as trusted, that can usually be accomplished with the wizard.

Hope this helps..

Tom S