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.

Technical Analysis

Md5:1e490056bdb537f9492bc72a365537f0

sha1:80c1bd8611d37d10650b7b1a8b90274e6fe54419

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.

Sandbox Evasion

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.