Windows et Linux, mondes à part pour les ransomwares

Code, accès initial, chiffrement, persistance… Check Point met en lumière quelques particularités des ransomwares ciblant Linux.

De Windows à Linux, un monde d’écart pour les ransomwares ? Check Point a mené une étude comparative à ce sujet.

L’éditeur a examiné des échantillons issus de douze familles ciblant Linux et/ou ESXi. Nommément, BlackCat, Cl0p, Cylance, ESXiArgs, IceFire, GwisinLocker, LockBit, Maori, Monti, Rorschach, Royal et Vice Society.

Des ransomwares « minimalistes »

Souvent, le contenu du binaire est réduit. On n’y trouve parfois que le code de chiffrement. Le ransomware s’appuie alors sur des configurations et des scripts externes. Cl0p est dans ce cas, et il n’accepte qu’un paramètre : une cible à chiffrer.

Dans la même veine, l’échantillon ESXiArgs examiné n’embarque pas la clé publique RSA. On est supposé lui fournit, en paramètre, le chemin pour y accéder. L’échantillon ne peut pas ailleurs pas chiffrer tout un dossier : il faut itérer, par script, sur tous les fichiers.

La faible empreinte de ces ransomwares les rend d’autant plus difficiles à repérer. La plupart ne présentent pas d’éléments anomaux susceptibles d’aider à leur détection (exécution de commandes pour préparer le système au chiffrement, capacité à créer une forme de persistance, etc.).

Il existe des exceptions. BlackCat en fait partie (l’échantillon examiné est multiplateforme : il comprend des fonctionnalités spécifiques à Windows comme la suppression de shadow copies et la recherche de dossiers partagés). GwisinLocker aussi (il embarque une configuration chiffrée).

Beaucoup de ransomwares Linux ciblent aussi ESXi (Cylance, ESXiArgs, LockBit, Maori, Monti, Rorschach, Royal). Ils contiennent les bibliothèques nécessaires, en liaison statiques. Il arrive de tomber sur des échantillons compilés spécifiquement pour chacune de ces environnements.

Le phishing, moins approprié aux systèmes Linux

Sur Windows, les intrusions ont souvent pour origine du phishing. Sur Linux (et ESXi), l’un des vecteurs les plus communs est l’exploitation de vulnérabilités sur des services exposés. Logique vu la nature et la fonction de chacun de ces systèmes.

Il y a là aussi des exceptions. L’échantillon IceFire, par exemple, utilise une faille (CVE-2022-47986) dans une techno IBM. La version Linux de Cl0p a quant à elle, parmi ses cibles, des chemins liés à des bases de données Oracle.

Les vulnérabilités sur les systèmes Linux/ESXi occasionnent souvent le déploiement d’un webshell comme outil d’accès initial.

Le webshell, principal mécanisme de persistance

Pour établir une persistance sur les environnements Windows, on peut manipuler le registre (Ryuk, WannaCry), exploiter les tâches planifiées (REvil) ou créer des services.

Sur Linux et ESXi, il est beaucoup plus rare d’avoir des mécanismes de persistance à proprement parler. Quoique l’usage de webshells, du fait qu’il résiste aux redémarrages, devrait être considéré comme tel, souligne Check Point.

Dans le cas où l’accès se fait par latéralisation, la persistance se réduit souvent à la création de comptes utilisateurs ou à l’exfiltration d’identifiants.

Les ransomwares Linux laissent aussi des traces

En écho aux différences de nature et de fonction entre les systèmes visés, les typologies de cibles et victimes diffèrent entre Linux et Windows.

Cela transparaît dans les fichiers et dossiers sélectionnés pour chiffrement. Il est en tout cas beaucoup plus fréquent de trouver, sur les échantillons Linux, des configurations spécifiques… et sans lesquels les ransomwares ne s’exécutent pas (Cylance, LockBit, Monti, Royal). Il s’agit parfois surtout d’éviter des éléments susceptibles de corrompre le système, comme /boot, /etc et /sys.

Les impacts de type suppression de sauvegardes et désactivation des solutions de sécurité restent moins communs sur Linux. Les ransomwares laissent cependant des traces pouvant aider à la détection. Par exemple, comme sur Windows, les mutex, souvent créés avant de chiffrer pour éviter les corruptions liées à des exécutions simultanées.

LockBit utilise cette technique, créant un fichier /tmp/locked.pid. Si celui-ci se trouve déjà sur le système, l’exécution du ransomware s’interrompt. D’autres génèrent des mutex plus aléatoires, comme Gwisin.
Certains ransomwares génèrent, en outre, des fichiers de débogage, comme HelloKitty (work.log) et Monti (result.txt).

Chiffrement : OpenSSL et AES dominent

Sur Windows, il est fréquent de voir le chiffrement délégué aux API système. Sinon, les ransomwares exploitent des bibliothèques comme CryptoPP (PYSA), mbedtls (Petya), libgcrypt (Moneybird), etc.
Sur Linux, pour près de la moitié des échantillons, l’usage d’OpenSSL est majoritaire. Plusieurs familles embarquent la bibliothèque dans le binaire. Dans certains cas, les ransomwares sont développés dans des langages (Go, Rust…) pour lesquels les modules/bibliothèques natifs prédominent.

Au niveau des algorithmes, ChaCha20 et RSA dominent légèrement sur Windows. Sur Linux, la majorité des échantillons examinés utilisent AES… et ChaCha20 en première option alternative.
Sur le volet algorithmes symétriques, RSA domine. ESXiArgs est de ceux qui font exception. Il utilise Sosemanuk pour le chiffrement symétrique. Cl0p utilise quant à lui RC4 avec une clé embarquée.