There were some number of threads discussing this subject, but none of them received an attention of staff. Will try to put this subject as simple as possible.
Pls compare two examples of behaviour of Defense+ with exactly same configuration, only thing which differs is a Defense+ mode (pictures are visible only to logged in forum users).
Example #1 (Defense+ in Safe mode).
App called SecurAble found here is launched and its its execution allowed.
Alerts of Defense+ followed:
Example #2 (Defense+ in Paranoid mode).
…
Alerts of Defense+ followed:
Mind alert of D+ in Paranoid mode “services.exe tries to load a driver”. That alert must present in Safe mode of D+, too.
Currently Defense+ in Safe mode considers services.exe as safe/trusted/whitelisted and silently allows any “driver installations” despite these are set to “ask”.
This is not right. Because through services.exe may be loaded any (malicious) driver of any (malicious) executable which is programmed to use NtLoadDriver through the services controller. And that alert should be red, like in the cases when executable tries to load a driver calling NtLoadDriver directly (e.g. ProcessExplorer). [Used information from this message to write this paragraph].
Maybe most clear would be red alert which would show which executable tries to call services.exe with aim to load a driver?
Defense+ configuration related to this test: “[at]Gibson Research center” is not in the list of trusted vendors; securable.exe and securable.sys are not in the list of trusted files; securable.exe is not in the Computer security policy; services.exe under Computer security policy has everything set to “allow”, except for “run executable”, “Driver installations”, “registry modification” which are set to “ask” without exceptions; Sandbox permanently disabled.
Unrecognized (not trusted) executable is not considered safe (red alerts), but .sys file it places in \system32\ folder is considered safe (trusted)? How is that >:-D
System32 is a protected folder. In the case you are presenting if you allowed to write the .sys file to the system32 folder then that should not have been allowed in the first place.
I don’t know how the NtLoadDriver call works. Can it only start .sys files that are in system32 or can it also start .sys files in other folders?
Neither path nor file extension of the driver file matters.
Topic:
IMO it’s just a minor issue since it’s clear that the app is trying to install a driver or service due to the regsitry warning. If it’s blocked nothing gets installed.
CIS can’t block and/or filter already registered drivers. hence CIS can’t cure system after been installed on unknown-state system. And it doesn’t matter whether drivers signed or not (XP) if they registered - they will be loaded w/o any problems and HIPS notifications.
Yes, but. For applications calling NtLoadDriver directly Defense+ presents three alerts: registry modification to register driver, creating .sys file AND attempt to load a driver… despite writing of .sys file to the system32 folder “should not have been allowed in the first place”.
…And for applications calling NtLoadDriver thru services controller, third alert is present only in paranoid mode and moreover it is obscure (bcause does not tell what executable called sevices.exe to load a driver) and misleading (because it tells “services.exe is safe”, “you can safely allow this request” and tells nothing about .sys file: whether it is recognised or not).
drivers not necessary to be nearby sys32 and not necessary be loaded thru NtLoadDriver.
CIS’ safe mode handle only \Services\ branch access not the process driver’s loaded thru any of ways different to control manager like “services.exe tries to load driver”.
So what cis has against rootkits or not-so-clean machine? nothing
D+ cannot help you once a driver was allowed to be installed. You would need signature based scanners to do detecting and cleaning. The sandbox will catch malware on an already infected machine; I don’t know to what extend though.
Sandbox has nothing to do with HIPS. HIPS has to protect in any way. Drivers even when registered have to loaded some time. If CIS HIPS can’t prevent some unsigned driver from autoloading, it surely must have some protection from manual loading the drivers over several different ways. then i don’t know why CIS needs drivers and hooks if drivers gets loaded w/o troubles and checks.
People who think applications can install drivers with HIPS at proactive config and sandbox off maybe should show up with a proper malware sample which demonstrates this.
This thread is really just hot air about a cosmetic thing.
But if you only block what has been found in real malware and not proof of concepts then it is like signature based defence and not default deny. When the unknown arrives you are caught out.
If the registry access is blocked the driver shouldn’t become active. I could demonstrate you dozens of examples with malware which show this.
Do you have any proof that the opposite is the case?
