ARTEX et secrets GitHub : scan avant push, révocation, rotation

Le 5 novembre 2026, Microsoft Threat Intelligence a décrit des attaquants qui utilisent un framework d'IA agentique, ARTEX, pour chercher des secrets dans les dépôts GitHub publics puis s'en servir. Dans au moins un cas, un agent est passé de la recherche sur GitHub à l'exfiltration de données d'un Azure Key Vault en cinq minutes. Conséquence pratique : un secret poussé sur un dépôt public doit être traité comme compromis, et ce qui compte désormais, c'est de l'empêcher de partir (scan avant push) et de réduire le temps qui sépare la fuite de la révocation.

Ce qui s'est passé

Selon le billet de Microsoft Threat Intelligence publié le 5 novembre 2026 :

• Depuis août 2026, Microsoft observe des acteurs malveillants qui utilisent un framework offensif agentique pour envoyer de grands volumes de requêtes de recherche à GitHub. Ces requêtes combinent souvent le nom d'une organisation ciblée, des mots-clés de secrets, et un mot-clé lié à un service cloud ou à un fournisseur d'IA.
• À partir du 28 octobre 2026 au moins, Microsoft observe des connexions réussies de service principals (les identités qu'utilisent les applications pour s'authentifier dans Microsoft Entra ID) depuis une adresse IP associée à la campagne, sur plusieurs identifiants d'application et chez plusieurs clients. Dans certains cas, l'identifiant d'une application multi-tenant appartenant à un éditeur a été compromis à la source puis utilisé pour accéder à plusieurs tenants clients en aval.
• Les opérations visaient en priorité ce qui renvoie d'autres secrets : clés de comptes de stockage, paramètres d'App Service, chaînes de connexion, identifiants de clusters AKS (Azure Kubernetes Service), connexions IA et ML. Microsoft rapporte aussi des téléchargements de fichiers SharePoint et OneDrive et des accès à des éléments de boîtes mail.
• Les agents ont montré un intérêt marqué pour les identifiants donnant accès à des services d'IA : clés d'API de grands fournisseurs, applications OAuth ayant accès à Foundry Tools (anciennement Azure Cognitive Services).

Microsoft signale qu'une campagne impliquant les mêmes adresses IP a aussi été rapportée par l'éditeur Todyl.

Comment ça fonctionne, en principe

La recherche de secrets dans le code public n'a rien de nouveau. Microsoft le rappelle : sa limite historique était le temps humain nécessaire pour trouver les dépôts, lire leur contenu et exploiter ce qu'on y trouve. Un framework agentique enchaîne ces étapes sans opérateur au clavier : recherche, tri des résultats, essai de l'identifiant, cartographie de l'environnement, extraction.

Un détail du rapport illustre ce changement. Quand une requête vers l'API Azure Resource Manager échouait (erreur HTTP 400 à cause d'une version d'API inadaptée), l'agent relançait la même requête avec une version corrigée entre 28 et 80 secondes plus tard, et obtenait une réponse valide. Microsoft qualifie ce comportement de « dépannage adaptatif ».

Ce qu'il faut en retenir côté défense : le délai pendant lequel un secret fuité reste « sans danger parce que personne ne l'a encore trouvé » se réduit. Microsoft ne publie pas de délai médian entre la publication d'un secret et sa première utilisation ; le chiffre de cinq minutes décrit l'enchaînement observé dans un cas, entre la recherche sur GitHub et l'exfiltration. Notre lecture, qui reste une hypothèse : une procédure de révocation qui démarre au prochain point d'équipe arrive après l'attaquant.

Qui est concerné

• Toute équipe qui a déjà poussé un secret dans un dépôt public, même supprimé depuis. Microsoft est explicite : un identifiant exposé reste utilisable tant qu'il n'est pas révoqué ou renouvelé, et retirer la divulgation d'origine ne corrige rien, car des copies subsistent dans l'historique, les caches, les archives ou les journaux.
• Les applications OAuth et service principals authentifiés par secret client (une chaîne longue durée) plutôt que par identité managée ou fédération.
• Les éditeurs SaaS qui exposent une application multi-tenant : la compromission de leur identifiant ouvre des tenants clients en aval, cas que Microsoft a observé.
• Les équipes qui manipulent des clés d'API de fournisseurs IA dans des scripts, notebooks ou fichiers de configuration, cible explicitement privilégiée par les agents.
• Les MSP (prestataires de services managés), à qui Microsoft demande de revoir leurs accès partenaires et d'informer leurs clients touchés.

Le rapport décrit un environnement Azure et Entra ID. Le principe (secret public, utilisation rapide par un agent) s'applique à tout fournisseur cloud ; les contrôles cités ci-dessous sont à transposer.

Comment s'en protéger

1. Bloquer le secret avant qu'il ne parte

Le seul secret fuité sans conséquence est celui qui n'a jamais quitté le poste du développeur.

• Activez la push protection sur vos organisations GitHub (ou GitHub Advanced Security / Secret Protection pour Azure DevOps, comme l'indique Microsoft). Elle bloque les types de secrets reconnus au moment du push.
• Ajoutez un scan en hook pre-commit sur les postes, avec un outil open source de détection de secrets, pour couvrir les dépôts et formats que la push protection ne voit pas : dépôts personnels, autres forges, motifs propres à votre organisation.
• Doublez par un scan en CI sur chaque pull request, bloquant, pour attraper ce qui a contourné le hook local.
• Encadrez le contournement : la push protection permet de forcer un push. Exigez une justification et faites remonter chaque contournement à la sécurité.

Vérifier chez vous : poussez sur une branche de test un faux secret au format d'un fournisseur reconnu (un jeton factice de test, jamais un vrai). Le push doit être refusé. Puis regardez combien de contournements ont été enregistrés le mois dernier.

2. Surveiller au-delà de vos dépôts

Microsoft recommande d'activer la surveillance publique de GitHub, qui suit l'exposition de vos secrets dans des dépôts tiers : le fork personnel d'un ancien salarié, un gist, le dépôt d'un prestataire. C'est là que se trouvent souvent les fuites qu'aucun scan interne ne voit.

3. Mesurer et réduire votre délai de révocation

C'est l'indicateur à suivre. Il se décompose en trois temps : détection de la fuite, décision, révocation effective.

• Écrivez une procédure par type de secret : où on le révoque, qui a les droits, quels services tombent. Une clé d'API IA, un secret client Entra ID et un jeton d'accès personnel n'ont pas la même procédure.
• Supprimez l'étape de décision : la règle est « secret public = révocation immédiate », sans validation préalable sur le risque de casser la production. Microsoft le dit : une organisation qui trouve ses secrets exposés doit supposer que les secrets et les applications associées sont compromis.
• Révoquez tout ce qui est rattaché à l'application : Microsoft recommande de retirer tous les secrets clients, certificats et identifiants fédérés de l'application touchée, y compris ceux qu'un attaquant aurait pu ajouter, et de désactiver le service principal si nécessaire. Attention : les jetons déjà émis restent valides jusqu'à leur expiration.
• Renouvelez aussi ce que l'identifiant pouvait lire. Microsoft demande de renouveler tout ce qui est stocké dans un Key Vault accessible par l'application compromise, ainsi que les identifiants trouvés dans les documents consultés. C'est l'étape la plus souvent oubliée.

Vérifier chez vous : organisez un exercice. Prenez un secret de non-production, déclarez-le « fuité » à une heure non annoncée, et chronométrez jusqu'à sa révocation effective. Si le résultat se compte en heures, la priorité est l'automatisation du renouvellement.

4. Rendre la rotation banale

Un secret qu'on n'ose pas révoquer de peur de casser quelque chose est un secret dont la rotation n'a jamais été testée.

• Automatisez la rotation depuis votre coffre-fort de secrets, avec une durée de vie courte et un renouvellement régulier, pour que le geste soit déjà rodé le jour de l'incident.
• Supprimez les secrets longue durée là où c'est possible. Microsoft recommande de migrer les applications OAuth hors de l'authentification par secret, et d'utiliser des identités managées, qui suppriment la possibilité d'exposer le secret dans le code. Pour la CI, la fédération d'identité (OIDC, OpenID Connect) remplace les secrets stockés dans les pipelines.
• Appliquez le moindre privilège aux service principals : un identifiant fuité qui ne peut lire qu'un compte de stockage ne donne pas accès au Key Vault.

5. Détecter l'usage d'un identifiant volé

Microsoft fournit des signaux précis pour les environnements Entra ID :

• les erreurs de connexion AADSTS7000215 (secret invalide) ou AADSTS7000222 (secret expiré) indiquent que quelqu'un détient un identifiant de votre application ; un échec suivi d'un succès est à traiter en urgence ;
• une même adresse qui s'authentifie sur trois service principals ou plus avec un succès mitigé, ou une application qui demande des jetons pour Resource Manager, Key Vault, Storage et Graph dans une fenêtre courte ;
• des requêtes très variées en peu de temps, retentées par variations successives : la signature d'un agent plutôt que d'un humain.

Microsoft rappelle que les adresses IP et les agents utilisateurs changent vite ; ils servent d'alerte, pas de protection.

Vérifier chez vous : vos journaux de connexion non interactive et de service principals sont-ils conservés et consultables ? Microsoft conseille de remonter aussi loin que la rétention le permet. Si la rétention est de quelques jours, vous ne pourrez pas reconstituer une campagne commencée en août.

FAQ

Supprimer le secret du dépôt GitHub suffit-il ?

Non. Microsoft l'écrit sans ambiguïté : supprimer le contenu n'invalide pas l'identifiant et n'efface pas les copies conservées dans l'historique d'édition, les caches, les archives ou les journaux. Il faut révoquer ou renouveler le secret, puis enquêter sur son usage passé.

Qu'est-ce que la push protection de GitHub ?

C'est une fonction de GitHub Secret Protection qui analyse le contenu au moment du push et bloque les types de secrets reconnus avant qu'ils n'arrivent sur le dépôt. Elle couvre les formats que GitHub sait détecter ; un scan pre-commit et en CI complète les cas restants.

Combien de temps ai-je pour révoquer un secret exposé ?

Le rapport ne donne pas de délai garanti. Il décrit un cas où cinq minutes ont séparé la recherche du secret sur GitHub de l'exfiltration de données d'un Key Vault. La seule hypothèse prudente est de révoquer immédiatement et de traiter le secret comme déjà utilisé.

Qu'est-ce qu'ARTEX ?

Microsoft présente ARTEX comme un framework de tests d'intrusion à base d'IA agentique. Par défaut, il s'appuie sur des outils existants (Nmap, curl, wget, clients HTTP Python, Chromium sans interface via Playwright, entre autres) et peut enchaîner seul la recherche, l'analyse et les actions suivantes.

Sources

• Microsoft Threat Intelligence, Threat actors use agentic AI tooling to find and abuse exposed secrets, 5 novembre 2026 : https://www.microsoft.com/en-us/security/blog/2026/11/05/threat-actors-use-agentic-ai-tooling-to-find-and-abuse-exposed-secrets

---

Vous voulez savoir combien de temps il faudrait à votre équipe pour révoquer un secret fuité, et ce qu'il donnerait à lire ? WeeSec mesure ce délai et outille la chaîne pré-push lors de ses missions DevSecOps.