#1286250: VB2019 paper: DNS on fire
Cisco Talos has identified malicious actors that have been targeting the DNS protocol successfully for the past several years. In this paper, we will present two of the threat actors we have been tracking.
The first one developed a piece of malware, named DNSpionage, targeting several government agencies in the Middle East, as well as an airline. During the research process for DNSpionage, we also discovered an effort to redirect DNSs from the targets and discovered some registered SSL certificates for them. We identified multiple countries being targeted by this redirection. On 22 January 2019, the US Department of Homeland Security published a directive concerning this attack vector. We will present the timeline for these events and their technical details.
The second actor is behind a campaign we named ‘Sea Turtle’. This actor is more advanced and more aggressive than the first, directly targeting registrars and a registry.
This paper will present the two threat groups and the methodology used to target their victims.
DNS is a fundamental core technology of the Internet as we know it. It allows users to find websites easily and removes the requirement to know the IP address of every single host on the Internet. This paper will discuss two attacks on DNS and will show how an attacker can control your traffic. The DNSpionage  and Sea Turtle  campaigns show just how important DNS can be to attackers and how the abuse and manipulation of DNS can lead to success for the attackers. Each of these campaigns has a very specific focus and they demonstrate the determination of state-sponsored actors to ensure their operations are successful. Organizations and governments alike need to work together to establish a set of rules and potential punishments around the targeting of DNS and to cooperate in pursuing actors that irresponsibly target this system.
DNS is a hierarchical system that’s decentralized from any specific entity and operates as the ‘phonebook’ of the Internet. The DNS protocol is the technology responsible for turning an IP address, such as ‘188.8.131.52’, into a domain name, ‘www.talosintelligence.com’. Without DNS, users would have to remember a string of numbers rather than a simple name or phrase to navigate the Internet.
Registry vs. registrar vs. registrant
This can be a complicated area if you’re not familiar with DNS and the methods by which it is maintained and operated. The three types of organizations directly affected by these attacks on DNS are registries, registrars and registrants.
Registry: This is an organization that manages the top-level domains (TLDs). A registry is the entity responsible for working with registrars to allow registrants to purchase domain names.
Registrar: This is an organization that is responsible for providing a platform for end-users to purchase domain names. GoDaddy, for example, sells domain names to the public and operates as an accredited registrar. Depending on the TLD you wish to purchase (.com, .net, .org, etc.), the ccTLD (.us, .ca, .eu, etc.) or gTLD (.club, .site, .top, etc.), you will ultimately end up purchasing this from the registrar.
Registrant: This is the end-user – the customer of the registrar. Once a domain name is registered, the registrant can maintain their domain name settings through their registrar of choice. This allows changes to be made by the domain owner, which are then propagated across the Internet.
Cisco Talos discovered DNSpionage in late 2018 . DNSpionage is identified as an espionage campaign against several Middle Eastern government entities, specifically in Lebanon and the United Arab Emirates (UAE). The campaign utilized malicious documents delivered via spear phishing and fake job websites, and ultimately made use of DNS redirection to facilitate the redirection of network traffic from the end-user to actor-controlled infrastructure.
Fake job websites
The attackers’ first attempt to compromise the user involved two malicious websites that mimicked legitimate sites that host job listings:
hr-wipro[.]com (with a redirection to the real wipro.com)
hr-suncor[.]com (with a redirection to the real suncor.com)
These sites hosted a malicious Microsoft Word document: hxxp://hr-suncor[.]com/Suncor_employment_form[.]doc.
The document was a copy of a legitimate file that is available on the website of Suncor Energy (a Canadian sustainable energy company) and contained a malicious macro.
The malicious Word document was delivered via malicious links and spear-phished emails. It was specifically targeted to individuals and was not a widespread spam campaign trying to get as many clicks as possible. DNSpionage had specific intent in mind.
The malicious Word document was disguised as a legitimate human resources document from Suncor.
Figure 1: The malicious Word document was disguised as a legitimate Suncor human resources document.
As mentioned, the document contained a malicious macro, which performs the following actions:
When the document is opened, the macro decodes a PE file encoded with Base64 and drops it in %UserProfile%\.oracleServices\svshost_serv.doc.
When the document is closed, the macro renames the file ‘svshost_serv.doc’ to ‘svshost_serv.exe’. Then, the macro creates a scheduled task named ‘chromium updater v 37.5.0’ in order to execute the binary. The scheduled task is executed immediately and repeated every minute.
The payload is executed when Microsoft Office is closed, meaning that human interaction is required in order for it to be deployed. The macro, while available through analysis, is also password-protected in Microsoft Word to stop the victim from exploring the macro code via Microsoft Office.
In addition, the macro uses classical string obfuscation in order to avoid strings detection:
Figure 2: The macro uses classical string obfuscation.
The ‘schedule.service’ string is created using concatenation. The final payload is a remote administration tool that we named ‘DNSpionage’.
DNSpionage supports DNS tunnelling as a covert channel to communicate with the attackers’ infrastructure.
It creates its own data in the running directory:
The attacker uses the ‘Downloads’ directory to store additional scripts and tools downloaded from the command-and-control (C2) server.
The ‘Uploads’ directory is also used to store files temporarily before exfiltrating them to the C2.
The log.txt file contains logs in plain text. All the executed commands can be logged in this file. It also contains the result of the commands.
‘Configure.txt’ is the last file. As its name suggests, it contains the malware configuration. The attackers can specify a custom C2 server URL, as well as a URI and a domain that serves as a DNS covert channel. Additionally, the attackers can specify a custom Base64 dictionary for obfuscation. We discovered that the attackers used a custom dictionary for each target.
All the data is transferred in JSON, which is why a large part of the malware’s code is the JSON library.
DNSpionage made use of both HTTP and DNS ‘modes’ for communicating with the C2.
When using ‘HTTP mode’, a DNS request to 0ffice36o[.]com (notice the ‘zero’ character being used in place of the ‘o’, and vice-versa) is performed with random data encoded with Base64. This request registers the infected system and receives the IP address of an HTTP server (184.108.40.206 during our analysis).
The following is an example of a DNS request:
The malware is able to craft DNS requests which are used to provide the attacker with additional information. Here is an example of one of these requests:
In this context, the first four characters are randomly generated by the malware using rand(). The rest of the domain is then encoded in Base32. Once decoded, the value is 1Fy2048. ‘Fy’ is the target ID and ‘2048’ (0x800) represents ‘Config file not found’. This request is performed if the configuration file was not retrieved on the infected machine.
The malware then performs an initial HTTP request to retrieve its configuration at hxxp://IP/Client/Login?id=Fy.
This request will be used to create the configuration file, particularly to set the custom Base64 dictionary.
The second HTTP request is hxxp://IP/index.html?id=XX (where ‘XX’ is the ID for the infected system).
The purpose of this request is to retrieve the orders. The site is a fake Wikipedia page, as shown in Figure 3.
The commands are included in the source code of the fake page, as shown in Figure 4.
Read rest in the link
|Date added||Nov. 8, 2019, 5:21 p.m.|