Did Mozart malware break the mold?

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.