Des hackers ont trouvé le moyen d’infecter les journaux d’événements Windows avec des malwares sans fichier, ont découvert des chercheurs en sécurité.
Le 4 mai, des chercheurs de Kaspersky ont révélé « une nouvelle cachette pour les malwares sans fichier ». Au cours d’une campagne « très ciblée », les hackers ont utilisé les journaux d’événements Windows pour injecter des charges utiles en shellcode et opérer furtivement.
Cette nouvelle approche est très sophistiquée, mais pourrait malgré tout devenir populaire, puisqu’elle semble particulièrement efficace pour injecter des DLL malveillantes et échapper à la détection. Les chercheurs de Kaspersky ont découvert que les attaquants utilisaient divers outils, notamment des solutions personnalisées et commerciales comme Cobalt Strike, ainsi qu’un nouvel ensemble d’outils utilisé par les hackers.
Les chercheurs ont déclaré qu’il s’agissait clairement du travail d’un acteur malveillant avancé, mais n’ont pas pu attribuer la campagne à un groupe APT. La campagne est pour l’instant baptisée « SilentBreak », d’après le nom de l’ensemble d’outils utilisé par les hackers.
À lire aussi : Comment Cobalt Strike est devenu l’outil préféré des hackers
Techniques d’attaque de SilentBreak
Les chercheurs ont été frappés par « la variété des techniques et des modules de la campagne » et ont donc établi une classification pour analyser les modules un par un :
Toutes ces étapes ont été possibles parce que les hackers ont réussi à inciter une cible à télécharger une archive .rar infectée sur file.io, un site web légitime. Ils ont ensuite pu diffuser un module Cobalt Strike signé numériquement afin d’exfiltrer des données sensibles.
Comment les attaquants ont injecté du code dans les journaux Windows
Les chercheurs ont découvert des charges utiles malveillantes dans les journaux d’événements Windows pour les services de gestion des clés (KMS) :
Pour réaliser la première étape de leur campagne, les hackers ont utilisé un dropper de malware personnalisé qui copie l’exécutable légitime Windows Error Reporting (WerFault.exe) dans C:\Windows\Tasks, puis dépose un binaire malveillant dans le même répertoire :
Cette technique, appelée DLL hijacking, consiste à remplacer une DLL requise par une DLL malveillante et à la placer dans le même répertoire que l’application ciblée. Le système utilise les fichiers DLL (Dynamic Link Library) pour stocker certaines ressources nécessaires à l’application et les charge automatiquement.
Le nouveau WerFault.exe est ensuite configuré pour s’exécuter automatiquement, ce qui crée une « valeur Windows Problem Reporting dans la branche de registre système Windows Software\Microsoft\Windows\CurrentVersion\Run ».
Le dropper recherche ensuite les journaux appartenant à une catégorie précise (0x4142) et dont KMS est la source. S’il n’en trouve aucun, le shellcode chiffré est écrit par blocs de 8 Ko dans les journaux d’événements.
Les chercheurs de Kaspersky ont étudié le code et découvert qu’il agissait comme un proxy pour intercepter tous les appels à la bibliothèque d’origine (la bibliothèque légitime) et préparer les étapes suivantes, ce qui indique une procédure itérative.
Les hackers se sont concentrés sur la furtivité
La priorité absolue de cette opération était évidemment de rester indétectable. Pour y parvenir, les attaquants ont utilisé diverses techniques anti-détection, notamment :
- un certificat numérique légitime pour signer les fichiers malveillants
- des copies de l’exécutable légitime (Werfault.exe) configurées pour s’exécuter automatiquement
- des wrappers anti-détection compilés dans divers langages, comme Go ou C++
- des noms de fonctions obfusqués dans le code
- des instructions malveillantes fragmentées en blocs de shellcode dans les journaux d’événements Windows
L’analyse du malware réalisée par Kaspersky est particulièrement remarquable et détaillée. Les chercheurs ont dû écrire des scripts personnalisés pour déchiffrer toutes les zones dissimulées.
Selon les chercheurs, l’aspect le plus inhabituel et novateur de la campagne SilentBreak est le « shellcode chiffré divisé en blocs de 8 Ko et enregistré dans la partie binaire du journal d’événements ».
Au cours de la deuxième étape, les hackers ont utilisé des lanceurs de déchiffrement personnalisés pour Cobalt Strike afin de déchiffrer le shellcode, de le mapper en mémoire et, finalement, d’exécuter les instructions malveillantes et de déployer le malware.
À lire aussi : Comment les hackers échappent à la détection
La campagne reposait sur des chevaux de Troie
Les attaquants ont utilisé deux types de chevaux de Troie :
- cheval de Troie basé sur HTTP avec C2 (commande et contrôle)
- cheval de Troie basé sur des canaux nommés
Le shellcode chiffré présent dans les journaux d’événements contenait des paramètres très précis, comme l’adresse du cheval de Troie de l’étape suivante ou les hachages des noms de fonctions utilisés dans le cheval de Troie.
Il y avait également des chaînes inutilisées comme « dave » et la constante « 4 ». Les chercheurs estiment que le lanceur pourrait prendre en charge d’autres modules nécessitant des paramètres supplémentaires, ce qui pourrait expliquer ces artefacts.
Le cheval de Troie HTTP semble générer des informations permettant l’identification, comme le nom de l’ordinateur, les adresses IP locales, la version du système d’exploitation, l’architecture (x86 ou x64) et les valeurs de MachineGUID.
Ces informations servent ensuite à envoyer des instructions ciblées par le canal de communication malveillant (C2).
Selon les chercheurs, le cheval de Troie basé sur des canaux nommés dispose d’un « système de commande plus évolué », permettant notamment d’élever les privilèges, de prendre des captures d’écran ou de mesurer le temps d’inactivité.
Comment se protéger contre les attaques visant les journaux d’événements
Un tel niveau de préparation et le temps consacré à l’écriture de modules et de déchiffreurs personnalisés suggèrent l’œuvre d’un groupe de hackers chevronné qui n’était toujours pas identifié au moment de la rédaction.
Il n’y a pas grand-chose à faire pour anticiper des attaques aussi médiatisées, et les antivirus ou les pare-feu intégrés ne sont probablement pas capables de les détecter. Vous pouvez toutefois prendre des mesures concrètes, comme utiliser des solutions EDR et autres solutions de sécurité des terminaux afin d’augmenter vos chances de détecter les activités inhabituelles et suspectes, en particulier si ces solutions disposent d’un composant comportemental.
Une architecture zero trust peut également contribuer à contenir l’infection, car, dans le cas présent par exemple, les hackers avaient élaboré une stratégie pour diffuser leur malware et répéter le cycle d’infection.
Les éditeurs de solutions de sécurité et les bases de connaissances comme MITRE ATT&CK devraient ajouter cette nouvelle approche à leurs catalogues dans les mois à venir. Quoi qu’il en soit, ce serait une bonne idée pour aider les équipes de sécurité à cartographier la technique à des fins de renseignement sur les menaces.
À lire ensuite :