SNMP Community String Brute Forcing

SNMP Community String Brute Forcing

SNMPv1 and v2c authenticate entirely by community string. There is no password hashing, no session challenge. If you know the string, you get read access to the full MIB tree. Devices are frequently left with vendor defaults: public for read access, private for read-write. Routers, switches, printers, UPS units, and legacy servers are common offenders. Brute forcing these strings requires only UDP 161 and a wordlist. The SecLists SNMP wordlist covers the most common defaults and custom strings seen in real environments.

This technique only works against SNMPv1 and v2c. SNMPv3 uses username-based authentication with optional encryption. Community string brute forcing does nothing against SNMPv3. Many devices run v1 or v2c alongside v3 for legacy compatibility, so both may be reachable simultaneously. Custom strings often follow vendor patterns: Cisco gear frequently uses the device hostname or cisco, HP devices default to public or hp, and some vendors embed the model number. Add vendor-specific guesses to the top of your wordlist before running the full dictionary.

onesixtyone Fast Brute

Quick dictionary attack against a single target. onesixtyone is purpose-built for SNMP brute forcing and handles large wordlists efficiently:

• onesixtyone Fast Brute
• Nmap snmp-brute Script

onesixtyone prints each responding host alongside the community string and a brief system description pulled from sysDescr.0. A line like [192.168.1.1] public Linux router 3.18.0 confirms read access. No output for a string means it was rejected. UDP means dropped packets look identical to rejected attempts, so a non-response does not confirm the host is offline. If results seem sparse on a live target, increase the wait time with -w. onesixtyone sends requests in parallel, making it significantly faster than sequential tools on large subnets.

The sysDescr value immediately identifies the device type. Cisco IOS or Juniper JUNOS means network infrastructure. Linux with a kernel version means a server or embedded device. Use this to pick the right MIB walk approach and OIDs to prioritize. Different device types expose different MIB branches with different useful data.

If a known-live host returns nothing, two failure modes are likely. The device may enforce SNMP source IP ACLs, accepting queries only from specific management hosts. Queries from your IP are silently dropped. Try from a host on the management VLAN if you can pivot there. Alternatively, the device may run SNMPv3 exclusively. In that case, no community string will work regardless of the wordlist length.

For a quick first pass, test only the three most common strings:

onesixtyone is the fastest choice for subnet-wide brute forcing or long wordlists. It sends UDP packets without waiting for full SNMP session setup, and can reach hundreds of hosts in under a minute on a reliable internal network. For a single target where you want to chain results directly into other Nmap scripts, the built-in snmp-brute NSE script is more convenient:

If neither tool returns results but SNMP port 161 is confirmed open, the device likely runs SNMPv3 only. Community string brute forcing is irrelevant against SNMPv3. Confirm the version with nmap -sU -p 161 --script snmp-info $TARGET_IP. If SNMPv3 is confirmed, shift to SNMPv3 user enumeration instead of continuing with community string guessing.

Nmap snmp-brute Script

Integrated brute force using Nmap's scripting engine:

The Nmap script reports confirmed community strings in the port script output. It also attempts to pull basic system information using the valid string, giving you confirmation and initial enumeration data in one step. The tradeoff is speed: Nmap processes hosts sequentially, making it substantially slower than onesixtyone for subnet-wide work. Use it when you want a single integrated scan output or when chaining with other NSE scripts like snmp-info or snmp-interfaces.

Once you have a valid read community string, proceed to a full MIB walk. That walk surfaces running processes, installed software, network interfaces, routing tables, and often local user accounts. A write-enabled community string is a separate finding that enables direct configuration changes on the target device and warrants its own assessment. Be aware that brute forcing generates repeated UDP traffic to port 161, which is visible in flow logs and may trigger rate-limiting on managed devices.

During the MIB walk, prioritize high-value OIDs. hrSWRunName (OID 1.3.6.1.2.1.25.4.2.1.2) lists every running process by name. ipAdEntAddr (OID 1.3.6.1.2.1.4.20.1.1) shows all IP addresses the device knows about. ifDescr (OID 1.3.6.1.2.1.2.2.1.2) maps interface names and link states. On network gear, routing table OIDs reveal connected subnets you may not have discovered yet. On Linux hosts, hrSWInstalledName lists installed packages, which identifies software versions worth targeting.

If the MIB walk returns partial data or stalls, the device may be rate-limiting SNMP queries. Lower the request rate or add delays between OID requests. If a valid community string authenticates but returns no data at all, SNMP ACLs are restricting your source IP. Verify by querying sysDescr.0 directly with snmpget. An empty response from a string that passed brute force confirms the ACL is blocking your host.

After finding a valid community string, confirm the vulnerability: SNMP Default and Weak Community Strings covers version and access assessment. If the string has write access, see SNMP Write-Enabled Community String.