You can read part-1 (Passive Subdomain Enumeration) here.
Active sub-domain enumeration techniques
Brute force or Dictionary Attacks
Brute force means guessing possible combinations of the target until the expected output is discovered. So, in the subdomain context, the brute-forcing is to try the possible combination of words, alphabets, and numbers before the main domain in order to get a subdomain that is resolved to IP address. Sometimes subdomains are not indexed on search engines and are not available on online DNS aggregators sites in that case brute forcing is the best way to find out the subdomains which may have been forgotten by the organization. It is like a treasure for an adversary.
Two techniques for subdomain enumeration using brute force:
- Dictionary brute force
- Permutation brute force
Dictionary brute force:
In the dictionary brute force, we directly use the wordlist to a brute force domain name to find valid subdomains.
Permutation brute force:
In permutation brute force, we create a new resolved subdomain list from already known subdomains/domains by using permutation, mutation, and alteration with a wordlist.
By Zone Transfer
DNS zone transfer is the process of replication DNS database or DNS records from the primary name server to the secondary name server.
The DNS zone transfer functionality used by an adversary only when the primary name server is configured to replicate the zone information to any server. An adversary acts as a slave and asks the master for a copy of the zone records.
Why we need DNS zone transfer?
If the primary name server goes down, then the secondary server handles all DNS requests.
If many DNS name resolution requests occurred, then the secondary name server load balances these requests.
If the primary name server is located on the slow WAN link, then the secondary name server handles the name resolution requests.
Types of information gathered by zone transfer
- Email address (Could help in phishing)
- Current serial number (Change in serial no. may indicate changes in the organization)
- Email server (Could help in phishing)
- Name server
- Location may be disclosed by LOC record
- The IP address of the website
- Services running in the organization by SRV record
Command to check zone transfer
dig ns zonetransfer.me +noall +answer dig axfr @nsztm1.digi.ninja zonetransfer.me
host -t ns zonetransfer.me host -t axfr zonetransfer.me intns1.zonetransfer.me
By Domain Name System Security Extensions (DNSSEC)
Domain Name System Security Extensions (DNSSEC) is used to protect the integrity and authenticity of the data in DNS by establishing a chain of trust.
Before an understanding of DNSSEC, we first need to understand the basics of DNS:
What are the DNS functionalities?
- DNS is used to translate a domain name to IP address or vice-versa.
- DNS works on both TCP and UDP but normally works on UDP port 53.
- TCP port 53 is used when a very large request and response is sent, for example zone transfer.
www.example.com à 192.168.1.10
192.168.1.10 à www.example.com
Domain names are alphabet and they are easier to remember that is why we use domain names.
Before DNS the host.txt file was required to be regularly updated, which was distributed to all hosts on the Internet.
Issues with this are:
- The host file usually was huge after prolonged usage
- Regular manual updating was required
- Name uniqueness maintenance was required, which proved a difficult task.
How does it work?
When you enter a domain name in the browser (www.google.com), it first tries to resolve from the system host file, then passes the request to the ISP DNS server, then passes to another DNS server and this process continues until the request is not resolved. When the request resolves the response flow back to the DNS servers to the original requester that is a browser and then the requested website becomes accessible.
Basic DNS terminologies:
- Name servers
- Authoritative Servers
- Non-Authoritative/Caching Servers
- DNS Query
- Recursive DNS Query
- Non-Recursive or Iterative DNS Query
- Inverse Query
- An authoritative name server is the official name server that is authorized to provide an answer for a domain you are querying for.
- The authoritative name server can be more than one name server.
- There are two types of authoritative name servers based on the management method primary (master) and secondary (slave).
- Changes are done in the primary name server and the secondary name server/s will retrieve the copy of the zone file from the primary name server.
The non-Authoritative name server is the cache server, which cache the domain information for faster response to the domain you are querying.
DNS query is configured on the DNS server and accordingly, the DNS server works.
Recursive DNS Query
When a recursive query is configured on the DNS server then the DNS server does all the job on behalf of you to fetch the answer to your query. During this process, the DNS server might query other DNS servers on the internet for the answer.
Non-Recursive or Iterative DNS Query
When a non-recursive query is configured on the DNS server then the DNS server does not fetch the complete answer of the query on behalf of you but will give the address of other DNS servers, which might have the answer of the query. During this process, the DNS server might provide the IP address of other DNS servers on the internet for the answer and the operating system resolver will query until the domain name does not resolve.
Inverse DNS query works opposite to normal DNS query. Inverse DNS query or reverse DNS query is used when the user wants to resolve an IP address to the fully qualified domain name (FQDN).
DNS Protocol Vulnerability
The original DNS protocol was not designed with security in mind, as the Internet grows, it becomes less trustworthy. There was no DNS data protection mechanism available which caused the below vulnerabilities:
- DNS data can be corrupted as it was transferred between primary server, secondary server, resolver or forwarder, cache server.
- DNS data transaction could be compromised as the primary server may send DNS records data to a wrong secondary server which could be in adversary control.
- There was no way to check the integrity of the DNS data.
Basic DNS Security Practices
- Run the updated version of DNS software.
- Restrict queries
- Prevent unauthorized zone transfers
- Run BIND with the least privilege (use chroot)
- Randomize source ports
- Secure the box
- Implement TSIG and DNSSEC
Two protection mechanism “Transaction Signature (TSIG) and DNS Security Extension (DNSSEC)” use for DNS data protection
Transaction Signature (TSIG)
- TSIG secure the transaction to protect zone transfer and dynamic update.
- TSIG make sure that DNS query (Ex: AXFR) come from right place and are not modified in transit.
- Work on shared secret key, which is configured on both master and slave DNS servers.
- TSIG is configured in DNS server (named.conf) file, not in zone file.
- A wrong key does not allow for the zone transfer and will be logged on the server log.
- Command: dig @<server> <zone> AXFR -k <TSIG key file>
dig @localhost example.com AXFR -k Key-ns1.net.+200+1337.key
DNS Security Extension (DNSSEC)
- DNSSEC is used to secure the zone data by making sure that the resource records are those records that are signed by the administrator of the zone.
- It protects the integrity and authenticity of the zone data by establishing the chain of trust.
- It uses digital signature to verify the zone data.
For signature validation DNSSEC add new DNS record types:
|Resource Record||Full Form||Function|
|RRSIG||Resource Record Signature||It contains a cryptographic signature|
|DNSKEY||DNS Key||It contains public key which is needed for verifying the RRSIG|
|DS||Delegation Signer||It contains the hash of the DNSKEY record|
|NSEC/NSEC3||Next Secure||It indicates which name is the next one in the zone and it is for explicit denial-of-existence of a DNS record|
RRset and RRSIG
The first step for securing the zone with DNSSEC is to group all the same type of records which is called resource record set (RRset).
Bundle into a single A RRset
www.example.com. 7200 IN A 192.168.1.10
blog.example.net. 7200IN A 10.0.1.1
admin.example.net. 7200IN A 172.16.2.20
RRsets are digitally signed with the private key of the zone server and signature are published in DNS as RRSIG. Public DNSKEY is also published to verify the RRSIG signature.
www.example.com. 4 IN A 126.96.36.199
www. example.com. 4 IN RRSIG A 5 3 60 (
20141029233238 20140929233238 4521 isc.org.
Zone Signing Key (ZSK)
- The private zone signing key is used to digitally sign each RRset and store them in RRSIG.
- The public zone signing key is used by resolver to verify the digital signature that are stored in RRSIG.
- The public zone signing key is stored in DNSKEY record.
- When DNSSEC resolver ask for a DNS record (e.g. A), the name server also return the corresponding RRSIG and then DNSSEC resolver ask for the public ZSK from the name server.
- If we trust the zone signing key, then we can trust all the records in the zone but what if zone signing key was compromised? So, to validate the public ZSK we used key signing key (KSK).
Key Signing Key (KSK)
- The KSK validates the DNSKEY record for zone signing key in the same way the ZSK validate the RRSIG record.
- The private KSK signs the public ZSK and public KSK, which is stored in DNSKEY record and create an RRSIG for the DNSKEY that stores the signature of the public ZSK and KSK.
- The name server stores the public KSK in another DNSKEY record.
- DNSSEC resolver uses the public KSK to validate the public ZSK.
- To establish the trust within the zone.
- The key signing key (KSK) is signed by itself, which does not provide any additional trust, an adversary may compromise the zone and alter all these keys. So, for complete trust we need parent child trust, for this delegation signer (DS) record is use.
example.com. 300 IN DNSKEY 256 3 8 ( AwEAAclob7q+ccvDwaTVuMM2ddGIynWyMwaZlhFrU6cC 0qknWoPpkq0gIwTrYf3DJY+eIKPVHxrM+o2AoRIVhubG jfv1bT5wTYrawZstS84ejCQ+ehA+8DxKyeWUEzW0ZMBe OhyeG0cuQVK/p6Z1E096JLu0DjgbabLspequkw4M+HT7 ) ; ZSK; alg = RSASHA256; key id = 57009
example.com. 300 IN DNSKEY 257 3 8 (
AwEAAdQ2ctHx8VmryndiOgpchXPdj3NwxMeUvAre6uYI 5KELlFJUghTHrz+/CzEc8CXG8wwQ4ZvAey0FGV2nJAFC ENMxoRiCz0oSiQQxryNhACd3RnE2/D7G+ShwlOM6w53E wUJ/lsgu5UevSxFC+eA3fKeL3TWR44PH4iJQp9QmfW5v 7qG8Sic/HQvBGBdOGfFtHAl0a4jDPBi57imS4YsHcUYD 9bsWmhYWSHJKZ66+JnTiMS0nQM69YwBF43QfDKurs5R6 qPUDiBlaMCzSxmlaBU6fsI1Mu/yIU8w1ewy26a42rUTU rPBC3Oa/zf9VQ8kpUrMZgJ7LEAA4xmR+qwWDh6U= ) ; KSK; alg = RSASHA256; key id = 28267
Delegation Signer (DS) Record
- Delegation signer (DS) record allows the transfer of trust from the parent zone to the child zone.
- The zone operator hashes the public KSK and gives it to the parent zone to publish the hash as a DS record.
- Whenever the resolver connects with the child zone, the parent zone also shares its DS record, which makes the trust between parent and child.
- The DS record in the parent zone helps the resolver to know that the child zone is DNSSEC enabled.
- DS records should not be added in the child zone.
example.com. 86400 IN DS 8401 5 1 ( 5248DB0EAE4E829924F19D33B005FBC8C4606058 )
Why do we use two keys?
So, now the question is what is the purpose of using two keys when both keys are from the zone itself.
We use two keys to protect the zone itself and to provide the parent-child trust, as making any modification in the key signing key (KSK) is a difficult process because we have to make a hash and change that hash into the parent delegation signer (DS) record. Changing the DS record is a multi-step process that can end up breaking the zone if it’s performed incorrectly. On the other side, changing the zone signing key (ZSK) is much easier. We just need a modification within a zone.
What if an adversary compromised the child and parent server then all the DS information would match. So, to trust the DS record first we need to understand the “Chain of trust”.
The Chain of Trust
- The chain of trust works by signing the delegate signer (DS) records by ZSK like any other RRset for the child’s keys, which means it stores the signing data into the RRSIG in the parent.
- The digital signature for DS stored is stored in the RRSIG record.
- For the chain of trust, in example.com the validating resolver asks “.com” for the ZSK public key, DS, and signature to verify the hash in the parent zone of the child KSK key and to verify the KSK of “.com”. Then the resolver asks the root (.) for the DS, ZSK, and signatures. The same process is also followed for root. The whole validation process repeats until we get to the parent’s public KSK.
Till now, example.com and .com check out, but what about root? There is no parent DS record to validate against.
For completing the chain of trust cycle, we must trust the security procedure done by humans.
For signing the root, the Root Signing Ceremony is performed every quarter to verify the public and highly audited way. In this ceremony, some selected individuals from the international community agree and sign the root DNS zone’s RRset for the DNSKEY records. The ceremony produces an RRSIG record that can be used to verify the root name servers public KSK and ZSK. Instead of trusting the public KSK because of the parent’s DS record, DNS resolver assumes that it’s valid because we trust the security process in which the Root Signing Ceremony was performed.
NSEC/NSEC3 (Explicit Denial of Existence)
In traditional DNS setup, when we ask DNS for the IP address of a domain that does not exist, it returns an empty answer. So, how do we authenticate that the requested domain exists? As there is no message to sign. The fix for this issue was to add NSEC and NSEC3 record types that explicitly tell a DNS resolver that a given zone does not exist.
The NSEC record is used to prove that something really does not exist, by providing the name before it, and the name after it.
NSEC works by returning the “next secure” record. The NSEC record allows for proof of non-existence for record types. For every existing name, there is a corresponding NSEC record. This NSEC record states what types are available for the current name, as well as the next valid name, is in the sorted zone file. This brings us to the downside of NSEC: Since the NSEC records essentially chain through the complete zone, it is possible to do “zone walking”.
Let’s assume a request is made for example.com
dig NSEC example.com
example.com. 3600 IN NSEC api.example.com. A NS SOA MX TXT AAAA RRSIG NSEC DNSKEY
dig NSEC api.example.com
api.example.com. 3600 IN NSEC beta.example.com. A NS SOA MX TXT AAAA RRSIG NSEC DNSKEY
In the same way, the adversary can use it for zone walking and enumerate all subdomains in the zone.
NSEC3 uses a hashing algorithm to list the next available domain in the “hashed” format. It is still possible for an adversary to do zone walking, although at a higher computation cost.
- The user enters the example.com in the browser to access the website.
- DNS request transfer to resolver for the DNS resolution.
- Resolver query example.com nameservers for the A record and in this query, resolver add DNSSEC bit, which notifies the nameserver that resolver is DNSSEC enabled and DNSSEC Answers are desired.
- The name server is DNSSEC enabled, so the nameserver responds with the answer to the “A record” query with the RRSIG of “A record” which is the digital signature for the verification purpose.
- For digital signature verification, the resolver asks the nameserver for the public key which is DNSSEC (ZSK and KSK) records.
- Nameserver responds with DNSSEC (ZSK and KSK) and RRSIG of the DNSSEC records.
- The DNSSEC(ZSK) record is used to verify the RRSIG of the “A record”, the answer is received in step 4, and DNSSEC (KSK) record is used to verify the RRSIG of the DNSSEC (ZSK and KSK) record.
- For the chain of trust, the resolver queries the parent (.com) for the DS record that is hash of the of example.com KSK.
- Parent (.com) nameserver responds with the DS record and RRSIG of the DS record.
- The DS record is the hash value of the child KSK that is stored in the parent DS record. The resolver verifies the RRSIG record of the KSK in the child by decrypting the digital signature and comparing the hash of the DS record with the hash of the RRSIG KSK after decryption.
- Resolver query the .com nameserver for the DNSKEY to verify the RRSIG of the DS record.
- Parent (.com) nameserver responds with the DNSKEY (ZSK and KSK). The resolver decrypts the RRSIG of the DS record with the ZSK public key and verifies the result. RRSIG of KSK verifies by the KSK public key.
- For the chain of trust, the resolver asks the root (.) for the (.com) DS record, which is the hash of the .com KSK.
- Root name server responds with DS record and RRSIG of DS. The DS record is used to verify the KSK of the (.com).
- Resolver query for the DNSKEY of the root to verify the RRSIG record of DS.
- Root nameserver responds with the DNSKEY, resolver decrypts the RRSIG of the DS with the root ZSK and compares the DS values. Public root KSK is used to decrypt the RRSIG of the ZSK and compare the ZSK for the trust. If all the results are verified, then all zones and records are trustable.
Tools for NSEC subdomain enumeration
Subdomain Enumeration by DNS Records
In DNS zone file CNAME stands for a canonical name. CNAME is used in the domain name system (DNS) to create an alias or pointer for one domain name to another domain name.
example.com A 192.168.1.1 documents.example.com CNAME example.com
Let say, example.com is the domain name that connects with the file server, where you store all the personal files, but you want to access the same server with documents.example.com for better understanding. So, for accessing the domain with documents.example.com you have to create an alias or pointer that points to example.com.
Sometimes CNAME reveals an organization subdomain or reveals information about third-party services like Amazon.
SPF is the Sender Policy Framework as the name suggests. It is a policy that is used for whitelisting the IP address and domain names which are authorized to send an email on behalf of your domain. SPF is the list of IP addresses and domains that are allowed to send an email on behalf of your domain.
So, when you send an email let say from the example.com domain to the gmail.com domain. The Gmail that receives the email will check if the IP address of the mail server that sent the email is included in the SPF record of the example.com zone file.
If the sending IP address is in the list, the email will pass the SPF check and mail will likely be delivered.
If the sending IP is not on the SPF record, it likely not to be delivered.
An adversary uses this information to understand the organization’s infrastructure, IP addresses, third-party email services, internal netblocks, and subdomains. The SPF record is defined using the TXT record. So, whenever one searches for an SPF record, it should be searched by the TXT record.
Netblocks, ASN, and Domain names extractor from SPF Record
Subdomain Enumeration by HTTP Header
Content Security Policy (CSP) is a response header that tells the browser from what sources it is allowed to include and execute resources.
It is like a filter where sources are mentioned and in sources, the domains and subdomains are mentioned. An adversary may use this information to enumerate more subdomains and other domains that are allowed by the organization.
Domain extraction from CSP
The blog post covers different active techniques of subdomain enumeration. These techniques provide information regarding all the domains/subdomains of the target organization. The information contains all those subdomains that currently may or may not be in use by the organization. As these are active reconnaissance techniques, the adversary or tester gathers the information by directly probing the infrastructure managed by the organization. The detection of adversary or tester may be possible by the organization. Such kind of probing may raise alerts and/or flags. It also provides an understanding of the target organization’s infrastructure and web technologies which will be helpful for further attacks.
You can read part-1 (Passive Subdomain Enumeration) here.