Toma de control de una organización de GitHub: indicios
Indicios de toma de control de una organización de GitHub en el audit log: nuevos propietarios, 2FA desactivado, SSO SAML modificado, lista de IP y streaming.
En resumen. Una toma de control se ve en el registro de auditoría como una secuencia corta de cambios de control: un nuevo propietario (org.update_member / org.add_member con permission: admin, business.add_admin), después defensas rebajadas (org.disable_two_factor_requirement, org.disable_saml u org.update_saml_provider_settings, ip_allow_list.disable, org.disable_oauth_app_restrictions, política personal_access_token.* relajada) y, a veces, la eliminación del flujo hacia tu SIEM (audit_log_streaming.destroy). Cualquiera de ellos, hecho por un actor o desde una IP inesperados, es un hallazgo de alta prioridad. Dos sobre el mismo actor ya son un incidente.
Los propietarios de una organización pueden modificar todos los repositorios, secretos, miembros y ajustes de seguridad. Un atacante que se convierte en propietario, o que controla la sesión o el token de un propietario, no necesita ser discreto. Le basta con ser más rápido que tu revisión del registro de auditoría. Esta guía enumera los cambios de control que debes buscar y el orden en que conviene deshacerlos.
Los indicios de toma de control
| Indicio | Acciones de auditoría | Regla del analizador | Gravedad |
|---|---|---|---|
| Propietario añadido | org.update_member u org.add_member con permission: admin, business.add_admin | owner-granted | alta |
| Admin de un repositorio concedido a un colaborador | org.add_outside_collaborator, repo.add_member, repo.update_member con permiso admin | collaborator-admin | media |
| Requisito de 2FA desactivado | org.disable_two_factor_requirement, business.disable_two_factor_requirement | two-factor-disabled | alta |
| SSO SAML desactivado o redirigido | org.disable_saml, org.update_saml_provider_settings (y sus equivalentes business.) | sso-changed | alta |
| Lista de IP permitidas desactivada | ip_allow_list.disable, ip_allow_list.disable_for_installed_apps, ip_allow_list.disable_user_level_enforcement | ip-allowlist-disabled | alta |
| Restricciones de aplicaciones de terceros desactivadas | org.disable_oauth_app_restrictions | oauth-restrictions-disabled | media |
| Política de tokens debilitada | personal_access_token.access_restriction_disabled, .expiration_limit_unset, .auto_approve_grant_requests_enabled | pat-policy-weakened | media |
| Flujo de auditoría eliminado | audit_log_streaming.destroy, audit_log_streaming.update | audit-stream-changed | alta |
Las correspondencias ATT&CK que usan las reglas son T1098.003 Additional Cloud Roles para los ascensos a propietario, T1556 Modify Authentication Process para 2FA y SSO, T1562.007 Disable or Modify Cloud Firewall para la lista de IP permitidas y T1562.008 Disable or Modify Cloud Logs para el streaming.
Según la política de veredicto, dos reglas distintas de gravedad alta sobre el mismo actor, token o IP hacen que el veredicto sea Comprometida, incluso sin ningún hallazgo crítico. Encaja con las tomas de control: un owner-granted seguido de un two-factor-disabled desde la misma cuenta rara vez es un administrador poniendo orden.
Cómo leer cada cambio
Nuevos propietarios
org.update_member registra los cambios de rol. El campo permission (y el campo user de la cuenta afectada) te dice a quién se ascendió. Comprueba tres cosas. ¿El actor era un propietario existente que usaba su IP y su user agent habituales? ¿La cuenta ascendida es nueva en la organización (busca un org.add_member poco antes)? ¿El nuevo propietario actuó poco después? Una cuenta ascendida que se pone de inmediato a crear tokens, claves o runners es el patrón clásico.
Autenticación de doble factor
Cuando una organización exige 2FA, los miembros y colaboradores externos que no lo tienen se eliminan. Desactivar el requisito permite que cuentas débiles entren o se queden, y suele ser el paso previo a invitar a una cuenta controlada por el atacante. Volver a activarlo después elimina cualquier cuenta que siga sin 2FA: es una contención útil, pero también disruptiva, así que planifícala.
Inicio de sesión único SAML
Con SSO SAML (GitHub Enterprise Cloud), tu proveedor de identidad decide quién puede acceder a los recursos de la organización, y los tokens deben estar autorizados para SSO. org.update_saml_provider_settings cambia el issuer, la URL de SSO o el certificado. Un atacante que los apunta a un proveedor de identidad que controla puede iniciar sesión después como quien quiera. Compara los nuevos valores con los metadatos de tu IdP. Si tu IdP está implicado, sus propios logs son la siguiente parada: las herramientas hermanas cubren Okta, Microsoft Entra ID y Google Workspace.
Lista de IP permitidas
Una lista de IP permitidas (Enterprise Cloud) bloquea el acceso web, API y Git desde fuera de tus rangos, incluido el acceso con tokens de acceso personal y claves SSH. Por eso las credenciales robadas fallan mientras está activa. Vigila ip_allow_list.disable y también ip_allow_list_entry.create: añadir el VPS del atacante a la lista es más discreto que desactivarla, y el analizador lo muestra en la cronología pero no genera un hallazgo por ello.
Aplicaciones OAuth y política de tokens de acceso personal
Las restricciones de acceso de aplicaciones OAuth impiden que las aplicaciones OAuth autorizadas por los miembros lean datos de la organización hasta que un propietario las aprueba. Desactivarlas abre la puerta al consent phishing. La política de tokens de acceso personal puede bloquear los tokens clásicos, limitar la vida de los tokens y exigir aprobación para los tokens fine-grained. Relajarla justo antes de que se cree y se use un token es una secuencia que merece la pena reconstruir.
Streaming del registro de auditoría
Eliminar o redirigir el flujo (audit_log_streaming.destroy / .update) deja ciego al SIEM, mientras el registro de auditoría del propio producto sigue registrando. Es además uno de los pocos cambios que solo tienen sentido para alguien que espera ser investigado. Consulta streaming del registro de auditoría.
Orden de remediación
- Conserva la exportación del registro de auditoría antes de revertir nada. Revertir genera eventos nuevos y hace la cronología más difícil de leer.
- Elimina los propietarios y admins inesperados y, después, revoca sus sesiones, tokens, claves SSH y autorizaciones SSO.
- Restaura los controles de autenticación: requisito de 2FA, ajustes SAML (verificados contra el IdP), lista de IP permitidas, restricciones de aplicaciones OAuth y política de tokens.
- Restaura el flujo de auditoría y determina qué se perdió mientras estuvo desactivado. El almacenamiento en búfer depende del destino y de cuánto tiempo estuvo en pausa.
- Busca la persistencia que pudo crear el nuevo propietario: claves de despliegue, aplicaciones, webhooks, runners, colaboradores externos y equipos con acceso amplio. La guía sobre tokens filtrados tiene la lista.
- Revisa también los controles a nivel de repositorio. Los propietarios pueden eliminar la protección de ramas y los rulesets en cualquier parte. Consulta manipulación de la protección de ramas.
Relacionado
- ¿Organización de GitHub comprometida? Guía de respuesta a incidentes
- Token de GitHub filtrado: qué hacer y cómo investigarlo
- Prueba estas reglas con tu exportación en el analizador en el navegador