Architecture décentralisée

Listing 5.23 – Exécution d’un second invite de commande et écriture du script

Enfin, le second invite de commande va lire le contenu du script pour exécuter les commandes qui sont à l’intérieur. 5.24.

1 type=DTE audit(129676508875689710,221) avc:denied { read } for pid=2832 2 com="%systemroot%\system32\cmd.exe" ppid=2628

Listing 5.24 – Lecture du script par le second invite de commande

Grâce à la précision des fichiers d’audit, nous pouvons facilement suivre l’évolution de ce logi-ciel malveillant sur le système. Il nous est facile de suivre les relations de filiation grâce notamment auxPIDet auxPPID.

À travers l’étude des traces générées par notre moniteur, nous avons pu suivre l’évolution de l’installation du logiciel malveillant. Nous ne montrons pas tous les éléments de cette infection, mais nous pouvons bloquer une par une les interactions réalisées par le logiciel.

Ce scénario, entièrement joué puisque le moniteur est en mode détection, est un cas concret d’exécution du logiciel malveillant par un navigateur soumis à une attaque.

5.3.2.2 Architecture décentralisée

À partir de l’implantation du mécanisme de contrôle d’accès basée sur lesfilter-driver et les kernel callback, nous avons mis en place une architecture spécifique permettant d’analyser les logiciels malveillants. L’objectif de ces expérimentations est d’exécuter les logiciels malveillants sans bloquer leurs interactions dans le but de connaître leur impact sur le système entier et d’en étudier leur comportement.

Comme notre driverest en mode détection pour ces études, il enregistre chaque interaction effectuée sur le système. De plus, pour être sûr de ne pas rater d’interaction, il n’y a pas de poli-tique de contrôle d’accès. Cependant, le logiciel malveillant pourrait modifier le contenu du fichier d’audit, voire le supprimer puisqu’il est stocké sur le système et que les interactions ne sont pas bloquées par le moniteur. Pour éviter d’avoir des fichiers d’audit potentiellement modifiés par le logiciel malveillant, nous avons décidé d’envoyer directement les traces sur un serveur de sécurité distant.

Instrumentation du système La figure 5.8 représente notre nouvelle architecture du côté du Windows instrumenté. Cette architecture est divisée en quatre parties distinctes.

Le premier bloc traite les accès au système de fichiers. Lorsqu’une interaction est réalisée sur le système de fichiers, l’interaction est interceptée lors de son prétraitement par notre filter-driver(flèche 1, 2, 3). Lefilter-driverest chargé de construire une trace suffisamment précise pour pouvoir avoir toutes les informations nécessaires à l’étude du logiciel. De plus, pour avoir une chronologie des différentes interactions réalisées, nous ajoutons un identifiant unique pour chaque interaction ainsi qu’untimestamp. Nous obtenons ainsi une trace contenant :

1. un numéro de trace unique, ainsi que le numéro du cœur processeur qui exécute l’action ; 2. untimestamp;

FIGURE5.8 – Instrumentation du système pour l’analyse de logiciel malveillant 3. le type d’accès ;

4. nom court du processus qui a fait l’action etPID; 5. nom de l’objet.

Dans le but de ne pas faire de calcul intempestif sur la machine d’étude, nous ne calculons pas de contexte de sécurité. Cette tâche sera faite par le serveur de sécurité dans un modeoffline. Un exemple de trace générée est illustré par le listing 5.25. Cette trace est ensuite envoyée (flèche 4) authreadqui s’occupe de la communication avec le serveur de sécurité.

1 trace=1118 , cpu=0

2 timestamp=130208621983766250 3 Access : create

4 pid : consent.exe 568

5 Object Name : \Device\HarddiskVolume2\Users\toto\AppData\LocalLow

Listing 5.25 – Trace générée par lefilter-driverpour une interaction sur le système de fichiers Le second bloc traite de la gestion de processus. À chaque création ou mort d’un processus, un thread dufilter-driver enregistre certaines informations. Il doit récupérer les noms complets des processus impliqués, c’est-à-dire du père et du fils, ainsi que leurPID(flèche 5.1 et flèche 5.2). Une fois que ces informations sont enregistrées, la trace générée pour la création d’un processus 5.26 est envoyée au thread qui s’occupe de la communication avec le serveur de sécurité. La même chose est faite pour la mort d’un processus 5.27. Nous ne datons pas ces traces car ce n’est pas nécessaire. Nous nous servons de ces traces pour connaître les chemins complets ainsi que lesPID

des processus créés et détruits.

1 Parent Process name : \Device\HarddiskVolume2\Windows\System32\svchost.exe pid

=908

2 Process name : \Device\HarddiskVolume2\Windows\System32\consent.exe pid=568 ppid=908 sid=1

Listing 5.26 – Trace générée par lefilter-driverpour la création d’un processus

1 Parent Process name : \Device\HarddiskVolume2\Windows\System32\svchost.exe pid

=908

2 Process name : \Device\HarddiskVolume2\Windows\System32\consent.exe pid=568 ppid=908 sid=1

Listing 5.27 – Trace générée par lefilter-driverpour la mort d’un processus

Le troisième bloc de l’architecture concerne la gestion du registre. Tout comme pour le système de fichiers, nous n’interceptons que les requêtes en prétraitement. Lorsqu’un processus fait une in-teraction sur le registre, elle est interceptée (flèche 6) par le gestionnaire de registre puis transmise (flèche 7) à notredriver. LeRegistry Filter Driverrécupère toutes les informations nécessaires à la compréhension de l’interaction. Il ajoute aussi un identifiant unique ainsi qu’untimestamp. La trace construite est très proche de la trace générée pour le système de fichiers. Mais, en plus des informations de type nom du processus ainsi que sonPIDet nom de l’objet, qui dans ce cas la cor-respond à une clé registre, nous ajoutons le couple valeur et donnée dans la trace, pour connaître précisément les interactions du logiciel étudié. Nous obtenons ainsi une trace complète, comme le montre le listing 5.28, qui est envoyée authreadqui s’occupe de la communication avec le serveur de sécurité.

Listing 5.28 – Trace générée par ledriverpour une interaction sur le registre

Enfin, le quatrième bloc est celui qui gère les communications avec le serveur de sécurité.

L’implantation choisie sur le système instrumenté doit assurer deux règles importantes : la pre-mière règle est que les communications avec le serveur de sécurité distant doivent être assurées par un module dédié de l’architecture pour ne pas interférer avec le reste du mécanisme. Pour cela, nous utilisons unthreaddédié qui ne s’occupera que des communications réseau. La seconde règle impose que cette communication ne doit ni ralentir, ni bloquer le fonctionnement de la machine.

Pour cela, nous avons choisi une implantation basée sur le principe de producteur/consomma-teur. Les producteurs sont les trois parties précédemment présentées. Elles approvisionnent une file de messages sans attendre que le message soit envoyé. Ainsi, elles n’ont pas besoin d’attendre un retour de la part duthreadqui envoie les traces et elles ne bloquent donc pas les interactions.

Le consommateur est par conséquent lethreadqui récupère les traces et les envoie au serveur de sécurité.

Les communications sont réalisées sur une connexion TCP.

Nous noterons une chose importante. Nous avons ajouté dans les traces traitant les interactions du système de fichiers et du registre, un identifiant unique ainsi qu’untimestamp. Il est indispen-sable pour la compréhension de l’installation de l’infection que cet identifiant soit unique pour tout le système. Il est donc partagé entre les différentes parties de notre architecture.

De plus, comme nous le montrons dans les traces, nous n’enregistrons que le nom court des processus. Ce nom est récupéré grâce à la fonctionZwQueryInformationProcess. Elle va lire un champ de la structureEPROCESS².

Une étape importante est donc réalisée au moment du démarrage dudriver. Lors de cette étape, il va établir la liste des processus qui sont en cours de fonctionnement en recherchant, quand c’est possible, le père de chaque processus. En effet, sous Windows, il est possible qu’un processus n’ait pas de père (à la différence des systèmes Linux où les processus sont toujours au moins rattachés à init). Nous obtenons ainsi un graphe de l’activité courante du système. Cela nous permet aussi de connaître les chemins complets ainsi que les PIDdes processus qui sont lancés au moment où nous exécutons le logiciel étudié.

Serveur de sécurité distant Le serveur de sécurité est divisé en deux parties : la première partie est un serveur TCP, fait en python, qui récupère les traces envoyées par ledriver pour les mettre dans une base de données. Comme le nombre de traces est relativement grand, la mise en base est faite de manière offlinepour ne pas surcharger la machine. La seconde partie permet la vi-sualisation des résultats. Elle propose la génération de rapport présentant les activités qui se sont déroulées sur le système étudié.