Home / Blogs

DNS and Stolen Credit Card Numbers

FireEye announced a new piece of malware yesterday named MULTIGRAIN. This nasty piece of code steals data from Point of Sale (PoS) and transmits the stolen credit card numbers by embedding them into recursive DNS queries.

While this was definitely a great catch by the FireEye team, the thing that bothers me here is how DNS is being used in these supposedly restrictive environments. Even the FireEye researchers state that in order to resolve hostnames in the corporate environment, the recursive DNS servers must be able to access the public Internet.

That’s not really true, though.

The best protection against attacks like this is to block recursive queries to the public Internet. The great thing with going cold turkey is that one can still configure his DNS to be able to resolve all hosts inside the perimeter defence of the enterprise network.

Here’s a simple two-step guide on how to do it:

  1. Install one or two DNS servers in each PoS site. Configure them as authoritative slaves for all (internal) corporate zones AND allow recursion on these same servers.
  2. Block DNS access to the public Internet.

When a recursive query is made to a DNS server that is also authoritative for the queried zone, the query will be replied from the memory. In cases where the DNS server is not authoritative for the queried zone—and the DNS server has no access to the public Internet—the resolution process will fail and no authoritative response will be provided to the client that made the query.

The great thing about this simple solution is that it works much better than the “monitor and review” recommendation made by the FireEye research team. After all, if the DNS servers in protective network environments can only function within the boundaries set by the perimeter defense, it becomes impossible to use attacks like MULTIGRAIN to transmit stolen data outside.

By Juha Holkkola, Co-Founder and Chief Executive at FusionLayer Inc.

Juha Holkkola is the Co-Founder and Chief Technologist at FusionLayer Inc. An inventor with several patents in the US and Europe, he is an advocate of technology concepts with tangible operational impact. Juha is an active proponent of emerging technology trends such as cloud computing, hybrid IT and network functions virtualization, and a regular speaker at various industry events.

Visit Page

Filed Under


very true, but only for special networks, like POS ?! Marc Lampo  –  Apr 21, 2016 7:09 AM

DNS is mostly seen as the protocol that translates names into addresses.
As such a mandatory service in most networks and DNS is more or less considered to be part of the furniture.

Hardly anybody expects a piece of furniture to be dangerous.
But the way DNS operates it is actually a connectionless transport protocol.
As such it allows data exfiltration, like card numbers, and infiltration out and in of any network where nodes are allowed to have public DNS resolving.

By no means new, and my own talk on the subject, in october 2014, was by no means the first (nor will it be the last) to warn and show safer approaches :
Designing DNS flows for security.

That's true Marco, my suggestion only works Juha Holkkola  –  Apr 21, 2016 7:36 AM

That's true Marco, my suggestion only works well in restricted environments where access to the outside world is not needed. This is relatively common, though - PoS is a good example but there are also various kinds of management and government networks where DNS connectivity to the outside world isn't really needed. Here's how I would draw the line myself. In environments where regular traffic (HTTP, FTP, etc.) is being considerably restricted or even blocked, allowing DNS traffic to the outside should be blocked by default. In case there is a good reason to allow the traffic the default-deny can and should be reconsidered, but I think default-deny is the best policy in restricted environments. I think this is actually quite an important consideration because down the road we'll likely see a lot of new networks dedicated to IoT only. In these networks, there's not really much use for public DNS since the traffic is supposed to flow between a cloud and the dedicated IOT network. At the same time, though, there will surely be valuable tidbits of data that could be stolen and transmitted outside using DNS.

Comment Title:

  Notify me of follow-up comments

We encourage you to post comments and engage in discussions that advance this post through relevant opinion, anecdotes, links and data. If you see a comment that you believe is irrelevant or inappropriate, you can report it using the link at the end of each comment. Views expressed in the comments do not represent those of CircleID. For more information on our comment policy, see Codes of Conduct.

CircleID Newsletter The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

I make a point of reading CircleID. There is no getting around the utility of knowing what thoughtful people are thinking and saying about our industry.

Co-designer of the TCP/IP Protocols & the Architecture of the Internet




Sponsored byDNIB.com

Brand Protection

Sponsored byCSC

IPv4 Markets

Sponsored byIPv4.Global

New TLDs

Sponsored byRadix

Threat Intelligence

Sponsored byWhoisXML API


Sponsored byVerisign

Domain Names

Sponsored byVerisign