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.

Critical conversations on critical infrastructure

Find out how your peers are managing their networks through profound change. Watch this series of live interactive discussions with IT pros & join the debate in Slack.

Join the conversation

Read more

Six non-hype network automation lessons from IT pros

Five IT pros get real about network automation during the first Critical Conversation on Critical Infrastructure hosted in the Network VIP community.

Read more
BlueCat’s DDI Adaptive Plugins and Applications help IT teams better leverage ServiceNow, Ansible, Microsoft, and more

A growing suite of Adaptive Plugins and Applications will help automate existing BlueCat capabilities along with adjacent customer technologies.

Read more
BlueCat Overlay for Microsoft

With BlueCat Overlay for Microsoft, get visibility into Microsoft DNS and DHCP servers by relaying information back to your BlueCat Address Manager server.

Read more
ServiceNow

With the ServiceNow Adaptive Plug-in, enable self-service IT requests with automated fulfillment, such as hostname and IP address provisioning.

Read more

Subscribe to our blog