Man-in-the-browser attacks expose browser identity trust gaps

At a glance

What this is: This is an analysis of man-in-the-browser attacks and how browser-injected malware can steal or alter sensitive sessions.

Why it matters: It matters because identity and access teams still rely on browser sessions, MFA, and transaction trust signals that can be manipulated after login across human, NHI, and autonomous access paths.

👉 Read 1Kosmos's analysis of man-in-the-browser identity risk and prevention

Context

Man-in-the-browser attacks are a browser-layer identity threat, not just a malware problem. Once malicious code lands in the browser through a plugin, extension, or trojan, it can observe or alter what a user thinks they are sending to a website and can defeat assumptions that authentication alone secures the session.

For IAM teams, the issue is that browser trust is often treated as if it extends across the full session lifecycle. That assumption breaks once an attacker can intercept form submissions, modify transactions, or replay captured data after the user has already authenticated.

This makes the topic relevant to human identity controls first, but it also has governance lessons for any workflow that trusts a client-side session to remain intact after login. Browser integrity, transaction assurance, and out-of-band verification become identity controls, not just endpoint hygiene.

Key questions

Q: How should security teams reduce man-in-the-browser risk for critical user sessions?

A: Use managed browsers, extension allowlists, and out-of-band verification for sensitive actions. The goal is to prevent browser compromise from becoming transaction compromise. MFA still matters, but it should be paired with device integrity checks and separate approval channels so that a hijacked browser cannot both submit and confirm the action.

Q: Why do browser-based attacks bypass traditional login controls?

A: Because the attack happens after authentication, inside the browser session itself. Traditional login controls prove who signed in, not whether the browser later altered the request, captured the credential, or rewrote the transaction. That is why session integrity and action verification must be designed as separate controls.

Q: What do organisations get wrong about MFA in browser attack scenarios?

A: They assume MFA ends the risk once login succeeds. In man-in-the-browser attacks, the attacker can still intercept input or modify actions after authentication. MFA should therefore be treated as one layer, not the final control, and high-risk workflows need a second trust signal outside the browser.

Q: How can teams verify that browser sessions remain trustworthy during sensitive actions?

A: Look for independent confirmation of the action outside the browser, plus device integrity and extension governance on the endpoint. If the same session both requests and approves the change, trust is weak. Separate channels and managed endpoints give you better evidence that the action was not altered in transit.

Technical breakdown

How browser injection enables man-in-the-browser attacks

Man-in-the-browser attacks begin when malware, often delivered through phishing, an infected plugin, or a trojanized file, embeds itself inside the browser process or its extension layer. From there it can observe page content, intercept keystrokes, and alter requests before they reach the destination site. Unlike network interception, the attacker does not need to break transport encryption because the browser itself becomes the collection point. That makes the attack especially effective against sites that assume HTTPS and a valid login session mean the exchange is trustworthy.

Practical implication: treat browser integrity checks and extension control as part of identity assurance.

Why transaction manipulation survives normal authentication

MitB attacks work because authentication happens before the malicious manipulation, not after it. Once the browser is compromised, the attacker can change form fields, inject fraudulent payment details, or rewrite what the user sees while leaving the server-side session apparently valid. This is why MFA alone does not fully solve the problem. The user may authenticate legitimately, but the browser can still be coerced into sending altered data or stolen credentials to the attacker’s server.

Practical implication: add transaction verification that is separate from the compromised browser session.

Why out-of-band verification matters for browser-based identity

Out-of-band authentication reduces the attacker’s ability to reuse the same compromised path for both login and approval. In practice, this means using a second channel or separate trust device to confirm high-risk actions, especially for payments, password resets, and privileged changes. Browser-based identity flows are fragile when the same endpoint handles both the prompt and the approval because malicious code can tamper with both. A stronger model verifies intent outside the infected execution context.

Practical implication: use a separate verification channel for high-risk actions rather than relying on browser-only approval.

Threat narrative

Attacker objective: The attacker aims to harvest credentials or manipulate financial transactions without alerting the user or the website.

1. Entry occurs when the victim installs a malicious plugin, opens a trojanized file, or is phished into executing browser-infecting malware.
2. Credential capture begins when the malicious code sits inside the browser and monitors logins, form submissions, and transaction data in real time.
3. Impact follows when the attacker steals credentials, alters payment details, or injects spoofed requests that redirect money or sensitive data to attacker-controlled systems.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• JetBrains GitHub plugin token exposure — CVE-2024-37051 in JetBrains IntelliJ GitHub plugin exposed GitHub access tokens.

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 trust is the broken premise behind man-in-the-browser attacks. Authentication frameworks often assume that once a user passes login, the browser session remains a trustworthy execution environment. MitB malware invalidates that assumption because the browser itself becomes the attacker’s control point. The practitioner implication is that session success is not the same as session integrity.

Out-of-band verification is an identity control because it breaks the attacker’s same-channel advantage. If the approval path and the compromised browser path are the same, the attacker can rewrite both the action and the confirmation. That is why transaction signing, device-bound confirmation, and separate approval paths matter for high-risk actions. Practitioners should design for intent verification outside the browser context.

Man-in-the-browser attacks expose the gap between authentication strength and transaction assurance. MFA can prove the right user or device was present at login, but it does not prove the browser remained unmodified during the session. That distinction matters for banking, e-commerce, and any workflow that treats post-login browser state as trusted. Teams should separate login assurance from action assurance.

Client-side compromise is a human IAM issue with wider lifecycle lessons. Browser compromise can hijack human access today, but the governance pattern echoes across NHI and autonomous workflows whenever the client or agent runtime is assumed to stay stable after authentication. The named concept here is session integrity collapse: the trusted session is no longer trustworthy once execution context is compromised. Practitioners should treat runtime integrity as part of access governance.

From our research:

• 88.5% of organisations acknowledge that their non-human IAM practices lag behind or are merely on par with their human identity and access management efforts, according to The 2024 Non-Human Identity Security Report.
• Only 19.6% of security professionals express strong confidence in their organisation's ability to securely manage non-human workload identities.
• For related context, review The 52 NHI breaches Report for patterns that connect credential exposure, lifecycle failure, and session abuse.

What this signals

Session integrity collapse: browser attacks show that identity programmes cannot stop at authentication outcomes. The next maturity step is to govern the trustworthiness of the client context that carries the session, especially when the same device both requests and confirms high-risk actions.

With only 19.6% of security professionals strongly confident in their organisation's ability to securely manage non-human workload identities, the broader governance lesson is clear: access assurance is increasingly about runtime conditions, not just provisioning state. That applies to human sessions first, and then to machine and agent workflows that inherit the same assumptions.

Teams that already align with NIST SP 800-207 Zero Trust Architecture should extend the verify-every-request mindset into browser-mediated approval flows. The practical shift is to treat high-risk transactions as separate trust events, not as a continuation of the login ceremony.

For practitioners

• Restrict browser extension exposure Limit approved extensions to a managed allowlist, remove unused add-ons, and block sideloaded plugins on devices that handle financial, privileged, or administrative access. Review extension provenance and permissions as part of endpoint governance, not as an afterthought.
• Separate login from transaction approval Use an out-of-band approval path for high-risk actions such as payments, password resets, and privilege changes. The approval step should not reuse the same browser session that submitted the request.
• Harden browser-based identity workflows Add device integrity signals, step-up checks, and transaction verification for sensitive workflows that begin in the browser. Where possible, bind approvals to a second device or a separate trusted channel instead of relying on the same endpoint.
• Treat phishing as an execution-path risk Train users to avoid unknown attachments and links, but back that training with technical controls that prevent trojanized files and untrusted downloads from reaching managed endpoints in the first place.

Key takeaways

• Man-in-the-browser attacks succeed because they compromise the browser execution context after login, not because authentication is weak by itself.
• The scale of the control gap is visible in the confidence problem across identity governance, where human, machine, and session trust are still not managed as one runtime issue.
• Out-of-band approval, browser hardening, and session integrity checks are the controls that meaningfully reduce the blast radius of browser-layer identity abuse.

Key terms

• Man-in-the-Browser Attack: A man-in-the-browser attack is malware that lives inside a user’s browser and can observe, change, or replay data before it reaches a website. It bypasses many network-layer defenses because the browser itself becomes the interception point rather than the connection between systems.
• Session Integrity: Session integrity is the degree to which a logged-in session remains trustworthy after authentication. In browser attacks, it depends on the client environment staying unmodified, which is why endpoint control, approved extensions, and separate verification channels matter so much.
• Out-of-Band Authentication: Out-of-band authentication verifies an action through a separate trust channel from the one used to initiate it. It is especially useful when the primary channel may be compromised, because the attacker has to control two different paths instead of one.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or governance in your organisation, it is worth exploring.

This post draws on content published by 1Kosmos: Man-in-the-browser attacks and browser identity trust gaps. Read the original.