New Mozart malware: A ‘classical’ case of DNS abuse
DNS has a history of being abused to facilitate malicious activity. It’s ubiquitous, it’s reliable, and it often isn’t appropriately monitored or filtered. DNS is also the best way to abstract a service from a specific IP address. It’s why most malware leverages the protocol to carry out an attack.
Mozart, the malware first discovered by MalwareHunterTeam, is a classic case of an adversary using DNS for command and control. Its author(s) is/are using TXT records to return commands to the installed malware. For a full breakdown, Vitali Kremez, Head of SentinelLabs, unpacks the process on his blog.
About the author
Andrew Wertkin is Chief Strategy Officer at BlueCat.
“The reason this [method] is attractive,” explains Farsight CEO Paul Vixie in a video with me on the topic, “is that DNS works. You ask a question from anywhere, and you will get the answer that everyone should get.”
The malware’s author(s) is/are betting on the fact that organizations aren’t monitoring what’s in plain sight. I like to refer to DNS as a chump, in that it does a super job of answering the question to the best of its ability, without any sort of prejudice. And so, DNS can become part of any sort of command and control architecture.
How Mozart Works
Mozart sets up a direct line of communication between an infected client and its server. It does this by hardcoding a DNS server IP address to which an infected client resolves, thus bypassing central DNS servers, policy rules, and monitoring. The commands which are then transmitted between the malware server and infected device are hidden in DNS TXT records.
Blocklists Not Enough
Mozart has a hardcoded DNS server IP address. A strategy that relies solely on setting up a firewall rule to block IP addresses tied to Mozart, or other similar malware (or any suspicious domain for that matter), isn’t the right approach. You’re setting your security team up for a prolonged game of whack-a-mole in this case, because malicious activity can be initiated to a new IP to no end.
As a general rule, your list of known bad domains and IPs is unlikely to keep pace with emerging threats. Your strategy must account for that.
How to Leverage DNS To Protect Against Malware
Ensure you can inspect everything:
Use Mozart as a reminder – one with real consequences – to incorporate DNS best practices into your security posture. For one, don’t allow DNS traffic to bypass corporate DNS servers (and therefore monitoring and policy application).
Block all direct access out from port 53, except for designated corporate DNS servers. Forcing all of your corporate name resolution to go through your resolvers will help maintain your ability to monitor traffic and apply policy. More specifically, it ensures that DNS queries can only go to publicly registered domains, as opposed to self-hosted servers like what Mozart set up.
Compare to the baseline to infer context
Text record queries are common for several specific use cases. Beyond simply monitoring for queries to domains that are known to be bad, or are new, or are otherwise nefarious, enterprises can – and should – look for anomalies from measured baselines.
For example, if you knew the baseline percentage of TXT records that are normally queried by a Mac and Microsoft client, you could more easily spot anomalies caused by malware leveraging TXT queries. Also, if you know the typical use cases for TXT records in a corporate enterprise context (antivirus inspection, performance monitoring, embedding a question, etc), it’s easier to spot what might be abnormal with query inspection. Corporate devices have a very regular pattern when it comes to TXT queries. Sure, it varies based on antivirus agent plus a few other factors, but generally it’s quite predictable.
Advice
This advice, on anomaly detection, applies not just for TXT records. It applies to mail exchange, zone transfer, or other special purpose resource records as well. There’s no reason, for example, for an IoT device in the network to be querying for mail servers.
IoT devices, especially purpose-built ones like point of sale (POS) machines, also have a predictable set of domains that they query. Establishing a baseline for each type of IoT device, and monitoring for deviations, is yet another strategy for seeding signs of compromise. Alternatively, you could consider blocking IoT device queries to anything outside their typical set altogether.
Also, look closely at query names. DNS query names can betray data tunnelling activity (which may embed encoded strings right into query names), and signal whether domain generating algorithms are at work to circumvent your blocklists.
Finally, query responses, if baselined, can also be a rich signal for spotting DNS hijacking. Since hijacking involves an adversary inserting themselves into the DNS resolution chain and redirecting clients to bad-actor-owned destinations, a sudden change in response or response type to a routine query can indicate compromise.
As a general rule, understanding how DNS is normally used in an enterprise enables you to spot all sorts of signs of nefarious activity, like command and control, tunneling, exfiltration, poisoning, hijacking, and more. Mozart may have been authored creatively, but the malware plays to vulnerabilities that have existed (and been taken advantage of) in corporate enterprise environments for years.
DNS has a history of being abused to facilitate malicious activity. It’s ubiquitous, it’s reliable, and it often isn’t appropriately monitored or filtered. DNS is also the best way to abstract a service from a specific IP address. It’s why most malware leverages the protocol to carry out an attack. …
