As most of the world is aware by now, the recent credit card breach at Target (between November 27 and December 15) netted the attackers 40 million credit and debit cards, as well as personal information, such as phone numbers and addresses, of as many as 70 million more. For a few very long weeks, there was scant information about the attack vector and the malware involved with the attack. This posting is a follow-up to my recent posting where the community was taking stabs in the dark to determine how the attack took place. Well, wait no longer – this post provides further details about the attack vector, my thoughts as to why it was successful, and most importantly, what you can do to learn from this attack and to begin implementing controls that would thwart similar attacks in the future.

According to the Department of Homeland Security (DHS) report, the malware apparently was Trojan.POSRAM, otherwise known as “BlackPOS.” iSIGHT Partners helped perform the analysis and you can request the report directly from iSIGHT Partners at By now, most of you know that this malware originated in Russia and that a primary contributor to this malware is a 17-year-old teenager. This malware’s purpose is to extract cardholder data from memory on Point of Sale systems. Compromised data is collected in a .DLL file (in this case, track data, which includes all of the information within the magnetic strip) and is periodically relayed to an affected “dump” server over a temporary NetBIOS share drive located somewhere on the merchant’s network. The attackers served up a sophisticated software “cocktail,” which included other tools that were all able to circumvent any anti-malware platforms and Windows patches.

Scary stuff, right? While the report included additional technical details pertaining to the malware, I will focus on making suggestions on things you can do to help prevent this type of attack. Keep in mind, there is no such thing as being perfectly secure and we can’t always protect against the unknown – the key thing is to implement controls that help address what is known (defense-in-depth!). iSIGHT and DHS provided some of the suggestions listed below, and I’ve added some color commentary along with a few of my own suggestions.

Network segmentation and strong firewall access control lists: Yes, this is like beating a dead horse. Make sure that your POS environment can ONLY communicate with specific back-end hosts over whatever ports are required for those systems to do their business. The POS systems did not dump the compromised cardholder data directly over the Internet – they dumped it to a trusted (but maybe shouldn’t have been!) internal server. While you’re at it, try to limit internal servers from accessing the Internet if they don’t have a legitimate business need to do so.

Audit hosts for a rogue "POSWDS" service: This is one of the services that BlackPOS uses, so be on the lookout for it. Better yet, you ought to know your POS environment well enough to know what services and applications can be considered whitelisted, so from a holistic perspective, you ought to be on the lookout for ANY rogue service.

Look for rogue applications in memory: BlackPOS may attempt to masquerade as “svchost” or possibly as other POS system services. Be knowledgeable of what applications should be running in memory under normal conditions and determine whether you have any means of automating the monitoring of applications in memory.

Look for a rogue data manager application on internal LAN servers: Keep in mind, this is one VERY sophisticated attack. One of the biggest ongoing discussion points in the PCI world is scoping – and this means you should be acutely aware of not only your direct cardholder data environment, but of ALL systems attached to this environment. Security is only as good as your weakest point.

Implement DLP tools: Data Loss Prevention tools may help determine if there are any rogue cardholder data streams either to a compromised internal server or from a dump server to the attackers over the Internet.

POS blocking and tackling: Make sure that your POS systems have current patches, current anti-malware, file integrity monitoring, and if possible, host-based intrusion detection/prevention. While host-based IDS/IPS is not a PCI requirement, it can certainly be helpful in preventing or detecting an attack.

Payment applications: Use PA-DSS compliant payment applications, or if you do use your own payment applications, ensure that they go through the same security testing that PA-DSS payment applications go through. Make sure that you validate (i.e. perform a checksum) any automatic updates from third parties before deploying them. Work with your POS vendor to obtain signatures and hash values to perform this checksum validation. Also, work closely with your payment application vendor to understand if there are any known attack vectors or weaknesses.

Authentication mechanisms: When possible, use two-factor authentication to access your in-scope PCI networks. Attackers often use keystroke loggers or password capturing tools to obtain administrative credentials. Security is as good as your weakest point – don’t let that be your credentialing.

Build a better mousetrap: If it’s feasible, work closely with your penetration tester to see if there is a way to SAFELY perform a BlackPOS (I would imagine that this is available) attack scenario in your lab environment to determine if your detection/prevention mechanisms would detect or prevent this type of attack. If you do attempt this, proceed with extreme caution, ensure that your lab environment is isolated, and make sure that you scrub your test systems afterwards.

Choose your QSA wisely: There are many good QSAs (PCI assessors) out there, and unfortunately, there are also several QSA companies that are not very thorough. When you are considering your QSA, make sure you feel confident in their ability to deliver a thorough, yet pragmatic, assessment. This previous blog post provides some guidance.


If you implement these measures, will it prevent you from being compromised in the future? No. However, if you do not begin taking action and something bad DOES happen in the future, will you have a good excuse? Without a doubt, these attack scenarios ought to be considered in your formal risk assessment, and your organization should begin to create an action plan to address these threats.


Topics: Security

Leave a Reply