Windows: Abusing weak permissions
Permissive File System ACLs
Running SharpUp
We can use SharpUp from the GhostPack suite of tools to check for service binaries suffering from weak ACLs.
In the example, the tool identifies the PC Security Management Service
, which executes the SecurityService.exe
binary when started.
Checking Permissions with icacls
Using icacls we can verify the vulnerability and see that the EVERYONE and BUILTIN\Users groups have been granted full permissions to the directory, and therefore any unprivileged system user can manipulate the directory and its contents.
Output:
Replacing Service Binary
This service is also startable by unprivileged users.
We will:
- make a backup of the original binary
- Create a malicious binary with msfvenom
- Download it in the target host and replace the original
- Set a listener
- Establish the connection
We can make a backup of the original binary:
Create a malicious binary generated with msfvenom
in out attacking machine:
Serve the malicious file:
Download it from the target host to the needed location:
Set a listener:
Launch the service and get a reverse shell:
Permission with AccessChk
Running SharpUp
We can use SharpUp from the GhostPack suite of tools to check for service binaries suffering from weak ACLs.
In the example, the tool identifies the WindscribeService
, which is running the C:\Program Files (x86)\Windscribe\WindscribeService.exe
binary.
Checking Permissions with AccessChk
Next, we'll use 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).
Output:
Here we can see that all Authenticated Users have SERVICE_ALL_ACCESS rights over the service, which means full read/write control over it.
Changing the Service Binary Path
Checking the local administrators group confirms that our user htb-student is not a member.
Let's change it to add our user to the local administrator group. We could set the binary path to run any command or executable of our choosing (such as a reverse shell binary).
Restarting the Service
Next, we must stop the service, so the new binpath command will run the next time it is started.
Now we can confirm that our user htb-student is a member of the Administrator group:
Cleanup: Reverting the Binary Path
Starting the Service Again:
Verifying Service is Running:
Windows Update Orchestrator Service (UsoSVC)
Another notable example is the Windows Update Orchestrator Service (UsoSvc), which is responsible for downloading and installing operating system updates. It is considered an essential Windows service and cannot be removed. Since it is responsible for making changes to the operating system through the installation of security and feature updates, it runs as the all-powerful NT AUTHORITY\SYSTEM
account.
Before installing the security patch relating to CVE-2019-1322, it was possible to elevate privileges from a service account to SYSTEM
. This was due to weak permissions, which allowed service accounts to modify the service binary path and start/stop the service.
Unquoted Service Path
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.
Querying the service SystemExplorerHelpService
:
Output:
If we note the Binary Path:
Windows will decide the execution method of a program based on its file extension, so it's not necessary to specify it. 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
Although it's not uncommon to find applications with unquoted service paths, it isn't often exploitable because we need permissions to write to those folders, or permissions to restart the service.
Searching for Unquoted Service Paths
In a cmd session:
If we find any, we could include a malicious file created with msfvenom that is named after the binary.
Permissive Registry ACLs
It is also worth searching for weak service ACLs in the Windows Registry. We can do this using accesschk
. Checking for Weak Service ACLs in Registry:
Part | Meaning |
---|---|
accesschk.exe |
Sysinternals tool to view security permissions (on files, registry keys, services, etc.) |
/accepteula |
Silently accepts the license agreement (avoids GUI popup) |
"mrb3n" |
The user account whose permissions you want to check |
-k |
Tells AccessChk to target registry keys |
-v |
Show verbose output (includes more details) |
-u |
Show permissions that apply to the specified user (i.e., mrb3n ) |
-q |
Quiet — suppresses errors like “access denied” |
-s |
Recurse subkeys (goes deep into nested keys) |
-w |
Show only keys that are writable by the user |
hklm\System\CurrentControlSet\services |
The registry path being checked — where Windows service configurations live |
Basically, this command will recursively scan all subkeys under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services
. For each key, it checks if the user mrb3n
has write permissions.
If mrb3n
has write access to a service registry key, you can often:
- Hijack the service (change
ImagePath
,binPath
, etc.) - Get privilege escalation, especially if the service runs as SYSTEM
- Combine with service restart or reboot to trigger code execution
Above, find the change the binary path. Also let's understand the difference:
binPath vs. ImagePath
Term | Where it's used | Meaning |
---|---|---|
ImagePath |
Registry value under HKLM\SYSTEM\CurrentControlSet\Services\YourService |
Path to the executable that gets run when the service starts |
binPath or binPath= |
Used in command-line tools like sc.exe |
Argument that sets or shows the ImagePath for a service |
ImagePath
is the actual registry value namebinPath=
is just how it's referred to in commands
Changing ImagePath with PowerShell
The ImagePath
is a registry value under each service’s key that tells Windows what binary or command to execute when starting the service.
We can abuse this using the PowerShell cmdlet Set-ItemProperty
to change the ImagePath
value, using a command such as:
Modifiable Registry Autorun Binary
Check Startup Programs
We can use WMIC to see what programs run at system startup.
Suppose we have write permissions to the registry for a given binary or can overwrite a binary listed. In that case, we may be able to escalate privileges to another user the next time that the user logs in.
This post and this site detail many potential autorun locations on Windows systems.
Last update: 2025-04-13 Created: April 13, 2025 08:35:24