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.
Par erreur, Microsoft a déployé la nouvelle application Copilot, correspondante à son IA, sur Windows Server ! Ceci est lié à une mise à jour du navigateur Microsoft Edge. Voici ce qu'il faut savoir !
Si vous utilisez Windows Server 2022 et que vous avez constaté la présence d'une nouvelle application nommée "Microsoft Copilot" dans la liste des programmes installés, sachez que vous n'êtes pas seul. Au-delà de son nom, elle est facilement identifiable grâce à son logo désormais utilisé un peu partout par Microsoft. De plus, sa taille est surprenante : seulement 8 Ko.
Que se passe-t-il ? Tout a commencé par l'introduction de "Copilot" dans les versions "Preview" de Windows Server 2025. En effet, depuis plusieurs mois, nous avons accès à des versions de Windows Server 2025 qui donnent un aperçu des nouveautés à venir et des changements opérés par Microsoft.
S'il y a bien un changement qui n'a pas plus, c'est l'ajout de l'IA "Microsoft Copilot" à Windows Server 2025. Suite aux nombreuses réactions négatives, Microsoft a pris la décision de retirer Copilot de Windows Server 2025. Mais, alors, comment cette application est-elle arrivée sur Windows Server 2022 ?
Microsoft Copilot ajouté par une mise à jour du navigateur Edge
Sur la page de son site destinée à évoquer "les problèmes connus", Microsoft s'est expliqué : "Les mises à jour de la version 123.0.2420.65 du navigateur Edge, publiées à partir du 28 mars 2024, peuvent installer de manière incorrecte un nouveau package (MSIX) appelé "Microsoft chat provider for Copilot in Windows" sur les appareils Windows. En conséquence, l'application Microsoft Copilot peut apparaître dans les applications installées dans le menu Paramètres." - Ceci affecte Windows Server, ainsi que Windows 10 et Windows 11.
Autrement dit, ceci ne correspond pas à l'ajout complet de Microsoft Copilot à Windows Server 2022, et cela ne permet pas d'utiliser l'IA directement depuis la barre des tâches du serveur. "Il est important de noter que le fournisseur de chat Microsoft pour Copilot dans Windows n'exécute aucun code ou processus, et n'acquiert, n'analyse ou ne transmet aucune donnée relative à l'appareil ou à l'environnement à quelque titre que ce soit.", précise Microsoft, afin de rassurer ses clients.
Cette application vise à préparer l'activation future de Microsoft Copilot sur certains appareils Windows, dont les serveurs Windows Server ne devraient pas faire partie. Désormais, l'entreprise américaine cherche une solution pour supprimer cette application : "Nous travaillons sur une solution et fournirons une mise à jour dans une prochaine version de Microsoft Edge."
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 !
Alpes-Maritime : l'Hôpital Simone Veil de Cannes est actuellement victime d'une cyberattaque ! Certaines activités clés sont paralysées suite à cet incident de sécurité. Voici ce que l'on sait !
Malheureusement, l'Hôpital Simone Veil de Cannes vient s'ajouter à la longue liste d'hôpitaux victimes d'une cyberattaque, malgré tous les efforts effectués par les équipes techniques. Cette cyberattaque s'est visiblement déroulée dans la nuit du 15 au 16 avril, puisque les activités de l'Hôpital sont perturbées depuis mardi 16 avril. Plusieurs systèmes informatiques sont paralysés suite à cet incident.
En réponse à cet incident de sécurité, une cellule de crise a été activée "en lien avec l’Agence Régionale de santé PACA et le Groupement Hospitalier de territoire des Alpes Maritimes, le directeur et le président de la commission médicale d’établissement.", peut-on lire sur le compte X (Twitter) du centre. L'ANSSI est également sur le coup pour l'accompagnement technique.
Cette cyberattaque impact l'hôpital et ce dernier ne peut pas fonctionner normalement. Justement, en attendant un retour à la normale, les opérations non urgentes ont été reportées, tout comme les consultations. "Dans ce cadre, le CH est contraint de reporter l’activité programmée non urgente n’entraînant pas de perte de chance. Les consultations non urgentes sont également reportées jusqu’à retour à la normale.", a indiqué l'Hôpital Simone Veil sur X.
Pour le moment, aucune information n'a été publiée quant à l'origine de cette attaque. Nous ignorons s'il s'agit d'un ransomware. Si vous disposez d'informations supplémentaires, n'hésitez pas à commenter cet article ou à me contacter.
