CyberWire Daily - The driver's seat to ransomware. [Research Saturday]

Episode Date: August 1, 2026

This week, we are joined by Marcus Hutchins, Principal Threat Researcher at Expel, sharing their work on "Not very gentlemanly: Analyzing a zero-day exploit used by The Gentlemen ransomware to disable targets’ EDRs." Researchers examine how the Gentlemen ransomware group used a previously unknown zero-day vulnerability in a legacy Windows driver to disable endpoint detection and response (EDR) tools before deploying ransomware. The report details the group's advanced bring-your-own-vulnerable-driver (BYOVD) techniques, which bypass multiple Windows security protections to gain kernel-level access and terminate protected security software. It also outlines defensive measures organizations can take, including enabling Windows Defender Application Control (WDAC), virtualization-based security (VBS), and vulnerable driver blocklists to reduce the risk of similar attacks. The research and executive brief can be found here: Not very gentlemanly: Analyzing a zero-day exploit used by The Gentlemen ransomware to disable targets’ EDRs

You're listening to the Cyberwire Network, powered by N2K. Hello everyone and welcome to the Cyberwires Research Saturday. I'm Dave Bittner, and this is our weekly conversation with researchers and analysts tracking down the threats and vulnerabilities, solving some of the hard problems and protecting ourselves in a rapidly evolving cyberspace. Thanks for joining us. And I quickly realized that this was essentially a zero-day exploit that allowed allow them to just with the click of a single executable,

actually go from user mode to kernel mode and disable the EDR product. That's Marcus Hutchins, principal threat researcher at Expell. The research we're discussing today is titled Not Very Gentlemanly, analyzing a zero-day exploit used by the gentleman ransomware to disable targets EDRs. Well, let's dig into some of the details here. Research talks about this being a B-Y-O-V-D attack, which correct me if I'm wrong, is bring your own vulnerable driver. I have that right? Yeah, absolutely.

So can you unpack that for us for folks who might not be familiar with that term? What's involved there? Yeah, so back around, I think Windows XP-64Bet or Windows Vista, Microsoft introduced kernel mode code signing, which basically means in order to load drivers into the kernel, they have to be digitally signed with a certain type of code signing certificate that's not super easy to get. And that was designed to make it harder for malware and stuff to get into the kernel, which at the time was a huge problem.

But now you have this issue for the threat actors, which is all of the security products they sit in the kernel where they shouldn't really be touchable unless you were somehow able to load a kernel driver, but this signature requirement makes it quite difficult to actually get hold of a valid signature and sign a malicious driver. So with this barrier to getting into the kernel,

what Throne Act has found is that they could take legitimate, digitally signed vendor drivers, and they could either use known vulnerabilities, look for new ones, and then they could take the driver, load it, exploit the vulnerability, and then use that to gain cover mode code execution. And that's all the sidesteps this whole need for signing your own malware

because you can just piggyback off of legitimate digitally signed software. Well, you mentioned that this is a zero day that was used to disable EDR. What made disabling the EDR such an important step for a ransomware operator? What advantage does that give them? So for a lot of EDRs now, they've gotten really good at preventing ransomware attacks. They have all these features that will look for the sort of file access patterns that ransomware would do when it's encrypting files

because most security evasions, there's multiple ways to do different things. You can find different techniques. But when it comes to opening a file, reading the data, encrypting it, and then writing it back to the file, there isn't really any alternative ways to do that. So the security products can just go, oh, someone is opening and writing a ton of files on the system. This is abnormal. And then they can just shut that down.

So a lot of EDRs pose like a really serious threat to ransomware because they're just simply able to shut the attack down. So the ransomware actors basically just decided the easiest way around that was to just go into the kernel and disable the EDR entirely. Well, let's walk through the investigation together. As you mentioned, this unusual file got handed off to you. Can you take us through your process for examining and figuring out what was going on here? Yeah, absolutely.

So we sort of just, the file was just named WER.E. I'm sure it's just keyboard mashing because obviously those keys are all right next to each other. And I'm like, already that's strange because it was found on a domain controller. So like this is just an arbitrary file with a keyboard mashing name that has been found on a privileged system within the network. So I'm like, okay, that's definitely going to be interesting. I want to take a look at that. So I open it up in my reverse engineering software and I start pulling it apart. And I immediately see that it is referencing a driver.

And whenever I see something that's referencing a driver, that's usually an indication that it's either some kind of edge. exploit or B-Y-O-V-D attack. So I saw that driver name and I was like, I need to get hold of this driver. So I messaged the team and I was like, have you seen this driver with this name? The driver was in this case, KTAPI.S. So I asked, have you seen a KTAPI.S loaded on the endpoint? Because it must have been dropped and loaded at some point. But they couldn't find it.

So I actually went to Virus Total and I found it on there. So I pulled down the driver and within like probably three minutes of opening it, I'm like, oh, this is a vulnerable driver. It's one of those drivers that just, it's so powerful. It just lets you read and write arbitrary memory and it has so few features that you can just look at it and be like that is a vulnerable driver. So the driver itself is sort of a blank slate for whatever folks want to take advantage of it for? Yeah, basically, I believe these are often referred to as Godmode drivers.

They're usually used for hardware debugging by vendors, and they often expose these absolutely way over-privileged capabilities, such as the ability to write arbitrary I.O. ports, arbitrary physical RAM. So in this case, this one just allowed any user mode process to connect to the driver and then just read and write any address within the system's RAM. And naturally, you have a boundary where user mode processes are only allowed to write their own memory. They're not allowed to touch kernel memory. So you have this driver that just allows it to read and write whatever memory it chooses,

which means it can now override kernel memory. Well, take us through what happens next. you have this revelation. You're hot on the trail here. What's the next step for you? So obviously, first thing is to notify the client or the partner of my findings because there's obviously very serious. You find a zero-de exploit in your domain control.

That's a very serious issue. And then once I handed off the notification, I went on to essentially just finish reverse engineering the exploit because I was actually quite personally curious about. how it works because I'm fairly familiar to with vulnerability research but I'm not familiar with like how do you go from writing arbitrary physical memory to kernel mode code execution so I thought that would make a nice blog post and it would also be a nice learning experience for me because I don't personally have experience with privilege escalation uh exploits of this nature

so I then kind of spent a week just sort of pulling apart this exploit to figure out how each step of it worked. Can you explain to us how they went about jumping from user mode into kernel level control? Yeah, so basically they mess with Win32k.Sys, which is the part of the kernel that is typically responsible for graphics processing. There's some functions in there. They're just essentially stub functions, which means they call an address. from memory. And usually in the kernel you have something called a patch guard or a kernel

patch protection, which prevents you from overwriting any code that gets called. So theoretically, in most cases, you should not be able to redirect the kernel to call arbitrary code. But in this case, they had found some functions that were not protected by patch guard, sorry, some function pointers. So what they did is they redirected the function pointers to kernel, functions and these functions are exposed to user mode. They're normal functions that user mode processes can call without any like kernel privileges. They're like just day-to-day functions. But then the kernel side of the code, they had redirected somewhere else.

So now they're able to take these functions of the callable from user mode and use them to call any kind of function they want. So they start redirecting them to the function to allocate memory. they allocate a bunch of executable memory, then they write some shell code to the memory, and then they replace the function pointer with the address of the shell code, and then use it to call the shell code. So they've just gone from this very mundane user mode callable function

to this setup where they can just arbitrarily call any kind of mode function with full kind of level privileges. We'll be right back. This episode is supported by Black Hat USA. If you follow the research, you know a lot of it breaks on Black Hat stages. Hundreds of peer-reviewed briefings, more than 100 hands-on trainings, and the largest business hall in Black Hat's history. Six days to learn the skills you'll need tomorrow.

August 1st to the 6th. Use code Cyberwire for $200 off your briefings pass at blackhat.com. We'll see you in Vegas. You mentioned that this was a bit of an exploratory journey for yourself. How do you rate the sophistication of what you saw here as you dug into it? Were there any moments where you thought to yourself, I'm dealing with someone who's clever? Yes, so when I started pulling apart the exploit

and I started looking at some of the bypasses, because there's a couple of different security features. You have to bypass on modern hosts. you have things like supervisor mode execution prevention and supervisor mode access prevention and they had all these little tricks to bypass those exploit mitigations and just going through the code I was like this is a lot more advanced than what I'm typically used to seeing from ransomware actors or crimeware actors like this is a proper privilege escalation exploit and I had seen some like

small tells in the code that it might be, it might have some overlap with game cheats because they do this a lot as well in order to bypass a game anti-cheat software, which also exists in the kernel. They use the same techniques. They use B-Y-O-V-D attacks to get into the kernel and bypass these game cheats.

And some of the techniques had actually been documented on video game cheating forums. So I was like, this is a very sophisticated either cheat developer or exploit developer who's written this tool for a ransomware gang. I think a lot of organizations assume that if they're running a modern EDR,

they're pretty well protected. What's the lesson that defenders should take away from this incident? Yeah, so BYUVD just, it continues to be a massive problem because you have this sort of technical debt where when vendors sign drivers, they typically just have one code signing certificate, which means every single piece of software they release, every driver, every user mode executable,

is all signed with the same certificate. And then when they have an old obsolete driver, they don't want to maintain anymore, or they find one of their versions that their driver is vulnerable, there isn't really any recourse at all. The only realistic thing they could do is revoke their entire code signing certificate, which would just break every piece of software that they've ever signed. So what essentially happens is as vendors sort of release new software and new drivers, they just accumulate because once they're signed, they remain valid forever.

So you have this massive, like 30-year-long backlog of drivers that are still loadable on the latest Windows system. and they're still validly signed and there's no way to unsign them. So all the threat actor has to do is find a single driver with a good enough vulnerability to get kernel mode code execution, and they can just disable your EDR. And there's probably hundreds of thousands, if not millions of these drivers floating around out there that no one actually knows about. And this is just a very, very hard problem to solve.

Yeah, have you thought about, potential solutions to this particular problem? How could we figure this one out? So unfortunately, the best solution right now is Windows Defender Application Control, which is basically an application allow listing software. And it's a default component in the latest version of Windows. So if you're on Windows, I believe 10607 or above,

you have access to this feature and it works for kernel drivers so you can say only allow these kernel drivers that are already installed on my system and block anything else but the problem there is if you're like a massive enterprise you have all these different systems running all these different drivers and you don't know what drivers on what system so you need to somehow go out there order all of your systems and i mean you run into immediately a problem there which is asset inventory. Like most companies don't even know what systems they have. So you have to first figure out what systems do you have, what drivers are they running, and then you need to building massive application allow list of only the drivers that are needed to load on your system and then deploy

that organization-wide. And of course, if you miss a driver, then you now have a kernel driver that is not able to load, which can cause anything from like system instability to the system just won't boot at all. So it's a massive, really complex task. But it's really the only surefire way to prevent BYUVD attacks. Yeah, it seems like a real balancing act of the obvious necessity of these drivers. But as you said, there are thousands of them going back decades. I think there could be more things that could be done from Microsoft's end,

maybe sort of creating a segment in the kernel for specifically EDR drivers, and then saying, okay, you can only load drivers into this part of the kernel. If you have a special certificate that's only issued to security vendors or highly trusted vendors, and then there's sort of some kind of restriction on what you have to do when a vulnerability is found in your driver. But as things kind of stand where all drivers are considered equal, it's almost impossible to solve. I'm curious, your process as a researcher, again, talking about a balancing act,

it seems to me that you have to balance between providing enough technical details for folks out there to be able to do the things they need to do to defend themselves, but at the same time, you don't want to provide unnecessary help to the attackers themselves. how do you strike that balance day to day and the work that you do? Yeah, so this is actually something I spend a really, probably a way too long time thinking about because you are right, every time you go out there and you document an attack technique, sure, it helps the defenders, but then the attackers can also learn that technique from your blog. So I actually, on a case-by-case basis, will make the decision of,

is this going to cause more good or more harm? And in the case of B.Y.O.V.D. attacks, I think the equation's a little bit easier because in this case, I did basically document from beginning to end how this exploit works in a way that you could potentially just recreate the full exploit. But because it's used for disabling EDRs, that information is now out there for the EDR vendors. They now know of this driver and they can now block this driver from being deployed onto the system or loading. which means by putting that article out there, sure, someone could recreate the exploit, but it just wouldn't be useful for disabling EDRs anymore because every EDR vendor should be now taking that information and writing block rules for it. So in this case, it seemed like a pretty safe choice because it was so specific to targeting EDRs. We mentioned at the outset that this exploit was being used by the gentleman ransomware group. Are there any insights that you gained into that group themselves based on this research?

I wouldn't say this research specifically, but there's also been some research that came out around the same time about other exploits they'd been using. And it seems like they actually have a really massive toolkit of exploits for disabling EDRs. So it seems like they are either employing in-house developers to develop these exploits or they're cultivating them from somewhere. But they have a absolutely, like, massive collection of exploits, which I kind of didn't expect. I thought, like, maybe they might have, like, one or two here or there. But it seems that they just are sitting on a stockpile of all of these exploits. So whenever someone finds one and they report it, they can just move on to the next. Yeah, that's really fascinating.

I'm curious, what are your recommendations for the defenders in our audience? Any words of wisdom for them to best protect themselves here? Honestly, I really hate to say it, but it is when there's Defender Application Control. It is really the only short-file way to prevent BYUVD attacks. It's an absolute nightmare to set up and deploy, but it really, at this moment in time, is the only viable solution. There is a built-in vulnerable driver blog list that is built into newer versions of Windows, and you can enable that, but the problem is it's only updated at most about twice per year. So this driver isn't on it.

It might end up on it sometime in the next year, but until then, it's not really going to help much. And I'm sure they have already found new drivers, which won't end up on the block list until those two are burned. So I really think application allow listing is the only viable solution in this case. Our thanks to Marcus Hutchins from Expell for joining us. The research is titled Not Very Gentlemanly, analyzing a zero-day exploit used by the gentleman ransomware to disable targets EDRs. We'll have a link in the show notes. And that's Research Saturday, brought to you by N2K Cyberwire.

We'd love to know what you think of this podcast. Your feedback ensures we deliver the insights that keep you a step ahead in the rapidly changing world of cybersecurity. If you like our show, please share a rating and review in your favorite podcast app. Please also fill out the survey in the show notes or send an email to Cyberwire at n2K.com. This episode was produced by Liz Stokes. We're mixed by Elliot Peltzman and Trey Hester. Our executive producer is Jennifer Ibin. Peter Kilpe is our publisher, and I'm Dave Bittner.

Thanks for listening. We'll see you back here next time. Heading to Black Hat USA, the N2K Cyberwire team will be on-site recording from our podcast studio in the SpectorOps Kennel Club. If you're interested in joining us for a conversation or learning more about what we're recording throughout the week, stop by the studio and meet the N2K Cyberwire team. SpectorOps's Kennel Club is adjacent to Libertine Social inside Mandalay Bay.