Conférence sur la Réponse aux Incidents et l'Investigation CoRIIN 2019 à Lille

Date : 07 Janvier 2019

La 4ème édition de la conférence sur la réponse aux incidents et l’investigation numérique CoRI&IN 2019 s’est déroulée à Lille le 21 Janvier 2019. Elle s’est tenue un jour avant le FIC 2019 (Forum International sur la Cybersécurité) et était organisée par le Centre Expert contre la Cybercriminalité Français (CECyF).

Cette conférence est dédiée aux techniques de réponse aux incidents et d’investigation numérique. Elle a permis de rassembler une communauté d’experts sur la réponse aux incidents, de CERTs, d’enquêteurs spécialisés, d’experts judiciaires, juristes et chercheurs en sécurité informatique.

Cette journée a donné lieu à 9 présentations orientées forensics pour la plupart. Les supports de présentation sont disponibles sauf pour les retours d’expériences de cas réels qui restent confidentiels.

Nous donnons ci-dessous un compte rendu rapide de chacune des présentations, en suivant l’ordre du déroulement de la conférence.

[Etat de l’art] La montée des logiciels malveillants destructifs
Thomas Roccia, Chercheur en Sécurité chez McAfee, @fr0gger_
TLP: [WHITE]

Présentation des malwares destructeurs, qui ont la capacité à détruire les données et les systèmes. Il y a eu ces dernières années plusieurs campagnes qui utilisaient ces types de logiciels malveillants : MIRAI (2016), TRITON (2017), NotPetya (2018), VPNFilter (2018), Shamoon v3 (2018)…

Il existe différentes catégories de malwares destructeurs pour les classer :

Wiping (amenant à la suppression, réécriture des données), par exemple VFEmail
Encryption (pour éviter une possible récupération des données), par exemple NotPetya
Anti-Forensics (suppression des évènements de type logs, backups)
Physical impact (dont le but est le sabotage et la destruction physique des équipements), par exemple Shamoon.
DDoS (pour rendre des services inaccessibles), par exemple Mirai

Ces malwares doivent pouvoir se propager et utilisent donc en général les derniers exploits disponibles. La motivation des attaquants est généralement : financière, idéologique, acte hacktiviste…
Pour se préparer au mieux à ces campagnes de malwares destructeurs il est conseillé :

d’améliorer la segmentation du réseau de l’entreprise (en identifiant les nœuds du réseau qui seront utilisés pour répandre une telle attaque),
de gérer le patch management de manière priorisée,
d’effectuer régulièrement des sauvegardes et de préparer un plan de réponse à incident.

[Threat Intelligence] Goblin Panda: La chine en Asie du Sud Est
Sébastien Larinier, chercheur en sécurité et fondateur de Franco-Misp, @sebdraven
TLP: [AMBER]

Il n’y a pas de compte rendu pour cette présentation, suite à la demande de l’orateur.

Liens additionnels vers le blog de Sébastien (portant sur des investigations liées au groupe « Goblin Panda ») :

Goblin Panda targets Cambodia sharing capacities with another Chinese group hackers Temp Periscope
(https://medium.com/@Sebdraven/goblin-panda-targets-cambodia-sharing-capacities-with-another-chinese-group-hackers-temp-periscope-7871382ffcc0)
Goblin Panda against the Bears
(https://medium.com/@Sebdraven/gobelin-panda-against-the-bears-1f462d00e3a4)
Goblin Panda changes the dropper and reuses the old infrastructure
(https://medium.com/@Sebdraven/goblin-panda-changes-the-dropper-and-reused-the-old-infrastructure-a35915f3e37a)

[Forensics] Investigation dans AmCache
Blanche Lagny, Chercheur à l'ANSSI, @moustik01
TLP: [WHITE]

AmCache est une base de données spécifique à Windows qui consigne des métadonnées (nom du fichier, chemin d’exécution et hash de l’exécutable) portant sur l’exécution de binaires et l’installation de programmes sur un système. La présentation mettait en évidence l’importance de l’AmCache dans des investigations Forensics à travers différents scénarios effectués sur différents systèmes d’exploitation : Windows 7, 8 et 10. Ces scénarios ont mis en évidence le fait qu’AmCache stocke des données différentes suivant ces systèmes Windows. L’utilisation d’Amcache semble intéressante dans le cadre d’un Forensic où un fichier malveillant a infecté un système mais que l’exécutable n’est plus présent sur la machine. AmCache permet alors de récupérer des métadonnées relatives à ce malware. Il faut tout de même noter le fait qu’il existe des moyens de contournement, permettant à un attaquant d’exécuter un malware sans pour autant laisser de traces, et ce même dans AmCache.

Lien : https://www.ssi.gouv.fr/en/publication/amcache-analysis/

[Retex] Memcached ou quand votre backbone devient fou
Sébastien Mériot, responsable du CSIRT OVH, @smeriot
TLP: [WHITE]

Il s’agit d’un retour d’expérience pour une attaque de type déni de services distribués subie par OVH d’intensité 1,35Tb/s. Celle-ci a pu être contenue grâce à une investigation menée en amont par les équipes OVH et la mise en place de mesures de sécurité. Cette attaque était de type « amplification » (c’est-à-dire qu’elle effectuait une requête amenant une réponse de la part du service de taille plus importante) et « réflexion » (requête effectuée par un attaquant se faisant passer pour sa victime, de ce fait la réponse sera envoyée à la victime sans que celui-ci n’ait effectué une quelconque manipulation). Cette attaque DDoS utilisait des serveurs Memcached (écoutant sur le port 11211) mal configurés, cequi a permis une amplification de l’attaque d’un facteur 5000 (à titre de comparaison le service SNMP permet un facteur d’amplification de 6, DNS de 40, NTP de 560). Pour remédier cette attaque et la contenir, les équipes d’OVH ont opté pour une limitation du trafic sur le port UDP concerné. OVH a ensuite demandé à ses clients ayant mis en place un serveur Memcached de déployer les derniers correctifs de l’application ; ceux-ci permettaient en particulier de ne plus avoir ce port d’écoute ouvert sur internet.

Lien : https://www.ovh.com/fr/blog/13-tbps-mitiges-vac-retour-memcached/

[Etat de l’art] Agressions électromagnétiques et forensics
José Lopes Esteves, Chercheur à l'ANSSI, @lopessecurity
TLP: [WHITE]

Il s’agit d’une présentation d’un nouveau type d’attaque, qui pourrait se développer dans un futur proche, et qui se base sur les ondes pour effectuer des agressions électromagnétiques. Le but est donc d’identifier ces types d’ondes néfastes pour les reproduire avec comme objectif de détruire des composants, de dégrader des liens radio-fréquences (brouillage) ou de leurrer des capteurs. Il faut noter que pour le défenseur, détecter les agressions électromagnétiques est couteux : à la fois pour la détection des agresseurs (avec la surveillance de spectre, supervision de large bandes de fréquences, détecter des agressions dont on ne connait pas la conséquence) mais aussi pour la détection des systèmes agressés (déploiement d’un agent de supervision, système de supervision qui peut lui aussi se faire agresser). Un exemple d’application aux agressions électromagnétique a été présenté : celui des drones, avec en particulier comme objectif de détecter que ces derniers ont subi une agression. Les logs des drones sont très verbeux et donnent des indications concernant l’agression ou non de ce dernier par des ondes. Pour faciliter l’investigation, il est envisagé d’ajouter dans les logs un « Watermark », c’est-à-dire de poser un marqueur de type « timestamp » lorsque le drone passe à certains endroits géographiques précis. Grâce à ce Watermark, il sera possible de connaitre le lieu de l’agression électromagnétique.

[Retex] AWS EC2 Forensics 101
Frédéric Baguelin, CERT Societe Generale, @udgover
TLP: [WHITE]

Il s’agit d’un retour d’expérience (Retex) sur une investigation Forensic liée à des données hébergées dans le Cloud d’Amazon (AWS EC2). La présentation ne porte pas sur l’investigation Forensic en elle-même, mais plutôt sur la récupération des données présentes dans le cloud vers des machines locales. La totalité des données représentait ici pas loin de 6,6TB. Les différentes étapes effectuées étaient les suivantes :

Lister toutes les instances pour lesquelles il fallait récupérer les données,
Effectuer l’acquisition de ces données. Les difficultés rencontrées étaient liées dans un premier temps aux « avaibility zones » dans lesquelles étaient situés les serveurs Amazon. Par exemple si ce serveur est situé en Asie et n’est consultable que pour des personnes situées dans la même zone géographique, il faut alors procéder dans un premier temps à un duplicata de ces données vers un autre serveur AWS EC2, pour par la suite récupérer ces données.
Pour chaque serveur il fallait ensuite effectuer un snapshot de celui-ci dans un nouveau serveur Amazon de type S3 (copie de 200GB ~10min), donner les bons droits d’accès, et si les données étaient chiffrées, il fallait aussi donner les droits d’accès à la clé et effectuer la demande de déchiffrement.
Enfin une instance permettant de faire l’acquisition des données (outils EWFAcquire sur une machine de type Ubuntu) était déployée pour finalement permettre de récupérer les données puis de les transférer vers les machines locales au sein de la société.

Ce qu’il faut retenir de ce retex sur des données stockées dans le Cloud, c’est :

qu’il n’existe pas d’outils simple aujourd’hui, permettant d’effectuer un dump des disques durs des machines du cloud (ou en tout cas, pas d’outil mis à disposition par Amazon),
qu’effectuer un dump des données d’un Cloud vers des machines locales n’est pas sans frais. En effet le flux I/O est facturé, et ici pour 6,6TB de données récupérées il fallait compter environ 500€.

Une solution aurait aussi pu être d’effectuer du Forensics directement dans le Cloud d’Amazon en déployant un serveur permettant de faire les acquisitions et analyses, mais encore une fois cela n’aurait pas été sans frais, et ce n’était pas conforme à la demande initiale du client (récupérer les données en locale).

[Forensics] L’histoire de Greendale
Thomas Chopitea, DFIR Google Sécurité, @tomchop_
TLP: [WHITE]

Il s’agit d’une mise en situation à l’aide d’un scénario fictif, dans lequel une université est victime d’un phishing qui a potentiellement fait des victimes au sein de l’université. Ce scénario permet de présenter divers outils OpenSource développés par Google pour effectuer une analyse Forensics :

Tout d’abord « GRR » (prononciation « gueure ») agent de Forensics deployable à distance, permettant de collecter des données (fichiers ou artefacts) sur des machines cibles.
Utilisation de Plaso (anciennement Log2time) permettant de parser récurssivement tout un système de fichier pour produire une timeline,
Timesketch (pouvant s’apparenter à un frontend de « grep ») pour avoir une visualisation de la timeline de l’incident.
DfTimewolf, qui est un outil qui permet de lier GRR/Plaso/Timesketch entre eux.
Le dernier outil présenté était Turbinia. Il permet de déployer, gérer et exécuter des outils d’analyses Forensics dans le cloud.

Lien : https://www.youtube.com/watch?v=xVQ_OEqX1TY

[Forensics] Investigation numérique sur l’annuaire Active Directory avec les métadonnées de réplication
Léonard Savina, Chercheur sécurité ANSSI, @ldap389
TLP: [WHITE]

Présentation de l’outil ADTimeline développé par l’ANSSI, permettant une analyse Forensics en utilisant les informations présentes dans les méta-données de réplication des AD. Ces méta-données contiennent des informations comme son nom, sa date de dernière modification, sa version… L’outil développé permet ainsi de sélectionner un annuaire à considérer, de générer une timeline en triant les métadonnées par ordre chronologique et de générer en sortie un fichier au format .csv. L’utilisation de cet outil peut être faite en mode « en ligne » ou « hors ligne ».

Lien : https://www.ssi.gouv.fr/publication/investigation-numerique-sur-lannuaire-active-directory-avec-les-metadonnees-de-replication-outil-adtimeline/

[Retex] Retour d’expérience lors d’investigation iOS
Paul Rascagnères, chercheur en sécurité chez Cisco Talos, @r00tbsd
TLP: [WHITE]

Cette dernière présentation, reprenait les différents défis auxquels font face les analystes lors d’investigations Forensics sur un système iOS. L’iOS est un système Unix très sécurisé, composé de différentes couches avec aucun accès direct à la racine du filesystem. Tout est sandboxé et les applications ne peuvent donc pas lire des contenus d’autres applications. La racine d’un système iOS est en readonly. On apprend lors de cette présentation qu’il est dans la majorité des cas nécessaire d’avoir jailBreaké un système iOS avant de pouvoir y effectuer un dump mémoire du système, et donc de commencer une investigation. Il existe cependant une alternative nommée « Frida » qui permet une analyse sur un système non-jailbreaké. Mais il faut avoir installé au préalable cette application sur le système iOS concerné (ce qui n’est pas forcément le cas). Si la version de l’iOS est trop récente et ne permet donc pas un jailbreak, on effectue alors un « freeze » du système et on attend la sortie d’un nouveau jailbreak pour permettre l’investigation ; cette dernière est donc repoussée jusqu’à la prochaine version d’iOS jailbreakable. Les principaux outils permettant de faire une investigation sur un système iOS rooté sont alors « IDA Pro » ou « Hopper » pour effectuer des analyses de codes, et « Burp » pour l’analyse réseaux.