Una de las operaciones de ciberdelincuencia como servicio más prolíficas ha sufrido recientemente un revés: en noviembre, Sophos MDR observó que las detecciones de la plataforma «phishing-as-a-service»(PaaS) Rockstar2FA habían desaparecido repentinamente.
Según la telemetría recopilada por Sophos MDR, parece que el grupo que ejecuta el servicio experimentó al menos un colapso parcial de su infraestructura y las páginas asociadas al servicio dejaron de ser accesibles. Esto no parece deberse a una acción de desmantelamiento, sino a algún fallo técnico en el backend del servicio.
La desaparición de Rockstar2FA, una versión actualizada del servicio de phishing conocido como DadSec (anteriormente asociado al grupo de amenazas Storm-1575 de Microsoft) se produjo dos semanas antes de que TrustWave publicara una investigación en la que se detallaba la operación de phishing como servicio. Los elementos de la infraestructura del servicio de phishing ya no son accesibles, ya que devuelven una respuesta HTTP 522, lo que indica que se han desconectado de la red de distribución de contenidos de Cloudflare. Los canales de Telegram asociados al mando y control del servicio también parecen haberse desconectado.
En las semanas siguientes a la interrupción de Rockstar2FA, observamos un aumento en el uso de un conjunto similar de portales PaaS que algunos investigadores han etiquetado como «FlowerStorm», nombre que proviene del uso de términos relacionados con plantas en los títulos de las páginas HTML de muchas de las páginas de phishing («Flower», «Sprout», «Blossom» y «Leaf», por ejemplo). FlowerStorm comparte una serie de características con Rockstar y con Tycoon, otra plataforma PaaS impulsada por bots de Telegram.
Así que quieres ser una estrella del rock
Rockstar2FA es (o quizás era) un kit PaaS que imita el comportamiento legítimo de solicitud de credenciales de las plataformas en la nube y de software como servicio más utilizadas. Los aspirantes a ciberdelincuentes compran y controlan las campañas de phishing a través de Telegram y reciben una página de phishing y una URL únicas para utilizar en su campaña. Las visitas a través del enlace entregado al objetivo entregan el phishing; las visitas al dominio del propio sitio se dirigen a una página «señuelo». Las páginas señuelo de Rockstar solían tener una temática automovilística.
Los visitantes de la URL eran redirigidos a una página de inicio de sesión de Microsoft falsificada. Esa página capturaba las credenciales y los tokens de autenticación multifactor y los enviaba mediante un mensaje HTTP POST a una página de «servidor backend» controlada por el adversario: una página PHP con un número aparentemente aleatorio como nombre (como se muestra en la Figura 2). Estos servidores back-end se encontraban principalmente en dominios registrados como .ru, .de y .moscow. Las páginas señuelo se alojaban con frecuencia en los mismos hosts que los servidores back-end.
La mayoría de las páginas de phishing estaban en dominios registrados en los dominios de primer nivel .com, .de, .ru. y .moscow. En un momento dado, el servicio Rockstar2FA utilizó unos 2.000 dominios entre estos y otros TLD.
Sin embargo, a partir de junio de 2024 a más tardar, algunas de estas páginas utilizaban la implementación sin servidor de Cloudflare Pages (utilizando el dominio pages[.]dev), junto con código implementado como trabajadores de Cloudflare (en el dominio worker[.]dev), aunque seguían dependiendo de servidores backend para la exfiltración de datos de phishing. Estas páginas de phishing utilizaban nombres de subdominios que no parecían haber sido creados con un algoritmo de generación de dominios (AGD), sino que parecían haber sido escritos manualmente por el operador del kit. Algunas se crearon para emular dominios de destino específicos (como 4344655-proofpoint-online-secure.pages[.]dev). Pero otros eran similares al spam de teclado:
- whenyoucreatanydominsamedominusedturnslite.pages[.]dev
- pppaaaaulhaaaammmlinnnnbuiiildddeeeerrsssssnzzzzzozzzz.pages[.]dev
Estos dominios solo constituían un pequeño número del total de URL relacionadas con Rockstar y generalmente estaban asociadas a los propios portales de phishing.
Dificultades técnicas
El 11 de noviembre, la infraestructura de Rockstar2FA se interrumpió repentinamente. Las redirecciones a las páginas señuelo fallaron, produciendo un error Cloudflare 522, que indicaba que el servidor que proporcionaba la página ya no estaba en comunicación con Cloudflare.
Además, las páginas del portal empezaron a fallar. Mientras que antes, al hacer clic en la prueba «Soy humano» de Cloudflare, se cargaba un portal de inicio de sesión falso de Microsoft, ahora lo único que se cargaba era el logotipo animado de Outlook. El resto del script de las páginas del portal fallaba porque se había cortado la conexión con el servidor back-end (a través de una solicitud POST).
Lo mismo ocurría con las páginas del portal alojadas en pages[.]dev, que también se colgaban al intentar conectarse a las URL de back-end. Desde noviembre, hemos seguido viendo nuevas páginas de portales de phishing creadas en subdominios de pages[.]dev, pero todas fallan al intentar conectarse a sus servidores backend.
Esto sugiere que los operadores siguen luchando por volver a poner en línea su infraestructura. Puede deberse a un problema de alojamiento web o a algún otro problema técnico que afecte a los operadores de Rockstar2FA. El hecho de que los bots de Telegram utilizados para ejecutar el servicio también parezcan estar caídos sugiere que hay algún tipo de interrupción mayor en la operación.
La estrella de rock en ascenso (?): FlowerStorm
Aproximadamente una semana y media después de la interrupción de Rockstar, vimos un aumento de la actividad de FlowerStorm, aunque también descubrimos que muchos de estos sitios también estaban siendo interrumpidos. La plataforma PaaS FlowerStorm lleva activa al menos desde junio de 2024.
Al observar el comportamiento de las muestras de FlowerStorm, descubrimos que el portal utilizaba la misma URL para enviar una solicitud de autenticación del objetivo que la utilizada en las solicitudes de comunicación al «portal backend» en este caso, a un servidor backend que utiliza el archivo «next.php».
En este caso, la misma dirección IP utilizada para la recogida de credenciales se utilizó también para la autenticación de la cuenta de usuario, según los registros de inicio de sesión de EntraID.
La comunicación de las páginas de phishing con el archivo PHP del servidor backend utilizó los campos y la comunicación esperados que se indican a continuación:
Descripciones de campos y valores esperados
| Campo/Evento | Descripción | Valor/Ejemplo |
| Do | Especifica la acción que se solicita | «check» – Para la operación de comprobación “login” – Para el evento de inicio de sesión |
| CheckVerify | Comprobación periódica del servidor del estado del método de autenticación | – do: «checkVerify”- token: <token>- usuario: <email>- servicio: «notif”- clave: <base64_encoded_password> |
| Dirección de correo electrónico del usuario | <email> | |
| pass | Contraseña del usuario, necesaria cuando do es «login» | base64_encoded_password |
| token | JWT que contiene información de la sesión | <JWT_Token> |
Respuestas esperadas e interpretaciones
| Acción | Respuesta | Descripción |
| check | { “status”: “success”, “banner”: null, “background”: null, “federationLogin”: “”, “type”: “office” } | Indica un correo electrónico válido y emite un token |
| login | { “status”: “verify”, “message”: “Please verify your account”, “method”: “<base64 encoded method response>”, “token”: “<JWT_Token>”, “key”: “<base64_encoded_password>”, “user”: “<email>” } | Solicita la MFA utilizando el mismo JWT para el seguimiento de la sesión |
| Method | { “status”: true, “data”: “<base64 encoded session data>”, “number”: 59 } | Publica datos específicos de la sesión utilizados para MFA. |
| Method (Data Decoded) | [ { “authMethodId”: “PhoneAppNotification”, “data”: “PhoneAppNotification”, “isDefault”: true }, { “authMethodId”: “PhoneAppOTP”, “data”: “PhoneAppOTP”, “phoneAppOtpTypes”: [“MicrosoftAuthenticatorBasedTOTP”] } ] | Detalla los métodos de autenticación multifactor disponibles para el usuario |
| CheckVerify (Failure) | { “status”: false, “message”: “Verification failed”, “token”: “<JWT_Token>” } | El servidor comienza a comprobar la aceptación de la MFA |
| CheckVerify (Success) | { “<string_with_session_cookies>” } | Se ha aceptado la MFA, la respuesta contiene cookies de sesión para la autenticación |
No todas las páginas de phishing utilizan la misma estructura de servidor backend. Algunos portales utilizarán un next.php alojado en el mismo dominio que la página de destino del phishing. La dirección IP en los registros de autenticación de EntraID no será la misma para estos portales. Por ejemplo, en el caso siguiente, la página de phishing protectivewearsupplies[.]doclawfederal[.]com/wQBPg/ envía su solicitud de publicación a un host diferente con el mismo nombre de dominio:
![Una vista de navegador de desarrollador de la página de phishing protectivewearsupplies[.]doclawfederal[.]com/wQBPg/](https://news.sophos.com/wp-content/uploads/2024/12/FlowerstormDeveloperViewPhishportal.png)
Similitudes entre Rockstar2FA y FlowerStorm
FlowerStorm tiene un número significativo de similitudes con Rockstar2FA, tanto en el formato de las páginas de su portal de phishing como en la conexión con su servidor backend.
Modelo de objetos del documento
El HTML de las páginas del portal de FlowerStorm ha cambiado en los últimos seis meses, pero sigue manteniendo un contenido de Modelo de Objetos del Documento (DOM) similar al de las páginas de Rockstar. Las páginas HTML de las páginas de phishing de FlowerStorm más antiguas y más recientes, al igual que las de Rockstar2FA, tienen cadenas de texto aleatorio y sin relación entre sí en comentarios HTML, utilizan claves «torniquete» de Cloudflare para solicitar una comprobación de la solicitud de página entrante, y tienen otras estructuras y contenidos similares, como se muestra a continuación:
| Nuevo FlowerStorm | Antiguo Rockstar2FA | Antiguo FlowerStorm | |
| Título | OreganoLeaf | no parecido | Elderberry |
| Turnstile Sitekey | 0x4AAAAAAA0_fAGSk-ZDbrja | 0x4AAAAAAAhiG1SBeMjCx4fG | 0x4AAAAAAAceMeRudDiJWXJJ |
| Script de envío de formulario | FennelBlossom | Nautili | Bravery |
| Comentarios Temas | Literarios/académicos | Coches, fitness, frutas | Coches, estilo de vida, frutas |
| Texto de seguridad visible | “Inicializando los protocolos de seguridad del navegador” | “Ejecutando la verificación del navegador para proteger tu seguridad” | “Verificación de seguridad del navegador en curso para tu seguridad” |
Los elementos de la tabla anterior se indican en las capturas de pantalla siguientes, que muestran el código HTML de cada uno de los portales de phishing. Las etiquetas de título del documento HTML están resaltadas con un recuadro rojo, los comentarios están resaltados con naranja, la clave de estilo de giro con amarillo, el nombre de la función del script en verde y el texto visible de «seguridad» en azul. Todos parecen seguir el mismo tipo de plantilla para generar HTML, aunque los esquemas de nomenclatura de comentarios y títulos hacen referencia a distintas matrices de texto.
Aunque el abuso de los giros de seguridad de la CDN de Cloudflare ha estado presente en otros kits de phishing del tipo «adversario en el medio», la estructura de los portales de phishing de FlowerStorm y Rockstar sugiere al menos una ascendencia común.
Recogida de credenciales
Los métodos utilizados por FlowerStorm para la comunicación se parecen mucho a los de los anteriores portales Rockstar2FA, con alguna variación menor en los nombres de los campos y las respuestas:
Campos comunes
| FlowerStorm | Rockstar2FA | Común | |
| Comunicación PHP | Next.php | <numbers>.php | Ambos se comunican con un servidor backend que aloja un archivo PHP. Se utilizan para la exfiltración y la comunicación de datos |
| Validación de correo electrónico | “do”:
“check” para la validación del correo electrónico |
“do”: “check” para la validación del correo electrónico | Ambas admiten la validación del correo electrónico como función fundamental |
| Evento de inicio de sesión | “do”: “login” para autenticación | “do”: “le” para autenticación | Ambos facilitan las operaciones de inicio de sesión |
| Contraseña | “pass”: contiene la contraseña codificada en base64 | “px”: contiene la contraseña en texto plano | Ambas comunican las contraseñas al servidor backend |
| Seguimiento de sesión | “token” para el seguimiento de sesión | “sec” para el seguimiento de sesión | Ambos proporcionan tokens de seguimiento de sesión. |
Registro y detección de dominios
Los patrones de registro de dominios y de detección de nuevas páginas mediante envíos de URLScan para la infraestructura de ambos kits de phishing parecen seguir un patrón distinto, especialmente cuando se compara la actividad y la identificación de dominios de ambos.
Del 1 de octubre al 11 de noviembre, los picos y valles de las detecciones de páginas y registros de dominios de FlowerStorm y Rockstar Decoy siguen una tendencia notablemente similar, a menudo subiendo y bajando a la par. Este comportamiento podría indicar una infraestructura compartida, objetivos operativos que se solapan o una sincronización coordinada entre ambas actividades.
Después del 11 de noviembre, los dos patrones divergen:
- FlowerStorm empieza a mostrar picos independientes más fuertes, especialmente en torno al 22-26 de noviembre
- La actividad de la página Rockstar Decoy disminuye significativamente después del 11 de noviembre, lo que coincide con el cese de operaciones mencionado anteriormente.
Objetivos de FlowerStorm
La naturaleza general de FlowerStorm como servicio de phishing de pago significa que los operadores de FlowerStorm no eligen a quién se dirigen los ataques de phishing. Eso lo deciden sus clientes. Pero un análisis de lo que hacen los actores una vez que tienen acceso al sistema puede ser útil para los defensores.
Según nuestra información de detección de FlowerStorm, la gran mayoría de los objetivos elegidos por los usuarios de FlowerStorm (84%) se encuentran en Estados Unidos, Canadá, Reino Unido, Australia e Italia. Las organizaciones de Estados Unidos fueron los objetivos más frecuentes, con más del 60% de los casos asociados a organizaciones ubicadas principalmente en ese país. Canadá fue el siguiente país más atacado, con solo un 8,96%. En general, el 94% de los objetivos de los intentos de phishing de FlowerStorm detectados por Sophos eran empleados de organizaciones norteamericanas y europeas. Fuera de estos países, Singapur, India, Israel, Nueva Zelanda y Emiratos Árabes Unidos representan el 5% restante de los objetivos.
El sector más atacado es el de servicios, con especial atención a las empresas que prestan servicios de ingeniería, construcción, inmobiliarios y jurídicos y de consultoría.
Conclusiones
No podemos vincular con gran seguridad Rockstar2FA y FlowerStorm, salvo para señalar que los kits reflejan una ascendencia común, como mínimo debido al contenido similar de los kits desplegados Los patrones similares de registro de dominios podrían ser un reflejo del trabajo coordinado de FlowerStorm y Rockstar, aunque también es posible que estos patrones de coincidencia hayan sido impulsados por las fuerzas del mercado más que por las propias plataformas. La actividad divergente posterior al 11 de noviembre podría reflejar:
- Un giro estratégico en uno de los grupos
- Un cambio de personal que afecta a las operaciones
- Una alteración de la infraestructura compartida
- Una disociación deliberada de las operaciones para evitar ser detectados.
Además, la rápida puesta en marcha de FlowerStorm ha provocado algunos errores y desconfiguraciones en sus operaciones que han permitido que también se vean fácilmente perturbadas. Esos errores también nos han brindado la oportunidad de examinar más de cerca sus operaciones de back-end, algo que seguiremos haciendo.
Una lista de indicadores de compromiso relacionados con FlowerStorm está disponible en el repositorio Github de Sophos X-Ops.
Dejar un comentario