Default Credentials

How attackers find and exploit it

• Enumerate internet-facing hosts and services using mass scanners and search engines (Shodan, Censys, masscan), filtering for management ports and product banners that reveal a specific make and model.
• Fingerprint the exact device or application from HTTP titles, login page markup, SSH/Telnet banners, favicon hashes, and TLS certificate fields to determine which vendor defaults apply.
• Look up the published default username and password for that product in vendor manuals, support pages, and curated default-credential databases such as the SecLists and DefaultCreds collections.
• Attempt the default pair against the exposed login, often automated across many hosts at once because the same credential works on every unconfigured unit of the product.
• On success, authenticate as administrator, then change configuration, add accounts, dump credential stores, or upload firmware/web shells to establish persistence.
• Pivot from the compromised device into the internal network or chain the access into a larger campaign, for example loading DDoS bot code as Mirai did or staging ransomware deployment.

How to detect it on your surface

• Inventory every internet-reachable asset that presents a login: routers, firewalls, cameras, DVRs, printers, IPMI/BMC interfaces, databases, and web admin consoles.
• Cross-reference each asset's make, model, and software version against a maintained list of vendor default credentials for that product family.
• Attempt an authenticated login with the known default(s) in an authorized, controlled test against each identified asset, recording which accept the default.
• Check for default accounts that remain enabled even when a new admin password exists, such as guest, service, or vendor backdoor accounts that ship active.
• Review provisioning and onboarding records to confirm a forced password change actually occurred for each device, rather than assuming it did.

Detection signals

• Login succeeds with a documented factory pair (e.g., admin/admin, root/root, admin/password) or with an empty password.
• HTTP login pages, SSH/Telnet banners, or HTTP titles that identify a specific vendor and model whose defaults are publicly known.
• Telnet (port 23) open and reachable on a consumer-grade device, frequently indicating unmanaged firmware that still trusts hard-coded credentials.
• Web UI that loads a setup wizard, a 'change your password' prompt, or a 'default password in use' warning banner, signalling provisioning was never completed.
• Management interfaces (IPMI/BMC, switch web UI, database admin port) exposed externally where vendor superuser accounts are enabled by default.

Validate before you report

• Confirm the asset is genuinely owned by your organization and in scope before any credential test, then perform the login attempt from an authorized source.
• Authenticate with the matched default credential and capture evidence of the access level granted (admin dashboard screenshot, account list, version string) rather than just a 200 response.
• Verify the session yields real privilege, for example the ability to read configuration or list users, distinguishing a working default from a decoy or read-only landing page.
• Record the exact credential pair, the endpoint, timestamp, and source, so the finding is reproducible and the remediation owner can confirm the fix.
• Re-test after remediation to prove the default no longer authenticates and that no shadow default account remains enabled.

What looks like this but isn't

• A login page that displays a default-credentials hint but rejects them indicates the operator already rotated the password; this is hardened, not vulnerable.
• Honeypots and deception assets are designed to accept default logins to lure attackers; confirm the host is a real production asset before flagging.
• Some appliances show a generic 'admin' welcome page pre-authentication that does not grant privilege; verify that the default actually authenticates an administrative session, not just renders a public page.

Remediation

• Immediately change every default credential to a unique, strong, randomly generated value and store it in a secrets manager or password vault.
• Disable or delete unused default and vendor accounts entirely rather than only changing their passwords, removing dormant backdoors.
• Restrict management interfaces so they are not reachable from the public internet; place them behind a VPN, bastion host, or IP allowlist.
• Enforce a mandatory password change at first login and, where supported, phishing-resistant multifactor authentication on all administrative access.
• When procuring equipment, prefer vendors that follow CISA Secure by Design practices such as unique per-device setup passwords or time-limited setup credentials.
• Establish a recurring authenticated scan that re-tests for default and weak credentials across the asset inventory and feeds results into ticketing.

Operational checklist

• Maintain a live inventory of all externally reachable login surfaces with make, model, and version recorded.
• Run scheduled default- and weak-credential checks against that inventory and alert on any new positive.
• Require, as a documented build/onboarding gate, that every device has its defaults rotated before it goes live.
• Keep management planes off the public internet by default and review exceptions quarterly.
• Enforce MFA and least-privilege on all admin accounts, and rotate shared service credentials on a fixed schedule.
• Track vendor security advisories for hard-coded or undocumented default accounts and patch or mitigate promptly.

FAQs.

Weakness references (CWE)

• CWE-1392 · Use of Default Credentials
• CWE-798 · Use of Hard-coded Credentials
• CWE-1391 · Use of Weak Credentials