Hunting rootkits with

Windbg v1.1 Windbg v1.1

Frank Boldewin
Scope of this Talk
In the next few slides the audience learns
how to hunt for rootkits with Windbg
To get a good overview of the different was
how rootkits hide itself fro! being
recogni"ed several techni#ues fro! rootkits
$
recogni"ed several techni#ues fro! rootkits
like %unti!e$& %ustock.B& 'lipop& Stuxnet as
well as T()* and T()+ are introduced
,f course the techni#ues used to detect a
special rootkit are not li!ited to the shown
cases. -./
0rere#uisites are a good understanding
about Windows internals and basic Windbg
skills
Finding SS(T hooks
The SS(T is a data arra in kernel !e!or&
that stores pointers to the native '0I
functions of Windows& e.g. 1t2reateFile
These functions are handled in 1T,S3%1)
*
,lder rootkits used to hook so!e distinctive
functions to hide its files or registr entries
when #ueried fro! user!ode
'l!ost ever run.of.the.!ill antirootkit tool
is able to detect such hooks toda
Finding SS(T hooks
4iewing the SS(T !anuall
+
Finding Shadow SS(T hooks
The Shadow SS(T is another arra and stores
pointers to functions in the Win*$k.ss
To view its entries we first have to switch to
a 56I process context and reload the
s!bols for the specific !odule
7
s!bols for the specific !odule
8process 9 9 winlogon.exe
0%,2:SS ;1ebf<f; SessionId= .....
.process >p ;1ebf<f;
.reload
Finding Shadow SS(T hooks
<
Finding Shadow SS(T hooks
To find SS(T and Shadow SS(T hooks auto!aticall we can
use a Windbg script fro! )ionel d?Hauenens of )aboskopia
@
%unti!e$ %ootkit A Finding SS(T>Shadow SS(T hooks with a
Windbg script
;
%ustock.B %ootkit A SBS:1T:%C:I0 hook
The SBS:1T:%C:I0 DES% 9x1@</ usuall points to
3iFast2all:ntr to serve re#uests fro! the user!ode
to access native functions in the SS(T
This pointer gets hooked b the %ustock.B rootkit
If Ssenter gets called %ustock checks in its own S(T
F
If Ssenter gets called %ustock checks in its own S(T
table if a function is hooked or not. 1on hooked
native functions have a null pointer. Hooked
functions have a pointer to its own handler.
To avoid eas hook detections the SsenterC:I0
address points to the sa!e !odule D1T,S3%1).:G:/
as 3iFast2all:ntr.
It overwrites a textstring HF'T')C61H'1():(CH'%(C:%%,%I
with a 7 btes Ju!p to its real rootkit code.
%ustock.B %ootkit A SBS:1T:%C:I0 hook
19
%ustock.B %ootkit A SBS:1T:%C:I0 hook
'nother )aboskopia Windbg co!!and shows us the
hook auto!aticall
11
%ustock.B %ootkit A Finding hidden registr entries
To find the hidden registr entries %ustock uses to
survive a reboot& we walk the windows hive with the
H8regI co!!and and its para!eters
' hive is a logical group of kes& subkes& and values
in the registr that has a set of supporting files K
backup copies
1$
backup copies
Hives are stored as files on disk
1ext to standard hives ever user has his own hives
file
%ustock.B %ootkit A Finding hidden registr entries
Table of standard hives and their supporting files
%egistr hive Supporting files
H3:BC26%%:1TC2,1FI5 Sste!& Sste!.alt& Sste!.log& Sste!.sav
1*
H3:BC26%%:1TC2,1FI5 Sste!& Sste!.alt& Sste!.log& Sste!.sav
H3:BC26%%:1TC6S:% 1tuser.dat& 1tuser.dat.log
H3:BC),2')CE'2HI1:LS'E Sa!& Sa!.log& Sa!.sav
H3:BC),2')CE'2HI1:LSecurit Securit& Securit.log& Securit.sav
H3:BC),2')CE'2HI1:LSoftware Software& Software.log& Software.sav
H3:BC),2')CE'2HI1:LSste! Sste!& Sste!.alt& Sste!.log& Sste!.sav
H3:BC6S:%SL.(:F'6)T (efault& (efault.log& (efault.sav
%ustock.B %ootkit A Finding hidden registr entries
1+
%ustock.B %ootkit A Finding hidden registr entries
17
%ustock.B %ootkit A Finding the Hidden %egistr :ntr
1<
%ustock.B %ootkit A pIof2all(river Hook
Hooks at pIof2all(river are often used to filter
special I%0 re#uests to drivers
%ustock filters an atte!pt to directl co!!unicate
with 1TFS.SBS or F'STF'T.SBS. These files are
hidden& canMt be copied& nor overwritten or rena!ed
1@
%ustock.B %ootkit A I(T hooks
The Interrupt (escriptor Table DI(T/ is a structure
which is used when dispatching interrupts
Interrupts can interrupt an execution of a progra! to
to handle an event
Interrupts could be a result of a hardware signal or
1;
Interrupts could be a result of a hardware signal or
software based using the I1T instruction
The I(T descriptor table can handle $7< entries
The descriptor to the table can be written with the
instruction )I(T and read with SI(T
%ustock hooks I1T $:h& which is usuall pointing to
3iSste!Service& a NwO functions dispatcher and
handler for user!ode I1T $:h calls on old hardware
not supporting fastcalls via the SBS:1T:% co!!and
%ustock.B %ootkit A I1T $:h
%ustock hooks I1T $:h to co!!unicate between
user!ode and kernel!ode co!ponents
The HI(TI co!!and shows us the pointer to the
handler. 3iSste!Service is ok& otherwise itMs hooked
1F
'lipop %ootkit A 5(T 2allgate
' callgate is a !echanis! in Intel x;< arch to change
privilege level of the 206
The 'lipop rootkit installs such a callgate to execute
code with the highest privilege D%ing 9/ fro!
user!ode D%ing */ without the need to have a driver&
e.g. b calling (eviceI,2ontrol
$9
e.g. b calling (eviceI,2ontrol
2allgate usage works b executing Icall far ptr PaddrQR
fro! user!ode code
Installation of the callgate is done b the bootkit part
of 'lipop
,ther !alware seen in the wild used
L(eviceL0hsicalEe!or to install a callgate in the
5(T Dworks onl on older windows versions/
')I0,0 %ootkit A 5(T 2allgate
$1
')I0,0 %ootkit A 5(T 2allgate
$$
T()* %ootkit A 'T'0I I%0 hooks
The T()* rootkit usuall infects the 'T'0I driver
with a s!all loader for the real rootkit code in the 0:
resource area of atapi.ss and changes the
entrpoint to its loader code
The real rootkit part is being stored encrpted on
disk sectors
$*
disk sectors
The loader uses low level disk operations to read the
sectors& decrpts the !ini T() file sste! and starts
the real rootkit code
To hide and protect its sectors T()* uses I%0
hooking in 'T'0I.SBS
T()* %ootkit A 'T'0I I%0 hooks
$+
T()* %ootkit A 'T'0I I%0 hooks
$7
T()* %ootkit A Shared Ee!or structure D3ernel.>6ser !ode/
To share infor!ation with its user!ode co!ponents
T()* uses the structure 36S:%CSH'%:(C('T'
This structure is accessable fro! kernel at address
9xFF(F9999 and is !apped to userspace at
9x@FF:9999
3ernel !ode has read>write access to this structure&
$<
3ernel !ode has read>write access to this structure&
user!ode has onl read access
't 36S:%CSH'%:(C('T'K9*9;h DSste!2all0ad/
T()* stores a pointer to an own structure
This structure stores a bunch of things like
kernelbase& original 'T'0I I%0s& T()* FS start& path
to its config file S
T()* %ootkit A Shared Ee!or structure D3ernel.>6ser !ode/
$@
T()* %ootkit A Shared Ee!or structure D3ernel.>6ser !ode/
$;
T()* %ootkit A T() !ini FS Dfile sste!/
$F
T()* %ootkit A Traces in the sste! worker threads
(rivers re#uiring delaed processing usuall use a
work ite!& using IoTueueWorkIte! with a pointer to
its callback routine
When a sste! worker thread processes the #ueued
ite! it gets re!oved and the callback gets invoked
*9
Sste! worker threads run in the sste! process
context D0I( +/
T()* rootkit is using work ite!s as well
Whenever work ite!s have been processed or other
sste! threads have been created this leaves traces
on the callstack
's T()* does not belong to an known !odule& the
process thread view infor!s us about this proble!
T()* %ootkit A Traces in the sste! worker threads
*1
T()+ %ootkit A Finding T()+ with its invalid device obJect
*$
T()+ %ootkit A 'T'0I (riverStartI, hook
T()+ rootkit hooks the 'T'0I driver as well& but in a
lower level wa than its precedessor
's !ore and !ore tools were easil able to du!p its
files even fro! user!ode via
I,2T)CS2SIC0'SSCTH%,65HC(I%:2T calls directl
to the port device& T()+ changed the hook !ethod to
**
to the port device& T()+ changed the hook !ethod to
(riverStartI,
This !akes it harder to du!p the T()+ files
T()+ %ootkit A 'T'0I (riverStartI, hook
*+
T()+ %ootkit A Finding the 3ernel 2allback with a Windbg script
%ootkits often use kernelcallbacks to get notified
when files are loaded& processes or threads are
created as well as %egistr events occur.
T()+ installs a kernelcallback to inJect its user!ode
paload in distinctive windows processes
*7
T()+ %ootkit A (ropper du!ping after T()+ infection Dbefore
reboot/
*<
T()+ %ootkit A (u!ping inJected user !ode paload
*@
T()+ %ootkit A Finding inline hooks in user !ode paload
*;
Stuxnet %ootkit A Io%ehisterFs%egistration2hange
Stuxnet !rxnet.ss driver adds a new device obJect
and attaches to the device chain with the obJecttpe
LFileSste! Dfastfat& ntfs& cdfs/
' filesste! registration callback !akes it possible to
attach to the device chain for each devobJ !anaged b
these drvobJs
*F
these drvobJs
This !akes it possible to control and intercept I%0
re#uests
Stuxnet %ootkit A Io%egisterFs%egistration2hange
+9
Questions?
Thanks for good discussions and ideas
+1
Eichael Hale )igh
:0CG9FF
2r+sh
Eatthieu Suiche