The complexities involved with detecting Point of Sale credit card theft has to consider numerous tactics. It also requires an understanding that the behavior of Point of Sale – POS theft detection continues to evolve.
Back in November of 2014, HP DVLabs reported:
a new variant of the Home Depot point-of-sale (PoS) malware called FrameworkPOS was discovered.
The new strain:
exfiltrates customer debit and credit card track data out of the organization through the DNS protocol.
This is further evidence that as the malware writers obtain success with their evil tactics, they continue to change and modify their contagions in hopes of keeping them undetectable by most monitoring systems. Abusing DNS is particularly menacing due to the Internet’s dependency on it. The DNS is what translates human readable names (e.g. plixer.com) to IP addresses used by computer devices to access the Internet.
Piggy backing on DNS to sneak information past the firewall is not a new practice. Legitimate products like Dell Sonicwall Firewalls and iPhones have been doing it for years and still do today. Most firewalls will not question the legitimacy of these domain requests. Consider a fully qualified domain name (FQDN) that looks like: 29831.holmes.987ADE2F0D18BF.adobe-pdf105.com.
- 29831 : could be the ID utilized to identify the end system
- Holmes : could be used to identify the type of beacon
- 987ADE2F0D18BF : is the encrypted information (e.g. credit card number) the malware stole from the POS system
- adobe-pdf105.com : is the 2nd level domain the local DNS will reach out to the Internet for in hopes of communicating with the authoritative DNS responsible for adobe-pdf105.com
Why would the DNS forward this out to the Internet? Because this is the job of the DNS, to resolve each domain request to an IP address. After going out to root and finding the authoritative DNS, the authoritative DNS server responsible for adobe-pdf105.com would parse the request, decode the message and may or may not respond back. If it does, it might do so very selectively with instructions on what deeds the infection needs to carry out. All of these messages pass right by most if not all 2nd generation firewalls. What can be done to stop them?
Proactively monitoring and blocking attempts by infected POS systems that try to use DNS to exfiltrate information might sound like the ideal option. In practice, it is extremely difficult. Some domain reputation look ups done at the firewall might catch an infection but, many targeted POS attacks aren’t wide spread and because of this, the domains seldom end up on black lists. Ultimately, the thing to do is to monitor behaviors over time and to consolidate suspicious events into a single metric. The aggregation of events will breach a threshold and trigger notification. Stop worrying about false positives and employ a solution that adapts and monitors behaviors over time.
Take a 2nd look at the labels that are separated by dots in the FQDN: 29831.holmes.987ADE2F0D18BF.adobe-pdf105.com. Labels like 29831 and 987ADE2F0D18BF are not common words and could be suspicious events. DNS monitoring systems will pick up on this these and other odd FQDN patterns. NXDomain, DNS TXT or simply no response at all are all DNS message patterns that should be closely monitored. Contact our team to lean more.