Claves cloud filtradas en GitHub Actions: el salto a la nube
Claves de AWS, Google Cloud o Azure filtradas desde GitHub Actions o un repo: contén la clave, rastrea su uso en los logs de la nube y sustitúyela por OIDC.
En resumen. En cuanto una clave cloud sale de GitHub (impresa por un workflow, clonada con el historial de un repositorio, detectada por secret scanning), la investigación de GitHub se convierte en una investigación cloud. Desactiva la clave, pero antes anota su ID y la ventana temporal exacta. Busca en los logs de la propia nube cada llamada hecha con ella: CloudTrail en AWS, Cloud Audit Logs en Google Cloud, el Activity log y los logs de inicio de sesión de Entra ID en Azure. Sustituye las claves almacenadas por federación OIDC para que el próximo compromiso de un workflow solo entregue un token de vida corta y alcance limitado.
GitHub rara vez es el objetivo final del atacante. Los repositorios y los secretos de Actions guardan las credenciales de los sistemas que de verdad importan: cuentas cloud de producción, registros de artefactos y bases de datos. El analizador marca este traspaso como siguiente salto. Cuando la regla actions-secret-exfil detecta nombres de credenciales de AWS, Google Cloud o Azure en un script que codifica o envía secretos, o cuando una alerta de secret scanning afecta a una credencial cloud, el resultado enlaza con la herramienta cloud correspondiente.
Por dónde se filtran las claves cloud desde GitHub
| Origen | Evidencias en el lado de GitHub | Tratado en |
|---|---|---|
| Un workflow imprime o envía secretos | Archivo de logs de la ejecución: codificador o curl en el script del paso, cadena codificada larga en la salida | Fuga de secretos de Actions |
| Clave commiteada en un repositorio y después clonada | Ráfagas de git.clone, alerta de secret scanning, protección de push eludida | Exfiltración de repositorios |
| Protección de entorno eliminada | environment.remove_protection_rule antes de una ejecución que usó el entorno | Manipulación de la protección de ramas |
| Runner autoalojado comprometido | Host del runner con un rol de instancia o credenciales de CLI en caché | Seguridad de runners autoalojados |
Las alertas de secret scanning (secret_scanning_alert.create, secret_scanning_alert.public_leak) y las omisiones de la protección de push (secret_scanning_push_protection.bypass) las generan las reglas secret-leak-alert y push-protection-bypass. Suelta el JSON de alertas de secret scanning de la organización junto al registro de auditoría para incluirlas.
Primero: identifica la clave y la ventana
Antes de rotar, anota:
- El identificador de la clave. En AWS, el ID de la clave de acceso (
AKIA…para claves de usuario de larga duración,ASIA…para credenciales temporales). En Google Cloud, el email de la cuenta de servicio y el ID de clave del JSON. En Azure, el ID de aplicación (cliente) del service principal y el ID del secreto o del certificado. - El inicio de la exposición. La hora de la ejecución o el push maliciosos, del clonado o de la alerta. El hallazgo del analizador da la hora de la primera aparición en UTC.
- Dónde era válida. Qué cuenta, proyecto o suscripción, y qué permisos tenía.
Después, desactiva o elimina la clave. En AWS, desactivar una clave de acceso te permite reactivarla si se rompe producción. Cuando hayas confirmado que nada legítimo depende ya de ella, elimínala.
AWS: CloudTrail
Busca en CloudTrail el ID de la clave de acceso desde el inicio de la exposición. El historial de eventos y CloudTrail Lake permiten filtrar por la clave de acceso. Busca:
- Las comprobaciones de identidad que los atacantes suelen lanzar primero (
GetCallerIdentity), seguidas de enumeración (List*,Describe*,Get*en ráfagas). - Llamadas desde IP y user agents que no encajan con tu CI (los runners alojados por GitHub salen de los rangos publicados por GitHub; un
aws-clide portátil desde un VPS no es uno de ellos). - Persistencia:
CreateUser,CreateAccessKey,CreateLoginProfile,AttachUserPolicy, roles nuevos o cambios en políticas de confianza. - Acceso a datos:
GetObjectde S3 en volumen, lecturas de Secrets Manager o de SSM Parameter Store.
La herramienta hermana AWS Forensics analiza exportaciones de CloudTrail igual que este sitio analiza GitHub: en el navegador y sin subir nada.
Google Cloud: Cloud Audit Logs
Para una clave de cuenta de servicio filtrada, filtra los Cloud Audit Logs con la cuenta de servicio como principal y revisa los logs de Admin Activity y, si están activados, los de Data Access. Vigila las nuevas claves de cuentas de servicio, los bindings de políticas IAM y los accesos a Cloud Storage o Secret Manager. Continúa con GCP Forensics.
Azure: Activity log y Entra ID
Para el secreto de un service principal, revisa los logs de inicio de sesión de service principals de Entra ID para ese ID de aplicación y, después, el Activity log para ver qué cambió: asignaciones de roles, credenciales nuevas en aplicaciones y accesos a Key Vault. Continúa con Azure Forensics.
Sustituye las claves por federación OIDC
La mayoría de estos incidentes existen porque hay una clave de larga duración guardada en un secreto de GitHub. GitHub Actions puede solicitar un token OIDC de vida corta para cada trabajo, y AWS, Google Cloud y Azure pueden confiar en él directamente. Consulta la documentación de OpenID Connect de GitHub y la entrada del glosario sobre federación OIDC. La referencia de uso seguro de GitHub la recomienda para los despliegues en la nube.
Qué cambia para un atacante:
| Clave de acceso almacenada | Federación OIDC | |
|---|---|---|
| Vida útil | Hasta que alguien la rota | De minutos a una hora (sesión en el lado cloud) |
| Utilizable fuera del workflow | Sí, desde cualquier lugar | Solo hasta que caduca |
| Alcance | Todo lo que tenga el usuario de la clave | Un rol cuya política de confianza puede exigir un repositorio, una rama o un entorno concretos (claim sub) |
| Visible en los logs | ID de la clave | Sesión de rol vinculada a los claims de GitHub |
OIDC no lo arregla todo. Un workflow envenenado que se ejecuta en una rama permitida sigue obteniendo un token válido durante la ejecución. Pero la ventana se reduce de «hasta la rotación» a «mientras dura el trabajo», y condiciones de confianza como repo:ORG/REPO:environment:production bloquean los tokens solicitados desde ramas del atacante.
Lista de comprobación
- Anota el ID de la clave, la cuenta y la ventana de exposición. Después, desactiva la clave.
- Obtén los logs cloud de la ventana. Busca comprobaciones de identidad, enumeración, persistencia y acceso a datos.
- Rota todos los demás secretos que el mismo workflow podía leer (consulta el artículo sobre Actions).
- Elimina lo que el atacante creó en la nube: usuarios, claves, roles, funciones, instancias.
- Pasa los despliegues a OIDC con condiciones de confianza sobre el repositorio y el entorno.
Relacionado
- ¿Organización de GitHub comprometida? Guía de respuesta a incidentes
- El caso práctico ficticio de northwind-labs: un par de claves de AWS impreso en doble base64
- MITRE ATT&CK T1552.001 Credentials In Files