The hardest intrusions to catch are the ones that never look like intrusions. When an unwelcome party logs in with a real username and a real password, most of a defender’s instincts fire at the wrong moment or not at all. There is no malformed request, no malware signature, no broken lock. The authentication succeeds because it is supposed to succeed — the credential is genuine. The system does exactly what it was built to do and lets the holder in. This is the quiet power of the valid-accounts problem: legitimate credentials in the wrong hands turn your access controls into an usher rather than a guard.
That is why credential-driven access is both one of the most common ways in and one of the least visible. Breach research keeps finding that stolen, reused, or otherwise legitimate credentials feature in a large share of incidents, and the reason is structural, not accidental. A password that leaked from an unrelated service, a session token lifted from a device, or a login handed over during a convincing phishing call all produce the same thing: a valid identity that a defender cannot distinguish from the real person by the login alone. Detection has to come from somewhere other than “was the password correct.”
Why a correct login is the wrong place to look
Traditional detection leans on things that look wrong: an error, an anomaly in the protocol, a known-bad file. A valid-accounts intrusion offers none of that at the moment of entry. The authentication event is clean. This means the signal, if there is one, lives not in whether the login succeeded but in the context around it and the behavior after it. Did this account sign in from a place and device it has used before? Does what it did next match the person’s ordinary role and rhythm? A correct password answers none of those questions; only the surrounding evidence does.
There is a second complication that makes this category especially slippery. Once inside, an intruder using a legitimate account often has no need to deploy anything unusual. They can use the same built-in tools, the same file shares, and the same permissions the real employee uses every day. This is why the valid-accounts problem blends seamlessly into the harder problems of Lateral Movement Signals and Privilege Escalation Signals : the same trusted identity that got in can quietly reach further, and every step looks authorized because, in a technical sense, it is.
The four flavors of a legitimate credential gone wrong
It helps to distinguish where valid credentials come from, because the defenses differ. Reused personal passwords that leaked elsewhere are the classic case, and the countermeasure is unique credentials and a manager, argued in Password Managers and Credential Reuse . Credentials phished directly from a person are the second flavor, where phishing-resistant authentication changes the odds, as covered in MFA, Passkeys, and Recovery Paths . The third flavor is non-human credentials — the keys and tokens that service accounts and automation carry — which rarely get the same scrutiny as people yet often hold broad, standing access, a risk explored in Service Accounts and Secrets . The fourth is the account that should no longer exist at all: the departed employee or finished contractor whose login was never disabled, the subject of Identity Lifecycle and Offboarding .
Each flavor is a legitimate credential, and each defeats “is the password correct?” in the same way. But naming the flavor tells you which control was supposed to prevent it and which one to check first.
Toy example
Consider a fictional marketing agency, Beacon & Third, and an account belonging to an analyst named Marcus. On a Tuesday evening the identity logs show a successful sign-in to the company’s cloud workspace, multi-factor satisfied, from a device the account has not used before. So far this is unremarkable — people get new laptops. But the surrounding context adds texture: the login came from a region Marcus has never worked from, occurred at 2 a.m. local time for him, and was followed within minutes by the account granting itself access to a finance folder it had never opened and creating a rule to forward certain emails elsewhere.
No single one of these is proof. New devices, travel, and late nights all happen. But the pattern is what matters. The defender writes the observable facts first, then the benign story — Marcus traveled, got a new phone, and is doing unusual month-end work — and then the checks that separate the two. A direct message to Marcus asks whether he approved the multi-factor prompt and set up that forwarding rule. If he did not, the clean login is suddenly the strongest evidence of a valid-accounts intrusion, and the surrounding behavior is what elevated it. The correct password never lied; the context did the talking.
What evidence matters?
Because the login itself is clean, the evidence lives in three surrounding layers. The first is authentication context: the location, device, network, and time of the sign-in, and whether multi-factor was genuinely satisfied or fatigued into approval. Reading these patterns is the craft in Authentication Log Patterns . The second is behavioral fit: does what the account did after logging in match its normal role, or does it suddenly reach systems, data, or permissions outside its usual life? This depends entirely on knowing what normal looks like, which is why Known-Good Baselines is a prerequisite rather than a nicety. The third is change context: did the account modify its own security settings, create forwarding rules, add new access, or register new devices — the small administrative acts that a legitimate user rarely performs but an intruder often does.
Evidence is strongest when these layers agree and when they are timestamped, sourced, and comparable to history. One odd factor is a shrug; three that align into a coherent, out-of-character story are a signal worth acting on. The discipline is to hold the benign explanation open until the surrounding evidence closes it, rather than convicting a login for being unfamiliar.
Common mistakes and false positives
The defining mistake in this category is trusting authentication as if it were identity. A successful login proves that a valid credential was presented; it does not prove who presented it. Teams that stop at “the password was right, so it’s fine” are exactly the ones a valid-accounts intrusion is designed to slip past. The mirror-image mistake is treating every unfamiliar-but-legitimate login as an attack, which floods the team with noise and trains it to dismiss the alerts that matter. Neither extreme is a decision.
A subtler error is ignoring the non-human and dormant accounts. Service accounts and long-lived tokens often carry broad access and almost never trigger anyone’s suspicion, and a disabled-in-name-only account for a departed contractor is a legitimate credential nobody is watching. These are the valid accounts most likely to be abused precisely because no one thinks of them as accounts.
False positives are the daily weather here, and handling them cheaply is the skill. Travel produces new locations. Hardware refreshes produce new devices. Month-end, audits, and migrations produce genuinely unusual access by real people. Each resolves the same way: confirm with the human, compare against the baseline, and check whether the whole cluster of context tells a consistent, in-character story or a contradictory one. A false positive that ends in a confirmed baseline or a tightened alert has still strengthened the environment.
What to do next
Close the four flavors at their source. Push unique credentials and a manager through Password Managers and Credential Reuse , raise the identity gate with MFA, Passkeys, and Recovery Paths , bring non-human credentials under control with Service Accounts and Secrets , and retire stale access through Identity Lifecycle and Offboarding . Because a legitimate login is one of the most common footholds, read this alongside Initial Access Without Drama , and follow the trusted identity forward into Lateral Movement Signals and Privilege Escalation Signals .
For anything that looks like a live account takeover, resist the urge to simply reset the password and move on. Preserve the authentication and activity logs, follow your incident-response plan, communicate through approved channels, and involve qualified responders, since a valid-accounts intrusion often reaches further than the first account you noticed.
How this guide was made
This page is defensive education built from public frameworks including MITRE ATT&CK, NIST identity guidance, and widely published breach research, using invented people and toy data throughout. It makes no certification, legal, or incident-response-authority claims, and it deliberately avoids credential-theft detail so it stays useful for detection and defense rather than for harm.
Official references
For orientation, the MITRE ATT&CK Enterprise Matrix documents the valid-accounts technique together with the detection and mitigation notes that inform much of this guide. The CISA Known Exploited Vulnerabilities Catalog is a reminder that stolen credentials and unpatched access paths often work together, and the NIST Cybersecurity Framework 2.0 frames the identity and access safeguards that keep legitimate credentials from becoming a silent doorway.
Related guidebooks
Read this next to Initial Access Without Drama for the wider map, and alongside External Remote Services and Exploited Public-Facing Apps for the other doorways. Follow the trusted identity forward into Lateral Movement Signals and Privilege Escalation Signals .
