Skip to main content
add CT logs
Source Link
Luc
  • 33.2k
  • 8
  • 81
  • 140
  • Certificate transparency logs may show for which subdomains certificates were obtained, e.g. see https://crt.sh.

  • Search results might reveal subdomains. Again, dnsrecon can do this with the -t goo option (uses Google specifically).

  • Checking other TLDs for the same name might reveal some other variants or IP addresses. E.g. if example.com exists, example.org might exist as well. dnsrecon can also do this with dnsrecon -t tld -d example.com.

  • Crawling a website or finding references elsewhere might give hints. (Help wanted: which tool to use?)

  • Looking at TLS certificates often yields results. Be sure to check the ports for HTTPS, SMTP(S), FTP(S), etc. and use STARTTLS.

  • There are third party tools which can list subdomains in a domain. Their methods are less clear, but crawling the internet and historical records (maybe a domain transfer was once possible?) are often part of it. (Help wanted: any recommendations? I only remember seeing that it exists.)

  • Search results might reveal subdomains. Again, dnsrecon can do this with the -t goo option (uses Google specifically).

  • Checking other TLDs for the same name might reveal some other variants or IP addresses. E.g. if example.com exists, example.org might exist as well. dnsrecon can also do this with dnsrecon -t tld -d example.com.

  • Crawling a website or finding references elsewhere might give hints. (Help wanted: which tool to use?)

  • Looking at TLS certificates often yields results. Be sure to check the ports for HTTPS, SMTP(S), FTP(S), etc. and use STARTTLS.

  • There are third party tools which can list subdomains in a domain. Their methods are less clear, but crawling the internet and historical records (maybe a domain transfer was once possible?) are often part of it. (Help wanted: any recommendations? I only remember seeing that it exists.)

  • Certificate transparency logs may show for which subdomains certificates were obtained, e.g. see https://crt.sh.

  • Search results might reveal subdomains. Again, dnsrecon can do this with the -t goo option (uses Google specifically).

  • Checking other TLDs for the same name might reveal some other variants or IP addresses. E.g. if example.com exists, example.org might exist as well. dnsrecon can also do this with dnsrecon -t tld -d example.com.

  • Crawling a website or finding references elsewhere might give hints. (Help wanted: which tool to use?)

  • Looking at TLS certificates often yields results. Be sure to check the ports for HTTPS, SMTP(S), FTP(S), etc. and use STARTTLS.

  • There are third party tools which can list subdomains in a domain. Their methods are less clear, but crawling the internet and historical records (maybe a domain transfer was once possible?) are often part of it. (Help wanted: any recommendations? I only remember seeing that it exists.)

Commonmark migration
Source Link

Windows:

 
nslookup
> server <DNS you are querying>
> set type=any
> ls -d <target>
 

Unix (nslookup is deprecated on Unix):

 
dig -t axfr @<DNS you are querying> <target>

Obviously that response needs to be signed, but generally the DNS server itself doesn't have access to your signing key and can't sign the response on-the-fly; the signatures are all created "offline" ahead of time. This keeps your key from being exposed if your DNS server gets compromised.

 

So instead, you alphabetize your subdomains and say "for every name between mail.example.com and pop.example.com, no other subdomains exist" and sign that assertion. Then when someone asks for nachos.example.com you can just give them that response (which has already been signed) and the client knows that because nachos.example.com falls alphabetically between mail.example.com and pop.example.com, then the "this domain doesn't exist" response is considered to be correctly signed and actually came from you.

 

The place where this becomes problematic is that by having a set of these negative responses which explicitly state that "no responses exist between X and Y, you can easily map out exactly which domains exist for the entire zone. You know that "X" exists, and you know that "Y" exists, and you know there is nothing else between them. Just do a little more poking at random and you'll quickly be able to compile a list of all the records that do exist.

Windows:

 
nslookup
> server <DNS you are querying>
> set type=any
> ls -d <target>
 

Unix (nslookup is deprecated on Unix):

 
dig -t axfr @<DNS you are querying> <target>

Obviously that response needs to be signed, but generally the DNS server itself doesn't have access to your signing key and can't sign the response on-the-fly; the signatures are all created "offline" ahead of time. This keeps your key from being exposed if your DNS server gets compromised.

 

So instead, you alphabetize your subdomains and say "for every name between mail.example.com and pop.example.com, no other subdomains exist" and sign that assertion. Then when someone asks for nachos.example.com you can just give them that response (which has already been signed) and the client knows that because nachos.example.com falls alphabetically between mail.example.com and pop.example.com, then the "this domain doesn't exist" response is considered to be correctly signed and actually came from you.

 

The place where this becomes problematic is that by having a set of these negative responses which explicitly state that "no responses exist between X and Y, you can easily map out exactly which domains exist for the entire zone. You know that "X" exists, and you know that "Y" exists, and you know there is nothing else between them. Just do a little more poking at random and you'll quickly be able to compile a list of all the records that do exist.

Windows:

nslookup
> server <DNS you are querying>
> set type=any
> ls -d <target>

Unix (nslookup is deprecated on Unix):

dig -t axfr @<DNS you are querying> <target>

Obviously that response needs to be signed, but generally the DNS server itself doesn't have access to your signing key and can't sign the response on-the-fly; the signatures are all created "offline" ahead of time. This keeps your key from being exposed if your DNS server gets compromised.

So instead, you alphabetize your subdomains and say "for every name between mail.example.com and pop.example.com, no other subdomains exist" and sign that assertion. Then when someone asks for nachos.example.com you can just give them that response (which has already been signed) and the client knows that because nachos.example.com falls alphabetically between mail.example.com and pop.example.com, then the "this domain doesn't exist" response is considered to be correctly signed and actually came from you.

The place where this becomes problematic is that by having a set of these negative responses which explicitly state that "no responses exist between X and Y, you can easily map out exactly which domains exist for the entire zone. You know that "X" exists, and you know that "Y" exists, and you know there is nothing else between them. Just do a little more poking at random and you'll quickly be able to compile a list of all the records that do exist.

some updates & make the hash values consistent
Source Link
Luc
  • 33.2k
  • 8
  • 81
  • 140

A workaround was designed for this: NSEC3. It hashes names, so mail turns into 1d6e1cb83a88... and pop turns into 4f197c9b21afc.... Imagine those are the two only subdomains, then the signed response will say "no record exists between b21afc... and b83a88...". Again it works alphabetically and you can obtain them all, but this time you will need to crack each hash before you learn what the subdomains are.

dnsrecon also appears to be able to do it: dnsrecon -z -d example.com. I don't know if there is an official website with information, but in Debian Stretch, Buster, and Bullseye I can apt-get install dnsrecon.

By guessing a few, you will often find responses in a similar range. If you know www. exists and mail. exists, and they both resolve to 192.168.3.x, there might be more. Try to do a reverse lookup for all addresses in the 192.168.3.0-255 range (the /24), and you will probably find more names insubdomains. You may also want to try a WHOIS query on the domainIP address to find the range's boundaries .example.com(if they have their own block).

Where -t rvl means "type reverse-lookup" and -r passes an IP range in CIDR notation. I don't know if there is an official website with information, but in Debian Stretch, Buster, and Bullseye I can apt-get install dnsrecon.

A workaround was designed for this: NSEC3. It hashes names, so mail turns into 1d6e1c... and pop turns into 4f197c9.... Imagine those are the two only subdomains, then the signed response will say "no record exists between b21afc... and b83a88...". Again it works alphabetically and you can obtain them all, but this time you will need to crack each hash before you learn what the subdomains are.

dnsrecon also appears to be able to do it: dnsrecon -z -d example.com. I don't know if there is an official website with information, but in Debian Stretch I can apt-get install dnsrecon.

By guessing a few, you will often find responses in a similar range. If you know www. exists and mail. exists, and they both resolve to 192.168.3.x, there might be more. Try to do a reverse lookup for all addresses in the 192.168.3.0-255 range (the /24), and you will probably find more names in the domain .example.com.

Where -t rvl means "type reverse-lookup" and -r passes an IP range in CIDR notation. I don't know if there is an official website with information, but in Debian Stretch I can apt-get install dnsrecon.

A workaround was designed for this: NSEC3. It hashes names, so mail turns into b83a88... and pop turns into b21afc.... Imagine those are the two only subdomains, then the signed response will say "no record exists between b21afc... and b83a88...". Again it works alphabetically and you can obtain them all, but this time you will need to crack each hash before you learn what the subdomains are.

dnsrecon also appears to be able to do it: dnsrecon -z -d example.com. I don't know if there is an official website with information, but in Debian Stretch, Buster, and Bullseye I can apt install dnsrecon.

By guessing a few, you will often find responses in a similar range. If you know www. exists and mail. exists, and they both resolve to 192.168.3.x, there might be more. Try to do a reverse lookup for all addresses in the 192.168.3.0-255 range (the /24), and you will probably find more subdomains. You may also want to try a WHOIS query on the IP address to find the range's boundaries (if they have their own block).

Where -t rvl means "type reverse-lookup" and -r passes an IP range in CIDR notation. I don't know if there is an official website with information, but in Debian Stretch, Buster, and Bullseye I can apt install dnsrecon.

Source Link
Luc
  • 33.2k
  • 8
  • 81
  • 140
Loading