At our dayjobs, as reverse engineers at CBTS, Jeremy and I have been hunting new POS malware.
A new sample appeared on Virustotal this week that had a very interesting name “lusypos.exe”. There have been very few references to this particular family and it appears to be fairly new. Google searching was able to give me the following information:
The sample that I’ll be talking about in this post is bc7bf2584e3b039155265642268c94c7.
At the time of this writing the malware is currently flagged on Virustotal by 7/54 engines.
Interestingly, some of the signatures seem to be hitting on the copy of tor.exe that is in the bundle.
This malware clocks in around 4.0 MB in size, so it’s not small. For comparison, getmypass POS malware was 17k in size.
The first thing of note when executing this in a sandbox is that this malware drops a copy of tor.exe, libcurl.dll, and zlib1.dll. It also copies itself to the %APPDATA% directory on the victim host. The following are the locations and MD5’s of the dropped files are below:
The file mbambservice.exe is the copy of tor.exe
d0f3b3aaa109a1ea8978c83d23055eb1 C:\Documents and Settings\<USER>\Application Data\VeriFone32\libcurl.dll 4407393c1542782bac2ba9d017f27dc9 C:\Documents and Settings\<USER>\Application Data\VeriFone32\mbambservice.exe bc7bf2584e3b039155265642268c94c7 C:\Documents and Settings\<USER>\Application Data\VeriFone32\verifone32.exe b8a9e91134e7c89440a0f95470d5e47b C:\Documents and Settings\<USER>\Application Data\VeriFone32\zlib1.dll
The malware will also create the mutex “prowin32Mutex” and injects code into iexplore.exe. This was a strange mix of dexter-like behavior mixed with Chewbacca-like techniques.
While running in a sandbox, the malware communicated out to
220.127.116.11 18.104.22.168 22.214.171.124 126.96.36.199 188.8.131.52
Now let’s get to the good stuff.
The malware has an interesting method of decoding strings that are statically defined in the binary.
For the non-asm folks on here, the malware is using a lookup table with structures containing a one byte xor key, pointer to the string, and length of the string. It will perform an additional xor operation at the end.
A decoder for this is written (in python below)
Which when executed will decode the following strings:
http://kcdjqxk4jjwzjopq.onion/d/gw.php http://ydoapqgxeqmvsugz.onion/d/gw.php VeriFone32 verifone32 prowin32Mutex b00n v1.1 \\Internet Explorer\\iexplore.exe mbambservice.exe tor.exe zlib1.dll libcurl.dll Software\\Microsoft\\Windows\\CurrentVersion\\Policies\\Associations Software\\Microsoft\\Windows\\CurrentVersion\\Internet Settings\\Zones\\0 LowRiskFileTypes Content-Type: application/x-www-form-urlencoded 127.0.0.1:9050 Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; WOW64; Trident/6.0) g00n curl_easy_init curl_easy_setopt curl_easy_cleanup curl_easy_perform curl_easy_strerror curl_slist_append curl_easy_getinfo curl_slist_free_all page= &ump= &ks= &opt= &unm= &cnm= &view= &spec= &query= &val= &var= DetectShutdownClass download- update- checkin: scanin: uninstall response= UpdateMutex: Software\\Verifone32 Software\\Microsoft\\Windows\\CurrentVersion\\Run .DEFAULT\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run mbambservice.exe wmiprvse.exe LogonUI.exe svchost.exe iexplore.exe explorer.exe System smss.exe csrss.exe winlogon.exe lsass.exe spoolsv.exe alg.exe wuauclt.exe firefox.exe chrome.exe devenv.exe
This contains the C2 information, along with a process whitelist, and registry keys for persistence. One thing to note based on these strings, is that it looks like the malware may have taken a cue from dexter.
RAM scraping is performed through the common sequence of using CreateToolhelp32Snapshot, then using Process32First and Process32Next to iterate. Pseudocode for that would look something like the following:
handle = CreateToolhelp32Snapshot Process32First(handle) do sleep 1000 OpenProcess VirtualQueryEx ReadProcessMemory CloseHandle Sleep 5000 while Process32Next
This technique is not new and is commonly used in many different POS Ram scrapers. Truth is, that without writing a driver, the malware authors often have their hands tied and only have a few techniques to peer into process memory space.
The malware also contains methods to search memory for sequences of data that look like credit card track information.
Once it finds that data, there are checks against the potential credit card number to determine if it is Luhn valid. Luhn’s algorithm is the defacto algorithm for validating credit card numbers. It can be seen implemented in the malware using a lookup table rather than calcuating the digital root. One note, is that this is the same implementation of Luhn’s as FrameworkPOS, Dexter, and getmypass.
When looking into malware families like Chewbacca and now LusyPOS, one thought comes to mind. Why would a POS machine be allowed to talk to tor? Most PCI audits will attempt to lock this sort of activity down, but there seems to be devils in the implementation that allow malware like this to be successful.
This is just a scratch in the surface of a new malware family. We’ll be curious to watch it evolve over the next couple years and track its progress.