Hard2bit
← Volver al blog

ClickFix y los CAPTCHA falsos: cómo defender a tu organización de la trampa del "pega y ejecuta"

Por Thilina Manana · COO y Director Técnico de Seguridad hard2bit · Publicado: 15 de junio de 2026 · Actualizado: 15 de junio de 2026
ClickFix y los CAPTCHA falsos

Hay una técnica que en dieciocho meses ha pasado de curiosidad de investigador a vector mayoritario de entrega de malware en correo electrónico. Se llama ClickFix y consiste en algo tan elemental que casi avergüenza describirlo: el atacante convence a la víctima de que copie un texto, lo pegue en una ventana del sistema operativo y pulse Enter. Lo que se ejecuta es PowerShell, mshta, curl o cualquier intérprete que esté disponible en Windows, y lo hace con los permisos del usuario.

Las cifras explican por qué deberías leer esto y luego comprobar tu propia capa de detección. ESET, en su informe de telemetría del primer semestre de 2025, documenta un crecimiento de las campañas ClickFix y FakeCAPTCHA del 517% respecto al segundo semestre de 2024. Microsoft publicó en agosto de 2025 un análisis dedicado, «Think before you Click(Fix)», en el que confirma que la técnica afecta a millares de dispositivos al día en su telemetría global y la sitúa como uno de los métodos de entrega más eficaces que se han visto en años.

Anatomía de la trampa

Lo que hace difícil cortar ClickFix es que el envoltorio cambia cada pocos meses, pero la mecánica es siempre la misma: una página o un mensaje convencen al usuario de que el problema lo arregla pegando algo en una ventana del sistema. Estos son los cinco disfraces que están circulando en 2025 y 2026, cada uno documentado en campañas reales.

CAPTCHA falso del estilo Cloudflare

La víctima aterriza en una página comprometida o servida desde malvertising y encuentra el clásico recuadro «verifica que eres humano». Las casillas habituales son aquí imposibles de pulsar. En su lugar la página ofrece una alternativa: «paso 1, pulsa Win+R; paso 2, pulsa Ctrl+V; paso 3, pulsa Enter». Lo que está en el portapapeles ya es una línea de PowerShell ofuscada. La estética imita a Cloudflare deliberadamente para reducir la fricción del clic.

Error simulado de Word, Chrome o reproductor de vídeo

Otra variante muy vista por Proofpoint en campañas TA571 es el adjunto HTML que renderiza un mensaje de error de Microsoft Word del tipo «Word no puede mostrar este documento. Para repararlo, pega este comando en PowerShell». El mismo patrón aparece con un fallo simulado de Chrome, un códec faltante de vídeo o un error de DNS. El comando es siempre el mismo en estructura: descarga un segundo script y lo lanza.

Verificación humana en sitios de descarga

Las campañas más recientes han movido el lure a páginas que prometen software pirata, cracks, drivers, claves de licencia o herramientas IA. Antes de la descarga, una pantalla pide al usuario «verificar que no es un bot». La verificación, como en el caso anterior, es pegar y ejecutar.

Enlace falso de reunión o invitación

En marzo de 2025 Microsoft documentó cómo el grupo Storm-1865 atacaba al sector hostelería suplantando a Booking.com: correos legítimos en apariencia que llevaban a un enlace falso de reservas; la página presentaba un CAPTCHA que servía la carga ClickFix. La misma plantilla se ha visto reutilizada con falsas invitaciones de Microsoft Teams, Google Meet y Zoom.

Falsa pantalla azul de Windows

La variante más reciente, observada por equipos de respuesta a incidentes en el sector hostelería a finales de 2025, llega al usuario con una pantalla azul a tamaño completo del navegador que imita el BSOD de Windows. El texto «error» pide ejecutar una orden de PowerShell que supuestamente repara el sistema. La calidad gráfica es suficientemente buena como para que un usuario sin formación técnica no distinga la simulación de la pantalla real.

Qué ocurre cuando la víctima pega y ejecuta

La parte interesante para un equipo de seguridad no es el lure: es lo que ocurre en los segundos siguientes a pulsar Enter. La cadena típica de una campaña ClickFix moderna sigue cuatro pasos.

  • Win+R abre el cuadro de diálogo Ejecutar y la víctima pega la cadena del portapapeles. La actividad queda registrada en HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU, lo que es una de las mejores fuentes de evidencia forense una vez la cosa pasa.
  • La cadena pegada suele empezar por powershell.exe, mshta.exe, curl, bitsadmin o conhost con parámetros como -EncodedCommand o -WindowStyle Hidden. La línea está pensada para ser leída de izquierda a derecha sin levantar sospechas: termina con un comentario que parece un identificador de ticket o un código de error.
  • El intérprete descarga un segundo script desde un dominio rotatorio, frecuentemente un alojamiento legítimo comprometido (WordPress, Pastebin, cloud storage). Ese segundo script es el verdadero loader: añade persistencia, desactiva controles si puede y carga el payload final en memoria.

El payload final está bien documentado. Proofpoint y otros equipos lo han asociado de manera recurrente a Lumma Stealer, NetSupport RAT, AsyncRAT, DanaBot, Latrodectus y XWorm. ESET observa además StealC, Quasar RAT y, en campañas dirigidas, implants a medida. La intención final varía: robo de credenciales y cookies de sesión en estafas financieras, posicionamiento previo a ransomware, espionaje en ataques estado-nación.

La adopción por actores estado-nación importa para calibrar el riesgo. Entre octubre de 2024 y abril de 2025 se confirmó el uso de ClickFix por APT28 (Rusia), Kimsuky (Corea del Norte) y MuddyWater (Irán), algo que sucede únicamente cuando una técnica es lo bastante madura como para ser fiable en operaciones de espionaje real.

Por qué los controles tradicionales fallan

ClickFix no llega como adjunto malicioso ni como ejecutable descargado: lo que llega es un texto. La víctima copia y pega un comando que se ejecuta con sus propios permisos, en un binario firmado por Microsoft, sin disparar la mayoría de las heurísticas habituales. Tres motivos concretos explican el éxito de la técnica.

Primero, los gateways de correo no ven nada malicioso: el cuerpo es texto. La página intermedia puede ser un dominio limpio recién registrado o un sitio legítimo comprometido. Las plataformas de filtrado web suelen llegar tarde a categorizarla.

Segundo, la ejecución la inicia el propio usuario en su sesión. EDR y antivirus modernos no bloquean por defecto a powershell.exe lanzado desde explorer.exe: es una secuencia normal en cualquier estación. Detectarlo requiere mirar la línea de comandos, no el binario.

Tercero, las campañas de concienciación clásicas entrenan al usuario a no abrir adjuntos ni hacer clic en enlaces sospechosos. ClickFix no pide ninguna de esas dos cosas: pide pegar texto, que en la cultura ofimática es un acto inocuo. El reflejo defensivo está mal calibrado.

Detección operativa que sí funciona

La buena noticia es que ClickFix deja huella telemétrica clara si la cazas en el sitio correcto. Hay tres puntos de observación que conviene dejar afinados ya. Cazas concretas con KQL para Microsoft Defender XDR están publicadas y validadas por la comunidad.

RunMRU como evidencia primaria

La clave de registro HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU guarda lo que el usuario ha escrito en el cuadro Ejecutar. En una estación corporativa sana, esa clave no debería contener cadenas con powershell, mshta, curl, IEX, FromBase64String, encodedcommand ni URLs. Una regla que dispare ante cualquiera de esos términos en la creación o modificación del valor da casi cero falsos positivos. Sysmon EventID 13 con filtros específicos cubre el mismo punto si no usas Defender for Endpoint.

Árbol de procesos anómalo

La cadena explorer.exe → powershell.exe (o mshta.exe, conhost.exe, cmd.exe) con argumentos largos codificados es altamente sospechosa. La mayoría de los EDR permiten alertar sobre líneas de comandos que contengan los parámetros -EncodedCommand, -nop, -W hidden o IEX. Si tu organización usa PowerShell legítimamente para administración, restringe el script logging y bloquea el modo no constrained con AppLocker o WDAC para que los scripts ad hoc fallen.

Telemetría de red posterior

El loader siempre habla con un dominio externo para descargar el segundo stage. Una conexión saliente de powershell.exe o mshta.exe a un dominio recién registrado o a un servicio de pastebin debería ser una alerta de severidad alta. Si tienes un servicio gestionado de gestión de la superficie de ataque, conviene cruzar IOC con la cobertura de dominios sospechosos que ya estés monitorizando.

Defensas que sí funcionan

Una vez entendido el árbol de comportamiento, la defensa se mueve de la detección reactiva a controles preventivos concretos. No hay un solo botón que apague ClickFix; lo que funciona es combinar tres capas.

Reducir la superficie en el endpoint

Las reglas de reducción de superficie de ataque (ASR) de Microsoft Defender bloquean varios de los binarios que la cadena ClickFix necesita. Las reglas documentadas más útiles contra esta técnica son las que bloquean la ejecución de scripts ofuscados, las que impiden a aplicaciones de Office crear procesos hijo, las que bloquean la creación de procesos desde comandos PSExec/WMI y las que cierran la ejecución de archivos no firmados desde el endpoint. Ninguna es perfecta; las cuatro juntas suben considerablemente el coste de la operación para el atacante.

Más allá de ASR, conviene revisar GPO para limitar quién tiene el cuadro Ejecutar habilitado en estaciones corporativas. La eliminación de Win+R en perfiles estándar mediante directiva no rompe productividad y mata el lure más extendido. Para perfiles de administración o desarrollo, AppLocker o WDAC restringiendo qué binarios pueden invocarse desde sesiones interactivas hace lo propio sin afectar a la operativa.

Reforzar PowerShell y mshta

PowerShell Constrained Language Mode, script block logging activado y envío al SIEM, transcripción habilitada y AMSI integrado son la base mínima. Mshta.exe rara vez tiene un uso legítimo en una estación de empleado y conviene bloquearlo por completo en perfiles sin necesidad técnica. Bitsadmin, certutil, regsvr32 y rundll32 son LOLBins habituales y merecen reglas WDAC explícitas.

Capa de identidad y respuesta

Cuando el payload roba credenciales y cookies de sesión, una autenticación bien diseñada limita el alcance del daño. Phishing-resistant MFA en accesos privilegiados, sesiones cortas en aplicaciones críticas y bloqueo de protocolos legacy son controles que funcionan no porque eviten ClickFix, sino porque reducen el valor del robo de cookies. La identidad es la última línea cuando la pieza de endpoint ha fallado.

Formación que sí funciona, y la que no

Las simulaciones de phishing tradicionales no preparan al usuario para ClickFix. Quien recibe el lure no abre un adjunto ni hace clic en un enlace dudoso: ve un mensaje que le pide pegar tres líneas y pulsar Enter. Si el equipo de seguridad no ha entrenado explícitamente ese reflejo, el usuario lo hará.

Lo que sí enseña a la plantilla es una regla operativa breve y clara: ningún proveedor legítimo, ningún sistema de la empresa y ninguna página web va a pedirte nunca que pegues comandos en una ventana del sistema. Ninguno. Si te lo piden, es siempre fraude. Esa frase, repetida en formación, en cartelería interna y en el onboarding técnico, es más útil que cinco simulaciones de correo phishing. Para el departamento de IT y desarrollo conviene además entrenar el reflejo de leer la línea de comandos antes de ejecutarla, especialmente cuando se copia de Stack Overflow, ChatGPT o documentación externa.

Hay una variante interesante: parte de la formación debería simular ClickFix internamente con un comando inocuo (por ejemplo, que abra calc.exe y notifique al equipo de seguridad). Esa simulación, ejecutada con autorización y comunicación previa al comité de empresa, mide el riesgo real mucho mejor que una simulación de correo.

Si ya ha caído tu organización

La respuesta a una infección ClickFix es la respuesta a un compromiso de endpoint con potencial de movimiento lateral y robo de credenciales. El orden importa: aislar la estación afectada, recoger la clave RunMRU y el árbol de procesos como evidencia, rotar contraseñas y revocar tokens de sesión de la cuenta afectada en Microsoft Entra ID o el IdP equivalente, escanear el resto del estate buscando los mismos IOC, y abrir el procedimiento formal de respuesta a incidentes. Conviene no asumir que un único endpoint era el único objetivo: las campañas ClickFix suelen rebotar contra varias víctimas dentro de una misma organización antes de tener éxito.

Si no se dispone de capacidad propia para mover esos pasos en horas, un servicio gestionado de respuesta a incidentes o un SOC con cobertura 24x7 marcan la diferencia entre un incidente contenido y una brecha con notificación regulatoria.

Lo que viene

ClickFix no va a desaparecer en 2026. La técnica es barata, fiable y se está mercantilizando: ya hay kits de ClickFix-as-a-Service vendidos en foros que incluyen plantillas de CAPTCHA, dominios rotatorios y elección de payload. Para una organización mediana, prepararse no es comprar una herramienta nueva, es ajustar reglas en el endpoint que probablemente ya tienes, escribir tres consultas de cacería, revisar políticas de PowerShell y rediseñar la formación con esa única frase clara. Para acompañar ese trabajo, un proveedor MSSP que combine SOC gestionado con respuesta a incidentes y conozca tu pila de Microsoft 365 es el modelo de soporte más razonable cuando no se tiene equipo interno con capacidad de cazar a este nivel.

Para una foto rápida del lado expuesto de tu organización antes de subir el listón de detección, Hard2bit Scanner devuelve en menos de un minuto la postura externa pública del dominio. Es el punto de partida más rápido para saber dónde un atacante con un lure ClickFix tendría más probabilidad de llegar primero.

Fuentes externas citadas

ESET Threat Report H1 2025 (Help Net Security): helpnetsecurity.com/2025/06/26/clickfix-attacks-fakecaptcha-eset-report. Microsoft Security Blog, «Think before you Click(Fix)» (21 agosto 2025): microsoft.com/en-us/security/blog/2025/08/21/think-before-you-clickfix. Microsoft sobre Storm-1865 y Booking.com (13 marzo 2025): microsoft.com/en-us/security/blog/2025/03/13/phishing-campaign-impersonates-booking-com. Proofpoint, ClickFix landscape: proofpoint.com/us/blog/threat-insight/security-brief-clickfix. BleepingComputer, actores estado-nación adoptan ClickFix: bleepingcomputer.com/news/security/state-sponsored-hackers-embrace-clickfix. ASR rules reference (Microsoft Learn): learn.microsoft.com/defender-endpoint/attack-surface-reduction-rules-reference. KQL hunts para Defender XDR: kqlquery.com/posts/investigate-clickfix.

Preguntas frecuentes

¿Qué es exactamente ClickFix?

Es una técnica de ingeniería social en la que un atacante convence a la víctima de copiar un texto, pegarlo en una ventana del sistema operativo (normalmente el cuadro Ejecutar de Windows o un terminal) y pulsar Enter. Lo que se ejecuta es PowerShell, mshta o un binario equivalente que descarga malware con los permisos del propio usuario. El envoltorio puede ser un CAPTCHA falso, un error simulado de Word, una pantalla azul ficticia o un enlace de reunión.

¿Por qué ClickFix ha crecido tanto en 2024 y 2025?

Porque combina cuatro cosas que funcionan a favor del atacante: el contenido del correo es texto plano y los gateways no lo bloquean; la ejecución la inicia el usuario en su sesión, lo que evita muchas heurísticas de antivirus; el comando se ejecuta en un binario firmado por Microsoft; y las campañas de concienciación clásicas no entrenan el reflejo de no pegar comandos en una ventana del sistema. ESET cifró el crecimiento en un 517% entre el segundo semestre de 2024 y el primero de 2025.

¿Es ClickFix lo mismo que phishing?

No exactamente. El phishing tradicional pide hacer clic en un enlace o abrir un adjunto. ClickFix no pide ni una cosa ni la otra: pide copiar texto, pegarlo en el sistema y pulsar Enter. Por eso supera a muchos filtros y a buena parte de las simulaciones de phishing. Comparte con el phishing el componente de ingeniería social, pero la cadena técnica posterior es distinta.

¿Qué malware se entrega con ClickFix?

En las campañas más documentadas aparecen Lumma Stealer, NetSupport RAT, AsyncRAT, DanaBot, Latrodectus, XWorm, StealC y Quasar RAT. En operaciones dirigidas por grupos estado-nación (APT28, Kimsuky, MuddyWater) se han observado implants a medida. El objetivo varía: desde robo de credenciales y cookies de sesión hasta posicionamiento previo a ransomware o espionaje.

¿Cómo se detecta ClickFix en una organización?

Hay tres puntos de observación. Primero, la clave de registro RunMRU en HKCU guarda lo que el usuario escribió en el cuadro Ejecutar; cualquier valor que contenga powershell, mshta, curl, IEX, EncodedCommand o URLs es altamente sospechoso. Segundo, el árbol de procesos explorer.exe lanzando powershell.exe con parámetros largos codificados. Tercero, conexiones salientes desde powershell.exe o mshta.exe hacia dominios recién registrados. Hay consultas KQL públicas para Defender XDR que cubren estos tres puntos.

¿Qué controles preventivos funcionan contra ClickFix?

Las reglas ASR de Microsoft Defender que bloquean scripts ofuscados, ejecución de hijos desde Office y procesos no firmados. Bloqueo de Win+R en perfiles estándar vía GPO. PowerShell Constrained Language Mode con script block logging enviado al SIEM. AppLocker o WDAC restringiendo mshta, bitsadmin, certutil, regsvr32 y rundll32 en estaciones de empleado. Y phishing-resistant MFA en accesos privilegiados para reducir el daño cuando el robo de credenciales tenga éxito.

¿Sirve la formación al usuario contra ClickFix?

Sí, pero no la formación clásica de phishing. Lo que funciona es una regla operativa breve y clara: ningún proveedor, sistema interno o página web va a pedirte nunca pegar comandos en una ventana del sistema. Si te lo piden, es fraude. Esa frase repetida en formación, cartelería y onboarding es más eficaz que cinco simulaciones de correo. Conviene además simular ClickFix internamente con un comando inocuo y autorización previa para medir riesgo real.

¿Qué hacer si una estación ha caído a ClickFix?

Aislar la estación afectada y preservar la clave RunMRU y el árbol de procesos como evidencia. Rotar contraseñas y revocar tokens de sesión de la cuenta en Microsoft Entra ID o el IdP equivalente. Buscar los mismos indicadores en el resto del estate, porque las campañas suelen rebotar contra varias víctimas dentro de la misma organización. Abrir el procedimiento formal de respuesta a incidentes. Si no se dispone de capacidad propia para mover esos pasos en horas, un servicio gestionado de respuesta a incidentes o un SOC 24x7 marca la diferencia.