[TechDays2012] Forensics

Nicolas Ruff, d’EADS, présente cette session, la dernière pour ces Tech Days. A ce niveau de fatigue après avoir mangé des sessions pendant 3 jours, tout en s’étant levé à 4 heures du matin pour venir de Bretagne le premier jour, on commence à être un peu cuit, et la dernière session, d’expérience, est un quitte ou double. Là, excellente session d’un orateur visiblement passionné, et du coup passionnant. Je comprends maintenant pourquoi mes étudiants écoutent toujours mieux lorsque je leur fais un cours sur la sécurité : toutes ces petites anecdotes et astuces qui fourmillent dans ce domaine rende les interventions beaucoup plus sympa…

Forensics = recherche de preuve / analyse post-mortem. Autopsie de machines au lieu des cadavres. La scène de crime est une intrusion informatique, sachant que les anciennes méthodes ne fonctionnent plus.

Les interventions de personnes comme Nicolas Ruff sont surtout sur des Advanced Persistant Thread. Le terme de Successful Persistant Thread est, selon l’orateur, plus avancé. Il s’agit de combiner des méthodes, de manière organisée et récurrente pour accéder à des données très valorisables.

Le mode forensics traditionnel avec saisie du disque dur et indexation pour recherche d’un mot clé ne peut pas être utilisé avec des APT. Tout d’abord parce que les entreprises ne signalent pas leur piratage, alors même parfois qu’elles y sont forcées par la loi. Ensuite, parce qu’on ne sait pas précisément quoi chercher (ce n’est pas une adresse d’un site pirate, ou un fichier donnée, etc.). Enfin, la simple collecte des données serait impossible sur des milliers de serveur, avec des formats parfois spéciaux (RAID, par exemple) et la production reste prioritaire sur le forensics.

REX sur le forensics en APT : on ne cherche pas des preuves mais des indices, et il n’y aura pas de contre-expertise. La documentation reste indispensable, surtout si on travaille en équipe.

Big Data permet de traiter des masses de données de manière relativement rapides (5 minutes), mais les technologies de forensics n’existent aujourd’hui pas sur ces outils.

Du coup, recherche de signaux faibles : Autoruns de SysInternals, Fichier ZIP > 10 Go, Processus “Microsoft” mais pas signé par Microsoft, adresses IP suspectes, activité nocturne, certaines machines seulement avec un outil qui devrait être poussé partout par AD, etc. Plus de besoin d’intuition que pour de la forensics traditionnelle.

Même quand on a des logs actifs, ils ne remontent souvent pas beaucoup en arrière pour des raisons d’économie de place. Par exemple, un contrôleur de domaine prend plusieurs Go par jour pour loguer tout. Et il faut en plus un expert pour distinguer les sondes qui ne doivent pas être loguées, etc.

Très bonne idée d’avoir fait un petit quiz technique à la fin, c’était interactif et très intéressant. Ca montre aussi qu’il faut de l’intuition pour trouver ces problèmes, mais surtout un très bon background technique. Un des cas nécessitait de savoir trouver des instructions qui auraient du être absentes d’un code assembleur, tout en voyant qu’un JZ avec un JNZ sur la même adresse faisait en sorte qu’on aille toujours sur le même résultat, trompant ainsi les analyses de recherche d’instructions interdites qu’on avait juste après dans le code, et qui allaient taper directement sur les périphériques.