← All talks

BSidesCharm 2024 - The Fellowship of the Ring0

BSides Charm42:16149 viewsPublished 2024-06Watch on YouTube ↗
About this talk
Unveiling the Driver Risk Scores (DRS) threat detection system. Using research from loldrivers.io we know which drivers are vulnerable, and we know not all vulnerabilities are created equal. How can you quickly and accurately determine the risk that a device driver creates by either having built-in vulnerabilities or malicious behavior? The Driver Risk Score harnesses seven vital traits that include both security features and real-world insights to calculate a single, easy to understand ranking, similar to a CVE score, which allows system administrators and security operation teams to make educated decisions about the drivers allowed in their environments. Presenter: Dana Behling Dana Behling is a cyber security researcher at Carbon Black by day, and a science fiction and fantasy enthusiast by night. With a keen eye for digital threats and a passion for exploring otherworldly realms through literature, Dana thrives on the cutting edge of technology while escaping into imaginative worlds beyond. Whether decoding complex cyber puzzles or unraveling the mysteries of distant galaxies, Dana brings a unique blend of analytical prowess and creative insight to every endeavor. Join Dana on a journey through the digital frontier and beyond.
Show transcript [en]

[Music] you guys have all seen Lord of the Rings right we're all a bunch of nerds so yeah and I'm I'm talking about myself here right I love fantasy so if you haven't you've been living under a rock you've never seen uh the Lord of the Rings or The Hobbit or read the books or whatever uh the gist is is that um the four races of this place called Middle Earth are given these rings but this really bad guy decides to make one ring to rule all the other rings and control them and then basically like every evil guy in the movies take over the world right so you're probably wondering what does that have to do with Windows drivers

right well what yeah they're evil but uh so what if Sauron who is the what's the name of the really bad guy right what if he instead of being the evil guy who wanted to take over the entire world what if he was just an agent of chaos instead of making one ring to rule all the Rings he decided to make a million rings to rule all rings and just spread them out throughout the world that movie would have been way different right so drivers are kind of like these rings to rule all other rings but instead of having just one there's like thousands and thousands of them all over the place and more are probably being created

today so this is a little about me I my name is Dana bealing I've been in the industry for a really long long time I uh grew up as a programmer like literally grew up as a programmer um I entered the cyber security industry around 2007 and have been loving life ever since I feel very fortunate to be professionally uh employed as a cyber security researcher um I graduated from University of Hawaii I have spent my time at NSA and I was a government contractor for a long time uh the last couple years I've been working for carbon black the EDR vendor and as of Wednesday I'm now uh working for semantic and all of those uh words on

the ti on the slide are different titles I've held over the years so whatever I say you can trust me today okay so what we're going to talk about today we're going to talk about um bring your own vulnerable drivers so this is a uh it's a technique that's being used in malware leveraged more and more um there's lots of Ransom group groups using it these days um we're going to talk about driver Basics just so that way you can understand the stuff towards the end of the presentation or towards the middle of the presentation we're going to talk about the problems with drivers and we're going to talk about the real subject of this talk which is

driver risk scoring um and will'll lead up to why that is necessary we're going to talk about the site lol drivers. which is available now and you can go to and we're going to talk about about the Practical applications of the driver risk scoring in general so it's going to be a great time everybody so we've all seen the headlines uh Casa ransomware deploys bovd attacks and it's abusing um PS exec and exploits the martini driver they call it the martini driver but that's just what the bad guys named it like they renamed the file it's actually like a driver from an antivirus company so just to muddy the waters a little you know um Terminator EDR killer like this

was one where a um darknet Persona basically like released a video to show where he could run a tool and kill a couple of different edrs just by leveraging a driver there's another headline bring your own vulnerable driver attack is becoming popular amongst threat actors no kidding and then um most recently like last month Lazareth and the fud module rootkit which is U leverages drivers as well so there's like all of these groups and they're all using different drivers some of the drivers have cves some of them don't some of them have been patched some of them will never be patched so it's used in ransomware it's also used in crypto mining a lot um this

one driver XM rig I'm sure if anybody's a malware reverser they've seen that driver it is used if you do like a search in virus total and then try to correlate the number of driver the number of drivers that are used in malware so it's the the containing executable that contains the driver or leverages the driver has multiple AV hits the majority that you will get is all this wind rings z. Cy driver 79% a shocking amount and that's because it's used for crypto mining uh that driver what it allows you to do is partition like specific um cores of a CPU so you can just tell it um I only want to use one core of an8 core CPU for crypto

mining so that way you can run your Miner forever and no one will probably notice but 79% also info Stealers Bud modules and info stealer Enigma stealer all using vulnerable drivers oh and also if you're you don't want to write your own vulnerable driver uh tools you could just go to GitHub that's where you can get everything these days right it's like the One-Stop shop so these are some of the projects and some of the drivers that they leverage one of my favorites is this one EDR sand blast it um uses three specific drivers and basically what it does is it manipulates the uh Windows uh objects to basically prevent the edrs from calling back to themselves to alert on things so

you can run EDR sand blast do whatever you want and then uh run your do do whatever nefariousness you want and then turn it off so essentially you've created like a little blind spot for the EDR just for a very specific short period of time where you're doing your nefarious and so it's um particularly destructive here's another one Ghost Driver this one's written in Rust um the driver is actually embedded in the project and loads directly into memory it never touches dis and here's another one blackout which uses the uh it's like a popular gme driver so there's I I hope that I've uh demonstrated that this is a problem right there's all of these uh projects

out there all of these bad guys leveraging these drivers so why are they doing it and why is it a problem now we're going to talk about how drivers work and why they're doing it and why it's a problem so just so that way we're all on the same page here's some Basics about drivers I'm sure you've all know about user mode and kernel mode right user mode is the place where most users interact with the operating system I think of it as a punk rock concert like there are some rules but a lot less than the um kernel mode konel Mode's like a like a symphony so there's a lot more rules when you're attending a symphony

than attending a punk rock concert so the way that drivers work is there's basically four types of drivers there's user mode drivers kernel mode drivers there's drivers that um specifically support the kernel and then there's file system drivers and there's filter drivers there's there's like a whole bunch of other types of drivers too but for the for what we're talking about today the main thing we need to know is that there's user mode drivers that happen in the chaotic space of the user mode punk rock concert and there's kernel mode drivers that happen in the uh concert space of of the like a symphony and they communicate with each other they allowed to communicate with

each other that's the way Windows designed it and there there's two methods where they can interact or two spots where they can interact we're going to talk mostly about the one on the far right side where the user mode drivers talking to the kernel mode drivers so whenever you want to communicate with a device let's say you have a really cool um PC case that has LED lights on it and you want to change the lights from Rainbow to Blue so what happens is that you open the user mode application and that user mode application you click a button you say I want the lights blue you click the blue button and so an IO control which is a

special code that the uh driver the kernel mode driver can receive from the user mode side um knows that you you send that IO control code it's usually like a 8 byte value 8 00123 or something and it and along with like a color code and it will change the LED value the LED color on your PC case so user mode sends the io control code to the kernel the kernel uh driver sends a message to the operating system which in turn sends a message to the actual Hardware which then your lights will change colors so so everything is dependent upon these IO control codes that are hardcoded into the kernel driver and the and any user

mode application with access to the kernel driver can send these IO control codes to it in most drivers so now that we kind of have a understanding of how the uh kernel mode drivers work let's talk about why they're being used more okay so back in the day um there were we we we talked a lot about rootkits right and then mic Microsoft implemented something called patch guard patch guard got replaced by um these other things um the latest one is the hypervisor protected code integrity and what that has done is make it really hard for uh actors to manipulate memory addresses and different register values in the kernel itself and I'm going to explain to you

how that works basically the way that old rootkits used to work is that you would write a user mode application you would try to get an address into this thing called an MSR it's like a special purpose register that's only available to the kernel and whatever address you put in that MSR the uh operating system would just automat automatically jump to that address and start executing from there great feature right so that's the way a lot of them worked so Microsoft when they first implemented patch guard the first thing they said was no you can't do that anymore so actors what they did was they said okay since we can't do it from user mode anymore we're

just going to do it from unallocated space and Microsoft caught on Fast and said no you're not allowed to write to those registers anymore from an allocated space and then the best part or the the most recent is the um HCI in which basically they said yep we're still not going to let you write from user mode into kernel directly we're not going to let you run write from unallocated space into the kernel directly either and we're also going to um Implement process isolation between kernel processes um which wasn't there before shockingly so now you cannot write from one kernel process into another kernel process because they're all isolated so all making the jobs of the

hackers a lot more difficult right and just as a reminder this has existed in user space for a long time right you can have multiple programs open at any time and they're not going to interact with each other you can have their browser open slack open and calculator and you have a reasonable expectation unless maybe someone in this room is on your computer that they won't interact with each other so b y oov d so that's the way that we used to do it now we can still do some of that right because drivers are just software software has vulnerabilities so you can write an exploit for a driver right sure you can also still write to the MSR but it's

just a lot harder than it used to be so but almost all I would say a good 90% And I haven't like done any math or actual studies to back this up all most of the vulnerabilities and drivers that we see nowadays are all because of that IO control abuse so that is the special codes that are baked into the kernel mode drivers that the user mode driver can send to the kernel mode driver to have some kind of effect on the actual Hardware or some something in the kernel right um just like changing the LED lights on your um PC case from that example that I showed earlier just want to make sure I don't

run out of time so for the visual people out there this is how it would work for the the user mode driver would send an IO control request to the kernel mode driver right so that's the special code that special code could uh is linked with a specific activity or function within the driver so it could be like um terminate process that's a very popular one so uh the user mode driver sends the the command to the kernel mode it sends the kernel mode driver then by necessity because it's part of the operating system has to call operating system code and so it can it can kill or terminate a process in the kernel itself because the because

the user mode driver has passed off to the kernel mode and the kernel mode by necessity has to call uh operating system functions they can also kill user processes of course but yeah so basically it's taking advantage of these baked in IO control codes that are meant they're meant to by the original author to terminate processes but it's basically just the bad guys leveraging these IO control codes by by basically looking through all the drivers that you can find in order to find the the functions that you need to fulfill whatever uh outcome you want and then just use that the drivers by the way so you only need to be admin to install a

driver right so that's where the bring and the bovd comes in so as long as you have ad admin you essentially have system so long as the driver that you're using has an IO control code that can call into like kernel level functions so it doesn't matter like if the driver is already installed on the system is or not if it is already installed in the system that's particularly egregious right because then you don't even need to be admin you can just be whatever you're logged in at the time user to fulfill the action but even if you don't have uh user you as long as you have admin you have everything so let's look at some driver

patches so this is the driver for the MSI After Burner it's a video card driver basically What it lets you do is like overclock your video card it's called RT core 64. CIS it's um abused in so many different MERS it's one of the ones that's leveraged by the EDR sand blast technique that I mentioned earlier it does have a cve assigned to it which is great A lot of the drivers I look at don't even have cve assigned to them but let's look at the patch so if we look at it the kernel mode driver has is initiated with this IO create device which is uh deprecated by Microsoft because basically it allows anybody with

uh user access to to be able to uh connect to the kernel system driver just by making a call to create file literally it's that easy create file and then you provide the the device name which is listed right there as you can see so the cve basically said yeah we don't like it because anyone can create a handle to this driver and then get access to all the kernel resources that this driver exposes so let's see how they patched it okay so the bottom shows the patched version where they're calling the correct fun function wdm lib IO create device uh secure which is the correct way to do it according to Microsoft standards now and if you look at the at

the underlining portion there it looks like a bunch of semicolons and letters um we don't have to understand what it is exactly there but what it is is a sddl it's the security descriptor definition language and that allows you to Define who is allowed to connect to your driver right so this is the patched version who did they allow to connect to their driver oh anyone with a minimum of admin so if you installed it basically uh you still have access to all of the underlying functions within this driver so if it was if you're a person with this video card I I guess you're protected but if you're targeted by it um it really offers no protection this

patch at all here's another one Rogue killer anti-malware driver this one they actually did use the right function called wdm lib iio create device secure but the sddl description they used is VX and when I started looking at it I was like what is VX I I expected more semicolons so I was like oh okay let me look into how to define these and it says oh okay well if you're going to Define it like in the command line it needs to be defined it needs to be one of the ones that we have listed in the documentation so I went to look for it oh no there's there's no that VX doesn't exist anywhere so I don't know what that is

that basically just means that since it doesn't exist it's going to be open to everybody okay another true site. uh s true site driver basically it allows you to open a process and then terminate it so very useful for people doing malware because they want to kill all the security processes right so how did they um how did they check it they said oh let's check the process information so basically they're checking to make sure that the process they're going to kill they have permission to kill but since they're kernel they should have permission to kill it so kind of beside the point yeah um the zamana anti- logger so this is one of the most abused is this is the

one that the Spy boy was using in The Terminator tool if you're familiar with that um basically it's a um malware system that hasn't been updated since 2019 um there is a cve for it now but I uh highly doubt that it's it's ever going to get patched um the driver is also in like a whole bunch of the different products that that company owns not just the antimalware product and so basically it's using the wrong function to uh initiate the driver which basically means anyone connect can connect to it and um exercise any of the underlying code on the Kernel side right so what's available well you can terminate processes which is expected right

because it was used in that uh Terminator tool but these are the other things that you could do if you wanted to any of those things are available to you you just got to know the the right code to call pretty bad so at my company we were like well should we block this zamana antimalware driver like what if somebody's depending on it for their anti uh malware solution I don't you know I don't know it's it's still supported it's on their website they haven't updated it in a while and we were like in a conundrum right like if we block it we could really like make some people angry if we're blocking their their malware solution and it's

not just this one driver it's like all the drivers right um in many cases they have legitimate use cases they have been patched and so do you block it or do you not block it so I came up with this system it's the driver risk scoring system and basically what it is is a method of assigning a number value kind of like a cve score to drivers so that way if you're a system administrator you could just look up the score and decide well is it worth it or not for me to block it keep this software product in my environment or get rid of it and it looks at um seven different categories um so seven different

characteristics I guess the first one is we categorize it we look at the frequency of use we look at the signing status of the driver we look at the cve status malware family if it's on already on the driver block list that malware update or that Microsoft updates every um Tuesday I guess and then the severity of uh what the driver can actually do if it's actually being leveraged by a malware group so the C categor categorization is the first attribute we look at we try to determine if the driver is a known good unknown intentionally vulnerable classically vulnerable or intentionally malicious and that's another thing there are plenty of folks out there that just

write intentionally malicious drivers uh the majority of them are not signed so that's good right because at least if you're only allowing signed drivers um the other thing is that the Microsoft has a program where you could be like a trusted Hardware uh partner and you can just sign whatever you want and that's been problematic as of recent um but yeah so basically if it's a known good we give it a one unknown two three four just like the like the doctor's office smiley face scale right the second characteristic is um looking at how often the the driver is associated with known malware so if even if it is vulnerable if we don't know of

any cases of it ever being used with malware ever before we would still give it a one um if it's known to be associated with at least one malware sample and that's not one malware family it's like one hash for a malware so if uh the same malware uses it but the the malware has three different hashes we would count that as three and then of course the more malare that uses it the higher the ranking would be five being the highest so I think this one here is the win ring 06 I just thought it was great because look at the uh number of files that are associated with malware 262,000 yes artificially

um it it could um the highest number is five so even if it's used by 262,000 it's still only going to get a five yeah and then we look at the signature status um basically if it's a verified good signature we give it a one and anything else gets a five um I toyed with trying to do something with drivers that are signed by the um trusted partner program from Microsoft but it seemed like very a large majority of them were and it it really didn't add anything to the final sign the final score so I took that out so one for a good signature five for everything else oh yeah this is just some fun stuff

from my my own data so just looking at um drivers that are signed in virus total that have a antivirus hit of five or more I was able to find like 12,000 um signed drivers that have this is ones that have uh virus hits of like antivirus companies have have marked them as malware at least five different companies have marked them as

malware um no I haven't looked at it that detailed I just kind of this was just for fun to see how many I could see yeah but yeah it does include expired signatures for some reason V virus total um doesn't delineate expired from from real so I don't know why that is um so I looked at it in my own collection so uh I have in my own collection of drivers I have like a little more than 10,000 drivers um a little more than 8,000 have valid signatures on them but then I um looked at how many have a uh driver risk score which goes from one to five five being the worst one being um the not worst I

guess um and there were 126 signed verified signed drivers um that had a driver risk score that was above the median and then we look at if the driver has a active cve for it right so basically this is easy no cve we rank it a one um yes cve we rank it a five um and then um because I had the cve database downloaded you could just get it from GitHub I looked to see how many cve how many of the cve records listed the word driver and it was like a little bit like close to 2% and then the one and there was like 05% about that mentioned the word IO control specifically and considering um

cve uh are for all software from like a long time that's like a pretty large amount considering we're just talking about specific techniques here another thing is when you're trying to figure out if there is a cve for a driver it's like so aggravatingly difficult right because the cves are like written by the people that I submit them I guess and so there's a very big D diverse set of information that you get in the actual cve write up itself like sometimes it'll actually give you the name of the driver that's the ones I like that's that makes it real easy for me and then other ones they just tell you the name of the

product sometimes and you're like oh and then you have to like try to figure out like okay what's the name of the driver in that product the next category we look at is um maare families and AP associations and basically what this is is just if any anybody's released an open- Source report about it or any other kind of um cyber threat intelligence report in which it was listed in there so if it's listed it gets a um two if it's listed one time and it gets a five if it was listed greater than one next thing is it on the Microsoft driver block list or not one if it's blocked it's considered a lower risk

right because it's already blocked by Microsoft five not blocked yeah and oh I have to uh shout out to trail of bits they made a pow shell script so whenever Microsoft um releases its patches you can just run their Powershell script which is available on GitHub and it'll give you all of the new drivers that are on the block list you can also download it from their website the Microsoft has them listed there but it sort of lags behind and this is my very very favorite characteristic of the driver risk scoring which is ranking the severity and this is not that the driver is definitely um bad it's the potential to be leveraged for bad right so we're

looking for um specific function calls or combination of function calls that could um lead to the operating system being compromised and all of the HCI and patch guard and all that being subverted by the driver itself so the way that this works is is that I have thousands literally thousands of Y rules and each y rule is listed in a config file and that config file basically um ranks how bad I think that technique is so if you see on the slide here it says terminate process a so that it directly maps to a Yara rule where if you see these three functions calls in a driver um we will give it a severity score of five because

um there's a good probability that the driver could be leveraged to terminate a

process so there it is there severity and then also we do specific drivers like we looked at the RT core 64 driver before um that was the one where the MSI After Burner video card driver um so there's two yard for that in there um one for the patched version and one for the not patched version and then uh going back to throwing off the the different um values based on the categories um this tool Bas I wrote it in such a way that I didn't know what was important to the system administrators right what categories did they care about so basically you can go into the configuration file and decide what's important to you like if you

don't care about the frequency for example you could just Mark that frequency uh weight as zero and it would just not even be used at all yeah or you could or you could you know you can make all of them zero and then just make one and it would only give you the score for that one characteristic whatever is works for your environment so this is the driver risk for score for the zamana that's the uh antimalware tool that hasn't been updated from 2019 that was used in the Terminator spy boy tool so um this is all the different versions of that driver that I could find and then I ran it through the driver risk score uh tool

and then I got their score so that's really ugly to look at because it's a spreadsheet but this is it in graph form so you can see that the driver RIS scores um go from like very very close to five all the way to to below two and to contrast that these are um all of the drivers available on a default Windows 11 install I just downloaded them all and then run them through the driver risk score tool and so you can see that the majority of them uh rank at two or lower so um a lot of Windows drivers aren't signed it's weird so drivers right drivers um have you guys heard of the

site lol drivers. yeah yay so basically what it is it's a site uh created by Mike hog ha a a g I think the hog you can find him on or heg maybe I'm not sure how to pronounce it but you can find him on uh Twitter he created this site along with some of his friends and basically all it does is like lists all of the known uh living offthe land drivers or bovd drivers that people are leveraging at any time all of the information from the website is available on their GitHub and you can go through and look up any driver you want like um we talked about the RT core uh 64. Cy driver

that's the one that allows you to manipulate the internal uh objects inside of Windows and create like a black hole so that way you can perform the various actions without being without alerting an EDR and so if you were to like click on that one um you can see uh very easily on the site all of the different um things that you can learn about the driver like for example if you clicked on the Yara you could go to Yar rules that spe are specifically applicable for that driver um it's not integrated into LOL drivers yet but um in the in the near term um the driver risk scoring is going to be integrated into the LOL driver

site so if you wanted to um just go and do a quick check of the driver itself you could just go there and look and you wouldn't have to run the tool yourself so practical application you see this driver in your environment DB util drive to.is you plug in the hash into virus total and you see Zero hits looks pretty benign so it gets a category of one then we look the driver risk score tool goes and sees how many times it's associated with malware eight associations so that earned at a score of four signature verified cve oh there is a cve for it so got a score of five on that family it has been listed in one

um uh cyber intelligence report and it um is not on the Microsoft driver block list and then if we looked at the severity we can see that there are two very problematic function calls inside the driver that allows you to map virtual to real addresses which unless you're an exploit writer you don't understand but it's really bad and so it has a score of 3.5 so if you look at the virus total lookup again which looks all nice and green with a big zero that no antivirus companies have marked it um it gives you a completely different perspective from the system administrator point of view on if you want to block this driver or Not

Right But there is a problem right because um there are many different versions of drivers so if you're have ever had any exposure to software development before especially now in an agile Workforce where we do nightly builds you could potentially have like hundreds and hundreds of hashes for the very very similar drivers right and so these two hashes are for the same zamana um Terminator driver but you can see one has a score of 4.76 and another has a score of 1.74 but they have the same vulnerability and can be leveraged exactly the same so what I've done is created something called a click so that basically allows me to bend all those drivers together so that way if you see

the one driver with the high with a high score it will alert you that even though the driver may have a low score there are other drivers that have a high score that have the same vulnerability and can be leveraged the same as it so kind of like uh Clicks in high school remember they look they all look the same so future work there is still like a ton to do um we got to integrated into LOL drivers.com my plan was to open source the project today but but um my company got bought by broadcom and I just got took on a new role so I got to like go through legal now and start the

whole process over of open sourcing it um but yeah So eventually it will be open- sourced if you follow me on Twitter or Mastadon or whatever Blue Sky I will um alert whenever it becomes available um I also want to improve CV identification and um create options to like better update the the driver risk scoring tools right now like it you run it once and that's the score forever there is no like iteration to update it to see if there's like new new information about it so but that's it that's it so imagine instead of one ring to rule all Rings there were a thousand Rings or a million rings to rule all Rings yeah that would be a different

movie right anybody have any questions

yes we are looking into that it's it's a delicate um line to walk right because we don't want to block things that are legitimate and like depend are necess necessary for business processes

yeah we could very easily do that right and I think there might be a tool already to out there that will just automatically pull out all of the io control codes yep yes

the only way I've done it so far far is to just reverse engineer it but you could do it using API monitor yeah usually like dve aren't very ausc so you load them up and like you just follow it's like three clicks and then you just see a whole list of IO controls it's uh like even a very new a person new to reverse engineering could very easily find them so I hope that I have educated all of you about how drivers work and given you something to think about and if you see um bovd in the in the headlines now you have um more education behind you to understand what that means thank you for

your time [Applause]