Les angles morts des logs d'authentification cloud

Une équipe de sécurité de TrustedSec a récemment révélé ses troisième et quatrième méthodes pour contourner la journalisation des connexions Azure. Cela fait quatre techniques indépendantes pour s'authentifier auprès des services cloud Microsoft sans que l'authentification apparaisse dans les logs sur lesquels les équipes de sécurité s'appuient pour la détection. La connexion a bien eu lieu. Les logs, eux, ne l'ont pas enregistrée. Quiconque surveillait ces logs à la recherche d'activités suspectes n'a rien vu.

Ce n'est pas un problème théorique. Si un attaquant vole des identifiants et les utilise pour accéder à votre environnement Azure, la première chose que fait votre équipe de sécurité est de consulter les logs de connexion. Si ces logs sont incomplets, si des catégories entières d'authentification ne génèrent aucune entrée, votre capacité de détection a un trou dont vous ignoriez l'existence. Et vous avez pris des décisions de sécurité en partant du principe que les logs étaient complets.

Pourquoi les logs d'authentification ont des lacunes

L'hypothèse naïve est que la journalisation de l'authentification est simple : quelqu'un s'authentifie, on le journalise. En pratique, l'authentification dans le cloud est un système tentaculaire, avec des dizaines de protocoles, de points de terminaison et de types de jetons, et la couverture des logs varie selon les cas.

Azure Active Directory (désormais Entra ID) gère l'authentification pour Microsoft 365, les ressources Azure, les applications tierces via SAML/OIDC, les applications on-premises héritées via App Proxy, les principaux de service, les identités managées, et bien d'autres. Chacun de ces chemins d'authentification a son propre backend, son propre pipeline de journalisation et ses propres cas limites. Les logs de connexion sont générés par le service d'authentification, mais certains flux contournent ce service standard ou utilisent des chemins hérités antérieurs à l'infrastructure de journalisation actuelle.

Les lacunes liées aux protocoles hérités

Microsoft maintient la rétrocompatibilité avec des protocoles d'authentification datant du début des années 2000, des protocoles antérieurs à son infrastructure de journalisation moderne. Certains chemins d'authentification SMTP, IMAP et POP3 utilisent des flux « Basic Auth » qui s'authentifient au niveau de la couche de transport du courrier, et non via le point de terminaison de jetons Azure AD standard. Ces authentifications ne génèrent pas forcément les mêmes entrées de connexion que les flux OAuth/OIDC modernes.

Microsoft déprécie Basic Auth depuis des années, mais la dépréciation est lente dans les environnements d'entreprise. Les organisations qui utilisent d'anciens clients de messagerie, des scanners qui envoient des documents par e-mail ou des applications métier anciennes peuvent encore avoir Basic Auth activé. Chaque chemin hérité est un trou potentiel dans les logs.

Authentification des principaux de service

Les principaux de service, c'est-à-dire des identités non humaines utilisées par les applications et l'automatisation, s'authentifient différemment des utilisateurs. Leurs événements de connexion apparaissent dans un flux de logs distinct (connexions de principaux de service, connexions interactives et connexions non interactives). Les équipes de sécurité qui ne surveillent que le log des connexions interactives ne voient pas du tout l'activité des principaux de service.

C'est important, car les principaux de service compromis sont un vecteur d'attaque courant. Un attaquant qui obtient les identifiants ou le certificat d'un principal de service peut s'authentifier en tant que cette application et accéder à toutes les ressources auxquelles elle a droit. Si l'équipe de sécurité ne surveille que les connexions utilisateur, elle ne verra jamais cela.

Rejeu et renouvellement des jetons

Tous les accès ne passent pas par une nouvelle authentification. Les jetons de rafraîchissement OAuth permettent de conserver l'accès sans se réauthentifier. Si un attaquant vole un jeton de rafraîchissement valide (via un appareil compromis, du trafic intercepté ou un malware), il peut l'échanger contre de nouveaux jetons d'accès sans déclencher les mêmes entrées de connexion qu'une authentification par mot de passe. La connexion initiale a bien été journalisée, mais les rafraîchissements ultérieurs peuvent apparaître comme des connexions non interactives, que de nombreuses règles de détection ne surveillent pas.

Le problème de l'ingénierie de la détection

Les lacunes de journalisation de l'authentification révèlent un problème plus large de la sécurité cloud : nous construisons des systèmes de détection sur des logs que nous supposons complets, puis nous nous étonnons lorsque les attaquants trouvent des chemins qui ne génèrent aucun log.

L'architecture de sécurité standard pour les environnements cloud ressemble à ceci : les services cloud génèrent des logs → les logs remontent vers un SIEM (système de gestion des informations et des événements de sécurité) → des règles de détection analysent les logs à la recherche de schémas suspects → des alertes déclenchent une investigation. Cela ne fonctionne que si les logs capturent toute l'activité pertinente. Sinon, votre SIEM est un moyen très coûteux de surveiller une vision incomplète.

Typical detection rule logic:
IF sign-in from unusual location
AND sign-in at unusual time
AND multiple failed attempts followed by success
THEN alert: possible credential compromise
What this misses:
- Authentication via legacy protocol → no sign-in log entry
- Stolen refresh token → appears as normal non-interactive sign-in
- Service principal abuse → in a different log stream entirely
- Authentication bypasses → sign-in doesn't appear at all
The rule is correct. The data it operates on is incomplete.

Ce que vous pouvez réellement faire

Vous ne pouvez pas combler les lacunes de journalisation des fournisseurs cloud : c'est le travail de Microsoft (ou d'AWS, ou de Google). En revanche, vous pouvez construire des stratégies de détection qui ne dépendent pas uniquement de la complétude des logs d'authentification.

Surveiller plusieurs sources de logs

Les logs d'authentification ne sont qu'un signal. Les logs d'activité en sont un autre. Même si la connexion d'un attaquant n'apparaît pas dans les logs d'authentification, ses actions ultérieures (lecture d'e-mails, accès à des fichiers, requêtes sur des bases de données, modification de configurations) génèrent leurs propres entrées. Corréler les logs d'activité avec les logs d'authentification révèle les incohérences : une activité provenant d'une identité sans connexion récente correspondante est suspecte, quelle que soit la raison pour laquelle la connexion n'a pas été journalisée.

-- Detection query: activity without recent authentication
-- (KQL-style for Azure Sentinel/Microsoft Sentinel)
let timeframe = 24h;
let activity_logs = AuditLogs
| where TimeGenerated > ago(timeframe)
| summarize Actions = count() by Identity, bin(TimeGenerated, 1h);
let signin_logs = SigninLogs
| where TimeGenerated > ago(timeframe)
| summarize LastSignIn = max(TimeGenerated) by UserPrincipalName;
activity_logs
| join kind=leftanti signin_logs
on $left.Identity == $right.UserPrincipalName
| where Actions > 5  // filter noise
// Results: identities with activity but no sign-in log entry
// These need investigation — either a logging gap or a bypass

Désactiver l'authentification héritée

Si vous n'utilisez pas les protocoles hérités (Basic Auth pour SMTP, IMAP, POP3), désactivez-les. Cela élimine des catégories entières de lacunes, car les chemins d'authentification qui contournent la journalisation moderne ne peuvent tout simplement plus être utilisés. Les stratégies d'accès conditionnel d'Azure peuvent bloquer l'authentification héritée par utilisateur, par groupe ou à l'échelle du tenant.

Avant de désactiver, auditez votre utilisation actuelle. Les logs de connexion d'Azure (ironiquement) montrent certaines tentatives d'authentification héritées, et le classeur Entra ID dédié à l'authentification héritée aide à identifier les applications qui utilisent encore d'anciens protocoles. Corrigez d'abord ces applications, puis bloquez l'authentification héritée.

Surveiller l'activité des jetons

Mettez en place la Continuous Access Evaluation (CAE) si votre environnement le permet. La CAE permet à Azure AD de révoquer les jetons quasiment en temps réel lorsque les conditions changent (utilisateur désactivé, connexion à haut risque détectée, changement de localisation IP). Sans CAE, un jeton d'accès volé reste valide jusqu'à son expiration, généralement une heure, quoi que fasse l'équipe de sécurité.

Surveillez aussi la durée de vie des jetons et les schémas de rafraîchissement. Un jeton de rafraîchissement utilisé depuis une nouvelle adresse IP, un nouvel appareil ou à des heures inhabituelles devrait être signalé : c'est souvent le seul indice d'un vol de jeton.

Testez vos propres logs

La chose la plus efficace que vous puissiez faire est de vérifier régulièrement que vos logs capturent bien ce que vous pensez. Authentifiez-vous par chaque méthode prise en charge par votre environnement (interactive, non interactive, principal de service, protocole hérité) et vérifiez que chacune génère les entrées de log attendues. Si ce n'est pas le cas, vous avez trouvé une lacune avant un attaquant.

C'est une forme de test d'ingénierie de la détection que peu d'organisations pratiquent de manière systématique. La plupart des équipes écrivent des règles de détection et supposent qu'elles fonctionnent. Valider la qualité des données sous-jacentes, c'est-à-dire confirmer que les événements dont dépendent vos règles sont bien journalisés, est sans doute plus important que les règles elles-mêmes.

La leçon plus générale

Les contournements des logs de connexion Azure ne sont pas propres à Microsoft. Chaque fournisseur cloud dispose de chemins d'authentification à la journalisation incomplète. AWS CloudTrail présente ses propres lacunes connues : certaines opérations du plan de contrôle dans certaines régions, certaines prises de rôle de services liés, et des chaînages de rôles entre comptes qui peuvent masquer l'identité d'origine. Les journaux d'audit de Google Cloud présentent des cas limites similaires.

La leçon n'est pas « la journalisation d'Azure est cassée ». Elle est que toute journalisation est incomplète, et les architectures de sécurité qui supposent le contraire échoueront. La défense en profondeur ne consiste pas seulement à multiplier les contrôles de sécurité, mais à disposer de plusieurs sources de visibilité indépendantes. Si votre détection dépend entièrement de la complétude d'une seule source de logs, vous avez un point de défaillance unique dans votre posture de sécurité.

Construisez votre détection en partant du principe que toute source de logs peut être incomplète ou contournée. Corrélez les logs d'authentification, les logs d'activité, les logs réseau et la télémétrie des postes de travail. Recherchez les incohérences entre les sources : elles pointent souvent vers exactement les lacunes que les attaquants exploitent. Et testez vos logs régulièrement, car la lacune que vous ne connaissez pas est celle qui sera utilisée contre vous.