The HKCU Registry Bridge On the River PowerShell.

This blog will show you the options you have when you need to deploy Hkey_Current_User (HKCU) Registry changes when you are blocking PowerShell!

1. Introduction

When you block PowerShell in the user context with Applocker, deploying HKCU registry changes or policies could be difficult! Why? because running a PowerShell script or a Proactive Remediation as the logged-in user will be blocked!

As shown below, you will notice the error 0x8004005 in your agentexecutor.log mentioning that the program is blocked by group policy.

So, how are we going to solve this issue? Sometimes, you really want to push a simple HKEY_Current_User (HKCU) setting that isn’t available in the Intune Settings Catalog or Administrative templates.

As an example: When you are using OneDrive, and you configured the settings to Automount team sites, and you want to speed things up a little bit

https://call4cloud.nl/2020/07/once-upon-a-time-in-the-automount-of-onedrive-team-sites

Normally, that is not a problem when you are NOT blocking PowerShell.The only thing you need to do is to configure the “Run this script using the logged-on credentials” option to “yes”

But in my opinion.. not blocking PowerShell for the non-admins is a no-go. It’s just my opinion but if you want to read more about this…

If you have read the blog above you will know why I prefer to block PowerShell. It’s because malware/cryptoware/privilege escalation uses most of the time Powershell. And a normal user.. does not need access to PowerShell (except for loading user scripts.…)

So how can you make sure a user always gets the registry keys necessary? We also need to beware of the fact, the TimerAutoMount key will be reset, when OneDrive has successfully mounted the Sharepoint sites. So we need to have a solution that changes this key for each logon or each hour

I will show you the options we have got:

2. Using Reg.exe

I know deploying a PowerShell script in Intune is very simple to do… this is a little bit different. This is the PowerShell script that needs to be run in the system context instead of the user context, which you normally do when you want to deploy an HKCU key.

PowerShell Script:

$content = @'
 Windows Registry Editor Version 5.00
 [HKEY_CURRENT_USER\Software\Microsoft\OneDrive]
 "Test"=dword:00000001
 '@

$path = $(Join-Path $env:ProgramData CustomScripts)
 if (!(Test-Path $path))
 {
 New-Item -Path $path -ItemType Directory -Force -Confirm:$false
 }
 Out-File -FilePath $(Join-Path $env:ProgramData CustomScripts\onedrive.reg) -Encoding unicode -Force -InputObject $content -Confirm:$false

$WshShell = New-Object -comObject WScript.Shell
 $Shortcut = $WshShell.CreateShortcut("$env:ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp\config.lnk")
 $Shortcut.TargetPath = '"c:\windows\System32\reg.exe"'
 $Shortcut.Arguments = "import c:\programdata\CustomScripts\onedrive.reg"
 $Shortcut.WorkingDirectory = '"c:\programdata\CustomScripts\"'
 $Shortcut.Save()

As shown above, you can see I just make use of reg.exe to import the .reg file and create a shortcut to all user’s startup folders to make sure this reg file is imported on startup.

You can also create an intune-win installer to ensure this is done when the device is deployed to Azure AD for the first time.

Please note: You can’t change/add/remove a registry key in the HKEY_CURRENT_USER\Software\Policies path. It will not work, because it would be very weird if you could change the policies that have been applied as a regular user!

3. Using Remediations

A way better option than the reg.exe option would be to use Proactive remediations. So let’s do some magic with the use of ProActive remediations. If you want to see my other ideas with ProActive Remediations…

https://call4cloud.nl/category/proactive-remediations/

But how are we going to make sure we can read the TimerAutoMount key in the HKEY_Current_User registry section when running the remediations in a system context?

Because when we don’t know which user to look for… how are we going to change that setting? Here is how!

Detection Script:

New-PSDrive HKU Registry HKEY_USERS | out-null
$user = get-wmiobject -Class Win32_Computersystem | select Username;
$sid = (New-Object System.Security.Principal.NTAccount($user.UserName)).Translate([System.Security.Principal.SecurityIdentifier]).value;
$key = "HKU:\$sid\Software\Microsoft\OneDrive\Accounts\Business1"
$val = (Get-Item "HKU:\$sid\Software\Microsoft\OneDrive\Accounts\Business1");
$Timer = $val.GetValue("TimerAutoMount");

##################################
#Launch Timer Detection         #
##################################

if($Timer -ne 1)
{
    Write-Host "TimerAutoMount Needs to be changed!"
    Exit 1
}
else
{
    Write-Host "TimerAutoMount doesn't need to be changed"
    Exit 0
}

Remediation Script

New-PSDrive HKU Registry HKEY_USERS | out-null
$user = get-wmiobject -Class Win32_Computersystem | select Username;
$sid = (New-Object System.Security.Principal.NTAccount($user.UserName)).Translate([System.Security.Principal.SecurityIdentifier]).value;
$key = "HKU:\$sid\Software\Microsoft\OneDrive\Accounts\Business1"
$val = (Get-Item "HKU:\$sid\Software\Microsoft\OneDrive\Accounts\Business1") | out-null
$reg = Get-Itemproperty -Path $key -Name TimerAutoMount -erroraction 'silentlycontinue'

##################################
#Launch timer  detection       #
##################################

if(-not($reg))
	{
		Write-Host "Registry key didn't exist, creating it now"
                New-Itemproperty -path $Key -name "TimerAutoMount" -value "1"  -PropertyType "qword" | out-null
		exit 1
	} 
else
	{
 		Write-Host "Registry key changed to 1"
		Set-ItemProperty  -path $key -name "TimerAutomount" -value "1" | out-null
		Exit 0  
	}
 

Go open the ProActive Remediations and take a look at the outcome!

And yes, of course, it has been remediated!

Isn’t this cool? With this solution, you could change the user registry key each hour (when it’s not configured to 1).

Do you know what else is great? When you don’t want a policy to be targeted at the device (HKLM:\software\policies) maybe you could even change HKCU:\software\policies settings with this idea.

4. PowerShell Script

Another option to get the current logged-in Azure Ad user would be to query the User who is running Explorer.exe and convert that username to the well-known SID to change the registry values! To be sure I am getting the only correct username I am using a word boundary -match “\b$CurrentUser\b” to perform a search for “whole words only”

$currentUser = (Get-Process -IncludeUserName -Name explorer | Select-Object -First 1 | Select-Object -ExpandProperty UserName).Split("\")[1] 

$Data = $currentUser
$Keys = GCI "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\" -Recurse
Foreach($Key in $Keys){
    IF(($key.GetValueNames() | %{$key.GetValue($_)}) -match "\b$CurrentUser\b" ){$sid = $key}
}

$sid = $sid.pschildname

New-PSDrive HKU Registry HKEY_USERS | out-null
$key = "HKU:\$sid\Software\Microsoft\OneDrive\Accounts\Business1"
set-Itemproperty -path $Key -name "TimerAutoMount" -value "1" | out-null

If you don’t want to rely on who has the process explorer.exe opened or having multiple SIDs in the OUTPUT we could also call upon the registry to directly fetch the LastLoggedOnUserSID

$sid = (Get-ItemProperty -Path hklm:\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\LogonUI -Name LastLoggedOnUserSID).LastLoggedOnUserSID

New-PSDrive HKU Registry HKEY_USERS | out-null
$key = "HKU:\$sid\Software\Microsoft\OneDrive\Accounts\Business1"
set-Itemproperty -path $Key -name "TimerAutoMount" -value "1" | out-null

Conclusion:

Blocking Powershell is very important but it can put you in a difficult situation when you need to change some HKCU settings… Because it could be hard to apply the settings to the logged-in user and not to the system account!

Deploy one of these ideas and watch it pour down to the devices! Of course, you will know I prefer the proactive remediations—they are great!