Identity-Based Attacks: How Attackers Bypass MFA and Compromise Accounts

Identity-based attacks target the credentials, sessions, tokens, and trust relationships that control access to systems and data. The attacker logs in or acts as a valid user, so the activity looks like normal access.

Multi-factor authentication (MFA) has made account takeover harder in most SaaS environments. So the attackers adjusted themselves by working the systems around authentication: sessions, tokens, stored identity data, and trusted vendor infrastructure.

Between March and April 2026, four incidents showed what that looks like: a router campaign that harvested Microsoft session tokens, a breach at a French government identity portal, phishing delivered through genuine Apple emails, and takeovers of messaging accounts.

Each attacker exploited a weakness around identity. Each incident also teaches security teams something specific and points to a control that reduces the risk.

What Happened in the Four Identity-Based Attack Incidents?

The four incidents hit four different surfaces. The router campaign targeted sessions, the French breach targeted stored identity data, the Apple abuse targeted trust in a sender, and the messaging campaign targeted user accounts.

They are four different identity-security incidents, each with its own failure point.

1. Router Compromise Enabled OAuth Token Theft

Forest Blizzard (also tracked as APT28), a threat actor linked to Russian military intelligence, compromised end-of-life MikroTik and TP-Link small office and home office routers. The attackers changed their DNS settings to point to attacker-controlled servers and needed no malware to do it.

Lumen's Black Lotus Labs counted more than 18,000 routers at the December 2025 peak. Microsoft Threat Intelligence identified over 200 organizations and 5,000 consumer devices affected.

With DNS under attacker control, lookups for Microsoft Outlook on the web could be redirected, which puts the attacker between the user and the service. That setup is called adversary-in-the-middle (AiTM). Microsoft says most requests were proxied transparently, and active interception worked when a user clicked through an invalid TLS certificate warning.

Krebs on Security reports the attackers could then intercept OAuth tokens from users on the affected networks.

An OAuth token is issued after sign-in finishes, MFA included, and it works as a bearer credential: whoever presents it gets the session. A stolen, valid token therefore grants access without a new password or MFA prompt, because that challenge already happened.

Lesson: Login security covers one moment. Tokens and active sessions need their own protection. Microsoft also flags unmanaged home routers used by remote and hybrid staff as a path into corporate cloud access.

2. France's National Identity Agency Suffered a Data Breach

On April 15, 2026, France's National Agency for Secure Documents (ANTS) detected an incident on its portal, which handles passport, ID card, and driver's license applications. The Interior Ministry said exposed data may include login credentials, names, email addresses, dates of birth and account identifiers, and for some users, postal addresses, places of birth and phone numbers.

The Record reported that uploaded documents weren't included. ANTS later confirmed 11.7 million affected accounts, against a threat actor's claim of up to 19 million.

Stolen identity data fuels follow-on attacks. Names, dates of birth, and contact details make impersonation convincing: phishing that appears to come from ANTS, fraudulent credit or document applications, and attempts to reuse exposed credentials on unrelated services, which can end in account takeover.

The ministry said the exposed data can't be used to access ANTS accounts directly, so the damage shows up downstream.

Lesson: identity infrastructure and stored identity data belong on your attack surface map. Collect less, protect what you keep, and watch for reuse of exposed credentials.

3. Attackers Abused Apple's Legitimate Notification System

Attackers created Apple accounts and split a scam message across the first and last name fields. They then changed the shipping information, which made Apple send a real account-change alert with the lure embedded.

BleepingComputer reported the email claimed an $899 iPhone purchase and gave a phone number to cancel it. Victims who call typically get steered toward remote-access software or asked for financial details.

The message came from Apple's own mail servers, so it passed SPF, DKIM and DMARC. Those checks verify the sender. Content is a separate question, and no email authentication standard answers it.

The lure is familiar, and the delivery uses a legitimate account feature. Apple hadn't responded when BleepingComputer published.

Lesson: A trusted sender and a passing authentication check tell you who sent the message. Whether the request is safe is a separate judgment, so give employees and your helpdesk a call-back rule for urgent account alerts.

4. Compromised Messaging Accounts Exposed Encrypted Conversations

In March 2026, the FBI and CISA warned that Russian intelligence-linked actors had gained access to thousands of commercial messaging app accounts, with Signal the main target. The targets were current and former government officials, military personnel, political figures, and journalists.

The attackers posed as support or security accounts and asked victims to share verification codes or PINs, or to approve a linked device by scanning a QR code, according to CyberScoop. The apps' encryption stayed intact, and account access was the way in.

The FBI also said actors may add malware as the campaign evolves, which would extend access to the device itself.

The same pattern applies to any app staff use for sensitive conversations.

Lesson: Encryption protects messages in transit. User accounts, sessions, and endpoints need their own protection.

What do these Four Attacks Have in Common?

Each attacker went after something an organization trusts by default: an authenticated session, stored identity data, a verified sender, a legitimate user account. Trust that went unchecked after the first successful step was the common weakness.

MFA can work as designed while an attacker uses the session it produced. That's the router case: the user authenticated normally, and the token was collected afterward.

Traditional login alerting is built around the sign-in event, so it can miss misuse that starts after a successful one. A valid token replayed from an attacker's infrastructure looks like a valid session.

Other MFA bypass techniques follow the same logic. Push bombing wears down the user, and SIM swapping takes over the phone number behind an SMS code.

Identity security threats like these call for coverage beyond the login prompt: session activity, token use, and downstream access in every SaaS app your workforce touches.

How Can Organizations Defend Against Identity-Based Attacks?

Each incident broke at a different point, so each maps to different controls.

1. Phishing-Resistant MFA

Prioritize a multi-factor authentication (MFA) solution with FIDO2/WebAuthn-based authentication methods available. It binds each sign-in to the legitimate site, which defeats credential phishing and real-time MFA interception on a fake login page.

Enforce it with no phishable fallback, since attackers go after the weakest enrolled method. Give backup authentication paths the same scrutiny as the primary factor. Our phishing-resistant MFA solutions cover the methods in detail.

This control covers the “sign-in.” Tokens issued afterward need the next one.

2. Session and Token Protection

Protect token storage, limit where tokens are exposed, monitor for suspicious reuse, and revoke sessions once you suspect compromise. Token binding ties a token to the device it was issued to, so a copied token fails elsewhere.

It's a specific control, and coverage varies by platform, app type, and browser. Microsoft Entra Token Protection currently supports native applications on managed devices, and browser-based apps fall outside it.

Google's Device Bound Session Credentials reached general availability in Chrome on Windows in April 2026, with macOS planned. Check which of your apps and browsers sit inside that coverage before you count on it.

3. Identity Threat Detection

Monitor unusual sign-ins, device changes, token activity, and suspicious access after authentication. Microsoft's guidance on the router campaign recommends baselining normal user behavior and reviewing risky sign-ins and mailbox access.

Useful signals from these incidents include DNS setting changes on endpoints, a new linked device on a messaging account, and a token used from an unfamiliar network. Send them to your SIEM so your SOC sees identity events next to endpoint and network alerts.

4. Risk-Based Access Controls

Apply conditional access, least privilege, and extra verification when device, location, or behavior raises risk. Microsoft recommends requiring MFA on medium or higher sign-in risk and using continuous access evaluation so access gets rechecked during the session.

Least privilege caps what any one stolen session can reach.

No single control covers every identity attack. Prevention, detection, and response have to work together.

What Should Security Teams Prioritize Now?

Five moves, in this order:

1. Map critical identities, apps, and active sessions. Start with admins, finance and engineering roles and the SaaS apps behind them. Note which remote staff reach those apps over unmanaged networks.

2. Roll out phishing-resistant MFA to privileged and high-risk access first. Remove SMS and push as fallbacks for those groups.

3. Review token lifetime, storage, revocation, and session monitoring. Confirm you can end a session in minutes and treat a password reset as one step among several.

4. Improve detection after authentication. Alert on token reuse, new devices, and unusual access to mail and files.

5. Test incident response for compromised credentials and sessions. Run a tabletop where the password is already reset, and the attacker still has access.

Conclusion

Each of the four incidents broke at a different point around authentication. Identity security has to verify who signs in and keep verifying that the access and session activity afterward stay trustworthy.

Phishing-resistant authentication, session protection, and post-login detection, working together, leave attackers far fewer gaps.

FAQs

What is an identity-based attack?

An identity-based attack targets credentials, session tokens, authentication systems or stored identity data to gain access as a legitimate user. Common forms include credential phishing, session token theft, OAuth abuse, and breaches of identity data stores.

How do attackers bypass multi-factor authentication?

Most bypasses go around the MFA check. Attackers steal tokens issued after MFA succeeds, trick users into sharing codes or approving device links, or run phishing proxies that relay a real login in real time. Each works because MFA verifies the sign-in, and the attacker acts after it.

Why is phishing-resistant MFA important?

Phishing-resistant MFA, built on FIDO2 and WebAuthn, binds authentication to the legitimate site. Codes and approvals can't be captured on a fake page and replayed. It removes the weakest factors attackers rely on, though it needs session protection alongside it for tokens issued after sign-in.

How can security teams detect identity-based attacks?

Watch what authenticated identities do after sign-in as well as whether they signed in. Useful signals include unusual sign-ins, new devices, token reuse from unfamiliar networks, DNS or device setting changes and unexpected access to mail or files. An identity threat detection and response (ITDR) workflow connected to your SIEM brings these signals together.

Can attackers bypass phishing-resistant MFA?

Yes, through routes that skip the sign-in: stealing a session token after login, compromising the endpoint, or abusing a weak recovery or fallback method. Token binding, session monitoring, and tight recovery policies cover those gaps.

What is an adversary-in-the-middle (AiTM) attack?

In an AiTM attack, the attacker sits between a user and a service and relays or reads the traffic. That position lets the attacker capture credentials, MFA responses or session tokens as they pass. The router campaign in this article used the technique against Outlook on the web traffic.