← Volver al blog de ciberseguridad

ClickFix y ACR Stealer: el falso CAPTCHA que roba tokens y ficheros de Microsoft 365

Por Thilina Manana · COO y Director Técnico de Seguridad hard2bit · Publicado: 23 de julio de 2026 · Actualizado: 23 de julio de 2026
Falso CAPTCHA de ClickFix que induce al usuario a ejecutar un comando y roba tokens de Microsoft 365

Durante años, la formación en seguridad se ha apoyado en una idea sencilla: no abras adjuntos sospechosos ni descargues ficheros de remitentes desconocidos. ClickFix le da la vuelta a ese consejo. No hay adjunto, no hay descarga y, en muchos casos, no hay siquiera un fichero que un antivirus pueda analizar. Es el propio usuario quien copia un comando y lo ejecuta con sus manos, convencido de que está superando una verificación rutinaria.

El 16 de julio de 2026, el equipo Defender Experts de Microsoft publicó el análisis de dos campañas del infostealer ACR Stealer que empezaban exactamente así: un falso CAPTCHA que pedía “demostrar que eres humano”. El resultado no era una contraseña robada, sino algo más valioso: contraseñas del navegador, cookies de sesión, tokens de autenticación y ficheros de Microsoft 365 sincronizados en OneDrive y SharePoint. Para una empresa, ese botín equivale a dejar la puerta principal abierta con las llaves puestas.

ClickFix: de curiosidad a segundo vector de acceso inicial

ClickFix es una técnica de ingeniería social documentada por primera vez por Proofpoint a comienzos de 2024. La mecánica es siempre la misma: una página web muestra un mensaje de error falso o una verificación tipo CAPTCHA y, para “arreglarlo” o “confirmar que no eres un robot”, pide al usuario que pegue y ejecute un comando. En su informe de amenazas del primer semestre de 2025, ESET registró un aumento superior al 500% de este tipo de ataques y lo situó como el segundo vector de acceso inicial más habitual, solo por detrás del phishing clásico.

El salto no es casual. ClickFix resuelve el problema que más quebraderos de cabeza da a los atacantes: sortear las defensas de correo y los entornos aislados de análisis. Si no hay adjunto ni descarga automática, no hay nada que un gateway de correo pueda bloquear ni una sandbox que detonar. La ejecución la realiza la persona, a mano, en su propio equipo.

Anatomía del engaño: el usuario como ejecutor

Las variantes del señuelo —falso CAPTCHA al estilo de Cloudflare, error simulado de Word o Chrome, pantalla azul falsa— las desglosamos en nuestra guía completa de defensa frente a ClickFix. Aquí el foco es el desenlace más reciente y su mecánica conceptual, sin convertirlo en un manual: el patrón encadena cuatro condiciones:

  1. Un señuelo creíble. Una web comprometida o suplantada muestra un CAPTCHA o un aviso de verificación calcado a los de Google o Cloudflare. Malwarebytes documentó en julio de 2026 páginas falsas de verificación de ambos servicios distribuyendo varias familias de malware.
  2. Un portapapeles manipulado. Al pulsar el botón de “verificación”, la página coloca de forma silenciosa un comando en el portapapeles del usuario.
  3. Una instrucción disfrazada de trámite. Se pide a la persona que abra el cuadro de diálogo Ejecutar de Windows y pegue lo que cree que es un paso rutinario de la verificación.
  4. Una ejecución legítima. El sistema interpreta ese comando como una acción del propio usuario, con sus permisos y sin ninguna alerta de descarga.

El rastro que deja es, precisamente, lo que interesa al defensor: queda registro de esa ejecución manual, de los procesos que se lanzan a continuación y de las conexiones de red que se abren. Ahí es donde se detecta ClickFix, no en el correo.

ACR Stealer: qué se lleva realmente

En las dos campañas descritas por Microsoft, observadas entre finales de abril y mediados de junio de 2026, el desenlace era ACR Stealer, un ladrón de información especializado en credenciales de navegador y datos corporativos. Las dos cadenas compartían el mismo arranque —el engaño ClickFix— pero divergían en cómo entregaban la carga y esquivaban la detección.

Las dos cadenas de intrusión de ACR Stealer observadas por Microsoft (abril–junio 2026)
CadenaEjecución inicialCarga y evasión
Cadena AClickFix → WebDAV y rundll32.exePowerShell y un cargador en Python
Cadena BClickFix → mshta.exePowerShell ofuscado y carga oculta en una imagen

Fuente: Microsoft Security Blog, 16 de julio de 2026.

Una vez dentro, el objetivo no es solo la contraseña. Según el análisis de The Hacker News sobre estas campañas, ACR Stealer recopila contraseñas guardadas en navegadores basados en Chromium, cookies de sesión, tokens de autenticación, documentos, PDF y datos sincronizados a través de OneDrive y SharePoint. Con las cookies y los tokens de sesión, el atacante puede reutilizar una sesión ya autenticada y operar como el usuario legítimo sin volver a pasar por el inicio de sesión.

Por qué el token de sesión pesa más que la contraseña

Este es el punto que muchas organizaciones aún no han interiorizado. La autenticación multifactor protege el momento del inicio de sesión, pero no la sesión que resulta de él. Cuando un atacante roba una cookie o un token válido, no necesita la contraseña ni el segundo factor: presenta la sesión ya emitida y el servicio la acepta como legítima. Es el mismo desenlace que ya vimos en las campañas de robo de tokens mediante AiTM y en el device code phishing, por caminos de entrada distintos.

Por eso ClickFix resulta tan rentable contra entornos Microsoft 365: no ataca la contraseña, ataca la sesión. Y una sesión robada rara vez dispara las alertas que sí genera un intento de inicio de sesión anómalo desde otro país.

Por qué fallan los controles tradicionales

Tres supuestos habituales se rompen a la vez. El primero, “el correo lo filtra el gateway”: no hay adjunto ni enlace de descarga malicioso que filtrar, porque el usuario llega a la web por una búsqueda, un anuncio o un enlace aparentemente inofensivo. El segundo, “la sandbox lo detonaría”: no hay fichero que detonar, ya que la ejecución es manual. El tercero, “con MFA estamos cubiertos”: el robo de token evita el MFA por completo.

El resultado es que la primera línea de defensa deja de ser el perímetro y pasa a ser el endpoint y la telemetría de identidad. La pregunta ya no es “cómo evito que llegue”, sino “cómo veo la ejecución cuando ocurre y cómo invalido la sesión antes de que le sirva a nadie”.

Detección operativa

Hay varias fuentes de telemetría que, combinadas, delatan una intrusión de este tipo:

  • Historial de Ejecutar de Windows. La clave de registro RunMRU (en HKCU) conserva lo que se ha lanzado desde el cuadro Ejecutar. Microsoft señala que en estas campañas quedaban ahí rastros de rundll32, pushd y conexiones WebDAV.
  • Registro de PowerShell. El registro de bloques de script, el de módulos y la transcripción aportan visibilidad real de lo ejecutado, siempre que esa telemetría se conserve y alguien la revise.
  • Comportamiento del proceso en el EDR. Un navegador o un proceso de usuario que lanza powershell.exe, mshta.exe o rundll32.exe, seguido de conexiones WebDAV salientes, es un encadenamiento anómalo que un EDR bien afinado marca.

Una consulta de caza sencilla en Microsoft Defender parte de esa relación padre-hijo entre el navegador y el intérprete de comandos:

DeviceProcessEvents | where InitiatingProcessFileName in~ ('chrome.exe','msedge.exe','firefox.exe') | where FileName in~ ('powershell.exe','mshta.exe','rundll32.exe') | project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine

Es un punto de partida para caza de amenazas, no una regla lista para producción: hay que ajustarla a las herramientas legítimas de cada organización para reducir falsos positivos.

Defensa práctica

Las medidas que de verdad cambian la ecuación se agrupan en tres frentes.

Reducir la superficie de ejecución

Restringir mediante directiva de grupo el acceso al cuadro Ejecutar para los perfiles que no lo necesitan, aplicar el modo de lenguaje restringido de PowerShell y habilitar las reglas de reducción de superficie de ataque (ASR) que bloquean la ejecución de scripts ofuscados y la creación de procesos hijo desde aplicaciones ofimáticas cierran buena parte del camino.

Proteger la sesión, no solo el inicio de sesión

El robo de token se neutraliza vinculando la sesión al dispositivo. En Microsoft Entra, la protección de tokens y las políticas de acceso condicional que exigen un dispositivo conforme dificultan que una cookie robada sirva en otro equipo. Conviene, además, tener un procedimiento rápido para revocar sesiones y rotar credenciales ante la menor sospecha.

Cerrar el círculo con las personas

La formación tiene que actualizarse. El mensaje ya no es solo “no abras adjuntos”, sino “nunca pegues ni ejecutes un comando que no has escrito tú, por muy oficial que parezca la página”. Un CAPTCHA legítimo jamás pide abrir una terminal ni el cuadro Ejecutar.

Implicaciones para NIS2 y DORA

Para las entidades sujetas a NIS2, ClickFix toca dos obligaciones directas: la gestión del riesgo humano mediante formación y concienciación, y la notificación de incidentes en los plazos previstos cuando una intrusión de este tipo compromete datos o sistemas esenciales. En el sector financiero, DORA añade la exigencia de resiliencia operativa y de control sobre el robo de credenciales que pueda derivar en fraude o interrupción del servicio. En ambos casos, demostrar que existe detección en el endpoint y un procedimiento de respuesta no es un extra: forma parte del cumplimiento.

En esencia

ClickFix funciona porque explota algo que ninguna herramienta parchea del todo: la disposición del usuario a seguir un paso que parece rutinario. La buena noticia para el defensor es que, al mover la ejecución al endpoint, el ataque deja huellas claras —en el historial de Ejecutar, en los registros de PowerShell y en la cadena de procesos— que un EDR vigilado y una identidad bien gobernada convierten en detección temprana. La contraseña dejó de ser el objetivo hace tiempo; hoy lo es la sesión. Defender en consecuencia es lo que separa un intento fallido de una brecha real en Microsoft 365.

Consejo de Hard2bit: si quieres validar cómo respondería tu organización ante una intrusión que arranca con ClickFix, nuestros servicios de threat hunting, SOC gestionado y respuesta a incidentes cubren desde la caza proactiva hasta la contención. Y si el foco es Microsoft 365, la seguridad de Microsoft 365 y la revisión de identidades son el primer sitio por donde empezar.

Este artículo tiene una finalidad divulgativa y defensiva. Las referencias a herramientas, registros y consultas de detección se describen a nivel conceptual para ayudar a los equipos de seguridad a detectar y mitigar la amenaza; no constituyen instrucciones para reproducir el ataque.

Preguntas frecuentes

¿Qué es un ataque ClickFix?

ClickFix es una técnica de ingeniería social en la que una página web muestra un falso CAPTCHA o un mensaje de error y convence al usuario para que copie y ejecute un comando en su propio equipo. Al no haber adjunto ni descarga automática, evita muchas defensas de correo y de análisis, y traslada la ejecución del ataque a la propia víctima.

¿Por qué ClickFix evita los filtros de correo y las sandbox?

Porque no hay un fichero malicioso que interceptar ni detonar. El usuario llega a la web por una búsqueda, un anuncio o un enlace aparentemente inofensivo, y es él quien pega y ejecuta el comando a mano. Los gateways de correo y los entornos aislados están pensados para analizar adjuntos y descargas, no una acción manual del propio usuario.

¿Qué roba ACR Stealer?

Según el análisis de Microsoft de julio de 2026, ACR Stealer recopila contraseñas guardadas en navegadores basados en Chromium, cookies de sesión, tokens de autenticación, documentos, PDF y datos sincronizados a través de OneDrive y SharePoint. Con las cookies y los tokens, el atacante puede reutilizar una sesión ya autenticada de Microsoft 365.

¿El MFA protege frente al robo de tokens de sesión?

La autenticación multifactor protege el momento del inicio de sesión, pero no la sesión que resulta de él. Si un atacante roba una cookie o un token válido, presenta esa sesión ya emitida y el servicio la acepta sin volver a pedir el segundo factor. Por eso conviene añadir protección de tokens y acceso condicional que vincule la sesión al dispositivo.

¿Cómo se detecta ClickFix en el endpoint?

Las señales más útiles son el historial del cuadro Ejecutar de Windows (clave RunMRU), los registros de PowerShell (bloques de script, módulos y transcripción) y el comportamiento del proceso en el EDR: un navegador que lanza powershell.exe, mshta.exe o rundll32.exe seguido de conexiones WebDAV es un encadenamiento anómalo que conviene cazar y revisar.

¿Qué medidas reducen el riesgo de ClickFix?

Restringir el acceso al cuadro Ejecutar por directiva de grupo, aplicar el modo de lenguaje restringido de PowerShell, habilitar reglas ASR que bloqueen scripts ofuscados y la creación de procesos hijo, proteger la sesión con acceso condicional y dispositivo conforme, y actualizar la formación para que nadie pegue ni ejecute comandos que no ha escrito.

¿Qué implicaciones tiene ClickFix para NIS2 y DORA?

Bajo NIS2, afecta a la gestión del riesgo humano mediante formación y a la notificación de incidentes en plazo cuando se comprometen datos o sistemas esenciales. Bajo DORA, en el sector financiero, añade la exigencia de resiliencia operativa y de control del robo de credenciales. En ambos casos, demostrar detección en el endpoint y un procedimiento de respuesta forma parte del cumplimiento.