Attaques par rançongiciel contre les MSP : un guide de protection et de reprise

Comment récupérer plusieurs clients après une attaque par ransomware contre un MSP

Le fait qu’une attaque prenne les sauvegardes d’un seul client ou celles de tous dépend surtout de l’architecture, pas de la qualité de la gestion de l’incident. Dans les deux cas, le travail se ressemble : de nombreux environnements clients sont restaurés en même temps, via un seul pipeline, et chaque client s’attend à passer en premier. Ce qui change, c’est ce qu’il reste à restaurer.

Les organisations récupèrent aussi moins qu’avant : parmi celles touchées par un ransomware, seules 39% ont récupéré au moins 75% de leurs données en 2026, contre 57% en 2024. ^[2]

Coupez vos propres outils avant de toucher aux systèmes clients

Déconnectez d’abord les plateformes RMM et PSA, avant que tout travail de remédiation ne commence sur les systèmes clients. Si l’attaquant conserve encore l’accès au mécanisme de déploiement, des systèmes nettoyés le matin peuvent être chiffrés à nouveau l’après-midi.

Cela signifie désactiver les outils d’accès à distance, mettre fin aux sessions actives, révoquer les jetons d’API et les clés d’intégration, et auditer la plateforme pour repérer les comptes, scripts et tâches planifiées ajoutés par l’attaquant. Les systèmes clients restent isolés jusqu’à ce que le plan de gestion soit confirmé comme sain.

Confirmez quelles sauvegardes ont survécu avant de promettre un calendrier à qui que ce soit

Une fois la plateforme contenue, établissez quelles sauvegardes clients sont intactes, lesquelles ont été chiffrées ou supprimées, et jusqu’où remonte le dernier point de restauration sain pour chacune. Un calendrier de récupération construit sur des sauvegardes que personne n’a vérifiées est une supposition assortie de dates.

Vérifiez chaque point de restauration par rapport à la date de compromission initiale plutôt qu’à la date d’exécution du ransomware. Les attaquants maintiennent souvent l’accès pendant des jours ou des semaines avant de déclencher le chiffrement ; un point de restauration dans cette fenêtre peut réintroduire le point d’appui.

Lorsque le stockage de sauvegardes est absolument immuable, cette étape établit quel point de restauration utiliser. Lorsqu’il ne l’est pas, elle établit l’ampleur des pertes et, pour certains clients, la réponse détermine si la récupération est une option tout court.

Restaurez dans l’ordre déjà fixé par le contrat

Savoir ce qui a survécu vous dit ce qui peut fonctionner, mais pas ce qui fonctionne en premier. Cet ordre doit être fixé à l’avance, par écrit, sur des bases explicites : engagements contractuels d’objectif de temps de reprise (RTO), exposition réglementaire et criticité métier. Notez que le volume d’appels téléphoniques après l’événement n’en fait pas partie !.

Se mettre d’accord là-dessus avant un incident évite de négocier au pire moment possible et donne aux responsables de compte un élément auquel se référer lorsque trente clients posent la même question en même temps. Un plan de réponse aux ransomwares documenté est l’endroit où cet ordre est consigné, aux côtés des rôles, des voies d’escalade et des responsabilités de communication client qui l’accompagnent.

Planifiez le débit de restauration, pas le temps de restauration par client

Connaître l’ordre ne vous dit pas combien de temps cela prend. Une restauration qui dure une heure pour un client dure des jours à l’échelle de trente, car lorsque les copies sur site sont perdues, chaque client restaure depuis le centre de données du MSP en même temps, et la contrainte devient ce pipeline partagé, y compris les liaisons vers chaque site client, plutôt qu’un seul job. Le débit de restauration mesuré sur l’ensemble du parc est le chiffre qui détermine la durée de l’incident, et il vaut la peine de le tester avant d’en avoir besoin.

La hiérarchisation du stockage est ce qui fait évoluer ce chiffre. Dans un dépôt de sauvegarde évolutif Veeam, le niveau de performance conserve les données récentes pour une restauration rapide, tandis que les niveaux de capacité et d’archivage assurent une rétention plus longue à moindre coût.

Conserver les sauvegardes clients récentes sur du stockage de sauvegardes sur site sur le site du client, dans le niveau de performance, signifie que les restaurations les plus urgentes s’exécutent à la vitesse du réseau local ; ainsi, la récupération des données après une attaque par ransomware n’est pas mise en file d’attente derrière la copie hors site dans le centre de données du MSP, conçu pour la rétention à long terme.

Un tiers est impliqué dans 48 % de toutes les violations de données aujourd’hui, soit une hausse de 60 % en une seule année. ^[1] Pour chaque client de son portefeuille, un fournisseur de services managés (MSP) est un tiers, et généralement celui qui dispose de l’accès le plus privilégié.

Une attaque par ransomware contre un MSP est une intrusion unique qui atteint tous les clients en même temps. Plutôt que de pénétrer dans cinquante entreprises, l’attaquant compromet celle qui détient déjà un accès privilégié aux cinquante, puis utilise cet accès comme le ferait un technicien.

Alors que 83 % des organisations ont subi au moins une attaque par ransomware au cours des deux dernières années, éviter totalement les ransomwares n’est plus un plan réaliste. ^[2] Pour un MSP, la question autour de laquelle il vaut la peine de planifier n’est pas de savoir si un environnement client sera touché, mais combien le seront au même moment.

Ce guide explique pourquoi les groupes de ransomware ciblent les MSP, comment les attaquants passent des outils de gestion d’un MSP aux réseaux des clients, pourquoi des identifiants partagés Sauvegarde peuvent anéantir le plan de reprise pour chaque client, et comment restaurer plusieurs environnements à la fois.

Points clés

• Une seule intrusion dans un MSP peut livrer un ransomware à tous les clients en même temps, car l’accès privilégié qui permet au service de fonctionner est le même accès dont hérite un attaquant.

• Les plateformes de supervision et de gestion à distance (RMM) constituent la voie d’entrée la plus précieuse, car un RMM maintient une connexion permanente à chaque réseau client, dont un attaquant hérite intacte.

• Des identifiants d’administrateur partagés Sauvegarde déterminent l’issue d’une attaque par ransomware contre un MSP. Stockage des sauvegardes avec Absolute Immutability est ce qui protège les données Sauvegarde lorsque ces identifiants sont entre les mains d’un attaquant.

Pourquoi les groupes de ransomware ciblent les MSP

Les groupes de ransomware ciblent les MSP non pas parce qu’ils sont plus faciles à compromettre que les clients qu’ils protègent, mais parce qu’une seule intrusion peut produire de nombreuses victimes, et que l’accès nécessaire pour les atteindre est déjà en place.

Quatre aspects des MSP en font des cibles à forte valeur pour les acteurs malveillants.

• Une intrusion, de nombreuses victimes : Dans une attaque de la chaîne d’approvisionnement visant un MSP, l’attaquant atteint les cibles visées via un fournisseur auquel ces cibles font déjà confiance. Compromettre un seul MSP peut propager un ransomware à des dizaines ou des centaines d’environnements en aval, de sorte que l’effort par victime tombe à une fraction de ce que coûterait une attaque directe.

• Les clés viennent avec le contrat : Les MSP détiennent, par conception, des identifiants à privilèges élevés dans chaque environnement client, car l’administration à distance est le service pour lequel les clients paient. Un attaquant qui prend le contrôle de ces identifiants hérite de cette portée sans avoir à la gagner.

• Un seul mode opératoire convient à chaque client : L’outillage, les conventions de nommage et les référentiels Sécurité qu’un MSP applique à l’ensemble de son portefeuille sont ce qui rend un grand parc efficace à exploiter. Ils le rendent aussi efficace à attaquer, car une reconnaissance effectuée une fois tend à s’appliquer partout.

• Les régulateurs sont arrivés à la même conclusion : L’UE et le Royaume-Uni ont tous deux inscrit les fournisseurs de services managés dans la loi sur la cybersécurité comme une catégorie distincte plutôt que de les traiter comme des entreprises ordinaires. Leur raisonnement correspond à celui d’un attaquant : un MSP compromis peut perturber de nombreuses organisations à la fois.

• Dans le cadre de NIS2, la gestion des services TIC est l’un des secteurs à criticité élevée de l’annexe I, couvrant les fournisseurs de services managés et de services Sécurité managés. ^[3] La classification suit ensuite la définition européenne de la taille d’entreprise : les MSP comptant 250 employés ou plus, ou dont le chiffre d’affaires dépasse 50 M€ et dont le total de bilan dépasse 43 M€, sont considérés comme des entités essentielles. ^[4]

• Le Royaume-Uni s’oriente dans la même direction. Son projet de loi Cyber Sécurité and Resilience Bill n’est pas encore en vigueur, mais lorsqu’il le deviendra, il créera une catégorie de fournisseurs de services managés pertinents et fixera la déclaration d’incident à 24 et 72 heures. ^[5]

Comment les attaquants pénètrent dans un MSP via votre RMM

Chaque MSP s’appuie sur deux plateformes. Un logiciel de supervision et de gestion à distance (RMM) offre aux techniciens une connexion permanente à chaque réseau client. Un logiciel d’automatisation des services professionnels (PSA) contient les tickets, les contrats et les dossiers clients qui décrivent ce qui se trouve dans ces réseaux. Le RMM est la cible la plus précieuse, car il ne se contente pas de décrire les environnements clients : il permet aussi de les atteindre.

Pénétrer dans cette plateforme emprunte généralement l’une de deux voies. La première est un serveur de gestion laissé exposé à Internet sans correctifs à jour, et l’exploitation d’une vulnérabilité logicielle est désormais le principal point de départ des compromissions, à 31 %. ^[1] La seconde est un compte technicien sans authentification multifacteur, où un mot de passe volé suffit à lui seul.

Dans les deux cas, on arrive au même résultat. L’attaquant élève ses privilèges au sein de la plateforme, puis propage le ransomware via les propres agents du MSP, en utilisant le même mécanisme que les techniciens emploient pour déployer des correctifs et des scripts. Sur un tableau de bord de supervision, cette propagation ressemble à une mise à jour logicielle planifiée, ce qui rend ces attaques si difficiles à détecter.

Les acteurs DragonForce ont procédé exactement ainsi en 2025. Ils ont probablement enchaîné trois vulnérabilités dans SimpleHelp, l’outil RMM qu’un MSP hébergeait pour ses clients, puis ont utilisé cet accès pour cartographier leurs réseaux avant de déployer un ransomware et de voler des données. ^[6]

À ce stade, l’attaquant détient des droits d’administration dans chaque environnement que le RMM touche, y compris les consoles qui contrôlent les sauvegardes.

Un seul identifiant administrateur volé peut-il effacer toutes les sauvegardes des clients ?

Dans de nombreux MSP, un compte administrateur Sauvegarde contrôle les sauvegardes de chaque client ; ainsi, les identifiants qu’un attaquant vole pour se déplacer dans les environnements clients pilotent souvent le plan de récupération pour l’ensemble. Les MSP en arrivent là parce que des consoles partagées rendent économique la gestion de plus de 50 clients, et ce compromis fait partie des défis des MSP Sauvegarde liés à l’exploitation de nombreux environnements simultanément.

Ce compte est aussi la voie d’accès aux sauvegardes de données. De nombreux MSP fonctionnent selon un modèle hybride, en conservant une copie locale sur chaque site client et une copie hors site dans leur propre centre de données afin de respecter la règle 3-2-1-1-0 : trois copies, sur deux supports différents, une hors site, une immuable, et zéro erreur lors de la vérification de restauration.

Quand une seule console contrôle les deux, un seul identifiant volé peut atteindre les deux. Les attaquants traquent les sauvegardes pour bloquer la récupération et forcer le paiement d’une rançon, et sans elles, la rançon est la seule issue. Un pilier de la sauvegarde et de la récupération des données consiste à maintenir des sauvegardes immuables, ce qui signifie que, pendant une fenêtre de temps prédéfinie, une Sauvegarde ne peut pas être modifiée ni supprimée.

Il faut toutefois être vigilant, car de nombreux systèmes qui prétendent offrir des sauvegardes immuables comportent des exceptions et des failles cachées. La plus courante est un paramètre : Technologie S3 Object Lock en mode gouvernance permet à un utilisateur disposant d’autorisations spécifiques de contournement de retirer le verrou, ce que fournit précisément un compte administrateur Sauvegarde volé.

Une solution à cela est Absolute Immutability, ce qui signifie que même l’administrateur le plus privilégié, ou un attaquant ayant accès à Stockage des sauvegardes, ne peut ni modifier ni supprimer des données. Ce niveau de protection contre les ransomwares ne peut être atteint qu’avec un système Stockage des sauvegardes Sécurisé-by-Design, avec un accès zéro pour exécuter des actions destructrices. Cet accès zéro doit aussi être vérifiable via des tests réalisés par des tiers.

Parmi les responsables IT, 93 % déclarent que Stockage des sauvegardes doit protéger les sauvegardes même lorsque les attaquants connaissent les secrets IT d’une organisation, tandis que seuls 16 % affirment que leur stockage est absolument immuable. ^[2] Pour un MSP, cet écart détermine si la copie immuable dans une configuration 3-2-1-1-0 survit à un identifiant volé, pour tous les clients à la fois.

Comment récupérer plusieurs clients après une attaque par ransomware visant un MSP

Le fait qu’une attaque prenne les sauvegardes d’un seul client ou de tous dépend principalement de l’architecture, et non de la qualité de la gestion de l’incident. Dans tous les cas, le travail se ressemble : de nombreux environnements clients sont restaurés en même temps, via un pipeline unique, chaque client s’attendant à passer en premier. Ce qui change, c’est ce qu’il reste à restaurer.

Les organisations récupèrent aussi moins qu’avant : parmi celles touchées par un ransomware, seules 39 % ont récupéré au moins 75 % de leurs données en 2026, contre 57 % en 2024. ^[2]

Coupez vos propres outils avant de toucher aux systèmes clients

Déconnectez d’abord les plateformes RMM et PSA, avant que tout travail de remédiation ne commence sur les systèmes clients. Si l’attaquant conserve l’accès au mécanisme de déploiement, des systèmes nettoyés le matin peuvent être chiffrés à nouveau l’après-midi.

Cela signifie désactiver les outils d’accès à distance, mettre fin aux sessions actives, révoquer les jetons d’API et les clés d’intégration, et auditer la plateforme pour détecter les comptes, scripts et tâches planifiées ajoutés par l’attaquant. Les systèmes clients restent isolés jusqu’à ce que le plan de gestion soit confirmé comme sain.

Confirmez quelles sauvegardes ont survécu avant de promettre un calendrier à qui que ce soit

Une fois la plateforme contenue, établissez quelles sauvegardes clients sont intactes, lesquelles ont été chiffrées ou supprimées, et jusqu’où remonte le dernier point de restauration sain pour chacune. Un planning de récupération basé sur des sauvegardes que personne n’a vérifiées est une supposition assortie de dates.

Vérifiez chaque point de restauration par rapport à la date de compromission initiale plutôt qu’à la date d’exécution du ransomware. Les attaquants maintiennent souvent l’accès pendant des jours ou des semaines avant de déclencher le chiffrement ; un point de restauration dans cette fenêtre peut réintroduire le point d’appui.

Lorsque Stockage des sauvegardes est absolument immuable, cette étape établit quel point de restauration utiliser. Lorsqu’il ne l’est pas, elle établit l’ampleur des pertes et, pour certains clients, la réponse détermine si la récupération est une option tout court.

Restaurez dans l’ordre déjà fixé par le contrat

Savoir ce qui a survécu vous dit ce qui peut fonctionner, mais pas ce qui fonctionne en premier. Cet ordre doit être fixé à l’avance, par écrit, sur des bases explicites : engagements contractuels d’objectif de temps de reprise (RTO), exposition réglementaire et criticité métier. Notez que le volume d’appels téléphoniques après l’événement n’en fait pas partie !.

Se mettre d’accord là-dessus avant un incident évite de négocier au pire moment possible et donne aux responsables de compte un élément auquel se référer lorsque trente clients posent la même question en même temps. Un plan de réponse aux ransomwares documenté est l’endroit où cet ordre est consigné, aux côtés des rôles, des voies d’escalade et des responsabilités de communication client qui l’accompagnent.

Planifiez le débit de restauration, pas le temps de restauration par client

Connaître l’ordre ne vous dit pas combien de temps cela prend. Une restauration qui dure une heure pour un client dure des jours sur trente, car lorsque les copies sur site sont perdues, chaque client restaure depuis le centre de données du MSP en même temps, et la contrainte devient ce pipeline partagé, y compris les liaisons vers chaque site client, plutôt qu’un seul job. Le débit de restauration mesuré sur l’ensemble du parc est le chiffre qui détermine la durée de l’incident, et il vaut la peine d’être testé avant d’en avoir besoin.

Le tiering de stockage est ce qui fait évoluer ce chiffre. Dans un référentiel Sauvegarde scale-out Veeam, le niveau de performance conserve les données récentes pour une restauration rapide, tandis que les niveaux de capacité et d’archivage assurent une rétention plus longue à moindre coût.

Conserver les sauvegardes clients récentes sur du stockage de sauvegardes sur site sur le site client, dans le niveau de performance, signifie que les restaurations les plus urgentes s’exécutent à la vitesse du réseau local ; ainsi, la récupération des données après une attaque par ransomware n’est pas mise en file d’attente derrière la copie hors site dans le centre de données du MSP, conçu pour la rétention à long terme.

L’horloge de reporting démarre avant la fin de la restauration

Les obligations de reporting n’attendent pas la restauration. Elles commencent lorsqu’un MSP prend connaissance de l’incident ; ainsi, au titre de NIS2, une alerte précoce est due dans la première journée et une notification plus complète dans les trois jours. ^[7] Les deux tombent alors que les restaurations sont encore en cours. Le projet de loi britannique suit le même schéma en deux étapes. ^[5]

Restaurer les données ne clôt pas non plus le sujet. Les opérateurs de ransomware volent souvent des données avant de les chiffrer ; ainsi, une récupération de ransomware propre peut coexister avec une violation à déclarer pour le MSP et les clients affectés. Le conseil juridique et l’assureur cyber doivent être intégrés à la réponse dès le premier jour, et non une fois les systèmes de nouveau en ligne.

Stockage des sauvegardes conçu pour la flexibilité des MSP

Les MSP ont besoin de Stockage des sauvegardes qui soit Simple à exploiter, résilient face aux ransomwares, et suffisamment flexible pour prendre en charge des environnements clients variés, sur les sites clients et dans le propre centre de données du MSP.

Les solutions traditionnelles exigent souvent un durcissement manuel, s’appuient sur des outils fragmentés et enferment les MSP dans des modèles tarifaires rigides qui freinent la croissance.

Object First Ootbi rend les données Veeam Sécurisé avec Absolute Immutability, garantissant que personne, pas même l’administrateur le plus privilégié ou un attaquant ayant accès à Stockage des sauvegardes, ne peut modifier ni supprimer des données Sauvegarde.

L’application des règles se fait dans le stockage lui-même plutôt que dans une politique logicielle ; elle ne peut donc pas être désactivée par des identifiants, des changements de configuration ou des commandes à distance, et les actions destructrices sont entièrement retirées de l’interface d’administration plutôt que conditionnées par des permissions.

Pour les défaillances décrites ci-dessus, cela signifie :

• Un compte administrateur Sauvegarde volé peut toujours se connecter et restaurer, ce qui est nécessaire à la récupération, mais ne peut pas modifier ni supprimer les sauvegardes.

• Un ransomware propagé via les propres agents du MSP peut écrire de nouvelles sauvegardes, mais ne peut pas modifier ce qui est déjà écrit, car Immuabilité s’applique dès l’instant où chaque Sauvegarde arrive.

• Une console atteignant les deux copies dans une configuration hybride ne peut lever le verrou sur aucune des deux, car l’application des règles réside dans chaque appliance.

Les MSP peuvent simplifier la gestion de multiples déploiements grâce à l’utilitaire de supervision cloud Fleet Manager. Lors de l’achat d’appliances, les MSP peuvent choisir entre une tarification par consommation et un abonnement CapEx afin de s’aligner sur leur modèle économique.

Téléchargez le Livre blanc pour découvrir les défis auxquels les MSP font face et comment Object First fournit un stockage de sauvegardes résistante aux ransomwares tout en réduisant Charges opérationnelles supplémentaires.

FAQ

Faut-il payer la rançon ?

Payer ne garantit pas l’obtention de clés de déchiffrement fonctionnelles, et l’argent finance une opération qui attaquera à nouveau. Un MSP disposant de sauvegardes vérifiées, absolument immuables, peut restaurer les environnements clients sans négocier, ce qui écarte la question.

Quelle est la meilleure protection contre ransomwares pour les MSP ?

Le minimum vital est l’authentification multifacteur sur les plateformes RMM et PSA, l’application rapide des correctifs sur les outils de gestion exposés à Internet, et des identifiants et cibles de stockage séparés pour chaque client. Tout cela réduit la probabilité d’une compromission, tandis que Stockage des sauvegardes avec Absolute Immutability détermine si un MSP peut s’en remettre.

NIS2 exige-t-elle que les MSP soient capables de se remettre d’un ransomware ?

L’article 21 énumère la continuité d’activité, y compris la gestion Sauvegarde et la reprise après sinistre, parmi les mesures de gestion des risques que les entités dans le périmètre doivent mettre en œuvre, et la gestion des services TIC figure à l’annexe I comme secteur à haute criticité. ^[3] La directive ne cite pas de technologie spécifique ; l’obligation consiste donc à démontrer que la récupération fonctionne réellement, ce que les MSP peuvent vérifier par rapport à la liste complète des mesures de gestion des risques NIS2.

 

 

 

 

Références

[1] Verizon. "Vulnerability exploitation is top breach entry point, 2026 DBIR finds." 2026. https://www.verizon.com/about/news/breach-industry-wide-dbir-finds

[2] Omdia. "Recovery without Compromise: The Data-Backed Case for Backup Storage with Absolute Immutability." Research commissioned by Object First. 2026. https://objectfirst.com/recovery-without-compromise/

[3] European Parliament and Council. "Directive (EU) 2022/2555 (NIS2)." 2022. https://eur-lex.europa.eu/eli/dir/2022/2555/oj

[4] European Commission. "Commission Recommendation 2003/361/EC concerning the definition of micro, small and medium-sized enterprises." 2003. https://eur-lex.europa.eu/eli/reco/2003/361/oj

[5] UK Parliament. "Cyber Security and Resilience (Network and Information Systems) Bill, HL Bill 32 of 2026-27." 2026. https://bills.parliament.uk/bills/4035

[6] Sophos. "DragonForce actors target SimpleHelp vulnerabilities to attack MSP, customers." 2025. https://www.sophos.com/en-us/blog/dragonforce-actors-target-simplehelp-vulnerabilities-to-attack-msp-customers/

[7] European Parliament and Council. "Directive (EU) 2022/2555 (NIS2), Article 23." 2022. https://eur-lex.europa.eu/eli/dir/2022/2555/oj