Advanced endpoint protection (AEP) products are responsible for detecting and preventing threats, as well as providing forensic-level reporting on security events. These products create barriers that can be difficult to evade. However, rather than finding a way around these barriers, an attacker might opt instead to break or remove the barriers entirely, which is why AEP products must implement safeguards that prevent tampering with the product itself.

This year, NSS Labs introduced an Anti-Tampering Protection category in our AEPv3.0 Test Methodology to evaluate the effectiveness of security measures designed to prevent tampering with key product capabilities, such as threat prevention. During this Anti-Tampering Protection testing, code-injection vulnerabilities were discovered. As a result, NSS completely withheld the anti-tampering results from the 2019 AEP Group Test publication on March 5 in order to give vendors time to remediate.

Common tamper protection techniques employed by AEP products include:

·       Restricting unauthorized access to or modification of product resources such as files, directories, registry keys, processes, and services. This type of protection is referred to by AEP products in various ways, including “self-protection,” “self-defense,” “tamper protection,” or “anti-tamper protection.”

·       Employing access controls such as a password, one-time authorization code, or other credentials for local product administration

·       Where possible, launching product services as anti-malware protected services on Microsoft Windows 8.1 and above to protect processes from code injection, process termination, and other attacks by admin processes

Twenty-one AEP products were deployed onto unpatched Windows 10 RS1 64-bit and Windows 7 SP1 32-bit virtual machines for the AEP v3.0 Group Test. The product policies were configured to reflect the “enterprise standard” or “default” protection policy for each AEP product. Anti-tampering protection tests were executed under the assumption that an attacker had obtained administrator privileges on a victim machine, which is a reasonable assumption given that fully privileged local users are commonplace in organizations and given that an attacker with low-privilege code execution can use a local privilege escalation exploit to acquire administrator privileges.

For each product, NSS first determined whether threat prevention functionality could be disabled using the following tamper methods (identified by tamper method number):

 1.     Disable protection via the product’s local policy management functionality, sometimes available within the endpoint UI, without using credentials.

2.     Terminate the product processes via the Windows API TerminateProcess function or stop the product services via the Windows API service functions.

3.     Uninstall the product via “Programs and Features” in the Windows Control Panel or by using an uninstaller
included with the product without using credentials.

An AEP product’s threat prevention functionality was considered disabled if NSS could successfully run a malicious payload that the product blocked prior to tampering.

NSS conducted more tests to determine whether code could be injected into one or more of the product’s processes using methods such as remote thread creation and insecure library loading.[1] Upon successful code-injection, NSS evaluated if the process that was injected into could access or modify AEP product resources that are normally inaccessible due to self-protection measures (e.g., modify contents of the installation directory, terminate product processes, and/or make registry modifications). NSS then also checked to see if threat prevention functionality could be disabled from within the process.

Our anti-tampering protection testing yielded the following results:

·       Some of the AEP products that did not prevent tamper methods 1, 2, or 3 would have prevented them if self-protection measures and/or anti-tamper passwords had been enabled by default. Be sure to confirm that your policy is configured to provide the level of protection expected.

·       NSS discovered a few anti-tampering measures that were only partially implemented. For example, one product required a password during uninstallation using “Programs and Features” in the Windows Control Panel but not during uninstallation using an included uninstaller.

·       Less than half of the AEP products launched one of their services as an anti-malware protected service, and of the few that did, most were designed in a way that made it unnecessary to tamper with those designated protected service(s) in order to disable threat prevention.

·       On Windows 10, almost all (18 out of 21) AEP products were found to be vulnerable to some form of code-injection, in each case leading to the disabling of their threat prevention functionality.

·       The three vendors that were not vulnerable to code injection tampering techniques on Windows 10 were also tested on Windows 7, where the techniques were found to be successful. In these cases, vendors responded that this is due to a deficiency in the operating system rather than an issue with the product itself.

In the interests of responsible disclosure of the code-injection vulnerabilities discovered, vendors were notified with detailed instructions on how to reproduce discovered issues, and given at least 90 days to remediate prior to public disclosure. Figure 1 summarizes all vendor responses and outcomes: