Today, we are witnessing the impact of an IT outage to an upgrade in Crowdstrike endpoint sensors. This is causing major disruption across key industries such as healthcare, finance, IT, and aviation. 

Key Considerations

While the outage is due to a failed attempt to upgrade the sensor due to installing a new kernel driver, it raises 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 kernel drivers when affected, will not crash the system and kernel and cause system outages.

Better Approaches

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.

Leveraging osquery allows you to have deep visibility into the telemetry of your Windows endpoints. However, more importantly, the Uptycs osquery-based sensor for Windows can be configured to run completely in passive mode in your most critical workloads. This gives the following advantages:

• While still preventing threats by passively analyzing malware like behavior and applying remediation just in time to stop the kill chain.
• 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.

Solving For This Issue

At Uptycs, our Uptycs Sensor team is 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, with 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 osquery based sensors as highlighted above provides a distinct advantage that is less intrusive and more adaptable while providing in depth visibility and security into your Windows fleet.