Harvesting Passwords From Cisco Configs Posted on Online Community Forums

Support forums like Cisco Community, Stack Exchange or Spiceworks have become invaluable resources for troubleshooting all sorts of network issues. However, from a cyber security perspective these platforms can be dangerous. While asking other users for help is a fundamental aspect of problem-solving in the tech community, it’s important to understand the potential dangers that lurk beneath the surface.

In this blog post, we’ll look at some of the risks that can arise when you share Cisco running configurations on public forums. We’ll see how the simple act of uploading a configuration to get assistance could lead to a serious security breach.

Sensitive Information Within the Configuration

The Cisco running configs basically contain a full list of all the settings that were set by default and any that were changed during the configuration of a network component, like a switch, router or WiFi controller. It gives a complete view of the configuration of a network device, which is really helpful in troubleshooting.

While some of the entries aren’t that sensitive, others are. Some of the more sensitive data in a Cisco configuration includes passwordhashes, keys, SNMP v1 community strings and certificates.

The passwords within a Cisco configuration can be encrypted with a variety of different algorithms. For this blog post, I’m going to focus on the weaker types of encryption, which are basically salted MD5 hashes. Even though Cisco and other groups like the CIS have advised against it, these are still being used a lot. This is either because the admins aren’t aware of the issue, or because the hardware doesn’t support more secure algorithms, like type 9.

For more information on the different types of encryption and the underlying algorithms, see here.

Harvesting the Password Hashes

There are lots of places you can look for running configurations that contain password hashes. The obvious place to start your online search is the Cisco support forum on community.cisco.com.

Searching for config files hosted on community.cisco.com

Another popular choice to ask for cisco specific help (and to collect running configs) is Spiceworks.com. A quick Google search turns up several results:

Searching for config files hosted on community.cisco.com

Here’s what a typical running config looks like. We’re looking for the lines that say “secret 5” with the actual hash prefixed by “$1$”. The config posted on Spiceworks shows that an enable password had been set on this switch.

Building configuration...

Current configuration : 5175 bytes
version 12.2
no service pad
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
hostname OxfordMainSwitch
enable secret 5 $1$0.Jj$X9M9ADVNFs.KhM6anK9ZQ1
no aaa new-model
ip subnet-zero
ip routing
ip name-server

OK, let’s get on with it. We have our Google searches and know where to look in the configuration files, so we can start scaling up and getting those passwords.

We can easily get all the configs we need by using metagoofil (a handy Linux tool for downloading files indexed through Google). This tool lets us specify a domain (the -d parameter), and the file type (the -t parameter). All the results will be saved to the folder you specify with the -o parameter.

I have used proxy chains to tunnel the traffic through a network of rotating residential proxies to avoid triggering the bot detection.

proxychains4 metagoofil -d community.cisco.com -t txt -l 1000 -n 1000 -o configs_cisco_community -w

For Spiceworks this could be done in a similar fashion. Note, how the domain (parameter -d) has changed. Unfortunately, metagoofil does not allow us to filter for Cisco specificially, which results in a broad range of text files downloaded.

proxychains metagoofil -d spiceworks.com -t txt -l 1000 -n 1000 -o configs_spiceworks -w

After the search has finished, all config files have been downloaded to the config directory. Downloading the config files using metagoofil The list of downloaded config files

The last step to do is to extract the password hashes from the config files, combine them in a single file and do some manual clean up.

cat *.txt | grep -w "secret 5 \$1" | cut -d' ' -f7 > hashes.txt

The final hashes.txt looks as follows. Please note that I have done some further manual clean up, as certain entries were invalid.

Cleaned up password hashes

Cracking the Password Hashes using John

Cracking the password hashes using John is straightforward. I’ll simply provide an extensive password list, such as rockyou.txt and the file containing the hashes.

john --wordlist=/usr/share/wordlists/rockyou.txt hashes.txt

The time it takes to finish the calculation of password hashes greatly depends on the number of hashes and the hardware used. Once done, the passwords will be shown like this:

Cracking the password hashes using John

Sweet, for 4 of the hashes John had been able to recover the passwords. These plaintext passwords could potentially be used for authenticating locally or remotely.


In this post, we’ve been looking for device configurations of Cisco network components that are indexed on Google by searching several domains for uploads as text files. We then extracted the password hashes and cracked them using John. In the end, we were left with various plaintext passwords that could potentially give an attacker a foothold on the device if either the local network exists or the device is otherwise exposed to the internet. This might be the case for firewalls or routers. Are you wondering what you can do to avoid breaching any sensitive data on public support forums? I have a few simple recommendations:

  • Don’t share running configs online, rather generate a tech support config by executing show tech-support. This command redacts sensitive information automatically.
  • Another lesson that can be learned from my experiment is that it’s absolutely crucial to choose strong and random passwords. Strong passwords make it more difficult for hackers to crack them, so they’re less likely to be able to get into your account.
  • Use strong encryption. The Cisco Type 5 as well as the insecure Type 7 hashing algorithms are no longer secure. If you can, upgrade to the more secure Type 9.

These recommendations are in line with the best practices for hardening network devices. If you want to learn more about how to further harden your Cisco devices, I’d like to point you towards the CIS Benchmark. Let me know if you’ve used similar techniques during an engagement before or if you’re planning on incorporating it in the future.