Device policy: Memory Protection settings

When enabled, the

CylancePROTECT Desktop

agent detects various types of process calls that may be a threat and handles each type according to the options that you configure.

The violation type tables below provide more information about each violation type. For each violation type, you can configure the agent to respond with one of the following actions:

Ignore: The agent does not take any action.
Alert: The agent logs the violation and reports the incident to the management console.
Block: The agent logs the violation, reports the incident to the management console, and blocks the process call. The application that made the call is allowed to run.
Terminate: The agent logs the violation, reports the incident to the management console, blocks the process call, and terminates the application that made the call.

You can specify the relative path of the files that you want the

CylancePROTECT Desktop

agent to ignore when trying to detect memory protection threats. When you add a file to the exclusion list, you allow the file to be installed and run on devices that are assigned the policy.

When you add an exclusion, you specify the relative path of the file and the violation types that you want to ignore. On

Windows

devices, you can also specify the absolute file path. Use shortened relative paths with caution because they may exclude other executables that have the same relative path.

After applying the exclusion, all instances of that process must be terminated to stop the driver from injecting into it.

Windows

examples:

Relative path: \Application\Subfolder\application.exe
Absolute path: C:\Application\Subfolder\application.exe

Linux

examples:

Relative path: /opt/application/executable
Relative path for Dynamic Library files: /executable.dylib

macOS

examples:

Relative path without spaces: /Applications/SampleApplication.app/Contents/MacOS/executable
Relative path with spaces: /Applications/Sample Application.app/Contents/MacOS/executable
Relative path for Dynamic Library Files: /executable.dylib
You can also use wildcards for memory protection exclusions. For more information, see Wildcards in memory protection exclusions.

See the details below for using wildcards for executable or macro exclusions.

Enable this setting when you want to add an exclusion for a third-party DLL. For example, if you are running third-party security products in addition to

CylancePROTECT Desktop

for Windows, you can add an exclusion for the appropriate .dll files so that

CylancePROTECT

ignores specific violations for those products.

This feature supports the Malicious payload and System DLL overwrite violation types only. These violation types are supported for

Windows

devices only.

Note the following when you specify a DLL exclusion:

Devices must be running the
CylancePROTECT Desktop
agent for
Windows
version 3.1.1001 or later.
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, otherwise it will not be excluded.
For more information about supporting DLL exclusions, see KB 108909.

Enable this setting when you add a memory protection exclusion to select the violation categories and specific violation types that you want the

CylancePROTECT Desktop

agent to ignore.

When adding exclusions, if you want the policy to apply to memory protection violations only and not script control violations, specify at least one violation type that you want to ignore. If you do not select any violation types to ignore, a warning message appears and the exclusion will apply to both memory protection and script control policies.

Detects if the stack for a thread has been replaced with a different stack. Generally, the system only allocates a single stack for a thread. An attacker might use a different stack to control execution in a way that is not blocked by Data Execution Prevention (DEP).

Detects if the memory protection of a thread’s stack has been modified to enable execution permission. Stack memory should not be executable, so this can mean that an attacker is preparing to run malicious code stored in stack memory as part of an exploit, an attempt that would otherwise be blocked by Data Execution Prevention (DEP).

Detects if the code that resides in a process’s memory has been modified in a way that may indicate an attempt to bypass Data Execution Prevention (DEP).

Detects if a process is trying to read valid magnetic stripe track data from another process. Typically, this violation is associated with point of sale (POS) systems.

Detects shellcode and payloads that are associated with exploitation.

This violation type supports DLL exclusions.

Detects system calls made to an application or operating system.

Detects attempts to silently inject malicious code into other processes. This violation type cannot be blocked.

Detects attempts to overwrite a system DLL.

This violation type supports DLL exclusions.

Detects malicious code that has a reference to a Component Object Model (COM) object.

Detects if a process is injecting arbitrary code into a target process using an asynchronous procedure call (APC), or starting a remote thread to call LoadLibrary, or a similar function.

If the action is set to alert, you can expect to see alerts for both valid and malicious injections. The alert reports the application that received the injection, but you must determine the executable source that caused the alert. For more information, see KB 92422.

If the action is set to block or terminate, it prevents reported apps from running on the device even if they are valid.

Detects macros that contain dangerous implementations. Protects devices running agent version 2.1.1580 and later. Any memory protection exclusions are supported on agent version 3.0 and later.

Detects if a process allocates memory in another process. Most allocations occur only within the same process. This might indicate an attempt to inject code or data into another process to reinforce a malicious presence on a system.

Detects if a process introduces code or data into another process. This might indicate an attempt to execute code in another process and reinforce a malicious presence.

Detects if a process has modified memory in another process. This might indicate an attempt to store code or data in previously allocated memory, but it is possible that an attacker is trying to overwrite existing memory to divert execution for a malicious purpose.

Detects if a process has modified memory in another process to contain an executable image. This can indicate that an attacker is attempting to execute code without first writing that code to disk.

Detects if a process has modified executable memory in another process. Under normal conditions, executable memory is not modified, especially by another process. This can indicate an attempt to divert execution in another process.

Detects if a process has removed an executable from the memory of another process. This might indicate an intent to replace the executable image with a modified copy for the purpose of diverting execution.

Detects if a process has created a new thread in another process. A process’s threads are usually only created by that same process. This method can be used by an attacker to activate a malicious presence that has been injected into another process.

Detects if a process has diverted the execution of another process’s thread. An attacker can use this method to activate a malicious presence that has been injected into another process.

Detects if an environment variable has been set that will cause a shared library to be injected into a launched process. Attackers can modify the list of applications or replace applications with bash scripts that allow their modules to be loaded automatically when an application starts.

Detects if a new malicious process was started from a file that has not yet been written to the file system. The file write transaction is usually rolled back after the process starts (so that the malicious file is never committed to disk), and any attempt to scan the file on disk will only see the unmodified, benign file.

Detects an environment variable that might have malicious code attached to it.

Detects if memory belonging to the

Windows

Local Security Authority process has been accessed in a way that indicates an attempt to obtain user passwords.

Detects if a null page has been allocated. The memory region is typically reserved, but in certain circumstances it can be allocated. Attackers can use this to setup privilege escalation by taking advantage of some known null de-reference exploit, typically in the kernel.

Detects if a violating process has modified memory access permissions within another process. This is usually done to inject code into another process and make memory executable by modifying access permissions.

Detects if a violating process has created a child process and has modified memory access permissions in that child process.

Detects if an access token has been modified to allow a user to bypass security access controls.

Detects if a process has been set to run with a low integrity level.