Rootkit-driver install not intercepted?

I tried to install a rootkit driver manually via w2k_loqd.exe. CFP gave SCM access alert. I denied it but driver seems to be loaded as shwon by rootrepeal. While EQS stops it from loading. Can anyone confirm. Thanks

Tested on a fresh snapshot of Eaz-Fix , XP Home SP2, no other security software installed at all. Fresh install of CFP with paranoid settings. Used shadowSurfer for testing though.

[attachment deleted by admin]

What happens when you use “safe mode” and have remember checked off?

I always checked off remember( snasphots of popups taken before that just on appearing of pop ups). Did not try safe mode but it must be same as safe mode is less secure or atleast same as paranoid.

I have the same situation here (as I did comment on Wilders).
Here you go with some screenshots:


Thanks for confirming my findings.

Seems detection of service/ driver isntall/ loading is one of the areas where CFP needs to be improved a lot. Sadly I have not got any response from developers though I have post about atleast five threads where CFP seems to fail or seems buggy( 3 about driver loading/ install, one about physical memory access and one about file creation).

Can you please put all of your proof of concepts into one archive and post here? And let me see what is going on…


I am afraid i can not verify your finding. CFP is intercepting the attempts successfully. Plus, w2k_load.exe does not use any fancy techniques to load the drivers.

Well i am sure you are aware of the fact that, once you install and load a rootkit driver, the tests you perform later is meaningless.

You have to use a clean PC to see if your rootkit is loaded again. Once you load it, do not assume it is going to go away…

EDIT: I was using the development snapshot and hence could not verify the issue. The build 378 does have this bug in Windows XP. Just verified. It will be fixed with the planned release in a couple of weeks.

Hi egemen, thanks for your confirmation.

Can you verify these three issues as well.

1- Driver install not intercepted

2- No alert for physical memory access

3- Wrong file creation alert

Thanks for your time

2 is not a case. Please have a fresh XP instalation without any security software and try again. Vettech already posted screenshots. CFP intercepts and catches properly. But if you send me your version of the binary, i can verify again.

EDIT: I have just verified that this can happen in some computers. It is a rare bug. Fixed. Probably many other products have it.

3 there are many cases in which it can happen. CFP approves but later in the file system stack the request fails etc. It is not a serious issue or a bug.

Hmmmm… and what about no.1.

Many thanks

some stupid question, what’s your explorer setting in D+ ?

where to find this exploit?

What is the relation of explorer in this driver install? Driver is loaded by windows installer, not explorer. Explorer has custom policy BTW.

i ask that cause with explorer rule “windows system application”, device driver installation is allowed.

update : i dled the file, aigle, thanks.

i don’t have the same files like on the top of the topic, maybe u posted the wrong archive?

You can get the same alerts from CFP if you modify the policy. You can remove msiexec.exe from the default policy and CFP will just act like the hips you compare it.

However, there is something else there. A COM interface access. So asking the users about a legitimate system applications is not really a protection. MSIEXEC is DOING what it is supposed to do. COM interface access must be intercepted before the trojan controls msiexec service. So when we have time, we will analyze it and see what is going on.

I removed all default rules/ policy for msiexec.exe and unfoirtunately no alerts for a driver install/ load. CFP does not at all behaves like other HIPS here.

See my thread here for some more explanation.


As I said, it is not the ideal way. msiexec.exe is trying to load a driver. So what? It is a legitimate application and it does this for a lot of applications. what is the application behind this? Wihtout catching these details, showing the users about services.exe or msiexec.exe is not the solution.

Services.exe is trying to load a driver: so what? It is what services.exe is supposed to do… We will see what sort of COM access is happening there and why CFP is not catching it.

Thank you egemen… (B)

I undersatnd that but it,s common for legit applicatiosn to be exploited very often by malware. U catch the COM access that is good but IMO no harm in detecting a driver install by msiexec.exe.

As far as a driver install by msiexec.exe being a legit operation-- this should be valid only if u use default CFP policy for msiexec.ex but if u use a custom policy, u must get a pop up about driver install by it.

Otherwise I am afraid if we extend ur theory to other OS applications then we should not get any alert for execution of any application by explorer.exe. Afterall it,s a legit operation of explorer.exe to execute any appliaction.

this is true. however, finding the application behind the loading of the driver and being alerted when services.exe or msiexec.exe are trying to load a driver are not mutually exclusive. ideally, comodo can find the application when it attempts to invoke msiexec.exe and also alert the user when the driver is actually loaded by these known system applications.

still, i like your philosophy of finding out the application that is behind the loading, egeman. :slight_smile: this brings up a question: when comodo detects that an installer or program is trying to invoke a system application like msiexec.exe or services.exe that typically loads drivers, is the ONLY possible alert type COM access? i ask because i’m trying to uncheck as many of those boxes as possible to reduce the number of popups. would having COM access and device driver loading options checked be enough to stop rootkits?

Please do not post in topics which are outdated August 2008

Topic Locked