LOLDrivers

[hfiref0x]

Hello,

Here is couple of suggestions, my opinion if you don’t mind.

First of all, by bringing such collaborative list you should clearly specify what you mean under term “loldrivers”. Is it legitimate drivers which have some shady functionality? Or it is legitimate driver that turns into hacking tool by a bug? Or legitimate driver that unexpectedly turned into wormhole? Or it is all from above? Your list labelling as loldrivers literally everything – from legitimate bugged drivers to legitimate drivers with shady functionality and even just pure malware drivers signed with leaked certs. You have to distinguish what you want to represent. Malware drivers for example doesn't fit into any possible category of BYOVD which is what you describe as synonim to loldrivers.

If your plan is to organize your list as table, what is a practical purpose of “author”, “created” and “command” columns? “Author” and “created” are meaningless information nobody cares.

When someone looks for list of vulnerable drivers what they want is driver name, driver hash (optionally including Authenticode hash), optionally software name and a direct download link to exact sample.

The “command” column is totally useless and I will explain you why. I do not understand purpose of it. First, there are bunch of drivers that can’t be properly initialized by just creating service entry via executing sc commands. And even more – if you create registry entry with SCM this doesn’t guarantee you that driver you want to load will be accessible after successful load by sc command. That’s because some drivers actually built using driver frameworks that expect more information for proper driver initialization compared to simple legacy WDM stuff. If not initialized they won't create any device objects/symlinks etc, meaning no communication will be available. Second, even if loaded - some drivers will not be accessible without magic tricks which are specific to each sample. For example ENE drivers require caller checks to be passed to open a handle for them, and these checks are different for various versions of the drivers. Without this they will simple sit in kernel memory doing nothing while been inaccessible for user mode requests. Asrock drivers are based on RwEverything which requires IOCTL data to be encrypted with AES, etc. The amount of work required to load and “unlock” such drivers will not fit into any kind of table column.

As of source of this list, I see it incorporates mostly MSFT blocklist, and some of the open source lists available on github, for example from namazso. Okay, but.

There is a general problem with MSFT list. It is clunky and unprofessionally maintained.

From the beginning they started adding too much trash that nobody except MS seen while ignoring popular and widely exposed samples. For example – RTCore from MSI was known to be wormhole few years and they added it into this list just recently after some mass media hysterics. Or Process Explorer driver as another example. What they are doing is constantly adding various trash no one cares from unknowncheats.me and similar game cheat-oriented forums. I understand that signed BlackBone driver used by 100-150 users of unknowncheats exposes a giant THREAT to the MSFT while publically available exploited WHQL’ed drivers from senior hardware vendors are not. Even now they ignore entire set of drivers from some pseudo-ISV companies (one of it perfectly works with HVCI on) and drivers used recently in APT attacks (that even had some CVE numbers assigned) while busy fighting with numerous BEDaisy (BattleEye anticheat) drivers – a fresh upload from lurker on unknowncheats for sure. I’m not even talking about DELL drivers which they still cannot properly insert into their blocklist. Another kind of trash in this list is vulnerable drivers that are just… bugged. They have no value from attacker perspective (exploit primitive doesn’t work in modern Windows versions and this list is not available where this driver works) or when exploiting such drivers will bring too much instability for target system. Not every vulnerable driver is worth exploiting or can be used, it is far from everything. Even CVE id is not guarantee here. For past few years too much trash and noise were created with duplicate CVE describing same bugs with same but differently named drivers (hello winring0/winio). After all of this judging on amount of resources MSFT has - their list is unprofessionally maintained and doesn't worth a cent. So by blindly incorporating everything from this blocklist in yours you are just trashing it.

I’ve no idea how you will maintain this list without doing actual check of every sample you add.

[ghost]

What if tagging was featured, similar to malwarebazaar?

Then the community could tag / label / classify further each driver as well as add more context?

[MHaggis]

Thank you @hfiref0x for the feedback, we really appreciate it. You opinion is extremely valid here.

I sort of look at the LOLDrivers name as a similar name as "Doctor". When I tell someone I'm going to become a doctor, the next question is - What kind/type of doctor? LOLDrivers is similar, and you called that out, so I think it came across that it does cover all the different types.

The background of the project comes from a defenders perspective. Organizations of all sizes don't realize what drivers are running in their environment let alone which are good/bad/in between(?). Where do we start? How can we shine a light on to the community, help organizations of all sizes? I only recently was interested in drivers in 2019 when we investigated an event that lead to a malicious driver on disk. Who knew it was there. Many organizations and defenders may not be aware there are so many of these out there. There have been disparate lists of drivers, a directory full of them, some yara rules - but never a single source of truth - never a place where as a defender, I can go and see what drivers there are, a reference on it - how it was used or found in the wild. Now we have something. Sure, we'll never be "finished" with this project, we'll always miss an amount of evil drivers out there, but ultimately the idea is to take a light and shine it on a problem that doesn't get enough of attention. I hope that makes sense?

I definitely agree on the table on the front page and I like how @msftdevelop shared a cap of Malware Bazaar, ultimately that may be the way to go. Right now this was "get the project out the door" and receive feedback on next steps.

If there is any other things you believe we should clarify more or expand on for the site, definitely let us know. We really appreciate the feedback and it will help steer the project moving forward.

[Wack0]

Even now they ignore entire set of drivers from some pseudo-ISV companies (one of it perfectly works with HVCI on) and drivers used recently in APT attacks (that even had some CVE numbers assigned) while busy fighting with numerous BEDaisy (BattleEye anticheat) drivers

lol, you're right, they finally did add vulnerable bedaisy to the blocklist last month. I initially found the issue (stupidly simple privesc to PPL WinTcb lol) after someone on unknowncheats posted a devirtualised bedaisy idb (i seriously think any third party driver with heavy obfuscation should be considered malware by design, i consider vmprotect on a driver to be indicator of compromise at this point), and I reported it to MS' then brand new "report third party driver issue here" portal, then publicly posted a quick writeup after i heard nothing after several months. I wonder if it took them that long just to find every vulnerable binary...

I wonder if MS adding stuff to driver blocklist happens solely because of big game publishers and/or ~malware~ anticheat vendors complaints...

(I could write several pages on why anticheat's threat model is useless thanks to MS features and MS failings, but that would be somewhat offtopic here)

Tagging binaries sounds like a good idea.

[MHaggis]

Closing for now! We have a lot of new enhancements coming out in the next few weeks. Thank you again for the discussion!