(updated January 10, 2018)

Cyberbit malware researchers recently discovered a stealthy new malware injection technique being used by LockPoS that appears to be a new variant of that used by Flokibot. LockPoS is a Point-of-Sale (PoS) malware that steals credit card data from the memory of computers attached to point of sale credit card scanners. LockPos reads the memory of currently running processes on the system, searching for data that looks like credit card information and then sends them to the C&C. LockPoS is distributed from the same botnet used to distribute the Flokibot PoS and the code has some similarities.

LockPoS has a few stages of unpacking and decryption, but what is most interesting about it is its injection technique and the routines it uses for code injection. A similar malware injection technique was also present in Flokibot, but LockPoS uses different API calls for the injection.

One LockPoS malware injection technique involves creating a section object in the kernel using NtCreateSection, calling NtMapViewOfSection to map a view of that section into another process, copying code into that section and creating a remote thread  using NtCreateThreadEx or CreateRemoteThread to execute the mapped code.

Cyberbit EDR detects malware based on behavioral analysis, not signatures, so it is able to identify malware faster and close the ‘golden window’ of time it takes AV products to flag a malicious file and generate a signature which is then distributed to AV products.

The endpoint detection solution gathers and analyses data from a large number of sources and searches for suspicious behavior patterns. The behavioral information is triangulated and if a sufficient threat threshold is reached, an alert will be generated.

Cyberbit EDR generates malware alert based on analysis of multiple suspicious behavior patterns

Cyberbit EDR identifies the injected Explorer.exe file and additional suspicious behaviors which are related to the operations that happened after the injection, such as persistency through registry run-key and self-deletion of the original lockpos.exe file.

Analysis of Injected Explorer.exe – Cyberbit EDR

Due to the complex nature of this malware and its sophisticated injection technique, the original LockPoS.exe could not be identified as the injecting file. Nevertheless, Cyberbit EDR heuristically identified the Explorer.exe injection and generated an alert.

*Read a full analysis of How Cyberbit Researchers Discovered a New Silent LockPoS Malware Injection Technique 

LockPoS malware injection technique

ntdll.dll is a core dll file of the Windows operating system. It serves as kind of a gate from the user space to the kernel space. Routines from ntdll with the “Nt” prefix are part of the native Windows API.

When a routine from ntdll is called (e.g: NtCreateThreadEx), the appropriate hexadecimal value of its system call is copied to the EAX register. Then an appropriate instruction (int 0x2e or sysenter) is called to make the thread jump to the kernel mode. The kernel knows which routine from its SSDT to execute by the value in the EAX register. It copies the parameters from the user stack to the kernel stack and executes the routine. The system call values may differ from Windows versions and/or specific Windows updates.

LockPoS uses 3 main routines to inject code into a remote process:

• NtCreateSection
• NtMapViewOfSection
• NtCreateThreadEx

Silent malware injection avoids AV hooks

All these routines are exported from ntdll.dll. However, instead of calling them, it maps ntdll.dll from the disk to its own virtual address space. By mapping ntdll.dll from the disk, it maintains a “clean” copy of ntdll.dll, bypassing any hooks installed on it by anti-malware software:

Figure 1 – LockPoS maps ntdll.dll into its own address space

Then it allocates a buffer for saving the system call number:

Figure 2 – Using RtlAllocateHeap, LockPoS allocates a buffer for saving the system calls numbers. In this screenshot, the buffer is stored at 0x00327228 (see Dump 1 tab)

Then it searches for the routines it has interest in and copies the hexadecimal value from their “MOV EAX, HEX_VALUE” command to the buffer (figure 3). This HEX_VALUE of this command is the system call number.

Figure 3 – The command in the first purple rectangle is to check if the command starts with 0xB8 (starting byte of MOV EAX, HEX_VALUE). The second purple rectangle contains the command which copies the system call number to the previously allocated buffer. In this case, the system call number 0x54 of NtCreateSection is copied.

To execute each function by itself, it copies the value placed on the buffer to the EAX register, puts the appropriate parameters on the stack and lets its thread jump to the kernel mode using int 0x2e interrupt. The execution of this interrupt is similar to the execution of the sysenter command used by the native routines in the ntdll. They essentially do the same operation but with a bit of difference.

Figure 4 – A call to NtCreateSection  The value 0x54 is put into EAX register and the appropriate parameters are on the stack before the command “INT 2E” is executed. Notice the SectionPageProtection attribute: it is set to 0x40 (PAGE_EXECUTE_READWRITE). It hints that a code shall be executed from that section.

Figure 5 – A call to NtMapViewOfSection. 0xA8 is the system call value of NtMapViewOfSection routine. On the stack we can see the parameters of this routine. The ProcessHandle parameter is set to 0x80 – which is the handle the malware has for the explorer.exe process.

 Now it is ready to copy the malicious code to the section:

 Figure 6 – The malicious code is copied to the shared mapped section.

Finally, it creates a remote thread in explorer.exe to execute its malicious code:

Figure 7 – A call to NtCreateThreadEx. 0x58 is the system call value of NtCreateThreadEx routine. The 0x80 is the handle to explorer.exe process, as shown in figure 4.

Defending against ‘silent’ malware injection

This new malware injection technique suggests a new trend could be developing of using old sequences in a new way that makes detection difficult. Most EDR and next-gen antivirus products already monitor the Windows functions in user mode. But in Windows 10 the kernel space is still guarded so kernel functions can’t be monitored. For now, the best detection approach is to focus on improving memory analysis, which can be tricky, but these are the best traces currently accessible to security solutions.

Hod Gavriel is a malware analyst at Cyberbit.

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