L’équipe Sophos X-Ops Incident Response a examiné les tactiques d’un groupe de ransomware appelé Mad Liberator. Il s’agit d’un acteur malveillant relativement nouveau, apparu pour la première fois à la mi-juillet 2024. Dans cet article, nous examinerons certaines techniques utilisées par le groupe, impliquant la populaire application d’accès à distance Anydesk. Nous documenterons les tactiques d’ingénierie sociale intéressantes utilisées par celui-ci et fournirons des conseils sur la manière de minimiser votre risque de devenir une victime et, pour les investigateurs, de détecter l’activité potentielle de ce dernier.
Avant de commencer, nous devons noter qu’Anydesk est un logiciel légitime utilisé de manière abuse par les attaquants dans le cas que nous allons vous présenter. En effet, ces derniers utilisent cette application de manière malveillante et nous détaillerons ci-dessous comment ils procèdent, mais il est probable que n’importe quel programme d’accès à distance parviendrait à servir leurs objectifs. Nous vous signalons également que les SophosLabs ont mis en place une détection, Troj/FakeUpd-K, pour le binaire en question.
Présentation de Mad Liberator
L’activité observée par Sophos X-Ops jusqu’à présent indique que Mad Liberator se concentre sur l’exfiltration de données : d’après notre propre expérience, nous n’avons encore vu aucun incident utilisant le chiffrement de données dans lequel Mad Liberator était impliqué. Néanmoins, les informations sur watchguard.com suggèrent que le groupe utilise le chiffrement de temps en temps et se livre également à de la double extorsion (vol de données, puis chiffrement des systèmes de la victime et enfin menace de divulgation des données volées si la victime ne paie pas pour le déchiffrement).
Comme la plupart des acteurs malveillants qui effectuent des exfiltrations de données, Mad Liberator exploite un site de fuite de données sur lequel il publie les informations détaillées des victimes, dans le but d’exercer une pression supplémentaire sur ces dernières pour qu’elles paient. Le site affirme que les fichiers peuvent être téléchargés “gratuitement”.
Figure 1 : Site de divulgation de Mad Liberator.
Il est intéressant de noter que Mad Liberator utilise des techniques d’ingénierie sociale pour obtenir l’accès à l’environnement, en ciblant les victimes qui utilisent des outils d’accès à distance installés sur les systèmes endpoint et les serveurs. Anydesk, par exemple, est couramment utilisé par les équipes informatiques pour gérer leurs environnements, en particulier lorsqu’elles travaillent avec des utilisateurs ou des appareils distants.
Comment se déroule l’attaque ?
Anydesk fonctionne en attribuant un identifiant (ID) unique, en l’occurrence une adresse à dix chiffres, à chaque appareil sur lequel l’application est installée. Une fois cette dernière installée sur un appareil, un utilisateur peut soit demander à accéder à un appareil distant pour prendre le contrôle en saisissant l’ID, soit un utilisateur peut inviter un autre utilisateur à prendre le contrôle de son appareil via une session à distance.
Figure 2 : Une session Anydesk avec l’adresse à dix chiffres affichée de manière bien visible.
Nous ne savons pas à ce stade comment, ou bien si, l’attaquant a ciblé un identifiant Anydesk particulier. En théorie, il est possible de simplement parcourir les adresses potentielles jusqu’à ce qu’une personne accepte une demande de connexion ; cependant, avec potentiellement 10 milliards de nombres à 10 chiffres, cette approche semble quelque peu inefficace. Dans un cas investigué par l’équipe Incident Response, nous n’avons trouvé aucune indication d’un contact entre l’attaquant Mad Liberator et la victime avant que cette dernière ne reçoive une demande de connexion Anydesk non sollicitée. L’utilisateur n’était pas un membre du personnel haut placé ou exposé publiquement et il n’y avait aucune raison évidente pour qu’il soit spécifiquement ciblé.
Lorsqu’une demande de connexion Anydesk est reçue, l’utilisateur voit la fenêtre contextuelle affichée dans la figure 3. L’utilisateur doit alors autoriser la connexion avant qu’elle puisse être complètement établie.
Figure 3 : Une demande émanant d’une personne dénommée “User (Utilisateur)” pour se connecter via Anydesk ; comme les administrateurs d’Anydesk le savent, mais pas forcément les utilisateurs finaux, n’importe qui peut choisir n’importe quel nom d’utilisateur lors de la configuration d’Anydesk, de sorte qu’un attaquant pourrait même s’appeler “Support technique” ou bien utiliser une appellation similaire.
Dans le cas traité par notre équipe IR, la victime savait qu’Anydesk était utilisé par le service informatique de son entreprise. Elle a donc considéré que la demande de connexion entrante n’était qu’une instance habituelle d’une maintenance effectuée par le service informatique et a donc cliqué sur “Accept (Accepter)“.
Une fois la connexion établie, l’attaquant a transféré un binaire sur l’appareil de la victime et l’a exécuté. Dans nos investigations, ce fichier a été intitulé “Microsoft Windows Update“, avec le hachage SHA256 suivant :
f4b9207ab2ea98774819892f11b412cb63f4e7fb4008ca9f9a59abc2440056fe
Ce binaire était un programme très simple qui affichait un écran de démarrage imitant un écran Windows Update. L’écran était animé, donnant l’impression que le système était en cours de mise à jour, comme le montre la figure 4.
Figure 4 : Un écran Windows Update bien trop banal… n’est-ce pas ?
Ce programme n’effectuait aucune autre activité, ce qui rendait peu probable qu’il soit immédiatement détecté comme malveillant par la plupart des packages anti-malware (Sophos a développé une détection [Troj/FakeUpd-K] pour ce binaire particulier et continuera à surveiller les développements à son sujet).
À ce stade, pour empêcher que la ruse ne soit découverte et stoppée, l’attaquant a pris une mesure supplémentaire. Étant donné que ce programme simple aurait pu être fermé si l’utilisateur avait appuyé sur la touche “Échap“, ce dernier a utilisé une fonctionnalité d’Anydesk pour désactiver la saisie à partir du clavier et de la souris de l’utilisateur.
Étant donné que la victime n’était plus en mesure d’utiliser son clavier et que l’écran ci-dessus semblait afficher une activité inoffensive pour tout utilisateur Windows, elle n’était donc pas au courant des actions que l’attaquant lançait en arrière-plan, et elle n’aurait même pas pu les stopper facilement si ces dernières s’étaient avérées suspectes.
L’attaquant a ensuite accédé au compte OneDrive de la victime, qui était lié à l’appareil, ainsi qu’aux fichiers stockés sur un serveur central et accessibles via un partage réseau mappé. À l’aide de la fonction Anydesk FileTransfer, l’attaquant a volé et exfiltré ces fichiers hors de l’entreprise. Ce dernier a ensuite utilisé Advanced IP Scanner pour déterminer s’il existait d’autres appareils intéressants qui pouvaient être exploités dans le même sous-réseau (en fait, il ne s’est pas déplacé latéralement vers d’autres appareils).
Une fois les fichiers volés et sous son contrôle, l’attaquant a ensuite exécuté un autre programme qui a créé de nombreuses demandes de rançon. Il est intéressant de noter que ces demandes de rançon ont été générées à plusieurs endroits différents au niveau d’un réseau partagé qui était mappé sur l’appareil, plutôt que sur l’appareil de la victime lui-même. Ces demandes de rançon informaient que des données avaient été volées et fournissaient des détails sur la manière avec laquelle la victime devait payer la rançon pour empêcher la divulgation de ces fichiers (de telles tactiques ne sont que trop familières pour les lecteurs de notre enquête sur les tactiques de pression actuellement utilisées par les gangs de ransomware).
Figure 5 : La demande de rançon reçue par la victime ; notez bien les menaces concernant une potentielle atteinte à la réputation et un éventuel non respect de la réglementation, et notez également qu’aucun montant de rançon n’est mentionné.
Le faux écran Windows Update a empêché les actions de l’attaquant d’être visibles au niveau de l’écran de la victime. L’attaque a duré près de quatre heures, à l’issue desquelles l’attaquant a fermé le faux écran de mise à jour et mis fin à la session Anydesk, redonnant ainsi le contrôle de l’appareil à la victime. Nous avons noté que le binaire était déclenché manuellement par l’attaquant ; sans tâche planifiée ni automatisation en place pour l’exécuter à nouveau une fois l’acteur malveillant parti, le fichier est simplement resté sur le système concerné.
Leçons apprises et mesures de mitigation
Il s’agissait d’une attaque simple qui reposait sur le fait que la victime pensait que la requête Anydesk faisait partie de son activité quotidienne. D’après nos investigateurs, l’attaque n’a impliqué aucun effort supplémentaire en matière d’ingénierie sociale de la part de l’attaquant : aucun contact par email, aucune tentative de phishing, etc. En tant que tel, cet exemple souligne l’importance d’une formation continue et d’une mise à jour constante du personnel et indique que les organisations doivent définir et diffuser une politique claire concernant la manière avec laquelle les services informatiques vous contacteront et organiseront des sessions à distance.
Au-delà de la formation des utilisateurs, nous recommandons fortement aux administrateurs de mettre en œuvre les listes de contrôle d’accès Anydesk pour autoriser uniquement les connexions à partir d’appareils spécifiques afin de minimiser considérablement le risque de ce type d’attaque. AnyDesk fournit des conseils très précieux sur la manière de procéder, ainsi que des mesures de sécurité dans le lien suivant :
Avec des conseils supplémentaires disponibles ici :
- https://blog.anydesk.com/the-ultimate-guide-to-anydesks-security-features/
- https://anydesk.com/en/security
Une procédure à suivre destinée aux investigateurs est disponible à la fin de cet article.
Conclusion
Les groupes de ransomware se développent et déclinent constamment, et Mad Liberator pourrait s’avérer être un nouvel acteur important, ou bien juste un feu de paille de plus. Cependant, les tactiques d’ingénierie sociale utilisées par le groupe dans le cas décrit ci-dessus sont remarquables mais elles ne sont toutefois pas uniques. Les attaquants continueront toujours à développer et à employer diverses tactiques pour tenter d’exploiter à la fois les comportements humains et les couches techniques de sécurité.
Il peut s’avérer difficile de trouver un équilibre entre sécurité et convivialité lors de la mise en œuvre d’outils dans un environnement donné, en particulier lorsque ces outils facilitent l’accès à distance pour les personnes chargées de s’occuper des systèmes critiques de l’entreprise. Cependant, nous recommandons toujours que lors du déploiement des applications sur un réseau, en particulier celles qui peuvent être exploitées pour obtenir un accès à distance aux appareils, un examen attentif des recommandations de sécurité de l’éditeur soit réalisé. Lorsque ces recommandations ne sont pas suivies, ce choix doit être documenté dans le cadre de votre processus de gestion des risques afin qu’il puisse être continuellement révisé, ou que d’autres mesures de mitigation puissent être mises en place pour garantir qu’il reste dans les limites acceptables en matière de gestion des risques au niveau de votre organisation.
Annexe : Investigations impliquant Mad Liberator
Si vous investiguez un incident au cours duquel vous pensez que des attaquants ont pu exploiter Anydesk, recherchez les données utiles sur les événements et les connexions stockées dans les fichiers suivants :
- C:\ProgramData\AnyDesk\connection_trace.txt
- C:\ProgramData\AnyDesk\ad_svc.trace
- C:\Users\%\AppData\Roaming\AnyDesk\ad.trace
Le fichier connection_trace.txt contient uniquement l’ID des adresses concernant les connexions récentes et peut ne pas être très utile en soi. Mais ce fichier vous permet au moins de préciser l’identifiant (ID) incriminé.
Figure 6 : Un aperçu de connection_trace.txt, avec des informations sur le résultat de chaque événement.
Il existe quatre états possibles pour chaque connexion :
- “REJECTED” : l’utilisateur final a rejeté une demande de connexion.
- “User” : l’utilisateur final a accepté une demande de connexion.
- “Passwd” : un mot de passe a été saisi par le système distant pour obtenir la demande d’accès.
- “Token” : l’option “Login Automatically (Connexion automatique)” a été vérifiée par le système distant.
Les fichiers ad_svc.trace et ad.trace contiennent de nombreux détails assez précis. Ceux-ci peuvent être ouverts et visualisés avec un éditeur de texte tel que le Bloc-notes et, avec d’autres événements, contiennent également des données de connexion. Le fichier ad_svc.trace contient des détails sur les adresses IP sources des connexions distantes.
Figure 7 : Un aperçu de ad_svc.trace ; une connexion douteuse est mise en évidence dans l’image.
Le fichier ad.trace contient des logs relatifs aux transferts de fichier et à des événements tels que l’endroit où la ‘saisie utilisateur’ a été désactivée.
Figure 8 : Les options concernant la ‘saisie utilisateur’ sont désactivées.
Figure 9 : Les événements de transfert de fichier.
Bien que les logs indiquent le dossier et le nombre de fichiers transférés lors de l’exfiltration des données, malheureusement, ces derniers ne détaillent pas chaque nom de fichier.
Si Sophos Intercept X est installé, la collecte de ces données est simplifiée. La requête OSquery suivante peut être utilisée dans Live Discover au niveau du tableau de bord Sophos Central :
SELECT
strftime('%Y-%m-%dT%H:%M:%S', substr(grep.line, instr(grep.line, 'info') + 5, 19)) AS Datetime,
grep.path,
CASE
WHEN grep.pattern = 'Logged in from' THEN 'Login'
WHEN grep.pattern = 'Preparing files' THEN 'File Transfer from this Host'
WHEN grep.pattern = 'Accepting from' THEN 'Accepted Connection Request'
WHEN grep.pattern = 'Incoming session request:' THEN 'Incoming Session Request'
WHEN grep.pattern = 'Remote OS:' THEN 'Remote OS'
WHEN grep.pattern = 'Disabling user input.' THEN 'Disable Mouse and Keyboard'
WHEN grep.pattern = 'Download started' THEN 'File Transfer to this Host'
WHEN grep.pattern = 'Received a sysinfo request.' THEN 'System Information Request'
WHEN grep.pattern = 'Authenticated with permanent token' THEN 'Authenticated with Token'
WHEN grep.pattern = 'Authenticated with correct passphrase' THEN 'Authenticated with Password'
WHEN grep.pattern = 'Profile was used:' THEN 'Profile Assigned'
END AS 'Operation',
grep.line as Data
FROM file
CROSS JOIN grep ON (grep.path = file.path)
WHERE
(
file.path LIKE 'C:\ProgramData\AnyDesk\ad_svc.trace'
OR file.path LIKE 'C:\Users\%\AppData\Roaming\AnyDesk\ad.trace'
)
AND
(
--AnyDesk
grep.pattern = 'Logged in from'
OR grep.pattern = 'Preparing files'
OR grep.pattern = 'Accepting from'
OR grep.pattern = 'Incoming session request:'
OR grep.pattern = 'Remote OS:'
OR grep.pattern = 'Disabling user input.'
OR grep.pattern = 'Download started'
OR grep.pattern = 'Received a sysinfo request.'
OR grep.pattern = 'Authenticated with permanent token'
OR grep.pattern = 'Authenticated with correct passphrase'
OR grep.pattern = 'Profile was used:'
)
ORDER BY Datetime DESC
La requête permet même de trier les données dans une table utilisable, comme le montre la figure 10.
Figure 10 : La sortie de la requête OSquery présentée ci-dessus, sous un format tableau plus pratique.
Remerciements
Harshal Gosalia, Ollie Jones et Andy French ont contribué à cette recherche.
Billet inspiré de Don’t get Mad, get wise, sur le Blog Sophos.
