Identity is the new perimeter. In 2026, 65% of initial access in confirmed breach investigations traces back to compromised identities — stolen credentials, abused OAuth tokens, hijacked sessions, or bypassed multi-factor authentication. The network firewall, the EDR, and the SIEM are all secondary concerns when an attacker can log in as a legitimate user. In our red team engagements, we consistently demonstrate that valid credentials eliminate the need for zero-days. This post breaks down the identity-layer attack techniques we use most frequently and what defenders need to do about them.
Why Passwords Are Dead But Still Everywhere
Password-based authentication has been declared dead for over a decade. The security industry has been saying it since at least 2012. And yet, in virtually every engagement we run, passwords are still the primary authentication mechanism for a significant portion of an organization's attack surface. The gap between the aspiration of modern identity and the operational reality of legacy systems is enormous — and attackers exploit it every single time.
The problem is not that organizations lack awareness. Most enterprise security teams know passwords are weak. The problem is the long tail of systems that can never be migrated. Legacy on-premises applications that were built before SAML existed. ERP systems running on decade-old codebases that only understand username and password. VPN concentrators configured before MFA was standard. Industrial control system interfaces sitting on flat network segments. In every one of these cases, the answer to "can we add MFA?" is "not without a six-figure project."
Service Accounts: The Silent Credential Crisis
Service accounts represent one of the most consistently exploitable categories we encounter. These accounts — created to run scheduled tasks, connect applications to databases, or authenticate APIs — often carry static credentials that have not rotated in years. Many were provisioned by developers who have since left the organization, with passwords documented only in a shared spreadsheet or, worse, embedded directly in configuration files and source code.
In a financial services engagement in late 2025, we found a service account with Domain Admin privileges whose password had not changed since 2018. The account existed to support a legacy reporting tool that had been decommissioned, but Active Directory still had it enabled with full delegation rights. We compromised it through a credential dump within the first two hours of the engagement. Total time from initial access to Domain Admin: 23 minutes.
Legacy protocols compound the problem further. NTLM authentication, Basic Auth over Exchange Web Services, SMTP authentication, and LDAP simple binds all transmit credentials in ways that are either inherently weak or easily intercepted. Many organizations run conditional access policies that protect modern authentication flows while leaving legacy protocol access completely ungated — a gap that adversaries exploit through protocol downgrade attacks or by directly authenticating via legacy endpoints that bypass MFA entirely.
MFA Bypass Techniques We Use in Engagements
Multi-factor authentication is widely marketed as the single most impactful security control an organization can deploy. Microsoft has claimed it blocks 99.9% of account compromise attacks. In absolute volume terms, that statistic is probably accurate. But for a targeted adversary — one who has selected a specific organization and is willing to invest effort — MFA is a speed bump, not a wall. Here are the techniques we use to get around it.
Adversary-in-the-Middle Phishing with Evilginx-Style Tooling
Adversary-in-the-middle (AitM) phishing is now the standard technique for bypassing MFA in targeted attacks. Instead of building a static credential-harvesting page, AitM tools proxy the real authentication flow in real time. The victim authenticates to a reverse proxy controlled by the attacker. The proxy forwards the request to the legitimate identity provider, receives the authenticated session token, and delivers it to the attacker — all while the victim sees a normal, successful login.
Tools in the Evilginx family (and their successors) automate this process. The configuration is straightforward: define a "phishlet" that maps the target domain's authentication flow, configure DNS and TLS certificates to make the proxy appear legitimate, and send a spearphishing link to the target. When the victim clicks, they interact with the real Microsoft, Google, or Okta authentication page — including all MFA prompts — but their authenticated session is captured at the proxy layer. The attacker receives a valid session cookie that is already post-MFA.
In a recent engagement targeting a mid-size logistics company, we sent a single spearphishing email impersonating an IT helpdesk password expiry notification to a Director of Finance. The target authenticated within 11 minutes of receiving the email, completing their MFA push notification. We had their Microsoft 365 session cookie within seconds of their successful login. No zero-days. No malware. Just a proxy and a convincing pretext.
Detection is difficult because the authentication events look entirely legitimate in the identity provider logs. The user successfully completed MFA. The sign-in appeared from a residential IP. Behavioral analytics and impossible travel detections are the primary defensive controls — and they require baseline data to be meaningful.
MFA Fatigue and Push Notification Bombing
MFA fatigue attacks require valid credentials but exploit the human factor in push-based authentication. The attack is simple: an attacker who has obtained a valid username and password triggers repeated MFA push notifications to the target's device. The notifications arrive at all hours — including late at night or early in the morning. Many users, confused or frustrated by the repeated prompts, eventually approve one, believing it to be a legitimate system notification they missed.
The technique was used in the Uber breach of September 2022, where an attacker sent repeated MFA pushes and then contacted the target via WhatsApp pretending to be IT support, instructing them to approve the next prompt. It remains effective in 2026 because push notification fatigue is a fundamental limitation of the approval-based MFA model.
In engagements where we test this technique, we document how long it takes before a user approves a fraudulent push. In our testing data across multiple engagements, at least one user approves within the first three push attempts in 40% of tested scenarios. The number climbs significantly when we pair the push bombing with a social engineering call.
SIM Swapping for SMS-Based MFA
SMS-based MFA is the weakest commonly deployed second factor. SIM swapping — convincing a mobile carrier's customer service representatives to transfer a target's phone number to an attacker-controlled SIM card — bypasses SMS OTP entirely. The attacker simply receives the one-time code that was destined for the victim.
In a physical social engineering engagement, we used open source intelligence to identify a target's mobile carrier and account details, then placed a call to carrier customer service with enough personal information to pass the identity verification process. The carrier transferred the number within 18 minutes. We had SMS codes for the target's accounts within moments of gaining control of the number.
Carriers have added additional verification steps in response to SIM swapping, but the fundamental vulnerability persists because customer service is a human process and social engineering is a human attack. NIST 800-63 deprecated SMS OTP as a valid authentication mechanism years ago. In 2026, organizations still deploying SMS-based MFA for any account with access to sensitive data are operating with a known-weak control.
FIDO2 Downgrade Attacks
FIDO2 hardware tokens and passkeys are generally considered phishing-resistant. The cryptographic binding between the credential and the relying party domain means a credential obtained on a phishing page cannot be replayed against the legitimate service. However, FIDO2 deployment is almost never absolute — there are always fallback paths.
FIDO2 downgrade attacks target the authentication policy rather than the cryptographic mechanism. If an identity provider is configured to allow FIDO2 as an authentication option but also permits fallback to TOTP or push notification when "the authenticator is unavailable," an attacker can manipulate the authentication flow to force the fallback. The target believes they are authenticating normally; the attacker has simply removed the strongest factor from the equation.
We have also observed deployments where FIDO2 is required for the primary web portal but legacy API endpoints or mobile application authentication flows still accept password plus push notification. The security team considers the environment "FIDO2-protected" while maintaining a bypass path that any attacker who reads the documentation can exploit.
Token Theft and Session Hijacking
Once initial access is achieved — whether through credential compromise, MFA bypass, or social engineering — the goal shifts to persistence. In modern cloud-integrated environments, persistence lives in tokens: access tokens, refresh tokens, session cookies, and the crown jewel of Microsoft environments, the Primary Refresh Token.
Primary Refresh Token (PRT) Extraction
The Primary Refresh Token is Microsoft's mechanism for seamless single sign-on on Azure AD-joined and hybrid-joined Windows devices. A PRT is issued when a user authenticates to a domain-joined machine and is stored in the Local Security Authority (LSA) process memory, accessible via the LSASS process. The PRT is cryptographically bound to the device via a Session Transport Key, but this binding can be bypassed using specific tooling to request derivative tokens that are accepted by Azure AD services.
The tool ROADtoken and the AADInternals PowerShell module both provide functionality for PRT extraction and abuse. A typical extraction flow on a compromised endpoint looks like this:
# Using AADInternals to extract PRT from current session
Import-Module AADInternals
$prt = Get-AADIntUserPRT
# Output: PRT value, session key (encrypted), device certificate
# Convert PRT to access token for Microsoft Graph
$token = New-AADIntAccessTokenFromPRT -PRT $prt.prt -SessionKey $prt.session_key
# Enumerate mailbox with stolen token
$headers = @{ "Authorization" = "Bearer $($token.access_token)" }
Invoke-RestMethod -Uri "https://graph.microsoft.com/v1.0/me/messages" -Headers $headersWhat makes PRT theft particularly impactful is that the derived token inherits the device compliance status of the compromised machine. Conditional access policies that require device compliance are therefore satisfied by a token stolen from a compliant device, even when the attacker is operating from an entirely different machine in a different country.
Cookie Theft via Browser Exploitation
Browser session cookies are the post-authentication credential for nearly every web-based application. On a compromised endpoint, these cookies are readable from the browser's profile directory — but most modern browsers encrypt them using the operating system's Data Protection API (DPAPI), keyed to the user's credentials. This is not a significant obstacle on a machine where the attacker already has user-level access.
Tools like SharpChrome, HackBrowserData, and purpose-built C2 modules can decrypt and exfiltrate Chrome, Edge, and Firefox cookies in seconds. A typical output from a browser cookie extraction on a compromised workstation:
[*] Extracting Chrome cookies from: C:\Users\jsmith\AppData\Local\Google\Chrome\User Data\Default\Network\Cookies
[*] Decrypting DPAPI-protected cookie store...
[+] Successfully decrypted 847 cookies
Host Name Value (truncated)
---- ---- ----------------
.login.microsoftonline.com ESTSAUTH t=0!AQABAAAAAADnygAn...
.login.microsoftonline.com ESTSAUTHPERSISTENT 0.AQABAAAAAADnygAn...
accounts.google.com SSID AHWqTUmkBq8p...
.okta.com sid 102XTr7K9dPmW...
.salesforce.com sid 3MVG9n_HvETGhr3Bg...
[*] Extracted 847 cookies. Filtering for authentication tokens...
[+] 23 high-value authentication cookies identified.These cookies, imported into an attacker-controlled browser session, provide authenticated access to every application the victim was logged into — no password, no MFA prompt, no device compliance check. The attacker's session appears entirely normal from the application's perspective.
OAuth Token Replay Attacks
OAuth access tokens are issued with defined scopes and lifetimes. When applications do not implement proper token binding or audience restrictions, tokens obtained from one context can be replayed in another. Refresh tokens — which are used to obtain new access tokens — are particularly valuable because they typically have long lifetimes (often 90 days in default Microsoft configurations) and broad scope.
A common pattern we observe is OAuth tokens stored insecurely in application logs, environment variables, or configuration management systems. During a cloud-focused engagement, we discovered a Jenkins CI/CD pipeline that logged Azure AD access tokens to standard output during build steps. Those logs were readable by any developer with Jenkins access. Each token had a 60-minute lifetime, but the refresh tokens in the same logs had a 90-day validity window. We replayed a refresh token obtained from a three-day-old log entry and received a fresh access token for an account with Global Reader permissions across the tenant.
29-Minute Breakout: From Access to Lateral Movement
The security industry talks about "dwell time" — the period between initial compromise and detection. The more operationally relevant metric for identity-based attacks is breakout time: how long does it take an attacker to move from the first compromised identity to meaningful lateral movement or privilege escalation? Based on our red team engagement data, the answer in environments with identity-layer weaknesses is alarmingly short.
The following timeline is representative of a real engagement we conducted against a 1,200-person professional services firm in late 2025. Scope was full adversary simulation with assumed breach starting point of a standard user workstation.
The 29-Minute Timeline
- T+00:00 — Initial foothold established on endpoint via simulated phishing payload execution. User-level shell on workstation.
- T+02:15 — Browser cookie extraction complete. 23 authenticated session cookies exfiltrated, including Microsoft 365 and corporate SharePoint.
- T+04:40 — PRT extracted from LSASS via in-memory tooling. Device is Azure AD hybrid-joined and compliant. PRT is valid for SSO to all Azure AD resources.
- T+07:30 — Microsoft Graph enumeration begins using PRT-derived token. Identify 12 users with privileged roles. Identify service principal with Application Administrator rights registered three years prior.
- T+11:00 — Service principal client secret found in SharePoint document library accessible to all employees. Document titled "IT Infrastructure — Service Accounts Reference 2022." Secret is current and valid.
- T+14:30 — Authenticate as service principal with Application Administrator rights. Add credentials to a second service principal that has Global Administrator role assignment.
- T+19:00 — Authenticate as Global Administrator service principal. Create new user account in tenant with Global Administrator role.
- T+23:45 — Use Global Administrator account to read all mailboxes via Exchange Online. Identify CFO and CEO mailbox. Export 90-day email history.
- T+29:00 — Establish persistence via additional federated identity provider. Access will persist even if original compromised account is disabled.
Twenty-nine minutes from a standard user workstation to persistent Global Administrator access with full mailbox read capability. No vulnerabilities were exploited in the traditional sense. Every step used documented, expected Microsoft functionality. The failures were all identity and configuration failures: a PRT-enabled device with no token binding enforcement, overprivileged service principals, poor secrets management, and missing conditional access controls on service principal authentication.
Crowdstrike's 2025 threat intelligence data put the average eCrime breakout time at under 60 minutes. For targeted intrusions, that number drops significantly. The industry benchmark that organizations should plan for — detect and contain within two hours of initial access — is achievable, but only if identity signals are being monitored in real time.
Testing Identity Resilience: Our Methodology
When we assess an organization's identity security posture, we approach it as a layered evaluation. The goal is not just to find individual vulnerabilities but to understand how multiple weaknesses chain together into realistic attack paths. Our identity resilience assessment methodology covers four primary domains.
Conditional Access Policy Review
Conditional access is the primary policy enforcement layer in modern identity infrastructure. A poorly designed conditional access architecture creates gaps that are invisible in day-to-day operations but trivially exploitable in an attack. We evaluate:
- Coverage completeness — which applications, user populations, and authentication flows are governed by conditional access and which are not
- Legacy authentication blocking — whether SMTP Auth, Basic Auth, and other legacy protocols are disabled or explicitly blocked at the tenant level
- Guest and external user policies — whether guest accounts follow the same conditional access requirements as internal users or have broader implicit trust
- Named location trust — whether IP-based named locations are combined with device compliance requirements or can be spoofed by network-layer manipulation
- Break-glass account exposure — whether emergency admin accounts bypass conditional access and whether those accounts have compensating controls
- Sign-in risk policy integration — whether Azure AD Identity Protection risk signals are actually configured to block or require step-up authentication
Token Lifetime Analysis
Default token lifetimes in Microsoft environments are a known risk factor. Access tokens issued for Microsoft Graph default to 60 minutes. Refresh tokens for non-persistent browser sessions can persist for 24 hours; for persistent sessions, the default is 90 days. In environments that have not explicitly configured token lifetime policies, these defaults represent the window an attacker has to operate with a stolen token before it expires.
We review token lifetime configurations for all registered applications, assess whether Continuous Access Evaluation (CAE) is enabled for supported workloads, and test whether token revocation through conditional access policy changes takes effect within the expected timeframe. In many organizations, we find that token revocation is configured but takes 60–90 minutes to propagate, creating a window between detection and effective containment.
Session Management Testing
Beyond token lifetimes, we test the practical resilience of session management controls. This includes testing whether stolen session cookies from one geographic location can be replayed from another, whether impossible travel detections trigger in real time or are batch-processed with delay, and whether application-level session timeouts are enforced independently of the identity provider session. We also test re-authentication requirements for high-privilege operations — many organizations configure MFA at login but do not require step-up authentication for privileged actions like changing account settings, initiating large transfers, or modifying security configurations.
Privileged Identity and Service Account Enumeration
We enumerate all accounts with privileged role assignments in both on-premises Active Directory and cloud identity systems, with particular attention to service accounts, application identities, and service principals. We look for stale assignments, over-permissioned service principals, and client secrets with excessive validity periods. In cloud environments, we also enumerate workload identities — managed identities attached to compute resources — and test whether they carry permissions beyond what their assigned workload requires.
Defensive Guidance: Hardening the Identity Layer
The attacks described in this post are not theoretical. We execute them in client environments regularly. The good news is that identity security is a solvable problem — it requires deliberate configuration and ongoing governance, not new budget or new products. The following controls address the highest-impact gaps we consistently identify.
- Deploy phishing-resistant MFA for all privileged accounts immediately. FIDO2 hardware tokens or Microsoft Authenticator with number matching and additional context eliminate the push notification bombing and AitM phishing attack paths. If you cannot deploy FIDO2 universally, prioritize every account with administrative rights, every account with access to financial systems, and every account with the ability to modify identity configurations.
- Block all legacy authentication protocols at the tenant level. There is no valid security justification for leaving SMTP Auth, Basic Auth, or IMAP authentication enabled in 2026. If a legacy application requires these protocols, that application needs to be on a modernization roadmap with a defined timeline. The risk of leaving legacy auth open indefinitely is not acceptable.
- Implement token binding and Continuous Access Evaluation. CAE allows supported applications to receive near-real-time signals from the identity provider when a token should be revoked — user disabled, password changed, session explicitly revoked. Without CAE, a stolen token is valid for its full lifetime regardless of what happens to the originating account.
- Rotate service account credentials on a defined schedule and eliminate static secrets. Managed identities in Azure and workload identity federation eliminate the need for long-lived client secrets in most modern scenarios. Where static secrets are unavoidable, they should be stored in a secrets management system, rotated on a maximum 90-day cycle, and audited for last-use date. Any secret that has not been used in 90 days should be treated as abandoned and revoked.
- Configure impossible travel and sign-in risk policies to block rather than just alert. An impossible travel detection that generates an alert is useful for forensics. An impossible travel detection that requires step-up authentication or blocks the session entirely is a security control. The difference in implementation effort is minimal; the difference in defensive value is substantial.
- Audit privileged role assignments on a quarterly basis. Role assignments accumulate over time. People change jobs, projects end, tools get replaced — but their role assignments often persist. A quarterly review of all accounts with administrative or privileged roles in Active Directory, Azure AD, and cloud platforms should be a standard governance process, not an annual event triggered by an audit finding.
- Enable Microsoft Defender for Identity (or equivalent) and tune it for your environment. PRT theft, DCSync attacks, Pass-the-Hash, and Kerberoasting all generate detectable signals in identity telemetry. The challenge is that these signals are high-volume and require tuning to be actionable. An out-of-the-box MDI deployment with default alert thresholds will generate noise; a tuned deployment with environment-specific baselines will catch lateral movement within minutes.
- Implement a Zero Trust network architecture for privileged access. Privileged access workstations (PAWs) with hardened configurations, separate from standard user workstations, eliminate the risk of PRT theft and browser cookie extraction from administrator accounts. If an attacker compromises a standard user workstation, they should not be able to extract credentials or tokens that provide administrative access to identity infrastructure.
Frequently Asked Questions
Is MFA still worth deploying if it can be bypassed?
Absolutely. MFA eliminates the overwhelming majority of opportunistic credential attacks — password spray, credential stuffing, and brute force attacks that rely on username and password alone. The bypass techniques described in this post require targeting a specific individual and investing meaningful effort. That cost-benefit calculation deters most attackers. The goal is not to find a perfect, unbypassable control — it is to raise the cost of attack high enough that most adversaries divert to softer targets. Phishing-resistant MFA (FIDO2, passkeys) is the current strongest option and should be deployed wherever feasible.
How do we detect AitM phishing campaigns targeting our users?
The most reliable detection signals are impossible travel (a user authenticating from Toronto and then from Eastern Europe within minutes), unfamiliar device or user agent strings in sign-in logs, and new persistent session tokens appearing on non-compliant or unregistered devices. Defender for Cloud Apps and Azure AD Identity Protection both surface these signals. Pair automated detection with a user reporting program — many AitM attacks are reported by targets who received a login notification for a session they did not initiate.
What is the single highest-impact identity security improvement most organizations can make?
Blocking legacy authentication protocols at the tenant level. It is a configuration change, not a project. It requires no new tooling. It immediately eliminates entire attack categories — protocol downgrade attacks, basic auth credential stuffing, and legacy protocol MFA bypass. The only blocker is typically a legacy application that depends on the protocol. Identifying and addressing those dependencies is the actual work. In our experience, most organizations have fewer legacy auth dependencies than they assume, and those that exist are usually addressable within a standard change management cycle.