FunboxRookie — Anonymous FTP, Zip-Cracked SSH Keys, and a Password Hidden in MySQL History | OffSec…

FunboxRookie — Anonymous FTP, Zip-Cracked SSH Keys, and a Password Hidden in MySQL History | OffSec… | by Roshan Rajbanshi | in InfoSec Write-ups - Freedium Milestone: 20GB Reached We’ve reached 20GB of stored data — thank you for helping us grow! Patreon Ko-fi Liberapay Close < Go to the original FunboxRookie — Anonymous FTP, Zip-Cracked SSH Keys, and a Password Hidden in MySQL History | OffSec… FunboxRookie is a beginner-level boot-to-root on OffSec PG Play. The attack surface is wider than CyberSploit1, but still pretty… Roshan Rajbanshi Follow InfoSec Write-ups · ~9 min read · March 25, 2026 (Updated: March 25, 2026) · Free: Yes FunboxRookie is a beginner-level boot-to-root on OffSec PG Play. The attack surface is wider than CyberSploit1, but still pretty approachable — three services, an FTP server open to anonymous access, a pile of password-protected zip files, and a user who can run sudo with no restrictions whatsoever. The kill chain: Nmap finds FTP (21), SSH (22), and HTTP (80) FTP allows anonymous login — grab everything Hidden files in the FTP share reveal a username list and a Base64-encoded hint The zip files each contain an SSH private key, but they're password-protected Use zip2john + john against rockyou.txt to crack two zip passwords SSH in as [REDACTED_USER] using the cracked RSA key Spot sudo -l showing (ALL : ALL) ALL — one sudo -i later and you're root ⚠️ Disclaimer: All IPs and credentials in this writeup are redacted. Educational use only. Don't run any of this against systems you don't own or have written permission to test. Table of Contents 1. Introduction 2. Reconnaissance 2.1 Port Scanning — Nmap 2.2 FTP Anonymous Access 2.3 Enumerating Hidden Files & Notes 3. Initial Access 3.1 Cracking Zip Passwords with zip2john + john 3.2 Extracting RSA Keys & SSH Login 4. Privilege Escalation 4.1 MySQL History — tom's Password in Plaintext 4.2 Sudo Enumeration 4.3 Root via sudo -i 5. Rabbit Hole — cathrine's Key Doesn't Work 6. Attack Chain Summary 7. Defense & Mitigation 7.1 Anonymous FTP Access 7.2 Weak Zip Passwords Protecting SSH Keys 7.3 Overly Permissive sudo 7.4 Sensitive Data in MySQL History 7.5 SSH Hardening 8. Conclusion Lab Summary Lab Name : FunboxRookie Platform : OffSec Proving Grounds (PG Play) Difficulty : Easy OS : Ubuntu 18.04.4 LTS (kernel 4.15.0-117-generic x86_64) Services : FTP (21/tcp), SSH (22/tcp), HTTP (80/tcp) Initial Access : Anonymous FTP → zip2john → cracked RSA key → SSH as tom Privilege Escalation: sudo -l shows (ALL : ALL) ALL → sudo -i → root 2. Reconnaissance 2.1 Port Scanning — Nmap Standard aggressive scan. -Pn to skip ping, -A for full detection, -F for the top 100 ports. nmap -Pn -A -F [TARGET_IP] Three services up: Port 21/tcp — ProFTPD 1.3.5e, anonymous FTP login allowed Port 22/tcp — OpenSSH 7.6p1 (Ubuntu) Port 80/tcp — Apache 2.4.29, default Ubuntu page, robots.txt has one disallowed entry ( /logs/ ) The FTP banner immediately shows a directory listing — multiple .zip files named after people (anna, ariel, bud, cathrine, homer, jessica, john, marge, miriam, tom, zlatan) plus a welcome.msg . That's the obvious starting point. 💡 Anonymous FTP with a directory full of named zip files — someone left the front door wide open. 2.2 FTP Anonymous Access Logged in with username anonymous and any email as the password. ftp [TARGET_IP] Figure: Anonymous FTP login — zip files, welcome.msg, and two hidden files: .admins and .users ls -la reveals two hidden files that don't show up in the Nmap script output: .admins — 153 bytes, worth reading .users — 114 bytes, worth reading Pulled everything down with mget * . mget * Figure: mget pulling all zip files and hidden files to the attacker's machine 2.3 Enumerating Hidden Files & Notes With everything local, read the text files. cat welcome.msg cat .admins cat .users Figure 4: .admins contains a Base64 blob; .users is a note from root hinting at the zip structure Key findings: .admins — contains a long Base64 string. Decoded it reveals: "Hi Admins, be careful with your keys. Find them in %yourname%.zip. The passwords are the old ones." — signed root. .users — same message directed at regular users. 🔑 Takeaway: Each zip file contains an SSH private key for that user. The passwords protecting the zips are "the old ones" — meaning they're in a wordlist. Time for John. 3. Initial Access 3.1 Cracking Zip Passwords with zip2john + john Extracted hashes from all the zip files in one shot with a bash loop, then fed them to John the Ripper against rockyou.txt . for f in *.zip; do zip2john "$f" > "$f.hash"; done john --wordlist=/usr/share/wordlists/rockyou.txt --rules *.hash John cracked two passwords: tom.zip — password: [REDACTED_PASS_TOM] cathrine.zip — password: [REDACTED_PASS_CATHRINE] The other zips didn't crack against rockyou — those users' passwords are either stronger or not the intended path. 3.2 Extracting RSA Keys & SSH Login Unzipped both archives with the cracked passwords to extract the id_rsa private keys. unzip -P [REDACTED_PASS_TOM] tom.zip mv id_rsa tom_id_rsa unzip -P [REDACTED_PASS_CATHRINE] cathrine.zip -d cathrine_key mv cathrine_key/id_rsa cathrine_id_rsa Figure 6: Keys extracted — tom_id_rsa and cathrine_id_rsa ready to use SSH'd in as tom First — worked immediately. ssh -i tom_id_rsa tom@[TARGET_IP] Figure 7: Logged in as tom — Ubuntu 18.04.4 LTS, kernel 4.15.0–117-generic x86_64 Clean login. Ubuntu 18.04.4 LTS, kernel 4.15 — not as obviously ancient as CyberSploit1, but the real problem isn't the kernel here. 📌 Shell as: tom@funbox2 | Ubuntu 18.04.4 LTS 4. Privilege Escalation 4.1 MySQL History — Tom's Password in Plaintext First thing after landing a shell — poke around the home directory. .mysql_history was sitting right there. cat ~/.mysql_history The history shows that someone created a support database, a users table, and then ran: insert into support (tom, [REDACTED_PASSWORD]); Tom's password, in plaintext, was logged to a history file. That's the password we need for sudo. 🔑 tom's system password recovered from .mysql_history 4.2 Sudo Enumeration With Tom's password in hand, I ran sudo -l to see what he can do. sudo -l Figure 10: sudo -l — tom can run (ALL : ALL) ALL with no restrictions (ALL : ALL) ALL . Tom can run anything as any user with no command restrictions. That's the worst possible sudo config — effectively root at will. 4.3 Root via sudo -i sudo -i Figure 10: sudo -i drops straight into a root shell One command. That's it. 🎯 Rooted. root@funbox2:~# 5. Rabbit Hole — Catherine's Key Doesn't Work Worth documenting. After extracting, tried SSHing in as cathrine — the key wasn't accepted, and it fell back to password auth, which also failed. ssh -i cathrine_id_rsa cathrine@[TARGET_IP] The key file exists inside the zip, but doesn't match Catherine's authorized_keys on the server. Tom was the intended path. Cathrine's crack was a dead end. 6. Attack Chain Summary # Phase Technique / Tool Result - ----- ---------------- ------ 1 Recon nmap -Pn -A -F FTP (21), SSH (22), HTTP (80) found 2 FTP Enum ftp anonymous login + ls -la zip files + .admins + .users downloaded 3 Intel Gathering cat .admins / .users (Base64 decode) Confirmed: zips contain SSH keys, old passwords 4 Hash Extraction zip2john loop over all zips Hashes extracted for all zip files 5 Password Cracking john + rockyou.txt tom + cathrine zip passwords cracked 6 Key Extraction unzip -P with cracked passwords tom_id_rsa and cathrine_id_rsa extracted 7 Initial Access ssh -i tom_id_rsa tom@[TARGET_IP] Shell as tom on Ubuntu 18.04 8 Cred Discovery cat ~/.mysql_history tom's plaintext password recovered 9 Privilege Escalation sudo -l → (ALL:ALL) ALL sudo -i → root 7. Defense & Mitigation None of these vulnerabilities is subtle. Every single one is a basic configuration failure. 7.1 Anonymous FTP Access ⚠️ Risk: Anonymous FTP login was enabled on a server hosting user SSH private keys. Anyone on the network — or internet, if exposed — could download them with no credentials. Disable anonymous FTP entirely unless there's an explicit, reviewed business reason for it. In ProFTPD, set block to not exist, or add RequireValidShell off and ensure no anonymous access directive is present. Never store SSH private keys in FTP-accessible directories. Keys belong in user home directories with strict permissions ( chmod 600 ), not in world-readable shares. If FTP must be used, switch to SFTP or FTPS. Plain FTP transmits credentials and data in cleartext. Audit FTP access logs regularly. Anonymous logins downloading files should generate alerts. 7.2 Weak Zip Passwords Protecting SSH Keys ⚠️ Risk: SSH private keys were protected only by zip passwords that cracked against rockyou.txt in under two minutes. The encryption was trivial to bypass. Don't use zip encryption to protect sensitive key material. It's not the right tool — zip's AES-256 mode is acceptable, but the default PKZIP encryption (what these used) is weak. SSH private keys should be protected with strong passphrases directly on the key using ssh-keygen -p . That way, even if the key file is obtained, it's not immediately usable. Enforce a password policy that prevents dictionary words and common passwords. Anything in rockyou.txt is a failed password. The whole premise of distributing SSH keys via FTP is wrong. Use a proper key management or deployment process. 7.3 Overly Permissive sudo ⚠️ Risk: (ALL : ALL) ALL in sudoers means tom can run any command as any user, including root, with no restrictions. This is functionally equivalent to giving tom the root password. Apply the principle of least privilege to sudoers. If a user needs to run one specific command as root, grant exactly that — not everything. Review /etc/sudoers and /etc/sudoers.d/ on all systems. (ALL : ALL) ALL For a regular user is almost always a misconfiguration. Require password authentication for sudo — don't use NOPASSWD unless necessary and scoped tightly. Log sudo usage with auditd or similar. Unexpected sudo -i calls from a user who doesn't normally need root access should fire an alert. 7.4 Sensitive Data in MySQL History ⚠️ Risk: A plaintext password was inserted via MySQL and recorded in .mysql_history . Anyone with read access to tom's home directory can recover it. Clear .mysql_history and add it to .gitignore if the home directory is version-controlled. Better: disable MySQL history logging by setting MYSQL_HISTFILE=/dev/null in the user's shell profile. Never insert plaintext credentials directly into SQL queries typed at a terminal. Use parameterized inserts or seed scripts that read from environment variables. Rotate any credentials found in history files immediately — treat them as compromised. 7.5 SSH Hardening ⚠️ Risk: SSH was accessible with key-based auth, which is good — but the keys were trivially obtainable via anonymous FTP and the zip passwords were weak. Key distribution needs to be secure end-to-end. If a private key can be grabbed by anyone before they authenticate, key-based auth provides no real protection. Add passphrases to all SSH private keys. Restrict which users can SSH in with AllowUsers in sshd_config — Tom apparently having unrestricted sudo means a compromise of his SSH session is a full system compromise. Consider certificate-based SSH (using an internal CA) instead of individual key management. It's harder to leak and easier to rotate. 8. Conclusion FunboxRookie has a slightly longer chain than CyberSploit1, but every step is equally avoidable. The whole box collapses because of three decisions: Anonymous FTP hosting private SSH keys — the crown jewels sitting on a park bench Zip passwords are weak enough to crack in two minutes against a public wordlist A user account with unrestricted sudo privilege escalation that isn't really escalation, it's just switching seats The .mysql_history Finding isn't even part of the intended chain, but it's the kind of thing that shows up constantly in real assessments. Developers test locally, type passwords directly into MySQL prompts, and never clean up after themselves. The pattern here is the same as CyberSploit1: no exotic techniques, no vulnerability research, no zero-days. Just basic misconfigurations that have been on the OWASP and CIS benchmark radar for years. Fix anonymous FTP, use proper key management, scope sudo correctly, and this entire attack chain disappears. Key takeaways: Anonymous FTP + SSH keys is a complete auth bypass. Never combine them. Protecting private keys with weak zip passwords is not protection. (ALL : ALL) ALL In sudoers, the user is root—treat the account accordingly. Shell history files are a goldmine for attackers. Audit and clean them. If you're distributing keys, do it over an authenticated, encrypted channel. For educational purposes only. All credentials have been redacted. #cybersecurity #writing #penetration-testing #offensive-security #linux Reporting a Problem Sometimes we have problems displaying some Medium posts. If you have a problem that some images aren't loading - try using VPN. Probably you have problem with access to Medium CDN (or fucking Cloudflare's bot detection algorithms are blocking you).