A man-in-the-browser (MitB) attack is a form of malware that embeds itself inside a victim's web browser -- as a rogue extension, a hijacked plugin, or a banking trojan such as Zeus, SpyEye, or Dyre -- and then rewrites web transactions in real time before the data is ever encrypted for transit. Because the malware operates inside the browser process itself, it sees form fields, session tokens, and one-time passcodes in plaintext, and can alter what the user sees on screen while sending different instructions to the server behind the scenes. This is why MitB is the technique behind some of the largest banking-fraud campaigns of the last two decades, including the 2012 "Operation High Roller" wave that attempted to move at least $78 million out of more than 60 financial institutions. Below, we break down how the attack works, how it differs from a man-in-the-middle attack, and what it takes to detect and stop it.
How Does a Man-in-the-Browser Attack Work?
A man-in-the-browser attack works by injecting malicious code directly into the browser's DOM and API layer so it can read and rewrite a transaction after the user submits it but before the browser encrypts and sends it over TLS. The malware typically arrives as a Browser Helper Object (BHO), a malicious browser extension, an API hook injected via a DLL, or a modified JavaScript library loaded through a compromised ad network or third-party script. Once resident, it waits for the victim to visit a targeted site -- historically online banking portals, but increasingly SaaS admin consoles and crypto exchanges -- and then performs what security researchers call "form grabbing" and "transaction re-writing." For example, a victim might type a $500 transfer to a known payee; the malware silently changes the destination account and amount to $8,500 to an attacker-controlled account, then shows the victim a confirmation screen reflecting the original $500 transfer. Because the substitution happens client-side, after decryption but before submission, HTTPS and even hardware tokens provide no protection: the channel is secure, but the endpoint is compromised.
How Is a Man-in-the-Browser Attack Different From a Man-in-the-Middle Attack?
A man-in-the-browser attack differs from a man-in-the-middle (MitM) attack in where the interception happens: MitB compromises the browser endpoint itself, while MitM intercepts traffic somewhere on the network path between two otherwise uncompromised endpoints. A classic MitM attacker -- for instance, someone running a rogue Wi-Fi access point or exploiting a weak TLS configuration -- has to defeat encryption to read or modify traffic, which is why HSTS, certificate pinning, and TLS 1.3 significantly raise the cost of MitM. MitB attackers skip that problem entirely by operating after decryption, inside the trusted application, so the transaction looks legitimate to every network-layer control, including VPNs and TLS inspection proxies. This distinction matters for defenders: network segmentation, VPN policy, and certificate hygiene -- the standard MitM mitigations -- do essentially nothing against a MitB infection, because the attacker is never on the network path at all.
What Malware Families Have Used Man-in-the-Browser Techniques?
The best-documented MitB malware families are Zeus, SpyEye, Carberp, Tinba, Dyre, and Gozi/Ursnif, each targeting browsers on infected Windows endpoints between roughly 2007 and 2016. Zeus (also called Zbot) first appeared in 2007 and became the dominant banking trojan of its era; when its source code leaked in 2011, it spawned dozens of variants, including Citadel and Ice IX, that financial-crime researchers tracked for years afterward. SpyEye, Zeus's main rival, led to the 2016 sentencing of its creator, Aleksandr Panin, to 9.5 years in U.S. federal prison after the FBI attributed hundreds of millions of dollars in losses to the tool. Tinba (Tiny Banker), discovered in 2012, was notable for packing full MitB web-injection capability into a binary as small as 20 KB. Dyre (also known as Dyreza), active through 2014-2015, added a twist by also targeting corporate employees -- including a 2015 campaign against Salesforce.com users -- rather than only retail banking customers, foreshadowing today's shift toward MitB attacks against SaaS and enterprise identity portals.
How Do Man-in-the-Browser Attacks Bypass Two-Factor Authentication?
Man-in-the-browser attacks bypass two-factor authentication (2FA) by capturing the one-time passcode after the user enters it and reusing it in real time, rather than by breaking the cryptography behind the code itself. In a typical flow, the malware detects that the target site is requesting an SMS or app-based OTP, presents the user with a normal-looking prompt, captures the code the instant it's typed, and immediately relays it -- along with an already-modified transaction -- to the real banking or SaaS backend within the code's validity window (usually 30-60 seconds). Some variants go further with "man-in-the-mobile" companion malware that intercepts the SMS OTP directly on the victim's phone, closing the loop without any user action at all. This is precisely why security teams increasingly favor FIDO2/WebAuthn hardware keys over OTP-based 2FA: WebAuthn cryptographically binds the authentication response to the specific origin and session, which a browser-resident trojan cannot forge or replay the way it can a six-digit code.
What Are Real-World Examples of Man-in-the-Browser Attacks?
Real-world MitB campaigns have moved tens of millions of dollars in single operations and have expanded well beyond retail banking. In "Operation High Roller," documented by McAfee and Guardian Analytics in 2012, automated MitB scripts attempted to transfer at least $78 million -- with exposure estimated as high as $2.5 billion -- out of commercial accounts at more than 60 institutions across Europe, the United States, and Latin America, with minimal human involvement on the attacker's side. The 2015 Dyre campaign against Salesforce.com specifically targeted employees with financial-approval access, showing that MitB is as viable against enterprise SaaS as against consumer banking. More recently, malicious browser extensions distributed through official extension stores -- several pulled from the Chrome Web Store in incidents reported between 2018 and 2023 -- have used the same in-browser injection and form-grabbing techniques to harvest session cookies and credentials from millions of installs before discovery, proving the technique has outlived the banking-trojan era that popularized it.
How Can Organizations Detect and Prevent Man-in-the-Browser Attacks?
Organizations can detect and prevent man-in-the-browser attacks by controlling what code is allowed to run inside the browser, monitoring for anomalous DOM and API-hooking behavior, and removing static secrets that a compromised endpoint could replay. Concretely, that means enforcing browser extension allowlists managed centrally (rather than trusting store review alone), deploying endpoint detection and response (EDR) tooling that flags DLL injection and API hooking in browser processes, and moving high-value transactions to out-of-band confirmation -- a phone call or a signed push approval on a separate device -- rather than an in-browser OTP prompt. On the authentication side, migrating from SMS/OTP 2FA to FIDO2/WebAuthn removes the specific bypass MitB relies on, since the cryptographic assertion is bound to the origin and cannot be replayed by injected code. For engineering organizations, the same discipline extends upstream: any third-party JavaScript, ad-tech snippet, or npm-sourced browser library pulled into a web application is a potential MitB delivery vector, so treating client-side dependencies with the same scrutiny as server-side ones -- pinned versions, subresource integrity, and regular composition audits -- closes off one of the most common infection paths before it reaches a single end user.
How Safeguard Helps
Safeguard extends this same scrutiny to the software supply chain that ships browser-facing code in the first place. Our SBOM generation and ingest pipeline catalogs every client-side JavaScript dependency and third-party library bundled into your web applications, so a vulnerable or trojanized package used to deliver MitB-style injection doesn't ship unnoticed. Reachability analysis then determines whether a flagged dependency is actually exercised in a code path reachable from the browser, cutting through alert noise so security teams can prioritize the packages that genuinely expose users to injection or credential-harvesting risk. Griffin AI correlates those findings against real exploitation patterns -- including known MitB and session-hijacking malware behavior -- to separate theoretical CVEs from active threats. When a fix is available, Safeguard opens an auto-fix pull request that bumps the affected dependency to a patched version, so the vulnerable code path is closed before it ever reaches production or a customer's browser.