ClickFix en blockchain: más de 5.400 sitios comprometidos distribuyen código malicioso

WordPress y PrestaShop convertidos en puntos de distribución

Más de 5.400 sitios web comprometidos participan en una operación criminal que combina señuelos ClickFix, smart contracts y comunicaciones WebRTC. Netskope analizó la actividad y la dio a conocer el 5 de septiembre de 2026. La campaña afecta sobre todo a portales creados con WordPress y PrestaShop.

Los atacantes insertan en los sitios un script capaz de recuperar el siguiente payload desde BNB Smart Chain Testnet. De este modo, páginas pertenecientes principalmente a pequeñas empresas se convierten en puntos de distribución de código controlado de forma remota.

No se sabe cómo se produjo el acceso inicial a los sitios. Podrían estar implicados componentes vulnerables, credenciales robadas u otros vectores, pero no hay datos suficientes para determinarlo. Tampoco se han comunicado las versiones de WordPress, PrestaShop o de los posibles plugins afectados.

La operación no está asociada a una vulnerabilidad identificada formalmente: no constan CVE, niveles de gravedad estandarizados ni entradas en el catálogo Known Exploited Vulnerabilities de la CISA. El problema observado afecta a sitios ya comprometidos, no a un fallo específico atribuido a un producto concreto.

La escala es significativa. Netskope estima que se utilizan más de 300 sitios infectados al día. Desde primavera, el número de dominios que contactan con los endpoints RPC de BNB Smart Chain Testnet ha crecido de forma constante. En agosto, la media se acercó a los 400 sitios diarios, con un máximo de 536.

EtherHiding introduce el payload en un smart contract

El script inyectado en los sitios no tiene por qué contener toda la cadena maliciosa. En su lugar, consulta, a través de los endpoints RPC, un smart contract ubicado en BNB Smart Chain Testnet y recupera código o datos de configuración.

Esta técnica se conoce como EtherHiding. La blockchain se utiliza como una capa de distribución persistente, mientras que el sitio comprometido actúa como punto de entrada hacia la víctima.

El uso de la testnet ofrece varias ventajas operativas. La red está destinada a desarrolladores, reproduce el funcionamiento de la mainnet y puede utilizarse de forma gratuita. Además, el tráfico RPC puede confundirse con actividad legítima relacionada con aplicaciones blockchain y herramientas de desarrollo.

Por tanto, para desactivar por completo la campaña no basta con eliminar un servidor web tradicional. El contenido accesible a través del smart contract permanece disponible en la red, lo que complica una acción de desmantelamiento centralizada.

Los atacantes también pueden modificar el contenido proporcionado por el contrato. Esta característica les permite sustituir un señuelo, un stager o una configuración sin tener que volver a inyectar código manualmente en los 5.400 sitios.

Eso es precisamente lo que ocurrió durante la actividad analizada: el payload ClickFix inicial fue sustituido por un stager basado en WebRTC Data Channel.

El CAPTCHA falso convence a la víctima para ejecutar PowerShell

La primera variante observada muestra un CAPTCHA falsificado dentro del sitio comprometido. No se trata de una comprobación técnica real, sino de una instrucción de ingeniería social diseñada para inducir al usuario a comprometer su propio equipo.

Se invita a la víctima a abrir la ventana Windows Run, pegar un comando PowerShell y ejecutarlo. Ese comando descarga y ejecuta el payload final.

ClickFix sortea así uno de los obstáculos habituales de las infecciones a través del navegador. El sitio no tiene necesariamente que explotar una vulnerabilidad del sistema operativo: induce al usuario a ejecutar un comando que parece necesario para resolver un problema o completar una comprobación.

No se ha revelado la naturaleza exacta del payload final. Tampoco hay hashes, nombres de archivo u otros indicadores que permitan vincular la cadena con una familia de malware concreta.

Para los usuarios, la señal más inmediata es de carácter conductual. Un CAPTCHA legítimo no pide abrir Windows Run, pegar comandos ni iniciar PowerShell. Una página que proponga este procedimiento debe cerrarse sin seguir las instrucciones.

La variante WebRTC ejecuta JavaScript sin escribirlo en el disco

En la siguiente fase, los operadores sustituyeron en el smart contract el contenido ClickFix por un stager de JavaScript basado en WebRTC Data Channel.

Los navegadores utilizan normalmente WebRTC para las comunicaciones en tiempo real. En este caso, el stager crea una conexión peer y un canal de datos, generando una descripción de la sesión similar a la que se utiliza durante un handshake normal.

Sin embargo, el flujo es anómalo: el stager construye por sí mismo la respuesta y vuelve a introducirla en la conexión. De este modo evita un handshake efectivo, aunque consigue abrir un canal de datos hacia la infraestructura del atacante.

El código JavaScript se recibe desde una dirección de command-and-control integrada en el stager. Los datos se acumulan en la memoria del navegador y se ejecutan cuando el canal se cierra o cuando transcurren 10 segundos.

La ejecución se realiza de forma dinámica mediante la incorporación del código al elemento head del DOM. Por tanto, el contenido no tiene que guardarse como archivo en el disco.

Este método reduce la cantidad de artefactos disponibles para los controles centrados en los archivos. Sin embargo, no vuelve invisible la actividad: siguen siendo observables las solicitudes RPC, el tráfico WebRTC, el comportamiento del navegador y las comunicaciones con el C2.

La dirección hardcoded del servidor de command-and-control no se ha hecho pública. Tampoco se conocen las direcciones concretas de los endpoints RPC implicados, aunque Netskope ha indicado un conjunto de endpoints que deben bloquearse en sus recomendaciones.

Controles que deben aplicarse en sitios, redes y endpoints

Los administradores de sitios WordPress y PrestaShop deberían examinar las páginas, las plantillas y los componentes en busca de scripts inyectados. El análisis debe incluir las solicitudes dirigidas a endpoints RPC de BNB Smart Chain Testnet y la comparación con el comportamiento previsto del portal.

La ausencia de versiones vulnerables conocidas impide limitar la intervención a un único parche. Mantener actualizados el CMS y sus componentes sigue siendo una medida útil, pero no demuestra que un sitio ya comprometido haya quedado limpio. Es necesario comprobar directamente el código y las llamadas de red.

Para los equipos de defensa corporativa, Netskope recomienda:

• bloquear el conjunto de endpoints RPC de BNB Smart Chain Testnet identificado por los investigadores;
• supervisar el tráfico UDP no web asociado a WebRTC;
• buscar solicitudes RPC anómalas procedentes de sitios WordPress y PrestaShop;
• detectar PowerShell iniciado a través de Windows Run;
• controlar la ejecución dinámica de JavaScript en la memoria del navegador;
• identificar conexiones con direcciones C2 integradas en el código.

El bloqueo indiscriminado requiere evaluar los usos legítimos de la testnet, especialmente en entornos de desarrollo. Cuando no sea posible aplicarlo, las solicitudes RPC deberían registrarse y correlacionarse con el dominio de origen, el navegador, el proceso y el tráfico WebRTC posterior.

Por tanto, los indicadores más útiles forman una cadena. Una visita a un sitio, seguida de una llamada RPC a la testnet y de la apertura de un canal WebRTC inesperado, ofrece una señal más sólida que cualquiera de esos eventos considerado de forma aislada.

Tras el acceso inicial, muchas acciones siguen sin ser detectadas

La operación muestra dos niveles de compromiso distintos. Por un lado están los responsables de los sitios, cuya infraestructura se utiliza para llegar a otras víctimas. Por otro, los usuarios, expuestos a comandos PowerShell o a JavaScript entregado mediante WebRTC.

No se ha atribuido nominalmente la actividad a ningún atacante. También siguen sin conocerse el método utilizado para vulnerar los sitios y el destino final de todas las cadenas de infección.

El Blue Report 2026, citado por separado por Netskope, ayuda a contextualizar el problema de las fases posteriores al acceso. A partir de 338 millones de simulaciones realizadas en los entornos de producción de sus clientes, el informe concluye que, después de utilizar credenciales válidas, solo se bloquea el 37 % de las acciones de los atacantes.

Ese dato no atribuye la campaña ClickFix a un vector específico ni demuestra que se utilizaran credenciales robadas. Sin embargo, pone de manifiesto las limitaciones de una defensa evaluada únicamente por su capacidad para detener el acceso inicial.

En esta operación, la detección debe seguir toda la cadena: compromiso del sitio, consulta de la blockchain, interacción con la víctima, PowerShell o WebRTC y, finalmente, comunicación con el C2. Detener cualquiera de estos pasos puede interrumpir el ataque. Ignorar su correlación, en cambio, deja a los operadores varias rutas alternativas.