Identifying suspicious domains using DNS records

October 2, 2013  |  Jaime Blasco

Very often when cybercriminals are migrating to new infrastructure or when the previous has been taken down, they point their domain names (sleep) to temporary specific adresses including but not limited to:

  • 127.0.0.1
  • 127.0.0.2
  • 255.255.255.254
  • 255.255.255.255
  • 0.0.0.0
  • 1.1.1.1

Besides these, other common addresses where they point their domains are DNS servers and other infrastructure of big internet companies such as Google.

We are going to describe a couple of techniques that you can use to implement DNS logging in your environment and look for suspicious domains that follow this rule.

PassiveDNS

The first tool that we want to present is Passivedns. It is a set of tools that enable you to sniff traffic from an interface and output the DNS answers to a file that can be inserted into a Mysql database for further querying.

In order to process the traffic coming from the DNS servers, you should create a SPAN/Mirror port under your Router/Switch. You can check the following tutorials if you are not familiar with this process:

Once you are able to receive the traffic from your DNS servers or your internal systems are communicating with external DNS servers, follow the instructions to configure PassiveDNS.

After you setup the system, PassiveDNS will start collecting and storing the DNS responses that your internal systems are generating. From there you can use PassiveDNS’s web interface to query the system.

The following are a few examples of queries that you can use to identy domains matching the behavior we explained before:

Once you have found some of these domains, you can determine wheter or not they are malicious, detect the hosts these DNS queries originated from within your enterprise,

find other security events, extract IOC’s, etc.

Suricata-2.0beta1 + Alienvault USM

The second solution that we can use is based on the new beta version of Suricata that includes a module to log DNS requests and responses.

As you know, both Alienvault USM and OSSIM use Suricata as the IDS engine and we will include this feature in the product once Suricata publishes a stable version with that feature.

In the meantime, you can use the process we are going to describe using our Open Source OSSIM version.

- First of all, download and compile Suricata-20beta1:
wget http://www.openinfosecfoundation.org/download/suricata-2.0beta1.tar.gz
tar xvzf suricata-2.0beta1.tar.gz
cd suricata-2.0beta1
apt-get install libyaml-dev
apt-get install libmagic-dev
./configure
make

- Edit the suricata.yaml config file and add the dns-log statement:
vi suricata.yaml

  - dns-log:
      enabled: yes
      filename: dns.log
      append: yes

- Start Suricata:
./src/suricata -c suricata.yaml -i eth0 (the interface where you see the traffic)

If your system is receiving traffic, you will start seeing DNS logs in Suricata’s dns.log file:

lienvault:~/suricata-2.0beta1# tail /var/log/suricata/dns.log
09/18/2013-00:19:53.345953 [**] Query TX 538b [**] data.alienvault.com [**] A [**] 10.49.5.204:47749 -> 8.8.8.8:53
09/18/2013-00:19:53.345953 [**] Response TX 538b [**] data.alienvault.com [**] A [**] TTL 2076 [**] 70.38.37.7 [**] 8.8.8.8:53 -> 10.49.5.204:47749
09/18/2013-00:19:53.345953 [**] Query TX c4d3 [**] data.alienvault.com [**] AAAA [**] 10.49.5.204:47749 -> 8.8.8.8:53
09/18/2013-00:19:53.345953 [**] Response TX c4d3 [**] alienvault.com [**] SOA [**] TTL 161 [**] www.alienvault.com [**] 8.8.8.8:53 -> 10.49.5.204:47749
09/18/2013-00:19:53.655146 [**] Query TX 3ca8 [**] data.alienvault.com [**] A [**] 10.49.5.204:57663 -> 8.8.8.8:53

Now it is time to configure your Alienvault instances to collect this data. We have created a beta plugin that you can use to test this solution.

https://github.com/AlienVault-Labs/AlienVaultLabs/tree/master/plugins

  • Copy the file suricata-dns.cfg to /etc/ossim/agent/plugins/
  • Edit /etc/ossim/ossim_setup.conf and suricata-dns under sensor->detectors
  • Run alienvault-reconfig
  • Copy the file suricata-dns.sql to /tmp/
  • Execute ossim-db < /tmp/suricata-dns.sql
  • Restart ossim-agent and ossim-server:
  • /etc/init.d/ossim-agent restart
  • /etc/init.d/ossim-server restart

From there your OSSIM instance should be processing the logs coming from the Suricata DNS module.

In order to create a better view for these type of events, you can create a new view under “Custom Views”->”Create New View”

Using that view you should be able to see the following fields:

Using the Security Events console you can easily search for domains matching the criteria we want under “More Filters”->Userdata4 like:

The advantage of using this console is that you have the IP address of the machine the DNS request originated from, as well as other information about the related system in the same console such as Netflow data, IDS data, inventory, vulnerabilities, security events from other devices, etc. Thanks to that integration, the forensic investigation becomes much easier when you have to check if the system is compromised.

Share this with others

Tags:

Get price Free trial