CyberSploit1 is a beginner-level boot-to-root on OffSec PG Play. Nothing fancy here — open ports, a web app that practically hands you credentials, and a kernel so old it should be in a museum. If you're getting into CTFs or want to practice the basics of web enumeration and kernel privilege escalation, this is a solid box to run through.

The full kill chain goes like this:

  • Nmap to find what's running
  • Gobuster to poke around the web server
  • Stumble onto credentials sitting in plain sight in the HTML source and robots.txt
  • SSH in with those creds
  • Kernel is running 3.13 — grab the overlayfs exploit, compile it on the box, run it, get root

⚠️ Disclaimer: All IPs and credentials in this writeup are redacted. This is for 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 Web Directory Enumeration — Gobuster
3. Initial Access
   3.1 Investigating robots.txt
   3.2 HTML Source Code Analysis
   3.3 SSH Login
4. Privilege Escalation
   4.1 System Enumeration
   4.2 Exploit Identification — searchsploit
   4.3 Exploit Execution
5. Attack Chain Summary
6. Defense & Mitigation
   6.1 Credential Exposure in HTML Source & robots.txt
   6.2 Outdated Operating System & Kernel
   6.3 CVE-2015-1328 — Kernel overlayfs LPE
   6.4 SSH Hardening
   6.5 Web Server Hardening
7. Conclusion

Lab Summary

Lab Name           : CyberSploit1
Platform           : OffSec Proving Grounds (PG Play)
Difficulty         : Easy
OS                 : Ubuntu Linux 12.04.5 LTS (32-bit)
Services           : SSH (22/tcp), HTTP (80/tcp)
Initial Access     : Credentials found in HTML source / robots.txt (Base64)
Privilege Escalation: CVE-2015-1328 — Linux Kernel overlayfs LPE

2. Reconnaissance

2.1 Port Scanning — Nmap

First thing — kick off an Nmap scan to see what's exposed. Used -Pn to skip host discovery, -A for full service/version/OS detection, -F for the top 100 ports.

nmap -Pn -A -F [TARGET_IP]

Figure 1: Nmap scan — SSH on 22, Apache on 80

Two ports open:

  • Port 22/tcp — OpenSSH 5.9p1
  • Port 80/tcp — Apache 2.2.22, page title is "Hello Pentester!"

💡 The title is basically winking at you. This box wants to be found.

2.2 Web Directory Enumeration — Gobuster

HTTP is up, so let's see what's hiding on the server. Ran Gobuster with the standard common.txt wordlist.

gobuster dir -u http://[TARGET_IP]/ -w /usr/share/dirb/wordlists/common.txt

Figure 2: Gobuster results — /hacker and /robots.txt stand out

Things worth noting:

  • /index.html — the main page (200, ~2333 bytes)
  • /hacker — something big, ~3.7 MB, probably an image
  • /robots.txt — only 53 bytes, that's suspicious
None

3. Initial Access

3.1 Investigating robots.txt

robots.txt is always worth a look. Developers love sticking things in there they shouldn't, and at 53 bytes, this is clearly not a real SEO file.

curl http://[TARGET_IP]/robots.txt

Figure 3: robots.txt spits out a Base64 string

The whole file was just this:

Y3liZXJzcGxvaXR7eW91dHViZS5jb20vYy9jeWJlcnNwbG9pdH0=

Decode it, and you get a YouTube URL — not a password by itself, but the decoded value becomes the SSH password when paired with the username we find next.

3.2 HTML Source Code Analysis

Curled the index page to read the raw HTML. The page title says "Welcome To CyBeRSplOiT-CTF" — already a hint. But the real gold is at the bottom.

curl http://[TARGET_IP]

Figure 4: HTML source — Bootstrap template, nothing wild yet

Figure 5: Username sitting in an HTML comment right before </body>

There it is — a username left in an HTML comment. Combined with the Base64 string robots.txt as the password, we have everything we need to get in.

🔑 Credentials found:

  • Username: [REDACTED_USER]
  • Password: [REDACTED_PASS] (decoded Base64 from robots.txt)

3.3 SSH Login

Tried the creds over SSH. Went straight in.

ssh [REDACTED_USER]@[TARGET_IP]

Figure 6: Logged in — Ubuntu 12.04.5 LTS, kernel 3.13.0–32

The login banner immediately tells you what you're dealing with: Ubuntu 12.04.5 LTS, kernel 3.13.0–32-generic, i686. That's an EOL OS on a kernel that's been exploitable since 2015. This privesc practically writes itself.

📌 Shell as: [REDACTED_USER] | Kernel: 3.13.0-32-generic i686

4. Privilege Escalation

4.1 System Enumeration

Before reaching for an exploit, I quickly confirmed two things: the exact kernel version and whether gcc is on the box — we need it to compile the exploit locally.

pkexec --version
which gcc

Figure 7: pkexec 0.104 and gcc both confirmed

  • pkexec is version 0.104 — also vulnerable to PwnKit (CVE-2021-4034), but we didn't need to go there
  • gcc is at /usr/bin/gcc — We can compile directly on the target, no file transfer needed
None

4.2 Exploit Identification — searchsploit

Kernel 3.13 on Ubuntu 12.04 — that's a well-known target. Pulled exploit 37292 straight from ExploitDB.

searchsploit -m 37292 .

Figure 8: searchsploit confirms 37292 matches this kernel

CVE-2015–1328 — overlayfs Local Privilege Escalation

Affected Kernels : Linux 3.13.0 < 3.19 (Ubuntu 12.04/14.04/14.10/15.04)
Exploit-DB ID    : 37292
CVE              : CVE-2015-1328
Verified         : True

The bug is in how overlayfs handles file creation in the upper mount directory — it skips the permission check, so any local user can abuse it to write as root and drop a shell. The exploit is a C file, verified, and well understood. It just works.

4.3 Exploit Execution

Moved the exploit to /tmp on the target, compiled it, and ran it.

gcc 37292.c -o root_exploit
chmod +x root_exploit
./root_exploit

Figure 9: Exploit runs, spawns threads, drops a root shell

The output walks you through exactly what it's doing — spawning threads, setting up the mount, creating the shared library, and then dropping you into a root shell. whoami confirms it.

None

🎯 Rooted. whoami → root

5. Attack Chain Summary

#   Phase                  Technique / Tool                   Result
-   -----                  ----------------                   ------
1   Recon                  nmap -Pn -A -F                     SSH + HTTP found
2   Web Enum               gobuster (common.txt)              /robots.txt, /hacker found
3   Credential Discovery   curl robots.txt + HTML source      [REDACTED_USER] / [REDACTED_PASS] obtained
4   Initial Access         SSH with found creds               Low-privilege shell on Ubuntu 12.04
5   System Enum            pkexec --version, which gcc        Kernel 3.13 confirmed, gcc available
6   Exploit Research       searchsploit -m 37292              CVE-2015-1328 overlayfs exploit pulled
7   PrivEsc                gcc 37292.c && ./root_exploit       Root shell

6. Defense & Mitigation

These aren't exotic vulnerabilities. Every single one of them has a straightforward fix — they just require someone to actually do it.

6.1 Credential Exposure in HTML Source & robots.txt

⚠️ Risk: A username in an HTML comment and a password encoded in Base64 inside robots.txt. Neither of these is hidden — anyone who looks at the page source or curls robots.txt gets in.

  1. Stop putting credentials, usernames, or internal paths anywhere in client-facing files. This includes HTML, JS, robots.txt, and config files checked into public repos.
  2. Add secret scanning to your pipeline. Tools like TruffleHog and GitLeaks catch this before it ships.
  3. Base64 is not encryption. It's not even obfuscation — it takes three seconds to decode. Treat anything Base64-encoded in a public file as plaintext and rotate it immediately.
  4. robots.txt It is public by design. Don't use it to list paths you don't want people visiting — that's literally an invitation.

6.2 Outdated Operating System & Kernel

⚠️ Risk: Ubuntu 12.04 hit end-of-life in April 2017. It hasn't received a security patch in years. Running it means every known kernel CVE from the last seven-plus years is live on your system.

  1. Get off EOL software. Ubuntu 22.04 LTS and 24.04 LTS are both current and supported.
  2. If you can't upgrade immediately, at least patch the kernel. The fix for CVE-2015–1328 shipped in May 2015 — there's no excuse for running without it.
  3. Run a vulnerability scanner (Nessus, OpenVAS, Qualys) against your infrastructure regularly. EOL systems stick out immediately.
  4. If an upgrade is genuinely blocked short-term, compensate: restrict who can log in locally, add AppArmor profiles, isolate the system, and monitor it closely.

6.3 CVE-2015–1328 — Kernel overlayfs LPE

⚠️ Risk: Any local user can become root. The exploit is public, verified, and requires nothing but gcc. If someone can SSH in as a low-privileged user, they own the box.

  1. Patch the kernel. This was fixed in USN-2614–1 in May 2015. If you're still running an affected kernel, that's a process failure.
  2. Apply the principle of least privilege everywhere you can — the less a user account can do, the less damage an attacker can do with it.
  3. AppArmor and SELinux can contain the blast radius of a privilege escalation even when one lands. Use them.
  4. Set up process monitoring — auditd, Falco, or similar. A regular user spawning a root process should fire an alert.

6.4 SSH Hardening

⚠️ Risk: Password authentication on port 22 is open to the internet. Once credentials are found anywhere — an HTML comment, a paste site, a breached database — the box is one command away from being owned.

  1. Turn off password auth entirely. Set PasswordAuthentication no in sshd_config and use key-based auth only.
  2. Port 22 draws constant automated scanning. Moving to a non-standard port won't stop a determined attacker, but it eliminates most of the noise.
  3. fail2ban It is easy to set up and blocks IPs after repeated failed logins. There's no reason not to have it running.
  4. Lock SSH access down at the firewall — only allow it from known IP ranges wherever possible.
  5. If you need broader access, add MFA. The Google Authenticator PAM module integrates cleanly with SSH.

6.5 Web Server Hardening

⚠️ Risk: Apache 2.2.22 is ancient and has its own CVEs. On top of that, directory enumeration worked without any resistance — no rate limiting, no WAF, nothing.

  1. Upgrade Apache. 2.4.x is the current branch — 2.2 has been EOL since 2017.
  2. Stop advertising your server version. Set ServerTokens Prod and ServerSignature Off in httpd.conf. Don't hand attackers your version string for free.
  3. Disable directory listing with Options -Indexes. If there's no index file, Apache shouldn't be showing directory contents.
  4. Even basic rate limiting would have made the Gobuster scan slower and more visible. A WAF would have flagged it outright.

7. Conclusion

CyberSploit1 is straightforward — maybe almost too straightforward — but that's the point. The attack chain isn't clever. It's:

  1. Find credentials in a place no one should have put them.
  2. Log in over SSH.
  3. Run a 10-year-old public exploit on an unpatched kernel.

No zero-days, no custom tooling, no guesswork. Just basic enumeration and a system that was never properly secured.

The uncomfortable takeaway is that this isn't a contrived CTF scenario — variations of this exact chain show up in real-world assessments all the time. Credentials in source code, EOL systems that "can't be upgraded right now," password auth on SSH. These aren't hard problems to fix. They just require someone to prioritize fixing them.

Key takeaways:

  1. Credentials in any client-accessible file are credentials in the open. Full stop.
  2. EOL software is a liability. If it's on the network, it needs to be patched or replaced.
  3. Key-based SSH auth is not optional — it's the baseline.
  4. Scan your own infrastructure before someone else does.
  5. Monitor for privilege escalation. If a user process spawns a root shell, you want to know about it.