Aller au contenu

Analyse des logiciels malveillants

Un article de Wikipédia, l'encyclopédie libre.

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.

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

[modifier | modifier le code]

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].

Décompilation

[modifier | modifier le code]

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

[modifier | modifier le code]

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

[modifier | modifier le code]

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].

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].

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

[modifier | modifier le code]

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].

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].

Logiciel malveillant avancé

[modifier | modifier le code]

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

[modifier | modifier le code]

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

[modifier | modifier le code]

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].

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

[modifier | modifier le code]

Analyse dans l'espace utilisateur / noyau

[modifier | modifier le code]

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

[modifier | modifier le code]

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

[modifier | modifier le code]

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].

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

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

[modifier | modifier le code]

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

[modifier | modifier le code]

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

[modifier | modifier le code]

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

[modifier | modifier le code]

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

[modifier | modifier le code]

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

[modifier | modifier le code]

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

[modifier | modifier le code]

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

[modifier | modifier le code]
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

[modifier | modifier le code]

Apprentissage automatique

[modifier | modifier le code]

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] :

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

[modifier | modifier le code]

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

[modifier | modifier le code]
  1. Gandotra 2014, p. 56
  2. a b c et d Gandotra 2014, p. 57
  3. Yakdan 2016, p. 158
  4. a et b Damodaran 2017, p. 2
  5. a b c d e et f Deka 2016, p. 3
  6. a b c et d Ye 2017, p. 12
  7. Gandotra 2014, p. 57-58
  8. a b et c You 2010, p. 297
  9. You 2010, p. 297-298
  10. a et b Moser 2007, p. 422
  11. a b c d e f g et h Gandotra 2014, p. 58
  12. Sharif 2009, p. 94
  13. a b et c You 2010, p. 298
  14. a b et c You 2010, p. 299
  15. Moser 2007, p. 430
  16. Moser 2007, p. 429
  17. a b et c Egele 2008, p. 13
  18. Egele 2008, p. 14-15
  19. Egele 2008, p. 18
  20. a b c et d 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

Bibliographie

[modifier | modifier le code]
  • (en) Ekta Gandotra, Divya Bansal et Sanjeev Sofat, « Malware Analysis and Classification: A Survey », Journal of Information Security, vol. 2014,‎ (ISSN 2153-1242, DOI 10.4236/jis.2014.52006, lire en ligne, consulté le ) Document utilisé pour la rédaction de l’article
  • (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, no 2,‎ , p. 6:1–6:42 (ISSN 0360-0300, DOI 10.1145/2089125.2089126, lire en ligne, consulté le ) Document utilisé pour la rédaction de l’article
  • (en) A. Moser, C. Kruegel et E. Kirda, « Limits of Static Analysis for Malware Detection », Twenty-Third Annual Computer Security Applications Conference (ACSAC 2007),‎ , p. 421–430 (DOI 10.1109/acsac.2007.21, lire en ligne, consulté le ) Document utilisé pour la rédaction de l’article
  • (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, no 1,‎ , p. 1–12 (ISSN 2263-8733, DOI 10.1007/s11416-015-0261-z, lire en ligne, consulté le ) Document utilisé pour la rédaction de l’article
  • (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, no 3,‎ , p. 251–266 (ISSN 1772-9890 et 1772-9904, DOI 10.1007/s11416-008-0086-0, lire en ligne, consulté le )
  • (en) M. Sharif, A. Lanzi, J. Giffin et W. Lee, « Automatic Reverse Engineering of Malware Emulators », 2009 30th IEEE Symposium on Security and Privacy,‎ , p. 94–109 (DOI 10.1109/sp.2009.27, lire en ligne, consulté le ) Document utilisé pour la rédaction de l’article
  • (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),‎ , p. 158–177 (DOI 10.1109/sp.2016.18, lire en ligne, consulté le ) Document utilisé pour la rédaction de l’article
  • (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, no 3,‎ , p. 41:1–41:40 (ISSN 0360-0300, DOI 10.1145/3073559, lire en ligne, consulté le ) Document utilisé pour la rédaction de l’article
  • (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,‎ , p. 912–917 (DOI 10.1109/icpads.2011.78, lire en ligne, consulté le ) Document utilisé pour la rédaction de l’article
  • (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,‎ , p. 144:1–144:4 (ISBN 9781450339629, DOI 10.1145/2905055.2905361, lire en ligne, consulté le )
  • (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),‎ , p. 177–186 (DOI 10.1109/dsn.2008.4630086, lire en ligne, consulté le )
  • (en) Daniel A Quist et Lorie M Liebrock, « Reversing Compiled Executables for Malware Analysis via Visualization », Information Visualization, vol. 10, no 2,‎ , p. 117–126 (DOI 10.1057/ivs.2010.11, lire en ligne, consulté le )
  • (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),‎ , p. 765–769 (DOI 10.1109/apcc.2012.6388211, lire en ligne, consulté le )
  • (en) S. Jilcott, « Scalable malware forensics using phylogenetic analysis », 2015 IEEE International Symposium on Technologies for Homeland Security (HST),‎ , p. 1–6 (DOI 10.1109/ths.2015.7225311, lire en ligne, consulté le ) Document utilisé pour la rédaction de l’article
  • (en) I. You et K. Yim, « Malware Obfuscation Techniques: A Brief Survey », 2010 International Conference on Broadband, Wireless Computing, Communication and Applications,‎ , p. 297–300 (DOI 10.1109/bwcca.2010.85, lire en ligne, consulté le ) Document utilisé pour la rédaction de l’article
  • (en) C. Rathnayaka et A. Jamdagni, « An Efficient Approach for Advanced Malware Analysis Using Memory Forensic Technique », 2017 IEEE Trustcom/BigDataSE/ICESS,‎ , p. 1145–1150 (DOI 10.1109/trustcom/bigdatase/icess.2017.365, lire en ligne, consulté le ) Document utilisé pour la rédaction de l’article
  • (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),‎ , p. 81–85 (DOI 10.1109/icadw.2016.7942517, lire en ligne, consulté le ) Document utilisé pour la rédaction de l’article
  • (en) Ioan Cristian Iacob, « Reverse Engineering Malicious Applications », Journal of Mobile, Embedded and Distributed Systems, vol. VII, no. 2, 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,‎ , p. 46–53 (ISBN 9781595938862, DOI 10.1145/1314389.1314399, lire en ligne, consulté le )
  • (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,‎ , p. 1772–1774 (ISBN 9781450341394, DOI 10.1145/2976749.2989041, lire en ligne, consulté le )
  • (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,‎ , p. 3–10 (DOI 10.1109/syssec.2011.24, lire en ligne, consulté le )
  • (en) Chih-Hung Lin, Hsing-Kuo Pao et Jian-Wei Liao, « Efficient dynamic malware analysis using virtual time control mechanics », Computers & Security, vol. 73,‎ , p. 359–373 (DOI 10.1016/j.cose.2017.11.010, lire en ligne, consulté le )
  • (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,‎ , p. 1:1–1:12 (ISBN 9781605586373, DOI 10.1145/2689702.2689703, lire en ligne, consulté le )
  • (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),‎ , p. 173–178 (DOI 10.1109/isias.2011.6122815, lire en ligne, consulté le )
  • (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, no 3,‎ , p. 245–256 (DOI 10.1177/1548512916670784, lire en ligne, consulté le )
  • (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,‎ , p. 8–14 (ISBN 9781450302029, DOI 10.1145/1940941.1940944, lire en ligne, consulté le )
  • (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,‎ , p. 38–47 (DOI 10.1109/ctc.2012.15, lire en ligne, consulté le )
  • (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),‎ , p. 720–723 (DOI 10.1109/kbei.2015.7436133, lire en ligne, consulté le )
  • (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),‎ , p. 13–17 (DOI 10.1109/ths.2012.6459819, lire en ligne, consulté le )
  • (en) M. Bombardieri, S. Castanò, F. Curcio et A. Furfaro, « Honeypot-Powered Malware Reverse Engineering », 2016 IEEE International Conference on Cloud Engineering Workshop (IC2EW),‎ , p. 65–69 (DOI 10.1109/ic2ew.2016.16, lire en ligne, consulté le )
  • (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,‎ , p. 115–120 (DOI 10.1109/ems.2012.20, lire en ligne, consulté le )
  • (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,‎ , p. 745–756 (ISBN 9781450338325, DOI 10.1145/2810103.2813627, lire en ligne, consulté le )
  • (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,‎ , p. 11–22 (ISBN 9781605587806, DOI 10.1145/1655148.1655151, lire en ligne, consulté le )
  • (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,‎ , p. 103–112 (ISBN 9781450331531, DOI 10.1145/2666652.2666665, lire en ligne, consulté le )
  • (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,‎ , p. 619–624 (DOI 10.1109/icsse.2010.5551719, lire en ligne, consulté le )
  • (en) Gérard Wagener, Radu State et Alexandre Dulaunoy, « Malware behaviour analysis », Journal in Computer Virology, vol. 4, no 4,‎ , p. 279–287 (ISSN 1772-9890 et 1772-9904, DOI 10.1007/s11416-007-0074-9, lire en ligne, consulté le )
  • (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),‎ , 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),‎ , 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,‎ , p. 149–154 (DOI 10.1109/eisic.2011.77, lire en ligne, consulté le )
  • (en) Matthieu Kaczmarek, « Malware Instrumentation Application to Regin Analysis », The Journal on Cybercrime & Digital Investigations, vol. 1, no 1,‎ (ISSN 2494-2715, DOI 10.18464/cybin.v1i1.2, lire en ligne, consulté le )
  • (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),‎ , p. 641–646 (DOI 10.1109/icctict.2016.7514657, lire en ligne, consulté le )
  • (en) Y. Gao, Z. Lu et Y. Luo, « Survey on malware anti-analysis », Fifth International Conference on Intelligent Control and Information Processing,‎ , p. 270–275 (DOI 10.1109/icicip.2014.7010353, lire en ligne, consulté le )

Articles connexes

[modifier | modifier le code]

Liens externes

[modifier | modifier le code]