Chopitea Thomas

« Il ne faut pas vendre la peau de l’ours avant d’avoir sinkholé tous ses domaines »-- Ancien proverbe chinois

En plus des classiques fichiers exécutables Windows (.exe ou .dll), les malwares se présentent sous d'autres formats divers. VBScript (Houdini), fichiers Office (droppers de Dridex ou divers types de ransomware), Python (convertis en PE avec py2exe), Java (histoire d’assurer l’interopérabilité entre systèmes), ELF, JScript (droppers Locky)… Ici, nous allons nous intéresser de près à un exemple de malware écrit en… Node.JS [1].

Dans la première partie de cet article (MISC n°85) nous avons présenté la Threat Intelligence, ses concepts, ses outils. Dans cette seconde et dernière partie, nous passons à la pratique. Nous allons voir comment la Threat Intelligence opérationnelle peut aider et comment elle s'insère dans les activités de réponse aux incidents et d'investigation numérique (DFIR).

Qu’on se prenne pour James Bond ou pour un shaman, ce que notre industrie appelle la Threat Intelligence fait place à beaucoup de fantasmes que les vendors nourrissent joyeusement à chaque fois qu’un nouveau rapport est publié. Mais, concrètement, à quoi ça sert de « faire de la threat intelligence » ? Quelle est la différence par rapport au renseignement classique ? Quels sont les avantages concrets que le renseignement sur les menaces apporte lors de la gestion d’un incident de sécurité ? C’est ce que cet article cherche à expliquer, du point de vue de deux DFIRers.

L’analyse de trafic réseau est une des techniques les plus populaires d’analyse dynamique de malwares. Dans le cadre de la réponse à incident, elle permet rapidement d’identifier les points de commande et contrôle (C2) et de produire des marqueurs ou indicateurs de compromission (« Indicators of Compromise », ou IOC) pertinents pour identifier des hôtes infectés. Les marqueurs réseau sont aussi un très bon point de pivot pour étendre sa connaissance sur l’adversaire : infrastructure, autres malwares, etc. Cependant, les outils classiques d’analyse réseau ne permettent pas de partager ses trouvailles avec d’autres chercheurs, obligeant la communauté « blue team » à partir de zéro lors de l’analyse. Nous allons voir comment Malcom essaye de répondre à ces besoins de partage et en quoi il diffère des outils d'analyse réseau classiques.

« Even minutiae should have a place in our collection, for things of a seemingly trifling nature, when enjoined with others of a more serious cast, may lead to valuable conclusion. » — George Washington