Attacks on authentication
Techniques that defeat the login itself: real-time phishing proxies, factor relay, enrolment abuse, and credential guessing. Almost none of them break cryptography.
Why this control fails
Authentication attacks succeed because most factors produce something a human can read, type, or approve, and anything a human can relay an attacker can relay too. The Mirage2FA campaign reached 4,532 organization domains between 2024 and 2026 without defeating a single factor. Only origin-bound credentials break that pattern, because the authenticator refuses to sign for a domain other than the one that registered it.
What security people should do
- Deploy phishing-resistant MFA and write policy against the property, not the acronym.
- Audit the exemption list more often than the policy list. That list is your real access model.
- Disable device code flow for tenants with no input-constrained devices.
- Treat enrolment and recovery as high-assurance events, because that is where the bypasses are.
Techniques in this category
A reverse proxy sits between the user and the real login page, relays every step of authentication including MFA, and keeps the session cookie the successful login produces.
Attackers replay username and password pairs leaked from one breach against every other login page they can reach, betting on the well-documented habit of password reuse.
The victim enters a code on Microsoft's own login page and approves a real prompt. The attacker requested that code from a second device and walks away with access and refresh tokens.
The attacker already has a password. They trigger push approval prompts until a tired or confused user taps approve, sometimes with a fake IT message to speed the decision along.
The attacker starts a real login and calls the victim posing as support, asking them to read back the one-time code that just arrived. The code is genuine; the request is not.
Instead of guessing many passwords against one account and triggering a lockout, the attacker guesses a few common passwords against many accounts, staying under the threshold for each one.
Code already running in a signed-in Windows session can drive the device's own Windows Hello key to obtain a Primary Refresh Token, no PIN prompt, no admin rights, no CVE required.
A refresh token exists to let an app get new access tokens without bothering the user again. Stolen, it lets an attacker do the same thing indefinitely, surviving password resets along the way.
A session cookie is a bearer credential that proves nothing beyond possession. Whoever copies it inherits the logged-in session, skipping the password and the MFA challenge that produced it.
The victim never types a password. They click a legitimate 'Sign in with' button, land on the real identity provider, and approve an attacker-registered application's request for mailbox and file access.
A phone call to IT support, not a login attempt, is the actual attack. The target's strong password and MFA enrollment never come into play, because the attacker gets a human to reset both.
A certificate template with permissive enrollment rights or a misconfigured extension turns Active Directory Certificate Services into a path to domain compromise, no password or Kerberos ticket required.
A service provider that accepts a SAML assertion it should have rejected treats a forged identity as authenticated, because the failure sits in signature validation code, not in cryptography.
A passkey or Windows Hello key is supposed to stay locked to its device. Code running on an already-compromised endpoint can pull the key material out of the process that holds it, or drive it without the fresh check meant to gate its use.
Commodity malware on an endpoint reads whatever the browser and OS have stored in the clear or under a key the same machine already holds, then ships it to a marketplace where the credentials outlive the machine they came from.