A few months back I posted a blog entry, SNMP Best Practices, to give guidance on best methods to reduce security risks as they relate to SNMP. Now that everyone has had time to fix all those issues, I figured it's time to give some guidance to penetration testers and consultants on how to exploit exposed SNMP services by harvesting data and using it to expand their attack footprint.

The first question when approaching SNMP is identifying exposed services. To discover exposed services we often use the port scanner tool, NMAP, to scan for UDP port 161. Since most of the time we additionally want to enumerate the data, it is just as easy to automate the discovery and data extraction with simple scripts written in Python or Perl. I personally tend to use Perl and I have created such a script, which can be downloaded, from my GitHub page. If you choose to use my script, the syntax is very simple and is shown below in Figure 1:

Figure 1: snmpbw Perl Script Syntax

When I use this script, I set the target to the subnet range of the network I am testing. For example, if testing an internal network of, I would use the command, “./snmpbw.pl public 2 32.” This command will spin up 32 threads and attempt to conduct a snmpbulkwalk command on every host exposing SNMP on UDP port 161 within the entire /16 subnet range. When a device is found with SNMP enabled and a community string of “public,” the script will walk all MIB tables starting at ".1" then return the data and save it in a file for further offline analysis.

I have found this method to be very fruitful in harvesting valuable data, which can then be used to conduct further attacks against the environment. I typically kick off this SNMP data harvesting attack script once I have determined the IP address ranges in scope. Then, I just let it run in the background while I continue my network reconnaissance work. Once the snmpbw script has completed running, I then examine the recovered data.

One of the first things I do is extract the sysDesc . MIB data from each file to determine what devices I have harvested information from. This can easily be done using the following grep command:

grep "." *.snmp

An example of the results from this grep command is shown below in Figure 2:

Figure 2 sysDesc Data from extracted SNMP information

So now that you have harvested data from exposed SNMP services, what kind of information could you expect to find? Actually, it is quite amazing what can be discovered within the SNMP MIB data. With a little exploration, I often find some of the following usable pieces of data:

  • Email addresses
  • SNMP community strings
  • Password hashes
  • Clear text passwords

Of course, the effort it takes to discover usable information can often be very time consuming. MIB dumps can often be massive, running into multiple megabytes. So I have spent some time examining this issue trying to determine methods to reduce the time involved in examining the data and figured I would share a couple of these with the Community.

One of my favorite things I love to do with SNMP MIB data is trying to identify other valid SNMP community strings. Often this data can be used to gain further access to other system. As an example, if I can identify the private community string used by an organization on their Cisco IOS routers, then I could possibly use that community string to extract the running configurations from those routers. The best method for finding such data has often been related to SNMP Trap data. So again, using the following grep we can parse through a lot of MIB data quickly searching for the key word of “trap”:

grep -i "trap" *.snmp

The following example (Figure 3) shows information I was able to successfully enumerate from the SNMP data using the key word of “trap.” In this example, I was successful in identifying several SNMP community strings, which I then successfully used to gain, read, and write access to the SNMP of multiple network devices. I was also successful in using this data to extract the running configuration from nearly all of the Cisco routers on the network.

Figure 3: Recovered Community String Data

Another area of interest is logs, I have discovered that there are some devices that hold logs within the MIB tables. These logs can also contain failed logon attempts. Think about the last time you logged into a device via Telnet or SSH and inadvertently entered your password as the username. Sadly, I must admit, I do this quite often. That brings me back to the concept of devices storing logs in the SNMP MIB data. By examining the SNMP data, you could possibly find password information stored in MIB data from users who accidentally enter passwords in the wrong fields during authentication. To retrieve this log information, I typically search for key words such as fail, failed or login and examine that data to see if there is anything of value.

grep -i "fail" *.snmp

The following example (Figure 4) shows a snippet of logs from a SNMP MIB extraction showing a failed login attempt where the password was used for the username. The cool part is that the next log entry will most likely show a successful authentication for the true user name.

Figure 4: Failed Login

It is also important to note that these logs are usually short and they end up rolling over quickly, so make sure you get a copy before launching any brute force attacks against the device. If not, you may end up with SNMP MIB extraction data that looks like the logs in Figure 5:

Figure 5: Brute Force Overwriting of SNMP MIB Logs

In conclusion, I hope these few examples will give you some good ideas on how to extract and use SNMP data. Also, I think it is important to point out that by taking the time to better examine the data exposed by SNMP, we can better define the risk associated with poorly secured SNMP solution to our customers.