Delete REG KEY for HKEY_USERS hives (including CURRENT_USER)

[stevent]

Hi -

I have an issue where I need to delete 2 keys that may be in HKEY_CURRENT, or HKEY_USERS (including .DEFAULT). I have tried a few things without success. This would need to run as SYSTEM as it is being deployed as a custom action within an MSI. Has anyone out there encountered this issue? Thank you for any assistance.

[td]

You didn't state exactly which problems you are having but the system account uses .DEFAULT as its user key.  MSFT state's that for the local system account "The registry key HKEY_CURRENT_USER is associated with the default user, not the current user. To access another user's profile, impersonate the user, then access HKEY_CURRENT_USER."  It doesn't seem logical but the statement seems to imply that HKEY_USERS is not available as well as HKEY_CURRENT_USER for the logged on user unless the local system account impersonates another user but I am not sure about that.

Can't say that I have ever tried this to solve your specific problem but wntRunAsUser and RunWithLogon can be used to impersonate another user.  However, you might need to know at least one user's password to get those functions to work correctly.   There are ways for the system account to impersonate users without knowing the password but I am not sure if the wntRunAsUser and RunWithLogon can be used to do this.  I guess some experimentation would be in order.

Perhaps someone else has a better idea of what is going on and what any possible solution might be.

[ChuckC]

Provided that you have access to it both in the file system and on the registry key content within it, you can load any arbitrary registry hive file and access its contents.  When running as local system, this should permit a script to load the user-specific registry hive file from a user's profile folder on the system and then access the content within that would normally be accessible to the user as HKEY_CURRENT_USER when they are logged on as themselves.

[td]

I should have remembered that...  Thanks, Chuck.

[ChuckC]

You're quite welcome.

As an addendum... Even if you don't have access via the DACL [permissions] on the registry hive, all the same "escalation" attack rules apply if you have the "take ownership" privilege.  By taking ownership, you implicitly gain the ability to overwrite the DACL with permissions that you'll grant you the desired access, which then allows you to load the hive.  Once again, after the hive is loaded, then the same take ownership / overwrite permissions technique can be performed on the top registry key(s) in the hive to make them accessible.  Note, if you don't have the ability to read the permissions before modifying them, then you won't be able to restore them later on to their original state.

If you are running as Local System, this type of escalation attack isn't necessary since most hive files and the keys within them already grant Local System full control.  A compiled script can easily be run as Local System by setting it up as a native NT service and executing it that way.  Alternatively, the SysInternals tool suite has the "psexec.exe" utility that will effectively do a "Run As" that's capable of starting a process on the desktop under the Local System account.

If you are not running as Local System, then your mileage may vary somewhat, and an elevated token for an admin account will be required in some way.

[td]

Had a bad case of vapor lock on this one.  I believe with default Windows install user account creation gives the system account full control of all of the user registry hives.