Speaker #0En cybersécurité, le concept du living of the land ou lol consiste, pour un attaquant, à utiliser des outils ou applications légitimes déjà présentes sur les systèmes de la victime pour réaliser ses actions malveillantes. Cette technique permet à l'attaquant de rester discret car elle évite d'installer des logiciels suspects pouvant être détectés par les antivirus. Ainsi, les attaquants exploitent la confiance et la légitimité des ressources déjà installées, rendant la détection de leur activité particulièrement complexe pour les systèmes de sécurité classiques. C'est un peu comme essayer de fabriquer une bombe avec des ingrédients ménagers. Nous possédons tous, dans nos placards, divers produits chimiques destinés au nettoyage, chacun étant à première vue inoffensif. Pourtant, certaines combinaisons spécifiques peuvent devenir très toxiques. voire dangereuses, provoquant parfois des accidents graves ou même des explosions inattendues. Ainsi, même si chaque produit paraît banal lorsqu'ils sont isolés, l'association imprudente ou mal intentionnée de plusieurs d'entre eux peut mener à des situations potentiellement critiques. Dans le domaine informatique, certains outils initialement destinés à des fins légitimes peuvent également être employés à des fins malveillantes. Prenons un exemple concret avec la commande Color CPL. Cette commande est normalement utilisée pour ouvrir la boîte de dialogue permettant de gérer les profils couleur de l'écran. A première vue, il s'agit d'une commande tout à fait inoffensive. Toutefois, si vous saisissez cette commande en indiquant en paramètre le nom d'un fichier précis, ce fichier sera copié dans un autre répertoire. Il s'agit donc d'une manière détournée d'effectuer une copie de fichier sans passer par une commande officiellement et clairement dédiée à cet effet. Bien que cet exemple soit minimaliste, il illustre une problématique complexe. A quel moment peut-on considérer qu'un comportement informatique devient malveillant L'exécution de la commande en soi est tout à fait légitime, puisque le paramètre permet habituellement de charger un profil de couleur dans le répertoire prévu à cet effet. Cependant, dans ce cas précis, la commande est utilisée pour copier un fichier n'ayant aucun lien avec le profil de couleur. Toute la nuance réside précisément là. La commande elle-même est légitime. Mais c'est le contexte et l'intention derrière son usage qui déterminent ce caractère malveillant. Et c'est exactement cela qui rend cette méthode particulièrement redoutable. Car a priori, tout semble normal. Il existe cependant des moyens de mitiger ce risque. Mais pour les comprendre, il faut rentrer un petit peu dans les détails. L'exemple présenté ici est relativement simple, car le programme n'interagit pas beaucoup avec le système d'information. Cependant, certaines applications ou commandes peuvent gérer de nombreuses interactions supplémentaires, ce qui complexifie grandement la surveillance et l'analyse des comportements du programme. En effet, il est important de comprendre qu'un programme exécute souvent d'autres commandes en arrière-plan, créant ainsi une cascade d'appels susceptibles d'impacter la sécurité globale du système. Pour mieux appréhender ces interactions, il existe des outils spécialisés permettant de surveiller l'exécution d'un processus et d'observer précisément les échanges entre ce processus et son environnement d'exécution. Ces outils sont particulièrement précieux, car ils permettent d'identifier non seulement les commandes exactes lancées par le processus, mais aussi les accès aux ressources, les fichiers ouverts, les modifications dans le registre du système et bien d'autres activités potentiellement sensibles. Dans ce contexte, il n'est pas rare de constater des vulnérabilités permettant de détourner l'exécution normale d'un programme. Typiquement, lorsqu'un programme appelle une commande destinée à exécuter un autre programme, le système vérifie en priorité si le programme cible existe localement, c'est-à-dire dans le répertoire courant d'exécution. Si ce n'est pas le cas, le système explore ensuite d'autres répertoires définis dans la variable d'environnement PASS à la recherche du programme demandé. Cette recherche suit un ordre prédéterminé définissant ainsi une priorité d'exécution. Mais que se passe-t-il si un programme portant exactement le nom que celui cherché se retrouve déjà dans un répertoire courant Dans ce cas, c'est le programme local qui sera exécuté en priorité, court-circuitant ainsi l'appel légitime prévu initialement par le système. Cette particularité ouvre la voie à une catégorie bien connue de vulnérabilité appelée hijacking ou détournement du chemin d'exécution. On pourrait se demander quel intérêt présente le fait de lancer explicitement une commande pour exécuter un programme déjà présent localement. La réponse réside précisément dans la différence des contextes d'exécution possibles. Lorsqu'un programme est lancé directement par l'utilisateur, il hérite généralement des droits d'exécution limités à ceux de cet utilisateur. En revanche, lorsqu'un programme est invoqué indirectement par une commande intermédiaire ou par un processus parent avec des privilèges plus élevés, par exemple ceux de l'administrateur du système, il bénéficie d'un contexte différent, parfois associé à des droits d'exécution beaucoup plus étendus. Cette situation présente des risques importants. Un attaquant pourrait ainsi déposer un programme malveillant portant le même nom que celui attendu dans un répertoire non sécurisé, afin d'exploiter ce mécanisme et ainsi élever ses privilèges ou compromettre davantage le système. Le principe que je viens de décrire est relativement universel, car il s'applique à un grand nombre de commandes, mais aussi au script notamment ceux qui sont exécutés à des moments précis. En effet, dans la majorité des systèmes d'information, on retrouve un orchestrateur de tâches, tel que le planificateur de tâches sous Windows ou Chrome sous Linux. Il exécute régulièrement des actions automatisées, plus ou moins complexes sur le système. Dans cette logique, l'exécution planifiée de certains scripts peut être détournée à des fins malveillantes. Un attaquant pourrait, par exemple, modifier un script légitime ou en injecter un nouveau afin de lancer un programme malveillant, souvent avec les mêmes privilèges que le processus initial. Cela signifie qu'une élévation de privilèges peut également être exploitée, rendant l'attaque encore plus critique. Plus inquiétant encore, il est possible d'utiliser des commandes totalement légitimes pour charger un code malveillant directement en mémoire, sans jamais écrire de fichier sur le disque. Ce type d'attaque, connue sous le nom de fileless est particulièrement difficile à détecter. Elle exploite les processus en cours, et les outils natifs du système pour exécuter un malware de manière furtive, échappant ainsi à de nombreuses solutions d'antivirus traditionnelles qui se basent principalement sur l'analyse de fichiers. Ces techniques sont de plus en plus utilisées par les cybercriminels car elles permettent de rester discrets, d'échapper aux systèmes de détection classiques et de maximiser leur impact, tout en minimisant les traces laissées sur le système. Voici un exemple détaillé dont vous trouverez la description complète dans les commentaires de cet épisode. L'attaque commence par l'utilisation détournée, mais en apparence légitime, de la commande regsrv32. Cette commande, accessible depuis une interface en ligne de commande, est habituellement utilisée pour manipuler les enregistrements du registre du système Windows, notamment pour enregistrer ou désenregistrer des fichiers DLL dans le registre. Dans l'exemple présenté, la commande regsrv32 est appelée avec comme paramètre une URL pointant vers un site externe pour charger un fichier XML distant. Cette première étape, anodine en apparence, permet en réalité de charger un petit script JavaScript intégré au fichier XML. Ce script a une fonction cruciale, initier le téléchargement du malware lui-même sur la machine cible. Bien entendu, pour maximiser son efficacité et éviter la détection, le code JavaScript chargé lors de cette étape initiale est soigneusement offusqué. Cette offuscation consiste à mélanger le code. Utiliser des encodages inhabituels ou encore fragmenter les instructions afin de rendre l'identification est l'analyse plus complexe pour les outils automatisés des systèmes de sécurité. Une fois le script JavaScript chargé et exécuté discrètement sur le système compromis, il déclenche un téléchargement du malware principal. Ce processus implique alors l'émission d'une requête vers un second site distinct afin de récupérer un fichier particulier nommé five-icon A première vue, cette opération semble totalement anodine. Car un fichier 5-icons est typiquement légitime et omniprésent sur les sites web modernes. Il s'agit d'un petit fichier graphique représentant l'icône du site web visible dans l'omblet ou la barre des favoris du navigateur. Toutefois, dans cet exemple précis, ce fichier prétendument légitime cache en réalité le malware lui-même, subtilement dissimulé pour tromper la vigilance des systèmes de défense. Le fichier récupéré est ainsi minutieusement préparé par les attaquants grâce à une double opération de chiffrement et de compression, afin d'assurer une discrétion maximale. Une fois que ce fichier 5-icon spécifique est correctement téléchargé sur la machine de la victime, il subit une phase critique de traitement qui comprend à la fois le déchiffrement des données et la décompression. A l'issue de cette phase, le code obtenu se trouve prêt à être utilisé. Cependant, avant l'exécution finale, un détail crucial reste à réaliser. Le malware ajoute simplement les caractères MZ au début du fichier traité. A première vue anodine, cette action est pourtant fondamentale et nécessaire pour l'exécution immédiate en mémoire du malware, réalisée à travers une fonctionnalité légitime de PowerShell appelée Commandlet PE, PE pour Portable Execution. Mais pourquoi ajouter précisément les caractères MZ au début du fichier, juste avant son exécution La raison est simple et astucieuse. Sous Windows, tous les fichiers exécutables commencent obligatoirement par les caractères MZ. indiquant au système qu'il s'agit bien d'un programme exécutable. Ainsi, l'ajout tardif de ces caractères est soigneusement calculé par les attaquants. Le fichier traité pourrait être considéré comme un simple ensemble de données génériques, ne déclenchant aucune alerte majeure au niveau du mécanisme de sécurité. Dès que ces caractères MZ sont ajoutés, le fichier devient officiellement exécutable pour le système d'exploitation, signalant clairement une intention malveillante potentielle aux outils de détection. Cette méthode astucieuse permet ainsi au malware de franchir les différentes étapes de contrôle et de défense sans éveiller prématuralement les soupçons, maximisant ses chances de succès et d'implantation durable dans le système cible. Vous avez compris, l'utilisation de commandes et de fonctions parfaitement légitimes permet à un attaquant de se camoufler et d'éviter ainsi de se faire détecter. Mais comment éviter ce genre d'attaque Pour se protéger efficacement contre ce type d'attaque qui exploite des outils légitimes à des femmes malveillantes, Plusieurs mesures préventives et défensives peuvent être mises en place. Par exemple, numéro 1, désactiver ou restreindre l'usage de certaines commandes. Si certaines commandes ne sont pas nécessaires dans votre environnement, il est recommandé de les désactiver ou de restreindre leur exécution à des utilisateurs ou des processus spécifiques. Numéro 2, surveiller l'utilisation des commandes de système. Mettre en place des outils de supervision qui détaquent l'usage anormal ou non autorisé de commandes système, comme Reg SRV32, PowerShell ou WMI. Numéro 3. Configurer AppLocker ou Windows Defender Application Control, WDAC. Ces outils permettent de contrôler quels scripts ou exécutables peuvent être exécutés sur les postes, résuisant ainsi les risques d'exécution de codes non autorisés. Numéro 4. Bloquer les connexions de sortantes suspectes. Utilisez un firewall ou un proxy pour analyser les URL sortantes et bloquer les connexions vers des domaines inconnus ou non approuvés. Numéro 5. Mettre à jour les systèmes et les antivirus. Assurez-vous que tous les systèmes d'exploitation, logiciels antivirus et signatures sont à jour pour profiter des dernières protections. Numéro 6. Analysez les fichiers en profondeur. Les fichiers comme les five icons doivent être vérifiés en profondeur s'ils ne sont pas téléchargés depuis une source fiable. Numéro 7. Sensibilisez les utilisateurs. Formez les employés à reconnaître les comportements suspects. Les incitez à ne pas cliquer sur des liens inconnus. et à signaler toute activité anormale. Numéro 8, segmenter le réseau. Une bonne segmentation du réseau peut limiter la propagation d'un malware en cas de compromission. Encore une fois, en matière de cybersécurité, tout réside dans la préparation. Et c'est malheureusement ce qui a été fatal pour Christopher McCandles. Le jeune homme, bien qu'animé par une volonté sincère de vivre en harmonie avec la nature, était visiblement mal préparé à affronter les rigueurs de la vie sauvage, en particulier dans les conditions extrêmes de l'Alaska. Il ne disposait même pas d'une carte topographique de la région. Un outil pourtant essentiel pour s'orienter et repérer les ressources disponibles dans un environnement aussi isolé. Ignorant l'existence de certaines infrastructures, Christopher McCandell ne savait pas qu'un bac manuel permettant de traverser la rivière Taclanica en toute sécurité était en fonction, à seulement quelques centaines de mètres, de l'endroit où il s'était arrêté. De plus, quatre abris d'urgence contenant des vivres, des couvertures et du matériel de survie se trouvaient dans un rayon d'une dizaine de kilomètres, mais ils n'en avaient pas la connaissance. Selon John Krakauer, auteur du livre Into the Wild, et célèbre journaliste ayant lui-même survécu à une expédition dramatique sur l'Everest, ainsi que Peter Christian, garde forestier en Alaska, une simple carte détaillée de la zone aurait très probablement permis à Christopher de survivre. Ce manque de préparation logistique, couplé à une méconnaissance des dangers du territoire, a donc contribué à une issue tragique qui aurait pu être évitée avec quelques précautions de base. Encore merci d'avoir écouté cet épisode de la cybersécurité expliquée à ma grand-mère. N'hésitez pas à le liker, à le partager avec d'autres, à en parler autour de vous. Si vous êtes sur Spotify, vous pouvez aussi donner votre avis et proposer des sujets qui vous semblent pertinents. Mais surtout, n'oubliez pas, pour certains, la cybersécurité est un enjeu du vieux de l'an, c'est bien plus sérieux que ça. Sous-tit
