Which implies that any malware capable of replacing these channel files can crash their kernel driver. I wonder if there's a non-crashing way to exploit this & get kernel-space code execution.
Any malware capable of modifying files under C:\Windows\System32 has no need to fiddle with these files because to have that capability means it already got the keys to the kingdom and could wreck the system in a billion different ways.
The directory they're stored in needs Administrator access, but the kernel runs with SYSTEM level permissions. Administrator is an account, SYSTEM is a security principal. SYSTEM level processes can access domain servers in the context of the computer's domain account, while Administrators can't do so unless they provide explicit credentials (or share a password with an Administrator account on the domain). So this could be used as a way to elevate access from local Administrator up to whatever that computer can do on a connected domain server!
And yet the cleanup instructions were for the user to delete a file in that directory. That requires booting into safe mode, but if any random user is able to do that, kiss your systems goodbye, a good social engineer (or disgruntled employee) will own any desktop in your organization if he wants to.
The point is, malware can't get into that directory without user consent. Having physical access to the machine, rebooting into safe mode and running commands is a stonking big user consent.
I can pwn my own desktop, yes, all I have to do is say "run as administrator". But the point of the security boundary is to make it impossible for software to get these privileges without me actively giving it to them.
If you're shifting the goalposts and imagining the computer does not belong to me, but to an organisation that I'm a mere employee of, they'll be using AD Group Policy to control what I can and can't do, and Bitlocker to encrypt the boot drive. I cannot boot into safe mode without having the tech support department give me a special code to unlock the computer. Again, that's how you get on the other side of the airtight hatch.
In my organizations any user couldn't do it, we have to manually touch every computer and enter the bit locker key. We lost in the neighborhood of 14,000 end points, every single one needs touched. My team of 10 did about 800 in 5 hours. Pulling and entering the bitlocker key was what took the longest.
If you have write access a path like C:\Windows\System32\drivers\CrowdStrike\ (and I'd assume the parent directory), then you pretty much can crash the kernel many ways.
If you have the means to insert an AV config file update in between the config servers and the user's host then you probably can PWN the system pretty easily as well.
What this probably does mean is that Crowdstrike will be receiving some attention from hackers of both hat colors. Here's the bug bounty page ... https://hackerone.com/crowdstrike?type=team
