Monthly Threat Report octobre 2026

Les comptes que personne ne surveillait

Écrit par Security Lab / 30.10.2026 / Threat Reports

Introduction

Le Rapport mensuel sur les menaces de Hornetsecurity, par Proofpoint, vous propose chaque mois un éclairage sur les tendances en matière de sécurité de M365, les menaces véhiculées par e-mail et l’actualité du secteur de la cybersécurité. Cette édition revient sur les événements du secteur survenus en septembre 2026, jusqu’au 10 octobre. Consacrée à l’actualité et à l’analyse, elle ne comporte pas de sections statistiques ce mois-ci : la place est donnée aux recherches et aux incidents.

Résumé exécutif

Microsoft a d’abord classé la faille SharePoint CVE-2026-65660 comme une vulnérabilité d’usurpation d’identité de gravité moyenne, avec un score CVSS de 6,5. Le 27 août, l’entreprise a réécrit sa propre fiche CVE pour la décrire comme une exécution de code à distance et a relevé le score à 8,8. Les attaques ont commencé le 24 septembre. Le 25 septembre, la CISA l’a ajoutée à son catalogue des vulnérabilités exploitées connues (KEV), avec un délai de trois jours pour la correction par les agences fédérales.
Le 22 septembre, la Digital Crimes Unit de Microsoft et une coalition de partenaires ont annoncé avoir démantelé le service d’hameçonnage EvilTokens : 50 sites web et plus de 150 domaines associés ont été saisis en vertu d’une ordonnance du tribunal fédéral du district est de Virginie. Ce service par abonnement associait l’hameçonnage par code d’appareil à un assistant d’intelligence artificielle (IA) chargé de trier les boîtes mail dérobées. Depuis février, il avait ciblé plus de 12 000 boîtes de réception dans plus de 10 000 organisations.
· Previdian a signalé des tentatives d’exploitation de la faille de lecture de fichiers Atlassian CVE-2026-21589 (CVSS v4.0 : 9,3) moins de deux heures après la publication d’une preuve de concept. La lecture de fichiers ne nécessite aucune authentification et, lorsque Jira s’appuie sur Crowd, les fichiers concernés peuvent contenir des identifiants Crowd en clair.
Proofpoint a suivi une campagne de pulvérisation de mots de passe visant 5 714 comptes Microsoft 365 répartis dans 28 tenants. Sept comptes ont été compromis ; tous étaient des comptes fonctionnels auxquels aucun utilisateur ne s’était connecté auparavant. Selon Proofpoint, chacun utilisait encore son mot de passe initial ou un mot de passe tout aussi facile à deviner, et aucun n’avait l’authentification multifacteur (MFA) imposée.

Panorama des menaces

Sept comptes, et pas une seule personne

Le 22 septembre, Proofpoint a publié une analyse d’une campagne de pulvérisation de mots de passe qu’il suit sous le nom UNK_CondorFiltration. Du 21 juillet au 16 août, celle-ci a visé des tenants Microsoft 365 en Amérique latine, presque tous chiliens. Bilan : 32 825 événements d’authentification, 5 714 comptes uniques, 28 tenants, 1 487 adresses sources sur AWS EC2 et sept comptes compromis.

Les sept comptes compromis ne présentaient toujours aucune session utilisateur légitime antérieure dans la télémétrie de Proofpoint. C’étaient des comptes fonctionnels, affectés à une file de tickets, une caisse ou au traitement des paiements fournisseurs. D’après Proofpoint, chacun conservait le mot de passe défini à sa création, ou un mot de passe tout aussi facile à deviner. Aucun n’avait la MFA imposée. Six comptes sont tombés à sept minutes d’intervalle. La même campagne n’a produit aucun résultat que Proofpoint puisse confirmer contre les comptes du personnel, dont les titulaires doivent changer leur mot de passe.

L’automatisation a rendu les tentatives presque gratuites. Melvin Langvik a conçu TeamFiltration comme outil de test d’intrusion pour Microsoft 365. L’outil vérifie qu’une adresse existe en interrogeant l’API Teams, à environ 300 requêtes par seconde, sans jamais déclencher de verrouillage. Le trafic de pulvérisation passe d’une région AWS à l’autre via FireProx : c’est ainsi que la campagne a utilisé 1 487 adresses et gardé une longueur d’avance sur les listes de blocage IP. Une fois un mot de passe trouvé, l’outil peut récupérer les e-mails et les fichiers de façon autonome. Proofpoint précise toutefois que les journaux de connexion ne prouvent pas, à eux seuls, qu’une donnée a été exfiltrée.

Les sept compromissions ont eu lieu les 14 et 15 août, lors de la dernière vague de la campagne, contre un grand distributeur chilien qui représentait 78,3 % des événements observés. Dans le cas détaillé par Proofpoint, l’opérateur est passé à une infrastructure VPN allemande et a tenté de se connecter au VPN de l’entreprise victime moins d’une minute plus tard ; la MFA ou l’accès conditionnel l’en a empêché. Des sessions Azure Portal et SharePoint Online ont suivi. Environ 25 minutes après la première connexion, une requête visant à obtenir un jeton Microsoft Graph a été émise. L’ouverture d’Azure Portal a invité l’attaquant à enregistrer un moyen MFA, signe le plus clair qu’aucun n’était configuré.

Pourquoi c’est important

Sept comptes sur 5 714, c’est un faible taux de réussite, et chaque succès reposait sur une exception. Les sept appartenaient à la même organisation : cela révèle une pratique de provisionnement dans un seul tenant, et non une tendance mesurée dans les 28. Cette pratique est toutefois courante, ce qui rend le constat généralisable. Les contrôles conçus pour protéger une personne perturbent souvent les tâches planifiées ; l’exception accordée pour les faire fonctionner survit à la personne qui l’a demandée, et le compte conserve toutes les autorisations dont il a eu besoin au fil du temps.

Ainsi, « aucune connexion interactive depuis 90 jours » ne signifie pas qu’un compte est inactif. Cette description peut tout aussi bien correspondre à un compte qui fait exactement son travail, avec un identifiant inchangé depuis son provisionnement et en dehors de toutes les règles appliquées au personnel.

La page de connexion est bien réelle, mais pas la session

Le 1er octobre, nous avons publié une analyse d’EvilTokens et de l’hameçonnage par code d’appareil, technique utilisée par la plateforme dont Microsoft avait annoncé le démantèlement neuf jours plus tôt. Notre édition d’août décrivait déjà ce procédé utilisé par un kit d’hameçonnage isolé. En septembre, il était proposé avec une grille tarifaire.

Le protocole OAuth inclut un flux d’autorisation par appareil pour les équipements sur lesquels il est difficile, voire impossible, de saisir un mot de passe, comme le matériel de salle de réunion. Un code s’affiche à l’écran ; une personne le saisit dans un navigateur sur son téléphone ou son ordinateur, puis le jeton est transmis à l’appareil. L’hameçonnage par code d’appareil ne change qu’une chose : qui reçoit ce jeton. L’attaquant lance le flux, un leurre aux couleurs d’une entreprise dirige la victime vers une page qui génère un code actif, puis la victime le saisit sur la véritable page de connexion Microsoft, hxxps://microsoft[.]com/devicelogin, et valide la MFA si elle y est invitée. Le jeton arrive dans la session de l’attaquant, qui peut alors lire les e-mails, créer des règles de boîte de réception et cartographier l’organisation via Microsoft Graph.

Pourquoi c’est important

Rien n’est usurpé ici. Le domaine appartient à Microsoft, le certificat est valide et le titulaire légitime satisfait lui-même au second facteur, pour une session qu’il n’a jamais lancée. Une décennie de conseils invitant à vérifier la barre d’adresse ne sert plus à rien face à cette attaque.

En août, un seul kit proposait 34 modèles de leurres. En septembre, un abonnement et un canal d’assistance ont élargi l’accès à des acheteurs qui n’auraient jamais pu créer un tel outil.

Le contrôle à mettre en place reste le même. L’accès conditionnel d’Entra ID peut restreindre le flux de code d’appareil ; une politique bien conçue repose sur une liste d’autorisation : recenser les appareils qui en ont besoin, leur appliquer une politique dédiée et bloquer le flux partout ailleurs. Pour la plupart des organisations, cette liste est courte ; pour certaines, elle est vide.

Incidents majeurs et actualité du secteur

Microsoft et ses partenaires mettent EvilTokens hors ligne

Le 22 septembre, la Digital Crimes Unit (DCU) de Microsoft a annoncé avoir démantelé le service EvilTokens en vertu d’une décision du tribunal fédéral des États-Unis pour le district est de Virginie. Health-ISAC était co-demandeur. L’opération a permis de saisir 50 sites web et de neutraliser plus de 150 domaines associés. L’analyse de Microsoft Threat Intelligence détaille les aspects techniques ; Bleeping Computer et The Hacker News ont également couvert l’opération. Cloudflare, Coinbase, OpenAI, Railway, SpyCloud, The Shadowserver Foundation et TRM Labs y ont contribué.

Le service a été mis en vente sur Telegram en février 2026. Microsoft indique un tarif initial de 1 500 dollars, auquel s’ajoutent 500 dollars par mois, ainsi que des options payantes comme un redirecteur antibot et des outils d’envoi massif d’e-mails. Le kit de base proposait 44 thèmes de leurres : demandes de signature électronique, services cloud Microsoft et tiers, factures, alertes de messagerie vocale et notifications eFax. Les liens transitaient par des sites compromis mais par ailleurs légitimes, avant d’aboutir à des services d’hébergement sans serveur auxquels les filtres de réputation font souvent confiance, principalement Vercel (hxxps://*[.]vercel[.]app), Cloudflare Workers (hxxps://*[.]workers[.]dev) et AWS Lambda.

Les clients payaient surtout pour les outils d’IA. Avant une campagne, un assistant personnalisait les e-mails en fonction d’une cible précise. Après une compromission, un chatbot résumait et traduisait les messages de la victime, puis répondait aux premières questions d’un fraudeur : quels échanges concernent de l’argent, qui peut autoriser un paiement, quelles factures fournisseurs restent dues et à qui emprunter le nom.

Microsoft dénombre plus de 12 000 boîtes de réception dans plus de 10 000 organisations. De son côté, SpyCloud a récupéré des données d’hameçonnage concernant 8 708 comptes répartis sur 6 585 domaines d’entreprise dans 79 pays. Coinbase a retracé environ 1,1 million de dollars de paiements via quatre adresses Tron : cela mesure les revenus des opérateurs, et non les pertes des victimes. Le 11 septembre, des agents du Metropolitan Police Service ont interpellé à Londres deux opérateurs présumés, âgés de 32 et 38 ans. Tous deux ont été remis en liberté sous caution pendant la poursuite de l’enquête.

Pourquoi c’est important

Microsoft décrit le démantèlement comme une neutralisation de l’infrastructure et reconnaît que le modèle économique lui survivra. Pour 1 500 dollars et un abonnement mensuel, un client sans compétence particulière pouvait acheter une technique qui contourne l’inspection des URL et résiste à la MFA, avec en plus l’automatisation de la reconnaissance des boîtes mail. Notre analyse d’août sur l’accélération des cybermenaces par l’IA avançait que, à court terme, l’IA aurait surtout un effet économique sur les attaques. Pour la deuxième édition consécutive, cette hypothèse s’est vérifiée dans une opération réelle. Déterminer qui approuve les factures était autrefois la partie humaine, lente et coûteuse de la fraude au président. Ici, cette tâche était automatisée.

Une faille SharePoint d’abord classée comme usurpation d’identité, puis requalifiée en exécution de code

CVE-2026-65660 a été publiée dans les mises à jour Microsoft du 11 août comme une faille d’usurpation d’identité, avec un score CVSS de 6,5. Elle avait été signalée par Dinh Ho Anh Khoa, de Viettel Cyber Security. Le 27 août, Microsoft a modifié sa propre fiche CVE pour décrire une exécution de code à distance et a relevé le score à 8,8. La classification d’injection de code (CWE-94) figurait depuis le début dans la fiche, accolée à une description qui parlait d’usurpation d’identité. Les produits concernés sont SharePoint Enterprise Server 2016, SharePoint Server 2019 et SharePoint Server Subscription Edition.

La faille se trouve dans SafeControls, la liste que SharePoint consulte pour déterminer quels contrôles côté serveur peuvent être chargés. Lorsque ToolPane régénère une directive Register, un guillemet dans la valeur d’un attribut n’est pas échappé. Une valeur spécialement conçue peut donc fermer prématurément l’attribut et injecter ses propres directives. SharePoint a déjà validé les types lorsque ces directives supplémentaires apparaissent, mais n’a pas encore instancié le contrôle ; elles peuvent donc enregistrer n’importe quelle classe .NET. XamlServices.Parse() transforme ensuite cette étape en désérialisation et en exécution de code.

La charge utile de Viettel est un webshell entièrement conservé en mémoire. Selon le chercheur, d’autres techniques de désérialisation échouent généralement à cause des permissions du registre, contrairement à celle-ci. L’attaquant doit être connecté, mais un compte à faibles privilèges suffit. Khoa a également montré une voie sans authentification qui combine cette faille avec un contournement d’authentification corrigé auparavant par Microsoft. Elle ne fonctionne que sur les sites qui autorisent l’accès anonyme aux pages.

L’exploitation a commencé après la publication. SecurityWeek a rapporté que Previdian avait enregistré les premières tentatives le 24 septembre, puis des tentatives de déploiement de webshell le lendemain. Ce calendrier correspond à l’analyse technique de Viettel, couverte par The Hacker News avant le début des attaques. Le 25 septembre, Microsoft a modifié son avis pour confirmer l’exploitation. Le même jour, la CISA a ajouté la faille à son catalogue KEV, avec un bogue MikroTik RouterOS, CVE-2026-67279 ; la directive opérationnelle contraignante 26-04 accordait aux agences fédérales jusqu’au 28 septembre pour corriger les failles. Elle leur demandait également de déterminer si elles avaient été compromises avant l’application du correctif.

Pourquoi c’est important

C’est la deuxième édition consécutive dans laquelle une faille SharePoint sur site fait l’objet d’une exploitation active. Le mois dernier, il s’agissait de CVE-2026-55040 ; les attaquants avaient également testé sa combinaison avec CVE-2026-63520.

La requalification a des conséquences qui dépassent la faille elle-même. En août, une organisation qui hiérarchisait les correctifs par niveau de gravité pouvait reléguer une faille d’usurpation notée 6,5 en bas de la file : une décision défendable que la mise à jour du 27 août a invalidée, quatre semaines avant les premières attaques. La modification a été apportée à une fiche déjà publiée par Microsoft ; un scanner ou un ticket ayant enregistré le score 6,5 lors de sa première ingestion n’avait aucune raison de la consulter à nouveau. La gravité peut changer après une première évaluation : le processus de correction doit donc détecter toute modification de la fiche associée.

Comme l’exploitation a commencé avant l’inscription au catalogue KEV, la mise à jour d’août corrige la faille, mais ne dit pas si un attaquant était déjà passé par là. La CISA demande aux agences fédérales de vérifier ; le reste d’entre nous devrait appliquer la même exigence.

Deux heures entre la preuve de concept et le trafic sur un honeypot

Le 5 octobre, Atlassian a divulgué CVE-2026-21589, une faille de lecture de fichiers sans authentification notée 9,3 selon CVSS v4.0. Elle concerne huit produits auto-hébergés : les éditions Data Center de Jira Software, Jira Service Management, Confluence, Bitbucket, Bamboo et Crowd, ainsi que Crucible et Fisheye. Une bibliothèque commune aux huit produits interprète deux deux-points dans un chemin de requête comme une barre oblique. Cela suffit à sortir des points d’accès aux ressources des extensions et à atteindre n’importe quel fichier de la racine web. Les listes de répertoires restent désactivées : l’attaquant doit donc connaître à l’avance le nom et l’emplacement du fichier, une protection moins solide qu’il n’y paraît.

Le 6 octobre, watchTowr a publié une analyse technique accompagnée d’un code d’exploitation fonctionnel. Previdian a indiqué à Bleeping Computer que ses honeypots avaient commencé à enregistrer des tentatives moins de deux heures plus tard, depuis les adresses 38.60.157[.]86, 146.70.187[.]234 et 159.26.119[.]225. Un modèle Nuclei est ensuite apparu. Le 8 octobre, selon SecurityWeek, Previdian avait comptabilisé 190 tentatives provenant de 32 adresses dans 10 pays. Ces deux chiffres proviennent uniquement de Previdian. La CISA a ajouté la faille au catalogue KEV le 15 octobre.

Pourquoi c’est important

Notre édition de septembre prédisait que le délai entre la publication d’un code d’exploitation public et l’exploitation réelle continuerait de se réduire. En août, des opérateurs de honeypots avaient repéré dans le trafic la preuve de concept SharePoint de Rapid7 dès le lendemain ; ici, Previdian a signalé des tentatives en moins de deux heures. Les observateurs n’ayant pas surveillé les mêmes produits, il faut voir ces chiffres comme une tendance, pas comme une comparaison directe.

Deux heures ne suffisent pas pour réunir un comité de changement, prévenir les utilisateurs d’une maintenance ou laisser un correctif en observation dans un environnement de préproduction. Pour un logiciel exposé à Internet, la première réponse à une faille critique sans authentification doit être une mesure de protection au niveau de la périphérie, déployable en quelques minutes ; le correctif peut suivre son propre calendrier. Atlassian a fourni des recommandations pour les WAF et les serveurs mandataires avec ses mises à jour, donnant ainsi aux défenseurs une première mesure à appliquer.

Prévisions pour les prochains mois

Les comptes de service et comptes fonctionnels sans responsable identifié deviendront une porte d’accès initiale dans une part croissante des incidents M365. Les exceptions qui permettent à l’automatisation de fonctionner sont inscrites dans les règles, et personne n’est responsable de ces comptes. Nous nous attendons à davantage de rapports d’incident où l’identité compromise n’avait aucun propriétaire humain enregistré.
L’hameçonnage par code d’appareil et par consentement survivra au démantèlement d’EvilTokens. La technique ne dépend d’aucune plateforme unique et Microsoft s’attend lui-même à ce que le modèle perdure au-delà de l’infrastructure saisie. Nous prévoyons l’apparition de services successeurs dans les deux prochains trimestres, avec le tri des boîtes mail comme fonctionnalité standard.
Le délai entre la publication d’un code d’exploitation et le balayage opportuniste continuera de se réduire jusqu’à atteindre la limite imposée par l’automatisation. Les deux heures observées ce mois-ci concernaient une faille qui ne nécessitait ni authentification ni charge utile complexe ; le plancher pratique dépend de la vitesse à laquelle les infrastructures de balayage peuvent être redirigées.
Les usurpations d’identité liées à l’expédition et au commerce de détail vont se multiplier en novembre et décembre, comme à chaque quatrième trimestre, avec des leurres générés pour chaque destinataire à partir de kits plutôt que de modèles réutilisés. Cela élimine les répétitions qui facilitaient le filtrage des campagnes saisonnières et l’apprentissage des signes d’alerte par les utilisateurs.

Recommandations du mois

Recensez chaque identité non humaine de votre tenant et attribuez-lui un responsable nominatif. Renouvelez les identifiants des comptes fonctionnels et de service, imposez la MFA ou migrez-les vers des identités de charge de travail avec authentification par certificat, et examinez de près tout historique de connexion vide. 365 Permission Manager indique les ressources que ces comptes peuvent atteindre dans Teams, SharePoint et OneDrive.
Dans l’accès conditionnel d’Entra ID, limitez le flux OAuth par code d’appareil aux appareils qui en ont besoin et bloquez-le partout ailleurs. Établissez la liste d’autorisation à partir de l’inventaire matériel. Déclenchez ensuite une alerte lorsqu’une connexion réussie est suivie de l’ajout d’une méthode d’authentification, d’une nouvelle règle de boîte de réception ou de l’enregistrement d’un appareil inconnu ; corrélez ces trois événements en un seul signal, car chacun pris isolément peut sembler anodin.
Appliquez aux serveurs SharePoint sur site les correctifs disponibles au niveau d’août et vérifiez chaque hôte individuellement ; recherchez ensuite les signes d’activité antérieure au correctif. Sur les sites exposés à Internet, vérifiez l’accès anonyme aux pages, les assemblages enregistrés inattendus et les traces de webshell. Réévaluez également les éléments en attente dont le niveau de gravité attribué par l’éditeur a changé depuis votre première analyse.
Formez les utilisateurs aux leurres par code d’appareil, où la barre d’adresse est correcte. La consigne doit être concrète : n’approuver une demande de connexion sur un appareil que si l’utilisateur l’a lui-même déclenchée quelques secondes auparavant, sur un appareil présent devant lui. La sensibilisation à la sécurité permet d’ancrer ce réflexe.

À propos d’Hornetsecurity

Hornetsecurity est l’un des principaux fournisseurs mondiaux de solutions de sécurité, de conformité, de sauvegarde et de sensibilisation à la sécurité basées sur le cloud de nouvelle génération, qui aident les entreprises et les organisations de toutes tailles dans le monde entier. Son produit phare, 365 Total Protection, est la solution de sécurité en cloud pour Microsoft 365 la plus complète du marché. Poussée par l’innovation et l’excellence en matière de cybersécurité, Hornetsecurity construit un avenir numérique plus sûr et des cultures de sécurité durables grâce à son portefeuille primé. Hornetsecurity est présent dans plus de 120 pays grâce à son réseau de distribution international, de plus de 12 000 partenaires de distribution et MSP. Ses services haut de gamme sont utilisés par plus de 125 000 clients. Pour plus d’informations, visitez le site www.hornetsecurity.com.