PinkKite: The continuing threat of POS malware
PinkKite: The continuing threat of POS malware
Point-of-Sale, or POS, systems are often targeted by cyber-criminals due to the high return on investment for success, potentially thousands of credit card numbers and details.  Unlike many other devices targeted by criminals, POS systems are semi-unique in that they are often dedicated devices with limited resources and run specialised, and frequently non-upgradable software.  The combination of both the asset value and uniqueness tend to have POS related attacks grouped into their own category.  For statistical and tracking purposes, this level of sub-classification can be very useful, but when considering defence against POS targeting attacks, security professionals are able to fall back on the common principle of “defence in depth” to ensure proper robustness exists to identify and defeat even specialised attacks aimed at POS devices.  

The Kroll Cyber Security team recently identified a POS targeting malware named PinkKite, which was associated with a currently unreleased breach.  The analysis of PinkKite gives insight into how “defence in depth” would have provided ample opportunity to detect and mitigate almost every aspect of the threat, prior to a breach.  The details provided by Kroll, allowed us to walk through the attack and discuss detection methods or mitigating factors which could be applied to both prevent PinkKite, as well as identify other POS malware variants. 

PinkKite malware

The initial compromise and subsequent loading of PinkKite onto POS systems was based on common techniques for exploiting organisations.  While the initial vector is unknown, once within the organisation, attackers were able to extract credentials from compromised systems and to move laterally until they reached the POS network.  In this phase of the attack, defenders should be implementing traditional defences such as two-factor authentication, to prevent lateral movement with hashes extracted by Mimikatz, combined with authentication logging.  These would have both minimised the attacker's ability to move around the network and allowed the defending organisation to detect the compromise on the corporate network.  

Once the attackers had access to the POS network, they were able to load PinkKite onto POS systems.  Kroll did not mention any preventative measures in place, so the attackers were most likely able to log in directly and upload the PinkKite malware.  POS systems are unique in that they are typically single-purpose and require limited software to function.  Defenders should use this to their advantage, and enable application whitelisting to prevent unwanted or modified processes from running.  With application whitelisting in place, defenders can have more confidence that they will be notified if an unwanted change is applied to a POS system, regardless of size, process name, or persistence. 

With the POS systems infected, control of the breach was handed over from the attackers to the PinkKite malware.  PinkKite, like many POS malware variants, functions by accessing the system's active memory (RAM), extracting potential credit card data, and validating credit card numbers using a built-in Luhn algorithm.  Credit card data should be encrypted at all stages of processing, storage, and transit. By ensuring encryption exists even within the system's active memory, malware like PinkKite is unable to read or validate credit card numbers for exfiltration.  

The final and most important step in any POS compromise is exfiltration, getting the credit card data off the POS system and into the attacker's hands.  This typically involves sending the credit card data over the network to a remote location.  In the case of PinkKite, servers located in Canada, South Korea, and the Netherlands were used as staging points for exfiltrated data.  PinkKite would connect to these servers using a Windows management protocol, RDP, and transfer x-or encrypted files containing credit card data out for the attackers to retrieve. Similar to software and functionality required, POS systems typically require limited connectivity to known network locations and it is unlikely that outbound RDP to potentially foreign locations would be included in this list.  Defenders should ensure that network perimeters around POS systems and other high value assets are properly segmented using firewalls or Software Defined Perimeter (SDP) applications.  By implementing proper perimeters, malware and attackers may find it difficult to exfiltrate data, whether it's encrypted or not. 

Best practices 

In the case of PinkKite and the breach information reported by Kroll's Cyber Security team, any one of these specific safeguards may have mitigated the compromise of credit card data. To protect against a wider variety of POS malware and other unknown threats, defenders should consider implementing as many safeguards as is practical to increase the potential for detection and mitigation.  Additionally, defenders need to ensure security data collected is subject to monitoring and analysis to identify unknown attacks.  Similarities between attacks are frequently discussed, but subtleties can often confuse or defeat purely automated or signature-based defences.  Investing in a team to ingest and make sense of security data, network and host visibility, and current threat information allows organisations to identify variations or new threats more quickly. 

Contributed by Andrew Ellis, senior researcher, Cyxtera Threat Analytics team. 

*Note: The views expressed in this blog are those of the author and do not necessarily reflect the views of SC Media UK or Haymarket Media.