Quartz 4

DIG

5 min read

tags: dig dns reconnaissance passive 2zone_transfer

Comando che copre quasi tutti i campi che ci interessano

 
dig +nocmd targetdomain.com any +multiline +noall +answer
 
#oppure
 
dig any targetdomain.com

Nameserver DNS

Per vedere quali sono i server DNS di un determinato dominio ci basta lanciare il seguente comando:

dig ns certifiedhacker.com
 
; <<>> DiG 9.20.2-1-Debian <<>> ns certifiedhacker.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50497
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
 
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;certifiedhacker.com.		IN	NS
 
;; ANSWER SECTION:
certifiedhacker.com.	6847	IN	NS	ns1.bluehost.com.
certifiedhacker.com.	6847	IN	NS	ns2.bluehost.com.
 
;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Tue Nov 05 18:06:21 CET 2024
;; MSG SIZE  rcvd: 93

Le informazione riguardanti i server DNS del dominio certifiedhacker.com sono nella sezione ANSWER SECTION.

DNS Zone Transfer

Il trasferimento di zona DNS è il processo di trasferimento di una copia del file di zona DNS dal server DNS primario a un server DNS secondario. Nella maggior parte dei casi, il server DNS mantiene un server di riserva o secondario per ridondanza, che contiene tutte le informazioni archiviate nel server principale. Se l’impostazione di trasferimento DNS è abilitata sul server DNS di destinazione, fornirà informazioni DNS; in caso contrario, restituirà un errore che indica che il trasferimento di zona è fallito o rifiutato.

Ecco un esempio di Zone Transfer che fornisce molte informazioni:

dig @10.129.66.77 internal.inlanefreight.htb axfr
 
; <<>> DiG 9.20.15-1-Debian <<>> @10.129.66.77 internal.inlanefreight.htb axfr
; (1 server found)
;; global options: +cmd
internal.inlanefreight.htb. 604800 IN	SOA	inlanefreight.htb. root.inlanefreight.htb. 2 604800 86400 2419200 604800
internal.inlanefreight.htb. 604800 IN	TXT	"MS=ms97310371"
internal.inlanefreight.htb. 604800 IN	TXT	"HTB{DN5_z0N3_7r4N5F3r_iskdufhcnlu34}"
internal.inlanefreight.htb. 604800 IN	TXT	"atlassian-domain-verification=t1rKCy68JFszSdCKVpw64A1QksWdXuYFUeSXKU"
internal.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"
internal.inlanefreight.htb. 604800 IN	NS	ns.inlanefreight.htb.
dc1.internal.inlanefreight.htb.	604800 IN A	10.129.34.16
dc2.internal.inlanefreight.htb.	604800 IN A	10.129.34.11
mail1.internal.inlanefreight.htb. 604800 IN A	10.129.18.200
ns.internal.inlanefreight.htb. 604800 IN A	127.0.0.1
vpn.internal.inlanefreight.htb.	604800 IN A	10.129.1.6
ws1.internal.inlanefreight.htb.	604800 IN A	10.129.1.34
ws2.internal.inlanefreight.htb.	604800 IN A	10.129.1.35
wsus.internal.inlanefreight.htb. 604800	IN A	10.129.18.2
internal.inlanefreight.htb. 604800 IN	SOA	inlanefreight.htb. root.inlanefreight.htb. 2 604800 86400 2419200 604800
;; Query time: 359 msec
;; SERVER: 10.129.66.77#53(10.129.66.77) (TCP)
;; WHEN: Thu Jan 08 11:04:36 CET 2026
;; XFR size: 15 records (messages 1, bytes 677)

Tutti i dati contenuti potrebbero essere oro colato per un attaccante soprattutto quelli contenuti nel protocollo TXT.

Nel caso non fosse possibile il zone transfer ci apparirà il seguente errore.

dig @ns1.bluehost.com certifiedhacker.com axfr
;; Connection to 162.159.24.80#53(162.159.24.80) for certifiedhacker.com failed: connection refused.
;; no servers could be reached
;; Connection to 162.159.24.80#53(162.159.24.80) for certifiedhacker.com failed: connection refused.
;; no servers could be reached
;; Connection to 162.159.24.80#53(162.159.24.80) for certifiedhacker.com failed: connection refused.
;; no servers could be reached

Oppure su Parrot questo errore viene espresso così:

L’errore come già detto ci indica che l’opzione Zone Transfer è disabilitata.

DNS Reverse LookUp

Nel caso avessi un indirizzo IP e volessi trovare il suo relativo dominio potresti utilizzare la seguente sintassi:

dig @<IP_DNS> -x <IP_TARGET>

SOA (Start of Authority)

dig soa certifiedhacker.com                   
 
; <<>> DiG 9.20.2-1-Debian <<>> soa certifiedhacker.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15718
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
 
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;certifiedhacker.com.		IN	SOA
 
;; ANSWER SECTION:
certifiedhacker.com.	86400	IN	SOA	ns1.bluehost.com. dnsadmin.box5331.bluehost.com. 2024110500 86400 7200 3600000 300
 
;; Query time: 108 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Tue Nov 05 18:18:53 CET 2024
;; MSG SIZE  rcvd: 114

Il comando dig soa restituisce informazioni importanti sulla configurazione del dominio, specialmente riguardo al record SOA (Start of Authority). Questo record contiene i dettagli principali dell’autorità per il dominio e include informazioni utili per capire come funziona la gestione del dominio stesso.

Ecco cosa significano i vari campi nell’output:

  1. Server dei Nomi Primario (ns1.bluehost.com.): Questo è il server DNS principale per il dominio certifiedhacker.com. È l’autorità principale che ha il controllo sui record DNS del dominio.

  2. Responsabile del Dominio (dnsadmin.box5331.bluehost.com.): È l’indirizzo email del responsabile o amministratore DNS del dominio, rappresentato con un punto al posto della ”@” (in questo caso, [email protected]).

  3. Numero di Serie (2024110500): È un identificatore unico e incrementale per la versione del record SOA. Ogni volta che c’è una modifica ai record DNS del dominio, questo numero viene incrementato per informare i server secondari che devono aggiornare le informazioni.

  4. Refresh Time (86400 secondi): È il tempo (in secondi) che i server DNS secondari devono attendere prima di interrogare il server principale per vedere se ci sono aggiornamenti. In questo caso, è impostato su 86400 secondi (24 ore).

  5. Retry Time (7200 secondi): Se un server secondario non riesce a contattare il server primario, questo valore indica l’intervallo di tempo (in secondi) prima che il server secondario riprovi a connettersi. Qui è impostato su 7200 secondi (2 ore).

  6. Expire Time (3600000 secondi): Se un server secondario non riesce a contattare il server primario per aggiornare i record DNS per un lungo periodo, dopo questo tempo i dati memorizzati in cache verranno considerati non validi. In questo esempio, è impostato su 3600000 secondi (circa 41 giorni).

  7. TTL Minimo (300 secondi): Indica il tempo minimo (in secondi) che i resolver (come i provider DNS) devono mantenere in cache i record DNS per il dominio prima di richiederli di nuovo. In questo caso, è impostato su 300 secondi (5 minuti).

In breve

Il comando dig soa è utile per ottenere informazioni sulla struttura di gestione del dominio, identificare il server DNS primario, trovare il contatto amministrativo e capire i tempi di aggiornamento tra server DNS primario e secondari. La stessa identica operazione la si può fare tramite nslookup per saperne di più visita la seguente pagina Ns-lookup.

Graph View

Backlinks