La página de phishing que se construyó sola

El informe de tendencias de IR del Q1 2026 de Talos aterrizó el 22 de abril, y el titular es el tipo de cosa que los defensores leen como un indicador adelantado. El phishing vuelve a ser el vector de acceso inicial más observado — más de un tercio de los incidentes en los que se pudo determinar el vector — por primera vez desde el Q2 de 2025. Las debilidades en MFA aparecieron en el treinta y cinco por ciento de los incidentes, al alza respecto al Q4. La administración pública y la sanidad empataron como los sectores más atacados, con un veinticuatro por ciento cada uno. Nada de eso es especialmente sorprendente por sí solo.

Lo sorprendente es un caso de estudio en medio del informe. Talos documenta lo que denomina, con confianza moderada, la primera observación de una aplicación de IA específica — Softr, un builder no-code de «vibe-coding» — utilizada para alojar una página activa de captura de credenciales. La página imitaba Microsoft Exchange y Outlook Web Access. Capturaba las credenciales introducidas en una hoja de cálculo de Google desechable. Enviaba un correo al operador al producirse nuevas capturas. Talos estima que el patrón se remonta al menos a mayo de 2023, pero viene acelerándose a lo largo de finales de 2025 y durante el Q1. El seguimiento paralelo de Trend Micro muestra la misma técnica sobre Lovable, Netlify y Vercel: páginas CAPTCHA falsas levantadas sobre subdominios de builders de IA, con el formulario real de credenciales cargado detrás del reto.

La página concreta no tiene nada de particular. El hosting es la historia.

Cómo luce realmente la cadena.

Un builder no-code como Softr es, por diseño, una distancia muy corta entre un prompt y una aplicación web activa. Describes lo que quieres, él genera el HTML y el JavaScript, despliega el resultado en su propia infraestructura y te entrega un subdominio gratis. Ese subdominio es hermano de todos los demás subdominios de clientes de Softr: algo.softr.app. Softr se encarga del hosting, del certificado TLS, del CDN, del uptime. Si eres un atacante que quiere operar una página de captura de credenciales y no quieres registrar un dominio, comprar un certificado, alquilar un VPS ni explicarle a nadie qué alojas, esta es una propuesta de valor extraordinaria.

Lo que hace interesante a esta cadena en particular es que cada eslabón, con la excepción del prompt del propio atacante y de su propia bandeja de entrada, es un producto SaaS mainstream haciendo exactamente lo que anuncia. Softr construye la página. softr.app la aloja bajo un subdominio. Google Sheets almacena las credenciales recogidas. Gmail notifica al operador. Un defensor automatizado que recorra esta cadena de arriba a abajo ve solo terceros reputados. La cadena no se esconde. Lleva un camuflaje que la defensa fue construida para clasificar como benigno.

El punto ciego de la reputación de URL.

La mayoría de los sistemas de reputación de URL — los que puntúan un enlace como «seguro», «sospechoso» o «malicioso» antes incluso de que tu navegador termine el handshake TLS — funcionan como una central de riesgos. Construyen un perfil del dominio: qué edad tiene, cuán conocido es, si su certificado TLS tiene un largo historial o es un Let's Encrypt recién emitido, si alguna vez se ha observado en una lista de bloqueo, si su empresa matriz está en buen estado. El perfil produce un número, el número produce un veredicto, el veredicto produce un color.

Pasa algo.softr.app por ese pipeline.

Cada señal en la que se apoya la capa de reputación es una propiedad de softr.app, el dominio padre, y cada respuesta que da el padre es la correcta. Tiene seis años. Su certificado es válido. No está en ninguna lista de bloqueo. Sirve HTTPS. Es una categoría que el scorer ha clasificado. El subdominio no cambia ninguna de ellas de forma significativa. La página sobre el subdominio podría ser una tarjeta de cumpleaños o un formulario de captura de credenciales — el scorer no tiene manera de distinguirlas y, estructuralmente, dentro del diseño de la reputación de URL, ningún motivo para mirarlas.

La observación de Talos es que los atacantes entendieron esto hace tiempo y ahora lo están operacionalizando: construye la página en un SaaS reputado, recoge las credenciales en un SaaS reputado, enruta las alertas a través de un SaaS reputado. No le des al defensor nada que pueda rechazar.

La capa correcta es la página, no la URL.

La defensa tiene que bajar en la pila. La única señal que sigue siendo fiable una vez que el hosting se ha lavado es lo que la página misma dice ser y lo que realmente es. Un formulario de inicio de sesión de Outlook en onboarding-portal-8xq.softr.app es phishing. Un formulario de inicio de sesión de Outlook en login.microsoftonline.com no lo es. El mismo formulario, distinto origen, distinto veredicto. Un sistema que puede leer el formulario y compararlo con el origen tiene algo que decir sobre esta página; un sistema que solo lee la URL no.

Esta es la capa en la que el inspector anti-phishing de Bromure ya trabaja. Dentro de cada pestaña de Bromure, un content script vigila la página según se carga, extrae las señales que usaría un humano para decidir qué dice ser la página — el texto visible, el título, el origen del logo, la forma de los formularios, los campos que se piden — y envía ese paquete por un canal vsock a un modelo pequeño que emite un veredicto en lenguaje claro. «Esta página dice ser Microsoft Outlook pero está alojada en softr.app» es la clase de frase a la que un lector entrenado llega en una fracción de segundo. El modelo también llega ahí, y el banner que ve el usuario lo dice en una sola frase, en el color que corresponde al veredicto.

El inspector de contenido no es magia y no es una prueba. Es una segunda opinión entrenada que responde a una pregunta que la reputación de URL es estructuralmente incapaz de responder: ¿qué dice ser esta página? Esa pregunta tiene un filo más afilado en un softr.app o un vercel.app o un lovable.app que en casi cualquier otro sitio de la web, porque en esos subdominios el contenido de la página es casi la única señal que sobrevive. Todo lo demás ha sido lavado a través del padre.

Lo que Bromure sigue sin detener.

El inspector de contenido, y el banner que pinta, y el bloqueo que puede imponer, son la primera línea. La primera línea no siempre aguanta. Un usuario al que ha preparado un correo convincente, que está en medio de su jornada, que tiene por costumbre hacer clic en pantallas de inicio de sesión de Outlook, puede hacer clic para ignorar un banner de advertencia. Un usuario también puede aterrizar en una página que el inspector aún no ha evaluado, o una que evalúa como sospechosa en lugar de como phishing claro, y decidir que sospechosa está lo bastante cerca de probablemente bien.

Cuando eso ocurre, el usuario escribe una contraseña en un formulario, y el formulario la captura. Ninguna arquitectura de navegador en el mundo desactiva el acto de teclear. Esta es la más llana y más importante salvedad del post. Bromure no impide que un usuario introduzca una contraseña real en el formulario de un atacante. Lo que sí puede dar forma es a lo que ocurre después, y lo que ocurre después depende de dónde viva el resto del trabajo del usuario.

Qué cambia la postura del hábito en el navegador, y qué no.

Algunas cosas que la arquitectura de Bromure sí cambia, con honestidad, si un phishing de credenciales se cuela más allá del banner:

• No hay autocompletado del gestor de contraseñas en el origen equivocado. Los gestores de contraseñas casan las credenciales guardadas con el origen, y el origen aquí es softr.app, que la bóveda del usuario nunca ha visto. El autocompletado no se va a disparar. El usuario tiene que teclear. Es una defensa real, barata, aburrida — y funciona igual de bien en Chrome que en Bromure; solo merece mencionarse porque es una defensa que no depende del juicio, y el juicio es lo que el phishing derrota.
• No hay perfil persistente en la pestaña del phishing. La pestaña que albergó el phishing es una VM de Linux efímera. Cuando se cierra, nada de lo que se haya cargado en ella — cookies, almacenamiento, cachés, huellas — persiste. Eso no deshace la fuga de las credenciales que el usuario tecleó. Sí significa que la página no puede, en silencio, plantar un marcador en un perfil de larga vida para seguir al usuario entre sesiones.
• Una página que intenta alcanzar el host no lo encuentra. El caso de estudio de Talos es una captura pura de credenciales. El patrón más amplio que Trend Micro rastrea en Lovable y Vercel incluye páginas que además montan una continuación — un pegado tipo ClickFix, un «ejecuta este instalador», un CAPTCHA falso que termina en un prompt de aplicación nativa. Si la página de phishing intenta pasarle el testigo al sistema operativo anfitrión, la tab-VM corta ese traspaso en la frontera del hipervisor. El mismo motivo arquitectónico que en todos los demás posts de este blog.

Y algunas cosas que Bromure no cambia:

• Reenvío de credenciales desde la infraestructura del atacante. Una vez que el atacante tiene un usuario y una contraseña, puede iniciar sesión en el Outlook real desde su propia infraestructura. Nada en la máquina de la víctima, Bromure incluido, participa en esa sesión. La MFA ayuda. La MFA resistente a phishing — llaves hardware, passkeys — ayuda más. La política a nivel de tenant que prohíbe la autenticación heredada ayuda aún más. Estos son los arreglos para esta parte del ataque, y este blog no va a fingir que una arquitectura de navegador los sustituye.
• Kits adversary-in-the-middle que retransmiten sesiones en vivo. El caso de Softr que documenta Talos es una página estática de captura de credenciales, no un proxy inverso AiTM. La clase de kits más sofisticada — Tycoon, Evilproxy y su linaje — sí captura una cookie de sesión viva retransmitiendo el reto MFA de la víctima a través del phishing hacia el proveedor real. Esa cookie de sesión vive en la infraestructura del atacante desde el momento en que se captura. La desechabilidad del lado del navegador ayuda con la higiene de sesión a partir de ese momento; no invalida de forma retroactiva una cookie que ya salió del edificio. El binding de cookies en el servidor — DBSC y sus pares — es el arreglo que sí lo hace.

Por qué esto es un punto de inflexión y no una moda.

El marco de «primera atribución» de Talos es prudente, y la estimación con confianza moderada de que el patrón se remonta a mayo de 2023 sugiere que viene acelerándose en silencio durante casi dos años antes de que nadie lo etiquetara. Así es como llegan las mejores técnicas de atacante — no como un anuncio, sino como una curva que se nota en un gráfico que alguien finalmente dibujó. El writeup de Trend Micro de septiembre de 2025 sobre el phishing alojado en builders de IA trazó la misma curva desde la otra dirección. El punto de cruce está aquí. Cualquier defensor que asuma que sus usuarios nunca harán clic en un enlace a *.softr.app, *.vercel.app, *.lovable.app o *.netlify.app está asumiendo un mundo que ya terminó el trimestre pasado.

La estructura de costes es la razón. Hace una década, montar una página de phishing creíble requería competencia o dinero: un dominio, un certificado, un servidor, una página que no delatara su procedencia de inmediato. Hoy, un builder no-code gestiona las cuatro cosas a cambio de un registro gratuito. El coste marginal de otro sitio de suplantación se mide en minutos de prompting. El coste marginal de un takedown — porque cada página vive en un subdominio de un proveedor reputado, no en su propio dominio — es mayor que antes. Estas dos curvas apuntan en la dirección equivocada para la defensa, y la respuesta mainstream de «formar a los usuarios para que detecten URLs malas» es, a estas alturas, un centro de coste, no un control.

La posición honesta para un navegador que dice proteger a los usuarios es que tiene que hacer trabajo que los sistemas de reputación de URL no pueden. Tiene que leer de verdad la página. Tiene que decidir, para cada formulario con pinta de login sobre un dominio sin pinta de login, si el formulario casa con el dominio o miente sobre él. Tiene que decirlo en una frase que un humano pueda leer, y tiene que acertar con la frecuencia suficiente como para que la frase merezca ser leída.

Una historia, y lo que predice.

Talos escribió sobre una página. La página se construyó sobre un SaaS, recogió credenciales en otro, avisó al operador a través de un tercero. Cada eslabón de esa cadena es, para un scorer de reputación, un buen vecino. La historia que cuenta Talos dejará de ser la excepción antes de que termine este año. El phishing «vibe-coded» no es una etiqueta para una novedad; es el nombre de la forma por defecto en que los atacantes con interés en credenciales construirán páginas de ataque a partir de ahora, porque es la forma más barata y más indulgente.

Si la única respuesta de tu navegador al phishing es una puntuación de reputación de URL, tu navegador no tiene respuesta para esto. La puntuación de reputación será verde. La página será roja. Instala Bromure — y pon el segundo par de ojos sobre la página, donde el desajuste realmente vive.