BSidesCharm 2023 - Detecting and Triaging Modern Windows Rootkits - Andrew Case

foreign

[Music] so thank you all for coming for those I've met before my name is Andrew Case and I spend a lot of time doing memory forensics and malware analysis today I'm going to be talking about one of the latest research efforts I was involved in which is we did an exhaustive study of all of the windows root kits that were found in the wild in the last couple years so ones that affect Windows 10 and all of the security protections are enabled they can load also because we deal with this type these types of threats a lot obviously root kits in general are a grave threat to privacy and security once a root gets on a system and active

they can do whatever they want to the machine they have full control over all the operations they can blind any security products looking for any activity on the system and we noticed in our investigations I would say over the last two three years and this was shown by other security vendors as well because we read all the reports that come out that there really was a return to root kits appearing on Windows when Windows 10 first came out Microsoft had driver signing enforcement if you're not familiar with that we're gonna have a couple slides that explains it in great detail but the idea is my Microsoft came up with this driver signing enforcement idea and it made it where you really had

to be a legitimate software company work with Microsoft to get your driver to load into the kernel obviously something fell apart with that protection it fell behind the times because we started seeing root kits on Windows 10 which is not something we were used to so again we wanted to Deep dive these Roux kits figure out how are they actually loading on the machine what were they able to do on Windows 10 that they couldn't do on Windows 7 and before and obviously how could we detect them before we start any research project we always come up with the goals list so we don't get lost in Fall Down rabbit holes I'm sure no one here has done that

before so what we wanted to do was come up with triage techniques to figure out does the machine have a root kit on it and then if we have a bunch of machines that we're supposed to protect or sweep across how do we figure out quickly if a bunch of machines have signs of a root kit so we wanted to make these effective we wanted our techniques to not miss root kits that were there but we also didn't want a billion false positives saying that every machine and environment has a root kit when maybe one or zero of them do is not very helpful and then we also wanted what what we researched to be scalable

because it's very rare that we deal with like one or ten machines in investigations it's usually a lot of them that we have to get through quickly so if you've seen my talks before or research out of our group you know the two places we like to look are memory so we'll see some memory forensics this is where malware can live undetected where it also has full control of the machine and when it comes to historical records and being able to sweep across an Enterprise very quickly event logs really can't be beaten so we'll look at that we'll look at that as well if you're not familiar with memory forensics this is where you get a

capture of ram from a system so if it's a laptop with 16 gigs of RAM you're going to walk up to that machine run your software maybe you push the software across the network and then you walk away with roughly a 16 gig file obviously in an Enterprise environment you want to do it a little better than that but the idea is you're getting back a static copy of what was in Ram at one point in time the reason memory forensics is so powerful and the reason why it's used so much is that all of the malware that was present on the machine is going to be stuck in memory along with this exact configuration so when we

especially when we're talking about kernel root kits those things can be really nasty even if you're great at reversing even if you have years and years of experience with it it's really annoying to deal with kernel root kits if they're doing anti-forensics techniques and so on whereas when you have a memory sample the rootkit has already put itself into memory it's unpacked all its components decrypt everything it makes your life a lot easier and then the other reason why memory forensics is so important is that malware of this type is truly hidden from the live machine so whether it's your favorite tool something out of like CIS internals other software that you've written if you're reliant on the live

apis or on the live system to tell you what's going on that's precisely what the malware is going to hide so you're never going to see it anyway and this was just an interesting report from Microsoft that I clipped into the slides where they talked about this core lump software this was actually an awesome report they basically burned a company in Australia that was like four higher kind of like cyber mercenary groups if you want to call them that and Microsoft just burned their entire toolkit down to the ground and this was from it so Microsoft called the malware or one of the kind of the main malware component core lump and it talks about how it

lives only in memory and this is just one of many examples of if you're not doing memory forensics you know you're going to miss the malware on that machine so we'll see a lot of that the other thing that's incredibly powerful are the event logs if you're not familiar with event logs these will these will record a wide wide range of activity that happens on the system this occurs even by default but then if you configure them a little better you get even more information and the other great thing about event logs is their time stamp down to the second so if you see that something happened on the machine that you care about now you know

the exact second where that happened and in many organizations almost every organization that we work with now the event logs are centralized in some sort of way so you can say from one system write your query you want to know do certain event IDs exist do certain event log sources have records that you want to look at you'll see a few examples of that in the slides and that immediately tells you if there's somewhere to dig into and so it could be an Enterprise with thousands and thousands of machines and like we'll discuss in the slides there's some event IDs that are never good and if they're on any of the machines you immediately need to get

memory get your files off of there and start a real incident response process so between memory forensics and event logs if you're doing malware analysis IR these are by far the best places to look so now we'll discuss how the rookettes actually load on a system the recommended way if you've done malware analysis a long time back in the XP days I know there's some like hacky ways that drivers could load Microsoft has closed those out so I really just want to focus on the Windows 10 ones the ones that you're going to see most often in the wild so the way you load a driver the recommended way is you're going to create a service service services are

very powerful components of the system you can have Services run as a dll or a process and it's also the way to load code into the kernel when you create that service you tell Windows where the path is to your driver file so that executable on disk for your driver and then whenever you tell Windows you wanted to load upon system boot after a certain time frame whatever that trigger is that's going to get that loaded into the kernel so for root kits that want to load they normally want to load at startup they want to maintain persistence on the machine they're going to create a service now there are event logs for this but it's really noisy

because every third party application lots of random drivers are going to create services and so on so I'm aware that Services create event log records but we're not going to talk about those because in a real Enterprise you can't triage with them so you might be wondering though I kind of mentioned it before sure root kits can tell the operating system that they want to load their driver but as I mentioned Microsoft made a bunch of changes in Windows 10 so that unsigned drivers so unknown non-secure drivers aren't supposed to be able to load this talk I'm giving today should not exist if this worked obviously it didn't so I'm here talking about the root kits

that are in the kernel so the idea here is if you want to get a properly signed driver on Windows 10 so we're talking about legitimate vendors here not rootkit authors say you're an Nvidia or anyone else that has a driver for something that you ship to your customers you have to cross sign that driver with Microsoft so that means you have to upload a copy of that driver to Microsoft you imagine rootkit authors don't want to do that it's like sending it to virustotal kind of defeats the purpose um and then at that point Microsoft cross signs your driver so this is really bad for you right because Microsoft has a copy of the file and

then to get one of the certificates that you need to do this cross signing you don't just go to like GoDaddy or something like the old days and get one there's verification of the people involved the company involved and so on you can't just get like an anonymous email address and five minutes later you have your certificate the motivation for having this cross signing and this really difficult or kind of uh I'm going to call it difficult way of getting your driver cross-signed is because we all know of the famous stories of when this didn't happen where you could take any code signing certificate from any company sign your malware with it and load it

the very famous example of it was stuxnet there's been a bunch of other ones where companies get hacked the attackers purposely Target their code signing certificates can you imagine if every laptop desktop in your environment had an Nvidia card and then you had to disable all of their certificates and now no one has a screen they can look at anymore like it's just not feasible so this is a very uh I mean honestly it's a really effective way by the attackers steal the certificates now they look like legitimate software a lot of AVS and other EDR type software are going to skip scanning your file or skip scanning it is hard and so this works really well

which is why we now have the cross signing and as I mentioned before there's a lot of steps to do this if you want a lot of pain you can go back and read these slides but it's not a five minute thing to get it cross-signed so at this point you're thinking okay there really shouldn't be rootkits on Windows 10 they shouldn't be able to get in the kernel Unless somehow they make a fake company with fake identities and all this craziness well what malware authors did is they just said I'm just going to break the driver signing enforcement protection now it's like we're back on Windows XP days and I'm just going to load whatever I want which is obviously

not good from a security perspective so this is known as bring your own vulnerable driver I'm going to spend a couple slides on it there is a talk at two in this room in this track right after lunch where the whole talk is on vulnerable drivers I didn't know that obviously a few months ago when I submitted my talk um but if you've never heard of this before if you want a lot of technical details I would recommend coming back to this room after lunch for that talk but the idea with bringing on vulnerable drivers is you're going to take a vulnerable driver that is signed so this is from a legitimate company you find a

vulnerability in their driver that allows you to manipulate code in the kernel and this has been used by dozens of Apt groups in all sorts of attacks all the root kits that we see load have to do something with this if they want their driver to load because again their unsigned root Kit's not going to load if the DSC is still on so they're going to use a vulnerable driver use that to manipulate the kernel and then from there they'll be able to load their code this is one of the first really good uh public documentation of this like exhaustive documentation of this this was from rapid7 I believe a year ago there was actually a blog post by Splunk

last week where they went back through it all and all the drivers again because this just keeps getting used over and over and the idea is you might recognize some of these driver names so like vbox is virtualbox um there are some for like proc mons one of them part of CIS internals so there's a number of drivers these are cross signed by Microsoft and again the ideas are vulnerable in some way maybe they have bad API designs so that any process can send them commands those commands will let you write to physical memory read physical memory overwrite the kernel and so on so you have literally dozens of drivers that you can use to

still manipulate the kernel and then get it to where you can load in your malicious root kit and the problem with this you might just think okay there's vulnerabilities in software every day there was just a talk right before this on that and these are not all ones that can be fixed right away they're not all buffer overflows they're not all things like that where you just update the code recompile it and now they're not exploitable like I said a lot of these are by Design so you would have to go to the company and say hey your driver is being abused by root kits redesign your software stack from scratch in a week so we can stop this

and then ship it back out that's just not going to happen all those companies aren't going to fix it and the other problem is is there's Legacy Hardware right like there's a certain I'm not going to call them out but there's a certain Hardware vendor that sells network cards to a lot of Enterprises and their drivers are notorious for being vulnerable to this attack but it's the same thing if Microsoft pushed out and tried to disable all those drivers at once now those machines can't get on the network they can't send packets it's just it's not going to work so there needs to be something done about this maybe some fall off period where those

drivers could be disabled but until that happens um root kits are going to keep loading through this way so once you've found a vulnerable driver what can you do with it as I said you can manipulate the kernel at will you have you're going to eventually get read write access to the kernel but it's very hard to do really intense detailed operations through that primitive you're basically trying to write a root a root kit as Shell Code which that's very hard that sounds absolutely terrible so instead what root kits are going to do is they will simply the Second Step here they're going to disable driver signing enforcement now they can load whatever root kit they want and they can just

create a service or they can load it from a pre-existing service the rootkit is active and all of these defenses fell apart so again if driver signing enforcement was a little more robust if these issues didn't happen this talk wouldn't exist we still wouldn't have root kits on Windows 10 but we do and so until everything is fixed that I mentioned on the last couple slides this is going to keep being a problem we see it all the time and like I said there's vendors at least every couple weeks there's another blog post from a big vendor talking about it so how do root kits actually disable driver signing enforcement there was an old way for it so starting in Windows

8.1 plus so I know when you said anyway so we call it Windows 10. the idea was inside of the kernel there was a global variable called G underscore CI options and it was just a basic integer or number if it's zero it's disabled and if it's one it's enabled very simple right so with that basic primitive you got from having a vulnerable driver you just had to locate that variable in memory switch it from one to zero and then you could do whatever you want obviously that's kind of ridiculous for all of the infrastructure where you have to upload drivers and such so Microsoft wanted to fix that we'll get to that in a couple

slides but my first thought was well we should be able to detect that with memory forensics right we can find that variable ourselves we can check it and if it's on a Windows 10 machine and that variable set to zero hey there's a rootkit that switched it off so we need to look into this unfortunately that didn't work I probably should have reversed those root kits a little more before are writing the plugin the plugin was kind of short anyway but I eventually realized that all the root kits reset that value after so you can imagine the machines clean the attackers get on the system they load their piece that's going to disable this so they set

this value to zero they then load their malicious root kit and they set the value back to one so the enforcement was disabled for that's a small enough time period to let that root kit load but then it goes back to how it was previously so then I kind of re-examined it I'm like what can we do in memory to find this anyway I found these two really awesome blog posts so the GCI options in a virtualized world and the swan the swan song for DSE tampering two separate blog posts if you're interested in this I definitely recommend looking that up and the long story short is there's no memory forensics way that I could figure

out to definitively know if the SC has been tampered with because these list out like 20 different things if you reverse the code pass there's a ton of functions called a ton of variables consulted so there's at least a couple dozen ways you could disable DSC and it would be very hard to have like a comprehensive volatility plug-in that did all of those so it was back to the drawing board memory forensics wasn't going to immediately tell us if this happened but luckily Microsoft now has what's called in their expanded event log set they have two things that are really helpful to us one are the code Integrity logs and as we'll see on the next Slide

the security mitigation logs again this is event logs this is just in the tool I use for event log forensics it'll look exactly the same in anywhere else you ship your event logs and the idea is inside of the code Integrity provider there's an event ID 3004. it's kind of funny it says the first sentence is like this event is isn't common so I'm glad that like Rook hits loading on the machine isn't common but the idea is this is going to fire whenever an unsigned driver loads into the machine and if you read the whole page I have the references on my last slide if you read the whole page here there's some other closely related numbers so you

want like 3005 and six and so on but the idea is Windows is like hey this unsigned rootkit was trying to load for some reason that shouldn't happen I'm going to throw that in the event log so you can find it three months after you've been attacked but the root Kit's gonna load anyway like come on um the good thing about this is remember event logs are time stamped so you at least know the second of when your machine had a rootkit active on it again this is probably going to be loading in a service so this would be every time the machine rebooted it would come back but you can get back to that first time

pretty easily of when did this show up on my machine and this would be a really good example on Monday when you're at your office if you sweep your network for the code Integrity provider event ID 3004 and you see a bunch of hits um it should be root kits I'm going to get to an exception in a second I took out the slides I didn't think it was very fun or nice but there's this one which you'll definitely want to check and then as I mentioned before normally root kits are going to have a service associated with them it's 100 possible and it happens where a root kit will load its Service as a just the driver

and then you have this nice driver file sitting on disk that's what you're seeing on the previous slide another variation is they'll have a process based service as well that process might load the driver part or it might just be a separate component so now you have the malware active in user Lane and the kernel so on this machine where this is a real root kit we'll see some output from it when we're running volatility plugins the previous slide was the kernel driver component loading and this slide which you can see now we're in a different provider we're in the security mitigations part the event ID is 11 and it's telling us that a service host

process which is like a privileged service loaded this unsigned DLo so again you're like why do you allow that to happen you're writing out an event log just block the dll from loading in the first place but by querying for these IDs you have a really good idea of which unsigned drivers loaded in the kernel and this one's not documented extremely well the other one really isn't either but the idea what I gather from it is when an unsigned dll loads into a privileged process like a service host or something else it's going to flag this if you have some random third-party application that's loading unsigned dlls it's not going to trigger here but your main is really important

here because this tells you which services are loaded and created on the machine with unsigned execute which is a really common way that root kits Operate Now the exception to this and it gave me a heart attack for a second is when I originally found all this out and was documenting the IDS I like to go look across our the sources I can see from historical investigations we've done and then some live data on client networks because I want to know like is this just going to produce a billion false positives and it's a waste of time so the first thing I did was look for this one and I've got thousands of hits and I was like there's

no way that so first I thought my query was wrong like I typoed something I'm like no right provider write ID again thousands and thousands of hits across like every customer that we have and I'm like there's no way that like all this was missed and like there's all these root kits and everything there's got to be something wrong so I'll talk a little slow so you can try to think on it but if you can imagine there's one class of software products that make a lot of claims that are usually wrong and they usually end up shooting themselves in the foot to supposedly provide security on your machine that's what those thousands of hits were now there was

definitely signs of malware that we found that I found in those queries I checked with our services team they had known about them like there was previous you know IR situation questions for them but outside of those the tens of thousands of hits every single one was an EDR vendor unsigned dlls their services loading they're they weren't not the driver ones but these dlls from disk loading into Services everyone was a security product and if that doesn't scare you what that means is those vendors are shipping dlls that aren't signed and then loading them into service host processes that run with the most privileges possible now if I was a red teamer and I did offensive

research instead of talking about stuff like this I would profile every EDR vendor there was I would find ways to infect those files or you could really just replace those files if you wanted and now you're going to load into those EDR products you can disable everything and you have a really nice persistence mechanism because what's the first thing everyone does is they go into their allow list and they put everything related to their EDR product well at that point you just put into your allow list everything that the malware does so I very easily think you could get at least one if not two blackhead talks out of that just throwing it out there for

someone who wanted to do it but with my position I don't think that would be a very nice thing to do but it was definitely work like it just blew my mind that run-of-the-mill like like every single one like if you write RSA last week it would be just like looking at those logs all the vendors that load unsigned stuff on your machine foreign so at this point we know that root kits can load into the system we know they're not supposed to but DSC can be bypassed as we saw and as we talked about so the other thing that we wanted to research as part of this is the kernel patch protection normally known as patchgard

kind of the same idea so the idea is there was root kits since the earliest days of Windows and they kept abusing the same features over and over again so Microsoft had a really good idea which is why don't we protect those features and so the root kits don't have that level of control over the system so for a lot of the old things that rootkits did if they try to do them now the machine's going to blue screen which is not very helpful also if you have full crash jumps enabled that's going to trap the malware into a memory sample now I put stars because there's always someone who likes to raise their hand and say

well technically the malware can do this and get out of it I know I'm well aware of that but in 99 of the cases the malware will be in that crash jump that is produced and the thing that caused the blue screen will be the malware itself which is not once the malware others want to happen in the wild so uh rootkit authors want to avoid patch guard and then you also have to think to yourself uh like patchguard really doesn't have a lot of bypasses they're patched very quickly when they do happen so looking at the places that petchguard protects is not very good for triage because 99.9 percent of the time the malware's not going to be there because

it would have crashed the system out anyway so I wanted to figure out what was the latest version of what was being protected by patchguard and sometimes Twitter is actually cool like I tweeted it out like 30 seconds later one of the like gods of Windows internals is like hey run this at windebug and I've solved it for you I'm like this is awesome so took that window bug command loaded a VM ran it through uh wind debug once it was loaded the idea here is we're looking for reasons that would cause this 109 exception which is critical structure corruption and if you're familiar with memory forensics you use volatility before or anything like that everything

in red literally Maps directly to a volatility plug-in because these are things we wanted to look for in the past to see if root kits were performing these actions to detect them and now we don't have to anymore some of these obviously they're one sentence and you can make kind of a guess at what they are and I'm pretty sure some of these are covered by volatility but I only highlighted the ones but there's literally like there's a plug-in called IDT where you check the IDT and the gdt and you can check if the process list is corrupted and so on so you can imagine Microsoft had similar motivations to we did with volatility like root kits are

doing something we want to catch them root kits are doing something Microsoft wants to stop them from doing it so what are we so a big part of our research effort was to figure out as we're analyze analyzing these root kits what can they do on Windows 10 that is still deadly to a machine still going to let them hide from all of your security products still going to let them steal everything off the system and so that's what we're going to look at for a few slides just a quick recap when a kernel driver loads there's two data structures that are going to be created and that we can start our attempt to find the malware or

the root kit the first thing that happens is okay the first thing that happens is a kernel module data structure in memory gets created you can see that here it's going to have the path out to disk but just running this plugin is definitely not good for triage because I cut something like 250 rows out of this slide there's a lot of Kernel modules on a clean system the important part here though is the base so this tells us where that executable is going to be in memory and then depending what you're doing the size can be important as well besides the module data structure there will usually also be driver objects so this is what's going to allow

um a module or a module to be mapped back to its service and also this driver here is how processes can talk to it so a simple example would be if you have like an Nvidia card you have that GUI that lets you set the fan speed and the colors and whatever that is in many cases just going to talk to the device that that driver makes so you can set the values so when we're looking for these kernel mode components there's two things we want to look at to start the modules and the drivers again this would be the place in the registry where that service is you get the start and the size and then you get something close to

a name but all again you can't look at this on your own because there's going to be a couple hundred rows there um there's going to be a couple hundred rows so even on one machine it's too much to look at on your own that was interesting and blinding okay so just like uh so what we want to be able to do is figure out when root kits tamper with these data structures there are apis on the live machine that are available to you if you're using certain like forensic tools on the live machine or certain malware analysis tools that even from userland can recover the modules and the drivers that are loaded and then

certainly your EDR type products that are loaded in the kernel can figure those list out the same way volatility does so what malware will do is a couple things one is they're going to unlink themselves from the module list so they just won't show up on this slide anyway technically patchguard protects this but I've like with my own eyes seeing machines where the modules on LinkedIn it didn't blue screen so I don't know if that's some like bleeding edge feature that I just haven't triggered yet or something so that's why I have the star there but this definitely works the other thing that Rook hits will do is change the driver's metadata which the idea here is they don't want you to be

able to know where it is in memory so if we go back to the driver scan I'll put this is the Base address of where that executable starts in memory we get another copy of that same data in the module structure so what rootkits will do is zero that data that's usually what they do right they could technically put something else but normally they make the Base address zero and the size zero so now to start you don't know where that is in memory so that makes it difficult if you to find it because it's not going to show up in your normal listing tools but this is very nice from a memory forensics perspective because

now there's this weird disconnect where you have a driver in memory that like technically doesn't exist anywhere and you have a module that doesn't exist so we have a plugin called driver module and what driver module does is it compares the metadata from the modules plug-in that we saw before and the driver scan plugin that we saw before and it just kicks out ones that it thinks are weird and in every root kit that we studied as part of this project every single one fell to driver module when they tamper with the metadata and so on you're going to find it so just to kind of illustrate how this works this is a root kick called Dirty Mo this

write-up was like really awesome oh you can see the browser or whatever generates this that it would be almost a 40 minute read I mean this this company like tore this rootkit apart so so we got a sample a malware sample so the driver file we then created a memory sample out of it and so you can see us running volatility 3 against it um you had the offset this is the data structure address but the start that should tell us where that executable is in memory is zero and the size is zero like I said this is what you're going to see in most cases so you could I don't know run driver scan and Grub for zero

and hope you get lucky but that's not very automated so instead you could use driver module so again what this does is just prints out drivers that it thinks are weird something to be aware of is this known column so there's like eight or nine drivers that will legitimate drivers on a clean system that will always trigger this plug-in and so what known says is like yeah we know this is going to do it you can ignore it obviously you could configure the plug-in just not to print those if that's easier for you but in this case it finds the weird dump EDC B5 a3c automatically and that's the only one it shows that isn't true it only produces

two lines the slide's not cut so it tells you this one that you can ignore and this one it's like hey something's wrong and we know that the reason it couldn't map the driver to anywhere is because these are broken so with just running one plug-in every root kit that we found that we studied as part of this immediately fell to driver module so that's good and bad right like now you know you have a root kit on the machine you don't immediately know where it is in memory there's some I'm not going to talk about it here but there's some more advanced memory forensics techniques you can use to find that in memory but the

idea is you know we definitely need to investigate this some further foreign

so besides being able to still tamper with the metadata that they have available some of the common techniques that Ricketts have used forever still work and it's not just that these are available the root kits are still actually abusing them so the idea with irps is if you want to send a request to a kernel driver so again I like the video example say you tell your through that GUI you tell the Nvidia driver hey I want the fan speed to be 50 that GUI is going to take that value it's going to encode it and obviously it can't talk to the driver directly because the driver is in kernel space so it's going to use one of the IRP requests that the

driver is expecting and say hey this is the fan value that the user wants and this happens for everything that is in a privileged space your random notepad that's running can't write directly to the hard drive your browser can't write packets directly to the network you can imagine so if you think of it as whenever you want to talk to a hardware device or you want to deal with a privileged part of the kernel those processes have to make a request because obviously the kernel can say no if you try to overwrite a file you don't have access to the that gets denied and there's nothing you can do about it so there's plenty of legitimate reasons why

these exist operating systems would have no security and no real features if they didn't but this also gets abused heavily by root kids because a root kit can start you can imagine you get some type of like connect back to a machine you're running as an unprivileged user well using the software that the the rootkit authors write you run it and you say hey I want my process to run a system or hey I want my process to be hidden from the live machine and now assist internal is Task Manager all of those won't be able to see it so analyzing these IRP handlers is really important because basically every rootkit uses them to talk to back and forth with its

processes this is these are the entries again this slide isn't cut so this is a full IRP listing uh read and write we talked about so if you're trying to write to a file system or read from a file system from a rootkit perspective the ones I have in red these device control calls are how you ask a device to do something and read the response back so again I want to hide process 42 or I'm making network connections on a certain IP address make sure those are hidden from netstat and TCP View and so on all of that will go through here we have a plug-in to enumerate these handlers in volatility it's called

driver IRP what we're looking at here is a clean system just so you kind of get the idea and this is the normal flow so you have all of the handlers for the different driver and normally what happens is this last column here is the driver that's handling the request and this First Column is the name of the driver so you can see for the create call that's being handled by the NTFS driver for named pipe it's being created by ntos kernel which is the kernel and in most cases this is what you expect the driver either handles the request itself or it's a request it doesn't care about like maybe so NTFS in this case probably doesn't care about

name pipes it just tells the kernel hey I don't care about this one there's a certain value that can be set and then the kernel will handle it on behalf of the driver so it's just a much cleaner way to write the code as I mentioned root kits like to do two things with IRP handlers one is they have their own so that their Associated processes could talk to them and then also when they want to take control of a system and hide things a really good way to do this is to hook the IRP of the driver that's responsible for it so if you hook say the NTFS driver then you and you want to hide the presence of

your file or if AV is going to scan that file for signatures and you just make that file all zeros are all F's dynamically as it's being read the AV is not going to find that you're there so this happens a lot again there's some documentation that patchguard like I put supposedly because again I've never seen it happen but for what's deemed critical drivers which I would only could assume is like the network stack in the file system and so on patch guard's supposed to crash the machine if these are hooked but I've never seen it happen and we tried on the latest versions of Windows we could get in such and I don't know

patch guard didn't do anything so this is looking at driver IRP against uh ghost Emperor this is the same plugin we saw before so in case you forgot when we ran driver module um we got got it that way so against Ghost Emperor this was a root kit published about um from kapersky this was another really really good write-up that uh kapersky did so for this one they said that TCP connections were hidden on the live machine so again that's that or TCP viewer or anything else like that those were hidden because NSI proxy so that's the network stack it's in and out control handler was hooked which is the one we saw before is what handles

requests out to the device so running driver IRP and volatility if we focus on NSI proxy I picked a couple ones that aren't hooked so you can see the driver's NS NSI proxy the Handler is NSI proxy but then you have device control so that ioctl Handler is dashed because volatility is like I don't know what this is it doesn't map to a driver if you look at the address range here it's like e388 compared to the legitimate ones are f80 and if you look further in the driver IRP output we have this weird like dump audio codec 0 right in that same range and that doesn't map to a module either which is super

strange and this is an example if you run driver module against the sample with ghost Emperor this dump audio codec0 gets reported right away because it's hidden and it's malicious so again inspecting the IRP handlers especially for things like the file system the network stack this not everyone but a majority of the root kits we looked at did something like this driver IRP found them right away

the next thing is the device trees so Windows has this layered architecture I stole this out of our book so if it looks familiar from art of memory forensics that's where it came from the idea is multiple drivers can register to be involved when operations happen on a device so the network stack the file system and so on so what root kits will do is they will attach as the first or the last depending on what the particular operation is so they have full control so again they want to hide from AV reading from the file system or something Reading from the network stack then they're free to do that this is volatility's device tree plug-in this is

on a clean sample just trying to show you that we have your hard disk volume 3 so your C or D drive whatever it might be you have all these legitimate components attached to it you can see the filter manager attached to NTFS the um the qos subsystem attached to the network stack those are all normal but what you don't expect and I've highlighted two rootkit reports here is on this case we're seeing NSI proxy which is again the network stack weird kernel module called CRT sys that you don't expect to be there you don't expect anything besides legitimate components this matches 100 with the report from this rootkit says the rootkit attaches to NSI proxies device

stack the way that IRP was hooked on a couple slides ago to hide network connections this achieves the exact same thing without having to hook the IRP Handler and I've seen nothing to where Windows is going to try to stop device attaches for critical devices so even if the IRP thing gets blocked off this will still work this is uh back to the dump audio codec root kit we saw before this is from uh kapersky they said the NTFS based driver gets hooked the root kit attaches to its stack and you see that perfectly here so NTFS the filter manager that we saw on the previous slide and then we also have dump audio codec which driver module would have

told us right away was malicious two more things uh there's callbacks so in Windows kernel drivers can register callbacks for a dozen plus system events so if they want to know when processes are created when file systems are registered when the registry is accessed when the system is going to shut down really full control of the system and able to tamper with a wide variety of stuff so if like an AB process is going to start they can kill it if the AV process is going to spawn a thread they can terminate it if they want to inject code into a process before it can even run they can do that and then the registries

very powerful because they can manipulate the entire registry as the system sees it so if you use regedit or like Powershell scripts to try to enumerate things off the machine any type of auto run tools if that kernel driver is there it can hide all of it Windows 10 plus so no version of Windows tries to stop these that seems really difficult I don't know exactly how that would work anyway so we want to be able to detect them this is running the callbacks plug-in Against the Machine infected with a root kit you can see that one of the i o registration ones so when the machine's going to shut down root kits will do a

couple things as the machine's shutting down the most common one is to check their persistence so if they register to service or they have an auto run key in the registry they want to make sure it's still there it's also why you can try to clean machines live and then reboot it and the malware's back because the malware got that last chance to reinstall itself before the machine went away so we're seeing that here this callback address is exactly where the root Kit's active if you're going to try to do some type of static analysis in this case we were able to find the driver but not the module so this is something that driver module would pick

up and then we have a CM register callback which is how you hook the registry and that doesn't map to any known driver so with callbacks you can really just grab unknown across the plugin and if something hits it's going to be a root kit and most of the I think I don't know if I can say every but the majority of the root kits we looked at registered at least one callback now the other thing that's cool and this is the last artifact I'm going to show is this technique called get cell routine hijacking um so since tweeting about this at one point I found out like a kapersky research researcher uh commented on it and said

that they saw root kids doing this like apparently like a decade ago and they never saw it again uh for whatever reason so I'm still gonna call it new because there's the root kits in the last couple years or the first time it was really documented online but it's something to know about anyway so the idea is these callbacks are extremely powerful but if you're in the kernel so like you're an EDR developer you have your driver in memory it's actually really easy to find those and enumerate them the same way the plugin does so at that point the EDR software can say hey this weird driver I don't know has a callback registered it

can try to scrape it out of memory submit it to its you know cloud-based whatever it can run analysis on it so registering a callback is not stealthy by any means so what these root kits that we saw in the last couple years we're doing is what we call get cell routine hijacking and the idea is they can hijack all the operations in the registry without actually registering a callback for it so what we're looking at here is this is a memory sample infected with this technique but we're not seeing it on this slide this is just to illustrate something so it's called Hive list we're enumerating all the registry hives as Windows keeps them in memory obviously

the registry is consulted all the time so Windows doesn't go to disk back and forth multiple times a second for it so it has a cache of all the registry hives and all their stored data in memory and with volatility you can inspect those hives you can expect all the keys in data but the interesting thing is every Hive that's listed here is represented by one of these data structures in memory and even if you're not a programmer just follow along the idea is the data structure is called Hive so there's one hi for each of these lines so you can see like the software Hive system Hive Sam Hive and so on and then

inside of that data structure so as part of each of these things is a get sell routine pointer which is what's called when you try to do something with that registry Hive we try to enumerate a key write a key enumerator value and so on so if you control this call you control the registry and you can hide everything you want just like you can with the Callback so we have a new plugin in volatility called get cell routine it it from a programmatic standpoint walks this list it checks the get sell routine number for every Hive and if the Handler for that points to anywhere but the kernel it reports it so you can see

in this case the system Hive is hooked it's pointing to a module called CRT sys and this module is not hidden this is one of the few root kits that driver module wouldn't see right away but it doesn't matter because it should be in the kernel anyway this is the Handler you can start your reverse engineering so the end result of this is we wanted to make sure volatility and our techniques could find every rootkit technique out there like normal we had to update some plugins we had to write some new plugins we learned a lot along the way and that was the results of it I only have a couple minutes left but before questions you might have noticed

some slides had these numbers in them like 16 17 and so on the last slide which will be online is all of those references so if you want to read about all the root kits and DSE stuff that came out you can email me I can send it to you or the conference will post it online also uh thank you for attending any questions or anything [Applause] language

yeah send me an email because uh so at velocity where I work we actually have a person who spends a significant amount of time making like proof of concept stuff for us to test on also and like modifying them and I'm not going to call me out I probably don't remember I'll stop ahead anyway but some claim support for like unlinking processes and stuff on Windows 10 which like isn't a thing like that'll blue screen so if you shoot me an email um dfir you can send it to my company one I can send you the projects that we have like use as a base to make proof of Concepts that I know work on Windows 10

and if you have even like Visual Studio Community you could get them uh compiled and then you would just have to turn on test signing on your machine and then the driver would load and stuff so thank you no problem any other questions that there's a light so I don't see much yes

most of them I get from fire so some of them are customer samples like that we just changed the addresses and things like that but a lot of them are on virustotal and so um if there are specific ones you're interested in I can double check and probably get you a copy uh you'll want to use osr loader it's normally how we do it it's a software tool where you give it a path to a driver it creates the service loaded and all of that and then you can do it I have one minute left I'll be around a few minutes after anyway say we have a super quick question yes I can't hear them

no I mean because we we have a bunch of VMS that we use from like early Windows 10 and then some that update all the time and we test them out on the same ones the only time it falls apart which is like Windows basically getting lucky is sometimes some of these things operations require like uh non-documented data structures so the rootkit's coded like if I'm running on this version of like subversion release of Windows 10 do this this release and then Windows just gets like like newer than the malware supports so it doesn't work but theoretically if the if that malware was updated with the newer offsets it would work so it's not like a

protection fix it's just the malware needs to get updated so which is why we do the proof of concept stuff to like our own code to test it so foreign

because it's like boring when we're doing trainings or like even internal stuff to always see like see user Andrew whatever so we just spin up like AWS stuff all the time and infected take a memory sample turn the instance down it doesn't it doesn't I mean it's still windows or Linux or whatever it is I've never touched Mac in the cloud so I'll clarify that but I've done everything yeah I've used uh like Windows and Linux I mean like it whatever the cloud provider is isn't like inspecting your VM to that level to stop the maybe if he threw it on like an S3 bucket unencrypted I don't know maybe something would get scanned but like inside the

actual instance no one like no cloud provider changes anything

okay yeah that would be cool let me know I'm gonna be around I have a flight a little later today but I'll be around I'm not like running away right after this so thank you all again [Applause]