Question:
Existe-t-il un moyen simple de détecter si le SSDT a été corrigé à partir d'un vidage de la mémoire?
Polynomial
2013-04-02 02:56:28 UTC
view on stackexchange narkive permalink

Le SSDT est une table de répartition à l'intérieur du noyau Windows NT, et il est utilisé pour gérer les appels à diverses API internes du noyau. Souvent, les logiciels malveillants modifient les adresses dans le SSDT afin de raccorder certaines fonctions du noyau. Repérer ce genre de chose dans un vidage de mémoire serait génial, car cela me permettrait d'identifier des rootkits potentiels. Existe-t-il un moyen de les détecter de manière fiable? Quel type de vidage de la mémoire est requis?

Deux réponses:
#1
+8
0xC0000022L
2013-04-02 05:39:33 UTC
view on stackexchange narkive permalink

Aucun moyen absolument fiable , non.

Dans tous les cas, vous aurez besoin d'un vidage complet, mais le problème est que les logiciels malveillants pourraient même accrocher les fonctions responsables à l'intérieur du noyau et modifier ce qui est vidé. Il y a plusieurs choses à prendre en compte ici.

Vous pouvez le détecter si le malware a utilisé une méthode triviale pour accrocher en premier lieu. Supposons que l'adresse ait été remplacée par une adresse sur un trampoline ou à l'intérieur d'une autre image chargée (ou même à l'extérieur d'une seule dans un pool non paginé), alors vous pouvez la détecter facilement . Vous pouvez simplement énumérer tous les modules et tenter de trouver celui à l'intérieur duquel pointe l'adresse de l'intérieur du SSDT. Dans le cas d'un trampoline, vous devrez démonter les instructions pour voir où il saute / appelle. Il existe de nombreuses bibliothèques à cet effet, telles que udis86 .

Cependant, si un malware est sournois, il pourrait utiliser les lacunes naturelles à l'intérieur d'un exécutable (tel que le noyau) lorsqu'il est chargé en mémoire. Comme vous le savez probablement, la façon dont un fichier PE (tel que ntoskrnl.exe et ses amis) est représentée différemment sur le disque et en mémoire. Le format de fichier sur disque est plus concis. Chargées en mémoire, les sections sont alignées d'une manière particulière décrite dans l'en-tête PE. De cette manière, des espaces existeront probablement entre la taille réelle d'une section (extrémité) et la taille de section correctement alignée ("rembourrage"). Cela laisse place à cacher quelque chose comme un trampoline ou même plus de code shell qu'un simple trampoline. Ainsi, une vérification naïve comme celle ci-dessus - c'est-à-dire énumérer les modules et vérifier si les fonctions SSDT pointent à l'intérieur de l'image du noyau - ne fonctionnera pas. Il serait contourné par des logiciels malveillants suffisamment sophistiqués pour faire ce que je viens de décrire.

Comme vous pouvez l'imaginer, cela signifie que les choses - comme tout ce qui concerne les logiciels malveillants / anti-malware - deviennent rapidement une course aux armements. Ce que je suggérerais fortement, c'est que vous attachez un débogueur de noyau ( WinDbg via Firewire vient à l'esprit) et gardez la machine infectée (ou prétendument infectée) dans les limbes pendant que vous enquêtez. Pendant que vous êtes connecté et que vous êtes entré par effraction dans le débogueur, le débogueur ne peut rien faire. Cela peut être utilisé pour déboguer un système en direct et - en supposant que le malware ne soit pas assez sournois pour manipuler également kdcom - pour obtenir des métriques précieuses - il peut également être utilisé pour créer un crashdump directement (voir l'aide de WinDbg ). Si vous avez des preuves concluantes qu'une machine est infectée, en raison des symptômes qu'elle présente, il y a de fortes chances que le logiciel malveillant ne soit pas trop sophistiqué et que vous n'aurez pas à vous soucier du cas particulier que j'ai décrit. Cependant, gardez à l'esprit que ce cas particulier ne peut être considéré que un parmi les nombreux cas imaginables utilisés pour se cacher. Bref, il n'y a pas de moyen absolument fiable de faire ce que vous voulez.

On a parfois dit - et c'est vrai - que l'attaquant a juste besoin d'en trouver un d'un nombre infini de vecteurs d'attaque, alors que le défenseur ne peut défendre qu'un nombre fini de vecteurs d'attaque connus . La leçon à tirer de cela devrait être que nous - en tant qu'industrie anti-malware (dans laquelle je travaille) - pouvons toujours affirmer que nous n'avons rien trouvé sur le système, mais qu'il est faux de prétendre que le système est propre.


Comment provoquer délibérément un BSOD

On peut dire au (x) pilote (s) de clavier de provoquer un BSOD:

  HKLM \ CurrentControlSet \ Services \ kbdhid \ Parameters  

ou (pour les anciens claviers PS / 2)

  HKLM \ SYSTEM \ CurrentControlSet \ Services \ i8042prt \ Parameters  

Et là, définissez un REG_DWORD nommé CrashOnCtrlScroll sur 1 .

Après le prochain redémarrage, vous pouvez forcer l'écran bleu en Ctrl + ScrollLk + ScrollLk . Le code de vérification de bogue sera dans ce cas 0xE2 ( MANUALLY_INITIATED_CRASH ).


Note d'accompagnement: j'ai aussi lu, mais jamais vu dans une session de débogage du noyau moi-même ou dans tout type d'implémentation FLOSS, qu'une méthode essaie de recharger le noyau à partir de l'image sur le disque et de l'exécuter à travers les premières étapes d'initialisation, créant ainsi un SSDT "shadow". Celui-ci serait alors parfait et pourrait être utilisé pour «décrocher» tout d'un seul coup du SSDT d'origine. Encore une fois, je n'ai pas vu cela implémenté, mais d'après ma connaissance des composants internes, cela semble une possibilité. Bien sûr, cela joue plus avec l'idée de détecter / décrocher les fonctions d'un rootkit qu'avec votre intention initiale d'obtenir un vidage de la mémoire d'un système infecté.

#2
+6
Brendan Dolan-Gavitt
2013-04-02 05:37:25 UTC
view on stackexchange narkive permalink

Volatility peut détecter de tels hooks sur la base d'une image mémoire dans l'un de ses formats pris en charge.

En particulier, les threads le plugin marquera n'importe quel thread avec des hooks SSDT comme HookedSSDT , et le plugin ssdt videra toutes les fonctions du SSDT et donnera le nom du module noyau qui contient chaque fonction.

Une autre méthode, qui peut détecter des types de corruption plus subtils, serait d'utiliser WinDbg (soit sur un système en direct, soit sur un vidage sur incident), et d'utiliser le code chkimg > commande pour auditer chaque module du noyau, par exemple:

  chkimg -d nt  

Ceci télécharge une copie vierge du noyau à partir du serveur MS Symbol et des rapports toute différence par rapport à la version en mémoire. Notez que cela ne détectera probablement aucun hook placé dans un SSDT par thread.

Oups, merci pour la capture @0xC0000022L. Fixé.


Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...