Man-in-the-browser is malware that lives inside the victim's own browser and quietly rewrites web sessions in real time, changing the payee or the amount of a payment while still showing the victim the screen they expect. Because it operates inside an already-logged-in session, it defeats passwords and many one-time-code controls without the victim noticing anything is wrong.
What is man-in-the-browser, in plain English?
Man-in-the-browser, often shortened to MitB, is a Trojan that infects the browser itself, usually through a malicious extension or injected code. Once installed, it sits between what the user sees and what actually gets sent to the bank. The victim logs in normally, types a legitimate payment, and watches a confirmation screen that looks exactly right. Underneath, the malware has swapped the destination account and sometimes the amount before the request ever reaches the server.
The dangerous part is that it works inside a genuine, authenticated session. The customer passed login, passed multi-factor, and approved the transaction they thought they were making. Passwords do not help, because the attacker did not need them. Many one-time-code setups do not help either, because the victim willingly enters the code to approve what they believe is their own payment.
In the fraud stack, MitB is a form of session manipulation and account takeover that leaves an unusually clean trail. On the surface the payment looks fully legitimate and customer-initiated. The mismatch only shows up when you compare what the customer intended against what actually settled.
How a man-in-the-browser attack works
The attack unfolds silently around a normal banking session:
- Infect — Plant the Trojan. Malware reaches the device through a malicious browser extension, drive-by download, or phishing payload.
- Wait — Sit inside the browser. The code stays dormant until the victim visits a targeted banking or payment site and logs in normally.
- Rewrite — Alter the transaction. As the payment is submitted, the malware silently changes the beneficiary or amount before it reaches the server.
- Hide — Show the expected screen. The confirmation and statement the victim sees are rewritten to display the intended payee, hiding the theft.
How it differs from man-in-the-middle
What changes | Man-in-the-middle | Man-in-the-browser |
Where it sits | On the network between the user and the site | Inside the victim's own browser |
What it needs | Access to the traffic, such as rogue Wi-Fi | Malware installed on the endpoint |
Effect on TLS | Can be blocked by proper encryption and cert checks | Bypasses TLS because it acts after decryption in the browser |
What the victim sees | Often a real or spoofed site they think is genuine | Their real bank, with a doctored confirmation |
What it looks like in practice
In practice
A small business owner logs into online banking to pay a supplier and enters the supplier's account and an invoice amount. The confirmation page shows the correct payee and figure, so they approve it and even complete a one-time code prompt without a second thought.
What actually left the account went to a mule account the malware substituted at submission, for a slightly higher amount. The doctored on-screen statement kept showing the supplier for days. The fraud only surfaced when the real supplier chased the missing payment and the owner pulled the raw bank record.
Why it matters for operators
Man-in-the-browser is hard precisely because the transaction looks legitimate at every layer you normally trust: valid login, passed MFA, a customer who genuinely approved a payment. Static controls tuned to catch stolen credentials or new devices will wave it through. The defense has to move to signals the malware cannot easily fake: transaction signing that confirms the real beneficiary through a separate channel, behavioral biometrics that spot subtle changes in how the session behaves, and endpoint malware detection.
The practical lesson is that authentication is not the same as intent. Confirming who is logged in does not confirm that the payment leaving the account is the one the customer meant to make, which is why beneficiary confirmation and device integrity carry so much weight against this attack.
What to watch for
- Intent versus outcome. A gap between what the customer says they authorized and what actually settled is the core tell of MitB.
- Device-integrity anomalies. Unexpected browser extensions, injected scripts, or malware signatures during a session point to a compromised endpoint.
- Beneficiary swaps. Payments landing on newly seen accounts, often mule accounts, that the customer does not recognize when asked.
- Behavioral drift. Timing, mouse, and typing patterns that break from the customer's normal session profile mid-payment.
- Clean but disputed. A transaction that passed every authentication check yet the customer firmly disputes deserves a malware-aware review, not an automatic denial.
Quick questions
Does multi-factor authentication stop it?
Not reliably. Because the victim is inside a real session and believes they are approving their own payment, they willingly enter one-time codes, and the malware uses that approval for the altered transaction.
How is it different from a keylogger?
A keylogger steals credentials to use later. Man-in-the-browser does not need the credentials; it rides the victim's own live, authenticated session and rewrites the transaction as it happens.
What actually stops it?
Out-of-band transaction signing that shows the true beneficiary on a separate device, behavioral biometrics, and malware or endpoint detection. The common thread is verifying the real payment details outside the compromised browser.
Why is the fraud so hard to spot afterward?
The malware rewrites confirmation screens and sometimes statements, so the victim keeps seeing the intended payee. The theft often surfaces only when a legitimate counterparty reports a missing payment.
Is it still a common threat?
Classic banking Trojans have declined in some markets, but the technique persists through malicious extensions and injected scripts, and it remains relevant anywhere payments are approved in a browser.
Who bears the loss?
It depends on jurisdiction and the controls in place, but because the transaction is technically authorized by the customer, liability disputes are common and hinge on whether the institution offered adequate beneficiary confirmation.
Go deeper
- FTC Consumer Advice: Scams ↗ — US consumer guidance on current scams and fraud, and how to report them.
- FBI IC3 ↗ — The FBI Internet Crime Complaint Center. Fraud reporting and annual trend reports.