By NHI Mgmt Group Editorial TeamBased on Push Security: “7 things we learned from ‘Why the browser is the new battleground’ with John Hammond” (May 19, 2026)

TL;DR: Browser-based attacks such as AiTM phishing, ClickFix, ConsentFix, and device code phishing are moving faster than defenses, with ClickFix becoming Microsoft’s most common initial access vector in about a year and device code phishing jumping from near-zero to at least 12 kits, according to Push Security. Traditional email, endpoint, and network controls are losing coverage because the attack and the identity workflow now happen inside the browser.


At a glance

What this is: This webinar recap argues that browser-based attack techniques are now bypassing identity controls by living inside the browser rather than on the network or endpoint.

Why it matters: It matters because IAM, MFA, OAuth, and session controls can lose visibility when the attack path and the identity transaction happen in the same client-side surface.

By the numbers:

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

Context

Browser-based attack techniques are a governance problem because they collapse the distance between lure, authentication, and session theft. When credential capture, consent abuse, or device-code entry all happen inside the browser, the normal checkpoints that teams rely on can miss the event entirely.

This article focuses on the identity control gap created when attacks are delivered and executed in the same browser surface used for sign-in and authorization. For IAM teams, the question is no longer whether MFA exists, but whether the control plane still sees the transaction when the browser becomes the attack venue.


Key questions

Q: What breaks when identity controls stop at the endpoint and ignore the browser session?

A: Browser-native attacks can complete authentication, steal tokens, and trigger consent without host-level malware or suspicious process activity. That means the organisation may see a clean endpoint while the attacker already holds a valid session. The control failure is not endpoint weakness alone, but a missing governance boundary around where identity actions actually occur.

Q: Why do phishing frameworks that bypass MFA remain such a serious threat to identity security?

A: Phishing frameworks that bypass MFA are dangerous because they defeat a control many teams treat as a final barrier. If an attacker can capture a session or intercept the authentication flow, stolen credentials can still become usable access. That increases the risk of mailbox compromise, internal impersonation, and follow-on fraud, especially when privileged or high trust accounts are involved.

Q: What signs show that endpoint or email controls are missing browser-delivered identity attacks?

A: A common indicator is a clean mail queue paired with suspicious browser activity, unexpected OAuth grants, or sign-ins that originate from normal-looking web interactions. Another signal is user execution that looks manual, such as clipboard-paste commands or device-code entry, because the endpoint may classify the behaviour as ordinary user activity unless browser telemetry is present.

Q: How should teams govern OAuth consent and device-code authentication safely?

A: Treat both as privileged identity pathways, not convenience features. Limit who can grant consent, monitor high-risk app approvals, and decide when device-code flow is acceptable in the enterprise. The goal is to govern the browser-mediated trust decision itself, because the attack succeeds when the user interaction looks legitimate but the resulting token is not.


Technical breakdown

Why browser-native attacks bypass traditional identity controls

Browser-native attacks evade controls because the attacker no longer needs a separate malware dropper, a suspicious network destination, or a visible endpoint payload. AiTM phishing proxies the real login flow and steals session tokens in real time. ClickFix uses the browser to deliver a command the user pastes and runs manually, which weakens process-tree based detections. ConsentFix and device code phishing stay inside OAuth and browser interactions, so the security stack often sees only legitimate-looking traffic and valid authentication artefacts.

Practical implication: move detection closer to browser behaviour, not just email, network, or endpoint telemetry.

How OAuth flows become the attack surface

OAuth-based attacks exploit the fact that modern identity systems trust consent, device codes, and redirect flows once they are initiated in the right context. ConsentFix abuses the browser-mediated authorization path to obtain tokens without handling a password or MFA prompt. Device code phishing uses the device authorization grant, which was designed for constrained devices but is now common in enterprise CLI workflows. The weakness is not OAuth itself, but the assumption that user intent is reliably readable from the browser exchange.

Practical implication: review OAuth consent, device-code use, and browser-mediated token issuance as first-class identity risks.

Why endpoint and email controls lose coverage

Email gateways miss attacks when the lure is delivered through search, social platforms, compromised sites, or direct messages. EDR can miss ClickFix because the user appears to run the command manually, and it may see nothing at all in browser-only techniques like ConsentFix or device-code phishing. Network tools are limited because the malicious content is embedded in page logic, redirects, or client-side workflows rather than an obviously malicious payload in transit. The result is a control gap between delivery, identity interaction, and verification.

Practical implication: test whether your detection stack can see client-side identity abuse before assuming your current controls are sufficient.


Threat narrative

Attacker objective: The attacker wants authenticated access to enterprise accounts and downstream SaaS or identity resources without triggering the user's normal MFA expectations.

  1. Entry begins with browser-delivered lures that arrive through search, social messaging, compromised websites, or legitimate-looking redirects rather than through email alone.
  2. Credential access or token capture occurs inside the browser through AiTM token interception, OAuth consent abuse, or device code entry on a legitimate login page.
  3. Impact follows when the attacker uses the stolen session or token to access enterprise applications with the victim's authenticated context still intact.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.


NHI Mgmt Group analysis

Browser-mediated identity trust is now the primary control boundary: The browser is no longer just a delivery channel for identity events. It is where the lure, the user action, the authentication exchange, and the token handoff now converge. That changes the control boundary for IAM teams, because browser behaviour has become part of the trust decision itself. Practitioners should treat browser-layer observability as identity governance, not just endpoint hardening.

Access review processes were designed for identities that persist long enough to be reviewed: That assumption fails when the compromise is completed in-session and the stolen artefact is a live token rather than a durable credential. The implication is not that reviews become useless, but that they no longer describe the full risk surface when browser-based theft bypasses the review window.

Consent and device-code abuse expose a browser-shaped governance gap: OAuth consent screens and device-code prompts can look legitimate even when they are being weaponised. This is not a patchable nuisance at the edge of the stack. It is a structural problem in how identity teams interpret user intent across browser-mediated flows, and practitioners need controls that evaluate the transaction context, not just the authentication outcome.

Identity controls that depend on network reputation are increasingly under-specified: The article shows attackers chaining legitimate services, redirects, and compromised sites to reach the credential or token harvest stage. That weakens the old assumption that bad identity events travel through obviously bad infrastructure. The governance lesson is that authenticity of destination no longer proves legitimacy of intent.

Browser attack techniques now define a named concept: browser-layer identity bypass: This is the point where identity assurance fails because the browser becomes both the delivery mechanism and the authorization surface. Once that happens, MFA, endpoint, and email controls can each look present while the attacker still completes the transaction. Practitioners should frame this as a control-plane visibility problem, not only a phishing problem.

What this signals

Browser-layer identity bypass: Security teams need to assume that authentication can now be abused at the same layer where users read, click, paste, and approve. That means browser telemetry, token governance, and OAuth oversight belong in the identity programme, not only the endpoint stack.

The immediate governance challenge is not just to block known phishing pages, but to understand which workflows let attackers complete the identity transaction without tripping the controls you already trust.


For practitioners

  • Instrument browser-layer detections Add telemetry for browser-side redirects, consent prompts, clipboard injection, and device-code behaviour so identity abuse is visible before token issuance or command execution completes.
  • Review OAuth consent exposure Tighten governance around consent grants, especially for user-driven app approvals and device-code workflows that can complete without a password or phishing-resistant factor challenge.
  • Harden executive and developer workflows Assume high-value users will be targeted through search, messaging, and compromised websites, and tune monitoring for browser-delivered lures that never touch the mail gateway.
  • Validate EDR coverage gaps Test whether manual-paste attacks, Run-dialog execution, and browser-only identity abuses are actually visible in your endpoint controls, especially on BYOD and contractor systems.

Key takeaways

  • Browser-native attacks compress delivery and identity abuse into one surface, which reduces the value of controls that only inspect email, network, or endpoint artefacts.
  • OAuth consent abuse and device-code phishing show that legitimate-looking browser interactions can still produce dangerous tokens and sessions.
  • Practitioners should treat browser observability, consent governance, and token-level oversight as core identity controls rather than optional add-ons.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Non-Human Identity Top 10NHI-04 — Insecure AuthenticationThe article centers on browser-based authentication abuse and token theft.
NHI-10 — Human Use of NHIUsers are tricked into completing identity actions that should not depend on manual browser behaviour.
Recommendation — Map browser-mediated auth paths to NHI-04 and verify where session theft can bypass normal MFA flows. Limit human-mediated steps in NHI flows and remove browser prompts that let attackers steer consent or code entry.
MITRE ATT&CKTA0006;TA0001 — Credential Access; Initial AccessThe techniques described focus on initial access through phishing and credential or token capture.
Recommendation — Track browser-delivered phishing and token theft against TA0001 and TA0006 in your detection engineering.
NIST CSF 2.0PR.AA-05 — Access Permissions, Entitlements and AuthorizationsOAuth consent and token issuance are authorisation decisions central to this article.
Recommendation — Review authorisation grants and token scopes under PR.AA-05 for browser-mediated identity workflows.
NIST SP 800-53 Rev 5IA-5 — Authenticator ManagementThe article shows how authenticator handling and session tokens can be abused in the browser.
Recommendation — Apply IA-5 to govern token lifecycle and reduce reliance on browser-visible authenticator handling.

Key terms

  • Browser-Mediated Authentication: An access model where the browser helps enforce identity checks before the target application is reached. It is useful for brittle or legacy systems because the security controls sit outside the app while still shaping user access.
  • AiTM Phishing: Adversary-in-the-middle phishing inserts attacker infrastructure between the victim and the real login service. The attacker relays the login in real time, captures the issued token, and bypasses MFA by stealing the authenticated session rather than guessing the password.
  • 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.
  • Consent Abuse: Consent abuse occurs when an attacker convinces a user or admin to approve a malicious or overbroad application. The resulting authorization appears legitimate, which makes it harder for password or MFA controls to stop unauthorized data access once the app is approved.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
NHIMG Editorial Note
Published by the NHIMG editorial team on June 9, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org