Antivirus, PowerShell et ORC pour le Live-Forensics

Introduction & contexte

Le contexte de la réponse à incident sur l’environnement poste de travail

Le live-forensics et la live-response sont des sujets dont nous trouvons des traces depuis plus de 10 ans [1] [2] [3] dans la littérature. En effet, lorsque l’on regarde l’activité des CSIRT, SOC et CERT, nous nous apercevons rapidement qu’il est presque impossible pour un SIEM de collecter les journaux d’événements permettant une couverture à 100 % des différents types d’IoC sans rencontrer rapidement des problèmes de dimensionnement ou de coûts et cela dès lors que l’on surveille des périmètres importants. Il suffit de regarder la verbosité d’une configuration sysmon par rapport à la simple collecte des journaux d’événements par défaut pour s’en rendre compte. Il est donc nécessaire d’avoir une approche itérative dans ces techniques de surveillance et de détection, mais également sur le plan des capacités de réponse.

Si les solutions EDR (Endpoint Detection & Response) [4] commerciales permettent d’adresser ces difficultés, notre expérience montre néanmoins des limitations sur certains aspects. Par exemple, des fonctionnalités absentes comme la collecte d’images mémoire, la recherche de formats d’IoC peu courants, l’impossibilité de définir des règles de détection personnalisées ou encore l’absence de capacité d’industrialisation des actions de remédiation sont des éléments parfois manquants dans ces produits.

Par ailleurs, les solutions libres telles que GRR Rapid Response ou DFIR-ORC permettent bien d’investiguer voire de compléter les fonctionnalités des EDR lorsque c’est nécessaire. Leur approche libre de droits permet de limiter les coûts associés et d’améliorer la confiance dans le code du logiciel, en contrepartie de l’absence de support éditeur et d’un report partiel des coûts vers la ressource humaine nécessaire. Mais dans tous les cas, ces 2 solutions ne répondent pas à la question des actions de remédiation sur les postes de travail, qui s’avère être une mission difficile sur de grands parcs informatiques.

Acquisition, ordonnancement, ciblage, collecte et lancement de tâches forensiques massives

Nous commencerons ici par rappeler les grandes problématiques qui sont censées être adressées par un outil de live-forensics, à savoir :

• la prévention ;
• la détection ;
• l’investigation ;
• la remédiation.

Il ne faut pas oublier que les capacités de détection automatisées des EDR ne couvrent souvent que les menaces ou techniques « connues » et que les capacités futures à base d’IA restent à éprouver. Au-delà de la recherche d’IoC la réalité du travail d’un SOC consiste aussi à rechercher de nouvelles menaces dans son parc supervisé. Posséder la bonne information, actionnable au bon moment, durant un incident est un des enjeux majeurs de la supervision de sécurité.

Dans le cadre d’investigations numériques, ce fait est d’autant plus marqué par la complexité d’acquisition d’informations qui est proportionnelle à la dispersion géographique des systèmes ainsi qu’à leur nombre (notamment quand le périmètre porte sur des centaines de milliers de postes). Dans ce sens, toute solution qui permet d’éviter le rapatriement physique des postes jusqu’au laboratoire de forensics et de limiter le nombre d’analyses complètes au strict nécessaire est un gain de temps et d’argent conséquent pour un organisme. En conséquence, l’ordonnancement des moyens de réponse par rapport aux besoins d’analyses au cours d’un incident est donc primordial dans une organisation.

L’autre aspect à ne pas négliger concerne le déploiement de l’agent qui répond à ces besoins qui peut s’avérer pour le moins compliqué et long en dehors d’une période d’incident sur des parcs conséquents. Nous constatons régulièrement les doutes que les équipes en charge des postes de travail expriment à propos de l’ajout d’un agent supplémentaire sur des machines souvent déjà bien chargées.

De ce constat, nous dessinons un besoin intermédiaire en live-forensics que l’on qualifiera ici de « léger » et qui doit permettre de compléter les recherches lorsque les SIEM ne collectent pas les traces nécessaires et que les EDR ne possèdent pas la fonctionnalité (ou sont simplement absents du périmètre), mais aussi de déployer efficacement des outils plus lourds comme DFIR-ORC le cas échéant.

1. Antivirus : point d’entrée de l’environnement bureautique

Comme nous l’avons évoqué plus haut, le déploiement d’un outil de live-forensics sur le parc peut s’avérer difficile selon les contextes. Il est donc intéressant de s’appuyer sur des solutions existantes qui, malgré certaines limitations par rapport à des solutions dédiées, sont déjà en place et largement déployées. Les antivirus restent une première barrière active et fiable et sont déjà largement présents dans nos parcs informatiques, ce qui répond à ces critères.

Certains éditeurs de ces solutions proposent dans leur produit une fonctionnalité permettant l’exécution de code par l’agent antivirus sur les clients. Par exemple, dans le produit Broadcom Symantec Endpoint Protection cette capacité est accessible via le module d’intégrité de l’hôte, au travers d’un contrôle personnalisé avec une action nommée « utilitaire : exécuter un script » [5]. Il est ensuite possible de paramétrer l’intervalle d’exécution du contrôle et donc du script.

Cette fonction initialement prévue pour du contrôle de conformité et d’éléments fixes (clé de registre, fichier) probablement en vue de faire du NAC et de la gestion de quarantaine des postes peut être détournée pour exécuter le code d’agents de live-forensics (ou par un attaquant qui mettrait la main sur votre console antivirus…). Si le mode de fonctionnement par exécution à intervalle régulier peut limiter certains usages, cela permet quand même aux équipes de défense de se doter rapidement et à moindres frais d’une capacité d’exécution de code PowerShell avec des privilèges système.

On peut se servir de cette fonction pour compléter les capacités manquantes des EDR, maximiser le nombre de routes possibles pour les interventions et donc également déployer des outils complémentaires par un effort de développement raisonnable d’un framework PowerShell modulaire.

2. Get-Spice : light live-forensics et ordonnancement de tâches

2.1 Un outil de forensique rapide et interopérable

Get-SPICE (pour Get Secure PowerShell Investigation & Control for Endpoint) est un projet open source initié par le SOC (Security Operations Center) du groupe EDF. C’est un outil conçu pour réaliser des investigations numériques simples, et permettre de déployer rapidement l’outillage nécessaire aux investigations complètes en cas de suspicion d’incident. Un module de réponse actif est également prévu pour permettre par exemple des actions de nettoyage scriptées.

Fonctionnellement, Get-Spice se compose de deux parties : un agent déployé sur les postes, et un serveur orchestrant les analyses à effectuer. Il s’agit d’un mode de transaction client-serveur assez classique.

Écrit en PowerShell, intégré nativement aux systèmes Windows depuis Windows XP, l’agent ne requiert pas l’installation d’autres logiciels tiers ; ce qui garantit une compatibilité avec une grande majorité des postes Windows du système d’information. Pareillement, le serveur est codé en Go, langage de programmation open source développé par Google, et peut aussi être compilé à destination des systèmes d’exploitation de type UNIX-like.

Get-Spice repose sur une architecture centralisée, les ordinateurs se connectent au serveur et récupèrent régulièrement la liste des tâches de collecte qui leur sont assignées pour ensuite les effectuer et retourner les informations récupérées au serveur. Ces actions effectuées localement sur les ordinateurs sont orchestrées par l’agent Get-Spice, exécuté en tâche de fond, qui communique avec le serveur par le biais de requêtes HTTP.

2.2 Architecture et modules de recherche

Les différentes fonctionnalités de recherche et de collecte sont associées à l’agent de manière modulable. Aucune des fonctionnalités exécutées n’est inhérente à l’agent déployé sur les hôtes, elles sont toutes issues de modules.

Ces modules sont tout simplement des scripts PowerShell, décrivant une ou plusieurs fonctionnalités d’investigation bien distinctes des autres, comme contrôler une clé de registre ou vérifier la présence d’un fichier via un hash.

Avant d’exécuter un contrôle, l’agent vérifie si le module correspondant a déjà été téléchargé, s’il est inexistant sur l’hôte, l’agent demandera au serveur d’identifier le module contenant ladite fonctionnalité et de le mettre à disposition pour qu’il puisse être téléchargé. Une fois le module téléchargé, il est placé dans un répertoire local servant de cache.

À l’exécution, les fichiers PowerShell constituant le module d’origine, sont chargés par l’agent, en cours d’exécution, en tant que blocs de script puis exécutés.

Ci-dessus le module Inspect-Register permet de lire la valeur d’une clef de registre qui a été spécifiée en paramètre. Les résultats sont renvoyés au format Syslog à l’aide d’une fonction utilitaire pour permettre un traitement des résultats dans un SIEM.

Get-Spice est une solution rapide à installer et à utiliser, pour collecter des informations ciblées en temps réduit. Cependant, les fonctionnalités doivent être codées au préalable, ce qui peut s’avérer chronophage. Certaines menaces requièrent une vue d’ensemble pour être détectées, nécessitant la collecte de centaines d’artefacts à des emplacements différents. Dans l’urgence, si ce scénario complexe n’a pas été préparé, Get-Spice s’avérera inadapté. C’est ainsi que Get-Spice a notamment été conçu pour permettre de déployer des outils bien plus complets tels que DFIR ORC.

3. ORC : un PE32 pour les gouverner tous et dans Get-Spice les lier

L’Outil de Recherche de Compromission (ou tout simplement ORC) est un logiciel d’acquisition de données forensiques en environnement Windows publié par l’ANSSI en 2019 sur GitHub. L’agence a créé cet outil en 2011 dans le but de s’adapter aux nouvelles menaces de type APT. Il se devait donc d’être suffisamment pointu pour récupérer uniquement la donnée nécessaire lors d’une investigation numérique, tout en restant souple afin de s’adapter aux changements de contexte de cette dernière.

Pour définir ORC de manière synthétique, nous le qualifierons d’ordonnanceur de tâches de collectes forensiques, modulaire et autonome, se présentant une fois configuré sous forme d’un unique exécutable Windows. Il est fourni avec une suite d’outils de collecte assez complète embarquée de base [6], mais ses capacités peuvent être étendues par l’ajout d’autres outils externes à travers un mécanisme nommé ToolEmbed [7].

Selon nous, cet outil présente plusieurs atouts majeurs : maximiser le travail de préparation avant un événement de sécurité en offrant aux équipes de réponse à incident la possibilité de paramétrer des collectes d’informations spécifiques (configuration WolfLauncher [8]), d’y ajouter des conditions de lancement (ex. version et type de système d’exploitation Windows) et de les centraliser au sein d’un kit d’intervention numérique.

Mais sa force réside dans le détail des types de paramétrages possibles liés aux collectes. Il est notamment possible d’imposer une priorité au processus ORC s’exécutant sur un système, de paramétrer sa consommation de mémoire vive et/ou de temps processeur, ceci dans le but d’adapter son impact sur chaque cible. Enfin, les sorties des outils de collecte peuvent être configurées pour être réparties dans des archives puis déposées dans un répertoire ou bien transférées sur un serveur distant via le composant Windows BITS. Il est à noter que ce choix de mode de transfert n’a pas été fait au hasard : comme décrit précédemment, ce composant réduit grandement la charge réseau générée par les transferts de fichiers.

3.1 Système d’héritage des configurations

ORC permet de paramétrer sa configuration de trois manières différentes. La première manière correspond à la configuration de base du précieux binaire unique illustrée par le schéma ci-dessous :

Un script MS-DOS ainsi que des fichiers de configuration XML permettant d’effectuer cette configuration sont mis à disposition dans un des dépôts de code de l’ANSSI [9]. Cette phase correspond à la construction du socle d’outils sur lequel nous allons configurer nos profils de recherches. L’objectif étant d’embarquer tout ce qui est susceptible d’être utilisé pendant une intervention. En l’état, l’exécutable effectuera donc toutes les collectes possibles, ce qui en matière de temps d’exécution et d’impact sur un système est loin d’être optimal.

Il est possible d’affiner les recherches en utilisant en complément la seconde méthode proposée par l’outil : les fichiers de configuration locaux. Ces fichiers, une fois placés dans le même répertoire que le binaire configuré, permettent de réécrire des paramètres à la volée, notamment les collectes à enclencher ou encore la méthode de transfert des archives résultant des sorties d’outils comme nous le montrerons plus loin.

Enfin, en cas de dernier recours, il est possible de lancer des collectes directement depuis la ligne de commandes d’ORC. Cette dernière méthode est utile pour les besoins de dernière minute, par exemple lors d’une intervention sur site. Sans avoir à reconfigurer totalement l’outil, il suffit pour un opérateur de taper quelques commandes pour le paramétrer à nouveau [10] ou même, pour des besoins très succincts, une simple commande permet de lancer une collecte d’artefact bien précise :

Ce mécanisme de réécriture de configuration est d’ailleurs très bien décrit dans le tutoriel mis en ligne par l’ANSSI [11]. Il vous permettra notamment d’adapter l’outil en fonction de vos besoins lors d’une intervention (ex. matériel disponible et contexte de l’opération) et de la maturité de votre SI (ex. déploiement automatisé par SCCM/Active Directory et rapatriement des données par BITS/SMB).

3.2 Profils de recherche

Lors d’une intervention sur un ou plusieurs systèmes, un plan de recherche (qu’il soit informel ou explicitement rédigé) listant les questions auxquelles un analyste doit répondre pour clore un incident est souvent de mise. Le but de ce plan est de sélectionner la donnée à collecter pour répondre à ces questions. Or, juste après sa configuration initiale, ORC effectue toutes les collectes possibles. Ceci engendre une perte de temps sur deux étapes : lors de la collecte et de l’analyse. Il est donc souhaitable de sélectionner uniquement la donnée en fonction du contexte de l’investigation.

Ainsi, il est possible d’associer les fichiers de configuration locaux DFIR-Orc.xml à ce besoin. Ils sont la traduction des problématiques soulevées dans un plan de recherche qui pour être résolues nécessitent la collecte d’artefacts bien précis. Nous avons donc classé un certain nombre de ces configurations par grande famille d’artefacts dont voici un exemple :

Cette manière de procéder présente deux intérêts :

1. le gain de temps : il suffit pour un opérateur de sélectionner le bon fichier de configuration en fonction du plan de recherche, c’est tout.
2. la simplicité d’utilisation : par les fichiers de configuration, n’importe qui est en capacité de lancer une collecte.

En supplément de la programmation des collectes, il est possible de définir dans ces fichiers le mode de rapatriement des archives de collectes ORC :

Grâce à cela, ORC transférera les archives de fin de collecte sur un serveur IIS. Les équipes de réponse à incident pourront en se connectant à ce serveur procéder à l’analyse des résultats. Néanmoins, il est à noter que le nombre d’archives s’accumule très vite et les examiner au cas par cas peut s’avérer assez laborieux.

Le but final étant bien évidemment de pouvoir déployer massivement ORC sur un ensemble (utilisation d’un mécanisme de ciblage type WQL) d’un parc Windows. En ce sens, Get-SPICE offre à notre intégration ORC un canal de déploiement simple, efficace, stable et évolutif. Des modifications mineures seront nécessaires pour l’adapter à un potentiel changement de solution antivirus, garantissant toujours un moyen de déploiement massif d’ORC.

3.3 Ciblage fin des artefacts

Pour entrer un peu plus dans le détail de la collecte, penchons-nous sur un des outils de collecte de la suite interne ORC : RegInfo. Comme son nom l’indique si bien, cet outil permet de collecter sur la base de critères de ciblage [12] assez précis des informations contenues dans les clés de registres des ruches Windows.

Le fichier de configuration ci-dessus reste relativement simple, il n’en reste que les critères vont assez loin dans les possibilités de ciblage :

• type de valeur contenue dans la clé de registre ;
• valeur absolue ou partielle contenue dans la clé de registre (en hexadécimal, chaîne de caractères brute ou même expression régulière) ;
• taille de la valeur contenue (intervalle ou simple seuil).

À l’image de la majorité des outils intégrés à ORC, plus il y a de critères, plus la collecte ira vite constituant ainsi un double avantage : traquer les anomalies ayant des caractéristiques dérivant du comportement nominal du système et récupérer rapidement de la donnée.

3.4 Un exemple (clé USB)

Le lancement par clé USB d’ORC, à condition de disposer de l’outil bien configuré et un fichier de configuration local reste relativement simple. Il suffit de déposer le binaire et le fichier XML sur une clé, de la brancher sur le système cible, et de lancer l’exécutable avec les privilèges nécessaires.

Attention, si vous avez prévu un rapatriement BITS en fin de collecte, l’authentification au service associé du fait de l’élévation de privilèges risque de vous poser problème [13].

Hormis quelques complexités de mise en place, le transfert des collectes par BITS reste indéniablement le plus avantageux. Il rend possible une collecte massive d’artefacts là où une acquisition manuelle massive semble peu envisageable. À l’instar de Get-SPICE, sa seule contrainte reste l’accès au réseau. Il est impossible de transférer des archives sans un moyen d’atteindre le serveur de rapatriement. Dans ces cas-là, l’option d’exécuter ORC au travers d’une clé USB reste une solution, à condition que le nombre de systèmes sur lesquels doit s’effectuer la collecte soit proportionnel aux capacités de personnel sur place ainsi qu’au nombre de clés disponibles. Cela reste néanmoins un moyen très efficace sur un nombre réduit de systèmes hors réseau.

3.5 ORC en tant que module Get-Spice

DFIR ORC peut être déployé sur l'intégralité des postes en tant que module de Get-Spice, il suffit de planifier son téléchargement comme un module classique, suivi de son exécution une fois celui-ci téléchargé par le client.

Les configurations de DFIR ORC ainsi que l’exécutable doivent être rassemblés dans une archive ZIP puis téléversés sur un serveur IIS (Internet Information Services, un serveur web de Microsoft disponible dans toutes les versions de Windows NT). L’agent Get-Spice télécharge cette archive depuis le serveur IIS pour en extraire le contenu dans un répertoire temporaire afin de pouvoir lancer DFIR ORC en tâche de fond.

Le téléchargement de DFIR ORC peut aussi se faire par le biais de BITS (Background Intelligent Transfer Service) au travers de la cmdlet Start-BitsTransfer. BITS est un composant Windows qui permet le transfert de fichiers asynchrones utilisant la bande passante lorsqu’elle est inoccupée. Il assure notamment une reprise du transfert en cas d’interruption.

Chaque téléchargement effectué par BITS est défini comme « job » auquel il est possible d’associer des propriétés de téléchargement (priorité, utilisation d’un proxy, authentification…), ce qui permet aussi l’exécution d’un programme à la fin d’un téléchargement si spécifié.

Le déploiement par Get-Spice, permet aux investigateurs de s’affranchir de l’installation de DFIR-ORC, mais aussi de la suppression des fichiers nécessaires à son lancement.

Conclusion

Si les politiques d’intégrités SEP ont pour objectif de garantir ou de contrôler l’intégrité des postes clients, elles peuvent aussi planifier, sur un ensemble d’ordinateurs l’exécution d’un script de live-forensics à intervalles réguliers. Ce détournement permet l’exécution de l’agent Get-Spice par l’antivirus et de s’appuyer sur une infrastructure de sécurité existante pour ajouter ou compléter à moindres frais les capacités de live-forensics lorsque cela devient nécessaire.

Même si le développement de Get-Spice est encore à l’état de preuve de concept et présente certaines limitations comme l’absence de support des environnements Linux ou l’utilisation du module de l’antivirus qui ne permet pas de contacter l’agent sur demande, le projet reste open source et basé sur un fonctionnement par API. Il pourra donc être adapté à l’avenir pour couvrir ces besoins tout comme le passage à grande échelle qui n’a pas encore été adressé.

De même, malgré un certain regret de ne pouvoir admirer l’ORC gambader avec ses camarades ELF et DWARF sur les terres d’UNIX-like, il faut admettre que sur le domaine Microsoft il offre un grand nombre de possibilités d’acquisition de données qui en font un réel outil de référence. Le fait de tout réunir au sein d’un seul exécutable offre un réel confort lors d’une collecte manuelle et lui permet par la même occasion de s’intégrer facilement avec d’autres outils.

La synergie possible entre un agent léger comme Get-Spice et un outil complet comme ORC nous semble prometteuse dans une optique de Live-Forensics. Elle permet d’effectuer des contrôles simples et évolutifs dans une approche DevOps et de distribuer ensuite les outils complets comme ORC lorsque c’est nécessaire, ce qui permet une approche à la fois minimaliste et ajustable au besoin de l’outillage requis sur les postes pour le live-forensics.

Remerciements

Les auteurs tiennent à remercier particulièrement Marion, Amadou, Thomas et Frédéric pour leurs relectures attentives ainsi que l’ensemble de l’équipe SOC d’EDF pour avoir rendu possible cet article.

Références

[1] MISC n°56 – Les « live forensics » et l’enquête judiciaire, Eric Freyssinet :
https://connect.ed-diamond.com/MISC/MISC-056/Les-live-forensics-et-l-enquete-judiciaire

[2] MISC n°87 – Arrêtez de grogner avec GRR Rapid Response !, Étienne Ladent :
https://connect.ed-diamond.com/MISC/MISC-087/Arretez-de-grogner-avec-GRR-Rapid-Response

[3] MISC n°94 – Threat hunting 101, Chopitea Thomas :
https://connect.ed-diamond.com/MISC/MISC-094/Threat-hunting-101

[4] Wikipédia – Endpoint detection and response : https://fr.wikipedia.org/wiki/Endpoint_detection_and_response

[5] Using Endpoint Protection's Host Integrity feature to check if a Microsoft patch is installed : https://knowledge.broadcom.com/external/article/179348/using-endpoint-protections-host-integrit.html

[6] DFIR ORC Documentation – Embedded Tool Suite : https://dfir-orc.github.io/embedded_tool_suite.html

[7] DFIR ORC Documentation – ToolEmbed : https://dfir-orc.github.io/ToolEmbed.html

[8] DFIR ORC Documentation – WolfLauncher Configuration File : https://dfir-orc.github.io/wolf_config.html

[9] GitHub – DFIR ORC Configuration : https://github.com/DFIR-ORC/dfir-orc-config

[10] DFIR ORC Documentation – Architecture :
https://dfir-orc.github.io/tuto.html#edit-embedded-configurations

[11] DFIR ORC Documentation – Tutorial :
https://dfir-orc.github.io/architecture.html#deployment-specific-configuration

[12] DFIR ORC Documentation – RegInfo : https://dfir-orc.github.io/RegInfo.html

[13] Documentations Microsoft – Issues with BITS :
https://docs.microsoft.com/de-de/security-updates/windowsupdateservices/18127392