Screenshot: Rootkit infection stopped by Process Guard

Attached is a screenshot of Process Guard stopping the infection of a rootkit dead in its tracks. The screenshot shows the blocking of a rootkit known as "NT Rootkit", but the protection works against all driver-based (ie. kernel-mode) rootkits - the stealthiest of the stealthiest. Process Guard is able to prevent rootkit infections by securely blocking the installation of drivers, and although there are several ways to load drivers (including some undocumented methods used by recent rootkits), Process Guard is able to block all of them.

 

root kits are those bad or a new form of attack nowadays

 

Thanks Wayne, I notice that "deploy.exe" was allowed to start thus allowing the the driver to try and install - So in effect an alert user would probably not have allowed even deploy.exe to run, thus stopping such an attack in two different ways - Good stuff

 

Blaze,
Rootkits are stealthy trojans that attempt to hide themselves by modifying the functions used to detect them. For example, they might modify functions that enumerate processes so as to hide themselves from process enumeration lists. Once a rootkit has infected your system it is basically game over because usually nothing can then detect it (due to the system modifications the rootkit makes), so a proactive approach is the best way to go - it's a lot easier to block a rootkit infection than it is to disinfect one.

Pilli,
You're absolutely correct - for the screenshot we had to allow deploy.exe to run (you could consider that the "rootkit dropper"), because you can't just execute a .sys file like you can a .exe file. So, rootkits are confronted by two layers of Process Guard protection.

 

ouch yuck

 

For me, the beauty of Process Guard is the depth of protection provided without the need for daily updates. Just a short while in learning mode and some time spent adding potentially vulnerable programs, after that Process guard is usually very non-intrusive.

 

"Hacker Defender" is one of the most advanced rootkits ever made and is in constant development, it's one of the main rootkit threats out there at the moment. HOWEVER! It doesn't matter how many variants are made or how encrypted/packed they become - Process Guard will prevent the infection of all of them:

 

If services.exe has been set in Process Guard to allow ''install services/drivers'' and the rootkit loads its code via services.exe am I correct in assuming that the rootkit would have been able to succeed?

(If this is correct)I don't know how difficult or possible this would be but I think it would be excellent if Process Guard dealt with dynamic rules. So instead of all programs in the protected list having access to use services.exe to load services /drivers for example, only specific programs could do this. Currently when I allow services.exe to install services/drivers I think all programs in the protected list can also use services.exe to install services/drivers. With the dynamic ruleset, each rule would either be specific or global so I could allow one program access to using services.exe and I could deny another. lol hope this makes some sense.

 

Does it good to suggest that PG users should disbble "rootkit/driver...installation" to services.exe and smss.exe (nt) anyway until known that a "may be trusted" application needs to install a driver to make a complete & successful installation?
For a rookit to install successfully, its dropper must be run. If not let the dropper to run, rootkit kernel driver not be able to be installed?
The problem with many users (me too) is with trying new softwares and ones downloaded from the Internet (good/no sure-good site or sources).
?

 

But wouldn't PG warn you about such a rootkit when the rootkit executes (before it "loads itself via services.exe")?

 

Hi rerun2:

Wayne wrote in post 4

Cheers. Pilli

 

YES. You may have to do this if you use software which takes this method to install a driver. Haven't seen many that do this, I recommend contacting the vendor and asking them to install the service themselves not use services.exe. Since maturity of ProcessGuard this is somewhat of a design flaw in Windows and service creation. Vendors would be helpful if they installed services/drivers themselves - most seem to do this thankfully!.

DISABLING services.exe from installing a driver soon after boot will secure you against newly run programs though, so this is a very good option for some people.