Anti-virus software plays an important role in cybersecurity. When employees fail to discover malicious activity on their workstations, anti-virus software is the next line of defense. However, no anti-virus software is 100 percent effective. Anti-virus solutions come with various security mechanisms, but what happens when attackers find a method to manipulate these security mechanisms for their own gain? This post details the steps an attacker can use to manipulate the scanning exceptions in Symantec Endpoint Protection (SEP) and discusses methods to prevent such an attack.
Scanning exceptions are a set of rules that specify trusted files, folders, or processes. Trusted items will not be scanned by SEP for viruses, making them a prime target for attackers. If an attacker is able to inject a rule into the scanning exceptions, he or she may be able to plant viruses on the system that will go undetected.
Before an attacker can change the scanning exceptions, he or she must first gain access to a workstation without being detected by anti-virus software or an employee sitting at the workstation. This may be done through social engineering, password guessing, or the exploitation of vulnerable software. Once the workstation has been compromised, the attacker must have administrative privileges on the workstation to modify the workstation’s registry settings.
Under normal circumstances, when creating a scanning exception in SEP, the rule would be saved in the computer’s registry. To go undetected, an attacker may use a command prompt to perform various tasks on the compromised workstation as opposed to using a graphical user interface. The command prompt allows the attacker to make modifications to the computer’s registry, and thus make changes to SEP exceptions without the need to restart the workstation. Here are the steps an attacker likely would follow to add a custom exception:
Note: The following registry paths may vary depending on the system’s architecture.
Once the exception has been made, the attacker will place the virus on the system in the specified file path. To do this, the attacker can create a share that provides access to the folder. The following steps detail how this can be accomplished:
Several techniques may be used to prevent such an attack, but the best approach is to layer multiple controls to better mitigate the attack. The following describes five methods that could be used to prevent the attack described in this post.
In the scenario described, the attacker requires access to modify the compromised system’s registry in order to silently create a new scanning exception. The system’s registry can only be modified by users who have administrative privileges over their workstation. In the Microsoft® Active Directory® interface, domain administrator accounts have administrative privileges over all workstations and servers in the domain. If possible, domain administrators should have two accounts: a privileged domain administrator account and an unprivileged domain user account. The unprivileged account is primarily used for day-to-day tasks. However, when an administrative function must be performed, the privileged account is available. This is done to prevent an attacker from gaining administrative privileges over either that workstation or the domain if a domain administrator’s workstation is compromised.
Additionally, workstations should be assessed to verify that domain users do not have local administrative privileges. The Microsoft PowerShell™ scripting language can be used to accomplish this by first obtaining a list of computers on the domain and then checking each computer for local administrator accounts.
When a legitimate scanning exception is made, the permissions on the file or folder that the exception is being made for should be investigated. If an attacker could delete a legitimate file and replace it with a malicious file, SEP would not be able to detect it. NTFS permissions should be configured to prevent any modification of these files. This can be done via Microsoft Group Policy (Computer Configuration > Windows Settings > Security Settings > File System) by selecting a file or folder and specifying the permissions on the folder.
Scanning exceptions should be focused on specific files or folders as opposed to a file extension. Creating an exception for a general file extension allows an attacker to create a malicious file with the same extension to avoid detection. In addition, folder exceptions should be made in the closest location to the files that the exception is made for. For example, if multiple files exist in the “C:\Temp\Exceptions\” folder, the “C:\Temp\Exceptions\” folder should have an exception, and not “C:\” or “C:\Temp\”.
The SEP client has a setting called “Tamper Protection” that, when enabled, will protect the portion of the system’s registry that stores the SEP settings. This will prevent users, administrators, and attackers from modifying the registry directly in order to create an exception. However, the action that SEP should be configured to take should include blocking attempts to tamper or shut down Symantec security software. If SEP is set to only log attempts to tamper with SEP settings, exceptions can still be made via the system’s registry.
The registry setting “HKLM\Software\Symantec\Symantec Endpoint Protection\AV\Exclusions\ClientRiskExceptions” reflects whether or not the SEP client is allowed to make custom scanning exceptions. Using the Symantec Endpoint Protection Manager (SEPM), this setting should be locked (with a value of 1 in the registry) to prevent changes from being made in the registry. This will force exceptions to be made by an administrator in the SEPM.
Layering the controls outlined here is the best way to prevent an attack on anti-virus software. Are your controls layered to mitigate an attack that creates a scanning exception in SEP in order to plant a virus? Let us know what you are doing to try to prevent this kind of attack.
Microsoft, Active Directory, and PowerShell are either registered trademarks or trademarks of Microsoft Corp. in the United States and/or other countries.
“Symantec Endpoint Protection – Few Registry Tweaks”
"How to Verify if an Endpoint Client Has Automatically Excluded an Application or Directory”
“How to Understand the File or Folder Exclusion in the Registry by Symantec Endpoint Protection”
“Getting Computer Names From AD Using PowerShell”
“Administrators and Powerusers on Remote Computers to Excel Sheet”
In accordance with applicable professional standards, some firm services may not be available to attest clients.
© 2017 Crowe Horwath LLP, an independent member of Crowe Horwath International.
As of June 1, 2016, the professionals of AbleBridge have joined Crowe Horwath LLP, a public accounting, consulting, and technology firm. We continue our focus on Microsoft Dynamics® CRM (now Dynamics 365) sales and implementation as well as innovative add-on products.
The personnel of SDGblue have joined Crowe Horwath LLP, a public accounting, consulting, and technology firm with a global risk consulting practice and offices around the world. This move provides SDGblue clients access to a broader range of products, services, and solutions, while expanding the Crowe cybersecurity risk management capabilities with a deeply specialized team.
Looking for the Client Login?
Access the SDGblue Client Portal