[Applause]. DEFCON 22. So I came up with some stuff between when I submitted my slides and the
conference so I did a little bit of deviation here from what you guys have but I've got a really
awesome tool and I was like I'm not going to sit back and not release it so I'm still going to
share the page table shell code stuff which isn't new. I did do that. I held new stuff back just
for you guys, DEFCON 22 exclusive on finding what is really running on your system.
We will kill the Root- kit. Oh, any Rootkit I believe we're going to be able to handle in
the future quite decisively. I believe that we have a defensive mode, defensive exploit that you
can now use to actively find any attacker in your infrastructure in a very high assurance way.
Specifically the tool that's on the CD then I've got an updated version you can download on the
source code as well, whatever. And I am reimplemented in dot net so you can run it in Linux,
or mono and all that stuff. It's designed around solving the deacon type Rootkit problem,
there was some work earlier on 32 byte similar to this and then the papers you could read my
slides there's some references. Just follow the slides, follow the slides, follow the links.
Those authors left it a little short mode, you know we're going long. The thing about the 64 bit
long mode is we have so many more bits we can check. We've got so many more places to
identify that if you mess with the bits that we're checking the system just won't run. You will
get a blue screen, a reboot, whatever. So it's based on properties of the MMU, the
virtual management system and I wanted to throw that up there so I can get you engaged. I will
talk about the road to this discovery. So, Barnaby Jack, forever in our hearts and mind
‑ ‑ [Applause]. ‑ ‑ you know he would talk about or he would talk about it's about the
journey not the destination. So you know with that I'll have a little bit of the journey here.
Thirteen years ago I was here at DEFCON I guess I invented or first released a tool kit for
shell code and put it into a version you probably are running. So that was 13 years
ago. The more things change of course the more they stay the same. You know? And a lot of
these attacks get recycled and brought back and, you know, when ‑ ‑ before I made the
discovery on this Rootkit detection stuff and you will see how that links in with the page
table stuff, you know, um, I thought about even just like doing a new patch. Hey 14 years
later I still get the same code I'm talking about. I thought that would be a little bit
funny. But, you know, I just wanted something a lot more practical so... What you guys
have now on the CD I would love to get some feedback on what your experiences are with the
detection technique and it's definitely a million times more practical than just another
attack, just another encoder, just another thingy. You know an attack ‑ ‑ attack is hard and
people get a lot of kudos for their attack. But it all ends up, it's fun. You know,
exploiting stuff is definitely fun and getting that shell code and getting those root shells, I
mean it's fun until it's scary I guess. Fun scary. And defense is just a hard stress. That's the
hard part of defense. And I'm going to try to energize you guys and try to change some of
the way we're kind of thinking about defense. You know everyone is like attacking for fun and
profit. I don't think I've ever seen a defense for profit or defense for fun. I've never
thought defending my network for fun. What? Really? So, you know, it's obviously the quarter back
usually gets the headline. He's making the point. The defense just grinds it out. So I got
this a couple times in here, let's hear it for the D. DEFCON. >> Defense. >> I say D. Help her
out. She lost her voice. >> I lost my voice. >> : The idea here is that the tool that I've
given you on the CD or if you want to download the .net version it has two different
modes, less bit checking and a little bit of logic. Anyway... Sort of a defensive exploit.
Anyone that's going to exploit it, anyone that's been exploited or hacked, it sucks. It sucks
getting exploited. And some things that you can do though on the defensive side is, you know,
you have this historical knowledge and you have an ability to maybe talk post
process some of these events and, you know, the future. Storage is cheap. I will keep my
memory from any incident ever because maybe there's something I missed. I'm fanatical about
that. Hey, did I miss something? When I do like a forensic or look at the memory the physical
memory of the machine, it's like how do I know I looked at everything? I'm always checking
myself. Like I'm one of the worst programmers ever and that makes me a good code auditor
because I'm like, you know, like checking man cages like every line. No problem. So what we've
got today is the def of Dcom, process hiding is dead. Anyone doing process hiding Rootkits?
That's like you might as well be a rapper or something else like easily detectable. I don't know.
But that technique is effectively dead now. There's no hiding from it. I will digress a
little bit. Also 13 years ago this insane bash assembler thing kind of blows my mind. Right?
What goes on ‑ ‑ you know, this guy wrote an assembler in dash and so you just think about
things, people have been kind of doing this stunt tricks for a while and that was kind of my
talk. It was going to be like this stunty thing. So anyway... That's probably a little bit why
I'm cutting it a little short. I didn't want to be too happy and too just like another stunt. I'm
giving you something real. This is something super real. Okay? We're going to find out as best
as possible all possible code running the machine. There would be no code running that we don't
know about. There's ways to inject DLLs but that sort of attack is handled by hash
checking pretty easily so I don't want to spend a whole lot of time on hey this is an
integrity check as well, blah blah blah. Hash checking is kind of like what everyone is
accustomed to in files so it's also possible in memory so... The other thing I wanted to talk
about is procedurally we can devise a system that resists attack, resists back doors. I
noticed ‑ ‑ I went to the EFI talks earlier and I know the Intel and Miter guys are
brilliant, awesome work. But practically if you're an administrator on my host, you
know, I mean it's game over. So I'm not really like at that point I don't believe an
attacker is typically going to be escaping the guest on me. You know? If you're using a VM, a
cloud, some kind of virtual hyperviser even something maybe with a more weaker track record
like, you know, I don't want to call out virtual box but I know it sometimes crashes more than
other VM's. Even not I'm probably not even a great enough target to waste a virtual box
exploit on. Right? So if we use the hyperviser‑ if we use these systems we can establish a
number of things and I'll talk about device verifiability, verifying devices and that's why
this stuff is really cool. It's not really applicable in a lot of real world cases. I don't
know. There's 3 pillars here. Structural analysis, physical memory traversal and integrity
checking. We need to analyze memory from the physical memory side because I don't want to
deal with IDTLB issues, being trapped by like another threat in the kernel, being evaded on,
dumping memory. So dumping memory analyzing memory from a VM snap shot is vastly
simplified unless you do a dump of your ram or something like that. So here are the practical
concepts, again. The weird machine attacks are awesome. I mean finding the hidden machine
in custom application or you know code data intermixed in a font and that somehow triggers
the GPU to do some pixel shading to like anti alianize your retina display and that somehow
enables that code to like inject into some other memory and yad-da, yad-da. Yeah. I mean
like the more esoteric those attacks, that's awesome. Right? Let's say it's the cool stuff
but in the real world, procedurally we want to adapt the home field advantage to use
defensively ‑ ‑ I mean I've been using a hypervisor for 10 years. I don't know. Everyone
else probably the same. So default handler don't work on VMs. The snap shot will collect
everything. If it did work the VM wouldn't function so you know that you're not going to have
that shuttle walker issue. The EFI stuff doesn't work. A lot don't support SMM. People talk
like it still goes on. A lot of times you can't get in SMM. So you will need that VM escape.
Well I'm not the DOD and you're not China probably and you're not wasting that exploit on me.
Maybe those guys do but... Um another couple cool properties about this thing you will see is
that nested page tables, it's not really an issue either. Things like that. So the page
table shell code stuff was, you know, something devised to work on just evolving our
understanding of systems and go, okay, this is cool. I can kind of implant memory up until
windows 7 by just ‑ ‑ it's sort of a complicated thing but I'm just going to go over it quick
but the motivation was to help understand physical memory systems. So until windows 7 or
after windows 7 none of the page tables shell code stuff worked anymore and I was kind of like
deincentivized to work on an information disclosure on how to make it better, how to make it
like awesomer. If you want to look at this other reference here that's a mind melting
paper. They found a way between the interaction of the page fault handler and mapping the
TSS and GDT and doing this crazy faulting so the faulting itself in the CPU that would normally
be like bringing pages in and dealing with invalid instructions and these sorts of
things, that would actually, that interaction actually read and wrote memory. So all you
needed to read and write memory and you can kind of coerce that into a weird machine. And they
wrote a compiler for it. It's pretty amazing stuff. Um, here's an explanation on what the
virtual address base looks like on X64. I took this off code machine an interesting site with
other low level stuff. We can see here that, you know, obviously Microsoft has done
pretty good. The second row here you can see that the space nonexecuteable. They've been
doing a good job of reducing the surface area of what's kernel space. Other people talk about
sign drivers and there was an attack there was code injected into the hibernation file which
was awesome but they've been working on reducing this stuff. So again they did catch this
stuff. One interesting thing I want you to look at on this slide is look at the left hand
column. That column there those addresses aren't just random. Some of those ranges, what that
correlates to is entries in the root global table and they can mark security at that root level
to kind of adjust the permissions in the entire address space. And here's the
actual page table shell code weird machine. We can actually emit shell code or emit code
into the kernel on Windows 7 and earlier. So I know ‑ ‑ I was not going to upgrade to Windows
8. I don't know if anyone else ‑ ‑ I was like I'll wait for 9. But I'm telling you they did a
lot of security. Windows 8 is a lot better in the kernel and there's a lot of interesting
things they did. 8.1 they brought back the start menu. It's like oh great. By just
doing a virtual owlen user space not as an administrator, you know, unprivileged user, remote
user, even a remote user if I'm interacting with a service like a web server when I send a
request for that server when it allocates memory to receive that, that allocation emits
executable information into the kernel space. So what that means is like I can do a ROP right
through that. I can get code into the kernel by just reserving memory which is pretty
powerful which is pretty interesting. Those there means it's executable. Then, you know,
it wasn't bounded by the amount of physical memory. Just by reserving the space you would
have that area as well. This number here on the left if anyone knows what that number
is, feel free to yell it out. You can't see it? Sorry I assumed people had the slides
and stuff. I'll explain later. So again it's dead. Frowny face or indifferent face. If you do
want to kind of look at how the kernel in windows 8 interprets exceptions and page fault and
how the page fault handler, you know, the internals of it work feel free to step through it. In
this particular stack trace I was actually pretty perplexed for a while why if it was
patched I wasn't getting a straight abort exception. This is actually I guess a DOS. It
will spin a thread to infinity. Again I spent time wrestling with, okay I'm going to do this
as 80 mutate update. They released this dot net compiler thing. Maybe I'll do a compiler.
Maybe I'll do it as a bash script. I was like well it's really hard to deal with the
nulls and bash and... So what I did find along the line was this upcoming technique and I'll show
you in a second. I will build up to it. This is going to be the longest build up to one lined
code than you've ever saw. This whole technique is one line. Big one line but... So... Instead
of doing another attack, instead of trying to be like just how cool my hacking is, this is how
cool my stunts are I will give you a defensive exploit. I'm going to obsolete process
hiding. Anyone that does forensic, anyone that does incident issue, you know,
dealing with hidden processes, dealing with APC thread or whatever you want to call it is
kind of a pain and now like after this talk you can qualitatively say absolutely you
fucking found everything. I did look at everything. There's no hidden process or maybe there is
something new and no Rootkit is safe that I know of at this point. And again in a hypervisor
if you're dealing bare metal, you know, maybe you're a masochist. I don't know. Let's
hear from the D. >> Fence. >> Come on everybody. >> So there's a sign code example in D64. I
will forward this to other detectors soon. The other reason it doesn't work on all
immediately because the properties I'm detecting is something to do with the MMU and
on different operator systems it's on a different offset. If you are a harsh kernel debugging
with Linux and you want to help me like that would be great. And we're definitely closing the
door on the conference today. We're closing the door on the Rootkit and, you know, keep your
interesting memory dumps around so that sometime in the future you can deal with them. And
these are some issues again, you know, sometimes I personally feel like I recap stuff too
much. Maybe it's because I know this and obviously I wrote these slides. But, um, dumping memory
is really a pain physically. Please use a hypervisor. Please. I'm not really a super fan of
docker unless it's used in a hypervisor deployment. The zones or whatever that's not really
the most efficient possible thing around. Several different ways to detect hidden processes
have been proposed in the past. >>: [Off mic] I was told if I came up here I would get a shot.
>> Wait a minute. Raise your hand if you're a first time speaker at DEFCON. >> No you're
not. You spoke 13 years ago. >> Raise your hand if you were a first time speaker at DEFCON
like 15 years ago. Oh, wow. Alison gets a shot too. >> So dumping memory is a pain. >> Oh,
no. >> Spill in aisle 3. >> (not audible) >> Hope not. >> Scanning can be slow and it's a
pain. The technique I have single pass. A lot of other techniques along this path are
multi-pass. Multi-pass is like traversing the memory multiple times. Link list pointer
traversal is easily confused but also super fast. I will back up again and say what is a process.
>> What's a process? Holy shit. [Laughing]. I guess we're in DEFCON 101. Anyway...
[Laughing]. Hey listen it is really hard to get accepted to DEFCON. I'm sorry back up.
You're one of the guys that's been here so long you've gone back to zero. How about some
love? [Applause]. >> It definitely is an honor and privilege and thank you very
much for having me and that's especially why I wanted to bring you something fresh and new and
not just another stunt hat. >> By the way if after 15 years you still don't know what a process
is... >> The reason I put this up will become clear in one slide. A lot of people talk
about a process as a thread container. Right? But a process is also an address space
configuration. It shares common address space and that's why we have to lock and do things like
that. So they're a container for threads. It is difficult to know if you have all the processes.
Especially if someone is doing this decom thing and everything else. Process detection for a
lot of guys kind of boils down to these techniques here, the volatility. Great these are
great techniques. People should be using these tools, especially in forensic type situations. The
only caveat here is these are logical identifiers. This is a link list. These are operating
system constructs. I mean so we're in a cat and mouse came we're always in. Attack,
defense, I found this other table process thing, K thread, G ‑ ‑ I don't even know. And
this is what was said when you analyze memory and try to find out what's in there there's
these little things like flipping a bit here, flipping a bit there in these advanced sort
of low level areas, debug data header, 64 thing where I think with just like one bit this guy
like crippled all the software. But it can be crippled by the technique which is a little
unfortunate. So again to fully wrap it up before I go on I wanted to make sure I did the
appropriate thing and invited as many people as possible that had led up to this and prior work
before me the PMO dump that's a 32 bit one is great and everything but 32 bits we just
don't have the assurance level that we do on 64. So please go to 64, use a hypervisor, high
assurance. This technique that I'm going to be showing in one more slide the integrity of it,
how easy is it to attack this thing? Well can I make it nonabortable? Yes I can. The
current check is really good and I would appreciate anybody coming to me with some updates
or everything else. This is a quickie to just show you what a PFNs it's a page frame number.
This is a physical address in the memory dump. Virtual addresses are the bigger numbers
usually but a PFN is what the hardware specifically looks like when it's like number 1 is the
first 4K, number 2 is the next 4K. And then here's a slide from Microsoft where it almost shows
everything. Essentially what the detection has is based on self mapping page tables. This CR3
register is the register in your computer that when you switch processes this register changes
and gives you a new address and this is what actually gives you the process isolation. So at the
root level CR3 then we got these other pointers that are like you see this one kind of pointing
back to itself. So that's really handy. It's pointing back to itself in a way that we're going
to be able to leverage that to identify any point in time where we can find a page table. And
because each process has a page table inherently we're going to find every process by detecting
every page table. It doesn't matter if it's a kernel process. There could be two supervisor
processing or something like that, super weird but definitely we will find anything. Any of
the Linux guys out here, you know, if you want to help me evolve this technique for Linux
or something like that. Here is a huge paper on Linux and it is cross platform, cross
architecture process detection. And this quote here kind of goes down the line of like the kernel
developers really wanted this flexibility when they're dealing with managing memory. Right?
Having this pointer in there really makes it flexible for them in leveraging, you know,
memory allocations and dealing with processes, whatever. So the great thing about it is it is
for all processes. If you know when the bug or some other debugger and during your kernel
debugging you can go exclamation process 0, 0, this gives us these registers, the CR3 base
registers, the page table base pointer, whatever you want to call it. It's a really long
thing we say all the time. CR3 is a lot shorter. So !DQ is the physical memory dump. !DQ is
dump physical quad word. What we will see here is when you do that at the base register for
CR3 this is going to be the first quad word. So null is always happened because null
needs to be mapped in the virtual memory system because if it's not you're not going to
appropriately be able to handle like null, null violations and things like that. Right? So
that's always going to be there. This is the magic number here f68. For windows at least. At
this address which is the base CR3 page table DQ on that, f68, the response is here. What we
see. The blue bits here are the bits that are option bits. You can see there's quite a number
of them. This middle section of blue bits this is 32 bits on its own. So you can see this check
is very high assurance. Essentially, at least double. The current was found in
physical memory so just by looking at each 4K by itself at this offset checking a very few
amount of bits, in this case it looks like I'm checking a lot of bits. If you do the download
this is the mode 2, mode 1 only checks 1 bit. So, you know, I would like to see that. So based
on this app I can identify the current PFN by looking at current memory I can identify
all page tables for every process. So PFN for the win, defensive exploit. D. >> Fence.
Come on guys. >> Dead Rootkits. Everywhere. Again a more powerful thing. You will have a
lot of nulls unless you have tons of memory so those are additional bits. I know how big
the input is I'm looking at and it's always going to be incrementing and things like
that. If you try to attack it, you know, we could do additional checking. I would love to see
someone come up with an attack. I'll do additional checking. If you want to do attacks you go
banged. There's no eq. You can dump a quad word. You can't edit it. If you want to modify the
page table entries on a kernel debugging you could bang ED that same offset from F68 then play
with the bits and see if you can actually run your system. For me the system bsaud every time.
That's a help to your assurance level that you're doing good and everything like that. Here's the
implementation of the code and it's also, you know, it's on the CD and everything like that. The
managed version is on‑ line. You can download it. This is the one line right here checking in the
middle. Pardon me? >>: [Off mic] >>: Tennessee. On your phone or something. I don't know. I'm
running short on time. Here is a couple other cool properties. This is me dumping. This is also
format. Unless you've got some space memory dump like some virtual memory system might have
which would be an issue here ‑ ‑ so VMware is not an issue, what we will see here is
detected values and then this disk thing is also really important because it allows us
to do something very important. It allows us to detect memory runs. A memory run is like a gap
in memory so the hypervisor establishes these runs so that physical like PCI cards and
things like this have their marked areas of memory which aren't in the physical memory
they're in the card space or whatever. So we can see here this jump disk jump and we can
round up and round down these other values and we can automatically get the memory
down. So again there's a blog post on neighbors the butt there was with finding memory runs.
Well shit now you can use this and we're all good. Another interesting property is you can
actually detect processes in guest memory in a VM guest from a host dump. If you really
wanted to get really like super awesome with this you can actually look at this header
file for virtual box and this MM page full thing and, you know N is where you're going to look at
and essentially this is dumping a memory dump from a cloud server. The system has 64 giga
and these diff values you can see are aligned. The first 3 are aligned. If you can't see them
I'm sorry you will have to pull up the slides on your phone or something and then we see the
skew here because the VM doesn't necessarily, um, you know, it's allocating memory off the heap
on the host. It's not doing it physically. Right? So these discs start to skew and that's
where you will have to use the MM internal dot h to d muks and it will have other things that
handle whatever and you can see this 187 here ‑ ‑ 187, I don't know it's like the fucking
physical patriot number for kernels. For some reason 187 is always like the PFN for kernel.
Oh, okay. But then you can see down here this is because they did a dump and there's a
realignment again. These are host processes that the disk is realigned. The underlined ones
are in the guest. Guest memory doesn't necessarily wipe on the way out. The future is kind of
like, okay, well these weird machines are still happening. You know, this is a tool that
Microsoft research guys have. They have access to the source, they have a lot more data than
we do. That means maybe we can use public symbols to the rescue. Sort of RTTI, you know,
there's a lot of antiROP attack that we can then leverage. An antiROP attack kind of needs to
understand the stack and be able to analyze return addresses and make sure they're in the
appropriate place. So someone doing ROP they're so easily detected not even funny. In
summary there are issues possibly with GPU. I'm not so sure the EFI stuff is going to
work that well from a guest and again finally, you know, we've got these defenses kind of
active protection system that you can also try to use which combines this process detection
with integrity checking. There's a link on there. We call it block watch. Let's hear it for
the D. >> Fence. >> A couple more slides that I will kind of blow through. Hypervisor. Self
map detection. There is one possible thing. If you have a no paging process that means that
the MMU is not involved in that process. There could be something there. So if you are
going to rewrite your Rootkits to be no paging Rootkit I would like to see that. Remote DMA.
Please, no. Network cards, remote and everything, oh man just don't expose that stuff.
Authors, editors in here? There's a page and they talk on doom about how it's difficult
and stuff like this. I would like to see, you know, preDEFCON 22 hard. Post DEFCON 22 easy.
Very hard and difficult to very easy to detect in one day. If anyone has questions or anything
feel free to grab me after. I'm going to show you something, just some eye candy maybe. This
is our tool that we have. This is the TDL Rootkit. This is our analysis. It's free. You can go
ahead and download it. Whatever. This is a preWindows 8 so the kernel executable space, I don't
lie about what is executable in memory. I will not hide things from you. Here is the Rootkit
database that's executable. Here are different processes. This red bit is modified. Things like
that. But if you want to play with it, help us evolve our detection mechanisms, help us
evolve the defensive side of things, um, I'm very confident that there's not going to be a
Rootkit problem if you're using a hypervisor. If you procedurally developed your
systems you don't let people execute on your host into your EFI. I'm pretty confident you're
safe. So... Anything else it's pretty much it and thanks for coming and yeah the death of the
Rootkit. >> : Yeah. >> : We did it. >> : We finally did it. Yes. [Applause].