Overview
Simple Network Management Protocol (SNMP) is intended to provide administrators with visibility into system state and health. When implemented poorly, however, SNMP becomes a high-impact information disclosure mechanism, capable of leaking sensitive operational data including plaintext creds.
This post focuses purely on the technique: how SNMP enumeration works, how credentials end up exposed, and how that exposure transitions directly into authenticated system access.
How SNMP Works (High Level)
SNMP follows a manager/agent model [1]:
- SNMP Agent runs on the target system and exposes management data
- SNMP Manager queries that data
- MIB (Management Information Base) defines structured variables, accessed via OIDs
In SNMP v1 and v2c, access control relies on community strings, which function as shared passwords [1,2]:
- Common defaults such as
publicorprivate - Transmitted in cleartext
- Often granted broad read access to system OIDs
Once a valid community string is known, the agent implicitly trusts the requester.
Enumeration Technique
Community String Discovery
The first step is identifying a valid community string [4,9]. This is frequently successful due to:
- Default configurations remaining unchanged
- Legacy monitoring tooling requirements
- SNMP being excluded from routine hardening efforts
Once discovered, this enables unrestricted read access to exposed OIDs.
Walking the MIB
With a valid community string, an attacker can walk the MIB, enumerating large portions of the SNMP tree. This typically reveals:
- System descriptions
- Contact and location fields
- Hostnames and device roles
- Administrator-defined free-text fields
It is within these free-text fields that the most damaging misconfigurations occur.
Terminal Walkthrough (Redacted Example)
The following terminal output mirrors a real-world SNMP enumeration flow using industry-standard reconnaissance tools [7,8]. All IP addresses, usernames, and credentials have been deliberately redacted.
Initial Surface Check
┌──(pretengineer㉿wick)-[~/engagement]
└─$ rustscan -a <TARGET_IP> --ulimit 5000 -r 1-65535 -- -A -sS -Pn
Open <TARGET_IP>:22
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH X.XpX Ubuntu (protocol 2.0)
┌──(pretengineer㉿wick)-[~/engagement]
└─$ sudo nmap -sU -p- --min-rate 5000 <TARGET_IP>
Starting Nmap 7.XX ( https://nmap.org )
Nmap scan report for <TARGET_IP>
Host is up (0.050s latency).
Not shown: 65534 closed udp ports (port-unreach)
PORT STATE SERVICE
161/udp open snmp
Nmap done: 1 IP address (1 host up) scanned in XXX.XX seconds Network Service Discovery
Reconnaissance Methodology:
Initial network enumeration using a two-phase scanning approach: TCP port scanning with rustscan for speed, followed by targeted UDP scanning to discover management protocols.
Key Findings:
- SSH Service: OpenSSH running on TCP port 22
- SNMP Service: Running on UDP port 161 (v1/v2c)
- Attack Surface: Limited exposed services
- Target Protocol: SNMP becomes the primary enumeration target
Why UDP Scanning Matters:
SNMP operates over UDP, which is often overlooked in reconnaissance. UDP services like SNMP (161/162) can expose significant information about network devices and systems.
Next Steps:
- Enumerate SNMP community strings
- Walk the SNMP MIB tree
- Extract system configuration data
SNMP Community Enumeration
┌──(pretengineer㉿wick)-[~/engagement]
└─$ onesixtyone -c /usr/share/seclists/Discovery/SNMP/common-snmp-community-strings.txt <TARGET_IP>
Scanning 1 hosts, XXX communities
<TARGET_IP> [public] <RESPONSE_RECEIVED> SNMP Authentication Bypass
Community String Discovery:
SNMP v1 and v2c use community strings as a form of authentication. These function as shared passwords and are often left at default values like "public" (read-only) or "private" (read-write).
Tool: onesixtyone [7]:
- Purpose: Fast SNMP community string scanner
- Method: Dictionary-based brute-forcing
- Wordlist: SecLists SNMP community string list
- Success: Discovered "public" community string
Why This Works:
Default community strings are rarely changed in production environments. The "public" string grants read access to the entire SNMP MIB, exposing system configuration, network topology, and potentially credentials.
Impact:
- Full MIB read access granted
- No authentication required beyond community string
- Transmitted in cleartext (SNMP v1/v2c)
- Enables complete system information disclosure
ISM Control: ISM-1311 prohibits SNMP v1/v2c for this reason
SNMP Walk – Information Disclosure
┌──(pretengineer㉿wick)-[~/engagement]
└─$ snmpwalk -v2c -c public <TARGET_IP>
iso.3.6.1.2.1.1.1.0 = STRING: "The default <ROLE> password is: <REDACTED> (change it after use)"
iso.3.6.1.2.1.1.4.0 = STRING: "<REDACTED_EMAIL>"
iso.3.6.1.2.1.1.5.0 = STRING: "<REDACTED_HOSTNAME>"
iso.3.6.1.2.1.1.6.0 = STRING: "<REDACTED_DESCRIPTION>" Critical Information Disclosure
Critical Security Failure:
A plaintext credential was discovered embedded directly within an SNMP system OID. This represents a catastrophic operational security failure.
What Happened:
- Tool: snmpwalk with community string "public"
- Protocol: SNMP v2c (cleartext transmission)
- Discovery: Default password in system description OID
- Exposure Level: No authentication required
Why This Is Dangerous [4,13]:
Administrators often use SNMP system fields as "notes" or reminders. When credentials, IP addresses, or configuration details are stored here, they become publicly accessible to anyone who can query SNMP.
Common Misuse Patterns:
- Default passwords stored in sysDescr
- Admin credentials in sysContact
- Internal IP addresses in sysLocation
- Configuration notes in custom OIDs
Attack Chain Impact:
- No Exploitation Required: Simple SNMP query
- No Privilege Escalation Needed: Credentials directly exposed
- Cleartext Transmission: Sniffable on the network
- Direct Initial Access: Credentials likely valid for SSH/other services
OWASP: A05:2021 - Security Misconfiguration
Impact: CRITICAL - Direct credential exposure without exploitation
Credential Validation via Legitimate Access
┌──(pretengineer㉿wick)-[~/engagement]
└─$ ssh <REDACTED_USER>@<TARGET_IP>
<REDACTED_USER>@<TARGET_IP>'s password: <REDACTED>
Welcome to Ubuntu XX.XX LTS From Discovery to Compromise
Attack Chain Complete:
The credentials discovered via SNMP enumeration were successfully validated against the SSH service, establishing authenticated access to the target system.
Why This Succeeded:
- Password Reuse: SNMP-exposed credential valid for SSH
- Legitimate Authentication: No exploitation required
- Default Credentials: Likely unchanged from initial setup
- No Detection: Legitimate authentication from system perspective
Attack Characteristics:
- No CVEs Exploited: Pure misconfiguration
- No Malware Deployed: Standard SSH client
- No Privilege Escalation: Direct user-level access
- Appears Legitimate: Normal SSH login attempt
From the Defender's Perspective:
This login appears as a standard authentication event. Without context linking it to prior SNMP enumeration, it's indistinguishable from legitimate user activity.
Detection Opportunities:
- SNMP walks from non-monitoring hosts [4,15]
- Authentication attempts immediately following SNMP queries [4]
- Logins from unexpected geographic locations
- New SSH sessions to rarely-accessed accounts
Attack Phase: Initial Access Complete
Post-Compromise: Establish persistence, elevate privileges, lateral movement
Why Credential Storage in SNMP Is Dangerous
SNMP system OIDs are frequently treated as “notes” fields [4,13]. When administrators store:
- Default passwords
- Temporary access credentials
- Operational reminders
they unintentionally publish those secrets to anyone with SNMP access. In v1/v2c, this data is exposed unencrypted [1,2].
MITRE ATT&CK Mapping
The techniques demonstrated in this attack map to the following MITRE ATT&CK framework entries [10-14]:
| Phase | Technique ID | Technique Name |
|---|---|---|
| Reconnaissance | T1595 | Active Scanning |
| Discovery | T1046 | Network Service Discovery |
| Discovery | T1082 | System Information Discovery |
| Credential Access | T1552 | Unsecured Credentials |
| Initial Access | T1078 | Valid Accounts |
Defensive Guidance
Hardening
- Disable SNMP where it is not strictly required [4,16]
- Migrate to SNMPv3 with authentication and encryption [3,5]
- Remove all credentials and secrets from SNMP-exposed fields [4]
- Restrict SNMP access by IP and network segment [16]
Detection
- Alert on SNMP walks from non-monitoring hosts [4,15]
- Monitor for authentication events immediately following SNMP queries [4]
- Audit SNMP MIB contents during security reviews [4,16]
Related Security Controls
This attack directly demonstrates why ISM-1311 exists within the Australian Government Information Security Manual (ISM) [5]:
ISM-1311
“SNMP version 1 and SNMP version 2 are not used on networks.”
Why this control matters:
The vulnerabilities demonstrated in this post (community string enumeration, cleartext transmission, credential exposure) are inherent to SNMP v1 and v2c. The ISM mandates SNMPv3 specifically to eliminate these authentication and confidentiality gaps.
Organizations following ISM-1311 would not be vulnerable to this attack vector, as SNMPv3 requires [3,5]:
- User authentication (not community strings)
- Message encryption (preventing credential interception)
- Access control (restricting who can query MIB data)
Related Resource: Explore ISM-1311 in the ISM Explorer to see its full context within the Information Security Manual’s network management controls.
Key Takeaway
A single misconfigured community string combined with poor operational hygiene can expose credentials that bypass perimeter controls entirely.
If SNMP is enabled, treat its data as public unless proven otherwise.
References
SNMP Protocol Standards
-
RFC 1157 - Simple Network Management Protocol (SNMP)
https://datatracker.ietf.org/doc/html/rfc1157
Original SNMP v1 specification defining the protocol architecture and community-based authentication -
RFC 1901-1908 - SNMP Version 2 (SNMPv2)
https://datatracker.ietf.org/doc/html/rfc1901
SNMPv2c specification maintaining community string authentication -
RFC 3414 - User-based Security Model (USM) for SNMPv3
https://datatracker.ietf.org/doc/html/rfc3414
SNMPv3 authentication and encryption mechanisms
Security Guidance
-
NIST Special Publication 800-115 - Technical Guide to Information Security Testing
https://csrc.nist.gov/publications/detail/sp/800-115/final
Guidance on network service enumeration and vulnerability assessment -
Australian Government ISM - Information Security Manual (December 2025)
https://www.cyber.gov.au/resources-business-and-government/essential-cyber-security/ism
ISM-1311: SNMP version restrictions for Australian Government systems -
SANS SEC542 - Web App Penetration Testing and Ethical Hacking
https://www.sans.org/cyber-security-courses/web-app-penetration-testing-ethical-hacking/
Network reconnaissance and SNMP enumeration techniques
Tools and Resources
-
onesixtyone - SNMP Scanner
https://github.com/trailofbits/onesixtyone
Fast SNMP community string brute-forcing tool -
Net-SNMP - SNMP Tools Suite
http://www.net-snmp.org/
Includes snmpwalk, snmpget, and other SNMP query utilities -
SecLists - SNMP Community Strings
https://github.com/danielmiessler/SecLists/tree/master/Discovery/SNMP
Common SNMP community string wordlists for security testing
MITRE ATT&CK Framework
-
T1595 - Active Scanning
https://attack.mitre.org/techniques/T1595/
Network scanning and service enumeration techniques -
T1046 - Network Service Discovery
https://attack.mitre.org/techniques/T1046/
Identifying services running on remote systems -
T1082 - System Information Discovery
https://attack.mitre.org/techniques/T1082/
Gathering system and network configuration information -
T1552 - Unsecured Credentials
https://attack.mitre.org/techniques/T1552/
Credentials stored in accessible locations including network services -
T1078 - Valid Accounts
https://attack.mitre.org/techniques/T1078/
Using legitimate credentials for initial access
Additional Reading
-
OWASP Testing Guide - Information Gathering
https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/01-Information_Gathering/
Reconnaissance and enumeration methodologies -
Cisco SNMP Best Practices
https://www.cisco.com/c/en/us/support/docs/ip/simple-network-management-protocol-snmp/7282-12.html
Vendor-specific SNMP hardening recommendations