Cet article présente quelques techniques d'analyse qui ont fait leurs preuves en situation réelle, dans le cadre d'une réponse sur incident ou d'une recherche de compromission, de type APT ou SPT (Simple Persistent Threat pour les intimes), sur tout type de parcs. Ce domaine étant vaste, cet article s'attachera à dé nir les techniques employées par un analyste en charge de l'étude des logs proxy et des ux réseaux, appelé en urgence sur une suspicion de compromission. Ces techniques seront présentées de manière chronologique au fur et à mesure de l'investigation, en commençant par l'urgence des premières heures, et en nissant avec les ré exions des dernières semaines.
Appelé en urgence suite à la découverte d'un malware sur un serveur sensible ou la présence de chiers d'archives sur Internet, l'analyste est très souvent livré à lui-même dans le cadre d'une réponse sur incident ou d'une recherche de compromission. L'obligation de résultat et le stress le plongent dans une course e rénée contre le temps. La recherche de comportements suspects sera rythmée par des analyses plus ou moins complexes et rentables. Ainsi, les premières semaines, l'analyste s'orientera en priorité sur une approche low-hanging fruit [49], avec des analyses rentables et faciles pour dégrossir la masse de travail et découvrir un maximum d'attaques. Pendant les semaines suivantes, ayant une meilleure idée de la compromission, il s'attachera à mettre en place des analyses et alertes pour surveiller l'attaquant. Pour nir, des analyses plus complexes seront étudiées pour s'assurer que rien n'a été oublié.
Préparer et être prêt à la crise fait déjà partie de la réponse sur incident. Pour assurer une intervention rapide, l'analyste doit avoir revu et validé les méthodes d'analyse, de travail et les outils 1 . Comme chaque intervention o rira son lot d'imprévus et de surprises, notre analyse doit pouvoir surmonter chaque nouveau problème rencontré. Ainsi il préfèrera se baser sur plusieurs briques libres ou faites maison, pour s'assurer de la exibilité et du contrôle de ses solutions et outils. Concernant les méthodes d'analyse et de travail, il sera indispensable de respecter et appliquer les bonnes pratiques et méthodologies forensic : traçabilité des actions, main courante, modèles d'analyse et de rapport, structuration et consolidation des données dans une solution de partage et d'échange, comme un Wiki. Ceci dans l'objectif de structurer, consolider et partager les informations avec les équipes impliquées : du forensics système jusqu'aux administrateurs et managers.
La durée d'incident pouvant se compter en semaines, mois ou années, la masse d'informations à étudier peut devenir très importante et sa gestion complexe. Ainsi, notre analyste devra s'e orcer de :
Les premières semaines sont primordiales à l'analyste pour détecter et esquisser l'ampleur d'une compromission. La connaissance de l'entreprise : son architecture, ses applications et ses pratiques, les bonnes et surtout les mauvaises, sera un atout essentiel pour détecter des comportements suspects. Une véri cation des informations découvertes avec les équipes métiers sera régulièrement nécessaire lors de l'analyse de l'incident. Par exemple, l'envoi de 30 Go de données vers des systèmes hébergés dans un pays exotique pendant le week-end peut être tout à fait normal dans le cas d'un laboratoire qui envoie ses résultats à une équipe partenaire.
Le terme IOC Indicator of compromise [39] désigne un artéfact forensic, détectable sur le réseau ou sur un système d'exploitation, qui indique la présence d'une infection ou attaque donnée. Généralement, les IOC sont des adresses IP, domaines, hashs, URLs, etc., qui indiquent la présence d'un malware spéci que ou l'utilisation de C&Cs (Command and Control) [38] donnés. Plusieurs formats existent pour consolider et échanger les IOCs, comme OpenIOC [26], STIX [35], IODEF [16] (RFC5070), XML, etc. Malheureusement, peu de bases publiques d'IOCs sont disponibles (Iocbucket [21]) et généralement, les IOCs sont à extraire directement des rapports proposés par les sociétés d'antivirus ou de Cyber Intelligence. Heureusement, plusieurs projets de partage d'IOCs, comme le framework Open Source MISP [11] et des communautés d'échange [14] ont vu le jour pour permettre le partage et la consolidation des IOCs.
Face à l'urgence, une comparaison entre les IOCs privées/publiques et les informations à notre disposition (logs proxy, captures réseau, etc.) sera une première étape pour débroussailler la quantité d'informations et o rir peut-être les premières pistes.
La quantité de données La compromission pouvant s'étaler sur plusieurs semaines, mois ou années, les recherches sur plusieurs téraoctets de logs ou captures réseau peuvent être longues. Pour parvenir à optimiser les recherches et son précieux temps, l'analyste doit comprendre les goulots d'étranglement et les minimiser. Pour des traitements de recherche de motifs ou statistiques légers tels que les IOCs, les entrées-sorties sont le facteur limitant. Rien ne sert d'investir dans des machines contenant des centaines de c urs et To de RAM car le traitement par le CPU ou la place utilisée dans la RAM seront négligeables devant l'attente des informations lues sur le disque. Pour cette raison, il faut éviter de lire plusieurs fois la même donnée depuis le disque dur. Ainsi, il faudra utiliser de préférence des logs compressés pour maximiser la quantité d'informations utiles récupérées par chaque accès au support et d'autre part utiliser un moteur d'indexation pour minimiser le nombre d'accès aux chiers.
Il existe de nombreuses solutions d'indexation et de recherche pour le traitement en masse, comme Splunk ou RSA SA. Toutefois il est également possible de bricoler, pour des analyses ponctuelles, avec la solution libre ELKS 3 qui est disponible pour Windows et Linux.
Les premiers débroussaillages étant e ectués, l'analyste continuera la recherche d'une compromission par le calcul de métadonnées sur certaines valeurs, telles que les domaines/IPs, volumétries, etc. pour en étudier les variations sur les valeurs extrêmes (maximums et minimums) et mettre en évidence des comportements illégitimes. Ces recherches de maximums et minimums permettront de lever une alerte si les résultats changent dans le temps, et donneront à l'analyste les premières pistes de recherche.
Machines infectées Comme les polling intervals4 des malwares sont généralement faibles, inférieurs à 5 minutes, il n'est pas rare de trouver un C&C dans les domaines les plus accédés depuis le réseau. Ainsi, étudier les domaines et IPs les plus accédés, pendant une période d'inactivité comme le week-end, sera intéressant pour détecter des machines infectées. Cette analyse peut être aussi appliquée sur les comptes 5 et machines qui accèdent ou envoient le plus d'informations, à l'extérieur.
Possible ex ltrations L'échange d'une grosse quantité d'informations est toujours une action suspecte. Lorsque les informations sont transmises à l'extérieur (volumétrie montante), la suspicion est autrement grande car il pourrait s'agir d'une ex ltrations de données. Ainsi, la recherche du top 10 des domaines/IPs réalisant le plus de volumétrie montante, pendant les weekends ou par mois, sera un bon exercice pour découvrir d'éventuelles ex ltrations. Au même titre, étudier la volumétrie montante selon les domaines/IPs pour les méthodes HTTP CONNECT et POST sera intéressant. Plus globalement, l'utilisation du ratio :
|
|
servira à l'étude de volumétries dites asynchrones (échange de grandes quantités de données émises ou reçues) en analysant les valeurs extrêmes.
Chaque découverte demandera une véri cation avec les équipes métiers pour s'assurer que le comportement est bien anormal, et ainsi se familiariser avec les applications et pratiques de l'entreprise (les bonnes, et surtout les mauvaises). Ces études permettent de trouver les grandes étapes et indices de la compromission pour commencer à remonter le l de l'investigation. Les informations récoltées permettront aussi de déterminer les seuils et informations pertinentes à surveiller durant les prochaines semaines.
Quand cela est possible, les éléments découverts lors du traitement de l'incident peuvent être recherchés et corrélés sur plusieurs bases d'informations privées ou publiques. Pour des raisons d'image et de marketing, cette opération de collecte et de corrélation est souvent appelée Cyber Intelligence. Les objectifs de la Cyber Int (pour les intimes) sont d'obtenir des informations nouvelles ou historiques sur un IOC recherché, et con rmer ou in rmer certaines hypothèses, telles que la famille du malware, le groupe d'attaquants, etc. Ces informations récoltées seront ensuite réutilisées pour découvrir de nouveaux éléments de compromission.
Cette section se limitera à une rapide introduction des outils et techniques utilisables pendant les premières semaines d'intervention :
Dans l'exemple gure 1, les arcs marqués d'une date représentent les résolutions DNS e ectuées dans le passé entre un domaine et une ou plusieurs adresses IPs et les plus foncés et sans date 6 , indiquent l'IP courante du domaine. Sur le terrain, en partant d'un ou plusieurs C&C déjà identi és dans l'investigation, l'analyste va pouvoir découvrir de nouveaux C&Cs liés à l'attaque, estimer la date de début de l'utilisation de ces C&C ou encore détecter la réutilisation de vieux domaines par le ou les attaquants. Ces nouveaux éléments seront ensuite ajoutés dans les sondes ou dans l'analyse des logs proxy pour augmenter l'étendue de détection de l'attaque et trouver de nouvelles machines compromises ;
Ces domaines nous renseignent sur une éventuelle attaque ciblée ou attaque de point d'eau (watering hole attack [40]) utilisant des noms de domaines proches de celui d'entreprises existantes ;
Les résultats des premières semaines révéleront les grandes étapes et indices de la compromission, comme les C&C, les machines compromises, des patterns réseau ou les malwares utilisés. Avec cette vision plus claire de la compromission, notre analyste perspicace continuera à détecter une éventuelle nouvelle attaque 9 , tout en surveillant la première. Le but ultime est de suivre les actions de l'attaquant 10 pour réagir au bon moment et, quand cela est possible couper une éventuelle ex ltration. Bien sûr, il n'est pas exclu que l'analyste puisse revenir sur les actions e ectuées dans les premières semaines, pour ajuster ou récupérer de nouvelles informations.
Surveiller l'attaque, en parallèle de l'investigation, est le subtil équilibre que l'analyste doit trouver durant cette phase. Cette surveillance est généralement orchestrée selon 2 axes :
Sans préciser l'ensemble des outils ou solutions disponibles, cette sous-section présente des idées et axes de recherche pour découvrir des incohérences sur des points clés du SI :
L'utilisation des dissectors SMB [51], SMB2 [52] et ntlmssp [50] de Tshark 12 sera utile pour bricoler sur les études des volumétries et d'accès aux chiers des partages SMB. Une description plus détaillée, ainsi que des exemples pratiques sur l'analyse des ux SMB, est disponible dans l'annexe A.
Les analystes les plus combatifs n'hésiteront pas à aller plus loin dans l'étude pour :
En parallèle de la surveillance, le travail d'investigation de notre chercheur forensic est toujours d'actualité. La course pour découvrir un maximum d'indices, détails et preuves continue, et la découverte d'une éventuelle nouvelle attaque est toujours possible. Ainsi, en plus du travail des premières semaines, il continuera à a ner ses recherches de compromission au travers d'études comme celles-ci :
Après quelques semaines passées sur l'incident, notre analyste aura trouvé la ou les attaques, compris l'étendue de la compromission, surveillé, et dans certains cas sonné l'alarme pendant les phases critiques, telles que la récupération massive de documents ou les tentatives d'ex itrations.
En regard du manque de temps et du coup de feu des premières semaines, la n de l'investigation laisse place à des recherches plus abstraites et plus longues décorrelées de l'urgence au travers d'une approche un peu plus mathématique. L'objectif de ces études est d'analyser la compromission sous un angle di érent, pour s'assurer de n'avoir pas oublié ou négligé des pistes dans l'urgence des semaines précédentes. Beaucoup d'axes d'études sont possibles mais les calculs statistiques et de périodicités o rent les meilleurs résultats sur les logs proxy et captures réseau.
L'approche statistique par regroupement (clustering) permet de fournir les premiers éléments/outils pour aider à la découverte de comportements suspicieux. Cette technique consiste à grouper les informations qui partagent des métriques similaires pour former un groupe (cluster), l'objectif étant de les analyser individuellement et conjointement. Le clustering rend possible de traiter une grande masse de données et d'o rir une visualisation adaptée à la recherche d'anomalies par des être humains. Cette visualisation permet de se focaliser non pas sur les nuages de points (comportements classiques), mais sur les points extérieurs aux nuages de points (comportements anormaux). Cette technique est très souvent exploitée dans l'exploration de données (data mining) et l'apprentissage automatique (machine learning).
Un grand nombre de méthodes de calcul et d'algorithmes sont disponibles, comme OPTICS [45], DBSCAN [41], MDS [44], LOF [43]. En pratique il est préférable de partir sur les algorithmes DBSCAN [41] et MDS [44] pour les raisons suivantes :
L'ensemble des analyses de cette partie repose sur le choix de la métrique (distance function) utilisée. Dans le cas présent, la métrique correspond à une fonction de combinaison des champs, des logs proxy ou des protocoles que l'on souhaite étudier conjointement. Par exemple, pour étudier la corrélation de l'activité web des utilisateurs dans la journée, une métrique intéressante sera la combinaison entre les domaines/IPs, le timestamps et le compte ou la machine utilisé(e). Des exemples et idées de métriques applicables sur les logs proxy vont être présentés ci-dessous.
L'objectif est de collecter, pour un domaine donné un ensemble de métriques sur les URIs pour déterminer si elles sont su samment variables et ressemblent à un site web classique (page web, CSS, JavaScript, etc.). En e et, les URIs générées par les malwares comportent, le plus souvent, beaucoup ou peu de variations. La répartition des variations est souvent dé nie selon une fonction de répartition, où les URIs malveillantes sont réparties dans les valeurs extrêmes et les sites web classiques autour de la moyenne. Ainsi, pour étudier les variations il est intéressant de déterminer pour chaque domaine de deuxième et troisième niveau les statistiques suivantes, selon le temps et le nombre :
La liste de ces métriques n'est pas exhaustive, mais constitue un moyen rapide de découvrir des domaines ou adresses IP suspect(e)s ;
Comme un grand nombre d'actions légitimes ou malveillantes sont prédictibles (mise à jour des logiciels périodiquement) ou scénarisables (consultation des emails tous les matins en arrivant au travail), il est intéressant d'étudier les périodes ou fréquences d'une métrique, dans le but d'analyser les déviances de la métrique. Le calcul des fréquences étant complexe et parfois impossible 16 , l'utilisation d'un simple algorithme d'estimation de période est préconisé. Estimer la période d'une valeur de la métrique, suppose de déterminer :
Par exemple sur une semaine, si on observe que le domaine youtube.com est accédé tout les jours, à 9h00, 12h00, 14h00 et 16h00. Les intervalles de temps entre les valeurs sont : 2, 3, 4, 5, 7 et 25 heures. Si on compte combien de fois les intervalles de temps apparaissent dans notre exemple, nous obtenons :
Comme l'intervalle 2 heures est celui qui apparaît le plus de fois, notre estimation de période est de 2 heures.
Des exemples et axes de recherches basés sur cette idée sont présentés ci-dessous :
L'étude permet de distinguer les domaines et adresses IPs liés 17 aux :
Avec ce rapide classement en tête, l'analyste pourra se lancer dans l'étude des valeurs importantes dans les zones non conventionnelles, comme par exemple en dessous de 3 minutes. En regardant plus attentivement, deux valeurs importantes inférieures à 1 minute ressortent de la gure 2. La première, èche noire à gauche, représente l'activité d'un RAT étalée sur une semaine. La périodicité de cette valeur s'explique par un faible polling interval dans la con guration du RAT (50 secondes). La seconde valeur, èche grise, est due à la présence d'un adware qui essaye de joindre un site pour y télécharger les publicités à a cher. Pour continuer l'étude, il est envisageable d'attribuer une couleur à tous les domaines/IPs d'une même catégorie et d'analyser les domaines et IPs ne répondant pas aux catégories prédé nies. Pour nir, il sera aussi intéressant de comparer les domaines/IPs catégorisés par nos soins avec des listes ou sites web dédiés à la catégorisation ;
Ces recherches plus abstraite et plus mathématique, restent encore expérimentales, di ciles et longues à calculer. Cependant, elles o rent les premiers pas dans l'expérimentation du data mining forensic pour l'analyste imaginatif, qui n'hésitera pas à investir dans plusieurs clusters Hadoop pour subvenir à ses besoins.
Les semaines passées sur l'incident auront permis de trouver les méthodes, outils et actions de l'attaquant. Le plan de reconstruction sonne la n de l'investigation et le repos pour l'analyste. En espérant que toutes les mesures de la bascule, boutent dé nitivement l'attaquant hors du SI, le chercheur forensic épuisé s'assurera de faire le point avec l'ensemble des équipes. Malheureusement, le Retour d'Expérience (RETEX) est trop souvent rapidement expédié ou même complètement oublié, alors qu'il reste fondamental une fois l'investigation nie 18 . On s'assurera que tout le monde, interne et externe, puisse s'exprimer librement pour échanger et proposer des idées d'améliorations pour les prochaines réponses sur incident.
Depuis plusieurs années, l'analyse d'un système à chaud (live forensic) a fait son apparition. Cette nouvelle vision du forensic n'échappe pas aux analyses des logs et ux réseaux : alors qu'une analyse rapide de quelques centaines de Mo de logs proxy était su sante il y a quelques années, l'analyste doit aujourd'hui trouver une aiguille dans des teraoctets de logs proxy et rewall, tout en jonglant avec les di érents formats de ux réseaux et sous la pression de ses supérieurs qui attendent une analyse complète et sans faute, pour hier . Cette évolution montre bien le besoin de professionalisation des outils et des analystes qui doivent arriver déjà préparés et outillés pour mener à bien ces nouvelles missions. Cette préparation doit également passer par des discussions dans la communauté sécurité pour échanger sur les méthodes d'analyse et partager des outils. Nous espérons que cet article aura donné quelques pistes aux lecteurs confrontés à ces problématiques.
Comme vu à la section 2.3, l'analyse des ux SMB peut être très utile pour détecter les collectes des chiers avant ex ltration ou encore découvrir les phases de scan des partages SMB et de collecte des chiers durant une attaque. Ainsi, cette annexe détaillera les di érents elds à utiliser pour manipuler les ux SMB avec Tshark et présentera des exemples utiles sur le terrain d'une réponse sur incident.
Les dissectors SMB [51], SMB2 [52] et ntlmssp [50] de Tshark nous permettent d'extraire l'ensemble des informations nécessaires pour réaliser l'étude des ux SMB. Voici les elds les plus utiles dans nos recherches :
La complexité du protocole SMB et les nombreux faux positifs engendrés durant l'analyse, peuvent rapidement dérouter un analyste. Néanmoins, sur le terrain, des exemples simples peuvent être exploités. Par exemple, il sera envisageable de :
Attention, au chier gpt.ini (stratégie de groupe) qui peut générer un grand nombre de faux positifs, avec le ltre utilisé ci-dessus.
Le ltre ci-dessous a che l'ensemble des chiers copiés.
Si l'exécutable PsExec n'est pas renommé par l'attaquant, l'exemple
précédent listera toutes les exécutions de PsExec. En e et, l'exécution de
PsExec entraine la copie du binaire sur Admin$ du poste distant. S'il a été
renommé, une recherche du smb. le :
psexecsvc avec la commande SMB : SMB_COM_NT_CREATE_ANDX sera
nécessaire pour détecter la présence de PsExec sur le réseau ( ltre :
smb.cmd eq 0xa2 and smb.nt_status eq 0x0 and smb. le contains
psexecsvc).
L'utilisation de algorithme DBSCAN [41] demande 2 paramètres :
Malheureusement, il n'y a pas de valeur type pour MinPts et et leurs valeurs changent en fonction de ce que vous recherchez. Plus MinPts est petit, plus il y aura de clusters et donc une augmentation des clusters de bruit. Pour , si la valeur est trop grande, une grande partie des informations seront vues comme appartenant au même cluster. Pour un trop faible, une majorité des informations ne seront pas regroupées en cluster. Pour les plus coriace, la valeur peut être déterminée par le biais d'un graphe de K-distance [47]
1. Base de géolocalisation Hostip.info. http://www.hostip.info/dl/index.html.
2. Base de géolocalisation Maxmind. https://www.maxmind.com/en/geolocation_landing.
3. Base de passive DNS de Dnsparse . https://dnsparse.insec.auckland.ac.nz/dns/query.php.
4. Base de passive DNS de Exposure. http://exposure.iseclab.org/.
5. Base de passive DNS de la société BFK. https://www.bfk.de/bfk_dnslogger.html.
6. Base de passive DNS de société Farsight Security (DNSDB). https://www.dnsdb.info/.
7. Base de passive DNS de société VirusTotal. https://www.virustotal.com/en/#search.
8. Base de passive DNS du CERT-EE . sim.cert.ee:43.
9. Github du projet ChopShop. https://github.com/MITRECND/chopshop.
10. Github du projet Faup. https://github.com/stricaud/faup.
11. Github du projet MISP. https://github.com/MISP/MISP.
12. Liste de DDNS (dnslookup). http://dnslookup.me/dynamic-_dns/.
13. Liste de DDNS (freedns.afraid.org). https://freedns.afraid.org/domain/registry/.
14. Plateforme MISP du CIRCL. https://www.circl.lu/services/misp-_malware-_information-_sharing-_platform/.
15. RFC 3986. http://tools.ietf.org/html/rfc3986.
16. RFC 5070. https://www.ietf.org/rfc/rfc5070.txt.
17. Site o ciel du FPC Open Source : OpenFPC. http://www.openfpc.org/.
18. Site o ciel du NIDS Bro. https://www.bro.org/.
19. Site o ciel du NIDS Snort. https://www.snort.org/.
20. Site o ciel du NIDS Suricata. http://suricata-_ids.org/.
21. Site web d'Iocbucket. https://www.iocbucket.com.
22. Crowdstrike. Document de Crowdstrike sur l'opération Sa ron rose. http://blog.crowdstrike.com/cat-_scratch-_fever-_crowdstrike-_tracks-_ newly-_reported-_iranian-_actor-_flying-_kitten/.
23. Fireeye. Document de Fireeye sur l'opération Sa ron rose. https://www.fireeye.com/resources/pdfs/fireeye-_operation-_saffron-_rose.pdf.
24. Google. Dé nition et explication des advanced-operators de Google. https://sites.google.com/site/gwebsearcheducation/advanced-_operators.
25. Mandiant. Dé nition et explication du imphash par Mandiant. https://www.mandiant.com/blog/tracking-_malware-_import-_hashing/.
26. Mandiant. Site o ciel sur le format OpenIOC. http://www.openioc.org/.
27. Microsoft. Documentation sur la commande SMB_COM_DELETE (0x06). https://msdn.microsoft.com/en-_us/library/ee442133.aspx.
28. Microsoft. Documentation sur la commande SMB_COM_DELETE_DIRECTORY (0x01). https://msdn.microsoft.com/en-_us/library/ee441479.aspx.
29. Microsoft. Documentation sur la commande SMB_COM_MOVE (0x2A). https://msdn.microsoft.com/en-_us/library/ee441847.aspx.
30. Microsoft. Documentation sur la commande SMB_COM_NT_CREATE_ANDX (0xA2). https://msdn.microsoft.com/en-_us/library/ee442091.aspx.
31. Microsoft. Documentation sur la commande SMB_COM_READ_ANDX (0x2E). https://msdn.microsoft.com/en-_us/library/ee441503.aspx.
32. Microsoft. Documentation sur la commande SMB_COM_TREE_CONNECT_ANDX (0x75). https://msdn.microsoft.com/en-_us/library/ee441940.aspx.
33. Microsoft. Documentation sur la commande SMB_COM_WRITE_ANDX (0x2F). https://msdn.microsoft.com/en-_us/library/ee441848.aspx.
34. Microsoft. Documentation sur les commandes SMB. https://msdn.microsoft.com/en-_us/library/ee441741.aspx.
35. MITRE. Site o ciel sur le format STIX. http://stix.mitre.org/.
36. OpenDNS. Dé nition et explication des termes co-occurrences et Related Domains. http://labs.opendns.com/2013/07/24/co-_occurrences/.
37. Scikit-learn. Site o ciel de la bibliothèque python Scikit learn. http://scikit-_learn.org/stable/index.html.
38. Trendmicro. Dé nition du terme Command and Control. https://www.trendmicro.com/vinfo/us/security/definition/command-_and-_control-_\%28c-_c\%29-_server.
39. Wikipedia. Dé nition du terme IOC (Indicator of compromise). https://en.wikipedia.org/wiki/Indicator_of_compromise.
40. Wikipedia. Dé nition du terme watering hole attack (attaque de point d'eau). https://en.wikipedia.org/wiki/Watering_Hole.
41. Wikipedia. Explication de l'algorithme DBSCAN. https://en.wikipedia.org/wiki/DBSCAN.
42. Wikipedia. Explication de l'algorithme K-means. https://en.wikipedia.org/wiki/K-_means_clustering.
43. Wikipedia. Explication de l'algorithme LOF. https://en.wikipedia.org/wiki/Local_outlier_factor.
44. Wikipedia. Explication de l'algorithme MDS (Multidimensional scaling). https://en.wikipedia.org/wiki/Multidimensional_scaling.
45. Wikipedia. Explication de l'algorithme OPTICS. https://en.wikipedia.org/wiki/OPTICS.
46. Wikipedia. Explication de transformation de Fourier discrète. https://fr.wikipedia.org/wiki/Transformation_de_Fourier_discr%C3%A8te.
47. Wikipedia. Explication du graphe de K-distance. https://en.wikipedia.org/wiki/K-_distance_graph.
48. Wikipedia. Formule de l'entropie de Shannon. https://en.wikipedia.org/wiki/Information_theory#Quantities_of_information.
49. Wiktionary. Dé nition du terme low-hanging fruit. https://en.wiktionary.org/wiki/low-_hanging_fruit.
50. Wireshark. Documentation sur le dissector ntlmssp. https://www.wireshark.org/docs/dfref/n/ntlmssp.html.
51. Wireshark. Documentation sur le dissector SMB. https://www.wireshark.org/docs/dfref/s/smb.html.
52. Wireshark. Documentation sur le dissector SMB2. https://www.wireshark.org/docs/dfref/s/smb2.html.
