Browser in the Browser: How BitB Phishing and Evilginx Slip Past MFA and common sense
Starter draft. The frontmatter above is complete and drives the page title, byline, index card, and social preview. Replace the body below with your own writing — the headings are a suggested defensive-awareness outline, not final copy. Keep it conceptual: explain the mechanism and the defense, not a deployable kit.
The comfort that isn't
Most people have been trained on two rules: check the address bar, and turn on MFA. Both are good advice. Neither is sufficient anymore. Two well-known techniques take those exact habits and turn them against the user — one attacks the address bar, the other attacks the session behind it.
Browser in the Browser (BitB)
Evilginx and adversary-in-the-middle (AitM)
Why MFA doesn't save you here
What actually stops it
- Phishing-resistant MFA (FIDO2 / WebAuthn / passkeys). The authenticator is cryptographically bound to the real origin. A proxy on a look-alike domain gets a different origin, so the challenge simply won't sign — the one control that breaks the AitM relay instead of merely slowing it.
- The "drag test" for popups. A login popup that can't leave the browser window is not a real window.
- URL discipline that doesn't rely on eyeballs — password managers that refuse to autofill on the wrong domain, bookmarks over links, and conditional-access / device posture checks.
- Detection on the defender side — new-domain + reverse-proxy heuristics, impossible travel, and session-token binding.