CVE-2025-NoOneCares

A few months ago I was joking around with a colleague how cool it would be to use a vulnerable driver for one of our next RedTeam-Engagements. Well, from there on I went down a big rabbit-hole and started hunting for vulnerable drivers. Let me show you how that went.

Disclaimer: This information is for educational and research purposes only. Do not use this on systems you do not own!

Before you hunt me down, let me tell you why I am releasing this research now. I contacted multiple people and sent out multiple mails and messages over multiple channels over many days.

No one ever responded to me. Not even a boiler-plate-text. This is not cool guys! I will give you the common 90 days or so to fix this (or even longer if needed) but at least respond to me somehow. I redacted the full IOCTL-Codes to not give it away right away and will not release full code until the 90days are over. I have not much hope though to ever get a response.

BYOVD

First of all, why is this cool (trust me bro) and what does an attacker gain from using a vulnerable driver with BYOVD? (Bring your own vulnerable driver). When we ignore the drawbacks of BYOVD, the main pro-aspects are that you could potentially run your code from Ring0, which is the highest (or lowest) area on a windows-system and therefore is not restrained by anything. This is the high-level-idea, there are obviously some pitfalls and still some restrictions in place that you have to get around but the main idea of BYOVD is to get into Ring0 where the possibility resides to run your stuff from kernel.

This picture here shows you why getting into Ring0 is cool and any attackers goal. Another thing, most people do not know about the other rings and that you can actually go lower (higher?) in terms of access. You mostly only see the userland-rings (1-3) and Ring0 as the kernel. Windows is really only using Ring0 (kernel) and Ring3 for userland. For simplicity this is enough and needs no further splitting. For completeness-sake though let me show you the other rings as well.

Technically speaking we do have Ring -1 up to -3 as well. Those are even lower and more privileged or lets say, closer to the hardware. Intel VT-X for example runs in Ring -1 and even for those rings you will find malware (rootkit bluepill) or Ring -3 (tereshkin).

While those are interesting and cool to explore, they are even harder to exploit and even more selective and rely more so on the actual architecture than our driver here. Because of that (and because this is way easier) we are looking at BYOVD for now.

Driver?

What is a driver? To quote Microsoft (and because I am lazy)

This is not everything though. A driver is like an executable and can be copied onto a system and then could potentially run there as well. What differs here is how it operates and where it runs in the system. Before you get the pitchforks out, I know a driver != every other executable, but we are looking at this from the attackers point of view...calm down ;)

DiY!?!?

Now that we know that a driver is cool and all and that exploiting one gives you all the rights and stuff, why not write our own and load it into Windows? That would be cool but realistically not worth it (for an attacker at least) and not possible which is why we need to bring our own.

WHQL vs EV-Cert

First hurdle we would have to get over would be to get your driver to run on an up-to-date Windows 10 or 11. You would need to obtain an EV-Certificate basically proving to Microsoft that you are a legit company/individual with no malicious intentions.

The certificate cost is not even the bad part here (I saw some for 300$) but getting approved is. Only if you are approved you will be able to sign your driver and get it to load without hiccups on a modern system.

WHQL = Windows Hardware Quality Labs is the gold standard and will allow your driver to also be distributed via Windows Update (for example Nvidia Drivers). If you wanna know if your driver is signed you can simply check the file itself and look for the Digital Signatures. In this case a driver from Microsoft itself "crashdmp.sys" in C:\Windows\system32\drivers

Driver Blocklist

Next hurdle to get over is the Windows Driver Blocklist

This is simply a list of known vulnerable drivers that could be abused and therefore have been blocked by Microsoft. If you find a vulnerability and this driver is on this list then you will not get it to load without turning off multiple security-features which basically makes it worthless for any serious use. Microsoft is pretty fast in updating this list so once your vulnerability is known, it will not take long to land on this list.

Moar?

As if this would not be annoying enough, we have more shit we need to get around as an attacker. It is important to note, most of those protection will - unlike "normal" exploit-code running in userland - trigger a BSOD and crash the system if triggered, which is one of the reasons why developing kernel-code is much harder. You basically have to write flawless code that gets around the security-features everytime otherwise if caught, you risk crashing the system. Next up are some of the protections we have to worry about.

SMEP (Supervisor Mode Execution Prevention)

Simply, if the kernel (ring0) is supposed to execute code from userland (user memory) this will trigger a BSOD.

SMAP (Supervisor Mode Access Prevention)

In addition to SMEP, this will crash the system if the kernel tries to access userland-memory.

kASLR (Kernel Address Space Layout Randomization)

This works the same way as ASLR in userland and will simply load the kernel at different memory locations. This makes it harder to find the kernel base and therefore the right function or code to execute. There is a mask though that could be applied and locations are somewhat predictable and not that hard to find most of the time, as we will see in this post.

kCFG (Kernel Control Flow Guard)

Meant to control the flow (duh!) and crash the system if you are trying to use ROP-Gadgets. Not impossible but harder with kCFG.

DEP (Data Execution Prevention)

Same as in userland and will not allow to execute code from certain pages. Its a simple flag that can be set (or not)

PatchGuard

This (stupid) feature is like a guard-dog on speed. It will randomly check certain tables like the SSDT or IDT and check for any changes. If it detects changes it will crash the system. If you are trying to modify the kernel itself or rather play with its functions, you will need to play with PatchGuard.

HVCI (Hypervisor Code Integrity)

Think of a glass house with someone watching you from the outside. HVCI is basically that and you have no access to this watcher and will have to deal with it. In reality this means you will have to get around HVCI by finding other ways. HVCI basically enforces certain concepts like "no RWX-pages in kernel" and others.

The boring part

"Ok enough complaining, show me the good part already!" I hear you! Before though, lets get through the process of finding the right targets first, so you can understand my suffering a little. To find drivers I did the following:

Download anything and everything that I could find online with the ending ".sys". Afterwards filter those files out that were not signed as not signed meant I would not be able to simply load them onto a modern system. Next, check those signed files for validity. If the used certificate is revoked or not valid anymore, the file is basically not signed. Last step, check those files against the Windows-Driver-Blocklist. Last step, check those files if it contains interesting operations like MmMapIoSpace, ZwTerminateProcess, ObOpenObjectByHandle and many others.

Yeah, a lot of boring steps but in the end I ended up with a little over 4k files of drivers. Quite a lot to get through but after months I had a few vulnerabilities and PoCs ready to go and sorted them in a simple sheet. Here is a snippet...

Talking to myself

That is how I felt after I found a vulnerability. After checking quite a few drivers I developed PoC-Code for some of them and created reports with screenshots, offsets, used versions, environment, source and whatever else you would need as developer to work with me.

With those reports in hand I then contacted several big companies in an attempt to get this vulnerability fixed. The workflow was quite simple.

1. Find the right contact like security@ or psirt@ or something else. This was already pain because it seems some companies really want you to search for hours for the right contact and do not mention it anywhere on their site, who to contact.
2. Write a simple email with some hints and the request for a secure channel (pgp-key)
3. Wait for a response
4. Ask again...
5. and again
6. get annoyed

The !ONLY! company that not only responded in a timely fashion but also at least said "thanks" (I did not ask for anything with my initial email) was Lenovo. So, shout-out to the Lenovo PSIRT-Team. The found vuln. was already known internally unfortunately so was not credited to me.

All the others, Gigabyte, AsRock, MSI and some other smaller companies did either not respond, respond really late (how long do you need for a simple response? Is 14 days not enough?) or send me around to other departments which then ultimately ghosted me.

I have to preface, I never intended to make money with this research. 90% of the motivation was to understand how it works and to simply be able to have a working powerful exploit in hand, in case I would need it. A CVE would have been nice and a nice boost for my resume but not necessary.

WTF EVGA!?

Ok now that you know where I was coming from, lets look at my latest example. As the time of writing this blog (27.11.2025), the following vuln. still exist and still works on a current W11 (or W10). I found 3 critical vulnerabilities in the still current driver from EVGA Precision X1 v. 1.3.7.0

On top of that, this is a WHQL-Driver which means it enjoys the added bonus having gone through the Windows Lab which in return means that it is an even more trusted driver.

Before you say, "its EOL" yeah it is about to go End-Of-Life but you can still download it, the certificate is still valid and the driver can still be loaded. In other words, the software if installed (or loading the driver) is still currently vulnerable with the most recent up-to-date version.

When installed you will find the following driver "driver-x64.sys" in "C:\Program Files (x86)\EVGA\Kernel"

Cool?!?

"Ok cool but what did you find?" Now that we know how attractive this driver is from an attackers PoV, lets see what I found. I will not go into the code details and share the exploit (to not burn it right away) but show you where the vulns. exist.

In total I found 3 vulns.

• Arbitrary Read Primitive
• Arbitrary Write Primitive
• Arbitrary out

With those (actually you only need the first 2) it is possible to read and write (technically) anywhere and take over the system. I will explain a simple LPE with the first 2 vulns. The setup I used for this is the following:

• Windows 11 Pro 25H2 (Up-to-date 27.11.2025)
• All Security-Features active

Next, I attached a kernel-debugger via WinDBG and went hunting.

Arbitrary Read

You can find a vulnerable MmMapIOSpace at a certain IOCTL-Code. With this call we control Physical Address and can read 8bytes from any address. After poking around a bit I found that there is a ph. address which always contained an address with the same delta to the kernel bases address. This changes with every Windows-Version though so be careful where you run it or change the offsets accordingly.

As the delta never changed even after reboot, we can calculate the kernel base address (physical)

From here on its easy and just a question of the right offsets to calculate other addresses as well. With the now known address of the kernel base we can calculate the address of PsInitialSystemProcess which points to the system process (4). From here we can translate it into a virtual address and find the _EPROCESS_TOKEN address (va and pa).

Arbitrary Write

With that token in hand we can now use the second vulnerability which allows us to write to any physical location in memory. First though we need to find our own process and translate it into a physical address. Last step is to simply overwrite our own _EPROCESS_TOKEN with the value of the system process.

If this all worked we should elevate ourselves to system

What now?

As you can see, this works on a current Windows 11 25H2. Only downside, like with most kernel-stuff, you have to adjust the offsets. Still, a simple vulnerability and simple to exploit. I will now send this off to Microsoft - as my last attempt - to hopefully get a response - and otherwise just stop bothering writing reports at all.

If you have any questions just contact me via twitter (@doerp411) or LinkedIn or via blog@0idea.dev. The arbitrary out-vulnerability I leave for the reader to find as it is critical but not even necessary with those 2 vulns. Have fun! ;)

Cheers!

Timeline (until today - 27.11.2025):

• 12.11.2025 Contacted EVGA via Ticket Form - no response until today
• 15.11.2025 Contacted EVGA via mail - no response until today
• 17.11.2025 Contacted EVGA via personal mails (tech-lead) - no response until today
• 18.11.2025 Contacted disclosure@CCC via mail - no response until today
• 20.11.2025 Contacted EVGA via LinkedIn - no response until today
• 21.11.2025 Contacted EVGA-personal via LinkedIn (EMEA-Marketing) - no response until today
• 21.11.2025 Contacted S3cur3Th1sSh1t via Twitter - One of the only people responding > Thank you S3cur3Th1sSh1t > Recommended me to contact Microsoft as they signed it as well (WHQL)
• 27.11.2025 Finished this blog and published it