Case Studies for Using Network Anomaly Analysis Tools: DNSpionage Campaign Discovery

We continue to review cases for network traffic analysis (NTA) systems for cybersecurity goals. Today we will see how such solutions can be used to detect very complex, targeted and very effective campaigns called DNSpionage and Sea Turtle.

But before that, I will briefly recall how the Domain Name System (DNS), which underlies the interaction on the Internet, works. The human brain is so arranged that it is unable to memorize many numbers and numbers that a person does not associate with anything familiar. And the number of memorable combinations of numbers and numbers is in any case small. Therefore, in order not to memorize and store in the notebook hundreds and thousands of IP addresses of the sites we are interested in, a DNS system was invented that translates the symbolic addresses of sites that are more understandable to humans into their IP addresses. If I need to get to any site, then I send a DNS query with the name of the site to the DNS server, which returns me its IP address, which I go to.



If you dive a little more into the details, then the scheme looks more complicated. If the DNS server closest to me does not know the IP address of the site that interests me, it directs me to the root server, which then directs me to the DNS server of the zone in which the site of interest to me is located (for example, “.ru”), and further along the chain until I reach a DNS server that knows the IP address I need.



It turns out that we trust the DNS servers that send us the IP addresses of the sites we want to visit. And if someone breaks into a DNS server and spoofs a record for matching a symbolic name and IP address? What if we are directed to a fake site that looks like a real one and that can steal our logins and passwords, as well as other confidential information about us? This spoofing is called DNS Redirection and is used by cybercriminals in especially dangerous attacks.



In 2009, the “Iranian Cyber ​​Army” thus replaced twitter.com. In 2011, 186 domains were replaced by Turkish hackers, including HSBC, Vodafone, Acer, and others. In 2013-2014, the Syrian Electronic Army replaced the sites NYT, Twitter, Huffingtin Post (the attempt failed against Facebook). In the same year, similar actions were carried out against WhatsApp, AVG, Avira. A year later, Vietnamese and Malaysian Google sites were replaced, as well as the domain of the Federal Reserve Bank of St. Louis. In 2016, a certain amount of cryptocurrency was stolen from blockchain.info in this way.

In fact, there are more DNS attack vectors, but today we’ll only look at those related to the DNSpionage and Sea Turtle campaigns .



Now that we’ve got a quick look at how DNS works and how you can use it to the detriment, we can turn directly to the DNSpionage and Sea Turtle campaigns, starting with the first one. In 2018, the Cisco Talos division encountered it in several countries in the Middle East. It consisted of two parts - infection of users and DNS Redirection, which were not always related, but for a number of signs, we concluded that the same group is most likely behind both parts.



In the first case, victim users received job offers through LinkedIn and other job search sites. All vacancies led to fake sites on which tempting vacancies were posted. Two sites were recorded - hr-wipro [.] Com and hr-suncor [.] Com, which redirected users to the legal wipro.com and suncor.com. The links placed files in MS Word format with embedded macros, each of which worked when the document was opened and closed, respectively.



The first macro decoded the PE file and saved it at the address ”% UserProfile% \. OracleServices \ svshost_serv.doc”. The second macro renamed “svshost_serv.doc” to “svshost_serv.exe”. Then the macro created the “chromium updater v 37.5.0” task, which ran the executable file and repeated it every minute. This malware performed the functions of RAT (remote administration tool), which was called DNSpionage. It interacted with a specially created domain, requesting / receiving commands that it executed. Among these commands are requesting directory contents, scanning the network, copying files, using remote utilities (WinSSHD, Putty, mimikatz), etc. Commands from the command server, as well as the results of the work, were sent in one of two modes - HTTP or DNS. The second option is usually simpler, since there is a high probabilitythat you do not have a full-fledged inspection of DNS traffic and you simply don’t notice the DNSpionage malicious code communicating with the command server.

The most interesting thing begins at the moment the client and server parts of the malware communicate. The client sends the following obfuscated DNS query to 0ffice36o [.] Com (the first character is zero and the last letter is “o”): RoyNGBDVIAA0 [.] 0ffice36o [.] Com, where the first 4 bytes are randomly generated and the rest (GBDVIAA0 ) are a base32 encoded request (for each victim, their own base64 / dase32 alphabet was selected). Deciphering it gives us “0GT \ x00”, where GT is the identifier of the victim, and \ x00 is the request number. The command server answers us in the form of an IP address, which is not always correct, for example, 0.1.0.3 (the DNS protocol allows this). The second DNS query looks like this: t0qIGBDVIAI0 [.] 0ffice36o [.] Com. The command server returns us the IP address: 100.105.114.0, which is 4 characters in regular ASCII encoding,which in this case means the executable command “dir \ x00”. In response, the client side of DNSpionage sends:

[.] [.] gLtAGJDVIAJAKZXWY000 0ffice36o com -> GJDVIAJAKZXWY000 -> "2gt \ x01 Vol»
[.] TwGHGJDVIATVNVSSA000 0ffice36o com [.] -> GJDVIATVNVSSA000 -> «2gt \ x02 ume»
[.] 1QMUGJDVIA3JNYQGI000 0ffice36o com [.] - > GJDVIA3JNYQGI000 -> "2GT \ x03 in d"
iucCGJDVIBDSNF3GK000 [.] 0ffice36o [.] Com -> GJDVIBDSNF3GK000 -> "2GT \ x04 rive"
viLxGJDVIBJAIMQGQ36 [Q] [2]] 2JTQQJQQJQQ [J] 0] [J] 0. h "

As part of the second part of the DNSpionage campaign, the administrator of the DNS server administrator was stolen, the corresponding DNS records were changed, and certificates were created using LetsEncrypt, which will be used later in the “site in the middle” attack. It is on such a site that the previously described DNS Redirection attack will send selected victims (in just 2 years of this campaign, we were able to identify 25 redirects, which indicates not a massive, but a targeted attack). Please note that both your own DNS server (if you have one) and third-party DNS servers that you already do not control can be attacked.

As part of their activities, the attackers were able to intercept all traffic that went to the indicated domains of the government bodies of Lebanon and the United Arab Emirates (the Ministry of Finance, the police, the Ministry of Communications and Telecommunications, the airline, etc.), including email and VPN, which could allow them to gather additional information about their victims.

The Cisco Talos Sea Turtle campaign was even more complicated than DNSpionage, as attackers attacked not only DNS servers, but also TLD servers (including ccTLDs and gTLDs),



which allowed unknown hackers to attack state and military organizations in the Middle East and North Africa, as well as special services and oil and gas companies.



Now back to the original task and see how network traffic analysis systems can help identify the mentioned campaigns. It should be noted right away that given their complexity and the fact that they can be directed against external DNS servers, NTA class systems will not always help us. But in those cases when it comes to the DNS-mode of DNSpionage or an attack on local DNS servers within the framework of DNSpionage or Sea Turtle, we can use Netflow to see all the signs of an attack we need and block them in a timely manner.

First of all, we need to define our internal DNS servers and add them to one group. This is where the introduction of almost any anomaly monitoring system begins. To understand whether we encountered anomalies in network traffic or not, we first need to decide what is normal and legitimate. And only after that the system begins to work in full force.



This can be done manually, but it is better to use the function of classifying nodes by type of traffic, which allows you to identify all nodes, even those that we don’t know about, but which function as DNS servers.



In our case, we found 5 servers:



After we have decided on the legal DNS servers, we can only monitor all the DNS traffic, which is anomalous, that is, beyond what is allowed. For example, this is how we can describe a rule for identifying internal illegally working DNS servers:



And this rule will look like this, which shows that for some reason we have 2 DNS servers in our network, one of which is located in the confidential server segment , and the second in the segment of user devices.



The following rule allows us to identify external suspicious DNS servers that interact directly with internal hosts, which may indicate that the DNSpionage command server works with infected corporate devices:



And we find examples of such interaction:



In a similar way, we can configure the network anomaly detection system (and this article uses Cisco Stealthwatch as an example) to detect unauthorized attempts to access internal nodes to the local DNS server (this may indicate a DNSpionage or Sea Turtle is working), as well as active interaction internal hosts with external hosts using the DNS protocol (this will record the operation of DNSpionage in DNS mode).

Having fixed the corresponding anomalies and security policy violations, we must develop rules that allow us to signal any future attempts to connect internal nodes, excluding local DNS servers, to external DNS servers (and vice versa).



The second rule allows us to record any attempts to interact using DNS traffic within the corporate network, excluding local DNS servers.



This is how monitoring Netflow (as well as other flow protocols) allows us to identify individual stages of fairly complex attacks that can harm modern corporations and government agencies.

Source: https://habr.com/ru/post/undefined/