Updates for content and architecture of products: Sophos Endpoint
Expanding on our recent piece regarding the kernel drivers in Sophos Intercept X, in which we explored their testing methods and functionalities, we are extending transparency into the intrinsics of Intercept X – this time focusing on content updates that either involve changes in configuration leading to alterations in code execution paths or are code-based themselves.
Intercept X combines real-time Cloud lookups with on-device content updates. Given the constantly shifting and evolving threat landscape, it is imperative that on-device content updates are disseminated regularly (some data changes on devices may be less frequent but might necessitate swift updates). Nevertheless, there are associated risks; corrupted or invalid content updates can cause disruptions.
Sophos employs a standard mechanism for disseminating on-device content updates, which are injected into low-privileged Sophos user-space processes (rather than being loaded into or deciphered by Sophos kernel drivers) from Sophos’s Content Distribution Network (CDN). Content updates constitute one of the three primary elements of Intercept X, alongside software from the CDN and policies and configurations from Sophos Central.
In this article, we will delve into the various kinds of content updates we employ, how we authenticate and validate them, and how the ecosystem is structured to mitigate issues stemming from corrupt or flawed content. (As highlighted in our previous article, Intercept X (and all its constituents) has additionally been part of an external bug bounty program since December 14, 2017.)
It should be noted that the information presented in this article is accurate as of the current date (August 2024) but is subject to change as we continuously refine and enhance our solutions.
Sophos distributes new content updates to customers in ‘release groups.’ Each Sophos Central client is allocated to a specific release group.
The initial release group is designated for internal engineering assessment; no production clients are assigned to this group. This enables our engineering teams to examine new content updates on live infrastructure without necessitating any manual interventions. In case of unsuccessful testing, we halt the release before progressing to subsequent release groups.
If the engineering assessment is successful, we manually upgrade the release to the ‘Sophos internal’ release group (‘dogfooding’). This involves the production devices of Sophos employees, as well as their personal accounts. Once again, if issues are identified or reported, we cancel the release without proceeding further.
If all goes smoothly, we then manually move the release to public release groups. Subsequently, the Sophos release systems automatically disseminate the new content update to all release groups within a few hours or days as default (refer to Figure 1 below).
Figure 1: Progression stages of release, with verification inspections at each stage
Sophos AutoUpdate – a component of Intercept X – checks for new content updates every hour, although, in reality, the updates occur less frequently than that (see table below).
Sophos AutoUpdate retrieves each content update from the CDN and determines the availability of new content update packages for the corresponding release group.
Content updates are timestamped and validated using SHA-384 along with a private Sophos certificate chain. Sophos AutoUpdate authenticates the downloads it receives. If it identifies corrupt or untrustworthy updates, it discards them and notifies both Sophos and the Sophos Central administrator. Furthermore, to defend against obsolete CDN caches or malicious replay attacks, Sophos AutoUpdate rejects an otherwise legitimate update whose signature timestamp is older than the previously downloaded update.
If a new content update package is accessible, Sophos AutoUpdate retrieves and installs it through the relevant package installer. Different updates are managed by distinct components of Intercept X.
The subsequent content updates are incorporated in the most recent Intercept X release (2042.2).
Table 1: A summary of the content updates within the latest Intercept X release (2024.2)
Figure 2: A visual representation indicating which Sophos processes (depicted in navy blue) load which content updates (depicted in purple)
DataCompilationA
DataCompilationA is loaded by SophosFileScanner.exe, a process with restricted privileges and limited filesystem access (excluding its log folder and a temporary directory utilized for scanning large objects). It integrates the Sophos Anti-Virus Interface (SAVI).
Although named “SophosFileScanner.exe,” SophosFileScanner.exe primarily functions as the key content scanner in Intercept X, scanning files, process memory, network traffic, and more.
LocalRepData
LocalRepData comprises two reputation lists:
- Reputation by SHA-256
- Reputation by signer
Upon initiation of a Windows executable, Intercept X cross-references it in LocalRepData by its SHA-256 hash and its signature (assuming valid signing). If the reputation is available in LocalRepData, Intercept X assigns the process with the reputation (Sophos protocols treat high-reputation files and processes differently – for instance, exempting them from cleanup).
SSPService.exe utilizes LocalRepData to allot reputations as processes commence.
Additionally, SophosFileScanner.exe incorporates LocalRepData to assign reputations to embedded executable streams discovered in content other than executable files it executes.
Behavior
Behavior rules are integrated by SSPService.exe. These rule files encompass signed and encrypted Lua code. SSPService.exe validates, decrypts, and processes the rules into a restricted LuaJIT interpreter with access solely to internal Sophos APIs.
Lua serves as a swift, embedded scripting language. Sophosutilizes Lua to establish behavioral rules due to its adaptable nature for introducing new behavioral detections without necessitating a fresh software release, while concurrently upholding security measures. These rules are integrated into the user-space, eliminating the possibility of inducing critical system malfunctions if they malfunction. Furthermore, Sophos constructs its rules engine devoid of the Lua basic libraries, with the sole access to the system being through Sophos’ internal API, which is fortified against inadvertent misuse by the behavioral rules. Sophos gathers extensive telemetry regarding rule runtimes and consistently adjusts and diminishes the runtime overhead.
Rules act as reactors: Intercept X delivers numerous events, and rules enlist handlers for those events. In certain instances, rules can configure various aggregation parameters for specific high-volume events, allowing the sensor to merge or discard particular events.
Indicators
Indicators serve as the method through which Sophos progressively activates new functionalities in Intercept X. Indicators are deployed in two ways:
- The Indicators Supplement encompasses a fundamental set of indicators corresponding to the existing features in the software
- The Indicators Service represents a Sophos Central microservice enabling Sophos Release Engineers to set up indicators across various clients
The Indicators Supplement for a designated software release comprises a collection of feature indicators and how the feature is supposed to be enabled:
| Indicator Supplement Value | Indicator Service Value | Feature is… |
| Off | Ignored | Off |
| Available | Off | Off |
| Available | On | On |
This methodology equips Sophos with multiple pathways to enable and disable features.
- Sophos can introduce new features with the indicator “Available” (not enabled in the Indicators Service)
- Sophos can gradually enable new features by utilizing the Indicators Service to enable indicators across clients
- Sophos can deactivate a problematic feature by turning off the indicator in the Indicators Service
- Sophos can deactivate a problematic feature in a specific software release by altering the release’s Indicators Supplement.
Competitor Removal Tool
The Competitor Removal Tool (CRT) is equipped with a set of regulations for eliminating known-incompatible software during installation. It is automatically downloaded by the installer and eliminated post-installation.
Under normal circumstances, Intercept X does not employ the CRT; however, if a user installs a non-protection component such as Sophos Device Encryption and subsequently chooses to deploy Intercept X, the existing agent downloads, installs, and implements the CRT before installation. Once Intercept X is installed, the CRT is automatically uninstalled.
Endpoint Assistance Ruleset
The Endpoint Assistance (EA) rules encompass a series of standard expressions for specific log files. If Sophos engineers pinpoint a common root cause or misconfiguration, they may publish a new rule and link it back to the Knowledge Base Article (KBA) detailing the issue and proposed solution(s).
PlannedQueryPack
The planned query pack content update constitutes a roster of scheduled queries and their execution frequency. The rules are integrated by SophosOsquery.exe, with the output channeled through McsClient.exe for ingestion by the Sophos Central Data Lake.
SophosOsquery.exe contains an intrinsic watchdog that prevents excessive CPU or memory consumption from ‘runaway’ queries. Sophos gathers telemetry on the performance of scheduled queries and routinely fine-tunes and optimizes them to evade triggering the watchdog.
Remapper Regulations
The remapper regulations are integrated by McsAgent.exe and utilized to ‘remap’ Sophos Central policy configurations into the Endpoint setup, saved in the Windows registry under HKLMSOFTWARESophosManagementPolicy.
The policy is conveyed from Central as a repository of XML documents. The regulations also exist as XML documents delineating the structure of the data stored in the registry and presenting XPath queries plus a handful of conversion functions to extract content from the policy XML and produce registry data.
In the event that a regulation file is corrupted or fails during processing for any other reason, none of the registry values stipulated by that file are modified, and any prior settings remain unaffected. Processing of other valid regulation files follows a similar unaffected pattern.
EPIPS_data
The EPIPS_data content update incorporates intrusion prevention system (IPS) signatures loaded by SophosIPS.exe. SophosIPS.exe harbors a Sophos-developed IPS product, with the signatures representing IPS signatures published by SophosLabs.
SophosIPS.exe functions as a low-privilege process. When IPS is activated, the sntp.sys driver dispatches packets to SophosIPS.exe for filtering; SophosIPS.exe replies to the driver with commands to endorse or reject the packets.
Operating at the granular level of network flows packet-by-packet in the network stack demands meticulous attention. The Windows Filtering Platform (WFP) callouts at L2 are highly sensitive to the underlying drivers, often from third-parties, managing the physical and media access layers. Due to the considerable risk to system stability, the IPS feature monitors itself for BSODs or network disruptions likely triggered by interactions with third-party drivers. Upon detection, the IPS feature automatically deactivates itself and designates the endpoint’s health status as red to alert of the incompatibility.
NTP_OVERRIDES
One of the challenges when developing a Windows Filtering Platform (WFP) kernel driver is that while the platform is tailored for multiple drivers to interact with the filtering stack concurrently, Sophos has identified specific third-party software packages incompatible with the IPS feature, necessitating the ability to intercept and manage L2 packets.
The NTP_OVERRIDES content update accommodates a record of identified incompatible drivers. If IPS is mandated in policy but deployed on a device equipped with an incompatible driver, SophosNtpService.exe disables IPS, supplanting the policy.
This is propagated as a content update to enable dynamic responses from Sophos as new incompatible drivers come to light, safeguarding other clients with similar setups. Additionally, if Sophos or third-parties update drivers to address the compatibility issues, Sophos can exclude the driver from a specific version onwards.
RepairKit
Within every hourly update, Sophos AutoUpdate executes a self-repair program (su-repair.exe) to detect and rectify any reparable known anomalies. The RepairKit was initially crafted to pinpoint and rectify file corruption stemming from improper shutdowns that could jeopardize the Sophos installation. Over time, the Sophos engineering team has deployed this resource to address various issues that historically necessitated a support intervention from Sophos or could potentially remain unnoticed until a forthcoming software update highlighted the problem.
RepairKit directives are scripted in Lua and introduced by su-repair.exe. The directives are encrypted and authenticated. In cases where su-repair.exe falters to load the RepairKit directives, it resorts to a baked-in ‘last resort’ ruleset specifically focusing on rectifying issues within Sophos AutoUpdate.
RepairKit directives possess broad system access and operate as SYSTEM since they require the capability to rectify privileged keys and files.
TELEMSUP
This telemetry content update embeds a JSON document detailing the frequency and location for submitting telemetry:
{
"additionalHeaders": "x-amz-acl:bucket-owner-full-control",
"port": 0,
"resourceRoot": "prod",
"server": "t1.sophosupd.com",
"verb": "PUT",
"interval": 86400
}
The telemetryThe content update has remained unchanged since its inception in 2016.
APPFEED, USERAPPFEED
Updates for APPFEED content consist of Lua snippets that are signed and encrypted for the detection of installed applications and the dynamic generation of exclusions for them.
If an application is detected and the APPFEED contains exclusion rules, machine-specific exclusions are dynamically generated based on the detected application. These exclusions are then reported to Sophos Central for display to the administrator.
The rules have restricted access to the registry and filesystem, primarily working by scanning known apps in the Add/Remove Programs registry keys. Some applications, such as Microsoft SQL Server, require the execution of PowerShell scripts to identify optional OS components.
APPFEED and USERAPPFEED are loaded through an instance of SEDService.exe.
ProductRulesFeed
Product rules are loaded by SSPService.exe. These rules share the same format as Behavior rules, possessing similar access levels and privileges. Loaded into the LuaJIT interpreter, they offer essential functionality required by the Behavior rules.
ML models
The ML models content update includes various machine learning models loaded by SophosFileScanner.exe. In contrast to most updates, ML models contain Windows DLLs housing the core logic of the ML model, along with the ‘weights’ from training and tuning in SophosLabs Cloud.
These ML models are run by SophosFileScanner.exe within a low-privilege environment. The software supports loading two versions of each model: ‘telemetry’ and ‘live.’ This capability allows Sophos to test candidate ML models in telemetry mode, providing telemetry data for analysis and training purposes.
Sophos releases ML models as content updates to allow for several rounds of telemetry, retraining, and fine-tuning before promoting them to live models.
As the ML model update includes executable code, Sophos rolls it out gradually with additional quality assurance gates:
- Extended time in early release groups (engineering testing and Sophos Internal)
- Gradual release over weeks rather than hours
Hmpa_data
The Hmpa_data content update comprises a global allowlist of HitmanPro.Alert thumbprints, with each detection creating a unique thumbprint detailing relevant mitigation and detection-specific information.
Hmpa_data maintains a concise list of globally allowed thumbprints, used by the HitmanPro.Alert service hmpalertsvc.exe to suppress detections efficiently, lower false positives, and prevent performance or stability issues.
- The HitmanPro.Alert driver, hmpalert.sys, generates thumbprints and sends them to the service for driver-based mitigations such as CryptoGuard, CiGuard, PrivGuard, etc.
- The injectable Hook DLL for HitmanPro.Alert, hmpalert.dll, generates thumbprints for detections within user processes and forwards them to the service for reporting.
To keep up with evolving threats and safeguard against new risks, regular updates to security products are crucial. Ensuring that the updates are valid, signed, and verified is essential to prevent disruptions due to corrupt or faulty content updates.
In this overview, we’ve delved into the content updates used in Intercept X – discussing what they entail, their frequency of delivery, validation processes, the low-privileged environments they operate in, and the staged rollout mechanisms employed.
As mentioned in our previous article on Intercept X kernel drivers, managing the delicate balance between protection and safety is our commitment, with transparency at the core of our approach.
About Author
