Le CERT-XMCO a participé à la 5ème édition de la CoRI&IN, la Conférence sur la Réponse aux Incidents & l’Investigation Numérique. Cet événement, qui se tient depuis 2016, en marge du FIC (Forum International sur la Cybersécurité) rassemble les experts de la cybersécurité, mais aussi du juridique ou de l’investigation, autour des problématiques de la réponse aux incidents et de l’investigation numérique.
Avec 400 personnes réunies à cette occasion, cette nouvelle édition de la CoRI&IN a été un franc succès. Vous trouverez ci-dessous le compte-rendu des différentes présentations réalisée au cours de cette journée.
Nous tenons à remercier les membres du CECyF, l’association qui organise chaque année cette conférence.
L’investigateur, le Smartphone, et l’application WhatsApp
CERT-XLM / Excellium (Guénaëlle De Julis)
Guénaëlle De Julis du CERT-XLM (Excellium) est revenue sur une mission d’investigation inforensique d’un terminal mobile. L’objectif de l’investigation était d’extraire un maximum d’informations de la messagerie WhatsApp.
La présentation s’est articulée autour de trois axes majeurs :
- L’acquisition des données
- La structure des bases de données de l’application
- Comment corréler un grand nombre d’informations de bases de données via une bibliothèque de bigdata (python pandas)
La conférence a commencé par la première étape de l’analyse inforensique : L’acquisition des données à analyser. L’application WhatsApp stocke ses données dans des bases de données Sqlite, mais la manière de les stocker diffère entre les plateformes Android et iOS.
Dans le cadre de cette investigation, seule la plateforme Android a pu être étudiée. Les éléments présentés par la chercheuse concernant WhatsApp pour IOS sont théoriques, et n’ont pas pu être validés.
En ce qui concerne l’acquisition de données WhatsApp sur iOS, un rappel important est fait : Le chiffrement de bout en bout (End-to-end encryption) proposé par l’application ne s’applique qu’au transport du message, pas à son stockage.
Une fois le message transmis, il est possible pour le terminal de stocker ces informations à des fins de backup sur iTunes.
Il est également possible via l’utilitaire iExplorer de récupérer les données de l’application, dont les conversations et les contacts en clair.
Ces derniers sont stockés dans les chemins suivants :
- group.net.whatsapp.Whatsapp.shared/ChatStorage.sqlite
- group.net.whatsapp.Whatsapp.Shared/Contacts.sqlite
Il est possible d’accéder aux documents stockés au chemin suivant : net.whatsapp.Whatsapp/Documents.
Enfin, si le périphérique est rooté / jailbreaké, il est possible d’accéder directement au système de fichiers pour obtenir des artefacts supplémentaires (journaux d’évènements, bases de données temporaires…)
L’application WhatsApp sur Android stocke également des sauvegardes de WhatsApp, mais ces dernières sont chiffrées (AES-256). Ces sauvegardes chiffrées sont disponibles sur Whatsapp/Databases/msgstore.db.crypt{0-12}.
La clef de déchiffrement de la base de données est cependant disponible en clair sur le terminal (ce qui nécessite un accès direct au système de fichier et donc un accès “root”) à l’endroit suivant : data/com.whatsapp/files/key.
Les bases de données de l’application; sont disponibles aux endroits suivants :
- data/com.whatsapp/databases/wa.db
- data/com.whatsapp/databases/msgstore.db
2) La structure des bases de données
La structure des bases de données varie largement entre les deux plateformes. L’évolution distincte des 2 versions de l’application est probablement due à des impératifs de performances de l’application, qui a nécessité des adaptations spécifiques à chacune des deux plateformes dominantes sur le marché.
Sur Android, les conversations sont stockées dans la base msgstore.db.
Cette dernière est composée de 25 tables (même si l’essentiel des informations est dans la table messages).
Les contacts sont quant à eux stockés dans la base wa.db.
Ces contacts sont liés au carnet d’adresses et l’essentiel est stocké dans wa_contacts.
Lors de l’analyse des messages, chaque entrée représente un message vers un destinataire (représenté par un identifiant nommé JabberId). Ainsi dans une conversation de n personnes, pour un message envoyé par l’utilisateur, on retrouvera n entrées.
Les documents téléchargés sont stockés dans WhatsApp/Media et sont centralisés sur les serveurs WhatsApp.
Il est possible de retrouver les messages supprimés de l’application en déchiffrant une sauvegarde de l’application ou en allant vérifier les journaux d’évènements.
Sur iOS l’ensemble des conversations sont stockées dans la base de données ChatStorage.sqlite.
Cette dernière se découpe en 18 tables et les messages sont situés dans la table ZWAMESSAGE.
Cependant, afin d’avoir toutes les informations, il est nécessaire de recouper les informations disponibles dans cette table avec celles issues des tables suivantes :
- ZWAMESSAGEINFO (indique qui a reçu/lu les messages envoyés de l’utilisateur)
- ZWAMEDIAITEM (contient les chemins vers les miniatures des contenus multimédias de l’application)
- ZWAGROUPINFO (contient le JabberId du créateur du groupe)
- ZWAGROUPMEMBER
Chaque message contenu dans ChatStorage.sqlite possède un identifiant sous la forme du champ Z_PK. Les messages supprimés sont définis par les entrées manquantes dans la liste de Z_PK.
Il semblerait que ces différences d’implémentations (structure des tables, valeurs…) permettent de récupérer plus d’informations sur Android.
3) Analyse des données
Afin d’analyser ces bases de données, Mme De Julis a décidé d’utiliser le langage de script Python avec la bibliothèque de data sciences pandas
Cette bibliothèque permet de travailler avec des sets de données de manière naturelle grâce à une couche d’abstraction (DataFrame).
Il a été possible pour l’analyste de :
- identifier les messages manquants (en une dizaine de lignes Python).
- associer les périodes durant lesquelles ces messages sont été supprimé.
- associer les messages avec leurs auteurs respectifs (en réalisant des jointures sur plusieurs tables).
- retrouver les opérations de gestion des groupes.
Enfin, l’analyste a terminé sa présentation en indiquant qu’il est possible d’obtenir plus d’informations avec un accès complet au système de fichier, mais qu’il est déjà possible de récupérer un nombre d’informations satisfaisant via les BDD accessibles sans accès root.
Gestion d’Incidents et investigations en environnement Cloud
PwC (Philippe Baumgart et Fahim Hasnaoui)
Les deux consultants sont intervenus pour présenter un panorama large des problématiques pouvant être rencontrées en matière de réponse sur Incident dans des environnements Cloud.
La présentation a débuté par un rappel des challenges pour les entreprises :
- La CMDB est beaucoup plus complexe à maintenir dans les environnements multicloud provider, et engendre du Shadow IT.
- Il existe une grande hétérogénéité des fonctions de sécurité disponibles chez chaque fournisseur de cloud.
- Les utilisateurs interprètent de manière erronée la notion de “cloud sécurisé”, ce qui résulte en de mauvaises pratiques aboutissant à des incidents.
- La localisation des données est floue
- Les contrats de service sont rigides (SLA, …)
- Les événements de sécurité sont différents dans les mondes du on-premise et du cloud
Deux cas concrets d’incident ont ensuite été présentés (1 cas de ransomware et 1 cas d’exfiltration de données personnelles depuis une base de données).
Les consultants se sont appuyés sur ces exemples d’incident pour présenter le concept des attaques “intra-cloud provider”. Dans certaines configurations, un serveur peut ne pas être exposé publiquement sur Internet, mais reste exposé aux yeux des autres serveurs instanciés au sein du Cloud. Ainsi, les attaquants n’ont qu’à instancier un serveur chez le fournisseur, afin de lancer des scans depuis le réseau privé interne du Cloud. Ces scans leur permettent dès lors d’identifier des services sensibles non exposés sur Internet, mais exposés sur le réseau local du fournisseur de Cloud.
Enfin, plusieurs outils utiles dans le cadre d’une intervention ont été présentés :
- Office 365 Extractor (développé par PwC NL)
- aws_ir
- PMapper
En conclusion, les solutions cloud offrent des avantages et des inconvénients en matière de réponse à incident :
- Si l’on est bien préparé, il est généralement plus simple et plus rapide d’accéder aux informations de base qui sont déjà supervisées dans les environnement Cloud (vs on-premise)
- Il existe une grande hétérogénéité dans ce qui peut / doit être fait pour aller plus loin (entre chaque cloud provider)
Et surtout, comme dans le monde du on-premise, la réponse à incident doit être anticipée pour être efficace (définition des méthodologies de collecte et d’analyse, activation des fonctionnalités de supervision avancées souhaitées …).
Fuite de données & Credential Stuffing
OVH Cloud (Sébastien Mériot, @smeriot)
Sébastien Mériot, du CSIRT-OVH est ensuite intervenu afin de présenter un phénomène de masse bien connu de la majorité des experts en sécurité, mais sur lequel peut de grands acteurs ne communiquent : l’utilisation des « Data Breach » dans le cadre des attaques de « Credential Stuffing ».
Il a ainsi déroulé la chronologie du scénario.
Des attaquants compromettent le serveur d’une société, et parmi les actions entreprises pour lui nuire, vont à cette occasion (de manière opportuniste) dérober la base contenant les comptes utilisateurs des clients de l’entreprise et leurs mots de passe. Ces données peuvent généralement être relativement facilement monnayées. En effet, en fonction de l’activité de l’entreprise, un compte client peut disposer d’un solde ou d’un crédit, d’un nombre de points de fidélité donnant droit à des avantages, peut être associé à un n° de carte bancaire pré enregistré, …) : autant de caractéristiques donnant de la valeur à un compte dérobé.
Les données ainsi dérobées ne sont cependant pas mises à disposition de manière immédiate. En effet, les mots de passe sont généralement stockés dans ces bases sous forme de condensat (hash) “salés”. Les attaquants se doivent donc au préalable de réaliser des attaques de type Bruteforce sur ces empreintes, afin de retrouver le mot de passe en clair.
À titre d’exemple, le réseau social LinkedIn avait été victime d’une intrusion début mai 2012. C’est seulement 4 ans plus tard, fin mai 2016 que les données ont été mises en vente sur le Darknet.
Selon l’intervenant, avec l’avènement des GPU, cette durée tend cependant à se réduire.
Un article publié par Alice Henshaw en juin dernier (https://hackernoon.com/20-hours-18-and-11-million-passwords-cracked-c4513f61fdb1) montrait que pour 18$ seulement, la journaliste avait été en mesure de casser en 20 heures les mots de passe de 11 millions des 14 millions de comptes présents dans un dictionnaire.
Une fois le mot de passe cassé, une autre façon pour les attaquants de monétiser un compte compromis est d’essayer d’identifier les autres services accessibles avec les mêmes identifiants et mots de passe. C’est à ce moment qu’on retrouve les attaques de type Credential Stuffing. Pour réaliser ces tests à grandes échelles, différents outils sont disponibles aux attaquants :
- SentryMBA
- OpenBullet (intégration avec Selenium pour reproduire le comportement d’un humain derrière son navigateur)
- Storm
- Snipr (permet de tester des combinaisons d’identifiants / mots de passe sur des serveurs de messagerie type IMAP, SMTP …)
- Private Keeper
- Woxy
Chacun d’eux a ses avantages et ses inconvénients. Ils prennent en entrées une liste comptes et de mots de passe, une configuration adaptée au site ciblé :
- Le(s) champ(s) à du formulaire à renseigner,
- L’action à réaliser en cas de succès (comme la réinitialisation du mot de passe),
- et une liste de proxy (utilisé pour complexifier l’identification et le blocage de l’attaque).
À titre d’exemple d’attaque de réutilisation des identifiants / mots de passe, on peut rappeler que quelques jours/semaines après la divulgation de la compromission des serveurs de LinkedIn, les comptes Twitter et Pinterest de Mark Zuckerberg, le fondateur de Facebook avaient eux-mêmes été compromis. En effet, M. Zuckerberg utilisait le même identifiant et le même mot de passe sur ces 3 sites…
La présentation a ensuite été l’occasion d’analyser différentes statistiques liées à des cas concrets d’attaques de bourrage de mots de passe, et les mesures de remédiations adoptées en conséquence.
En effet, OVH en tant qu’acteur majeur, est souvent ciblé par ce type d’attaque. Différentes statistiques issues de ces attaques ont été présentées : les principaux AS depuis lesquels proviennent ces attaques, et les principaux User-Agent observées. Pour lutter contre ces attaques, OVH a mis en place depuis plusieurs années différents mécanismes : formulaire HTML dynamique pour le modifier à chaque visite de la page, analyse comportementale du client, réputation de l’IP, … Ces mesures permettent de déjouer 99,996 % des tentatives d’attaques.
Enfin, la présentation s’est achevée sur l’aspect financier de ces attaques. Selon lui, les acteurs (principalement localisé en Afrique) migrent du phishing vers le Credential Stuffing. Une fois les nouveaux comptes identifiés, les attaquants peuvent les revendre sous les formes suivantes :
- vente de comptes (ex. Netflix)
- faux comptes sur les réseaux sociaux pour diffuser des fakenews
- revente de compte de cloud-provider
- vente des comptes disposant d’un solde positif (location d’instance, envoi massif de spam…)
- revente des serveurs sous forme de VPS, mise à disposition de services éphémères (RDP/SSH) afin de faciliter les attaques ciblées depuis une infrastructure inconnue
Injection et discrétion avec Pastebin
LastInfoSec (François Normand)
Après avoir rappeler le principe de Pastebin, l’intervenant a présenté plusieurs cas concrets d’utilisation à des fins malveillantes de la plateforme accessible publiquement.
On peut trouver sur Pastebin tout ce qui ne devrait pas être publié d’après la FAQ…
Concrètement, il a montré qu’on pouvait trouver sur cette plateforme les données suivantes :
- des fichiers encodés en Base 64
- des scripts JS ou PowerShell
- des commandes devant être exécutées par le poste compromis d’une victime
- ou encore des fichiers de configurations de malwares
Après avoir illustrés avec 2 scénarios concret les cas d’utilisation de Pastebin par les attaquants, il a rappelé qu’il était complexe pour les entreprises de lutter contre ces nouveaux usages adoptés par les attaquants. En effet, le simple blocage de Pastebin ne résout par le problème, car il existe de nombreuses alternatives (Gist, Hastebin, …).
Il recommande donc de mettre en place une défense multi-couches, couplant les éléments suivants :
- une sonde réseau + règles de détection dédiées
- de l’analyse en sandbox
- un EDR
- un SIEM capturant les traces générées dans le SI, et une sortie vers Internet au travers d’un proxy
A year hunting in a bamboo forest
Aranone Zarkan et Sébastien Larinier
Cette présentation ayant été classifiée TLP:AMBER, aucune information la concernant ne peut être communiquée.
Investigations numériques avec le projet TSURUGI LINUX
Open Minded (Giovanni « Sug4r » Rattaro, @sug4r7)
La conférence a débutée par une brève présentation par Giovanni de la genèse du projet et de l’équipe en charge. Cette dernière est composée en particulier de membre des forces de l’ordre, qui orientent les choix de développement de Tsurugi.
Ce projet Open-Source composé de plusieurs éléments :
- Tsurugi Linux : une distribution Linux (64 bits) orientée réponse à incident
- Tsurugi Acquire : une distribution Linux « live » très légère (32 bits), dédiée à l’acquisition de disque
- Bento : une boîte à outils, dédiée à la réponse à incident en environnement Windows
A l’instar de la distribution Kali pour le monde de l’offensif, l’objectif du projet est de fournir un ensemble d’outils pré-configurés afin de faciliter le travail d’un investigateur.
Par exemple, Tsurugi Linux repose sur la version LTS d’Ubuntu, et peut être utilisée aussi bien pour faire du live-forensics qu’elle ne peut être installée de manière pérenne sur le poste d’un analyste.
Afin de garantir l’intégrité des disques manipulés au cours d’une investigation, le noyau Linux utilisé a été recompilé afin d’adapter sa configuration au impératif du DFIR, de manière par exemple à rendre impossible de monter une image autrement qu’en « lecture-seule ».
Autre exemple illustrant la volonté des développeurs du projet de simplifier la vie des analyses, les menus sont organisés de manière à respecter les grandes phases d’une investigation. On peut ainsi retrouver l’acquisition des données, la génération des empreintes, la création de la timeline, …
Etant utilisée par les forces de l’ordre, la distribution inclut également des outils spécifiques permettant d’analyser les images (reconnaissance d’images, analyse de vidéos).
Enfin, l’intervention s’est conclue avec les nouveautés attendue durant 2020, avec entre autre la publication courant Q3 d’une nouvelle version reposant sur Ubuntu LTS 20 et la migration de Tsurugi Acquire sur Debian.
Analyse mémoire de routeur CISCO IOS-XR 32bits
ANSSI (Solal Jacob, @arxsys)
Ces équipements étant au coeurs de nos système d’information, l’ANSSI s’intéresse aux routeurs commercialisés par les principaux constructeurs, à commencer par Cisco. Cette présentation a été l’occasion pour Solal Jacob de détailler son travail de recherche sur le système d’exploitation Cisco IOS-XR 32bits, équipant une partie des routeurs Cisco.
L’OS est basé sur QNX 6.4, qui appartient depuis 2010 à la société Blackberry. Il est principalement utilisé dans le monde de l’embarqué. Le code source de cet OS, initialement fermé a été temporairement mis à disposition en open-source (vers 2007). Il n’est cependant plus accessible depuis le rachat par Blackberry.
L’OS dispose d’une architecture de type “micro-kernel”. Ceci le dote les propriétés suivantes :
- Tolérance aux pannes (comme toute applications, les drivers sont exécutés en userland pour limiter l’impact d’une erreur, fault-tolerence)
- Surface d’attaque réduite
- Conforme à la norme POSIX
Malgré quelques CVE, peu d’information sont disponibles sur la structure du système. Le chercheur a donc principalement réalisé un travail de reverse engineering pour comprendre son architecture et son fonctionnement.
Il a commencé par évoquer la problématique de l’acquisition de la mémoire du routeur via le développement d’un outil dédié, relativement simplifié par le fait que toutes les applications tournent en userland, donc pas de driver à installer comme sous Windows ou Linux.
Ensuite à été évoqué la problématique d’envoyer l’image mémoire générée. Deux options se présentaient au chercheur : développer une nouvelle pile TCP/IP lui permettant d’envoyer via le réseau son dump vers un serveur de collecte ; ou utiliser la pile TCP/IP mise en oeuvre par Cisco. Afin de ne pas nuire à la stabilité de l’OS en exposant 2 piles en parallèle, le choix a été fait d’utiliser la pile Cisco déjà en place.
Enfin, la problématique de l’analyse de la structure de l’image mémoire a été adressée. Cette étape était particulièrement importante, puisqu’il s’agit du préalable à l’analyse des données disponibles.
Grâce à ce travail, différentes informations ont pu être extraites de la mémoire du routeur, telles que : la création d’un graphe de dépendance entre les services.
A noter, l’ensemble du travail de recherche de Solal sera prochainement mis à disposition par l’ANSSI. Son framework porte le nom d’ “Amnesic Sherpa”.
Mais qui est vraiment responsable de ce préfixe d’adresses IP
Afnic (Stéphane Bortzmeyer, @bortzmeyer)
Cette conférence de Stéphane Bortzmeyer porte sur les préfixes d’adresses IP laissés à l’abandon (aussi appelés préfixes du marais) et les problématiques associées à leur gestion.
Qui est responsable d’un préfixe d’adresse IP d’une société ayant fermé depuis des années ? Que faire quand une personne souhaite s’accaparer un préfixe dont il n’est pas le titulaire ?
Contexte
Depuis des années, il y a une pénurie d’IPv4. Ces dernières deviennent de plus en plus dures à obtenir alors que la transition vers IPv6 tarde à être faite.
De ce fait, les personnes essayent d’obtenir des adresses IP via des préfixes abandonnés tels les préfixes dits “du marais” qui ont été enregistrés avant la mise en place des RIR (registres internet régionaux).
Rappel sur comment sont alloués les IP
Les préfixes IP sont alloués par les RIR (entités comme le RIPE NCC en Europe) après vérification des possesseurs. Ces RIR possèdent leurs propres bases de données contenant ces informations.
Ces dernières sont disponibles via les protocoles whois et RDAP.
Les routes sont ensuite annoncés par les opérateurs Internet via les AS (Protocole BGP) après vérification des bases des RIR.
Ensuite, les registres de route IRR se mettent à jour (maintenus par divers acteurs)
Cas n°1 : Le préfixe 143.95.0.0/16
Ce préfixe d’adresse IP est un préfixe affecté en 1990 à la société Athenix basée en Californie. L’entreprise a fait faillite depuis. (Préfixe du marais donc).
En 2008, une société nommée Athenix est créée dans le Massachusetts. Ces derniers parviennent à récupérer le préfixe IP.
Bortzmeyer propose quelques outils d’investigation sur ces questions :
- Les bases whois et RDAP. Cependant, il arrive qu’il manque certains détails publics tel l’historique. A noter que le protocole RDAP renvoie des données au format JSON ce qui peut aider l’automatisation.
- Les outils RIPE Stat et RIPEGlass
- L’outil nicinfo permet de récupérer les informations de bases RDAP et de les mettre en forme.
Cas n°2 : Un préfixe d’IP
Dans ce cas, Bortzmeyer s’est intéressé aux préfixes d’adresses IP sud-africaines.
Ce dernier a remarqué qu’un grand nombre de préfixes étaient en train d’être détournés, non pas par une annonce BGP mais par la création d’objets dans le registre de routes RADB.
Après vérification, il semblerait que ces informations proviennent de l’opérateur de transit Cogent qui aurait été trop indulgent dans ses vérifications.
Afin de démontrer ces annonces suspicieuses, Stéphane Bortzmeyer a présenté des outils et des conseils pour l’investigation :
Tout d’abord, pour investiguer, il est possible d’utiliser le protocole RDAP ou whois mais il faut être vigilant à la passerelle utilisée car cela peut divulguer des informations sur l’investigation en cours.
Il faut (lorsque cela est possible) interroger directement le RIR concerné (à l’aide du flag -h pour la commande whois) ou éventuellement utiliser l’outil RIPESTAT.
Il existe des mécanismes de vérification d’authenticité à l’image du DNSSEC. Il existe une chaîne de certification pour prouver la titularité d’une ressource nommé la RPKI avec les documents ROA qui permettant d’autoriser un AS à annoncer un préfixe donné.
En utilisant whois, Bortzmeyer a démontré que pour certaines IPs, il y avait deux AS annonçant une route. L’une des entrées appartenait au RIPE et la nouvelle entrée appartenait au NTT (annoncé par l’AS 8100).
Bien que ce genre de cas peut arriver, l’entrée en elle même était suspicieuse, d’autant plus qu’une centaine d’objets avaient été détournés de cette manière.
DFIR-ORC
ANSSI (Jean Gautier, @_jeanga_)
À travers cette conférence, Jean Gautier a présenté l’outil de collecte d’informations utilisé lors des missions de réponse à incident : DFIR-ORC (pour Digital Forensics Incident Response Outil de Recherche de Compromission).
Ce dernier permet de collecter :
- les métadonnées des systèmes de fichiers
- les diverses bases de registres
- les journaux d’évènements
- les informations relatives aux connexions réseaux
- les informations relatives aux processus et aux services
- les informations générées par des outils tiers (autorun, winpmem…)
Les principes clés de l’outil sont les suivants :
- Limiter au maximum les opérations d’écriture sur le système
- Réduire au maximum l’impact sur le système et le réseau (limitation de % de CPU, de Mémoire, …)
- Privilégier la stabilité des opérations
- Être facile à déployer (1 seul binaire pour toute les versions de Windows allant de XP SP2 à 2019)
- Être modulable au possible
L’outil est pensé comme un exécutable à déployer de manière centralisée, capable d’agréger les résultats sur un serveur de collecte centralisé.
Les données collectées sont compressées dans un fichier 7Zip chiffré en PKCS#7 (multi-destinataire).
Le transfert des données peut se faire via l’utilisation du protocole BITS (HTTP, SMB), afin d’optimiser la charge sur le réseau.
L’utilitaire va récupérer les informations dans la MFT (Master File Table) permettant ainsi de récupérer des fichiers verrouillés (voire supprimés) via du metadata carving.
L’utilitaire n’utilise pas de pilote, lui permettant d’être exécuté en userspace.
ORC peut récupérer les sauvegardes du système (VSS) et supporte les format d’export Apache Orc et Apache Parquet. Ces formats qui correspondent à des base de données, permettent d’aller plus loin que l’utilisation classique d’un CSV dans l’analyse des données générées par ORC.
L’utilitaire ré-implémente certaines fonctionnalités centrales, telles qu’un parseur NTFS ou un parseur de base de registre afin de réduire le nombre d’outils à embarquer :
- NTFSinfo, FATinfo : pour obtenir des informations du système de fichiers
- GetSectors : pour obtenir le découpage du disque (MBR, VBR, Slack space…)
- GetThis : pour collecter des fichiers sans se faire bloquer par les ACLs.
- GetSample
- …
DFIR ORC peut également gérer les différents chemins désignant un disque physique (\.HardDiskVolume1, \.PhysicalDriveDisk0, …)), afin de choisir l’accès le plus fiable dans le contexte du système sur lequel il est exécuté (utilisation de GPT, de Bitlocker, …)
Il est possible pour l’analyste de mettre en place des conditions d’arrêt pour l’analyse (notamment un TTL) et de gérer la qualité de service.
Le workflow d’utilisation est le suivant :
- Création de fichier de configuration
- Génération de tâches de collecte
- Génération des fichiers collectés
- Renvoi des fichiers vers un serveur de collecte.
Un point d’amélioration soulevé a été lors de l’arrêt d’une analyse, il n’est pas encore possible de reprendre au point d’arrêt. L’analyste doit relancer une analyse.
DFIR ORC est disponible en Open Source à l’adresse suivante : https://dfir-orc.github.io/.
L’outil a également été présenté dans un épisode du Podcast NoLimitSecu : https://www.nolimitsecu.fr/dfir-orc/.
Réponse à incidents suite à l’exploitation d’une vulnérabilité sur un VPN Pulse Secure possiblement par APT5 : retour d’expérience
Deloitte (Mathieu Hartheiser et Maxence Duchet)
À travers ce retour d’expérience, les consultants de Deloitte sont revenus sur une mission de réponse à incident faite suite à l’annonce de la vulnérabilité référencée CVE-2019-11510 à la BlackHat.
Les consultants ont cherchés si des comptes (locaux ou AD) avaient fuités, si des comptes AD avaient été utilisés ou pire, si des scripts de démarrage ont été déployés sur les clients VPN.
Les consultants ont commencé leur mission en séparant le S.I. de leur client en deux zones : Une zone SI Gestion (avec les logs AD) et une zone dédiée à l’appliance Pulse Secure.
Pour pouvoir commencer rapidement les analyses, les logs Azure AD et les journaux centralisés dans Splunk ont été analysé pour vérifier l’activité des attaquants. Après vérification, 900 comptes avaient été impactés par la vulnérabilité.
En parallèle des preuves de concept ont été testées en interne pour qualifier l’étendue des dommages envisageables. Ce dernier a démontré que les cookies et les identifiants étaient disponibles en clair. Enfin, une vérification a été faite au niveau des autres BU mondiales en ce qui concerne l’application des correctifs. Ces dernières n’avaient pas appliqué les correctifs de sécurité.
La remédiation s’est faite en trois étapes, réinitialisation des mots de passe, recherche de marqueurs d’exploitation (guacamole) et application des correctifs au niveau des différentes BU.
