Hace años que nos enseñan a mirar la URL antes de escribir nuestras credenciales. Los ataques Browser in the Browser explotan un problema sutil de ese consejo: ¿y si la barra de direcciones que estás mirando también es falsa?
La mayoría de las páginas de phishing intentan imitar un sitio legítimo.
Copian el logo, los colores, la tipografía, los formularios, los botones y la disposición general de servicios que ya conocemos. Pero tradicionalmente hubo una parte especialmente difícil de falsificar para el atacante: el navegador mismo.
Podés clonar una página de login, pero la barra de direcciones real del navegador sigue diciéndole al usuario dónde está parado de verdad.
Browser in the Browser, que suele abreviarse BitB, cambia eso.
En lugar de clonar solamente un sitio, el atacante crea algo que parece una ventana de navegador aparte dentro de la propia página web, con su barra de título, sus controles, su candado y —lo más importante— una barra de direcciones convincente que muestra un dominio de aspecto legítimo.
La trampa es simple:
Nada de esa interfaz pertenece al navegador. Es parte de la página web.
La técnica se hizo conocida en marzo de 2022, cuando el investigador de seguridad mr.d0x publicó una demostración que mostraba cómo recrear los popups de autenticación habituales del navegador usando tecnologías web comunes.
La idea resultó especialmente efectiva porque los usuarios ya están familiarizados con esa interacción.
Pensá en la frecuencia con la que ves botones como:
Al hacer clic en uno de esos botones, muchas veces se abre una ventana de autenticación más chica.
Nos entrenaron para confiar en ese patrón.
Los ataques BitB explotan esa expectativa.
El atacante no necesita comprometer al proveedor de identidad real ni explotar una vulnerabilidad en Chrome, Firefox, Safari o Edge.
Simplemente hace que la página web parezca haber abierto un popup de autenticación legítimo.
Esa distinción es importante.
A pesar del nombre, Browser in the Browser no suele ser un exploit contra el navegador.
No hace falta ejecución remota de código, ni un escape del sandbox, ni un zero-day, ni malware instalado en la máquina de la víctima.
Es, ante todo, una técnica de phishing e ingeniería social.
El navegador hace exactamente lo que tiene que hacer: renderizar HTML, CSS, imágenes, frames y JavaScript.
El ataque funciona porque algunos de esos elementos están diseñados para imitar la interfaz del propio navegador.
Dicho de otro modo, la vulnerabilidad que se explota es, en gran medida, nuestra confianza visual en la interfaz del navegador.
Un ataque típico se puede reducir a unas pocas etapas.
Primero, el atacante necesita que la víctima visite un sitio que él controla.
Eso puede pasar por un mail de phishing, un mensaje directo, un anuncio en un buscador, una página de descarga falsa, una publicación en redes o prácticamente cualquier otro mecanismo capaz de entregar un enlace.
El sitio inicial no tiene por qué parecer obviamente malicioso.
Puede imitar una aplicación legítima, un servicio para compartir documentos, un portal corporativo, un sorteo, una página de inscripción a un evento o un producto SaaS.
En algún momento la página muestra algo familiar:
Iniciá sesión con tu cuenta.
Por ejemplo, la página puede afirmar que hace falta autenticarse con un proveedor de identidad externo antes de acceder a un documento.
El usuario hace clic en el botón.
Normalmente, ahora el navegador crearía un popup de autenticación real.
Pero en un escenario BitB no hace falta que aparezca ninguna ventana de autenticación real.
La página crea una interfaz que visualmente se parece a un popup de navegador aparte.
Puede incluir:
El HTML y el CSS modernos hacen que reproducir estos elementos sea sorprendentemente fácil.
JavaScript agrega realismo: permite mover la ventana por la página, hacerla aparecer con animaciones, reaccionar a los botones o comportarse de forma parecida a un popup real.
Y lo más importante: el atacante controla la barra de direcciones que se muestra dentro de esa ventana.
Podría mostrar algo tranquilizador como:
https://login.example.com
mientras la pestaña real del navegador sigue estando en:
https://sitio-controlado-por-el-atacante.example
La primera dirección existe solo visualmente.
Es texto y gráficos renderizados por la página web.
Si la ventana de autenticación falsa es lo bastante convincente, la víctima escribe su usuario y su contraseña.
Esas credenciales se están ingresando en un formulario controlado por el atacante, no en el proveedor de identidad legítimo.
Desde la perspectiva de la víctima, casi todo puede parecer normal.
Desde la del atacante, la página de phishing hizo su trabajo.
Las credenciales se pueden usar después contra el servicio legítimo.
Según el ataque y el método de autenticación involucrado, el flujo de phishing también puede intentar obtener información adicional, como un código de un solo uso.
Por eso vale la pena hacer una distinción importante:
BitB por sí solo no evade mágicamente la autenticación multifactor.
Es el mecanismo de engaño visual.
Se le pueden combinar otras técnicas de phishing para pedir contraseñas, códigos OTP u otra información.
Lo interesante de BitB no es su complejidad técnica.
Es cómo se aprovecha de un hábito de seguridad que normalmente es un muy buen consejo:
Revisá el dominio antes de escribir tu contraseña.
El problema es que la víctima puede creer que está revisando el dominio.
Ve un candado.
Ve el nombre correcto de la empresa.
Ve lo que parece ser la URL de autenticación correcta.
Todo se ve bien.
Pero está inspeccionando una imitación del navegador, no el navegador.
Esto se vuelve especialmente peligroso con flujos de autenticación tipo OAuth y SSO, porque los usuarios ya esperan que la autenticación ocurra en un popup.
Que aparezca una segunda ventana después de hacer clic en Iniciar sesión con… no se siente sospechoso.
Se siente normal.
BitB no es solamente una prueba de concepto interesante de 2022.
La técnica sigue apareciendo en operaciones de phishing reales.
A fines de 2025, investigadores de seguridad que analizaban Sneaky2FA, una operación comercial de Phishing-as-a-Service, observaron funcionalidad BitB incorporada en sus páginas de phishing.
Eso importa porque el Phishing-as-a-Service baja drásticamente la barrera de entrada.
Los atacantes ya no necesitan diseñar cada componente de una campaña. Los kits pueden proveer infraestructura, plantillas, mecanismos de evasión, recolección de credenciales e interfaces cada vez más sofisticadas.
Así, técnicas que antes aparecían sobre todo en investigación de seguridad terminan siendo funcionalidades empaquetadas al alcance de atacantes mucho menos sofisticados.
Depende del tipo de autenticación.
Los métodos tradicionales de MFA, como los códigos por SMS o los códigos TOTP de una app autenticadora, siguen siendo piezas de información que el usuario puede llegar a escribir en una página de phishing.
El atacante puede, entonces, diseñar un flujo de autenticación falso que se los pida.
Eso no significa que BitB derrote automáticamente a MFA, pero sí que el MFA convencional no elimina del todo el phishing.
Una defensa mucho más fuerte es la autenticación resistente al phishing, en particular las tecnologías basadas en WebAuthn/FIDO2 y passkeys.
Estos mecanismos están atados al origen del sitio legítimo.
Una passkey creada para un servicio legítimo no puede ser usada, sin más, por un dominio de phishing que se hace pasar por ese servicio.
La apariencia visual de la página falsa pasa a ser mucho menos relevante, porque el mecanismo criptográfico de autenticación mira el dominio real, no el dominio dibujado en la pantalla.
Esta es una de las razones por las que empresas como Microsoft recomiendan cada vez más la autenticación resistente al phishing para cuentas sensibles.
No hay un único truco visual que exponga toda implementación de BitB, sobre todo a medida que mejora la calidad de las páginas de phishing.
Pero hay varias señales útiles.
Acordate de que la barra de direcciones dentro de una ventana BitB no es realmente una barra de direcciones.
Según la implementación, puede que no puedas:
El atacante puede simular algunas de estas interacciones, pero eso le exige trabajo adicional.
Un popup falso normalmente existe dentro de los límites de la página que lo creó.
Si lo arrastrás, puede comportarse raro cerca del borde del área de contenido del navegador.
Una ventana real del sistema operativo puede existir con independencia de la página original.
Un elemento del DOM simulado no puede salir genuinamente de su viewport.
No es una prueba perfecta —el atacante puede simular el movimiento de forma muy convincente— pero un comportamiento inesperado es una señal de alerta.
Los gestores de contraseñas conocen el origen real del sitio.
Si normalmente recibís la sugerencia de autocompletado para un servicio y de repente tu gestor no reconoce una página de login supuestamente idéntica, eso merece atención.
No lo tomes como prueba por sí solo, pero sí como una razón fuerte para verificar lo que estás viendo.
El contexto sigue siendo una de las defensas más poderosas contra el phishing.
¿Iniciaste vos este login?
¿Por qué este sitio necesita tu cuenta?
¿Estabas esperando un pedido de autenticación?
¿Llegaste por un mail, un anuncio, un código QR, un mensaje directo o un enlace inesperado?
Una página de login perfectamente diseñada puede tener igual un motivo de existir completamente inverosímil.
Si algo te resulta sospechoso, no sigas investigando el popup.
Cerrá la página.
Abrí una pestaña nueva y navegá manualmente al servicio que querías usar, preferentemente desde un marcador o un dominio que ya conocés.
Eso saca de la ecuación a la página controlada por el atacante.
BitB pone de relieve algo más amplio que una técnica de phishing.
Solemos tratar elementos visuales como si fueran límites de seguridad.
El candado significa seguro.
El logo familiar significa legítimo.
El popup de login significa autenticación.
La barra de direcciones significa identidad.
Pero en la web moderna, un atacante puede reproducir casi cualquier elemento visual que exista dentro de una página.
Los píxeles son baratos.
La confianza, entonces, tendría que venir de cosas que el atacante no puede reproducir fácilmente.
El origen real del navegador.
Un gestor de contraseñas que reconoce el dominio correcto.
Una passkey atada criptográficamente al servicio legítimo.
Un pedido de login que iniciaste vos a propósito.
Una URL que abriste por tu cuenta y no una que te llegó.
Estas señales son bastante más fuertes que un logo, un candado o un marco de ventana convincente.
Hay una regla muy práctica que protege contra BitB y contra muchas otras técnicas de phishing:
Cuando un sitio te pide inesperadamente que te autentiques con una cuenta importante, no uses la ventana de login que te ofrece.
En su lugar:
Para cuentas de alto valor, usá passkeys u otro método de autenticación resistente al phishing siempre que esté disponible.
Porque, en el fondo, los ataques Browser in the Browser tienen éxito convenciéndonos de confiar en algo que apenas parece una interfaz de seguridad.
Y esa es la parte más interesante de la técnica.
El atacante no necesita comprometer el navegador.
Solo necesita convencernos de que un pedazo de la página es el navegador.