See here's the problem. Win 10 kernel driver protections are: 1. Prevent the driver from getting installed. 2. If somehow no. 1 can be bypassed, prevent the driver from loading at boot time if Secure Boot is enabled. The fact the driver can be directly loaded into memory on the fly via .Net should not surprise anyone. Windows always will be a POC(piece of crap) security wise. That fact is one of the "undisputable truths."
That's being a little hard on those boys isn't it? Problem now as I personally see it is that even if Microsoft could, or would one day finally discover a better way to 100% prevent kernel poking like that, (minus new hardware), as it currently stands, the new techniques malware/hackers invent wouldn't even need to break kernel protection to fudge a Windows 10 unit good and proper. Is that so unusual? But back more on topic-that's a formidable move to have at disposal where they could 0wn the box and make hay any which way suits the plans. I remain solidly sold there should have been a Windows 9 to draw out all these sorts of (Ring0) kernel bugs/errors-and more, being raised and discovered on Windows 10 now. IMO sort of defeats the purpose of orderly sequence to skip-a-version while blowing the horn as the best and more secure when it's not there yet fully.
BTW - Endgame has a couple of kernel mode breach mitigation tools called KASR and MARTA here: https://www.endgame.com/tools for those who like to "play."
M$ did do a lot to make Windows safer, to be fair. Because of PatchGuard and Driver Signature Enforcement you almost never hear of rootkit attacks anymore. And for this attack to succeed, you still need to be able to run a malicious process, but I would sure like to know which technique is used to load Turla Driver.
I couldn't find any info about this, haven't they made it public yet? Normally, HIPS should always alert when certain API's are being used to load a driver, so I wonder how this could be done.
I haven't seen a HIPS to date that monitors COM activity. Maybe @cruelsister can chime if Comodo's Defense+ does.
What do you mean with COM activity? And there is still no info to be found, not even on their blog, pretty weird. https://www.endgame.com/blog/technical-blog
LOL, is Comodo still this stupid? But these COM alerts don't have anything to do with drivers being loaded "directly into memory", so that's why I didn't understand what itman means.
https://www.cbronline.com/news/kernel-attack-fully-compromises Koadic is a COM-based rootkit: https://www.countercept.com/our-thinking/hunting-for-koadic-a-com-based-rootkit/ -EDIT- Here's a link to EndGame's BlackHat presentation: https://www.blackhat.com/us-18/brie...nel-mode-threats-and-practical-defenses-11211 . You can download the slides which are contained within a .pdf. The sections you want to note are: INTERNAL RvB FILELESS KERNEL MODE IMPLANT -and- EVADING VBS/HVCI
About Koadic, it's a bit weird that they call it a rootkit, because in my book a rootkit makes use of API hooking and/or a malicious driver, this one seems to do none of them. And thanks for the second link, I was looking for this info. But it still seems that with this attack they don't actually bypass HIPS that monitor driver loading. After the driver is allowed to run, then it becomes hard to stop.