OSSIR Bretagne - Avril 2014
ça faisait longtemps que je n’avais assisté à une séance de l’OSSIR Bretagne.
Splunk : plateforme d’analyse d’événements de sécurité
Au lieu d’adapter les données à l’outil d’analyse de log par un pré-formatage. On intègre directement toutes les sources de données telles quelles. L’approche clustering de Splunk, permet de tenir le volume de données généré par ces sources de données.
Retour sur l’exemple des APT avec Splunk, Snowman, Caretto, des malwares peu diffusés utilisés pour des attaques très ciblés. Splunk ne permet pas de bloquer ce type d’attaques, mais permet de découvrir les artefacts laissés par le malware lors de l’intrusion.
Le malware tentera d’entrer en contact avec son serveur de C&C de façon régulière. Qu’il y arrive ou non, il laissera des traces réseau qui peuvent être collectées à partir de traces netflow etc. La périodicité des contacts effectués par le malware peut être détecté sous réserve d’avoir une fenêtre d’analyse assez grande.
A partir d’un langage simple, inspiré du bash, on peut directement créer des requêtes sur les données avec des pipes et des wildcards.
On peut ainsi exprimer dans ce langage des analyses simples qui mettent en exergue un comportement particulier comme les contacts réguliers fait par un malware vers son C&C.
L’architecture de splunk permet d’intégrer n’importe quel type de sources qui vont être parsés pour être en suite stockés sous forme textuelles. les événements sont agrégés, typés et indexés dans la base de données de splunk. Une fois intégrés dans Splunk, les données peuvent aussi être ressorties vers d’autres systèmes tels que syslog.
Splunk peut être éclaté sur N machines avec des clusters d’indexation et des machines d’analyse et de recherche de données. L’accès au données peut faire l’objet d’une politique de sécurité spécifique pour chaque « tête de recherche ».
Exemple avec Bro IDS, un outil de capture de paquets capable de traiter du 100GE ! la logique de Bro permet de traiter des logiques réseau sous forme de règles pour extraire les informations que l’on souhaite monitorer. Ce qui permet par exemple d’obtenir l’ensemble des échanges réseaux ou des pdf sont échangés. Et tout ça s’intègre dans Splunk en natif.
En gros, Splunk, c’est un framework sur lequel on va construire un système d’analyse d’événements de sécurité adapté a chaque contexte. Pour ceux qui ne veulent pas construire, ya des applications pour ça…
Fast Forensics: Quand l’heure tourne
par Sebastien Larinier – Sekoia
Quant on cherche, on trouve, et quand il s’agit de sécurité, on se retrouve forcément avec une réponse sur incident sur les bras. Il faut donc effectuer des analyses, non pas post-mortem mais en live sur le système compromis. C’est ce principe qui se cache sous #DFIR. Le fast forensic à pour but de comprendre très rapidement l’ampleur de l’attaque, l’objectif de l’attaque, et d’établir un plan de remédiation et de reprise du service.
Le traitement d’un incident peut coûter très cher, car lorsqu’un pan entier de l’entreprise fonctionne au ralenti parce qu’on traite un virus (même banal), l’entreprise perd de l’argent.
L’analyse forensic traditionelle qui consiste à collecter des images disques des systèmes pose beaucoup de problèmes: arrêt des systèmes pour analyse, collecte des données, etc… ce qui est simple lorsqu’il s’agit d’une ou deux machine devient infernal lorsque l’intrusion à lieu sur une trentaine de machines répartis sur plusieurs sites au travers du globe.
Du coup la problématique c’est trouver une aiguille dans 1000 bottes de foin sans tout brûler…
La question qui se pose souvent lors d’une réponse sur incident, c’est Qui attaque, le problème c’est pas le malware mais l’entité ou l’individu derrière ce logiciel malveillant. Plus important encore, la question de ce qui intéresse l’attaquant et de son niveau de technicité permet d’avoir une idée de qui est derrière l’attaque.
Le fast forensic consiste donc à partir du malware ou de la machine compromise pour remonter vers un corpus d’informations permettant de répondre à ces questions.
Un malware utilisant un driver pour s’installer au niveau du kernel, il laisse des traces dans les EVT. De même l’exécution d’un PSExec sur une machine, et le service créé correspondant sur l’autre est un événement de sécurité intéressant.
Le niveau de furtivité du malware est corellé avec la sophistication du malware. le niveau de protection offert par le packer est aussi un indicateur. La persistance par la base de registre, des services ou des drivers assure différent niveaux de persistance, techniques anti-forensic etc…
La technique consiste donc à effectuer une acquisition de la RAM, ainsi qu’une prise d’image à chaud du disque pendant que la machine fonctionne. Ce qui permet d’avoir l’équivalent d’un snapshot de machine virtuelle.
Dans la RAM, la MFT indique ou se situe les informations du disque, et si l’on effectue un diff entre la MFT et l’image du disque prise à chaud, on peut découvrir les éléments cachés par le rootkit.
Pour lister les sockets en écoute, il vaut mieux passer par un driver pour obtenir les informations en direct, plutôt que de passer par l’API Windows dont les réponses sont potentiellement trafiquées par le malware.
La recherche de pages mémoires exécutables alors qu’elle ne le sont pas dans le binaire de base est un indicateur d’une injection dans la mémoire du process.
Les mutex et les pipes nommés sont des éléments de communication entre les exécutables qui coopèrent pour former le malware. Ce qui rend leur exécution unitaire dans une sandbox impossible s’ils n’ont pas été chaînés dans l’ordre.
Pour l’acquisition à chaud, soit on travail à partir des shadow copy, soit on travaille à partir de la MFT. L’acquisition à froid est très utile pour effectuer une timeline et rechercher des indicateurs de compromission (IOC).
L’utilisation de md5 des binaires présents sur le système et leur comparaison par rapport à une base de md5 de binaires sains permet de faire le tri et d’identifier les binaires backdoorés.
Certaines suites logicielles telle que DFF permet d’automatiser pas mal la partie forensic classique.
Le plus long c’est de développer le collecteur d’information, et d’avoir une base d’IOC. La problématique du partage de ces IOC, et de la mise en place d’un système de partage d’information interopérable n’est pas simple.