Depuis novembre 2023, un groupe de pirates exploite 2 failles de sécurité zero-day présentes dans les firewalls Cisco pour compromettre des infrastructures gouvernementales dans le monde entier. Faisons le point sur cette menace.
Si vous utilisez un firewall Cisco ASA (Adaptive Security Appliance ou Cisco FTD (Firepower Threat Defense), vous devriez lire cette alerte de sécurité avec une attention particulière. Un groupe de pirates, traqués sous le nom UAT4356 par Cisco Talos, et STORM-1849 par Microsoft, a compromis des firewalls vulnérables au début du mois de novembre 2023, dans le cadre d'une campagne de cyberespionnage baptisée "ArcaneDoor".
Dans le cadre de ces attaques, le groupe de pirates a exploité deux vulnérabilités en tant que failles de sécurité zero-day :
CVE-2024-20353 : un attaquant distant non authentifié peut provoquer un déni de service sur l'appareil.
CVE-2024-20359: un attaquant local authentifié peut exécuter un code arbitraire avec les privilèges "root", ce qui implique de compromettre l'appareil au préalable.
Ce n'est qu'en janvier 2024 que Cisco a pris connaissance de la campagne ArcaneDoor. Mais, d'après les chercheurs en sécurité de chez Cisco, les attaquants ont développé et testé des exploits pour ces deux failles zero-day en juillet 2023. Le vecteur d'attaque initial reste inconnu à ce jour.
Sur les appareils Cisco compromis et sur lesquels ils avaient la main, les pirates ont déployé des logiciels malveillants inconnus jusqu'ici. Le premier implant se nomme "Line Dancer" et il permet d'exécuter du code en mémoire pour désactiver la journalisation, activer l'accès distant ou encore exfiltrer les paquets capturés.
Le second implant se nomme "Line Runner" et il s'agit d'une porte dérobée persistante permettant l'exécution de code Lua sur les équipements, tout en étant discret et difficilement détectable.
Dans le rapport de Cisco Talos, nous pouvons lire : "UAT4356 a déployé deux portes dérobées dans le cadre de cette campagne, "Line Runner" et "Line Dancer", qui ont été utilisées collectivement pour mener des actions malveillantes sur la cible, notamment la modification de la configuration, la reconnaissance, la capture/exfiltration du trafic réseau et, éventuellement, le déplacement latéral."
Cisco a publié des correctifs de sécurité
Cisco a mis en ligne des correctifs de sécurité pour permettre aux entreprises de se protéger de ces failles de sécurité importantes, déjà exploitées dans le cadre de la campagne de cyberespionnage menée par le groupe UAT4356.
"Cisco recommande vivement à tous ses clients d'effectuer une mise à niveau vers les versions logicielles patchées.", peut-on lire sur le site de Cisco.
En complément de l'installation du correctif de sécurité, Cisco vous recommande de surveiller les journaux de système à la recherche d'une activité suspecte. Il peut s'agir d'un redémarrage non programmé de l'appareil, d'un changement de configuration ou encore de connexions suspectes.
Pendant 5 ans, des pirates sponsorisés par l'État chinois ont espionné le groupe automobile Volkswagen ! Pendant cette période, ils ont dérobé des milliers de documents confidentiels au sujet des futurs véhicules électriques de la marque, mais pas seulement...
19 000, c'est le nombre de documents qu'est parvenu à dérober un groupe de pirates, entre 2010 et 2015. Cette information a été révélée il y a quelques jours grâce à des journalistes allemands parvenus à obtenir des documents internes évoquant cet espionnage important. Pour être plus précis, le 20 avril 2024, les médias allemands ZDF et Der Spiegel ont publié des articles à ce sujet.
Un groupe de pirates lié à la Chine ?
Même si la Chine n'est pas directement accusée de cet acte de cyberespionnage, tout porte à croire qu'elle en est à l'origine. En effet, il y a plusieurs indices qui vont dans ce sens, notamment la méthodologie employée par les pirates et le fait que les adresses IP utilisées par les pirates soient associées à la Chine. Bien qu'il n'y ait pas de preuve réelle, voici ce que l'on peut lire dans l'article du média ZDF : "Nous avons pu remonter l'adresse IP jusqu'à Pékin, et même jusqu'à l'Armée populaire de libération (APL)."
Par ailleurs, les pirates ont utilisé deux logiciels espions habituellement utilisés par les acteurs étatiques chinois : "China Chopper" et "PlugX". Par exemple, China Chopper est un web shell découvert pour la première fois en 2012 et utilisé pour obtenir la persistance sur un système compromis.
À quoi correspondent les documents volés ?
Au total, les pirates auraient volé environ 19 000 documents. Mais, alors, à quoi correspondent-ils ? Au-delà des informations au sujet des véhicules électriques de Volkswagen, les pirates ont mis la main sur d'autres documents, car ce n'était pas leur cible initiale. Parmi les objectifs identifiés des pirates, il y avait :
Le développement de moteurs à allumage commandé
Le développement de boîtes de vitesses
Les boîtes de vitesses à double embrayage
Par ailleurs, des documents relatifs aux boites de vitesses automatiques, aux travaux effectués sur les piles à combustibles ou encore l'e-Mobilité, ont été dérobés par les cybercriminels.
Cette affaire est clairement de l'espionnage industriel et les documents volés ont pu participer à donner un avantage concurrentiel à la Chine, si elle est bien à l'origine de cette attaque. Ceci est d'autant plus vrai que le groupe Volkswagen comprend également d'autres marques comme Audi, Lamborghini, MAN, Porsche, Skoda et Bentley.
Je vous propose dans cet article un writeup du Sherlocks Litter proposé par Hack The Box. Cette investigation nous permettra notamment de manipuler Wireshark pour explorer un cas de protocol tunneling via le DNS : une technique utilisée pour faire communiquer discrètement un système compromis avec le serveur de contrôle distant d'un attaquant.
Les Sherlocks sont des challenges d'investigation numérique/forensic mis à disposition par la plateforme Hack The Box. Dans cet article, nous allons détailler la démarche qui permet de résoudre le Sherlocks Litter, de difficulté "Facile". Cet article sera notamment l'occasion de comprendre comment peut se dérouler concrètement une cyberattaque, et quels sont les modes opératoires des attaquants et des analystes en cybersécurité.
Cette solution est publiée en accord avec les règles d'HackThebox et ne sera diffusée que lorsque le Sherlocks en question sera indiqué comme "Retired".
Technologies abordées
Windows, DNS, protocol tunneling
Outils utilisés
Wireshark, python
Retrouvez tous nos articles Hack The Box via ce lien :
Dans le cadre de l'investigation, un contexte et une archive sont mis à disposition :
D'après les éléments de contexte qui nous sont fournis, l'hôte ciblé semble être utilisé pour tout et n'importe quoi et par n'importe qui. Cela ne va certainement pas nous aider à comprendre ce qui est légitime de ce qui ne l'est pas. Également, nous apprenons que des données de l'entreprise y ont été volées.
Nous commençons donc par ouvrir l'archive à sur notre Kali Purple fraîchement installée. À l'intérieur, un fichier Wireshark, un célèbre outil d'analyse réseau :
III. Investigation numérique : le cas Litter
A. Tâche n°1: Identifier le protocole utilisé
Énoncé - Task 1 : At a glance, what protocol seems to be suspect in this attack?
La première tâche consiste à identifier le protocole qui semble avoir été utilisé pour la réalisation de l'attaque. Wireshark nous permet d'avoir des statistiques intéressantes concernant la volumétrie des protocoles au sein d'un même fichier ".pcap" :
Si l'on cherche les protocoles les plus utilisés, 4 candidats sont intéressants : les protocoles UDP "QUIC IETF" et "DNS", ainsi que les protocoles TCP "TLS" et "HTTP".
Après quelques recherches, je comprends que QUIC IETF est censé être un "nouveau" protocole de transport (comme UDP ou TCP) : QUIC: A UDP-Based Multiplexed and Secure Transport. Intéressant, mais un peu trop obscure pour un challenge "facile". Il semble également complexe d'investiguer sur des échanges chiffrés TLS. Ce qui nous oriente sur deux candidats : HTTP ou DNS.
Si l'on effectue un filtre sur le protocole HTTP avec la fonctionnalité "Conversations" de Wireshark, nous pouvons très rapidement isoler les hôtes avec lesquels des échanges HTTP ont eu lieu :
On peut noter que l'adresse IP avec laquelle le serveur compromis a le plus discuté est "13.107.4.50". Les autres échanges comportent trop peu de paquets pour nous intéresser. Renseignons-nous sur cette adresse IP à l'aide de la commande "whois" :
Notre hôte compromis à interrogé un point d'entrée "/msdownload/" sur une adresse IP appartenant à Microsoft. De toute évidence, il s'agit d'échanges en rapport avec les mises à jour Windows.
Attention : dans la réalité, les attaquants peuvent héberger ou utiliser des services Microsoft/Cloud pour leurs actions malveillantes, ils profitent alors du crédit et de la confiance accordés à ces services/IP/plateformes par les blues team et les solutions de sécurité. Je pense notamment à l'hébergement de service C&C (Command and Control) par Azure ou l'utilisation de machines Azure compromises comme intermédiaires.
Il ne nous reste donc plus que le protocole DNS comme candidat !
B. Tâche n°2 : Identifier l'IP suspecte
Énoncé - Task 2 : There seems to be a lot of traffic between our host and another, what is the IP address of the suspect host?
Maintenant que nous savons quel protocole a principalement été utilisé (DNS), et bien que ce dernier nous paraisse inoffensif au premier abord, tentons d'identifier quelle est l'adresse IP suspecte. Nous pouvons ici à nouveau utiliser la fonctionnalité "Conversations" de Wireshark après avoir effectué un filtre sur le protocole DNS :
Nous pouvons clairement voir que l'une des adresses IP a beaucoup plus discuté que les autres au travers le protocole DNS. Il est d'ailleurs suspect en soi qu'un tel volume de paquet DNS ait été échangé, il s'agit d'un protocole d'ordinaire plutôt "léger" dans la mesure où seuls quelques éléments textes sont échangés.
L'adresse IP "192.168.157.145" est donc celle de notre suspect.
C. Tâche n°3 : une commande via DNS ?
Énoncé - Task 3 : What is the first command the attacker sends to the client?
Il est maintenant temps de s'intéresser au contenu de ces échanges DNS. Commençons par isoler les paquets en appliquant un filtre sur ce protocole et l'IP suspecte :
DNS && (ip.addr==192.168.157.144 && ip.addr==192.168.157.145)
Ces échanges paraissent pour le moins inhabituels. Les noms DNS sont la plupart du temps intelligibles, et ils ne sont jamais aussi long. Ici, ils semblent être constitués uniquement des alphabets suivants avec aucun mot intelligible à part "microsofto365.com" :
1-9
a-f
Voilà qui nous rappelle quelque chose : de l'hexadécimal. Je récupère au hasard une requête TXT et copie le contenu de la requête via la fonction Copy Value de WIreshark (pensez à bien faire un clic droit sur le champ exact à copier dans le paquet ciblé) :
Je tente ensuite de décoder l'hexadécimal à l'aide de l'outil en ligne "CyberChef".
Cyberchef se présente comme "The Cyber Swiss Army Knife", c'est un outil très pratique proposé par le GCHQ (services de renseignement britannique) qui permet d'encoder/décoder ou chiffrer/déchiffrer des données au sein d'une application web intuitive. Cela permet de tenter rapidement tout un tas de format de conversions, d'encodage/decodage ou d'algorithme de chiffrement sur des données sans saisir la moindre ligne de commande : https://gchq.github.io/CyberChef/
Si vous souhaite l'utiliser dans un contexte professionnel, je vous recommande son installation sur un de vos serveurs déconnectés d'internet pour l’investigation : https://github.com/gchq/CyberChef
La conversion "hexadecimal -> ASCII" nous donne donc un bout de texte intelligible !
L'attaquant est parvenu à utiliser le protocole DNS en tant que protocole d’encapsulation en vue d'envoyer des commandes au serveur compromis, puis de recevoir en retour le résultat. Cette technique est connue sous le nom de DNS protocol Tunneling et est référencée sur le site du MITRE : T1071.004 - Application Layer Protocol: DNS
Un C2, C&C, ou centre de commandement et de contrôle (en anglais, Command and Control), est un élément crucial dans le contexte des cyberattaques. C'est une infrastructure utilisée par les cybercriminels pour gérer et contrôler des systèmes compromis à distance. Les attaquants utilisent de nombreuses infrastructures, techniques et protocoles pour que les agents déployés sur les systèmes compromis des entreprises communiquent avec leur C2, le MITRE ATT&CK en référence un certain nombre : TA0011 - Command and Control
Il est à noter que, contrairement à ce que l'on pourrait penser, le nom de domaine microsofto365.com n'appartient pas à Microsoft, dans la réalité, personne ne possède ce nom de domaine :
Pour comprendre l'intégralité de l'échange, il faut donc isoler le nom DNS exact dans les requêtes et les réponses des paquets déjà isolés, supprimer les éléments parasites (les "." et le "microsofto365.com"), concaténer le tout puis effectuer une conversation hexadécimal vers ASCII, je ne pense pas parvenir à faire cela avec Wireshark, je suis donc passé par le script Python suivant :
#!/usr/bin/python3
import argparse
from scapy.all import rdpcap, DNSQR, DNSRR
def main(args) -> None:
f = ""
last = ""
for p in rdpcap(args.file):
if p.haslayer(DNSQR) and not p.haslayer(DNSRR) :
if "microsofto365" in p[DNSQR].qname.decode('utf-8'):
qry = p[DNSQR].qname.decode('utf-8').replace(args.domain,"").strip().split(".")
qryStr = ''.join(qry)[4:]
if len(qryStr) > 1:
decoded_string = bytes.fromhex(qryStr).decode('utf-8', errors='replace')
if (len(decoded_string) > 20) and last != decoded_string:
f += decoded_string
last = decoded_string
print(f)
if __name__ == '__main__':
# create the top-level parser
parser = argparse.ArgumentParser(prog='PROG')
parser.add_argument("-f", '--file', help='.pcap filepath', required=True)
parser.add_argument("-d", '--domain', help='top domain to remove (eg. attacker.com)', required=True)
args = parser.parse_args()
main(args)
J'ai notamment utilisé "scapy" pour isoler les échanges DNS concernant le nom de domaine "microsofto365.com". Des recherches sur le décodage des échanges "dnscat2" m'ont également renseigné sur le besoin de retirer les 4 premiers octets de chaque échange DNS (Analysis on Popular DNS Tunneling Tools), qui correspond à un marqueur spécifique permettant le suivi des sessions "DNScat" : inutile dans le cadre d'une conversion en texte donc. Suite à l'exécution du script :
Le résultat n'est pas parfait, mais nous pouvons tout de même comprendre les échanges et exécution de commande qui on eut lieu. On obtient notamment la première commande exécutée par l'attaquant suite au déploiement de sa backdoor : whoami.
D. Tâche n°4 : dnscat2
Énoncé - Task 4 : What is the version of the DNS tunneling tool the attacker is using?
Maintenant que nous sommes parvenus à avoir l'échange client-serveur presque en clair, il nous est plus facile de comprendre les opérations réalisées par l'attaquant. Nous pouvons notamment identifier la version de dnscat utilisée dans le nom du binaire déposé par l'attaquant :
Nous savons donc que l'attaquant à utiliser "dnscat2" en version 0.07.
E. Tâche n°5 : un attaquant presque discret
Énoncé - Task 5 : The attackers attempts to rename the tool they accidentally left on the clients host. What do they name it to?
L'attaquant aurait tenté de renommer son outil une fois déposé sur le système compromis, nous pouvons de nouveau facilement repérer ses tentatives dans les échanges client-serveur "dnscat2" décodés :
L'attaquant a renommé son binaire "dnscat2" en "win_installer.exe".
Le fait de changer le nom d'un outil malveillant avant de le déposer sur un système surveillé par une solution de sécurité (antivirus, EPP, EDR, etc.) correspond au TTP T1036.005 - Masquerading: Match Legitimate Name or Location. Cela vise à contourner les règles de détections basées sur des mots ou des noms caractéristiques d'outils malveillants ou les analyses manuelles. Les attaquants optent souvent pour des noms communs et connus pour tenter de contourner ses règles, par exemple, en renommant leur malware "firefox.exe", "teams.exe", etc. EPP/EDR et humains peuvent facilement se faire berner par ce genre d'opérations.
Il est à noter que changer le nom du binaire après son dépôt sur le système est moins utile en termes de discrétion. En effet, une bonne partie des solutions de sécurité vont analyser celui-ciet lever une alerte dès sa création sur le système et pas seulement lors de son exécution.
Cependant, ce type de renommage peut être utile dans le cadre d'une persistance. En effet, un administrateur effectuant une analyse manuelle des processus en cours d'exécution ne prêtera pas attention à un processus win_installer.exe en cours d'exécution, alors qu'un processus "dns2cat.exe" l'interrogera un peu plus, le poussant à investiguer.
F. Tâche n°6 : Enumeration utilisateur
Énoncé - Task 6 : The attacker attempts to enumerate the users cloud storage. How many files do they locate in their cloud storage directory?
Il semblerait que l'attaquant ait tenté d'énumérer les fichiers Cloud depuis le système compromis. En effet, nous pouvons voir cette tentative :
Seulement le dossier "OneDrive" parcouru par l'attaquant ne contenait aucun fichier.
G. Tâches n°7 et 8 : fuite d'informations sensibles
Énoncé - Task 7 :What is the full location of the PII file that was stolen?
Énoncé - Task 8 :Exactly how many customer PII records were stolen?
Ces deux tâches peuvent être traitées en même temps. Il s'agit de retrouver le nom et le contenu du fichier sensible ayant été dérobé par l'attaquant. Il nous suffit de suivre le flux des échanges clients-serveur décodés jusqu'à trouver ceci :
Nous voyons que l'attaquant a consulté le fichier "C:\users\test\documents\client data optimisation\user details.csv" et que celui-ci contient des informations personnelles :
Ce fichier contient 721 lignes (le premier objet ayant l'identifiant 0), c'est donc le nombre de clients uniques contenu dans le fichier dérobé.
IV. Résumé de l'attaque
Au cours de cette investigation, nous avons découvert que suite une compromission du système "desktop-umncbe7" par un vecteur non connu, l'attaquant a déposé un binaire sur le système, puis a utilisé le protocole DNS pour établir une communication directe entre son C2 et le système compromis. L'attaquant a effectué une brève recherche de fichiers sensibles sur le système et a récupéré les informations personnelles de 721 clients, incluant noms, prénoms, mails, adresses, numéros de téléphone, date de naissance, etc.
Pour aller jusqu'au bout de la démarche, voici les TTP (Tactics, Techniques and Procedures) utilisés :
Affichage et exfiltration du fichier "user details.csv" contenant les informations personnelles
V. Notions abordées
Nous allons à présent mettre en avant les principales notions et les apprentissages de cet exercice, aussi bien pour l'attaquant que pour les défenseurs ou l'analyste. Il ne s'agit pas d'un point de vue complet, n'hésitez pas à améliorer ce contenu en donnant votre avis dans les commentaires :).
A. Côté analyste
Côté analyste, connaitre les outils et les méthodes des attaquants pour être discret et passer sous les radars est important. Ici, il est facile pour un analyste de passer à côté des flux DNS. La connaissance et le suivi actif des mises à jour des TTP du MITRE ATT&CK permet aux analystes de rester à jour sur les outils et techniques utilisés par les attaquants.
Il est à noter qu'en conditions réelles, le protocole DNS serait totalement noyé (en volume) par les autres protocoles, ce qui rendrait d'autant plus difficile cette investigation. Il serait peut-être intéressant de disposer d'un outil qui oriente les recherches de l'analyste, au moins sur les techniques connues et fréquemment utilisées et lors d'une analyse de formats connus et standardisés comme les fichiers PCAP. Une des fonctions de cet outil pourrait, par exemple, répondre à la question "est-ce qu'il existe des requêtes DNS portant sur des noms très long ?".
Nous avons également vu que la maitrise de Wireshark est importante et permet de gagner du temps sur les analyses de flux réseau. Notamment via les fonctions de statistique et les filtres.
Disposer d'une boite à outils pour se faciliter la vie est également important et c'est ce qu'apporte, entre autres, l'expérience et la formation. L'outil cyberchef est ici un incontournable, comme les outils capables d'identifier et d'extraire des informations concernant les noms de domaine. Il en va de même pour les méthodologies d'analyse. Je suis, par exemple, passé à côté du fait que le domaine microsofto365.com n'est pas un domaine officiel de Microsoft pendant toute l'analyse, car je n'ai pas fait la requête "whois" concernant ce nom de domaine immédiatement. Cela aurait pu m'induire en erreur (miser sur l'utilisation d'instances Cloud par l'attaquant par exemple).
B. Côté défense
Côté défense, il peut déjà être recommandé d'investiguer de façon plus approfondie sur les raisons de la compromission, élément qui est hors du périmètre de cette analyse.
Également, la mise en place de règles de détections basées sur un volume anormalement élevé de requête DNS ou la taille de noms de domaine peut être recommandé. Il faut savoir qu'un nom DNS a une taille maximale de 255 caractères :
Cependant, dans la réalité, il est très rare de croiser des noms de domaine dépassant 50 ou 60 caractères. J'ai d'ailleurs déjà croisé des solutions de sécurité basées sur l'analyse des flux réseau émettant une alerte de sécurité lorsqu'une requête ou réponse DNS concernant un nom de domaine trop long était identifiée.
La mise en place d'une solution de sécurité capable de détecter les outils malveillants que pourrait déposer un attaquant est également à recommander. Il est, par exemple, aisé de trouver des règles de détection SIGMA (utilisées par les EDR et IDS, entre autres) concernant le binaire ou les commandes PowerShell dnscat2 : Detection.fyi - Dnscat Execution
Il est difficile de proposer des améliorations concernant le nom de domaine utilisé par l'attaquant. Impossible de prévoir toutes les permutations DNS non enregistrées concernant Google, Microsoft ou autres Cloud provider. Si l'entreprise souhaite surveiller ses propres noms de domaine et être informé de l'enregistrement d'un nom de domaine ressemblant au sien par un attaquant, différents outils peuvent être utilisés :
Ici, nous sommes parvenus à décoder les échanges encapsulés dans le protocole DNS, car ceux-ci étaient simplement encodés en hexadécimal. Il faut savoir que dnscat2, l'outil utilisé par l'attaquant, possède une fonction permettant de chiffrer les échanges à l'aide d'une clé fixe avant transmission via le réseau. Il est alors plus complexe pour l'analyste de retrouver le contenu des échanges avec le C2.
Également, il pourrait être intéressant pour l'attaquant de renommer ses binaires malveillants avant dépôt sur le système, cela pour éviter qu'un éventuel antivirus, EPP ou EDR n'émette une alerte basée sur un terme surveillé dans les noms des fichiers ou des commandes.
V. Conclusion
J'espère que cet article vous a plu ! Au-delà de la résolution du challenge, il est toujours intéressant de savoir tirer parti de ces exercices pour s'améliorer et en extraire le maximum d'apprentissage. N'hésitez pas à utiliser les commentaires et le Discord pour partager votre avis !
Enfin, si vous voulez accéder à des cours et des modules dédiés aux techniques offensives ou défensives et améliorer vos compétences en cybersécurité, je vous oriente vers Hack The Box Academy, utilisez ce lien d'inscription (je gagnerai quelques points ) : Tester Hack the Box Academy
L'entreprise Hive Systems a mis en ligne la nouvelle version de son étude permettant de connaître le temps nécessaire pour "brute forcer" un mot de passe, c'est-à-dire le casser, le deviner quoi ! Alors vos mots de passe sont-ils en vert ? Réponse dans cet article !
L'algorithme bcrypt et le matériel utilisé pour les tests
Avant d'évoquer les résultats et cette fameuse matrice "Password Table", évoquons la méthodologie utilisée par les équipes de Hive Systems. Jusqu'ici, les tests étaient effectués sur des hashs de mots de passe chiffrés avec l'algorithme MD5 : ce qui n'était pas cohérent et représentatif, car il est obsolète. Mais, si Hive Systems se basait sur cet algorithme, c'est parce qu'il était encore massivement utilisé. Désormais, la "Password Table" indique le temps qu'il faut pour casser un mot de passe chiffré avec bcrypt, et non md5.
"MD5 a régné en maître pendant plusieurs années, mais bcrypt a pris la tête en 2020, 2021, 2023 et, jusqu'à présent, en 2024.", ce qui justifie le fait de basculer de md5 vers bcrypt.
Le matériel utilisé reste le même entre cette édition 2024 et l'édition 2023 : 12 cartes graphiques (GPU) RTX 4090, ce qui représente une puissance très élevée ! Hive Systems estime a fait le choix de ce matériel, car c'est "la meilleure configuration matérielle accessible au grand public." - En complément, des résultats sont donnés pour des configurations beaucoup plus musclées basées sur des GPU A100, notamment utilisées pour l'IA.
Oubliez les mots de passe de 8 caractères
À partir de différentes configurations matérielles, d'une simple RTX 2080 à une configuration monstrueuse de 10 000 GPU A100 (ChatGPT), Hive Systems a essayé de casser des mots de passe de 8 caractères plus ou moins complexes, aussi bien avec le md5 que le bcrypt. Ces résultats prouvent que le bcrypt est plus robuste que le md5, mais il montre aussi les limites des mots de passe de 8 caractères.
Voici le comparatif, avec md5 au-dessus, et bcrypt en dessous :
Source : Hive Systems
La matrice Password Table de 2024
Alors, en 2024, combien de temps faut-il pour casser un mot de passe ? Bien entendu, cela dépend de la longueur de ce mot de passe et du type de caractère.
Pour être "dans le vert", selon la matrice d'Hive Systems, le mot de passe doit être d'au moins 13 caractères et utiliser 4 types de caractère (nombres, majuscules, minuscules et symboles) car il faudra 11 milliards d'années pour le casser. Il faudra surement beaucoup moins de temps avec du matériel encore plus performant.
Au-delà des types de caractère, cette matrice met en avant l'importance de la longueur des mots de passe. Un mot de passe de 14 caractères, avec uniquement des lettres minuscules et majuscules, sera cassé en 766 000 années. Pour utiliser seulement ces deux types de caractère et "être dans le vert", comptez 17 caractères minimum : c'est facilement atteignable avec une passphrase.
Voici la fameuse matrice de 2024 :
Vous pouvez accéder à l'étude complète et au téléchargement en haute définition de cette Password Table en visitant cette page.
Une nouvelle fois, ce type d'étude m'encourage à vous recommander l'utilisation de passphrases plutôt que de mots de passe.
Tarn: la Ville d'Albi est actuellement victime d'une cyberattaque qui est déroulée dans la nuit de dimanche à lundi ! Certains services sont inaccessibles suite à cet incident de sécurité. Voici ce que l'on sait !
La Ville d'Albi a été ciblée par une cyberattaque qui s'est déroulée dans la nuit du dimanche 21 avril au lundi 22 avril 2024. Sur ses réseaux sociaux, notamment sur Facebook, la Ville d'Albi précise : "La Ville d’Albi est victime depuis ce lundi 22 avril 2024 à 6h du matin d’une attaque informatique."
Sans surprise, cette cyberattaque perturbe les activités des services publics de la Ville d'Albi (Mairie, Police municipale, État civil, Urbanisme, etc.), et directement, les Albigeoises et les Albigeois. Le communiqué officiel donne quelques précisions à ce sujet : "Les numéros de téléphone habituels, les mails et les services informatiques du quotidien sont inaccessibles pour une durée indéterminée." - Ce qui n'est pas étonnant, car l'accès à Internet a probablement été désactivé volontairement suite à cette intrusion.
D'après des propos relayés par le site La Dépêche, un agent a évoqué un retour au papier et au stylo, en indiquant que "Tout a été crypté" pour reprendre les termes exacts qu'il a utilisés. S'il y a réellement eu un chiffrement des données, cela signifierait que la Ville d'Albi serait victime d'une attaque par ransomware. Il s'agit là que d'une hypothèse, car aucune information officielle n'a été publiée quant à l'origine de cette attaque.
De son côté, un syndicat a évoqué la paie des agents : s'il y a une perte de données, la paie sera identique au mois dernier et une régularisation sera effectuée plus tard. Un représentant du personnel a indiqué que cette décision avait été prise en accord avec le Trésor public.
En attendant, les équipes techniques doivent identifier l'origine de cette cyberattaque et restaurer les services afin qu'ils soient de nouveau en ligne. D'ailleurs, en réponse à cet incident de sécurité, la Ville d'Albi a sollicité l'aide de l'ANSSI (Agence nationale de la sécurité des systèmes d'information), habituée à gérer ce type d'événement.
Proton s'intéresse à la surveillance du Dark Web pour détecter les éventuelles fuites de données impliquant les utilisateurs de la solution Proton Mail. Faisons le point sur cette nouveauté !
La solution Proton Mail s'enrichit d'une nouvelle fonctionnalité permettant de protéger encore un peu plus ses utilisateurs grâce à la détection et l'analyse des fuites de données présentes sur le Dark Web.
Si par malheur, votre adresse e-mail Proton Mail est identifiée dans une fuite de données, vous recevrez une alerte dans le Centre de sécurité Proton Mail de votre compte. Celle-ci vous indiquera précisément quelles sont les informations personnelles compromises et la source de la fuite de données.
En complément, des recommandations sur la manière dont les utilisateurs peuvent se protéger seront intégrées. Autrement dit, cela vous permettra d'être réactif et de procéder à un changement immédiat de votre mot de passe sur le service impacté (et les éventuels autres services où vous utilisez le même mot de passe...).
"La détection de fuites d’identifiants vient compléter le chiffrement de bout en bout éprouvé de Proton Mail et avertit les utilisateurs en cas de brèche d'un service tiers pour lequel ils auraient utilisé leur adresse Proton Mail pour s'inscrire.", peut-on lire dans le communiqué de presse officiel. Par exemple, si vous utilisez votre adresse Proton Mail pour vous inscrire sur le service "XYZ" et que ce dernier est victime d'une fuite de données publiée sur le Dark Web, vous en serez informé.
Grâce à cette nouveauté, Proton Mail souhaite protéger ses utilisateurs et leurs données, mais aussi limiter les pertes financières : "En identifiant en informant rapidement les utilisateurs des informations d'identification compromises, Proton peut aider à prévenir les pertes financières résultant du vol d'identité et de la fraude.", peut-on lire.
Précision importante : cette nouvelle fonctionnalité sera accessible à tous les utilisateurs qui ont un abonnement payant à Proton Mail. Si vous utilisez la version gratuite de Proton Mail, vous ne pourrez pas en bénéficier. Pour en savoir plus, vous pouvez consulter cette page du blog de Proton Mail.
Un hacker éthique a découvert de nombreuses failles de cybersécurité sur Wizz App, une application pointée du doigt pour des affaires de sextorsion. Ses recherches incluent des captures de discussions privées.
Un hacker éthique a découvert de nombreuses failles de cybersécurité sur Wizz App, une application pointée du doigt pour des affaires de sextorsion. Ses recherches incluent des captures de discussions privées.
Grâce à la boutique en ligne Apple Store et à une option d'achat bien précise, des cybercriminels sont parvenus à s'emparer de plus de 400 000 dollars en 2 ans. Mais, comment ont-ils fait ?
À l'occasion d'une conférence organisée à l'événement Black Hat Asia, Gyuyeon Kim et Hyunho Cho, deux chercheurs de l’Institut de sécurité financière de Corée du Sud, ont dévoilé une vaste opération menée par des cybercriminels. Cette présentation baptisée "Operation PoisonedApple" est le fruit de plusieurs mois d'enquête.
Tout d'abord, les chercheurs ont identifié une vague de piratages ciblant une cinquantaine de centres commerciaux en ligne, notamment au Japon, grâce à l'utilisation d'une technique bien connue : le phishing. Les pages mises en ligne sont des copies des sites officiels et sont utilisés par les cybercriminels pour voler des informations personnelles au sujet des victimes, ainsi que leurs coordonnées bancaires.
"Ces groupes de cybercriminels ont utilisé diverses stratégies d'évasion pour empêcher la détection de leurs pages d'hameçonnage par les administrateurs de sites et les utilisateurs, en utilisant de multiples vulnérabilités et outils.", précise le rapport des chercheurs.
Au fil des mois, les pirates sont parvenus à collecter de nombreux numéros de cartes bancaires. Ils se sont alors demandés comment les utiliser sans attirer l'attention des forces de l'ordre ? C'est là que l'Apple Store entre en jeu.
Utilisation de petites annonces et de l'Apple Store
Pour commencer, les pirates ont publié des annonces en ligne sur un site de vente de matériel d'occasion situé en Corée du Sud. Nous pouvons imaginer que c'est l'équivalent du site « Leboncoin ». Par l'intermédiaire de ces annonces, ils ont proposé des produits Apple à des prix réduits : iPhone, Apple Watch, AirPods, etc. Compte tenu de l'attractivité des offres, de nombreux internautes ont contacté les pirates, sans le savoir, par l'intermédiaire de ces annonces.
Dès qu'un internaute effectuait un achat, les cybercriminels se servaient d'un numéro de carte bancaire volé pour commander le produit en ligne directement sur l'Apple Store. Au moment de passer la commande, les pirates ont pris soin de cocher l’option « Someone-else pickup » pour permettre à un tiers de retirer la commande ! Et là, ce fameux tiers déclaré, c'est l'acheteur qui a utilisé le site de vente de matériel d'occasion !
Finalement, l'argent de la première victime est utilisée pour passer cette commande sur l'Apple Store tandis que les pirates empochent l'argent via le site de petites annonces grâce à la seconde victime. D'ailleurs, elle ne dira rien, car elle va récupérer du matériel flambant neuf à prix réduit, tout en ignorant que la commande a été réglée avec un numéro de cartes volé...
Ce stratagème a permis aux cybercriminels de voler 400 000 dollars en deux ans. D'après les chercheurs en sécurité, les attaques sont toujours en cours et les pirates cherchent de nouvelles cibles. De son côté, Apple, refuse de coopérer en raison de réglementations internes et toujours dans la volonté de protéger la vie privée de ses utilisateurs.
Utilisée par des centaines de milliers de sites WordPress, l'extension Forminator contient une faille de sécurité critique permettant à un attaquant de charger un fichier malveillant sur le serveur où est hébergé le site web. Faisons le point sur cette menace.
L'extension Forminator, développée par WPMU DEV, sert à ajouter des formulaires de différents types à WordPress, dont des formulaires de paiements, ainsi que des quiz et des sondages.
Le CERT du Japon a mis en ligne un bulletin d'alerte au sujet de la faille de sécurité critique CVE-2024-28890 présente dans Forminator et associée à un score CVSS v3 de 9.8 sur 10. "Un attaquant distant peut obtenir des informations sensibles en accédant aux fichiers du serveur, modifier le site qui utilise le plugin et provoquer un déni de service.", peut-on lire.
Par ailleurs, ce n'est pas la seule faille de sécurité évoquée, puisqu'il y en a deux autres avec une sévérité inférieure : la CVE-2024-31077, une injection SQL qui implique d'être administrateur du site WordPress pour être exploitée, et la CVE-2024-31857 (une vulnérabilité de type XSS).
Comment se protéger ?
Pour se protéger de ces trois failles de sécurité, vous devez installer Forminator 1.29.3. Cette version a été publiée le 8 avril 2024. L'extension Forminator compte plus de 500 000 installations actives, et depuis le 8 avril 2024, elle a été téléchargée environ 180 000 fois. Ce qui signifierait que la mise à jour de sécurité n'a pas été déployé sur environ 320 000 sites WordPress et qu'ils sont vulnérables à une attaque.
Pour le moment, rien n'indique qu'elles sont exploitées dans le cadre d'attaques. Néanmoins, cela pourrait évoluer compte tenu de la popularité de cette extension et du nombre de cibles potentielles.
En résumé : si vous utilisez l'extension Forminator sur votre site WordPress, vous devez passer sur la version 1.29.3 le plus rapidement possible pour vous protéger de ces 3 vulnérabilités.
Opération de rebranding dans le monde de la cybercriminalité : le gang de ransomware HelloKitty devient HelloGookie ! À cette occasion, des informations sensibles issues de précédentes piratages ont été publiées, ainsi que des clés de déchiffrement ! Faisons le point.
Désormais, HelloKitty va laisser sa place à HelloGookie ! C'est celui que l'on appelle "Gookee/kapuchin0" et qui prétend être le créateur du ransomware HelloKitty, qui a fait cette annonce il y a quelques jours. Un nouveau « site vitrine » a été mis en ligne pour le ransomware HelloGookie. À l'heure actuelle, ce site ne référence aucune victime. Malheureusement, cela risque d'évoluer...
Des données et des clés de déchiffrement divulguées !
Pour célébrer ce nouveau départ, Gookee a publié quatre clés de déchiffrement qui peuvent être utilisées pour récupérer des fichiers chiffrés lors de précédentes attaques ! Ceci devrait permettre à certaines victimes de déchiffrer leurs données, et ce gratuitement. Un outil de déchiffrement pourrait être publié dans les prochains jours.
Il a également publié des informations internes volées à l'entreprise Cisco, lors d'une attaque en 2022. Mais, ce n'est pas tout, puisqu'il a aussi mis en ligne des données issues du piratage de CD Projekt Red en 2021 : des mots de passe pour accéder au code source de Gwent, Witcher 3 et Red Engine.
À l'époque, cette cyberattaque avait fait beaucoup de bruit : les cybercriminels étaient parvenus à chiffrer les serveurs de l'entreprise CD Projekt Red, un studio de développement polonais à l'origine de plusieurs gros titres, dont Cyberpunk 2077.
Suite à la publication de ces données, un groupe de développeurs s'est penché sur le sujet. Ils sont parvenus à partager des captures d'écran et des vidéos de la version de développement de Witcher 3, après avoir réussi à compiler le jeu à partir du code source divulgué. C'est surtout pour le fun, car ce jeu est disponible depuis plusieurs années.
Une campagne de phishing contre les internautes utilisant LastPass comme gestionnaire de mots de passe a été repérée. Elle mobilise le kit de phishing CryptoChameleon. Un site utilisé pour le hameçonnage a été neutralisé, mais d'autres tentatives pourraient survenir.
Une campagne de phishing contre les internautes utilisant LastPass comme gestionnaire de mots de passe a été repérée. Elle mobilise le kit de phishing CryptoChameleon. Un site utilisé pour le hameçonnage a été neutralisé, mais d'autres tentatives pourraient survenir.
Tout roule pour les membres du gang de ransomware Akira puisqu'ils seraient parvenus à voler la jolie somme de 42 millions de dollars grâce à la compromission de l'infrastructure de plus de 250 organisations. Il s'agit de chiffres publiés par plusieurs agences, dont le FBI.
Le FBI, la CISA, le Centre européen de lutte contre la cybercriminalité (European Cybercrime Centre) et le National Cyber Security Centre (NCSC) du Pays-Bas ont travaillé sur l'écriture d'un rapport complet au sujet de la menace Akira. Ce bulletin d'alerte disponible sur le site de la CISA montre la progression fulgurante de ce gang de ransomware apparu pour la première fois en mars 2023.
Le gang de ransomware a fait des victimes partout dans le monde, même si la majorité des organisations ciblées sont situées en Amérique du Nord, en Europe et en Australie. Au début, Akira s'en prenait principalement aux systèmes Windows, mais assez rapidement, les cybercriminels ont mis au point une variante pour Linux afin de chiffrer les machines virtuelles sur les serveurs VMware ESXi.
Ainsi, au 1er janvier 2024, le groupe de ransomwares avait touché plus de 250 organisations et volé environ 42 millions de dollars grâce aux victimes qui ont pris la décision de payer la rançon demandée.
Le mode opératoire du gang de ransomware Akira
Le rapport publié sur le site de la CISA fournit des informations intéressantes sur les techniques et méthodes employées par les cybercriminels d'Akira.
L'accès initial est notamment évoqué, et d'après le FBI, ils ciblent principalement les accès VPN, les accès RDP, le spear phishing et l'utilisation de comptes utilisateurs valides qu'ils ont en leur possession. Deux failles de sécurité, liées aux équipements Cisco, sont citées : CVE-2020-3259 et CVE-2023-20269.
Pour les différentes phases de l'attaque, notamment pour la persistance, la découverte et l'exfiltration des données, le gang de ransomware Akira utilisent différents outils dont certains que vous connaissez et utilisez probablement : Mimikatz, LaZagne, SoftPerfect et Advanced IP Scanner. À cela s'ajoutent des outils accessibles facilement et peut-être même déjà présents sur certaines machines : AnyDesk, MobaXterm, RustDesk, Ngrok, RClone, les protocoles FTP et SFTP ou encore le service de stockage de fichiers Mega.
Les conseils pour se protéger du ransomware Akira
Ce rapport contient également un ensemble de conseils et recommandations pour se protéger de cette menace.
Voici la liste de ces recommandations :
Mise en œuvre d'un plan de reprise d'activité.
Effectuer des sauvegardes déconnectées (hors ligne) des données.
Effectuer des sauvegardes chiffrées et immuables.
Exiger que tous les comptes soient protégés par des mots de passe conformes aux normes du NIST, et qui doivent être suffisamment long. "Envisagez de ne pas exiger de changements de mot de passe récurrents, car cela peut affaiblir la sécurité", peut-on lire.
Exiger une authentification multifactorielle pour tous les services dans la mesure du possible.
Maintenir tous les systèmes d'exploitation, les logiciels et les firmwares à jour.
Segmenter les réseaux pour empêcher la propagation des ransomwares.
Identifier, détecter et étudier les activités anormales et les mouvements potentiels du ransomware à l'aide d'un outil de surveillance du réseau.
Filtrer le trafic réseau en empêchant des sources inconnues ou non fiables d'accéder à des services distants sur des systèmes internes.
Installer, mettre à jour régulièrement et activer la détection en temps réel des logiciels antivirus sur tous les hôtes.
Examiner les contrôleurs de domaine, les serveurs, les postes de travail et les annuaires actifs pour détecter les nouveaux comptes et/ou les comptes non reconnus.
Auditer les comptes d'utilisateurs disposant de privilèges élevés et configurer les contrôles d'accès selon le principe du moindre privilège.
Désactiver les ports inutilisés.
Ajouter un avertissement aux e-mails dont l'expéditeur est externe à votre organisation.
Désactiver les hyperliens dans les e-mails reçus.
Mettre en place une politique Time-based Access (Zero Trust) basée sur la durée pour les comptes avec des privilèges élevés.
Désactiver les activités et les autorisations relatives à la ligne de commande et aux scripts.
En novembre 2023, la société Derichebourg a subi une cyberattaque ayant entrainé une paralysie totale et temporaire de son logiciel d'exploitation. Cet incident de sécurité aurait fait perdre entre 15 et 20 millions d'euros à l'entreprise.
Dans la nuit du 9 au 10 novembre 2023, le groupe français Derichebourg, spécialisé dans le recyclage de métaux, avait été victime d'une cyberattaque ayant eu un impact important sur une partie de son activité : "Le groupe Derichebourg a subi une cyberattaque qui n’a pas interrompu ses activités opérationnelles mais en a cependant perturbé le déroulement.", peut-on lire dans le communiqué de presse publié mardi 16 avril 2024.
La cyberattaque a impactée directement le logiciel d'exploitation principal utilisé par les équipes du groupe Derichebourg et Derichebourg Multiservices. Cette indisponibilité, bien que temporaire, a été relativement longue à en croire les informations fournies dans le communiqué de presse : "Cette cyberattaque a cependant perturbé le déroulement des activités du fait de l'indisponibilité temporaire du principal logiciel d'exploitation, en particulier au cours des mois de novembre 2023, décembre 2023 et dans une moindre mesure janvier 2024."
Cette indisponibilité du logiciel d'exploitation causée par la cyberattaque a perturbé le pilotage de l'activité de l'entreprise, et il a été à l'origine de pertes de volumes d'achats et de retard dans la saisie informatique. Résultat, Derichebourg estime que cette cyberattaque a un impact financier compris entre 15 et 20 millions d'euros. À cela s'ajoute des difficultés liées à la conjoncture actuelle et à la difficulté du marché.
Pour ces différentes raisons, le groupe Derichebourg estime qu'il est peu probable d'atteindre son objectif initial pour l'année 2024 : 350 millions d'euros d'excédent. Enfin, sachez que suite à la publication de ce communiqué de presse, le titre Derichebourg a fortement reculé à la Bourse de Paris.
Le malware Raspberry Robin est en circulation depuis plusieurs années et il continue de se propager pour infecter les appareils Windows. Désormais, il est capable de contourner Microsoft Defender et d'être très furtif sur la machine infectée. Faisons le point !
À la base, le logiciel malveillant Raspberry Robin se propage principalement par l'intermédiaire de clés USB, comme nous l'avions évoqué dans un précédent article publié en juillet 2022. Mais, depuis mars 2024, les pirates semblent bien décidés à le distribuer plus largement, alors qu'initialement, il ciblait plutôt les industries et les grandes entreprises.
Campagnes de phishing et fausses publicités
Un nouveau rapport publié par l'équipe de chercheurs en sécurité HP Wolf Security met en avant les nouvelles capacités et techniques employées par Raspberry Robin. Désormais, la clé USB est remplacée par de fausses publicités et des campagnes de phishing par e-mails. L'objectif étant de rediriger les utilisateurs vers des sites malveillants contrôlés par les pirates sur lesquels sont hébergés des fichiers WSF (Windows Script Files) obscurci.
"Le format de fichier WSF prend en charge les langages de script, tels que JScript et VBScript, qui sont interprétés par le composant Windows Script Host intégré au système d'exploitation Windows.", peut-on lire. De plus, les chercheurs en sécurité précisent que le code des scripts WSF distribués par les pirates est long et difficile à analyser. En effet, il y a beaucoup de lignes de code inutiles, uniquement là pour brouiller les pistes.
Une analyse minutieuse de la machine infectée
La dernière version de Raspberry Robin se démarque également par sa capacité à contourner les solutions de sécurité et à passer entre les mailles du filet. Avant de passer à l'action, le malware effectue une analyse complète de la machine pour déterminer l'environnement sur lequel il se trouve, avant de passer à la phase d'infection.
Parmi les éléments vérifiés, il y a la version de Windows, le type d'appareils (machine virtuelle, serveur, poste de travail), le type de processeur, la détection de la solution de virtualisation via l'adresse MAC, et enfin, il vérifie la présence éventuelle de certains antivirus (Kaspersky, ESET, Avast, Avira, Check Point et Bitdefender). Si l'un de ces antivirus est identifié, le script s'arrête. L'objectif principal de cette série de vérifications est de s'assurer que le malware est exécuté sur l'appareil d'un utilisateur final.
Par contre, les chercheurs en sécurité précisent que Raspberry Robin est capable de contourner Microsoft Defender : "Il est donc plus probable que le script s'exécute sur un terminal protégé par Microsoft Defender. Pour échapper à la détection, le script ajoute une exception à Microsoft Defender qui exclut l'ensemble du disque principal de l'analyse antivirus."
La phase finale : le déploiement de Raspberry Robin
Si tous les voyants sont au vert et qu'il s'agit de l'appareil d'un utilisateur final, le script va télécharger la DLL Raspberry Robin depuis un serveur situé sur Internet. Pour cela, il va s'appuyer sur la commande "curl" prise en charge nativement sur Windows, et il va stocker la DLL malveillante dans le dossier "AppData" local. Ainsi, Raspberry Robin est déployé sur la machine et il peut agir sans déclencher d'alerte sur Microsoft Defender.
Raspberry Robin est capable de télécharger et d'exécuter des charges utiles supplémentaires. Les cybercriminels ont l'habitude de l'utiliser pour déployer un ransomware ou d'autres malwares comme IcedID, BumbleBee et Truebot.
Les grands modèles de langage (LLM), comme le célèbre GPT-4 d’OpenAI, font des prouesses en termes de génération de texte, de code et de résolution de problèmes. Perso, je ne peux plus m’en passer, surtout quand je code. Mais ces avancées spectaculaires de l’IA pourraient avoir un côté obscur : la capacité à exploiter des vulnérabilités critiques.
C’est ce que révèle une étude de chercheurs de l’Université d’Illinois à Urbana-Champaign, qui ont collecté un ensemble de 15 vulnérabilités 0day bien réelles, certaines classées comme critiques dans la base de données CVE et le constat est sans appel. Lorsqu’on lui fournit la description CVE, GPT-4 parvient à concevoir des attaques fonctionnelles pour 87% de ces failles ! En comparaison, GPT-3.5, les modèles open source (OpenHermes-2.5-Mistral-7B, Llama-2 Chat…) et même les scanners de vulnérabilités comme ZAP ou Metasploit échouent lamentablement avec un taux de 0%.
Heureusement, sans la description CVE, les performances de GPT-4 chutent à 7% de réussite. Il est donc bien meilleur pour exploiter des failles connues que pour les débusquer lui-même. Ouf !
Mais quand même, ça fait froid dans le dos… Imaginez ce qu’on pourrait faire avec un agent IA qui serait capable de se balader sur la toile pour mener des attaques complexes de manière autonome. Accès root à des serveurs, exécution de code arbitraire à distance, exfiltration de données confidentielles… Tout devient possible et à portée de n’importe quel script kiddie un peu motivé.
Et le pire, c’est que c’est déjà rentable puisque les chercheurs estiment qu’utiliser un agent LLM pour exploiter des failles coûterait 2,8 fois moins cher que de la main-d’œuvre cyber-criminelle. Sans parler de la scalabilité de ce type d’attaques par rapport à des humains qui ont des limites.
Alors concrètement, qu’est ce qu’on peut faire contre ça ? Et bien, rien de nouveau, c’est comme d’hab, à savoir :
Patcher encore plus vite les vulnérabilités critiques, en priorité les « 0day » qui menacent les systèmes en prod
Monitorer en continu l’émergence de nouvelles vulnérabilités et signatures d’attaques
Mettre en place des mécanismes de détection et réponse aux incidents basés sur l’IA pour contrer le feu par le feu
Sensibiliser les utilisateurs aux risques et aux bonnes pratiques de « cyber-hygiène »
Repenser l’architecture de sécurité en adoptant une approche « zero trust » et en segmentant au maximum
Investir dans la recherche et le développement en cybersécurité pour garder un coup d’avance
Les fournisseurs de LLM comme OpenAI ont aussi un rôle à jouer en mettant en place des garde-fous et des mécanismes de contrôle stricts sur leurs modèles. La bonne nouvelle, c’est que les auteurs de l’étude les ont avertis et ces derniers ont demandé de ne pas rendre publics les prompts utilisés dans l’étude, au moins le temps qu’ils « corrigent » leur IA.
Depuis quelques jours, la faille de sécurité critique découverte dans le système PAN-OS utilisé par les firewalls de Palo Alto Networks fait beaucoup parler d'elle. Désormais, un code d'exploitation est disponible et pourrait être utilisé pour compromettre les firewalls exposés sur Internet. Faisons le point.
Rappel sur la vulnérabilité CVE-2024-3400
Voici un résumé de la situation actuelle, avec quelques dates et points clés :
Depuis le 26 mars 2024, une nouvelle faille de sécurité zero-day est exploitée par les cybercriminels dans le cadre d'attaque. Elle a été utilisée pour déployer une porte dérobée nommée Upstyle et pivoter vers l'infrastructure interne de l'entreprise. Lors d'une attaque, les pirates sont parvenus à voler des données sensibles telles que la base de données Active Directory.
Vendredi 12 avril 2024, Palo Alto Networks a publié un bulletin de sécurité pour évoquer cette vulnérabilité (CVE-2024-3400) et les risques associés.
Dimanche 14 avril 2024, l'éditeur a publié de premiers correctifs de sécurité à destination de ses firewalls sous PAN-OS : PAN-OS 10.2.9-h1, PAN-OS 11.0.4-h1 et PAN-OS 11.1.2-h3. Depuis, de nouveaux correctifs ont été publiés, car Palo Alto Networks va publier des patchs pour une dizaine de versions différentes de PAN-OS.
Voici nos précédents articles pour approfondir le sujet :
Un code d'exploit et des dizaines de milliers de firewalls vulnérables
Le mardi 16 avril 2024, watchTowr Labs a publié un rapport au sujet de cette vulnérabilité, ainsi qu'un PoC d'exploitation permettant d'exécuter des commandes à distance sur un firewall vulnérable. Dans le même temps, Justin Elze, directeur technique de TrustedSec, a également évoqué sur X (Twitter) un exploit utilisé par les cybercriminels pour exporter la configuration du pare-feu Palo Alto pris pour cible.
D'après une carte partagée par The Shadowserver Foundation, il y a environ 156 000 firewalls Palo Alto exposé sur Internet et potentiellement vulnérables. Ce chiffre est à prendre avec des pincettes, car il ne tient pas compte de la version de PAN-OS, ni de la configuration.
Vendredi dernier, le chercheur en sécurité Yutaka Sejiyama, a partagé sur X (Twitter) des statistiques au sujet des firewalls vulnérables à cette faille de sécurité. Il en a identifié un peu plus de 82 000 firewalls. Ce chiffre a certainement diminué désormais, mais le nombre de cibles potentielles doit rester élevé.
Voici quelques chiffres clés (nombre de firewalls vulnérables par pays) :
États-Unis : 32 916
Allemagne : 3 268
Royaume-Uni : 3 213
Canada : 2 239
France : 1 794 (sur un total de 3 162, si l'on s'appuie sur la carte de The Shadowserver Foundation)
Belgique : 772
Suisse : 561
Le correctif de sécurité comme seule et unique solution pour se protéger
La seule solution pour vous protéger, c'est d'installer le correctif de sécurité sur votre firewall. La mesure d'atténuation partagée initialement par Palo Alto consistait à désactiver la télémétrie, mais elle n'est pas efficace et ne permet pas de se protéger.
Voici ce que l'on peut lire dans le bulletin de sécurité de Palo Alto : "La désactivation de la télémétrie sur l'équipement n'est plus une mesure d'atténuation efficace. Il n'est pas nécessaire que la télémétrie soit activée pour que les pare-feux PAN-OS soient exposés aux attaques liées à cette vulnérabilité."
Malgré tout, si vous avez un abonnement à la fonction "Threat Prevention", vous pouvez bloquer cette attaque en activant la protection contre la menace avec l'ID 95187. De plus, assurez-vous que cette protection soit activée sur l'interface GlobalProtect, en suivant cette page de la documentation. Cette méthode est toujours efficace.
Dans cet article, nous allons nous intéresser à Sysmon, un outil qui permet une meilleure journalisation des évènements de sécurité système sous Windows. Il s'agit d'un élément indispensable pour une surveillance efficace des évènements de sécurité.
Nous allons notamment voir que les évènements Windows par défaut ne permettent pas d'avoir une détection très précise des activités systèmes et des attaques telles qu'elles sont opérées aujourd'hui, et comment Sysmon permet d'améliorer cette détection.
Nous verrons également comment l'installer et le configurer à l'aide de modèles de configuration proposés par la communauté, et analyserons ensuite concrètement les journaux produits par Sysmon.
II. Sysmon : qu'est ce que c'est ?
Sysmon (pour System monitor) est à la fois un service et un driver fournit dans le package SysInternals de Microsoft. Il vise à améliorer la journalisation des évènements Windows avec un focus sur la journalisation des évènements de sécurité système. Il s'agit plus d'un outil de détection que de prévention, dans le sens où il permet une meilleure journalisation des évènements, mais ne permet pas à lui seul de bloquer des activités malveillantes.
Depuis Sysmon 14, Microsoft a revu sa stratégie concernant Sysmon. Celui-ci peut maintenant bloquer des exécutables malveillants ("FileBlockExecutable") ainsi que la suppression de fichiers via certains outils ("FileBlockShredding"). Cette protection n'est cependant pas parfaite et ne remplace par une solution dédiée (EPP/EDR).
Pour être plus clair, voici une partie de la liste des évènements que Sysmon peut surveiller et journaliser :
Création de processus
Modification de l'heure de création d'un fichier
Connexion réseau
Modification de l'état du service Sysmon
Fin d'un processus
Chargement de pilote
Chargement d'image (injection de DLL)
Evènement CreateRemoteThread (création d'un thread par un processus)
Evènement RawAccessRead
Requête DNS
ProcessTampering
etc.
Tous ces évènements peuvent paraitre très (trop) précis pour être intéressants. Mais, tous correspondent à des attaques et modes opératoires bien identifiés et connus des attaquants. Sysmon permet alors de retracer bien plus précisément que les logs par défaut une activité malveillante sur un système.
En plus de journaliser ces évènements clés pour surveiller l'activité d'un système, il inclut plusieurs éléments importants du point de vue des équipes de sécurité et relatifs au contexte de l'évènement :
les condensats (ou hash) des images des processus lancés
les GUID des processus (facilite la corrélation des évènements)
des informations précises sur les connexions réseau (processus source, adresse IP, numéro de port, etc.)
Integrity Level du processus
des informations relatives aux métadonnées des processus (signature, auteur, description)
etc.
Ces différents éléments facilitent également l'investigation numérique ainsi que la recherche et corrélation d'évènements, par exemple, grâce aux IOC (Indicators of compromise) publiés par la communauté ou une équipe interne de Threat Intelligence (adresse IP, nom DNS, hash d'un binaire, etc). Rien de mieux qu'un exemple pour illustrer cela. Comparons la journalisation de l'évènement "Création d'un processus" entre les logs par défaut Windows et les journaux créés par Sysmon (cliquez sur l'image pour zoomer) :
Comparaison entre l'évènement par défaut de Windows et celui de Sysmon concernant la création d'un nouveau processus :
L'eventID 1 (à droite de l'image) créé par Sysmon est beaucoup plus verbeux en contenu technique. Il fournit plus d'informations de contexte autour de l'exécution du processus. Ces informations vont notamment grandement faciliter la recherche et la détection d'activité malveillante qui ont lieu sur le système.
Il faut savoir que l'intérêt de Sysmon est aussi la journalisation d'évènements qui ne sont pas du tout journalisés par Windows (au contraire de la création d'un processus, qui est le cas le plus simple pour exposer les capacités de Sysmon). Nous verrons ensuite que, grâce à la configuration que nous allons utiliser, les TTP (Tactics, Techniques and Procedures) relatifs à tel ou tel évènement journalisé sont aussi indiqués. Nous comprenons donc bien ici que l'intérêt de Sysmon est d'avoir des logs plus précis, orientés autour d'évènements de sécurité très importants sur un système d'exploitation et facilitant la détection et l'investigation numérique.
Enfin, comme tout élément capable de générer des journaux d'évènement, la puissance Sysmon est décuplée si ces évènements sont centralisés et analysés par une plateforme de type SIEM (ELK, Splunk, etc.) et traités par un SOC (Security Operation Center).
Le code source de Sysmon est public et peut être consulté librement. Ainsi, vous pouvez découvrir précisément comment il fonctionne : Github - Sysinternals/SysmonCommon
III. Logs Windows : quelques trous dans la raquette
Les journaux d'évènements Windows peuvent paraitre complexes au premier abord. D'apparence, ils sont assez verbeux et consultables à travers un outil de visualisation/recherche peu efficace ("Observateur d'évènements"). Il est difficile de trouver exactement ce que l'on cherche si l'on n'y est pas familier.
Également, la politique d'audit par défaut de Windows passe sous silence des évènements importants de l'activité sur le système. Pour illustrer ce constat, intéressons-nous aux journaux produits durant trois étapes d'attaque d'un système. Pour faciliter cette analyse, j'ai créé un filtre de journalisation dans l'Observateur d'évènements qui centralise tous les Event ID, peu importe leur source :
Création d'un filtre permettant de voir tous les évènements Windows.
Admettons qu'en tant qu'attaquant, j'exécute le binaire "mimikatz64.exe" :
.\mimikatz64.exe
Par défaut, cette activité n'est pas journalisée comme nous le montre "auditpol.exe" :
Visualisation de l'état de la stratégie d'audit par défaut Windows concernant la "création du processus".
Evènement 4688 concernant la création d'un processus mimikatz64.exe
La moindre des choses que l'on puisse dire est que cet évènement est peu verbeux. Les seuls éléments concrets dont nous disposons sont : le nom de compte ayant exécuté la commande, le nom du processus créateur et le nom du processus. Par exemple, le simple fait de renommer "mimikatz64.exe" en "itconnect.exe" suffit à contourner l'un des principaux éléments sur lequel une détection serait possible (le nom du processus) :
Evènement 4688 concernant l'exécution d'un mimikatz renommé.
Dans un second temps, je décide d'ajouter un moyen de persistance en modifiant le contenu de la clé de registre "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run". Cette clé de registre est utilisée pour lancer des binaires au démarrage (voir Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder). Il s'agit d'un moyen de persistance très connu et souvent utilisé par les attaquants, qui leur permet d'avoir une connexion vers leur serveur C2 (Command & Control) dès le démarrage du système compromis :
J'utilise ensuite la CmdLet PowerShell "Get-EventLog" pour récupérer les évènements 4657 – A Registry Value Was Modified relatifs à la modification d'une clé de registre :
À nouveau, aucun évènement n'est journalisé par défaut sous Windows lors de la modification des clés de registre. Enfin, je vais initialiser une connexion réseau vers un serveur malveillant afin de récupérer un ransomware :
Absence de journaux de sécurité relatifs au téléchargement d'un exécutable.
À nouveau, aucun évènement journalisé.
Comment nous le voyons à travers cet exemple, les journaux d'évènements produits par Windows par défaut ne sont pas suffisants pour tracer exactement le déroulement de mon attaque et de mon activité sur le système. Par défaut, ils ne sont pas tous activés et lorsqu'ils le sont, leur contenu n'est pas assez détaillé pour une investigation numérique efficace.
Autrement dit, si vous subissez une cyberattaque et que, par chance, vos journaux d'évènements sont préservés (externalisation, centralisation, voire sauvegarde), ceux-ci ne seront pas suffisants pour que l'équipe d'investigation numérique ou de remédiation puisse vous dire précisément ce qu'il s'est passé, par où est passé l'attaquant, quelles ont été ses actions, etc.
IV. Déploiement de Sysmon
A. Installer Sysmon de façon classique
Nous allons à présent voir comment installer Sysmon sur un système Windows (serveur ou client, la procédure est la même). Pour acquérir la dernière version de Sysmon, il faut le télécharger depuis le site de Microsoft : SysInternals - Sysmon.
Attention à bien télécharger le binaire depuis le site de Microsoft, et nulle part ailleurs.
Une fois que ce binaire est téléchargé, décompressé et présent sur notre système cible, nous allons ouvrir une Invite de commande en tant qu'administrateur, puis exécuter le binaire avec l'option "-i" :
.\Sysmon64.exe -i -accepteula
Voici la sortie attendue :
Installation de Sysmon sur un système WIndows.
L'installation de Sysmon64 entraine notamment la création d'un service "Sysmon64" et l'installation d'un driver "SysmonDrv", dont le rôle est de capturer les évènements de sécurité côté kernel. Le driver échange notamment avec les API Windows et exploite l'Event Tracing for Windows (ETW) pour capturer les informations sur les actions qu'il souhaite surveiller.
Il est important de noter que l'installation de Sysmon est permanente, son service et son driver seront toujours présents et actifs après un redémarrage. Il peut toutefois être désinstallé simplement.
Le driver permet notamment à Sysmon d'utiliser des callbacks, aussi appellés hooks (crochet), sur des fonctions clés du système d'exploitation. Lorsqu'une fonction surveillée est invoquée, le callback associé au driver Sysmon est déclenché. À ce moment-là, Sysmon peut collecter des informations pertinentes sur l'événement en cours, telles que les détails du processus impliqué, les arguments de la fonction, les fichiers accédés, etc. Ces informations sont ensuite journalisées. On retrouve cette mécanique sur la plupart des services type EPP/EDR aujourd'hui.
Aucun redémarrage n'est nécessaire, en vous rendant dans le "Gestionnaire de tâches" puis dans "Services", vous devriez voir le service "Sysmon64" en cours d'exécution :
Présence du service "Sysmon64" dans la liste des services du Gestionnaire des tâches.
Vous noterez également qu'il est impossible d'arrêter ce service en tant qu'administrateur :
Tentative d'arrêt du service "Sysmon64" en tant qu'administrateur via le Gestionnaire des tâches.
Cela est dû à une protection mise en place par Windows sur ce service : le Protected ProcessLight. Cette protection est notamment chargée de vérifier l'intégrité du code pour s'assurer que seul le code "vérifié" et "de confiance" est chargé dans le processus protégé. Ainsi, il ne peut être pris pour cible d'une injection de code ou de DLL et personne ne peut toucher à ce processus :
Vue de la protection PPL du processus "Sysmon64.exe" via "ProcessHacker".
Grâce à cette protection, il sera plus difficile pour l'attaquant d'altérer le fonctionnement de ce processus en vue de mettre fin à la journalisation de ses actions.
Sysmon s'installe par défaut avec une configuration qui permet de journaliser certains évènements. Cette configuration par défaut peut être consultée via l'option "-s" :
.\Sysmon64.exe -s
Voici le résultat attendu :
Visualisation de la configuration par défaut de "Sysmon".
Comme vous pouvez le voir, il s'agit d'une configuration au format XML. Celle-ci permet de définir les évènements à journaliser, leur Event ID et leur contenu. Exemple avec la journalisation de la création d'un processus :
Configuration par défaut pour l'évènement "1 - Create process" de Sysmon.
Ici, nous voyons dans un premier temps la définition de l'event ID avec son nom et son ID ("1"). Les sections précédentes de cet article contiennent déjà un exemple d'évènement créé via cette règle, vous pourrez donc voir les champs déclarés par la configuration dans cet évènement. Par défaut, la journalisation de cet évènement est activée ("ruledefaut=include"). Ce qui n'est pas le cas de tous les évènements, exemple avec l'évènement "11 - Process Create" :
Configuration par défaut pour l'évènement "11 - File create" de Sysmon.
Ainsi, avec la configuration par défaut, vous ne constaterez aucun évènement avec l'ID 11 dans vos logs. Nous voyons ici qu'il faut savoir lire et comprendre cette configuration, au risque de ne pas être assez précis dans notre journalisation.
Pour visualiser les logs, ouvrez l'Observateur d'évènements, puis rendez-vous dans "Journaux des applications et des services" > "Microsoft" > "Windows" > "Sysmon".
Accès aux journaux Sysmon dans l'observateur d'évènement Windows.
En fonction de la configuration en place (pour l'instant, celle par défaut), vous verrez dès à présent différents évènements journalisés.
B. Installation discrète de Sysmon
Les attaquants les plus avancés vont toujours commencer par regarder quels sont les composants de sécurité en place sur un système avant de tenter d'aller plus loin dans leur compromission. Il s'agit d'une phase de prise d'information très classique, par exemple :
Est-ce qu'un EPP (Endpoint Protection) est en place ? Ils peuvent pour cela regarder la liste des processus en cours d'exécution à la recherche de nom d'agents EPP connus (Trellix, Symantec, Sophos, etc.)
Est-ce que Microsoft Defender est actif ? Si oui, quelle est sa configuration ? Contient-elle des exclusions intéressantes ? Sa base antivirale est-elle à jour ?
Les journaux d'évènements sont-ils envoyés sur un autre système ? Ce qui serait le signal qu'un SIEM, voire un SOC peut enregistrer et voir son activité malveillante. L'attaquant peut pour cela regarder les processus et services actifs à la recherche d'agent de transmission de log connus, ou encore les connexions établies visant des ports connus, etc.
Est-ce que Sysmon est installé ? Quelle est sa configuration ? Contient-elle des exclusions intéressantes ?
La réponse à ces questions permet à l'attaquant d'avoir une idée du niveau de discrétion dont il doit faire preuve pour ses prochaines opérations sur le système ou le réseau.
Cependant, Sysmon donne la possibilité aux administrateurs de dissimuler sa présence, notamment en modifiant le nom du driver et du service lorsqu'il s'exécute. Par défaut, comme nous l'avons vu, nous pouvons voir un service "Sysmon64" actif dans la liste des services en cours d'exécution :
VIsualisation du service "Sysmon64" dans le gestionnaire des tâches.
Lors de la phase d'installation, Sysmon propose l'option "-d" pour permettre de donner un nom arbitraire au driver Sysmon (limité à 8 caractères). Quant au nom du service, il est déterminé par le nom du binaire exécuté lors de l'installation. Il nous suffit donc de le modifier avant installation :
Renommage puis installé de "Sysmon" avec un nom de driver personnalisé.
Une fois cette opération effectuée, il sera plus difficile pour l'attaquant de détecter la présence de Sysmon sur le système :
Présence du service "Sysmon" renommé dans le Gestionnaire des tâches.
Sur l'image ci-dessus, le processus Sysmon apparait bien comme "ITCProc". Dès lors, pour gérer le service Sysmon et par exemple, récupérer sa configuration actuelle, il faudra utiliser le binaire nommé "ITCProc.exe", l'utilisation de "Sysmon64.exe" ne fonctionnera plus.
Attention, cette méthode est une dissimulation et il existe d'autres moyens de détecter la présence du driver Sysmon (notamment via son altitude identifier).
V. Configuration de Sysmon
A. Récupération et étude d'une configuration XML Sysmon
À présent, nous allons configurer Sysmon pour qu'il journalise les évènements qui nous intéressent. La configuration par défaut est un bon départ, mais vous allez voir qu'il est possible d'aller beaucoup plus loin assez simplement.
Nous allons notamment nous baser sur des configurations connues et éprouvées créées par la communauté de la cybersécurité. La configuration la plus connue est celle proposée par SwiftOnSecurity, consultable et téléchargeable ici : Github - SwiftOnSecurity :
Extrait de la configuration Sysmon proposée par "SwitfOnSecurity".
Cette configuration comporte plusieurs intérêts :
Elle est éprouvée par la communauté et sa pertinence est reconnue. Vous pouvez notamment jeter un œil à son historique de modification Github.
Elle est documentée, même si la lecture de son contenu peut être difficile à cause du format XML, elle contient différents commentaires permettant de comprendre ses principales sections, exclusions
Elle est bien structurée, ce qui permet une compréhension et une modification aisée. Elle peut ainsi servir de base à une configuration propre à vos besoins et environnements
Elle contient des cas d'exclusions permettant d'éliminer les faux positifs "classiques" sur les OS Windows, facilitant ainsi l'exploitation des journaux créés par Sysmon.
Elle apporte des éléments de contexte supplémentaires sur chaque Event ID tels que les TTP du MITRE relatif à une action malveillante journalisée.
Bref, utiliser cette configuration apporte une réelle plus-value par rapport à celle par défaut et un gain de temps qui évite d'avoir à concevoir sa propre configuration XML, avec les difficultés que le format et la complexité des uses-case apportent. Avant de l'appliquer, je vous recommande tout de même de finir la lecture de cet article, puis de lire en détail le contenu de la configuration XML, afin que vous sachiez exactement ce qui sera journalisé et ce qui sera exclu de la journalisation.
B. Application d'une nouvelle configuration Sysmon
Il nous suffit donc de télécharger cette configuration XML puis de l'appliquer à Sysmon, nous pouvons utiliser l'option "-c" :
.\Sysmon64.exe -c .\sysmonconfig-export.xml
Voici la sortie attendue :
Ajout d'une nouvelle configuration à "Sysmon".
Pour vérifier que notre configuration est en place, nous pouvons utiliser l'option "-c" de "Sysmon" :
Affichage de la configuration SwiftOnSecurity importée dans Sysmon.
Les éléments de configuration affichés sont à présent très différents et bien plus verbeux que la configuration par défaut de Sysmon.
Nous pouvons à tout moment revenir à la configuration par défaut avec l'option "-c --".
C. Suppression du fichier de configuration
Maintenant que nous avons appliqué notre configuration à Sysmon, il est très important de ne pas laisser le fichier de configuration persister sur le système sous la forme d'un fichier XML. Si l'attaquant accède à ce fichier, il aura la possibilité de comprendre en détail les règles de détection en place, incluant ses potentielles exclusions et exceptions. Ainsi, il pourra construire une attaque qui exploite ou contourne les règles configurées.
En cela, il est mieux de laisser l'attaquant dans le noir et de supprimer cette configuration du système. Attention à ne pas non plus la laisser accessible sur un partage réseau trop ouvert auquel l'attaquant pourrait avoir accès.
Même si le fichier de configuration initial a été supprimé, Sysmon aura toujours cette configuration à disposition. Lors de l'import d'une configuration avec l'option "-c", Sysmon transforme cette configuration XML en blob de données et le stocke dans une clé de registre :
Stockage de la configuration actuelle de Sysmon dans une clé de registre.
Ce blob de donnée n'est pas facile à parser et l'attaquant aura du mal à récupérer en clair les règles et exclusions de la configuration à partir de celui-ci.
VI. Exemple de journaux Sysmon
Comme nous l'avons vu, les journaux d'évènements Sysmon sont stockés dans "Journaux des applications et des services" > "Microsoft" > "Windows" > "Sysmon". Si je réitère mon activité malveillante initiale (celle qui n'avait pas été ou peu journalisée par les logs par défaut de Windows) : voici ce que je peux voir dans les logs Sysmon (cliquez sur l'image pour zoomer) :
Journaux d'évènement Sysmon relatifs aux actions malveillantes effectuées sur le système.
Nous voyons clairement dans les logs : un event ID 1 - Process Create, un event ID 13 - Registry value set et and event ID 3 : Network Connecion detected. Ce qui correspond et retrace exactement les activités malveillantes réalisées sur le système. Dans la capture ci-dessus, nous avons les détails de l'exécution de "mimikatz64.exe", déjà exposé précédemment dans cet article. On peut noter la présence de nombreuses informations, dont le hash MD5 du binaire, qui ne changera pas en fonction du nom qui lui est donné (bien que des méthodes simples permettent de modifier ce hash pour qu'il ne colle plus aux signatures classiques).
Nous pouvons également regarder le contenu de l'évènement relatif à l'ajout d'une valeur dans une clé de registre :
Evènement Sysmon 13, relatif au paramétrage d'une valeur dans une clé de registre (mise en place d'une backdoor par l'attaquant).
À nouveau, nous avons un grand nombre d'informations à propos de l'évènement, le processus parent, le nom de la clé de registre modifiée, sa valeur, on y retrouve clairement l'exécutable malveillant, etc. Vous remarquerez également la présence du "T1060" dans l'attribut "RuleName", il s'agit de l'identifiant du TTP relatif à cette action malveillante. Cet ajout provient de la configuration SwitfOnSecurity et vise à aider l'analyste à comprendre la nature et l'impact d'un évènement de sécurité.
Pour mieux comprendre l'intérêt et les bénéfices de cette information, regardons par exemple le contenu du TTP T1060 sur le site du framework MITRE ATT&CK (le framework ayant été mis à jour récemment, l'action au TTP 1060 rédige vers son nouvel identifiant : T1547.001 - Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder ):
Extrait des détails du TTP1547.001 (anciennement T1060).
Il ne s'agit là que d'un extrait, mais l'on comprend ici bien plus en détail les enjeux de cet évènement : l'attaquant a cherché à établir une persistance sur le système en modifiant une clé de registre contenant des binaires exécutés au démarrage.
Enfin, voici l'évènement relatif au téléchargement d'un binaire malveillant depuis un serveur appartenant à l'attaquant, action qui n'était pas du tout journalisée par les logs par défaut de Windows :
Evènement Sysmon 3 relatif à une connexion réseau sortante.
Là aussi, nous obtenons des informations claires et précises sur l'évènement, notamment l'IP, nom et port de destination, qui sont des informations importantes en termes de détection (grâce aux IOC) et d'investigation.
Pour mieux comprendre chaque évènement produit par Sysmon, nous pouvons utiliser la documentation Microsoft, qui référence précisément les eventID et leur définition : Sysmon - Events
VII. Conclusion
J'espère que cet article vous a aidé à mieux comprendre ce qu'est Sysmon, son utilisation standard ainsi que sa plus-value pour la sécurité d'un système Windows et plus globalement du système d'information. Nous n'avons pas fait un tour complet de l'outil, notamment en ce qui concerne les évènements plus techniques (CreateRemoteThread, RawAccessRead, Process Tampering, etc.), ni la construction complète d'un fichier de configuration avec ses exclusions, exceptions, etc. Mais, le contenu de l'article devrait être suffisant pour mettre en place et utiliser Sysmon au sein de votre système d'information.
Ce qu'il est important de retenir au-delà de Sysmon est l'importance d'avoir une journalisation la plus complète et précise possible concernant les évènements de sécurité, puis d'être capable de la centraliser (SIEM) et de surveiller activement et comprendre ces différents évènements. Dans cette démarche macro, Sysmon n'est finalement qu'un point de départ.
N'hésitez pas à donner votre avis dans les commentaires ou sur notre Discord !
Connexion
