I've been following the crowd strike outage and as someone who was an ex malware developer is currently a malware analyst and has spent the better part of their life reverse engineering the windows kernel I actually felt like I was uniquely qualified to talk about this now I've been seeing like a lot of misinformation everything from antiviruses don't need to be in the kernel to this claim that Microsoft tried to lock antiviruses out of the kernel but then the EU said no you can't do that and that is the reason why this crowd strike outage happened and we' also seen a very dubious claim from Dave's garage where he implies that Microsoft had this amazing magical security API that was all ready to go uh and then the EU said no you can't release it and I want to kind of debunk all of these claims at the same time and also go through a bit of the history of uh windows and windows malware now the claim that the crre outage wouldn't have happened if antiviruses weren't allowed in the kernel is kind of correct in the same way it's correct to say that you won't get Whiplash from your seat belt if you don't wear it you might be dead but you won't get Whiplash now I think this claim comes from the fact that a lot of people aren't familiar with either Windows architecture or how security products on Windows work or worked because Windows has evolved throughout the days and it has got to a point where it is almost possible to make a good Windows security product without any c access at all but these cases happened around around like 2006 to 2009 which was in the Windows Vista era and I don't really need to say more than Windows Vista but we're going to go into details anyway now so what happened was back before Windows Vista if you were running as administrator on a system you could load a driver into the kernel and then you could patch the kernel to do whatever you wanted and this would allow maare to uh hide itself from the antivirus the user prevent removal it was a very powerful tool and this was referred to as the kernel rootkit now kernel rootkits were a huge problem on Windows now Windows never really had very good separation of privileges uh either at user mode or between user mode and konel so if you got onto the system as a standard user it was very easy to escalate to administrator privileges and there wasn't really a boundary between administrator and system so if you administrator you were essentially system and if you were system you could load a konel driver and if you could load a colel driver than you were kernel so you could go from user to the kernel fairly easily so ma would get onto a system it would slip into the kernel deploy a kernel rot kit and then it would basically just own that system now because Microsoft never really gave security products the tools they needed to do their job antiviruses essentially behaved exactly the same way as Colonel rootkits the konel was basically just a giant King of the Hill battle between security products and malware and of course that led to a lot of problems because the malware was causing instability the antiviruses were causing instability the antiviruses and malware fighting each other were causing instability and of course because the blue screen is synonymous with Microsoft whenever users would see the blue screen of death they would blame Microsoft and it gave way to The Narrative of Windows being like hilariously unstable uh when in a lot of the cases it was actually not windows that was crashing it was security products crashing the kernel or ma crashing the kernel so Microsoft decided we want to get rid of all of this so they invented something called patch guard or kernel patch protection which basically prevented any modifications to critical kernel structures from being made and this prevented both kernel root kits and antiviruses from operating ironically violating patch guard results in the system blue screening itself so they fixed all of the blue screens with more blue screens but we can just kind of skip over that part so what Microsoft thought they could do with Windows Vista is lock down the kernel and then prevent both malware and antiviruses from needing kernel access because if Mau isn't in the kernel then does the antivirus need to be in the kernel the answer is yes but it took them a while to learn this lesson you see they were making a couple of different bets on Windows Vista you had kernel patch protection which prevented both security products and malware from modifying the kernel you also had something known as driver signature and enforcement or dsse which requires your driver to be digitally signed in order to go into the kernel now Microsoft thought this was going to prevent maare from entering the kernel entirely because you would need a digital signature to get in but this was a long time before whql which is Microsoft's new process on Windows 10 where not only do you need a special certificate to be allowed in the kernel but you must submit your driver to be like manually verified by Microsoft so that actually does a pretty decent job at stopping ma getting into the konel but back in a Windows Vista days it was any code signing certificate and almost every software company had these you could sign up a shell Corporation and buy one you could steal one from a software company you had previously hacked uh or you can do a technique which still works today which is known as uh bovd or bring your own vulnerable driver and how this works is you take a signed legitimate driver that is approved by Microsoft but it has a vulnerability you load it into the the colonel and then you exploit the vulnerability to get konel code execution and this bypasses not only driver signature enforcement but the now more comprehensive whql so in locking everyone out of the kernel what Microsoft actually did is they accidentally created a situation in which it was actually easier for malare to get into the kernel than it was for legitimate security products and that was obviously a big problem but the problems didn't stop there and Microsoft bet a lot on user account control now user account control was a new system that was supposed to stop one of the problems I spoke about earlier which is the lack of privilege separation even within user mode like if you're User it's very easy to get to admin and if you're admin it's very easy to get to system so user account control kind of created this split down the middle you had low privileged code on one side and high privileged code on the other so by default any code run on an administrator account would just run with standard user privileges unless the administrator manually elevated that code to admin and that was kind of designed to limit the damage malware could do cuz you would have the antivirus running a system and if malware couldn't pass that boundary from uh user privileges to admin it couldn't tamper with the antivirus uh but as we know that didn't go so well uh because some of Microsoft's own code needed to run as administrator so their solution was to make a bypass certain executables were allowed to go from this limited user privileges automatically to administrator but malware developers found this and they found a way to abuse it so what happened is a lot of males started implementing these bypasses to go straight from user privileges to administrator and then once they were administrator they could go to system and they could simply just remove the antivirus when antiviruses were in the kernel it wasn't just to better detect malware it was also to protect their own processes so by limiting anti virus's access to the kernel they prevented the antivirus from defending itself now Now Dave basically claims that Microsoft had this new security API that would make all of this possible from user mode and then the EU said no you can't release that which if we just think about that for a second why would the EU do that why would they just be like hey we see you're making security better just just stop that now fortunately for us the case was public and as is Microsoft settlement in fact the settlement terms are hosted on Microsoft's own website and the settlement terms are what they agreed to in order to make this case go away and it mentions nothing about not releasing an API it mentions nothing of the sort Microsoft's agreement basically said that they have to create a Level Playing Field they're not allowed to give any capabilities to their own security products that aren't given to third- party ones cuz the problem wasn't that Microsoft made an API cuz that API was released anyway their problem was Microsoft tried to make one API for all of the third party security products and then have kernel access for their own so that kind of undermines that claim CU if this API was so amazing and so great and would have solved everything why would Microsoft not use it themselves like I wouldn't trust an iPhone salesman who uses an Android phone so why would we trust a Microsoft who doesn't use their own security API and it was worse than that because the EU did not say you have to let these products into the kernel they just said everyone has to have the same capabilities which could have meant that Microsoft take uh their own security product put it in user mode with the rest of the third party security products and then lock down the kernel but they chose not to they wanted to keep Kel access for their own security products so badly that they would rather let all of these security products that had been crashing windows and causing them all of this headache back into the kernel just to not use their an API that's apparently so amazing I'm not a conspiracy theorist but that doesn't make a whole lot of sense now since Dave mentioned the wfp or Windows filtering platform what I think he's talking about is some new apis that Microsoft introduced to make certain things possible without kernel access now the Windows filtering platform I believe is for packet filtering so it makes like firewall capabilities uh possible from user mode and I believe they also released a similar vers for file system filtering so that would enable like on access scanning and like antivirus signature scanning from user mode uh but there's a third class of security product that is missing here uh it is the runtime antivirus which has now come to be known as the EDR you see edrs don't work by scanning for file signatures or network signatures they work by scanning for Behavior now let's say I'm writing some malware that injects into the browser to steal users passwords now there are infinite permutations of code that I could write to do that which means there are infinite file signatures there are also infinite like permutations of network protocols I could use to exfiltrate the data which means there are infinite Network signatures but what isn't infinite well the ways I could inject into a process Windows has a finite number of apis and of those finite number of apis only a finite subset is useful for process injection so if you have to choose between tracking every possible file signature or every possible Network signature or a couple of different process injection methods that one kind of makes more sense right and that is what antiviruses at the time were doing with ssdt hooking which is what patch guard eliminated you see when a process wants to do anything on a Windows system it needs to talk to the kernel and it does that via a CIS call the CIS transitions into kernel mode and then triggers some kind of Kernel code now ssdt hooking allowed them to hook the kernel side of that process which meant that antiviruses could see any call a process was making and therefore anything a process was doing was it tampering with executable memory was it writing files that shouldn't be was it injecting into processes these were all very easy ways to detect malware versus playing whacka mole with signatures so when Microsoft introduced patch guard they killed that entire class of antivirus because Microsoft made a user mode way to inspect Network tra traffic and a user mode way to inspect the file system but they didn't make a user mode equivalent to what these antiviruses were doing to monitor process behavior in fact they basically took away all of their visibility they replaced it with like a couple of sporadic apis that would give you like a signal here and there but it was nothing compared to not just the being able to attract every possible system call but also being able to intercept them because one thing security products could do with CIS core hooking is if they suspected a core was ious but they weren't sure enough to block the process they could redirect it or edit the parameters or just block that call and let other calls go through so it allowed security products a lot of wiggle room between block and not block they could just block individual calls or change them to be slightly safer but they lost all of these capabilities with patch guard and this actually led to another EU court case where they were forced to release Windows Vista Service Pack 1 now Windows Vista Service Pack 1 did not fix the problem all they created a couple of callbacks that antivirus drivers could register to monitor things like handle access process creation but they left a huge gap in the capabilities that they removed with patch guard and one of those capabilities was memory access you see on Windows processors can interfere with the memory of other processors they can allocate executable memory into another process write code there and then run that code they can also like read and write memory and they can do all of these malicious activities which Microsoft didn't make an API to track so Microsoft made it very hard for antimalware products to see what processes were doing with either their own memory or other processor memory so this led to maare techniques such as process injection and shellco dominating the malware market for over a decade now one of the things security products tried to do to get some of this Insight back is inject code into every process on the system and then hook all of the windows AP AP that they needed that way if malware called an API to allocate executable memory the antivirus product would know except there was one teeny tiny problem with this the CIS you see as I mentioned earlier in order to talk to the kernel you need to run a CIS and CIS calls just talk directly to the kernel so even if antiviruses hook every single function in a process it can still talk to the kernel via CIS calls and this led to antivir bypass techniques such as using direct or indirect cisal which is still a technique that is popular today so the problem wasn't that the EU forced Microsoft to allow Kel access it was that Microsoft refused to make user mode equivalents to what security products were doing in the kernel and they drastically weakened EDR products as a result now later on in Windows 10 uh 1703 they did reintroduce some of those capabilities they basically said you can subscribe to our new event interface which will tell you uh when memory is read written allocated threads are created apcs are cued and that gave back some of the visibility they lost due to patch guard but it didn't give them back the ability to like intercept and redirect calls only see what calls are being run now since this API was introduced in Windows 10 1703 which was only released a couple of years ago it makes me really question Dave's claim that such an API was ready to go in 2009 with Windows Vista now Microsoft did actually fix a lot of the issues in Windows 10 they also introduced protected process and protected process light which allow certain whitelisted antiviruses to basically request that the kernel protect their process so rather than having to inject a driver into the kernel and modify all this kernel code to protect their user mode process the antivirus can just simply request that the kernel do it for them now when protected process light was initially released in Windows 10 it had like a lot of flaws where m could still tamper with the process and disable it but over time like most of those have been fixed and we are kind of at the point where on the very latest version of Windows 10 you can have an antivirus process without a kernel driver protecting it and with the new Microsoft uh thread intelligence API you can get a lot of the konel insights that you previously needed a driver to do but for every other Windows operating system none of that is possible so the idea that might Microsoft could have just like locked all of these providers out of the kernel providing no alternative whatsoever and that would have been fine is insane so the EU made the right call at the time and even if that argument happened today they would have still made the right call the problem is not that antiviruses are in the kernel mode or that the EU made Microsoft let antiviruses into the kernel mode the problem is Microsoft never made a sufficient API from user mode that enables antiviruses to do what they need to do so the blame is entirely on Microsoft like did crowd strike mess up of course but the blame lies entirely with Microsoft for creating this ecosystem that was so problematic in the first place if they had done something like what Mac did where they removed all the security products from the caral but then gave them all the same capabilities in user mode we wouldn't be having this problem but we are because it took to until the latest version of Windows 10 to get this fully functional anyway I hope you found this video insightful and as always if you did enjoy it please like And subscribe it helps my channel out and I'll be back with some more videos probably uh after Defcon