En quelques jours, trois éditeurs utilisés par des PME et des ETI ont vu leur canal de distribution détourné. Aucun de ces incidents ne reposait sur une faille non corrigée chez la victime : ce sont précisément les entreprises qui faisaient « bien les choses » qui ont reçu le code malveillant. C’est ce paradoxe qu’il faut comprendre pour ajuster votre gestion des correctifs sans la casser.

Trois mises à jour piégées en une semaine, un même schéma

Rank Math PRO : une extension WordPress piégée pendant onze heures

L’éditeur de l’extension SEO Rank Math a confirmé que la version PRO 3.0.123, téléchargée depuis son site officiel entre le 15 octobre à 20 h 02 UTC et le 16 octobre à 7 h 12 UTC, contenait un logiciel malveillant (avis de l’éditeur). Une fois l’extension activée, la porte dérobée se recrée à chaque visite du site, crée des comptes administrateurs et expose les identifiants de base de données et les clés d’API accessibles au serveur web. La version gratuite publiée sur WordPress.org n’est pas concernée, et la version 3.0.124 est saine.

AOMEI Backupper : un logiciel de sauvegarde qui installe une porte dérobée

Les équipes de Google Threat Intelligence et de ManageEngine ont documenté une campagne dans laquelle les fichiers de configuration du système de notification d’AOMEI Backupper ont été modifiés sur les serveurs de l’éditeur pendant des fenêtres de cinq à dix minutes seulement (rapport Google). Les attaquants avaient aussi modifié la somme de contrôle attendue : le fichier malveillant passait donc la vérification d’intégrité du logiciel. Résultat : un outil de prise en main à distance légitime, détourné en porte dérobée, installé sans aucune action de l’utilisateur.

ConnectWise Cloud Backup : la confiance accordée à une application SaaS

Troisième variante, sans aucun fichier téléchargé : un identifiant appartenant au service de sauvegarde Microsoft 365 de ConnectWise a été volé puis utilisé pour accéder aux tenants de ses clients. Le service disposait de permissions très élevées, et Huntress a observé des connexions non autorisées dans 162 tenants (The Record). ConnectWise a suspendu le service et révoqué les certificats concernés.

Le point commun de ces trois cas n’est pas une technologie, c’est un canal de confiance : un site officiel, un serveur de mise à jour, une application à laquelle vous avez donné votre accord. C’est la définition même d’une attaque supply chain.

Pourquoi arrêter de patcher serait la pire réponse

La tentation est compréhensible : si la mise à jour elle-même peut être piégée, pourquoi se presser ? Parce que les deux risques ne sont pas du même ordre. Les fenêtres de compromission décrites plus haut se comptent en minutes ou en heures, puis l’éditeur publie une version saine. Une faille connue et non corrigée, elle, reste exploitable pendant des semaines ou des mois, et les attaquants industrialisent désormais l’exploitation en quelques heures après la publication d’un correctif. Nous avons détaillé ce phénomène dans notre article sur la réduction de la fenêtre de patch.

Renoncer aux correctifs, ou les repousser de plusieurs semaines « par prudence », revient donc à échanger un risque rare et bref contre un risque fréquent et durable. La bonne question n’est pas « faut-il patcher ?», mais « quelles mises à jour doivent passer tout de suite, et lesquelles peuvent attendre deux jours ? ».

Ce qu’une mise à jour piégée change dans votre gestion des correctifs

Distinguer les correctifs de sécurité des mises à jour fonctionnelles

Un correctif qui ferme une faille activement exploitée doit être appliqué sans délai, quel que soit l’éditeur. En revanche, une nouvelle version d’extension WordPress, d’utilitaire de bureau ou d’outil de sauvegarde qui n’apporte que des fonctionnalités peut attendre 48 heures. Ce court délai suffit souvent à laisser la communauté repérer une version piégée : dans le cas de Rank Math, la version compromise a été retirée en moins d’une demi-journée. Concrètement, désactivez la mise à jour automatique des extensions non critiques et regroupez-les dans une fenêtre hebdomadaire.

Réduire ce que chaque outil tiers peut faire

L’incident ConnectWise rappelle qu’une application SaaS connectée à Microsoft 365 avec des droits d’écriture sur l’annuaire est, de fait, un administrateur supplémentaire. Plus vous accordez de permissions, plus la compromission de l’éditeur devient la vôtre. Notre méthode pour auditer les applications tierces Microsoft 365 permet de faire ce tri en une demi-journée.

Savoir en une heure si vous êtes concerné

Quand un éditeur annonce une compromission, la première question est simple : utilisons-nous ce logiciel, et dans quelle version ? Une PME sans inventaire à jour met souvent plusieurs jours à répondre, pendant lesquels la porte dérobée reste active. Un inventaire des logiciels installés, des extensions de vos sites et des applications connectées à vos comptes cloud est la condition pour réagir vite.

Détecter ce que la signature ne voit pas

Le cas AOMEI le montre : une mise à jour piégée peut porter une signature valide et passer les contrôles d’intégrité. La détection ne peut donc pas reposer uniquement sur la provenance du fichier. Elle repose sur le comportement après installation :

• un logiciel de sauvegarde qui installe un outil de prise en main à distance ;
• un compte administrateur créé sur votre site WordPress sans demande interne ;
• une nouvelle tâche planifiée ou un fichier modifié dans un répertoire système ;
• une connexion sortante vers un domaine jamais vu auparavant ;
• une application cloud qui s’attribue un rôle d’administrateur.

C’est ce type de signal faible, isolé dans le bruit quotidien, qui permet de couper l’accès avant que l’attaquant ne s’installe durablement. ManageEngine a d’ailleurs repéré la campagne AOMEI parce qu’un outil de sécurité a remarqué une installation inhabituelle (rapport ManageEngine). Autre leçon : corriger le serveur de l’éditeur stoppe les nouvelles infections, mais ne retire pas la porte dérobée des machines déjà touchées. Le nettoyage reste de votre côté.

Que faire maintenant

1. Vérifiez dès aujourd’hui si vous utilisez Rank Math PRO, AOMEI Backupper ou ConnectWise Cloud Backup, et appliquez la procédure de l’éditeur si c’est le cas.
2. Activez une alerte sur toute création de compte administrateur, sur vos sites WordPress comme dans votre annuaire Microsoft 365.
3. Révoquez les autorisations des applications cloud que vous n’utilisez plus et réduisez celles des autres au strict nécessaire.
4. Appliquez un délai de 48 heures aux mises à jour fonctionnelles des extensions et utilitaires, jamais aux correctifs de failles exploitées.
5. Testez la restauration d’une sauvegarde hors ligne de votre site et de vos serveurs clés, pour pouvoir revenir à un état sain.

Une mise à jour piégée ne se voit pas à l’installation, mais à ce qu’elle fait ensuite : c’est exactement ce que repère une surveillance continue, avec notre SOC managé 24/7 pour PME et ETI.

Ce qu’il faut retenir

• Une mise à jour piégée passe par le canal officiel de l’éditeur, parfois avec une signature valide.
• Continuer à patcher vite reste indispensable : une faille connue expose bien plus longtemps qu’une version piégée.
• Seules les mises à jour fonctionnelles non critiques méritent un délai court de 48 heures.
• Les permissions accordées aux applications SaaS transforment la compromission d’un éditeur en la vôtre.
• La détection repose sur le comportement après installation, pas sur la provenance du fichier.

Sources

• Rank Math — Rank Math PRO 3.0.123 security incident
• Wordfence — Rank Math SEO PRO 3.0.123 malware
• Google Threat Intelligence — Investigating ephemeral supply chain tampering
• ManageEngine Threat Analysis Lab — AOMEI Backupper supply chain compromise
• The Record — ConnectWise suspends Cloud Backup service after supply chain attack

Ce que permet la faille Wi-Fi Broadcom sur le WPS

Le chercheur belge Quentin Kaiser a présenté le 16 octobre 2026, à la conférence Hexacon à Paris, une vulnérabilité dans l’implémentation propriétaire du Wi-Fi fournie par Broadcom aux fabricants de box et de routeurs. Le défaut se trouve dans le code qui gère le WPS, la fonction d’appairage « par bouton » que l’on trouve sur la plupart des box. Selon sa publication détaillée, la faille se déclenche à distance par simples trames Wi-Fi, sans clé réseau et sans terminer un appairage WPS normal.

Concrètement, l’attaquant exécute son propre code sur l’équipement. Dans la démonstration, ce code lit le mot de passe Wi-Fi stocké dans la mémoire de la box, le renvoie à l’attaquant, qui rejoint ensuite le réseau comme n’importe quel poste légitime. Une seconde démonstration ouvre un accès complet à distance sur la box, sans serveur de commande sur internet : tout passe par les ondes. Le chercheur précise que l’attaque fonctionne à bonne distance, la proximité de l’antenne dans les vidéos n’étant qu’un artifice de laboratoire.

Pourquoi le correctif n’arrive pas

Le bug date d’au moins 2010. Un correctif partiel a été publié discrètement en 2018, puis Broadcom a recommandé aux fabricants de migrer vers une autre pile logicielle. Résultat, d’après les supports de la conférence : sur les puces fonctionnant sous eCos (BCM3380, BCM3383, BCM33834), la faille ne sera jamais corrigée ; sur les puces sous Linux (BCM3390, BCM65xx, BCM68xx), tout dépend de la bonne volonté de chaque fabricant. Broadcom a refusé d’attribuer un identifiant CVE, ce qui signifie qu’aucun scanner de vulnérabilités ne la signalera.

Le chercheur a confirmé l’exploitation sur trois des quatre grands opérateurs belges et estime à plus de 1,5 million le nombre de box potentiellement exposées dans ce seul pays. Au 15 octobre 2026, aucun des modèles testés n’avait reçu de correctif.

Les box internet des PME sont-elles concernées ?

À ce jour, les modèles confirmés sont des box d’opérateurs belges. Mais les fabricants concernés vendent dans de nombreux pays, et le chercheur évoque « des dizaines de fabricants et des centaines de produits ». Aucun modèle distribué en France n’a été confirmé ou écarté publiquement : l’absence d’information n’est pas une preuve d’immunité.

Le risque est réel pour une PME pour trois raisons :

• La box sert souvent de point d’accès Wi-Fi principal dans les agences, les petits sites et les bureaux partagés, sur le même réseau que les postes et les serveurs.
• Personne ne surveille son micrologiciel : elle est gérée par l’opérateur, rarement inventoriée, et n’envoie aucun journal à votre supervision.
• L’attaque ne laisse pas de trace sur internet, puisqu’elle passe par les ondes. Une box compromise peut intercepter ou rediriger le trafic sans éveiller de soupçon.

Ce type d’attaque de proximité n’a rien de théorique : en 2024, Volexity a documenté un groupe d’espionnage qui avait pénétré une organisation en rebondissant par le Wi-Fi d’un bâtiment voisin. Les cibles prioritaires sont les entreprises situées en rez-de-chaussée, en centre d’affaires, en zone commerciale ou à proximité de lieux publics.

Que faire maintenant face à la faille Wi-Fi Broadcom

1. Identifiez le modèle exact de chaque box et point d’accès de vos sites (étiquette, interface d’administration), puis comparez-le à la liste publiée par le chercheur ; votre prestataire peut aussi utiliser son script de détection.
2. Désactivez le WPS sur toutes les box, répéteurs et bornes qui le proposent : le code vulnérable est celui du WPS, et cette fonction n’a aucune utilité en entreprise.
3. Demandez par écrit à votre opérateur ou à votre infogérant si vos modèles utilisent une puce Broadcom concernée, si un correctif est prévu et à quelle date.
4. Coupez le Wi-Fi intégré à la box et confiez la diffusion à des bornes professionnelles maintenues, avec un réseau invités séparé des postes et des serveurs.
5. Planifiez le remplacement des équipements pour lesquels aucun correctif n’est annoncé, en commençant par les sites les plus exposés physiquement.

La désactivation du WPS réduit l’exposition, mais elle ne remplace pas un micrologiciel corrigé : sur certains équipements, l’option de l’interface ne coupe pas forcément tout le code concerné. Les recommandations de l’ANSSI sur les réseaux Wi-Fi vont dans le même sens : cloisonner le Wi-Fi du reste du système d’information et traiter chaque point d’accès comme un équipement à part entière.

Un équipement réseau compromis se repère surtout par ce qu’il fait ensuite : connexions inhabituelles, nouveaux appareils sur le réseau, flux vers l’extérieur. C’est précisément ce que surveille notre SOC managé 24/7 pour PME et ETI.

Pour aller plus loin, relisez notre article sur les routeurs compromis par APT28 et celui consacré aux Wi-Fi publics et DNS pirates.

Ce qu’il faut retenir

• Une faille du WPS de Broadcom permet de prendre le contrôle d’une box à portée Wi-Fi, sans mot de passe.
• Elle existe depuis 2010, n’a pas de CVE et reste sans correctif sur de nombreux modèles.
• Les modèles confirmés sont belges, mais les fabricants concernés vendent dans de nombreux pays.
• Désactiver le WPS et sortir le Wi-Fi de la box sont les deux mesures immédiates.
• Les équipements sans correctif annoncé doivent être remplacés.

Sources

• Quentin Kaiser — One Parser, Two Bugs, Many Routers (publication du chercheur)
• Supports de la conférence Hexacon 2026
• Script de détection et règle YARA (GitHub)
• Volexity — The Nearest Neighbor Attack
• ANSSI — Recommandations de sécurité relatives aux réseaux Wi-Fi

La question n’est pas théorique. Mi-octobre 2026, un attaquant a utilisé le secret d’une application de sauvegarde Microsoft 365 largement déployée par les infogérants, ConnectWise Cloud Backup (ex-SkyKick), pour se connecter directement à des tenants clients. Huntress a recensé au moins 162 tenants compromis dans son seul périmètre, et Todyl rappelle que ces connexions, faites par script au nom de l’application, échappaient totalement à la MFA. Un administrateur a même reçu une alerte pour une application qu’il n’utilisait plus depuis des années.

Pourquoi une application tierce échappe à vos protections

Quand vous connectez un outil de sauvegarde, d’archivage, de signature ou de CRM à Microsoft 365, vous créez dans votre tenant un principal de service : une identité propre à l’application, avec ses propres autorisations (lire tous les e-mails, écrire dans SharePoint, gérer l’annuaire…). Cette identité s’authentifie avec un secret ou un certificat détenu par l’éditeur, pas avec le compte d’un collaborateur.

Conséquence directe : si l’éditeur se fait voler ce secret, l’attaquant hérite de toutes les autorisations que vous avez accordées un jour, sans phishing, sans MFA et sans alerte de connexion utilisateur. Et ces autorisations ne disparaissent pas quand vous résiliez le service : l’application reste dans votre tenant tant que vous ne la supprimez pas.

Le tutoriel : auditer vos applications tierces Microsoft 365 en 7 étapes

Étape 1 : listez toutes les applications d’entreprise

Dans le centre d’administration Microsoft Entra, ouvrez Applications d’entreprise, puis retirez le filtre par défaut et choisissez le type « Toutes les applications ». Exportez la liste en CSV. Vous obtenez chaque application, son éditeur et sa date de création. Dans une PME de 50 personnes, il n’est pas rare d’en découvrir plusieurs dizaines, dont une bonne partie installée par un ancien prestataire ou par un collaborateur parti.

Étape 2 : repérez les autorisations les plus dangereuses

Pour chaque application, ouvrez l’onglet Autorisations. Distinguez les autorisations « déléguées » (l’application agit au nom d’un utilisateur connecté) des autorisations « d’application » (elle agit seule, sur tout le tenant). Ce sont ces dernières qu’il faut traquer en priorité, en particulier :

• Mail.ReadWrite ou Mail.Read : accès à toutes les boîtes aux lettres ;
• Files.ReadWrite.All et Sites.ReadWrite.All : tout OneDrive et tout SharePoint ;
• Directory.ReadWrite.All et RoleManagement.ReadWrite.Directory : la capacité de modifier l’annuaire et de s’attribuer des rôles d’administration.

Selon BleepingComputer, qui cite Microsoft Threat Intelligence, l’attaquant a vraisemblablement abusé de Directory.ReadWrite.All pour que des applications s’attribuent le rôle d’administrateur Exchange, voire d’administrateur général dans un cas.

Étape 3 : vérifiez qui utilise encore chaque application

Dans Journaux de connexion, ouvrez l’onglet « Connexions de principal de service ». Filtrez sur chaque application de votre liste : une application à hauts privilèges qui ne s’est pas connectée depuis 90 jours est une candidate évidente à la suppression. Croisez avec vos contrats : un service résilié ne doit plus avoir aucune identité dans votre tenant. La documentation Microsoft sur les journaux de connexion détaille les quatre types de connexions disponibles.

Étape 4 : désactivez, puis supprimez les applications inutiles

Procédez en deux temps pour éviter de casser un flux métier oublié. D’abord, dans les Propriétés de l’application, passez « Activé pour la connexion des utilisateurs ? » sur Non : l’application ne peut plus obtenir de jeton. Attendez une à deux semaines. Si personne ne se plaint, supprimez-la. Microsoft documente les deux opérations : désactiver la connexion et supprimer l’application.

Étape 5 : réduisez les droits des applications que vous gardez

Pour chaque application conservée, demandez à l’éditeur la liste minimale des autorisations nécessaires. Un outil de signature électronique n’a pas besoin de lire toutes les boîtes aux lettres ; un CRM n’a pas besoin de modifier l’annuaire. Quand l’éditeur le permet, limitez l’accès à une partie des boîtes (stratégies d’accès aux applications Exchange) ou à certains sites SharePoint plutôt qu’à l’ensemble du tenant. Notez dans un registre, pour chaque application : propriétaire interne, éditeur, autorisations, date de la dernière revue.

Étape 6 : fermez la porte aux nouvelles autorisations non validées

Dans Consentement et autorisations, interdisez aux utilisateurs d’accorder eux-mêmes des droits à des applications, ou limitez-les aux éditeurs vérifiés et aux autorisations à faible impact. Activez ensuite le flux de demande de consentement administrateur : un collaborateur qui veut connecter un outil fait une demande, un administrateur la valide. Les deux réglages sont décrits dans la documentation Microsoft sur le consentement des utilisateurs.

Étape 7 : surveillez ce que font vos applications

L’audit est une photo ; il faut aussi un film. Configurez des alertes sur trois événements : l’ajout d’un secret ou d’un certificat à une application, l’attribution d’un rôle d’administration à un principal de service, et toute connexion d’application depuis une adresse IP inhabituelle. C’est exactement ce qui a permis à certains administrateurs de repérer l’attaque ConnectWise le jour même : une notification Privileged Identity Management signalant qu’une application s’attribuait un rôle Exchange. Planifiez enfin une revue complète tous les six mois.

Le cas particulier des outils de votre infogérant

Les applications les plus puissantes de votre tenant sont souvent celles de votre prestataire informatique : sauvegarde, supervision, RMM, outil de gestion multi-clients. Elles sont aussi les plus attractives pour un attaquant, puisqu’un seul secret volé ouvre des centaines de tenants. Demandez à votre infogérant la liste des applications et des accès qu’il a installés chez vous, les autorisations de chacune, et la façon dont il protège leurs secrets. Côté accès humains, exigez des relations d’administration déléguée granulaires (GDAP), limitées dans le temps et aux seuls rôles utiles, plutôt qu’un accès d’administrateur général permanent.

Ces contrôles prolongent la démarche décrite dans notre article sur l’encadrement des accès de vos prestataires, et complètent la protection contre le phishing par consentement, détaillée dans notre guide sur le consentement OAuth.

Une application qui s’attribue un rôle d’administrateur un vendredi soir ne se remarque que si quelqu’un regarde les journaux en continu : c’est le rôle de notre SOC managé 24/7 pour PME et ETI, qui surveille aussi les identités cloud de votre tenant Microsoft 365.

Ce qu’il faut retenir

• Une application tierce Microsoft 365 s’authentifie avec son propre secret : la MFA de vos utilisateurs ne la protège pas.
• Les autorisations d’application (Mail, Files, Directory) donnent accès à tout le tenant, sans utilisateur connecté.
• Un service résilié laisse son application et ses droits dans votre tenant tant que vous ne la supprimez pas.
• Désactivez avant de supprimer, puis bloquez le consentement des utilisateurs et activez la demande d’approbation.
• Surveillez l’ajout de secrets et l’attribution de rôles aux applications, et revoyez la liste tous les six mois.

Sources

• Huntress — Vendor credential enables unauthorized access
• Todyl — Investigation : accès non autorisé via l’application ConnectWise Cloud Backup
• ConnectWise — Avis de sécurité
• Microsoft Learn — Configurer le consentement des utilisateurs aux applications
• Microsoft Learn — Examiner les applications OAuth à risque

Cette réponse courte ne suffit pourtant pas le jour où la production est arrêtée et où le dirigeant reçoit une demande chiffrée en cryptomonnaie. Ce guide détaille ce que la décision engage réellement, les obligations qui courent dès les premières heures, et ce qui se prépare en amont pour ne jamais avoir à se poser la question sous pression.

Pourquoi payer la rançon ne règle presque jamais le problème

Le guide de l’ANSSI « Attaques par rançongiciels, tous concernés » et la fiche réflexe de Cybermalveillance.gouv.fr convergent : ne payez pas, car vous n’êtes pas certain de récupérer vos données et vous financez directement le groupe criminel. Concrètement, plusieurs risques se cumulent.

• Un déchiffreur partiel ou défaillant : l’outil fourni par l’attaquant est souvent lent, buggé, ou échoue sur les gros fichiers et les bases de données. La restauration reste un chantier de plusieurs jours.
• La double extorsion : la plupart des groupes copient les données avant de les chiffrer. Payer pour le déchiffrement n’empêche pas une publication ou une revente, et la promesse de suppression n’est vérifiable par personne.
• La porte reste ouverte : payer ne supprime ni le compte compromis, ni la porte dérobée, ni la faille d’entrée. Une entreprise qui a payé est identifiée comme solvable et coopérative, donc une cible de choix pour une nouvelle tentative.
• Le risque juridique : certains groupes ou leurs portefeuilles relèvent de régimes de sanctions internationaux. Un paiement peut exposer l’entreprise, ses dirigeants et ses intermédiaires.

Les obligations qui démarrent avant toute décision

Qu’il y ait paiement ou non, plusieurs horloges se déclenchent dès que l’attaque est découverte. Les manquer coûte souvent plus cher que l’incident lui-même.

Déposer plainte dans les 72 heures pour être indemnisé

Depuis la loi n° 2023-22 du 24 janvier 2023 (article 5), une assurance « cyber » ne peut indemniser une victime que si elle a déposé plainte dans les 72 heures suivant la connaissance de l’attaque, comme le rappelle Cybermalveillance.gouv.fr. La plainte se dépose au commissariat, à la gendarmerie ou par écrit au procureur. Ce délai est indépendant de la décision de payer.

Notifier la CNIL si des données personnelles sont touchées

Un rançongiciel qui chiffre ou exfiltre des fichiers clients, RH ou fournisseurs constitue presque toujours une violation de données personnelles. Le RGPD impose une notification à la CNIL dans les 72 heures lorsque la violation présente un risque pour les personnes, et une information des personnes concernées si ce risque est élevé.

Prévenir l’assureur avant toute négociation

La plupart des contrats cyber imposent de déclarer le sinistre rapidement et d’obtenir l’accord de l’assureur avant d’engager des frais, prestataires de réponse à incident compris. Relisez dès aujourd’hui les clauses de votre contrat, et vérifiez les mesures qu’il exige en amont : notre article sur les 8 mesures exigées par les assureurs détaille les plus courantes.

Le négociateur, maillon de confiance à vérifier

Face à une demande de rançon, certaines entreprises font appel à un négociateur spécialisé. La pratique n’est pas illégale en soi, mais elle repose entièrement sur la confiance accordée à cet intermédiaire. Dark Reading revient cette semaine sur des cas où le négociateur mandaté par la victime travaillait en réalité pour l’autre camp.

Pour une PME, la leçon est simple : n’acceptez jamais un intermédiaire trouvé dans l’urgence. Passez par votre assureur, par un prestataire de réponse à incident identifié à l’avance, ou par les dispositifs publics. La plateforme Cybermalveillance.gouv.fr oriente gratuitement vers des prestataires référencés.

Les alternatives au paiement d’une rançon

Ne pas payer ne veut pas dire subir. Trois leviers permettent de reprendre l’activité sans financer l’attaquant.

• Chercher un déchiffreur gratuit : le projet No More Ransom, porté par Europol et des éditeurs de sécurité, publie des outils de déchiffrement pour de nombreuses familles de rançongiciels. Conservez une note de rançon et quelques fichiers chiffrés pour l’identification.
• Restaurer depuis une sauvegarde saine : c’est la seule vraie assurance. Elle suppose une copie hors ligne ou immuable, testée régulièrement, que l’attaquant n’a pas pu atteindre.
• Reconstruire plutôt que nettoyer : un serveur compromis se réinstalle à partir d’une image connue, avec de nouveaux mots de passe. Restaurer des données sur un système encore infecté relance l’incident.

Préparer la décision avant l’attaque

La question « payer ou non » se pose rarement de façon froide. Elle arrive à 6 heures du matin, avec des salariés à l’arrêt et des clients qui appellent. Les entreprises qui s’en sortent le mieux sont celles qui ont tranché à l’avance.

• Une position de principe écrite : la direction formalise qu’elle ne paie pas, sauf circonstances exceptionnelles décidées collégialement avec l’assureur et les conseils juridiques.
• Une cellule de crise nommée : qui décide, qui parle aux salariés, qui contacte l’assureur, la CNIL et les forces de l’ordre. Notre modèle de plan de réponse à incident en une page fournit une trame prête à remplir.
• Des contacts prêts : numéro de l’assureur, prestataire de réponse à incident, gendarmerie ou commissariat, imprimés hors du système d’information.
• Une sauvegarde déjà testée : un test de restauration complet par trimestre transforme un arrêt de plusieurs semaines en reprise de quelques jours.

Que faire maintenant

1. Imprimez la fiche réflexe rançongiciel de Cybermalveillance.gouv.fr et rangez-la avec les contacts d’urgence, hors réseau.
2. Relisez votre contrat cyber : délai de déclaration, accord préalable, prestataires imposés, exclusions liées au paiement.
3. Testez une restauration complète d’un serveur critique depuis votre sauvegarde hors ligne.
4. Formalisez avec la direction une position écrite sur le paiement et la composition de la cellule de crise.

Le meilleur moyen de ne jamais avoir à choisir est de repérer l’intrusion avant le chiffrement, souvent plusieurs jours plus tôt : c’est le rôle de notre SOC managé 24/7 pour PME et ETI, qui surveille vos serveurs et vos postes en continu.

Ce qu’il faut retenir

• Les autorités françaises recommandent de ne pas payer la rançon : aucune garantie de récupération ni de suppression des données.
• La plainte sous 72 heures conditionne l’indemnisation par l’assurance cyber.
• Une violation de données personnelles se notifie à la CNIL sous 72 heures.
• Un négociateur se choisit à l’avance, jamais dans l’urgence.
• Une sauvegarde hors ligne testée reste la seule vraie alternative au paiement.

Sources

• ANSSI — Attaques par rançongiciels, tous concernés
• Cybermalveillance.gouv.fr — Rançongiciel : que faire si votre organisation est victime ?
• CNIL — Notifier une violation de données personnelles
• No More Ransom — outils de déchiffrement gratuits
• Dark Reading — When Your Ransomware Negotiator Works for the Other Side

Ce que permet la faille BeyondTrust Remote Support

BeyondTrust a publié le 15 octobre l’avis BT26-05. D’après l’analyse de Mandiant et du Google Threat Intelligence Group, la vulnérabilité touche toutes les versions supportées jusqu’à la 26.2.3 et autorise des opérations sur les fichiers de l’appliance sans aucune authentification. L’attaquant peut ensuite obtenir le contrôle de l’hôte et accéder à tous les identifiants que l’appliance stocke ou relaie.

C’est là que le risque devient sérieux pour une PME : un outil de prise en main à distance est, par construction, une porte d’entrée vers tous les postes et serveurs qu’il administre. Compromettre l’appliance revient à hériter des droits de votre support informatique.

Un zero-day exploité depuis l’été par un groupe d’espionnage

Mandiant a observé l’exploitation de CVE-2026-102764 dès la fin août 2026, bien avant sa publication, par ARMORY CASTLE, un acteur d’espionnage soupçonné d’être lié à la Chine et déjà connu pour ses attaques contre les équipements de bordure. Une fois dans la place, le groupe a suivi un scénario précis :

• connexion au portail d’administration avec un compte administrateur compromis ;
• élévation des rôles « Jump Item » du compte, de « No Access » à « Administrator », pour un accès permanent aux machines gérées ;
• ouverture de sessions de support vers des postes internes et exfiltration de documents via le transfert de fichiers natif ;
• installation d’un tunnel discret (BARECLAW) et modification de la configuration du proxy de l’appliance pour l’exposer sur Internet ;
• suppression des journaux tout au long de l’intrusion.

Google prévient que ce groupe a l’habitude de lancer une exploitation massive et opportuniste dès qu’une faille qu’il utilisait en secret devient publique. Les prochains jours sont donc les plus exposés.

Êtes-vous concerné par BeyondTrust Remote Support ?

La version SaaS a été corrigée par l’éditeur le 9 octobre : aucune action n’est nécessaire sur l’appliance elle-même, mais la revue des comptes et des identifiants reste recommandée. Les appliances auto-hébergées (virtuelles ou matérielles) doivent être corrigées par vous ou par votre prestataire. Pensez aussi à vos fournisseurs : un infogérant qui vous dépanne via BeyondTrust fait entrer ce risque chez vous, comme nous l’avons détaillé dans notre article sur l’encadrement de l’accès des prestataires.

Le point le plus délicat concerne les appliances déjà compromises. Selon Mandiant, l’attaquant efface les journaux présents sur l’appareil et sa persistance survit à un redémarrage comme à une réinitialisation de configuration. Appliquer le correctif ferme la porte, mais n’expulse pas un intrus déjà installé. C’est pourquoi l’éditeur et Google recommandent de conserver une copie de l’appliance avant toute intervention, de bloquer son adresse publique au pare-feu si un doute existe, puis de la reconstruire à partir d’une image propre plutôt que de tenter un nettoyage.

Enfin, l’ordre des opérations compte : renouveler les mots de passe avant d’avoir corrigé ou reconstruit l’appliance revient à les confier directement à l’attaquant qui la contrôle encore.

Que faire maintenant

1. Identifiez vos instances BeyondTrust Remote Support (ou Bomgar), en SaaS ou auto-hébergées, et leur version ; posez la question par écrit à votre infogérant.
2. Appliquez le correctif BT26-05-RS depuis l’interface /appliance (version 24.3.1 ou ultérieure) ; mettez d’abord à niveau les versions plus anciennes, puis appliquez le correctif.
3. Restreignez l’accès aux interfaces /login et /appliance à vos seules adresses IP d’administration, et activez la double authentification sur le compte Admin intégré.
4. Vérifiez les journaux depuis fin août : rôles « Jump Item » passés à Administrator, nouveaux comptes API, transferts de fichiers inhabituels, interruptions de l’envoi syslog.
5. Renouvelez les identifiants stockés ou saisis via l’appliance après le correctif, et reconstruisez-la à partir d’une image saine si un indice de compromission apparaît.

Ce type d’abus d’un outil d’administration légitime passe sous le radar d’un antivirus classique, comme lors de la faille N-central qui visait les RMM.

Un changement de rôle anormal ou une session de support ouverte à 3 h du matin se détecte et se contient avec une surveillance continue : découvrez notre SOC managé 24/7 pour PME et ETI.

Ce qu’il faut retenir

• CVE-2026-102764 permet de prendre le contrôle d’une appliance BeyondTrust Remote Support sans authentification.
• La faille est exploitée comme zero-day depuis fin août par un groupe d’espionnage.
• Le SaaS est corrigé ; les appliances auto-hébergées doivent recevoir le correctif BT26-05.
• Corriger ne suffit pas : contrôlez les rôles, les journaux et renouvelez les identifiants.
• Interrogez vos prestataires : leur outil de télémaintenance est aussi votre surface d’attaque.

Sources

• BeyondTrust — avis de sécurité BT26-05
• BeyondTrust — recommandations complémentaires BT26-05
• Google Threat Intelligence Group / Mandiant — ARMORY CASTLE Exploits BeyondTrust
• BeyondTrust — activer la double authentification

Le sujet n’a rien de théorique : en une seule journée, la CISA a ajouté à son catalogue des vulnérabilités exploitées une faille de Palo Alto Networks PAN-OS et une faille de Cisco Secure Email Gateway, deux équipements que l’on retrouve en bordure de réseau dans de nombreuses PME et ETI.

Pourquoi un pare-feu compromis survit au correctif

Un pare-feu, une passerelle VPN ou une passerelle de messagerie voient passer tout votre trafic et stockent des secrets précieux : comptes administrateurs, clés de chiffrement, certificats, identifiants VPN des utilisateurs. Un attaquant qui y obtient un accès root n’a pas besoin de rester bruyant : il copie ce dont il a besoin et revient plus tard par la porte d’entrée normale.

L’enquête publiée par Unit 42 sur l’implant PEERSTITCH l’illustre bien. Après avoir exploité une faille de la console FortiManager, les attaquants ont exfiltré les configurations, le matériel cryptographique et les données de plus de 500 pare-feu FortiGate gérés. Ils ont ensuite conservé un accès de long terme, intercepté du trafic et ouvert des sessions VPN. Corriger la console après coup ne changeait rien aux secrets déjà volés.

Cisco le dit explicitement dans son avis sur la faille Secure Email Gateway : une fois l’exécution de commandes en root obtenue, l’attaquant peut effacer ses traces sur l’équipement. D’où la consigne de recouper avec les journaux du pare-feu et du réseau, et pas seulement avec ceux de l’appareil touché.

Les 7 étapes pour vérifier votre pare-feu ou votre VPN

Étape 1 : inventoriez vos équipements exposés et leurs versions

Dressez la liste de tout ce qui est joignable depuis Internet : pare-feu, passerelle VPN SSL, passerelle de messagerie, console d’administration centralisée, accès distant de votre infogérant. Pour chaque équipement, notez le modèle, la version exacte du système, la date de la dernière mise à jour et qui l’administre. Sans cet inventaire, vous ne saurez pas quels avis de sécurité vous concernent.

Vérifiez aussi un point souvent oublié : l’interface d’administration est-elle accessible depuis Internet ? La faille PAN-OS CVE-2026-0322 vise précisément l’interface de gestion, et Palo Alto Networks précise dans son avis que l’exposition dépend de cette configuration.

Étape 2 : croisez cet inventaire avec les failles exploitées

Comparez vos modèles et versions avec le catalogue KEV de la CISA et les avis du CERT-FR. Une faille qui figure dans le KEV est exploitée en conditions réelles : si votre version était vulnérable pendant la période d’exploitation, partez du principe que l’équipement a pu être visé et poursuivez la vérification.

Étape 3 : appliquez le correctif, puis notez la fenêtre d’exposition

Installez la version corrigée recommandée par l’éditeur. Notez ensuite deux dates : celle de la mise en ligne de la version vulnérable et celle du correctif. C’est la fenêtre d’exposition : toutes les vérifications suivantes portent sur cette période, pas uniquement sur les derniers jours.

Étape 4 : recherchez les indicateurs de compromission publiés

Les éditeurs publient souvent des indicateurs de compromission (IOC) : adresses IP d’attaque, noms de fichiers, hachages. Palo Alto Networks a par exemple communiqué trois adresses IP liées à l’exploitation de CVE-2026-0322, et Cisco un tableau d’IOC pour sa passerelle de messagerie. Recherchez ces éléments dans les journaux de l’équipement, mais aussi dans ceux du pare-feu situé devant ou derrière, de votre proxy et de votre serveur DNS, puisque les journaux locaux ont pu être effacés.

Étape 5 : contrôlez les comptes, la configuration et les sessions VPN

Exportez la configuration actuelle et comparez-la à une sauvegarde antérieure à la fenêtre d’exposition. Cherchez en priorité :

• un compte administrateur ou un compte VPN que personne ne reconnaît ;
• une règle de filtrage ou une redirection de port ajoutée sans ticket ;
• une tâche planifiée, un script ou un fichier inconnu sur le système ;
• des sessions VPN ouvertes depuis des pays ou à des horaires inhabituels pour vos équipes.

Si l’éditeur fournit un outil de vérification d’intégrité, lancez-le : il détecte des modifications que l’interface web n’affiche pas.

Étape 6 : renouvelez les secrets en cas de doute

Au moindre indice, considérez que tout ce que l’équipement stockait est connu de l’attaquant. Changez les mots de passe administrateurs, réinitialisez les comptes VPN des utilisateurs, renouvelez les certificats et les clés prépartagées des tunnels site à site, et vérifiez les comptes de service liés à l’annuaire. C’est l’étape la plus coûteuse, mais c’est elle qui ferme réellement la porte.

Si l’analyse confirme une compromission, l’équipement ne doit plus être considéré comme fiable : la réinstallation complète depuis une image de l’éditeur, suivie d’une reconfiguration propre, est la seule option sûre. Déclenchez alors votre plan de réponse à incident.

Étape 7 : mettez les journaux sous surveillance continue

Une vérification ponctuelle ne vous protège que jusqu’à la prochaine faille. Envoyez les journaux de vos équipements de bordure vers un système centralisé, hors de l’équipement lui-même, et définissez quelques alertes simples : nouvel administrateur créé, connexion à l’interface de gestion depuis Internet, session VPN depuis un pays inattendu. Pour réduire la surface d’attaque en amont, notre tutoriel de durcissement FortiGate détaille les réglages prioritaires.

Quand cette vérification dépasse vos ressources internes

Les étapes 1 à 3 sont à la portée de tout responsable informatique. Les étapes 4 à 6 demandent de lire des journaux sur plusieurs mois et de savoir distinguer une anomalie d’un comportement normal : c’est là que les petites équipes manquent le plus souvent de temps. Si votre prestataire informatique administre vos équipements, demandez-lui par écrit le résultat de chaque étape pour les avis qui vous concernent.

Une compromission d’équipement de bordure se détecte bien plus tôt quand ses journaux sont analysés en continu : découvrez notre SOC managé 24/7 pour PME et ETI.

Ce qu’il faut retenir

• Un correctif ferme la faille, il ne retire pas un attaquant déjà entré.
• Vérifiez toute la fenêtre d’exposition, pas seulement les derniers jours.
• Cherchez les IOC aussi dans les journaux externes à l’équipement.
• Au moindre doute, renouvelez comptes, certificats et clés VPN.
• N’exposez jamais l’interface d’administration sur Internet.

Sources

• CISA : ajout de quatre vulnérabilités exploitées au catalogue KEV
• Palo Alto Networks : avis de sécurité CVE-2026-0322 (PAN-OS)
• Cisco : avis de sécurité Secure Email Gateway CVE-2026-76519
• Unit 42 : PEERSTITCH, un implant furtif sur FortiGate
• CISA : catalogue Known Exploited Vulnerabilities

Ce n’est pas un sujet réservé aux grands groupes dotés d’un service achats et d’un questionnaire de conformité interminable. Une PME de 80 personnes compte souvent plus d’accès tiers que de comptes administrateurs internes : l’infogérant, l’éditeur de l’ERP, le mainteneur de la téléphonie, le prestataire de la GTB, l’agence web. Chacun d’eux est une porte d’entrée possible, et c’est rarement la plus surveillée.

Un boîtier géré par un tiers, des mois d’intrusion silencieuse

Les équipes de réponse à incident de Unit 42 (Palo Alto Networks) ont publié le récit d’une intrusion dans une banque européenne qui illustre parfaitement le problème. L’attaquant n’a utilisé aucune technique sophistiquée. Il est entré par une passerelle externe gérée par un prestataire, mal configurée et qui n’imposait pas d’authentification stricte, avec des identifiants compromis.

Une fois à l’intérieur, il a mené pendant plusieurs mois des campagnes de reconnaissance bruyantes, des attaques par force brute sur les comptes administrateurs et une collecte systématique de la documentation interne. Il a fini par tenter d’exploiter une vulnérabilité du serveur WSUS, celui qui distribue les mises à jour à tout le parc. C’est seulement à ce moment-là que l’EDR l’a bloqué.

Trois enseignements valent pour n’importe quelle PME :

• l’équipement par lequel l’attaquant est entré n’était pas administré par l’entreprise elle-même, donc personne en interne ne vérifiait sa configuration ;
• l’activité anormale a duré des mois, car les connexions venant du canal prestataire paraissaient légitimes ;
• ce qui a sauvé la situation, c’est une détection sur les postes et serveurs, pas un contrôle contractuel.

Pourquoi le risque fournisseur pèse plus lourd en PME

Dans une grande entreprise, un prestataire reçoit un compte nominatif, limité dans le temps, passant par un bastion qui enregistre les sessions. Dans beaucoup de PME, la réalité est différente : un compte « admin-presta » partagé, créé il y a cinq ans, sans double authentification, avec des droits de domaine complets, et un outil de prise en main à distance installé en permanence sur les serveurs.

Ce raccourci se comprend : le prestataire doit pouvoir intervenir vite, et la PME n’a pas d’équipe pour ouvrir et refermer les accès à la demande. Mais il produit trois angles morts :

• l’identité : vous ne savez pas qui, chez le prestataire, utilise réellement le compte, ni si ce collaborateur est encore en poste ;
• le chemin : VPN dédié, outil RMM, logiciel de télémaintenance, accès direct au cloud du prestataire… les voies d’entrée se multiplient sans inventaire ;
• la surveillance : les connexions du prestataire sont considérées comme « normales » par défaut, donc personne ne les regarde.

Les outils de gestion à distance (RMM) concentrent ce risque : un seul outil compromis chez l’infogérant donne accès à tous ses clients d’un coup. Nous avons détaillé ce scénario dans notre article sur la faille N-central et la sécurisation des outils RMM.

Cartographier les accès prestataires en une demi-journée

Le premier livrable n’est pas une politique, c’est un tableau. Pour chaque prestataire qui touche à votre informatique, notez cinq colonnes :

1. le nom du prestataire et le contact technique responsable ;
2. le ou les comptes utilisés (nominatifs ou partagés) et leur niveau de droits ;
3. le chemin d’accès : VPN, RMM, outil de télémaintenance, console cloud, accès physique ;
4. la protection en place : double authentification, restriction d’adresse IP, plage horaire ;
5. la date de la dernière intervention réelle.

Pour remplir ce tableau, croisez trois sources : la liste des comptes de votre annuaire (Active Directory ou Entra ID) dont le nom évoque un prestataire, la liste des logiciels de prise en main à distance installés sur vos serveurs, et vos factures fournisseurs des douze derniers mois. Les comptes sans intervention récente et les outils que personne ne reconnaît sont vos premières actions de nettoyage.

Ce travail fait presque toujours apparaître des surprises : un ancien prestataire dont le compte est encore actif, un outil de télémaintenance resté installé après un dépannage, une passerelle VPN que le fournisseur administre et dont vous ignorez la version.

Les cinq exigences à poser à chaque prestataire

Inutile d’envoyer un long questionnaire de conformité. Pour une PME, cinq exigences couvrent l’essentiel du risque, et elles se vérifient facilement :

• Comptes nominatifs : un compte par intervenant, jamais de compte partagé, désactivé quand la personne quitte le prestataire.
• Double authentification obligatoire sur tout accès distant, y compris sur les équipements que le prestataire administre pour vous (pare-feu, VPN, passerelle).
• Moindre privilège : des droits limités au périmètre du contrat, pas d’administrateur de domaine par défaut.
• Accès ouverts à la demande quand c’est possible, ou au minimum restreints aux adresses IP du prestataire.
• Engagement de notification : le prestataire vous prévient sous un délai fixé au contrat s’il subit lui-même un incident.

Le point le plus souvent oublié concerne les équipements administrés par le tiers. Dans le cas analysé par Unit 42, c’est précisément une passerelle externe gérée par un prestataire qui a servi de point d’entrée. Demandez explicitement qui applique les correctifs sur ces boîtiers, dans quel délai, et comment vous en êtes informé. Les failles critiques sur les VPN et passerelles d’accès se succèdent : la réponse « c’est le prestataire qui gère » ne suffit pas.

Surveiller l’accès des tiers sans alourdir la relation

Le contrat fixe les règles, mais seule la surveillance prouve qu’elles sont respectées. Trois signaux simples suffisent pour repérer un accès prestataire détourné :

• une connexion du compte prestataire en dehors des créneaux d’intervention habituels ou depuis une adresse inhabituelle ;
• un compte prestataire qui interroge massivement l’annuaire, scanne le réseau ou échoue à répétition sur des comptes administrateurs ;
• l’apparition d’un nouvel outil de prise en main à distance sur un serveur sans ticket correspondant.

Ces signaux supposent de collecter les journaux d’authentification et de les analyser en continu, y compris la nuit et le week-end, moments que les attaquants privilégient. C’est souvent la question qui décide entre surveiller en interne et confier cette tâche à un spécialiste ; notre article infogérant ou MSSP spécialisé détaille ce choix. Point important : si votre infogérant est aussi celui qui surveille, personne ne surveille l’infogérant.

Risque fournisseur et NIS2 : ce que la directive exige

Pour les entités concernées, la directive NIS2 fait de la sécurité de la chaîne d’approvisionnement une mesure obligatoire. Son article 21 cite explicitement la sécurité des relations entre chaque entité et ses fournisseurs ou prestataires de services directs, et demande de tenir compte des vulnérabilités propres à chaque fournisseur et de la qualité de ses pratiques de cybersécurité.

Concrètement, un auditeur attendra trois choses : un inventaire des prestataires ayant accès au SI, des exigences de sécurité formalisées dans les contrats, et la preuve que ces accès sont contrôlés. Le tableau et les cinq exigences décrits plus haut couvrent l’essentiel de cette attente. L’ENISA et le NIST publient des guides de bonnes pratiques plus détaillés pour aller plus loin.

Si votre entreprise entre dans le périmètre NIS2, la gestion des prestataires fait partie des mesures contrôlées : voir notre guide de mise en conformité NIS2 pour PME et ETI.

Ce qu’il faut retenir

• Le risque fournisseur se joue sur trois points : l’identité de l’intervenant, son chemin d’accès et la surveillance de ses connexions.
• Un tableau des accès prestataires, rempli en une demi-journée, révèle presque toujours des comptes et des outils oubliés.
• Comptes nominatifs, double authentification et moindre privilège couvrent l’essentiel des exigences à poser.
• Les équipements administrés par un tiers (VPN, passerelles, pare-feu) doivent avoir un responsable des correctifs clairement identifié.
• NIS2 impose la sécurité de la chaîne d’approvisionnement : inventaire, exigences contractuelles et contrôle des accès.

Sources

• Unit 42 : The Noise Inside the Network, How an Unsophisticated Attack Exposed a Third-Party Risk
• Directive (UE) 2022/2555 (NIS2), article 21
• ENISA : Good Practices for Supply Chain Cybersecurity
• ANSSI : Guide d’hygiène informatique
• NIST SP 800-161 Rev. 1 : Cybersecurity Supply Chain Risk Management Practices

Le calendrier presse : les mises à jour de sécurité étendues (ESU) de Windows Server 2012 et 2012 R2 s’arrêtent le 13 octobre 2026, Windows Server 2016 sort du support étendu le 12 janvier 2027, et Microsoft prévient que les systèmes non supportés perdront l’accès à Windows Update lors de la rotation des certificats de mai et juin 2027.

Ce que change vraiment la fin de support Windows

Une machine hors support continue de démarrer, d’imprimer et de faire tourner votre logiciel métier. Ce qui disparaît, ce sont les correctifs de sécurité : chaque faille publiée après la date de fin reste ouverte pour toujours sur cette machine. Or les attaquants comparent justement les correctifs publiés pour les versions récentes avec le code des anciennes pour trouver ce qui n’a pas été corrigé.

Le risque n’est donc pas le jour de la fin de support, mais les mois qui suivent. Un serveur Windows Server 2012 exposé ou joint au domaine devient un point d’entrée stable, que l’attaquant peut garder en réserve. Pour une PME, l’enjeu se résume à trois questions : quelles machines sont concernées, lesquelles peuvent encore recevoir des correctifs payants, et comment contenir les autres.

Étape 1 : inventorier les systèmes obsolètes en une journée

Vous ne pouvez pas protéger ce que vous ne voyez pas. Commencez par une liste exhaustive des versions de Windows en service, postes et serveurs confondus.

• Dans l’Active Directory : la commande PowerShell Get-ADComputer -Filter * -Properties OperatingSystem,OperatingSystemVersion,LastLogonDate exportée en CSV donne la version de chaque machine jointe au domaine et sa dernière connexion.
• Dans Intune ou votre outil RMM : filtrez le parc par version de système d’exploitation ; c’est souvent plus fiable pour les portables rarement connectés au réseau.
• Hors domaine : pensez aux PC de production, aux postes qui pilotent une machine-outil, aux serveurs de vidéosurveillance et aux machines virtuelles oubliées sur l’hyperviseur.

Pour chaque machine, notez trois informations : la version exacte (Windows 10 22H2, Server 2012 R2, Server 2016…), le rôle métier, et l’exposition (accessible depuis Internet, joint au domaine, ou isolé).

Étape 2 : classer chaque machine en trois catégories

Avec l’inventaire, classez chaque système selon ce que vous pouvez faire dans les trois prochains mois :

1. Migrable rapidement : un poste Windows 10 compatible Windows 11, un serveur de fichiers qu’on peut remplacer. Planifiez la migration, c’est la solution la moins chère à terme.
2. Prolongeable : la machine peut recevoir des correctifs étendus (ESU) le temps de migrer.
3. Bloqué : un logiciel métier qui n’existe que pour cette version, un automate livré avec son PC, un éditeur disparu. Cette catégorie demande des mesures de confinement.

Cette étape est aussi le moment de faire valider le classement par la direction : maintenir un système obsolète est une décision de risque, pas une décision technique.

Étape 3 : prolonger avec les correctifs étendus quand c’est possible

Le programme ESU de Microsoft fournit uniquement les correctifs de sécurité critiques et importants, sans nouvelles fonctionnalités ni support général.

• Windows 10 : les postes en version 22H2 peuvent être inscrits à l’ESU commercial, facturé 61 dollars par poste la première année, avec un prix qui double chaque année et un maximum de trois ans après la fin de support d’octobre 2025.
• Windows Server 2012 et 2012 R2 : la troisième et dernière année d’ESU se termine le 13 octobre 2026. Au-delà, il n’existe plus de correctif officiel, même payant.
• Windows Server 2016 : il reste quelques mois de support étendu standard. C’est la fenêtre idéale pour migrer sans payer d’ESU.

Avant de payer, vérifiez que les postes concernés sont bien à jour : un poste Windows 10 qui n’a pas installé les mises à jour récentes ne pourra pas recevoir les nouveaux certificats de Windows Update avant 2027.

Étape 4 : isoler les systèmes Windows bloqués

Pour les machines de la catégorie « bloqué », l’objectif est simple : qu’une compromission de ce système ne puisse pas se propager au reste du réseau.

• Segmentez : placez ces machines dans un VLAN dédié, avec des règles de pare-feu qui n’autorisent que les flux strictement nécessaires (le serveur applicatif vers sa base, l’automate vers son poste de pilotage).
• Coupez Internet : un système obsolète n’a presque jamais besoin de naviguer. Bloquez les sorties directes et passez par un proxy si une mise à jour d’éditeur est indispensable.
• Retirez-le du domaine si possible : un serveur ancien joint à l’Active Directory peut servir de tremplin vers vos comptes d’administration. Si le retrait est impossible, interdisez les connexions des comptes administrateurs du domaine sur cette machine.
• Supprimez l’exposition : aucun bureau à distance (RDP) ni partage de fichiers ouvert vers Internet. Un accès distant passe par un VPN ou un bastion, avec double authentification.

Étape 5 : réduire la surface d’attaque de la machine elle-même

Sur chaque système conservé, désinstallez les rôles et logiciels inutiles, désactivez SMBv1 s’il est encore actif, et retirez les droits d’administrateur local aux utilisateurs. Faites tourner un antivirus ou un EDR encore compatible avec la version : de nombreux éditeurs maintiennent un agent sur les anciennes versions de Windows quelques années de plus que Microsoft, mais vérifiez la date de fin de support de l’agent lui-même.

Ajoutez une sauvegarde déconnectée de ces machines. Si un rançongiciel les chiffre, vous devez pouvoir les reconstruire, surtout quand l’installateur du logiciel métier n’existe plus.

Étape 6 : surveiller et dater la sortie

Un système obsolète isolé reste un système vulnérable : ce qui compte ensuite, c’est de voir rapidement ce qui s’y passe. Centralisez ses journaux d’événements (connexions, création de comptes, nouveaux services) et définissez des alertes simples sur ces machines. Ce type de poste à risque se surveille idéalement en continu : c’est précisément ce que permet un processus de priorisation des correctifs couplé à une détection active.

Enfin, donnez une date de sortie à chaque machine bloquée et inscrivez-la dans le registre des risques. Une exception sans échéance devient une installation permanente. Pour les postes, comparez le coût de trois années d’ESU avec celui d’un renouvellement : passé la deuxième année, le calcul penche presque toujours vers le remplacement. Si vous hésitez sur le niveau de protection à conserver sur les postes, notre comparatif EDR ou antivirus en PME détaille les différences.

Un serveur ancien qu’on ne peut pas encore remplacer se détecte et se contient avec une surveillance continue : découvrez notre SOC managé 24/7 pour PME et ETI.

Ce qu’il faut retenir

• Les correctifs étendus de Windows Server 2012 et 2012 R2 s’arrêtent le 13 octobre 2026, sans prolongation possible.
• L’ESU Windows 10 achète du temps, pas une solution : son prix double chaque année.
• Les systèmes bloqués doivent être segmentés, coupés d’Internet et éloignés des comptes d’administration.
• Les machines non supportées perdront l’accès à Windows Update avec la rotation des certificats de 2027.
• Chaque exception doit avoir une date de sortie validée par la direction.

Sources

• Microsoft Learn : Extended Security Updates pour Windows Server 2012 et 2012 R2
• Microsoft Learn : programme ESU pour Windows 10
• Microsoft Lifecycle : Windows Server 2016
• Microsoft Windows message center : rotation des certificats Windows Update
• ANSSI : guide d’hygiène informatique

Ce que le VPN d’entreprise protège vraiment, et ce qu’il ne protège pas

Un VPN d’accès distant crée un tunnel chiffré entre le poste du salarié et le réseau de l’entreprise. Il protège la confidentialité du trafic sur un Wi-Fi d’hôtel ou de gare, et il permet d’atteindre des serveurs internes : partages de fichiers, ERP, logiciel de paie hébergé dans le local technique.

Son défaut est structurel : une fois authentifié, l’utilisateur, ou l’attaquant qui a volé son identifiant, se retrouve sur le réseau, avec une visibilité large sur des machines qu’il n’a aucune raison de joindre. C’est ce qui rend les passerelles VPN si recherchées par les groupes de rançongiciel : une seule passerelle compromise donne un point d’appui à l’intérieur.

Le second défaut tient à l’équipement lui-même. Une passerelle VPN est exposée sur Internet en permanence, et les boîtiers des grands constructeurs reviennent très régulièrement dans le catalogue des vulnérabilités activement exploitées de la CISA. Pour une PME sans équipe dédiée, appliquer chaque correctif d’urgence dans les heures qui suivent sa publication est souvent irréaliste.

Le ZTNA : l’accès à une application, pas au réseau

Le ZTNA (Zero Trust Network Access) applique le principe décrit par le NIST dans sa publication SP 800-207 : aucune confiance implicite liée à l’emplacement réseau, chaque demande d’accès est évaluée selon l’identité, l’état du poste et la ressource visée.

Concrètement, le salarié ne « rejoint » plus le réseau. Il ouvre une application précise, après une authentification forte, depuis un poste reconnu comme conforme (chiffré, à jour, protégé par un EDR). Les autres serveurs lui restent invisibles. Et dans la plupart des offres, il n’y a plus de port d’entrée ouvert sur votre pare-feu : un connecteur interne établit une connexion sortante vers le service du fournisseur.

Le revers existe aussi : vous déplacez la confiance vers un fournisseur de cloud, la mise en place demande d’inventorier précisément qui doit accéder à quoi, et certaines applications anciennes (clients lourds, protocoles propriétaires) passent mal.

Trois profils de PME, trois réponses différentes

Vos outils sont presque tous en SaaS

C’est aujourd’hui le cas de nombreuses entreprises de services. Ici, le VPN est souvent un vestige. La priorité est l’identité : authentification multifacteur résistante au phishing, accès conditionnel qui refuse les postes non gérés, et désactivation des protocoles d’authentification anciens. Un guide dédié détaille le déploiement de la MFA en PME étape par étape.

Vous gardez quelques applications sur site

Un ERP, un serveur de fichiers, un logiciel métier hébergé en interne. Le ZTNA est alors le choix le plus cohérent : il publie ces quelques applications sans exposer le reste du réseau. Si un VPN reste en place le temps de la transition, il doit être segmenté, c’est-à-dire limité aux seuls serveurs utiles pour chaque groupe d’utilisateurs.

Vous avez des accès techniques ou industriels

Prestataires de maintenance, automates, administration de serveurs. Ces accès sont les plus sensibles et les plus souvent oubliés. Ils doivent passer par un point unique, nominatif, journalisé, ouvert à la demande et refermé ensuite, jamais par un compte partagé sur une passerelle toujours active.

Durcir un VPN que l’on ne peut pas encore remplacer

Remplacer une infrastructure d’accès distant prend des mois. En attendant, un VPN existant peut être rendu beaucoup moins dangereux :

• Authentification multifacteur obligatoire pour tous les comptes, y compris ceux des prestataires et les comptes d’administration de la passerelle.
• Correctifs appliqués en priorité : la passerelle passe avant les postes de travail, car elle est directement exposée. Abonnez-vous aux avis de sécurité de son constructeur.
• Interface d’administration fermée à Internet : elle ne doit être joignable que depuis le réseau interne.
• Segmentation des droits : un commercial n’a pas besoin d’atteindre le contrôleur de domaine.
• Journalisation exploitée : connexions depuis des pays inhabituels, tentatives répétées, sessions à 3 h du matin. Des journaux que personne ne lit ne détectent rien.

Le cas récent des failles critiques des VPN Check Point illustre la vitesse à laquelle une passerelle non corrigée devient une porte d’entrée.

Le poste de travail, angle mort du débat VPN ou ZTNA

Un tunnel parfaitement chiffré ne sert à rien si le portable qui l’ouvre est infecté par un voleur d’identifiants. L’ANSSI, dans ses recommandations sur le nomadisme numérique, insiste sur ce point : le poste nomade doit être maîtrisé par l’entreprise, chiffré, mis à jour, et l’utilisateur ne doit pas en être administrateur.

Trois règles simples couvrent l’essentiel : pas d’accès aux ressources de l’entreprise depuis un ordinateur personnel non géré, chiffrement intégral du disque, et un outil de détection sur chaque poste nomade. C’est précisément ce que le ZTNA vérifie automatiquement à chaque connexion, et ce qu’un VPN classique ne regarde pas.

Par où commencer, dans quel ordre

Pour une PME, la séquence la plus rentable est la suivante :

1. Inventoriez les applications réellement utilisées à distance, et par qui. Beaucoup découvrent à cette étape que le VPN ne sert plus qu’à deux ou trois usages.
2. Généralisez l’authentification multifacteur sur la messagerie, les outils SaaS et le VPN.
3. Durcissez la passerelle existante : correctifs, administration fermée, segmentation.
4. Publiez les applications internes restantes via une solution ZTNA, application par application, en commençant par la plus sensible.
5. Éteignez le VPN, ou réduisez-le aux seuls accès techniques, une fois les usages migrés.

Le modèle de maturité Zero Trust de la CISA rappelle qu’il s’agit d’une progression par étapes, pas d’un projet unique. L’ANSSI le souligne également : le Zero Trust ne remplace pas la défense en profondeur, il s’y ajoute. Aucune PME n’a besoin de tout faire en un trimestre ; l’important est de ne plus ajouter d’accès « à tout le réseau ».

Quel que soit le choix retenu, un accès distant abusé laisse des traces qu’il faut voir à temps : connexions anormales, comptes réactivés, mouvements latéraux. Notre SOC managé 24/7 pour PME et ETI surveille ces signaux en continu, y compris la nuit et le week-end.

Ce qu’il faut retenir

• Le VPN donne accès au réseau ; le ZTNA donne accès à une application. C’est toute la différence de risque.
• Si vos outils sont en SaaS, la sécurité du télétravail passe d’abord par l’identité et la MFA, pas par un tunnel.
• Une passerelle VPN exposée doit être corrigée en priorité, avec une interface d’administration fermée à Internet.
• Le poste nomade géré, chiffré et surveillé compte autant que la technologie d’accès.
• La migration se fait application par application, sans big bang.

Sources

• NIST SP 800-207 : Zero Trust Architecture
• ANSSI : le modèle Zero Trust
• ANSSI : recommandations sur le nomadisme numérique
• CISA : Zero Trust Maturity Model
• CISA : Known Exploited Vulnerabilities Catalog

La plupart des incidents cloud ne viennent pas d’une faille du fournisseur, mais d’un réglage laissé ouvert par commodité lors d’un projet pressé. Le modèle de responsabilité partagée est clair : le fournisseur sécurise l’infrastructure, vous sécurisez ce que vous y configurez. Comptez une demi-journée pour un premier passage sur un compte de taille raisonnable, puis une heure par mois pour l’entretien.

Repérer vos erreurs de configuration cloud avant de corriger

Avant de toucher au moindre réglage, dressez la liste de vos comptes, abonnements et projets. En PME, le piège classique est le compte oublié : un abonnement Azure ouvert par un prestataire, un projet Google Cloud créé pour un test, un compte AWS payé par carte bancaire au nom d’un salarié parti depuis. Pour chacun, notez le propriétaire métier, le moyen de paiement et qui détient les accès administrateur.

Lancez ensuite un premier scan automatique. Les trois fournisseurs proposent un tableau de bord natif : AWS Security Hub, Microsoft Defender for Cloud (son score de sécurité de base est gratuit) et Security Command Center chez Google. Si vous préférez un outil unique pour plusieurs clouds, l’outil open source Prowler couvre AWS, Azure et GCP et s’appuie sur les référentiels du CIS. Ne cherchez pas à tout corriger d’un coup : servez-vous du rapport pour vérifier les six points ci-dessous, dans cet ordre.

Étape 1 : verrouiller le compte racine et imposer le MFA

Le compte racine AWS, le compte « Administrateur général » Microsoft Entra ou le super administrateur Google ont tous les droits, y compris celui de fermer le compte. Une seule fuite de mot de passe suffit.

• Activez une double authentification résistante au phishing (clé FIDO2 ou passkey) sur chaque compte à privilèges.
• Supprimez les clés d’accès programmatiques rattachées au compte racine AWS : il ne doit jamais servir aux scripts.
• Créez au moins deux comptes d’administration nominatifs, et réservez le compte racine aux opérations qui l’exigent.
• Stockez l’accès de secours (mot de passe et clé) hors ligne, sous la responsabilité de deux personnes.

Vérification : dans la console IAM d’AWS, le tableau de bord indique si le MFA est actif sur le compte racine. Côté Microsoft, les paramètres de sécurité par défaut ou une stratégie d’accès conditionnel imposent le MFA à tous les administrateurs.

Étape 2 : réduire les droits IAM au strict nécessaire

Deuxième erreur la plus fréquente : tout le monde est administrateur, parce que « c’était plus simple pour démarrer ». Un compte de développeur compromis devient alors un compte d’administration compromis.

1. Exportez la liste des utilisateurs et des rôles disposant de droits administrateur ou propriétaire.
2. Pour chacun, demandez au responsable : de quoi cette personne a-t-elle réellement besoin ?
3. Remplacez les rôles larges par des rôles prédéfinis plus étroits (lecture seule, gestion d’un seul service).
4. Supprimez les comptes inactifs : AWS IAM Access Analyzer et les rapports d’identifiants signalent les accès jamais utilisés.

Visez une règle simple : pas plus de deux ou trois administrateurs permanents, et des droits élevés accordés à la demande pour le reste.

Étape 3 : fermer les stockages ouverts au public

Un bucket S3, un conteneur Azure Blob ou un bucket Cloud Storage accessible sans authentification reste la cause la plus banale de fuite de données. Il suffit d’un partage « temporaire » pour un client ou un site web.

• Sur AWS, activez le blocage de l’accès public S3 au niveau du compte, pas seulement bucket par bucket.
• Sur Azure, désactivez l’option d’accès anonyme aux blobs au niveau du compte de stockage.
• Sur Google Cloud, appliquez la prévention de l’accès public via une règle d’administration de l’organisation.

Si un contenu doit vraiment être public (images d’un site, par exemple), isolez-le dans un stockage dédié qui ne contient rien d’autre. Pour un partage ponctuel avec un client, utilisez une URL signée à durée limitée plutôt qu’un bucket ouvert.

Étape 4 : retirer les ports d’administration exposés à Internet

Des machines virtuelles avec SSH (port 22) ou RDP (port 3389) ouverts à toute l’Internet sont scannées en permanence par des robots. Une règle « 0.0.0.0/0 » dans un groupe de sécurité est souvent un reste de mise en service.

1. Listez les groupes de sécurité ou règles de pare-feu qui autorisent ces ports depuis n’importe quelle adresse.
2. Remplacez l’accès direct par un bastion géré : AWS Systems Manager Session Manager, Azure Bastion ou IAP chez Google.
3. À défaut, limitez l’accès aux adresses IP fixes de vos bureaux ou de votre VPN.
4. Faites la même revue pour les bases de données : une base n’a jamais besoin d’être joignable depuis Internet.

Étape 5 : activer et conserver les journaux d’audit

Sans journaux, un incident cloud est impossible à reconstituer : vous ne saurez ni qui s’est connecté, ni ce qui a été modifié. Or certains journaux ne sont pas activés, ou pas conservés assez longtemps, par défaut.

• Sur AWS, créez un trail CloudTrail multi-régions qui écrit dans un bucket protégé contre la suppression.
• Sur Azure, exportez le journal d’activité et les journaux de connexion Entra vers un espace de stockage ou un outil de collecte.
• Sur Google Cloud, vérifiez que les journaux d’accès aux données sont activés pour les services sensibles : seuls les journaux d’activité d’administration le sont d’office.

Fixez une durée de conservation cohérente avec vos obligations et votre contrat d’assurance, puis vérifiez que quelqu’un regarde réellement ces journaux : un journal que personne ne lit ne protège de rien.

Étape 6 : supprimer les clés d’accès longue durée et les secrets en clair

Les clés d’accès programmatiques sans date d’expiration finissent dans un dépôt Git, un fichier de configuration ou un poste de développeur. Une fois volées, elles fonctionnent sans MFA.

1. Listez les clés d’accès les plus anciennes et identifiez à quoi elles servent.
2. Remplacez-les par des identités gérées ou des rôles : rôles IAM sur AWS, identités managées sur Azure, comptes de service avec fédération chez Google.
3. Déplacez les secrets restants dans un coffre (AWS Secrets Manager, Azure Key Vault, Secret Manager) avec rotation.
4. Activez l’analyse des secrets sur vos dépôts de code pour attraper les fuites avant qu’elles ne partent.

Nous avons détaillé la marche à suivre quand une clé a déjà fuité dans notre article sur les clés AWS exposées et la reprise de contrôle du cloud.

Tenir ces réglages dans la durée

Une configuration propre se dégrade dès le projet suivant. Instaurez une revue mensuelle courte : relancez le scan, comparez avec le mois précédent, et traitez chaque nouvel écart avant qu’il ne devienne la norme. Ajoutez aussi les alertes de facturation : un pic de consommation inexpliqué est souvent le premier signe d’un compte détourné pour du minage.

Les accès administrateur restent le maillon central de toute cette démarche ; si votre déploiement de la double authentification n’est pas terminé, notre guide pour déployer le MFA en PME étape par étape vous aide à fixer l’ordre de priorité.

Une erreur de configuration exploitée se repère d’autant plus vite que quelqu’un lit vos journaux cloud en continu : découvrez notre SOC managé 24/7 pour PME et ETI.

Ce qu’il faut retenir

• Le fournisseur sécurise l’infrastructure, vous restez responsable de vos réglages.
• Protégez d’abord les comptes à privilèges : MFA résistant au phishing, compte racine inutilisé.
• Fermez les stockages publics et les ports d’administration au niveau du compte entier.
• Activez les journaux d’audit et remplacez les clés longue durée par des rôles.
• Planifiez une revue mensuelle : une configuration propre ne le reste pas toute seule.

Sources

• AWS : bonnes pratiques de sécurité IAM
• Microsoft : Microsoft Cloud Security Benchmark
• Google Cloud : bonnes pratiques de sécurité
• CIS : référentiels de configuration (CIS Benchmarks)
• ANSSI : dossier cloud