Une fois le botnet (ou un de ses composants) détecté, s’en suit la phase d’investigation. L’objectif de cette section n’est pas de décrire l’ensemble de ces étapes parfois très techniques de façon exhaustive, mais de pointer certaines difficultés que l’on pourrait rencontrer ou axes de développements en cours ou à venir de la part de la communauté.
Nous avons vu au premier chapitre que les développeurs de codes malveillants utilisaient différentes méthodes pour rendre plus difficile non seulement la détection mais aussi l’analyse de ces logiciels. C’est la difficulté principale à laquelle vont être confrontés les chercheurs.
fonctionnalités) et les autres composants du botnet (le système de commande et de contrôle par exemple), et la façon dont c’est réalisé. En particulier il pourra s’agir de réaliser des rapprochements entre plusieurs logiciels malveillants à partir de leur architecture et de leur code.
Les techniques d’analyse se décomposent traditionnellement en méthodes statiques et dynamiques (avec exécution du code malveillant), qui vont parfois se combiner. Nous allons les parcourir en fonction de leur complexité.
3.3.1 L’analyse en bac à sable
L’analyse en bac à sable est souvent la première approche des observateurs de logiciels malveillents. Il s’agit [ESKK08] d’exécuter le code malveillant dans un simulateur, une ma-chine virtuelle ou une mama-chine physique sous contrôle, reposant sur le système d’exploitation ciblé, avec un certain nombre de capteurs permettant de mesurer l’activité sur le système de fichiers, les process créés, les appels de fonctions du système d’exploitation ou des composants installés, dans la base de registres Windows (ou le service équivalent dans les autres systèmes d’exploitation), la mémoire ou sur le réseau.
La première brique de l’apprentissage des analystes débutants est généralement l’exécution manuelle dans un environnement virtuel (Virustotal, VMWare,...) avec un ensemble d’outils pré-installés dans la machine virtuelle ou en périphérie (pour simuler ou filtrer les interactions avec Internet, comme INetSim11, FakeNet12 ou Mozzle [GLB12]).
L’analyse en bac à sable étend ce modèle et peut être totalement automatisée, donner des résultats très rapides. S’ils ne sont pas détectés, les bacs à sable ont tous les avantages de l’analyse dynamique, en particulier le contournement possible des méthodes d’obfuscation et une compréhension plus rapide des fonctionnalités. Le résultat des différentes étapes de l’exécution en bac à sable enfin peut être éventuellement l’objet d’une analyse statique (car issus d’un dépaquetage ou d’un téléchargement depuis un site distant comme module com-plémentaire). Les bacs à sable enfin peuvent constituer une méthode de détection de codes malveillants.
Certains auteurs [KVK11], [KVK14] proposent le développement de bacs à sable sur base de machines physiques. L’intérêt est de contourner une grande partie des méthodes de détection utilisées par les logiciels malveillants. Les difficultés principales résident dans la complexité de l’injection du code malveillant, de la collecte de certaines informations (instru-mentation) et la restauration rapide du système dans son état initial.
3.3.2 L’analyse statique
L’analyse statique est donc l’observation du code malveillant sans l’exécuter. Elle est généralement réalisée avec des outils de désassemblage et de décompilation, quand le code n’est pas directement accessible (pour les scripts malveillants). Elle peut être combinée avec les méthodes dynamiques permises par les outils de déboguage (qui autorisent une exécution pas à pas en parcourant le code).
L’analyse statique ne se limite pas à l’examen du code et de sa structure par un être humain, mais peut aussi être l’objet d’automatisations.
11. http://www.inetsim.org/
Ainsi, [IW12] présente une méthode de classification des échantillons de logiciels mal-veillants par analyse du graphe de flot de contrôle à la recherche des appels à des fonctions d’une interface de programmation (Application programming interface (API)). La première tape consiste à simplifier le graphe : identification des appels API, élimination des nœuds du graphe qui ne sont pas des appels API et fusion des appels vers les mêmes fonctions lorsqu’ils sont proches. Ensuite, il est possible de calculer une similarité entre ces graphes simplifiés. La méthode dévelopée est selon les auteurs peu résistante à l’utilisation de compilateurs dif-férents et les auteurs suggèrent que l’analyse statique ne peut pas répondre totalement aux objectifs (il y a des façons différentes de réaliser les appels aux fonctions des API).
Les auteurs de [LJL10] font une proposition qui a l’air plus aboutie. La technique employée est similaire, avec une construction de cette signature sémantique reposant sur la signification de l’appel à fonction : objet et comportement de l’appel (lecture sur disque dur, écriture sur disque dur, etc.) ; elle est stockée dans une matrice d’adjacence de dimension 128. Ils s’attachent ici en particulier, avec des calculs de similarités sur ces “graphes de code”, à la détection de codes malveillants obfusqués et obtiennent une détection de 100% pour trois techniques d’obfuscation (ils estiment qu’elle doit être améliorée pour pouvoir traiter certaines méthodes d’obfuscation telles que l’insertion d’appels API non signifiants ou redondants).
3.3.2.1 Aller plus loin dans l’analyse dynamique
[Cal13] soutient que l’analyse dynamique peut permettre de répondre à trois défis de l’ana-lyse de code malveillant : « code auto-modifiant, complexité du jeu d’instructrions et absence d’informations de haut niveau ». L’auteur présente l’étude a posteriori d’une exécution d’un programme informatique, grâce à l’exploitation d’un traceur, c’est-à-dire un outil permettant d’observer l’exécution d’un programme avec les possibilités suivantes : (1) connaissance de l’état de la machine, à la granularité temporelle de l’exécution, (2) la transparence de l’obser-vation et (3) la capacité d’enregistrer des informations (production d’une trace d’exécution). Ce traceur13 est ici réalisé avec Pin, framework d’instrumentation dynamique d’Intel.
Les résultats présentés démontrent que sur l’échantillon représentatif de logiciels mal-veillants analysé, les protecteurs mis en place par leurs développeurs sont avant tout des couches de protection autour de la charge utile. Les outils développés grâce au traceur et à l’identification des “boucles de flux de données” permettent la détection d’implémenta-tions d’algorithmes cryptographiques avec une efficacité supérieure aux outils classiquement utilisés.
Plates-formes de simulation. Dans le même esprit, la suite des travaux de [Cal13] ont
porté sur l’émulation du botnet Waledac pour tester la validité d’une méthode d’attaque pos-sible. Les possibilités de telles plates-formes sont particulièrement prometteuses pour la com-préhension des menaces mais aussi tester des hypothèses de mitigation : c’est, par exemple, ce que propose la plate-forme EPIC [SGH13] du centre de recherches de la Commission eu-ropéenne.
3.3.3 Détecter et contourner les méthodes d’obfuscation
On a vu au premier chapitre que l’obfuscation du code malveillant était un paramètre incontournable de leur développement aujourd’hui et ci-dessus, nous avons vu que des mé-thodes d’analyse dynamique [Cal13] permettent de les détecter et de mieux comprendre leur
structuration. De nombreux travaux proposent des méthodes de détection et de classification des empaqueteurs utilisés.
Des solutions de dépaquetage dynamique ont été proposées (Justin [GFC08], OmniUn-pack [MCJ07]) et parfois mises en difficulté [BLB11]. Enfin, la plupart des méthodes efficaces étant dynamiques, il est difficile d’envisager pour l’instant de les intégrer directement dans les solutions de protection anti-virus.