CNIT 126: 10: Kernel Debugging with WinDbg
1 like1,681 views
Chapter 10 of 'Practical Malware Analysis' focuses on kernel debugging using WinDbg, emphasizing its use for analyzing device drivers and rootkits in both user and kernel modes. The chapter explains the complexity of drivers, their interaction with the Windows kernel, and provides instructions for setting up kernel debugging and utilizing various WinDbg commands for malware analysis. It also discusses rootkit behavior, particularly how they conceal themselves within the kernel, and techniques for identifying malicious activities and modifications to the kernel environment.
CNIT 126: 10: Kernel Debugging with WinDbg
- 1. Practical Malware Analysis Ch 10: Kernel Debugging with WinDbg Updated 10-23-18
- 2. WinDbg v. OllyDbg • OllyDbg is the most popular user-mode debugger for malware analysts • WinDbg can be used in either user-mode or kernel-mode • This chapter explores ways to use WinDbg for kernel debugging and rootkit analysis
- 3. Drivers and Kernel Code
- 4. Device Drivers • Windows device drivers allow third-party developers to run code in the Windows kernel • Drivers are difficult to analyze – They load into memory, stay resident, and respond to requests from applications • Applications don't directly access kernel drivers – They access device objects which send requests to particular devices
- 5. Devices • Devices are not physical hardware components • They are software representations of those components • A driver creates and destroys devices, which can be accessed from user space
- 6. Example: USB Flash Drive • User plugs in flash drive • Windows creates the F: drive device object • Applications can now make requests to the F: drive (such as read and write) – They will be sent to the driver for that USB flash drive • User plugs in a second flash drive – It may use the same driver, but applications access it through the G: drive
- 7. Loading DLLs (Review) • DLLs are loaded into processes • DLLs export functions that can be used by applications • Using the export table • When a function loads or unloads the library, it calls DLLMain • Link Ch 10n
- 8. Loading Drivers • Drivers must be loaded into the kernel – When a driver is first loaded, its DriverEntry procedure is called – To prepare callback objects – Just like DLLMain for DLLs – Links Ch 10n, 10o, 10p
- 9. 9
- 10. DLLs v. Drivers • DLL • Loads into memory when a process is launched • Executes DLLMain at loadtime • Prepares the export table • Driver • Loads into kernel when hardware is added • Executes DriverEntry at loadtime • Prepares callback functions and callback objects
- 11. DriverEntry • DLLs expose functionality through the export table; drivers don't • Drivers must register the address for callback functions – They will be called when a user-space software component requests a service – DriverEntry routine performs this registration – Windows creates a driver object structure, passes it to DriverEntry which fills it with callback functions – DriverEntry then creates a device that can be accessed from user-land
- 12. Example: Normal Read • Normal read request – User-mode application obtains a file handle to device – Calls ReadFile on that handle – Kernel processes ReadFile request – Invokes the driver's callback function handling I/O
- 13. Malicious Request • Most common request from malware is DeviceIoControl – A generic request from a user-space module to a device managed by a driver – User-space program passes in an arbitrary- length buffer of input data – Received an arbitrary-length buffer of data as output
- 15. 15
- 16. Ntoskrnl.exe & Hal.dll • Malicious drivers rarely control hardware • They interact with Ntoskrnl.exe & Hal.dll – Ntoskrnl.exe has code for core OS functions – Hal.dll has code for interacting with main hardware components • Malware will import functions from one or both of these files so it can manipulate the kernel
- 18. Setting Up Kernel Debugging
- 19. VMware • In the virtual machine, enable kernel debugging • Configure a virtual serial port between VM and host • Configure WinDbg on the host machine
- 20. Boot.ini • The book activates kernel debugging by editing Boot.ini • But Microsoft abandoned that system after Windows XP • The new system uses bcdedit
- 21. bcdedit
- 24. 24 Run LiveKD • Instructions for Windows Server 2016 x64 • Download livekd from https://docs.microsoft.com/en-us/ sysinternals/downloads/livekd • Put livekd.exe in C:Program Files (x86)Windows Kits10Debuggersx64 • Run from that directory
- 25. 25
- 26. Using WinDbg • Command-Line Commands
- 27. Reading from Memory • dx addressToRead • x can be – da Displays as ASCII text – du Displays as Unicode text – dd Displays as 32-bit double words • da 0x401020 – Shows the ASCII text starting at 0x401020
- 28. Editing Memory • ex addressToWrite dataToWrite • x can be – ea Writes as ASCII text – eu Writes as Unicode text – ed Writes as 32-bit double words
- 29. Using Arithmetic Operators • Usual arithmetic operators + - / * • dwo reveals the value at a 32-bit location pointer • du dwo (esp+4) – Shows the first argument for a function, as a wide character string
- 30. Setting Breakpoints • bp sets breakpoints • You can specify an action to be performed when the breakpoint is hit • g tells it to resume running after the action • bp GetProcAddress "da dwo(esp+8); g" – Breaks when GetProcAddress is called, prints out the second argument, and then continues – The second argument is the function name
- 31. No Breakpoints with LiveKD • LiveKD works from a memory dump • It's read-only • So you can't use breakpoints
- 32. Listing Modules • lm – Lists all modules loaded into a process • Including EXEs and DLLs in user space • And the kernel drivers in kernel mode – As close as WinDbg gets to a memory map • lm m disk – Shows the disk driver
- 33. Reading from Memory • dd nt • Shows the start of module "nt" • dd nt L10 • Shows the first 0x10 words of "nt"
- 35. Online Help • .hh dd – Shows help about "dd" command – But there are no examples
- 36. More Commands • r • Dump all registers • Link Ch 10m
- 39. Symbols are Labels • Including symbols lets you use – MmCreateProcessAddressSpace • instead of – 0x8050f1a2
- 40. Searching for Symbols • moduleName!symbolName – Can be used anywhere an address is expected • moduleName – The EXE, DLL, or SYS filename (without extension) • symbolName – Name associated with the address • ntoskrnl.exe is an exception, and is named nt – Ex: u nt!NtCreateProcess • Unassembles that function (disassembly)
- 41. Demo • Try these – u nt!ntCreateProcess – u nt!ntCreateProcess L10 – u nt!ntCreateProcess L20
- 42. Deferred Breakpoints • bu newModule!exportedFunction – Will set a breakpoint on exportedFunction as soon as a module named newModule is loaded • $iment – Function that finds the entry point of a module • bu $iment(driverName) – Breaks on the entry point of the driver before any of the driver's code runs
- 43. Searching with x • You can search for functions or symbols using wildcards • x nt!*CreateProcess* – Displays exported functions & internal functions
- 44. Listing Closest Symbol with ln • Helps in figuring out where a call goes • ln address – First lines show two closest matches – Last line shows exact match
- 45. Viewing Structure Information with dt • Microsoft symbols include type information for many structures – Including undocumented internal types – They are often used by malware • dt moduleName!symbolName • dt moduleName!symbolName address – Shows structure with data from address
- 47. Demo • Try these – dt nt!_DRIVER_OBJECT – dt nt!_DEVICE_OBJECT
- 48. Show Specific Values for the "Beep" Driver
- 49. Initialization Function • The DriverInit function is called first when a driver is loaded • See labelled line in previous slide • Malware will sometimes place its entire malicious payload in this function
- 50. Configuring Windows Symbols • If your debugging machine is connected to an always-on broadband link, you can configure WinDbg to automatically download symbols from Microsoft as needed • They are cached locally • File, Symbol File Path – SRC*c:websymbols*http:// msdl.microsoft.com/download/symbols
- 51. Manually Downloading Symbols • Link Ch 10a
- 53. Kernel Debugging in Practice
- 54. Kernel Mode and User Mode Functions • We'll examine a program that writes to files from kernel space • An unusual thing to do • Fools some security products – Kernel mode programs cannot call user-mode functions like CreateFile and WriteFile – Must use NtCreateFile and NtWriteFile
- 55. User-Space Code Creates a service with the CreateService function dwServiceType is 0x01 (Kernel driver)
- 56. User-Space Code • Not shown: edi being set to – .FileWriterDevice
- 57. User-Space Code
- 58. Kernel-Mode Code • Set WinDbg to Verbose mode (View, Verbose Output) • Doesn't work with LiveKD • You'll see every kernel module that loads • Kernel modules are not loaded or unloaded often – Any loads are suspicious – Except Kmixer.sys in VMware machines
- 59. 59
- 60. Kernel-Mode Code • !drvobj command shows driver object
- 61. Kernel-Mode Code • dt command shows structure
- 62. Kernel-Mode Filenames • Tracing this function, it eventually creates this file – DosDevicesC:secretfile.txt • This is a fully qualified object name – Identifies the root device, usually DosDevices
- 63. Finding Driver Objects • Applications work with devices, not drivers • Look at user-space application to identify the interesting device object • Use device object in User Mode to find driver object in Kernel Mode • Use !devobj to find out more about the device object • Use !devhandles to find application that use the driver
- 64. Rootkits
- 65. Rootkit Basics • Rootkits modify the internal functionality of the OS to conceal themselves – Hide processes, network connections, and other resources from running programs – Difficult for antivirus, administrators, and security analysts to discover their malicious activity • Most rootkits modify the kernel • Most popular method: – System Service Descriptor Table (SSDT) hooking
- 66. System Service Descriptor Table (SSDT) • Used internally by Microsoft – To look up function calls into the kernel – Not normally used by third-party applications or drivers • Only three ways for user space to access kernel code – SYSCALL – SYSENTER – INT 0x2E
- 67. SYSENTER • Used by modern versions of Windows • Function code stored in EAX register • More info about the three ways to call kernel code is in links Ch 10j and 10k
- 68. Example from ntdll.dll • EAX set to 0x25 • Stack pointer saved in EDX • SYSENTER is called
- 69. SSDT Table Entries • Rootkit changes the values in the SSDT so rootkit code is called instead of the intended function • 0x25 would be changed to a malicious driver's function
- 70. Hooking NtCreateFile • Rootkit calls the original NtCreateFile, then removes files it wants to hide • This prevents applications from getting a handle to the file • Hooking NtCreateFile alone won't hide a file from DIR, however
- 71. Rootkit Analysis in Practice • Simplest way to detect SSDT hooking – Just look at the SSDT – Look for values that are unreasonable – In this case, ntoskrnl.exe starts at address 804d7000 and ends at 806cd580 – ntoskrnl.exe is the Kernel! • lm m nt – Lists modules matching "nt" (Kernel modules) – Shows the SSDT table (not in Win 2008 in LiveKD)
- 72. Win 2008 • lm m nt failed on my Win 2008 VM • This command shows the SSDT • dps nt!KiServiceTable L poi nt! KiServiceLimit • Link Ch 10l
- 73. SSDT Table • Marked entry is hooked • To identify it, examine a clean system's SSDT
- 74. Finding the Malicious Driver • lm – Lists open modules – In the kernel, they are all drivers
- 76. Interrupts • Interrupts allow hardware to trigger software events • Driver calls IoConnectInterrupt to register a handler for an interrupt code • Specifies an Interrupt Service Routine (ISR) – Will be called when the interrupt code is generated • Interrupt Descriptor Table (IDT) – Stores the ISR information – !idt command shows the IDT
- 78. Loading Drivers • If you want to load a driver to test it, you can download the OSR Driver Loader tool
- 79. Kernel Issues for Windows Vista, Windows 7, and x64 Versions • Uses BCDedit instead of boot.ini • x64 versions starting with XP have PatchGuard – Prevents third-party code from modifying the kernel – Including kernel code itself, SSDT, IDT, etc. – Can interfere with debugging, because debugger patches code when inserting breakpoints • There are 64-bit kernel debugging tools – Link Ch 10c
- 80. Driver Signing • Enforced in all 64-bit versions of Windows starting with Vista • Only digitally signed drivers will load • Effective protection! • Kernel malware for x64 systems is practically nonexistent – You can disable driver signing enforcement by specifying nointegritychecks in BCDEdit