Tip:
Highlight text to annotate it
X
so I was going back and I was
creating snapshots in my VM for one rootkit change at a time
Alright don't infect anyone
you sit right there
he already have this full
alright so the correction was
i was going back and making snapshots
a single rootkit per VM
because Matt asked
yesterday when I eventually go over
you know showing what the changes were actually in the system and
the answer was yes
I figured it'd probably be better if I made some snapshots where I put a single
rootkit in the VM and then ran the tools against it and see all the changes
I start from a known clean VM where there are no hooks and stuff like that
then I just put one thing at a time
so when i was doing that
i was trying to recreate this sort of change
and it turns out that I'd miss described this probably because I was not
particularly rigorous when i was uh...
doing my initial testing
so like i said i thought this was due to
shadow walkers actual hiding of a module and that didn't really jive with what the
author had said
and so
i kind of didn't get it
for when i went back and look at this it turns out this is actually due to
FuTo ("Foo Toe")
or "foo too"
hiding the system process so now it sort of makes sense
to some degree that
that uh...
zero within the square brackets is I believe trying to be the process ID and
that's actually
what he's saying right here that PID zero
is the system quote process
and then be addressed after it is a new process is just saying
the system process itself instead is hidden
and thats actually due to .... not shadow walker
all is well in the world and that makes sense
alright so the second thing was when I was when I was talking about Patch guard yesterday I said I was going to
check if
it is
whether checked if the IAT got hooked or the IAT was changed
and the answer is no it doesn't do any sanity checks of the IAT
also it doesn't look like it's
it checks the code section for just
the kernel itself, NTUSKernel or NT Kernel or NT Kernel PA
checks the kernel, HAL.dll and and ndis.sys which is the networking
component
so it doesn't check
other drivers beyond that
at least according to the quick page that I read
so
that's another point that someone could still go put him on hooks and various
other
components into the system
and patch guard wouldn't actually be stopping that
which is again why it's really
i would say it's really more geared towards you
preventing people from using unsupported mechanisms rather
than trying to be one rootkit detector
you know has some elements of that
i wouldn't say that's its primary purpose
I wanted to talk about WinDBG a little bit today because i didn't
talk about it yesterday
so
a couple times I yesterday said you find a 0:03:20.909,0:03:22.639 particular change so
so let's say this type of change
well let's say
or have been
the tidly wiki kind of goes through this process
the point is
you find some change in your tool and it's not able to help you actually
attribute to
what's causing the change
well this is saying that IDT entry E
is currently
pointing at
at F-9-F-5-5-A-4-0 which is somewhere that
the tool doesn't expect to be pointing
but simultaneously because this happens to be pointing into a hidden module
it's not be able to actually tell you
what it's actually pointing at could but for whatever reason this
it's not syncing it up correctly
and so there becomes this question of how do you actually get down to change
find out whether it's due to malicious software or
third-party software
security software or whatever
and the answer for that is uh...
basically you have to start doing some level of debugging
of inspection system so
i wanted to show
a little bit of
the technique of local
kernel debugging
so some people were trying to use
WinDBG
because we learned about it in previous classes
so in previous classes we saw that you can really
do a deep system inspection
uh... if you attach a kernel debugger but simultaneously they knew they had to
reboot the system and some people were trying to do things entirely without rebooting
but there is a way
uh... that you can
get around that
and do debugging on a system that is live without having to
attach the kernel debug externally
so should all go to your VM and we are going to
download WinDBG
We are actually going to run it within the system
this is not the optimal
way of doing things obviously you wanna
do a normal kernel debugging session when possible
when it's not possible this is the next best thing
just search for
WinDBG download
WinDBG download
and go to the first link assuming your searching with google
so eventually you should
if you got to the right link
debugging tools for windows 32 bit version
there's going to be this link to install
six point eleven point one point four oh four
download that to your desktop
and once it's there go ahead and install it
I going to check around the room
alright once the MSI file downloads just go ahead and run it to
install it
when it's finally done
you should see in the Start Menu All Programs debugging tools for windows
alright once you have that
go to All Programs Debugging Tools for Windows WinDBG
open that up
and then when you go to file
kernel debug
and there's tabs at the top and you want to select the local debug
normally in the other class we use the COM the virtual serial port
in order to debug the virtual machine
but actually from within the VM we can do
of basic debug
where it's just gonna grab some snapshot of memory
and then do a debug on that
and I thought the way it worked was it literally created a created a snapshot put it in
a file then opened the file
it doesn't
i'm thinking that's not the case because last time i was playing with it i tried to
make a change in I'd like to see I can't write to memory
and then when I
tried that it immediately crashed
so i think it is maybe
i think it's probably loading a kernel driver and there may be some basic
communication between user space and kernel space
so anyways
again file kernel debug
go to local
click ok
then this is going to give you a basic debugging session
now as with the previous class
we need to get all sort of on the same page here
so you all have the same UI
so you have this one window covering over the the gray
drag it over the gray so that
it compeltely fills the screen
like this
alright once you got that
that's the command window that's where we're going to be
issue commands
i also want to have for this purpose I think I just need
the disassembly window
if you see this little one point zero
on the top bar
either hit ALT 7 or click the 1.7 there
and you're gonna get
a floating window again and we want to drag that to the middle
of the right side
and that will split the screen like this
drag that to the middle right
split the screen like this and you'll have disassembly window
and a command window
oh you've got a floating window
it's floating around
dragged the window to the middle
right and it should split the command window
sometimes if it's like overlapping you won't be able to
so now drag it down to the middle right
okay so i have
a new command reference at the end of the slides
i put together most of the commands but for now
we're just kind of hunting down this
specifically we're trying to investigate this interupt E
which GMER is reporting
and want to see
what code is at that location and trying to figure if that's malicious code or whatever
so one of the command you can use is
*** idt exclamation point idt
space e
in order to say
print out interrupts E
so if you do that it would give you the literal address
it'll give you the 32-bit offset of
the uh...
the IDT entry at
index E
and then you can just take that address copy it
and then paste it into the disassembly window up at the top by little
offset box and then
place to put things
so you do
*** idt space e into the command window
get the address of the interrupt handler
then copy that address into the top of the top of the disassembly window
and then you'll see the
disassembly
you left off the e
*** idt space e
and some of you saw that if you do *** idt it will show you a
few
it'll show you a few
interupt descriptor tables entries that don't
point at
and NTUSKernel and hal.dll
instead things that point elsewhere but
anyways this is good enough
we're not going to do
full analysis on this obviously that takes a while
but when something's come to
my attention
here
one of them is that were accessing
control registered two
in the intermediate x86 class we talked about
page fault so we know first of all were
at the page fault handler
this should be handling page faults
and then second
from intermediate x86
you know the CR3 register
is the address of
the memory location which was trying to be access at the time of page fault
looks like if you go out and try to access memory address zero
and zero in virtual memory isn't mapped to any physical memory
you get page fault
the hardware will automatically put
address zero into CR2
so that the page fault handler when it starts handling this can say okay which memory
was someone trying to access let me go walk the page table
and see where that should have been mapped
was that you know
is it paged out to disk, is there meta data that indicates that
so anyways i do go through all this assembly and tiddly wiki
and go check that out after class
so other than
reverse engineering rootkits section
think it was uh...
it was
there's the same code
so this is that code
with the CRT access and stuff like that
and so i go through that say you know what's the meaning of each of those
instructions
what sort of thing do we need to remember from intermediate x86
about the stack and what it looks like at the time that an interrupt occurs
and then there's actually one extra piece of information that you didn't
know intermediate x86
where a page fault occurs there's actually an error code
you may have known there is an error code
and this part right here says that there is an error code in certain cases and
this part says that page fault does have an error code
but what we didn't talk about was the format of this error code
this particular thing
I copied that in from
the manual as well
and that will describe when you see that thing
reading this error code and
parsing the data
you don't really know what the
meaning is unless you go and find out what the error code means
so anyways that's just a sort of one example
where you
you could do this to basically anything can go into GMER
you can find things in wherever it says this points here
but can't tell you what actually happened location
you probably have to go in
you probably have to go and find the address
pull up the disassembly and actually start
reading it and that why I said this is kind of
beyond this class's scope but
in some cases there really is
no other good way to do that
yeah you could absolutely just put in any arbitrary memory address here
so you could have just
pull that the GMER results
you could have said GMER point and go straight to disassembly in
WinDBG
and paste it in
I didn't do that here because i knew that
that's not going to match
wouldn't you expect to have the same disassembly if shadow walker wasn't there or what do you mean
I'm not seeing what your seeing
ah yours is hooked by Tuluka right now
you've got tuluka installed okay so yeah on some people systems if you have
tuluka still running from yesterday
here's the reminder here
tuluka also it
hooks int 0x0E
so if you've got tuluka running and you'll actually see different disassembly
at that location that will actually be the code for Tuluka's kernel driver
fair enough
put it in a ziploc bag
do you have
tuluka running
do I even have it open
I have it open as well
maybe tuluka will unload this driver
at some point in
if you in a different app or something it could be doing
dynamic unloading a bit I'm not sure on that
but i do know that this is the shadow walker code
that I'm seeing but Steve was seeing the tuluka code back there
and again same thing had you not known this was
tuluka code or saw that it was tuluka code that
was hooking the base you want to
go in there and say what is it actually doing
what's the nature of the changes that make to the system
and they need to go and looks at itself
and then you can go through and look at the disassembly and start teasing out what's going on
alright I just wanted to mention real quick, I have a bunch of
admends at the end of the slides now
where you can look for the IDT stuff
from intermediate x86 class we had that one plugin and that will show us GDT and IDT
so you can go
for call gate experience with GDP command
we look for IRP hooking you can look for
SSDT hooking
import address table hooking would be a much more manual process here there is not a
great way to do that right now but
probably there
find a way to script it to make it much more
much more automatic
but there is also than scripts which were
parsing out the call back
functions
so for a registry callback process call back and
thread callbacks and image load callbacks
uh... there are scripts in there
scripts that i got
from a blog that
and go in there parse those and see what's actually in there
like I sort of said
when I was making reference to the reason I wanted to come back to
that just because a
with this detection
comparison matrix that I did
whereas showed of this hook and this detect this
I said I was you know overly generous in this thing and that
I put things down, yes it's been detected even if
you have go manually look
for exactly what you want to find
so because WinDBG is so flexible it lets you go search for
the exact memory location you care about
uh... you can find a lot of stuff
simultaneously need some more expertise in some cases
well you wouldn't really know what shadow walker does until
you analyze
the entirety of the code
so the case is you don't even know what shadow walker is
you don't even know what shadow walker is then
your saying okay I don't even know what this is doing eventually
we'll sort of
let's see here
where you sort of get
where could use see that something is a little wierd
so the code isn't that big right
so it eventually comes down to this JMP instructions
how much that is
yeah basically what you would see you when you're looking at this code is
you'd see it's doing conditional checks where it's trying to see
if memory is in a
particular range and if it's in that range
it goes to the page tables and it starts modifiying the
values so
from intermediate x86 we'd seen there were certain
virtual memory addresses that were used by convention for the start of the
page tables
and page directories
so these
0C03 so even if you just started by
you know googling interesting constants for instance one way to
while analyzing code
just google that constantly google this constant what is it you
find quickly that these are
constats related to aging and stuff like that
what you see when you analyze the code is that if
memory is in a certain range which of course is
location it's keeping its own code
if its in a range
it goes out and modifies the page table
for instance to mark things as present
and that it does something
and when it's done goes back to marks it does not present
so would at least have a sense that
this thing is
trying to mark its memory as not present whenever this page fault is not
occuring so that its not basically just
will always keep coming back to the page fault whenever someone tries to access it
going beyond that then it becomes
an issue of whether or not you are aware of
techniques like shadow walker
so you could infer the the existence of something shadow walker-esque has that
it's trying hide memory by
it's marked as non-present, this code runs, marks it as present
does something
and marks it as not present again
that's probably degree which should be able to analyze this code
not knowing anything else about shadow walker
similar sorts of things with
other things let say you saw
analyzing code at that location
you're not necessarily going to be able to pull out and say you know this is
heap or hook which is doing this
if you get a sense of what the instructions of doing
then you can start googling
for the behavior you think it's doing
that may or may not
lead you to a specific rootkit or
specific third-party software
this particular case
yes you could but
you have to
and would imply
that collection of known rootkits off to the side which here at that point you
are no different than anti-virus
so some people do
take anti-virus and run it across memory dumps and stuff like that
that may find this for instance
yeah but certainly one way to go about it
really then depends on if you have your own good signature or whether anti-virus has a good signature
I will say that anti-virus will catch most of these types of rootkits
that we have installed they are all known rootkits
there proof of concepts stuff that was posted on rootkit.com
they even
you know mark things that
just installed drivers that mark those as
malicious tools
the anti-virus name which is something Corey and I review
frequently we've got just a little program with all it does is load a kernel module
into memory
and that's frequently marked as virus by the anti-virus software
just because it came from rootkit.com
pretty sure they just scraped the site
took any exes and said lets make signatures for those
alright that's all I want to talk
about WinDBG for now just to say that
for some people who have tried to
go the WinDBG route is a option for local
debugging which you could do on the system without having to reboot it
so you could come on the system drop GMER, and look for stuff
but if you end up with ambiguous results you could still have the system running
you know running the webserver or whatever its doing
that you could still be looking at the actual code analyzing it on the system
before you have to
take it down
before you tried to do any cleaning of the system
alright so
quick review of
the stuff that we learned yesterday
since we're running a little ahead of scheduled but that's good because then you're gonna
get some uh...
time at the end
here hopefully to look at
these machines need a good looking at
so hopefully we'll have enough time
to check them out at the end here yes?
Uh, so. We ran WinDbg in the running kernel.
Are there things
we're going to be able to find in thereÉ knowing that...
obviously if we could bootstrap and attach the debugger beforehand then we will have better access
Are there things that are hiding that we're not going to see?
yes absolutely and it won't necessarily be so much because they're targetting
WinDBG for instance
but the important thing to keep in mind and I call this out in my slides later is that
WinDBG is not
an anti-rootkit tool
pursay
and therefore
so i can do lm for loaded modules
I'm going to reload the symbols then I'm going to
list the modules lm is list modules its going to list everything that is
installed right now
issue is here
some of the things which i know are hidden right now
that's not in a state that it can show me, but
the msdirectx.sys
mmpc.sys those were two kernel modules that were hidden with DCOM
they're not gonna show up
in this things
loaded module
because this thing just does walk eprocess structure walks the
the loaded module
linked lists, dll linked list
so this thing's not going to be able to find things
it's not trying to it's saying your just debugging the system your just working on own drivers
not worried about malicious stuff
so this is not meant to get around malicious things it's just that
it can look for certain things and so if you really want it
you can manually look this sort of vcom detection you can say
okay here's this list that one look
now let me go out to that
PspCid table
and uh... sorry, PspCid table was
sorry that was for uh...
loaded processes but there's other things to do you like
searching for specific signatures related to the data
structures
that are in this linked list and say okay search memory found all these data
structures
and now let me take those links
for those loaded modules models vs these loaded modules compared to list and see if
there is anything hidden
but by default this will definately
not show you any detail on stuff
it won't show you anything about hidden files or anything like that
because it's not meant to look at file stuff it's meant to look at memory
What would be the distinction between
running it as we are now vs. running it on a cleanÉ on a cold boot
right on a cold boot I'd say the distinction would be
for something like
let's say FuTo
if i run this on a cold boot
i can issue a particular command (and that's a good reminder to me that I need to put this command in)
so if i run a particular command it will actually interrupts it'll cause a
breakpoint every time a new module
is loaded into memory
so for some of these things where they load into memory
then for instance they unlink themselves or unlink other things
you would have seen that it's loading
at load time you could have examined all of its code and everything else
you could parse the PE headers go to the image, sorry
the address of entry point
field of PE headers
see that's where the code starts
start analyzing it
point is that if you let it run after that it's going to
immediately hide itself
not necessarily going know where it is
it really becomes an issue of
stopping every instance all of
loading of drivers
in heap or hook case it gets really nasty in that
you probably have to intercept
all accesses
or all allocations of kernel heap essentially
so because that they load up
so you would see at load time
and then it takes its own code
allocated a chunk of heap space
the copies itself to be and then below that drivers it's just
but then it's sitting there in heap memory so problem is if i try to
find out who allocated that heap memory who copied that code there
there's really no way that I can answer that question
but if i do it on a cold boot I can intercept every heap allocation and I
can create a list here's the drivers allocated this location and that location and that
location application and then I can eventually tie it back to say okay here's
that driver that pop in and popped out again
it's really just a question of getting yourself in and being able to watch
every event as it occurs
before the attackers actually gain control its sort of the same issue
we had with those callbacks we talked about
yesterday I said
if security software gets there first and if it
says I want to
find out every time something loads into memory
then it kind of wins and if the rootkit gets there first and says I want to know everytime
someone is loaded into memory then it wins
same issue here
the debugger as long as it started
early enough
then it can really stop before the kernel
is loaded and anything else is loaded can't stop before master boot record
but once the OS is loaded to the point where the kernel debugger can talk out
then it can see everything
device driver
exactly so
when you load WinDBG even on a cold boot it's still loading a
device driver loading it as early as possible
but it's
still has to load it the thing is it actually does load it before
I shouldn't say that if I'm not sure
i believe it loaded before
the kernel certainly
i know that I see the kernel load events occur when I'm doing a cold boot
but that doesn't really jive with my notion of rootkits but, anyways
So I was thinking that if you do it locally
then it's loading a device driver, but if you do it during cold boot
then you're actually just enabling the hooks that are already part of the kernel
that could be the case
that's reasonable
worth looking into actually
.reload so it's not really loading the modules it's reloading the symbols
but all of your VM's because I had already WinDBG installed not uninstall
so that you would have to install it if you wanted to use it
but all of your VMs if you
go to file symbol path
it will probably already be filled in
with the appropriate windows symbols path
this is just the URL so you
can download the symbols from microsoft
so that this thing knows what the names and
modules are
knows what the functions are
does everyone see that
so that was already there are on
new system when you're putting this on the system you've got sat
down in front of
you have to know you have to
but that in there
it's going to be reaching out to the internet if it doesn't will sit down with the puzzle
have internet access you potentially have to
bring along a symbols file
on a DVD or whatever
in order to tell WinDBG where to find that
help it help you
understands the system better
alright so that was WinDBG
local debug and
talking a little bit about the benefits of
doing it on an actual
reboot
so just to quickly recap what we talked about yesterday in terms of stuff
you already have a sense of
from other classes potentially
talked about IDT hooking
we said that IDT is just a
big array of these interrupt descriptor gates
which are
far pointers they've got
32 bit offset
and a 16 bit segments selector segment pretty much always
selects segment which starts at zero and
goes to 4 GB so really
in typical usage
the 32 bit offset is just a virtual memory address
second we talked about
call gates so we said there was a call gate installed in the thing and
how the call the call gate looks very much like an interrupt gate
it's got a segment selector and a offset it's really just specifying here's a target address inside a kernel
space
where kernel sets it up so that user space can call this call gate
it will transfer control to the kernel
basically a way to allow that interring
transfer
and we talked about import address table hooks which we've seen
briefly in
the life of binaries class
we said every PE file has
to import something from other module
it's got an array of vstructures
one for thing it imports from so here's a simple example where
you've got some kernel module where it imports from ntoskrnl
and there's an image names table and image
address table
initially
on disk they both point to the same thing
then in memory
when the OS loads up the binary
the importer address table gets pointed to the function pointer where things are actually imported
and the whole point of the
IAT attack is that
the attacker just comes in
points those IAT entries at his own code and starts man in the middling
we also talked about inline hooks where
putting things like jump instruction
or other small changes you overwrite some code you copy the code that got overwritten
off to the side
alright so that was stuff
we've kind of see in other classes and a lot of things we
haven't seen yet
there was
this covered a couple different types of things
so we know there could have been import address table hooks
there could be IAT hooks we'd see that and there could be inline hooks we'd see that
IDT IAT inline whatever
what was new here was covered in this entire processed
and the fact that
you know one other path thats more commonly used now in order to go from user space to kernel
space is sysenter
and you saw that there's specific modules
there's module specific registers which are used to say here's the
target
IA32_sysenter_eip
is the EIP where they want
control transfered
at the time they call syscall
so there's sysenter
so that MSR is set up
to point at this normally but if attacker comes in they can point it wherever
they want
they'll functional have middled this control flow
from user space to kernel space
we said that once you get to one of these functions
uh... what they're going to do is they're going to say okay what thread is
running right now
and where is that
thread service table pointing so it will either be pointing at the shadow table
or the normal table
and in each of these cases they were use tables had four entries and so we know
down here in user space when you're calling a system call you
put EAX equal to the syscall
you want to call
so you say EAX equals one one two
and so this guy here parses EAX and says okay one one two while bits
thirteen and fourteen
those are zero so I'm going to go to for instance
so i'm going to go to the zeroth entry of this right here
and that this has a
service table entry
which points at that table right there
which has all of those function pointers in it
so the one one two it's the zero-th entry of this and the one one two-th entry of
that
and then all of this table over here always points, is always supposed to point
into ntoskrnl
so those are a bunch of functions which are
supposed to be implemented in the kernel proper as opposed to when something is using gui functionality
gdi that we talked about yesterday
that has an alternate path that's was
gpi32.dll
it comes in and ends up at the same thing
when the person here instead it'll be somethings when their parsing EAX instead it will be
something like one one one
one one two E
something like that as we saw yesterday
that initial one says
so first of all it would be consulting with thread information the thread information
would say it's pointing at this instead
so for anything that uses GUI functions the thread information points here
anyone that doesn't
they point here
alright so one one two E would say index one of this
then index one two E of this
and then those would point over to win32k.sys
which is
the thing which implements kernel side of the GUI components
we said you can actually hook
either of those tables
call that the shadow SSDT call that the the normal SSDT
either of those cases you can change the those function pointers to point at the attacker code
and we said in some cases like
some cases like black energy rootkit it actually says on a per thread level
it'll say okay we'll this thread is not pointing at that not pointing at that
it's actually pointing at some different structure over here
which potentially points at a different
function pointer table
we also
saw yesterday
and we're not going to see a tool that actually does this until the end of the
day
but I briefly describe that in case of heap or hook
in those four entry tables we said there can be if
IIS is installed
there can be a third entry here
normally that's not installed on any of
our machines anyways
so that's usually going to be empty like on the top
but heap or hook calls
this KeAddSystemServiceTable when it does that
it gets a new structure right here
and that structure then points out to a table which has a number of
function pointers in it
and instead He4Hook uses this as a sort of uh...
userspace to kernel space command and control
mechanism, so it says
your kernel space I got a new
file that I want you to hide here is the name of the file
it's going to call command two or something like that
alright so that was sort of
this was
different level of SSDT hooks but really
you can hook anywhere along this path
alright then we talked about
IR request packets
and the key point here was that there are two different ways that an attacker
can interpose on these, man-in-the-middle them
way one is just create
he inserts...
way one is that he loads up a kernel module
his kernel module is going to get a driver module associated with it
and then he's going to create a device object
and say i want that device object to be here
or I want that device object to be here
so the driver creates device
objects and put them into the chain that way it
is registering itself as a filting driver because he's sort of filtering commands
comming up and down the step
thats way one
way two instead of even bothering
to put yourself into that chain
just figure out where there's something at the level that you want to be at
and go on to this major function table which is
an array of twenty-eight
function pointers
tacted on to the end of these driver objects
and he's basically saying here's the function that implements the handler
for create IRP
and here's the one
for directory control IRP's
so we can put itself in here and point the function pointers out to
the attackers and then he'll be called whenever
lets say he's in the keyboard thing whenever a
read IRP is coming down
so the read IRP comes down gets to the hardware says here's that
key stroke you were looking for
and then he comes back up the line
following the completion routines for anything that
asks for a completion routine to be registered
and so
and attacker could
see that an IRP is coming down by hooking thethe read
major function
say he's right here
say there's a
read entry right here
you can see when read is coming dow his code gets called
based on the function pointer here you can set up and say okay
when that's coming back up the stack I want to hear about it so here's my completion
routine
call me back
when you're done with the read
so that i can see the actual data that's has been read
in this case a key stroke
alright that was IRPs
these are thethe different types of IRPs
we saw that
this directory control was relevent to Stuxnet as well
heap and hook which was installed
its doing a Directory Control
thing used to list files
within a directory
so if you filter on that
you can remove your entries from the file system
alright we talked a little bit about
DKOM as well
we said that you know in simple cases
it's things like
removing things from linked lists
and I gave three examples of how this could happen
one it could be hidden prcesses which will hide things from task manager
or level viewing
when task manager calls a function to get a list of
programs running right now
that function it calls basically just walks this list in order to
find out what's running
but if an attackertakes the forward link and instead of pointing it to this
process and points it over that
well that process there points this one's backwards linked
than this thing is just not included in the list and so if someone wants it their
not going to find it
basically the exact same thing could to remove
kernel modules which is what we have hidden in here
there's two kernel modules that are hidden with this technique
there's a different data structure used for them but it's the same idea you just got a linked list and you remove yourself.
and the exact same data structure that's used for kernel models is used for user space
DLL's
so in either of those cases you can just remove it
I don't believe there is other housekeeping they have to
in some sense you can think of this list like sort of
you can think of it like
i kind of thing that like
useful information that that the kernel would like to have at it's
fingers tips if it ends up needing it
like i said yesterday fundamentally it's not something that's required to actually
schedule
the process
the scheduler uses thread level
information so
there's going to be various pools of these threads where there going to be at different priority
levels and say these threads get scheduled first and these get scheduled later
and the thread information is what's used to actually run processes
if you're wondering if
when a hidden process
you know maybe if the hidden process called some function
and if that function would have looked at this list in order to find this
information
and then wouldn't be able to find it
but I don't think that's the case because
as this pictures sort of shows
whatever the current running thread is
the current running thread still knows where to find the example off the top of my head where
some function would be
querying this data structure but
if you think of it like whenever the hidden process is running
it's unlinked from the left so it can't find any information about anything else
but it can still find
information about itself
so no functions are going to die
over on it because it'll still be able to get to the data
structured through this path
but you know
if the hidden process wants to go pry on other processes then potentially it would have a problem
thats a interesting question actually
I should see what happens
when I had task manager
if it suddenly loses the ability to see
processes I kind of doubt it
any other questions
as we're going through IRP stuff SSDT stuff anything like that
and so I just talked about the list examples of this
there's also
examples like
token elevation process privileges
elevation
where know you go directly to the data structure that holds your
privileges for this process and you just
elevate it and say this is now a system level process
DKOM just means
instead of using API you've gone and
reverse engineered things you understand how they work
go directly to those data structures you find some way to finding the
datastructures you care about
so in this case he's saying hey I know how to find that data structure
and from that I can get that link
and from that I can get that link
so you need to have the attacker needs to have some way of finding what they're looking for
but once they are have that
they can go manipulate the data
how ever they want
I think this is the last thing we covered yesterday
OS level OS-provided callbacks and or notify routines whatever you want to call them
we said
these were monitoring functions these are things where they'll tell you when
certain events are occurring
and they're trying to push developers to use these types of things
rather than those unsupported mechanisms like
hooking the SSDT
putting inline hooks in the
kernel and stuff like that
where in security programs you want to find out everytime the registry is being edited
every time a process of being created
can find that using these methods
flip side of things is that if a
rootkit gets installed
first and if it
for instance
has a call back on the load image notify routine it can see
every single thing that gets loaded into memory
it can change it so there one example we talked about
where
this PoC hybrid hook one
it says whenever something gets loaded into memory and then it will
scribble over its import address table with if it's importing something the attacker wants to hook
but you know there's other things like
let's say
rustock for instance
as a process notify routine
let say it see's that
your anti-virus
Symantec
it's call symantec.exe loads up
it see's everytime a process is loaded if it can see the name of the process
it can be immediately terminated
so if you get in there first and you're just killing processes scribbling over
them changing
that sort of thing
so when you call some
one of these functions CmRegisterCallBack that's a function you call can you give
as well as the parameters here is the address where I want to be called later
so then the OS puts you into a list of a bunch of addresses
so that when a event occurs
when a event occurs
it goes calls that one calls that one calls that one
and kind of just walks down the line and calls who's asked to be called back
there can be attacks messing with the list and actually i was looking at this
last night
lets see if its still open
like i said i was trying to
see exactly what
each rootkit does by itself and for some of the more advanced ones like
some of the ones that arn't just Proof of Concept
where they're doing one technique
i'll admit that i haven't you know
looked over all their code and looked over every single thing that they're doing
so
on the notecards i was noticing last night when i only installed
He4Hook
there's the shut down notifiers where there's actually a lot of these naturally
on my clean system
I look and I see a bunch of things
but it looks to me so these ones right here all have the same
address these are He4Hook things, and
I think I'd have to confirm it but it looks to me like
there were a bunch of existing shut down notifiers He4Hook came in
and overrode those with its own function pointer address
i think that's a great attack that's the way to do it
you don't want, you know the security software something like that
i mean it all really depends on the security software can stop you or not in the first place
but if they're not stopping you or lets say you just have something like an
exploit
kernel mode exploit
if you have arbitrary write permissions you can go in and
you know point the
pullbacks for some security software at
a return instruction
and say i want the function to be called to be that address
and that address just happens
to correspond to a return instruction so that the security software callback always
just returns
its functionally blinded stuff like that
but it looks to me based on this so it was really based on the
device object things right here
the device object things didn't change between the clean system and the dirty system
so these used to point at legitimate system drivers like
mup.sys and
other things, but
post-He4Hook I could see that all those addresses got changed to the
same He4Hook
memory space looking address
but those device objects didn't change so that's kind of interesting
so yep, the attacker can go in and mess with the list as well so there could be things
registered to find out when things occurred
but the attacker can go in and put himself so he's the first one that hears about it
or can go in and remove security software or stuff like that
of course it all depends on
when the attacker's executing relative security software
what his missions are or whether he's being intercepted, all that sort of thing
alright I just kind of glazed over this but if you go to these site
I'll try this maybe at the next break
some reason it wasn't working on my VMs anymore
but at these URLs
there's two
little WinDBG scripts
which would parse those lists so can actually go in
read the script they're pretty simple you can see there keying in at specific symbol
names
you can go to those symbol names and see that they are function pointers in the list
and so specifically its actually just an array
in XP
it's a list in Win7
and yes we finally left it with
Virus Blok ada has pretty good
detection of the these callback mechanisms
we've got a bunch of security software here you've got some legitimate
things like hal.dll and ndis.sys but then
we got stuff where they have unknown handler
which I'm pretty sure is associated with a hook
alright
so i will
any questions on the stuff we went over yesterday that was our quick review there
inline hooks IAT hooks
IDT hooks
call gates
anyone on the phone have any questions
alright I'm going to go on