Stopping “Dexter” malware stealing credit card data from the POS

There's new malware on the loose targeting merchant point of sale systems (POS), often called checkouts, electronic cash registers (ECR) or tills. Apparently the impact of this new "Dexter" virus is being felt world-wide. POS systems are often the weak link in the chain and the choice of malware. They should be isolated from other networks, but often are connected. And as a checkout in constant use, they are less frequently patched and updated and thus vulnerable to all manner of malware compromise. They often store cardholder data. The good news is that savvy merchants are already tackling this risk and giving the malware nothing to steal through solutions that also have a dramatic cost reducing benefit to PCI compliance.

You can read about the new clever malware here

This new kind of attack is exactly why several years ago we launched Voltage SecureData Payments to let merchants brush off such credit card data theft risks. In the last couple of years the PCI Council has also supported the approach and called it Point to Point Encryption (P2PE) or end to end encryption. For merchants, Voltage SecureData Payments addresses this risk by encrypting the payment card data before it even gets to the POS. This might be in the card reader, a reading pin pad, or even inside a reading "sled" or "wedge" attached to the POS. If POS is breached, the data will be useless to the attacker. On the other hand, the secure card readers are very, very difficult to attack and do not store live data to steal: they encrypt it and pass it up the payment process to the POS. If tampered with they are designed to destroy their contents.

The trick is getting it right so that even though the data is protected and secure, it's still compatible to the payment applications in the merchants systems and applications in the POS itself to permit regular POS functions to continue without change. That's where format preserving encryption (FPE) comes in – NIST recognized FFX mode AES in particular. With FPE, the data stays protected from the moment it is captured as its read or entered. The magnetic stripe data and track information (Track 1, Track 2 or even EMV data) or manually entered credit card numbers are all protected while retaining the track structure, PAN format and integrity. To the POS, it still looks and feels like cardholder data, so low impact to the way customer payments are handled. To the merchant the PCI DSS scope is dramatically reduced, the whole POS is potentially out of scope. To an attacker, there's nothing of value to steal. "Dexter" would get nothing but useless encrypted data. Only the other "end" of the payment process, usually an acquirer after the payment data has passed through switches, gateways, networks and applications, can decrypt the data. For post authorization processes, a token might be returned to the merchant for storage and re-use in applications and databases without needing live PAN data again. Some larger merchants may also want to decrypt and tokenize in house so they are independent of acquirers. Voltage SecureData Payments supports all these options – and also extends to e-commerce transactions too to cover Card Not Present data theft risks in e-commerce and web infrastructure. We ran a popular webinar covering this recently.

When implemented correctly, this new approach can dramatically reduce the cost of PCI compliance and solve huge risk challenges easily. No live data means no gold to steal. Attackers don't like stealing straw.

We've helped thousands and thousands of merchants along with their payment gateways and acquirers to embrace this new approach – and the merchants couldn't be happier. Without having to worry about nasty POS infecting malware and the reducing the cost of PCI DSS compliance, they can focus on growing their business.

If you would like to learn more, drop us a line (, or take a look at the solutions here and an example of a leading merchant doing this today here.

Leave a Reply

Your email address will not be published. Required fields are marked *