6 min de lectura Por Excello Mail Team

50 Solicitudes, 50 Páginas Distintas: Un Kit de Phishing Polimórfico Que a Veces Se Rompe Solo

El manejador del SANS Internet Storm Center Xavier Mertens tomó un enlace de phishing atrapado en una trampa de spam y encontró un kit que reconstruye su página de robo de credenciales desde cero en cada solicitud, usando código aleatorizado y caracteres de ancho cero para vencer la detección por hash, derrotado en uno de cada cincuenta intentos por una variable sin alcance definido.

La mayoría de los kits de phishing se detectan de la misma manera: un proveedor de seguridad toma la huella de la página, calcula su hash, y ese hash termina en una lista de bloqueo que el resto de los proveedores eventualmente heredan. Es lento, pero funciona, porque la mayoría de los kits sirven el mismo HTML a todo el que hace clic en el enlace. El manejador del SANS Internet Storm Center Xavier Mertens encontró un kit que se niega por completo a seguir esa regla. Cada solicitud a la misma URL regresa estructuralmente distinta, lo que significa que cualquier defensa basada en hashes persigue un objetivo que nunca se queda quieto. Lo interesante no es que la evasión funcione. Es que el mecanismo construido para lograrlo tiene fallos suficientes como para sabotearse a sí mismo de vez en cuando.

Cincuenta Solicitudes, Cincuenta Huellas

Mertens tomó el enlace de phishing de un mensaje atrapado en una trampa de spam y, en lugar de simplemente registrarlo y seguir adelante, escribió un script para descargar la misma URL cincuenta veces seguidas y comparar lo que recibía. Cada una de las cincuenta muestras produjo un hash SHA-256 distinto. Solo el título de la página rotó entre al menos 21 valores diferentes, ciclando entre palabras deliberadamente insulsas como Solution, Viewer, Credentials, Private y Authenticate, ninguna de las cuales significaría algo para un analista que revisara de reojo el resultado de un escáner de URLs. Los nombres de campos de formulario e input, los nombres de clases CSS y los identificadores de elementos fueron todos reordenados entre solicitud y solicitud. Los valores numéricos dentro del código fueron reescritos como expresiones aritméticas en vez de dígitos simples. Se insertaron caracteres de ancho cero dentro de cadenas de texto por lo demás visibles, un truco antiguo para vencer reglas simples de coincidencia de texto que un lector humano jamás notaría. Nada de esto cambia lo que la página le hace a un visitante. Existe únicamente para asegurar que ninguna copia se parezca a otra ante una máquina.

El Error Escondido Dentro del Ofuscador

Cuarenta y nueve de las cincuenta muestras se desofuscaron limpiamente y mostraron el formulario de credenciales tal como fue diseñado. Una no lo hizo. Quedó atrapada en un bucle infinito en lugar de mostrar nada. Mertens rastreó la falla hasta la propia aleatorización del ofuscador: dos funciones separadas dentro de la cadena de decodificación habían recibido nombres distintos y generados aleatoriamente, exactamente lo que se espera de un motor polimórfico, pero los bucles de ambas funciones referenciaban la misma variable sin declarar, una k minúscula. Como la variable nunca se declaró con su propio alcance, JavaScript la trató como una única variable global compartida en lugar de dos contadores independientes, y cuando ambas funciones intentaron usarla a la vez, el bucle jamás terminó. El ofuscador fue lo bastante sistemático como para reescribir casi todo lo demás de la página en cada pase. No fue lo bastante disciplinado como para verificar que su propia lógica de renombrado respetara el alcance de las variables, así que aproximadamente uno de cada cincuenta visitantes recibió una página rota en vez de una trampa de credenciales funcional.

El Polimorfismo Es un Problema de Detección, No un Problema de DMARC

Nada de esto toca la pregunta que DMARC, SPF y DKIM existen para responder, que es si el dominio en el encabezado From de un mensaje tenía autoridad para enviarlo. El polimorfismo ocurre por completo después del clic, en infraestructura que el atacante controla totalmente, reescribiendo la página que el navegador renderiza en lugar de algo relacionado con cómo se autenticó o entregó el correo que llevaba el enlace. Un mensaje que apunte a este kit podría, en principio, pasar todas las verificaciones de autenticación que ejecute un buzón receptor y aun así llevar a un usuario a una página construida específicamente para vencer las herramientas de coincidencia por hash y firmas estáticas que se encuentran río abajo de esa bandeja de entrada. Los protocolos de autenticación nunca se diseñaron para evaluar lo que finalmente renderiza un enlace, y un kit como este es un recordatorio de exactamente cuánto terreno queda más allá de ese límite, terreno que sigue mereciendo defensa, solo que no con las mismas herramientas.

Qué Significa Esto Para Tu Programa

No dependas de la coincidencia por hash o firma exacta como tu única defensa contra páginas de robo de credenciales. Un kit que regenera su HTML en cada solicitud producirá un hash nuevo para cada analista, cada sandbox y cada rastreador automatizado que lo toque, convirtiendo la huella estática en una carrera perdida por diseño.

Lleva la inspección de enlaces y contenido más allá de la bandeja de entrada. Dado que DMARC solo valida el dominio emisor, una pila de seguridad necesita una capa separada, ya sea detonación de enlaces en sandbox, análisis de comportamiento de páginas o aislamiento del navegador, que realmente evalúe lo que entrega una URL una vez que alguien hace clic.

Trata las páginas de phishing inconsistentes o rotas como una oportunidad de detección, no como un callejón sin salida. Los propios errores de un kit, como la variable compartida que congeló una de cada cincuenta muestras aquí, a veces pueden ofrecer una huella más confiable que el contenido intencionalmente aleatorizado de la página.

Sigue recolectando y comparando múltiples muestras de la misma URL sospechosa antes de sacar conclusiones. Una sola descarga de una página polimórfica no dice casi nada sobre el kit detrás de ella. El muestreo repetido, como hizo Mertens en este caso, es lo que realmente revela el patrón.

La Conclusión

Un kit de phishing que reescribe su propio HTML en cada visita representa un salto real en lo difícil que resulta atrapar estas páginas con las herramientas basadas en firmas de las que aún dependen la mayoría de las defensas. También representa, en la única muestra rota de cincuenta, un recordatorio de que los atacantes construyen bajo la misma presión y el mismo descuido que cualquiera, y que la sofisticación en una dimensión no garantiza corrección en otra. Ni la evasión ni el error tienen algo que ver con DMARC, porque ambos viven por completo del lado del clic. Eso no es una falla de DMARC. Es un alcance, y la defensa de cada organización necesita una capa construida específicamente para lo que queda más allá de él.


DMARC te dice si un dominio tenía autoridad para enviar un mensaje. No puede decirte qué renderiza un enlace dentro de ese mensaje una vez que alguien hace clic, sea polimórfico o no. Excello Mail convierte tus reportes agregados de DMARC en un registro claro y continuo de cada servicio que envía en nombre de tu dominio, para que la capa que la autenticación realmente cubre permanezca vigilada mientras tu equipo construye las defensas para todo lo que queda más allá del clic. Regístrate gratis en Excello Mail y ten esa base lista.