I’m a professional penetration tester with hands-on red-team experience and OSCP-style practice. I treat every engagement — even CTF boxes — with the same discipline: methodical reconnaissance, prioritized attack paths, and clean, reproducible exploitation. I’m passionate about improving my craft and sharing practical knowledge that helps others learn faster.

Introduction

This Cybersploit1 walkthrough walks through the exact steps I took to compromise the machine: reconnaissance, web enumeration, credential discovery, SSH access, and local privilege escalation. You’ll find the precise commands I used, why I used them, annotated screenshots for verification, and short post-exploit checks — presented so beginners can follow and experienced testers can reproduce.

Reconnaissance

I started with a simple Nmap scan to identify open ports and services:

nmap -sC -sV -p- - min-rat 1000 192.168.122.92

The scan showed two open services: HTTP on port 80 and SSH on port 22. I opened the HTTP service in a browser and saw a simple web page.

The site’s UI had non-functional tabs, so the next step was to view the page source.

At the bottom of the HTML I found a hint: a username itsskv. I saved that — likely an SSH username.

Web enumeration

I used a directory fuzzing tool to find hidden files and directories. I prefer it ffuf because it’s fast and flexible:

ffuf -u http://192.168.122.92/FUZZ -w /usr/share/wordlists/dirb/common.txt -t 50 -mc 200

From the discovered directories I inspected /hacker and found an image and a robots.txt entry. The robots.txt contained a suspicious hash string

To decode the hash, I used CyberChef (or any base64 decoder). After trying different decodings, it turned out to be Base64, which revealed the password for the itsskv user.

Why CyberChef? CyberChef is an interactive tool that lets you quickly try common encodings/transforms (Base64, hex, rot, gzip, etc.) without guessing blindly.

Initial access — SSH

With itsskv and the decoded password, I SSHed to the machine:

ssh [email protected]

After logging in, I checked the home directory and found local.txt and flag2.txt. local.txt contained a flag string; flag2.txt said “Your flag is in another file...” (typical CTF hint).

ls -la
cat local.txt
cat flag2.txt
uname -a
cat /etc/issue

After that, I did basic enumeration

This shows an old Linux kernel: 3.13.0–32 on Ubuntu 12.04 LTS — important because old kernels often have local privilege escalation vulnerabilities.

Kernel vulnerabilities — choosing an exploit

Common kernel LPEs against kernels in this family include:

• OverlayFS local root (CVE-2015–1328) — affects certain kernel versions and configurations.
• Dirty COW (CVE-2016–5195) — widely exploited against older kernels.

I searched Exploit-DB and found an exploit (ID 37292) that targets a vulnerability applicable to this kernel. Link (for your notes): https://www.exploit-db.com/exploits/37292.

Note: Always verify whether an exploit is suitable for the exact kernel and architecture (i386 vs x86_64). Misapplying an exploit can crash the box.

Preparing the exploit on the target

The target system lacked network utilities like wget/curl, so I copied the exploit code manually: I opened nano 37292.c on the target and pasted the C source into a file.

Commands I used to inspect and prepare the file:

ls -l 37292.c
head -n 20 37292.c   # show the first 20 lines to confirm it's the expected C source

Why ls -l and head -n?

ls -l shows file size and permissions so you can confirm the file was saved and is the expected size.

head -n 20 quickly inspects the top of the file to confirm it contains C source (includes, function signatures) before compiling.

gcc 37292.c -o  expoilt
chmod +x expoilt

Why gcc 37292.c -o exploit?

• gcc is the GNU C Compiler. -o exploit names the output binary exploit (instead of default a.out), which keeps things tidy and obvious.
• Compiling on the target ensures the binary is built for the target architecture and libc, avoiding cross-architecture problems.

Then I made it executable and ran it:

chmod +x exploit
./exploit

After a short wait, I switched to the elevated root shell:

Post-exploit validation and notes

• I validated privileged access by listing /root and reading proof.txt. This confirms local privilege escalation success.
• Avoid leaving any artifacts on real systems. For CTFs, this is fine, but on real engagements, you must clean up and follow the rules of engagement.

Lessons learned / takeaways

1. Start small: scan (Nmap) and follow high-value paths (web → creds → SSH).
2. Inspect page source & fuzz directories (HTML comments, robots.txt).
3. Check kernel/arch (uname -a) before chasing LPEs; compile exploits on-target if needed.
4. Validate exploits and always follow rules of engagement.

Thank you for reading!!