Of course it can be fixed in an automated fashion; it just requires effort. The machines should have netboot enabled so that new validated operating system images can be pushed to them anyway, so you just write a netboot script to mount the filesystem and delete the file, then tell the netboot server that you're done so it doesn't give you the same script again when it reboots.
It's like two hours of work with dnsmasq and a minimal Linux ISO. The only problem is that much of the work is not shareable between organisations; network structures differ, architectures may differ, partition layout may differ, the list of assets (and their MAC addresses) will differ.
Edit: + individual organisations won't be storing their BitLocker recovery keys in the same manner as each other either. You did back up the recovery keys when you enabled BitLocker, right? Modern cryptsetup(8) supports a BITLK extension for unlocking said volumes with a recovery key. Again, this can be scripted.
> so you just write a netboot script to mount the filesystem and delete the file
Because writing such a script (that mounts the filesystem and delete a file) under stress and time constraint is a great idea? That's a recipe for a worse disaster. The best solution, for now, is to go PC by PC manually. The sole reason the situation is as is was the lack of backstage testing.
If the affected organizations had such an organized setup, they probably won't need crowdstrike in the first place. The product is made so that companies that don't understand (and won't invest) in security can just check that box by installing the software. Everyone is okay with this.
