A man-in-the-browser attack hides inside the one piece of software almost every employee uses all day: the web browser. The malware sits between the browser and the sites it loads, so the page looks right, the padlock looks right, and the receipt looks right, while the attacker quietly rewrites what happens behind the glass.
That invisibility is what makes MitB attacks worth understanding. According to the FBI's 2025 Internet Crime Report, phishing and spoofing remained the most frequently reported cybercrime category, and phishing is the most common way MitB malware reaches a victim's machine. This article explains how man-in-the-browser attacks work, how they differ from man-in-the-middle attacks, and which controls actually stop them.
What is a man-in-the-browser attack?
A man-in-the-browser (MitB) attack is a cyberattack in which malware infects a victim's web browser and intercepts or alters the data exchanged between that browser and the websites the victim visits. Attackers typically aim it at online banking, payment portals, and other high-value web sessions to steal credentials, hijack sessions, or change transaction details in real time.
MitB is a form of adversary-in-the-middle attack, but it operates in a different place than a classic network interception. The malicious code runs inside the browser process itself, so it sees data after the browser has decrypted it and after the user has authenticated. That position is why MitB attacks can defeat controls that protect the network path, including TLS encryption and many forms of multi-factor authentication.
Why MitB attacks bypass encryption and multi-factor authentication
MitB attacks bypass encryption and MFA because they act after both have already done their job. TLS protects data in transit, and MFA verifies who is logging in, but neither control inspects what happens inside a compromised browser once the session is established.
The OWASP Foundation describes the technique plainly: a previously installed Trojan horse sits between the browser and the browser's own security mechanisms, sniffing or modifying transactions as they are formed, while still displaying the user's intended transaction on screen. The server receives a well-formed request that looks legitimate, and the user sees a confirmation that matches what they thought they submitted.
How man-in-the-browser attacks work
A man-in-the-browser attack follows four stages: infection, dormancy and monitoring, interception and manipulation, and communication with the attacker's infrastructure. Each stage is designed to keep the malware invisible to the user and to standard endpoint defenses.
Infection. The attacker delivers malware to the victim's device, usually through a phishing email, a malicious download, or a compromised browser extension. The payload is often a banking Trojan or an infostealer.
Dormancy and monitoring. The malware installs itself as a browser extension, a browser helper object, or injected code, then waits. It stays quiet until the user opens a site on its target list, such as a bank or a payment provider.
Interception and manipulation. Once the target site loads, the malware captures credentials and form data, and can rewrite page content, add input fields, or change transaction values before the browser submits them.
Command and control. The malware reports stolen data to the attacker's server and receives updated instructions, which lets the attacker adapt the campaign, add new target sites, or trigger fraudulent transfers.
Web injection: how attackers change what you see
Web injection is the technique that lets MitB malware change a page without the user noticing. The malware manipulates the page through the browser's own document object model (DOM), so it can read and rewrite form fields, insert extra input boxes, or replace a transaction receipt with the values the user expected to see.
OWASP documents the full sequence: the extension registers a handler for every page load, matches the URL against a target list, extracts form values when the user submits, modifies those values, and then rewrites the receipt page so the user sees the transaction they intended. The bank's server has no way to distinguish the altered request from a legitimate one.
Common malware families used in man-in-the-browser attacks
The best-known man-in-the-browser malware families are banking Trojans built to run inside a browser and manipulate web sessions. Most were written for Windows and spread through phishing, and several remain templates that newer campaigns still borrow from.
Zeus (Zbot). One of the most widely distributed banking Trojans, Zeus targets Windows systems and includes keystroke logging and form grabbing. It is highly customizable and has served as a base for later malware.
SpyEye. SpyEye targets major browsers including Chrome, Firefox, and Internet Explorer, and added features such as credit card autofill tools and the ability to spoof HTTPS sessions.
Citadel. A Zeus variant that specifically targets password managers, Citadel added screen recording and an advanced keylogger.
Gozi. Gozi uses web injection techniques that extend into banking fraud, ecommerce fraud, ransomware, and point-of-sale compromise.
Torpig. Torpig is a Trojan and botnet that harvests login credentials, credit card numbers, and email account details from Windows systems.
The threat has not stayed in the banking Trojan era. According to the Picus Red Report 2025, malware targeting credentials stored in password managers and browser login stores increased threefold, and 25% of analyzed malware showed behavior mapped to stealing credentials from password stores. Modern infostealers such as Lumma Stealer and RedLine follow the same logic as Zeus: get inside the browser, then take what the browser can already see.
Man-in-the-browser vs man-in-the-middle: what is the difference?
The difference between a man-in-the-browser attack and a man-in-the-middle attack is where the attacker sits. A MitB attack compromises the browser on the victim's device, while a man-in-the-middle (MitM) attack compromises the network path between the victim and the server.
Man-in-the-browser attack. The point of attack is the victim's browser process, reached through malware, a malicious extension, or injected code. The attacker sees data after decryption and after authentication, including form fields and session data. Typical targets are specific sites such as banking, payment, and ecommerce portals, and the goal is usually to steal credentials, alter transactions, or hijack a session.
Man-in-the-middle attack. The point of attack is the network path, reached through spoofing, rogue Wi-Fi, or a compromised router or proxy. The attacker sees traffic in transit between the victim and the server. Typical targets are any unencrypted or weakly validated communications, including web, email, and file transfers, and the goal is usually to eavesdrop on or modify traffic, or to downgrade a secure connection.
Both are adversary-in-the-middle techniques, and each is defeated by different controls. MitM defenses focus on the connection, while MitB defenses focus on the endpoint and on verifying transactions through a channel the browser cannot touch.
What are the warning signs of a man-in-the-browser attack?
There is usually no reliable warning sign of a man-in-the-browser attack, because the malware is built to leave the page, the URL, and the padlock looking correct. Detection therefore depends on indirect signals rather than on a user spotting something wrong on screen.
Signals worth investigating include endpoint security software flagging a Trojan, infostealer, or suspicious browser extension; a user being logged out of an account unexpectedly or locked out entirely; login notifications arriving from locations or devices the user does not recognize; a page missing elements it normally shows or displaying fields and prompts that do not belong; and bank or payment statements showing transactions the user never authorized.
Any of these signals warrants a full credential reset and an account recovery review, plus a check of active sessions. For teams that manage customer accounts, pairing that review with a structured account takeover protection process shortens the window between detection and containment.
How to prevent man-in-the-browser attacks
Preventing man-in-the-browser attacks requires layered controls across the endpoint, the browser, and the authentication flow. No single control stops MitB malware, but combining endpoint hygiene with transaction verification outside the browser removes most of the attacker's advantage.
Patch browsers, plugins, and operating systems promptly. MitB malware depends on unpatched browser and plugin vulnerabilities. Enable automatic updates and apply them without delay.
Use phishing-resistant multi-factor authentication. Push-based MFA and FIDO2 security keys or passkeys bound to a specific device are far harder for MitB malware to abuse than SMS codes or one-time passwords.
Verify transactions out of band. Confirm high-value transactions through a separate channel, such as a mobile app prompt or a signed push notification, so a compromised browser cannot approve them.
Treat email links and attachments as untrusted by default. Phishing remains the primary delivery method for MitB malware. Restrict downloads on business machines and block attachments from unknown senders.
Audit browser extensions regularly. Remove extensions that are unused, unverified, or no longer maintained. According to GitLab Threat Intelligence, a cluster of 16 malicious Chrome extensions reached at least 3.2 million users before being removed, and removal from the store does not uninstall them automatically.
Monitor accounts and transactions continuously. Review statements, watch for unexpected session activity, and investigate login alerts from unfamiliar locations.
Why out-of-band verification is the strongest control
Out-of-band (OOB) verification is the strongest practical control against man-in-the-browser attacks because it moves confirmation to a channel the malware does not control. Instead of trusting the browser to display an accurate transaction summary, the user approves the transaction on a separate device or through a cryptographically signed prompt.
OOB verification works because the malware's core trick is rewriting what the browser shows. When the approval step happens outside the browser, the attacker can alter the page but cannot alter the approval. This is also why phishing-resistant MFA matters: authentication methods that bind a credential to a specific device and origin give an attacker far less room to replay or relay a session.
How 1Kosmos reduces man-in-the-browser risk
1Kosmos reduces man-in-the-browser risk by moving authentication and transaction approval onto a device-bound identity that malware running in a browser cannot impersonate. The platform combines biometric authentication, identity proofing, and device binding, so a stolen password or a hijacked session is not enough to complete a sensitive action.
The 1Kosmos passwordless authentication platform uses SIM binding, SMS verification, and SIM card authentication to tie authentication to a specific employee phone, which means an attacker who controls the browser still does not control the credential. Authentication is identity-based rather than device-based: 1Kosmos verifies who a person is through biometrics and credential triangulation, and reports identity proofing accuracy above 99% on any device.
Privacy and architecture reinforce that model. Personally identifiable information is protected in a distributed identity architecture where encrypted data is accessible only to the user, and digital identities are stored in a private, permissioned blockchain, so there is no central credential database for attackers to breach. 1Kosmos also integrates with existing infrastructure through more than 50 out-of-the-box integrations or through its API and SDK.
For financial services teams and other organizations that process high-value transactions, that combination closes the gap MitB malware exploits. The browser can be compromised, but the identity behind the transaction still has to prove itself on a trusted device.
The bottom line on man-in-the-browser attacks
Man-in-the-browser attacks succeed because they hide inside a tool users already trust. The malware does not break encryption or steal a password at the network layer. It simply changes what the browser shows and what it sends, which is why endpoint hygiene, extension discipline, and out-of-band transaction verification matter more than any single security product.
The practical takeaway is to stop treating the browser as a trusted display. Verify identity and approve sensitive actions on a device the attacker does not control, and MitB malware loses the leverage it depends on.
Sources
FBI. (2026). Cryptocurrency and AI scams bilk Americans of billions. https://www.fbi.gov/news/press-releases/cryptocurrency-and-ai-scams-bilk-americans-of-billions
GitLab Threat Intelligence. (2025). Tech note: Malicious browser extensions impacting at least 3.2 million users. https://gitlab-com.gitlab.io/gl-security/security-tech-notes/threat-intelligence-tech-notes/malicious-browser-extensions-feb-2025/
OWASP Foundation. (n.d.). Man-in-the-browser attack. https://community.owasp.org/attacks/Man-in-the-browser_attack
Picus Security. (2025). Red report 2025: A 3X increase in credential theft while AI threats stay more hype than harm. https://www.picussecurity.com/resource/blog/red-report-2025-3x-rise-in-credential-theft
A man-in-the-browser attack hides inside the one piece of software almost every employee uses all day: the web browser. The malware sits between the browser and the sites it loads, so the page looks right, the padlock looks right, and the receipt looks right, while the attacker quietly rewrites what happens behind the glass.
That invisibility is what makes MitB attacks worth understanding. According to the FBI's 2025 Internet Crime Report, phishing and spoofing remained the most frequently reported cybercrime category, and phishing is the most common way MitB malware reaches a victim's machine. This article explains how man-in-the-browser attacks work, how they differ from man-in-the-middle attacks, and which controls actually stop them.
What is a man-in-the-browser attack?
A man-in-the-browser (MitB) attack is a cyberattack in which malware infects a victim's web browser and intercepts or alters the data exchanged between that browser and the websites the victim visits. Attackers typically aim it at online banking, payment portals, and other high-value web sessions to steal credentials, hijack sessions, or change transaction details in real time.
MitB is a form of adversary-in-the-middle attack, but it operates in a different place than a classic network interception. The malicious code runs inside the browser process itself, so it sees data after the browser has decrypted it and after the user has authenticated. That position is why MitB attacks can defeat controls that protect the network path, including TLS encryption and many forms of multi-factor authentication.
Why MitB attacks bypass encryption and multi-factor authentication
MitB attacks bypass encryption and MFA because they act after both have already done their job. TLS protects data in transit, and MFA verifies who is logging in, but neither control inspects what happens inside a compromised browser once the session is established.
The OWASP Foundation describes the technique plainly: a previously installed Trojan horse sits between the browser and the browser's own security mechanisms, sniffing or modifying transactions as they are formed, while still displaying the user's intended transaction on screen. The server receives a well-formed request that looks legitimate, and the user sees a confirmation that matches what they thought they submitted.
How man-in-the-browser attacks work
A man-in-the-browser attack follows four stages: infection, dormancy and monitoring, interception and manipulation, and communication with the attacker's infrastructure. Each stage is designed to keep the malware invisible to the user and to standard endpoint defenses.
Infection. The attacker delivers malware to the victim's device, usually through a phishing email, a malicious download, or a compromised browser extension. The payload is often a banking Trojan or an infostealer.
Dormancy and monitoring. The malware installs itself as a browser extension, a browser helper object, or injected code, then waits. It stays quiet until the user opens a site on its target list, such as a bank or a payment provider.
Interception and manipulation. Once the target site loads, the malware captures credentials and form data, and can rewrite page content, add input fields, or change transaction values before the browser submits them.
Command and control. The malware reports stolen data to the attacker's server and receives updated instructions, which lets the attacker adapt the campaign, add new target sites, or trigger fraudulent transfers.
Web injection: how attackers change what you see
Web injection is the technique that lets MitB malware change a page without the user noticing. The malware manipulates the page through the browser's own document object model (DOM), so it can read and rewrite form fields, insert extra input boxes, or replace a transaction receipt with the values the user expected to see.
OWASP documents the full sequence: the extension registers a handler for every page load, matches the URL against a target list, extracts form values when the user submits, modifies those values, and then rewrites the receipt page so the user sees the transaction they intended. The bank's server has no way to distinguish the altered request from a legitimate one.
Common malware families used in man-in-the-browser attacks
The best-known man-in-the-browser malware families are banking Trojans built to run inside a browser and manipulate web sessions. Most were written for Windows and spread through phishing, and several remain templates that newer campaigns still borrow from.
Zeus (Zbot). One of the most widely distributed banking Trojans, Zeus targets Windows systems and includes keystroke logging and form grabbing. It is highly customizable and has served as a base for later malware.
SpyEye. SpyEye targets major browsers including Chrome, Firefox, and Internet Explorer, and added features such as credit card autofill tools and the ability to spoof HTTPS sessions.
Citadel. A Zeus variant that specifically targets password managers, Citadel added screen recording and an advanced keylogger.
Gozi. Gozi uses web injection techniques that extend into banking fraud, ecommerce fraud, ransomware, and point-of-sale compromise.
Torpig. Torpig is a Trojan and botnet that harvests login credentials, credit card numbers, and email account details from Windows systems.
The threat has not stayed in the banking Trojan era. According to the Picus Red Report 2025, malware targeting credentials stored in password managers and browser login stores increased threefold, and 25% of analyzed malware showed behavior mapped to stealing credentials from password stores. Modern infostealers such as Lumma Stealer and RedLine follow the same logic as Zeus: get inside the browser, then take what the browser can already see.
Man-in-the-browser vs man-in-the-middle: what is the difference?
The difference between a man-in-the-browser attack and a man-in-the-middle attack is where the attacker sits. A MitB attack compromises the browser on the victim's device, while a man-in-the-middle (MitM) attack compromises the network path between the victim and the server.
Man-in-the-browser attack. The point of attack is the victim's browser process, reached through malware, a malicious extension, or injected code. The attacker sees data after decryption and after authentication, including form fields and session data. Typical targets are specific sites such as banking, payment, and ecommerce portals, and the goal is usually to steal credentials, alter transactions, or hijack a session.
Man-in-the-middle attack. The point of attack is the network path, reached through spoofing, rogue Wi-Fi, or a compromised router or proxy. The attacker sees traffic in transit between the victim and the server. Typical targets are any unencrypted or weakly validated communications, including web, email, and file transfers, and the goal is usually to eavesdrop on or modify traffic, or to downgrade a secure connection.
Both are adversary-in-the-middle techniques, and each is defeated by different controls. MitM defenses focus on the connection, while MitB defenses focus on the endpoint and on verifying transactions through a channel the browser cannot touch.
What are the warning signs of a man-in-the-browser attack?
There is usually no reliable warning sign of a man-in-the-browser attack, because the malware is built to leave the page, the URL, and the padlock looking correct. Detection therefore depends on indirect signals rather than on a user spotting something wrong on screen.
Signals worth investigating include endpoint security software flagging a Trojan, infostealer, or suspicious browser extension; a user being logged out of an account unexpectedly or locked out entirely; login notifications arriving from locations or devices the user does not recognize; a page missing elements it normally shows or displaying fields and prompts that do not belong; and bank or payment statements showing transactions the user never authorized.
Any of these signals warrants a full credential reset and an account recovery review, plus a check of active sessions. For teams that manage customer accounts, pairing that review with a structured account takeover protection process shortens the window between detection and containment.
How to prevent man-in-the-browser attacks
Preventing man-in-the-browser attacks requires layered controls across the endpoint, the browser, and the authentication flow. No single control stops MitB malware, but combining endpoint hygiene with transaction verification outside the browser removes most of the attacker's advantage.
Patch browsers, plugins, and operating systems promptly. MitB malware depends on unpatched browser and plugin vulnerabilities. Enable automatic updates and apply them without delay.
Use phishing-resistant multi-factor authentication. Push-based MFA and FIDO2 security keys or passkeys bound to a specific device are far harder for MitB malware to abuse than SMS codes or one-time passwords.
Verify transactions out of band. Confirm high-value transactions through a separate channel, such as a mobile app prompt or a signed push notification, so a compromised browser cannot approve them.
Treat email links and attachments as untrusted by default. Phishing remains the primary delivery method for MitB malware. Restrict downloads on business machines and block attachments from unknown senders.
Audit browser extensions regularly. Remove extensions that are unused, unverified, or no longer maintained. According to GitLab Threat Intelligence, a cluster of 16 malicious Chrome extensions reached at least 3.2 million users before being removed, and removal from the store does not uninstall them automatically.
Monitor accounts and transactions continuously. Review statements, watch for unexpected session activity, and investigate login alerts from unfamiliar locations.
Why out-of-band verification is the strongest control
Out-of-band (OOB) verification is the strongest practical control against man-in-the-browser attacks because it moves confirmation to a channel the malware does not control. Instead of trusting the browser to display an accurate transaction summary, the user approves the transaction on a separate device or through a cryptographically signed prompt.
OOB verification works because the malware's core trick is rewriting what the browser shows. When the approval step happens outside the browser, the attacker can alter the page but cannot alter the approval. This is also why phishing-resistant MFA matters: authentication methods that bind a credential to a specific device and origin give an attacker far less room to replay or relay a session.
How 1Kosmos reduces man-in-the-browser risk
1Kosmos reduces man-in-the-browser risk by moving authentication and transaction approval onto a device-bound identity that malware running in a browser cannot impersonate. The platform combines biometric authentication, identity proofing, and device binding, so a stolen password or a hijacked session is not enough to complete a sensitive action.
The 1Kosmos passwordless authentication platform uses SIM binding, SMS verification, and SIM card authentication to tie authentication to a specific employee phone, which means an attacker who controls the browser still does not control the credential. Authentication is identity-based rather than device-based: 1Kosmos verifies who a person is through biometrics and credential triangulation, and reports identity proofing accuracy above 99% on any device.
Privacy and architecture reinforce that model. Personally identifiable information is protected in a distributed identity architecture where encrypted data is accessible only to the user, and digital identities are stored in a private, permissioned blockchain, so there is no central credential database for attackers to breach. 1Kosmos also integrates with existing infrastructure through more than 50 out-of-the-box integrations or through its API and SDK.
For financial services teams and other organizations that process high-value transactions, that combination closes the gap MitB malware exploits. The browser can be compromised, but the identity behind the transaction still has to prove itself on a trusted device.
The bottom line on man-in-the-browser attacks
Man-in-the-browser attacks succeed because they hide inside a tool users already trust. The malware does not break encryption or steal a password at the network layer. It simply changes what the browser shows and what it sends, which is why endpoint hygiene, extension discipline, and out-of-band transaction verification matter more than any single security product.
The practical takeaway is to stop treating the browser as a trusted display. Verify identity and approve sensitive actions on a device the attacker does not control, and MitB malware loses the leverage it depends on.
Sources
FBI. (2026). Cryptocurrency and AI scams bilk Americans of billions. https://www.fbi.gov/news/press-releases/cryptocurrency-and-ai-scams-bilk-americans-of-billions
GitLab Threat Intelligence. (2025). Tech note: Malicious browser extensions impacting at least 3.2 million users. https://gitlab-com.gitlab.io/gl-security/security-tech-notes/threat-intelligence-tech-notes/malicious-browser-extensions-feb-2025/
OWASP Foundation. (n.d.). Man-in-the-browser attack. https://community.owasp.org/attacks/Man-in-the-browser_attack
Picus Security. (2025). Red report 2025: A 3X increase in credential theft while AI threats stay more hype than harm. https://www.picussecurity.com/resource/blog/red-report-2025-3x-rise-in-credential-theft
About the author
1Kosmos
1Kosmos enables remote identity verification and passwordless multi-factor authentication for users to securely transact with digital services.
The latest in identity security.
Enter our orbit.
The latest in identity security.
Enter our orbit.
The latest in identity security.
