Mantis
https://app.hackthebox.com/machines/98
Last updated
https://app.hackthebox.com/machines/98
Last updated
Password: PentestEverything
Add "10.10.10.52 htb.local" to /etc/hosts.
Starting out we hit SMB
with the smb-os-discovery
nmap
script to pull some further information. Revealing the FQDN of the target system is mantis.htb.local.
Add "10.10.10.52 mantis.htb.local" to /etc/hosts.
Running checks over Kerberos
with kerbrute
showed a few discovered users.
I tried checking for accounts with no "pre-authentication enabled" with GetNPusers.py
against the Domain controller. Unfortunately none of these worked.
I also tried some common password lists against SMB
and LDAP
. Again, nothing..
Moving over to port 1337 with HTTP running we land on the root page for IIS7
.
Some common directory enumeration with Feroxbuster
shows few results.
With the /orchard
directory reporting a 500 Internal Server Error code.
Over on port 8080 we also have a web server running. Under the heading "Tossed Salad". At the foot of the page we see, it is powered by OrchardCRM.
Orchard: http://www.orchardproject.net/
Looking through searchsploit
we see a few vulnerabilities regarding this CRM.
I was unable to identify the version of Orchard that is running. I tried the exploits listed above and was unable to reproduce anything promising.
Back onto further enumeration we take a deeper dive into port 1337. This time, running a larger wordlist.
Where we pick up the directory /secure_notes
.
The web.config file is inaccessible. However, the dev_notes
file is readable.
From this we obtain information regarding the SQL
user "admin". Regarding the file name for the dev_notes
, we can assume by looking at the long string that this may be encoded or encrypted.
Using base64 to decode the string we get the following:
Running this through the magic option on CyberChef
We see the resulting plaintext.
We can then use these credentials along with the aforementioned admin account to login to MSSQL
using mssqlclient.py.
After confirming the credentials work, I then decided to download Sqlectron in order to connect to the database with a GUI for easy navigation.
Sqlectron: https://github.com/sqlectron/sqlectron-gui/releases/tag/v1.37.1
After connecting we find the table blog_Orchard_Users_UserPartRecord
contains plaintext password information for the use james.
Credentials:
After gaining these credentials I found I was unable to use them anywhere meaningful which could get me code execution on the target system.
The user is part of the "Remote Desktop Users" group, however, no RDP ports are open. We have no WinRM and not enough privileges to gain code execution through the use of psexec,wmiexec and so forth...
At this point I ran extra vulernability scans against the target with Nmpa and Nessus and still, nothing...
I have to admit that I was utterly stuck and ended up looking at other walkthroughs. Supposedly the target system is vulnerable to MS14-068. it looks, however that other walkthroughs do not have any conclusions on how they arrive at that fact the target system is vulnerable to MS14-068.
This article suggests some form of detection to MS14-068.
Trustedsec.com: https://www.trustedsec.com/blog/ms14-068-full-compromise-step-step/
The article suggests already having knowledge the target is vulnerable to MS14-068. However, it does give a small snippet for decting if the exploit may be vulnerable with Responders's FindSMB2UPTime.py script.
I was unable replicate the same results for detection. Likely due to target system being rebooted multiple times a day.
Through the various methods availabe to exploiting PAC Impacket's goldenPac.py appears to be the most simplist away to acheive the desired results.
First, we need to ensure our system clock is inline with the target system. Kerberos does not allow for more than five minutes clock skew.
We can now run goldenPac.py with the user James to acheive privilege escalation.