One night I was curious about how the Group Policy Manager sets the policies using registry keys. The GUI displays detailed descriptions but not the backend registry key the target policy uses.
Of course, if you Google a policy you can end up finding the target registry value or have a look at the “C:\windows\policydefinitions” folder for the admx files. But I wanted to see for myself how this works behind the scenes. So, I used the API Monitor to monitor the APIs and check the values manually.
Let’s have a look at the policy where we can disable the right click.
The process is “mmc.exe”, the Microsoft Management Console. The Local Group Policy Editor – “gpedit.msc” is just one snap-in of it.
If you monitor the registry APIs of the “Kernelbase.dll” you can see the APIs being called in the registry.
The first API which is used is “RegCreateKeyW” which internally calls the “NtCreateKey” API. It seems like the API checking for the following path:
This API Creates the specified registry key. If the key already exists in the registry, the function opens it.
If we check the “NtSetValueKey” API we can see the exact registry key which is “NoViewContextMenu” inside the Data parameter.
The ZwSetValueKey routine creates or replaces a registry key’s value entry.
NTSYSAPI NTSTATUS ZwSetValueKey(
The data which is written to the registry key is “1” to enable the setting.
Now if we check the registry we can check if it’s the real setting.
When you click Disable or Not Configured on the policy it will simply delete the registry key by calling the “NtDeleteValueKey” API. The “ZwDeleteValueKey” routine deletes a value entry matching a name from an open key in the registry.
NTSYSAPI NTSTATUS ZwDeleteValueKey(
The ValueName passed to the API is the registry key “NoViewContextMenu”.
The registry locations and keys of group policy settings might come handy while pentesting to change settings of the computer.