Man-in-the-Browser Attack

A man-in-the-browser (MitB) attack places malicious code inside the victim's own browser — typically via a trojan, a malicious or hijacked browser extension, or an injected script — where it can read and rewrite web pages in real time. Unlike a classic man-in-the-middle attack, which intercepts traffic on the network, a man-in-the-browser sits after every network protection: inside the decrypted, authenticated session, with the same view of the page as the user.

How it works

The implant waits for the user to visit a targeted site, most classically online banking. Because it operates between the browser's rendering engine and the user, it can do two things at once: alter what is submitted (changing the payee and amount of a transfer after the user clicks confirm) and alter what is displayed (showing the user the transaction they intended, and doctoring the balance afterward so nothing looks wrong). Banking trojan families such as Zeus and SpyEye made this technique infamous with configurable "webinject" files that tailored the manipulation to specific banks. The defining property is that encryption and authentication do not help: TLS is intact, the password was real, and any MFA challenge was completed by the genuine user — on a transaction they could not see had been modified.

Modern variants increasingly arrive through the extension layer rather than a classic endpoint infection, which is why browser extension governance has become part of the defense.

How to defend against it

Keep endpoints and browsers patched with reputable anti-malware in place, and govern extensions centrally — inventory, allowlist, and flag high-risk permissions such as scripting on all sites. On the process side, use out-of-band verification for high-value actions: a transfer confirmation that shows the payee and amount through a second channel (such as a banking app push) defeats in-browser manipulation, since the implant cannot rewrite what another device displays. Train finance and treasury staff that "the website showed the right details" is not proof those details were sent — the same lesson that callback verification teaches for session hijacking and payment fraud.