ISR07: Insecure Authentication Methods and Default Credentials

How ISR07: Insecure Authentication Methods and Default Credentials works

Insecure authentication is where an internal system accepts a weak, guessable or vendor-set secret as sufficient proof of identity. It lives at every login prompt an operator forgets is a login prompt: the web console on a printer, switch or UPS, the out-of-band card on a server, the domain accounts behind SMB, LDAP and RDP, and the VPN or webmail portal that fronts the estate. None of these is application code, so the strength of the secret is the whole of the control.

It survives because a working login looks the same whether the secret is strong or shipped from the factory. Appliance consoles sit outside the patch cycle and the directory, so no policy ever rewrites their password; a seasonal password passes complexity rules while being trivially guessable; and a portal marked “MFA enabled” in one dashboard still answers a password-only legacy flow. After initial access any one of these yields a valid credential with no exploit, which is why it feeds directly into lateral movement. The three chapters below each take one surface: Default Credentials On Devices And Appliances covers the vendor-set logins on hardware, Password Spraying Internal Services covers one guessable password tried across the account base, and Missing MFA On Remote Access covers the paths a single stolen password still opens.

Keywords: default credentials, password spraying, account lockout policy, mfa bypass, single factor remote access, bmc default login

Examples/Proof

• Fingerprinted default-pair check
  • Fingerprint an appliance by its service banner, then try only its documented default pair once. An authenticated session with no wordlist used is the finding.
• Effective-policy read before a spray
  • Pull the lockout threshold and observation window from the domain before any attempt. That number sets how many accounts one password can safely touch.
• Low-and-slow horizontal spray
  • Send one seasonal password to every account once per observation window. A single success means a valid domain credential with no account locked out.
• Second-factor enforcement gap
  • Log in to each remote path with a password-only test account. Any path that returns a session without demanding a second factor is single factor.

Detection and Monitoring

• Horizontal failure breadth
  • On the domain controller Security log, count distinct target user names per source in a short window; many accounts failing from one source is a spray, not typos.
• Default-credential console logins
  • On appliance and BMC logs, alert on a successful login as the built-in account (admin, root, ADMIN) from any address outside the management jump path.
• Authentication without a second factor
  • On the identity platform sign-in log, alert on any interactive success via legacy or basic authentication, or from an account excluded from the MFA policy.

How to fix and prevent ISR07: Insecure Authentication Methods and Default Credentials

1. Inventory every authentication surface first
   • List each device, service and portal that accepts a login and the account type behind it. Controls you cannot see you cannot fix.
2. Remove vendor defaults at enrolment
   • Change the shipped credential before a device joins the network, recorded against the asset register. Appliance consoles rarely sit in any patch or policy cycle, so nothing else will catch them.
3. Enforce MFA on all remote and administrative access
   • A second factor neutralises a sprayed, phished or reused password. Partial control: it protects only the paths that actually enforce it, so the gap is the carve-out.
4. Make credentials spray-resistant and verify the lockout policy
   • Ban seasonal and company-derived passwords with a filter, and confirm the effective threshold and window - including any fine-grained policy - actually apply. The AD-side plumbing belongs to the domain password policy page.
5. Monitor for the patterns each attack leaves
   • Breadth-based failure alerting for spraying, built-in-account success alerting for defaults, and legacy-auth success alerting for MFA gaps.

Prevention Checklist

• No device or appliance on the network still answers to a documented vendor default pair
• Every remote and administrative access path enforces a second factor, with no standing exclusion
• The effective account lockout policy is known, tested, and applies to every domain account including PSO-scoped ones
• Horizontal authentication failures across many accounts from one source raise an alert

Last updated 2026-08-24