Rootkits What they are and how to find

Rootkits: What they are and how to find them Part 2 Xeno Kovah – 2010 xkovah at gmail 1

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

System Calls Revisited • You need to see the full path, and know that attackers can hook basically everywhere along the path. 3

Conceptual Separation of Duties Hardware Read. Sector(123) Data Kernel Open. File(Pv. Z. exe) User Memory Mapped File Userspace Open Vid-yo-game! 4

Conceptual Separation of Duties Hardware Read. Sector(423) Data Kernel Read. Key(HKLMBla) User Registry Information Userspace Open Vid-yo-game! 5

Conceptual System Call Interface Nt. Read. Key() Nt. Write. File() Kernel Nt. Shutdown. System() Nt. Open. Semaphore() Userspace Read. Key() Write. File() Shutdown. System() User Yay Comp-utors! Open. Semaphore() 6

Slightly More Accurate System Call Interface Nt. Read. Key() Nt. Write. File() Kernel Nt. Shutdown. System() Nt. Open. Semaphore() Ki. Fast. Call. Entry() or Ki. System. Service() ntdll. dll Read. Key() Write. File() Shutdown. System() User Yay Comp-utors! Open. Semaphore() 7

Kernel User Ntdll. dll Nt. Write. File(){ mov eax, 0 x 112 int 0 x 2 E OR sysenter } Kernel 32. dll Write. File(){ Call IAT: Nt. Write. File() } Start Here My. App. exe … Call IAT: Write. File() … Hook inline at target (seen it) Hook IAT (seen it) 8

The INT 0 x 2 E path is the Win 2 k path ntoskrnl. exe … Ki. System. Service(){ } IDT From userspace INT 0 x 2 E Ki. System. Service Hook IDT (seen it) Kernel User 9

The sysenter path is the > Win 2 k path Ki. Fast. Call. Entry != Ki. System. Service ntoskrnl. exe … Ki. Fast. Call. Entry(){ } From userspace sysenter Kernel User Hook sysenter (IA 32_SYSENTER_EIP MSR) new 10

unused IIS spud. sys (if installed and running) unused Win 32 k. sys API Native API Ke. Service. Descriptor. Table. Shadow ntoskrnl. exe … Ki. System. Service() or Ki. Fast. Call. Entry(){ * Consult Thread Info * Extract address of System Service Descriptor Table (SSDT) which is Ke. Service. Descriptor. Table normally or Ke. Service. Descriptor. Table. Shadow if the process has used any graphical (GDI) routines * Parse eax for specific table entry } Kernel User 11

unused IIS spud. sys (if installed and running) unused Native API struct System. Service. Descriptor. Table{ PULONG_PTR Service. Table. Base; PULONG Service. Counter. Table. Base; ULONG Number. Of. Services; PUCHAR Param. Table. Base; }; Index to function mappings change between releases to discourage assumptions and SSDT hooking … 0 x 112 - nt!Nt. Write. File … 1 - nt!Nt. Access. Check 0 - nt!Nt. Accept. Connect. Port Ke. Service. Descriptor. Table service number = eax = 0 x 112 0000010010 2 bits table index Kernel User 12 bits service index 12

… 0 x 112 - nt!Nt. Write. File … Hook SSDT (new) ntoskrnl. exe … Nt. Write. File(){ } Hook inline at target 1 - nt!Nt. Access. Check 0 - nt!Nt. Accept. Connect. Port 13

Kernel User GDI 32. dll Nt. Gdi. Update. Colors(){ mov eax, 0 x 112 E int 0 x 2 E OR sysenter } Update. Colors(){ Call IAT: Nt. Gdi. Update. Colors () } Start Here My. App. exe … Call IAT: Update. Colors() … Hook inline at target (seen it) Hook IAT (seen it) 14

unused IIS spud. sys (if installed and running) unused Win 32 k. sys API Native API Ke. Service. Descriptor. Table. Shadow ntoskrnl. exe … Ki. System. Service() or Ki. Fast. Call. Entry(){ * Consult Thread Info * Extract address of System Service Descriptor Table (SSDT) which is Ke. Service. Descriptor. Table normally or Ke. Service. Descriptor. Table. Shadow if the process has used any graphical (GDI) routines * Parse eax for specific table entry } Kernel User 15

unused IIS spud. sys (if installed and running) Win 32 k. sys API struct System. Service. Descriptor. Table{ PULONG_PTR Service. Table. Base; PULONG Service. Counter. Table. Base; ULONG Number. Of. Services; PUCHAR Param. Table. Base; }; Index to function mappings change between releases to discourage assumptions and SSDT hooking … 0 x 12 E - win 32 k!Nt. Gdi. Update. Colors … 1 - win 32 k!Nt. Gdi. Abort. Path 0 - win 32 k!Nt. Gdi. Abort. Doc Native API Ke. Service. Descriptor. Table. Shadow service number = eax = 0 x 112 E 0100101110 2 bits table index Kernel User 12 bits service index 16

Hook SSDT (new) … 0 x 12 E - win 32 k!Nt. Gdi. Update. Colors … win 32 k. sys … Nt. Gdi. Update. Colors(){ } Hook inline at target 1 - win 32 k!Nt. Gdi. Abort. Path 0 - win 32 k!Nt. Gdi. Abort. Doc 17

Big Picture … … Ke. Service. Descriptor. Table win 32 k Ke. Service. Descriptor. Table. Shadow nt … 2 e kernel user IDT Ki. System. Service … Ki. Fast. Call. Entry INT 2 e (depending on Windows/HW version) Ntdll. dll Kernel 32. dll My. App. exe sysenter (depending on WindowsHW version) 18

O. M. G. it's Yoshi!!! … (and Mario is doing the splits) … Ke. Service. Descriptor. Table win 32 k Ke. Service. Descriptor. Table. Shadow nt … kernel user Ki. System. Service … Ki. Fast. Call. Entry INT 2 e Ntdll. dll sysenter Kernel 32. dll My. App. exe 19

Nu 2 U - sysenter • We never talked about the sysenter instruction in Intermediate x 86, due to lack of time, even though it would work well in that class. • Sort of as a background notion when we were talking about interrupts that they were 1) a way for hardware to get the CPU's attention, and 2) a way to get some kernel code to execute (Break. On. Thru. To. The. Other. Side lab, discussion of interrupts underlying debugging. ) • So "back in the day" systems would implement the "system call table"(*nix) or "system service descriptor table" (Windows) as a way for userspace code to ask the kernel to do specific actions for it. E. g. open a file, allocate some memory, • This was achieved by putting a system call number in some register and then calling int 0 x 80 (linux), or int 0 x 2 e (Windows). The code on the kernel side would then just check the designated register(s) which were input parameters and call the appropriate kernel library function. 20 Book page 279, 321

Out with the old, in with the Nu 2 U • Intel and AMD introduced a specific instruction for achieving this same sort of system call table capability for kernels, but doing it more efficiently. • The instructions for doing this are syscall/sysret on AMD and sysenter/sysexit on Intel. • Linux used int 0 x 80 <= 2. 4, and sys* >= 2. 5, Windows used int 0 x 2 e <= Win 2 k, sys* >= XP 21

Mi. Se. Rly Mi. Se. Ry Mi. Santh. Ropy • The syscall/sysenter instructions basically just jump to a predefined location in the kernel ala an interrupt. That location is predefined by using a "Model Specific Register" (MSR) • MSRs are special registers which exist on specific models and have specific purposes (not a "general purpose" register like eax, ebx, etc. ) • You read and write MSRs with "rdmsr" (read msr) and "wrmsr“ (write MSR) • IA 32_SYSENTER_EIP = 0 x 176 22

Mi. Se. Rly Mi. Se. Ry Mi. Santh. Ropy • IA 32_SYSENTER_EIP = 0 x 176 • Reading from the MSR – mov ecx, 0 x 176 – rdmsr – (eax now contains value that was in the MSR) • Writing a MSR – – mov eax, 0 xdeadbeef mov ecx, 0 x 176 wrmsr (IA 32_SYSENTER_EIP now holds the value 0 xdeadbeef) 23

More about system calls • For more into on int vs sys*, as well as how interrupts work and worked on Windows: – How Do Windows NT System Calls REALLY Work? - http: //www. codeguru. com/Cpp/WP/system/devicedriverdevelopment/article. php/ c 8035/ – System Call Optimization with the SYSENTER Instruction - http: //www. codeguru. com/cpp/wp/system/devicedriverdevelopment/print. php/c 8223 • It's going to make a whole lot more sense thanks to Intermediate x 86 : ) 24

Noo. Too. Yoo - SSDT • Win. Dbg command to print tables: • !for_each_thread ". echo Thread: @#Thread; dt nt!_kthread Service. Table @#Thread" • (from http: //www. securabit. com/wpcontent/uploads/2010/03/Rootkit. Analysis-Hiding-SSDT-Hooks 1. pdf) 25 Book page 286, 324

Ke. Add. System. Service. Table() • He 4 Hook uses Ke. Add. System. Service. Table() (which was first talked about in Hoglund's NT Rootkit phrack article) to talk from its userspace component to kernel • Ke. Add. System. Service. Table() adds in one of those System. Service. Descriptor. Table structs onto the table pointed to by Ke. Service. Descriptor. Table. Shadow 26

He 4 Hook Ke. Add. System. Service. Table ASSUMING NO IIS INSTALLED unused He 4 Hook table Win 32 k. sys API Native API Ke. Service. Descriptor. Table. Shadow before Ke. Add. System. Service. Table() ASSUMING IIS INSTALLED Ke. Service. Descriptor. Table. Shadow after Ke. Add. System. Service. Table() unused He 4 Hook table IIS spud. sys Win 32 k. sys API Native API Ke. Service. Descriptor. Table. Shadow before Ke. Add. System. Service. Table() Ke. Service. Descriptor. Table. Shadow after Ke. Add. System. Service. Table() 27

SSDT Hook 28 From: http: //www. blackhat. com/presentations/bh-europe-06/bh-eu-06 -Silberman-Butler. pdf

SSDT Hook hehehe 29 From: http: //www. blackhat. com/presentations/bh-europe-06/bh-eu-06 -Silberman-Butler. pdf

SSDT False Positives (go look at the overall SSDT results again at this point) How you could determine these are due to symantec and not a rootkit is given in the tiddlywiki file in the class materials 30

Nou. Tou. You - IRP • Windows uses an abstraction called IO Request Packets (IRPs) in order to send events to and from hardware IO devices. • Drivers can attach to devices with Io. Attach. Device. To. Device. Stack(), which is how they indicate that they would like to hear about IRPs to/from a specific device. • They can also just not attach to the stack, and instead intercept the calls to someone who's already attached. 31 Book page 325, 457

A tale of two objects • Driver Object – Every driver gets this object passed to it when it's loaded as the first parameter of the required driver entry point function • Device Object – Used to create a linked list which holds the other devices for other drivers which want to hear about IRP activity 32

IRP chain Driver Objects Device Objects "DriverCtrl 2 Cap" "" "DriverKbdclass" "Keyboard. Class 0" "Driveri 8042 prt" "" "DriverACPI" "00000071" 33

DRIVER_OBJECT struct (on XP) lkd> dt nt!_DRIVER_OBJECT +0 x 000 Type : Int 2 B +0 x 002 Size : Int 2 B +0 x 004 Device. Object : Ptr 32 _DEVICE_OBJECT +0 x 008 Flags : Uint 4 B +0 x 00 c Driver. Start : Ptr 32 Void +0 x 010 Driver. Size : Uint 4 B +0 x 014 Driver. Section : Ptr 32 Void +0 x 018 Driver. Extension : Ptr 32 _DRIVER_EXTENSION +0 x 01 c Driver. Name : _UNICODE_STRING +0 x 024 Hardware. Database : Ptr 32 _UNICODE_STRING +0 x 028 Fast. Io. Dispatch : Ptr 32 _FAST_IO_DISPATCH +0 x 02 c Driver. Init : Ptr 32 long +0 x 030 Driver. Start. Io : Ptr 32 void +0 x 034 Driver. Unload : Ptr 32 void +0 x 038 Major. Function : [28] Ptr 32 long 34

DEVICE_OBJECT struct (on XP) http: //msdn. microsoft. com/en-us/library/ff 543147(v=vs. 85). aspx typedef struct _DEVICE_OBJECT { CSHORT Type; USHORT Size; LONG Reference. Count; struct _DRIVER_OBJECT * Driver. Object; struct _DEVICE_OBJECT * Next. Device; struct _DEVICE_OBJECT * Attached. Device; struct _IRP * Current. Irp; PIO_TIMER Timer; ULONG Flags; ULONG Characteristics; __volatile PVPB Vpb; PVOID Device. Extension; DEVICE_TYPE Device. Type; CCHAR Stack. Size; union { LIST_ENTRY List. Entry; WAIT_CONTEXT_BLOCK Wcb; } Queue; ULONG Alignment. Requirement; KDEVICE_QUEUE Device. Queue; KDPC Dpc; ULONG Active. Thread. Count; PSECURITY_DESCRIPTOR Security. Descriptor; KEVENT Device. Lock; USHORT Sector. Size; USHORT Spare 1; struct _DEVOBJ_EXTENSION * Device. Object. Extension; PVOID Reserved; } DEVICE_OBJECT, *PDEVICE_OBJECT; "Next. Device: A pointer to the next device object, if any, that was created by the same driver. The I/O manager updates this list at each successful call to Io. Create. Device or Io. Create. Device. Secure. " "The device object that is pointed to by the Attached. Device member typically is the device object of a filter driver, which intercepts I/O requests originally targeted to the device represent by the device object. " 35

IRP struct (see wdm. h for comments on fields) kd> dt _IRP ntdll!_IRP +0 x 000 Type : Int 2 B +0 x 002 Size : Uint 2 B +0 x 004 Mdl. Address : Ptr 32 _MDL +0 x 008 Flags : Uint 4 B +0 x 00 c Associated. Irp : __unnamed +0 x 010 Thread. List. Entry : _LIST_ENTRY +0 x 018 Io. Status : _IO_STATUS_BLOCK +0 x 020 Requestor. Mode : Char +0 x 021 Pending. Returned : UChar +0 x 022 Stack. Count : Char +0 x 023 Current. Location : Char +0 x 024 Cancel : UChar +0 x 025 Cancel. Irql : UChar +0 x 026 Apc. Environment : Char +0 x 027 Allocation. Flags : UChar +0 x 028 User. Iosb : Ptr 32 _IO_STATUS_BLOCK +0 x 02 c User. Event : Ptr 32 _KEVENT +0 x 030 Overlay : __unnamed +0 x 038 Cancel. Routine : Ptr 32 void +0 x 03 c User. Buffer : Ptr 32 Void +0 x 040 Tail : __unnamed 36

I am the very model of a modern major function bla (in parody, it's important to maintain the correct number of syllables…wes : P) • Major. Function[] is an array of callback functions which will be called when IRPs are traversing the chain. • This table is the target for function pointer hooking, in both legitimate and illegitimate software. So just like with the SSDT, you have to be aware of what 3 rd party software might be hooking it. 37

major functions (from wdm. h) http: //msdn. microsoft. com/en-us/library/ff 550710. aspx #define IRP_MJ_CREATE 0 x 00 #define IRP_MJ_CREATE_NAMED_PIPE 0 x 01 #define IRP_MJ_CLOSE 0 x 02 #define IRP_MJ_READ 0 x 03 #define IRP_MJ_WRITE 0 x 04 #define IRP_MJ_QUERY_INFORMATION 0 x 05 #define IRP_MJ_SET_INFORMATION 0 x 06 #define IRP_MJ_QUERY_EA 0 x 07 #define IRP_MJ_SET_EA 0 x 08 #define IRP_MJ_FLUSH_BUFFERS 0 x 09 #define IRP_MJ_QUERY_VOLUME_INFORMATION 0 x 0 a #define IRP_MJ_SET_VOLUME_INFORMATION 0 x 0 b #define IRP_MJ_DIRECTORY_CONTROL 0 x 0 c #define IRP_MJ_FILE_SYSTEM_CONTROL 0 x 0 d #define IRP_MJ_DEVICE_CONTROL 0 x 0 e 38

major functions 2 (from wdm. h) #define IRP_MJ_INTERNAL_DEVICE_CONTROL 0 x 0 f #define IRP_MJ_SHUTDOWN 0 x 10 #define IRP_MJ_LOCK_CONTROL 0 x 11 #define IRP_MJ_CLEANUP 0 x 12 #define IRP_MJ_CREATE_MAILSLOT 0 x 13 #define IRP_MJ_QUERY_SECURITY 0 x 14 #define IRP_MJ_SET_SECURITY 0 x 15 #define IRP_MJ_POWER 0 x 16 #define IRP_MJ_SYSTEM_CONTROL 0 x 17 #define IRP_MJ_DEVICE_CHANGE 0 x 18 #define IRP_MJ_QUERY_QUOTA 0 x 19 #define IRP_MJ_SET_QUOTA 0 x 1 a #define IRP_MJ_PNP 0 x 1 b #define IRP_MJ_PNP_POWER IRP_MJ_PNP #define IRP_MJ_MAXIMUM_FUNCTION 0 x 1 b // Obsolete. . 39

Device. Tree • http: //www. osronline. com/article. cfm? article=97 40

Win. Dbg (display device driver stack) kd> !object devicekeyboardclass 0 Object: 814 e 7 d 28 Type: (819 b 8 ca 0) Device Object. Header: 814 e 7 d 10 (old version) Handle. Count: 0 Pointer. Count: 3 Directory Object: e 1006948 Name: Keyboard. Class 0 kd> !devstack 814 e 7 d 28 !Dev. Obj !Drv. Obj !Dev. Ext Object. Name > 814 e 7 d 28 DriverKbdclass 814 e 7 de 0 Keyboard. Class 0 814 e 7020 Driveri 8042 prt 814 e 70 d 8 8167 c 030 DriverACPI 819 a 32 e 8 00000070 !Dev. Node 818 f 7348 : Device. Inst is "ACPIPNP 03034&5289 e 18&0" Service. Name is "i 8042 prt" 41

Win. Dbg 2 (display driver object) kd> !devobj 814 e 7 d 28 Device object (814 e 7 d 28) is for: Keyboard. Class 0 DriverKbdclass Driver. Object 814 ea 0 b 8 Current Irp 0000 Ref. Count 0 Type 0000000 b Flags 00002044 Dacl e 13 cf 7 cc Dev. Ext 814 e 7 de 0 Dev. Obj. Ext 814 e 7 ec 0 Extension. Flags (00000) Attached. To (Lower) 814 e 7020 Driveri 8042 prt Device queue is not busy. kd> dt nt!_DRIVER_OBJECT 814 ea 0 b 8 +0 x 000 Type : 4 +0 x 002 Size : 168 +0 x 004 Device. Object : 0 x 81872030 _DEVICE_OBJECT +0 x 008 Flags : 0 x 12 +0 x 00 c Driver. Start : 0 xf 9 c 4 c 000 +0 x 010 Driver. Size : 0 x 6000 +0 x 014 Driver. Section : 0 x 819 b 7 aa 8 +0 x 018 Driver. Extension : 0 x 814 ea 160 _DRIVER_EXTENSION +0 x 01 c Driver. Name : _UNICODE_STRING "DriverKbdclass" +0 x 024 Hardware. Database : 0 x 80670 de 0 _UNICODE_STRING "REGISTRYMACHINEHARDWAREDESCRIPTIONSYSTEM" +0 x 028 Fast. Io. Dispatch : (null) +0 x 02 c Driver. Init : 0 xf 9 c 50610 long kbdclass!Gs. Driver. Entry+0 +0 x 030 Driver. Start. Io : (null) +0 x 034 Driver. Unload : (null) +0 x 038 Major. Function : [28] 0 xf 9 c 4 cdd 0 long kbdclass!Keyboard. Class. Create+0 42

Win. Dbg 3 (display next driver object) kd> !devobj 814 e 7020 Device object (814 e 7020) is for: Driveri 8042 prt Driver. Object 814 ea 410 Current Irp 0000 Ref. Count 0 Type 00000027 Flags 00002004 Dev. Ext 814 e 70 d 8 Dev. Obj. Ext 814 e 7368 Extension. Flags (00000) Attached. Device (Upper) 814 e 7 d 28 DriverKbdclass Attached. To (Lower) 8167 c 030 DriverACPI Device queue is not busy. kd> dt nt!_DRIVER_OBJECT 814 ea 410 +0 x 000 Type : 4 +0 x 002 Size : 168 +0 x 004 Device. Object : 0 x 817 dda 40 _DEVICE_OBJECT +0 x 008 Flags : 0 x 12 +0 x 00 c Driver. Start : 0 xf 9 a 2 c 000 +0 x 010 Driver. Size : 0 xcd 00 +0 x 014 Driver. Section : 0 x 81973070 +0 x 018 Driver. Extension : 0 x 814 ea 4 b 8 _DRIVER_EXTENSION +0 x 01 c Driver. Name : _UNICODE_STRING "Driveri 8042 prt" +0 x 024 Hardware. Database : 0 x 80670 de 0 _UNICODE_STRING "REGISTRYMACHINEHARDWAREDESCRIPTIONSYSTEM" +0 x 028 Fast. Io. Dispatch : (null) +0 x 02 c Driver. Init : 0 xf 9 a 35285 long i 8042 prt!Gs. Driver. Entry+0 +0 x 030 Driver. Start. Io : 0 xf 9 a 2 c 910 void i 8042 prt!I 8 x. Start. Io+0 +0 x 034 Driver. Unload : 0 xf 9 a 32 eb 6 void i 8042 prt!I 8 x. Unload+0 +0 x 038 Major. Function : [28] 0 xf 9 a 2 faa 6 long i 8042 prt!I 8 x. Create+0 43

Win. Dbg 4 (print IRP table) kd> dps 814 ea 410+0 x 38 L 1 C 814 ea 448 f 9 a 2 faa 6 i 8042 prt!I 8 x. Create 814 ea 44 c 804 f 355 a nt!Iop. Invalid. Device. Request 814 ea 450 f 9 a 32 e 18 i 8042 prt!I 8 x. Close 814 ea 454 804 f 355 a nt!Iop. Invalid. Device. Request 814 ea 458 804 f 355 a nt!Iop. Invalid. Device. Request 814 ea 45 c 804 f 355 a nt!Iop. Invalid. Device. Request 814 ea 460 804 f 355 a nt!Iop. Invalid. Device. Request 814 ea 464 804 f 355 a nt!Iop. Invalid. Device. Request 814 ea 468 804 f 355 a nt!Iop. Invalid. Device. Request 814 ea 46 c f 9 a 2 e 1 f 9 i 8042 prt!I 8 x. Flush 814 ea 470 804 f 355 a nt!Iop. Invalid. Device. Request 814 ea 474 804 f 355 a nt!Iop. Invalid. Device. Request 814 ea 478 804 f 355 a nt!Iop. Invalid. Device. Request 814 ea 47 c 804 f 355 a nt!Iop. Invalid. Device. Request 814 ea 480 f 9 a 32 e 4 b i 8042 prt!I 8 x. Device. Control 814 ea 484 f 9 a 2 c 836 i 8042 prt!I 8 x. Internal. Device. Control 814 ea 488 804 f 355 a nt!Iop. Invalid. Device. Request 814 ea 48 c 804 f 355 a nt!Iop. Invalid. Device. Request 814 ea 490 804 f 355 a nt!Iop. Invalid. Device. Request 814 ea 494 804 f 355 a nt!Iop. Invalid. Device. Request 814 ea 498 804 f 355 a nt!Iop. Invalid. Device. Request 814 ea 49 c 804 f 355 a nt!Iop. Invalid. Device. Request 814 ea 4 a 0 f 9 a 337 ea i 8042 prt!I 8 x. Power 814 ea 4 a 4 f 9 a 2 fa 59 i 8042 prt!I 8 x. System. Control 814 ea 4 a 8 804 f 355 a nt!Iop. Invalid. Device. Request 814 ea 4 ac 804 f 355 a nt!Iop. Invalid. Device. Request 814 ea 4 b 0 804 f 355 a nt!Iop. Invalid. Device. Request 814 ea 4 b 4 f 9 a 2 f 990 i 8042 prt!I 8 x. Pn. P dps = display processor-sized pointer (meaning it decides whether it should be 16 -64 bits), as a pointer to a symbol dds = display dword as a pointer to a symbol 44

Stuxnet IRP filtering http: //www. symantec. com/content/en/us/enterprise/media/se curity_response/whitepapers/w 32_stuxnet_dossier. pdf "The driver scans the following filesystem driver objects: File. Systemntfs File. Systemfastfat File. Systemcdfs A new device object is created by Stuxnet and attached to the device chain for each device object managed by these driver objects. The Mrx. Net. sys driver will manage this driver object. By inserting such objects, Stuxnet is able to intercept IRP requests (example: writes, reads, to devices NTFS, FAT or CD-ROM devices). " 45

Stuxnet IRP filtering 2 • "The driver monitors 'directory control' IRPs, in particular 'directory query' notifications. Such IRPs are sent to the device when a user program is browsing a directory, and requests the list of files it contains for instance. " 46

He 4 Hook code (from kirpfilter. cpp) NTSTATUS KIrp. Filter: : Irp. Handler(…){ … if ( dw. Major. Fn == IRP_MJ_DIRECTORY_CONTROL && dw. Minor. Fn == IRP_MN_QUERY_DIRECTORY ) { Nt. Status = On. Query. Directory(p. Irp, p. Irp. Stack, p. Drv. Info); } … } 47

Direct Kernel Object Manipulation (DKOM) (It's a joke see? Since Distributed Component Object Model - DCOM - is a MS technology? ) • Introduced by Jamie Butler in the FU rootkit. http: //www. blackhat. com/presentations/bh-usa 04/bh-us-04 -butler. pdf • Recognized the prevailing technique of hooking was easily detected, so wrote a detector ("VICE - Catch the hookers!" ; )) • DKOM perpetuates the arms race and shows the importance of information asymmetry for rootkits. The attacker reverse engineers a component he finds to be relevant to his goal. Then, having more understanding of the system than the defender, will likely succeed in having the manipulation go undetected. 48 Book page 428, 436

Canonical DKOM • Exploit the fact that the lists which taskmgr. exe or top (on *nix) consult to find running processes, are not the lists that the scheduler uses. Therefore things can be removed from those lists but they will still get to run. • Also manipulates security tokens to elevate process or user privileges. Is DKOM, but isn't about hiding. But just like hooking does not automatically imply rootkit, DKOM can be used for non-rootkit ends 49

Process Linked List Before DKOM 50 From: http: //www. blackhat. com/presentations/win-usa-04/bh-win-04 -butler. pdf

Process Linked List After DKOM 51 From: http: //www. blackhat. com/presentations/win-usa-04/bh-win-04 -butler. pdf

Detecting DKOM • Different tools used different means to detect FU's process hiding. • F-Secure Black. Light used a bruteforce where it calls Open. Process() on all possible PIDs (which behind the scenes is just consulting Psp. Cid. Table, which has a handle for every open process. These handles are not hidden as part of DKOM. ) It then calls Create. Toolhelp 32 Snapshot() as another more traditional way to get a list of processes. Any discrepancy in the lists is deemed a hidden process. • So Peter Silberman introduced FUTo (http: //uninformed. org/index. cgi? v=3&a=7&t=sumry) which bypassed Black. Light by manipulating the Psp. Cid. Table. • Then Butler and Silberman put out RAIDE to detect the FUTo hiding too (using memory signature searching I believe) • Klister by Rutkowska walked the list that the scheduler uses • This is an example of "cross view detection" 52

FWIW: turns out… This change: For the record I emailed the GMER author and he said: "The 32 -bit hex number that is after PID[0] is the EPROCESS structure pointer. In this case GMER cannot identify the name of process. " If you look at my omega. bat in the tiddlywiki install proceedure, you will see that I'm using fu. exe to hide pid 4 ("system"). Sometimes system is called pid 0, sometimes pid 4 (on XP) 53

OS-Provided Callbacks (The ones we want to highlight for the moment anyway. Go to the links and go up one level on the side bar to find more. ) • On registry actions: – Cm. Register. Callback{Ex} – http: //msdn. microsoft. com/en-us/library/ff 541918(v=vs. 85). aspx • On process creation/deletion: – Ps. Set. Create. Process. Notify. Routine{Ex} – http: //msdn. microsoft. com/en-us/library/ff 559951(v=VS. 85). aspx • On thread creation/deletion: – Ps. Set. Create. Thread. Notify. Routine{Ex} – http: //msdn. microsoft. com/en-us/library/ff 559954(v=vs. 85). aspx • On image load (e. g. DLL, EXE, SYS mapped into memory, imports resolved, but entry point not yet called): – Ps. Set. Load. Image. Notify. Routine – http: //msdn. microsoft. com/en-us/library/ff 559957(v=VS. 85). aspx • Filesystem becoming active (to attach to with a filesystem filter driver): – Io. Register. Fs. Registration. Change – http: //msdn. microsoft. com/en-us/library/ff 551037(v=vs. 85). aspx • System Shutdown: – Io. Register. Shutdown. Notification – http: //msdn. microsoft. com/en-us/library/ff 549541. aspx 54

Some example rootkit use of callbacks • He 4 Hook - Po. C – Sets a callback with Ps. Set. Create. Thread. Notify. Routine() (see the source) • FUTo - Po. C – Ps. Set. Create. Process. Notify. Routine() (see source) • Black Energy 2, Rustock – http: //code. google. com/p/volatility/wiki/Command. Reference#notifyroutines – Black Energy Thread notify, Rustock Process notify • Hybrid. Hook - Po. C – Sets a callback with Ps. Set. Load. Image. Notify. Routine() and does IAT hooking at load time (see the source) • TDSS/TDL 3 – http: //www. prevx. com/blog/139/Tdss-rootkit-silently-owns-the-net. html – Ps. Set. Load. Image. Notify. Routine() to inject DLLs • Stuxnet – http: //www. symantec. com/content/en/us/enterprise/media/security_response/whit epapers/w 32_stuxnet_dossier. pdf – "The driver also registers to a filesystem registration callback routine in order to hook newly created filesystem objects on the fly. " 55

Listing registered callbacks in Win. Dbg • http: //analyze-v. com/? p=746 - process/memory image load (Ps. Set. Create. Process. Notify. Routine[Ex]/Ps. Set. Image. Load. Notify. Routine) • http: //analyze-v. com/? p=756 - registry callbacks(Cm. Register. Callback[Ex]) • Here comes a new challenger! Hadoken! • http: //www. moonsols. com/2011/02/17/global-windows-callbacks-and-windbg/ kd> $$>a<c: pscallbacks. wbs ************************ * This command brought to you by Analyze-v. com * ************************ * Printing image load callbacks. . . * ***************************************** * Printing process notification callbacks. . . * *********************** 814 ec 008 ff 2508605 c 81 jmp dword ptr ds: [815 C 6008 h] 56

Listing registered callbacks • Newest Virus Blok Ada anti-rootkit has fairly comprehensive coverage. 57

New. Tew. Yew - Master Boot Record (MBR)-infecting rootkits aka "Bootkits" • e. Eye Bootroot - 2005 – Derek Soeder and Ryan Permeh – From the readme. txt "September 20, 2005: Scott Tenaglia provided a NASM port of the source, included as "ebrknasm. asm". Many folks were not too keen on the MASM requirement, so this is a big boon to Boot. Root. Kit users at large. Thanks Scott!" • VBootkit - 2007, Vbootkit 2 - 2009 – Nitin Kumar and Vipin Kumar • Stoned Bootkit - 2009 – Peter Kleissner 58 Book page 380

What does an MBR actually look like? • http: //thestarman. narod. ru/asm/mbr/Win 2 kmbr. htm • http: //thestarman. narod. ru/asm/mbr/Vist a. MBR. htm 59

Bootkit Lives here (from disk), but in order to do anything of consequence it has to keep hooking each subsequent thing to keep control. 60 From http: //www. stoned-vienna. com/downloads/Presentation. pdf

e. Eye Boot Root • http: //www. eeye. com/Resources/Securit y-Center/Research/Tools/Boot. Root • The first Po. C, didn't actually change the MBR on the HD, instead booted from a disk which redirected to the normal boot process, hooking as it went. 61

VBoot. Kit • Coined the term "bootkit" for master boot record infecting rootkits • Vbootkit – http: //www. blackhat. com/presentations/bh-europe 07/Kumar/Presentation/bh-eu-07 -kumar-apr 19. pdf – First thing supporting Vista • Vbootkit 2 – http: //conference. hitb. org/hitbsecconf 2009 dubai/materials/D 2 T 2%20 -%20 Vipin%20 and%20 Nitin%20 Kumar%20%20 vbootkit%202. 0. pdf – First thing to support boot subversion on Windows 7 x 64 – Payload includes disabling code signing & kernel patch protection (KPP aka Patch. Guard) 62

Stoned Bootkit • http: //www. stoned-vienna. com • Basically a weaponized bootkit…so, surprise, it got used in real malware, and the German cops came knocking (illegal to distribute "hacking tools" in Germany). So now he doesn't distribute the full thing. • Highly module to support many possible payloads • Has a customization to work in the presence of True. Crypt 63

bootkits in the wild • http: //www 2. gmer. net/mbr/ – Good dissection (w comparison to e. Eye boot root) – Also shows adding one nop to asm bypassed MS, Kaspersky, F-Secure, and Sophos detection circa 2008 • Mebroot w/ Torpig/Sinowal – http: //www. symantec. com/security_response/writeup. js p? docid=2008 -010718 -3448 -99 – http: //www. fsecure. com/weblog/archives/00001393. html • IRP hooking. How droll. How easy peasy • TDSS/TDL 3 – http: //www. prevx. com/blog/139/Tdss-rootkit-silentlyowns-the-net. html • IRP hooking. How droll. How easy peasy 64

Detecting bootkits • http: //www 2. gmer. net/mbr. exe (though I think GMER has that mostly built in now) • Trend. Micro Rootkit. Buster claims to have removal • Remove with "fixmbr" command from a windows install disk recovery mode • Turn on your damn TPM! This, and bios subversion, are the whole reason we have trusted boot! – Get ins. Pe. Cto. R from Corey Kallenberg – or 65

An “Integrity Measured” Boot Process OS TIME OS Loader • Measure and store (PCR-4) OS components, other TCBrelevant stuff • System runs normally! • Measure OS Components • Append PCR-3 with measurement • Pass control to OS BIOS • Measure Option ROMs • Append PCR-1 with measurement--pass control, get it back • Measure OS Loader, append PCR-2, pass control CRTM • Core Root of Trust for Measurement, (e. g. BIOS block) • Measure itself and BIOS • Append PCR-0 with hash of measurement Hardware • Clear PCRs—not really configurable 66

Loading code into kernel • Service Control Manager (SCM) – Leaves registry footprint • Zw. Set. System. Information() • - http: //seclists. org/bugtraq/2000/Aug/408 • - http: //www. nvlabs. in/archives/6 -Loading-drivers-and. Native-applications-from-kernel-mode, -without-touchingregistry. html • Zw. Load. Driver() • http: //www. codeproject. com/KB/system/DLoad. aspx – Uses SCM, Zw. Set. System. Information, Zw. Load. Driver • Windows < Vista used to be able to access DevicePhysical. Memory – http: //www. phrack. com/issues. html? issue=59&id=16 67 Book page 198

Autoruns • Sysinternals tool to show the various places on the system that are set to automatically load extra code (either on boot, or when something else is loaded) • http: //technet. microsoft. com/enus/sysinternals/bb 963902 • Recent article "Analyzing a Stuxnet Infection with the Sysinternals Tools, Part 1" – http: //blogs. technet. com/b/markrussinovich/arc hive/2011/03/30/3416253. aspx 68

69