Los ataques a velocidad de máquina exigen detección y respuesta a la misma velocidad

Un análisis de Exaforce, publicado el 22 de octubre de 2026, concluye que los atacantes ya son capaces de enumerar o extraer datos en un plazo de 15 minutos desde que consiguen entrar en un entorno, y que las herramientas que deberían haberlos detectado no resultaron eficaces. El estudio describe tres patrones de ataque habituales en los que se observó este comportamiento.

Tokens de desarrollador robados. Los paquetes npm envenenados y los infostealers extraen tokens de GitHub de los portátiles de los desarrolladores; después, los atacantes los emplean para exfiltrar datos de GitHub. GitHub no dispone de detecciones nativas sobre cómo se usa un token, lo que deja a las empresas expuestas al robo de código.
Señuelos ClickFix contra herramientas de IA. Comandos de instalación falsos de Claude Code en chats compartidos de Claude cargan un stealer para macOS que captura cookies del navegador y credenciales de la nube. La víctima ejecuta los comandos por sí misma, igual que haría al instalar cualquier herramienta, lo que puede activar o no una detección en el endpoint.
Vishing al servicio de ayuda. Los atacantes recurren a la ingeniería social y se hacen pasar por el equipo de TI para que un empleado apruebe una solicitud MFA real en una página de inicio de sesión clonada. Los proveedores de identidad pueden considerar legítimo el acceso del atacante, lo que los vuelve ineficaces para detectar estos incidentes.

Detectar estos incidentes requiere capacidades de detección basadas en datos y comportamiento; detenerlos exige una respuesta autónoma. El artículo aborda ambas cuestiones.

Tokens durmientes en portátiles de desarrolladores

En marzo, un desarrollador instaló GitHub Desktop, inició sesión y dejó de usarlo ese mismo día. El token OAuth que generó permaneció en el llavero del Mac durante 95 días. El 19 de junio, otra persona empezó a utilizarlo. El token extrajo 76 repositorios en unos 15 segundos a través de proxies residenciales en más de dos docenas de ciudades europeas. GitHub no emitió ninguna alerta porque nada en su sistema vigila cómo se usan los tokens. La plataforma de Exaforce lo señaló en cinco minutos y lo trió en diez. Los analistas del servicio MDR confirmaron la exfiltración y notificaron al cliente minutos después de que saltara la detección, pero cuando se tomó cualquier medida el atacante ya había exfiltrado datos de 472 de los 638 repositorios.

Este caso ilustra las dos mitades del problema: sin detección de anomalías nadie habría sabido que el token estaba en uso, y con una detección adecuada la contención habría requerido igualmente aprobación humana, dando al atacante tiempo suficiente para exfiltrar datos. Las funciones de seguridad de GitHub se centran en inspeccionar código y secretos, no en el uso indebido de tokens. La detección se logró combinando señales débiles sobre una única sesión de GitHub: inicios de sesión desde redes y ciudades nunca vistas, descargas de archivos ZIP a velocidad de máquina, un user agent de Windows en una cuenta que solo había usado macOS. Cada señal por separado puede tener explicación, pero todas juntas indican actividad maliciosa.

Los tokens de aplicaciones OAuth con prefijo gho_ no caducan y GitHub solo los revoca por su cuenta tras un año. En las pruebas realizadas, la página de SSO de la organización ni siquiera los enumera y solo son visibles a través de la CLI. Desactivar al desarrollador en el proveedor de identidad tampoco detiene el token: sin SCIM, GitHub sigue aceptándolo hasta que alguien lo revoque o elimine al usuario de la organización. Los desarrolladores que usan herramientas de codificación con IA instalan paquetes npm y conectan servidores MCP todo el día, en gran medida fuera de los flujos que vigilan los equipos de seguridad, y gusanos como Shai-Hulud recorren la máquina en busca de tokens de GitHub y de nube en cuanto se instala un paquete envenenado. Esto ocurre antes de cualquier confirmación de cambios, por lo que escanear los repositorios para determinar si un paquete npm comprometido pudo afectar no es suficiente.

ClickFix se dirige a las instalaciones de herramientas de IA

Robar un token del llavero de macOS suele requerir un infostealer que engañe para obtener la contraseña de inicio de sesión. Los últimos señuelos ClickFix aprovechan la confianza en las herramientas de IA. En uno de esos incidentes, un empleado que buscaba instrucciones para instalar Claude Code acabó en una conversación compartida de Claude con un comando de instalación de una sola línea. El comando carga un stealer para macOS que simula una solicitud de contraseña de Preferencias del Sistema y después copia el llavero, las cookies del navegador, las contraseñas guardadas y las credenciales de la nube.

Como es la víctima quien ejecuta el comando, se eluden el filtrado de correo y los controles de descargas. El enfoque más eficaz para detectar este tipo de ataques es una solución de detección en el endpoint. Evaluar el alcance del impacto debería implicar un análisis exhaustivo de todos los tokens y credenciales generados por el usuario.

Llamadas falsas de TI que acaban en sesiones robadas

En los casos de vishing gestionados este año, el atacante registró su propio dispositivo MFA y puso en marcha un script de descarga masiva entre 2,5 y 7 minutos después de que la víctima aprobara la solicitud. En uno de ellos exfiltró 140.000 archivos y exigió un rescate por los datos filtrados.

La mayoría de estas llamadas siguen el guion de servicio de ayuda que suele emplear el grupo Scattered Spider. Un interlocutor que se hace pasar por TI dirige al empleado a una página de inicio de sesión con el nombre de la empresa en la URL, como el dominio contoso.add-passkey[.]com citado en el informe de Microsoft de septiembre. La página redirige el acceso mediante un proxy de adversario en el medio (AiTM) o el atacante guía a la víctima por un inicio de sesión con código de dispositivo. Uno de los kits analizados, alojado en oskeysetup[.]com, estaba escrito desde cero, de modo que las detecciones diseñadas para Evilginx y otros kits públicos no resultan eficaces.

En la mayoría de los casos, las detecciones de los proveedores de identidad resultan ineficaces porque las víctimas aprueban una solicitud MFA real. En un secuestro de sesión de julio, Microsoft marcó el primer inicio de sesión del atacante como riesgoso y después lo dio por remediado porque el usuario había superado el MFA. En cuestión de minutos, el token robado se reprodujo desde otros dos países en un segundo, y las alertas posteriores de Microsoft elevaron el nivel de riesgo del usuario. Exaforce lo detectó vinculando los inicios de sesión de Okta y Microsoft y comparándolos con el historial del usuario: era el primer acceso de la cuenta desde Estados Unidos, en un dispositivo Linux y a través de un ISP doméstico que la cuenta nunca había usado. En estos casos, la primera señal fuerte suele ser un nuevo método MFA desde un dispositivo y una red que el usuario nunca ha tocado. También se observó que los atacantes atacan a la misma empresa a través de varios empleados, a menudo usando los mismos servidores y dominios.

Acciones de respuesta autónoma

Un enfoque eficaz para contrarrestar estos incidentes es avanzar hacia la respuesta autónoma. Automatizar la respuesta no es nuevo, pero el temor siempre ha sido a las consecuencias de una acción equivocada que bloquee a un directivo o rompa una integración en producción. Los autores consideran mejor clasificar las acciones por fricción: cuánto costaría al propietario de la credencial una respuesta errónea. Si solo le cuesta un nuevo inicio de sesión o volver a inscribir el teléfono, la acción es de baja fricción y puede ejecutarse ante un hallazgo de alta confianza. Esto cubre revocar sesiones, eliminar un método MFA registrado durante la sesión señalada y desactivar una clave que puede volver a activarse.

Los restablecimientos de contraseña, la desactivación de cuentas, las eliminaciones permanentes y cualquier acción de la que dependa un servicio en producción deben requerir aprobación humana. Esa persona puede ser el usuario objetivo y su responsable, confirmando en un mensaje rápido que el inicio de sesión no fue suyo. Aunque la mayoría de estas acciones se relacionan con una identidad o sus credenciales asociadas, no pueden limitarse al proveedor de identidad: restablecer la contraseña de Okta o cerrar su sesión no revoca los tokens que Microsoft 365, Google Workspace o GitHub ya emitieron, y las sesiones de AWS y Snowflake iniciadas por SSO siguen activas.

En los casos de vishing analizados, la exfiltración de datos continuó entre 44 minutos y 3 horas después de revocar la sesión en el IdP, y en un caso las reglas de bandeja de entrada del atacante sobrevivieron a un restablecimiento de contraseña. El Universal Logout de Okta alcanza algunas aplicaciones, como Google Workspace y Slack, pero no GitHub, Snowflake ni los proveedores de modelos de IA. Conviene preparar de antemano las acciones de revocación de cada aplicación, junto con la cuenta que las ejecuta; se ha observado cómo una acción de respuesta fallaba en mitad de un incidente con un error 403 porque nadie había concedido los permisos necesarios. Los autores recomiendan empezar por los servicios que albergan los datos más críticos.

Productividad: Google Workspace, Office 365, Box, Dropbox, Slack
Nube: AWS, GCP, Azure
Servicios de IA: Anthropic, OpenAI
Datos: Snowflake, Databricks
Código: GitHub, GitLab

Acciones de baja fricción recomendadas para empezar

Okta — Acción: revocar sesiones y los tokens OAuth emitidos por Okta. API: DELETE /api/v1/users/{id}/sessions?oauthTokens=true. Permisos: ámbitos okta.users.read y okta.users.manage, más un rol de administrador personalizado que solo incluya okta.users.read y okta.users.lifecycle.clearSessions.
Okta — Acción: restablecer todos los factores del usuario, incluido el del atacante. API: POST /api/v1/users/{id}/lifecycle/reset_factors. Permisos: los mismos ámbitos, añadiendo okta.users.credentials.resetFactors al rol.
Microsoft Entra ID — Acción: revocar tokens de actualización y cookies de sesión. API: POST /users/{id}/revokeSignInSessions. Permisos: User.RevokeSessions.All, más User.Read.All para consultar el usuario.
Microsoft Entra ID — Acción: eliminar los métodos MFA del usuario, incluido el del atacante. API: DELETE /users/{id}/authentication/{type}Methods/{methodId} para cada método de teléfono, aplicación Authenticator, OATH de software, FIDO2, Windows Hello y Temporary Access Pass. Permisos: UserAuthenticationMethod.ReadWrite.All, más User.Read.All.
Google Workspace — Acción: terminar sesiones web y de dispositivos, y revocar los tokens OAuth de la aplicación. API: POST /admin/directory/v1/users/{userKey}/signOut y DELETE /admin/directory/v1/users/{userKey}/tokens/{clientId}. Permisos: ámbito admin.directory.user.security y un rol de administrador delegado.
GitHub Enterprise Cloud, SSO SAML a nivel de organización — Acción: eliminar el token robado de la organización. API: GET /orgs/{org}/credential-authorizations?login={user} para localizarlo y después DELETE /orgs/{org}/credential-authorizations/{credential_id}. Permisos: propietario de la organización con admin:org, o una GitHub App con Administration (write) de la organización; no hay una opción más restringida.
Snowflake — Acción: desactivar un token de acceso programático. API: SQL propio, como ALTER USER {name} MODIFY PAT {token} SET DISABLED TRUE, enviado mediante la API SQL POST /api/v2/statements. Permisos: un usuario de servicio dedicado cuyo rol tenga MODIFY PROGRAMMATIC AUTHENTICATION METHODS sobre el usuario.
AWS — Acción: terminar las sesiones STS ya emitidas a un usuario IAM. API: PutUserPolicy con una denegación en línea sobre las sesiones emitidas antes de ese momento (aws:TokenIssueTime). Permisos: iam:PutUserPolicy, más iam:GetUser e iam:GetUserPolicy.
Anthropic — Acción: desactivar una clave de API. API: POST /v1/organizations/api_keys/{id} con {"status":"inactive"}. Permisos: clave de API de administración.

Cómo gestionó Exaforce estos ataques

Exaforce es una plataforma Agentic SOC con un servicio MDR opcional. Sus agentes, denominados Exabots, se encargan de la ingeniería de detección, la triaje de alertas, las investigaciones, la búsqueda de amenazas y la respuesta. Los agentes operan sobre una plataforma de datos unificada que puede funcionar como SIEM o junto al SIEM existente. La plataforma incluye 800 detecciones de anomalías basadas en IA y aprendizaje automático que ayudan a detectar los incidentes descritos en servicios críticos de nube, SaaS, identidad, endpoint e IA. Dispone de más de 100 acciones de respuesta dinámicas que los agentes pueden ejecutar, de modo que las organizaciones no tienen que construirlas ni mantenerlas por sí mismas para todos sus servicios críticos.

El artículo está patrocinado y redactado por Exaforce.