GhostLock ne chiffre rien, n’écrit rien sur le disque et n’exploite aucune faille corrigible. Pourtant, ce prototype d’attaque peut rendre des fichiers Windows temporairement inaccessibles en abusant d’un comportement légitime d’une API Windows. Comme un faux air de ransomware.
En théorie, un ransomware chiffre les fichiers. GhostLock ne s’en donne même pas la peine. Présentée par le chercheur en sécurité Kim Dvash, cette preuve de concept s’appuie sur une fonction documentée de Windows pour ouvrir des fichiers en mode exclusif, puis empêcher les autres utilisateurs, applications ou services d’y accéder. Et comme GhostLock ne modifie pas les données, il peut bloquer l’accès aux documents sans produire les signaux que les dispositifs anti-ransomware surveillent d’ordinaire.
Offre partenaire
Votre petite entreprise a de grandes ambitions. Protégez-là contre les pirates. Et développez sereinement votre activité !
Offre partenaire
Une fonction Windows tout à fait légitime, détournée pour bloquer les fichiers
Dans le détail, GhostLock s’appuie sur CreateFileW, une API Windows utilisée par les applications pour ouvrir des fichiers. Jusque-là, rien d’anormal. Le détail qui change tout se trouve dans le paramètre dwShareMode, chargé de définir ce que les autres processus peuvent faire pendant qu’un fichier est déjà ouvert. Lorsque cette valeur est réglée sur zéro, Windows accorde un accès exclusif au programme qui a ouvert le fichier, et toute autre tentative d’ouverture se solde par une erreur STATUS_SHARING_VIOLATION.
Ce mode de fonctionnement fait lui aussi partie des comportements prévus par Windows, puisqu’il permet en temps normal d’éviter que plusieurs applications manipulent le même fichier en parallèle, au risque de provoquer des conflits d’accès ou des modifications concurrentes. GhostLock se contente alors d’automatiser l’opération à grande échelle, en appliquant cette logique d’accès exclusif non plus à un document isolé, mais à une arborescence entière, notamment sur des partages SMB.
Les documents ouverts par GhostLock ne sont donc ni chiffrés ni modifiés, mais les accès sautent les uns après les autres pour les autres postes connectés au même environnement.
Pas de chiffrement, mais une vraie capacité de nuisance
Évidemment, ce n’est pas parce que GhostLock ne chiffre ni ne détruit les données que les entreprises s’en tirent à bon compte. D’après Kim Dvash, un compte de domaine standard disposant d’un simple accès en lecture peut provoquer le blocage, sans droits administrateur ni capacité particulière. Un accès récupéré après phishing, un poste déjà compromis ou un profil interne malveillant peuvent donc générer un incident visible très vite, sans recourir à une chaîne d’attaque particulièrement lourde.
L’ampleur du problème dépend ensuite de l’architecture touchée. Un serveur de fichiers isolé limitera naturellement la casse, mais des partages départementaux, des espaces DFS, des volumes NAS ou des répertoires utilisés par des applications métier peuvent étendre l’indisponibilité des fichiers à plusieurs équipes, jusqu’à provoquer une paralysie plus vaste de l’organisation.
À cette propagation possible s’ajoute un problème de détection, puisque GhostLock prend les protections anti-ransomware à contrepied. En temps normal, ce type de dispositif surveille les écritures massives, les renommages en série ou les modifications suspectes de fichiers. Ici, ces signaux manquent à l’appel. Selon Kim Dvash, l’indicateur le plus fiable se situe plutôt au niveau du serveur de fichiers, dans le nombre anormal de fichiers ouverts en accès exclusif par une même connexion. Une information qui remonte rarement dans les journaux Windows, les EDR ou les outils réseau classiques.
Pour revenir à la normale, il ne faudra donc pas restaurer des fichiers ni retrouver une clé de déchiffrement, mais inspecter côté serveur les fichiers ouverts et les sessions SMB actives, afin d’identifier les connexions responsables, puis de les interrompre. Moins spectaculaire qu’une demande de rançon, mais pas forcément beaucoup plus simple à traiter sur le moment.
CreateFileW est une fonction Win32 qui permet d’ouvrir (ou créer) un fichier, un périphérique ou un flux, en précisant précisément les droits d’accès et le mode de partage. Elle ne fait pas « l’édition » du fichier par elle-même : elle obtient surtout un handle (un pointeur de gestion) vers la ressource. Si un processus ouvre un fichier avec un partage restrictif, Windows applique cette règle au niveau du système de fichiers et refuse les ouvertures concurrentes incompatibles. Le résultat peut être une indisponibilité totale pour les autres applications, sans chiffrement ni écriture sur le disque. C’est un mécanisme normal de synchronisation, détournable si on l’applique massivement et intentionnellement.
Que signifie le paramètre dwShareMode à 0, et à quoi correspond l’erreur STATUS_SHARING_VIOLATION ?dwShareMode définit quelles opérations (lecture, écriture, suppression) les autres processus sont autorisés à effectuer pendant qu’un fichier est déjà ouvert. Quand dwShareMode vaut 0, le fichier est ouvert en accès exclusif : aucun autre processus ne peut l’ouvrir tant que le premier handle reste actif. Si une autre application tente quand même d’y accéder, Windows renvoie typiquement l’erreur STATUS_SHARING_VIOLATION, qui indique une violation des règles de partage. Ce comportement vise normalement à éviter les corruptions ou les conflits d’écriture entre logiciels. Utilisé à grande échelle, il peut produire un effet “ransomware-like” basé sur le verrouillage, pas sur la modification des données.
Pourquoi des partages SMB, DFS ou un NAS amplifient-ils l’impact d’un verrouillage en accès exclusif ?SMB est le protocole de partage de fichiers le plus courant sous Windows : une ouverture de fichier faite depuis un poste client se traduit par des handles maintenus côté serveur de fichiers. DFS (Distributed File System) peut, selon le déploiement, présenter plusieurs partages et serveurs comme une arborescence unique, ce qui étend mécaniquement la surface touchée si l’opération est automatisée. Un NAS exposé en SMB centralise souvent les données de plusieurs équipes, donc un verrouillage massif se répercute rapidement sur de nombreux utilisateurs et applications. Dans ces environnements, le symptôme n’est pas la perte de données, mais l’indisponibilité généralisée de fichiers pourtant intacts. La remédiation passe alors par l’inspection des sessions/handles côté serveur et la coupure des connexions responsables, plutôt que par une restauration.
