Análisis del registro de auditoría de GitHub paso a paso
Analiza offline las exportaciones del audit log de GitHub: JSON, eventos Git y logs de Actions; lee el veredicto, prioriza hallazgos y exporta un informe.
En resumen. Exporta el registro de auditoría en JSON (y los eventos Git y los archivos de logs de Actions si los tienes) y suéltalo todo en la herramienta GitHub Forensics. El análisis se ejecuta en tu navegador, sin subir nada. Lee primero el veredicto y sus notas de cobertura, después prioriza los hallazgos por gravedad, pivota sobre el token o la IP sospechosos, revisa la cronología y recorre la lista de remediación. Calcula unos 30 minutos para una primera pasada sobre una organización típica.
Este es el recorrido práctico por el analizador de este sitio. Da por hecho que ya tienes los ficheros. Si no es así, empieza por cómo exportar el registro de auditoría de GitHub.
Paso 1: reúne las exportaciones
Lo mínimo es el registro de auditoría de la organización en JSON. Cada fuente adicional elimina un punto ciego:
| Si añades | Desbloqueas |
|---|---|
| Direcciones IP activadas antes de exportar | detecciones de IP nueva y país nuevo por token y por actor |
Eventos Git (include=all, exportación de la empresa o streaming) | detección de clonado masivo (ráfagas de git.clone) |
| Archivos de logs de Actions de las ejecuciones sospechosas | secretos codificados o enviados fuera por un paso de un workflow |
| Alertas de secret scanning (JSON de la API REST) | credenciales filtradas y el siguiente paso en el cloud |
Exporta también unas semanas anteriores a la supuesta intrusión. Las reglas de "país nuevo" e "IP nueva" comparan cada token con su propio historial, y necesitan al menos 24 horas de él.
Paso 2: suelta los ficheros
Suelta en la herramienta ficheros sueltos, carpetas completas o ZIP (anidados hasta tres niveles). El formato se detecta por el contenido, no por el nombre del fichero. La herramienta acepta las exportaciones JSON / CSV de la interfaz, las páginas de la API REST, los .json.log.gz del streaming, los export-*.json.gz de eventos Git, los ZIP de "Download log archive" de Actions y el JSON de las alertas de secret scanning.
Los ficheros se leen en bloques de 4 MB y el gzip se descomprime al vuelo, así que los volcados de streaming de varios gigabytes funcionan sin cargarlo todo en memoria. Cada fichero omitido aparece en una lista con el motivo ("formato no reconocido", "el archivo termina en mitad de un registro", "los registros no son eventos de auditoría"). Lee esa lista. Una exportación truncada es una causa habitual de un resultado sin hallazgos.
Para ver el resultado antes de usar tus propios datos, haz clic en Probar un ejemplo. Carga un incidente ficticio, claramente identificado como tal, que se analiza en el recorrido de northwind-labs.
Paso 3: lee el veredicto y las notas de cobertura
El banner muestra uno de estos tres veredictos. La política está publicada en el fichero de reglas y en la página de la herramienta:
- Comprometida: al menos un hallazgo crítico (por ejemplo, un paso de workflow que codifica secretos), o dos o más reglas distintas de gravedad alta sobre el mismo actor, token o IP.
- Actividad sospechosa: al menos un hallazgo de gravedad alta o media.
- Ningún indicio de compromiso: nada por encima de baja.
Bajo el banner, Por qué enumera los hallazgos que han determinado el veredicto, y Periodo cubierto muestra la primera y la última marca de tiempo. Comprueba que el periodo incluye la ventana que te interesa.
A continuación, lee las Notas de cobertura. Te dicen lo que el veredicto no ha podido ver: sin direcciones IP, sin eventos Git, sin metadatos de token (hashed_token), sin eventos de ejecución de workflows o con una tabla truncada. Un veredicto "Ningún indicio de compromiso" con la nota de que no hay eventos Git significa que no se ha comprobado el clonado masivo, no que no haya ocurrido.
Paso 4: prioriza los hallazgos
Los hallazgos se ordenan por gravedad. Cada uno muestra la regla, sus técnicas de ATT&CK, la primera y la última vez, el número de eventos (y el número de valores distintos en las reglas con umbral), las entidades implicadas y las filas de evidencia.
Prioriza respondiendo a una pregunta cada vez:
- ¿El actor es el esperado? Que un propietario cambie la protección de una rama en horario laboral es normal. El mismo cambio hecho con un token desde un VPS a las 3 de la madrugada no lo es.
- ¿La credencial es la habitual? Compara
hashed_token,programmatic_access_typeyuser_agentcon los demás eventos del actor. Uncurl/8.xdonde el desarrollador suele usargit/2.xes una señal fuerte. - ¿Encaja con otros hallazgos? Un
token-new-ipaislado suele ser un portátil en la wifi de un hotel. Si el mismo token dispara tambiéngit-clone-burst, es un incidente.
Algunas reglas son ruidosas por naturaleza. workflow-new-branch salta con la primera ejecución de cada rama de funcionalidad, y actions-secret-created salta con el trabajo rutinario de CI. Por eso tienen gravedad baja. Cobran importancia cuando implican a un actor que otros hallazgos ya han señalado.
Paso 5: pivota sobre las entidades
La pestaña Entidades lista actores, tokens (por hash), direcciones IP, repositorios, workflows, runners y aplicaciones. Haz clic en Ver eventos en cualquiera de ellos para filtrar la tabla de eventos.
El pivote más útil es el token. En cuanto decides que un hashed_token ha sido robado, todos los eventos que lo llevan son actividad del atacante mientras no se demuestre lo contrario, incluidos los que no han disparado ninguna regla. Después pivota sobre la IP del atacante para encontrar otras credenciales usadas desde el mismo sitio. La guía sobre tokens filtrados explica cómo asociar un hash a un token real.
La pestaña Eventos admite búsqueda de texto libre (acción, actor, IP, repositorio, cualquier campo), filtros por categoría, un interruptor Solo señalados y hora UTC o local. Haz clic en una fila para ver todos sus campos y qué reglas la citan.
Paso 6: lee la cronología, remedia, exporta
La Cronología con "Solo hallazgos" ofrece el relato del incidente en orden. Las filas agregadas (por ejemplo, 38 clonados) la mantienen legible. Desactiva el filtro para ver los eventos de contexto que los rodean: cambios de miembros, actualizaciones de SAML, registros de runners.
La pestaña Remediación es una lista de comprobación ordenada por urgencia y derivada de las reglas que se han activado. Siempre empieza por conservar las evidencias y después cubre la revocación de tokens, la rotación de los secretos de Actions y de las claves cloud, la eliminación de la persistencia y la restauración de las protecciones. Las marcas solo se guardan en la página.
Por último, exporta:
- Eventos CSV: los eventos que coinciden con tus filtros actuales (así que filtra primero, o quita los filtros para exportar todo lo listado). Las celdas que empiezan por
=,+,-o@se escapan para evitar la inyección de fórmulas. - Hallazgos CSV: una línea por hallazgo.
- Informe JSON: el resultado completo, para tu expediente del caso o para otra herramienta.
Lo que la herramienta no hará por ti
Las reglas son heurísticas con umbrales fijos: 10 repositorios distintos clonados en aproximadamente una hora desde una misma IP, y una referencia de 24 horas para las IP y los países nuevos. Están ajustadas para una organización de tamaño medio, no para la tuya. El registro de auditoría tampoco contiene el contenido de los ficheros, así que un workflow modificado se deduce de sus ejecuciones, no del diff. Lee las limitaciones del registro de auditoría de GitHub antes de escribir "ningún indicio de compromiso" en un informe.