Des groupes de vishing utilisent des téléphones personnels pour s’introduire dans Microsoft 365 sans toucher aux appareils de l’entreprise
Cloud Security

Image d’illustration générée par IA

Des groupes de vishing utilisent des téléphones personnels pour s’introduire dans Microsoft 365 sans toucher aux appareils de l’entreprise

Storm-3032 et Storm-3121 ciblent les mobiles personnels par vishing pour voler des accès Microsoft 365 et exfiltrer SharePoint via Graph.

Texte généré par intelligence artificielle, publié sans relecture humaine. Transparence IA

Des acteurs malveillants appellent et contactent par SMS des employés sur leur téléphone personnel en se faisant passer pour le support informatique interne afin de dérober des identités Microsoft 365 et des sessions d’authentification. Une fois à l’intérieur, ils utilisent des interfaces cloud légitimes pour cartographier les environnements de l’entreprise et extraire discrètement des données de SharePoint, OneDrive et Exchange.

L’activité a été signalée le 10 septembre 2026. Microsoft surveille ces campagnes visant des appareils personnels depuis mai et suit leurs opérateurs sous les noms Storm-3032 et Storm-3121.

Cette technique est particulièrement dangereuse, car la première étape se déroule hors de portée de nombreux outils de sécurité de l’entreprise. Les attaquants n’ont pas nécessairement besoin de compromettre un ordinateur portable géré, de déployer un malware ou d’envoyer un message via le système de messagerie de l’entreprise.

Ils exploitent plutôt la confiance des employés.

L’attaque commence en dehors du périmètre de l’entreprise

Les cibles comprennent des cadres dirigeants, des administrateurs et des employés disposant de privilèges élevés dans Microsoft 365. De tels comptes peuvent donner accès à davantage d’utilisateurs, de groupes, de sites, d’applications, d’autorisations, de communications et de fichiers professionnels que l’identité d’un employé ordinaire.

L’attaquant contacte le numéro de téléphone mobile personnel de la cible par appel vocal ou SMS. Se faisant passer pour le support informatique de l’organisation, il affirme que l’employé doit mettre à jour un paramètre d’authentification sous peine de perdre l’accès aux services professionnels.

Les prétextes courants incluent notamment :

  • Enregistrer ou remplacer une passkey
  • Modifier une configuration MFA
  • Mettre à jour les paramètres de l’authentification unique
  • Rétablir un accès au compte prétendument interrompu

La victime reçoit ensuite un lien menant vers une fausse page de connexion Microsoft. Les domaines malveillants peuvent associer le nom de l’employeur à un vocabulaire lié à l’authentification, selon des schémas tels que company[.]add-passkey[.]com.

La campagne peut utiliser un système de phishing adversary-in-the-middle, ou AiTM, pour intercepter les identifiants et les jetons de session authentifiés. Elle peut également détourner l’authentification par code d’appareil, en convainquant la victime d’autoriser une session initiée par l’attaquant depuis un autre emplacement.

Dans un nombre plus restreint de cas, les opérateurs utilisent le compte compromis d’un employé pour contacter un autre membre du personnel. Des messages provenant d’une identité interne familière peuvent rendre la demande d’authentification plus crédible.

Le téléphone lui-même peut rester intact. L’attaque réussit parce que l’utilisateur suit des instructions frauduleuses et effectue une action d’authentification légitime au profit de la mauvaise personne.

Pourquoi le BYOD crée un angle mort dans la surveillance

Les passerelles de messagerie d’entreprise, les plateformes de détection et de réponse sur les terminaux et les contrôles appliqués aux navigateurs gérés peuvent ne jamais voir le leurre initial. L’appel ou le SMS arrive sur un appareil personnel qui n’est pas intégré à l’écosystème de sécurité de l’organisation.

Les enquêteurs se retrouvent ainsi face à un point de départ difficile. Les premiers éléments disponibles peuvent se limiter au récit d’un employé concernant une conversation téléphonique ou un SMS, plutôt qu’à un e-mail conservé, une alerte sur un terminal ou une pièce jointe capturée.

Les équipes d’intervention doivent alors mettre ce signal en relation avec les événements ultérieurs liés aux identités et au cloud. Les données de télémétrie pertinentes comprennent notamment :

  • Des connexions inhabituelles
  • Des tentatives d’authentification par code d’appareil
  • L’utilisation de jetons depuis des emplacements ou des clients inattendus
  • La modification des méthodes d’authentification enregistrées
  • L’enregistrement de nouveaux appareils MFA
  • L’énumération via Microsoft Graph
  • L’accès à SharePoint, OneDrive ou Exchange
  • Des téléchargements répétés de faible volume depuis des référentiels cloud

Après avoir pris le contrôle d’une identité, l’attaquant peut enregistrer un appareil MFA sous son contrôle. Cette étape assure une persistance et peut rendre les accès ultérieurs plus conformes à l’utilisation normale du compte.

Une interdiction générale des dispositifs personnels, ou BYOD, ne suffirait pas à résoudre complètement le problème. La faiblesse se situe principalement dans les processus d’authentification, les autorisations des comptes et la confiance des utilisateurs, et non dans la présence d’un malware sur le téléphone de l’employé.

Microsoft Graph transforme une identité volée en outil de reconnaissance

Après l’authentification, Storm-3032 et Storm-3121 ont été observés utilisant la Microsoft Graph API pour examiner les environnements Microsoft 365. Graph est une interface programmatique standard : les attaquants n’ont donc pas besoin d’installer d’outils de reconnaissance sur le réseau de l’entreprise.

Selon les autorisations de l’identité compromise, les requêtes Graph peuvent révéler :

  • Des utilisateurs et des groupes
  • Des sites SharePoint
  • Des applications et d’autres ressources
  • Des emplacements de contenu
  • Des droits d’accès et des relations d’autorisation
  • D’autres détails de configuration de Microsoft 365

Les requêtes adressées à des points de terminaison tels que /users, /groups et /sites ne sont pas intrinsèquement malveillantes. Les entreprises et les applications approuvées les utilisent régulièrement, ce qui limite la valeur des alertes fondées sur un seul appel d’API.

C’est le comportement d’ensemble qui compte, davantage que le point de terminaison.

Un utilisateur ou une application qui interroge soudainement de nombreuses parties de l’environnement, suit une séquence inhabituelle de requêtes d’énumération ou associe des opérations de reconnaissance à une activité d’authentification suspecte doit faire l’objet d’une investigation. Les références comportementales doivent tenir compte du rôle de chaque identité : une activité Graph normale pour un compte d’automatisation peut être très inhabituelle pour un cadre dirigeant.

Les attaquants utilisent cet inventaire pour identifier les fichiers, messages et chemins d’accès de valeur. Microsoft a observé des vols de données depuis SharePoint, OneDrive et Exchange, ainsi que depuis d’autres référentiels Microsoft 365.

L’exfiltration est conçue pour rester discrète. Plutôt que de télécharger une archive volumineuse en une seule opération, les acteurs récupèrent régulièrement de petits lots sur une période prolongée. Cette méthode peut contourner les seuils axés sur un volume de transfert soudain tout en se fondant dans l’utilisation habituelle du cloud.

Des courtiers en accès peuvent remettre les comptes à des groupes d’extorsion

Microsoft estime que les opérateurs pourraient vendre ou transférer les accès obtenus à des groupes d’extorsion actifs en aval, notamment ShinyHunters. Toutefois, aucune compromission connue d’une entreprise n’a été directement attribuée à l’une ou l’autre de ces campagnes d’accès initial.

Cette distinction limite les conclusions qui peuvent actuellement être tirées. L’activité observée établit une voie viable vers la reconnaissance, le maintien de l’accès et le vol de données, mais elle ne prouve pas que Storm-3032 ou Storm-3121 soit à l’origine d’une intrusion particulière connue du public.

L’impact potentiel pour les entreprises reste considérable. Une identité compromise d’administrateur ou de cadre dirigeant pourrait exposer des communications internes, des documents sensibles, des relations organisationnelles et des configurations de sécurité. Cet accès pourrait également faciliter une extorsion ultérieure si les informations volées étaient utilisées pour faire pression sur l’entreprise victime.

Il ne s’agit pas d’une vulnérabilité logicielle. Aucun CVE, aucune version de produit affectée, aucun correctif de sécurité ni aucune échéance de la liste CISA Known Exploited Vulnerabilities n’y sont associés. La campagne exploite l’ingénierie sociale, des fonctions d’authentification légitimes, des autorisations excessives et des lacunes dans la surveillance du cloud.

Le rapport consacré aux conclusions de Microsoft décrit ces campagnes comme une menace visant la couche des identités, plutôt qu’une compromission nécessitant le contrôle d’un terminal de l’entreprise.

Les défenses doivent suivre l’identité sur les appareils et les services cloud

La principale recommandation de Microsoft consiste à exiger une MFA résistante au phishing pour chaque connexion. Lorsqu’elle est correctement appliquée à l’utilisateur ciblé, elle devrait empêcher cette chaîne d’attaque, au lieu de simplement générer une invite supplémentaire qu’un interlocuteur peut convaincre la victime d’approuver.

Les organisations devraient également bloquer l’authentification par code d’appareil partout où elle ne répond à aucun besoin opérationnel documenté. Si certains processus l’exigent, les politiques Conditional Access doivent limiter les personnes autorisées à utiliser ce flux, les appareils concernés et les conditions applicables.

Les autres mesures prioritaires comprennent :

  1. Réserver les applications sensibles aux appareils gérés. Appliquer ce contrôle lorsque la valeur des données justifie le coût opérationnel.
  2. Réduire les autorisations Microsoft Graph. Les utilisateurs et les applications ne doivent recevoir que les périmètres nécessaires à leurs fonctions.
  3. Surveiller les modifications des méthodes d’authentification. Les nouvelles inscriptions MFA faisant suite à des appels, SMS ou connexions inhabituels doivent être examinées immédiatement.
  4. Corréler les données de télémétrie liées aux identités et au cloud. Les événements liés aux codes d’appareil, l’activité des jetons, les requêtes Graph et les téléchargements sont plus révélateurs lorsqu’ils sont analysés ensemble.
  5. Détecter les exfiltrations de faible volume. La surveillance doit examiner les accès cumulés et répétés, et pas uniquement les transferts importants effectués en une seule fois.
  6. Réexaminer les comptes privilégiés. Le principe du moindre privilège réduit la quantité d’informations et de contenus accessibles après la compromission d’une seule identité.
  7. Mettre en place un processus de vérification pour le support informatique. Les employés doivent disposer d’un canal de confiance pour confirmer les demandes inattendues concernant les passkeys, la MFA ou le SSO.

La formation doit s’appuyer sur une règle claire : un interlocuteur qui appelle sans avoir été sollicité ne doit jamais demander à un employé de s’authentifier via un lien envoyé sur son téléphone personnel. Les utilisateurs doivent mettre fin à l’échange et contacter le service informatique au moyen d’un numéro interne ou d’un portail connu.

Mettre fin à l’appel ne constitue que la première ligne de défense. Les équipes de sécurité doivent également partir du principe que certains employés suivront les instructions et mettre en place des contrôles capables de contenir la compromission d’identité qui en résulte avant que la reconnaissance via Graph ne se transforme en vol de données durable.

À lire aussi

Sources

Cet article est une réécriture originale fondée sur les sources ci-dessous.

Sujets liésvishingMicrosoft 365Storm-3032téléphone personnelMicrosoft Graphphishing AiTMSharePoint
Retour à l'accueil