Whenever you tackle any DNS task, the first thing you should do is an NSlookup (name server lookup).
nslookup -type=NS (domain) (target machine IP)
This will provide you with the correct domain and nameserver.
We can also see other types of records such as
nslookup -type=TXT (domain) (target machine IP)
or email records
nslookup -type=MX inlanefreight.com
The `nslookup` command can be used to obtain various types of DNS-related information. Here’s a list of the most common queries you can perform with nslookup:
1. Query the record type (A, MX, CNAME, etc.):
– A (Address): IP address of a domain.
– MX (Mail Exchange): Mail servers for a domain.
– CNAME (Canonical Name): Canonical name of an alias.
– NS (Name Server): Domain name servers.
– PTR (Pointer): Used to perform reverse lookups (from IP to domain name).
– TXT (Text): Text records associated with the domain (such as SPF, DKIM, etc.).
nslookup -type=MX inlanefreight.com nslookup -type=A inlanefreight.com nslookup -type=NS inlanefreight.com
Nmap
We can also run the script –script dns-nsid with [[nmap]]
nmap -p 53 --script dns-nsid <server_ip>;
Enumeration
The `SOA` record is located in a domain’s zone file and specifies who is responsible for running the domain and how the domain’s DNS information is managed.
Jesuslopez@htb[/htb]$ dig soa www.inlanefreight.com ; <<>> DiG 9.16.1-Ubuntu <<>> soa www.inlanefreight.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15876 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;www.inlanefreight.com. IN SOA ;; AUTHORITY SECTION: inlanefreight.com. 900 IN SOA ns-161.awsdns-20.com. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400 ;; Query time: 16 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Thu Jan 05 12:56:10 GMT 2023 ;; MSG SIZE rcvd: 128
The period (.) is replaced by an at sign (@) in the email address. In this example, the administrator’s email address is `awsdns-hostmaster@amazon.com`.
————————
DIG – NS Query Query the DNS server for other nameservers it knows about.
We do this by using the NS record and specifying the DNS server we want to query using the `@` character.
This is because if other DNS servers exist, we can also use them and query the records.
However, other DNS servers may be configured differently and may also be permanent for other zones.
Jesuslopez@htb[/htb]$ dig ns inlanefreight.htb @10.129.14.128 ; <<>> DiG 9.16.1-Ubuntu <<>> ns inlanefreight.htb @10.129.14.128 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45010 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 2 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: ce4d8681b32abaea0100000061475f73842c401c391690c7 (good) ;; QUESTION SECTION: ;inlanefreight.htb. IN NS ;; ANSWER SECTION: inlanefreight.htb. 604800 IN NS ns.inlanefreight.htb. ;; ADDITIONAL SECTION: ns.inlanefreight.htb. 604800 IN A 10.129.34.136 ;; Query time: 0 msec ;; SERVER: 10.129.14.128#53(10.129.14.128) ;; WHEN: So Sep 19 18:04:03 CEST 2021 ;; MSG SIZE rcvd: 107
DIG – Querying a DNS server version
This is done using a CHAOS query of type TXT.
This entry must exist on the DNS server.
To do this, we could use the following command:
Jesuslopez@htb[/htb]$ dig CH TXT version.bind 10.129.120.85 ; <<>> DiG 9.16.27-Debian <<>> CH TXT version.bind ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47786 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; ANSWER SECTION: version.bind. 0 CH TXT "9.10.6-P1" ;; ADDITIONAL SECTION: version.bind. 0 CH TXT "9.10.6-P1-Debian" ;; Query time: 2 msec ;; SERVER: 10.129.120.85#53(10.129.120.85) ;; WHEN: Wed Jan 05 20:23: ;; MSG SIZE rcvd: 101
`ANY` option to view all available records.
This will cause the server to show us all the available entries it is willing to reveal.
It is important to note that not all zone entries will be displayed.
DIG – ANY query
Jesuslopez@htb[/htb]$ dig any inlanefreight.htb @10.129.14.128 ; <<>> DiG 9.16.1-Ubuntu <<>> any inlanefreight.htb @10.129.14.128 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7649 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 2 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: 064b7e1f091b95120100000061476865a6026d01f87d10ca (good) ;; QUESTION SECTION: ;inlanefreight.htb. IN ANY ;; ANSWER SECTION: inlanefreight.htb. 604800 IN TXT "v=spf1 include:mailgun.org include:_spf.google.com include:spf.protection.outlook.com include:_spf.atlassian.net ip4:10.129.124.8 ip4:10.129.127.2 ip4:10.129.42.106 ~all" inlanefreight.htb. 604800 IN TXT "atlassian-domain-verification=t1rKCy68JFszSdCKVpw64A1QksWdXuYFUeSXKU" inlanefreight.htb. 604800 IN TXT "MS=ms97310371" inlanefreight.htb. 604800 IN SOA inlanefreight.htb. root.inlanefreight.htb. 2 604800 86400 2419200 604800 inlanefreight.htb. 604800 IN NS ns.inlanefreight.htb. ;; ADDITIONAL SECTION: ns.inlanefreight.htb. 604800 IN A 10.129.34.136 ;; Query time: 0 msec ;; SERVER: 10.129.14.128#53(10.129.14.128) ;; WHEN: So Sep 19 18:42:13 CEST 2021 ;; MSG SIZE rcvd: 437
AXFR
Zone transfer refers to the transfer of zones to another DNS server, usually on port 53.
This procedure is abbreviated as Asynchronous Full Transfer Zone (AXFR).
Since a DNS failure often has serious consequences for a company, the zone file is almost invariably kept identical on multiple name servers.
When changes are made, it must be ensured that all servers have the same data.
Synchronization between the servers involved is achieved through zone transfer.
Using a secret key rndc-key, which we initially saw in the default configuration [[1 – DNS Configurations]], the servers ensure that they communicate with their own master or slave.
Zone transfer involves simply transferring files or records and detecting discrepancies in the data sets of the servers involved.
The original data for a zone is located on a DNS server, which is called the primary name server for that zone.
However, to increase reliability, facilitate load distribution, or protect the primary server from attacks, in practice, in almost all cases, one or more additional servers are installed, called secondary name servers, for that zone.
For some Top-Level Domains (TLDs) and Second-Level Domains, it is mandatory to make zone files accessible on at least two servers.
DNS entries are generally only created, modified, or deleted on the primary server.
This can be done by manually editing the corresponding zone file or automatically through a dynamic update from a database.
A DNS server that serves as a direct source for synchronizing a zone file is called a master server.
A DNS server that obtains zone data from a master server is called a slave server.
A primary server is always a master server, while a secondary server can be either a slave or a master server.
The slave obtains the SOA record for the corresponding zone from the master at certain intervals, the so-called refresh time, usually one hour, and compares the serial numbers. If the serial number of the master’s SOA record is greater than that of the slave, the data sets no longer match.
DIG – AXFR Zone Transfer
Jesuslopez@htb[/htb]$ dig axfr inlanefreight.htb @10.129.14.128 ; <<>> DiG 9.16.1-Ubuntu <<>> axfr inlanefreight.htb @10.129.14.128 ;; global options: +cmd inlanefreight.htb. 604800 IN SOA inlanefreight.htb. root.inlanefreight.htb. 2 604800 86400 2419200 604800 inlanefreight.htb. 604800 IN TXT "MS=ms97310371" inlanefreight.htb. 604800 IN TXT "atlassian-domain-verification=t1rKCy68JFszSdCKVpw64A1QksWdXuYFUeSXKU" inlanefreight.htb. 604800 IN TXT "v=spf1 include:mailgun.org include:_spf.google.com include:spf.protection.outlook.com include:_spf.atlassian.net ip4:10.129.124.8 ip4:10.129.127.2 ip4:10.129.42.106 ~all" inlanefreight.htb. 604800 IN NS ns.inlanefreight.htb. app.inlanefreight.htb. 604800 IN A 10.129.18.15 internal.inlanefreight.htb. 604800 IN A 10.129.1.6 mail1.inlanefreight.htb. 604800 IN A 10.129.18.201 ns.inlanefreight.ht app.inlanefreight.htb. 604800 IN A 10.129.18.15 inlanefreight.htb. 604800 IN NS ns.inlanefreight.htb. dev.inlanefreight.htb. 604800 IN A 10.12.0.1 internal.inlanefreight.htb. 604800 IN A 10.129.1.6 inlanefreight.htb. 604800 IN SOA inlanefreight.htb. root.inlanefreight.htb. 2 604
echo "ns1.inlanefreight.com" > ./resolvers.txt Jesuslopez@htb[/htb]$ ./subbrute inlanefreight.com -s ./names.txt -r ./resolvers.txt
Brute Force Attacks on Subdomains
This is done with A records.
Beware, there are subdomains within subdomains, such as
win2k.dev.inlanefreight.htb
The subdomain dev.inlanefreight.htb has appeared in the hatthebox task.
When doing
dig axfr inlanefreight.htb @10.129.198.252 app.inlanefreight.htb. 604800 IN A 10.129.18.15 dev.inlanefreight.htb. 604800 IN A 10.12.0.1 internal.inlanefreight.htb. 604800 IN A 10.129.1.6 mail1.inlanefreight.htb. 604800 IN A 10.129.18.201 ns.inlanefreight.htb. 604800 IN A 127.0.0.1
If we try an axfr on each subdomain and there’s no connection, we can also perform a brute-force attack on that subdomain.
BE CAREFUL! Tip: Use all the dictionaries you can if you can’t find anything.
Here’s the link to
Subdomain Brute Force
Jesuslopez@htb[/htb]$ for sub in $(cat /opt/useful/seclists/Discovery/DNS/subdomains-top1million-110000.txt);do dig $sub.inlanefreight.htb @10.129.14.128 | grep -v ';\|SOA' | sed -r '/^\s*$/d' | grep $sub | tee -a subdomains.txt;done ns.inlanefreight.htb. 604800 IN A 10.129.34.136 mail1.inlanefreight.htb. 604800 IN A 10.129.18.201 app.inlanefreight.htb. 604800 IN A 10.129.18.15 inlanefreight.htb. 604800 IN NS ns.inlanefreight.htb. dev.inlanefreight.htb. 604800 IN A 10.12.0.1 internal.inlanefreight.htb. 604800 IN A 10.129.1.6 inlanefreight.htb. 604800 IN SOA inlanefreight.htb. root.inlanefreight.htb. 2 604
We also have tools like https://jprhack.net/dnsenum/
————————————————————————————————
If we only have the IP
If we don’t have a domain and only an IP, we can start by creating a
This would be the PTR record
dig -x 10.10.10.10 dig @10.10.10.10 domain Now we list the nameservers dig @10.10.10.10 ns domain Now the mail servers dig @10.10.10.10 mx domain --> is for listing emails
This is a reverse resolver query. The `-x` option is used to perform a reverse DNS lookup.
In this case, you are asking `dig` to resolve the IP address `10.10.10.10` to a domain name.
This type of query is used to find the domain name associated with a given IP address.
For example, if `10.10.10.10` corresponds to a server named `example.com`, this query will return the domain name `example.com`.