Browser attacks are bypassing identity controls through the browser

At a glance

What this is: This is a browser-attack analysis showing that identity compromise is increasingly happening inside the browser rather than through the email, endpoint, or network layers.

Why it matters: It matters because IAM, NHI, and human identity programmes all depend on assumptions about where authentication, consent, and session control can be observed and enforced.

By the numbers:

• Device code phishing went from near-zero to at least 12 distinct kits in a matter of months.

👉 Read Push Security's analysis of browser-based attack techniques in 2026

Context

Browser-based phishing is no longer a single technique. It is a fast-moving attack surface where adversaries abuse legitimate login pages, browser redirects, clipboard actions, and OAuth flows to obtain sessions or tokens without tripping the controls that were built for email, endpoint, or network events. In identity terms, the browser has become part of the trust boundary.

For IAM teams, the issue is not just credential theft. It is that authentication, consent, and token issuance are now being manipulated in a place where many programmes still assume visibility from EDR, mail gateways, or proxy inspection. That assumption breaks down when the compromise lives entirely in the browser and never becomes a traditional endpoint incident.

The article focuses on a familiar problem in a new form: identity abuse is being operationalised faster than defenders can adapt their review, detection, and response models. That is already the case for large enterprises, but the pattern is even harder for organisations with contractor fleets, BYOD, developer tooling, or uneven MFA coverage.

Key questions

Q: How should security teams defend against browser-based identity attacks?

A: Security teams should defend browser-based identity attacks by treating the browser as a control point, not just a delivery channel. That means detecting token theft, consent abuse, and clipboard-driven execution before the attacker reaches the endpoint or cloud session. Controls should focus on browser telemetry, risky OAuth journeys, and fast session revocation.

Q: Why do browser attacks bypass so many traditional security controls?

A: Browser attacks bypass traditional controls because the malicious action often happens inside a legitimate browser session. Email gateways may never see the lure, EDR may only see a user action, and network tools may only observe normal traffic. The control failure is coverage, not just detection quality.

Q: What breaks when device code phishing is allowed in everyday enterprise workflows?

A: When device code phishing is normalised in everyday workflows, attackers can hijack a legitimate identity flow without stealing a password or intercepting MFA. That makes user training less effective and shifts risk into protocol design, app consent, and the trust users place in codes from a real login page.

Q: How do organisations reduce the impact of stolen browser sessions?

A: Organisations reduce the impact of stolen browser sessions by shortening session lifetime, revoking tokens quickly, and watching for reuse across impossible locations or unusual devices. They should also separate high-risk administrative access from ordinary browser-based SaaS use so a stolen session does not unlock everything.

Technical breakdown

AiTM phishing and real-time session token theft

Adversary-in-the-middle phishing places a proxy between the user and the real identity provider so the attacker can relay traffic, capture session tokens, and complete MFA in real time. The victim sees a normal login flow, which is why reputation-based controls often miss it. The important detail is that the attacker does not need the password after the session is established, because the browser session itself becomes the reusable asset. This shifts the problem from credential capture to token interception and session replay, which is a different detection challenge entirely. Practical implication: identity teams need browser-aware controls that can detect active interception rather than relying only on login success and MFA completion.

Practical implication: detect interception at the browser layer, not just login failure or MFA bypass.

ClickFix and clipboard-driven execution

ClickFix attacks use a malicious page to place a payload into the clipboard and persuade the user to paste and execute it, usually via a legitimate-looking instruction. That breaks the usual process-tree clues that endpoint tools depend on, because the user appears to have manually launched the command. The technique works because it converts browser content into local execution without a direct exploit chain. In effect, the browser becomes the delivery and persuasion layer, while the endpoint sees only a normal user action. Practical implication: teams need pre-execution browser telemetry and policy controls that can flag clipboard injection before the command reaches the shell.

Practical implication: stop clipboard injection before the shell ever sees the payload.

ConsentFix and device code phishing inside OAuth flows

ConsentFix abuses the OAuth authorization flow so the attacker can obtain access tokens without stealing a password or waiting for MFA approval. Device code phishing uses a legitimate device authorization grant, tricking the user into entering a code on a real login page while the attacker completes the flow elsewhere. Both techniques exploit identity protocols as designed, then redirect them into attacker-controlled outcomes. This is why browser-only attacks are so hard to contain: the abuse happens in the same trust channel the organisation depends on for legitimate authentication. Practical implication: practitioners should review which OAuth and device-code flows are truly necessary and where browser-side detection is the only viable control plane.

Practical implication: review OAuth and device-code flows as identity attack paths, not just login features.

Threat narrative

Attacker objective: The attacker aims to obtain authenticated access that can be reused for account takeover, data access, and follow-on compromise across cloud and SaaS environments.

1. Entry occurs through a browser-delivered lure such as a fake login page, compromised website, search result, or direct message that leads the victim into the attack flow.
2. Credential access or session abuse happens when the browser relays tokens, accepts OAuth consent, or captures device codes, allowing the attacker to obtain usable identity artefacts without password theft.
3. Escalation follows when the attacker reuses the session or token to access mail, cloud apps, developer tools, or downstream services while remaining outside normal email, endpoint, and network detections.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Internet Archive breach — unsecured GitLab authentication tokens exposed 31M Internet Archive accounts.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Browser-first identity compromise has become the governance gap that IAM programmes keep underestimating. Traditional identity controls were built around login events, MFA prompts, and endpoint-visible execution, but these browser attacks exploit the space between them. The browser is now the control plane where authentication, consent, and session theft converge. Practitioners should treat browser-mediated identity abuse as a core IAM problem, not a peripheral phishing issue.

Session theft has displaced password theft as the more durable identity failure mode. AiTM techniques prove that the attacker does not need to know the password when the browser session itself can be captured and replayed. That changes how access risk should be modelled across human identity and downstream SaaS access. Teams that still anchor detection and response on credential reuse are measuring the wrong artefact.

Browser-based attack chains create identity blast radius across human, NHI, and delegated access paths. A compromised session can be used to authorise tools, trigger consent, or reach administrative workflows that were never meant to be exposed through the browser. The named concept here is browser identity blast radius: the amount of downstream access an attacker can unlock once browser-mediated trust is compromised. Practitioners should treat that blast radius as a governance boundary, not just a technical one.

Device code phishing shows that phishing-resistant factors are not a universal end state when protocol choice is the weak point. The attack does not defeat authentication by force, it routes around it by abusing a legitimate grant flow that many users already trust. That is a reminder that identity assurance is only as strong as the protocol boundary underneath it. The implication is that governance must move upstream into flow selection, not just factor selection.

Browser-layer detections are becoming a prerequisite for modern identity defence. Email, proxy, and EDR controls all lose coverage once the lure, redirect chain, and identity action occur inside the browser. This is especially relevant for developer-heavy environments and BYOD estates where endpoint certainty is uneven. Practitioners should align control design to the actual attack surface, not to the historical control stack.

From our research:

• 1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months, according to The State of Non-Human Identity Security.
• 45% of organisations cite lack of credential rotation as the top cause of NHI-related attacks, followed by inadequate monitoring and logging at 37% and over-privileged accounts at 37%.
• For a broader control lens, read 52 NHI Breaches Analysis to see how governance failures map to real compromise patterns.

What this signals

Browser identity blast radius: once the browser becomes the place where authentication, consent, and token replay happen, programme boundaries need to shift from device-centric thinking to session-centric governance. Teams should expect more attacks to resemble identity misuse than malware delivery.

The practical signal for practitioners is that browser-layer telemetry will matter more as developer tools, SaaS admin consoles, and OAuth consent journeys continue to converge. The control objective is not only preventing login compromise, but limiting how far a stolen browser session can travel before it is contained.

For practitioners

• Map browser-mediated identity flows Inventory which authentication, consent, and device-code journeys are reachable through the browser, then mark the ones that bypass email, EDR, or proxy visibility. Prioritise the flows that can issue usable tokens without a password prompt.
• Add pre-execution browser controls Detect clipboard injection, suspicious redirects, and page content that instructs users to paste commands before the payload is executed. This is the control point that matters for ClickFix-style attacks.
• Review OAuth and device-code exposure Limit which apps and users can approve OAuth consent, and reduce unnecessary device-code reliance in developer and admin workflows. Where the flow is required, pair it with conditional access and browser-layer telemetry.
• Rebuild response around session theft Treat token theft and session replay as the primary incident pattern, then define containment steps that revoke sessions, not just reset passwords. That shortens the time attackers can use captured browser identity artefacts.

Key takeaways

• Browser attacks are now identity attacks, because the browser is where tokens, consent, and session reuse are being abused.
• The scale is accelerating, with ClickFix and device code phishing showing how quickly new browser techniques can become common entry paths.
• Teams need browser-aware detection, tighter OAuth governance, and faster session revocation to reduce blast radius.

Key terms

• Adversary-in-the-middle phishing: A phishing method that places an attacker between the user and the real identity provider so the attacker can intercept or relay the authenticated session. It often preserves the user experience, which is why it can evade awareness and some detection paths while still producing usable session tokens.
• ClickFix: A browser-delivered social engineering technique that persuades a user to paste and execute a malicious command, usually through clipboard manipulation and a fake instruction sequence. The key risk is that the endpoint may see a normal user action even though the payload originated from a hostile webpage.
• Device code phishing: An identity attack that abuses the device authorization flow by tricking a user into entering a code on a legitimate login page while the attacker completes the flow elsewhere. It is effective because it relies on a real authentication protocol and can bypass password theft and familiar MFA prompts.
• Browser identity blast radius: The downstream access an attacker can unlock once browser-mediated trust is compromised, including sessions, tokens, consent grants, and administrative workflows. The term helps teams think about how far a browser compromise can travel before containment, especially in SaaS and developer-heavy environments.

Deepen your knowledge

Browser-based identity attack detection is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is trying to govern sessions, consent, and token reuse across human and non-human access, it is worth exploring.

This post draws on content published by Push Security: browser-based attack techniques defining the 2026 threat landscape. Read the original.