- These techniques can reveal your interest in the target organization to anyone in your network path, so consider using a VPN or tor to conduct searches.
- When performing "active enumeration" it is always good to ask to whitelisting your IPs whenever you perform assessments. This rules out the idea of attackers having able to avoid shunning. Whitelisting your IPs also removes false positive reports and inaccurate results
- It is important that we verify that we have the correct target domain(s) before proceeding with any of the scans/audits/assessments exercises within SAFETAG Framework. The last thing we wouldn't want to happen is to scan and enumerate target which is out of scope!)
The flexibility of having multiple options in performing a DNS enumeration activity is the key for a successful enumeration. As a practice, comparing results can help in assuring that the information we gather is accurate.
A note on DDoS Protection Services Your investigation may be blocked by DDoS protection services which operate at the DNS level such as Deflect or CloudFlare. "CloudFlair" provides some options in this case, as does tracking DNS and IP history to see if only DNS records changed.
One way to identify if a website is using DDoS service or not is by investigating it's DNS record. Since that we're working with organizations may not have enough funding to subscribe to a DNS mitigation service, lot's of time you will see them not using DDoS protection.
Server Names or your
A Record that points to a particular 3rd party CDN DDoS service such as the following examples:
- brianna.ns.cloudflare.com (Cloudflare) - toby.ns.cloudflare.com (Cloudflare) - 4k9o.x.incapdns.net (Incapsula) - e3396.dscx.akamaiedge.net (Akamai)
If these appears on your result, then there's a high probability that your target is behind DDoS service
DNS Enumerations Tools:
|Robtex||Gathers public information about IP numbers, domain names, host names, Autonomous systems, routes etc, then indexes the data in a big database and provide free access to that data||Online||Passive|
|DNSdumpster||Free domain research tool that can discover hosts related to a domain, results with banners for HTTP, FTP, SSH & Telnet||Online||Passive|
|CentralOps-Domain Dossier||Investigates domains and IP addresses. Gathers registrant information, DNS records, Network and Domain Whois Records, services scans and traceroutes||Online||Passive|
|DNSSEC Analyzer||Checks for DNSSEC keys managment and configurations records||Online||Passive|
|Recon-ng||Automated web reconnaissance framework written in Python. Complete with independent modules, database interaction, built-in convenience functions, interactive help and command completion.||Script||Active|
|IntoDNS||IntoDNS checks the health and configuration of your DNS and provides report on MX records too. Provides suggestions to fix and improve findings||Online||Passive|
|YougetSignal||Helps you find other sites being hosted on a particular IP address, verifying if the target is using a shared hosting service||Online||Passive|
|DNSRecon||A Python script written by Carlos Perez for conducting DNS reconnaissance. It can enumerate general DNS records, perform zone transfers, perform reverse lookups, and brute-force subdomains among other functions. It will even perform Google scanning, automating the process we discussed in the Using Google to find subdomains section.||Script||Active|
|DNSenum||multithreaded perl script to enumerate DNS information of a domain and to discover non-contiguous ip blocks.||Script||Online|
Specific instructions for selected tools/techniques follows:
Variant: Passive: Third Party and Online Tools
Using 3rd party and online tools can help an auditor/tester in avoiding his/her machine to generate logs on the target's end. In cases where the target, or partner organization who requests for an audit/assessment has some security devices in place (IDS/IPS, Firewall etc.) Generating logs from your machine/network may result sometimes in our traffic getting blocked due to "automatic blocking" features in these security devices/appliances.
Passive tools include:
Variant: Active: DNSrecon
DNSrecon (available in Kali 2017 Release) is a powerful DNS enumeration script that can help and auditor in gathering information during the recon stage. This tool checks all NS records for Zone transfers, enumerate general DNS records for a given domain (MX, SOA, NS, A, AAAA, SPF and TXT). Performs SRV record enumeration and TLD (Top Level Domain) Expansion to name some.
This exercise will help you in performing some of the DNS enumeration methods using DNSrecon and generate information which you can add to your database to be used for other avenues of testing.
Perform basic DNS enumeration on target:
[email protected]:~# dnsrecon -d <target domain>
Perform DNS Zone Transfer enumeration:
[email protected]:~# dnsrecon -d <target.domain> -a [email protected]:~# dnsrecon -d <target.domain> -t axfr
Perform Reverse Lookup:
[email protected]:~# dnrecon -r <start-IP-to-end-IP>
[email protected]:~# dnsrecon -d <target.domain> -D <namelist> -t brt
[email protected]:~# dnsrecon -t snoop -n Sever -D <Dictionary>
[email protected]:~# dnsrecon -d <target.domain> -t zonewalk
Variant: Active: DNSenum
DNSenum, just like DNSrecon, is a tool designed to analyze DNS information of a specific DNS target. From zone transfer, hostname and subdomain dictionary brute force, reverse lookup service record and standard record query and top level domain name expansion, results are almost identical for both assessment tools.
You can use DNSenum from the Kali terminal and MSF Console platform as an auxilliary.
To access DNSenum, simply type the command
dnsenum. (You can add
-h for help options.)
[email protected]:~# dnsenum
The table below will help you get started with your DNS enumeration using
||Performs basic DNS enumeration|
||Performs fast enumeration
||Performing hostname and subdomain directory bruteforce using the
|dnsenum -f list.txt -s 5 -p 5
||Enumerate using subdomain list,
||Enumerate target with subdomain list
Variant: Active: DNS Zone Transfer
Anonymous individuals online can request the full list of the hostnames on the organizations domain. Responding to zone requests from anyone on the Internet is comparable to providing an inventory of office locations, pending projects and service providers to anyone who asks. As such, it is not inherently dangerous, but it does require that the organization not rely on the assumption that unpublicized URLs are in fact secret.
An overly permissive domain name service (DNS) provider allows an attacker to enumerate online services that the organization might think are “hidden” because they have not been (intentionally) published. A zone transfer returns all of the hostnames at a particular domain, or “zone.” So, a request for sample.org may return www.sample.org, webmail.sample.org and ftp.sample.org, along with other less obviously guessable targets, such as wordpress-testing.sample.org.
While any user should be able to use a name server to look up a hostname and convert it to the corresponding IP address, most well-administered name servers allow full “zone transfer” requests only from a specific list of authorized locations (often themselves subsidiary name servers).
Determine the authoritative name server(s) for the organization’s primary domain:
$ host -t ns sample.org sample.org name server ns1.something.net. sample.org name server ns2.something.net.
Attempt a zone transfer on that domain, using that name server:
$ host -l sample.org ns1.something.net Using domain server: Name: ns1.something.net Address: 2184.108.40.206#53 Aliases: www.sample.org has address 2220.127.116.11 mail.sample.org has address 218.104.22.168 webmail.sample.org has address 222.214.171.124 ftp.sample.org has address 2126.96.36.199 foo.sample.org has address 2188.8.131.52 bar.sample.org has address 2184.108.40.206
Variant: Active: MX Records
MX, or Mail Exchange, records are required to be public for any domain you wish to receive email through. These records can still reveal sensitive information about an organization's hosting set-up and office software in use through further scanning (see Vulnerability Scanning). MX Records can reveal vulnerable mail servers or information about other services hosted internally. Unless other assessments reveals specific vulnerabilities in e-mail services used, there is no specific action to take. If an orgnization is self-hosting email, it may be advisable to suggest outsourcing that if funds permit. While self-hosted email provides more control and potentially security, managing the security of the server is a complex job. Other mail services can provide some level of protection by being a first-pass check for spam and viruses, and (slightly) reducing the visibility of an organizational mail server.
[email protected]:~# host -t mx sample.org sample.org mail is handled by 21 mail.sample.org
Determine the IP address of the mail server:
[email protected]:~# host mail.sample.org mail.sample.org has address 2220.127.116.11
DNS is inherently public information, but we can still do a lot of steps to secure any parts of it which are revealing more private information. Fortinet provides a set of good recommendations:
If the site is not protected from DDoS attacks, there are multiple resources which provide not only DDoS protection but additional security against attacks, such as:
If a zone transfer was successful, (most providers automatically limit anonymous zone transfers), you will need to work with their support team to prevent this, or switch to a different DNS provider. If your organization maintains its own DNS servers, the administrator of those servers should check the zone transfer policies to prevent anonymous transfers.