Loading presentation...

Present Remotely

Send the link below via email or IM


Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.


Bootkits on the rise

No description

Peter Hlavaty

on 17 October 2012

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Bootkits on the rise

Bootkits On the Rise What about Boot process contains both partition table and boot code
determine which partition (or hard disk) to boot from
use BIOS INT 13h commands to load the Volume Boot Record
start executing VBR MBR - master boot record test critical aspects of OS
load and run the BOOTMGR "bootstrap"
which end in load and exec Os Loader - winload.exe VBR - volume boot record load ntoskrnl.exe
Enable Paging!
Create PsLoadedModuleList & LOADER_PARAMETER_BLOCK Os Loader - winload.exe ntoskrnl.exe init system via KiSystemStartup()
build SSDT, Page Tables
load hal.dll - HallInitializeBios, HallInitSystem
set IVT
load kdcom.dll
load SERVICE_BOOT_START drivers clasical scenario Points of interest! NTOSKRNL.EXE initialize system!! main goal is get control of system ASAP INT 13 http://en.wikipedia.org/wiki/INT_13H Crucial interrupt

BIOS interface, initial i/o of OS!
INT 13h AH=02h: Read Sectors From Drive
INT 13h AH=03h: Write Sectors To Drive
INT 13h AH=41h: Check Extensions Present
INT 13h AH=43h: Extended Write Sectors to Drive

Commonly hooked
parsing read request & find pattern
osloader - winload.exe is next target for hook interrupt hook code ? MBR / VBR code stored at 0x0:0x7c00
bootstrap code from VBR copied at 0xD00:0x0
bootmgr rewrite most likely both pieces of memory
so, how can int13 hook code survive ?
BIOSDATA 0x40:0x13 (a.k.a. es:0x413) => base memory size in KB!
decrease & copy hook code to "tricky reserved" memory unhook
is INT13 read request ? (ah in (0x2, 0x42) )
find OS Loader (winload.exe) pattern!
hook OS Loader at specified point INT13 hook code OS Loader hook code unhook
important structures created (PsLoadedModuleList, ...)
copy next hook code to ntoskrnl.exe slack space
survive mode switching
hook ntoskrnl.exe wait till OS is initialized (if not yet, then rehook ntoskrnl.exe)
install payload
load rootkit to memory
must be disabled integrity checks
rewrite windows binary (explorer, winlogon, userinit, svchost, ...)
register binary to windows startup ntoskrnl.exe owned == windows owned! FileSystem parser for rewriting binary whithout support of OS Api
Patch (activate) malicious inactive binary
Create ring3-ring0 callgate
protect 'reserved' memory
Debug ntoskrnl.exe instead of [find pattern & hook]
Hook before Os fully initialized Advanced 'features' introduced in Stoned
used in several bootkits in the wild
Unruy, Smytnil, Plite, MbrLoader, Guntior

In MBRLoader.B presented inovative idea
patch malicious binary back to live during boot
original state is non-malicious (EntryPoint on nop slide, etc...)
evade AV techniques (emulation, hips)

+ :
no hooking needed
minimal interference with boot process
- :
low system control FileSystem parser ring3-ring0 callgate first used in malware family of rovnix
and some time ago tested by goblin family
goblin first attempt to infect boot process Another trick how to hide reserved memory ax = 0xe820 -> Query System Address Map
It reports which memory address ranges are usable and which are reserved for use by the BIOS.
it is stealthy problem!

protect own data (resize queried memory -in output record- if contains bootkits data!) INT15 why modify windows code ? :)

Get IDT base addr
set own INT1 handler
set DRx

int1 handler :
check pattern on breakpoint instruction
set new hw breakpoint till not specified state exec yet debug instead of hooking! patch in early state vs PatchGUARD PatchGuard is mittigation against :
rewriting critical structures (IDT, GDT, SSDT)
Using kernel stacks not allocated by the kernel
Modifying or patching code contained within the kernel itself
kernel objects
kernel procedures hooks

and when you will patch in this manner BSOD will appear, because :

Patching the kernel has never been supported by Microsoft
... but ...

when you will patch before PatchGuard is active, protecting new code is exactly what will microsoft PatchGuard support! ;) infect MBR / VBR
hook INT13
hook OSLoader
Patch ntoskrnl.exe, hal.dll
os loader load these to memory, just find it!
PatchGuard is your best friend, ever and ever *introduced in win vista FLAGS P -> Is segment present ? (1 / 0)
DPL -> Descriptor privilage level (ring 0 - 3)
DT -> Descriptor type
Type - > Segment type (code / data)
G -> Granularity (0 = 1byte; 1 = 1kb)
D -> Operand Size (0 = 16b, 1 = 32b)
Rs -> Reserved, should be 0
A -> Available for system use (always 0) CALLGATE (0x8003F3E0)
Routine Address => 0x8003F000
Descryptor => 0x8003F3e8
Flags => 0xEC == 11101100 b
P = 1 (present)
DPL = 11 (ring 3)
Type = 01100 (0xEC default)

Segment Limit => 2^20 == 4GB
Base => 0 == user mode address!
Flags => 0x9A == 10011010 b
P = 1 (present)
DPL = 00 (ring0)
Type = 11010 (0x9a code segment)
Granularity => 0xC == 1100 b
G => 1 (1kb granularity)
D => 1 (32b operand size)

Routine (0x8003F000)
retn -> ret to user space code but in ring-0!! By realworld example call far fword ptr ss:[ebp-6]
how can simlpe call switch from ring3 to ring0
just to know where the callgate is ;) http://blog.eset.com/wp-content/media_files/REcon2012.pdf



uefi -> http://www.intel.com/content/dam/doc/guide/uefi-boot-time-optimizaiton-windows7.pdf

arsenal :

szor art :

www.jamesmolloy.co.uk/tutorial_html/4.-The%20GDT%20and%20IDT.htmlhttp://www.osdever.net/tutorials/view/protected-mode References push ebpmov ebp, esp
add esp ,-8
and dword ptr ss:[ebp-6], 0
movzx eax, word ptr ds:[CALLGATE]
mov word ptr ss:[ebp-2], ax BIOS interrupt calls are used for :
basic i/o requests
for initialize hardware resources

List of BIOS interrupt classes
{int0, ..., int1F, int41, int46, int4A, int70, int74, int75, int76, int77}

Most Interesting interrupts :
INT13 => Low Level Disk Services (read / write sectors, ...)
INT15 => Miscellaneous system services (query system map, switch to protected mode)
INT1 => CPU: Executed after every instruction while the trace flag is set

Interrupt handlers pointers are stored in IVT-table (table of dwords)
BIOS interrupt table offset of pointer INT13 = 0x13 * 4 = 0x4C BIOS interrupt calls
Full transcript