Mantis
Gaining Access
Nmap scan:
$ nmap -p- --min-rate 5000 -Pn 10.129.77.179
Starting Nmap 7.93 ( https://nmap.org ) at 2023-06-22 01:02 +08
Nmap scan report for 10.129.77.179
Host is up (0.0089s latency).
Not shown: 65508 closed tcp ports (conn-refused)
PORT STATE SERVICE
53/tcp open domain
88/tcp open kerberos-sec
135/tcp open msrpc
139/tcp open netbios-ssn
389/tcp open ldap
445/tcp open microsoft-ds
464/tcp open kpasswd5
593/tcp open http-rpc-epmap
636/tcp open ldapssl
1337/tcp open waste
1433/tcp open ms-sql-s
3268/tcp open globalcatLDAP
3269/tcp open globalcatLDAPssl
5722/tcp open msdfsr
8080/tcp open http-proxy
9389/tcp open adws
47001/tcp open winrm
49152/tcp open unknown
49153/tcp open unknown
49154/tcp open unknown
49155/tcp open unknown
49157/tcp open unknown
49158/tcp open unknown
49167/tcp open unknown
49170/tcp open unknown
49173/tcp open unknown
50255/tcp open unknownFor this particular machine, Port 8080 and 1433 are both public facing. Also, there's an unknown port 1337 (likely HTTP).
Port 8080 -> Tossed Salad
Port 8080 shows a blog page:
There wasn't much functionality within this website, so I moved on to port 1337 instead. There was a sign in, but we don't have any credentials yet.
Port 1337 IIS -> Hidden Files
This port just shows the default IIS server page:
I ran a directory scan on both of these websites, and found that the service hosted on port 1337 contained one hidden directory:
The directory contained an encrypted file:
The file contained a lot of lines which I removed:
This is just the password in binary, which can be converted online:
With this, we can login as the administrator using admin:@dm!n_P@ssW0rd! on the blog service on port 8080.
Credentials -> MSSQL Access
The dashboard can be accessed at /admin.
However, I could not find any exploitable feature of this at all. There also wasn't any public exploits related to LFI, RCE or anything I could work with. So I went back to the file found earlier.
The name of the file was a little strange, and also the credentials aren't valid when used to login to the MSSQL service:
The name of the file contained a string which looks like base64. We can decode it to find another password:
These credentials don't work with the sa user, but they do for admin:
We aren't allowed to execute xp_cmdshell in this instance:
So let's just take a look at the database itself. We can first find the databases present:
The orcharddb looks the most interesting, so let's enumerate that one. There were a lot of tables present, but the one that stood out was the Users table:
Then, we can find the columns present from this table and get both the usernames and passwords from it:
Great! Now we have this user. However, this user doesn't seem to be part of any remote management group, but his credentials are valid.
Privilege Escalation
Bloodhound -> Deadend
I initially tried to gather more information about the domain via bloodhound to see if this user had privileges over other users.
First we need to find the domain name by scanning port 389.
Add this domain to our /etc/hosts file, and then run bloodhound-python. We would also need to add mantis.htb.local after an initial collection resulted in some errors.
After uploading the data to Bloodhound, we find that the user james can RDP into the machine:
That's rather unique, but port 3389 is not open on the machine, meaning we need to do something else. There wasn't any other users on the domain as well:
I was stuck here for a while...
Kerberos Exploit
Let's think about this for a bit. We have user credentials to do something other than access the file system. We also know that the next step isn't related to any permission or ACL Abuse. It also isn't any service abuse such as Kerberoasting.
We know that this machine is running on Windows 2008 Server, which is pretty old. Maybe there's an exploit pertaining to the version of the services that were running on the machine?
Hacktricks shows that MS14-068 exists, which is a Kerberos exploit.
This exploit allows us to manipulate current logon tokens of users on the DC. In short, we can trick the machine into thinking that we are a Domain Admin. More information regarding this exploit can be found here:
Also, while researching for exploitation methods, I found that the Impacket suite of tools included one specifically for this:
We can then run impacket-goldenPac to get a SYSTEM shell.
Rooted!
Exploit Understanding
I wanted to take some time to understand why this exploit works on this machine in particular. First, let's enumerate this machine using systeminfo:
So this was running a severely outdated version of Windows Server. It should also be noted that this machine does not contain the Hotfix KB3011780 which fixes this exploit.
Kerberos has something called Privileged Attribute Certificate (PAC) which contains information about the ticket being used, which is mainly the user's current privileges, group memberships, SID History and what not. Only recently in Nov 2021 did Microsoft include the PAC_ATTRIBUTES_INFO and PAC_REQUESTOR fields.
PAC Signature Validation is the function that checks the PAC via a checksum. In an earlier version, MS11-013 allows for attackers to basically spoof the PAC to request tickets as the administrator.
The current exploit MS014-68 does include a bit more checks, but not enough. The exploit comes about because the DC fails to check for valid checksums for the PAC field, thus allowing us attackers to spoof the PAC to impersonate an administrator requesting for a TGT.
The DC validates our TGT-REQ because it sees us as the administrator, and thus returns the admin's TGT, which is a golden ticket that can be used to do anything on the domain.
Normally, getting a golden ticket (without administrator access) would involve getting the NTLM hash of the krbtgt account, which is really hard because we can't dump credentials using mimikatz or something since we don't have any privileges.
Last updated