Revealing Stealth Malware UMD CMSC389M

Revealing Stealth MalwareUMD CMSC389M Xeno Kovah – Jan. 2013 xkovah at gmail Subject line starting with "UMD:"

All materials is licensed under a Creative Commons “Share Alike” license. • http://creativecommons.org/licenses/by-sa/3.0/

Outline • PatchGuard • Review

"PatchGuard" akaKernel Patch Protection • Meant to stop 3rd party software from patching the kernel • Has gone through a number of iterations, but can still be defeated • http://fyyre.ivory-tower.de/ • Specifically disable_pg_ds_v3.rar

Big Picture To Hardware … … KeServiceDescriptorTable win32k KeServiceDescriptorTableShadow nt … KiSystemService … KiFastCallEntry Device Object Driver Object IRP IO Manager kernel IDT user sysenter or syscall (depending on Windows\HW version) INT 2e (depending on Windows/HW version) Ntdll.dll Kernel32.dll MyApp.exe

Tool Time

Import Address Table (IAT) Hooks (GMER) If GMER can, it tries to infer which module space the function pointer is pointing into. And if there's version information in that module, it pulls that out too This is the address in the IAT pointing somewhere other than where it should (based on the Exports Address Table (EAT) of the exporting module This is the module doing the importing This is the function being imported by the first module and exported by the second Telling you that this is an IAT hook This is the module doing the exporting

Telling you that this is an IAT hook This is where the IAT does point (hook target) This is where the IAT should point This is the module doing the exporting This is the module doing the importing This is the module the hook points into This is the function being exported by the first module and imported by the second You probably don't want to use XueTr for inline hooks, because it's much uglier output than gmer

Inline Hooks (GMER) if control flow redirect (call, jmp) module space where it's redirected to if it is within a module address range PE section where the hook resides module within process memory function name within module number of bytes that changed hooked process name interpretation of changed bytes (if possible) specific virtual memory address where the change is found process ID (PID)

Should be self-explainatory GMER doesn't check the shadow SSDT tho, so you would have to use XueTr

FSD = File System Drivers Hook target IRP MajorFunction[] table entry What it should be Target image (if known) Not the actual IRP index. Can be ignored File system driver name

Revealing Stealth Malware UMD CMSC389M