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 public or private
  • 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

Port Enumeration
┌──(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
MITRE ATT&CK: T1046 - Network Service Discovery, T1595 - Active Scanning

SNMP Community Enumeration

Community String Brute-Force
┌──(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
MITRE ATT&CK: T1552 - Unsecured Credentials
ISM Control: ISM-1311 prohibits SNMP v1/v2c for this reason

SNMP Walk – Information Disclosure

MIB Walk - Credential Exposure
┌──(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
MITRE ATT&CK: T1552 - Unsecured Credentials, T1082 - System Information Discovery
OWASP: A05:2021 - Security Misconfiguration
Impact: CRITICAL - Direct credential exposure without exploitation

Credential Validation via Legitimate Access

SSH Authentication - Initial 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
MITRE ATT&CK: T1078 - Valid 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]:

PhaseTechnique IDTechnique Name
ReconnaissanceT1595Active Scanning
DiscoveryT1046Network Service Discovery
DiscoveryT1082System Information Discovery
Credential AccessT1552Unsecured Credentials
Initial AccessT1078Valid 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]

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

  1. 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

  2. RFC 1901-1908 - SNMP Version 2 (SNMPv2)
    https://datatracker.ietf.org/doc/html/rfc1901
    SNMPv2c specification maintaining community string authentication

  3. RFC 3414 - User-based Security Model (USM) for SNMPv3
    https://datatracker.ietf.org/doc/html/rfc3414
    SNMPv3 authentication and encryption mechanisms

Security Guidance

  1. 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

  2. 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

  3. 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

  1. onesixtyone - SNMP Scanner
    https://github.com/trailofbits/onesixtyone
    Fast SNMP community string brute-forcing tool

  2. Net-SNMP - SNMP Tools Suite
    http://www.net-snmp.org/
    Includes snmpwalk, snmpget, and other SNMP query utilities

  3. 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

  1. T1595 - Active Scanning
    https://attack.mitre.org/techniques/T1595/
    Network scanning and service enumeration techniques

  2. T1046 - Network Service Discovery
    https://attack.mitre.org/techniques/T1046/
    Identifying services running on remote systems

  3. T1082 - System Information Discovery
    https://attack.mitre.org/techniques/T1082/
    Gathering system and network configuration information

  4. T1552 - Unsecured Credentials
    https://attack.mitre.org/techniques/T1552/
    Credentials stored in accessible locations including network services

  5. T1078 - Valid Accounts
    https://attack.mitre.org/techniques/T1078/
    Using legitimate credentials for initial access

Additional Reading

  1. 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

  2. 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