Final-Connect-Image.jpg

Unusual Forms of Persistence - Endpoint Security

Posted by Madeline Lee   |   March 29, 2018

By Micah Graf, Security Researcher at CounterTack

Most forms of malware today attempt to gain persistence prior to performing its main goal (e.g. mine cryptocurrency, steal data, surveil the end user, etc). Persistence is important for APTs and commodity malware attack, in order to establish a reliable foothold on the endpoint security (and survive system reboots). As malware attack evolves and becomes stealthier, so have the methods used by malware to maintain persistence. Maintaining persistence used to be adding the attacker's malicious executable to the Run registry key, add the executable to the Startup folder, or create a scheduled task; however, now that more SOC analysts and endpoint security tools know to look at these common places, malware attack has started using alternative methods to avoid detection. As new persistence methods come to light, there seems to be a trade off between reliability and complexity; malware authors also seem to be getting smarter, and have started using multiple forms of persistence in case one of the forms is broken or removed by AV.

1) Sticky Keys:

This method of persistence is very useful because it creates a persistent backdoor on an endpoint, giving the attacker an unauthenticated command prompt with SYSTEM level privileges. By modifying this registry key the attacker can RDP into the endpoint security, trigger the sticky keys function and instead running the actual sticky keys executable (sethc.exe) the system instead launches the value provided in the data value (in this case cmd.exe). The caveats for this form of persistence, requires the endpoint’s firewall to allow incoming RDP connections, and there isn’t a network firewall blocking the RDP connection between the attacker and the endpoint. For these reasons, this type of backdoor is best used once the attacker already has a foothold on the network. This allows them to access the endpoint security without having to place a malicious executable on the machine, or use any obvious forms of persistence like the Run registry key or Startup folder. This method also assumes the attacker has administrative privileges to make the registry key modification; however, this method makes for a great backup if their initial foothold on the endpoint is lost. This method can also be done using other processes like utilman.exe, osk.exe, etc. under the same Image File Execution Options Registry Key and Debugger Registry Value. Another version of this persistence method is to simply overwrite the actual executable files (i.e. sethc.exe or utilman.exe) with the command prompt executable.

endpoint security

malware attack

malware attack

 

 

 2) A Random File Extension & Handler:

This method is more complex than the last and requires a number of registry modifications and features many redirects. This method has been used by the Kovter variant (known as a form of “file-less” malware), and first requires the malware attack to register a bogus file extension under HKEY_Classes_Root\ (e.g. HKEY_Classes_Root\.e653f); next you specify a handler (e.g. cb98) in the Data portion for “(Default)” in the new extension key.

endpoint security

Next the handler must be created, which also falls under the HKEY_Classes_Root (e.g. HKEY_Classes_Root\cb98) and can again be a random set of characters but must match the value entered in the Data field above. Next the shell, open, and command sub keys must be created (e.g. e.g. HKEY_Classes_Root\cb98\shell\open\command) and then the actual command value will be placed in the Data field for “(Default)” in the command sub key (shown below).

malware attack

 From there the mshta process is created from the command above and is used to run the subsequent malicious javascript. The malicious javascript is used to obtain the real encrypted payload from yet another registry key as we can see from the “RegRead” and random registry key listed in the Javascript (shown above). If we look at the registry key that is read by mshta.exe (shown below) we can see a few registry values that are encrypted chunks of data, along with what looks like a User Agent. Going back to the Kovter variant, this makes sense since Kovter is used to perform click-fraud (hence the User Agent). Once the payload is deobfuscated and ran, mshta.exe spawns PowerShell which the injects itself into regsvr32.exe, regsvr32.exe process is then seen carrying out malicious HTTP Post requests with the User Agent from the registry key.

EDR

Wrapping this method up, we still have to launch a file that has the bogus file extension whenever the computer starts up or whenever the user logs on to the endpoint; to do this Kovter creates a link file in the User’s startup folder, this link file redirects to an empty file containing the bogus file extension located in the User’s AppData Roaming folder (link file shown below). To simplify this method, the attacker could modify commonly used file extensions (e.g. HKEY_CLASSES_ROOT\.txt), put the payload within the handler, and rely on the end user to regularly open that type of file whenever they are using the endpoint (thus the file with the bogus file extension, and the link file in the User’s Startup folder is no longer required).

EDR

endpoint security

EDR

3) DLL search order hijacking:

The next form of persistence is pretty easy compared to the last method, it relies on the way DLL’s are loaded by programs in Windows OS. Typically, when a program goes to load a DLL, it first looks in the local directory before looking in the legitimate directory where the DLL is stored by default. Instead of overwriting the legitimate DLL file with a malicious DLL, the malware attack can instead of place a malicious DLL with the same name in the working directory of the program; when the program is launched, the process looks in the local directory first, loads the malicious DLL, and completely ignores the legitimate DLL located in the default directory. In the example shown below, the Prikormka dropper variant saves a malicious DLL (typically loaded by explorer.exe when the host starts up) to C:\Windows\ntshrui.dll, while the legitimate DLL is stored in C:\Windows\System32\ntshrui.dll. Everytime the endpoint starts up, explorer.exe is launched and loads the malicious DLL from the Windows directory (since explorer.exe is located in the Windows directory).

EDR

4) Microsoft Office Template Macros:

This next method makes use of malicious office macros to maintain persistence instead of using them for the initial infection. When a user opens winword.exe application, they are given options for the type of document they want to create; these options are based on word documents (known as templates) that are saved as files on the endpoint in \Users\user\AppData\Roaming\Microsoft\Templates directory. In order to gain persistence, the attacker can add their malicious VBA macro into one of these template documents (e.g. normal.dotm shown below). This way anytime the user opens word, the malicious macro is run.

malware security

malware security

endpoint security

However, Microsoft Office typically has macros disabled or require the user to click a button to run the macro, by default. In order to circumvent this security, measure the malware attacker can simply modify the “VBAWarnings” registry value for the Security registry key, and set it to 1; this means that the macro automatically runs the second the word application is opened. A variation of this attack is to simply add the malicious macro to an existing document that is frequently used by the end user, thus whenever the user opens that document the backdoor is re-established.

EDR

advanced threat

5) The Screensaver:

This next method requires some registry key modifications (depending on the current environment configuration) and using an executable file saved with a “.scr” file extension. First the attacker saves their malicious backdoor executable file to C:\Windows\System32, with a “.scr” (theoretically they could save their executable to a different directory, but this is the default directory for screensaver files). Once the “.scr” file is in place, next the attacker has to enable the screensaver on the endpoint (if it isn’t already enabled) and point the screensaver to use their malicious “.scr” file. This is done by changing the data value for “SCRNSAVE.EXE” to the backing file path for their malicious “.scr” file. Next they can enable the screensaver and change screensaver timeout by modifying the registry data for “ScreenSaveActive” and “ScreenSaveTimeOut” registry values. Once this is completed, anytime the user leaves their desktop unattended for the specified amount of time, the screensaver function automatically kicks in and executes the attackers malicious “.scr” file. Variations of this method can be to overwrite one of the existing default screensavers that come with Windows with their malicious executable file, or they can save their malicious “.scr” file to a hidden directory, and simply point SCRNSAVE.exe registry value to the “.scr” file in the hidden directory.

micah 16

micah 17

 

 

About Micah Graf:  Micah attended DePaul University where he earned Bachelor's and Master's degrees in Computer, Information, and Network Security. Micah has spent over 5 years  working in small to large SOCs as a security analyst, performing digital forensics and incident response.

micah photo

Topics: malware, cybersecurity, endpoint security, CounterTack, persistence

Subscribe to Email Updates

Recent Posts

Posts by Topic

see all