This time we can skip getting a foothold and dive right into PrivEsc.
So I connect via xfreerdp:
We could use several enumeration scripts here but let’s go with the manual approach this time. Let’s begin by getting a general overview of the box and check some quick wins.
I strongly recommend doing the Windows PrivEsc room before you start this room. It gives you a nice overview of different approaches. Personally took a lot of notes while doing this room so I have a checklist that I can rely on. Everytime I see a new way to escalate privileges I add it to my notes.
Starting off with systeminfo:
Check users:
Check whoami /priv. This can reveal some very easy ways to escalate, but we’re unlucky this time:
Looking for some non-default files or folders I found:
A Service.exe 2 folders deep, both folders containing empty spaces. This screams unquoted service path. Let’s check for it.
Get some more information about the service:
This path is definetly unquoted. The Start Type is AUTO_START tho, so we have to look at this again. Let’s see if we have write access somewhere.
I decided to use an alternative to accesschk, I use :
We can place files in Development Files. So let’s recap what we know so far:
We have a service called “Development Service” which starts a Service.exe located in:
C:\Program Files\ Development Files\Devservice Files\
Wo what exactly happens with the service? Upon boot (because of Start Type: AUTO_START) this service searches for the exe in this order:
- C:\Program.exe
- C:\Program Files\Development.exe
- C:\Program Files\Development Files\Devservice.exe
- C:\Program Files\Development Files\Devservice Files\Service.exe
So if we place a fittingly named .exe within the first 3 steps, this .exe will be used upon start and execute with system privileges. We have write access to Development Files. So we can do it like in step 3 and place a file called Devservice.exe in Development Files. Since we have no rights to modify the service config, we have to restart the box to restart the service. Sounds like a plan, let’s execute it:
Generate a payload.
Host the files on kali:
Start powershell on our victim and use:
Don’t forget the listener:
Now restart the box back in the command prompt:
/r makes the box restart instead of shutting down.
/t 0 executes this command without delay.
After waiting for a bit the shell pops but dies almost instantly, let’s try with another payload. Stageless this time.
This worked like a charm!
Lesson learned:
Found another way to look for writable paths without accesschk.
