Memory Injection Policies
Memory injection happens when external code executes within an authorized process. You can create a Memory Injection policy to protect against such an attack.
Reflective memory injection occurs when code that did not originate from an executable file or library on the local file system is executed within an authorized process running in memory. This is sometimes (though not always) the result of a malware attack. Because the code originates from outside the local file system, it bypasses the protection afforded by the endpoint’s whitelist and application control policies.
Ivanti Application Control provides a Memory Injection policy to handle this type of violation. The policy can operate in two modes:
- Enforcement mode shuts down the affected process once the violation is detected.
- Audit mode logs the violation without shutting down the process.
A Memory Injection policy operating in Enforcement mode provides ongoing protection against reflective memory injection attacks. But not every memory injection event is caused by malware. You can switch to Audit mode to investigate such events and to determine if the relevant file is safe or not.
Reflective memory injection is not the same as DLL injection. Both techniques involve external code executing within the memory space of a running process. In reflective memory injection, the external code originates outside the local file system. In DLL injection, the external code is in a DLL on the local file system.
Ivanti Application Control's Easy Lockdown and Supplementary Easy Lockdown/Auditor policies protect against unauthorized DLLs being loaded into a running process.
Memory Injection Scanning
Ivanti Application Control can scan running processes for reflective memory injection. There are two mechanisms for running the scan.
System Calls |
A scan is carried out whenever a process makes one of the following system calls:
|
Polling |
If a scan has not been initiated by any of the three system calls for five minutes, it is carried out automatically. |
The combination of these mechanisms provides continuous protection against reflective memory injection without affecting performance.
Excluding Files from Memory Injection Policies
Some files use memory injection as part of their normal operation. You can exclude these files from Memory Injection policies.
Ivanti Application Control can detect memory injection, but this is not always the result of a malicious attack. For example, dynamic languages such as Python and .NET may execute code in memory that did not originate from the file system. Application Control will correctly identify this as a reflective memory injection, but in this case it is not desirable to shut down the process.
You can avoid this by configuring the Memory Injection policy to exclude files/applications that use memory injection in their normal operation. You can identify these files/applications by initially running the policy in Audit mode.
Multiple Policy Resultant Value Rules
If an endpoint is assigned or inherits more than one Memory Injection Policy, some settings may conflict. Resultant value rules determine which settings prevail on the endpoint.
When multiple Memory Injection Policies are assigned to groups, an endpoint may inherit different and possibly conflicting, policy settings. Standard inheritance rules mean that the policy assigned closest
to the endpoint will prevail. However, if two policies are at the same parent level, or if two policies are assigned directly to the endpoint, the following rules determine which setting prevails.
Enforcement Settings |
The Enforce setting overrides the Audit only setting. |
Logging Settings |
Logging turned on overrides logging turned off. |
Exception Settings |
Exception settings are cumulative, so all files listed as exceptions in the different policies are treated as if in a single list. If the exception option is different for the same file name, the Log memory injection events option will override the Exclude from policy option. |