Process Guard Rootkit prevention - in need of an update?

Nonsense. It´s impossible to always decide what is good and what is bad.

The execution prevention is fully nonsense in my opinion.

The best way is a kind of iron sandbox system, give the possibility to the bad guys to show what they are able to do, trace them back, track them down and jail them.

 

You made a good point SystemJunkie, execution prevention is important, but isn't as effective in case of software install for example.

Errr...No , executable control can "block a rootkit" as well as any legit process : you Word processor, calc, a game... just anything, good or bad. Doing so is merely a test about the program's execution protection, nothing more.

I agree that in real life, the better and most safe way to block a rootkit is to prevent the file from starting. Better not to run nasty files at all, no problems on that point. That being said, blocking file from starting is different than blocking a rootkit install : It's just blocking the rootkit installer, dropper. In this scenario, you may block a rootkit as well as any malware kind, virus, spyware, trojan.

The features description, regarding Process Guard, takes it this way (see picture), could I say : Blocking rootkit is only available in full version (though free version has enough protection to stop most user-mode rootkits).

Now, from a "testing" perspective, it wouldn't make sense at all to pretend rootkits are blocked by preventing files from starting, I think it's obvious. Tests would be quick and very easy to do , but I think such tests would not be interesting for readers. When testing a program on its ability to stop rootkits, you have to let the file run, to see how the rootkit is blocked - or not. A rootkit has "special actions" to make, in order to hide on the system, and that's what needs to be checked, when doing a test : Did these actions work, or were they blocked?

Same goes for leaktests, for example : In your view, blocking file start would equal to a passed test, regarding firewalls, now that a lot of FW do have execution control. Here again, it doesn't work this way : Blocking file start do not allow you to see how your firewall handles the network attempt, if it can detect it or not.


Another point : Following your thought, PG wouldn't need update thanks to its execution protection ability only. That's not how Diamondcs team did consider the problem, last year, when I posted about a termination method PG didn't block at this time : A new version of PG was released, protecting against this termination method (it was about the XP killer trojan, see here ) . I consider the problem is the same today, about this rootkit : Rootkit won't install if you do not allow it to run, but PG is not able to block it once the files run.

ps: What is the source you've quoted, btw?

Cheers,

nicM

 

Anyhow, I still think PG(Full version) is up to date against any rootkit.

It is really stable and powerful in AD. Many thanks to the original developers.

 

Perhaps, there r some misunderstandings here.

IMO, "AD"means "application defend"----control anything that executable , prevent apps/processes from being stopped/suspended/injected code, even including rootkit.

PG really runs very stable on my system, never with any problem; although it only has basic functions.

 

That is absolutely true and nothing else counts. A protection program must be able to defend the system against running rootkits, all other is useless.

As I said forget execution prevention.
Beside the way App Defend handles it is much better then PG, because it also acts as a network firewall.

L*o*L you are still dreaming man. Nothing is fully secure.

 

Fine, but be assured that there is at least one rootkit which can bypass it for now .

Still a good ratio, when you think about the amount of rootkits it is able to block.

 

as I said.. no 100% secure app in this world.

 

Unfortunately

 

U r right. That is why I always combine PG with other "FD" app (including something with "FD" functionality) such as "SafeSystem 2006" or "McAfee VirusScan Enterprise 8.5i " to protect critical files from any alteration ,deletion, even being read. I suppose this may help a lot in fighting against RootKit.

 

1. I prefer to apply some professional firewall .
2. Sure, no compelete protection/security should be expected.
But, I still trust PG , caz I am some kind of optimistic.

 

These exchanges shared in this Topic continue to support the benefits of a Layered approach no matter what. It would be nice to have a single app a shield-all and especially against rootkits but of course those too originate from a single executable as in dropper which was mentioned a bit earlier.

Now more on topic here, it quickly becomes clear enough why there is still great interest by users in ProcessGuard even though it is considered somewhat defunct now but not entirely just yet i think. From my testings with it awhile back and shortly after it was abandoned, i gave it a whirl and while it's coverage was reasonably adequate enough for the average malware if there is such a thing, like any other security app it had weaknesses. Now with that being said it's always going to be good practice with any of these type programs to compliment or cover them with another to fill the gaps.

For example i regularly used System Safety Monitor to keep my other security apps "in memory" in event a malware was coded to Terminate them even if they already contained self-protection.
PG was no exception.

I do admire loyalty of users in programs the majority others consider useless due to them being outdated or abandoned so long as they still can prove to still serve enough of a useful purpose for some protection. I still use Kerio 2.15 as outdated as it's regarded by now, but no other firewall for me has proved itself this long going all the way back to Windows 98SE and Me, and i'm still yet to find any need to switch. It works, it's light, and completely stable and nothing malicious ever makes it's way in without being detected plus it's prevented from permanant shut-down by SSM's feature.

 

I'm a very weak point between chair and keyboard, but whatever I do wrong or malware do wrong, I will reboot each time in a clean, trouble-free and malware-free computer. So it doesn't matter who is sitting on my chair.

 

Eric, how many times u are writing the word reboot each day( since u stopped using the word freeze)?

 

hi nicM!

Could you reply the test with another top HIPS like ProSecurity in order to see if there are behavioural differences? (is this last one able to identify the service install method not covered by PG or the result is the same?...)

Sorry for my poor enghlish and txs in advance!

 

Hold on, people : Another rootkit passing through PG like butter : Trojan.Win32.Pakes.n

In this case, nothing to change in PG settings, protection on maximum level, but service installed with flying colours, PG doesn't even notice anything once the file is allowed to run. Even more obvious fail for PG than with the former rootkit I've been talking about in this thread, just one single dropper here. Will post screenshots later.

This one was noticed by someone else, not me btw.

alfa1, I'll try to do if I can find time, but honestly I'm very busy doing tests on another app so i can't promise .

ps : The culprit :

Complete scanning result of "NTUPDSRV.EXE", received in VirusTotal at 05.20.2007, 04:53:22 (CET).

Antivirus Version Update Result
AhnLab-V3 2007.5.16.1 05.18.2007 no virus found
AntiVir 7.4.0.23 05.18.2007 HEUR/Crypted
Authentium 4.93.8 05.18.2007 no virus found
Avast 4.7.997.0 05.18.2007 no virus found
AVG 7.5.0.467 05.19.2007 no virus found
BitDefender 7.2 05.20.2007 no virus found
CAT-QuickHeal 9.00 05.18.2007 (Suspicious) - DNAScan
ClamAV devel-20070416 05.19.2007 no virus found
DrWeb 4.33 05.19.2007 no virus found
eSafe 7.0.15.0 05.17.2007 Suspicious Trojan/Worm
eTrust-Vet 30.7.3644 05.19.2007 no virus found
Ewido 4.0 05.19.2007 Trojan.Pakes.n
FileAdvisor 1 05.20.2007 no virus found
Fortinet 2.85.0.0 05.20.2007 W32/Pakes.N!tr
F-Prot 4.3.2.48 05.18.2007 no virus found
F-Secure 6.70.13030.0 05.18.2007 Trojan.Win32.Pakes.n
Ikarus T3.1.1.7 05.19.2007 Trojan.Win32.Pakes.n
Kaspersky 4.0.2.24 05.20.2007 Trojan.Win32.Pakes.n
McAfee 5034 05.18.2007 no virus found
Microsoft 1.2503 05.20.2007 no virus found
NOD32v2 2277 05.18.2007 no virus found
Norman 5.80.02 05.18.2007 no virus found
Panda 9.0.0.4 05.19.2007 Suspicious file
Prevx1 V2 05.20.2007 no virus found
Sophos 4.17.0 05.18.2007 no virus found
Sunbelt 2.2.907.0 05.17.2007 no virus found
Symantec 10 05.20.2007 no virus found
TheHacker 6.1.6.118 05.18.2007 no virus found
VBA32 3.12.0 05.18.2007 no virus found
VirusBuster 4.3.7:9 05.19.2007 no virus found
Webwasher-Gateway 6.0.1 05.18.2007 Heuristic.Crypted

Cheers,

nicM

 

It's evident that there are two perspectives on prevention being discussed.

Prevention=Blocking - Posts # 4,12,21,25

Prevention=Detection - The OP and others start from the standpoint that the dropper/installer has gotten onto the system and PG needs to snag it.

For those arguing this point of view, how do you suggest that a malware file would get into the computer in the first place, and therefore need to be detected (prevented from executing its rootkit instructions)?

regards,

-rich

________________________________________________________________
"Talking About Security Can Lead To Anxiety, Panic, And Dread...
Or Cool Assessments, Common Sense And Practical Planning..."

--Bruce Schneier​

 

NicM,

I tried to find Trojan.Win32.Pakes.n on the internet. Could not find it. Would you try this against EQSecure (you can download post #21 from https://www.wilderssecurity.com/showthread.php?t=170691)
Thx in advance K

 

I've just uploaded a video displaying this infection, since I feel lot of scepticism in the air :

http://rapidshare.com/files/32374564/rootkit.avi.html

Vid is 2.30 mn long, 50 Mb, full screen; I didn't know how to make it smaller while keeping a decent quality.

I think it shows it all, you can see a new instance of svchost.exe, hidden, running without any alert from PG, and no alert either for the driver, syssrv.sys.

 

Rmus, I understand your point of view (if you look closely at one of my previous post, you'll see that I admit that it is better not to run malwares at all, in "real life" perspective), but I think your opinion is biased by the way your main protection program works : Anti-executable. Here, you have no option but to prevent the file from running, this is obvious. This program can't help once the file is running.

With HIPS like Proces Guard (full), SSM, OA 2, DSA, Prosecurity, and all, you can let a rootkit dropper run, and block its rootkit install, by blocking its driver install when rootkit is kernel-mode, for example. Then some programs will manage to do, some won't, as I tried to show with these two rootkits discussed here regarding Process Guard. In fact yes, some other programs are able to stop the 2nd one (didn't have time to check for the 1st one yet).

That's what makes such tests interesting.

Cheers,

nicM

 

I think that Trojan.Win32.Pakes.n is a signature for certain runtime packers. So, you won't find any info about it.

 

I concede that point. But I'm asking, under what circumstances the file gets on my computer in the first place, in order to run.

regards,

-rich

________________________________________________________________
"Talking About Security Can Lead To Anxiety, Panic, And Dread...
Or Cool Assessments, Common Sense And Practical Planning..."

--Bruce Schneier​

 

I don't know, there are lots of possibilities : The file is part of software you're installing, or binded in another file you run to install a program, for example.

But does that really count? My intent wasn't to start a kind of brainstorming about general security practice, here, just to pinpoint a weakness in the way PG handles driver installation : Some new rootkits start making its rootkit protection unreliable these days, that was the point.

Some programs are able to block it, some are not, and checking which programs do belong to which category can help. If you don't care about what happens once a file is running since the "only" way to truly block the threat is to prevent it from running, fine, but blocking processes from running is useful to a certain point only. I think some people will concur with that point.