12/03/2025
Cybersecurity Insights
Retour d’expérience : Chiffrement d’hyperviseurs via des outils tiers (WinFsp, SSHFS-win, TNTDrive et S3Browser)
Cet article présente un retour d’expérience (RETEX) sur deux missions menées par le CERT, illustrant des méthodes d’attaque distinctes employées par des acteurs malveillants pour chiffrer des infrastructures critiques. L’objectif est d’exposer les techniques utilisées, d’analyser leur impact et de tirer des enseignements afin d’améliorer les dispositifs de défense, de détection et de réponse aux incidents.
Dans la première mission, l’attaquant a ciblé un hyperviseur VMware ESXi en exploitant une méthode originale pour maximiser l’efficacité de son chiffrement. En utilisant l’outil sshfs-win, il a monté l’hyperviseur ESXi comme un partage réseau sur l’une des machines Windows hébergées par cet ESXi. Une fois le montage effectué, le ransomware a été exécuté depuis ce système invité Windows, permettant ainsi de chiffrer en une seule opération l’hyperviseur et l’ensemble des machines virtuelles qu’il héberge.
Dans la seconde mission, l’attaquant a ciblé un environnement de sauvegardes en cloud basé sur des buckets S3 AWS. Grâce à l’outil TNTDrive et S3Browser, l’attaquant a monté le bucket S3 en tant que partage réseau sur l’hyperviseur Windows Hyper-V de la victime. Cette technique a permis au ransomware d’accéder directement aux données stockées dans le bucket, facilitant et accélérant leur chiffrement.
Ces deux scénarios mettent en lumière des techniques de montage de ressources distantes comme des partages réseau, détournées pour exécuter des opérations de chiffrement à grande échelle, et soulignent la nécessité de renforcer la sécurité et la surveillance autour de ces mécanismes d’accès.
Introduction
Traditionnellement, les attaquants rencontrent plusieurs défis lorsqu’ils cherchent à chiffrer un système d’information (SI) hétérogène, composé de divers systèmes d’exploitation comme Windows, Linux ou des hyperviseurs comme VMware ESXi. La diversité des environnements implique des différences dans les outils et méthodes de chiffrement disponibles.
La méthode la plus courante consiste à déployer des versions spécifiques de ransomwares adaptées à chaque système d’exploitation. Par exemple, un binaire Windows pour les machines Windows, un binaire Linux pour les serveurs Linux, et parfois un autre adapté pour les hyperviseurs ESXi. Cette approche, bien qu’efficace, présente des inconvénients majeurs : elle nécessite de préparer plusieurs variantes du malware et de les exécuter successivement ou d’utiliser des mécanismes comme les GPO ou des persistances (via services, ou tâches planifiées spécifiques à un OS), ce qui augmente les délais et les risques de détection.
Un autre exemple observé dans une mission différente met en évidence une attaque moins efficace. Dans ce cas, l’attaquant a ciblé une organisation possédant des milliers de machines Windows, toutes appartenant au même domaine, avec un réseau à plat et sans aucune segmentation. Malgré cette surface d’attaque étendue, seulement quelques dizaines de machines ont été chiffrées. Cela s’explique par la méthode employée : l’attaquant s’est connecté manuellement à chaque machine à l’aide du compte administrateur local et les a chiffrées une par une, ralentissant ainsi considérablement la propagation de l’attaque et laissant davantage de temps aux équipes de défense pour réagir.
Ces méthodes sont efficaces mais longues et parfois fastidieuses, nécessitant une préparation minutieuse et augmentant le risque que les équipes de défense détectent et interrompent l’attaque avant sa finalisation. C’est dans ce contexte que les méthodes innovantes observées dans les deux missions du RETEX ci-dessous se distinguent : en exploitant les montages réseau pour centraliser l’exécution du chiffrement des systèmes d’exploitation hétérogènes à partir d’un seul point de contrôle.
Contexte
Un incident récent (novembre 2024) géré par le CERT CWATCH Almond a permis de mettre en évidence une méthode innovante employée par les attaquants pour chiffrer un hyperviseur VMware ESXi sans y déposer une souche du ransomware. Cette méthode consiste à exploiter les outils WinFsp[1] et SSHFS-Win[2] pour contourner les limitations liées aux différences de systèmes d’exploitation entre l’hyperviseur et les machines virtuelles sous Windows.
Nous appellerons cet incident : « Attaque SSHFS » dans la suite de l’article.
WinFsp ou Windows File System Proxy est un backend Framework qui fournit un support d’exécution et de développement pour des systèmes de fichiers personnalisés sur les ordinateurs Windows.
Toute information ou tout stockage peut être organisé et présenté comme un système de fichiers via WinFsp, l’avantage étant que les applications Windows peuvent accéder à l’information de n’importe quel système de fichier supporté via les API de fichiers standard de Windows. Ainsi WinFsp agit comme une passerelle universelle et fournit l’infrastructure nécessaire pour connecter des systèmes de fichiers non natifs à Windows.
WinFsp est en quelque sorte une implémentation de FUSE pour Windows, il est couramment utilisé avec :
- NTFS (via des implémentations FUSE spécifiques)
- FAT/FAT32
- exFAT
- ZFS, XFS, ext2/ext3/ext4 (via des outils comme extFS for Windows)
- Virtuellement tout système de fichiers pris en charge par une implémentation FUSE compatible Windows
SSHFS-Win (tout comme NFS-Win) est basé sur WinFsp. Il permet de monter un système de fichiers distant via SSH/SFTP. Il fonctionne donc principalement avec :
- Tout système de fichiers supporté par le serveur SSH distant :
- Linux : ext2, ext3, ext4, XFS, Btrfs, ZFS…
- Windows: NTFS, ReFS, FAT32, exFAT…
- macOS : APFS, HFS+…
En résumé, WinFsp est une base permettant d’implémenter des systèmes de fichiers en espace utilisateur, tandis que SSHFS-Win permet d’accéder à des systèmes de fichiers distants via SSH, sans restriction spécifiques côté client Windows.
Note : Il arrive que lors de nos missions de réponses aux incidents, les analystes soient amenés à utiliser l’outil SSHFS afin de collecter des preuves des ESX directement depuis une machine Windows.
Un deuxième incident tout récent (février 2025) également géré par le CERT CWATCH Almond a permis de mettre en évidence une autre méthode innovante employée par les attaquants pour chiffrer des buckets S3 AWS sans y déposer une souche du ransomware. Cette méthode consiste à exploiter les outils S3Browser et TNTDrive pour contourner les limitations liées aux différences d’environnements entre un HyperViseur (type HyperV) contenant des VMs, ainsi que des buckets S3 contenant les sauvegardes VEEAM de ces VMs. Ces techniques n’avaient encore jamais été observées par le CERT.
Nous appellerons cet incident : « Attaque S3 » dans le reste du document.
S3Browser et TNTDrive sont 2 outils légitimes développés par Netsdk qui permettent d’administrer et de monter des buckets AWS S3 en tant que lecteurs réseau ou lecteurs amovibles sous Windows. Il est possible de les télécharger gratuitement via leur site, et de les utiliser soit en GUI, soit en utilisant des lignes de commande. De plus, il est aussi possible de préconfigurer des installateurs, qui pourront être envoyés sur une machine par le biais d’un fichier préalablement zippé.
1. Description des attaques
Attaque SSHFS
Un des hyperviseurs concernés (Vmware ESXi 6.0.0) hébergeait plusieurs machines virtuelles sous Windows, dont un contrôleur de domaine avec un système d’exploitation Windows Server 2019 Standard et une version fonctionnelle de la forêt également en 2019. L’attaquant a compromis ce contrôleur de domaine et a pu obtenir un accès à celui-ci, puis a procédé aux étapes décrites ci-après pour chiffrer les disques des VMs hébergées sur l’hyperviseur.
Attaque S3
L’attaquant a compromis un HyperV (Microsoft Windows Server 2019 Datacenter) hébergé chez OVH, exposé sur internet via une connexion sur le compte de service « WDAGUtilitYAccount », en exploitant la vulnérabilité SMBGhost liée à SMBv3.
Il a par la suite pivoté sur d’autres machines du parc dans le but d’identifier des données d’intérêt avant de déployer son ransomware. Il est ensuite retourné sur le patient 0, dans le but d’installer les outils « TNTDrive » et « S3Browser », lui permettant de monter les systèmes de fichiers des buckets S3 en tant que partage réseau sur l’environnement Windows et ainsi accéder aux sauvegardes. Finalement, l’attaquant a exécuté son ransomware, chiffré les données présentes sur la machine ainsi que sur tous les partages réseau montés sur le système chiffrant également les sauvegardes VEEAM hébergées sur le bucket S3.
1.1. Dépôt de la charge utile
Attaque SSHFS
L’attaquant a déposé les exécutables Windows permettant de chiffrer les données accessibles depuis le serveur DC.
Attaque S3
L’attaquant a déposé le chiffreur Windows sur le serveur HyperV OVH.
1.2. Dépôt des outils WinFsp, SSHFS-win et TNTDrive
Attaque SSHFS
L’attaquant a déposé les outils WinFsp et SSHFS-win sur le serveur DC. Ce sont des outils qui permettent de monter des systèmes de fichiers distants via le protocole SSH. Cela facilite l’accès aux systèmes de fichiers distants non Windows.
Attaque S3
L’attaquant a déposé les outils S3Browser et TNTDrive sur le serveur HyperV. Ils permettent, comme mentionné plus haut, de monter un bucket AWS S3 en tant que lecteur réseau ou lecteur amovible sous Windows.
1.3. Montage des systèmes distants en tant que partages réseaux
Exemple : Montage du FAT et VMFS de l'hyperviseur ESXi
Après avoir installé les outils WinFsp et SSHFS-win sur l’hôte invité compromis (le DC), l’attaquant a pu monter le système de fichiers VMware de l’hyperviseur comme un partage réseau sur le DC via la commande :
\\sshfs\root@hyperviseur\vmfs
Cette commande a permis à l’attaquant d’avoir un accès transparent aux fichiers de l’hyperviseur y compris les disques .vmdk stockés dans les datastores et d’interagir avec eux comme un répertoire local.
Voici une capture d’écran illustrant un exemple de montage d’un système de fichiers EXT4 via la commande :
\\sshfs\{user}@{host}\{Mount Point}
ici :
\\sshfs\forensics@192.168.0.34\dfirtrack
Exemple : Montage de bucket S3 sur un hyperviseur HyperV
Après que l’attaquant a téléchargé et installé TNTDrive sur l’Hyper-V compromis, il a configuré le bucket S3 avec les identifiants déjà présents sur la machine, puis a monté le bucket S3 via la GUI de TNTDrive. Il est à noter que S3Browser utilise TNTDrive pour le montage de système de fichiers en tant que partage réseau :
1.4. Exécution du ransomware
Attaque SSHFS
Le ransomware a été exécuté sur le DC (serveur Windows) par l’attaquant. En parcourant tous les points de montage, y compris ceux de l’hyperviseur (ESXi), le ransomware a chiffré les fichiers accessibles, à savoir ceux stockés sur le serveur DC, ainsi que les disques virtuels des VMs hébergées (.vmdk, .vmem,.vmss, …) sur l’ESXi.
Voici un récapitulatif concernant la souche du ransomware :
Attaque S3
Le ransomware a été exécuté sur le serveur HyperV (serveur Windows) par l’attaquant. En parcourant tous les points de montage, y compris ceux des buckets S3 précédemment montés via l’utilisation des outils TNTDrive et S3Browser, le ransomware a chiffré les fichiers accessibles, à savoir ceux stockés sur le serveur HyperV, ainsi que toutes les sauvegardes VEEAM des VMs (.vbk) qui étaient stockées sur les buckets S3.
Voici un récapitulatif concernant la souche du ransomware :
b298051aaa7d6c1c0670cbedc8921200
SHA1 :
6313E67DBEDADF6E346AB24F1D5D892E6B8D77CD
SHA256 :
23f1d2313435f4a15a98ef721b9fbfb72c987deebb3de27aa63b9e86a1bd9a24
La reconstruction des caches RDP via l’outil développé par l’ANSSI : BMC-tools a permis de mettre en évidence la charge virale « isir.exe » cherchant des points de montage SSHFS sur lesquels s’exécuter, montrant ainsi la volonté et la connaissance des développeurs du ransomware de l’accessibilité de tels FS via partages réseaux. Voici une capture d’écran illustrant l’exécution du ransomware et mentionnant lors du scan des assets à chiffrer, l’information « No SSHFS drives found » nous permettant de confirmer nos observations du premier cas « Attaque SSHFS » :
Etant donné que les buckets S3 d’AWS ne sont pas accessibles via SFTP, mais via les API REST d’AWS ou le protocole S3 spécifique, l’attaquant a donc utilisé les outils S3Browser et TNTDrive pour palier à cette contrainte et monter les buckets S3 en tant que partages réseaux sur l’HyperV.
2. Artefacts
Note : Les Indicateurs de compromission associés aux artefacts sont disponibles dans la partie dédiée.
2.1. Installation
Information sur l’installation des applications WinFsp, SSHFS-win :
Information sur l’installation des applications TNTDrive et S3Browser :
DisplayName: TntDrive version 6.0.9 DisplayVersion: 6.0.9 Publisher: Netsdk Software FZE InstallDate: 20250118
2.2. Exécution & montage
Artefacts permettant l’observation de l’exécution et montages réseaux « WinFsp » et « SSHFS-win» :
sshfs\account@remote_IP\vmfs = 0
\\sshfs\account@remote_IP\vmfs
##sshfs#account@remote_IP#vmfs
Artefacts permettant l’observation de l’exécution et montages réseaux « TNTDrive » et « S3Browser » :
C:\Program Files\TntDrive\tntdrive-svc.exe
C:\ProgramData\Microsoft\Windows\Start Menu\Programs\TntDrive\TntDrive.lnk
3. Impacts
Attaque SSHFS :
- DC chiffré au niveau OS : L’accès aux principales fonctionnalités du DC a été bloqué.
- Hyperviseur ESXi chiffré au niveau OS : L’accès aux principales fonctionnalités de l’hyperviseur a été bloqué.
- VMs chiffrées au niveau disque : Les disques virtuels des VMs (fichiers VMDK) ont été chiffrés, rendant les machines virtuelles inaccessibles.
Attaque S3 :
- Hyperviseur HyperV chiffré au niveau OS : L’accès aux principales fonctionnalités de l’hyperviseur a été bloqué.
- VMs chiffrées au niveau disque : Les disques virtuels des VMs (fichiers VMDK) ont été chiffrés, rendant les machines virtuelles inaccessibles.
- Bucket Amazon S3 hébergeant les backups chiffrés intégralement
4. Avantages pour les attaquants
- Gain de temps et simplification pour les attaquants lors du chiffrement : une seule souche et une seule exécution du ransomware depuis un point unique a permis de chiffrer le SI ainsi que les backups dans son intégralité.
- Absence « d’accès direct » à l’hyperviseur et aux sauvegardes : l’attaquant a pu compromettre l’hyperviseur en exploitant un point de montage SSH, sans interaction directe autre avec l’hyperviseur lui-même telle qu’une connexion RDP ou un passage via une console comme vCenter.
- Absence d’accès direct aux machines virtuelles hébergées : l’attaquant n’a pas eu besoin d’accéder aux machines virtuelles.
5. TTPs
Initial Access
Exploit Public-Facing Application
Initial Access
Valid Accounts: Default Accounts
Command and Control
Remote Access Software
Impact
Data Destruction
6. Recommandations
Restreindre les accès SSH : utiliser des méthodes d’authentification forte (par exemple, l’authentification par clé) et limiter l’accès SSH par adresse IP. SSH ne devrait pas être possible depuis un DC vers un Hyperviseur.
Durcir la politique de gestion des comptes à privilège. Et utiliser des fonctionnalités telles que Protected Users et gMSA (ADAC).
Sensibiliser les administrateurs à l’usage de coffres-forts de mots de passe.
Restreindre l’utilisation des outils de montage de systèmes de fichiers tels que WinFsp, SSHFS-win et TNTDrive et S3Browser.
Notamment utiliser des outils comme DeviceGuard afin de limiter les logiciels installables.
Favoriser l’utilisation de sauvegardes immuables limitant ainsi les capacités de l’attaquant de les chiffrer.
S’assurer d’avoir une politique 3-2-1 pour la donnée critique :
- 3 copies
- Sur 2 supports et dans 2 lieux différents
- Dont 1 offline
Surveiller les opérations sur fichiers : Déployer des outils de contrôle de l’intégrité des fichiers (FIM) pour détecter toute modification anormale des fichiers.
Détecter des montages suspects : déployer des solutions EDR et SIEM pour identifier des montages de systèmes de fichiers, notamment via SSHFS-win et WinFsp
Surveiller le trafic SSH : pour identifier des activités suspectes telles que les connexions vers des destinations non autorisées.
Journalisation et surveillance : Mettre en place des outils de journalisation et de surveillance des activités réseau pour détecter des comportements suspects, comme le montage de volumes distants non autorisés ou l’accès à plusieurs sauvegardes en simultané.
Formation : Sensibiliser les équipes techniques sur les outils potentiellement exploités par les attaquants, tels que WinFsp, SSHFS, TNTDrive et S3Browser.
Conclusion
Ces méthodes d’attaque montrent comment des outils légitimes, tels que WinFsp, SSHFS-win, TNTDrive et S3Browser peuvent être utilisés pour faciliter et accélérer le chiffrement des données sans avoir accès direct aux machines, pour contourner les mesures de sécurité.
Ce type d’attaque lié au RaaS, où les criminels préfèrent compromettre une machine du S.I ayant accès à tous les éléments critiques, récupérer tous les identifiants tiers, et monter toutes les ressources accessibles sous forme de partition logique pour rendre trivial le chiffrement, tend à montrer la capacité des attaquants à améliorer leur mode opératoire afin d’être le plus efficace possible d’un seul coup (cela va dans la mouvance de l’accélération des attaques dites « Go-fast »).
Une stratégie de sécurité renforcée, des contrôles d’accès rigoureux et une surveillance continue, sont essentiels pour prévenir de telles attaques.
Détection Yara rule
rule ISIR_SSHFS {
meta:
description = "Detects files matching modified conti malware targeting SSHFS"
author = "ALMOND/JCO"
date = "2025-03-03"
version = "1.0"
SHA256 = "23f1d2313435f4a15a98ef721b9fbfb72c987deebb3de27aa63b9e86a1bd9a24"
strings:
$IOC_SSHFS = "No SSHFS drives found" ascii wide
$str_main_loop = "starting the main loop" ascii wide
$str_instruction = "Creating instructions..." ascii wide
$str_edge_update = "MicrosoftEdgeUpdate.exe" ascii wide
$XOR_IOC_SSHFS = "No SSHFS drives found" ascii wide xor
$XOR_str_main_loop = "starting the main loop" ascii wide xor
$XOR_str_instruction = "Creating instructions..." ascii wide xor
$XOR_str_edge_update = "MicrosoftEdgeUpdate.exe" ascii wide xor
condition:
($IOC_SSHFS and 1 of ($str_*))
or
(3 of ($str_*))
or
(3 of ($XOR_*))
}
