Retour sur l’édition 2019 de CoRI&IN

Retour sur l’édition 2019 de CoRI&IN

Le CERT-XMCO a participé à la 4ème édition de CoRI&IN, 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.

Cette année, c’est le MACC’S (Métropole Auditorium pour la Culture, les Congrès et les Séminaires), situé à Villeneuve-d’Ascq (près de Lille), qui a accueilli les 350 participants.

MACC.jpg
Comme les années précédents, c’est le Cecyf (Centre Expert contre la Cybercriminalité Français), et plus particulièrement Éric Freyssinet qui était à la baguette, et qui nous ont offert une journée très enrichissante.

Au total, cette conférence a regroupé 9 présentations, dont vous retrouverez un résumé ci-dessous. Malheureusement, les présentations des conférenciers ne sont pas encore toutes disponibles.

La montée des logiciels malveillants destructifs, par Thomas Roccia

logicielmalveillant.jpg

Cette première présentation nous a été présentée par Thomas ROCCIA, chercheur en sécurité chez McAfee France. Celui-ci nous a présenté l’historique, le fonctionnement et les prévisions au sujet des logiciels malveillants destructifs.

Il a défini un logiciel malveillant destructif comme un logiciel ayant pour objectif de provoquer un déni de service, en détruisant les données ou en visant directement l’équipement physique.

Le premier logiciel malveillant de ce type, qui nous a été présenté, date de 1974 et s’appelle Rabbit. Ce dernier agissait comme une fork bomb, rendant instable le système d’exploitation. Puis, en remontant jusqu’à nos jours, il a présenté, entre autres, Jerusalem (infection de tous les exécutables du système – 1987), Michelangelo (suppression du secteur de démarrage – 1991), CH Virus (suppression de la mémoire flash du BIOS – 1998), Shamoon (suppression des données du disque, puis du « MBR » (Master Boot Record) – 2012), Destover (impliqué dans le hack de Sony – 2014), Industroyer (suppression des clés de registre, et qui a mis hors service le système électrique ukrainien – 2016).

Il a également présenté, plus en détails, les logiciels malveillants, tels que NotPetya  (un pseudo-ransomware puisque les données sont supprimées une fois la rançon payée, et qui a été une première « supply-chain attack » massive), Triton (un malware agissant sur les systèmes de contrôle des équipements Schneider Electric, en les empêchant de lever des alertes) qui aurait impacté des vies humaines, OlympicDestroyer (utilisé pour cibler les serveurs des Jeux Olympiques) et ShamoonV3 (dont l’action était de réécrire les fichiers afin d’empêcher leur récupération et dont le but était de mettre en avant des revendications idéologiques).

Selon lui, on retrouve 5 actions utilisées par les logiciels destructifs :
1. Le wipe : suppression de données par réécriture multiple, suppression de secteur de démarrage
2. Le chiffrement : pour empêcher l’accès à l’information contenue dans les fichiers
3. L’anti-forensic : suppression des journaux, des sauvegardes… pour retarder la détection et la remise en l’état du système
4. L’impact physique : modification du comportement interne des cibles, sabotages
5. Le déni de service

De plus en plus de ces logiciels utilisent des mécanismes de propagations (récupération d’identifiants via psexec ou mimikatz, utilisation d’exploit comme EternalBlue) afin d’avoir un impact plus conséquent, une fois un système infecté.

Ces informations ont permis au chercheur de classer les logiciels malveillants dans 6 catégories :
1.  Les leurres (Hermes, CyanWeb)
2. Les botnets destructeurs (Mirai)
3. Les logiciels disrupteurs (WannaCry)
4. Les pseudo-ransomwares (NotPetya)
5. Les Wipers (NotPetya, Shamoon)
6. Les destroyers physiques (Triton)

Enfin, avant d’aborder le futur, quelques mesures pour permettre de limiter l’impact de ces logiciels malveillants ont été présentées : la nécessité de réaliser une segmentation (tant au niveau réseau qu’au niveau utilisateur) pour limiter les capacités des mécanismes de propagation, la nécessité de connaitre les points de pivots du SI ou encore l’obligation d’avoir un plan de réponse à incident (et de le tester régulièrement).

Concernant le futur, le chercheur voit une accélération du développement de ces logiciels, notamment car ils sont de plus en plus utilisés pour faire peser une pression financière ou politique sur les organisations. Celui-ci s’attend aussi à l’utilisation croissante et récurrente des « supply-chain attack » comme vecteurs d’infections et à l’émergence d’attaques ciblées visant des infrastructures critiques comme Triton.

Goblin Panda : La Chine en Asie du Sud-Est, par Sébastien Larinier

goblinpanda.jpg

Malheureusement, cette conférence a été catégorisée comme étant « TLP AMBER » ce qui nous empêche d’en partager les détails. Toutefois, n’hésitez pas à contacter le conférencier si vous désirez plus d’informations.

Investigation dans AmCache, par Blanche Lagny

SUPPORT

amcache.jpg

Cette conférence avait pour objectif de présenter un artefact peu connu, utilisable dans le cadre d’investigations numériques sous Windows, appelé AmCache.

Cet artefact, qui recense les preuves d’exécutions de binaires Windows et d’installation de programmes est disponible à partir de Windows 7 et de Windows 2008 R2. Il est utilisé dans le cadre du service de compatibilité d’applications de Windows et peut servir à trouver des preuves d’exécutions de binaires malveillants.

Les travaux de Mme LAGNY visaient à proposer une documentation de référence sur cet artefact, qui est consultable ici.

La conférence a débuté par la présentation du fonctionnement d’AmCache, qui diffère en fonction des versions de Windows.

Sur Windows 7 (et versions de Windows Server équivalentes), lors de l’exécution d’un exécutable, celui-ci met à jour un fichier (RecentFileCache.bcf). Puis, tous les jours, une tâche planifiée s’exécute, et vide le contenu de ce fichier dans un fichier XML (nommé de la forme suivante : AEINV_WER_{GUID}_timestamp.xml).

Sur Windows 8 (et versions de Windows Server équivalentes), lors de du lancement d’un exécutable, celui-ci met à jour un fichier (Amcache.hve). Puis, tous les 3 jours, une tâche planifiée démarre, et vide le contenu de ce fichier dans un fichier XML (nommé de la forme suivante : AEINV_WER_{GUID}_timestamp.xml) ainsi que dans un fichier binaire (PropCache.bin), si l’exécutable est un pilote.

Enfin, sur Windows 10 (et versions de Windows Server équivalentes), lors de l’exécution d’un exécutable, celui-ci met à jour un fichier (Amcache.hve). Le fichier XML n’existe plus.

Afin de démontrer l’utilité de l’artefact, Mme LAGNY a déroulé 3 scénarios fictifs, afin de présenter les informations qu’il est possible de retrouver grâce à l’AmCache.

Dans le premier scénario, celle-ci parvient à récupérer le nom d’un fichier exécuté supprimé, son chemin réseau, ainsi que son empreinte SHA-1.

Dans le second scénario, elle réussit à retrouver le nom d’un fichier exécuté, son chemin réseau, son empreinte SHA-1, mais aussi le répertoire dans lequel le logiciel malveillant et le suivi de celui-ci.

Enfin, dans le troisième scénario, elle parvient à retrouver un pilote malveillant et son chemin réseau.

L’AmCache est un artefact qui peut se révéler très puissant, mais qui est complexe à utiliser (notamment à cause de sa variation non pas avec l’OS, mais avec les versions de DLL).

Memcached ou quand votre backbone devient folle, par Sebastien Mériot

memcached.jpg
Sébastien MERIOT, responsable du CSIRT d’OVH, est revenu sur la vulnérabilité ayant affecté Memcached en mars 2018, qui a permis une attaque DDoS de grande ampleur.

Étant donné la position d’OVH, avec plus d’un million de clients et quasiment autant de serveurs, il est naturellement plus compliqué de réagir face à ce type d’attaque. Cette conférence a ainsi permis aux participants de mieux comprendre comment se passe une session de réponse à incident chez un « Cloud Provider ».

La problématique initiale posée par Memcached provenait de la capacité de ce dernier à obtenir un facteur d’amplification très élevé. Sébastien MERIOT en a profité pour rappeler que le facteur d’amplification est la valeur par laquelle la taille des paquets d’origine est multipliée pour donner la taille du paquet de réponse. La technique est classique : un attaquant forge un paquet avec l’adresse IP de sa victime en source (usurpant son identité) afin que la réponse soit envoyée à cette dernière. Le but de l’attaquant est alors de trouver le facteur d’amplification le plus élevé possible afin d’obtenir une réponse la plus lourde possible pour un paquet émis le plus petit possible. À titre d’exemple, les amplifications sur le protocole DNS permettaient d’obtenir une réponse avec une taille 40 fois supérieure à la requête initiale.

La gestion de l’incident s’annonçait difficile au sein des équipes d’OVH étant donné le nombre conséquent de serveurs exposant une instance Memcached directement sur Internet (UDP/11211) : environ 7 000 chez OVH et 74 000 dans le monde (selon Shodan), et le facteur d’amplification estimé à environ 50 000. Les décisions ont été difficiles à prendre et les solutions relativement peu nombreuses : bloquer purement et simplement le port UDP/11 211 (et impacter potentiellement des milliers de joueurs, le port étant aussi utilisé pour certains serveurs de jeux), développer des techniques de mitigation maison (ce qui serait précis, mais prendrait beaucoup de temps à réaliser), définir un mécanisme d’UBRL (pour User Based Rate Limiting), consistant à forcer une limite du trafic UDP lié à Memcached (et avoir un léger impact global sur les performances), ou simplement espérer que l’attaque s’arrête.

L’option choisie par OVH a été d’implémenter un mécanisme d’UBRL pour limiter les dégâts à court terme, tout en décidant de développer une technique de mitigation en parallèle pour une solution long terme. Il restait alors à protéger le reste du monde de cette attaque, puisque les serveurs OVH disposant d’une instance Memcached étaient aussi utilisés pour augmenter la force de frappe des attaquants. Là encore, plusieurs décisions ont dû être prises en parallèle : éviter le phénomène d’amplification en empêchant le flood sur les IP « malveillantes » à l’origine du trafic, prévenir les clients d’OVH qu’un logiciel vulnérable sur leurs serveurs participait à une attaque DDoS et menaçait les administrateurs des serveurs de couper ces derniers s’ils ne réagissaient pas.

En collaborant avec l’équipe de marketing d’OVH, et grâce à 3 campagnes de communication, les équipes de sécurité ont ainsi réussi à obtenir des utilisateurs qu’ils corrigent environ 75 % des serveurs Memcached impactés.

À l’heure actuelle, les DDoS via une amplification utilisant Memcached existent toujours, surtout en Asie, mais la plupart des instances ayant été corrigées, les attaques sont beaucoup moins impressionnantes.

Agressions électromagnétiques et forensics, par Jose Lopes Esteves

agressionsEM.jpg

Cette conférence nous a présenté l’utilisation et l’évolution des agressions électromagnétiques et son utilisation possible dans le cadre d’une investigation numérique.

L’idée des agressions électromagnétiques est apparue pendant les essais nucléaires au 20ème siècle, quand les chercheurs ont découvert l’impact de la détonation d’une arme sur son entourage électromagnétique. L’objectif habituel de ces agressions est principalement de pouvoir endommager (physiquement, ou en terme de communications) un appareil, afin de causer un déni de service. Elles peuvent également être utilisées afin de dégrader les communications d’une zone, de leurrer des capteurs ou d’injecter des signaux arbitraires.

Depuis les premiers essais nucléaires, les technologies ont évolué, et aujourd’hui les stratégies de détection coûtent cher à mettre en place, comparativement à la simplicité relative de ces attaques. Deux stratégies sont principalement utilisées : la surveillance du spectre électromagnétique, afin de déterminer un signal bruit, et la surveillance des effets, qui permet de déterminer l’impact qu’a pu avoir une agression électromagnétique. Cependant, ces deux techniques sont distinctes, et l’une utilisée isolément ne permet pas d’obtenir les informations fournies par l’autre.

Avant de conclure, l’intervenant a proposé une utilisation de ces agressions électromagnétiques dans le cadre de lutte contre les drones. Actuellement, on utilise des armes électromagnétiques afin de faire tomber un drone (ce qui peut causer des dommages considérables). Le projet porté par le conférencier consiste à utiliser les variations du signal électromagnétique afin d’injecter un signal arbitraire dans les journaux des drones, et d’y déposer, par exemple, un timestamp chiffré par une clé. La corrélation des informations permettrait alors de déterminer si un appareil se trouvait dans une zone précise à une heure précise.

En conclusion, les agressions électromagnétiques sont des attaques en cours de développement grâce au coût du matériel qui est de moins en moins élevé et à des capacités de défense qui sont encore immatures.

AWS EC2 Forensics 101, par Frédéric Baguelin

AWS.jpg
Cette conférence trouve son origine dans un besoin de la Société Générale de récupérer, en local, des volumes (associés à des instances Amazon EC2) pour un total de 6TB.
La présentation a débuté par un rappel du contexte technique concernant AWS (Amazon Web Services), ainsi que les offres EC2.

Le point le plus important de cette introduction était le rappel qu’un volume, qui est un stockage virtuel attaché à une instance EC2, est disponible uniquement dans la même zone de disponibilité que l’instance. Il n’est donc pas possible de déplacer directement un volume d’une instance située à Los Angeles, vers une instance située à Paris.

Pour faire cela, il est nécessaire de créer un instantané du volume (qu’Amazon appelle « snapshot »), et de donner les droits d’accès aux snapshots ainsi qu’aux clés de déchiffrement de ceux-ci (tous les volumes sont chiffrés). Une fois le snapshot créé, il faut l’associer à l’instance d’acquisition, attendre la lecture complète de celui-ci (environ 10 min pour un snapshot de 200GB), puis, le présentateur a utilisé wget afin de récupérer son volume depuis l’instance EC2 d’acquisition.

Au final, cette technique est actuellement l’une des seules disponibles pour récupérer le contenu d’un volume en local, avec celle consistant à envoyer un disque vierge à Amazon, en demandant de copier les données dessus. C’est donc une méthodologie intéressante, bien que difficilement automatisable et surtout, qui représente un certain coût (500 $ pour récupérer 6,6TB de données).

L’histoire de Greendale, par Thomas Chopitea

greendale.jpg
Thomas CHOPITEA, membre de l’équipe de réponse à incidents interne de Google, a présenté les outils utilisés par son équipe grâce à une conférence basée sur une fausse attaque, menant à une investigation imaginaire.

Via une présentation très didactique et un scénario bien ficelé, le chercheur a présenté les outils GRR, plaso, TimeSketch, dfTimewolf et Turbinia.

La présentation a ainsi débuté avec une attaque classique de typosquatting visant une fausse université. Laissé sans informations sur le domaine visiblement malveillant utilisé, le conférencier a détaillé comment l’utilisation de GRR lui permet de récupérer des informations, et notamment de déterminer qui aurait pu visiter le site malveillant. GRR est un framework de réponse à incidents utilisant des agents distants. Ce dernier a l’avantage d’exister sur de multiples plateformes et permet de récupérer rapidement des artefacts et des fichiers importants.

Une fois ces artefacts récupérés, c’est au tour du logiciel plaso d’entrer en scène. Originellement connu sous le nom de « log2timeline», ce logiciel permet de convertir tous les éléments d’un système de fichier et d’en extraire les timestamps. L’objectif est d’observer de manière temporelle (sous forme de timeline) les divers incidents qui ont pu avoir lieu sur une machine infectée, ou qui ont mené à l’infection d’une machine.

Après que la timeline ait été créée, c’est l’utilisation de Timesketch qui a été présentée. Timesketch a pour but de présenter une timeline d’une manière plus visuelle, en mettant en avant les informations importantes et en permettant de filtrer facilement l’information. Timesketch permet également à plusieurs analystes de travailler en parallèle sur divers cas et diverses timeline.

Ensuite, dfTimewolf permet d’utiliser les différentes sorties des divers logiciels utilisés (GRR, plaso) les unes à la suite des autres, via un système de « recettes » indiquant les différentes actions à entreprendre, de manière à automatiser la récupération et le pré-traitement d’un certain nombre d’informations, pour qu’ils soient ingérés dans Timesketch.

La présentation s’est conclue par l’utilisation du logiciel Turbinia, qui permet de réaliser une analyse forensique complète depuis le Cloud (Google Cloud, dans ce cas). Il permet ainsi de récupérer des preuves sur une machine du Cloud déployée automatiquement, de lancer plaso sur celles-ci, d’exporter les résultats et de les importer dans une autre machine présente sur le Cloud, qui servira à l’investigation numérique.

Thomas CHOPITEA en a profité pour rappeler que tous les outils présentés sont open source, gratuits et sous licence Apache 2. Ils peuvent donc facilement être réutilisés dans n’importe quelle entreprise.

Investigation numérique sur l’annuaire Active Directory avec les métadonnées de réplication, par Léonard Savina

SUPPORT

activedirectory.jpg

Objectif de cette conférence : démontrer l’utilité des métadonnées de réplication dans le cadre d’une investigation numérique portant sur un annuaire Active Directory.

Léonard SAVINA a introduit sa présentation en expliquant ce que sont les métadonnées de réplication. Ces métadonnées, disponibles au format XML pour chaque objet, sont des informations relatives à la dernière modification des attributs répliqués de l’objet entre plusieurs Active Directory d’une même forêt. Chaque modification d’un attribut répliqué dans un des annuaires Active Directory va incrémenter une valeur appelée USN, qui, reliée au nom d’un contrôleur de domaine permet d’identifier de manière unique une modification de l’annuaire. L’ensemble des métadonnées de réplications se retrouvent dans 2 sources : le « msDS-ReplAttributeMetaData » pour les attributs et le « msDS-ReplValueMetaData » qui se récupère lors de l’interrogation d’un groupe.

Afin de manipuler ces métadonnées, l’ANSSI a développé un outil open-source appelé « ADTimeline ». Celui-ci permet d’extraire, pour des objets donnés, leurs métadonnées de réplication (« msDS-ReplAttributeMetaData » et, pour les groupes, « msDS-ReplValueMetaData ») puis de générer une timeline (au format CSV), en triant ces métadonnées par date de dernier changement. L’outil génère également deux fichiers XML, qui contiennent les objets avec leurs attributs récupérés par LDAP et par le « Global Catalog », et un fichier de log.

Dans la suite de la démonstration, l’intervenant a déroulé 2 scénarios afin de montrer l’utilité des métadonnées de réplication.

Dans le premier scénario, un attaquant avec les droits « administrateur de domaine » met en place une porte dérobée sur le système, déploie un logiciel malveillant à l’aide d’une GPO et utilise Mimikatz DCSync pour voler les secrets d’authentification. Avec ADTimeline, la personne qui mène l’investigation est en mesure de détecter la modification suspecte d’attributs, l’effacement suspect d’objets, la modification de groupes d’utilisateurs (ajout/suppression de comptes) et enfin, des incohérences dans la timeline, qui permet de détecter un comportement frauduleux. À partir de là, il est nécessaire de pivoter sur les journaux Windows pour analyser la compromission. Les métadonnées de réplication servent ici à détecter un comportement suspect pour fournir une piste à l’équipe en charge de l’investigation.

Dans le second scénario, l’attaquant, toujours avec les droits administrateur de domaine, a modifié un attribut afin de pouvoir contourner l’authentification multifacteur en place sur le parc. Puis, il utilise Mimikatz DCShadow pour contourner les alertes du SIEM et falsifier les métadonnées de réplication afin de ralentir l’investigation. Ici, ADTimeline permet de détecter une incohérence dans la première timeline générée à cause de valeurs surprenantes des valeurs de l’USN sur un des Active Directory. L’équipe d’investigation a alors généré une seconde timeline afin de trouver la raison de l’incohérence.

En conclusion, Léonard SAVINA est revenu sur les différences entre métadonnées de réplications et journaux de sécurité, et notamment sur le point que les métadonnées de réplications ne remplacent en aucun cas un système de centralisation, stockage et analyse des journaux.

Retour d’expérience lors d’investigation iOS, par Paul Rascagnères

ios.jpg
Dans cette dernière présentation de la journée, Paul RASCAGNERES, chercheur en sécurité chez Talos, est revenu sur 3 grosses investigations iOS sur lesquelles il a pu travailler durant l’année écoulée.

Premier rappel fait par Mr RASCAGNERES : les logiciels malveillants existent bien sur iOS, contrairement aux idées reçues. Il a ensuite réalisé un bref rappel de l’architecture iOS : un système UNIX, séparé en plusieurs couches. C’est un système d’exploitation sans aucun accès total au système (pas d’accès root, pas d’accès à une CLI) et où l’intégralité du système est sandboxé. Le système de fichier root est également en lecture seule, ce qui en empêche la modification (au risque de planter le téléphone). Ce rappel est conclu par un constat : les protections en place, limitent, voire empêchent, les analyses de logiciels malveillants et les investigations numériques.

La seconde partie, concernant la nécessité de « jailbreak » le téléphone, est introduite par un second constat : afin de mener une investigation numérique sur iOS, il faut extraire la source de l’application (en .ipa). Théoriquement, le « jailbreak » n’est pas obligatoire. Cependant, dans le cas d’un téléphone non-jailbreaké, le seul moyen de récupérer l’application est d’envoyer directement l’appareil à Apple, en leur demandant de vous envoyer l’application extraite. En effet, sans « jailbreak », impossible pour un chercheur de réaliser un « dump » de la mémoire ou du disque, et l’analyse de l’application nécessite la source. Troisième constat de cette présentation : si l’appareil n’est pas à jour, « jailbreakez-le », sinon, envoyez un message à Cellebrite et préparez un chèque conséquent (ou retirez l’appareil des processus de mise à jour et attendez un hypothétique « jailbreak » pour cette version d’iOS).

Parmi les outils utilisés pour son investigation, l’intervenant a notamment cité IDA Pro (ou une alternative appelée Hopper), Frida (qui permet de débugguer iOS) ainsi que la nécessité d’avoir un routeur configuré pour effectuer une capture réseau de ce qu’envoie l’appareil.

Il est ensuite rentré dans les détails du déploiement des malwares, et a principalement mis en avant une technique : l’utilisation d’un MDM (Mobile Device Manager). Un MDM permet de déployer des applications à distance sur un appareil iOS. Toutefois, il existe deux principales limitations :

  • la nécessité que l’appareil s’inscrive à un MDM (ce qui peut être fait soit par une attaque d’ingénierie sociale, soit avec un accès physique à l’appareil) ;
  • l’impossibilité de supprimer directement des applications via le MDM (ce qui peut toutefois être fait en utilisant un paramètre de contrainte d’âge – intégré dans l’application –  pour supprimer certaines applications, autorisées seulement à partir d’un certain âge).

Paul RASCAGNERES a également cité l’utilisation des failles 0-day comme moyen de déployer des applications malveillantes, mais sans toutefois rentrer dans les détails.

Suite à cela, le conférencier a présenté les 3 techniques utilisées par les attaquants dans les logiciels malveillants qu’il a pu utiliser : l’injection de bibliothèque, l’interception web et l’utilisation d’un clavier customisé.

L’injection de bibliothèque est une technique bien connue de la communauté technique iOS, puisqu’elle permet d’ajuster le comportement d’une application (par exemple, avoir deux comptes WhatsApp actifs sur un même appareil). L’injection d’une bibliothèque malveillante permet donc à un attaquant d’obtenir les mêmes droits que l’application légitime, ainsi qu’un accès en lecture et en écriture sur les fichiers de l’application. Il est toutefois limité à la sandbox de l’application.

L’interception web consiste à générer des évènements sur des applications dans des pages web (notamment les applications de navigateurs). L’application malveillante injecte du code JavaScript dans le code HTML de la page pour exécuter son action malveillante, puis met à jour le code de la page avant de la monter à l’utilisateur afin qu’il ne se doute de rien. Cette forme d’attaque permet notamment de récupérer des identifiants.

Enfin, les claviers customisés peuvent être programmés de façon à surveiller l’envoi des touches saisies, ce qui permet à un attaquant d’injecter un enregistreur de frappes sur un appareil. Ce genre d’application est censé être refusé par le store d’Apple, puisqu’il utilise le framework Web alors que ce n’est pas censé être le cas. Cependant, lorsque l’utilisateur saisit du texte dans un champ de mot de passe, l’appareil re-bascule automatiquement sur le clavier original, empêchant un attaquant de récupérer certains mots de passe grâce à ce genre d’attaques.

Pour conclure, Paul RASCAGNERES est revenu sur son premier constat : les logiciels malveillants existent bel et bien sur iOS et peuvent prendre plusieurs formes. Ce dernier a terminé sur un dernier constat : le plus compliqué dans une investigation numérique sous iOS, c’est de « jailbreaker » l’appareil.

bannierecoriin2019
Enfin, les organisateurs ont conclu cette édition par la confirmation que l’édition 2020 se tiendra normalement la veille du FIC l’année prochaine.


Arthur Gautier