A credential based attack gets in by using a real username and password, or another login secret, instead of exploiting software. The login might be phished, guessed, reused from another breach or lifted from code. Because the activity looks like a normal sign in, defense rests on multi factor authentication, breach screening and good account hygiene.
How do attackers get credentials?
There are four common routes.
Phishing. A convincing page or message tricks a person into typing a password or approving a prompt.
Guessing. Brute force tries many passwords against an account. The attacker needs no prior knowledge but pays in volume.
Credential stuffing. OWASP defines this as automated use of stolen username and password pairs to log in to websites. Because many people reuse passwords, a breach at one service opens accounts at others. OWASP calls it a subset of brute force and names multi factor authentication as a primary countermeasure.
Exposed secrets. Keys and tokens left in code repositories, build logs or public cloud storage. MITRE lists keeping credentials out of code and repositories among its mitigations.
Why is it hard to spot?
MITRE ATT&CK catalogues this as technique T1078, Valid Accounts. Its description says adversaries use legitimate credentials for initial access, persistence, privilege escalation and defense evasion, and that the activity can be hard to tell from normal use. It also notes attackers may target inactive accounts, since nobody notices if an old account is used.
There is no malicious file for antivirus to find and no exploit for a firewall to block. The signal lives in identity logs: an unusual location, an impossible travel pattern, a first ever use of an administrative role.
Constructed example: the contractor account
A company ends a contract but forgets to disable the contractor's cloud account. The contractor's personal email password was exposed in an unrelated breach months earlier, and it was reused here. An attacker tries the pair, signs in, and finds the account still holds read access to a storage bucket. No alert fires, because the sign in used a valid password. Three controls would each have broken the chain: multi factor authentication, a leaver checklist that disables accounts, and a rule alerting on sign ins from new countries.
What does current guidance say about passwords?
NIST SP 800-63B, the digital identity guideline, is direct. It requires verifiers to screen new passwords against known breached and commonly used values. It says composition rules, such as forced mixes of character types, must not be imposed, and that periodic password changes are not required unless there is evidence of compromise. It sets a minimum of 15 characters for passwords used alone and 8 when used inside multi factor authentication, and requires rate limiting of failed attempts. It also notes that passwords are not phishing resistant, and that phishing resistant authenticators such as WebAuthn are required at its highest assurance level.
In plain terms: longer, screened, unique and backed by a second factor beats frequent forced changes.
What about machine credentials?
Service accounts, API keys and tokens are credentials too, and they often never expire and carry broad rights. Scan repositories and build output for secrets, rotate anything exposed and issue short lived credentials where the platform allows it. Safeguard includes secrets scanning among its checks, which is one way to catch keys before they leave a developer's machine.
How to check or apply this
- Turn on multi factor authentication for every account type, starting with email, remote access and administrators.
- Prefer phishing resistant methods for privileged users.
- Screen new passwords against a breached password list and drop forced rotation.
- Rate limit and monitor failed sign ins.
- Audit accounts quarterly and disable the unused ones, including leavers and default accounts.
- Scan code and pipelines for secrets and rotate any found.
- Alert on new locations, new devices and first time admin actions.
Quick check
Is credential stuffing the same as brute force?
It is a subset. Brute force guesses passwords. Credential stuffing replays username and password pairs already stolen from other sites.
Does changing passwords every 90 days stop these attacks?
NIST guidance says periodic changes are not required without evidence of compromise. Unique passwords, breach screening and multi factor authentication help more.
Sources
- MITRE ATT&CK, Valid Accounts (T1078)
- OWASP, Credential stuffing
- NIST SP 800-63B, Digital Identity Guidelines: Authentication
Last reviewed: 18 October 2026.
