Memory Exploit Protection

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

1. STEP 1: Create Host Profile with Memory Exploit Protection Enabled. Click here for Host Profile Creation steps
   
2. STEP 2: Attacker Process Terminated – In cases where Protect mode is enabled, the attacker process is terminated when an attack is detected
3. 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 
4. 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-sensitive
   NOTE

   Regex-based Exclusions are not supported currently.
   1. Click Add to Exclusions on the incident
   2. Select whether the Profile or Global Exclusion List must be appended. Click LAUNCH EXCLUSION LIST
   3. The values are pre-populated. Click SAVE

Memory Exploit Protection Exclusion

An exclusion to the Memory Exploit Protection can be added as described below

1. Click Add Memory Exploit Protection Exclusion
   
2. In the pop-up window, add the process name and press Enter. One entry can be added at a time. Click SAVE
3. Based on the provided exclusion, MEP behavior can be defined as:
   1. If process names with extensions (Example:chrome.exe) are provided, MEP libraries are not injected into the specified processes
   2. 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
4. 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_cmd	Linux
   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

   
   

5. 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.dll
   C:\\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:

1. After the Probe installation, if the Kernel version is unsupported by MEP, a System Alert is generated
2. Navigate to the Probes page and select the required Probe. Memory Exploit Protection field is displayed as Unsupported
3. 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:

1. To verify whether a Kernel version is supported or not, access the required file on Artifactory
2. 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

3. Verification on LFR:
   1. The version number in the file vsysi_info.txt is updated to the latest version. The file is located under:
      1. Version 2.8 and Above: https://<LFR_IPAddress>:8443/vsp/vsysi/
      2. Version 2.7: http://<LFR_IPAddress>/vsp/vsysi/
   2. The file manifest.txtis updated with the required Kernel number. The file is located under:
      1. Version 2.8 and Above: https://<LFR_IPAddress>:8443/vsp/vsysi/<vsysi_Version>  
      2. For Version 2.7: http://<LFR_IPAddress>/vsp/vsysi/<vsysi_Version>
4. Restart the vsysi service using the command:

   service vsysi restart

5. Ensure that Memory Exploit Protection is enabled on CMS