I was looking into BYOVD techniques today because of a recent case where a threat actor brought a vulnerable driver onto the system to disable the EDR and I want to share my thoughts on the topic. Bringing the vulnerable driver is just one part of the equation. Threat actors usually have to bring additional components to load it and execute the code needed to actually tamper with the EDR. The EDR blocked that payload... And I think that's an important point when we talk about BYOVD. For seasoned operators, this might be easy. But that is not most of what we see. The average threat actor still has to expose themselves somewhere along the chain: → Introduce and load the vulnerable driver -> LOLDrivers.io vuln drivers list → Create or start the service -> Service creation events → Drop a DLL or other payload -> File creation events under sus locations → Use PowerShell/.NET -> PowerShell execution events/AMSI detections → Compile something directly on the target -> Behavioral detections from ETW CLR provider. Usually CLR loading into non-.NET processes, assembly load notifications for newly compiled DLLs from `%TEMP%` There is not just a perfect way to detect BYOVD techniques. Defense in depth is the way to go... Again, having said all that, I know how difficult it is for the majority of organizations to have this in place. This is why these methods are still very successful and quite popular, but in my personal case, most attackers will not even come as prepared as seasoned operators like I mentioned above. We have to detect/hunt for the path they have to take to get there!