Il existe une définition assez simple du ransomware.
Quelqu’un empêche l’accès à un outil ou à des données tant qu’un paiement supplémentaire n’a pas été effectué.
On pense à des groupes criminels, à des serveurs lointains, à des messages alarmistes.
On pense beaucoup moins à un logiciel métier installé depuis des années chez un client, en local, sans abonnement actif, sans cloud, sans dépendance externe affichée.
Et pourtant.
Un logiciel de facturation et de devis, acheté et installé en local, devient soudainement inutilisable sans modification volontaire, sans incident de sécurité et sans demande du client.
Derrière un message de licence invalide, c’est toute une mécanique de forçage commercial qui se révèle, au nom de la cybersécurité.
Analyse factuelle, technique et éthique d’une pratique qui interroge sur les limites du pouvoir des éditeurs sur des logiciels dont ils ont « vendue l’utilisation illimité dans le temps » : la licence.…
Un logiciel métier vital, désactivé sans demande
Cas réel de Ransomware
Logiciel métier de facturation et de devis, installé en local depuis des années.
Licence achetée.
Données hébergées chez le client.
Sauvegardes internes.
Aucun service cloud.
Aucun abonnement actif.
Aucune demande d’intervention.
Un logiciel vital pour l’entreprise, édité par un acteur très connu, leader sur son marché dans le bâtiment.
À 8h du matin, le premier utilisateur se connecte.
Il accède à ses devis, à sa facturation, à ses dossiers. Aucun problème.
À 9h10, un collaborateur se connecte à son tour.
Déconnexion brutale de l’ensemble des postes.
Et un message qui apparaît sans avertissement :
« Votre logiciel est désactivé, le statut de la licence n’est pas valide. »
La clé est correcte.
Les données sont là.
Le serveur n’a pas changé.
La seule chose qui a changé, c’est ce qui s’est produit entre ces deux connexions.Et la on pense au pire, Ransomware, cyberattaque virus ou autre.
Analyse de sécurité et premières vérifications : Ransomware ou pas ?
Face à ce type de message, la première hypothèse est évidente : un incident de sécurité, un Ransomware un virus….,
Une analyse complète est donc menée, selon les procédures habituelles :
- audit des postes de travail
- vérification des antivirus et protections locales
- analyse des journaux systèmes et applicatifs
- contrôle des accès au NAS et aux partages réseau
- vérification des accès et des journaux du serveur
- contrôle de l’état et de l’intégrité des sauvegardes pour une restaurations complète sans Ransomware ou virus.
- Aucune anomalie n’est détectée.
- Pas de trace de ransomware.
- Zéro activité suspecte.
- Aucune erreur système visible.
Les sauvegardes sont complètes, cohérentes et exploitables.
Restauration du système et comportement anormal
Une restauration du système est alors effectuée à l’état de 8h.
Le logiciel fonctionne à nouveau.
Les utilisateurs accèdent aux devis et aux factures.
Tout semble normal.
Trois minutes plus tard, sans action particulière, le logiciel est à nouveau désactivé.
Le même message s’affiche.
À ce stade, l’hypothèse d’un problème d’horodatage est envisagée.
Les paramètres horaires du serveur sont vérifiés.
Aucune incohérence n’est constatée.
Une nouvelle restauration est réalisée.
Le comportement est strictement identique :
fonctionnement immédiat, puis invalidation rapide.
Analyse ciblée du logiciel, Ransomware ciblé ?
L’attention se porte alors sur le logiciel lui-même.
Les fichiers modifiés lors du lancement sont observés.
Un élément ressort très clairement :
le fichier de licence au format XML est modifié presque instantanément dès que le logiciel est lancé.
La question n’est alors plus de savoir si quelque chose agit, mais quoi.
Identification du déclencheur
Une hypothèse est formulée : un échange externe déclenche la modification de la licence.
Les règles de pare-feu du serveur sont temporairement ajustées afin de bloquer l’intégralité du trafic sortant lié aux composants du logiciel.
Une nouvelle restauration du système est effectuée.
Le serveur est relancé.
Le logiciel est démarré.
Cette fois, le problème ne se reproduit plus.
Le logiciel reste fonctionnel.
Les données restent accessibles.
Le fichier de licence n’est plus modifié.
Constat technique
Les tests permettent d’établir un constat clair :
- le blocage ne provient ni des postes, ni du réseau interne, ni du serveur
- les données locales ne sont pas corrompues
- la licence est modifiée uniquement après un échange externe
- le problème disparaît dès lors que ces échanges sont empêchés
Une solution temporaire permet ainsi de rétablir l’usage du logiciel, sans perte de données, en attendant une décision plus globale.
Le discours de l’éditeur
Côté éditeur, le discours est double.
Le service commercial explique qu’il faut payer une mise à jour ou une migration afin de garantir la récupération et l’accès aux données.
Ce discours implique de fait que, sans cette opération payante, les données ne seraient plus accessibles, alors même qu’elles sont stockées en local chez le client et non chez l’éditeur.
L’export et l’accès aux données sont finalement validés, ce qui confirme que le blocage ne porte pas sur la donnée elle-même, mais bien sur l’usage du logiciel.
Du côté technique, aucune explication claire n’est fournie sur la désactivation de la licence.
La seule réponse apportée est que, sans contrat de maintenance actif et sans mise à jour, aucune assistance n’est possible.
La vraie question n’est pas technique
La question n’est pas de savoir s’il faut mettre à jour ses logiciels.
Cette question est déjà tranchée, et la réponse est oui.
La vraie question est beaucoup plus simple :
jusqu’où un éditeur peut-il forcer un paiement sur un produit déjà vendu ?
Les entreprises ont des obligations légales de conservation des devis, des factures et des documents comptables sur de longues durées.
Migrer des années d’historique vers de nouveaux outils, multiplier les imports ou maintenir des environnements parallèles n’est ni toujours économiquement viable, ni toujours nécessaire.
Les données qu’il contient n’appartiennent pas à l’éditeur.
L’éditeur n’a aucun droit sur la donnée.
Il n’a aucun droit de contraindre un utilisateur à une mise à jour.
Il n’a aucun droit de rendre inutilisable un outil déjà payé pour imposer une évolution commerciale.
Quand l’accès à un logiciel est bloqué pour forcer une décision financière, la sécurité n’est plus un argument technique.
C’est un levier.
Et à partir de là, on ne parle plus d’informatique.
On parle d’éthique.
