U.S.-based fashion retailer, Forever 21, recently reported that its POS (point of sSale) machines) were infected by LockPoS malware. We also saw LockPoS in the news in mid- 2017 for targeting Brazilian companies. This blog will share additional detail about some of the latest variants of LockPoS.
The malware has multiple levels of obfuscation. It often has an executable stored in encrypted form in a resource named “CORE”.
Fig 1 - “CORE” resource having encrypted biary
This resource is loaded into memory using FindResourceW(),sizeOfResource() and LoadResourceW().
Fig 2 - resource loaded in memory
The resource is then loaded into memory then decrypted using the Microsoft Cryptograpy APIs CryptAcquireContextW(),CryptImportKey(),CryptDecrypt().
Fig 3 - decrypted data from resource
The deobfuscation doesn’t end here. This data is again put in a compressed format and is uncompressed in memory using RtlDecompressBuffer(). The result is an executable that contains the string “dropper.pdb”.
Fig 4 - Dropper.pdb see in the decompressed file
This executable has yet another executable in an encrypted format in its resource section named “XXXX”. This is again decrypted and decompressed with the same process mentioned above. The decryption happens in memory and post-decryption the control is transferred to the decrypted code. This code further maps a part of its decrypted memory into explorer.exe where the final payload is decrypted.
The malware maps dlls into its own memory and calls the ntdll functions through it using CreateFileW(), createFileMappingW(), MapViewOfFile() APIs. This technique can bypass hooks created by sandboxes and makes it more difficult to spot the malicious behavior.
Fig 5 - map ntdll to memory
The malware, while injecting into explorer, does not call the windows APIs involved directly. Instead, it uses a system call using INT 2E to carry out the functionality. User mode API logging won’t work in this case. This is sometimes an extra overhead for malware reverse engineers.
The code injected into explorer.exe further decrypts the actual payload. The final payload is a dll that is responsible for POS malicious activities.
Fig 6 - The dll has a string named “lock.pdb”.
The dll has a string named “lock.pdb”. It also contains the Command and Control (CnC) server list hard coded in its resource section. It can be used as part of a Yara-type signature for this malware variant along with the strings “chrome.exe”,”_x/update.php”.
Fig 7 - url’s in resource section
The malicious dll searches for credit card patterns in memory.
Fig 8 - malware code looks for credit card patterns
After stealing the data, the malware sends it to its CnC server using HTTP POST method.The user agent used is “lock”, and can be easily detected by a Snort-type rule.