- 25 Sep 2023
- 5 Minutes to read
- Print
- DarkLight
- PDF
Memory Exploit Protection
- Updated on 25 Sep 2023
- 5 Minutes to read
- Print
- DarkLight
- PDF
- This feature does not support SELinux or AppArmor in Enforcing mode
- Memory Exploit Protection on Windows can lead to system instability if another security product is enabled on the server. Refer to the article Working with Existing Security Solution and contact Virsec technical team for further guidance
Introduction
Memory Exploit Protection provides protection against two types of attacks: Memory Injection and OS Credential Dumping.
Memory Injection
Memory Injection or Cross-process injection gives attackers the ability to execute malicious code that masquerades as legitimate programs. With code injection, attackers do not use custom processes that can be detected quickly. Instead, they insert malicious code into common processes (e.g., explorer.exe, regsvr32.exe, svchost.exe, etc.), giving their operations an increased level of stealth and persistence.
Memory Exploit Protection protects against external code executing within an authorized process. It is deployed as a VSP-Host component during Probe installation on VMs (Virtual Machines). This feature can be enabled during the Host Profile creation.
OS Credentials Dumping on Windows using LSASS
In a typical attack kill chain, attackers often use the tactic of credential access as a precursor to accessing data assets and/or move laterally. A popular technique to achieve this is to dump OS credentials from memory. This involves an attempt to dump credentials to obtain account login and credentials in plain text, but mainly in the form of a hash from the critical operating system and other services. In the context of server protection, this technique is quite relevant for server workloads, since these systems usually have a non-named account that cannot be targeted via attacks like phishing (and its variants) that target users.
Dumping credentials from OS memory is a standard method for malicious actors to extract dump of OS credentials from critical OS services. These dumps can be analyzed locally or out of the band to extract hashes and get plaintext credentials.
One of the most critical services targeted on a Windows server is the Local Security Authority Subsystem Service (LSASS). The Windows system generates and stores various credential material in LSASS process memory. This memory can be dumped using multiple ways from the target host to extract credentials data.
This attack can involve the usage of sophisticated tools such as - Mimikatz to dump credentials from lsass.exe by targeting lsass.exe memory space and dumping memory. But, this can be executed by many "living off the land" utilities like Windows Task Manager, Process Explorer, etc.
MEP feature on the Virsec Security Platform adds the ability to protect against dumping of memory from the process lsass.exe. With Memory Exploit Protection enabled in the detect mode, VSP alerts the attempts to dump the memory of LSASS processes, whereas in the protect mode, these attempts are blocked and malicious actors will not succeed.
Workflow
Below are the steps involved in Memory Exploit Protection
- STEP 1: Create Host Profile with Memory Exploit Protection Enabled. Click here for Host Profile Creation steps
- STEP 2: Attacker Process Terminated – In cases where Protect mode is enabled, the attacker process is terminated when an attack is detected
- STEP 3: Incident Reported – For both Protect and Detect modes, whenever an attack is detected, an incident is generated with the type Memory Integrity. Navigate to Monitor > Incidents in the left navigation pane to view the incident
- Step 4: Add to Exclusion List (Optional) – If a process does not need monitoring, it can be added to the Exclusion list using the below steps. The complete file name must be added to the Exclusion list. It is also case-sensitiveNOTERegex-based Exclusions are not supported currently.
- Click Add to Exclusions on the incident
- Select whether the Profile or Global Exclusion List must be appended. Click LAUNCH EXCLUSION LIST
- The values are pre-populated. Click SAVE
Memory Exploit Protection Exclusion
An exclusion to the Memory Exploit Protection can be added as described below
- Click Add Memory Exploit Protection Exclusion
- In the pop-up window, add the process name and press Enter. One entry can be added at a time. Click SAVE
- Based on the provided exclusion, MEP behavior can be defined as:
- If process names with extensions (Example:chrome.exe) are provided, MEP libraries are not injected into the specified processes
- If processes are specified using full paths or regular expressions, MEP libraries are injected into the specified processes, but the generated incidents are not reported in CMS
- The rules for the RegEx patterns are provided below:
Goal RegEx RegEx Example Represented Path OS Match the beginning of a line ^ ^C:\\test\\path C:\test\path Windows Match the beginning of a line ^ ^/opt/virsec /opt/virsec/test Linux Match the end of a line $ tmp\\path$ C:\\tmp\\path Windows Match the end of a line $ test/path$ /tmp/test/path Linux Make an expression case insensitive (?i) (?i)c:\\tmp\\test.exe C:\\Tmp\\Test.exe, c:\\tmp\\TEST.exe Windows Make an expression case insensitive (?i) : (?i)test_app /tmp/Test_App/tmp/test_APP Linux Require at least 1 whitespace [ ]+ EncodedCommand[ ]+ powershell.exe -EncodedCommand abf2321e Windows Require at least 1 whitespace [ ]+ -c[ ]+ test_cmd bash -c test_cmd
bash -c test_cmdLinux Ignore arbitrary number of chars .* .*nativeImages.*.dll C:\\nativeImages\\test.dll, C:\\nativeImages\\test_123.dll Windows Ignore arbitrary number of chars .* /tmp/.*.so /tmp/test.so, /tmp/test123.so Linux Restrict a particular char to a known set [] [Cc]:\\test c:\\test\\app.exe, C:\\test\\app.exe Windows Restrict a particular char to a known set [] /opt/[vV]irsec /opt/virsec, /opt/Virsec Linux - The table below shows a few RegEx examples:
RegEx Examples Represented Files/ Directories Windows .:\\*test.*\\*tmp\\*.* C:\test-1\tmp\tmp-lib.dll
C:\test-2\tmp\tmp-lib-2.dll
D:\test-test\tmp\tmp-lib-3.dllC:\\ProgramData\\Amazon\\SSM\\*.* C:\ProgramData\Amazon\SSM\example.exe C:\\dir1\\tmp\\tmp-lib.dll Specific file: C:\dir1\tmp\tmp-lib.dll C:\\dir1\\dir2\\*.exe All the files with extension .exe in the directory: C:\dir1\dir2 C:\\dir1\\dir2\\* All the files in the directory: C:\dir1\dir2 Linux /opt/test/tmp.*/.* /opt/test/tmp-1/example
/opt/test/tmp-abc/example-2/var/packages/.*cache.*/.* /var/packages/pkg-cache/program-1
/var/packages/publisher-cache/program-2/opt/test/tmp-1/example.sh Specific file: /opt/test/tmp-1/example.sh /home/user/*.log All the files with extension .log in the directory: /home/user /home/user/log/* All the files in the directory: /home/user/log
Unsupported Linux Kernel Versions
All the latest Linux Kernel Versions are supported. Support for newer versions is also provided by an automated process. The list of the supported Kernel versions is available on Artifactory in JSON format: https://artifacts.virsec.work/ui/native/vsysi/vsp-vsysi-release-info.json
If MEP is not supported on a Linux Kernel version of the Probe, it is depicted on CMS in three locations:
- After the Probe installation, if the Kernel version is unsupported by MEP, a System Alert is generated
- Navigate to the Probes page and select the required Probe. Memory Exploit Protection field is displayed as Unsupported
- In the Host Monitoring page, select the required profile and click on Associated Hosts. The unsupported kernel version is indicated by the red dot depicted below. Hovering the mouse over the icon displays the error message. A click on it redirects the user to the System Alerts page
Refresh LFR for Kernel Support Updates
The support for any Kernel version can be checked. If the support is newly added, follow the process described below to include the Kernel support in the deployed environment:
- To verify whether a Kernel version is supported or not, access the required file on Artifactory
- Refresh LFR to obtain the required Kernel Support:
./update_lfr.sh --help # to view all parameters ./update_lfr.sh -Y <vsysi_version> #to refresh the required vsysi (Kernel Support) package
- Verification on LFR:
- The version number in the file vsysi_info.txt is updated to the latest version. The file is located under:
- Version 2.8 and Above: https://<LFR_IPAddress>:8443/vsp/vsysi/
- Version 2.7: http://<LFR_IPAddress>/vsp/vsysi/
- The file manifest.txtis updated with the required Kernel number. The file is located under:
- Version 2.8 and Above: https://<LFR_IPAddress>:8443/vsp/vsysi/<vsysi_Version>
- For Version 2.7: http://<LFR_IPAddress>/vsp/vsysi/<vsysi_Version>
- The version number in the file vsysi_info.txt is updated to the latest version. The file is located under:
- Restart the vsysi service using the command:
service vsysi restart
- Ensure that Memory Exploit Protection is enabled on CMS