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.

1. Disable anonymous FTP entirely unless there’s an explicit, reviewed business reason for it. In ProFTPD, set <Anonymous ~ftp> block to not exist, or add RequireValidShell off and ensure no anonymous access directive is present.
2. 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.
3. If FTP must be used, switch to SFTP or FTPS. Plain FTP transmits credentials and data in cleartext.
4. 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.

1. 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.
2. 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.
3. Enforce a password policy that prevents dictionary words and common passwords. Anything in rockyou.txt is a failed password.
4. 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.

1. Apply the principle of least privilege to sudoers. If a user needs to run one specific command as root, grant exactly that — not everything.
2. Review /etc/sudoers and /etc/sudoers.d/ on all systems. (ALL : ALL) ALL For a regular user is almost always a misconfiguration.
3. Require password authentication for sudo — don’t use NOPASSWD unless necessary and scoped tightly.
4. 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.

1. Clear .mysql_history and add it to .gitignore if the home directory is version-controlled.
2. Better: disable MySQL history logging by setting MYSQL_HISTFILE=/dev/null in the user's shell profile.
3. Never insert plaintext credentials directly into SQL queries typed at a terminal. Use parameterized inserts or seed scripts that read from environment variables.
4. 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.

1. 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.
2. Add passphrases to all SSH private keys.
3. 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.
4. 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:

1. Anonymous FTP hosting private SSH keys — the crown jewels sitting on a park bench
2. Zip passwords are weak enough to crack in two minutes against a public wordlist
3. 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:

1. Anonymous FTP + SSH keys is a complete auth bypass. Never combine them.
2. Protecting private keys with weak zip passwords is not protection.
3. (ALL : ALL) ALL In sudoers, the user is root—treat the account accordingly.
4. Shell history files are a goldmine for attackers. Audit and clean them.
5. If you’re distributing keys, do it over an authenticated, encrypted channel.

For educational purposes only. All credentials have been redacted.