Insecure SNMP Configuration

Simple Network Management Protocol (SNMP) is widely used for monitoring and managing network devices including routers, switches, firewalls, printers, servers, and IoT devices. Insecure SNMP configuration encompasses several related weaknesses: the use of default or easily guessable community strings (the shared secret used for authentication in SNMPv1 and SNMPv2c), the use of SNMPv1 or SNMPv2c instead of SNMPv3 (which supports proper authentication and encryption), overly permissive SNMP access that allows write operations, and the exposure of SNMP services to untrusted networks.

The most common SNMP security issue is the use of default community strings. The default read community string for most devices is "public" and the default read-write community string is "private". Despite being well-documented and universally known, these defaults persist across a staggering number of production systems. Even when changed from defaults, community strings are often set to easily guessable values like the company name, location, or simple words. Since SNMPv1 and SNMPv2c transmit community strings in cleartext, they can also be captured through network sniffing.

SNMP exposes a wealth of sensitive information through its Management Information Base (MIB). Querying SNMP can reveal system descriptions, installed software, running processes, network interface configurations, routing tables, ARP caches, user accounts, TCP connection states, and device configurations. With write access, an attacker can modify device configurations, alter routing tables, disable interfaces, and in some cases execute commands on the target device. This makes SNMP a high-value target for infrastructure reconnaissance and exploitation.

Attackers begin by scanning for SNMP-enabled devices using UDP port scanning. Since SNMP runs on UDP port 161, standard TCP scans will miss it. Use nmap -sU -p 161 --open target_range or the faster onesixtyone tool to identify responsive hosts. Once SNMP-enabled devices are located, the attacker attempts to authenticate using common community strings. The onesixtyone tool efficiently brute-forces community strings: onesixtyone -c /usr/share/seclists/Discovery/SNMP/common-snmp-community-strings.txt target_range. This can be performed against hundreds of hosts simultaneously.

Upon gaining authenticated SNMP read access, the attacker walks the entire MIB tree to extract maximum information: snmpwalk -v2c -c public target_ip. Specific high-value OIDs are targeted for reconnaissance. The 1.3.6.1.2.1.1 subtree reveals system information (hostname, description, uptime, contact). The 1.3.6.1.2.1.25.4.2.1.2 subtree (hrSWRunName) lists running processes on the target. Network interfaces and IP configurations are found under 1.3.6.1.2.1.2 and 1.3.6.1.2.1.4. On Windows systems, SNMP can expose user accounts under 1.3.6.1.4.1.77.1.2.25. The tool snmp-check automates extraction of all relevant information into a readable report.

With write access (typically the "private" community string), attackers can cause significantly more damage. On Cisco devices, SNMP write access can be used to download the running configuration (which often contains credentials): snmpset -v2c -c private target_ip 1.3.6.1.4.1.9.9.96.1.1.1.1.2.111 i 1 (initiating a TFTP config transfer). On some platforms, SNMP write access enables command execution through the NET-SNMP extend MIB. Attackers can also modify routing tables, disable interfaces, or change system configurations to facilitate further attacks or cause denial of service.

• Full network reconnaissance exposing system configurations, installed software, running processes, network topology, and user accounts
• Device configuration extraction including stored credentials on network devices (routers, switches, firewalls)
• Network topology mapping through SNMP-discovered interfaces, routing tables, and ARP caches
• Remote command execution on systems where SNMP write access allows extension execution or configuration modification
• Credential exposure from SNMP-enumerated configuration files that contain cleartext or weakly hashed passwords
• Denial of service through modification of routing tables, interface shutdowns, or configuration changes via SNMP write access
• Community string capture through network sniffing, as SNMPv1/v2c transmits authentication in cleartext
• Pivoting and lateral movement using intelligence gathered from SNMP enumeration to identify and target additional systems

1. Migrate all SNMP implementations from SNMPv1/v2c to SNMPv3, which supports authentication (SHA/SHA-256) and encryption (AES-128/AES-256), eliminating cleartext community string transmission
2. If SNMPv3 migration is not immediately possible, change all community strings from defaults to strong, random values of at least 20 characters that are not based on dictionary words, company names, or other guessable patterns
3. Disable SNMP write access on all devices unless there is a documented, operational requirement for SNMP-based configuration management. Use read-only community strings wherever monitoring is the sole requirement
4. Restrict SNMP access to specific, authorised management IP addresses or subnets using device-level ACLs: on Cisco devices, configure snmp-server community [string] RO [acl_number] to bind community strings to specific source IP ACLs
5. Place all SNMP management traffic on a dedicated, isolated management VLAN/network that is not accessible from user workstation segments or untrusted networks
6. Disable SNMP on all devices and interfaces where it is not required for monitoring or management operations
7. Implement SNMP trap monitoring and log all SNMP authentication failures to the SIEM for detecting brute-force attempts and unauthorised access
8. Conduct quarterly audits of SNMP configurations across all devices to ensure compliance with the organisation's SNMP security policy and detect any configuration drift

Begin SNMP testing by identifying all devices with UDP port 161 open. Since UDP scanning is inherently unreliable, use multiple methods: nmap -sU -p 161 --open -oA snmp_scan target_range and onesixtyone target_range. The tool onesixtyone is significantly faster for large-scale SNMP discovery. Also check for SNMP trap receivers on UDP port 162 and non-standard SNMP ports. Verify that SNMP is not accessible from untrusted network segments by testing from different VLANs.

Attempt community string enumeration against all discovered SNMP services. Use onesixtyone with comprehensive wordlists: onesixtyone -c /usr/share/seclists/Discovery/SNMP/common-snmp-community-strings-onesixtyone.txt -i targets.txt. Hydra can also brute-force SNMP: hydra -P community_strings.txt target snmp. Test common defaults first: "public", "private", "community", "manager", "admin", and company-specific variations. If any valid community string is found, perform a full MIB walk: snmpwalk -v2c -c discovered_string target_ip and document all sensitive information exposed.

For each device with valid SNMP access, use snmp-check for automated enumeration: snmp-check -c community_string target_ip. This extracts system information, user accounts, network details, routing, listening ports, and installed software in a structured format. Test for write access by attempting a benign SET operation (with authorisation): snmpset -v2c -c private target_ip 1.3.6.1.2.1.1.4.0 s "pentest_contact" (modifying sysContact). Use the Nmap SNMP scripts for additional checks: nmap -sU -p 161 --script snmp-brute,snmp-info,snmp-interfaces,snmp-processes,snmp-win32-users target. Determine the SNMP version supported and flag any device using SNMPv1/v2c as a finding, even with strong community strings, due to the cleartext transmission vulnerability. Report the specific community strings discovered, the information exposed, and whether write access was obtained.