Another Brick in the FrameworkPoS

Introduction

FrameworkPoS is a well-documented family of malware that targets Point of Sale (PoS) systems and has been attributed to at least one high profile retail breach. The malware author(s) have continued to improve upon the original malware, releasing several versions since it was first discovered. In a recent investigation Trustwave discovered a new variant of FrameworkPoS. The new variant uses two PowerShell scripts for execution and a new obfuscation method for exfiltration of Card Holder Data (CHD). As always, it is important to provide details and resources to aid the community in protection and detection of emerging threats.

Powering the Malware

As operating systems change, malware authors adapt with them. PowerShell has been around since 2006, but wasn't installed by default on Windows XP. With the end of life occurring a few years ago for that operating system, the adoption of Windows 7 has increased. Windows 7 and its successors have PowerShell enabled by default and provide a powerful interface into the system from the command line and PowerShell scripts.

Previous versions of FrameworkPoS were installed as a service in an attempt to hide and persist on victim systems. This version uses two PowerShell scripts, which can inject either a 32-bit or 64-bit version of the malware into memory. The first script simply executes the second script. This is because the second script is taken almost directly from a publicly available set of scripts called PowerSploit. As described on their website, " PowerSploit is a collection of Microsoft PowerShell modules that can be used to aid penetration testers during all phases of an assessment."

In this case the attacker slightly modified the injection abilities of a PowerSploit script and used it to base64 encode both 32-bit and 64-bit versions of FrameworkPoS and inject them into memory. This makes the malware more difficult to detect since the binaries are never written to disk. As more environments move to Windows 7 and newer operating systems, it is likely that we will see an increase in the use of PowerShell to execute malware. PowerShell allows powerful access to the system and is present by default on the Windows operating system.

Inside FrameworkPoS

Like a lot of malware, FrameworkPoS starts out by creating a mutex "m_number3". This is used to prevent multiple copies of the malware simultaneously running on the system. When the malware starts it checks to see if the mutex exists already and exits if it does. FrameworkPoS also looks for a file called "ldr.mem" and reads it in if it exists, however the data is never used. A second mutex is created: "MuTeX-Check" but never accessed by anything else in the binary. The malware collects system-identifying information in the form of hostname and IP address, encodes it, and stores it for later use.

Encoding

The encoding is a custom encoding technique involving a substitution cipher and XOR key. The first array contains a slightly jumbled set of these characters: [A-Za-z0-9=^/.;]:

^=/0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklm;no.pqrstuvwxyz

The character to be encoded is looked up in this array and the index of where it is in the array is stored. This index is used to select a character from the second array:

ILMxgTnvbzVtBiry3=X^KWQAG847oYdFZlR1NPe5j/mS0hODs.aU2qkCJ6H;wcu9fpE

For example the number 9 is at index 12 in the first array. The character B would be selected from the second array. This character is then XOR'd with 0xAA and added to the string. B (0x42 ^ 0xAA = 0xE8) becomes part of the exfiltration string as e8. To make this easier I've written a python script to decrypt either a string or a file. The binary also contains several obfuscated strings that are simply XOR'd with 0x4D.

Memory Scraping

Many variants of FrameworkPoS use a blacklist to prevent wasting computer cycles and limit false positives in applications that are unlikely to contain credit card information. This variant was no different using the following black list:

• smss.exe
• csrss.exe
• wininit.exe
• services.exe
• lsass.exe
• svchost.exe
• winlogon.exe
• sched.exe
• spoolsv.exe
• System
• conhost.exe
• ctfmon.exe
• wmiprvse.exe
• mdm.exe
• taskmgr.exe
• explorer.exe
• RegSrvc.exe
• firefox.exe
• chrome.exe

The credit card hunting algorithm for FrameworkPoS is similar to other variants of the family, capturing both track 1 and track 2 data and verifying the numbers using the Luhn algorithm. The verified numbers are encoded with the method discussed in the previous section.

Exfiltration?

The encoded system information and CHD is compiled into a dot notation.

As you can see this decoded into (these card numbers are from a fake track generator application):

The encoded information is written to a dump file at the hardcoded location:

%WINDIR%\Temp\Perflib_Perfdata_f44.dat

Previous versions would append a DNS name to the end and perform a DNS request to get the information back to the C&C server. This variant did not have any code for performing the exfiltration. It is possible that another piece exists or that the attacker was manually grabbing the dump files from victim systems. The malware sleeps for ten seconds and continues to scrape CHD.

WTF Mate?

FrameworkPoS has never been accused of being sophisticated. The malware is known for XORing strings with 0x4D to obfuscate them in the binary. However, previous versions had the clear-text strings in the binary, then XOR'd them with 0x4D only to immediately XOR them again with 0x4D. Even more inexplicable is that two FrameworkPoS variants look for a specific hardcoded credit card number. Each time a credit card number is found in memory, it is checked against the hard coded number. If there is a match, a special "notice" line is added to the exfiltration file along with the name of the application the number was found in. The notice follows this format:

IP.Hostname.notice.name_of_application

We have communicated with the appropriate authorities about the number contained in the samples. This is the first time I've ever heard of a malware author targeting specific credit card number, especially when they already have all the information needed to commit fraud on the card. It is unclear the purpose of this mechanism.

This variant has a very Frankenstein feel to it. As if segments of code from other variants and malware families are added without removing dead code. The malware contained pieces of several techniques that were never fully developed. For instance, the variant opened up a file and never used what it read in, WSAStartup was performed but no network traffic occurred, and a mutex name was registered but never checked. The malware also contained timing intervals used in previous versions to control exfiltration, but did not do any automated exfiltration.

Conclusion

FrameworkPoS has never been the most sophisticated malware on the market, but it has been effective. It is responsible for at least one major breach and several variants have been released since its inception. Using techniques like PowerShell injection and DNS exfiltration have contributed to successful campaigns for the malware author. Our goal with this blog is to expose techniques employed by this recent FrameworkPoS variant, and to raise awareness about upcoming malware trends. The first step in protecting yourself is to understand the threat itself. We have publicly released a decoding script to help the security community dissect and quickly understand how this point of sale malware attempts to hide and exfiltrate its targeted CHD data. Let's keep the upcoming Holiday season safe for everyone!