#SwishDbgExt

SwishDbgExt ist eine Microsoft WinDbg Debugging-Erweiterung, die den Satz verfügbarer Befehle von Microsoft WinDbg erweitert, aber auch vorhandene Befehle repariert und verbessert. Diese Erweiterung wurde von Matt Suiche (@msuiche) entwickelt – zögern Sie nicht, sich unter [email protected] zu melden, um weitere Funktionen anzufragen, einen Beitrag zu leisten und/oder Fehler zu melden.

SwishDbgExt zielt darauf ab, Kernel-Entwicklern, Troubleshootern und Sicherheitsexperten mit einer Reihe von Debugging-, Incident-Response- und Memory-Forensik-Befehlen das Leben zu erleichtern. Da SwishDbgExt eine WinDbg-Debugging-Erweiterung ist, bedeutet dies, dass sie in lokalen oder remote Kernel-Debugging-Sitzungen, Live-Sitzungen, die von Microsoft LiveKd generiert wurden, aber auch in Microsoft-Crash-Dumps, die bei einem Blue Screen of Death oder hybriden Dienstprogrammen wie Comae DumpIt erstellt wurden, verwendet werden kann.

2016 Wettbewerb

Weitere Informationen auf https://blog.comae.io/comae-2016-contest-swishdbgext-features-3c9a63c62209#.tnt1b9usx

Installation

Sie können die WinDbg-Erweiterung entweder in den entsprechenden (x86 oder x64) WinDbg-Ordner kopieren oder manuell mit dem !load-Befehl laden, wie unten gezeigt. Beachten Sie, dass der vollständige Pfad zur zu ladenden DLL keine Leerzeichen oder Anführungszeichen enthalten darf. !load X:\FullPath\SwishDbgExt.dll

Beispiel:

kd> !load E:\projects\labs\SwishDbgExt\bin\x64\SwishDbgExt.dll;
       SwishDbgExt v0.7.0 (Nov  2 2016) - Incident Response & Digital Forensics Debugging Extension
       SwishDbgExt Copyright (C) 2016 Comae Technologies FZE - http://www.comae.io
       SwishDbgExt Copyright (C) 2014-2016 Matthieu Suiche (@msuiche)

       This program comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
       This is free software, and you are welcome to redistribute it
       under certain conditions; type `show c' for details.

Wenn Sie Ihre WinDbg-Vorlage mit einer DML-freundlicheren Vorlage aktualisieren möchten, können Sie die dem Paket beiliegende Datei windbg_template.reg direkt importieren.

TODO

Strukturen definieren
Befehle definieren
Feature-Wettbewerb ankündigen.

Befehle

!SwishDbgExt.help

Zeigt Informationen zu verfügbaren Erweiterungsbefehlen an.

Dieser Befehl gibt Ihnen die Liste aller Befehle, wenn Sie kein Argument angeben, und die Liste der Parameter für einen vorhandenen Befehl, wenn ein Argument angegeben wird.

!ms_callbacks

Callback-Funktionen anzeigen

!ms_checkcodecave

Nach verwendeten Code-Caves suchen

!ms_consoles

Verlauf der Konsolenbefehle anzeigen

!ms_credentials

Benutzeranmeldeinformationen anzeigen (basiert auf gentilwiki's mimikatz)

!ms_drivers

Liste der Treiber anzeigen. !ms_drivers zeigt eine Liste der derzeit geladenen Treiber an. In diesem Beispiel finden Sie einige der zum Zeitpunkt des Absturzes in diesem Kernel-Dump geladenen Treiber: Mit diesem Befehl können wir auch detaillierte IRP-Informationen zu einem Treiber anzeigen: Im obigen Bild sehen Sie den treiberspezifischen I/O-Stack-Standort im IRP von e1cexpress.sys. Hier sehen wir Funktionscodes wie IRP_MJ_CREATE, die das Zielgeräteobjekt öffnen, was darauf hindeutet, dass es vorhanden und für I/O-Operationen verfügbar ist.

!ms_dump

Speicherbereich auf Festplatte dumpen

!ms_exqueue

Ex in der Warteschlange befindliche Worker anzeigen.

!exqueue funktioniert unter Windows 8 nicht richtig, daher musste eine funktionierende Version implementiert werden. Genau wie der ursprüngliche Befehl zeigt dieser die Warteschlange der arbeitenden Threads an.

!ms_fixit

Segmentierung in WinDbg zurücksetzen (Fix "16.kd>")

!ms_gdt

GDT anzeigen.

!ms_gdt zeigt die Global Descriptor Table an. Beachten Sie, dass unter x64 jeder Selektor flach ist (0x0000000000000000 bis 0xFFFFFFFFFFFFFFFF). Dieser Befehl kann besonders hilfreich sein, um auf verdächtiges Hooking der GDT zu prüfen, da ein solcher Versuch unter x64 einen Bug Check auslöst. Dies liegt daran, dass x64 das Hooking der GDT verbietet.

!ms_hivelist

Liste der Registry-Hives anzeigen.

ms_hivelist zeigt eine Liste der Registry-Hives an. Wir können direkt in einen Hive (z.B. \Registry\Machine\Software) schauen, um dessen Unterschlüssel, Werte usw. zu sehen:

Alt text

!ms_idt

IDT anzeigen.

!ms_idt zeigt die Interrupt Descriptor Table an. Ähnlich wie bei der GDT wird bei einem Hooking der IDT unter x64 ein Bug Check ausgelöst. Dies liegt daran, dass Microsoft programmatisch eine Verhinderung des Hookings der IDT implementiert hat, indem ein Kernel-Mode-Treiber normalerweise Aufrufe an die IDT abfängt und dann eigene Verarbeitung hinzufügt. Deshalb gibt es im obigen Bild überall ‘No’.

!ms_malscore

Analysiert einen Speicherbereich und gibt einen Malware Score Index (MSI) zurück – (basiert auf der Arbeit von Frank Boldewin)

!ms_mbr

Master Boot Record (MBR) scannen

!ms_netstat

Netzwerkinformationen anzeigen (Sockets, Verbindungen, ...)

!ms_object

Liste der Objekte anzeigen

!ms_process

Liste der Prozesse anzeigen. !ms_process ist eine verbesserte Version von !process und !dml_proc. Eines der netten Dinge, wie Sie unten sehen können, ist die Verwendung von DML (Debugger Markup Language) mit den Befehlen. Alle unterstrichenen Befehle sind tatsächlich Links zu Befehlen. Im untenstehenden Beispiel sehen Sie die Ausgabe von /vads /scan, um VAD (Virtual Address Descriptors) zu scannen. Sie können feststellen, dass eine Spalte den „Malware Score Index“ angibt, der nützlich sein kann, um Shellcodes oder Heap-Spray zu erkennen. Im Screenshot unten sehen Sie eine ungewöhnlich hohe Punktzahl in mehreren VADs – aufgrund der Verwendung von Heap-Spray. Durch Klicken auf die Punktzahl wird der Scan-Algorithmus ausgeführt. Der Scan-Algorithmus basiert auf Frank Boldewin’s Dienstprogramm OfficeMalScanner. Und gibt Ihnen Informationen darüber, wo sich der Shellcode befindet: Die Option /scan kann auch für exportierte Funktionen verwendet werden, um festzustellen, ob die EAT (Export Address Table) gepatcht wurde oder ob der Prolog der Funktion modifiziert wurde.

Ähnliche Tests sind für die SSDT (!ms_ssdt) verfügbar.

!ms_readkcb

Key Control Block lesen

!ms_readknode

Key-Knoten lesen. Der WinDbg-Befehl !reg war aufgrund einiger Fehler lange Zeit frustrierend. Deshalb hat SwishDbgExt eigene Registry-Explorer-Funktionen, um den Zugriff auf Registry-Daten so einfach wie möglich zu gestalten.

!ms_readkvalue

Key-Wert lesen

!ms_scanndishook

Verdächtige NDIS-Hooks scannen und anzeigen

!ms_services

Liste der Dienste anzeigen

!ms_ssdt

Funktionen der Service Descriptor Table (SDT) anzeigen. !ms_ssdt zeigt die System Service Dispatch Table an. Dieser Befehl ist äußerst hilfreich bei der Untersuchung von verdächtigen Rootkit-Hooks durch Direct Kernel Object Manipulation (DKOM). Wenn Sie hier eine Low-Level-Routine sehen, die gehooked ist (wie nt!NtEnumerateKey), kann Ihnen dies bei Ihrer Analyse einer möglichen Rootkit-Infektion helfen.

!ms_store

Informationen zum Store Manager (ReadyBoost) anzeigen.

Dieser Befehl ermöglicht es, den aktuellen ReadyBoost-Cache (erfordert USB 3.0) des Betriebssystems aufzulisten, aber auch die Protokolle der vom Store Manager verwalteten Speicherseiten anzuzeigen. Parameter: /cache

!ms_timers

Liste der KTIMER anzeigen.

!ms_timers zeigt die KTIMER-Struktur an, eine undurchsichtige Struktur, die verschiedene Timer-Objekte darstellt und enthält. Dieser Befehl kann hilfreich sein, um herauszufinden, welche Treiber welche Timer-Objekte erstellt haben, welche Treiber welche Routinen aufgerufen haben usw.

!ms_vacbs

Liste der zwischengespeicherten VACBs anzeigen

!ms_verbose

Ausführlichen Modus ein-/ausschalten

!ms_lxss

Das Folgende basiert auf der von Alex Ionescu veröffentlichten Forschung, die hier verfügbar ist: https://github.com/ionescu007/lxss/

Diese Funktion ist unter Windows 10+ als optionale Funktion verfügbar, die über den folgenden PowerShell-Befehl installiert werden kann:

Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux

Weitere Informationen zum Windows-Subsystem für Linux finden Sie unter den folgenden Links:

	Windows Subsystem for Linux Overview.
	Instance 0xFFFFE704EEB8F010
	GUID: {E29032FD-35D3-4C53-AB68-6BCEBDA7176F}
	State:            (1) [STARTED]
	Creation Flags:   00000001
	GlobalData:       0xFFFFF802ED4138A0
	Root Handle:      80000834
	Temp Handle:      80000838
	Job Handle:       8000083c
	Token:            80000818
	Event Handle:     800008bc

	Map Paths (0):    0xFFFFE704EF437920
	VFS Context:      0xFFFFE704EEFC4710
	Memory Flags:     0x2

	Last PID:         35
	Thread Groups:    3
		Session 0xFFFFE704EDB79EC0
		Instance:         0xFFFFE704EEB8F010
		Console inode:    0x0
		Foreground PID:   -1
			Process Group 0xFFFFE704EDB79AE0
			Instance:      0xFFFFE704EEB8F010
			Session:       0xFFFFE704EDB79EC0
				Thread Group 0xFFFFE704EF4F8000
				Binary Path:           /init
				Thread(s):             1
				Owner Process Group:   0xFFFFE704EDB79AE0
				Flags:                 0x00000000
				Main Thread:           0xFFFFE704EF5CC010
				Arguments (006 bytes): 0x00007FFFC081D6E0
					Process 0xFFFFE704EF2F1D70
					Instance:            0xFFFFE704EEB8F010
					NT Process Object:   0xFFFFAE05E84EF800
					NT Process Handle:   0xFFFFFFFF80000F58
					VDSO Address:        0x00007FFFC0849000
					Stack Address:       0x00007FFFC001E000
		Session 0xFFFFE704EF5DB830
		Instance:         0xFFFFE704EEB8F010
		Console inode:    0xFFFFE704EF32D7A0
		Foreground PID:   2
			Process Group 0xFFFFE704EF5EF970
			Instance:      0xFFFFE704EEB8F010
			Session:       0xFFFFE704EF5DB830
				Thread Group 0xFFFFE704EF5EE000
				Binary Path:           /bin/bash
				Thread(s):             1
				Owner Process Group:   0xFFFFE704EF5EF970
				Flags:                 0x0000000C
				Main Thread:           0xFFFFE704EF5F8010
				Arguments (010 bytes): 0x00007FFFDF34E418
					Process 0xFFFFE704EDEF6EC0
					Instance:            0xFFFFE704EEB8F010
					NT Process Object:   0xFFFFAE05E84E6800
					NT Process Handle:   0xFFFFFFFF80000D9C
					VDSO Address:        0x00007FFFDF883000
					Stack Address:       0x00007FFFDEB4F000
		Session 0xFFFFE704EF0A8ED0
		Instance:         0xFFFFE704EEB8F010
		Console inode:    0xFFFFE704EF06B9C0
		Foreground PID:   19
			Process Group 0xFFFFE704F059CBC0
			Instance:      0xFFFFE704EEB8F010
			Session:       0xFFFFE704EF0A8ED0
				Thread Group 0xFFFFE704EDE51000
				Binary Path:           /bin/bash
				Thread(s):             1
				Owner Process Group:   0xFFFFE704F059CBC0
				Flags:                 0x0000000C
				Main Thread:           0xFFFFE704EDC78090
				Arguments (010 bytes): 0x00007FFFF78CFB78
					Process 0xFFFFE704F06389B0
					Instance:            0xFFFFE704EEB8F010
					NT Process Object:   0xFFFFAE05E618D800
					NT Process Handle:   0xFFFFFFFF80001650
					VDSO Address:        0x00007FFFF7C99000
					Stack Address:       0x00007FFFF70D0000

!ms_yarascan

Prozessspeicher mit YARA-Regeln scannen.

Prozessspeicher scannen.

!ms_yarascan /pid 0x228 /yarafile /yarafile C:\Rules.yar

Speicher aller Prozesse scannen.

!for_each_process "r? @$t0 = (nt!_EPROCESS *) @#Process; .process /r /p @$t0; !ms_yarascan /pid @@C++(@$t0->UniqueProcessId) /yarafile C:\\Rules.yar"

Klassen

PEFile

MsPEImageFile enthält die grundlegenden gemeinsamen Informationen, die von Windows-Binärdateien (PE) verwendet werden, und wurde in drei verschiedene Klassen abgeleitet:

MsProcessObject
MsDllObject
MsDriverObject

SwishDbgExt

Beliebteste