-
What Is an Identity-Based Attack?
An identity-based attack is a breach technique in which the attacker authenticates as a legitimate user or service instead of exploiting a software flaw. They get there with stolen passwords, hijacked session tokens, or manipulated MFA, and from then on most tools see normal use.
-
Are Stolen Credentials Still the Main Way In?
By the narrowest measure, no, and the nuance is worth understanding. Verizon's 2026 DBIR found vulnerability exploitation at 31% of breaches as the first known initial access vector, with credential abuse at 13%. Help Net Security noted this was the first time in the report's 19-year history that stolen credentials lost the top spot.
Two caveats matter. First, part of the drop is methodological: this year's report added pretexting as its own category, which absorbed incidents that previously counted as credential abuse. Second, initial access is only the first step. The same analysis notes credential abuse still appears somewhere in 39% of breaches.
Incident responders see the identity layer even more starkly. In Q2 2026, Cisco Talos Incident Response found authentication abuse in 65% of its engagements, up from 35% the previous quarter, and phishing led initial access in over half of them. These are different datasets (breaches versus incident response engagements), so don't compare the numbers directly. Both put identity at the center of the story.
-
Three Ways Attackers Get a Valid Identity
-
1. Stolen Credentials
-
Infostealer malware quietly harvests saved passwords, VPN logins, and cookies from infected devices, often personal laptops where work and personal accounts sit side by side. Flashpoint estimated that infostealers harvested around 1.8 billion credentials in the first half of 2025 alone. Phishing kits and credential stuffing feed the same market.
-
2. Session and Token Theft
A session cookie is proof that someone already logged in. Steal it, replay it, and the server sees a continuation of an authenticated session, so there is no login to challenge and no MFA prompt. MITRE tracks this as T1539, Steal Web Session Cookie. SpyCloud reports roughly 8.6 billion stolen cookies recaptured in 2025, about 40% from devices already running EDR or antivirus.
-
3. MFA Weaknesses
MFA still blocks the bulk of simple password attacks. The problem is that "MFA" covers methods of very different strength. Talos observed attackers defeating it through adversary-in-the-middle proxies, session-token theft, MFA fatigue, and self-enrolled devices. Phishing-as-a-service has industrialized the first of these: Group-IB estimates the Tycoon 2FA kit alone drove a large share of credential theft attacks in 2025, putting MFA bypass in the hands of operators with little technical skill.
| Technique | How it works | Stopped by FIDO2/passkeys? | What helps |
|---|---|---|---|
| MFA fatigue (push bombing) | Floods a user with approval prompts until they tap "Approve" | Yes. There is no push to approve | Number matching; phishing-resistant MFA |
| Adversary-in-the-middle (AiTM) phishing | A reverse proxy relays the real login and captures the session token after MFA | Yes. The credential is bound to the real site | FIDO2/WebAuthn; Conditional Access |
| Session cookie theft | Malware copies a live session from the device | No. The theft happens after login | Session anomaly detection; fast token revocation |
| OAuth device-code phishing | The victim authorizes the attacker on the genuine sign-in page | No. Nothing fake for a passkey to refuse | Monitor device-code sign-ins; Conditional Access |
| Attacker-registered MFA device | The attacker enrolls their own device after a foothold or help desk social engineering | Not by itself. It is an enrollment gap | Help desk verification for enrollment; alert on new devices |
Phishing-resistant MFA is still the most valuable single upgrade. CISA rates it the strongest form of MFA and identifies FIDO/WebAuthn as the only widely available phishing-resistant option. But it protects the front door, not the session after it has been issued. The Talos analysis of the ARToken phishing platform shows why: its device-code phishing bypasses MFA through a legitimate OAuth flow rather than by stealing passwords.
-
Why Identity Monitoring Matters
Once an attacker holds a valid session, prevention has already failed. Detection is what remains, and many organizations can't see well enough to use it. Talos found insufficient logging in 42% of Q2 engagements, up from 18% the quarter before, with some gaps so severe that responders couldn't determine how the attacker got in.
Identity signals worth alerting on:
-
Session reuse from a new device or location shortly after a normal login.
-
New MFA methods or devices registered, especially right after a password reset or outside business hours.
-
Device-code sign-ins and OAuth consent grants for apps nobody approved.
-
New inbox rules that hide, forward, or delete mail. Talos named email hiding rules the most observed persistence technique in Q2.
-
Bursts of outbound email from one account. In one Talos engagement, a single compromised mailbox sent over 6,600 phishing emails.
-
Valid accounts doing what their role never does, such as privilege escalation or admin tools from unusual hosts.
Logs must also outlive the incident. Talos recommends centralized logging with at least 90 days of retention, forwarded off-device so attackers can't delete the evidence.
-
A Practical Order of Operations
-
Move high-value accounts to phishing-resistant MFA first. CISA recommends a phased rollout, starting with services that already support FIDO. Administrators, help desk, executives, and finance come before everyone else.
-
Block legacy authentication through Conditional Access, since it can sidestep MFA entirely.
-
Lock down MFA enrollment. Require help desk verification and alert on every new device.
-
Rehearse session revocation. For a compromised identity, revoke active sessions and tokens and rotate secrets. A password reset alone leaves a stolen session alive.
-
Centralize identity and cloud logs with at least 90 days of retention.
-
Practice the response under pressure, because the playbook that reads well at noon tends to fail at 2 a.m.
Common Mistakes
-
Treating "MFA enabled" as a finished project instead of asking which kind of MFA.
-
Resetting the password without revoking the session.
-
Monitoring logins but not enrollments, consent grants, and inbox rules.
-
Keeping identity logs for days when investigations need months.
Practice the Identity Fight Before You're in It
Identity attacks are hard to learn from slides because the evidence is subtle: a valid login, a quiet inbox rule, a device that wasn't there yesterday. Teams get faster by working through it. Simulations Labs' Cyber Range lets security teams run live-fire incident response exercises, so you can turn a session-hijack timeline into a scored drill and see where detection and handoffs slow down. For a recurring program rather than a one-off, security team upskilling tracks help you repeat and measure it, and the scenario library gives analysts hands-on practice with the underlying techniques.
Want your SOC to rehearse a session-hijack response before a real one? Explore the Simulations Labs Cyber Range or request a demo.
-
Frequently Asked Questions
-
FAQ 1: What is an identity-based attack?
-
It is an attack in which the adversary signs in as a legitimate user or service instead of exploiting a software vulnerability. They use stolen passwords, hijacked session tokens, or manipulated MFA, so their activity looks like normal use to most security tools.
-
FAQ 2: Can attackers bypass MFA?
Yes. Talos observed attackers defeating MFA through adversary-in-the-middle proxies, session-token theft, MFA fatigue, self-enrolled devices, and legacy authentication protocols. Phishing-resistant MFA such as FIDO2/WebAuthn stops several of these, but not session theft after login.
-
FAQ 3: What is session token theft, and why doesn't MFA stop it?
A session token is issued after a successful login and proves the user is already authenticated. If malware copies it, the attacker can replay it from another device. The server sees an existing session, so no new login happens and no MFA prompt is triggered.
-
FAQ 4: Are passkeys enough to stop identity-based attacks?
No. Passkeys and FIDO2 resist phishing and AiTM attacks because the credential is bound to the real site. They do not stop a session cookie stolen from an infected device, or device-code phishing that happens on a genuine sign-in page. They work best alongside session monitoring and fast revocation.
-
FAQ 5: Is credential abuse still the top initial access vector?
Not in Verizon's 2026 DBIR, where vulnerability exploitation led at 31% and credential abuse was 13%. Part of that shift is methodological, since pretexting became its own category, and credential abuse still appears somewhere in 39% of breaches.
-
FAQ 6: What should identity monitoring alert on?
Prioritize session reuse from new devices or locations, new MFA device registrations, device-code sign-ins and OAuth consent grants, new inbox rules, bursts of outbound email from one account, and valid accounts performing actions outside their role. Keep at least 90 days of centralized logs.
