Overview
A legitimate application may trigger a Memory Protection violation shown as an Exploit Attempt.
- This can occur when a legitimate application performs actions characteristic of malware, but is used for legitimate purposes.
- If needed, an exclusion can be configured to allow the application to continue to operate.
Viewing Exploit Attempts
Memory Exploit Alerts can be viewed via the Devices page of the Cylance console.
- If the Exploit Attempts column is not visible, access the button, "Table Columns", and select, "Exploit Attempts".

- Then you can see which devices have had Exploit Attempts alerted/blocked.
- Click on the desired device to view the Device Details for that device, then select “Exploit Attempts” to view the alerted processes for that device.
Important Values:
- Process Name includes the full path to the application
- Type displays the specific violation that was triggered
- Action displays the current ‘action’ taken when the violation was triggered

Exclusions for Exploit Attempts
After adding exclusions to all desired policies, be sure to delete the memory exploit alerts. This will aid in awareness of any new alerts that may need to be excluded in the preferred device policies.
Adding Exclusions
Adding an exclusion allows an application that is trusted to continue to function if the trusted application is being blocked due to a Memory violation.
Memory Protection in Protect version 2.1.1578 and newer provides the ability to create an exclusion for the exact cause of the violation. This allows the application to function while maintaining a secure platform.
Exclusions should be configured to only target specific violation types and actions. Creating an exclusion for an entire application can be risky and should not be done when it is possible to exclude a specific violation.
How to add an Exclusion:
Complete the following steps:
- Log in to the UES Console.
- Navigate to Policies | Device Policy.
- Open the desired Device Policy.
- Click on Memory Actions.
- Click the green Add Exclusion button.
- Enter the full (absolute path) for the process.
- This can be copied from the Process Path when viewing the Exploit Attempt(s).
- For example:
C:\Program Files\Common Files\microsoft shared\ClickToRun\OfficeClickToRun.exe - Optionally, provide a comment (for example, explain why the exclusion is being created or who has created it).
- Select the Ignore Specific Violation Types checkbox and select the specific violation that is being triggered. This can be determined from the Type column when viewing the Exploit Attempt(s).
- Save the Exclusion.
- Save the changes to your policy (blue SAVE button in the upper-right of the screen).

Wildcard Exclusions
The * wildcard can now be utilized in Memory Action exclusions, but it works a little differently from Script Control.
- When replacing folders in a path, use two “**” back to back.
- The entire folder should be replaced with the **.
- For example: C:\Users\**\example.exe
- Do NOT make a partial folder exclusion.
- For Example: C:\Users\**_admin\example.exe.
- When working with the filename portion of the exclusion, use a single *.
- For example: C:\Users\**\*.exe
Examples of correct wildcard exclusions for the following path: C:\Application\TestApp\MyApp\program.exe
- C:\Application\**\MyApp\program.exe
- Would exclude program.exe as long as program.exe is located under the MyApp child directory in C: drive.
- C:\Application\**\MyApp\*.exe
- Would exclude any .exe extension file as long as the executable is located under the MyApp child directory in C: drive.
- C:\Application\**\MyApp\*
- Would exclude any executable as long as the executable is located under the MyApp child directory in C: drive.
- C:\Application\TestApp\**\program.exe
- Would exclude program.exe as long as program.exe is located under any child directory that belongs to the TestApp parent directory in C: drive.
- **\Application\TestApp\MyApp\program.exe
- Would exclude program.exe as long as program.exe is located under \Application\TestApp\MyApp\ for any drive.
- **\Application\TestApp\MyApp\*.exe
- Would exclude any .exe extension file as long as the executable is located under \Application\TestApp\MyApp\ for any drive.
- **\Application\TestApp\MyApp\*
- Would exclude any executable as long as the executable is located under \Application\TestApp\MyApp\ for any drive.
Example of incorrect exclusions:
- C:\Application\TestA**.exe
- "**" is used for directories. Use a single asterisk "*" for executables.
- C:\Application\**
- "**" is used for directories. There is no single asterisk "*" specifying executables to exclude.
Not recommended exclusions:
- Technically Correct (but not recommended): C:\**\*
- Would effectively exclude anything in any directory (including child directories) under the C: drive.
- Technically Correct (but not recommended): **\*
- Would effectively exclude anything in any directory (including child directories) in any drive.
Exclusions for UNKNOWN Exploit Attempts
With CylancePROTECT agent versions 2.1.1580 and newer, an Exploit Attempt for <UNKNOWN>, with a violation type of Dangerous VBA Macro, is reported by the CylancePROTECT agent when it detects a macro script but is unable to determine the path that the macro script originated from.

- This can occur if:
- Third-party add-ons execute a Macro script before an office document opens.
- A Macro script is run outside of the confines of a document.
- A Macro script runs faster than a document can open.
- Memory Protection of Dangerous VBA Macro does not currently handle macro scripts that do not originate from office documents.
Examples of applications that load Visual Basic DLLs and run macro scripts natively are SOLIDWORKS and EMC Captiva. - These types of macro scripts will be blocked by default.
- The scenarios described above are not caused by the BlackBerry Protect Agent, as the Macro script or add-on would be from a third-party and potentially designed to function in that manner.
To Allow These Macros to run:
- Add the below Memory Action exclusion as specified.
- Make certain to check the box to Ignore Specific Violation Types, and select Dangerous VBA Macro.

Please Note: The Memory Protection exclusion for /<UNKNOWN> does open up a vulnerability to email based spear-phishing attacks.
- If only a specific device or group of devices need this exclusion, you may want to consider making a unique policy with this exclusion for just those devices.
If you would like to discuss some email security options please feel free to reach out to our Sales team (msssales@sonicwall.com).
DLL Exclusions
CylancePROTECT version 3.1.1001 for Windows allows administrators to create DLL exclusions in the Cylance console. Previously, administrators could only create exclusions for Memory Protection that applied to executables or folder paths. They can now exclude DLLs related to Malicious Payload and System DLL Overwrite memory protection violations.
The following rules apply when you specify a DLL exclusion: - The device must be running CylancePROTECT Desktop agent version 3.1.1001 or later on a Windows device.
- You must select the Treat as DLL exclusion option in the device policy.
- The file path that you specify must be the full, direct path to the .dll file. Wildcards are not allowed.
- The .dll file must be signed using a certificate that is trusted on the device where CylancePROTECT Desktop is installed. Otherwise, it will not be excluded.
Complete the following steps to create a DLL exclusion:
- Log in to the Cylance console.
- Navigate to Policies|Device Policy.
- Click an existing device policy. If necessary, filter the list of policies and search for a specific policy by name, if many of them have been created.
- Click Memory Actions.
- Click Memory Protection (if it is not already enabled).
- Click Add Exclusion.
- In the Add Exclusion window, provide the full path to the desired DLL in the Executable or Macro file field.
- Optionally, provide a comment (for example, explain why the exclusion is being created or who has created it).
- Click Treat as DLL exclusion. This opens an expanded view where administrators can configure which of two applicable violation types the exclusion applies to.
- The available options are Malicious Payload and System DLL Overwrite. All other violation types are not selectable in the window, as they do not apply to DLL exclusions.
- Click Save to commit the exclusion.
To Create a DLL Exclusion, specific information is required. To obtain the required information, these steps must be followed:
- Enable Verbose Logging.
- Enable Debug/Verbose Logging (sonicwall.com)
- Enable enhanced memory protection logging.
- This increased logging has the potential to adversely affect performance, so it should be used carefully. This feature is only intended to be enabled during troubleshooting to increase the usefulness of the data that is collected, and it must always be disabled immediately afterwards.
- Enable Enhanced Memory Protection Logging (sonicwall.com)
- Upload logs from the device that is experiencing the issue.
- In the management console, on the menu bar, click Assets| Devices.
- Click a device.
- To obtain the CylancePROTECT Desktop agent log file, under Threats & Activities, on the Agents Logs tab, click Upload Current Log File.
- When verbose logging for the CylancePROTECT agent is enabled and enhanced memory protection logging is also enabled, there are specific log lines that will be printed to the CylancePROTECT logs when memory protection violations occur. These log lines contain information about the DLLs that were involved in the memory protection violation. The full paths to the DLL(s) in question can be copied from these log lines and used in the DLL exclusion.

The Upload Current Log File option is available only if the device is online. The log upload may take a few minutes to complete but after the log has been uploaded, it will be displayed in the console and can be downloaded by clicking on its file name. Log files that have been uploaded to the Cylance console are retained for 30 days.
Deleting/Clearing Exploit Attempts
When viewing the Exploit Attempts from the Device Details page, you can delete the currently logged Exploit Attempt alerts. This will aid in awareness of any new alerts that may need to be excluded in the preferred device policies.
Use the Checkboxes on the left to select the desired alerts to delete, and then select the red DELETE button.
- If there are many Exploit Attempt alerts you can use the PROCESS NAME column to filter the list and delete only alerts that match what you are searching for.
- You can delete up to 200 Exploit Attempt alerts at a time, by viewing 200 items per page.
