Microsoft 365 est aujourd’hui le cœur du système d’information de nombreuses entreprises : messagerie, collaboration, partage documentaire, applications métiers, tout comme l'est aussi Google WorkSpace. 

Cette centralité en fait une cible stratégique. Or, les nouvelles attaques ne cherchent plus à casser les protections existantes : elles exploitent les mécanismes légitimes du Cloud et passent sous les radars traditionnels.

Ils rentrent sans passer par les failles… Quelles solutions ?

Historiquement, la sécurité de Microsoft 365 reposait sur la détection de vulnérabilités, le durcissement des configurations et la protection des identités (Multi-Factor Authentification -MFA-, Conditional Access). Ce modèle est désormais insuffisant. Depuis quelques mois, de nouvelles attaques très ciblées sur Microsoft 365 apparaissent.

Avec l’IA et une connaissance fine des environnements Cloud, les attaquants ciblent aujourd’hui les mécanismes d’autorisation de Microsoft 365, sans exploiter la moindre faille technique et restent donc invisibles. Comment ?

Beaucoup d’organisations pensent que l’activation du MFA suffit à sécuriser l’environnement. Or le MFA protège l’authentification, mais pas toujours l’usage des autorisations déjà accordées. C’est précisément ce décalage qui est aujourd’hui exploité.

Les nouveaux vecteurs d’attaque

Voici quelques tactiques relevées parmi les plus efficaces aujourd’hui. Elles reposent sur des fonctionnalités légitimes :

• OAuth[1]Consent Abuse

: en incitant un utilisateur à consentir à une application malveillante, l’attaquant obtient des tokens valides, parfois avec des permissions élevées (Mail.Read, Files.Read.All, Directory.Read).

Concrètement, ce peut être le cas d’un employé qui reçoit un email semblant provenir de Microsoft indiquant : “Votre session Outlook va expirer. Pour éviter l’interruption, veuillez revalider vos accès.”

• Persistence via App Registration 

Création ou modification d’applications Azure AD pour maintenir un accès durable, même après changement de mot de passe ou révocation de sessions.

Le plus classique est l’utilisateur qui demande à son responsable IT : “Pour corriger un problème d’intégration avec Power Automate, peux-tu enregistrer cette application et lui donner les permissions API suivantes ? C’est urgent, c’est pour la direction.”

Pourquoi est-ce critique ? Parce que l’attaquant peut ainsi générer des tokens à volonté, agir via Microsoft Graph et maintenir l’accès pendant des mois !

• Living-off-the-Cloud  

Utilisation exclusive d’API Microsoft Graph, rendant l’activité difficile à distinguer d’un usage légitime.

C’est le cas lorsque l’attaquant utilise Microsoft Graph et dispose déjà d’un token OAuth valide, d’une App Registration persistante, voire d’un compte compromis.

C’est redoutable parce que l’attaquant, au lieu de s’appuyer sur un Malware, utilise les API officielles[dg1]  Microsoft.

• Bypass MFA indirect 

Le MFA protège l’authentification, mais pas toujours l’utilisation des tokens déjà émis.

Concrètement, c’est le cas de l’utilisateur qui clique sur une application OAuth malveillante : il s’authentifie normalement et valide le MFA. Puis il clique sur “Accepter” les permissions.

Dans ces différents scénarios, aucun identifiant n’est volé, et les contrôles traditionnels restent aveugles. Ils sont dans la place sans qu’on le sache.

L’erreur que l’on rencontre fréquemment chez nos clients, c’est qu’ils pensent que le MFA protège tout, même après avoir validé une action suspecte. Ils se disent que puisqu’ils ont validé avec leur téléphone, c’est sécurisé. Et si c’était malveillant, le MFA l’aurait bloqué.

Mais il faut comprendre que le MFA valide l’identité, pas la légitimité de l’application. Et il ne bloque donc pas l’usage ultérieur du token. 

Dans ces scénarios, aucun identifiant n’est volé, et les contrôles traditionnels restent aveugles. 

[1] « Open Authorization » la norme industrielle de facto pour l'autorisation en ligne. OAuth est un protocole d'autorisation et non un protocole d'authentification.

Ils sont dans la place sans qu’on le sache.

Il est urgent de modifier nos stratégies de défense !

Pour contrer ces attaques, il est nécessaire d’ajouter des contrôles après l’authentification. 

Voici quelques bonnes pratiques à mettre rapidement en œuvre, mais il pourrait y en avoir d’autres selon l’évolution des attaques :

Gouvernance stricte des consentements OAuth

1. • Désactiver le consentement utilisateur par défaut
   • Mettre en place un workflow de validation administrateur
   • Auditer régulièrement les applications et permissions accordées

Ce sont des règles assez simples à mettre en œuvre et qui renforcent significativement le niveau de sécurité. 

Surveillance comportementale des identités

1. • Détecter l’usage anormal de Microsoft Graph (volumes, horaires, géolocalisation)
   • Identifier les accès persistants non interactifs

C’est un peu plus technique. Sans outils spécialisés, cette surveillance comportementale est impossible. Le SIEM sera la première brique à mettre en place, couplée avec des XDR. Mais l’idéal est d’aller plus loin avec de l’UEBA (User & Entity Behavior Analytics).

Durcissement des accès conditionnels

1. • Appliquer des règles spécifiques aux applications et aux API
   • Restreindre les tokens longue durée et forcer leur expiration

C’est un peu de travail, mais assez facile à faire.

Journalisation et visibilité étendue

1. • Centraliser les logs Azure AD, Unified Audit Log et Graph
   • Corréler les événements d’autorisation, de consentement et d’accès aux ressources

Là aussi, les outils comme le SIEM seront d’une grande utilité. Mais vu la masse colossale d’informations à traiter par seconde, il faudra s’appuyer sur une IA performante pour détecter un comportement anormal le plus rapidement possible.

Approche Zero Trust orientée identité

1. • Ne plus considérer une identité authentifiée comme implicitement fiable
   • Réévaluer en continu le contexte et le comportement

Il est indispensable d’augmenter les contrôles automatiques et de ne plus se reposer uniquement sur les mécanismes standards.

Ce ne sont que quelques exemples qui devront être actualisés en fonction de l’évolution de la posture des attaquants dans les prochaines semaines.

Conclusion

Ces changements et cette surveillance sont assez complexes. Si vous n’avez pas le temps ou pas les ressources, faites appel à des experts. Le risque est suffisamment important.

La plupart des organisations disposent des briques techniques nécessaires, mais manquent de supervision continue et centralisée, ainsi que d’expertise pour interpréter les signaux faibles. Or ce sont précisément ces signaux faibles qui révèlent ces nouvelles attaques.

Quoiqu’il en soit, la sécurité Microsoft 365 n’est plus un simple sujet de configuration ou de correctifs. Elle repose désormais sur un vrai savoir-faire s’appuyant sur la maîtrise des identités, des autorisations et des usages légitimes.

C'est bien sur le même combat pour les autres Suites Collaboratives en ligne (Google WorkSpace...).

Les attaquants ne forcent plus la porte… Ils utilisent les clés qu’on leur donne.