Scripts can be launched whenever a user logs onto a system. Utilising this we’re able to move laterally in an environment if we can push scripts to multiple assets (for example through group policy), or we can maintain persistence through this technique.
Logon Scripts Analysis
RED TEAM: ATTACK
In this example we’ve used 1 registry key to ensure that whenever a particular user logs onto a system calc.exe is spawned.
reg add HKCU\Environment /v UserInitMprLogonScript /t REG_SZ /d C:\Windows\System32\calc.exe
BLUE TEAM: DEFEND
By monitoring this registry key within our SIEM we can detect the malicious modification and also see this being launched by userinit.exe which is a good indicator that logon scripts are being utilised to launch this program.
We can also prevent this from happening by removing write access to the Environment registry key for this user, and instead making it read only without any real adverse affects (by default Administrators can still modify this key):
$acl = Get-Acl -Path HKCU:\Environment $AccessRule = New-Object System.Security.AccessControl.RegistryAccessRule ("CYBERRAIJU-LAB1\JPMinty", "ReadKey", "Allow") $acl.SetAccessRule($AccessRule) $acl | Set-Acl -Path HKCU:\Environment
For those with access to Group Policy and have systems on a domain, we can do a couple of things:
- Create a user preference to delete this registry key if it exists, or if wanted update it with something else.
- Lockdown the access permissions on this registry key via Group Policy (Note: it may be easier to run a script under each user context to do so on first logon).
One more note to close off around Logon Scripts: