Subverting the Windows Kernel with Exploits and Rootkits

All right, let's start. I hope you are hearing me fine. Let me start with this. All right, so Windows camel. This talk is going to be about subverting the Windows kernel. So the we're going to go through four stages on this presentation. First we have to cover the fundamentals because not a lot of uh security professionals are in deep on uh on Windows kernel. So we're going to cover those fundamentals. Also it's also it helps to do a recap so you can understand this the the second part that is going to be the software development and root kits that's the first stage of uh starting to interact with the windows kernels developing uh for the windows kernel and then we going

to cover windows kernel exploitations I mean how can you abuse of the yeah of yeah we'll cover that later or how can you abuse the windows kernel to yeah to get to do what you wanted to do and protections. That's going to be what are uh the protections that I have to yeah that I have to fight off in Yeah. to actually achieve achieve that. And I have a lot of PPTs but also I have a demos I'm going to try to fly through. If you have questions let's not wait to the end. I'm going to try to cover quickly otherwise you can keep it and then at the end we can do a round of uh

questions and answers. So first why is this important? you might be aware of also I seen uh some of the vendors here as well they are going into this direction basically uh the golden era of uh exploits and exploitation doing basic uh buffer overflows and so on is gone long gone. So but the the threats are evolving now and as well the protections are evolving. So we have a bunch of uh uh uh here a bunch of uh vendors names so for you to understand how is this happening and as you can see the mon endpoint security is getting a lot of coverage on that right so uh what I mean with this in a long story short is like

everything is moving into aristics into edrs into sensors into telemetry right if you want to understand it's not for this talk is this is not a prerequisite for this presentation but it's a prerequisite for uh uh doing windows kernel exploitation or developing rootkits. Uh so you need to understand first what is an overflow and their types. How do you do depth uh bypass? How ASLR works. A little bit of heap management because there is a lot of a heap uh in kernel. Windows internals will help to get the Windows internals books and also the Windows kernel programming book. Uh and if you have some knowledge on assembly that doesn't help you. You also need to have knowledge on C and C++

because there are a lot of professional that is skip during during the whole career uh um uh understanding programming the programming side of it and they go straight into assembly. But when you look at the de compilation of the in this case a driver it will help you to achieve results much faster if you know how to program in C or C++. So the last one is EIP control. If you know how to do a buffer overflow if you did your OCP everyone says yes I take control of the EIP it's not like that what you take control if of the flow right and that's quite important for windows can exploitation so first fundamentals recap

all right I'm going to cover this quite quick but basically um you have a division Let's start with the memory. You have a division between the memory that you use in kernel and the memory that you use in user space. Right? You can see here from this we have assigned two gigabyte of system space and then 128 terabytes of syn for 64bit. There are some section that has map and you cannot access from a user mode uh uh application into the kernel space and this is physical memory. Same applies for virtual memory. Of course, this is a virtual memory layout and um yeah and there are some things that you need to understand and we will talk about it a bit later on how

do you prove the memory you using you test if the memory actually let's call it proved for read for example and then you check if the memory can be accessed from kernel from the user these images were taken from the books so if you are interested go windows internals these are taken from there um and on the left side you will see the structure of uh uh of how the Windows kernel and the and the user space works. uh basically it's like a really simple uh schema but then you have system process services process user process as subsystem and then I'm saying subsystem DLS and you have different layers of wrappers between the user space and the application after you

reach the NL DLL uh that is still in user mode and then after that you go into executive and in the executive and in the kernel mode you have the executive device drivers and kernel. This talk is going to go through device drivers and how do we interact with user mode right? All right. And besides that, you have the harbor abstraction layer and then of course you have the hypervisor and some other components as well. But this is to make it a little bit more simple. All right, hope you are not scared yet. Now we going to cover basic software drivers. So um everyone knows what a sub driver is, right? Everyone knows. Okay. All right. So a driver is something that

you use is basically you can think of like a DL. It's a library like the DL. It's a module that you you implement you put into uh if it's the if it's a DL then you put it into your application and then you use that DL to uh use the functions inside that DL and then you can have it statically or dynamically compile it. But in the case of the kernel you have drivers. So you can think of driver like if there were library. So it's easier to to put in the box of knowledge in your head. And so you can think of a driver like that. But then when you in when you want to

interact with that driver, you cannot just say okay I want to use this function of this that you have to interact. I'm going to show you later with to a dispatcher and how to use IOCL codes and so on. But this is the basic of a sortar driver Viber. First you create a device. Viber create device. Then you create a symbolic link for the device on the top right. create symbolic link device. Then you define the dispatch routines for each IRP. We'll recall what is what IRP is. And then you have the major functions here. You see the major create, close, read and write. And then the device control right on the right. Then we have something that we will uh

go later but those are ICTL calls. And then at the end those are the functions and then you implement the IOCDL handler right all right and request packages. So I'm just covering the fundamentals. So when we go into the Windows exploitation it will make more sense. So IRP request package is a data structure to communicate between the driver and the operating system. So remember I say you cannot go from user pay to kernel. So you use packages to communicate with the driver from the process in in this case is IO that's input output request package and then you here I'm declaring the measure functions and then at the end I'm just calling the the drivers through device

IO control. Okay. And these are the device input anopo control. So those are the codes that are defined and dispatched by device IO control IO will will be selected per IOCTL per uh per control. Yeah, per control number. It has a number. It has a control code here on the right in this in this example. So I got the process. The process is communicating with is trying to communicate with the driver. It's trying to launch something. is trying to do an action and then he's doing it through an IOCL code. In this case, it's 222200 0. And then he's declaring the input uh data, the length, the output data, and the buffer length. Surely, if you never seen this, this

make no sense at all. It's like this guy is talking rubbish. But I'm going to I'm going to show you the code and then it will make more sense. Yeah. Because now it's only theory. Okay. At the end, you you get into the driver and then you get the the the communication back. You get your response to the IOCTL communication. And that's why I'm going to do a just a really quick quick demo. So you see a see a driver. So what I'm going to show you here is a driver that I develop just choose for this presentation. Um and then I I also have so I have the driver and the user mode application and the user mode

application is is going to run on the user space and the driver is going to be running on the kernel level right and then I'm going to use all these u structure IOCTLs and stuff to communicate with that uh with that driver. Then I'm going to show you an exploit and then I'm going to show you more I'm going to go deeper into it. But first and all all drivers they follow the same structure. So when you when you are looking for uh memory corruption issues or memory uh or or b vulnerabilities on other programs it might be quite difficult to find because then you have to understand the flow of the program and how it works. With drivers it's a

little bit more simple from an starting point because they all all follow the same structure. Yeah. At least they should follow the same structure in the majority. They don't have to, but they they they they must, right? Um one example is the use of IOCls. There are other alternatives to using IOCls like share memory if you are into drivers, but IOCL is something that you you use typically to communicate with the driver. There are other ways, but typically you will find the same structure. What it means is that if you grab any driver, so if you go system drive uh system 32 drivers and you grab any of those drivers in your machine and you putting into IDA or gyra and you the

compile the code, you will see something similar. The structure will be similar to the one I have here of this driver that I just made. So uh the structure is going to be like this. So for your libraries, yeah, libraries that you will use in kernel. So it's not that you can just call any library. They are libraries that going to be implemented for a kernel driver. And then I'm calling external functions in this in this particular case but it's it's not uh it's not something that is going to come by standard. I'm calling m M copy virtual memory to interact with the memory and then IO create driver directly from the kernel. But this is where it goes standard.

First I define the the IOCTL codes. Yeah. And then the structure. Sorry if I go too fast. It's because we don't have that much time. Uh so um this is uh basically the IOTL codes. I I have five different IOCTL codes. Uh I have attach read memory memory check write memory and kill process. Why? Why? Why do you think I have that? So what is going to do first? attach is going to allow me to attach a process and then move the process memory from that target process into my target process into the process. Remember? Yes. >> Yes. There you go. Um, so that's attach then read memory is going to allow me to read the memory of

attacked process. Bry memory is almost the same implementation but the other way around. I'm going to be able to write memory from the kernel. Check writable is basically going to try to write something in the memory of that process of that user memory process and if it doesn't is it doesn't succeed the statute is is is not the good status. So basically zero then uh it means that you cannot write it into it. So that's why you have to do check writable then kill process and choose killing a process. Yeah from target from from my P ID. So finding the the process P ID and then choose calling from the kernel is a different function is set W terminate

process. Yeah, it's different. It's different. So why is different? Why is important? Because the kernel is higher on the hierarchy of of processes. So you can kill anything from the from the from the kernel. Same from read and write memory. You might hear about ppl process protected process light like uh the antiviruses they run with ppl uh they run with uh with system rightes uh same for edrs you cannot interact with them you cannot read the memory of them and you cannot uh you can not directly you cannot access the handles for example to the antimalware uh from uh Microsoft right so MSMP you cannot choose you cannot read the handle of If you are kernel you can right all

right then a structure is this is the structure that we're going to use to communicate so basically we send a package and then that package needs to have a structure you define the structure that the package is going to have right and then this is the structure for that IOTL and then uh the major functions create IO close IO and then the dispatcher device IO control so device IO control is the one you have you see here switch control code and between the control code is going to choose between the control codes here 775 776 and so if that switch is like a nested if um it's going to go to read memory if the user

mode ask for 779 then it's going to go to terminate process 78 is going to go to bime memory Right? And then it's going to run this function. So the structure is create driver uh IO device control and then the dispatcher and then that's the custom code. Yeah. Because otherwise in most is mostly a structure. Yeah. All right. And then of course you have one of the major functions. It has it has to be but it's not always like that. Driver unload. So you can unload the driver from memory because otherwise it will keep there. Something interesting to say about I'm really I'm going really fast but still slow. So uh so when you talk memory when you when

you talk memory memory from the kernel you have to make everything right. So if you load a variable into the kernel you have to unload it. So fre it fre it. So you cannot just leave it there because it will not nothing in the camel we there is no garbage collector there is nothing like that. So if you make an error it will remain there until you reboot the machine right so that's I mention it because of the driver download some drivers they don't have driver unload and then what's going to happen the driver should remain there until yeah there's no way to uh unload it unless you use another driver. Um, all right. And let's see the

this is the user mode. So what I show you what I show you is the uh kernel application, right? So it's the driver. So it's it's a it's basically a DLL that is on the kernel and then a user mode application will act ask stuff to do through the dispatcher and it's going to say hey can you do this for me and this is your response. Can you do that for me? And then it's going to do something else, right? So, and they who does that the user mode application who what is the endine or the module is the kettle driver and we are talking about software drivers. All right. So, next you have on

the user mode uh the same uh I have declared here the same uh IOCTL codes and then of course the device name because I need to I need to know what is the device that I'm going to connect to. In this case, it's called camel pack. would be uh whatever you will find out uh that name of of the device driver that you are reversing to a decompiler or you can uh see it on the if you list the windows object list on globals uh then you can find it out um open driver then here I'm using all the functions attach process terminate process from the kernel check writable read memory so basically using all the

functions uh from the driver. Yeah, this is the main and the main on that driver, it doesn't looks like that. The main on a driver is driver entry. The main on a on a on a uh user mode application is main. So that that's that's a big difference. So if you want to go into the main if you are disassembling a driver, you have to look for driver entry and if you want to look for the IOC code, you need to find the dispatcher. So then you can see the the the the functions. Um so basically here I'm just creating the driver and then calling uh uh the each uh each each function from it. Here

I have a simple exploit and here I'm just using one specific IOCL IOCTL for kill process that 7 is 779 and then uh choose create then the file to in to create the device and then after that I connect to the device uh call IO device IO control and then I choose can I can ask for a P ID interact with it and then kill that P ID. Okay, enough of demo. Back to it. Exploit classes. So now that you have a little bit more understanding on how ex uh drivers works and remember um whatever you can do on kernel you can that's why it's rootkit development because you can make a the same you can make a software driver and

then have that power from the kernel and ask a user more application to do whatever you wanted from it right um and you will see some examples from it. But uh think on what you can do from the kernel if you have kernel power. Yeah. So that's why uh a rootkit on the on the kernel is basically game over. You have full power of the computer. There is nothing else besides that. There are some protections. I'm going to name a few but still. And how do you get there? uh prior to uh signing uh drivers uh you could choose load your driver. I just give you my driver and then he load my driver and

then I can connect to it and then I have my driver in your computer. But now you cannot load drivers just as easy as before and now you have to um assign your drivers and so on. So there are there are some protections that you cannot choose you can you can choose go ahead with that but there are some exploits that you can use to get access into into that uh into that memory so different exploit and now I'm talking about exploit classes use after free dangling pointers pool memory basically if you know about heap overflows and use after free uh pointers then it's quite similar the way that you implement that is a bit different because you do it

from the kernel But uh it's quite similar race condition to then uh what else boundary issues and these boundaries issues they are mostly into how do you protect the when I say boundary issues is how do you protect your driver from uh uh from user mode right if you have something mapped in the in the kernel and you don't uh check whatever is coming from the user mode using as I mentioned before read and this is the same structure and same implementation for uh for Linux as well. So it's not only the Windows kernel driver every other every other kernel does that. you have to check if what is coming from um the user mode is is user

mode or is kernel right so if you don't check that then it's it's basically free-for-all uh initial devices or info leak box is it could come as well from a use after free and then you get an info leak in kernel in at least in Windows uh it's this could be used for example to get the base address of uh other drivers or the driver of the NTOS Kennedy itself is there are some functions at this moment uh that you can use for that uh that's coming from Microsoft but it will change in the future but as at this point you you don't actually need info leaks but you might need in the future access

control logic is basically breaking the logic and giving too much power to the user mode and then uh bride access and read access it could be virtual or physical And the most typical ways are using Lars and uh direct primitives to access write and read. This is an example of an arbitrary right. Um this part is going to be inside IOCTL code. This is from a driver and you see that the mem copy is copying the system buffer. So basically what is coming from the ioctl from the user control and then it's send it there and then you have control of the file path and the length. So that's uh that's a lot and whatever going to show you here

um add this on part it's fine okay but what can you do with that I don't know so what can you do with this so typical pock so when you when you say uh an an overflow or heap overflow what you typically see on on user mode is a calc right you see the calculator popping up. Oh, it's fine. So, the pock on kernel is typically this is um getting the e- process structure and then getting the token from in most of the cases the process ID for because that's hardcoded and then you steal that token and then you put that token into your new process. So, that's how you get the system um the system uh uh the system uh command,

right? But what else can you do? Um, and what I'm showing you here is just a few examples, right? But there are some logic bugs. And this is one one good example. And this is from the from the code that I showed you before. And this is uh found with a tool called IOCTL lens. Uh, and you can also find it with a driver body. Uh, that is a plug-in for IDA. And this is just arbitrary process termination using set c terminate process. That's the control code system buffer and all of this has been found directly from static an from an static analysis uh using this tool. You can also find it with driver body. I think I have a

screenshot of that. Um and who is using it? Malware is already using it. This is like six months, eight months ago. Um and it's going for long. It's not just now. Uh this is from killf flooror.exe. This is not my screenshot. I I stole it from the from from the researchers. Um this is from the Abbas uh anti-rootkit uh driver and you see that is the driver and then what this malware does. So basically it's a malware that you get infected and then this remember I should say that you can only load trusted signet drivers right well the Abas is trusted and is signet and is installed in a lot of computers so that's why they they bring

their own driver it's called a bring your own driver uh that's a technique so basically the malware would load that driver yeah and then after loading that driver is going to use that driver to look for well it's going create a tool snapshot to basically create a snapshot of the all the running processes and then from the running processes it's going to try to use it's going to use that malware that that malware well it's a it's a little bit of a malware the ABS but it's going to use the anti-root kit from Abas the driver to run terminate process from the kernel using the ABS driver right and right so it's uh the list here's just a

a a snippet of the list but the list cover all the antiviruses. So, it's going to load that and it's going to it's going to do that. And here's a a quick uh screenshot from the from the code of the of the ABS driver itself. If the process name matches the malware creates a handle to reference this solid ABS driver as as as you can see that's the name create file then create a creates a creates a handle with it and then once the handle of the driver is created the malware calls the dispatcher that I mentioned device IO control and then it's going to call that IOCTL with the process ID that I already got.

So first it goes through a list of uh u uh antiviruses or edr names. So cross strike, abg, h macafei, all of them. And then if there is a match, it's going to get the p and it's going to kill it using the driver from a bus. Yeah. All right. And this is able to terminate the process at the kernel level for release by passing the tamper protection mechanisms of most antivirus and edr solutions. All right, enough of that. Let's talk about protections in kernel. First, the most scary one that that still you can bypass is the BBS virtual asset based security is coming from the hypervisor is hypervisor protected code integrity known as memory integrity.

What it basically does if you if you are talking about vanilla stack overflows, you always want to push a shell code into the stack. Do you want to mark the stack as a executable and then you want to run it from it? Right? So you want to be to have write an executation exact permissions. Right? In the most simple way what the hypervisor does is that you can either have a memory section writable or executable. Right? So you cannot have both and also use their own C sys calls as well to to get into the uh hypervisor pages and so on. So isolate and enforce code integrity policy for kernel enabled by default on many windows 11.

Then you have enforces stack protection that is control flow and all of the all of these protection they go being set together. So you have control flow that is basically checking the flow is is similar as you as what you have on user mode and then you have shadow stack in kernel mode. I think there is something similar as well in in user mode but basically shadow stack is having a a shadow stack of your the stack that you are using and then comparing the flow the returns of the flow and if doesn't match then blue screen of that and harden to address as swap in kernel the allocate and manage a shadow stack for

each thread and basically compares the red that's what I said then driver signing I already explained it a little bit of what driver signing is um then you have patchwire or KP kernel patchic protection that basically at runups intervals it will look into uh specific places a specific critical functions of the kernel and then if it finds that something is has been modified blue screen of dead and and it you don't know when it's going to when it's going to when it's going to run uh so a way to bypass this is to modify it do your thing and then modify it back. Um then you also have uh kernel ASLR so address space like route randomization

in kernel. You also have supervisor mode execution prevention is a security feature that has prevent detection execution of user space as is similar to dep uh so prevents execution and can be bypassed uh using rope z for hypervisor protected core integrity and then smap that's basically access prevention that prevents read right so we have smap and smap so it's execution and access um yeah And this map is quite funny because the register with flax AC can be disabled directly from user mode on the on the application. And then you also have kel cookies that can be bypasses if you find an info league or if you get uh uh the memory then you can just get that

uh and then override it with a real one. Okay. And how do you do it dynamically? So how do we approach this? Typically you will think okay I have to approach this from a C++ code. No there are some tools that you can use to quickly found uh issues and replay those issues. There are not many just don't don't guess uh high hopes. Uh but uh there are a few tools that you can use. I should mention a few. Uh ioctlance is one that's awesome tool to get a uh to get a quick uh check on drivers to see if there is going to find something. Then you have the driver body um that the plug-in for

IDA pro but it's not well maintained and it's quite old and it's not going to find uh the stuff like like it will not find the CTL ctl codes. It's going to miss a lot of stuff because it's old. And then once you find that you want to reproduce your let's say I found an issue on a driver then you you can use tools like IOCTL plus there are other tools that you can use as facers uh to get uh to get to do that and how it works on top you see the device path you need the the device name then the IOCTL code you need that then you need also the input size and the output size for

the data that you're going to send to that IOCL code to the dispatcher of your target driver and then you can choose send it on the left side and then also you have some history that you can do you can do right so if you say I found this heap overflow of this way to interact with this driver you can use a tool like this to reproduce it but there are some requirements so what do we need exactly as I said if you are the fer then you need the IOCL codes and then from there you can send that to the fiber through the IOCTL codes. So I made a tool. I'm going to give you

a tool and that tool is going to go over ioctlus and I improve that tool by using a driver hooker. Uh what what I mention is you have the driver right and then you have the dispatcher and then you can find the IOCTL codes by reversing the driver. So what I did is using a I placed a hook another driver in the kernel that is going to hook the dispatcher the the iOS the dispatcher of the of the driver and then it's going to of that specific driver not of every driver of the driver that you want is going to hook that and every time uh IOCTL is called it doesn't matter which one it's going to create a a new txt

file and going to drop the the name of the IOCTL and also it's going to drop the data of it. I'm not going to cover the code because otherwise you have no time. But this is the tool. So it has been expanded. It's based on IOCTL plus and you see can be used to make device IO control request with arbitrary inputs. The original tool has been improved with a driver hooker allowing the user to capture the data. And you can see now you can load the config from the hook that you got. The low load data from the hook as well. And on top you you first you have to start the kernel hook on top right. Then you

can select the target driver the service name and basically call that driver and besides the hooker you can also create a new instant of that driver. Then once it's running and you get a hook then you can uh you get a trigger the the hook is triggered then you can go into that file and load it and then you can reproduce it and this is what is is going to help you. Of course you also need to have your debuggy and your debuggy uh machine with windbg red uh red sync with gyra and so on so you can see what is happening. You can get it from here and includes everything. So it's the binary in binary

form or also the source code. So you can uh compile it, modify it and do like I did with IOCTL plus I made the IOCL++ so you can make the IOCTL rust or something like that. That's even better. Uh so bonus um f first let me show you the IOCL plus I think I go let me show you how it works. I have it running here. So this is a tool and I'm going to start the GLE driver

first. I'm going to remove this that I tested. All right. Um,

okay, this is the uh the driver. So, the hook now is on the kernel. So, the driver with the hook is on the kernel. And now I'm gonna create a new instance of the remember I show you the the the driver that I made for this presentation that it has also termin terminate process choose the same code. I reverse engineer the driver from Abas and I took the termination uh the the the part that is using for that and I put it on this on this one. So you we use the same code but not that one. So uh use something similar but it's the same. So basically, well, I need a name.

All right. Now I have the hook and the driver loaded in the kernel. And now for the device list, I need to select that here. And I'm going to set the hooker on to that because now I have the both drivers but they are not communicated with each other. Now I'm going to instruct using an IC IOCL to the uh kernel hook driver to start hooking this device kernel pack. All right. Now the hooking is ready but now I need to trigger a hook for that. So I'm going to do that. That's why I also made uh here.

No, in the rootkit folder.

Oh, is it here?

I should have a release somewhere. Oh snap. Maybe I don't have it. No, it cannot be.

Yes, it was there. All right. I don't know why I have three copies of the same, but fine. Um, I don't typically I don't use this uh laptop, so I just made a BM for this uh for this presentation. So, I can use it here. But what I'm going to do now is from the user mode, I'm going to call. So basically here if you if you are replicating the the ABS case uh then it's going to be the user mode application in this case I have my own user mode application to communicate with the driver but basically I'm going to call IOCTL code from it um I'm going to do it uh can do it using the user

mode app like this that when I connect to it it's ask me for a P I can also do read memory write memory and so from the driver. But let's uh let's kill a process. Let's open notepad. Well, okay. Notepad++ and then let's kill it. So the P ID is 10772. 10772. Done. I And this is the user mode application choose interacting with the driver. But because the hook was in place now I can go load config from the hook. I can go into where the hooks are driver hooks driver kernel driver and I have this here and I can load it and as soon as I load it it got me the IOCTL code the decoded

IOCTL code. So I can also see uh the the file access the method that is using if they has a a device type and then the the function in this case is 775. I think I should have another one

779. All right. Uh and then I can also load the data.

There you go. And you see that this is the data that has been sent from the user mode application. Remember the hook was in place what what this was interacting with. And you can use the same if you want to look how an IOCL works when you use your actual antivirus or if you use tools like uh process explorer or something like that that you can see hey can I do something with it um all right so 42A was so that's why I have here the X2 decimal so that that was the one that's the P ID key, right? Because that's the one it captured and you see that I put it in reverse because it's from memory. So it

goes in reverse. Uh so now now we are driver and we can replay that. So but instead of just killing our own notepad, let's keep something that we shouldn't be killing like uh I don't know 4316 that is a system uh is running a system uh the handle and then is also with ppl. So uh 43 4316. So DC one zero and should be this one. And then I'm going to replay it and it's gone. And so we replay it the hook. Yeah. From the user mode application. If this was just like with the bus driver, you could do it as well. And there are a bunch of of applications that they do that. And it's not only to

call terminate process, right? Uh you can just use it to find your hip overflow or whatever you wanted. All right. Next, let's say wait there's more. That's from application system explorer. And in this driver using IOCTL uh code as well found read control address. So basically I can read or write uh on on on this driver in a controllable uh way and there's also destination controllable but you see that it goes into the same IOCL code that one and this is from the driver body and the driver body this is from IDA and I I run it against is basically the same uh test and it found that is using memove in that function sub function 1 one zero

444. Yeah. And so what you need as as as I said in the beginning, you need a device driver. If you want to write the exploit, you need the device driver name that is going to be device list uh uh list file driver. I got this from the driver entry. You can see it on top. And then here are on on the right uh you see the dispatcher functions. And as you can see and if if we go to the to the me move is in sub 111044 and you see that the four major functions including driver unload they point to the same no sorry driver unload point to driver unload and then the three major functions they point to the

same uh function the vulnerable function. All right. And this is a reversing of that function specifically. And you can see uh that inside sub 111's A you have the uh IOCTL code that is going to select that one. It's going to check if it match. If it matches, then it's going to choose go there. It's going to go to 1144. All right. And we found the minimum. That's the vulnerable function that basically uh you you can control the buffer the length just like the the the exploit that I showed you in the beginning from a different driver. Uh this is from uh system explorer and it's basically the same exploit. You have control of the buffer, the length of the

buffer and if you if you manage to see on top the me move is also not controlling the the the length of what you are sending into. Okay. Uh so basically uh if you want to taking control of the length of what you are sending to the buffer then you have an overflow as well. So you have an overflow and you can take control of what you are sending into. So it's basically game over. So what do we have here? Two issues. First, no proof for read. So whatever we are sending from user mode, it gets executed. So that's completely wrong. That's the fix. So the fix that I'm that's the fix. So you should use proof for read and then get

the user buffer and then the user length and check if where it's coming from by using proof for read. They are not doing that. And then the heap overflow here. Uh this is not what the code should be because the the code is bigger to to fix it. But neither copy secure the length that's that's the length of the basically the input and the and the output. What do we need the way to local privilege escalation codes? We have it 22e00008 and the device name. We got that from the disassembly. Yeah. And the hooking uh the input buffer we also got it from the hooking uh the eight is the input and the output buffer is 144 that there

is no control if we send more the vulnerable function we need one of course if you want to make an exploit and in this case we're going to use mem move right um the windows API uh to get the the token address to make the poke that I mentioned uh before and I as a note the driver base address is disclosed by system model information class. So basically you can get the the base address of it. So goal to get the token is first antiquery system information uh to quote unquote do the kernel uh ASLR info to disclose the token address of the of the process system 4. So basically, you know, you have the system 4 and then you

get the token because it's running a system and then we want the address of it. We're going to map the kernel page with the token to user mode using the me. Yeah. And then override the privileges with a field to change to uh se debug privileges and choose a a a parenthesis. This needs to be run as admin first because you are accessing a driver. There are ways to do that without it but in this case it's doing it like that and then spain spawn a system shell with token of system 4. So basically we will create a new process we're going to change we're going to look into the process list entry and we're going to get the token from system

4 and then we're going to put it into a new uh process and that's how you get system on local privilege escalation using this driver. All right, that was a lot guys. I hope uh something uh it helped someone. If you want the the tool itself, you can get it from ioctl uh uh++ from GitHub. Here there is also the QR code from it. And uh if you want to start doing window kernel exploitation, reading is not the answer. Doing is the answer. or set your uh Windows debugger, get Jedra, get some get to play uh and get to replay uh the pox from uh from the internet and start start doing start doing and as I said in the beginning is

not starting the starting point should always be uh developing. So basically start programming your own uh drivers understand how the structure work and then after that you can move into exploitation. All right. Thank you.

>> Thank you. Um, any questions?

Sorry. >> Uh, hi. Is there any actually something a driver can do to defend being called from user space or specific user space programs? >> Sorry, come again. >> Uh, is there anything a driver can do to prevent being called from user space? So if I write a driver for an application and I only want this specific application for example to call me. I mean I could sign the request or something but then obviously I can extract the key private key from the application for example. >> Yes. So I I mentioned a few I mentioned a well more than a few protections from the kernel itself from the operating system from the kernel but if you are

developing a driver there are ways to check for the IOCTLs when you receive something. So the first check if by the structure of the IOCTL itself if the IOCL doesn't match the structure then it's going to get discarded but then you can also a simple check will be to say hey the target P is from the process that I'm expecting to receive if it's not then choose discarded but in my experience you don't see a lot of that implemented but there is you you can Hello. Hi. Um, not my area, not my expertise, but my understanding is that drivers have bad code. This can be abused, right? So, you saw the memory copy or memory problems in the drivers.

And I was wondering what is Microsoft doing in this case, right? So, they have driver driver signing. Is there any programs at Microsoft that look at the driver look at the driver code and says hey um your code is not good and this leads to exploitability before the driver is signed. Yes, they are they are doing uh um first all the drivers now they need to be signed right. So first you need to send it to Microsoft and then uh they are doing a quick check and if the driver is fine then it goes is signed and then you can use it with your device or with your choose software right um but just if you go to media

mark or or saturn you will see that there's a lot of hardware right so and most of this hardware they use drivers they share drivers as well but uh the the mechanism of checking and signing is not as uh as as harden it as you think but if you go and use a Windows server, then it's a different check, right? Say they they they go way deeper into into into the check. Uh so it's not that they just going to give you uh a signet driver for a Windows server. Besides all the uh besides all the protections that I mentioned and if you want to look what is going to come next on 2026 uh then you can or you can

choose go and check the insiders preview from the from from windows and see what is going to come and be prepared. All right guys, if uh you have any further there's more no more questions. >> If you have any other questions then you can uh contact me here in the future. >> Okay, thank you very much.