Error 524 Decoy: Desenmascarando una Operación Global de Smishing Oculta Tras Páginas de Error

Introducción

América Latina, concentra una alta adopción móvil y controles desiguales contra la suplantación de SMS, lo que la convierte en un blanco frecuente de operadores de fraude. Los investigadores de Group-IB han identificado una operación sofisticada y a gran escala de smishing y phishing, activa desde el segundo semestre de 2025, que utiliza la región como su principal escenario y se ha expandido a 72 países en todo el mundo. Esta campaña ha suplantado a más de 267 marcas únicas en sectores como telecomunicaciones y servicios financieros, generando exitosamente miles de instancias de dominios de phishing destinadas a recolectar credenciales completas de tarjetas de crédito e identificadores personales.

La operación cuenta con una arquitectura de evasión anti-análisis por capas, que utiliza páginas de error falsas de Cloudflare muy convincentes, como la pantalla de tiempo de espera “Error 524”, a modo de distracción. El contenido malicioso solo se revela a las víctimas que cumplen con criterios específicos de geolocalización y dispositivo móvil. Esto se combina con una infraestructura técnicamente madura que utiliza Aplicaciones de Página Única (SPA) ofuscadas en Base64 y exfiltración de datos en tiempo real mediante canales WebSocket cifrados.

Hallazgos Clave

• La campaña ha estado activa desde el segundo semestre del 2025, suplantando a más de 260 marcas únicas en 72 países de LATAM, Europa, APAC, América del Norte y la región META.
• Group-IB identificó 4.389 instancias de dominios de phishing; México por sí solo representa 1.851, con Chile (529) y Colombia (258) entre los principales objetivos en LATAM.
• Las telecomunicaciones son el sector más atacado con 1.754 instancias de dominios, seguido por Servicios Financieros (696) y programas de Recompensas al Consumidor (488).
• El kit de phishing utiliza páginas de error falsas de Cloudflare como distracción, revelando contenido malicioso solo a víctimas que cumplen las reglas de geolocalización y configuración del dispositivo.
• La exfiltración de datos ocurre a través de canales WebSocket cifrados utilizando payloads codificados en binario, con señales heartbeat para mantener conexiones en tiempo real.
• Aproximadamente el 30% de la infraestructura de phishing está alojada en servidores de origen de Tencent Cloud y Alibaba (EE. UU.), enmascarada por Cloudflare (AS13335) para ocultar las IPs de alojamiento reales.

¿A quién puede interesarle este blog?

• Analistas de ciberseguridad y equipos de seguridad corporativa
• Analistas de malware
• Especialistas en inteligencia de amenazas
• Investigadores cibernéticos
• Equipos de Respuesta a Emergencias Informáticas (CERT)
• Investigadores de fuerzas del orden
• Cuerpos de policía cibernética

Portal de Inteligencia de Amenazas de Group-IB: Smishing Error524

Los clientes de Group-IB pueden acceder a nuestro portal de Inteligencia de Amenazas para obtener más información sobre este actor.

Smishing Error524

Perfil del Actor de Amenazas

Threat Actor Profile

Detección de la Campaña y Alcance Geográfico

Los equipos de Digital Risk Protection (DRP) de Group-IB identificaron esta campaña durante un monitoreo rutinario de infraestructura de suplantación de marcas en el segundo semestre de 2025. El grupo automatizado de dominios y la identificación visual de kits de phishing revelaron un patrón de alta consistencia en dominios que apuntaban a operadores de telecomunicaciones, instituciones financieras y programas de fidelización de consumidores predominantemente en América Latina, y llegando en menor escala a Europa, APAC y América del Norte.

La concentración de la campaña en LATAM no es casual. México, Chile y Colombia juntos representan 2.638 de las 4.389 instancias de dominios atribuidas regionalmente, aproximadamente el 60% del alcance documentado de la campaña.

Figura 1. Desglose de la huella de la campaña de smishing en LATAM.

Figura 2. Desglose de las industrias más atacadas por la campaña de smishing en LATAM.

El análisis de Group-IB atribuye esta ponderación geográfica a tres factores estructurales:

Controles anti-suplantación de SMS deficientes en múltiples operadoras de LATAM.

Alta penetración de internet móvil combinada con una cultura de ciberseguridad relativamente baja entre usuarios que acceden a internet principalmente desde el teléfono.

La amplia oferta de programas de fidelización y recompensas de grandes telecomunicaciones y minoristas, que generan “pretextos de urgencia” — puntos por vencer, recompensas sin reclamar — y que impulsan las tasas de clics de las víctimas.

Más allá de LATAM, la presencia europea de la campaña (673 dominios confirmados, principalmente en Países Bajos y Alemania) apuntaron a servicios financieros y operadores logísticos, mientras que presencia en APAC (238 dominios, lideradas por Australia) se centraron en telecomunicaciones y suplantación gubernamental. La huella norteamericana (405 dominios) apuntó desproporcionadamente a servicios financieros y programas de recompensas al consumidor, consistente con el patrón de la campaña de suplantar programas de fidelización como pretexto de engaño.

Figura 3. Desglose de la distribución regional de la campaña.

La Arquitectura de Evasión del Error 524

La característica operativamente más significativa de esta campaña es su arquitectura anti-análisis por capas, centrada en imitar la estética de las páginas de error legítimas de Cloudflare como mecanismo de engaño. Cuando un dominio de phishing es visitado por una solicitud que no cumple con los criterios de control de acceso de la campaña — geolocalización IP de un país no objetivo, un user-agent no móvil, o la ausencia de parámetros de sesión esperados — el servidor devuelve una página visualmente idéntica a un error de gateway de Cloudflare, mostrando varios códigos de error como el 524 (tiempo de espera del gateway), 300 o 313.

Esta táctica tiene un doble propósito. Para los investigadores de seguridad y los escáneres automatizados que intentan mapear la infraestructura de phishing, la página de distracción no ofrece ningún indicador de contenido malicioso: sin formularios de recopilación de credenciales, sin activos de suplantación de marca, sin JavaScript sospechoso. Para los proveedores de alojamiento y los destinatarios de solicitudes de eliminación que revisan dominios marcados, la página de distracción refuerza la negación plausible, ya que el sitio aparenta ser un despliegue legítimo mal configurado o defectuoso, en lugar de una operación de fraude activa.

Los criterios de filtrado se aplican en el momento de carga de la página mediante consultas de geolocalización IP del lado del cliente a APIs externas. La respuesta, que incluye el código de país, la moneda y el idioma, determina si la víctima accede a la SPA maliciosa o recibe la página de distracción. La validación del user-agent móvil añade una segunda capa de filtrado, coherente con el enfoque exclusivo de la campaña en usuarios de dispositivos móviles. Esta renderización condicional de doble capa se encuentra entre las implementaciones operativamente más disciplinadas que Group-IB ha observado en una campaña atribuida a PhaaS.

Figura 4. Los sitios web utilizan una página de error de Cloudflare, mostrando varios códigos de error, como página de destino engañosa.

Cadena de Ataque: Del SMS fraudulento a la Exfiltración de Tarjetas de Crédito

Para las víctimas que sí cumplen con los criterios de geolocalización y dispositivo de la campaña, el ataque se desarrolla en un flujo de interacción de cinco etapas cuidadosamente diseñado, optimizado para la usabilidad móvil y diseñado para construir progresivamente la confianza de la víctima antes de solicitar los datos de mayor valor: credenciales completas de tarjetas de crédito.

Etapa 1: Envío del Mensaje Fraudulento

Las víctimas reciben un SMS de un número falsificado que parece local en su país. El mensaje está construido con un pretexto de urgencia – más comúnmente un saldo de recompensas a punto de vencer, un beneficio pendiente de reclamar, o una entrega que requiere confirmación – e incluye una URL acortada. Los acortadores de URL ocultan el dominio de destino dentro del SMS, reduciendo la probabilidad de que los operadores o los destinatarios conscientes de seguridad identifiquen el enlace como sospechoso antes de hacer clic.

Figura 5. La campaña utilizó mensajes de texto SMS enviados desde un número local para suplantar el programa de recompensas de una marca.

Etapa 2: Carga de la Página de Destino

Al hacer clic (desde un dispositivo e IP calificados), el dominio de phishing carga un esqueleto HTML mínimo, un único punto de montaje <div id=”app”> consistente con una arquitectura de Aplicación de Página Única. El contenido completo de la aplicación está codificado como datos Base64 dentro de elementos HTML personalizados y decodificado en tiempo de ejecución por JavaScript incluido. Este enfoque elimina los scripts en línea visibles para las herramientas de análisis estático y traslada la lógica de renderizado malicioso a una capa en tiempo de ejecución ofuscada.

Figura 6. Páginas de destino de phishing renderizadas para víctimas que cumplen los requisitos de geolocalización y perfil de dispositivo, mostrando una convincente interfaz de suplantación de marca.

Etapa 3: Recolección de Datos de Identidad

El formulario inicial solicita un número de registro nacional o de identificación, un punto de entrada de baja fricción que se vale de la familiaridad. Al enviarlo, la interfaz muestra una “oferta de recompensa” personalizada o un beneficio relevante para la marca suplantada, reforzando la legitimidad de la interacción. Las pantallas posteriores recopilan nombre completo, dirección física, correo electrónico y número de teléfono.

Figura 7. Una vez ingresado el número de identificación del usuario, se muestra una interfaz de selección de recompensas.

Figura 8. La campaña solicita los datos personales completos de los usuarios (nombre, dirección, correo electrónico y número de teléfono) antes de escalar a los datos de pago.

Etapa 4: Recolección de Datos de Tarjeta de Crédito

La etapa final de recolección de datos solicita información completa de la tarjeta de pago: número de tarjeta, fecha de vencimiento y CVV. La validación es intencionalmente mínima, basándose únicamente en la suma de verificación del algoritmo de Luhn para validar el formato del número de tarjeta. Las tarjetas de prueba que superan la suma de verificación son aceptadas e inmediatamente activan la redirección posterior al envío. Este enfoque maximiza el rendimiento al evitar comprobaciones de autorización en tiempo real que requerirían conectividad bancaria e introducirían latencia.

Figura 9. Solicitud de credenciales completas de tarjeta de crédito, incluyendo número de tarjeta, fecha de vencimiento y CVV.

Etapa 5: Exfiltración y Redirección

Los datos enviados son exfiltrados en tiempo real mediante un canal WebSocket cifrado (WSS) establecido al cargar la página. Los payloads codificados en binario de tamaños variables (64–1.008 bytes) transportan las credenciales recopiladas, mientras que las señales de heartbeat mantienen la integridad del canal y registran el tiempo de permanencia en sesión como analíticas de comportamiento. Tras el envío, la víctima es redirigida sin problemas al sitio web legítimo de la marca. Esta redirección post-recopilación cumple dos funciones: sostiene la ilusión de que la interacción fue legítima, reduciendo los reportes inmediatos de las víctimas; y refuerza el cierre de sesión, garantizando que no haya persistencia post-recopilación en el dispositivo de la víctima.

Análisis de Tráfico HTTP

Primera Solicitud

La respuesta HTTP de esta solicitud inicial entrega un documento HTML mínimo para una aplicación de página única (SPA). Está enrutada a través de Cloudflare, con el servidor de origen siendo Caddy, un servidor web ligero frecuentemente usado para aplicaciones en lenguaje Go o servicio estático.

El cuerpo de la respuesta es un esqueleto HTML básico: Sin contenido renderizado por el servidor, solo un punto de montaje <div id=”app”> para la renderización del lado del cliente.

Bloque de código 1. Primera solicitud HTTP de la página de phishing.

Bloque de código 2. Primera respuesta HTTP de la página de phishing.

Segunda Solicitud

Esta respuesta HTTP es una llamada de API inmediata desde el JavaScript del lado del cliente, después de montar la SPA en /apps/CL_PT_04. Es dinámica, enrutada a través de Cloudflare con Caddy nuevamente como servidor de origen.

Tras la carga de la SPA, el JS envía una solicitud vinculada a la sesión para obtener datos personalizados o seguros. El Backend (PHP/Caddy) los cifra en el lado del servidor y devuelve blobs para el descifrado del cliente.

Bloque de código 3. Solicitud HTTP al endpoint /getApp.

Bloque de código 4. Respuesta HTTP que entrega un payload JSON.

El objeto de datos contiene tres grandes blobs binarios codificados en Base64 (k, d, s), que no son texto legible por humanos:

• k: Probablemente una clave de cifrado simétrico (p. ej., clave derivada AES-256) o nonce.
• d: Payload cifrado (texto cifrado), posiblemente datos de la aplicación como estado del usuario, configuración o contenido obtenido a través de la sesión (cookie PHPSID).
• s: Firma o MAC (p. ej., HMAC-SHA512) para integridad o autenticidad, calculado sobre d usando k.

Tercera Solicitud

Una solicitud HTTP a un endpoint administrado de Cloudflare para Monitoreo de Usuarios Reales (RUM).

RUM es una herramienta de monitoreo de rendimiento que recopila datos de telemetría anonimizados sobre cómo los usuarios reales experimentan los tiempos de carga, interacciones y uso de recursos de un sitio web. El endpoint /cdn-cgi/rum es parte de Cloudflare Web Analytics, que los sitios pueden habilitar para rastrear métricas sin cookies de terceros.

Reporta datos para un evento de navegación de página única, incluyendo tiempos detallados del navegador. El payload es un objeto JSON con métricas de rendimiento, lo que indica una carga de página relativamente rápida. Esto permite una comunicación eficiente y persistente sin sondeos, ideal para dispositivos móviles.

Bloque de código 5. Solicitud HTTP al endpoint /cdn-cgi/rum.

Bloque de código 6. Respuesta HTTP 204 Sin contenido.

Cuarta Solicitud

Esta solicitud intenta actualizar a una conexión WebSocket en el mismo dominio. La ruta /wss con un parámetro de consulta uuid indica un endpoint WebSocket personalizado, probablemente para funciones en tiempo real en la SPA para actualizaciones en vivo, notificaciones o comunicación bidireccional en la aplicación /apps/CL_PT_04. Esto sigue la secuencia: HTML load → JSON API fetch → WebSocket init.

Bloque de código 7. Solicitud HTTP al endpoint /wss.

Bloque de código 8. Respuesta HTTP a la solicitud previa de actualización de WebSocket, confirmando una conexión exitosa.

El estado HTTP 1.1 101 Switching Protocols indica que la conexión ha sido actualizada de HTTP a WebSocket, sobre el socket TCP existente. Toda la comunicación cambia a frames WS. Esto completa la configuración en tiempo real de la SPA. El cliente ahora tiene un canal bidireccional de baja latencia para funciones como actualizaciones en vivo o chat en /apps/CL_PT_04.

Comunicación por WebSocket

Los dominios maliciosos utilizan el protocolo WebSocket para transmitir información cifrada, incluyendo el tiempo que un usuario permanece en el sitio web, mediante solicitudes de “heartbeat”.

El tráfico WebSocket es binario, compuesto de bytes codificados en Base64 que se decodifican en 1.008 bytes de datos binarios ofuscados. Este formato binario indica que los datos no son texto UTF-8 estándar.

El mecanismo de heartbeat es esencial para mantener el canal en tiempo real, que soporta la funcionalidad del endpoint principal /apps/CL_PT_04 de la aplicación, por ejemplo la sincronización en vivo.

Análisis de Infraestructura

La arquitectura de infraestructura de la campaña refleja decisiones deliberadas de seguridad operacional, equilibrando el alcance global, una huella de detección baja y la rotación ágil de dominios, frente a la necesidad de una entrega confiable a las víctimas móviles que califican.

Arquitectura de Alojamiento y CDN

Cloudflare (AS13335) actúa como el CDN principal y proxy inverso en la mayoría de los dominios analizados, proporcionando enmascarado de la IP de origen, cancelación TLS y el endpoint de Monitoreo de Usuarios Reales (RUM) reutilizado como canal de telemetría de comportamiento. Los servidores de origen están alojados predominantemente en Tencent Cloud (AS132203) y Alibaba US (AS45102), que juntos representan aproximadamente el 30% de la infraestructura de phishing identificada por volumen de dominios identificados. Group-IB evalúa que la selección de proveedores de nube chinos es deliberada: ambos servicios ofrecen aprovisionamiento rápido, precios competitivos y cierto grado de resistencia al bloqueo de IP debido a la asociación de los proveedores con infraestructura de nube global legítima.

El uso de Cloudflare para enrutar a través de proxy los servidores de origen de Tencent y Alibaba crea un desafío de atribución compuesto para las solicitudes de eliminación: el equipo de abuso registrador típicamente contacta a Cloudflare, que puede aplicar restricciones a nivel CDN mientras el servidor de origen permanece activo, lo que permite migrar rápidamente a un nuevo dominio.

Patrones de Dominio y Selección de TLD

Los dominios exhiben patrones estructurales consistentes: registros cortos en dominios de nivel superior de bajo costo con prefijos genéricos que imitan nombres de marcas (p. ej., rewards-[marca]-cl[.]ink, puntos-[marca]-mx[.]bond). El registro masivo con patrones de nombres secuenciales permite el ciclo rápido de dominios tras las eliminaciones. Los TLDs identificados en la infraestructura de la campaña incluyen .ink, .top, .bond, .click, .icu, .vip y .cyou, todos coherentes con las preferencias de TLD de los grupos de infraestructura de crimen electrónico del sudeste asiático documentados en investigaciones anteriores de Group-IB.

IPs de Infraestructura Primaria

Análisis de la Composición Técnica de las Páginas de Phishing

La coherencia operacional en todos los sitios de phishing funcionales proporciona evidencia irrefutable de un kit y campaña unificados. El análisis de estructuras DOM, ejecución de JavaScript, encabezados HTTP y patrones XHR revela una huella técnica idéntica:

• Para desarrollar una experiencia de usuario realista, los atacantes utilizan el framework frontend Vue.js (evidenciado por atributos data-vue- y objetos window específicos como __VUE_INSTANCE_SETTERS__) combinado con FormKit para el manejo de formularios complejos.
• Se usa un patrón de endpoint central estandarizado, donde cada sitio activa un XHR a /getApp?app_id=XX_XX_XX (p. ej., CL_PT_04). Esto actúa como el cargador central, con el prefijo “PT” probablemente denotando “Payment Target” (Objetivo de Pago).
• La estructura de activos permanece uniforme, cargando archivos JS empaquetados de gran tamaño (1–2 MB) junto con recursos legítimos como fuentes Open Sans e iconos Font Awesome para mejorar la credibilidad.
• Para la geolocalización y el monitoreo, el kit utiliza ipapi.co para eludir las restricciones geográficas y el beacon.min.js de Cloudflare para el análisis de comportamiento.
• La configuración del backend utiliza consistentemente cookies PHPSID y uuid, con servidores alternando entre Caddy y Workerman.

Este diseño estructural explica la apariencia de dos caras de los dominios identificados: un sitio de destino operativo impulsado por Vue cuando se cumplen las condiciones, y una pantalla de error de tiempo de espera 524 fraudulenta diseñada para ocultar el kit de phishing de solicitudes que no coinciden con los perfiles de dispositivos objetivo.

Conclusión

La operación Smishing Error524 representa una amenaza en evolución y altamente sofisticada que ha industrializado la suplantación de marcas a escala global. Al aprovechar la estética engañosa de páginas de error para eludir los filtros de seguridad tradicionales, la campaña demuestra una madurez técnica significativa en los sindicatos modernos de crimen electrónico.

El impacto es particularmente notable en la región LATAM, donde la ausencia de controles robustos anti-suplantación de SMS permite que los mensajes fraudulentos se entreguen con facilidad. Esta falta de aplicación en los operadores regionales crea un entorno fértil para que los atacantes apunten a sectores críticos de la economía de confianza digital, incluyendo las telecomunicaciones y los servicios financieros.

El éxito de esta campaña depende de la manipulación psicológica. Los usuarios finales deben mantenerse vigilantes y escépticos ante los mensajes no solicitados que crean una falsa sensación de urgencia. Mantenerse por delante de estas operaciones PhaaS disciplinadas requiere una combinación de detección de comportamiento, inteligencia de la dark-web y monitoreo proactivo de marcas.

La Plataforma de Riesgo Unificado de Group-IB proporciona monitoreo continuo a lo largo del ciclo de vida del dominio de phishing, desde el registro hasta el despliegue activo y la eliminación, dando a las organizaciones el tiempo de ventaja de inteligencia necesario para actuar antes de que las víctimas queden expuestas. A medida que los operadores PhaaS continúan refinando sus arquitecturas anti-análisis y expandiendo sus redes de afiliados a nuevas regiones, la combinación de inteligencia de amenazas, análisis de comportamiento y capacidad de eliminación coordinada definirá qué organizaciones se mantienen por delante de estas campañas y cuáles no.

Recomendaciones

Para Equipos de Seguridad y Prevención del Fraude

• Integrar fuentes de para recibir indicadores (IOCs) oportunos sobre dominios de phishing recién registrados que coincidan con los patrones de TLD e infraestructura de la campaña (.ink, .bond, .top, .cyou en IPs de origen Tencent/Alibaba).
• Monitorear los registros masivos de dominios que utilizan patrones de nombres adyacentes a marcas en TLDs sospechosos, particularmente aquellos que registran grupos de dominios secuenciales en un plazo de 24–72 horas.
• Aprovechar una plataforma avanzada de para la detección automatizada de suplantación de marcas y la eliminación coordinada, apuntando a los dominios antes de que lleguen al contacto activo con las víctimas.

Para Usuarios Finales y Equipos de Atención al Consumidor

• Entrenar a los usuarios para que sean escépticos ante los mensajes SMS no solicitados que afirman saldos de recompensas, confirmaciones de entrega o reclamaciones de beneficios, independientemente de si el número del remitente parece local.
• Instruir a los usuarios para que naveguen directamente a los sitios web de las marcas escribiendo la URL en lugar de hacer clic en los enlaces SMS, especialmente para interacciones financieras o de programas de recompensas.
• Recordar a los clientes que las marcas legítimas nunca solicitarán datos completos de tarjetas de crédito, incluido el CVV, a través de páginas de destino vinculadas por SMS.

Para Ejecutivos y CISOs

• Evalúe la exposición de su organización en los sectores más afectados por esta campaña: telecomunicaciones, servicios financieros y programas de fidelización de consumidores, especialmente si opera en México, Chile, Colombia u otros mercados de LATAM.
• Incluya la suplantación de marca basada en PhaaS en el modelo de amenazas de su organización y asegúrese de que la cobertura de Digital Risk Protection incluya el monitoreo de registros de dominios, no solo la respuesta de eliminación.
• Colabore con el Centro de Resistencia al Crimen Digital (DCRC) de Group-IB en Chile para obtener inteligencia de amenazas regional y capacidades de respuesta coordinada adaptadas a sus mercados operativos.

Matriz de Fraude de Group-IB

MITRE ATT&CK

Indicadores de Compromiso (IOCs)

IOCs de Red

47.82.154[.]2

43.165.6[.]36

43.159.168[.]186

154.81.166[.]17

43.162.84[.]202

8.222.134[.]149

45.135.162[.]90

Descargo de Responsabilidad: Toda la información técnica, incluido el análisis de malware, los indicadores de compromiso y los detalles de infraestructura proporcionados en esta publicación, se comparte únicamente con fines defensivos de ciberseguridad e investigación. Group-IB no respalda ni permite ningún uso no autorizado u ofensivo de la información aquí contenida. Los datos y conclusiones representan la evaluación analítica de Group-IB basada en la evidencia disponible y tienen como objetivo ayudar a las organizaciones a detectar, prevenir y responder a las ciberamenazas.

Group-IB renuncia expresamente a cualquier responsabilidad por el uso indebido de la información proporcionada. Se alienta a las organizaciones y lectores a aplicar esta inteligencia de manera responsable y en cumplimiento con todas las leyes y regulaciones aplicables.

Este blog puede hacer referencia a servicios legítimos de terceros, como Telegram y otros, únicamente para ilustrar casos en los que los actores de amenazas han abusado o hecho un uso indebido de estas plataformas.

Este material se proporciona con fines informativos, preparado por Group-IB como parte de su propia investigación analítica, y refleja actividad de amenazas identificada recientemente.

Todas las marcas comerciales mencionadas en este documento son propiedad de sus respectivos dueños y se utilizan únicamente con fines informativos, sin ninguna implicación de afiliación o patrocinio.