ClickFix: el ataque que convence al usuario de pegar el comando en PowerShell
El usuario abre la consola y pega él mismo el comando que le pide una web falsa. No hay adjunto ni ejecutable: por eso la formación clásica no lo detecta.
Los ataques conocidos como ClickFix se están extendiendo y dejan una pregunta incómoda sobre la mesa: qué se hace contra una amenaza en la que el usuario ejecuta el malware con sus propias manos. No hay adjunto, ni ejecutable descargado, ni macro habilitada. Hay una página que simula un CAPTCHA o una pantalla de verificación y le pide a la víctima que abra Run, PowerShell o la Terminal y pegue un comando para demostrar que es humana. La víctima lo pega.
El detalle que fastidia desde el lado de la administración es que la formación al uso no cubre esto. Durante años el mensaje fue no abrir adjuntos sospechosos y no descargar ejecutables de sitios raros. Aquí no hay nada de eso: el comando lo teclea el propio usuario, a veces desde una web que parecía legítima, y la actividad resultante puede pasar por normal.
Hay además un factor cultural que juega en contra. Años de instrucciones de soporte del tipo «abre PowerShell y ejecuta esto» han normalizado la escena. Para mucha gente, pegar un comando que le da una web es una operación de mantenimiento, no una señal de alarma. El hábito, que nació del troubleshooting legítimo, es exactamente el que explota el atacante.
Qué se puede hacer
Las opciones que se barajan entre quienes administran estos entornos no son nuevas, pero aquí ganan peso: reglas de EDR, restringir PowerShell o el cuadro de Run, control de aplicaciones para que solo se ejecute lo autorizado, monitorización del portapapeles y, cómo no, formación. El mensaje formativo tiene que cambiar. Ya no basta con no descargar cosas: hay que decir de forma explícita que ninguna verificación legítima pide pegar un comando en la consola.
Ninguna de esas medidas es un interruptor único. El control de aplicaciones choca con la operativa diaria de mucha gente y restringir PowerShell tiene un coste para quien lo usa para trabajar. Ahí está el equilibrio que cada organización decide, y no hay una respuesta que valga para todas.
Lo que queda por ver es si los fabricantes de EDR empiezan a tratar el patrón como firma propia —un intérprete que arranca justo después de una acción del usuario en el navegador— o si sigue dependiendo de que cada equipo lo detecte y lo bloquee a mano.
