During July 2017 a sample of a LockPoS variant was harvested by the Cyberbit Malware Harvesting lab which gathers thousands of malware samples every day from both public and internal repositories.

In our automated malware analysis lab, each malware is analyzed both dynamically and statically against publicly known anti-malware and antivirus tools and is run on a machine monitored by a Cyberbit EDR agent.

Our analysis lab also categorizes malware into groups of interest according to run results and the techniques used.

This specific LockPoS malware was automatically flagged as potential code injection by our system due to two main behaviors:

• Process enumeration was done from a suspicious process, followed by an open process to Explorer.exe.
• Explorer.exe performed several irregular operations which we will present later in this post.

Explorer.exe is the main Windows UI process that contains the start menu, taskbar, desktop and file manager. It is a Windows process that is run automatically at startup and remains an active process.

Every operation the user performs through the file manager is handled by this process. However, registry autorun changes are usually done by the specific applications or by regedit process in case it is a user that launches the registry editor application.

Since this sample caught our attention we opened the relevant alert in the Cyberbit EDR application.

LockPoS Malware Alert  – Cyberbit EDR

The malware alert screen above shows the initial indication of a malicious Explorer.exe. The malware indication is very clear since, in addition to the indication of potential code injection, you see Explorer.exe performing many irregular and suspicious operations such as registry auto-run, executable self-delete and deletion of files in the user folder.

In the screen below you can see Explorer.exe dropping a suspicious file into the C:\ProgramData folder. This folder is used to store program specific information which is shared among all users of this computer. On Windows XP, there was no C:\ProgramData folder. Instead, there was a “C:\Documents and Settings\All Users\Application Data” folder. Starting with Windows Vista, the All Users application data folder was moved to C:\ProgramData.

Malware authors love the C:\ProgramData Folder because it is hidden by default and access to this folder doesn’t raise any flags since it is being used by common applications.

Suspicious Behaviors Observed – Cyberbit EDR

As seen above, this file has a very high entropy value of 8.0 in the resource section, which is a strong indication of a packed file. Entropy relates to the amount of randomness in the data of the file. Entropy level above 7.0 indicates a packed/encrypted file.

Enough time has gone by that this file is now flagged by most AV vendors. So in this indication there is also strong threat intelligence indication of malicious activity. However, at the time of discovery there were very few indicators of compromise for this file.

The second indication is the fact that this dropped file was also added to the registry as run-key value under the HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run

Adding to this registry key generates persistence since the programs under the run key will be loaded upon logon of the relevant user.

This is one of the simplest ways to generate persistence and the easiest to discover. It was puzzling at first that the malware authors whom invested so much effort in the injection technique chose to generate such an easily discoverable persistence method.

However, upon closer analysis, we found an additional trick was used to mislead antivirus and next-generation AV products. The authors placed a non-visible character at the end of the string that generates backspace. This way when you read the string you end up with a file which is concatenated, and you fail to identify that this is an executable. Cyberbit EDR was not fooled by this trick because it disregarded non-graphical characters when searching for the run file on disk.

Event Insight – Executable to Registry – Cyberbit EDR

The third indication is the fact that the running process was deleted by Explorer.exe, a behavior we call self-deletion. Deletion of the original run file after the execution of this file is also an additional strong indication of malicious activity. Malware authors try to erase all traces of their malicious activity. Having a malicious file on disk which can be analyzed and flagged later on is risky, that is why they try to delete the files they are using.

Detecting that a file was run and then deleted by the process child is a tricky job since malware tends to generate a long trace of parent-child chain in which the original file is deleted by a great-great-grandchild of the original file to mislead detection products. Alternatively, they do so after injecting to a running process, and then use that process to delete the original file to break the parent-child relationship.

Executable Self-Delete – Cyberbit EDR Suspicious Behaviour Insight

Let’s examine the deleted file a bit further. This is the original LockPos.exe. This file is now flagged by most AV vendors so you can see the Threat Intelligence indication confidence is high (77). Cyberbit EDR allows the administrator to easily block this file which will remove the menace from other computers before they will be infected.

Blocking LockPoS.exe – Cyberbit EDR

After deletion of the original run file, the malware using the injected Explorer.exe tries to place hooks in the memory of a running process and search for the credit card data using memory scrapping of different processes.

DNS Request Event – Cyberbit EDR

Chronologically, what raised the first suspicious alert was a process enumeration call which went over all processes until it reached Explorer and then called open process to receive the process handle.

This handle was later used to perform the code injection.

Despite the malware stealthily performing its code injection without making any API calls, Cyberbit EDR behavioral analysis identified Explorer.exe performing a number of malicious operations and immediately generated this alert.

Explorer.exe Process Suspicious Behaviors

What is most interesting is that this malware did not use any Windows APIs to perform the injection. The malware injection is direct to the kernel, which means that endpoint security products that rely on hooks for detection, as well as products that rely on IoCs, will not identify this attack. This includes AVs, most next-generation AVs, and any EDR products which rely on IoCs for detection. The above analysis demonstrates how Cyberbit EDR used behavioral analysis to identify and correlate the preceding behaviors preparing for the injection, to detect a potential attack in progress, despite the new evasive tactics that were used.

Hod Gavriel, from Cyberbit’s Malware Research group, analyzed this malware and discovered that this sample utilizes a new stealthy technique to hide the code injection by directly calling the relevant kernel system calls without calling the Windows API. Read the full post at: /new-lockpos-malware-injection-technique/.

This analysis emphasizes the benefits of the heuristic behavioral approach over the signature or static based approach since in this case even a complex malware which uses an entirely new and stealthy injection technique is identified and the injection operation is exposed by the resulting operations.

About the Author
Meir Brown is Director of Research for EDR at Cyberbit, where he oversees the establishment and management of the malware research lab. Brown is a 15-year cybersecurity veteran. He began his career as a software developer and team leader at CheckPoint, culminating in taking leadership of the entire endpoint applications group.

Learn more about Cyberbit EDR Kernel-Based Endpoint Detection vs. Whitelisting