En este ejemplo analizaremos una campaña de phishing que se hace pasar por Netflix y utiliza el control en tiempo real de la víctima. No se trata de un simple formulario HTML estático, sino de un servicio de phishing completo: el usuario pasa por varias etapas y el operador, desde el panel de control, decide hacia dónde dirigirlo a continuación —ya sea a introducir el nombre de usuario, los datos de la tarjeta, el código SMS, el código PIN o la confirmación en la aplicación—.
Por otra parte, hemos confirmado este mecanismo tras obtener acceso y analizar el panel de control de este sitio web de phishing.
En este artículo no describimos el método para obtener acceso al panel, pero utilizamos el mero hecho de su existencia como confirmación del modelo operativo: el ataque se gestionaba de forma manual o semiautomática a través de una interfaz de backend.
0. El anzuelo
Lo primero que recibe el usuario es un correo con una táctica estándar de ingeniería social que le insta a actuar. Esperan llamar la atención del usuario con la amenaza de que se pueda suspender el visionado de sus programas de televisión favoritos. Para eludir los filtros de correo y ocultar el dominio final de phishing, los atacantes utilizan un enlace acortado a través de la infraestructura de la red social X: https://t.co/XXXXXXX
A primera vista, parece un enlace normal a través de t.co, por lo que resulta menos sospechoso tanto para el usuario como para algunos filtros automáticos.
Al hacer clic, el usuario no accede directamente a la página principal de phishing. Primero se le redirige a un recurso intermedio.
1. Un bucket público de S3 como redireccionador intermedio
El enlace conduce a un bucket público de S3: https://access-authority-2faXXXXX.s3.eu-north-1.amazonaws.com/index.html
Esta etapa actúa como filtro y redireccionador.
index.html Incluye un filtrado por países y direcciones IP conocidas de antemano. Esto permite ocultar el verdadero sitio web de phishing a los investigadores, los escáneres automáticos, los entornos de pruebas y los sistemas de protección.
Tras pasar el filtro, el usuario recibe una simple redirección HTML:
<meta http-equiv="refresh" content="1;url=https://www.XXXXX.help/index.html">
El dominio se disfraza de servicio para resolver CAPTCHAs. Se trata de una coartada muy útil: el usuario ve el nombre técnico y puede pensar que se trata de una comprobación intermedia del navegador, un CAPTCHA o una validación de seguridad.
En la práctica, se trata de una infraestructura de phishing.
Ya en esta fase se lleva a cabo el «fingerprinting» del dispositivo. El código recopila eventos del usuario:
- mousemove
- touchmove
- keyup
- Backspace
- deviceorientation
El script analiza no solo el hecho de que se produzcan los eventos, sino también sus parámetros:
- la velocidad de movimiento;
- los intervalos entre eventos;
- coordenadas normalizadas;
- la brusquedad del cambio de dirección;
- el comportamiento del teclado;
- orientación del dispositivo;
- perfil táctil/del ratón.
Esto se utiliza para evaluar si el visitante es una persona real.
Ofuscación y «cifrado» de la telemetría
Parte de la telemetría se cifra mediante AES-CBC antes de su envío: crypto.subtle.encrypt({ name: 'AES-CBC', iv: ... }, key, data)
El código contiene lógica antidepuración. El script extrae una palabra debugger de una matriz numérica y lo invoca mediante new Function(). Si la ejecución se retrasa, la página envía una solicitud de baliza a /misc/index.php?r=<random> con el parámetro bcl
Esto parece un intento de detectar si el usuario ha abierto DevTools o si la ejecución de JavaScript se ha detenido en un punto de interrupción; el backend puede modificar el comportamiento, ocultar el flujo real y mostrar un error o redirigir al usuario a la página web legítima de Netflix.
Tras superar con éxito el «captcha», se produce una redirección a main/prepare.php
2. Primera fase: recopilación del nombre de usuario y la contraseña
La primera etapa real del ataque no es ni la tarjeta ni el SMS. En primer lugar, el usuario accede a una página que imita el inicio de sesión en Netflix.
En esta etapa, los atacantes recopilan el correo electrónico y la contraseña.
Esto es importante: el ataque comienza con el robo de credenciales de la cuenta y, solo después, pasa a los datos de pago.
Tras enviar el formulario POST, la página redirige al usuario a la siguiente etapa: la «verificación de la tarjeta de pago».
De este modo, aunque no se completen los pasos de pago posteriores, los atacantes ya obtienen un resultado valioso: el acceso a la cuenta.
3. Segunda fase: introducción de los datos de la tarjeta
Tras introducir el nombre de usuario y la contraseña, el usuario es redirigido a la página de verificación de pago.
En esta etapa, el escenario simula la necesidad de confirmar la tarjeta vinculada a Netflix. El usuario ve una interfaz similar al flujo de facturación legítimo e introduce los datos de pago.
El objetivo de esta etapa es recopilar:
- el nombre del titular de la tarjeta
- el número de la tarjeta
- fecha de caducidad
- el CVV/CVC
Durante todo el proceso se envía telemetría:
4. Tercera fase: pantalla de carga y espera del operador
Tras introducir los datos de la tarjeta, el usuario accede a una página de espera. Es precisamente este código HTML el que vemos en el artefacto analizado.
La página indica:
Se requiere una validación adicional para completar la verificación de su tarjeta
Recibirás un mensaje corto en tu teléfono móvil...
Visualmente, parece una espera habitual de confirmación bancaria. Pero técnicamente no se trata simplemente de una «pantalla de espera», sino del punto en el que el usuario permanece en la sesión mientras el backend o el operador decide qué paso siguiente mostrar.
5. Control en tiempo real a través de WebSocket
El principal mecanismo de control es WebSocket. Podemos observar una wss:// en la parte inferior de las solicitudes. La página se conecta al WebSocket y espera una orden del backend. En el HTML está implementada la lógica mediante la cual el operador puede dirigir al usuario a diferentes pantallas:
| Código | Ruta | Descripción |
|---|---|---|
| 1 | ./app.php | Página de solicitud de confirmación en la aplicación bancaria |
| 2 | ./payment.php | Nueva solicitud de introducción de los datos de la tarjeta debido a un error |
| 3 | ./sms.php | Página para introducir el código del SMS |
| 4 | ./pin.php | Página para introducir el código PIN de la tarjeta |
| 5 | https://netflix.com | Redirección a la página web oficial de Netflix |
La tarjeta que introduce el usuario, ya sea de forma automática o semiautomática, comienza a utilizarse para realizar pagos en diferentes tiendas. Lo más probable es que se trate de comercios controlados por los atacantes.
Es precisamente aquí donde el componente en tiempo real se vuelve especialmente peligroso. El operador puede ver qué tipo de confirmación ha solicitado el sistema de pago y adaptar la página de phishing al momento concreto del ataque. Solicitando, unas veces, la confirmación en la aplicación; otras, el código de un SMS o el código PIN de la tarjeta.
6. Confirmación a través del panel de administración
Tras analizar el funcionamiento del sitio web de phishing, decidimos buscar vulnerabilidades en dicho panel. De paso, recibimos unos «huevos de Pascua» bastante extraños por parte del creador de dicho panel.
Según los registros, se puede afirmar que, en un periodo de 24 horas, al menos cuatro administradores diferentes accedieron al panel de administración en intervalos de entre 4 y 7 horas.
Asimismo, detectamos puertos abiertos adicionales en el panel (2082, 2095, 8880 y 1010), lo que nos permitió identificar la IP real, ya que la web de los estafadores se encuentra detrás de CloudFlare.
Se ha notificado a los proveedores de acceso a Internet.
7. Indicadores de compromiso
Dominios
*.solvecaptcha.help
8. Conclusión
Esta campaña muestra cómo los servicios de phishing modernos convierten una página de inicio de sesión normal en una operación controlada en tiempo real.
Los atacantes obtienen primero el nombre de usuario y la contraseña, luego los datos de pago, tras lo cual retienen al usuario en una pantalla de carga. En ese momento, el operador, desde el backend o el panel de administración, decide qué paso mostrar a continuación: un código SMS, un código PIN, una confirmación en la aplicación o una redirección final a la página auténtica de Netflix.
La principal característica técnica de este esquema es el control mediante WebSocket. Es precisamente esto lo que hace que el ataque sea interactivo y permite a los operadores adaptar el guion a una víctima concreta y a un flujo bancario específico.
Ya no se trata de una «página de phishing». Es una operación de phishing en directo.