Les images de mémoire physique, recueillies auprès de systèmes MS Windows compromis, constituent une source de renseignement importante sur les dernières générations de codes malveillants qui visent ces systèmes d'exploitation.
Cependant, en raison de sa complexité structurelle et de la volonté de Microsoft de rendre inaccessible la connaissance du coeur de ses systèmes d'exploitation, l'analyse d'une telle image est actuellement une tâche trop rédhibitoire pour être complètement intégrée dans une procédure IR où chaque minute est comptée.
Ma première question est la suivante :
La mise au point d'un outil d'analyse de la mémoire physique des systèmes Windows est-il un objectif valable pour reprendre l'initiative face aux nouvelles armes dont disposent nos adversaires ?
Se retrancher derrière les procédures forensiques traditionnelles, qui mettent de côté le recueil de la mémoire physique, jugée trop intrusive, n'est pas une solution satisfaisante. Mais, avant de sauter le pas, il nous faut encore obtenir un outil performant et opérationnel qui nous permette de reprendre l'avantage tactique face à des adversaires disposant d'outils offensifs anti-forensiques, comme le meterpreter de la plate-forme Metasploit ou encore les plates-formes d'industrialisation de génération de rootkits.
Développer un outil from scratch pour l'analyse d'images de la mémoire physique de systèmes MS Windows peut devenir rapidement un véritable cauchemar, en raison de l'instabilité de la structure interne du noyau Windows NT. Cette instabilité se situent principalement au niveau des signatures d'objet et des offsets correspondants. Ceux-ci sont complètement différents selon la version du système d'exploitation Windows NT (NT 4.0, Windows 2000, Windows XP, Windows 2003, sans parler de Vista et Windows Server "Longhorn"), selon l'architecture du système et au sein même d'une version selon le service pack et la présence de certains hotfix.
Ma deuxième question est la suivante :
Vaut-il mieux développer un outil d'analyse complet, mais difficile à maintenir, ou alors s'appuyer sur les symbols fournis en ligne par le serveur dédié de Microsoft et sur l'analyseur d'espace mémoire du débogueur noyau Windows ?
Les outils s'appuyant sur les symbols et le débogueur noyau sont par construction limités à l'analyse d'une image générée à partir d'un crash dump (.dmp), alors que les premières procédures IR concernant le recueil de la mémoire physique s'appuient sur l'outil dd.
L'analyseur du débogueur noyau ne peut travailler qu'à partir d'un crash dump. Une telle image se différencie d'une image générée par dd par des informations supplémentaires sur l'état du CPU au moment de la photographie. D'où l'idée consistant à rajouter ces informations à une image de type dd pour la transformer en en image de type dmp.
Ma dernière question est la suivante :
La transformation d'une image dd en crash dump (.dmp) est-elle réaliste ?
Cependant, en raison de sa complexité structurelle et de la volonté de Microsoft de rendre inaccessible la connaissance du coeur de ses systèmes d'exploitation, l'analyse d'une telle image est actuellement une tâche trop rédhibitoire pour être complètement intégrée dans une procédure IR où chaque minute est comptée.
Ma première question est la suivante :
La mise au point d'un outil d'analyse de la mémoire physique des systèmes Windows est-il un objectif valable pour reprendre l'initiative face aux nouvelles armes dont disposent nos adversaires ?
Se retrancher derrière les procédures forensiques traditionnelles, qui mettent de côté le recueil de la mémoire physique, jugée trop intrusive, n'est pas une solution satisfaisante. Mais, avant de sauter le pas, il nous faut encore obtenir un outil performant et opérationnel qui nous permette de reprendre l'avantage tactique face à des adversaires disposant d'outils offensifs anti-forensiques, comme le meterpreter de la plate-forme Metasploit ou encore les plates-formes d'industrialisation de génération de rootkits.
Développer un outil from scratch pour l'analyse d'images de la mémoire physique de systèmes MS Windows peut devenir rapidement un véritable cauchemar, en raison de l'instabilité de la structure interne du noyau Windows NT. Cette instabilité se situent principalement au niveau des signatures d'objet et des offsets correspondants. Ceux-ci sont complètement différents selon la version du système d'exploitation Windows NT (NT 4.0, Windows 2000, Windows XP, Windows 2003, sans parler de Vista et Windows Server "Longhorn"), selon l'architecture du système et au sein même d'une version selon le service pack et la présence de certains hotfix.
Ma deuxième question est la suivante :
Vaut-il mieux développer un outil d'analyse complet, mais difficile à maintenir, ou alors s'appuyer sur les symbols fournis en ligne par le serveur dédié de Microsoft et sur l'analyseur d'espace mémoire du débogueur noyau Windows ?
Les outils s'appuyant sur les symbols et le débogueur noyau sont par construction limités à l'analyse d'une image générée à partir d'un crash dump (.dmp), alors que les premières procédures IR concernant le recueil de la mémoire physique s'appuient sur l'outil dd.
L'analyseur du débogueur noyau ne peut travailler qu'à partir d'un crash dump. Une telle image se différencie d'une image générée par dd par des informations supplémentaires sur l'état du CPU au moment de la photographie. D'où l'idée consistant à rajouter ces informations à une image de type dd pour la transformer en en image de type dmp.
Ma dernière question est la suivante :
La transformation d'une image dd en crash dump (.dmp) est-elle réaliste ?
Articles
Pour ce qui est de la dernière question, ça me semble bien compliqué ... Le format DMP a été "semi-
RépondreSupprimerdocumenté".
De nombreuses informations sont ajoutées par le système, par rapport à un simple "dd".
Si certaines peuvent être renseignées (ex. nombre de processeurs), d'autres comme le mapping mémoire physique/mémoire virtuelle ou la valeur des registres du processeur sont beaucoup plus difficiles à obtenir a posteriori !
Pour la dernière question, il est plus facile le faire pour Windows 2003 et plus tard parce qu’il y a déjà une fonction (KeInitializeCrashDumpHeader) qui permet de créer le dump header. Mais KnTDD peut le faire aussi pour XP et Windows 2000. Quant à la première question, je croix qu’un outil du genre est pas seulement valable mais vraiment nécessaire. On ne trouvera pas la majeure partie du malware actuel à travers les méthodes traditionnelles. Car le malware aujourd’hui est plus fois injecté dans les processus légitimes. Peut-être, il y a un injecteur qui démarre initialement, mais après il ne reste qu’une région de mémoire exécutable dedans un processus bien connu. Pour la seconde question, tous les deux méthodes sont utiles. Je utilise le Microsoft debugger main dans la main avec le KnTList. Les symboles publiés ne contenant pas beaucoup de choses comme, par exemple, les objets du TDI.
RépondreSupprimer-rossetoecioccolato@yahoo.com