Blacklists and Fast Flux Domains

1. Blacklists

Several web pages that maintain blacklists exist these days. These web pages maintain IP addresses and domains that are believed to be malicious, but the problem is that there are quite a lot of those pages and we don’t have the time to check them all. Fortunately, several web pages exist that send queries to all the other maintained web pages that contain the blacklists and present the results on the united web page. An example of such a web page is the Anti-Abuse Project, which automatically checks IP addresses and domains against different blacklists.

If we visit the web page of the Anti-Abuse Project that is located on the address http://www.anti-abuse.org/, we will be presented with a web page as shown below:

At the top of the web page we can see two links. The first is for Multi-RBL Check, which will scan the IP address of the domain against the real-time blacklists, and the second link is the RBLmon web page that monitors the IP address or domain in real time and notifies us as soon as the entered IP address or domain appears on at least one of the blacklists.

1.1 Multi-RBL Check

The Multi-RBL Check web site looks like this:

We must enter the IP address or domain into the input field, in our case 66.7.209.205, and click on Check. Upon completion, multiple blacklists are scanned and the results are shown below:

In the picture above only a few of the blacklists are shown because there are just too many of them to present them all in one picture. We can see that the IP address 66.7.209.205 is not listed on any of the blacklists presented. If the IP was listed in one of the blacklists, the square would have been red instead of green.

1.2 RBLmon

The RBLmon is an automated online service that allows us to monitor an IP address of a domain against the various blacklists in real-time and send an email as soon as the IP address or domain appears as blocked in any of the blacklists.

The web page looks like this:


We need to register an account. Upon doing that and logging into the RBLmon, we’re presented with a user interface as seen below:

We can see that we haven’t configured any IP addresses just yet. Let’s add a new IP address 66.7.209.205 (infosecresources.com).

We can freely add up to three addresses, but if we want to monitor more IP addresses we have to pay for their service. If we use a free account, the frequency of checking whether the IP addresses are blacklisted is once per two days, whereas otherwise it’s one a day. We can see different membership packages here:

Once we’ve set-up our IP addresses we would like to monitor, everything should be working fine. The RBLmon should check the IP address against blacklists once every 2 days and we should receive an email about our IP being blacklisted. If the IP address wasn’t blacklisted in any of the blacklists we’ll receive an email like below:

2. Fast Flux Domains

Fast Flux domains are used to make malware more resilient. The ideas is that one single domain has multiple IP addresses associated with it. When a query against the domain name is made, a different IP is returned each time (thus the IPs are changed in a round-robin fashion). If one server is taken down by the government, the other IPs are still operational and the malware can still operate successfully without downtime. The servers that were taken down will be replaced by new servers by the attackers who wrote the malware.

A round-robin DNS technique is used for this to work. The round-robin technique is usually used for load distribution, load balancing or fault-tolerance, but in fast flux domains multiple nodes are registering and de-registering their addresses as part of the DNS round-robin IP addresses. This combines a round-robin DNS with very short time to live values, which forces that DNS resolves to a different IP every 5 minutes or so.

We can’t block or take down IP addresses associated with fast flux domains, because there is normally too many nodes and we can’t take them all down. A better way to fight against those fast flux domains is to take down the domain itself, because there is normally just one domain.

The fast flux domains can be identified with the host command where we query a specific domain for IP addresses that it uses. In case there are multiple IP addresses returned, the likelihood of a malicious fast flux domain increases. But multiple IP addresses don’t necessarily mean we’re dealing with a fast flux domain. A good example of this is Google, which uses the same domain for load balancing. Let’s present the results of running the host command on a google.com domain:

$ host google.com
google.com has address 173.194.39.72
google.com has address 173.194.39.69
google.com has address 173.194.39.70
google.com has address 173.194.39.64
google.com has address 173.194.39.66
google.com has address 173.194.39.67
google.com has address 173.194.39.68
oogle.com has address 173.194.39.73
google.com has address 173.194.39.78
google.com has address 173.194.39.65
google.com has address 173.194.39.71

There are multiple IP addresses tied to the same domain, but in the case of Google, we can be pretty sure the domain isn’t malicious :). If we query the same domain again a couple of moments later, we can see that the order of IP addresses has changed:

$ host google.com
google.com has address 173.194.39.71
google.com has address 173.194.39.65
google.com has address 173.194.39.78
oogle.com has address 173.194.39.73
google.com has address 173.194.39.68
google.com has address 173.194.39.67
google.com has address 173.194.39.66
google.com has address 173.194.39.64
google.com has address 173.194.39.70
google.com has address 173.194.39.69
google.com has address 173.194.39.72

The IP address 173.194.39.72 is now listed as last and before it was first; it looks like the IP addresses are part of the round-robin DNS load balancing. In the case of malicious domains, the round-robin DNS load balancing ensures that the bad IP addresses won’t always be returned first. When a single node is taken down, a single IP address is unreachable, because the server doesn’t exist anymore. In such cases the IP address will still be returned, but won’t be accessible over the Internet. Usually, such nodes will be replaced by good new nodes corresponding to the new IP address and the old non-valid IP address will be removed from DNS load-balancing and a new valid IP address will be added.

To ensure that the domain is actually a fast flux domain, we need to query the domain for IP addresses with the host command several times at different time intervals and check whether the returned IP addresses are the same (never mind the order of them). If they are not the same, we can be pretty sure we’re dealing with a fast flux domain, since the IP addresses of the fast flux domains change frequently over time.

We can also detect fast flux domains because the returned TTL value is usually 0, which means that the DNS servers will not cache the returned IP address, but will always send a new request when a query to resolve that domain into an IP address is sent. This allows the attackers to frequently update the IP addresses of the domain in question with non-stale information being stored on the Internet. We can get the time to live value of the domain with the dig command as follows:

# dig infosecresources.com | grep -A 1 "ANSWER SECTION"
;; ANSWER SECTION:
infosecresources.com.   13266   IN      A       66.7.209.205

The TTL value in the case above is 13266 seconds, which is approximately 3 hours. If we execute the same query on the domain google.com we get the results below:

# dig google.com | grep -A 1 "ANSWER SECTION"
;; ANSWER SECTION:
google.com.             277     IN      A       173.194.39.72

The TTL value is 277 seconds, which is approximately 4 minutes. The TTL value in this case is considerably lower because of the DNS load balancing. This prevents the DNS servers from caching the value for a longer period of time.

But if we would execute the above query on a fast flux domain, we would probably receive a TTL value 0, which means that DNS servers shouldn’t cache the IP address; this effectively forces the DNS resolution mechanism to ask for a new IP address every time and not return a stale cached (possibly taken down) IP address that would no longer work.

3. GeoIP

It’s always a good idea to know the location of the IP address. We can install the GeoIP package right from our repository. On Linux we can do that by executing the following command:

# easy_install pygeoip

Once installed, we can simply run Python interpreter and import the pygeoip library to have access to the geographical information about the IP address. But we also need GeoIP.dat or GeoLiteCity.dat database. We can download one from the maxmind web site as follows:

# wget <a href="http://www.maxmind.com/download/geoip/database/GeoLiteCity.dat.gz">http://www.maxmind.com/download/geoip/database/GeoLiteCity.dat.gz</a>
# gunzip GeoLiteCity.dat.gz

Afterward we can run python interpreter, import the pygeoip library and feed it the IP address of the domain, upon which it will return the geographical information. We can see that below:

Want to learn more?? The InfoSec Institute Ethical Hacking course goes in-depth into the techniques used by malicious, black hat hackers with attention getting lectures and hands-on lab exercises. While these hacking skills can be used for malicious purposes, this class teaches you how to use the same hacking techniques to perform a white-hat, ethical hack, on your organization. You leave with the ability to quantitatively assess and measure threats to information assets; and discover where your organization is most vulnerable to black hat hackers. Some features of this course include:

  • Dual Certification - CEH and CPT
  • 5 days of Intensive Hands-On Labs
  • Expert Instruction
  • CTF exercises in the evening
  • Most up-to-date proprietary courseware available
>>> import pygeoip
>>> ip = pygeoip.GeoIP('GeoLiteCity.dat')
>>> ip.record_by_name('infosecinstitite.com')
{'city': u'Burlington', 'region_name': u'MA', 'area_code': 781, 'time_zone': 'America/New_York', 'longitude': -71.2047, 'metro_code': 'Boston, MA', 'country_code3': 'USA', 'latitude': 42.5051, 'postal_code': u'01803', 'dma_code': 506, 'country_code': 'US', 'country_name': 'United States'}

We can see that we’ve gotten quite a lot of information, such as the city, the region, the latitude and longitude, etc.

3. Conclusion

We’ve seen how to identify if an IP address or domain name was blacklisted, which we can use to identify if we’ve been infected by some kind of malware. There are other better ways of doing that, but nevertheless this is one option of identifying if we’re been infected. Usually it’s too late for blocking the attack, but at least we know our network has been compromised and we can do something about it.

We’ve also seen what are fast flux domains and how to identify them.