Analyse des logiciels malveillants

L'analyse des logiciels malveillants (« malware » en anglais) permet de déterminer leurs fonctionnements et leurs impacts potentiels. C'est une tâche essentielle dans la sécurité informatique, elle fournit la compréhension nécessaire pour concevoir des contre-mesures efficaces et des stratégies d'atténuation contre les différents logiciels malveillants.

Contexte

Les logiciels qui « remplissent délibérément les intentions nuisibles d'un attaquant » sont qualifiés de logiciels malveillants. Ils sont destinés à accéder aux systèmes informatiques et aux ressources réseau, perturber les opérations informatiques, et recueillir des informations personnelles sans le consentement du propriétaire du système créant ainsi une menace à la disponibilité de l'Internet, l'intégrité de ses hôtes et la vie privée de ses utilisateurs. Les logiciels malveillants regroupent plusieurs variantes comme le virus, le ver, le cheval de Troie, le rootkit, la backdoor, le botnet, les espiogiciels, l'adware, etc. Ces classes de logiciels nuisibles ne sont pas mutuellement exclusives, ce qui signifie qu'un maliciel particulier peut révéler les caractéristiques de plusieurs classes en même temps[1].

Les attaquants exploitent les vulnérabilités dans les services Web, les navigateurs et les systèmes d'exploitation, ou utilisent des techniques d'ingénierie sociale pour inciter les utilisateurs à exécuter le code malveillant afin de propager les logiciels malveillants. Les auteurs de logiciels malveillants utilisent des techniques d'obfuscation telles que l'insertion de code mort, la réaffectation de registre, le réordonnancement de sous-programme, la substitution d'instructions, la transposition de code et l'intégration de code pour échapper à la détection par les défenses traditionnelles telles que les pare-feux, les antivirus et les passerelles qui utilisent généralement des techniques basées sur les signatures et ne peuvent pas détecter les exécutables malveillants qui utilisent ces techniques. Les éditeurs d'antivirus commerciaux ne sont pas en mesure d'offrir une protection immédiate pour les logiciels de type zero-day, car ils doivent les analyser pour créer leurs signatures[2].

Pour surmonter la limitation des méthodes basées sur les signatures, des techniques d'analyse de logiciels nuisibles sont suivies, qui peuvent être statiques ou dynamiques. Les techniques d'analyse des logiciels malveillants aident les analystes à comprendre les risques et les intentions associés à un échantillon de code malveillant. Les informations ainsi obtenues peuvent être utilisées pour réagir aux nouvelles tendances dans le développement de logiciels malveillants ou pour prendre des mesures préventives afin de faire face aux menaces futures. Les fonctionnalités dérivées de l'analyse des logiciels malveillants peuvent être utilisées pour regrouper les logiciels malveillants inconnus et les classer dans leurs familles existantes[2].

Avant de créer les signatures pour les maliciels nouvellement arrivés, ceux-ci doivent être analysés afin de comprendre les risques et les intentions associés. Le programme malveillant et ses capacités peuvent être observés soit en examinant son code ou en l'exécutant dans un environnement sûr[2].

Analyse statique

L'analyse d'un programme malveillant sans l’exécuter se nomme l'analyse statique. Les modèles de détection utilisés en analyse statique sont la comparaison de signatures de chaine de caractères, séquence d'octets n-grams, appels syntaxique de bibliothèque, diagramme de flux de contrôle, fréquence de distribution des opcodes. L’exécutable malveillant doit être déchiffré ou décompressé pour procéder à une analyse statique[2].

Techniques

Décompilation

La décompilation offre une technique attractive pour aider l'analyse de malware en permettant celle-ci d'être effectuer à haut niveau afin d'avoir une forme plus abstraite du code binaire. La décompilation consiste à la collection de mécanismes de récupération abstraite afin de remonter des abstractions haut niveau qui ne sont pas lisibles dans le code binaire. Les analyses manuelles et automatiques peuvent être effectuées sur du code de programme décompilé afin de réduire le temps requis pour l'analyse. Vis-à-vis de cet objectif, la communauté scientifique a abordé des principes de méthodes pour la récupération d'abstraction de haut niveau nécessaire pour la reconstitution du code source. Cela inclut la récupération des types de données, le flux de contrôle de structure haut niveau tel que la construction de if-then-else et de boucle while par exemple depuis le code binaire. Malgré des avancées significatives, les états de l'art sur les décompilateurs créent un code vraiment complexe et ne se concentre pas sur la lisibilité. Cependant, certains décompilateurs existent afin d'améliorer la lecture du code décompilé et le rendre plus facile à comprendre. Ainsi, ils accélèrent la rétroconception de programme malveillant[3].

Signature numérique

La détection basée sur la signature numérique est la technique la plus largement utilisée par les anti-virus. Une signature est une séquence d'octets qui peut être utilisée pour identifier un logiciel malveillant spécifique. Les anti-virus basés sur la détection de signature doivent maintenir un dépôt de signatures de maliciels déjà connus et celui-ci doit être mis à jour fréquemment dès qu'une nouvelle menace est découverte[4]. Les deux algorithmes MD5 et SHA1 sont utilisés pour générer la signature de hachage d'un fichier exécutable (16 octets pour MD5 et 20 octets pour SHA1)[5].

La détection basée sur la signature est facile, plutôt rapide et efficace contre les types de malware ordinaire. L'inconvénient de cette méthode et qu'elle nécessite une mise-à-jour de la base de données des signatures et que si la signature d'un maliciel n'est pas présent dans celle-ci, le fichier ne sera pas détecté comme malveillant. De plus, une simple technique d'obfuscation peut être utilisée pour changer la signature d'un même malware et par conséquent, échapper à la détection de signature[4].

Chaînes de caractères

Les chaînes de caractères sont des propriétés facilement interprétables. Ces chaînes peuvent refléter l'intention et l'objectif de l'attaquant car elles contiennent souvent des informations sémantiques importantes d'un comportement malveillant. Par exemple la chaîne suivante :

<html><script language=‘javascript’>window.open(‘readme.eml’)

existe toujours dans le ver Nimda, montrant que le ver essaye d'infecter les scripts. Un autre exemple est la chaîne &gameid=%s&pass=%s;myparentthreadid=%d;myguid=%s qui indique les intentions de l'attaquant qui sont de dérober le mots de passe d'un jeux-vidéo en ligne et de les renvoyer au serveur. Par ailleurs, les chaînes de caractères sont des fonctionnalités robustes et il n'est pas facile pour le créateur du malware d'échapper à la détection par chaînes de caractères. La raison est que même si des variantes de logiciels malveillants peuvent être générées en recompilant ou en adoptant des techniques d'obfuscation, modifier toute la table d'interprétation des chaînes de caractères n'est pas pratique dans la majorité des programmes[6].

N-grammes

Les n-grammes sont toutes les sous-chaînes de caractère de longueur N dans le code du programme. Par exemple, la séquence "82EDD875" est segmentée en 5-grammes :

• 82EDD
• 2EDD8
• EDD87
• DD875

Au cours de la dernière décennie, de nombreuses recherches ont effectué une détection de logiciels malveillants inconnus basée sur le contenu du code binaire[6].

Opcodes

Un opcode (pour operational code) est une sous partie d'une instruction en langage machine qui identifie les opérations qui sont exécutées. Plus précisément, un programme est défini par une série d'instructions assembleur ordonnés. Une instruction est une paire composée d'un code opérationnel et d'une opérande ou d'une liste d'opérandes. Par exemple :

mov ebx ebx
add eax 1
xor eax eax
call sub_401BCD

Les segments d'instruction peuvent souvent montrer les fonctionnalités d'un programme. Des études ont montré qu'en pratique, les échantillons d'un logiciel malveillant dérivé du même code source, ou qui proviennent d'une même famille de logiciels malveillants partagent souvent un grand nombre de blocs ou segments d'instructions en commun[6].

Graphe de flot de contrôle

Les graphes de flot de contrôle représentent le flux d'exécution d'un programme. Ils sont beaucoup utilisés dans l'analyse de logiciel et ont été aussi énormément étudiés[6].

Outils

Des outils de désassemblage, debug et de capture de mémoire-vive peuvent être utilisés afin d'inverser et analyser la pile d’exécutables sous Windows. Les outils de désassemblage et de debug tel que IDA Pro et OllyDbg affiche le code du programme malveillant sous forme d'instructions assembleur x86 Intel, ce qui fournit des idées sur l'intention du malware et ce qu'il fait. De même que cela permet d'identifier l'attaque via les modèles utilisés par le malware. Les outils de capture de mémoire-vive comme LordPE et OllyDump sont utilisés afin d'obtenir du code protégé localisé dans la mémoire du système et l'enregistrer dans un fichier. C'est une technique particulièrement utile pour analyser des exécutables qui sont chiffrés par exemple car ils sont difficiles à désassembler[7].

Limites

Logiciel malveillant avancé

Un logiciel malveillant avancé contient une variété de mécanismes codés spécifiquement pour rendre sa détection et son décryptage difficile. Le tableau ci-dessous illustre trois approches pour échapper à l'analyse statique :

Type	Description
Chiffré	Dans cette approche, qui consiste à utiliser le chiffrement, un programme malveillant chiffré est généralement composé du déchiffreur et du corps principal du programme chiffré. Le déchiffreur récupère le corps principal du programme chaque fois que le fichier infecté est exécuté. Pour chaque infection, en utilisant une clé différente, le logiciel malveillant rend la partie chiffrée unique, cachant ainsi sa signature. Cependant, le principal problème de cette approche est que le déchiffreur reste constant de génération en génération. Cela permet aux scanners antivirus de détecter ce type de malware en fonction du modèle de code du déchiffreur[8].
Polymorphe	Le malware polymorphe parvient à créer un nombre incalculable de décrypteurs distincts à l'aide des méthodes d’offuscation, y compris l'insertion de code mort, la réaffectation de registre, et plus encore. Même si les malwares polymorphes peuvent efficacement contrecarrer la correspondance des signatures, leur corps constant qui apparaît après le déchiffrement peut être utilisé comme une source importante pour la détection[8].
Métamorphe	Le malware métamorphique a été proposé comme une nouvelle approche au malware polymorphe. Notez que ce malware utilise au mieux les techniques d’offuscation pour faire évoluer son corps vers de nouvelles générations, qui ont l'air différentes mais fonctionnent essentiellement de la même manière. Pour une telle évolution, il devrait être capable de reconnaître, d'analyser et de muter son propre corps chaque fois qu'il se propage. Il est important que le logiciel malveillant métamorphique ne révèle jamais son corps constant dans la mémoire en raison de ne pas utiliser le chiffrement. Cela rend ce type de malware difficile à détecter pour les scanners antivirus[9].

Offuscation

L'idée de base est que certaines instructions du code original sont remplacées par des fragments de programme qui sont sémantiquement équivalents mais plus difficiles à analyser, ou que des instructions supplémentaires sont ajoutées au programme et ne modifient pas son comportement[10]. À l'origine, cette technologie visait à protéger la propriété intellectuelle des développeurs de logiciels, mais elle a été largement utilisée par les auteurs de logiciels malveillants pour échapper à la détection. Pour éviter les scanners antivirus, les malwares, dans les nouvelles générations, évoluent leur corps grâce à la technique d'obfuscation[8].

Les techniques d’offuscation de binaire, qui transforment les binaires des logiciels malveillants en fichiers binaires auto-compressés et à structure unique, sont conçues pour résister à l'ingénierie inverse et rendent ainsi l'analyse statique très coûteuse et peu fiable. De plus, lorsqu'on utilise des exécutables binaires (obtenus en compilant du code source) pour l'analyse statique, les informations telles que, la taille des structures de données ou des variables, se perdent, compliquant ainsi l'analyse du code malveillant[11].

Le tableau ci-dessous présente les techniques d'obfuscation couramment utilisées dans les logiciels malveillants :

Technique	Description
Constante opaque	Les valeurs constantes sont omniprésentes dans le code binaire, que ce soit la cible d'une instruction de flux de contrôle, l'adresse d'une variable ou un opérande d'une instruction arithmétique. Dans sa forme la plus simple, une constante est chargée dans un registre. Une technique d'obfuscation importante est basée sur l'idée de remplacer cette opération de chargement par un ensemble d'instructions sémantiquement équivalentes difficiles à analyser statiquement[10]. Exemple : int zero[32] = { z_31, z_30, ... , z_0 }; int one[32] = { o_31, o_30, ... , o_0 }; int unknown = load_from_random_address(); int constant = 0; for (i = 0; i < 32; i++) { if (bit_at_position(unknown, i) == 0) constant = constant ^ zero[i]; else constant = constant ^ one[i]; } constant = constant | set_ones; constant = constant & set_zeros;
Émulation	L'émulation est une approche générale d’exécution d'un programme écrit pour une interface de matériel sous adjacente d'une autre. Un programme d’offuscation qui utilise l'émulation convertit un programme binaire pour une architecture d'ensemble d'instructions réelles, telle que x86, en un programme de bytecode écrit pour un ISA virtuel généré aléatoirement et associé à un émulateur qui émule ce programme[12].
Insertion de code mort	L'insertion de "code mort" est une technique qui consiste à ajouter des instructions inefficace voir sans effet au programme afin de changer son apparence sans aucune modification sur son comportement. Un exemple est l'ajout d'instructions NOP dans le code original d'un programme. Cependant, certains anti-virus peuvent contrepasser cette technique en supprimant les instructions inutiles durant l'analyse ce qui rend le programme détectable par signature[13].
Réaffections de registre	L'offuscation par réaffections des registres consiste à intervertir les registres utilisés par les instructions entre plusieurs générations du programme. Cela permet de garder le comportement identique en changeant à nouveau sa signature. Un exemple serait qu'un programme utilise les registres suivants dans cet ordre : EAX, EBX et EDX, l'ordre serait changé de la façon suivante : EBX, EDX et EAX[13].
Réorganisation des sous-programmes	La réorganisation du sous-programme obscurcit un code original en changeant l'ordre de ses sous-programmes de manière aléatoire. Cette technique peut générer n! différentes variantes, où n est le nombre de sous-programmes[13].
Remplacement d'instructions	La technique utilisant le remplacement d'instructions fait évolué le code original d'un programme en remplaçant certaines instructions par d'autres qui sont équivalentes pour le comportement. Par exemple, on pourrait remplacer un XOR par un SUB et un MOV par un PUSH/POP[14].
Transposition de code	La transposition de code réorganise les séquences d'instructions du code original sans affecter son comportement. Il existe pour cela deux méthodes qui permettent ce changement. La première consiste à mélanger les instructions de façon aléatoire et de retrouver l'ordre d’exécution original en y insérant des branches inconditionnel ou des instructions JUMP. Cependant, il n'est pas difficile de contrecarrer cette méthode car le programme original peut facilement être retrouvé. La seconde méthode consiste à générer un nouveau programme en choisissant et en réorganisant les instructions indépendantes qui n'ont pas d'impact sur les autres. Du fait que trouver les instructions indépendantes créer un problème complexe, cette méthode est difficile à implémenter mais peut rendre aussi la détection compliquée[14].
Intégration de code	L'intégration de code a été introduite par le malware Zmist sur Win95. La technique consiste à prendre un programme sain comme cible et d'intégrer le code du malware dans celui-ci. Zmist commence par décompiler le programme ciblé en objets gérables et ajoute parfaitement son propre code entre eux puis réassemble le code en une nouvelle génération du programme. C'est une des méthodes les plus sophistiqué dans l'offuscation ce qui rend la détection difficile[14].

Bien qu'il soit concevable d'améliorer l'analyse statique pour traiter des techniques d'obfuscation plus avancées, il y a une limite fondamentale à ce qui peut être décidé statiquement[15]. L'évolution des techniques d'évasion utilisées par les auteurs de logiciels malveillants pour contrecarrer l'analyse statique a conduit au développement de l'analyse dynamique[11] car la plupart des transformations d'obfuscation deviennent inefficaces une fois le code exécuté[16].

Analyse dynamique

Analyser le comportement d'un code malveillant (les interactions avec le système) pendant qu'il est exécuté dans un environnement contrôlé (machine virtuelle, simulateur, émulateur, sandbox, etc) est appelé analyse dynamique[11].

L'analyse dynamique est plus efficace comparée à l'analyse statique et ne requiert pas la rétro-conception du programme. Cette analyse dévoile le comportement naturel du malware qui résisterait mieux à l'analyse statique. Cependant, cela coûte beaucoup de temps et de ressources ce qui soulève des problèmes d'évolutivité. L'environnement virtuel, dans lequel le malware est exécuté, est différent d'un environnement réel et le malware peut adopter un comportement artificiel plutôt que son comportement naturel. De plus, il arrive que le comportement du malware ne soit déclenché que dans certaines conditions (à une date système spécifique ou via une commande spécifique) et ne puisse pas être détecté dans un environnement virtuel[11].

Techniques

Plusieurs techniques peuvent être appliquées pour réaliser une analyse dynamique comprenant la surveillance des appels de fonctions, l'analyse des paramètres de fonction, le suivi de flux d'information, les traces d'instructions, etc[11].

Le tableau ci-dessous donne un aperçu des différentes techniques qui peuvent être utilisées :

Technique	Description
Activité du registre	Les activités du registre incluent l'ajout, la modification ou la suppression des fichiers de registre par certains processus[5].
Trafic réseau	Le trafic réseau donne des informations à propos de la source et la destination ainsi que sur des détails des paquets de données[5].
Emplacement de démarrage automatique	Certains exécutables s'installent dans divers endroits tels que le registre, le dossier de démarrage, etc.[5]
Appels d'API système	En général, les applications et les services invoquent l'API (pour Application Programmable Interface) pour l'exécution. L'appel d'API fournit des informations sur l'ID de thread, le nom de la DLL effectuée par les appels d'API et fournit également des détails sur le nom du paramètre qui passe, des valeurs de retour[5].
Image mémoire	L'adresse mémoire donne des détails sur l'adresse d'instruction, l'adresse de processus, etc., de la mémoire principale, qui permet de détecter un comportement malveillant[5].

Environnement d'exécution

Analyse dans l'espace utilisateur / noyau

Analyser le programme malveillant dans l'espace utilisateur permet une approche d'analyse qui collecte des données, par exemple les invocations d'appels de fonctions ou les appels d'API. Une telle approche peut avoir facilement accès à toutes les structures de mémoire et aux informations de haut niveau fournies par le système d'exploitation. La possibilité de cacher des informations à l'analyse dans l'espace utilisateur est vraiment limitée. Par exemple, cacher un processus ou le chargement d'une bibliothèque aux autres processus tournants sur la machine n'est généralement pas possible depuis l'espace utilisateur. Cette limitation n'est pas aussi restrictive quand l'analyse d'un composant est sur l'espace noyau. Les outils d'analyse accédant aux fonctions au niveau du noyau peuvent collecter diverses informations, comme les invocations d'appels système et peuvent cacher leurs présences au logiciel malveillant qui s'exécute seulement dans l'espace utilisateur[17].

Analyse dans un émulateur

Exécuter un programme à l'intérieur d'un environnement émulé permet à un composant d'analyse de contrôler chaque aspect de l’exécution du programme. Selon la partie de l'environnement d'exécution émulé, plusieurs formes d'analyse sont disponibles. Émuler le processeur et la mémoire dans une sandbox permet d'exécuter du code potentiellement malveillant sans craindre des effets néfastes sur le vrai système. Un binaire est exécuté dans une sandbox en lisant de façon successive les instructions et en réalisant les opérations équivalentes dans l'environnement virtuel émulé. Tous les effets secondaires fait par l'exécutable sont contenus dans la sandbox. Beaucoup d'anti-virus emploient l'émulation de processeur et de mémoire pour surmonter les difficultés imposées par les exécutables offusqués ou chiffrés. Pour analyser un potentiel binaire chiffré, il est exécuté dans un environnement émulé et si l'anti-virus détecte une séquence non chiffrée, les signatures sont appariées sur le contenu de la mémoire non chiffrée contenue dans la mémoire émulée[17].

Analyse dans une machine virtuelle

Une machine virtuelle (VM) est une duplication efficace et isolée d'une vraie machine. Le moniteur de machine virtuelle (VMM) est responsable de la gestion de cette copie aux programmes et est responsable du matériel sous-jacent. En pratique, cela signifie qu'aucune machine virtuelle ne peut accéder aux matériels avant que la VMM le lui assigne. Un composant d'analyse implémenté dans la VMM a l'avantage d'être invisible par les programmes analysée. Généralement, un tel composant d'analyse est soit directement intégré à la VMM ou dans sa propre machine virtuelle[18].

Outils

Avant d'exécuter un échantillon de malware, les outils appropriés à la surveillance sont[11] :

• Process Monitor (pour le système de fichier et la surveillance du registre)
• Process Explorer (pour la surveillance des processus)
• Wireshark (pour la surveillance réseau)
• Regshot (pour la détection de changement dans le système).

Plusieurs outils automatique pour l'analyse dynamique existent en ligne, par exemple :

• Norman Sandbox
• CWSandbox
• Anubis
• Ether
• ThreatExpert

Les rapports d'analyse générés par ces programmes donnent en profondeur une compréhension sur le comportement du malware et des éclaircissements sur les actions faites par celui-ci. L'analyse système doit avoir une représentation appropriée des malwares, qui sont par la suite utilisés pour la classification selon leur similitude ou leurs fonctionnalités semblables[11].

Contre-mesures

L’offuscation d’exécutable n'est pas une solution efficace contre une analyse dynamique car celle-ci ne se base pas sur la signature du binaire ou les instructions produitent par celui-ci mais elle se focalise sur son comportement et il reste le même avec ou sans offuscation.

Une des contre-mesures existantes pour l'analyse dans un émulateur est la suivante : Pour un échantillon malveillant qui veut détecté qu'il est exécuté dans un environnement émulé, il doit réaliser une opération sur un composant qui n'existe pas ou n'est pas suffisamment simulé dans le système. Par exemple, l'émulateur peut avoir un comportements différent d'un vrai processeur dans le cas d'une faille connu sur les CPU (si le bug n'est pas pris en considération par l'émulation)[17].

Des instances de malware essayent de détecter la plateforme d'analyse dans laquelle ils se trouvent, le cas échéant, le malware s'arrête simplement ou va exécuter un comportement non suspect pour tromper l'analyse[19].

Dysfonctionnement de la machine virtuelle

Faire dysfonctionner la machine virtuelle est un moyen facile de s'échapper de l’analyse. Par exemple, certains bugs étaient présents dans l'émulateur QEMU et l'un de ces bug était "QEMU NE2000 MTU heap overflow". Exploiter ce bug rendait la machine virtuelle instable et dysfonctionner jusqu'à l'arrêt anormal de celle-ci[20].

Attaque sur le temps

L'attaque sur le temps vise pour le logiciel malveillant à différencier s'il se trouve sur une machine virtuelle ou non. En effet, les performances des applications sont différentes d'un vrai système à un virtuel. Généralement, les performances d'une machine virtuelle sont plus lente qu'une machine réelle. Quelques techniques Anti-VM consistent à exploiter ces attaques sur le temps.

Ces attaques mesurent le temps d'exécution des instructions pour identifier si l'environnement où ils se trouvent correspond à une machine virtuelle. Un autre type d'attaque vise le cache d'une machine virtuelle. En effet, sur une vraie machine, une même instruction aura un temps d'exécution selon que le cache est activé ou non, sans cache, les performances seront plus mauvaises. Sur une machine virtuelle, le temps d'exécution sera le même avec ou sans cache. Par conséquent, l'utilisation de ces attaques peuvent servir à dévoiler l'environnement sur lequel le logiciel malveillant se trouve[20].

Empreinte d'un périphérique virtuel

Les empreintes d'une machine peuvent être utilisées comme moyen Anti-VM pour identifier l'environnement virtuel sur lequel le malware se trouve. En effet, les machines virtuelles créent des périphériques matériel avec des identifiants spécifiques qui peuvent être utilisés afin d'identifier la machine virtuelle[20] (par exemple, VMware utilise les tags "Logic BT-958" et "pcnet32" pour le périphérique VGA et la carte réseau).

Exploitation d'un bug sur la machine virtuelle

Certaines machines virtuelles possèdent des bugs connus qui peuvent être utilisés pour vérifier l'environnement. L'entreprise VMware avait annoncé que leurs produits avaient un bug qui permettait de sortir de la machine virtuelle. SI un attaquant peut accéder aux fichiers de la machine hôte depuis la machine virtuelle, cela donne l'opportunité de contrôler et d'infecter la vraie machine[20].

Lutte Anti-VM

Les malware Anti-VM vont avoir un comportement différent selon l'environnement s'il est réel ou virtuel. Certaines solutions utilisent un algorithme appelé algorithme de distance de comportement (behavior distance algorithm) afin de distinguer si un malware est Anti-VM ou non. Cet algorithme compare la distance de comportement en estimant la variation du comportement des logiciels malveillants Anti-VM à partir d'environnements réels et virtuels. Pour cela, il utilise des séquences d'appel système et mesure la distance comportementale entre deux processus. Cette approche est capable de détecter des attaques de mimétisme avec de faibles faux positifs. Un moniteur de processus est aussi utilisé afin de collecter ces évènements[21].

Analyse hybride

Les approches d'extraction d’analyse statiques et dynamiques ont leurs propres avantages et limites. Comparée à l'analyse dynamique, l'approche statique est moins coûteuse et peut couvrir tous les chemins de code (y compris les morceaux de programme qui ne sont pas toujours exécutés), fournissant ainsi une caractérisation plus précise et complète des fonctionnalités du programme.

Cependant, cela coute de haute performance en raison de techniques de mutation de bas niveau (comme l'offuscation ou le chiffrement). Au contraire, l'analyse dynamique résiste à l'obfuscation de bas niveau et convient à la détection de variantes de logiciels malveillants et de nouvelles familles, mais exécute souvent mal sur les échantillons de logiciels malveillants basés sir des déclencheurs. En outre, l'analyse dynamique est coûteuse et non évolutive en raison de sa couverture limitée.

Selon les statistiques de Comodo Cloud Security Center, environ 80 % des échantillons de fichiers peuvent être bien représentés à l'aide d'une analyse statiques alors que seulement environ 40 % des échantillons de fichiers peuvent s'exécuter avec une analyse dynamique. En raison de leurs avantages et inconvénients respectifs, aucune approche statiques ou dynamiques ne peut fournir une solution parfaite à l'extraction de caractéristiques dans l'analyse de logiciels malveillants. Par conséquent, une approche globale intégrant à la fois l'analyse statique et dynamique et bénéficiant des avantages des deux serait souhaitable. L'analyse hybride est une approche qui combine les avantages respectifs de l'analyse statique et de l'analyse dynamique. Par exemple, le logiciel malveillant chiffré peut d'abord passer par un analyseur dynamique tel que PolyUnpack, où les parties de code masqué d'une instance de logiciel malveillant chiffré sont extraits en comparant l'exécution du programme malveillant avec son modèle de code statique. Une fois que les morceaux de code caché sont découverts, un analyseur statique peut continuer l'analyse du logiciel malveillant[22].

Approche forensique

Les étapes de l'approche forensique dans l'analyse de logiciels malveillants.

Cette approche intègre à la fois l'analyse statique et les approches forensiques de la mémoire et propose des améliorations, qui fournit de meilleurs résultats. La raison en est la résistance de certains échantillons de logiciels malveillants à révéler leur comportement prévu en raison du cryptage et de leur nature compacte. Par conséquent, l'approche de l'analyse des logiciels malveillants statiques et les approches forensiques peuvent être combinés pour surmonter les problèmes de comportement et de chiffrement. L'outil Volatility est utilisé dans cette méthode[23].

L'analyse forensique se fait en quatre étapes :

1. Préparation d'un environnement virtuel
2. Analyse statique sur un logiciel malveillant
3. Génération d'un dump mémoire
4. Analyse de la mémoire

Par la suite, les résultats sont comparés et vérifiés avec les résultats obtenus sur l'outil en ligne de VirusTotal, qui est un outil d'analyse de malwares en ligne.

Classification

Apprentissage automatique

Diverses approches d'apprentissage automatique ont été proposées, pour détecter et classer des échantillons inconnus dans des familles de logiciels malveillants connus ou pour les analyser, telles que[11] :

• Les règles d'association
• Les machines à vecteurs de support
• Les arbres de décision
• Les forêts aléatoires
• La classification naïve bayésienne
• Le partitionnement de données

De nombreux chercheurs préfèrent maintenant travailler sur des techniques dynamiques afin d'améliorer la précision et l'efficacité de la classification des logiciels malveillants[24].

Analyse phylogénétique

L'analyse phylogénétique est l'étude des similitudes et des différences dans la structure du programme pour trouver des relations au sein de groupes de logiciels, fournissant des informations sur les nouvelles variantes de logiciels malveillants non disponibles à partir de la détection de logiciels malveillants basés sur les signatures. Un exemple de solution utilisant cette analyse est la solution DECODE.

Les principales technologies de DECODE :

• Création d'une empreinte digitale d'un spécimen de logiciel malveillant à l'aide d'une analyse statique.
• Un système de classification évolutif et précis pour regrouper des centaines de milliers d'échantillons de logiciels malveillants dans une taxonomie de logiciels malveillants.
• Un système de classification évolutif et précis pour trouver le code partagé, au niveau des sous-programmes individuels, sur des dizaines de milliers d'échantillons
• Plusieurs algorithmes pour reconstruire des lignées d'échantillons de logiciels malveillants connexes[25]

Références

1. Gandotra 2014, p. 56
2. Gandotra 2014, p. 57
3. Yakdan 2016, p. 158
4. Damodaran 2017, p. 2
5. Deka 2016, p. 3
6. Ye 2017, p. 12
7. Gandotra 2014, p. 57-58
8. You 2010, p. 297
9. You 2010, p. 297-298
10. Moser 2007, p. 422
11. Gandotra 2014, p. 58
12. Sharif 2009, p. 94
13. You 2010, p. 298
14. You 2010, p. 299
15. Moser 2007, p. 430
16. Moser 2007, p. 429
17. Egele 2008, p. 13
18. Egele 2008, p. 14-15
19. Egele 2008, p. 18
20. Sun 2011, p. 912-913
21. Sun 2011, p. 913
22. Ye 2017, p. 14
23. Rathnayaka 2017, p. 1146
24. Gandotra 2014, p. 59-60
25. Jilcott 2015, p. 1

Annexes

Bibliographie

• (en) Ekta Gandotra, Divya Bansal et Sanjeev Sofat, « Malware Analysis and Classification: A Survey », Journal of Information Security, vol. 2014,‎ 20 février 2014 (ISSN 2153-1242, DOI 10.4236/jis.2014.52006, lire en ligne, consulté le 7 janvier 2018)
• (en) Manuel Egele, Theodoor Scholte, Engin Kirda et Christopher Kruegel, « A Survey on Automated Dynamic Malware-analysis Techniques and Tools », ACM Comput. Surv., vol. 44, n^o 2,‎ mars 2008, p. 6:1–6:42 (ISSN 0360-0300, DOI 10.1145/2089125.2089126, lire en ligne, consulté le 7 janvier 2018)
• (en) A. Moser, C. Kruegel et E. Kirda, « Limits of Static Analysis for Malware Detection », Twenty-Third Annual Computer Security Applications Conference (ACSAC 2007),‎ décembre 2007, p. 421–430 (DOI 10.1109/acsac.2007.21, lire en ligne, consulté le 7 janvier 2018)
• (en) Anusha Damodaran, Fabio Di Troia, Corrado Aaron Visaggio et Thomas H. Austin, « A comparison of static, dynamic, and hybrid analysis for malware detection », Journal of Computer Virology and Hacking Techniques, vol. 13, n^o 1,‎ 1^er février 2017, p. 1–12 (ISSN 2263-8733, DOI 10.1007/s11416-015-0261-z, lire en ligne, consulté le 7 janvier 2018)
• (en) Grégoire Jacob, Hervé Debar et Eric Filiol, « Behavioral detection of malware: from a survey towards an established taxonomy », Journal in Computer Virology, vol. 4, n^o 3,‎ 1^er août 2008, p. 251–266 (ISSN 1772-9890 et 1772-9904, DOI 10.1007/s11416-008-0086-0, lire en ligne, consulté le 7 janvier 2018)
• (en) M. Sharif, A. Lanzi, J. Giffin et W. Lee, « Automatic Reverse Engineering of Malware Emulators », 2009 30th IEEE Symposium on Security and Privacy,‎ mai 2009, p. 94–109 (DOI 10.1109/sp.2009.27, lire en ligne, consulté le 7 novembre 2017)
• (en) K. Yakdan, S. Dechand, E. Gerhards-Padilla et M. Smith, « Helping Johnny to Analyze Malware: A Usability-Optimized Decompiler and Malware Analysis User Study », 2016 IEEE Symposium on Security and Privacy (SP),‎ mai 2016, p. 158–177 (DOI 10.1109/sp.2016.18, lire en ligne, consulté le 7 novembre 2017)
• (en) Yanfang Ye, Tao Li, Donald Adjeroh et S. Sitharama Iyengar, « A Survey on Malware Detection Using Data Mining Techniques », ACM Comput. Surv., vol. 50, n^o 3,‎ juin 2017, p. 41:1–41:40 (ISSN 0360-0300, DOI 10.1145/3073559, lire en ligne, consulté le 10 janvier 2018)
• (en) M. K. Sun, M. J. Lin, M. Chang et C. S. Laih, « Malware Virtualization-Resistant Behavior Detection », 2011 IEEE 17th International Conference on Parallel and Distributed Systems,‎ décembre 2011, p. 912–917 (DOI 10.1109/icpads.2011.78, lire en ligne, consulté le 7 novembre 2017)
• (en) Rakesh Singh Kunwar et Priyanka Sharma, « Malware Analysis: Tools and Techniques », Proceedings of the Second International Conference on Information and Communication Technology for Competitive Strategies, ACM, iCTCS '16,‎ 2016, p. 144:1–144:4 (ISBN 9781450339629, DOI 10.1145/2905055.2905361, lire en ligne, consulté le 10 janvier 2018)
• (en) Xu Chen, J. Andersen, Z. M. Mao et M. Bailey, « Towards an understanding of anti-virtualization and anti-debugging behavior in modern malware », 2008 IEEE International Conference on Dependable Systems and Networks With FTCS and DCC (DSN),‎ juin 2008, p. 177–186 (DOI 10.1109/dsn.2008.4630086, lire en ligne, consulté le 7 novembre 2017)
• (en) Daniel A Quist et Lorie M Liebrock, « Reversing Compiled Executables for Malware Analysis via Visualization », Information Visualization, vol. 10, n^o 2,‎ 13 janvier 2011, p. 117–126 (DOI 10.1057/ivs.2010.11, lire en ligne, consulté le 7 novembre 2017)
• (en) Chan Lee Yee, Lee Ling Chuan, M. Ismail et N. Zainal, « A static and dynamic visual debugger for malware analysis », 2012 18th Asia-Pacific Conference on Communications (APCC),‎ octobre 2012, p. 765–769 (DOI 10.1109/apcc.2012.6388211, lire en ligne, consulté le 7 novembre 2017)
• (en) S. Jilcott, « Scalable malware forensics using phylogenetic analysis », 2015 IEEE International Symposium on Technologies for Homeland Security (HST),‎ avril 2015, p. 1–6 (DOI 10.1109/ths.2015.7225311, lire en ligne, consulté le 7 novembre 2017)
• (en) I. You et K. Yim, « Malware Obfuscation Techniques: A Brief Survey », 2010 International Conference on Broadband, Wireless Computing, Communication and Applications,‎ novembre 2010, p. 297–300 (DOI 10.1109/bwcca.2010.85, lire en ligne, consulté le 7 novembre 2017)
• (en) C. Rathnayaka et A. Jamdagni, « An Efficient Approach for Advanced Malware Analysis Using Memory Forensic Technique », 2017 IEEE Trustcom/BigDataSE/ICESS,‎ août 2017, p. 1145–1150 (DOI 10.1109/trustcom/bigdatase/icess.2017.365, lire en ligne, consulté le 21 novembre 2017)
• (en) D. Deka, N. Sarma et N. J. Panicker, « Malware detection vectors and analysis techniques: A brief survey », 2016 International Conference on Accessibility to Digital World (ICADW),‎ décembre 2016, p. 81–85 (DOI 10.1109/icadw.2016.7942517, lire en ligne, consulté le 10 janvier 2018)
• (en) Ioan Cristian Iacob, « Reverse Engineering Malicious Applications », Journal of Mobile, Embedded and Distributed Systems, vol. VII, no. 2, 2015,‎ 2015, p. 65-86 (lire en ligne)
• (en) Min Gyung Kang, Pongsin Poosankam et Heng Yin, « Renovo: A Hidden Code Extractor for Packed Executables », Proceedings of the 2007 ACM Workshop on Recurring Malcode, ACM, wORM '07,‎ 2007, p. 46–53 (ISBN 9781595938862, DOI 10.1145/1314389.1314399, lire en ligne, consulté le 7 novembre 2017)
• (en) Thomas Rupprecht, Xi Chen, David H. White et Jan Tobias Mühlberg, « POSTER: Identifying Dynamic Data Structures in Malware », Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, ACM, cCS '16,‎ 2016, p. 1772–1774 (ISBN 9781450341394, DOI 10.1145/2976749.2989041, lire en ligne, consulté le 7 novembre 2017)
• (en) W. M. Khoo et P. Lio, « Unity in Diversity: Phylogenetic-inspired Techniques for Reverse Engineering and Detection of Malware Families », 2011 First SysSec Workshop,‎ juillet 2011, p. 3–10 (DOI 10.1109/syssec.2011.24, lire en ligne, consulté le 7 novembre 2017)
• (en) Chih-Hung Lin, Hsing-Kuo Pao et Jian-Wei Liao, « Efficient dynamic malware analysis using virtual time control mechanics », Computers & Security, vol. 73,‎ mars 2018, p. 359–373 (DOI 10.1016/j.cose.2017.11.010, lire en ligne, consulté le 7 janvier 2018)
• (en) Shabnam Aboughadareh, Christoph Csallner et Mehdi Azarmi, « Mixed-Mode Malware and Its Analysis », Proceedings of the 4th Program Protection and Reverse Engineering Workshop, ACM, pPREW-4,‎ 2014, p. 1:1–1:12 (ISBN 9781605586373, DOI 10.1145/2689702.2689703, lire en ligne, consulté le 7 novembre 2017)
• (en) F. Daryabar, A. Dehghantanha et N. I. Udzir, « Investigation of bypassing malware defences and malware detections », 2011 7th International Conference on Information Assurance and Security (IAS),‎ décembre 2011, p. 173–178 (DOI 10.1109/isias.2011.6122815, lire en ligne, consulté le 7 novembre 2017)
• (en) Zachary D Sisco, Patrick P Dudenhofer et Adam R Bryant, « Modeling information flow for an autonomous agent to support reverse engineering work », The Journal of Defense Modeling and Simulation: Applications, Methodology, Technology, vol. 14, n^o 3,‎ 11 octobre 2016, p. 245–256 (DOI 10.1177/1548512916670784, lire en ligne, consulté le 7 novembre 2017)
• (en) Cory Q. Nguyen et James E. Goldman, « Malware Analysis Reverse Engineering (MARE) Methodology & Malware Defense (M.D.) Timeline », 2010 Information Security Curriculum Development Conference, ACM, infoSecCD '10,‎ 2010, p. 8–14 (ISBN 9781450302029, DOI 10.1145/1940941.1940944, lire en ligne, consulté le 7 novembre 2017)
• (en) M. Alazab, M. A. Kadiri, S. Venkatraman et A. Al-Nemrat, « Malicious Code Detection Using Penalized Splines on OPcode Frequency », 2012 Third Cybercrime and Trustworthy Computing Workshop,‎ octobre 2012, p. 38–47 (DOI 10.1109/ctc.2012.15, lire en ligne, consulté le 7 novembre 2017)
• (en) M. H. Alaeiyan et S. Parsa, « Automatic loop detection in the sequence of system calls », 2015 2nd International Conference on Knowledge-Based Engineering and Innovation (KBEI),‎ novembre 2015, p. 720–723 (DOI 10.1109/kbei.2015.7436133, lire en ligne, consulté le 7 novembre 2017)
• (en) R. A. Nolan et P. P. Chen, « MCARTA: A Malicious Code Automated Run-Time Analysis framework », 2012 IEEE Conference on Technologies for Homeland Security (HST),‎ novembre 2012, p. 13–17 (DOI 10.1109/ths.2012.6459819, lire en ligne, consulté le 7 novembre 2017)
• (en) M. Bombardieri, S. Castanò, F. Curcio et A. Furfaro, « Honeypot-Powered Malware Reverse Engineering », 2016 IEEE International Conference on Cloud Engineering Workshop (IC2EW),‎ avril 2016, p. 65–69 (DOI 10.1109/ic2ew.2016.16, lire en ligne, consulté le 7 novembre 2017)
• (en) M. Shudrak et V. Zolotarev, « The New Technique of Decompilation and Its Application in Information Security », 2012 Sixth UKSim/AMSS European Symposium on Computer Modeling and Simulation,‎ novembre 2012, p. 115–120 (DOI 10.1109/ems.2012.20, lire en ligne, consulté le 7 novembre 2017)
• (en) Guillaume Bonfante, Jose Fernandez, Jean-Yves Marion et Benjamin Rouxel, « CoDisasm: Medium Scale Concatic Disassembly of Self-Modifying Binaries with Overlapping Instructions », Proceedings of the 22Nd ACM SIGSAC Conference on Computer and Communications Security, ACM, cCS '15,‎ 2015, p. 745–756 (ISBN 9781450338325, DOI 10.1145/2810103.2813627, lire en ligne, consulté le 7 novembre 2017)
• (en) Min Gyung Kang, Heng Yin, Steve Hanna et Stephen McCamant, « Emulating Emulation-resistant Malware », Proceedings of the 1st ACM Workshop on Virtual Machine Security, ACM, vMSec '09,‎ 2009, p. 11–22 (ISBN 9781605587806, DOI 10.1145/1655148.1655151, lire en ligne, consulté le 7 novembre 2017)
• (en) Blake Anderson, Curtis Storlie, Micah Yates et Aaron McPhall, « Automating Reverse Engineering with Machine Learning Techniques », Proceedings of the 2014 Workshop on Artificial Intelligent and Security Workshop, ACM, aISec '14,‎ 2014, p. 103–112 (ISBN 9781450331531, DOI 10.1145/2666652.2666665, lire en ligne, consulté le 7 novembre 2017)
• (en) S. Burji, K. J. Liszka et C. C. Chan, « Malware analysis using reverse engineering and data mining tools », 2010 International Conference on System Science and Engineering,‎ juillet 2010, p. 619–624 (DOI 10.1109/icsse.2010.5551719, lire en ligne, consulté le 7 novembre 2017)
• (en) Gérard Wagener, Radu State et Alexandre Dulaunoy, « Malware behaviour analysis », Journal in Computer Virology, vol. 4, n^o 4,‎ 1^er novembre 2008, p. 279–287 (ISSN 1772-9890 et 1772-9904, DOI 10.1007/s11416-007-0074-9, lire en ligne, consulté le 7 novembre 2017)
• (en) Guillaume Bonfante, Jean-Yves Marion, Fabrice Sabatier et Aurélien Thierry, « Code synchronization by morphological analysis », 7th International Conference on Malicious and Unwanted Software (Malware 2012),‎ 2012, p. 1-9 (lire en ligne)
• (en) Murray Brand, Craig Valli et Andrew Woodward, « Malware Forensics: Discovery of the Intent of Deception », Journal of Digital Forensics, Security and Law, Vol. 5(4),‎ 2010, p. 1-12 (ISSN 1558-7223, lire en ligne)
• (en) X. Li, P. K. K. Loh et F. Tan, « Mechanisms of Polymorphic and Metamorphic Viruses », 2011 European Intelligence and Security Informatics Conference,‎ septembre 2011, p. 149–154 (DOI 10.1109/eisic.2011.77, lire en ligne, consulté le 21 novembre 2017)
• (en) Matthieu Kaczmarek, « Malware Instrumentation Application to Regin Analysis », The Journal on Cybercrime & Digital Investigations, vol. 1, n^o 1,‎ décembre 2015 (ISSN 2494-2715, DOI 10.18464/cybin.v1i1.2, lire en ligne, consulté le 7 novembre 2017)
• (en) A. Jadhav, D. Vidyarthi et Hemavathy M, « Evolution of evasive malwares: A survey », 2016 International Conference on Computational Techniques in Information and Communication Technologies (ICCTICT),‎ mars 2016, p. 641–646 (DOI 10.1109/icctict.2016.7514657, lire en ligne, consulté le 10 janvier 2018)
• (en) Y. Gao, Z. Lu et Y. Luo, « Survey on malware anti-analysis », Fifth International Conference on Intelligent Control and Information Processing,‎ août 2014, p. 270–275 (DOI 10.1109/icicip.2014.7010353, lire en ligne, consulté le 10 janvier 2018)

Articles connexes

• Logiciel malveillant
• Virus informatique
• Détection de logiciels malveillants sur Android

Liens externes

• (en) « How to Accidentally Stop a Global Cyber Attacks », sur malwaretech.com