Defense+ fails to stop driver loading

i installed comodo internet security on windows xp to defend against rootkits, but comodo has failed to alert me about the loading of drivers. here is one situation in which comodo fails: VCD Download

that link leads to a virtual cd burner application. this application installs the following 4 drivers:


to see this for yourself, simply install the trial at that link. comodo detects only VC9SecS.sys. does anybody know why this is? if comodo fails to stop the loading of drivers, it could potentially allow rootkits to be installed.

Is your CIS set in default configuration? If yes, please change it to proactive security

Right click CIS icon>Configuration- Proactive Security

and try again.

where is the “proactive security” mode that you speak of? i have my defense+ set to “paranoid mode”. the only other modes i see are “safe mode”, “clean mode”, and “training mode”.

Right click the CIS system tray icon (down near the clock). Select CONFIGURATION → COMODO - PROACTIVE SECURITY.

Looking at mine its set to proactive security (updated updated) beside it but at the bottom of list there is proactive option again?

Same as mine it means you have updated the program twice.

The procative option at the bottom is the same as if you did a fresh install, it has all the default settings of the latest version you have.


i see. in this case, my tests were done with proactive security on. in fact, proactive security has been on since comodo was installed. i never turned it off. what other explanations could there be?

by the way, if you have a few minutes and if you haven’t done so already, please try the installer and let me know what you think.

Did you install the program step by step and didn’t use Installer policy when installing?

I did the manual installation and I caught 3 out of the 4 mentioned until it crashed:
VDRV9000.SYS this one was not flagged.

The VDRV9000.SYS did not show up under \system32\ or system32\drivers\ on my system. I installed in Vista SP1 comp mode on Win 7 RC.

I guess you owe a more in depth description of how you installed. I think you allowed the installation of the drivers. CIS will catch the installation of drivers and stuff in the act. Not after the act.

yes, i did do the installation step by step. i never use installer mode because it takes away control from me.

after a few more tests, it seems that i have indeed caught the installation of more drivers, though not under the “device driver installation” filter. instead, i caught the following as registry modifications:


my question then, is tihs: if i block a driver from modifying the registry HKLM\System\ControlSet???*, have i blocked the installation of the driver itself? or is there still something else i’m missing?

also, can you please list the manner in which you were able to detect those 3 drivers? was it modification of a protected file directory? modification of a protected registry entry? or was it the blocking of a device driver?

Drivers get installed either as flagged by the Device driver installation alert or by a an alert about service to install. That’s how you catch them.

I don’t exactly recall the alerts as this is not something I do on a daily basis and clicking at least 100 times is mind numbing to say the least…:wink:

mind numbing indeed :). anyways, the device driver installation alert definitely did not go off for all 4 files. by the way, i’m not sure what you mean by “service about to install”. is service installation a type of alert distinct from device driver installation? if so, i have never seen it. the failure i was referring to was the failure to detect those 4 files under a “device driver” type alert. the difference between alert types is critical in a security configuration.

however, the ones i listed in my most recent post before this one were caught with the registry protection rules. since you do not remember exactly what alerts popped up and i went step by step, it is likely that the names of those files showed up as registry protection alerts (or, if you so specified, the execution of .sys files - but, executing .sys files is not the same as loading them as drivers). i see protecting the registry to prevent driver loading as a weakness. there is a huge difference.

You blocked the start up reference of the service. So, if there is nothing that tells Windows to start the service and subsequently the driver.

Seems driver alert issues are still there with CFP. I will test this myself as well.

Comodo needs to modify their drivers/ services related pop up alerts to more easier and clear format, just like other HIPS.

To rephrase you some. You are not disputing the capabilities of D+ to intercept all driver installs? It is only clumsily notified to the users?

I can’t speak for aigle, but I do dispute the capabilities of D+ to intercept all driver installs. It is not so simple as clumsy notification. I stated here in this thread the difference between intercepting driver installs and simply protecting the registry:

In that thread, I also gave specific examples of how registry protection is incomplete. Virtual CD 9 in this thread is a specific example of how the device driver filter fails to properly notify users. You disputed this in a recent post prior to its editing. You stated specifically that you remembered clearly the device driver filter catching everything. This is incorrect. You can verify this yourself without answering hundreds of popups! Simply uncheck all checkboxes under “Monitor Settings” except for “Device Driver Installations”. If Defense+ correctly alerts you about those 4 drivers I listed in my first post with these settings, then I am wrong. So don’t take my word for it. Do the Virtual CD 9 installation for yourself with only that one box checked, and you will see it yourself.

I tried the installation with only monitoring Device Driver Installations. It didn’t show up as you predicted.

That doesn’t convince me Comodo is bypassed as your TS seems to suggest when you say “but comodo has failed to alert me about the loading of drivers” . The drivers that get installed don’t get the Device Driver Installation alert, you seem to expect, but you need to filter that from the alerts for the Protected Registry alerts regarding services as well as the fact that *.sys files get installed in system\drivers. I can see there may be a usability issue here; and I don’t mean that lightly or derogatory.

In the following thread, the link to which I have already posted here ( ), I explained why the registry protection Defense+ provides by default currently does not cover all driver installs. I gave specific examples of lines in the registry which could be written to in the event of a driver installation. Even blocking access to all registry keys cannot prevent all driver installations, let alone the 2 lines I gave as examples. Moreover, some methods of loading drivers require writing to the \windows\system32\drivers folder that you mentioned; others do not. Is it really worth increasing the number of alerts so much with 2 additional filters when neither of them alone can stop all driver installations? By the way, I don’t think you meant to use “usability issue” in a derogatory manner. I think all you meant to say is that Defense+ might be more difficult to use. No worries :slight_smile:

I’m still curious as to what you meant by “service about to install”. I have never seen this type of alert. I have seen a Device Driver installation alert, however. Is there perhaps a setting I’ve missed?

I played with this installer, CFP, EQS and OA. I will make a new thread hopefully tomorrow evening. ATm I will just say that CFP alert pop ups are not user friendly at all. IMO EQS gave best alerts then OA and lastly CFP( so many pop ups and not user friendly(.\

I will make a detailed thread to make my point. May be I can convince CFP developers to change the way they alert on driver/ serivce instal. Current alert scheme is poor, sorry to say.

In my common sense approach to malware when I am suspicious of a file I am on the look out for all signs of programs wanting to start with Windows: “regular” auto start keys, all alert about services and of course driver installation alerts. I have never studied the Winternals or similar books; it seems common sense to me… back on topic now…

In a wishlist topic you state Comodo fails registry protecting. I won’t reply thre as it is may digress the wishlist topic.

I tested your thesis about registrty keys by making the two keys, HKLM\SYSTEM\CurrentControlSet* andHKLM\SYSTEM\ControlSetXXX*, part of my protected keys and I cannot confirm your observation.

My configuration is Proactive/Paranoid and tested with Regedit; I deleted the Regedit rule in D+ before testing. I tried to make new keys in the mentioned entries and its sub entries. I see the keys and subkeys being protected. Each time I make one I would get an alert.

However there is word of caution here when testing. After I made a key in the "main"key or in a sub key like services then if I made another key in those keys D+ would not alert anymore. That is by design; it will “remember” for the session; you need to log off or reboot to make it forget.To put it plain and simple; once you made a new key in a certain (sub)key all subsequent new keys will be allowed by design.

That puts the ball back in your field. In another topic you mentioned you made changes to your configuration ( I think removed *.exe from the Image Execution Control list). May be other changes you made to your configuration play a role here.

Please import the back up Proactive config from the Comodo installation folder, give it a new name, and activate it. Now see if the same thing happens now Comodo is back to "factory defaults: .

Keep us posted in the new topic. Try making it a Proof of Concept. With a concise thesis, concise steps on how to reproduce it and your CIS settings.