New LockPoS Malware Injection Technique

By Hod Gavriel, Malware Analyst at Cyberbit

January 4, 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.

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

 LockPoS malware injection maps ntdll.dll 

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)

 LockPoS malware injection LockPoS allocates a buffer

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.

LockPoS malware injection copies the system call


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.

LockPoS malware injection technique call to NtCreateSection

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.

 LockPoS malware injection technique call to NtMapViewOfSection


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

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

LockPoS malware injection technique copies malicious code  

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.

LockPoS malware injection technique creates a remote thread

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.

Terms of Use | Copyright © 2002 - 2018 CONSTITUENTWORKS SM  CORPORATION. All rights reserved. | Privacy Statement