La semana pasada, GitHub lanzó la revocación de credenciales de autoservicio para Enterprise. Esta función permite a los propietarios de la organización cortar las credenciales comprometidas en toda la organización en una sola acción, en lugar de intentar rastrear tokens individuales durante un incidente activo.
Esta solución se esperaba desde hace tiempo, ya que los últimos meses han demostrado lo que ocurre cuando la revocación es lenta o incompleta. El compromiso de Trivy en marzo regresó para una segunda ronda porque la primera limpieza dejó al menos una credencial activa, y esa cascada llegó a Checkmarx días después. En junio, los propios repositorios durabletask de Microsoft fueron afectados a través de una cuenta que nunca se limpió completamente después de un ataque anterior.
Microsoft ha estado a tope últimamente con las correcciones de seguridad. Nos dieron tiempos de espera de publicación después de cambios en la cuenta solo unos días antes de esto, y a principios de junio también actualizaron npm para detener los scripts de postinstalación automáticos. Estaremos atentos a qué más lanzan y cómo esto impacta en los ataques al software de código abierto.
Lo que lanzó GitHub
Los propietarios de Enterprise con el permiso "Manage enterprise credentials" (Gestionar credenciales de empresa) ahora pueden revocar o eliminar credenciales de forma masiva para todos los usuarios de la organización, o dirigirse a una cuenta específica. Esto cubre las autorizaciones SSO para Personal Access Tokens (PATs), claves SSH y tokens OAuth. Una opción de eliminación total está disponible para las organizaciones de Enterprise Managed Users (EMU), y las API REST a nivel de organización gestionan una revocación más granular por organización. Cada acción crea una entrada en el registro de auditoría y envía notificaciones por correo electrónico a los usuarios afectados.
Los miembros individuales tienen una nueva vista en Ajustes > Credenciales que muestra cada credencial vinculada a su cuenta, autorizada por SSO y personal. Desde allí, una única acción elimina el acceso de todas esas credenciales a los recursos empresariales protegidos por SSO en un solo paso, eliminando el proceso que consume mucho tiempo de revisar una lista de tokens entrada por entrada. Los miembros de las organizaciones EMU también tienen una opción separada para eliminar permanentemente todos sus tokens y claves SSH.
Antes de esta función de emergencia, había que trabajar con varias herramientas diferentes para cortar las credenciales de una cuenta. Los PATs de grano fino podían revocarse desde la pantalla de tokens de la organización. Los tokens clásicos solo podían cortarse mediante la revocación de autorización SSO por token, y solo si se tenía activado SAML SSO. La API de revocación de credenciales podía eliminar un token, pero solo si ya se tenía la cadena del token a mano, lo que funciona en el caso de secretos filtrados, no en el de cuentas comprometidas (esto apenas roza la superficie de las complejidades, pero nos detendremos aquí). La cuestión es que esto generaba un intento bastante desordenado de coordinar los cambios de credenciales.
Nota: Los tokens de GitHub Actions están fuera de este alcance, porque se generan por trabajo y expiran cuando el trabajo finaliza, por lo que no hay nada que revocar. La forma de limitar los daños durante un incidente es deshabilitar Actions en el repositorio.
¿Por qué ahora?
Los recientes ataques de malware han afectado a Microsoft de cerca.
El 19 de mayo, los atacantes utilizaron credenciales previamente robadas para realizar un push tres versiones maliciosas de Microsoft tarea duradera paquete a PyPI, parte de la campaña del gusano Miasma. Microsoft retiró los paquetes en cuestión de horas. Sin embargo, el 5 de junio, la misma cuenta subió un commit malicioso al repositorio de GitHub `Azure/durabletask`, plantando el gusano de nuevo. GitHub respondió deshabilitando 73 repositorios en cuatro de las organizaciones de GitHub de Microsoft. Esto incluía las herramientas de Azure Functions que muchos equipos despliegan, rompiendo las pipelines de CI/CD más allá de Microsoft. Los investigadores enumeran algunas posibles explicaciones para la repetición, pero la principal es que las credenciales de mayo nunca se rotaron completamente. Una empresa de monitorización encontró más tarde las credenciales de GitHub de la cuenta en los registros de infostealers desde abril. Cualquiera que fuera el mecanismo exacto, la misma cuenta se utilizó en ambos compromisos.
Pero esto no es nuevo, y el problema ya ha aparecido varias veces este año. A finales de febrero de 2026, un bot de IA malicioso explotó un pull_request_target workflow de GitHub Actions mal configurado en el repositorio de Trivy, lo que permitió al atacante robar un PAT con acceso de escritura a más de 33 workflows en toda la organización de GitHub de Aqua Security. Aqua Security descubrió la brecha y rotó las credenciales. Pero, por desgracia, la rotación no fue completa y las credenciales no se revocaron todas simultáneamente.
El 19 de marzo, los atacantes utilizaron credenciales que sobrevivieron a la rotación incompleta para forzar el push de 75 de las 76 etiquetas de versión en aquasecurity/trivy-action a commits maliciosos. La carga útil se ejecutó antes del escaneo real de Trivy en cada pipeline, por lo que cada workflow parecía completarse normalmente. Las pipelines de CI/CD que ejecutaban Trivy estaban recolectando credenciales de sus propios runners, como claves SSH, credenciales de cloud, tokens de Kubernetes y PATs de GitHub.
Cuatro días después, las credenciales robadas de esas pipelines se utilizaron para envenenar las GitHub Actions de Checkmarx con una carga útil de robo idéntica. Checkmarx confirmó que la actividad del actor de amenazas persistió en su entorno hasta el 22 de abril, y sus datos exfiltrados se publicaron en la dark web el 25 de abril.
Toda esta cadena de Trivy a Checkmarx se remonta a una rotación incompleta. Si Aqua Security hubiera podido cortar instantáneamente todas las credenciales de la cuenta de servicio comprometida después de la brecha de febrero, el ataque se habría detenido allí.
¿Rotación atómica qué?
La rotación atómica significa intercambiar una credencial como una única operación de todo o nada, de modo que no hay ningún momento en el que las credenciales nuevas y antiguas funcionen simultáneamente. El objetivo es evitar cualquier tiempo de inactividad en el sistema. Esto es genial en teoría. En un sistema distribuido, simplemente no funciona así. Hay demasiada coordinación involucrada. A la escala de una organización como GitHub, la rotación atómica carece de sentido.
Así, la rotación real elige uno de dos caminos, ambos imperfectos. La rotación rutinaria mantiene ambas credenciales válidas durante un período para que nada se rompa, lo cual está bien cuando no hay problemas, pero deja la credencial antigua activa. La respuesta a incidentes hace lo contrario, cortando la credencial antigua instantáneamente y aceptando que las cosas se rompan hasta que se reemita.
Un botón de emergencia (break-glass) permite hacer lo único que es realmente atómico: eliminar todas las credenciales en el ámbito de una sola vez. Claro, eso rompe el CI/CD. Pero sacar a un atacante de tu infraestructura es mucho más importante y vale la pena unas pocas horas o días de builds rotas.
Hasta ahora, cortar todas las credenciales a la vez era difícil de ejecutar. Este nuevo corte de una sola acción es lo que lo hace ejecutable bajo presión, y aunque la rotación atómica completa sigue siendo bastante esquiva, esto nos acerca al mundo ideal.
Qué hacer
En tu organización de GitHub, confirma que el permiso "Manage enterprise credentials" esté asignado a alguien que pueda actuar de inmediato, y hazlo antes de que ocurra un incidente. Revisa Configuración > Credenciales ahora para entender qué está en el ámbito.
Además, mientras actualizas tu configuración de seguridad, fija tus GitHub Actions a SHAs de commit completos en lugar de etiquetas de versión. Las etiquetas pueden ser forzadas a apuntar a código completamente diferente, lo cual es la técnica principal detrás del compromiso de Trivy. Un SHA de commit fijado no se puede mover.
Aikido Security monitoriza tus aplicaciones en busca de paquetes comprometidos en tiempo real. Cuando algo en tu pipeline se ve comprometido, recibes una alerta antes de que se ejecute el recolector de credenciales. Esto funciona con Aikido Intel, que analiza las nuevas versiones de los paquetes tan pronto como están disponibles.
Gracias por todas las actualizaciones, Microsoft. Por favor, seguid así. 🙏
