Did Mozart malware break the mold?

Is this ‘new’ DNS-based malware really anything new?

A couple of 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 hardcoded command server IP address to your 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 is 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 the 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.


An avatar of the author

BlueCat provides core services and solutions that help our customers and their teams deliver change-ready networks. With BlueCat, organizations can build reliable, secure, and agile mission-critical networks that can support transformation initiatives such as cloud adoption and automation. BlueCat’s growing portfolio includes services and solutions for automated and unified DDI management, network security, multicloud management, and network observability and health.

Related content

Simplify NIS2 compliance with DNS management

Learn whether the EU’s NIS2 requirements apply to your organization and about how DNS management and BlueCat can boost your path to compliance.

Read more

Detect anomalies and CVE risks with Infrastructure Assurance 8.4 

The Infrastructure Assurance 8.4 release features an anomaly detection engine for outliers and a CVE analysis engine to uncover device vulnerabilities.

Read more

Get fast, resilient, and flexible DDI management with Integrity 9.6

With Integrity 9.6, network admins can get support for new DNS record types, architect and configure multi-primary DNS, and automate IP assignments.

Read more

Deepen your security insight with Infrastructure Assurance 8.3

BlueCat Infrastructure Assurance 8.3, with an enhanced analytics dashboard, including interactive widgets and top 10 alerts, is now available.

Read more

BlueCat to acquire LiveAction

BlueCat adds LiveAction’s network observability and intelligence platform, which helps large enterprises optimize the performance, resiliency, and security of their networks.