Back in July, we witnessed a major IT outage due to an upgrade in Crowdstrike endpoint sensors. This caused major disruption across key industries such as healthcare, finance, IT, and aviation. The incident was historic, with the worldwide financial damage estimated to be at least US$10 billion.
What happened, and what lessons should we learn?
The Need for a Passive Mode
While the outage was due to a failed attempt to upgrade the sensor due to installing a new kernel driver, it raised the following question – is there a less aggressive setting needed for you to be able to detect malicious behavior but not cause key outages?
Ultimately, the goal is to be able to detect key activity in your Windows endpoints for incident response, vulnerabilities, and malicious risk. This requires the need to have a passive mode which, unlike with affected kernel drivers, will not crash the system and kernel and cause system outages.
Endpoint Protection without a Kernel Drive
With eBPF not being available for Windows, how do you solve for endpoint protection without having to use a kernel driver?
Kernel driver based callbacks are only one of the many available techniques on Windows to obtain fine grained operating system telemetry and apply detection rules over a combination of them. Over the years, Microsoft Windows has evolved to provide many user-mode interception and observation techniques both inline and passive. Still, a lot of vendors choose kernel mode callbacks for their ease of implementation and one-stop nature of the solution.
At Uptycs we’ve designed a better way. Our sensor allows you to have deep visibility into the telemetry of your Windows endpoints. However, more importantly, the Uptycs sensor for Windows can be configured to run completely in passive mode in your most critical workloads. This gives the following advantages:
- You are preventing threats by passively analyzing malware like behavior and applying remediation just in time to stop the kill chain.
- The sensor does not cause outages due to incorrect kernel modules/kernel behavior.
With this approach, you also get security visibility through insights into the state and activity of your Windows endpoints that can be applied to a fleet to detect what is anomalous, what is common vs what is rare, and so on.
The Uptycs Solution
At Uptycs, our Uptycs Sensor team is still actively monitoring affected assets in our customers. To workaround the issue you should do the following:
- Query your assets for the affected kernel driver. For example, at Uptycs we can leverage our security data lake to be able to do this across thousands of Windows endpoints: select * from kernel_memory_map where image like '%C-00000291%'
- Delete C-00000291*.sys. We can achieve this manually on a windows endpoint. However, on a large scale that is inefficient. At Uptycs, we can leverage bulk remediation to do this on a fleet of windows endpoints.
An example of a bulk remediation powershell script that can be used to disable the faulty driver on affected endpoints is:
Conclusion
There are better alternatives to using kernel modules to solve your security for Windows endpoints. While eBPF developments are being pursued for Windows, leveraging less intrusive but equally effective sensors as highlighted above provides a distinct advantage that is also more adaptable while providing in-depth visibility and security into your Windows fleet.
Connect with our Team
The Uptycs team is ready to help. If you would like to learn more about the Uptycs Platform, speak to one of our experts, and see a demo of how to investigate and remediate issues like this one contact us today.
