Broken Registry Key Class Acronym for HKEY_CURRENT_USER

1: CIS version:

2: OS version:

Windows 10

3: What you did:

Add registry key to HIPS rule using the ‘Select Registry Keys’ dialogue box.

4: What you actually saw:

Added a HKCU rule. Rule ignored as CIS actually uses the acronym HKU as shown in the [HIPS] logs.

5: What you expected to happen or see:

CIS needs to either use HKCU or HKU for both adding rules and using rules. Otherwise HKCU rules do not seem to work (at least not all of the time).

Edit: Steps to Reproduce Issue

  1. Create a HIPS rule of an .exe that ‘blocks’ access to protected registry keys
  2. Run .exe to modify a protected HKEY_CURRENT_USER key
  3. Check HIPS logs which should refer to the protected key being blocked as a HKU key instead of HKCU
  4. Add a HIPS exception for that key using HKCU
  5. Run .exe again to verify HIPS Logs continues to show the application is attempting to modify a HKU rule.

Can you point to the exact dialogue box?
I’ve opened some registry dialogue boxes but I see HKCU when selecting and adding the key or a subkey.

Note: HKCU (HKEY_CURRENT_USER) and HKU (HKEY_USERS) are two different keys (see main reg tree in regedit).

HKCU (HKEY_CURRENT_USER) and HKU (HKEY_USERS) are two different keys (see main reg tree in regedit).


HKU is not correct.

HKCU is what the ‘Select Registry Key’ box adds.

HKU is what is displayed in logs.

Using HKCU as a rule does not appear to work.

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.

In the ‘HIPS’ logs (not the ‘Configuration Changes’ logs), HKEY_CURRENT_USER is referred to as HKU.

Sorry my bad, I’m talking about a different thing.

Added [HIPS] before ‘logs’ plus steps to reproduce in the original post to clarify.


I’ll try to reproduce the issue by following your steps at a later moment…

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?

No need to try to reproduce it on my Windows 7 then…

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.

  1. 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.

  1. 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.

  2. Using HKU was the only string that worked. There was no HIPS log when using this string.

See attached screenshot 2 below.

  1. 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.

Ok, I’ve just did some steps . . .

Here’s my observations . . .

  • Having created the following key and string value for test purpose using regedit
  • 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).

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…

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.

Yeah I see the inconsistent behavior which is completely different on Windows 7.

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.

Just a guess.

Hi ReeceN,

Thank you for reporting, we are checking this.