Frage:
Gibt es eine einfache Möglichkeit, festzustellen, ob der SSDT von einem Speicherauszug gepatcht wurde?
Polynomial
2013-04-02 02:56:28 UTC
view on stackexchange narkive permalink

Die SSDT ist eine Versandtabelle im Windows NT-Kernel und wird zur Verarbeitung von Aufrufen an verschiedene interne Kernel-APIs verwendet. Oft ändert Malware die Adressen in der SSDT, um bestimmte Kernelfunktionen zu verknüpfen. Es wäre fantastisch, solche Dinge in einem Speicherauszug zu entdecken, da ich so potenzielle Rootkits identifizieren könnte. Gibt es eine Möglichkeit, sie zuverlässig zu erkennen? Welche Art von Speicherauszug ist erforderlich?

Zwei antworten:
#1
+8
0xC0000022L
2013-04-02 05:39:33 UTC
view on stackexchange narkive permalink

Kein absolut zuverlässiger Weg, nein.

In beiden Fällen benötigen Sie einen vollständigen Speicherauszug, aber das Problem ist, dass Malware sogar die verantwortlichen Funktionen in den Kernel und einbinden kann Ändern Sie , was ausgegeben wird. Hier müssen einige Dinge beachtet werden.

Sie können erkennen, ob die Malware überhaupt eine triviale Methode zum Einbinden verwendet hat. Nehmen wir an, die Adresse wurde durch eine Adresse für ein Trampolin oder für ein anderes geladenes Bild (oder sogar außerhalb eines nur im nicht ausgelagerten Pool) ersetzt, und Sie können es leicht erkennen . Sie können einfach alle Module auflisten und versuchen, das Modul zu finden, in dem die Adresse innerhalb der SSDT verweist. Im Falle eines Trampolins müssen Sie die Anweisungen dort zerlegen, um zu sehen, wo es springt / ruft. Zu diesem Zweck gibt es zahlreiche Bibliotheken, z. B. udis86 .

Wenn eine Malware jedoch hinterhältig ist, kann sie die natürlichen Lücken nutzen in einer ausführbaren Datei (wie dem Kernel), wenn sie in den Speicher geladen wird. Wie Sie wahrscheinlich wissen, wird die Art und Weise, wie eine PE-Datei (z. B. ntoskrnl.exe und Freunde) auf der Festplatte und im Speicher unterschiedlich dargestellt. Das Dateiformat auf der Festplatte ist knapper. In den Speicher geladen, werden die Abschnitte auf eine bestimmte Weise ausgerichtet, die im PE-Header beschrieben ist. Auf diese Weise bestehen wahrscheinlich Lücken zwischen der tatsächlichen Größe eines Abschnitts (Ende) und der richtig ausgerichteten Abschnittsgröße ("Polsterung"). Dies lässt Platz, um so etwas wie ein Trampolin oder sogar mehr Shell-Code als ein einfaches Trampolin zu verstecken. Eine naive Prüfung wie die oben genannte - d. H. Auflisten von Modulen und Prüfen, ob die SSDT-Funktionen auf das Kernel-Image verweisen - funktioniert also nicht. Es würde von Malware umgangen werden, die hoch genug ist, um das zu tun, was ich gerade beschrieben habe.

Wie Sie sich vorstellen können, bedeutet dies, dass Dinge - wie alles Malware / Anti-Malware - schnell zu einem Wettrüsten werden. Ich würde dringend empfehlen, dass Sie einen Kernel-Debugger anhängen ( WinDbg über Firewire) und den infizierten (oder angeblich infizierten) Computer während der Untersuchung in der Schwebe halten. Während Sie verbunden sind und in den Debugger eingebrochen sind, kann der Debugger nichts tun. Dies kann verwendet werden, um ein System live zu debuggen und - vorausgesetzt, die Malware war nicht hinterhältig genug, um auch kdcom zu manipulieren - um wertvolle Messdaten zu erhalten - kann es auch verwendet werden, um direkt einen Crashdump zu erstellen (siehe WinDbg-Hilfe ). Wenn Sie schlüssige Beweise dafür haben, dass ein Computer infiziert ist, besteht die Wahrscheinlichkeit, dass die Malware nicht allzu hoch entwickelt ist, und Sie müssen sich nicht um den von mir beschriebenen Sonderfall kümmern. Beachten Sie jedoch, dass dieser Sonderfall nur als einer von vielen denkbaren Fällen betrachtet werden kann, die zum Verstecken verwendet werden. So lange Rede und Antwort: Es gibt keinen absolut zuverlässigen Weg, um das zu tun, was Sie wollen.

Es wurde manchmal gesagt - und es ist wahr -, dass der Angreifer nur einen herausfinden muss einer unendlichen Anzahl von Angriffsvektoren, während der Verteidiger nur eine endliche Anzahl von bekannten Angriffsvektoren verteidigen kann. Die Lehre daraus sollte sein, dass wir als Anti-Malware-Branche (in der ich arbeite) immer behaupten können, dass wir nichts auf dem System gefunden haben, aber dass es falsch ist, dies zu behaupten Das System ist sauber.


So verursachen Sie absichtlich ein BSOD

Den Tastaturtreibern kann gesagt werden, dass sie ein BSOD verursachen sollen:

  HKLM \ CurrentControlSet \ Services \ kbdhid \ Parameter  

oder (für ältere PS / 2-Tastaturen)

  HKLM \ SYSTEM \ CurrentControlSet \ Services \ i8042prt \ Parameter  

Und dort setzen Sie ein REG_DWORD mit dem Namen CrashOnCtrlScroll auf 1 .

Nach dem nächsten Neustart können Sie den Bluescreen mit Strg kbd> + ScrollLk kbd> + ScrollLk kbd> erzwingen. Der Fehlerprüfcode lautet in diesem Fall 0xE2 ( MANUALLY_INITIATED_CRASH ).


Randnotiz: Ich habe auch gelesen, aber nie gesehen In einer Kernel-Debugging-Sitzung selbst oder in einer FLOSS-Implementierung versucht eine Methode, den Kernel erneut vom Image auf der Festplatte zu laden und ihn durch die frühen Initialisierungsschritte auszuführen, wodurch eine "Schatten"-SSDT erstellt wird. Dieser wäre dann makellos und könnte verwendet werden, um alles auf einen Schlag von der ursprünglichen SSDT "abzuhaken". Auch hier habe ich dies nicht implementiert gesehen, aber nach meinem Wissen über die Interna scheint es eine Möglichkeit zu sein. Dies spielt natürlich mehr mit der Idee, die Funktionen eines Rootkits zu erkennen / zu lösen, als mit Ihrer ursprünglichen Absicht, einen Speicherauszug eines infizierten Systems zu erstellen.

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

Volatility kann solche Hooks anhand eines Speicherabbilds in einem der unterstützten Formate erkennen.

Insbesondere die Threads Plugin markiert jeden Thread mit SSDT-Hooks als HookedSSDT , und das Plugin ssdt gibt alle Funktionen in der SSDT aus und gibt den Namen des Kernelmoduls an, das es enthält Jede Funktion.

Eine andere Methode, die subtilere Arten von Beschädigungen erkennen kann, wäre die Verwendung von WinDbg (entweder auf einem Live-System oder auf einem Crash-Dump) und die Verwendung des Codes chkimg > Befehl zum Überwachen jedes Kernelmoduls, z. B.:

  chkimg -d nt  

Hiermit wird eine makellose Kopie des Kernels vom MS Symbol-Server heruntergeladen und Berichte erstellt Unterschiede zur In-Memory-Version. Beachten Sie, dass dadurch wahrscheinlich keine Hooks erkannt werden, die in einer SSDT pro Thread platziert sind.

Hoppla, danke für den Fang @0xC0000022L. Fest.


Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...