Why do browser-based attacks still work in environments with MFA and EDR?

Why browser-based attacks still succeed after MFA

Browser-based attacks work because MFA proves a login step, not the trustworthiness of the page, prompt, or consent screen a user is looking at. If the victim enters credentials or approves a flow in a cloned site, the attacker can capture a live session or token and reuse it before security tools notice the fraud.

The practical weakness is that modern authentication often ends with a trusted browser session. Once that session exists, the attacker may not need to bypass MFA again. That is why phishing-resistant methods and session binding matter as much as the second factor itself, especially when the user is the one authorising the transaction.

Browsers also flatten context. A user cannot always tell whether the request came from a legitimate app, a malicious reverse proxy, or a consent flow that is asking for excessive access. That gap is what makes browser-mediated attacks durable: they exploit human judgment at the point where the control plane, not just the login page, matters.

How attackers turn one successful browser interaction into access

The key move is session theft or session creation, not repeated password cracking. In an adversary-in-the-middle or token replay flow, the attacker relays the real authentication to the target service, then keeps the resulting cookie, code, or bearer token. CitrixBleed exploitation 2023 is a good example of how a stolen session can bypass MFA entirely.

Consent abuse is the other common pattern. A malicious app can ask for permissions that look routine to a busy employee, then keep access long after the click. Twilio 0ktapus breach 2022 shows how a browser-delivered lure can open the door to downstream account compromise even when the initial sign-in seemed protected.

Once inside, the attacker often pivots from the browser session into adjacent systems. That can mean mailbox access, OAuth token abuse, cloud console access, or internal app impersonation. Storm-1283 OAuth apps abuse 2023 illustrates how one abused permission grant can become durable infrastructure access.

What browser-based attacks reveal about control design

The important lesson is that MFA and EDR are necessary but not sufficient. MFA reduces password reuse and remote login abuse, while EDR improves endpoint visibility, but neither control automatically validates that a browser consent or sign-in happened on the right page for the right purpose. If the session is trusted after creation, the attacker only has to win once.

That is why organisations need controls that are specific to browser-mediated identity risk. Phishing-resistant authentication, strict app consent governance, short-lived sessions, conditional access, and token protection reduce the window in which a fraudulent browser interaction can be converted into persistent access. NIST SP 800-63 Digital Identity Guidelines is useful here because it ties assurance to authenticator strength rather than to the mere presence of MFA.

It also helps to separate endpoint compromise from identity compromise. EDR can tell you the device is healthy or suspicious, but a compromised browser session may still look “normal” at the operating-system layer. MFA Guide is relevant because it covers the bypass patterns practitioners need to design against, not just the enrolment of factors.

Risk and Threat Considerations

Browser-based attacks create a trust gap between authentication and authorisation. The main risk is not that MFA fails outright, but that a valid session or consent grant is created for the wrong interaction, then reused before defenders can revoke it. EDR may provide telemetry after the fact, but it does not prevent a fraudulent browser transaction from becoming a trusted session.

Failure mechanism: Attackers exploit reverse-proxy phishing, token replay, malicious OAuth consent, or session hijacking to convert a single user action into durable access that bypasses the original login challenge.

Impact: The resulting access can support mailbox takeover, application abuse, cloud persistence, lateral movement, and data theft, often without triggering repeated MFA prompts or obvious endpoint compromise.

Practitioner Guidance

What to prioritise: Treat browser-based identity abuse as a session security problem, not just an MFA problem. Prioritise phishing-resistant authentication, short session lifetimes, consent restrictions, and token revocation paths that work quickly when a suspicious browser interaction is detected.

What to verify: Check whether your policy distinguishes a successful login from a trustworthy session. You want to know which apps issue long-lived refresh tokens, which consent grants can persist indefinitely, and which browser flows can be replayed outside the original device or context.

Common mistake: Assuming that a clean EDR signal means the user session is trustworthy. In these attacks, the browser is often the attack surface, so device hygiene alone does not eliminate the risk.

Practitioner takeaway: If the attacker can win once in the browser, your real control objective is to make that success short-lived, narrowly scoped, and easy to revoke.

Related resources from NHI Mgmt Group

• Why do passwords and OTP-based MFA still fail against modern identity attacks in regulated environments?
• Why do weak or reused passwords still create outsized risk in browser-based work environments?
• Why do adversary-in-the-middle attacks still work when MFA is enabled?
• Why do MFA fatigue attacks still work in mature IAM programmes?