Credential and Password Attacks
Key Takeaways
- Credential attacks target authentication secrets, stored hashes, session tokens, identity providers, and user behavior rather than network capacity.
- Brute force tries many passwords against one account; password spraying tries a few common passwords across many accounts to dodge lockout thresholds.
- Credential stuffing replays valid username/password pairs harvested from an unrelated breach, so logins succeed from unusual sources.
- Phishing, smishing, vishing, and MFA-fatigue/push-bombing attack the human, bypassing the strength of the stored password.
- Mitigations include phishing-resistant MFA, salted adaptive hashing, lockout and rate limiting, conditional access, password managers, and credential rotation.
Distinguishing the Pattern
Authentication attacks look similar in raw logs, so the exam expects you to read the failure distribution and pick a mitigation that fits. The deciding question is usually "are many guesses hitting one account, or a few guesses spread across many accounts, or are valid credentials succeeding from a strange place?"
| Attack | Pattern | Best clue | Useful mitigations |
|---|---|---|---|
| Brute force | Many guesses against one account or service | High failed-attempt count for a single username | Account lockout, rate limiting, MFA, block source IP |
| Password spraying | One or few common passwords across many users | Low failures per user, many usernames affected | Detect horizontal failures, MFA, banned-password list |
| Credential stuffing | Reused breached username/password pairs | Successful logins from residential proxies or odd geos | MFA, breached-password checks, anomaly/risk scoring |
| Dictionary attack | Wordlist plus mutations | Common words and leetspeak variants | Strong policy, password manager, blocklists |
| Rainbow table | Precomputed unsalted-hash lookup | Stolen unsalted hashes cracked instantly | Per-password salt, slow adaptive hashing |
| Phishing | Deceptive message or cloned site | User reports a link, fake login page captured | Awareness, mail filtering, FIDO2/passkeys |
| MFA fatigue / push bombing | Repeated push prompts until approval | Many denied or ignored MFA pushes | Number matching, push rate limits, phishing-resistant MFA |
| Shoulder surfing | Observing secrets physically | Public area, visible screen or keypad | Privacy filters, clean-desk policy, training |
Worked Log Example
| Event | Users | Failure pattern | Likely attack |
|---|---|---|---|
| 1,900 failed logins for "admin" in 4 minutes | 1 | Many guesses, one account | Brute force |
| 450 users each fail once with "Spring2026!" | 450 | One password, many accounts | Password spraying |
| 17 successful logins from residential proxies using real employee emails | 17 | Valid pairs, unusual source | Credential stuffing |
The mitigation must match the attack. An aggressive account lockout slows brute force but is a poor answer to spraying - it can lock out 450 real users and become a self-inflicted denial of service. When valid credentials succeed from a suspicious context (stuffing), the strongest answers are MFA and risk-based conditional access, because they break the value of a stolen password.
Credential Storage and Cracking
Hashing stores a one-way digest; a salt is a unique random value added before hashing so identical passwords produce different hashes, defeating rainbow tables. Key stretching (bcrypt, scrypt, PBKDF2, Argon2) deliberately slows hashing to make offline cracking expensive.
| Weakness | Why it matters | Better control |
|---|---|---|
| Plaintext passwords | Immediate disclosure if the database is stolen | Never store plaintext |
| Fast unsalted hash (MD5, SHA-1) | Trivial offline cracking and reuse lookup | Salted adaptive hashing (Argon2/bcrypt) |
| Shared admin password | One compromise affects many systems | Unique privileged credentials or PAM vaulting |
| Hardcoded secret in code | Leaks with the repo or container image | Secrets manager and rotation |
| Long-lived bearer token | A stolen token stays useful for weeks | Short lifetime, scope limits, revocation |
Social Engineering Forms
| Form | Channel | Note |
|---|---|---|
| Phishing | Email / web | Broad, untargeted |
| Smishing | SMS text | Mobile-focused |
| Vishing | Voice call | Often impersonates IT or a bank |
| Spear phishing | Targeted email | Tailored to a specific person |
| Whaling | Targeted email | Aimed at senior executives |
| Pretexting | Any | Invented backstory to build trust |
Common Traps
| Trap | Correct reasoning |
|---|---|
| Treat every login-failure spike as brute force | Check whether failures concentrate on one account or spread across many |
| Rotate only the visible user's password after malware | Tokens, browser sessions, API keys, and service accounts may also be exposed |
| Rely on SMS MFA for high-risk admin access | SIM-swap and SS7 attacks make SMS weak; prefer FIDO2/number matching |
| Store recovery codes in the mailbox they protect | Protect recovery material separately and offline |
Token, Session, and Identity-Provider Abuse
Modern credential attacks increasingly skip the password entirely and target the session. After a user authenticates, the system issues a token or cookie; stealing that artifact lets an attacker ride the session without ever knowing the password - and without tripping MFA, because MFA already happened at login.
| Abuse | How it works | Mitigation |
|---|---|---|
| Session hijacking | Stolen session cookie reused by attacker | Bind sessions to context, rotate on privilege change, HttpOnly/Secure cookies |
| Pass-the-hash | Reuse an NTLM hash without cracking it | Credential Guard, restrict admin reuse, unique local admin passwords |
| Pass-the-ticket / Golden Ticket | Forge or replay Kerberos tickets | Protect the KRBTGT account, limit Domain Admin exposure |
| OAuth/token theft | Steal a bearer token from storage or logs | Short token lifetime, scope limits, revocation on anomaly |
| Directory traversal of secrets | Read a secrets file via app flaw | Secrets manager, least privilege, path validation |
The exam lesson: after a credential compromise, resetting the visible password is necessary but not sufficient - active sessions, refresh tokens, API keys, and service-account secrets must also be revoked and rotated, or the attacker simply keeps the session they already hold.
Quick Drill
(1) One executive gets a fake DocuSign email to a cloned login page - spear phishing; filter, train, and require phishing-resistant MFA. (2) Hundreds of accounts each fail once with "Password1!" - password spraying; detect horizontal attempts and enforce MFA. (3) A leaked database of unsalted MD5 hashes - rainbow-table/offline cracking risk; migrate to salted adaptive hashing and force resets. (4) An attacker reuses a stolen session cookie and bypasses MFA - session hijacking; rotate and bind sessions, then revoke the token.
A log shows the password "Welcome2026!" attempted once against hundreds of usernames, with only one failure per account. What attack is most likely?
Attackers reuse valid employee email-and-password pairs harvested from a previous unrelated breach to log into a company portal. What is this called?
Which controls best reduce credential-stuffing risk? Select two.
Select all that apply