Why HKLM\SYSTEM\CurrentControlSet is not protected?

I read here

(it is in Italian) that a new trojan (Win32/Dalsk) creates some Registry keys

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\incs HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ipcdr HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\irpfit HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ScardClt

Out of curiosity I went to see if those keys are among those protected by default in Defense+ but I didn’t find them.

There are some … ControlSet… but not Current ControlSet
Is there any reason?

My configuration is in the signature

The syntax in Defense+ is:
Controlset???

I don’t know the meaning of the “???” switch, and to what extent it protects the HKLM\System tree.

Another occasion to ask, i remember having done so with no answer, a full “dictionnary” of CIS files, folders, and registry keys switches…

It’s interesting…Why does Comodo ignores CurrentControlSet? Can somebody explain this?

CurrentControlSet is a pointer to one of the control sets so I guess if each control set is protected then so is current.

Comodo has so called CurrentControlSet and that shows , for instance, printer drivers or so. Of what I know d+ will give an alert that sometime is trying to create new HKEY or registry keys. What important does HKEY have when a malware is deleted but that managed to create new HKEY?

Regards,
Valentin N

In the registry itself, ControlSet001, ControlSet002 and CurrentControlSet are independent sub-arborescences.

There is no reason for the ControlSet??? string to control CurrentControlSet if the ControlSet switches only refer, as i believe, to any number (e.g. 001, 002,…).

There is no reason either to write a specific group of “Important Keys” if CIS protects every registry key: it would be a nonsense.

A probable intermediate reason is that, outside of course of the fact that one can write whatever registry group of his choice, CIS might apply the contents of some group or another to a specific action.

Maybe CIS actually protects CurrentControlSet, but none of the evocated mechanisms advocate for it.

I was unable to find any access right registry rule for it in Defense+, but the said section concerns hardware, and altough my usb printer appears in this registry section, there was no corresponding permission asked by CIS.
But, true enough, my CIS 5.3 partition is mostly used for testing purposes (and thus free of most software and hardware); one of you fully working with CIS 5.X should look, if he has appropriate customized Defense+ rules, if there actually are CIS Defense+ access rights refering to CurrentControlSet.

... ControlSet001 may be the last control set you booted with, while ControlSet002 could be what is known as the last known good control set, or the control set that last successfully booted Windows NT. The CurrentControlSet subkey is really a pointer to one of the ControlSetXXX keys. ... http://support.microsoft.com/kb/100010/en-us

I just did a little test.

I put D+ to Paranoid and ran Process Hacker and created a service from it. Then you get alerted when trying to “install” the service.

And if you run it in Clean PC Mode?

My test showed CIS is protecting the services branch in the registry.

Since Process Hacker is a safe file you don’t get alerted when using Safe Mode or Clean PC Mode.