By Gianna Mulé
Introduction and Background
DNS hijacking is an attack where innocuous DNS requests resolve to a malicious website. Also known as DNS redirection, this attack has gained popularity due to the widespread attack, dubbed DNSpionage, back in 2018. There are four types of attack: local, router, man in the middle, and rogue server. According to the FireEye report on this campaign, there were three main tactics used. The first was the pollution of DNS A records, making this technique a rogue server attack. The second tactic employed was the pollution of NS records, another rogue server attack. The third tactic seen during this campaign was a man in the middle attack. Requests to the server were intercepted, and if the victim was in a certain “zone” (if the request originated from a source the attack was targeting), a malicious address was returned. If not, the request was passed upstream and the true IP address was returned. FireEye, CrowdStrike, and Cisco Talos researched this event and released reports. KrebsOnSecurity conducted research and also published an article detailing the event. The purpose of this post is to discuss a new way of detection of DNS hijacking through the use of a neural network, and further to discuss the theoretical prediction of future attacks before they happen.
If you Google anything close to protecting yourself from DNS redirection, you’ll see suggestions ranging from “don’t click on the links in sketchy emails” to “employ DNSSEC.” These are valid suggestions, however, the malware behind DNSpionage was embedded into a legitimate looking document, and some of the affected hosts did employ DNSSEC. How do we detect when something has passed our prevention methods? Currently, detection is difficult, until of course the effects of the attack are wreaking havoc. I believe a neural network could detect an attack in its early days before the effect is too destructive, and may be able to detect unscheduled changes in DNS configuration for an even earlier detection. To do this, the first step is to create data sets of what PDNS traffic looks like during normal time, as well as during an attack. For this project, I used documented affected addresses (found on the CrowdStrike report) during the DNSpionage campaign.
What does our data look like? In its raw form, the collectible data for PDNS traffic is an IP address, the domain is points to, the dates that address points to that domain, and the record type. With this information, we can create a data structure to feed our neural network. This structure will be something of a timeline, created with vectors that contain a single date, an address, and a domain. Each training set for the neural network must be a compilation of these vector-timelines, with a label of “STANDARD” or “ATTACK”. Here, “STANDARD” denotes that the current timeline is normal, uninterrupted, and innocuous DNS data. Conversely, “ATTACK” denotes that the timeline is the product of an attack, campaign, or otherwise malicious manipulation of traffic.
Neural Network and Placement
After training the network with the aforementioned training set data, we can verify functionality by feeding the network new data sets that follow the same pattern, this time without labels. Due to a limited data pool, from this point on any information provided in this post is theoretical. Assuming the network can accurately categorize attack timelines and standard timelines, the next question would regard the practical use of such a technology. In training and validation, the network was fed complete data sets. For this to be practical, the network should be able to identify timelines based on partial data sets. Next generation firewalls have great traffic-analyzing capabilities. If the sorted DNS traffic that passes through these firewalls is dissected to create the same timeline vectors described earlier (in other words, if the firewall isolated DNS traffic and extracted the queried domain and the returned IP address), it could send this information along with a timestamp to the neural network as a vector in the current timeline. In this situation, the neural network is receiving a constant stream of data rather than a chunk at once. It must have the capability of memory – it must store all previous entries for a given time period (which could be determined statistically by feeding it different sized training sets to determine the optimal size of accurate categorization) and append new vectors is receives to these previous entries. This wouldn’t be a hard task, though these stored data sets should be protected as they open a new potential attack space. If these stored timelines were poisoned by an attacker, this warning system would be rendered ineffective. With a set up like this, however, a neural network could work alongside firewalls to trigger earlier alerts for suspected DNS attacks. It should be noted that the ideal placement of this neural network would be in front of the DNS server, so it could catch all queries forwarded to it. This would not protect individual clients from having their DNS configurations changed, but it would protect public servers.
Setting up a practical alert system for DNS attacks should be the first step towards tightening DNS security. Once in place, we could theoretically take it one step further and begin to work towards predicting the likelihood of a domain being targeted. A neural network calculates the probability a node falls into a specific category. If we format new data sets from the vectors in the flagged timelines, we can create a parallel neural network to further analyze these attack-like behaviors to predict which nodes might be victimized next.
These new data sets would be a bit more involved than the vector-timelines discussed previously. After the first neural network flags a timeline as attack-like, we need to expand on the vectors that make up that timeline. The new data sets will not be a collection of timelines, but merely a collection of vectors. These vectors, however, are going to change slightly. We need to include certain characteristics with each vector to help us determine patterns in targeted nodes.
The nodes from the vector-timeline data sets include the date the information was stored, an IP address, and the associated domain. The new sets should include this same information, as well as the record type. We will also need some information about what currently lies at this domain. This is a bit of a gamble, because if this node has already been affected by an attack the results will be skewed. Some of the pertinent information about the domain is the TLD; how many levels are in the domain name (in other words: a quick count of how many “.” are in the remaining domain name string); and a boolean variable of whether or not the domain exists in a list of known relevant domain names (for example, security-related government sites, airline sites, banking sites, etc). The string may also be pattern matched and/or checked for key words to gather further information about what the domain is. After the characteristics have been determined, the vectors are fed into the network and a percentage is returned representing the probability that this node becomes a targeted node. The training sets for this network must include “TARGET” and “BYSTANDER” as tags.
Drawbacks and Shortcomings
Obviously, there are a couple potential snags. This is purely in theory, and the bumps along the road to creating such an AI are innumerable. Some prominent ones include the potential for tainted data due to an already compromised node being passed through the neural network under the assumption that the associated domain is not compromised; determining the probability threshold for which we assume a node is vulnerable; and the methods used to gather domain characteristics being weak.
In conclusion, the use of AI could drastically aid in early detection of DNS hijacking by analyzing data in realtime. After successful identification of an attack, it may be possible to collect characteristics about the domain and further predict which nodes may be targeted next based on previous known attack patterns.
Dahl, M. (2019, January 25). Widespread DNS Hijacking Activity Targets Multiple Sectors. Retrieved from https://www.crowdstrike.com/blog/widespread-dns-hijacking-activity-targets-multiple-sectors/.
Hirani, M. (2019, January 10). Global DNS Hijacking Campaign: DNS Record Manipulation at Scale. Retrieved from https://www.fireeye.com/blog/threat-research/2019/01/global-dns-hijacking-campaign-dns-record-manipulation-at-scale.html.
Krebs, B. (2019, February 18). A Deep Dive on the Recent Widespread DNS Hijacking Attacks. Retrieved from https://krebsonsecurity.com/tag/dnspionage/.
Rascagneres, P. (2018, November 27). DNSpionage Campaign Targets Middle East. Retrieved from https://blog.talosintelligence.com/2018/11/dnspionage-campaign-targets-middle-east.html.