Dentro del ataque de cadena de suministro Megalodon en GitHub

Según los análisis, la campaña se desarrolló entre aproximadamente 11:36 y 17:48 UTC, lo que apunta a un sistema altamente automatizado capaz de comprometer miles de repositorios antes de que los mantenedores detectaran los cambios.

Cómo lograron inyectar miles de commits en pocas horas

La campaña combinó automatización con técnicas de camuflaje social para que los commits maliciosos parecieran mantenimiento normal de infraestructura CI.

Bots falsos y cuentas desechables

Los atacantes crearon cuentas temporales de GitHub con nombres aleatorios y se hicieron pasar por sistemas de automatización usando identidades como:

• build-bot
• auto-ci
• ci-bot
• pipeline-bot

Esto hacía que los commits parecieran generados por herramientas automáticas en lugar de por un atacante humano.

Metadatos de commit falsificados

Los datos de autoría y los mensajes de commit se diseñaron para parecer legítimos, a menudo simulando actualizaciones de CI o pequeños cambios de configuración. Esa apariencia ayudó a que los cambios pasaran desapercibidos en el historial del repositorio.

Repositorios con protección de ramas débil

El ataque se centró en proyectos donde las reglas de protección de ramas eran débiles o inexistentes. Sin revisiones obligatorias de pull request o restricciones sobre quién puede modificar workflows, los atacantes pudieron insertar cambios directamente en la rama principal.

Workflows de GitHub Actions envenenados

Cada commit añadía un workflow de GitHub Actions que contenía un payload Bash codificado en Base64. Cuando el pipeline de CI se ejecutaba, el script se activaba dentro del runner de GitHub Actions y comenzaba a recopilar credenciales del entorno.

Esto significa que el ataque a menudo permanecía inactivo hasta que el siguiente pipeline del proyecto ejecutaba el workflow.

Qué datos intentaba robar el malware

El script codificado en Base64 estaba diseñado para recolectar información sensible del entorno de CI y enviarla a infraestructura controlada por los atacantes.

Entre los objetivos reportados estaban:

• Variables de entorno del pipeline CI/CD
• Credenciales de proveedores cloud (AWS, Google Cloud y Azure)
• Claves privadas SSH
• Tokens de API y secretos de aplicaciones
• Tokens OIDC de GitHub Actions
• Otros secretos de configuración disponibles en el runner

El malware recopilaba variables de entorno, información del sistema y credenciales accesibles para el runner antes de exfiltrar esos datos a un servidor de comando y control.

Dado que muchos pipelines contienen credenciales de despliegue, comprometer un entorno de build puede abrir acceso a infraestructura cloud, registros de paquetes o incluso sistemas de producción.

Por qué el robo de tokens OIDC es especialmente peligroso

Uno de los objetivos principales del payload de Megalodon eran los tokens OIDC de GitHub Actions.

En muchos pipelines modernos de CI/CD se usa OpenID Connect (OIDC) para autenticarse en servicios cloud sin guardar credenciales permanentes. En este modelo, el workflow solicita un token de identidad temporal que el proveedor cloud intercambia por credenciales de acceso de corta duración.

Este enfoque mejora la seguridad porque evita almacenar claves API permanentes. Sin embargo, introduce un riesgo diferente: si un atacante roba ese token durante la ejecución del pipeline, puede suplantar temporalmente la identidad del workflow.

Como los sistemas de identidad en la nube confían en estos tokens, uno robado puede convertirse en acceso temporal a recursos cloud con los mismos permisos del pipeline de despliegue.

Eso podría permitir, por ejemplo:

• acceso a infraestructura en la nube
• manipulación del pipeline de despliegue
• extracción de secretos almacenados en servicios cloud

Aunque los tokens OIDC expiran rápidamente, incluso un acceso breve puede ser suficiente para que un atacante robe datos o escale privilegios.

¿Está relacionado con la brecha de GitHub por una extensión de VS Code?

Casi al mismo tiempo, GitHub reveló otro incidente de seguridad independiente: una extensión maliciosa de Visual Studio Code instalada en el dispositivo de un empleado permitió a atacantes acceder a aproximadamente 3.800 repositorios internos de GitHub antes de que la intrusión fuera contenida.

Ese incidente se originó en un entorno de desarrollo comprometido y utilizó una extensión troyanizada distribuida a través del marketplace de VS Code para robar credenciales.

Algunos informes señalan similitudes en el momento y en las tácticas con otros ataques a herramientas de desarrollo. Sin embargo, no hay evidencia pública que confirme que esa brecha interna de GitHub haya habilitado directamente la campaña Megalodon.

Por ahora, lo más prudente es considerar ambos sucesos como dos incidentes distintos pero ocurridos en el mismo periodo dentro del ecosistema de desarrollo.

La lección para la seguridad de CI/CD

El caso Megalodon muestra cómo la automatización puede escalar un ataque de cadena de suministro a miles de repositorios en muy poco tiempo. Al combinar bots falsos, commits automatizados y workflows de CI manipulados, los atacantes transformaron la infraestructura de build en una herramienta de robo de credenciales.

El incidente refuerza varias prácticas clave para los equipos de desarrollo:

• aplicar reglas estrictas de protección de ramas
• exigir revisiones obligatorias para cambios en workflows
• limitar permisos de los jobs de CI
• monitorear cuentas de automatización y cambios en pipelines

A medida que los pipelines controlan despliegues en la nube e infraestructura crítica, la seguridad de los workflows de CI/CD se ha convertido en una pieza central de la defensa de la cadena de suministro del software.