Effective DFIR Triage Techniques to Detect Modern Rootkits

threats in Windows Linux and Mac memory tux abstract is going to be the wealth of data available to incident response handlers during breach investigations is often overwhelming both to Junior and senior senior analysts alike depending on the I.T maturity of the victim organization the state can range from days to months of forensic data acquired from hard drives of volatile memory Network sensors AV EDR engine Sims and Beyond effectively efficiently locating signs of malware intrusions and such a large data set large data set requires an analyst to possess techniques that lead to Quick wins and avoid falling down rabbit holes this presentation a walkthrough of effective dfir techniques will be showcased it gets Windows root kits that

have been discovered in the wild through a combination Target file system and memory analysis attendees will see precisely where the most actionable artifacts reside and how to detect such malware in an automated fashion and they will be able to apply these techniques in the field to detect threats throughout environment State protect get it for Andrew y'all thank you yeah so thank you all for coming out to the talk that was rescheduled multiple times uh I live outside New Orleans and tried to fly here yesterday and it took 27 hours to get here between all the cancellations and stuff so that's why that's why I got here a little bit late um but again thank you all for sticking

sticking out and coming to this slot so yeah today I'm going to be walking through a project that myself and one of my co-workers at velixity did recently to find the most effective ways to find root kits in memory samples and data sets that we were looking at we do a lot of incident response and then myself in Austin who who I did the project with or on the research team so we do all the coding and research to make sure that our services team can find data as quick as possible and our motivation for this is if you're in the room then you know root kits are a serious threat but if you don't follow

the space closely it's something that we've noticed over the last two to three years is that there's been a significant rise in the usage of Windows root kits by apt groups so we work on cases that with clients that are targeted by nation states targeted by very motivated actors and for the years before that it was mostly user land stuff so if you look at the stuff we published if you looked at work from other security researchers forensics researchers there was a lot of push towards powershelldetections.net detections and all of that but we in the back of our mind we kept seeing root kits over and over and if you look at reports from other vendors there was these new root

kits as well and for the years before that there wasn't a whole lot of root kids which is what led to the userland malware being pushed out so hard if you haven't heard of driver signing enforcement before you're going to hear it a lot today this was one of the main reasons that rootkits kind of fell off a cliff on Windows but as we'll see the attackers figured out how to get their malware loaded anyway which brought us to where we are now so our goals for the research were to develop effective and scalable triage techniques effective meaning when you use these techniques on a memory sample or some files from disk you don't get a thousand false positives

or out of 10 systems you get six false positives and one true positives that doesn't one true positive that doesn't work when you're trying to really work at scale when investigations involve tens hundreds thousands of machines and then scalable like I mentioned just looking at one memory sample one disk image that's not where we try to focus our effort now because it doesn't work out anyway to start this we needed to do a deep study of rootkits from the last couple years we see them a lot in our own investigations but as you probably know that means you look at them you reverse them and then you forget it 10 minutes later or it's a note somewhere you don't

look at again so we wanted to do a really systematic study of root kits that we've seen we have a lot of internal memory samples and malware samples and then we also have just virus total and Connections in the threat Intel world so that we can get samples that are in other vendors reports so we did a very thorough study over probably 12 20 root kits somewhere in there and we wanted to see how they were loading on systems with driver signing enforcement enabled it's a little bit puzzling once you'll learn about it in a couple slides and then with patch guard which you'll also see a lot today in this talk patchguard stops a lot of the old ways that

rootkits infected systems so we knew we could detect those old ways while at the same time we knew they weren't really being used unless you had like an old old Windows 7 or Windows XP system so we wanted to see which of our techniques where we which malware techniques were we still detecting on Windows 10 and which new techniques were being used and as far as where we looked at for our investigation our sources we the first place is where malware operates which is in memory if you're familiar with volatility that's probably not a big shock that we went there first but that's truly where malware operates and then the second thing we looked at which

is besides memory our favorite forensic Source are the event logs because those can have historical records going back way back in time if you're not familiar with memory forensics just real quick the idea is what I'm going to call basically all modern payloads at this point any payload you're going to see in a real attack in the real world is going to be memory only so it's not going to write anything to disk anything that's on the network is going to be encrypted so if you walk up to that machine and you pull the plug or you say it's like an ec2 instance and you just use the apis to get a disk image out the data that you

actually need is in memory and if you don't look in memory you're not going to find the malware payloads in many cases you'll find absolutely nothing at the bottom of the slide here this was a report actually a really nice report from Microsoft yes is there a question

so so root kits and the stuff I'm talking about today specifically enter kernel mode so a lot of the other things you might be familiar with like Cobalt strike Powershell Empire interpreter like all the and then all the private ones used by direct groups when if you're just talking to a C2 server something like that normally that's just in user land that's just in process memory now you can inject code into a very privileged process like service host lsas whatever but you're still in process memory where once you're in kernel mode it's totally different as we'll see you have full access to the hardware to the other every process on the machine it's a totally different

thing and you have to really change your approach on detection as well and then

yes right and you it can persist on disk as we'll see with like a service but it's the the differentiator between root kits and everything else is that it's in ring zero and that has code there some some summer kits don't persist off of this because especially if you're in a Windows like active directory environment which most organizations are um depending on your tooling there's not a whole it's actually kind of uh it's not a great idea to have persistence on disk on critical servers so instead what you can do is maintain persistent on like a machine in accounting that no one cares about also you have a lot of machines and environments with like no

security software that people just forget about so we'll see persistence on those but then there's no persistence on the critical servers because you have credentials anyway so if the machine reboots you just reinfect it through the same thing you did before there's no reason to leave files on disk there so that's what we see a lot and it's also it's not really the point of this presentation but it's also why when we talk more generally about how to approach large-scale IR it's really important to find to be able to trace through the network all the machines because if you want to actually find the persistent stuff it's going to be on the machine with no security software on it

that's in a closet somewhere that no one knows about so that's what we see a lot but yeah I should probably started to find that before so thank you for the question Rook hits here mean we're in ring zero we have the most privileged access to the system and uh at the bottom of the slide here it was just another example of the power of memory only malware Microsoft basically burned this Australian security company that was selling uh zero days and tool sets and like tool sets to use those zero days and they were targeting journalists and other people so Microsoft basically burned the company to the ground they took all their malware wrote some

awesome technical reports on it the malware was called core lump and you can see what I have highlighted and read here from the report is that all of the payloads that actually matter the key loggers the screenshots Expo trading files those are all memory only so again if you're not looking in memory you're not going to find what you're looking for also I have at the bottom if you haven't seen one of my talks before you'll see slides with numbers and brackets the very last slide is all the URLs so rather than flood the slides with URLs they're all on one slide at the end so that's the memory forensics part the other part is event logs these are an

amazing resource if they are configured correctly and in a lot of the environments that we work they're centralized so if you know the event IDs to look for if those events are being fire or firing on the machines you care about it's as easy as querying them out and now you found all the malware you found every infected machine and event logs and as we'll see event logs and memory forensics play really nicely together because if we have a very solid event ID that tells us that a root Kit's on a machine but what are we going to do after that go take a memory sample and really deep dive that system it also prevents us from having to take memory

samples from thousands of machines in the first place when we can filter down to a much smaller set by using the event logs in a smart way and then the other thing is if you're familiar with old style malware old style tool kits for like Windows XP Server 2003 yes you can wipe the event logs on those it's a pain but starting with Vista and all the way through Windows 11 by default you have something like 40 50 event logs and then you have a couple hundred by the time you have all the other software installed so it's just not feasible at that point to wipe out all the records there's overlapping data there's data

that the attackers don't know about unless they're like forensics experts which most of them aren't so it's very we don't see that very often it's not really an issue anymore even on single machines and then like I said in your corporate world you probably have centralized logs especially from those critical servers so with our two sources let's talk about how root kits actually load and what the type of malware we're talking about is so we need to create a service this is the Microsoft recommended and provided way for loading a kernel driver so remember that driver is going to load into the kernel ring zero access with access to everything so you create a service of the appropriate type this is

going to create some entries within the registry so it'll have the path to the driver the name of it and so on and it will also have when it starts this does create a records in the event logs but I just wanted to point out that I'm not going to be talking about those because they're super noisy there's hundreds of services on a single machine it's even if you have a white list it's very hard to try to narrow that down so we're not going to focus on that from a triage perspective but I'm just pointing it out so no one asked about it later so we have our drivers that we can load through a service before driver signing

enforcement which I'm just going to call DSE from now on because it takes a long time to say before DSE was there in Windows 10 rootkits could just with admin access create a service point the point it out to their rootkit file and now they can load into ring zero whenever they want the other thing to be aware of is you might be saying well at that point we find the rootkit right away that is true but most of the root kits especially the good ones were just loaders so the same way that user land loaders are just small pieces of code that download files over the internet and then execute something the root kits

work the same way they're going to download those kernel drivers over the Internet or they'll be packed and encrypted inside that smaller driver it's not as simple as just throwing something in Ida Pro okay I'm pretty good at talking over things but that would have been tough um so with driver signing enforcement it broke all of those abilities for root kits the first thing that happens is the drivers have to be signed uh before Windows 10 it was not enforced and to get a driver signed for Windows 10 and this is something that we dealt with at flexity and it's it's a pain there's a quite the learning curve to it you have to use this entire software setup from

Microsoft you have to get an EV certificate which is super difficult to get they verify Way Beyond what they used to before and then to get the driver signed you have to actually submit your driver file to Microsoft so as a malware developer you do all your anti-forensics tricks and everything and then you send a copy of the file to Microsoft like come on that's not going to work so this is great from a security perspective except as we'll see in a couple slides malware authors figure out how to get around it in quite a few cases but this is a significant hurdle this was the reason we didn't see great advances in Windows root kits for quite

a few years because the malware authors weren't able to break it and if you're wondering why besides or I guess the main reason why Microsoft was doing this is highlighted at the bottom they were just getting thrashed from stolen signing keys so they would give out signing keys to developers those developers would get hacked now there's legitimate malware if you look on virus total a lot of malware reports there's something signed that a lot of the AVS just skip it or they don't look at it as hard and there's been some pretty devastating attacks with this as far as I know the most devastating one was stuxnet it the that malware was all signed including its rootkit driver from

stolen certificates remember there was no cross signing then so if you had that stolen certificate you could sign the executable and then this is not just something from 10 15 years ago these are two articles with Microsoft still signing rootkits and then very famously a couple months ago six months ago now Nvidia had source code stolen with the certificates yes software manufacturers are now technically kind of your own group kit to make sure you're not stealing your product through your own drivers we do see it we do see it a lot Microsoft still signs those they do show up in memory a lot we end up the first time I kind of know what like semantic and crowdstrike and

all those look like in memory now from looking at it so much but the first time you see like an EDR you're like wow this is malware and then you're like oh no it's just it falls back to some driver like um I think it's crowdstrike makes uh makes files that are named exactly as malware would make them like kernel 32 where the first e is a three and a bunch of craziness and you're like come on man this is like evil this is and then you trace it back and it's just crowdstrike stuff and whatever and there's a bunch of examples of that it's not just them um but yeah it's a real pain when you

have when you have that on a system so but yeah so stolen certificates led to many devastating attacks so Microsoft wanted to stop that that's where the cross signing came from but of course attackers still want to be able to load their root kits on system and get that ring zero access so there was this headline here there's a I guess we call an attack type or class called bring your own vulnerable driver I'm not going to say that over and over again I'm just going to say vulnerable driver from now on the title here is probably a little bit uh overblown but it looks really good on the slide so they're breaking Windows the root kits are loading and

this is recent right this is from this summer and then I think this second one was from October so since I even submitted the call for papers for this conference another apt group was found using these attacks to get drivers loaded and the idea is which we'll look at the details in a couple of slides is by using a vulnerable driver that's signed you can basically piggyback off of it to get into ring zero yourself so you don't have to submit your own driver and all that to Microsoft and this is a pretty prolific way to get into the kernel this is an amazing article the the screenshots here come from an amazing article from rapid7

where it was published in December 2021 so it doesn't have any of the root kits from this year which you just saw there's quite a few of those as well but they profiled all of the main apt real root kits used in real targeted attacks that use vulnerable drivers so I definitely ran recommend reading that if you're new to this vulnerability class the article is really nice and so you can see there's quite a few apt groups quite a few Brew kits that are using these vulnerable drivers to still get access to Kernel mode even though they can't get their own drivers signed now I want to quickly Define vulnerable because it is not just it's a you know

drivers or C C plus plus it's not just buffer overflows integer overflows things like that drivers do have to provide access from processes to be able to talk to the hardware your Nvidia manager where you can set all the settings on your video card and all of that that program that you're clicking in is running as a process and it has to be able to tell the video card hey do these things and set these parameters So that obviously needs to go through the driver to get there same thing with your network card and every other piece of Hardware that you have and then there's a bunch of these just built into Windows as well so with that access if the

driver doesn't lock down which processes can make those calls and it doesn't lock down what regions of memory or which Hardware registers can be written to by those calls then malware can just read and write directly to the kernel so this is what we see all the malware you saw on the last slide all the stuff from this year they package a vulnerable driver with it they know how to exploit that driver so from a a process they can read and write kernel memory and then from there there's two approaches they can take the first one is to directly manipulate kernel code and data but I will say that many of the targets that you would want for this are protected by

patchguard which you'll see all the details of that shortly and this is really hard to do if you've ever written Shell Code or anything like that where you're not using visual studio where you're piecing together assembly code imagine trying to do that for a Chrono rootkit it's completely miserable so there's a couple root kits that do this for very very specific operations like hooking functions but I would say 95 plus percent of the root kits that we looked at from this research use approach two which is they're going to disable the driver signing enforcement to then load a second root kit so once the DSC is disabled it's like it was never there in the first place and then

you can take your unsigned driver and then load it into kernel memory the way this worked initially until somewhat recently is from Windows 8.1 onward there was a global variable in the kernel that said whether DSC was on so you can imagine through a vulnerable driver you can write anywhere in the kernel that you want you just set that value to zero and now windows will happily load your rootkit for you it's like all that work that Microsoft did probably hundreds of thousands of dollars to test it is gone with one integer in memory going to zero so I initially thought this is awesome I can write a very easy volatility plugin detect when the GCI options variable the

one that's getting set to zero when that value is zero it should never be zero in production settings but in reality nothing worked the code the plugin I wrote is very simple all I did was print out the value and literally every memory sample I tested had a non-zero value so then I went back to Ida back to some reading and every piece of malware after it set the value to zero and loaded its vulnerable driver it then went back and set it to the old value so that was a waste of time I mean it was a good thing to learn but the plugin doesn't make any sense because the value is only zero for

you know a couple seconds of the whole time so then digging further because I wanted to see how could we detect this with memory forensics I found these two awesome articles the first ones from Adam Chester who wrote a ton of Powershell and other bypasses in the past the second one is from the threat research team at Fort net which is also very talented and they talked about a few things one is that this technique of writing to zero is now protected by patch guard so you'll blue screen the machine so then they just came up with like 15 other ways to disable DSC anyway through function Hooks and other things that patch card doesn't protect so at

that point I'm like okay this is just whack-a-mole it's not something we really want to bother with so how in a more generic way can we figure out this happened so this is where the event logs become very handy if you're not familiar with the code Integrity operational logs this is an amazing event log resource it will find when say that runtime sees that buffer overflow attacks happen and the stack Canary breaks and things like that but for the purpose of this talk we care about the ones in the early 3000 range so like 3001 3002. on the slide here I have 3004 so in our event log application you're seeing it's coming out of the code Integrity Source the

event log ID is 3004. if you're not familiar with the event logs all these entries are time stamped so you know the exact second this happened and what we're looking at at the bottom which I have highlighted in red the file name buffer is the path to a driver that loaded but that wasn't signed the entire point of this event ID is to say hey this driver loaded on your machine but it's not signed something's wrong with that so if you have centralized event logs in your environment all you have to do is query for this if you see something stand out there's something wrong in this case the root kit is the Moria stream Watchman this was part of

tunnel snake from the Turlock Group which there was a talk about earlier today that I missed this was one of their most potent root kits and yeah all you would have to do is query this out and you would find their very intense root kit very quickly you'd have the path on disk and then you could try to start your analysis get a memory sample and so on the other thing I'll point out which I found very interesting when I was when I was querying all of the memory samples and all the systems that we have access to is not so much for 3004 but for like 3001 and 3002 they will also tell you if dlls in user land so I can

processes load into critical processes like service host and all of that and what was hilarious in our entire data set that we have which is pretty big I didn't find one a sign of one piece of malware and user land loading through that way but what I found was dozens of examples of edrs doing that loading dlls that are unsigned into service host into lsas and all of that and I'm like this is there used to be all this talks to Defcon of like how AV is a threat service and you could use it for privilege escalation I'm like this is awesome all you have to do is like overwrite your edr's unsigned dll it

gets loaded into service host and then you're done so um that was interesting to look at for sure but definitely 3004 if you see a kernel driver there it means that a unsigned driver loaded into your machine and I'm not going to go through every example but all those ones from the rapid seven one that trigger using the vulnerable drivers plus the ones from this year that aren't in the rapid 7 blog post they're going to trigger this event event ID if it's being logged so you definitely want to make sure it's there now the other thing that I mentioned a few times is patchguard if you're not familiar with it the idea is patchguard

wanted to stop wants to stop a lot of the ways that Rook hits tamper with the kernel so tamper with code within the kernel data structures within the kernel kernel and so on and if a violation is found the system crashes and if you're familiar with like incident response if that machine has crash jumps enabled then you get a full memory dump so now the malware is essentially trapped there because it performed an operation that patch card didn't like I have stars at the bottom because yes malware can technically scrub itself from the crash jump it's actually not very popular anymore there was quite a few root kits we found in like the XP days that did

that haven't seen any since I don't know why but it's technically possible but it's not done very much so with patchguard like I said it protects a number of critical sources and the sources that it protects changes all the time so I wanted to get a reasonably up-to-date list on this Microsoft doesn't publish it like on the msdn so I tweeted out how can I get that set and it was awesome uh Alex isq one of the smartest Windows researchers wrote me back with if you're not familiar with windebug probably a cryptic reply but um the analyze command is a wind debug command and then show 109 says to show the abilities of that crash ID so I use

not my fault from CIS internals that will force your machine to crash and write out a crash jump and loaded that into windebug and then this is me running the analyze show 109 and what it's showing here again you kind of have to know like Windows internals to understand what it's telling you but these are at least the resources that Microsoft directly tells you it protects I saw a lot of replies online and blog posts where this list isn't complete Microsoft like hides some stuff but this is actually a pretty good thing of of the ways that we've seen malware change so the ones I have highlighted in red are things that we have volatility

plugins for and detections for to to figure out when those are manipulated in memory but now they basically don't matter anymore because if you do them on a Windows 10 machine you crash the machine so root kits don't Target those anymore so things like the IDT gdt the system call table breaking the process list all of that those are all protected by patchguard so like I said we wanted to study the root kits to figure out what can they do even though patch guard is active so I just wanted to go over two two refresher slides for people who might not have seen volatility in a while when you have a service and you create a

service on the machine like I said you give it the path to your assist file on disk and then what happens when that service starts is that file will be loaded into memory so the operating system is going to load that into kernel memory and the first thing that is created is what's known as a module structure and you can see the output of the modules plug in here from volatility three this is a clean system and I'm showing you this for a few reasons one is it tells us the path on disk to where every module should be assuming it's not malicious it also gives us the Base address in memory of where that module

is so using volatility we can dump out that executable and then throw it into Ida Pro or whatever other tool you want and then the other important thing here which I have at the bottom is I cut out like 250 lines from this slide from the rows here and the reason I've highlighted that is this is not a triage technique right you can't just run module also on a machine and try to see find a root kit because there's gonna be hundreds of them you have no idea which one's legitimate or not but what's important here is we have a lot of metadata here based on where the kernel thinks kernel modules are and this is

where all of the legitimate kernel modules should be so as we'll see shortly we can use this to kind of make a diff and see where malware is hiding the second thing that happens when a service is created is normally that kernel module that kernel driver is going to create a driver object and the purpose of this driver object is for other drivers to be able to communicate with it as well as user land processes so remember like I said with the Nvidia driver you want to be able to use your control panel set the resolution whatever other settings the way that process the way that control panel talks to the driver is it opens a handle to

its file so you can imagine there's like a virtual file that Maps out to the Nvidia driver you open a reference to that and now you can tell it things to do so to get one of those virtual files created you have to have a driver object structure so in volatility we have a plug-in called driver scan it's going to list out all of the drivers that are loaded and we get more useful information we get a second copy of the start address or the Base address of where the driver is we get the size of the driver we also get the service key so that tells us which service in the registry it belongs to we also get some

names and then and this is an example of where there's too much data by default to use it but we can definitely use this metadata to sniff out things that look suspicious and one thing we want to look for is when Rook hits tamper with the metadata that you just saw printed on the last slide EDR engines AV engines and kernel memory can walk these lists themselves generate the same data they can go to those start addresses and then scan the PE files for anything malicious and then now they know there's a rootkit there so malware obviously doesn't want that to happen so there's a couple things that rootkits will try to do to hide from that

analysis the first thing they will do is unlink themselves from the module list that means that they won't show up here because they're unlinked from that list this is supposedly protected by patchguard but I definitely and I verify this a few times before putting in the slide I definitely have samples from Windows 10 systems where modules are broken out of the list like I said patchguard is not a static thing it evolves over time with the releases so it's possible that those samples were just before patchguard was supposed to do that but I do know it's in the list of things it's supposed to protect it just I don't know I have memory samples where that wasn't the case the other

thing that The Rook hits will do is change all the metadata that we just saw if they change the Base address to something crazy or to zero then the AV engine can't scan it if they set the size to zero then the AV is going to try to scan for zero bytes which doesn't make sense and then the driver's data structure also has function pointers that show you or supposed to be able to tell you where a bunch of the different pieces of the code are of the malware so like when the driver starts when it unloads and so on malware will manipulate those because it literally just points you right to where the malware code is so you don't want those

hanging out in memory so but what's nice from a forensics perspective is by changing all this metadata and breaking things it makes a huge disconnect between what the module says should be there and what the driver says should be there and this is what we can key on from a memory forensics perspective and this is one of the most powerful triage techniques we have for this entire talk so this is looking at volatility versus a memory sample infected with the rootkit known as Dirty Mo this is also another awesome report to read you can see it says 38 minutes it's a very detailed like really nice rootkit report so to start I'm running the driver scan

plugin and I filtered it just to the rookit driver just so you can see some of the metadata obviously this would be like hundreds of lines of output by default but we want that metadata because when we run the driver module plugin which is the second one here this one down here the only output that that plug-in provides on this memory sample are these two lines it's not filtered in any way and the first one we see it's saying that this file system raw was pointed out and then the second one was this dump EDC B5 blah blah it's just randomly generated anyway and then if you look in the known column it says that the raw driver is true so we know

that that's going to usually be here but then the dump one is false and what the driver module plugin does is it takes the start address of the driver which you can see is set to Zero by the rootkit and then the size is zero and then we try to map it back to one of the kernel modules to see if that driver is associated with the module so the fact that the start address is here on the size is zero means we're going to look for a module that's like zero bytes in memory it doesn't make any sense so we're going to immediately notice this disruption of the metadata and we're going to be able to say that hey this

driver is out in memory it's not associated with the module besides the few that are in that known list from the OS itself that does doesn't make any sense and this is another example of I only show it for this plugin because it's basically the same or only showed for this rootkit because it's basically the same output over and over again but out of that list from rapid7 and the ones we looked at since then the ones from 2022 like 99 of them fall to this driver module plug-in because they're going to tamper with that metadata so we can find the drivers this way it's too much to get into in this slide it's like 30 pages in The Art of memory

forensics but you can find the code for the drivers even if the metadata is tampered with you can dump it out of memory and then you can do what you want to do your static analysis so we can find the drivers this way finding the driver is not enough though we want memory for is not just enough though we want memory forensics to tell us as much as possible about what happened on the machine so the next place we're going to look and that's not protected by a patch guard is the IRP handlers these are where if a process wants to request something or to tell a driver or something it sends it in IRP

so it's like a known you can think of it as like an API to tell a driver to do something so for example if you have notepad open and you want to write out to a file on disk you hit save in notepad and many operations later there's an IRP that fires for the NTFS driver that actually gets that file written same thing if you want to send something on the network rootkits also abuse this to send the rootkit command so if you have a rootkit where you can say hide the process with a certain PID or a certain name or hide network connections out to a certain IP address that's almost certainly going through an

IRP Handler out to that rootkit this is all of the IRP entries that Windows provides the two on the left that I have highlighted the device control and internal device control these are for these are the ones that get abused by rootkits for userland to talk to them these Implement ioctls if you're familiar with those so the whole point of an ioctl is to use basically like a hard-coded number and say hey command 4 equals whatever send a packet and then you implement or you send the request with command 4 with the data the way the driver wants it so by drivers implementing these they can have those custom protocols that you see with userland and usually when you read a

rootkit report it's like if you send you know four you get this five you get this and so on that's all going through this IRP Handler and the ones that have in green are these are normally targeted on legitimate drivers so if you have like I said your NTFS driver or your file your hard drive driver if you hook these then you're hooking all of that access at a very low level unfortunately or I guess it doesn't matter because we're going to triage it anyway but if you run driver IRP by default you get a crazy amount of output so remember driver scan itself produces like 200 lines of output normally uh driver IRP is going to produce 28

entries for every driver because it's going to take all the IRP handlers which you can see in the second column here it's going to list out the address of where it is and then it's going to tell you the module or the driver that's implementing that Handler so you can see here I filtered it to just the NTFS driver and all the handlers are either in the NTFS driver which you would expect or they're within the kernel and drivers don't have to implement all of these and there's a place within ntos kernel where you can just point your IRP Handler Handler to say I don't care about that request just ignore it when it comes in so that's normally what you

see in most situations when you look at an IRP table is they either point to the kernel or to the driver that you're looking at but as I mentioned Rook hits want to Target these because for a few reasons they can control at a very low level all the operations on the machine and also patch guard supposedly protects these but I've never seen it I have a ton of memory samples with malware that's infected also all the screenshots from today are from Windows 10 samples patchgard didn't do anything to stop those and so uh I don't know it's listed that patch card does something about these but I've never seen it it supposedly protects really critical ones

like NTFS like I said I've seen where that's hooked so I don't know about that so this is an example of running driver IRP to find the ghost Emperor rootkit which was another very powerful root kit in the report it says that to hide TCP Connections in user land the ghost Emperor root kit would hook the ioctl Handler for NSI proxy when we run driver IRP against the memory sample infected with it you can see that I've kind of cut out four of the handlers for NSI proxy the first two point to NSI proxy the last one points to NSI proxy here at the end so it's handling its own irps but then this one points to dash which

is volatility's way of saying hey I don't know what module this belongs to this is the device control one which is the ioctl Handler and this is tells us exactly where the malware is in memory the other interesting thing is Ghost Emperor will make this dump audio codec driver this will definitely show up in the driver module plugin output and what's interesting is when you have a hidden module and the driver is disassociated from it then volatility can't map back any of the handlers so in the full output here you would see where all 28 handlers are just dashed because none of them point to a module and that's almost a dead giveaway that you're dealing with the rootkit because

their IRP handlers point to a hidden place in memory so not only can we detect that the legitimate NSI proxy has been tampered with it tells us even more information about where the rootkit is in memory because we look at the IRP handlers and then the last thing that we looked at were device trees this picture is stolen from art of memory forensics but the idea is Windows uses a layered architectures for device access and this slide shows you the perfect reason why because you can imagine when you have an application writing out to a file on disk there are a lot of drivers that care about that you can have your AV drivers that want to look at the

contents to scan it if you have BitLocker on then BitLocker needs to encrypt that data on the way out and decrypt it on the way in you have whatever driver actually talks to your specific hard drive that you have in the machine and then all of those just get put in a stack and windows does that dynamically so as convenient as that is for legitimate developers it's also really nice from a rootkit perspective because if they can insert their own driver anywhere in that stack then they get to tamper with the operations as well so this is looking at a couple of device trees of legitimate drivers additional malware showing up here just to kind of

show you the idea so you have hard disk volume three so this would be your C drive C drive something like that and these are all the drivers that care about when you write tier C drive so this is BitLocker this is stuff to make the rest of the system work under NTFS you have your filter manager which controls all access to the file system under the network stack you have your quality of service driver so you kind of get the idea when processes talk to these drivers the other drivers that care have a very organized and ordered way to deal with those requests and see those requests so of course fruit kits want to abuse

this because they're root kits so they're going to attach to devices of interest in order to intercept those operations again they have very low level powerful control over the system when they do this and I don't know I've never seen anything say patch guard tries to stop this I don't know of any other built-in mechanisms to stop this so it's still a very viable attack method for root kits and what we're looking at here is the vice tree that same plugin we saw before against two root kits the first one was a rootkit published with the proxy logon attacks so it's called something like the fire chili root kit or something weird but they it's a really powerful

root kit so looking at the report it says the rootkit attaches to NSI proxies device stack and then it says it uses that to filter out the connections and if we look in the device tree output we see NSI proxy and then attached to it which makes no sense there shouldn't be anything attached to NSI proxy there's this file system CRT sys which is exactly the rootkit driver so it's a dead giveaway that something's hooking the network stack and then if what we also have from this one is Ghost Emperor again ghost Emperor implemented like 15 different rootkit techniques this HEX number here is the ioctl value for the specific one like I was talking about so

if you wanted to be able to hide files you send this ioctl and then for every NTFS based file system the report here says the rootkit creates a device object like we saw before and attaches it to the file systems device stack so if you remember on the previous slide two slides ago where we had NTFS the only thing that really should be attached is the filter manager but on this machine that's infected we see that under the filter manager is that dump audio codec0 which we know from before is Ghost Driver ghost Emperor's malicious driver so again a dead giveaway that there's malware on this machine and we've called it ghost Emperor and all the other ones

like five times over from our plugins so I have about five minutes left I can take questions also I think the slides go up online um so this is the references if you want to just shoot me an email I didn't realize they would like crunched down so much when I was making them uh but shoot me an email or the slides will be online as well and then you can get all the references from before so that's all my slides any questions while we have time

um so we have an internal one we built but there's also one I won't I don't remember the name but I know it's like it's on GitHub and it's called like uh I believe useful is the word it's like useful event ids.md or something like that um if you send me an email I can send you that link because we have an internal one but we've crossed referenced it with a bunch of a bunch of other ones there's also one uh it's in one of the references called malware archeology and what that does is um the the PDFs are a couple years old now but they're still like 90 of what you need and it shows you how to make all the

settings for group policy to get the different events enabled and then it talks about like why they're important and so between those and that whatever that other one's called useful events or something like that um you have most of what you need like that one that useful one definitely has all the code Integrity ones plus not just the rootkit ones but also like I said if um if the runtime catches like a buffer overflow trying to be exploited or something like that it'll get those IDs too so okay uh we actually haven't seen too much with that so we did res we did research on that a couple years ago and sent it to dfrws

um that was V1 which was very much like Microsoft hacked in Linux to the kernel now it's literally just um what well it's what's the oh hyper-v I was thinking of virtualbox you're literally just running hyper-v VMS in the background when you're running WSL so it's not so to do to do memory forensics you want to go in the guess like we have done that before so I have like City we have like an acquisition tool and we've tested it where you can get memory samples like out of the WSL VMS and then do full Linux memory forensics on them but we've never seen any like real world attack take advantage of it yeah I mean from if you have a a memory

sample of the host then it's like a hyper-view process you probably don't want to dump it out of memory or anything like that it's also a little bit weird because you'll have fragments of it and what you would see in a regular memory dump but then Microsoft now also does um what you see as your main desktop is actually a VM of like a really thin hypervisor so that's how you get like lsas isolation and all of that so so as as far as I'm aware if you have the correct Hardware which most uh like Enterprise level newish laptops would those VMS are actually running in a separate space as like an actual separate guest so it kind of depends on

the settings I haven't looked at that in a while but I do know in some memory samples we looked at we didn't have like everything we expected in the memory dumps of the host without guests running so I'm pretty sure it's running in those like kind of hidden VMS that Microsoft makes um but yeah you would want to do like regular Linux just treat them as like Linux boxes and that's how we would do it but we've never we've never seen them running on machines that were part of our investigations we've never seen or read about like malware loading them or anything like that which is usually like we're really busy so we can only focus

on like what's in the wild no I mean it's it's a threat it is a major threat from the sense like people um would load like VMware on their corporate machine and now you can do whatever you want outside of like app control and all of that so it does give that same capability um we just haven't seen a whole lot with it so

no I think it'd be loud I mean a lot of places we work in have edrs installed which it's always it's always funny that we get like infected memory samples with the EDR in there but I would hopefully if like a huge VM was downloaded and US was running I would hope they would notice that at least so so yeah any other questions all right thank you for coming out I'll be around later too if you have questions [Applause]

[Music]

thank you before I forget to get that no problem it was

um

do you have an impression for you okay Victoria is like the content covered in the art of memory forensics how much reading would you say is needed now with the introduction of Windows um um there's so I did a talk at a couple conferences like right before like end of 2019 on on basically that for Windows 10 stuff at the time like a new there's there was a bunch of new like file system artifacts that were really helpful and then some of the ways that memory forensics changed besides that there's some there's some ways they would be kind of hidden from like a volatility user but there was some plugins who basically had to completely

rewrite because of how Windows 10 did it but if you just run the plugin like you don't notice the difference uh from that perspective because it just works the same so I don't know I would say that talk I gave and then I don't know you could just use like an up-to-date version of the tools most of them kind of hide all the difficult stuff in the back for you yeah because because we have a we have a set template for when we collect all systems that defines like we're going to get memory and then which files we want off the machine and so we had to update that for Windows 10 but the talk I gave

was like based on the research we did to update that template so it's all the extra sources that we take in from those systems the memory structures themselves no I mean there was no they were significantly changed I was just saying like it's in volatility so if you're using the tool you don't like if you run the PS list plug-in you're going to get the processes anyway no matter no matter what the changes were so yeah so there's a lot of work on our effort but from like a user perspective it's not much different yeah so just the the main thing was like kind of like today like running like inspecting the system called table and say a Windows 10 sample

you can do it but it's probably a waste of time because patch guard would blow up the machine if you know if it got hooked and things like that so so yeah so we keep those implemented because they're still like Windows XP Windows 7 out there in the wild and all of that but it's not like uh it's not the first place I would look for a root kit if I was looking for one so yeah is that what you're asking oh how much is the disease the information kind of stood the test of time versus how much this we can do is Windows been changed yeah like the information is good like I said because

um Windows change a lot but you won't notice anyway yeah thank you yeah