CREDIT: Pierluigi Paganini
The security community is observing a sensible increase of botnet activities, in particular of cloud-hosted botnets that are mainly based on the Amazon cloud architecture.
Amazon isn’t the only provider that’s been abused by cybercrime. “Cheap hosting” providers represent a privileged choice for bad actors because they usually implement a poor monitoring system and a put in place a few safeguards to prevent bad bot origination.
The financial services industry is the one that serves up the highest botnet traffic, according to recent research proposed by Distil Networks Security.
The DNS sinkhole is a technique adopted by principal security firms to analyze malicious traffic related to a botnet, spyware and any other kind of malware. The principle is very simple: security experts analyze outbound DNS requests for malicious domains and interfere with communications that occur between the infected machine within a targeted organization and the malicious domains that usually host malicious code and command and control servers.
The term sinkhole indicates a standard DNS server that is configured to provide non-routeable addresses in response to the DNS requests for all domains in the sinkhole. All the computers that refer to it for naming resolution will fail to get access to the real website.
Practically, DNS sinkholing consists of the spoofing of the authoritative DNS for malicious domains. The administrator configures the DNS forwarder for outbound traffic in a way to return wrong IP addresses for bad domains. With this technique, specialists can analyze the overall traffic to an unwanted domain, estimate the entity of an infection, and apply the necessary mitigation strategy.
“Sink Holes are the network equivalent of a honey pot.” (Green, Barry Reveendran & McPherson, Danny 2003)
The DNS Sinkhole technique could be used to decapitalize a botnet (destructive mode) by interrupting the bot access to the Command & Control servers, or to monitor the activities of bad actors (monitoring mode). DNS sinkhole could be used to mitigate different types of cyber threats that adopt DNS resolution.
One use is to stop botnets by interrupting the DNS names the botnet is programmed to use for coordination.
Security firms use it to analyze the connections to bad domains to discover the clients that have been compromised by the cyber threat.
To mitigate the threats, administrators could use the techniques interfering with all the connections to domains included in the lists of malicious domains. On the Internet numerous entities provide constant updates for these lists (e.g. SANS Internet Storm Center). Sinkhole administrators could benefit from these open sources that list bad domains. Let’s think, for example, to establish an intrusion detection policy based on the analysis of outbound DNS requests for the malicious domains included into public black lists (e.g. http://pgl.yoyo.org/as/serverlist.php?showintro=0 ). The administrators could also contribute to the improvement of the lists, providing further information elaborated from the observation of the infected systems within their infrastructure.
Note that there isn’t an official and authoritative list of sinkholes and the reason is intuitable. Sinkhole operators try to keep their structures reserved. To avoid that, botnet operators implement mechanisms to avoid sinkholes.
The DNS sinkhole technique doesn’t request a significant effort to network administrators. They could use a well-known DNS zone file to manage unwanted hosts and domains that are typically noted in public lists maintained by a community of security experts. The principal benefits related to the use of the sinkhole technique are its limited cost, scalability of solutions, and easiness to maintain.
One of most common Sinkhole solutions is based on an internal DNS sinkhole server that is used by administrators to impersonate an authoritative DNS server for blacklisted domains. Of course for single entities it is also possible to implement a sinkholing technique using the local host’s file.
The servers responds to the DNS queries for unwanted domains with private addresses. For the efficiency of the technique, it is crucial to maintain an updated list of malicious domains.
To improve overall security of systems, it is possible to adopt Intrusion Prevention Systems that analyze outbound DNS requests looking for anomalies in the related packers. A typical indicator for illicit activities is for example the presence of a packet with a a short DNS time-to-live (TTL). This setting allows us to rapidly propagate changes.
It is important to understand that DNS sinkhole is efficient to detect indicators for the presence of malware, but it could not be considered a method to detect or eradicate malware.
Another typical limitation of the technique is represented by its inefficiency to block malicious codes that don’t use an internal DNS server. Malware authors in many cases use IP addresses equipped with a built-in DNS server, which will never be detected by sinkhole servers of the targeted company.
As explained in a paper published by the SANS organization, a possible mitigation strategy for malware that doesn’t refer the internal sinkhole server is represented by the regimentation of outbound DNS queries. Administrators can authorize traffic only from authorized DNS servers.
One of the principal problems is represented by a false positive. A sinkhole erroneously blocks traffic to non-malicious domains with serious impact on the organization.
Malware inside our network
Once a victim machine is infected by attackers, via phishing attack or a watering hole, the malicious agent dropped on the machine resolves a malicious domain name to retrieve the IP address for the command & control server. The authoritative DNS server responds to the DNS query sent by the malware. In this way, the malicious core retrieves the IP address for the bot controller and establishes the connection.
The most simple DNS Sinkhole architecture includes the following components:
Figure – DNS Sinkhole (SANS.org)
In the above image is shown the flaw for domain name resolution in the presence of a Sinkhole server.
Also, in this case the infected machine tries to resolve a malicious domain name to retrieve the IP address for the command & control server. The DNS Sinkhole server intercepts the DNS query sent by the malicious code on the infected machine. The request is captured by the internal DNS Sinkhole server that acts as the authoritative DNS server and provides in response a fake IP address.
In the above scheme, the DNS Sinkhole receives the DNS request for the malicious domain and responds with an authoritative answer configured by the administrator. In this way, the bot will not be able to contact the command & control server.
In the image the DNS Sinkhole returns with an IP of 127.0.0.1 to force the client to connect to itself instead the bot controller domain.
Real-time notification: Sinkhole and advanced detection
The identification of the malicious agent is just a part of the administrative work. With the sinkholing it is also able to partially contain the threat, but it must be considered that malware, despite being unable to reach the C&C server, could try to propagate itself within the network anyway.
To improve the above solution, it is possible to add an IDS with customized sinkhole signatures for realtime alerting. In a typical scenario which includes an Intrusion Detection System, the compromised machine resolves a malicious domain name to retrieve the IP address for the command & control server. The DNS Sinkhole server responds to the DNS query sent by the malware, and the infected machine receives a legitimate IP address of the network. The IP address sent to the infected client by the DNS sinkhole is a re-direct to an IP address controlled by the administrators. The administrator configures on this IP address a listening service on most common HTTP ports (e.g. 80, 8000, 8080) to detect malicious activities.
To monitor traffic to a malicious domain, it is possible to write an IDS signature for each sinkhole group. The IDS will detect each time an infected system is redirected to the sinkhole.
Figure – DNS sinkhole+ IDS
Sinkholing data … a growing business with technical and legal issues
The continuous growth of principal cyber threats has increased the demand of companies for botnet data. In response to the commercial request, a growing number of companies provides different threat data types including botnet victim identities, malicious and unwanted domains, bad URL information, and much more.
This information is precious for companies that want to protect their networks from threats.
Behind many of these commercial feeds offered on the market, there are sinkholes, and as explained by experts at Damballa, there are quite a variety of sinkhole approaches:
“Ranging from passive systems that simply catalogue the IP addresses of devices that attempt to connect to them (in response to a domain that’s been forcefully extracted from the hands of a cybercriminal), through to active systems that are more honeypot-ish in nature (that engage in digital conversations with malware victims), and anything in-between – but in essence the sinkhole exists to extract information about previous victims and/or attempt to neuter a communication channel associated with a particular threat.”
Are sinkhole data really reliable?
There are different legal and technical issues related to the sinkholing practice. Let’s start from the principal limitations related the use of the passive sinkhole to harvest botnet data.
DHCP Churn – ISPs typically assign residential IP addresses from pools of dynamic IP address ranges. It is impossible to predict how long an IP address is assigned to a specific machine that is detected by a sinkhole server. This can cause a false positive.
Network Address Translation (NAT) – If the victim’s network includes a firewall or a router, there is the concrete probability that the IP gathered by a sinkhole is not linked to the real identity of the infected machine. In this case also the extension of the infection is missed. Behind a single IP address there could be dozens or hundreds of compromised PCs.
Timing Windows – One of the most important factors to evaluate for botnet data harvested by sinkhole data is the time. If it’s not possible to uniquely identify the compromised machine, it is crucial to identify the frequency in which it reaches out to the sinkhole servers. This calculation is hard due to the issued described in the previous points, DHCP churn and NAT.
Darknet Scanning – Thousands of devices crawl the Internet for various purposes. As consequences, even “hidden” sinkholes and darknets are constantly being probed, which affects data collected by this monitoring architecture. This generates false positive identifications.
The above limitations have a serious impact on the fidelity of harvested data, but other serious considerations are related to the legal sphere.
Data drops – When security experts hijack traffic related to a malicious domain, and if the malicious domain was intended to be used as the drop location for the victim’s stolen data (e.g. an FTP server), then the administrator for sinkhole servers will collect a huge quantity of personally identifiable information (PII) and/or sensitive documents. The maintenance of this information must be regulated by law. In these scenarios, it must be also considered that sinkhole operators are perpetuating the abuse; for example, by sinkholing a malicious or unwanted domain name, the malware may continue to upload data, continuing to cause the loss of personal and confidential information.
Device failure – If the compromised machine fails due the impossibility to communicate with the C&C server, there is an objective responsibility of sinkhole administration. Critical functions executed by compromised machine could be impacted by sinkholing activity.
Compromised machines seizure – Once the compromised machine is identified, their control and seizure is the responsibility of law enforcement.
Unauthorized access – Sinkhole operators in some cases could be able to manage remote access to compromised machines that was originally granted to command and control servers. Sinkhole operators could not abuse these acquired privileges.
CASE study Sinkhole activities – CERT.PL
Poland CERT has recently published a report on the activities conducted during 2013. The organization was very active in the botnet takeovers, with the most prominent examples being Citadel, Zeus, Dorkbot, Andromeda and Sality.
CERT also identiﬁed a rogue domain registrar, Domain Slver Inc., which specialized in the creation of domains exclusively used for illicit activities.
“The agreement with Domain silver Inc. was terminated, and the domains were successively taken over by CeRT Polska. Due to these activities.pl domain became a less attractive target for cybercriminals,” stated the CERT report.
The report also presents current trends in cyber threat scenarios, reporting details on principal incidents, but the scope of this post is to give visibility to their sinkholing operations.
The CERT data on botnets were collected from sinkhole and honeypot systems, P2P botnet crawlers, and not from antivirus systems. They used multiple sources to overwhelm the problems of fidelity described in the previous paragraph, helping to minimize the rate of false positives.
The experts at CERT discovered that in Poland there are not more than 300,000 infected computers active per day. They observed that there is a growing number of small botnets consisting of several thousand machines.
CeRT Polska has created a sinkhole server since 2012 to redirect malicious traffic from .pl domains. The IT architecture is composed of a DNS server, which responds with the appropriate IP address to the domain query, and a TCP server, which allows emulation of many types of C&C servers.
Domains are sinkholed by CeRT Polska servers in three ways:
By changing the A-record – by the request of CeRT Polska, a registrar changes the domain A record to point to the IP address of the sinkhole server.
By a takeover of a .pl domain – the records in the registry are changed to redirect the respective NS records to sinkhole.cert.pl. All queries of such domain are received by the sinkhole server and it replies with an appropriate IP address in response.
- As a side eﬀect – if domain name(s) used in NS records of another domain are sinkholed, then that domain is also eﬀectively sinkholed, because all queries for its names are resolved by the sinkhole server.
Figure – Domain Sinkholig CERT PL
In 2013, experts noticed several new botnets targeting Polish users. The criminal organizations behind them mainly targeted online banking customers. The malicious code served by cyber criminals was used to steal used login data and valid TAN codes to bypass the two-factor authentication process implemented by principal banking solutions.
Figure – Sinkhole data – CERT PL
Thanks to sinkhole activity, experts also verified that botnets are making large use of cryptography in the implementation of bots. Sinkholed Andromeda botnet used the RC4 stream encryption, the “Mobile Antivirus” application for Android phones used Aes encryption, and the popular CryptoLocker ransomware uses advanced cryptography.
In 2013, CERT PL received 12,674,270 submissions on 8,393,693 unique malicious URLs, including 1,486,066 submissions relating to 497,721 unique URLs in the .pl domain. The data confirm the intense activity of a criminal organization, an average of 1,363 malicious sites in the .pl domain per day.
Figure – Malicious domains 2013 (CERT PL)
The following table reports the list of the countries where servers with malicious sites in the .pl domain were located. In previous year the situation is unchanged, Poland is confirmed at the ﬁrst place of the ranking.
Figure – Countries with malicious domains
Sinkhole activity is a crucial part of botnet tracking. It is a powerful technique largely adopted by security firms, but is important to consider that it must be integrated with other methods to maximize its efficiency and fidelity of its data, reducing to a minimum value the occurrence of a false positive.
Next time you read a security report, please carefully evaluate the data extracted with this technique. Now you certainly have more info to analyze them.
CREDIT: Pierluigi Paganini