Tentacle

Initial Enumeration

Rustscan results-

A quick google search about the open ports leads to the following information-

Port 53 - DNS(Domain Name System)
Port 88 - kerberos-sec
Port 3128 - Squid Proxy

Squid Proxy Enumeration

On curling 10.10.10.224:3128, we get

mailto:j.nakazawa@realcorp.htb

We also got a subdomain from the curl

I went ahead and added both to my /etc/hosts file.

Kerberos Enumeration

Tried brute-forcing credentials using kerbrute but couldn’t find anything.

DNS Enumeration

Since, I couldn’t find any other relevant information I started to enumerate DNS for subdomains hoping I would find something

I found 4 subdomains

All these IP’s are not yet accessible to us YET, so I thought of using a proxy

I used https://github.com/haad/proxychains which is pre-installed in Kali.

I went ahead and added 10.10.10.224:3128 to /etc/proxychains4.conf(if getting an error comment every other service out)

Ran a nmap scan on 127.0.0.1 - proxychains4 nmap 127.0.0.1 > nmap Results - Found a new port 464 kpasswd5 open which led to nothing.

Again back on the IP’s we discovered -

adding 127.0.0.1:3128 to the /etc/proxychains4.conf I tried running nmap scan on both the IP’s, i.e. - 10.197.S243.77 and 10.197.243.31

Result - We find that 10.197.243.77 is open but we still can’t access 10.197.243.31 and the result of scan on 10.197.243.77 is the same as 10.10.10.224

Now I added 10.197.243.77 to the .conf file and now we can access 10.197.243.31 so the proxy chain looks like - 10.10.10.224 –> 127.0.0.1 –> 10.197.243.77 –> 10.197.243.31

Scan Results -

Port 80 is OPEN.

On curling the page we can see it is a default nginx page. On googling wpad we find about it’s config file which is in wpad.dat, which had -

Seeing these I decided to run nmap against 10.197.243.0/24 and 10.241.251.0/24 of the top ports and it took ages to complete.

proxychains4 nmap -Pn 10.197.243.0/24 > nmap3
proxychains4 nmap -Pn 10.241.251.0/24 > nmap4

After hours of scanning I finnaly got an OK

Port 25 of 10.241.251.113 is open!!! Scanning the IP separetely, we only get the smtp port open, running -A flag on port 25

Through some quick enumeration, we find that this version is exploitable. For gaining a reverse shell I tried using metasploit through proxycahins but for some reason it couldn’t create a session, so I searched google for some other scripts and i found https://github.com/jopraveen/CVE-2020-7247

I changed this line to: and ran it as - and we gained a shell as root??

but looking around I found that we were trapped in the smtp server and we had to somehow pivot.

SMTP Server Machine Enumeration

Looking in the /home/j.nakazawa directory we found a hidden file .msmtprc which had some credentials which I hoped would work on ssh but it didn’t :/.

Privilege Escalation to User

There was a kerbrute port open on the original IP and there is a method to login through kerbrute into ssh. I followed parts of this article - https://uz.sns.it/~enrico/site/posts/kerberos/password-less-ssh-login-with-kerberos.html The default kerb configuration file is in /etc/kerb5.conf so changes have to be made in it. I changed the default_realm variable to
REALCORP.HTB(For some reason it has to be in all caps)

(I commented other default_realm and realms as they caused errors) and then I added REALCORP.HTB in realms like -

then did - kinit j.nakazawa and entered the password when asked this generated a ticket to login through ssh which I confirmed by klist.

ONLY srv01.realcorp.htb should be in the /etc/hosts file

Now we try to login through ssh

ssh j.nakazawa@10.10.10.224

and voila we are in

Privilege Escalation to admin?

Seeing the home directory there is another user by the name of admin so I had an intuition that we first had to escalate to admin and then move forward. In the crontab there is a service running as admin -

Taking a look into the sccript -

It is using rsync, which is a file copying tool, so the first part of this script is copying files from /var/log/squid to /home/admin. We see the perms of /var/log/squid to see if we can write in it and it turns out we can.

So I first tried to put my public ssh key in /var/log/squid/.ssh/authorized_keys and tried to login through that into admin but that didn’t work.

So back to kerberos, I made a .k5login in /var/log/squid and put in “j.nakazawa@REALCORP.HTB” to enable ssh login through kerberos, and it worked.

Privilege Escalation to root

Linpeas found this -

But this lead to nothing :(. It also found this -

The squid.conf file contains nothing special. A quick google about keytab files tells us that A keytab is a file containing pairs of Kerberos principals and encrypted keys, so I did some enumeration on this keytab file.For Kerberos commands refer to https://docs.oracle.com/cd/E19253-01/816-4557/refer-5/index.html