Ce que Microsoft dit avoir observé
Microsoft Threat Intelligence a publié son rapport le 5 novembre 2026. Selon l’entreprise, des acteurs malveillants ont utilisé un framework agentique pour chercher dans des dépôts GitHub publics des identifiants exposés, notamment des secrets d’application et des clés d’inférence IA, puis analyser les résultats et mener des actions ultérieures. Microsoft décrit un cas où un agent serait passé du balayage de dépôts à l’exfiltration de données depuis Azure Key Vault en cinq minutes. Il s’agit du compte rendu d’incidents par Microsoft ; CherTra News n’a pas vérifié les cas indépendamment.
Microsoft rapporte également des connexions réussies de service principal chez certains clients à partir du 28 octobre, puis la découverte de ressources cloud et l’accès à Key Vault et Storage. Certains identifiants compromis proviendraient d’une application mutualisée appartenant à un fournisseur. Cela ne signifie pas que tout secret public est automatiquement exploité, mais supprimer une chaîne du dépôt ne suffit pas à mettre fin à l’exposition.
Considérer tout secret détecté comme compromis
Si un identifiant apparaît dans du code public, supposer qu’il a pu être copié, même si le dépôt est rapidement privé ou si le commit est réécrit. Révoquer ou désactiver d’abord l’identifiant, puis en émettre un nouveau selon la procédure du fournisseur. Mettre à jour les services dépendants de manière sûre, vérifier que l’ancien ne fonctionne plus et examiner les journaux pour des usages inhabituels par heure, lieu, identité ou ressource.
Déterminer à quelles ressources l’identifiant donnait accès et s’il était partagé entre environnements. Une clé de développement ne devrait pas autoriser la production. Pour un service principal ou un fournisseur, demander quelles applications ou quels tenants partagent l’identité. Conserver les preuves d’audit et prévenir le responsable de réponse aux incidents : un historique Git apparemment propre ne prouve pas que la fuite est terminée.
Réduire le risque d’une nouvelle exposition
Activer l’analyse des secrets et la protection contre leur envoi dans les dépôts, y compris la surveillance des dépôts publics si l’offre le permet. Stocker les identifiants dans un coffre géré, limiter les permissions à chaque identité et préférer des identifiants à courte durée ou une identité de charge de travail quand c’est possible. Séparer production et test, désigner un responsable et une échéance, et surveiller les authentifications ou lectures sensibles inhabituelles.
Examiner aussi les tâches automatisées, forks, journaux de build, pièces jointes et configurations de déploiement. L’analyse détecte les formats reconnus sans prouver que tous les types de secrets sont absents. Un inventaire périodique et une revue d’accès restent nécessaires, surtout pour les fournisseurs et identités machine.
Checklist de réponse pour une petite équipe
1) Révoquer le secret exposé. 2) Le renouveler et mettre à jour le service légitime par un canal fiable. 3) Contrôler les journaux d’identité et du cloud pour rechercher son usage et celui des comptes associés. 4) Limiter les accès suspects en préservant les preuves. 5) Rechercher des copies dans les dépôts et systèmes de build contrôlés. 6) Activer l’analyse et la protection push, puis revoir permissions et expiration.
Si des données ou environnements clients ont pu être consultés, appliquer la procédure d’incident et de notification de l’organisation et solliciter une expertise sécurité adaptée. Le billet Microsoft fournit des indicateurs techniques aux défenseurs ; cet article se limite volontairement à la réaction défensive. Un secret est une identité : après exposition, il faut la renouveler et examiner ce qu’elle permettait d’atteindre.
Sources et références
Une erreur factuelle à signaler ou une source à suggérer ? Contacter la rédaction.
