Did DNS-based Mozart malware break the mold or is it nothing new?

A couple weeks ago, news broke of a ‘new’ type of malware called Mozart. While the exact way Mozart commands infected devices is innovative, the malware…

A couple weeks ago, news broke of a ‘new’ type of malware called Mozart. While the exact way Mozart commands infected devices is innovative, the malware is still a textbook example of DNS being leveraged as an attack vector. As such, news of Mozart should serve as a reminder of a few best practices that must be part of all enterprise security postures.

How Mozart Works

Mozart works by establishing a backdoor connection between the malware’s server and an infected computer, and then using DNS TXT records to return commands to the installed malware.

DNS has a history of being abused by malicious actors, in large part because many organizations aren’t properly monitoring it. With Mozart, the authors are betting on that fact.

In a video conversation between our Chief Strategy Officer Andrew Wertkin and CEO of Farsight Security Paul Vixie, they unpack the implications of Mozart’s chosen method. “This allows to publish from anywhere – and subscribe from anywhere – and not really have a trail of breadcrumbs leading to the criminal’s infrastructure,” he says.

How not to deal with Mozart

As a band-aid solution, you could shut this malware down by adding the Mozart’s hard coded command server IP address to device firewall blocklist. We don’t recommend only doing that.

The issue with this approach is that you’re signing your organization up for a reactive game of whack-a-mole. The next version of Mozart – or any other malware – could simply resolve to a new IP address.

Best practices for Mozart and beyond

Architect your network against unauthorized backdoors

For IT teams nervous about the threat of malware to the corporate network, it’s important to remember that Mozart (and all other backdoor-type attacks) could be thwarted by following this best practice: block all direct access out from Port 53, except for designated corporate DNS servers. This will force all corporate name resolution to go through your resolvers (and drop the other stuff), and help you maintain visibility, and therefore policy controls and analytics, over potentially malicious traffic. It also ensures that only registered domains can be queried.

Watch your DNS data

DNS data speaks, and listening pays dividends. Watching for anomalies in everything from query name, to query type, and even time of day a query is made can tell you a lot about the security of your network.

For example, TXT record queries are common for several specific use cases, like antivirus inspection, performance monitoring, embedding a question, etc. Watching for anomalies in how those queries are used, compared to an established baseline, is a worthwhile exercise. In Andrew and Paul’s conversation, Andrew specifically cited the example of monitoring the percentage of TXT records that are normally queried by a Mac or Microsoft client, and watching for changes. Corporate devices exhibit a very regular pattern when it comes to TXT queries (factors like antivirus agent and a few others need to be factored in), or mail exchange records, so anomalies can be used as a reliable indicator of compromise.

Monitoring query names is another example of good practice, since they can betray signs of compromise as well. Bad actors embed sensitive bits of information into query names as a way of tunneling out data. Also, domain generating algorithms (DGA) are used by other bad actors as a means of circumventing block lists to establish contact with malicious servers.

The context of a query and its device are also important. If a purpose built device, like a fish tank, is querying google.com, that’s a hint something is wrong. Purpose built devices typically have a predictable set of domains they query, and any deviation from that should be treated as suspicious. Similarly, the context of regular operating hours for clients can be useful context, especially in retail and manufacturing industries. Think about it: why would a point of sale (POS) machine have any reason to be querying anything in the middle of the night, outside store hours? (The exception here is, of course, if it’s pinging for software updates.)

DNS does a stand-up job of answering questions to the best of its ability without discrimination. In other words, it’s a chump. That’s why criminals use it as an attack vector in a number of different scenarios. As part of any organization’s security posture, DNS must therefore be architected and monitored in a way that allows organizations to fight back.

Subscribe to our blog

Get in touch

We’re the DDI provider you’ve been looking for.
Drop us a line and let’s talk.

Read more

Tales from the Edge: DNS is so much more than a phone book

A conversation on Edge and enterprise use cases with BlueCat’s Chief Strategy Officer, Andrew Wertkin, and podcast hosts Stephen Spector, & Rob Hirschfeld.

Read more
Cloud Discovery & Visibility Demo

Advanced DDI capabilities & visibility for your multi-cloud & private cloud environments

Read more
GAO report shows how difficult IPv6 migrations really are

How difficult are IPv6 migrations? A recent GAO report on DOD’s transition plan provides some sobering conclusions.

Read more
Manage compute seamlessly with the BlueCat OpenStack Adaptive Plug-In

The BlueCat OpenStack Adaptive Plug-In provisions compute to support updates for DNS name resolution across the enterprise.

Read more