Today’s blog post is about creating a DNS subdomain canary to capture when an attacker is brute forcing/enumerating subdomains in an internal environment using tools such as DNSRecon. Using DNSRecon recommends using DNS Wordlist DNSMAP which is located here: DNS Subdomain List. We are going to pick one from random from this list to make our it the DNS Canary. Let’s say we pick the canary to be ”secure”. Now, we have to create the entry; secure.DOMAIN.TLD. Since my domain is area1337.com, it should be secure.area1337.com. I personally use BIND but this can done with any DNS servers with Logging capabilities. In BIND, we want to add both a forward lookup and reverse to make sure it looks legit: Forward lookup: secure IN A 192.168.1.25 Reverse lookup: 25 IN PTR secure.area1337.com ; 192.168.1.25 Now let’s restart the service and check if its working.
nslookup secure.area1337.com 192.168.1.18
If everything is working this should show up. Now let’s check /var/named/chroot/var/log/dns_queries.log, to confirm if the DNS requests does show up in the logs.
As we can see here the requests are being logged using BIND and Syslog. Now let’s switch over to the malicious actor and use the DNSRecon tool to enumerate subdomains. I will be using Kali to do this. Let’s download the wordlist by Darkoperator, also used by default in the Metasploit DNS enum : auxiliary/gather/enum_dns. Use the following command to download the wordlist:
Now let’s run DNSRecon with the BRT option command and see the output: The actor was able to brute force the canary entry we create but we also were able to see the canary on our logs. We can see again in the logs that IP ADDR (192.168.1.201) has made the secure.area1337.com Canary DNS requests to our internal server. If these logs were ingested into a log, we can create alerts that sends us e-mail when this is triggered that provides insight into what’s going on. This can DNS Bruteforcing attack can also be detecting by searching for actor making 100 DNS requests to your DNS Assets in a 15 second span. In future blog post, I will create a second part of this to capture when a virtual hosts that uses the subdomain it will gather information about the actor. The virtual hosts will used for assurance to make the actor actually visited the subdomain instead of using the ip address.