Publication des troisième et quatrième cas de vulnérabilités de contournement des journaux de connexion d’Azure Entra ID

 (trustedsec.com)
1 points par GN⁺ 2026-03-22 | 1 commentaires | Partager sur WhatsApp
  • Depuis 2023, un total de 4 vulnérabilités de contournement des journaux de connexion d’Azure Entra ID ont été découvertes, les deux plus récentes étant confirmées comme des problèmes graves permettant l’émission de jetons valides
  • GraphGoblin contourne la génération des journaux dans le flux OAuth2 ROPC en répétant le paramètre scope, tandis que Graph**** provoque une absence complète de journaux avec une chaîne User-Agent de plus de 50 000 caractères
  • Les deux vulnérabilités seraient dues à un échec de journalisation causé par un dépassement de longueur de colonne SQL, et Microsoft a corrigé les problèmes après signalement
  • Microsoft a classé ce problème au niveau « Medium », l’a corrigé discrètement sans récompense ni reconnaissance officielle, alors qu’il est évalué au niveau High (7,5 à 8,7) selon le CVSS
  • Comme des défauts liés à des échecs répétés de validation des entrées continuent d’apparaître, le recoupement des journaux et le renforcement des règles de détection basées sur KQL sont présentés comme des tâches essentielles pour les responsables sécurité

Publication de vulnérabilités de contournement des journaux de connexion d’Azure Entra ID

  • Depuis 2023, un total de 4 vulnérabilités de contournement des journaux de connexion d’Azure Entra ID ont été découvertes
    • Les deux premiers cas permettaient seulement de vérifier la validité d’un mot de passe, mais les deux plus récents atteignent un niveau de gravité supérieur en permettant jusqu’à l’émission de jetons valides
    • Toutes les vulnérabilités ont désormais été corrigées par Microsoft

  • Résumé de GraphNinja et GraphGhost

    • GraphNinja : lorsqu’une tentative de connexion est effectuée en spécifiant l’endpoint d’un autre tenant, il est possible de savoir si le mot de passe est valide sans qu’aucun journal ne soit généré
      • Un attaquant peut envoyer une requête d’authentification vers un tenant externe et déterminer via la réponse si le mot de passe est correct
      • Microsoft a ensuite introduit une journalisation supplémentaire pour corriger ce problème
    • GraphGhost : si un Client ID erroné est utilisé, le flux d’authentification échoue après la vérification du mot de passe, mais les journaux n’indiquent qu’un échec
      • L’information selon laquelle le mot de passe était correct n’apparaît pas dans les journaux administrateur
      • Microsoft a corrigé cela en ajoutant l’état de vérification du mot de passe dans les journaux de connexion

  • Vulnérabilité GraphGoblin

    • GraphGoblin contourne la génération des journaux dans le flux OAuth2 ROPC en répétant le paramètre scope
      • Si une valeur de type "openid openid openid ..." est répétée des milliers de fois, un jeton valide est émis normalement mais aucune trace n’apparaît dans les journaux de connexion Entra ID
    • La cause pointée du doigt est un échec d’INSERT dû à un dépassement de longueur de colonne SQL
      • Il est supposé que la chaîne de scopes répétée dépasse la longueur du champ en base de données, ce qui fait échouer l’enregistrement du journal
    • Microsoft a eu des difficultés à reproduire le problème, mais a fini par le corriger après la fourniture d’une preuve vidéo

  • Graph****** (contournement via User-Agent)

    • Si une chaîne de plus de 50 000 caractères est fournie dans le champ User-Agent, aucun journal n’est généré
      • La requête d’authentification est traitée normalement et un jeton est émis, mais le journal est totalement absent
      • Là encore, la cause supposée est un échec de journalisation lié à un dépassement de longueur de colonne SQL
    • Découvert le 28 septembre 2025, le problème avait déjà été corrigé par Microsoft le 8 octobre avant même le signalement

  • Résumé de la chronologie

    • 2025-09-20 : première découverte de GraphGoblin
    • 2025-09-26 : signalement de GraphGoblin à Microsoft
    • 2025-09-28 : découverte de Graph******
    • 2025-10-08 : correction de Graph****** terminée
    • 2025-11-21 : Microsoft parvient à reproduire GraphGoblin et commence la correction

Réponse et évaluation de Microsoft

  • Microsoft a classé cette vulnérabilité au niveau « Medium » et n’a ni accordé de récompense ni publié de reconnaissance officielle
    • Les deux cas précédents (2023~2024) avaient fait l’objet d’une récompense et d’une reconnaissance
    • Cette fois, le problème a été jugé non prioritaire malgré sa gravité, puisqu’il permet l’émission de jetons valides
  • L’évaluation est de 7,5 (High) selon le CVSS v3.1 et 8,7 (High) selon le CVSS v4.0
    • Le score élevé s’explique par l’atteinte à l’Integrity (intégrité)
    • L’absence de journaux est considérée comme une altération directe d’un composant de sécurité
  • Microsoft a terminé la correction deux semaines après avoir reproduit le problème
    • À titre de comparaison, la correction de GraphNinja avait pris 7 mois et celle de GraphGhost 5 mois

Méthode de détection du contournement des journaux

  • Une requête KQL permet de comparer les Session ID ou UniqueTokenIdentifier entre les journaux Graph Activity et les journaux Sign-In
    • Si une session existe dans Graph Activity mais pas dans les journaux Sign-In, elle peut être considérée comme une connexion contournée
    • Toutefois, une licence E5 est nécessaire pour collecter les journaux Graph Activity
  • Exemple de requête KQL : 
    MicrosoftGraphActivityLogs
| where TimeGenerated > ago(8d)
| join kind=leftanti (union isfuzzy=true
SigninLogs,
AADNonInteractiveUserSignInLogs,
AADServicePrincipalSignInLogs,
AADManagedIdentitySignInLogs,
MicrosoftServicePrincipalSignInLogs
| where TimeGenerated > ago(90d)
| summarize arg_max(TimeGenerated, *) by UniqueTokenIdentifier
)
on $left.SignInActivityId == $right.UniqueTokenIdentifier
    • Si nécessaire, la comparaison peut aussi se faire sur SessionId
    • Sur la base des résultats de détection, il est possible de configurer une Azure Log Search Alert Rule

Résumé des quatre contournements des journaux de connexion

Date de découverte Méthode Émission de jeton Reconnaissance par Microsoft
2023-08 / 2024-05 Aucune génération du journal de vérification du mot de passe via la désignation d’un tenant ID externe X X
2024-12 / 2025-04 Forcer un échec d’authentification avec un Client ID erroné X X
2025-09-20 Dépassement de colonne SQL via répétition de scope O X
2025-09-28 Dépassement de colonne SQL via une longue chaîne User-Agent O N/A

Critiques du processus de sécurité de Microsoft

  • Des défauts découverts dans de multiples paramètres de la journalisation des connexions Entra ID

    • Des vulnérabilités répétées ont été observées dans des champs clés tels que tenant ID, client ID, scope et user-agent
    • Le problème provient d’un simple échec de validation des entrées, pas d’une attaque complexe
    • Cela met en cause l’absence de revue de sécurité et de contrôle qualité chez Microsoft
    • Des défauts similaires se répètent depuis des années dans la même zone
    • Le texte soulève aussi la possibilité d’un manque de rigueur dans la gestion du code ou dans l’introduction de génération de code par IA

  • Manque de transparence dans la divulgation

    • Aucun des quatre cas n’a reçu de CVE ni fait l’objet d’une annonce officielle
    • Microsoft, en tant que CNA, décide de manière exclusive si ses propres vulnérabilités doivent être divulguées

Conclusion

  • Les journaux de connexion d’Azure Entra ID constituent une donnée clé pour la détection d’intrusion dans des organisations du monde entier
    • Si des journaux manquent, l’ensemble du dispositif de détection d’attaque peut être neutralisé
  • Les quatre vulnérabilités découvertes étaient toutes détectables par un simple fuzzing des entrées
  • Microsoft doit renforcer ses explications publiques et la transparence de ses procédures de revue de sécurité face à ces défauts répétitifs
  • Les administrateurs et responsables sécurité doivent compléter leur dispositif de défense via le recoupement des journaux et des règles de détection fondées sur KQL

À lire aussi

1 commentaires

 
GN⁺ 2026-03-22
Avis sur Hacker News

  • Cela rappelle le rapport sur l’incident de compromission de Microsoft publié par la CISA
    Il s’agissait d’une attaque où des hackers soutenus par un État ont percé Microsoft puis infiltré plusieurs organismes, dont le département d’État américain
    Le plus surprenant, c’est que ce n’est pas Microsoft mais un administrateur système du département d’État qui a repéré une anomalie dans les logs de messagerie et découvert l’intrusion
    Lien vers le rapport de la CISA

  • Dans un article où ProPublica et ArsTechnica critiquaient frontalement Azure, il était dit que des experts fédéraux en cybersécurité qualifiaient le cloud de Microsoft de « médiocre »
    Lien vers l’article

    • En réalité, un expert parlait ainsi de la qualité de la documentation, et ProPublica semble avoir étendu cette critique à l’ensemble d’Azure
    • Ars n’a fait qu’une simple republication sous licence
    • Les ingénieurs sécurité Azure que je connais sont quasiment en burn-out mental. Sur une douzaine, la moitié est épuisée, et le reste n’a tout simplement pas le niveau
    • Bloomberg et CNBC n’ont pas traité cette affaire. J’aimerais que quelqu’un la fasse remonter via ses contacts dans les médias

  • L’état actuel de la cybersécurité est bien trop fragile pour des systèmes dont dépend toute la civilisation
    On dirait qu’on colmate un bateau percé avec du duct tape avant de le lancer sur l’océan

    • Le pire, c’est que le secteur réagit comme si, pour boucher ces trous, il suffisait d’ajouter plus de tourelles de mitrailleuses

  • Dans la discussion sur les logs SQL, il semble que l’attaquant ait envoyé une entrée trop longue, ce qui a fait échouer l’INSERT à cause d’un dépassement de longueur de colonne
    Résultat : la tentative de connexion n’a pas été enregistrée dans les logs

    • Les deux services fonctionnaient séparément. Le service de validation détectait l’échec et demandait au service de logs de l’enregistrer, mais même si ce dernier échouait, le service de validation renvoyait quand même sa réponse
      Cela ressemble à un problème structurel de conception, avec un flux d’authentification bien trop complexe

  • J’ai déjà eu le cas où les logs d’audit d’Azure enregistraient quelque chose de différent du comportement réel
    J’ai supprimé un client secret ; l’UI disait qu’elle allait supprimer B, mais l’API s’est comportée comme si elle ne laissait que A
    Au final, le log indiquait que c’était bien mon action, alors qu’en réalité c’était un bug du système
    Après ce genre d’expérience, ma confiance dans les logs d’audit en général, et pas seulement ceux d’Azure, a été ébranlée
    Je pense que c’est dangereux d’utiliser cela comme preuve devant un tribunal

    • C’est pour ça que je préfère les interfaces avec une étape de confirmation obligatoire avant toute modification. Les interfaces à sauvegarde automatique « façon jeu vidéo » sont trop risquées
    • Le portail Azure (nouvelle et ancienne version comprises) est truffé de bugs, donc ça n’a rien de surprenant. Il suffit parfois d’un mauvais clic pour modifier un autre objet
    • Ce cas est un très bon exemple pédagogique des risques de l’opération set vs l’opération delete dans un environnement d’édition simultanée. Les logs étaient exacts, mais c’est la conception de l’UI qui posait problème
    • Au fond, il est inquiétant de voir que l’utilisateur ne fait qu’exprimer une intention, tandis que l’exécution réelle est contrôlée par le frontend

  • Comparé aux vulnérabilités récentes d’EntraID, le contournement des logs paraît moins important

    • Mais si les logs d’authentification critiques ne fonctionnent qu’en mode « best-effort », c’est un problème grave comme base d’un audit de sécurité
    • Au final, les attaques réussies et furtives reposent souvent sur la combinaison de plusieurs vulnérabilités

  • Microsoft a déjà introduit une vulnérabilité critique jusque dans Notepad, donc ce genre de chose n’a rien de surprenant

  • Quand j’avais évalué Azure VPN autrefois, il n’y avait absolument aucun log de succès ou d’échec de connexion
    Quand j’ai soulevé le problème, Microsoft m’a répondu de l’enregistrer comme demande de nouvelle fonctionnalité
    C’est à ce moment-là que j’ai complètement perdu confiance en Azure. Avec le temps, j’ai l’impression que ça ne s’améliore pas, voire que ça empire

  • Si les administrateurs IT continuent d’utiliser Microsoft, c’est parce qu’ils n’ont pas vraiment d’alternative

    • Dans des environnements comme le mien, où il faut gérer des applications LOB en .NET et divers SaaS, les solutions Microsoft restent le choix le plus réaliste
      Les budgets sont serrés et les équipes manquent de personnel, alors on maintient juste le tout à un niveau qui permet de toucher son salaire et rentrer chez soi
    • Les jeunes administrateurs ont souvent une forte tendance à détester Microsoft. C’est peut-être un effet de génération
    • Comme le dit l’expression, « personne n’a jamais été licencié pour avoir choisi X » ; opter pour Microsoft présente peu de risques pour sa carrière

  • J’ai trouvé marquant que lorsque Microsoft n’arrivait pas à reproduire une vulnérabilité Azure et a demandé une preuve vidéo, quelqu’un ait répondu avec une simple ligne de commande curl
    Un moment vraiment jubilatoire