Screenshot: Rootkit infection stopped by Process Guard

Discussion in 'ProcessGuard' started by Wayne - DiamondCS, Oct 1, 2004.

Thread Status:
Not open for further replies.
  1. Wayne - DiamondCS

    Wayne - DiamondCS Security Expert

    Joined:
    Jul 19, 2002
    Posts:
    1,533
    Location:
    Perth, Oz
    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. :)
     

    Attached Files:

  2. Mr.Blaze

    Mr.Blaze The Newbie Welcome Wagon

    Joined:
    Feb 3, 2003
    Posts:
    2,842
    Location:
    on the sofa
    root kits are those bad or a new form of attack nowadays
     
  3. Pilli

    Pilli Registered Member

    Joined:
    Feb 13, 2002
    Posts:
    6,217
    Location:
    Hampshire UK
    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 :)
     
  4. Wayne - DiamondCS

    Wayne - DiamondCS Security Expert

    Joined:
    Jul 19, 2002
    Posts:
    1,533
    Location:
    Perth, Oz
    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. :)
     
  5. Mr.Blaze

    Mr.Blaze The Newbie Welcome Wagon

    Joined:
    Feb 3, 2003
    Posts:
    2,842
    Location:
    on the sofa
    ouch yuck
     
  6. Pilli

    Pilli Registered Member

    Joined:
    Feb 13, 2002
    Posts:
    6,217
    Location:
    Hampshire UK
    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.
     
  7. Wayne - DiamondCS

    Wayne - DiamondCS Security Expert

    Joined:
    Jul 19, 2002
    Posts:
    1,533
    Location:
    Perth, Oz
    "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:
     

    Attached Files:

  8. Frieza

    Frieza Guest

    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.
     
  9. hochoi

    hochoi Guest

    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).
    ?
     
  10. Peter2150

    Peter2150 Global Moderator

    Joined:
    Sep 20, 2003
    Posts:
    17,048

    You are right, once services.exe has been given permission, the rootkit would have suceeded.

    Jason has said this is a tough nut, but I know I also need this.
     
  11. rerun2

    rerun2 Registered Member

    Joined:
    Aug 27, 2003
    Posts:
    338
    But wouldn't PG warn you about such a rootkit when the rootkit executes (before it "loads itself via services.exe")?
     
  12. Pilli

    Pilli Registered Member

    Joined:
    Feb 13, 2002
    Posts:
    6,217
    Location:
    Hampshire UK
    Hi rerun2:

    Wayne wrote in post 4
    Cheers. Pilli :)
     
  13. Gavin - DiamondCS

    Gavin - DiamondCS Former DCS Moderator

    Joined:
    Feb 10, 2002
    Posts:
    2,080
    Location:
    Perth, Western Australia
    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.
     
Thread Status:
Not open for further replies.