Operating in ‘kernel-space’ – the most privileged layer of an operating system, with direct access to memory, hardware, resource management, and storage – is vitally important for security products. It enables them to monitor ‘user-space’ – the non-privileged environment where applications run – and protect against malware that executes in that environment, even when it tries to evade detection. But kernel access also allows security products to counter more insidious threats within the kernel itself. As we’ve reported previously, for example, some threat actors use BYOVD (Bring Your Own Vulnerable Driver) attacks, or attempt to get their own malicious drivers cryptographically signed, in order to access kernel-space and take advantage of that elevated level of access.

However, from a security standpoint, working in kernel-space comes with its own risks. A wrong step in this environment – such as a bad update to a kernel driver – can cause outages. If the driver in question starts at boot time, when the operating system first loads, that can lead to prolonged impacts, potentially requiring affected hosts to be started in a recovery mode to mitigate the problem and allow the machines to boot normally.

Sophos’ Intercept X Advanced product uses five kernel drivers as of release 2024.2. All drivers are extensively tested* with applicable flags enabled and disabled, and shipped with new flags disabled. (Sophos Intercept X and Sophos Central use feature flags to gradually enable new features. Feature flags are deployed through Sophos Central. New features are typically ‘guarded’ by feature flags – turned off unless the flag is enabled – so that the feature can be rolled out gradually and potentially revised before wider enablement.)

In this article, in the interests of transparency, we’ll explore what those drivers are, what they do, when they start, how they’re signed, and what their inputs are. We’ll also explore some of the safeguards we put in place around these drivers to minimize the risk of disruption (such as staged rollouts, as mentioned above; we provide an example of this later in the article), and the options available to customers when it comes to configuring them. It’s also worth noting that Intercept X Advanced and all its components, including the kernel drivers, has been part of an external bug bounty program since December 14, 2017; we welcome scrutiny via external bug bounty submissions, and we foster a culture of collaboration with the research community.

* ‘Testing’ refers to a range of internal testing, including Microsoft-provided tools and verifiers

Overview

The following table provides an at-a-glance overview of the five kernel drivers which are part of Intercept X Advanced release 2024.2.

Table 1: An overview of the kernel drivers in Intercept X Advanced2024.2
* Microsoft Windows Early Launch Anti-malware Publisher
+ Microsoft Windows Hardware Compatibility Publisher

Figure 1: A conceptual depiction of user-space/kernel boundaries and where Intercept X Advanced components operate

SophosEL.sys

What it does: SophosEL.sys is the Sophos Early Launch Anti-Malware (ELAM) driver.

Inputs: This driver has one input – a blocklist of known-bad drivers which must be prevented from executing as boot start drivers at machine startup. This blocklist, located at the registry key below, is set by Sophos user-space threat detection logic when it detects a malicious driver. At the next boot cycle, SophosEL.sys ensures that this driver is not loaded.

Customer options: Customers can configure remediation and allowed items in the Threat Protection policy from Sophos Central.

Additional measures: Any Microsoft or Sophos-signed driver is exempt from cleanup/blocking.

SophosED.sys

What it does: SophosED.sys (Endpoint Defense) is a boot start driver, started during ELAM processing and before many other kernel drivers are loaded, Windows user-space is initialized, and the system drive is mounted. It has three broad responsibilities:

1. Providing tamper protection for the Sophos installation and configuration
2. Exposing system activity events to Sophos user-space components for protection and detection
3. Recording low-level system activity events to the Sophos Event Journals for after-the-fact forensics and analysis

Inputs: Since SophosED.sys starts before the filesystem is available, its entire configuration is provided through its service key. Note that all the below inputs are under HKLM\SYSTEM\CurrentControlSet\Services\Sophos Endpoint Defense.

Filter driver altitudes inputs

SophosED.sys registers with Windows as a Mini-Filter driver at multiple altitudes (a unique identifier that defines a driver’s position on the ‘stack’ of drivers, with ‘lower’ drivers being closer to bare metal) allocated and approved by Microsoft.

Tamper Protection inputs

Sophos Tamper Protection is configured by a combination of customer policies, Sophos feature flags, and signed manifests built into the agent.

* The configuration password is hashed with PBKDF2-SHA512 and a salt

System Activity Events inputs

The Sophos Central Threat Protection policy supports multiple configuration options, which Sophos user-space processes write to the SophosED.sys registry key, so that they’re available when the driver is loaded.

Event Journal inputs

Customer options: Customers can configure disk limits and manage exclusions in Sophos Central Threat Protection policy.

Additional measures: If a driver facility is available (based on a combination of Customer Policy plus Sophos flag), then Sophos user-space processes can configure various parameters at runtime:

• A bitmask of mitigations to apply per-process
• What events to enable or disable for each process
• The amount of time the driver should wait for a response from user-space (or whether it should be an asynchronous notification).

Sntp.sys

What it does: Sntp.sys (Sophos Network Threat Protection) is a kernel driver that registers for various Windows Filtering Platform events to intercept and potentially modify network flow data. Depending on features enabled by Sophos Central Threat Protection and Web Control policies, different filters and callouts are registered.

Inputs: Feature configuration is communicated to the driver from one or more of the following user mode processes:

• SophosNtpService.exe
• SophosNetFilter.exe
• SophosIPS.exe
• SSPService.exe

User-space processes communicate with the driver via the Windows Driver Framework, using IOCTLs, Read, and Write. Communications to and from the driver are protected, only accepting connections from authorized and authentic Sophos processes.

Customer options: The filter driver intercepts network traffic by browser and non-browser processes based on the policies defined in Sophos Central. Processing of the intercepted traffic is performed in user-space by SophosNetFilter.exe and SophosIPS.exe, which may send modified content back to the driver (for example, to display a block page for malicious content).

Additional measures: Customers can add individual sites to their allow or block list in Sophos Central.

Hmpalert.sys

What it does: Hmpalert.sys enforces Sophos CryptoGuard, which detects and prevents bulk encryption of files by ransomware. It also configures what exploit mitigations are enforced as processes are executed.

Inputs: Hmpalert.sys has a number of inputs, including several registry subkeys and IOCTLS.

Customer options: Customers can enable/disable exploit mitigations and manage exclusions in Sophos Central Threat Protection policy.

Additional measures: N/A

SophosZtnaTap.sys

What it does: SophosZtnaTap.sys is a Sophos-built OpenVPN TAP driver. If the customer deploys the Sophos Zero Trust Network Access (ZTNA) agent, the driver intercepts DNS lookups for managed applications, and redirects traffic for those applications to the applicable Sophos ZTNA gateways. ZTNA applications and gateways are configured through Sophos Central policies and stored in the registry.

Inputs: Inputs into SophosZtnaTap.sys are via a registry subkey.

Customer options: Customers can manage their ZTNA-protected applications and gateways from Sophos Central.

Additional measures: N/A

Gradual deployment example: CryptoGuard ExFAT

Sophos CryptoGuard has protected against bulk encryption on permanent disks for over a decade. Intercept X version 2024.1.1 introduced a new feature, CryptoGuard ExFAT, which extends this protection to ExFAT partitions (typically found on removable USB drives).

CryptoGuard ExFAT development and testing took place in September 2023 through March 2024. This feature was guarded by the flag ‘hmpa.cryptoguard-exfat.available.’

Sophos Engineering ran the software internally with the flag enabled (our ‘Dogfood release’) starting March 22, 2024.

Intercept X version 2024.1.1 was released to Sophos, then to customers using our gradual software deployment process, between May 21, 2024 through June 6, 2024. At this stage the feature was still dormant for everyone apart from Sophos engineers.

The ’hmpa.cryptoguard-exfat.available’ flag was enabled using our gradual flag enablement process, between June 10, 2024 through June 26, 2024.

Customer control

Customers can select a fixed software version (Endpoint Software Management: Fixed-term support, Long-term support). This locks the software and flags until the customer selects a different software package. Customers who use the ‘Sophos recommended’ option receive new software periodically. Aside from software rollouts, they also receive gradual feature-flag enablements for new features in the software, as with a normal software release. Sophos has evolved this process to improve stability and avoid enabling new events globally for all customers.

Conclusion

Kernel drivers are fundamental to the Intercept X Advanced product – and to robust Windows endpoint security, in general – but we also acknowledge that operating in kernel-space is not without its risks.

In this article, we’ve walked through the kernel drivers in Intercept X Advanced (as of release 2024.02), what they do, how they’re signed, what their inputs are, the control customers have over their management, and additional safeguards we’ve put in place – including gradual, phased rollouts of new features, and exemptions to minimize the risk of disruption.

While no safeguard can ever eliminate risk altogether, we wanted to share the details of our drivers in the interests of transparency, and to explain in depth how we approach the complex problem of trying to protect our customers from threats, in as safe a manner as possible.