Phishing via Teams et SharePoint : menace Microsoft 365

En août 2023, Microsoft a révélé que le groupe Midnight Blizzard (ex-Nobelium, lié au renseignement russe) avait ciblé des organisations via des messages Teams provenant de comptes Microsoft 365 compromis. Les attaquants n’ont pas eu besoin de contourner un filtre email. Ils n’ont pas eu besoin de créer un domaine d’expédition crédible. Ils ont envoyé des messages directement dans Teams, avec le nom et la photo de profil d’un vrai compte Microsoft, et ont demandé aux destinataires d’approuver une application OAuth.

Ce type d’attaque ne relève pas du phishing tel que la plupart des PME le conçoivent. Pas d’email suspect avec un logo pixelisé. Pas de faute d’orthographe dans l’objet. Pas de domaine @microsft-securty.com repérable en deux secondes. Ici, le message arrive dans un outil de confiance, Teams, depuis un compte qui ressemble en tout point à celui d’un interlocuteur légitime.

Et c’est précisément là que réside le problème : les défenses de la plupart des PME sous Microsoft 365 sont construites autour de l’email, alors que les attaquants se sont déplacés vers des canaux que ces défenses ne couvrent pas.

Cet article analyse pourquoi Teams et SharePoint sont devenus des vecteurs de phishing privilégiés, quels types d’attaques circulent, quels incidents réels ont marqué 2024-2025, et comment protéger concrètement votre organisation. Pour les bases du phishing : notre glossaire du phishing.

Pourquoi les attaquants migrent de l’email vers Teams et SharePoint

Pendant vingt ans, l’email a été le vecteur principal du phishing. Les entreprises ont répondu en empilant des couches de protection : passerelles de sécurité email (SEG), filtres anti-spam, analyse d’URL, sandboxing des pièces jointes. La grande majorité des organisations de plus de 50 employés disposent d’au moins une solution de filtrage email.

Cette course aux armements a produit un effet prévisible : les attaquants cherchent des canaux moins surveillés.

Teams : la porte ouverte que personne ne surveille

Microsoft Teams est utilisé par plus de 300 millions d’utilisateurs actifs mensuels (Microsoft). Dans la plupart des organisations, Teams est configuré avec ses paramètres par défaut, qui autorisent la réception de messages de la part d’utilisateurs externes.

Trois caractéristiques font de Teams un vecteur de phishing redoutable :

Aucune inspection par les SEG. Les messages Teams ne transitent pas par les passerelles email. Un lien malveillant envoyé dans un message Teams contourne 100 % de l’infrastructure de filtrage email de l’entreprise. C’est comme installer une porte blindée sur l’entrée principale et laisser la fenêtre du rez-de-chaussée ouverte.

Confiance implicite élevée. Les collaborateurs perçoivent Teams comme un outil interne. La psychologie est différente de celle de l’email : quand un message arrive dans Teams, le réflexe de méfiance est bien plus faible. Le Système 1 (le mode de traitement rapide et automatique décrit par Kahneman) prend le dessus. On clique, on ouvre, on répond, sans l’analyse critique qu’on appliquerait à un email externe suspect.

Contexte riche et crédible. Un message Teams affiche le nom de l’expéditeur, sa photo de profil, son statut de présence (en ligne, absent, en réunion). Cette richesse contextuelle renforce la crédibilité du message. Un email de support@microsoft.com peut être forgé, et les utilisateurs le savent. Mais un message Teams de « Julie Martin — Service Comptabilité — En ligne » active des circuits de confiance bien plus profonds.

SharePoint : le cheval de Troie des notifications de partage

SharePoint complète le dispositif. Les attaquants utilisent SharePoint de deux manières :

Les vraies notifications SharePoint. Un attaquant qui a compromis un compte Microsoft 365 peut partager un document SharePoint malveillant avec les contacts de la victime. La notification de partage est légitime : elle provient réellement de SharePoint, elle contient le vrai nom de l’expéditeur, et le lien pointe vers un vrai site SharePoint. Le document hébergé contient soit un lien de phishing, soit une macro malveillante, soit un fichier OneNote piégé.

Les fausses notifications SharePoint par email. En parallèle, des campagnes de phishing par email imitent les notifications de partage SharePoint. Ces emails reproduisent fidèlement le template visuel de Microsoft : logo, mise en page, bouton « Ouvrir le document ». Le lien redirige vers une page de login factice qui collecte les identifiants Microsoft 365.

La subtilité de cette deuxième méthode : même un utilisateur formé à détecter le phishing peut baisser sa garde face à une notification SharePoint, parce que recevoir des partages de documents est un comportement normal dans son quotidien professionnel.

Phishing email classique vs phishing Teams/SharePoint

Critère	Phishing par email	Phishing via Teams/SharePoint
Filtrage par la passerelle email (SEG)	Oui — la majorité est bloquée	Non — le SEG ne voit pas le trafic Teams
Niveau de confiance de l’utilisateur	Moyen (habitué aux alertes phishing)	Élevé (outil de travail interne perçu comme sûr)
Détection visuelle	URL visible, en-têtes analysables	URL masquée dans le chat, pas d’en-têtes email
Propagation après compromission	Limitée (un compte = des emails sortants)	Rapide (lateral phishing via contacts Teams)
Taux de signalement	Faible (SANS)	< 10 % (peu de boutons de signalement Teams)
Journalisation par défaut	Complète (Exchange, SEG)	Limitée (audit Teams désactivé par défaut, rétention 180 jours)

Les quatre vecteurs d’attaque via Microsoft 365

1. Messages Teams depuis un compte compromis (lateral phishing)

C’est le scénario le plus dangereux et le plus difficile à détecter. Un attaquant compromet un compte Microsoft 365, souvent par credential stuffing sur un compte sans MFA, et utilise ce compte pour envoyer des messages Teams aux contacts internes de la victime.

Le message est personnalisé. Il fait référence à un projet en cours, à un document réel, à une réunion prévue. Le lien contenu dans le message pointe vers une page de phishing qui récolte les identifiants du destinataire. L’attaquant compromet ainsi un deuxième compte, puis un troisième, puis un quatrième : c’est le lateral phishing.

Ce qui rend ce vecteur dévastateur :

Le message provient d’un collègue réel, avec sa photo et son nom
Il arrive dans Teams, un canal de confiance
Il fait référence à un contexte professionnel réel (récupéré dans les emails et fichiers du compte compromis)
Le lien de phishing peut être hébergé sur un domaine Microsoft légitime (*.sharepoint.com, *.onmicrosoft.com)

Les taux de clic sur ces messages internes sont considérablement supérieurs à ceux des campagnes de phishing par email externe. Quand votre collègue de bureau vous envoie un lien dans Teams, vous ne vérifiez pas l’URL.

2. Phishing par consentement OAuth

Le phishing par consentement OAuth est la technique utilisée par Midnight Blizzard et Storm-0324. L’attaquant crée une application OAuth malveillante (ou compromet une application légitime) et envoie à la victime une demande d’autorisation.

L’écran de consentement est familier : il ressemble à n’importe quelle autorisation d’application Microsoft. L’utilisateur voit :

Un nom d’application qui inspire confiance (« Microsoft Security Update », « SharePoint Migration Tool »)
Une liste de permissions demandées (accès aux fichiers, lecture des emails, profil utilisateur)
Un bouton « Accepter » ou « Autoriser »

Si l’utilisateur clique sur « Accepter », l’application obtient un jeton d’accès OAuth qui lui permet de lire les emails, accéder aux fichiers SharePoint, envoyer des messages Teams au nom de l’utilisateur, et ce sans connaître le mot de passe et sans que le MFA ne se déclenche. Le jeton OAuth contourne le MFA parce que l’authentification a déjà été validée par l’utilisateur.

C’est le cauchemar des équipes sécurité : une compromission complète du compte sans vol de mot de passe et sans alerte MFA. Pour approfondir le sujet du MFA et ses limites, consultez notre guide de déploiement du MFA en entreprise.

3. Fausses invitations à des réunions Teams

L’attaquant envoie par email une invitation à une réunion Teams. Le mail reproduit fidèlement le format des invitations Microsoft : objet, date, heure, bouton « Rejoindre la réunion Teams ». Le bouton ne lance pas Teams : il redirige vers une page de phishing qui collecte les identifiants Microsoft 365.

Cette technique exploite un automatisme comportemental : les utilisateurs qui reçoivent des dizaines d’invitations Teams par semaine cliquent sur « Rejoindre » sans vérifier l’URL de destination. Le traitement est entièrement en Système 1 : l’invitation ressemble à toutes les autres, le cerveau applique la même réponse automatique.

4. Documents SharePoint piégés avec redirections

Un document hébergé sur un site SharePoint légitime (le SharePoint de l’organisation compromise) contient un lien vers une page de phishing. Le document peut être un fichier Word avec un bouton « Cliquez ici pour accéder à la version mise à jour », un fichier OneNote avec un faux bouton « Ouvrir dans le navigateur », ou un PDF avec un QR code de redirection.

La notification de partage SharePoint est légitime. Le lien dans la notification pointe vers un vrai site SharePoint. Le document est hébergé sur un domaine Microsoft de confiance. Seul le lien à l’intérieur du document est malveillant. Cette chaîne de confiance à plusieurs niveaux rend la détection extrêmement difficile, tant pour les outils automatisés que pour les utilisateurs.

Incidents réels : Midnight Blizzard et Storm-0324

Midnight Blizzard (Nobelium) — Campagne Teams 2023-2025

En août 2023, Microsoft Threat Intelligence a publié un rapport détaillant une campagne de Midnight Blizzard ciblant des organisations gouvernementales, des ONG et des entreprises technologiques via Teams. Le groupe avait compromis des tenants Microsoft 365 de petites entreprises et utilisait ces comptes pour envoyer des messages Teams aux cibles.

Les messages contenaient des demandes de consentement OAuth déguisées en vérifications de sécurité Microsoft. Les victimes qui acceptaient donnaient aux attaquants un accès complet à leur messagerie, leurs fichiers et leurs contacts.

Points à retenir pour les PME :

Les petites entreprises servent de tremplin : leurs comptes compromis sont utilisés pour attaquer des cibles plus importantes
Votre PME n’a pas besoin d’être la cible finale pour être impliquée dans une chaîne d’attaque
Un compte compromis dans votre organisation peut être utilisé pour attaquer vos clients, vos partenaires, vos fournisseurs

Storm-0324 — Distribution de malware via Teams

En septembre 2023, Microsoft a signalé que Storm-0324 (un groupe cybercriminel à motivation financière) utilisait Teams pour distribuer des charges malveillantes. Le groupe envoyait des messages Teams avec des liens vers des fichiers SharePoint hébergés sur des tenants compromis. Les fichiers déclenchaient le téléchargement du malware JSSLoader, un chargeur utilisé pour déployer des ransomwares.

Storm-0324 n’est pas un groupe étatique sophistiqué : c’est un groupe criminel motivé par l’argent, qui vend l’accès initial à d’autres groupes de ransomware. Sa migration vers Teams signale que les vecteurs de collaboration interne sont devenus des canaux d’attaque commerciaux, accessibles à des acteurs de compétence moyenne.

DarkGate et phishing Teams externe — 2024

Tout au long de 2024, des campagnes de distribution du malware DarkGate ont exploité les messages Teams externes. Les attaquants envoyaient des messages à des utilisateurs dont les organisations autorisaient la messagerie Teams externe. Les messages contenaient des pièces jointes ou des liens vers des fichiers hébergés sur SharePoint, qui déclenchaient le téléchargement de DarkGate.

Ce vecteur d’attaque n’a fonctionné que contre les organisations ayant laissé les paramètres d’accès externe Teams en configuration par défaut : ouverts à tous.

Pourquoi les paramètres par défaut de Microsoft 365 sont insuffisants

Microsoft 365 est livré avec des paramètres par défaut conçus pour faciliter l’adoption et la collaboration. Ce choix de conception est compréhensible du point de vue commercial. Il est catastrophique du point de vue de la sécurité.

Accès externe Teams : ouvert par défaut

Par défaut, Microsoft Teams autorise la communication avec des utilisateurs de n’importe quel tenant Microsoft 365 externe. N’importe qui possédant un compte Microsoft peut envoyer un message à vos collaborateurs. Les messages des utilisateurs externes sont marqués d’un bandeau discret « Externe », mais la plupart des utilisateurs ne le remarquent pas ou n’en comprennent pas la signification.

Consentement OAuth : utilisateurs autorisés par défaut

Par défaut, les utilisateurs Microsoft 365 peuvent accorder des permissions à des applications tierces via OAuth sans validation d’un administrateur. N’importe quel utilisateur peut autoriser une application à lire ses emails, accéder à ses fichiers et envoyer des messages en son nom. C’est le vecteur exploité par Midnight Blizzard.

Safe Links : pas activé dans Teams par défaut

Microsoft Defender for Office 365 propose Safe Links, une fonctionnalité qui analyse les URL en temps réel. Pour l’email, Safe Links est activé par défaut avec une licence E5 ou Defender Plan 2. Pour Teams, Safe Links nécessite une configuration explicite que la majorité des PME n’effectue pas.

Journaux d’audit : rétention limitée

Les journaux d’audit Microsoft 365 (unified audit log) ont une rétention par défaut de 180 jours avec une licence E3, et de 365 jours avec E5. Pour les investigations sur des compromissions de longue durée (les attaques APT peuvent rester dormantes pendant des mois), cette rétention est insuffisante. De nombreuses PME n’activent même pas l’audit unifié, qui n’est pas activé par défaut sur tous les tenants.

Pour une vue complète des mesures de sécurisation, consultez notre guide pour sécuriser Microsoft 365.

Plan de protection : 8 mesures concrètes

1. Restreindre l’accès externe Teams

Accédez au centre d’administration Teams → Paramètres à l’échelle de l’organisation → Accès externe. Trois options :

Bloquer tout : si votre entreprise ne collabore pas via Teams avec des parties externes. C’est la configuration la plus sûre.
Liste blanche de domaines : autorisez uniquement les domaines de vos partenaires et clients avec lesquels vous collaborez effectivement via Teams. Bloquez tout le reste.
Bloquer des domaines spécifiques : la moins sûre des trois options, car elle laisse passer tous les domaines non listés.

La recommandation pour les PME : passez en liste blanche. Si vous ne savez pas quels domaines autoriser, bloquez tout pendant deux semaines et observez les demandes. Vous identifierez rapidement les partenaires qui ont réellement besoin de vous contacter via Teams.

2. Restreindre le consentement OAuth

Dans le centre d’administration Azure Active Directory (Entra ID) → Applications d’entreprise → Paramètres de consentement :

Désactivez le consentement utilisateur pour les applications tierces
Configurez un workflow d’approbation administrateur : les utilisateurs peuvent demander l’accès à une application, mais un administrateur doit valider
Révisez régulièrement les applications OAuth déjà autorisées : supprimez celles qui ne sont plus utilisées

Cette mesure neutralise le vecteur de phishing OAuth utilisé par Midnight Blizzard. Sans consentement utilisateur, l’attaquant ne peut pas obtenir de jeton OAuth même si l’utilisateur clique sur « Accepter ».

3. Déployer le MFA sur tous les comptes

Le MFA reste la mesure la plus efficace contre la compromission initiale de comptes. Un compte protégé par MFA résiste au credential stuffing, au password spraying et à la réutilisation de mots de passe issus de fuites de données.

Cependant, le MFA ne protège pas contre le phishing par consentement OAuth (le jeton est délivré après une authentification MFA réussie) ni contre le vol de jetons de session. C’est pourquoi le MFA est nécessaire mais pas suffisant : il doit être combiné avec les autres mesures de cette liste.

4. Activer Safe Links pour Teams

Si vous disposez de Microsoft Defender for Office 365 (Plan 1 ou Plan 2), activez Safe Links pour Teams dans le centre de sécurité Microsoft 365 :

Sécurité → Politiques et règles → Politiques de menaces → Safe Links
Créez ou modifiez une politique Safe Links et activez l’option « Microsoft Teams »
Activez également l’analyse en temps réel des URL suspectes

Safe Links analyse les URL partagées dans les messages Teams au moment du clic et bloque les liens identifiés comme malveillants. Ce n’est pas une protection absolue (les URL fraîchement créées peuvent ne pas être encore répertoriées), mais elle élimine les campagnes de masse utilisant des domaines connus.

5. Configurer des politiques d’accès conditionnel

Les politiques d’accès conditionnel (Conditional Access) d’Azure AD / Entra ID permettent de restreindre l’accès à Microsoft 365 en fonction de critères contextuels :

Emplacement : bloquer les connexions depuis des pays où votre entreprise n’opère pas
Appareil : exiger des appareils conformes ou joints au domaine
Risque de connexion : exiger un MFA renforcé pour les connexions jugées à risque (nouvel appareil, localisation inhabituelle, connexion impossible géographiquement)
Application : restreindre les applications autorisées à accéder aux données Microsoft 365

Une politique d’accès conditionnel bien configurée réduit considérablement la surface d’attaque, même en cas de compromission d’identifiants.

6. Activer les alertes de connexion suspecte

Microsoft 365 génère des alertes sur les connexions suspectes : connexion depuis un pays inhabituel, connexion impossible (deux pays différents en moins d’une heure), tentatives de connexion en masse. Ces alertes sont disponibles dans le centre de sécurité Microsoft 365 et peuvent être transmises par email aux administrateurs.

Activez au minimum les alertes suivantes :

Connexion depuis un emplacement inhabituel
Activité d’envoi de messages en masse depuis Teams
Création d’une règle de transfert d’emails (signe classique de compromission)
Consentement OAuth accordé à une nouvelle application

7. Former les utilisateurs au signalement

La technologie ne peut pas tout bloquer. Les utilisateurs restent le dernier rempart, à condition d’être formés non seulement à détecter, mais surtout à signaler. Un programme de simulation de phishing efficace entraîne les collaborateurs à :

Reconnaître les marqueurs de phishing dans les messages Teams (bandeau « Externe », demande inhabituelle, lien inattendu)
Signaler les messages suspects via le bouton de signalement Teams ou un canal prévu à cet effet
Ne jamais approuver une demande de consentement OAuth sans validation d’un administrateur
Vérifier par un autre canal (appel téléphonique, message sur un autre outil) toute demande sensible reçue via Teams

Le SANS Institute montre que les organisations qui combinent simulation et micro-learning atteignent un taux de signalement élevé. Sans entraînement régulier, ce taux tombe sous les 10 %.

8. Auditer régulièrement les applications OAuth et les accès

Programmez un audit trimestriel des applications OAuth autorisées dans votre tenant Microsoft 365 :

Listez toutes les applications ayant reçu un consentement (administrateur ou utilisateur)
Vérifiez les permissions accordées : une application de gestion de calendrier n’a pas besoin d’accéder à vos emails
Révoquez les autorisations des applications non reconnues ou inutilisées
Vérifiez les logs de connexion pour détecter des connexions suspectes depuis des applications OAuth

Simuler le phishing Teams et SharePoint en sensibilisation

La simulation de phishing par email est bien établie. Mais si votre programme de sensibilisation ne couvre que l’email, il laisse un angle mort sur les vecteurs que les attaquants exploitent le plus activement.

Pourquoi simuler au-delà de l’email

Les retours d’expérience des campagnes de simulation montrent des taux de clic sur les messages Teams nettement plus élevés que sur les emails de phishing classiques — nettement plus élevés (Keepnet Labs) — précisément parce que les utilisateurs ne s’attendent pas à être attaqués via cet outil. La simulation permet de corriger ce biais de confiance avant qu’un vrai attaquant ne l’exploite.

Scénarios de simulation recommandés

Scénario 1 : fausse notification de partage SharePoint. Un email imitant une notification SharePoint informe le collaborateur qu’un document a été partagé avec lui par un collègue. Le lien mène à une page de login factice. Ce scénario teste la capacité à vérifier l’URL avant de saisir des identifiants.

Scénario 2 : message Teams d’un « collègue ». Un message simulant une conversation Teams demande au collaborateur de consulter un document ou de valider une information via un lien. Ce scénario teste la réaction face à un message qui arrive par un canal de confiance.

Scénario 3 : invitation à une réunion Teams. Une fausse invitation à une réunion Teams urgente, envoyée par email, contient un bouton « Rejoindre la réunion » qui redirige vers une page de phishing. Ce scénario teste la vigilance face aux invitations non sollicitées.

Scénario 4 : demande de consentement OAuth. Une demande d’autorisation pour une application présentée comme un outil Microsoft officiel. Ce scénario teste la compréhension des risques liés aux autorisations d’applications.

Intégrer ces simulations dans un programme continu

Un programme de simulation efficace alterne les vecteurs (email classique, notification SharePoint, message Teams, invitation calendrier) et augmente progressivement la difficulté. Les résultats par vecteur révèlent les angles morts spécifiques de chaque organisation.

Testez d’abord la posture de sécurité de votre messagerie avec notre outil de test de sécurité email, puis intégrez les scénarios Teams et SharePoint dans vos campagnes de simulation.

Ce que la direction doit retenir

La migration des attaques de phishing vers Teams et SharePoint n’est pas une prédiction : c’est un fait documenté par Microsoft, par les rapports Proofpoint et par les incidents publics de 2023-2025. Les PME qui n’ont pas ajusté leur posture de sécurité Microsoft 365 au-delà des paramètres par défaut sont exposées à des vecteurs que leurs défenses email ne couvrent pas.

Les trois actions prioritaires :

Restreindre l’accès externe Teams et le consentement OAuth — deux changements de configuration qui prennent quinze minutes et neutralisent les vecteurs les plus exploités
Déployer le MFA sur tous les comptes sans exception — la mesure qui élimine la majorité des compromissions initiales de comptes
Former les collaborateurs aux vecteurs Teams et SharePoint — parce que les filtres email ne protègent pas Teams, et que le réflexe de méfiance des utilisateurs n’existe pas encore sur ces canaux

Le phishing n’est plus un problème d’email. C’est un problème de confiance mal placée dans des outils perçus comme sûrs. Les organisations qui l’ont compris forment leurs équipes à la réalité des attaques modernes, pas à la menace d’hier.

Testez la sécurité de votre messagerie Microsoft 365 →