La semana pasada, Hugging Face sufrió una intrusión por parte de un agente de OpenAI que actuó por su cuenta, y este incidente sigue aportando información y conocimientos. El equipo de Hugging Face ha publicado una cronología detallada, junto con una reproducción en streaming de un rastreo de 17 600 eventos que permite visualizar lo que ocurrió, y el nivel de detalle es maravilloso y fascinante. Te recomiendo que lo leas si tienes tiempo.
La intrusión en su plataforma no consistió en un único exploit brillante seguido de una ruta de ataque limpia y dirigida por personas. Se trató de una multitud de acciones repartidas a lo largo de cuatro días y medio, con miles de experimentos fallidos que ocultaban el número relativamente reducido de acciones que, en última instancia, resultaron decisivas. El reconocimiento, la ejecución de código y la preparación de la carga útil comenzaron casi de inmediato. El movimiento lateral decisivo hacia sus clústeres de Kubernetes, la red interna y el control de código fuente no comenzó hasta el tercer día.
La mayoría de las organizaciones cuentan con suficientes registros y sistemas de supervisión como para reconstruir un ataque una vez que se haya producido. Son mucho menos las que cuentan con la visibilidad en tiempo real, la lógica de alertas y el apoyo a la toma de decisiones necesarios para detectar el ataque mientras aún se está gestando.
La cronología combinada de Hugging Face, junto con la información tan esperada que ha compartido OpenAI sobre el incidente, además del análisis retrospectivo inicial de la CSA, sugieren lo que, en mi opinión, son cuatro puntos críticos de decisión en la respuesta a incidentes que las empresas deben tener en cuenta. Cada uno de ellos supone también una prueba práctica para determinar si tu organización cuenta o no con esas capacidades.
Decisión 1: ¿Cuándo se considera que un reconocimiento con señal débil constituye un incidente?
El primer día de la intrusión, los agentes realizaron un recuento de los sistemas de archivos, los procesos, las interfaces de red, las variables de entorno, los puntos de montaje y las herramientas disponibles. Probaron los canales de salida y establecieron un sistema de mando y control utilizando servicios públicos comunes. Por sí solo, cada uno de estos hechos podría justificarse como una tarea de depuración, automatización, una carga de trabajo mal configurada o una experimentación habitual.
Hugging Face afirma que las primeras señales aparecieron en el análisis en tiempo real, los registros SIEM y otros controles. Su sistema de seguridad basado en IA correlacionó esas señales en un patrón de ataque coherente, pero no les asignó la criticidad suficiente ni alertó al equipo de guardia. Ese retraso supuso una pérdida de un tiempo de respuesta muy valioso. Análisis previos y debates en la comunidad llegaron a la misma conclusión: se había estado registrando un reconocimiento durante varios días, pero la escalación solo se produjo cuando el volumen posterior de actividad no autorizada superó finalmente el umbral de alarma.
La decisión no consiste simplemente en determinar si un evento concreto es malicioso, sino en determinar si una secuencia de comportamientos en tiempo de ejecución, ambiguos por sí mismos, constituye la construcción de una ruta de ataque.
Las organizaciones deberían preguntarse si pueden establecer una correlación entre la ejecución de procesos, el acceso al sistema de archivos, la actividad de las API, la identidad de la carga de trabajo y el comportamiento de la red en contenedores de corta duración. ¿Son capaces de reconocer que un pod que lee /proc/self/environ, inspecciona los tokens de las cuentas de servicio y prueba múltiples métodos de salida difiere sustancialmente de un fallo normal de una aplicación?
Aquí es donde la instrumentación «canary » puede eliminar la ambigüedad. La técnica en la que debemos invertir aquí consiste en colocar tokens falsos en entornos de carga de trabajo seleccionados, dejar credenciales señuelo en almacenes de secretos y supervisar los valores de configuración en rutas que no sean de producción. Estos nunca deben proporcionar acceso real. En cambio, su único propósito es generar una señal de alta confianza cuando se lean, se copien o se presenten. Un token canario bien colocado debería alertar a un responsable en lugar de ser descartado como una anomalía. Desarrollar una capacidad de engaño debería formar parte de la hoja de ruta de todos los equipos.
Decisión 2: ¿Qué ocurre cuando se roban y se utilizan unas credenciales?
El tercer día cambió el carácter del incidente. El agente leyó los tokens de las cuentas de servicio de Kubernetes, consultó los metadatos de la nube, reprodujo credenciales temporales de proveedores de alojamiento externos (Modal dio un paso al frente para declararse uno de esos proveedores de alojamiento), creó pods con privilegios y se escapó a la raíz del nodo. A continuación, accedió a un objeto secreto que contenía 136 claves, incluidas las credenciales utilizadas para una VPN en malla y un intermediario de acceso al clúster interno. Una credencial compartida del conector proporcionó, de hecho, acceso de administrador del clúster en múltiples clústeres.
Este es el momento en el que la «investigación» debe convertirse en una contención activa.
¿Es capaz tu equipo de identificar todos los sistemas que confían en una credencial comprometida? El gráfico de dependencias y el análisis de impacto son fundamentales para iniciar la fase de contención de la respuesta ante incidentes. ¿Pueden tus herramientas y paneles de control distinguir entre un token utilizado por su carga de trabajo prevista y el mismo token que aparece procedente de un nuevo proveedor de nube, un entorno de pruebas o un origen de red? ¿Pueden los responsables de la respuesta revocar toda una familia de credenciales, en lugar de rotar una sola clave mientras los tokens derivados siguen siendo válidos?
La detección en tiempo de ejecución es esencial porque la credencial en sí misma puede parecer legítima. La condición maliciosa se encuentra en su contexto de ejecución: el proceso incorrecto, el pod incorrecto, la red de origen incorrecta, la identidad de la carga de trabajo incorrecta o una secuencia de acciones imposible. Me gusta llamar a esto la supervisión del tipo «el agua está mojada». De todas las cosas que sé que son ciertas, el agua está mojada, igual que el cielo es azul. Si no implementamos una supervisión que nos ayude a detectar cambios en nuestros entornos que «rompan nuestras suposiciones», seguiremos llevándonos sorpresas.
Un ejemplo de ello sería configurar pruebas de enrutamiento de siguiente salto para detectar un secuestro de BGP. Los cuatro primeros saltos desde tu red interna hacia un recurso externo estable y conocido (como time.windows.com) no deberían desviarse en absoluto. Otro ejemplo de supervisión del tipo «el agua moja» es el de los registros DNS, evaluando constantemente si tus direcciones IP internas y externas para los componentes clave de la infraestructura permanecen inalteradas.
Por lo tanto, los «canarios» desplegados para detectar ataques dirigidos por agentes deben incluir tokens falsos de cuentas de servicio, credenciales de nube señuelo y claves de registro de VPN sintéticas. Un token almacenado en un entorno de pod cuidadosamente seleccionado puede revelar la recopilación de credenciales. Una cuenta de servicio señuelo puede revelar la enumeración de espacios de nombres. Una entrada de clúster falsa devuelta por un catálogo de servicios interno puede revelar intentos de movimiento lateral. Estos artefactos deben conducir a sumideros o a puntos finales denegados, no a acceso a producción, pero cada interacción debe conservar la identidad de origen y activar inmediatamente las directrices de contención.
Decisión 3: ¿Eres capaz de detectar C2 cuando parece tu propia aplicación?
Quizá la lección más importante en materia de detección sea que el tráfico de comando y control no tiene por qué parecerse necesariamente al tráfico tradicional de malware.
El agente utilizó servicios públicos de captura de solicitudes, pastebins y servidores para compartir archivos. Y lo que es más importante, utilizó conjuntos de datos de Hugging Face controlados por los atacantes como puntos de entrega secretos. Los comandos y los datos robados se colocaban en commits de conjuntos de datos y en ramas secundarias, para luego recuperarse a través de la API habitual de Hugging Face. También se utilizó un proxy CORS abierto de Space como relé de salida. Las cargas útiles se dividían en fragmentos, se comprimían, se codificaban y, en ocasiones, se enviaban a través de sockets sin procesar. Al reproducir el proceso de decodificación del atacante, se recuperaron aproximadamente cuatro veces más secretos expuestos que en el análisis inicial.
En otras palabras, las instrucciones entrantes parecían actividad relacionada con conjuntos de datos y la exfiltración saliente también parecía actividad relacionada con conjuntos de datos. La propia plataforma Hugging Face pasó a formar parte del transporte C2. Un sistema SIEM convencional puede notificar miles de eventos inusuales sin revelar que estos forman parte de un protocolo bidireccional.
El punto clave es decidir si se debe desactivar una función destinada a los clientes, aislar un inquilino, bloquear un servicio público o interrumpir una ruta de datos de producción. Los responsables de la respuesta necesitan pruebas más sólidas que un simple «este tráfico es inusual».
Crea conjuntos de datos señuelo con nombres convincentes, como resultados de pruebas comparativas internas, respuestas de evaluación o investigaciones de seguridad archivadas. Incorpora en ellos marcadores únicos y credenciales falsas. Ninguna carga de trabajo legítima debería acceder a ellos. Supervisa las lecturas, las copias, las confirmaciones, la creación de ramas y las solicitudes de API. Un clúster interno falso o un conjunto de datos que figure en un catálogo también puede revelar si un atacante está explorando posibilidades en lugar de limitarse a interactuar con el servicio de forma normal.
Los «canarios» bien diseñados y bien situados aportan información sobre la intención, no solo sobre anomalías.
Decisión 4: ¿Reparar los daños o reconstruir el entorno?
Al final, la cuestión es si la organización sigue confiando en la infraestructura afectada.
Hugging Face renovó las credenciales de forma generalizada, bloqueó el acceso a los metadatos en la nube, redujo el alcance de las credenciales y borró y reconstruyó la infraestructura básica desde cero. En términos generales, la decisión supuso «borrar de un plumazo» aproximadamente un tercio del entorno, en lugar de intentar demostrar que se habían eliminado todos los puntos de acceso, tokens falsificados y mecanismos de persistencia.
Esa opción solo existe cuando la infraestructura es reproducible y desechable. En análisis anteriores se señaló que la recuperación de Hugging Face se aceleró gracias al despliegue de infraestructura nueva a partir de repositorios, en lugar de restaurar y limpiar posteriormente los sistemas afectados. La competencia para tomar esa decisión también debe asignarse y documentarse claramente antes de que se produzca el incidente.
El paquete de apoyo a la toma de decisiones debe incluir el historial de credenciales, las identidades de las cargas de trabajo afectadas, la verificación de imágenes inmutables, la cobertura de la infraestructura como código, los requisitos de restauración de datos y las pruebas de intentos de persistencia. Los directivos deben conocer la duración estimada de la interrupción del servicio necesaria para la reconstrucción antes de que se les pida que la autoricen. Y con qué nivel de confianza (¿cuándo fue la última vez que se implementó de nuevo un clúster o servicio concreto?).
Los «canarios» también siguen siendo útiles tras la recuperación. Sustituye cada señuelo por un valor recién generado. Cualquier uso de un token de «canario» antiguo tras la reconstrucción constituye una prueba sólida de que ha sobrevivido un punto de acceso no detectado, un secreto copiado o una ubicación de preparación externa. Esto es especialmente cierto si partimos de la base de que los atacantes con intencionalidad son lo suficientemente previsores como para dejar rastros a sus agentes modelo, con el fin de que estos eviten la detección o retomen la tarea donde la dejaron.
El incidente de Hugging Face demuestra que el registro de eventos no es lo mismo que la detección, que la detección no es lo mismo que la escalación y que la escalación no es lo mismo que el apoyo a la toma de decisiones. La visibilidad en tiempo de ejecución te permite saber qué está haciendo realmente el software. Los tokens «canary», los clústeres y los conjuntos de datos te indican cuándo una actividad carece de una explicación legítima.
El objetivo no es simplemente recopilar pruebas suficientes para comprender la infracción la semana que viene. Se trata de crear señales lo suficientemente claras como para tomar la decisión correcta hoy mismo.
