Ask a room of security testers for the most common way into a home router and most will give the same answer: the password it left the factory with. routersploit has a whole family of modules, the creds modules, built to test exactly that weakness. You point one at a service on your own router, and it works through a built-in list of default usernames and passwords, reporting any pair the router accepts. This guide explains how creds modules work, how to run one properly, and what a successful hit is trying to teach you.
Why default credentials refuse to die
Routers ship with known logins so owners can set them up, and those logins are published in manuals and support pages for anyone to read. The setup wizard begs you to change them, and a surprising share of people never do, or change the Wi-Fi password and leave the admin password alone. Years later the router still answers to its factory credentials, on the admin page and often on other services too.
That is the entire reason creds modules exist, and why they are usually the highest-value test you can run on your own hardware. Before you worry about exotic exploits, you check the front door. A creds run takes minutes and settles the question with evidence instead of assumptions.
The creds modules, service by service
List the family with show creds. Each module targets one service, because each service asks for credentials in its own way:
- HTTP basic auth covers routers whose admin interface answers with a login prompt.
- HTTP web forms covers routers whose login is a form on a page, which the module fills in and submits.
- FTP tests the file service some routers expose.
- SSH and Telnet test the remote access services, one modern and encrypted, one an old plaintext leftover.
- SNMP tests the management protocol, which uses community strings that work much like passwords and are famous for staying at their defaults.
Every module carries built-in lists of default router usernames and passwords gathered from real devices, so you do not supply the guesses yourself. Your job is choosing the right module for the service you want to test and aiming it correctly.
Pick the right module for your router
Start from the service, not from habit. If you log into your router through a browser, you want one of the HTTP modules, and a look at the login screen tells you which kind: a browser pop-up prompt means basic auth, while a login page with fields means the web form module. If you have deliberately enabled SSH on your lab router, the SSH module is your test. Telnet and FTP modules matter most on older hardware, where those services were often left running by default.
Load your pick with use followed by its path under the creds tree, then read it. show info confirms what the module tests, and show options shows the settings you must fill in.
Set the target, port, and threads
Three options shape a creds run. The target is your router’s address:
set target 192.168.1.1
The port is where the service listens. Web interfaces usually sit on the standard web port, while SSH and Telnet have their own usual ports, and the module’s defaults reflect that. If your router’s admin page lives on a custom port, set it with set port so the module knocks on the right door.
The third option is threads, which controls how many login attempts the module runs at the same time. More threads finish the list faster, and the temptation is to crank the number up. Resist it on real hardware. A home router is a small computer, and hammering it with parallel login attempts can overwhelm it or make it sluggish for everyone connected to it. A moderate thread count finishes a default list quickly enough and keeps your test device healthy.
Run it and read the result
Start the module with run. It works through its credential list against your router’s service, and the console shows its progress. Two outcomes are possible. The run may finish with nothing found, which means your router rejected every default and common pair on the list, the result you want on any device you care about. Or the module reports a working username and password pair, printed plainly for you to see.
If you get a hit on a lab router you reset for practice, congratulations, the lesson worked: that is the exact pair anyone could have used. If you ever get a hit on a router that guards a real network, treat it as urgent housekeeping rather than a trophy. Log in with those credentials yourself and change the admin password on the spot, then check which other services are exposed while you are in the settings.
A note on scope
One factual point, stated the way the project states it: routersploit is meant for devices you own or have permission to test. Creds modules make that boundary easy to respect, because the honest use case is sitting right in front of you: your router, your lab, your password hygiene. Testing your own gear tells you everything you need to know about how this attack works and how completely a changed password defeats it.
What a clean run does and does not prove
A creds module that finds nothing has tested your router against its built-in list, which is broad but finite. A determined person could still guess a weak custom password you chose yourself, something like a pet’s name, which no default list would contain. The module’s clean result proves the factory door is shut. Choosing a strong, unique admin password of your own is what keeps the whole wall solid, and the defensive guide below turns these test results into a full hardening checklist.
Test the other services while you are at it
A changed admin password on the web interface is the headline fix, and it is not always the whole story. Routers can expose several services at once, and each one keeps its own credentials. An owner who sets a strong password on the admin page may never learn that the same box still answers Telnet with a factory login, because nothing in the web settings mentions it.
That is why a thorough self-test runs the creds family as a set. After the HTTP module comes back clean, run the modules for any other services your router has enabled, FTP, SSH, Telnet, SNMP, each aimed at its own port. The routine is identical every time, which makes a full sweep a fifteen-minute job. What you are really building is a map of every door the router presents, with evidence about which ones are locked. That map, more than any single run, is what a creds session should leave behind.
Conclusion
Creds modules are routersploit’s simplest idea and its most practical one. Pick the module that matches your router’s service, HTTP, FTP, SSH, Telnet, or SNMP, set the target and port, keep the threads sensible, and run it. The module tries the default and common credentials your router may still accept and reports any that work. Run them against your own hardware and you will know, rather than hope, that the oldest trick in router security no longer works on yours.
Read next:
Pingback: Secure Your Router: Lessons from routersploit