A new backdoor malware is evading detection by a few security software and intrusion detection systems by using the DNS protocol to communicate with remote attackers.
For ease of use and communication, a malware typically phones home to receive commands that should be executed and it will do so over the HTTP/S protocols. However, as security software normally monitors this traffic for malicious activity, using HTTP/S communication to communicate, though, has its drawbacks. The security software will block the connection and the malware that performed the HTTP/S request if it is detected.
In the newly discovered Mozart, the malware uses DNS to receive instructions from attackers and to evade detection.
Issuing Commands through DNS TXT records
For the software to connect to the remote computer, it uses the DNS which is a name resolution protocol that is used to convert a hostname to its IP address. The DNS protocol also allows you to query TXT records that contain text data, in addition to converting hostnames to IP addresses. This feature is commonly used for domain ownership verification for online services and email security policies such as Sender Policy Framework or DMARC.
Threat actors behind Mozart are using these DNS TXT records to store commands that are retrieved by the malware and executed on the infected computer.
It is believed that the Mozart Malware is being distributed via phishing emails that contain PDFs that link to a ZIP file that was located at www.masikini[.]com/CarlitoRegular[.]zip.
This zip file contains a JScript file that when executed will extract a base64 encoded executable that is saved to the computer as %Temp%\calc.exe and executed.
According to researchers who have analyzed this backdoor, the malware will first check for the file %Temp%\mozart.txt. It will create the file with the contents of ‘12345’ and perform some preparation work on the computer if the file does not already exist.
This includes copying the calc.exe file from the %Temp% folder to a random named executable in the %AppData%\Microsoft\Windows\Start Menu\Programs\Startup\ folder to startup every time the victim logs into Windows.
According to the researchers, after communicating hardcoded DNS server under the attacker’s control, the Mozart malware will issue following DNS requests to receive instructions or configuration data:
Base64-encoded parameters are returned for tasks and further processing once the loader obtains the bot id:
- “.getid” (.1)
The bot generation API sequence is as follows:
GetCurrentHwProfileW -> GetUserNameW -> LookupAccountNameW -> ConvertSidToStringSidW - .
“.gettasks” (.1)
Parse tasks with “,” delimiter - “.gettasksize” (.1)
Allocate memory for the task and dnsquery_call - “.gettask” (.1)
Parse for the specific task - “.reporttask” (.0|.1)
Run the task via CreateProcessW API - “.reportupdates” (.0|.1)
Retrieve and check updates via WriteFile and MoveFilW locally for a stored check as “.txt” - “.getupdates” (.0|.1)
Check for presence of “.txt” update and write the update with “wb” flag and check for executable extension (“.exe”) following with “.gettasks” call.
When researchers conducted tests and assigned the bot of ID ‘111’, which caused Mozart to do DNS TXT lookups for 111.1.getid, 111.1.getupdates, and 111.1.gettasks.
The malware continually issues ‘gettasks’ queries to the attacker’s DNS server to find commands to execute. As shown above, if the TXT record response is empty that means the malware will continue to perform this check over and over until a task is provided and there are no commands to execute.
Currently, it is not known what commands are being executed by Mozart. It is to be seen if the attackers are currently in the process of building their botnet before transmitting commands.
Barricading the threat
It is critical to note that malware using DNS to communicate is not unique to the Mozart backdoor. In 2017, a malware called DNSMessenger was discovered that was also using TXT records for malicious communication.
At the firewall, our experts suggest blocking of outbound port 53 from everywhere except the official internal DNS server, since this virus goes directly to a fixed external IP, and while it can just be blocked, the next virus won’t use the same IP. Forcing all of the corporate name resolutions to go through the resolvers that are maintained giving the security team the ability to monitor traffic and control policy.
It is also essential to keep an eye out for novel methods of malicious communication.
To read more, please check eScan Blog
