How Cyber Criminals Are Attacking
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.
What Are Scanning Exceptions?
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.
Prerequisites of Bypassing SEP
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.
Adding a Custom Exception
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.
- Test to determine if SEP is configured to allow the local software client to add scanning exceptions. This can be completed by querying the registry key HKLM\Software\Symantec\Symantec Endpoint Protection\AV\Exclusions\ClientRiskExceptions. The registry key should have a value of zero; if it does not, it must be changed.
- Query the remote system’s registry to ensure the “Client” registry key exists to store the custom file exception that will be created. This key can be found at HKLM\Software\Symantec\Symantec Endpoint Protection\AV\Exclusions\ScanningEngines\Filename\Client. In the event this registry hive does not exist, it should be created.
- Create the exception in the remote workstation’s “Client” registry hive. First create a new registry hive to include the exception configuration information. This hive must be named using a random nine digit number that does not already exist within that hive in the registry (for example, HKLM\Software\Symantec\Symantec Endpoint Protection\AV\Exclusions\ScanningEngines\Filename\Client\234567890).
- Create several keys inside the hive that will define the exception within SEP and allow the executable to be planted. For example, if we have GSECDUMP in C:\Temp, we need to create the following keys:
Planting the Virus
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:
- On the remote system, start sharing the folder that will contain the virus.
- Connect to the share from the local system using the credentials obtained for the compromised user account during social engineering, password guessing, or parsing the system’s memory.
- Copy the virus from the local system to the share. At this point, the virus is planted, and SEP will not scan the file for malicious activity. The virus may now be executed without detection.
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.
File and Folder Permissions
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.
Avoid Broad Scanning Exceptions
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\”.
Enable Tamper Protection
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.
Set the Lock
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.
What Are You Doing to Prevent an Attack?
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.