Hmm, I see HKCU and HKSU being added to the “Configuration Changes” logs when I add those two different keys to “Protected Objects → REGISTRY KEYS” for example, seems to work here.
Not sure which box you are referring at when this happens at your end.
No, HKU is the correct acronym for HKEY_USERS on Windows 10, meanwhile CIS uses HKUS in alerts, rules, settings, and in the logs on Windows 7 for some reason. Anyways HKCU is a link to HKU<your user security identifier> so any change made to the current_user key hive will be reflected into HKEY_USERS within the subkey corresponding to the currently logged on user SID.
Now for the bug, what do you have added under protected registry key specific for HKEY_CURRENT_USER? Did you add it as HKCU*, HKCU*, or is it the result of a default protected key that generated alerts or made it possible to use a rule?
By saying not correct I was referring to the fact that it was not the standard for what was being used when adding rules. The correct thing to do would be for CIS to use the same acronyms for when both providing an option for adding a rule and logging HIPS events. As for HKU being referred to as HKCU, see below.
The syntax of HKU in my CIS logs is what you would expect from HKCU. This is because it does not have the SID in the string.
See attached screenshot 1 below.
Using either HKUS or HKCU, or both, as ‘Protected registry key’ exceptions does not work in my test. There was still a HIPS log for the Modify key attempt.
Using HKU was the only string that worked. There was no HIPS log when using this string.
See attached screenshot 2 below.
HKU is not an option when creating rules. You need to manually add it.
So in this example the blocking HKU rule appears to be instead formatted as HKCU in HIPS Logs, ignores both HKUS and HKCU exception rules anyway, and only accepts HKU exceptions which is not an option when adding rules in the first place.
Having created the following key and string value for test purpose using regedit
[HKEY_CURRENT_USER\Test]
“Hello”=“World”
Added “HKCU\Test*” (which refers to [HKEY_CURRENT_USER\Test]) to “Protected Objects → REGISTRY KEYS”
For regedit.exe added “HKCU\Test*” to HIPS rule “ACCESS RIGHTS → Protected regsitry keys → BLOCKED REGISTRY KEYS”
Using regedit tried to change the string value “World” into something else which got blocked as intended.
Checked the logs “HIPS Events” for regedit, showing:
Date & Time Application Action Target
2021-06-03 09:20:20 C:\Windows\regedit.exe Modify Key HKUS\S-a-b-cc-ddddddddd-eeeeeeeeee-ffffffffff-gggg\Test\Hello
So, yes, the initial referred to key HKCU\Test* ([HKEY_CURRENT_USER\Test]) changes to HKUS.… in the logs (that is on Windows 7).
EDIT:
When settiing “Action” to “Ask” for regedit.exe HIPS rule without having the key added to “BLOCKED REGISTRY KEYS” then changing the key string “World” in something else results in “HKUS*\Test*” being added by CIS to the “ALLOWED REGISTRY KEYS” for regedit.exe HIPS rule.
As futuretech mentions, on Windows 7 HKSU appears everywhere…
P.S.
I have to note here that while doing the above steps I got a CIS Application Error (see attached image).
I got this error now for the second time, the first time when I was playing around doing the same kind of things as described in another thread.
Now it happened a second time while doing the above steps so I thought to report the error here.
I have a feeling that the developer(s) at least for Windows 10 meant to use HKU as HKUS but by mistake made it work as HKCU.
It then had this chain reaction.
Link | HKU used instead of HKUS (replaces HKUS)
Function | HKU works as HKCU (Replaces HKCU)
Result | Both HKUS and HKCU are nullified in favour of HKU, who’s function is HKCU instead of HKUS.
Therefore breaking HKUS and HKCU in some scanarios and using the wrong string in the HIPS Logs.
For example, maybe CIS thinks when using HKU as a blocking rule that the exception rule HKUS/1-1/test is actually HKCU/1-1/test (which does not exist as what it is actually looking for is HKUS/1-1/1-1/test
(Note the additional SID which could be caused by using HKUS string for a HKCU query.)
Or maybe the logs cutout the SID, and HKCU along with HKUS just get ignored when used as exceptions if HKU is used as the blocking rule.