A Successful Login Is Not Evidence of a Legitimate User

“Every session in those logs authenticated successfully, so that activity is our users.”

Let me stop you there, before the incident timeline gets a column headed “legitimate.”

A successful login is not evidence of a legitimate user.

A successful login is evidence that an accepted credential was presented.

That is all it is.

It doesn’t say who was holding the credential.

It doesn’t say why.

And for an attacker who has a real credential, the login is not the risky part of the operation. It is the safest part. It is the one moment in the whole intrusion where they look exactly like the person whose account it is.

You would never say “the car started, so the driver must own it.”

Keys are keys.

MITRE files the technique as Valid Accounts, T1078, and it maps it to four tactics at once: Initial Access, Persistence, Privilege Escalation, and Stealth, the tactic formerly called Defense Evasion.

Four jobs, one credential.

It gets the attacker in.

It keeps working after a reboot, with no further attacker action.

It carries whatever rights the account already had.

And it evades detection built to flag suspicious tooling, because the login itself looks completely ordinary.

That last property is the whole problem.

A log that says “authenticated” is the attacker’s alibi, not your evidence.

1. “But the Account Passed MFA.”

Good.

MFA passed.

Now say precisely what that proves: the second factor was presented.

It doesn’t prove the second factor was in the right hands.

Take SMS codes. NIST SP 800-63B classifies out-of-band verification over the public telephone network as RESTRICTED. It tells verifiers to weigh risk indicators, “device swap, SIM change, number porting, or other abnormal behavior”, before using it at all, and it treats a change of number as binding an entirely new authenticator.

That restriction exists because the attack is ordinary.

Once an attacker ports your user’s number, the SMS codes route to the attacker’s SIM.

The login then passes MFA.

Correctly.

The factor was presented.

The FBI’s Internet Crime Complaint Center recorded 1,600 SIM-swap complaints in 2021, more than a 400% increase from 2018, and $68 million in reported losses that year alone, against $12 million across 2018 to 2020 combined.

So “passed MFA” tells you which checks the session cleared.

It doesn’t tell you whose phone cleared them.

Session theft after sign-in is a different attack again, and it’s covered in Authentication Does Not Authorize Anything. This piece stays with the credential.

MFA answers “was the factor presented?” It does not answer “is this the person?”

2. “But MFA Blocks 99.9% of Account Attacks.”

That’s Microsoft’s figure, from a 2019 Microsoft Security blog post: MFA “can block over 99.9 percent of account compromise attacks.”

Read what it measures.

It describes automated, credential-based attacks. Password spraying. Credential stuffing. Brute force against a login form.

The attacker in your logs is not a spraying script that bounced off a prompt. It is someone the prompt let through.

And the post does not publish its dataset or its definition of “attack” in detail. It references a SANS Institute white paper and stops there.

The number is real, widely repeated, and thin on method.

Cite it as Microsoft’s claim about that attack class.

Now put it next to breach data.

Verizon’s 2025 Data Breach Investigations Report analysed 22,052 security incidents and 12,195 confirmed breaches across 139 countries. Among non-error, non-misuse breaches with a known initial-access vector, n=9,891, credential abuse was the most common way in, at 22%. Vulnerability exploitation followed at 20%. Phishing at 16%.

Do the arithmetic yourself: 22% of 9,891 is about 2,176 breaches. The percentage is rounded, so treat that as approximate.

Those are breaches that started with a valid login.

A 99.9% block rate against automated guessing and a leading breach vector made of working credentials are not in conflict.

They are measuring different attackers.

One of them fails at the login.

The other succeeds there.

Name the edition when you cite the ranking. Verizon’s 2026 DBIR put vulnerability exploitation first, at 31% of breaches, with phishing, credential abuse and pretexting together at roughly 32%. The ranking moves year to year.

The logon that looks ordinary doesn’t.

3. “But Nobody Else Knows the Administrator’s Password.”

They don’t need to.

Pass the Hash, T1550.002, authenticates as a user by presenting a captured NTLM password hash directly to a remote system.

The mechanism is a property of NTLM itself. Its challenge-response exchange only ever needs the hash, never the plaintext.

So nobody recovers the password.

Nobody cracks anything.

An attacker who dumps hashes from one compromised host’s memory, commonly with credential-access tooling like Mimikatz, in circulation since 2011, can reuse them against every other host that accepts the same domain credential.

A related variant, overpass the hash, converts a captured NTLM hash into a valid Kerberos ticket, which extends the same material from NTLM targets to Kerberos-authenticated ones.

“Stealing the password” is the wrong description. No password is ever recovered or needed.

And every one of those remote logons succeeds.

Your authentication log records the administrator.

Knowing the password and holding the credential are different things.

The good news is that this technique’s detection signal is specific, not generic:

• an NTLM authentication event,
• with LogonType 3, a network logon,
• with no corresponding Kerberos ticket request at the domain controller,
• arriving from a host the account does not normally log into.

Look at what that signal is built from.

Not “did authentication succeed?”

It did.

It is built from how the credential was used, and where from.

4. “But PsExec and RDP Are Our Own Administration Tools.”

Yes.

That’s the point.

PsExec is a free Microsoft Sysinternals tool for running a program on another machine. It is in every IT department’s toolkit.

MITRE’s software catalog tracks it as abused by more than 40 adversary groups, for lateral movement, remote command execution and privilege escalation. Ransomware operators such as BlackByte and Medusa. Nation-state groups such as APT29.

Nothing in the binary distinguishes an administrator’s session from an attacker’s.

Same tool.

Same command.

The difference lives entirely in context: whose credentials, what target, what payload, and whether change management approved it.

The tool records none of that for you.

Remote Desktop Protocol, T1021.001, is the same pattern one layer up. Every Windows shop depends on it, and abusing it for lateral movement requires nothing beyond valid credentials.

Which is why detection guidance for RDP abuse doesn’t focus on the logon.

It focuses on what happens after a legitimate-looking logon: unusual process execution or file access in the following minutes.

Block RDP outright and you break the business.

Trust every RDP session equally and you miss the attack.

Neither of those is a strategy.

The category doesn’t resolve at the tool, and it doesn’t resolve at the logon.

It resolves in the session.

5. “But We Reset the Password as Soon as the Phishing Was Reported.”

Good.

You addressed one of four jobs.

Valid Accounts gets the attacker in, keeps them in, carries privilege, and hides them in ordinary logons. A password reset addresses entry.

An organization that revokes a credential after spotting unauthorized initial access can still be re-entered through that credential’s persistence and privilege-escalation properties, if the initial-access angle was the only one handled.

Look at what an attacker with a working session can leave behind.

A scheduled task, T1053.005, registered through schtasks, the GUI, WMI or PowerShell, runs code at boot, at a fixed time, or on an interval. MITRE tags it to Persistence, Execution, and Privilege Escalation when the task runs as SYSTEM.

The task that survives the reboot is also the thing that runs the payload, and, configured as SYSTEM, the thing that elevates it.

Changing a user’s password does not unregister it.

A scheduled task can also be hidden from the standard enumeration GUI, so “we looked in Task Scheduler” is not a clean bill.

A registry run key, T1547.001, writes a value under one of four standard locations, HKCU\...\Run, HKCU\...\RunOnce, HKLM\...\Run or HKLM\...\RunOnce, or drops a shortcut in a startup folder. The operating system itself then launches the payload at the next logon.

No attacker code needed to trigger it again.

Run keys are visible to any registry viewer. They are also one of thousands of legitimate entries most environments never audit.

Volume, not concealment, is the cover.

Then there are the hashes. If credentials were dumped from a compromised host’s memory, the phished user’s reset says nothing about the hashes that were taken.

A password reset is a credential action. Persistence and privilege are not credentials.

6. “But Alerting on Every Administrative Logon Would Drown the SOC.”

It would.

So don’t.

Alerting on the logon is alerting on the one event the attacker has already made look normal.

That’s the worst possible place to spend analyst attention.

Alert on what the account does next, with signals narrow enough to mean something:

• An NTLM network logon, LogonType 3, with no matching Kerberos ticket request, from a host the account does not normally use. Each part is ordinary. The combination is not.
• A PsExec or RDP session with no matching change record. The tool is legitimate. The unapproved use of it is a finding.
• Unusual process execution or file access in the minutes after an RDP logon. That’s where RDP detection guidance already points.
• A new scheduled task or run key created under an account shortly after an unusual logon. Registration is where persistence becomes an artifact.

None of those fires on “an administrator logged in.”

All of them fire on “an administrator’s credential did something its owner doesn’t do.”

That needs a baseline.

Which hosts does this account touch?

Which tools does it run?

When?

Without a baseline of normal use, “legitimate-looking” is the only category you have, and the attacker lives in it.

7. No, This Does Not Mean MFA Is Wasted.

It isn’t.

Credential abuse was the leading known way into a breach in Verizon’s 2025 DBIR.

MFA shuts out the automated end of that problem: spraying, stuffing, brute force.

Stronger factors raise the attacker’s cost against the rest of it.

SMS codes are a real improvement over no second factor. They are also the weakest tier that still qualifies as MFA, and NIST treats them accordingly.

Keep all of it.

Nothing here argues for a weaker login.

It argues against reading a login as a verdict.

The authentication event proves a credential was presented. Compromise shows in the behaviour that follows.

Those are both true.

Only the second one catches the attacker who got the first one right.

8. What You Should Actually Do

Log and baseline what authenticated accounts do in the minutes after logon. Process execution. File access. Remote-administration tool use. Per account, per host.

Alert on NTLM network logons without a matching Kerberos ticket request, from hosts the account does not normally use. It’s a narrow query. It depends on collecting both the logon events and the domain controller’s ticket requests.

Tie PsExec and RDP sessions to change-management approval. An administrative session with no change record is a finding, even when every credential in it is valid.

When a credential is found compromised, remove its persistence and privilege, not only its password. Enumerate scheduled tasks and run keys it could have registered. Don’t trust the standard Task Scheduler view alone. If hashes were dumped on a host it reached, remember they work against every other host that accepts the same domain credential.

Check your corporate domains against credential-dump exposure. Verizon’s 2025 DBIR correlated infostealer dumps with domains later disclosed by ransomware actors: 54% of ransomware victim domains had already appeared in credential-dump data, and 40% of those had corporate email addresses among the compromised credentials. Of compromised systems carrying corporate logins, 46% were non-managed devices holding personal and business credentials together.

Your users’ credentials may already be for sale before anyone logs in with them.

Report MFA effectiveness against the attack class it actually measures. “Blocked automated credential attacks” is a real result. “Prevented account compromise” is a different claim, and your 99.9% slide doesn’t support it.

9. The Actual Model Is Not Complicated.

Authentication proves an accepted credential was presented.

A stolen credential is an accepted credential.

A hash that NTLM accepts is an accepted credential.

A factor delivered to a ported number is an accepted factor.

A PsExec session run with an administrator’s rights is administration, as far as the binary knows.

So the logon is where a credential-holding attacker looks most legitimate.

Not least.

The evidence is elsewhere.

In the host the account has never logged in from.

In the NTLM logon with no ticket behind it.

In the RDP session followed by processes nobody runs.

In the scheduled task nobody approved.

Authentication tells you a credential was presented. It does not tell you who presented it or why.

Stop asking whether the login succeeded.

It did.

Ask what the account did next.