search

Mantis

hashtag
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  unknown

For this particular machine, Port 8080 and 1433 are both public facing. Also, there's an unknown port 1337 (likely HTTP).

hashtag
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.

hashtag
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.

hashtag
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.

hashtag
Privilege Escalation

hashtag
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...

hashtag
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.

LogoPage not found - HackTricksbook.hacktricks.xyzchevron-right

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:

Kerberos Vulnerability in MS14-068 (KB3011780) ExplainedActive Directory & Azure AD/Entra ID Securitychevron-right

Also, while researching for exploitation methods, I found that the Impacket suite of tools included one specifically for this:

Logoakb/Impacket/MS14-068.md at master · mubix/akbGitHubchevron-right

We can then run impacket-goldenPac to get a SYSTEM shell.

Rooted!

hashtag
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.

PreviousKotarakNextMonitors

Last updated