Prise de contrôle d'organisation GitHub : 2FA, SSO, IP

En bref. Une prise de contrôle apparaît dans le journal d'audit sous la forme d'une courte séquence de modifications des contrôles : un nouveau propriétaire (org.update_member / org.add_member avec permission: admin, business.add_admin), puis des défenses abaissées (org.disable_two_factor_requirement, org.disable_saml ou org.update_saml_provider_settings, ip_allow_list.disable, org.disable_oauth_app_restrictions, politique personal_access_token.* assouplie), et parfois la suppression du flux vers votre SIEM (audit_log_streaming.destroy). Chacune de ces modifications, venant d'un acteur ou d'une adresse IP inattendus, est un constat hautement prioritaire. Deux sur le même acteur, c'est un incident.

Les propriétaires d'une organisation peuvent modifier chaque dépôt, secret, membre et paramètre de sécurité. Un attaquant qui devient propriétaire, ou qui contrôle la session ou le jeton d'un propriétaire, n'a pas besoin d'être discret. Il lui suffit d'aller plus vite que votre revue du journal d'audit. Ce playbook recense les modifications de contrôles à rechercher et l'ordre dans lequel les annuler.

Les indicateurs de prise de contrôle

Indicateur	Actions d'audit	Règle de l'analyseur	Gravité
Propriétaire ajouté	`org.update_member` ou `org.add_member` avec `permission: admin`, `business.add_admin`	`owner-granted`	élevée
Droits admin sur un dépôt pour un collaborateur	`org.add_outside_collaborator`, `repo.add_member`, `repo.update_member` avec la permission admin	`collaborator-admin`	moyenne
Exigence de 2FA désactivée	`org.disable_two_factor_requirement`, `business.disable_two_factor_requirement`	`two-factor-disabled`	élevée
SSO SAML désactivé ou redirigé	`org.disable_saml`, `org.update_saml_provider_settings` (et leurs équivalents `business.`)	`sso-changed`	élevée
Liste d'IP autorisées désactivée	`ip_allow_list.disable`, `ip_allow_list.disable_for_installed_apps`, `ip_allow_list.disable_user_level_enforcement`	`ip-allowlist-disabled`	élevée
Restrictions des applications tierces désactivées	`org.disable_oauth_app_restrictions`	`oauth-restrictions-disabled`	moyenne
Politique des jetons affaiblie	`personal_access_token.access_restriction_disabled`, `.expiration_limit_unset`, `.auto_approve_grant_requests_enabled`	`pat-policy-weakened`	moyenne
Flux d'audit supprimé	`audit_log_streaming.destroy`, `audit_log_streaming.update`	`audit-stream-changed`	élevée

Les correspondances ATT&CK utilisées par les règles sont T1098.003 Additional Cloud Roles pour l'attribution du rôle de propriétaire, T1556 Modify Authentication Process pour la 2FA et le SSO, T1562.007 Disable or Modify Cloud Firewall pour la liste d'IP autorisées, et T1562.008 Disable or Modify Cloud Logs pour le streaming.

Selon la politique de verdict, deux règles distinctes de gravité élevée sur le même acteur, jeton ou adresse IP donnent le verdict Compromis, même sans constat critique. C'est adapté aux prises de contrôle : un owner-granted suivi d'un two-factor-disabled depuis le même compte relève rarement d'un administrateur qui fait du ménage.

Analyser chaque modification

Nouveaux propriétaires

org.update_member enregistre les changements de rôle. Le champ permission (et le champ user pour le compte concerné) vous indique qui a été promu. Vérifiez trois points. L'acteur était-il un propriétaire existant, avec son adresse IP et son user agent habituels ? Le compte promu est-il nouveau dans l'organisation (cherchez un org.add_member peu de temps avant) ? Le nouveau propriétaire a-t-il agi rapidement ensuite ? Un compte promu qui crée immédiatement des jetons, des clés ou des runners, c'est le schéma classique.

Authentification à deux facteurs

Lorsqu'une organisation exige la 2FA, les membres et collaborateurs externes qui ne l'ont pas activée sont retirés. Désactiver cette exigence permet à des comptes faibles de rejoindre l'organisation ou d'y rester, et c'est souvent l'étape qui précède l'invitation d'un compte contrôlé par l'attaquant. La réactiver ensuite retire tout compte toujours dépourvu de 2FA : c'est un confinement utile mais aussi perturbant, alors planifiez-le.

Authentification unique SAML

Avec le SSO SAML (GitHub Enterprise Cloud), votre fournisseur d'identité décide qui peut accéder aux ressources de l'organisation, et les jetons doivent être autorisés pour le SSO. org.update_saml_provider_settings modifie l'émetteur, l'URL de SSO ou le certificat. Un attaquant qui les fait pointer vers un fournisseur d'identité qu'il contrôle peut ensuite se connecter sous l'identité de son choix. Comparez les nouvelles valeurs avec les métadonnées de votre IdP. Si votre IdP est impliqué, ses propres logs sont l'étape suivante : les outils voisins couvrent Okta, Microsoft Entra ID et Google Workspace.

Liste d'IP autorisées

Une liste d'IP autorisées (Enterprise Cloud) bloque les accès web, API et Git depuis l'extérieur de vos plages, y compris les accès avec des jetons d'accès personnels et des clés SSH. C'est pour cela que des identifiants volés échouent quand elle est active. Surveillez ip_allow_list.disable mais aussi ip_allow_list_entry.create : ajouter le VPS de l'attaquant à la liste est plus discret que de la désactiver, et l'analyseur fait apparaître cet événement dans la chronologie sans lever de constat.

Applications OAuth et politique des jetons d'accès personnels

Les restrictions d'accès des applications OAuth empêchent les applications OAuth autorisées par les membres de lire les données de l'organisation tant qu'un propriétaire ne les a pas approuvées. Les désactiver ouvre la porte au phishing par consentement. La politique des jetons d'accès personnels peut bloquer les jetons classiques, plafonner leur durée de vie et exiger une approbation pour les jetons à granularité fine. Un assouplissement juste avant la création et l'utilisation d'un jeton est une séquence qui mérite d'être reconstituée.

Streaming du journal d'audit

Supprimer ou rediriger le flux (audit_log_streaming.destroy / .update) aveugle le SIEM, tandis que le journal d'audit dans le produit continue d'enregistrer. C'est aussi l'une des rares modifications qui n'ont de sens que pour quelqu'un qui s'attend à faire l'objet d'une enquête. Voir streaming du journal d'audit.

Ordre de remédiation

Préservez l'export du journal d'audit avant d'annuler quoi que ce soit. Chaque retour arrière crée de nouveaux événements et rend la chronologie plus difficile à lire.
Retirez les propriétaires et administrateurs inattendus, puis révoquez leurs sessions, jetons, clés SSH et autorisations SSO.
Rétablissez les contrôles d'authentification : exigence de 2FA, paramètres SAML (vérifiez-les par rapport à l'IdP), liste d'IP autorisées, restrictions des applications OAuth, politique des jetons.
Rétablissez le flux d'audit et déterminez ce qui a été perdu pendant son interruption. La mise en mémoire tampon dépend de la destination et de la durée de la pause.
Recherchez la persistance que le nouveau propriétaire a pu mettre en place : clés de déploiement, applications, webhooks, runners, collaborateurs externes et équipes aux accès étendus. Le playbook sur les jetons fuités en donne la liste.
Vérifiez aussi les contrôles au niveau des dépôts. Les propriétaires peuvent supprimer la protection de branche et les rulesets partout. Voir altération de la protection de branche.