En effet, ils peuvent l’utiliser pour obfusquer leur code, empêcher les utilisateurs (dans le cas des ransomwares) d’accéder à leurs fichiers et enfin pour sécuriser leur communication réseau malveillante.
Alors que les sites web et les applications adoptent de plus en plus le protocole TLS (Transport Layer Security) et communiquent via des connexions HTTPS, le trafic non chiffré attire du coup encore plus l’attention, car il est plus facile pour les analystes et les outils de sécurité d’identifier les modèles de communication malveillants dans ces sessions HTTP simples. Les créateurs de malwares le savent et ils ont fait de l’adoption du protocole TLS une priorité afin d’obfusquer le contenu de leurs communications malveillantes.
L’une des raisons pour lesquelles il est plus facile de trouver des signes d’activité malveillante dans le trafic non chiffré est que les versions récentes de malwares ont tendance à effectuer des ‘call home’ plus fréquemment qu’auparavant et, dans ce cas, envoient des volumes de plus en plus importants d’informations de profilage sur la machine et le réseau ciblés à leurs opérateurs. Après avoir identifié la victime, le malware communique de plus en plus avec son ou ses opérateurs afin d’effectuer une reconnaissance du réseau en envoyant les informations collectées à son serveur command-&-control.
Ce type de vol d’informations peut être un préalable à une attaque ciblée ultérieure, ou peut être utilisé pour faire chanter, ou encore peut être vendu à d’autres cybercriminels qui pourront en abuser de diverses manières. Sans la couche protectrice du chiffrement TLS qui obfusque le contenu de cette communication, un analyste au regard aiguisé ou bien un outil de prévention de la perte de données pourrait facilement surprendre les responsables de ce type de vol en flagrant délit, avant même que le malware ne puisse nuire à qui que ce soit.
Nous avons également observé que de plus en plus de fonctions malveillantes sont orchestrées à partir du serveur command-&-control (C2), plutôt que mises en œuvre dans le binaire du malware, et les C2 prennent des décisions sur les actions que le malware devrait lancer par la suite en fonction des données exfiltrées, augmentant ainsi le volume du trafic réseau. Les créateurs de malwares souhaitent également doter leurs fichiers binaires de nouvelles fonctionnalités et les actualiser plus souvent, augmentant également le besoin de communication réseau sécurisée. Cette technique empêche les outils de protection du réseau de repérer une infection active à l’intérieur de celui-ci chaque fois qu’il télécharge une version d’auto-mise à jour.
Utilisation du SSL/TLS par les récentes campagnes de malwares
Les malwares qui tentent médiocrement de masquer leur communication C2 peuvent être plus facilement détectés. Ainsi, de plus en plus, les cybercriminels ont eu tendance à adopter le chiffrement de la couche de transport.
Pour comprendre l’état de l’art actuel, nous avons examiné un échantillon représentatif des analyses de malwares que nous avons effectuées au cours des six derniers mois. Les analyses comprenaient des détails sur la connexion éventuelle du malware à une ou plusieurs machines sur internet. Par souci de simplicité, nous avons considéré qu’un échantillon était de type “utilisateur TLS“, dans le cadre de cette recherche, lorsque l’échantillon en question avait communiqué, pendant l’analyse, via le port 443/TCP (à savoir le port standard utilisé pour les communications HTTPS TLS chiffrées).
Parmi tous les malwares qui ont établi une sorte de connexion réseau pendant leur processus d’infection, environ 23% ont communiqué via le HTTPS, soit pour envoyer ou recevoir des données provenant du C2, soit pendant le processus d’installation lorsqu’ils sont susceptibles d’utiliser le HTTPS pour masquer le fait qu’ils récupèrent des charges virales ou des composants malveillants.
Le chiffrement du trafic réseau est plus important pour les chevaux de Troie (Trojans), en particulier les voleurs d’informations. L’objectif principal de ces derniers est de collecter autant de données que possible sur la victime, y compris des données financières sensibles, et de ne pas être détecté et surpris en flagrant délit. Parmi notre ensemble d’échantillons, les voleurs d’informations représentaient 16% du nombre total d’échantillons testés au cours de la période considérée.
Les voleurs d’informations s’appuyaient plus sur le HTTPS pour communiquer que tout autre type de malware. Même s’ils ne représentent, dans nos analyses, qu’un peu plus du huitième du total des échantillons qui ont établi une connexion Internet pendant leur processus d’infection, environ 44% des voleurs d’informations communiquent à l’aide du protocole TLS via les ports HTTPS standards.
L’utilisation du SSL/TLS permet aux malwares de masquer les commandes envoyées au client, de cacher l’exfiltration des données ou d’empêcher la détection de téléchargements de modules ou de charges virales supplémentaires. Dans cette analyse, nous avons considéré que toutes ces activités, quelles qu’elles soient, utilisaient le protocole TLS.
Ajouter encore plus de chiffrement
Mais les créateurs de malwares ne comptent pas uniquement sur le protocole TLS pour masquer la véritable nature de leurs activités. Beaucoup ajoutent une autre couche de sécurité, comme un chiffrement symétrique supplémentaire pour chiffrer leurs données, afin de mettre en place une dissimulation additionnelle au sein même du protocole TLS .
Les créateurs de malwares utilisent généralement des API de niveau supérieur pour la communication réseau, comme WinInet.dll ou URLmon.dll. Avec des API de niveau inférieur, les développeurs peuvent créer des sockets manuellement, afin de pouvoir utiliser des protocoles personnalisés, qui peuvent être plus difficiles à identifier.
Sans surprise, le taux d’adoption du protocole TLS par les ransomwares, en particulier, est bien inférieur à la moyenne de toutes les familles de malwares, car les ransomwares n’ont pas réellement besoin de masquer leurs communications, ou de masquer quoi que ce soit en général, une fois qu’ils ont causé les dégâts souhaités.
Des services légitimes utilisés pour dissimuler du contenu malveillant
Du point de vue du créateur du malware, l’utilisation d’un service légitime pour stocker et héberger du contenu malveillant présente plusieurs avantages. La première est que les services légitimes, dans presque tous les cas, utilisent le protocole TLS par défaut, et comme avantage secondaire, le contenu malveillant peut rester caché et le distributeur de malwares n’a pas besoin d’obtenir son propre certificat TLS pour son site web.
L’utilisation malveillante de services légitimes tels que Pastebin, Dropbox ou d’autres services de stockage Cloud a également eu tendance à se développer. Au cours des six derniers mois, 0,8% des échantillons que nous avons analysés ont communiqué directement avec Pastebin, y compris les chevaux de Troie, les RAT et les infostealers.
Certaines des utilisations de ces Pastebin de type mal-paste incluent des téléchargeurs (downloaders) de 2ème niveau, des scripts VBA ou PowerShell, des fichiers PE malveillants ou des listes d’URL au niveau desquelles d’autres contenus peuvent être récupérés. Dans la plupart des cas, nous avons observé que le contenu mal-paste était également codé avec de simples méthodes XOR, RC4 ou Base64 pour obfusquer davantage leur véritable nature.
De récentes familles de malwares assez répandues utilisent le SSL/TLS
TrickBot
Le principal objectif de TrickBot est de voler des informations sur la machine victime. Il collecte des données concernant le système, l’utilisateur, leurs navigateurs, le réseau utilisé par l’ordinateur, les comptes de messagerie appartenant à la victime, et en particulier les mots de passe bancaires ou financiers ou d’autres identifiants.
Handshake SSL/TLS de TrickBot
Cette famille se distribue avec sa propre charge virale malspam et peut également être distribuée par d’autres malwares, comme Emotet. Les campagnes de spam efficaces d’Emotet se sont avérées être une collaboration réussie avec TrickBot.
TrickBot applique plusieurs techniques pour échapper aux détections, notamment le Process Hollowing ou la désactivation de certains outils de sécurité. Il a une structure modulaire, ayant plusieurs modules pour voler, se déplacer latéralement afin de mieux se propager, ou encore pour offrir un accès à distance aux attaquants. TrickBot télécharge généralement ses modules à l’aide du HTTPS, puis injecte les modules dans une instance du composant Windows légitime svchost.exe. Ensuite, TrickBot exfiltre toutes les données que le malware peut collecter avec une méthode HTTPS POST. En plus d’utiliser le port TLS standard 443, dans certains cas, il utilise des ports inhabituels et non standards tels que le 449/TCP, pour communiquer via le protocole TLS.
Le binaire TrickBot utilise WinHttpOpenRequest, WinHttpSendRequest dans WINHTTP.dll, avec les méthodes GET et POST, pour télécharger des modules ou envoyer des informations sensibles au serveur. Les données envoyées au C2 incluent l’ID groupe et l’ID client de la distribution du malware spécifique et une ou plusieurs commandes. Il utilise CryptoAPI pour chiffrer davantage les données exfiltrées.
IcedID
IcedID est un cheval de Troie bancaire qui effectue des attaques par injection web contre les navigateurs afin de voler des informations. Il s’injecte dans svchost.exe et peut se propager latéralement à travers le réseau pour infecter d’autres machines.
Trafic IcedID filtré au niveau de ses messages SSL/TLS Client Hello
Il utilise WINHTTP.DLL pour effectuer sa communication réseau, tout comme TrickBot. Le SSL/TLS est utilisé dans la communication vers et depuis le serveur C2. Il télécharge également ses fichiers de configuration via le protocole TLS, et le corps des réponses est également chiffré à l’aide de la méthode RC4. Outre le protocole TLS, il peut utiliser des requêtes HTTP GET non chiffrées pour transmettre des données volées (comme on peut le voir sur la capture d’écran ci-dessus concernant une capture de paquet). Les requêtes incluent l’ID du Bot et le numéro de la version interne du malware.
Dridex
Dridex est un cheval de Troie bancaire, propagé par des campagnes de phishing et utilisé en tant que charge virale du botnet Emotet. Il a été repéré pour la première fois en 2011 et il est toujours en développement constant. Les exemples récents utilisent plusieurs types de techniques d’injection de code, comme Atom Bombing ou Process Hollowing, ciblant des exécutables Windows légitimes.
Dridex a un framework modulaire; le module de chargement télécharge le module principal, qui peut exécuter plusieurs fonctions de base parallèlement au téléchargement de modules supplémentaires. Il a la capacité de voler des identifiants, des cookies, des certificats, des frappes clavier et même de prendre des captures d’écran. Dridex utilise fréquemment le HTTPS via le port 443 pour télécharger des modules de charge virale ou envoyer les données collectées. Les données exfiltrées peuvent en outre être chiffrées à l’aide du RC4, si l’attaquant le souhaite.
Un échantillon Dridex a communiqué avec les ports et adresses IP suivants via la méthode POST et à l’aide de WinInet.dll en utilisant les fonctions HttpOpenRequestW, HttpSendRequestW habituelles.
Dridex C2s
Le protocole TLS est là pour durer
Comme nous l’avons vu, le protocole TLS ne distribue pas les malwares avec une sécurité garantie à 100%, dans la mesure où il existe des outils d’inspection du réseau qui sont capables de scruter l’intérieur du tunnel chiffré, d’identifier et de bloquer le trafic malveillant. La proportion de malwares mettant en œuvre le protocole TLS pour protéger ses communications s’est fortement développée et continuera probablement à augmenter. Cette tendance soulève de fortes inquiétudes quant à la capacité de détecter et de se défendre contre l’adoption croissante, par des acteurs malveillants, de la sécurité de la couche de transport. Les familles de malwares susmentionnées comprennent les menaces les plus répandues et les plus dangereuses de ces dernières années, et elles ne devraient pas disparaître à l’avenir.
Pour vous protéger, il est important d’inspecter le trafic réseau et de vérifier les détails du certificat TLS des communications HTTPS. Vous devez prêter une attention particulière aux volumes inhabituels ou inattendus de trafic HTTPS vers des domaines inconnus ou à l’utilisation de certificats TLS invalides ou falsifiés, en particulier lors des transactions financières et lors de la saisie d’informations personnelles ou sensibles au niveau des navigateurs. Investissez dans une solution de sécurité réseau qui peut effectuer ce type d’inspections en matière de communication TLS et, idéalement, qui peut communiquer et se synchroniser avec votre solution antivirus, votre VPN, vos pare-feux et/ou votre IDS/IPS pour stopper les communications réseau malveillantes suspectes ou connues.
Indicateurs de Compromission (IoC)
Les exemples suivants ont été utilisés pour générer du trafic réseau pris comme exemple dans cet article.
Trickbot :
- 2baf66b83d6cd0b52e3dae66c42a0a3a3c279319c68b77e02141a2c355698409
- e17149663a7d2f9ec19d28102d8379b764c5dd83c1ec8c7278300c58893e7600
IcedID :
- da7d9687c5776eecc90f7d11dbe32623f9aa1f44fc2eff5088e0540014adcb0e
- f09fe918108769ef3200e7978d983722b407b26cc2d3fe07d3804e8e331a0986
Dridex :
- 585e245b0ba761e2ec27bf33e02dec44b888469b868dddd65d2511bfd5155917
- 8be38d81426e338c5daa60e35776000f5d199f562c74a57a55356861ba21703d
Billet inspiré de Nearly a quarter of malware now communicates using TLS, sur le Blog Sophos.