Access
Source: Proving Grounds OS: Windows Community Rating: Very Hard
Enumeration & Reconnaissance
Started with autorecon again. it showed lots and lots of ports, so there's no point in listing them all.
Service Analysis
I began with HTTP (80), which was a simple page featuring a "buy ticket" function that included a file upload capability.
The fuzzers in the background also exposed the "uploads" directory, so cool, I guess we need to upload a shell.
Gaining Initial Access
I first tried uploading a PHP shell, but nothing worked. I attempted known file upload restriction bypasses, null byte, different extension names, double extensions, but none of them did the trick.
Then I tried another approach: what if I created a new extension that gets treated as PHP? This is where .htaccess comes in handy. I created a .htaccess file with the following content:
I then uploaded this file and it worked, the file got uploaded (note that it doesn’t appear in the uploads directory because it’s a hidden file).
Now that this is in place, I can upload files with the .puss extension and they will be treated as PHP files. So I uploaded my shell again, this time with the .puss extension, and it worked. Now I have a web shell. Using the web shell, I uploaded a reverse shell and ran it, now we got a reverse shell.
I checked the user I got the shell as and it was access\svc_apache. I then uploaded winPEAS and ran it to check for privilege escalation. It showed that we are in a domain, access.offsec (no surprises, I knew it was an AD machine I was preparing for), and there is another user, svc_mssql.
Lateral Movement & Privilege Escalation
I tried the FullPowers script that attempts to restore privileges of service accounts, but that didn’t work. I checked for other PE vectors using the svc_apache account but nothing obvious hit, so I turned to lateral movement targeting svc_mssql. Since it’s an Active Directory machine, I applied some techniques I had been learning over the past few weeks.
I started with kerberoasting. I uploaded rubeus.exe and ran:
This revealed the password to be trustno1.
Now we have credentials for svc_mssql. I tried using these newly acquired credentials through various methods:
Both didn’t work, the account had no access to the SMB shares, so that failed. I then tried runas:
That wouldn’t let me type the password. I then tried a new tool, Invoke-RunasCs. I uploaded the PowerShell script, ran:
Now that we are in as svc_mssql. I checked around for further privilege escalation vectors but there was no the usual impersonate privilege. I tried FullPowers but still nothing. After searching further, I discovered I could use the SeManageVolumePrivilege to escalate.
Someone had made a PoC on GitHub that granted access to the entire C: drive:
.\SeManageVolumeExploit.exe
Now that we have access over the C: drive we have multiple ways to escalate our privilege. According to the PoC, one method involved overwriting a DLL. The steps were:
Doing this, I got back a shell as SYSTEM.
Lessons Learned
File upload restrictions can sometimes be bypassed by redefining file types using .htaccess. This allowed me to execute PHP code from a non-standard extension.
In AD environments, lateral movement using kerberoasting is an effective method to pivot from one service account to another.
When standard privilege escalation tools (like FullPowers) don’t work, alternative vectors, such as abusing SeManageVolumePrivilege, can provide a path to SYSTEM.
Last updated