DNS Enumeration Attack Chain: dig, dnsrecon, gobuster & fierce — Από τη Ζώνη στον Πλήρη Χάρτη Επιφάνειας Επίθεσης

Πώς τέσσερα εργαλεία αναγνώρισης DNS ενώνονται σε μία ρεαλιστική αλυσίδα χαρτογράφησης — από τα χειροκίνητα ερωτήματα A/MX/TXT/NS με το dig, στην αυτοματοποιημένη απαρίθμηση και τη μεταφορά ζώνης (AXFR) με το dnsrecon, στο subdomain brute-forcing με το gobuster και σε ένα fierce-style reverse sweep — μέχρι την πλήρη αποκάλυψη κρυφών hosts (dev, vpn, backup, db-prod, vault) και τη διαρροή εσωτερικών πληροφοριών μέσα από μια λανθασμένα ρυθμισμένη ζώνη. Όλα εκτελεσμένα αποκλειστικά εναντίον ενός δικού μας, τοπικού authoritative DNS server σε loopback.

TL;DR (EN): A DNS reconnaissance chain in an isolated lab zone: dig, dnsrecon, gobuster and fierce, from manual queries and a misconfigured AXFR zone transfer to subdomain brute-forcing and a full 25-record attack-surface map — plus how to lock down zone transfers and DNS exposure.

Νομική σημείωση / Authorization. Όλη η δραστηριότητα που περιγράφεται εκτελέστηκε αποκλειστικά εναντίον μιας δικής μας ζώνης DNS, σε ένα απομονωμένο εργαστήριο που κατέχουμε εξ ολοκλήρου. Ο authoritative server (meltemi.lab) τρέχει τοπικά, δεσμευμένος μόνο στο loopback (127.0.0.1), σε μη-προνομιακή θύρα. Κανένα ερώτημα δεν στάλθηκε ποτέ σε πραγματικό ή δημόσιο DNS server, ούτε σε πραγματικό domain. Όλα τα ονόματα, οι IP και τα TXT records είναι εργαστηριακά και φανταστικά. Οι τεχνικές αναγνώρισης DNS — και ιδίως η προσπάθεια zone transfer (AXFR) — είναι παράνομες όταν εφαρμόζονται εναντίον υποδομών χωρίς ρητή γραπτή εξουσιοδότηση. Χρησιμοποιήστε τις μόνο σε δικές σας ή ρητά εξουσιοδοτημένες ζώνες, στο πλαίσιο νόμιμου penetration testing.

Εισαγωγή: γιατί το DNS είναι ο πιο υποτιμημένος χάρτης της επιφάνειας επίθεσης

Σε κάθε σοβαρή αξιολόγηση ασφάλειας, το πρώτο πράγμα που θέλει να μάθει ο επιτιθέμενος είναι απλό: «τι υπάρχει;». Πριν από κάθε exploit, πριν από κάθε brute-force, πριν από κάθε προσπάθεια αυθεντικοποίησης, προηγείται η αναγνώριση — και το DNS (Domain Name System) είναι η πλουσιότερη, φθηνότερη και συχνά η πιο παραμελημένη πηγή αυτής της αναγνώρισης. Το DNS είναι, στην ουσία, ο τηλεφωνικός κατάλογος του Internet και των εσωτερικών δικτύων: μεταφράζει ονόματα (www.meltemi.lab) σε διευθύνσεις (10.10.20.5). Αυτό που ξεχνούν πολλοί οργανισμοί είναι ότι ο κατάλογος αυτός μιλάει — και συχνά λέει πολύ περισσότερα από όσα θα ήθελε ο ιδιοκτήτης του.

Ένα λανθασμένα ρυθμισμένο DNS δεν είναι απλώς ένα «θεωρητικό» εύρημα. Είναι η διαφορά ανάμεσα στο να ξέρει ο επιτιθέμενος μόνο τον δημόσιο ιστότοπό σας και στο να έχει μπροστά του ολόκληρο τον κατάλογο των εσωτερικών σας συστημάτων: το dev περιβάλλον, το vpn gateway, τον backup server, το admin panel, τη βάση παραγωγής db-prod, το vault με τα μυστικά. Κάθε ένα από αυτά τα ονόματα είναι ένας νέος στόχος, μια νέα υπόσχεση για ένα ευάλωτο σημείο εισόδου. Η αναγνώριση DNS δεν σπάει τίποτα από μόνη της — αλλά σχεδιάζει τον χάρτη πάνω στον οποίο θα σχεδιαστεί ολόκληρη η υπόλοιπη επίθεση.

Η αξία, όμως, στην πραγματική επιθετική ασφάλεια δεν βρίσκεται στο να τρέξεις ένα εργαλείο και να τυπώσεις μια λίστα εγγραφών. Βρίσκεται στην ικανότητα να ενώνεις βήματα: ένα χειροκίνητο ερώτημα NS αποκαλύπτει ποιοι είναι οι authoritative servers· ένα ερώτημα TXT διαρρέει ένα εσωτερικό σημείωμα· μια προσπάθεια AXFR επιτυγχάνει και ξεχύνει ολόκληρη τη ζώνη· ένα subdomain brute-force επιβεβαιώνει και επεκτείνει τα ευρήματα· και ένα reverse sweep αποκαλύπτει hosts που κανένα wordlist δεν θα μάντευε ποτέ. Αυτή η λογική — η kill chain της αναγνώρισης — είναι που ξεχωρίζει την πραγματική αξιολόγηση επιφάνειας επίθεσης από το θεατρικό «έτρεξα ένα εργαλείο».

Σε αυτό το flagship άρθρο των Audax Labs στήνουμε μια ολοκληρωμένη, ρεαλιστική αλυσίδα αναγνώρισης DNS εναντίον μιας δικής μας, σκόπιμα λανθασμένα ρυθμισμένης ζώνης, χρησιμοποιώντας τέσσερα εργαλεία που κάθε σοβαρός επαγγελματίας κυβερνοασφάλειας πρέπει να γνωρίζει σε βάθος:

1. dig — για χειροκίνητα, χειρουργικά ερωτήματα DNS (A, AAAA, MX, TXT, NS) και για την πρώτη προσπάθεια zone transfer (AXFR).
2. dnsrecon — για αυτοματοποιημένη απαρίθμηση και οργανωμένη προσπάθεια AXFR σε όλους τους authoritative servers, με parsing ανά τύπο εγγραφής.
3. gobuster (dns mode) — για subdomain brute-forcing εναντίον της ζώνης, με ένα στοχευμένο wordlist.
4. fierce-style reverse sweep — για διασταύρωση και reverse (PTR) lookups που αποκαλύπτουν hosts τους οποίους το brute-force δεν πιάνει.

Και στη συνέχεια, ενώνουμε όλα τα ευρήματα σε έναν πλήρη χάρτη της επιφάνειας επίθεσης του domain. Το σενάριο ακολουθεί μια αφήγηση πέντε κινήσεων: query -> transfer -> brute -> sweep -> map.

Αντίθετα με ένα απλό «πώς-να», εξηγούμε τι κάνει το κάθε εργαλείο, ποιες είναι οι σημαντικότερες παράμετροί του και ποια ακριβώς εντολή τρέξαμε — μαζί με τα πραγματικά αποτελέσματα, σε αποστειρωμένα, αναγνώσιμα screenshots. Κλείνουμε με αντιστοίχιση σε MITRE ATT&CK και με μια σκληρή, πρακτική ενότητα άμυνας: πώς σταματάτε κάθε ένα από αυτά τα βήματα στο δικό σας περιβάλλον.

Το σενάριο και το εργαστήριο

Ο στόχος μας είναι το domain meltemi.lab, η φανταστική ζώνη μιας εταιρείας logistics («Meltemi Logistics AE»). Στήνουμε έναν δικό μας authoritative DNS server που εξυπηρετεί αυτή τη ζώνη με ένα ρεαλιστικό σύνολο εγγραφών: SOA, δύο NS, MX για το mail, A/AAAA για τους δημόσιους hosts, TXT (SPF, DMARC) και — εδώ είναι το ενδιαφέρον — μια σειρά από «κρυφούς» εσωτερικούς hosts και ένα TXT record που διαρρέει ένα εσωτερικό σημείωμα.

Η ζώνη είναι σκόπιμα λανθασμένα ρυθμισμένη με δύο τρόπους που συναντάμε συνεχώς στην πραγματικότητα:

• Ανοιχτό AXFR (zone transfer). Ο server επιτρέπει σε οποιονδήποτε client να «κατεβάσει» ολόκληρη τη ζώνη με μία εντολή. Αυτό είναι το κλασικό, διαχρονικό εύρημα «unrestricted zone transfer» — μια ρύθμιση που μετατρέπει την αναγνώριση από κοπιώδες μάντεμα σε στιγμιαία, πλήρη αποκάλυψη.
• Διαρροή πληροφοριών σε TXT. Ένα από τα TXT records περιέχει ένα «σημείωμα λειτουργίας»: «migration in progress — legacy VPN at vpn.meltemi.lab still ONLINE, decommission pending (ticket OPS-4471)». Είναι η καρικατούρα ενός πανίσχυρου, πραγματικού anti-pattern: εσωτερική πληροφορία που «ξεχνιέται» σε δημόσια ορατά records.

Στη ζώνη τοποθετήσαμε επίσης εγγραφές που ένα κοινό wordlist subdomain brute-force δεν θα μάντευε ποτέ (db-prod, vault, hr-exports, kibana-7), ώστε να δείξουμε ρεαλιστικά ότι το AXFR και το reverse sweep αποκαλύπτουν πράγματα που το brute-force χάνει.

Τοπολογία

Ολόκληρο το εργαστήριο ζει σε έναν host, με τη μηχανή επίθεσης και τον authoritative server στο ίδιο μηχάνημα, χωρίς καμία γέφυρα προς LAN ή Internet. Η ταυτότητα του χειριστή είναι απόλυτα ουδέτερη (kali@lab). Ο DNS server είναι δεσμευμένος στο interface loopback και δεν εκθέτει καμία θύρα εκτός του host.

Ειλικρινείς διευκρινίσεις για την απομόνωση και τη θύρα. Η αρχική πρόθεση ήταν ο authoritative server να τρέξει σε Docker (BIND ή CoreDNS), σε ένα internal bridge χωρίς δημοσιευμένες πόρτες. Στο συγκεκριμένο περιβάλλον ο Docker daemon δεν ήταν διαθέσιμος (ήταν ανενεργός και δεν υπήρχε δικαίωμα εκκίνησης χωρίς sudo), ενώ δεν υπήρχε και εγκατεστημένος named/coredns. Ακολουθήσαμε λοιπόν την τίμια εναλλακτική: γράψαμε έναν μικρό, πραγματικό authoritative DNS server σε Python (με τη βιβλιοθήκη dnslib), ο οποίος φορτώνει μια κανονική BIND-style zone file, απαντά σε UDP και TCP, εξυπηρετεί reverse (PTR) ζώνη και — το κρίσιμο για το σενάριο — επιτρέπει AXFR σε οποιονδήποτε. Επιπλέον, η κανονική θύρα του DNS (53) είναι προνομιακή και απαιτεί root· επειδή το lab τρέχει χωρίς δικαιώματα root (και τα user namespaces ήταν κλειδωμένα), δέσαμε την υπηρεσία στη μη-προνομιακή θύρα 15353 (η τυπική εναλλακτική 5353 ήταν ήδη κατειλημμένη από τον mDNS/avahi). Κάθε εργαλείο στοχεύεται ρητά σε αυτή τη θύρα. Το πρωτόκολλο και η συμπεριφορά είναι πανομοιότυπα με ένα DNS στο 53 — απλώς το δηλώνουμε ρητά αντί να το κρύψουμε. Οι εγγραφές ns1/ns2 δείχνουν στο 127.0.0.1, γιατί εκεί ζει πραγματικά ο authoritative server του lab.

Το εργαστήριο περιλαμβάνει επίσης ένα μικρό wordlist που φτιάξαμε ειδικά (wl/subdomains-lab.txt), με τα «τυπικά» εταιρικά subdomains — ανάμεσά τους αυτά που υπάρχουν (www, mail, dev, vpn, backup, admin…) αλλά και μερικά που δεν υπάρχουν (test, api, blog, owa…). Αυτό μας επιτρέπει να δείξουμε ρεαλιστικά τόσο τα hits όσο και τα misses του brute-force.

Εργαλείο 1 — dig: χειροκίνητα ερωτήματα και η πρώτη προσπάθεια AXFR

Τι είναι και πού ταιριάζει

Το dig (Domain Information Groper) είναι το de facto εργαλείο χειροκίνητης ανάκρισης DNS. Είναι, στην ουσία, το «σμίλης» της αναγνώρισης DNS: σου επιτρέπει να ρωτήσεις έναν συγκεκριμένο DNS server για έναν συγκεκριμένο τύπο εγγραφής, να δεις ακριβώς τι απαντά, και να ελέγξεις τη συμπεριφορά του με πλήρη έλεγχο (θύρα, πρωτόκολλο, flags). Σε αντίθεση με τα αυτοματοποιημένα εργαλεία που «τρέχουν τα πάντα», το dig είναι το εργαλείο με το οποίο κατανοείς τι πραγματικά συμβαίνει στη ζώνη — και είναι το πρώτο εργαλείο κάθε σοβαρού DNS assessment.

Πού ταιριάζει: στην αρχή της αλυσίδας. Με το dig χαρτογραφείς χειροκίνητα τα βασικά (ποιοι είναι οι NS, πού πάει το mail, τι λένε τα TXT) και κάνεις την πρώτη, καθαρή προσπάθεια AXFR — που, αν πετύχει, σου δίνει ολόκληρη τη ζώνη πριν καν χρειαστείς οτιδήποτε άλλο.

Σημαντικές παράμετροι / flags

Η εντολή που τρέξαμε

Πρώτα χαρτογραφούμε χειροκίνητα τα βασικά:

dig @127.0.0.1 -p 15353 meltemi.lab A   +noall +answer
dig @127.0.0.1 -p 15353 meltemi.lab NS  +noall +answer
dig @127.0.0.1 -p 15353 meltemi.lab MX  +noall +answer
dig @127.0.0.1 -p 15353 meltemi.lab TXT +noall +answer

Το dig επέστρεψε την A εγγραφή του apex (10.10.20.5), τους δύο authoritative NS (ns1, ns2), τα δύο MX (mail, mail2 με προτεραιότητες 10/20) και — το κρίσιμο — τα TXT records, ανάμεσα στα οποία το εσωτερικό σημείωμα που διαρρέει την ύπαρξη και την κατάσταση του vpn.meltemi.lab.

Το δίδαγμα εδώ είναι διπλό. Πρώτον, τα NS records μας δίνουν αμέσως τους στόχους για την επόμενη κίνηση (την προσπάθεια AXFR). Δεύτερον, τα TXT records είναι μια χρυσωρυχεία διαρροών: SPF που αποκαλύπτει mail infrastructure, verification tokens τρίτων υπηρεσιών, και — όπως εδώ — εσωτερικά σημειώματα που δεν είχαν καμία δουλειά να βρίσκονται σε δημόσια ορατή εγγραφή.

Στη συνέχεια, η πρώτη προσπάθεια zone transfer:

dig @127.0.0.1 -p 15353 meltemi.lab AXFR

Και εδώ έρχεται το «κερασάκι»: το AXFR πέτυχε. Ο server, λανθασμένα ρυθμισμένος, παρέδωσε ολόκληρη τη ζώνη σε ένα και μόνο ερώτημα — SOA, όλα τα NS/MX/A/AAAA/TXT/CNAME και κάθε κρυφό host.

Σε ένα βήμα, χωρίς κανένα brute-force, χωρίς κανένα credential, ο επιτιθέμενος απέκτησε τον πλήρη κατάλογο των εσωτερικών συστημάτων: dev, staging, git, jenkins, vpn, backup, admin, intranet, legacy, db-prod, vault, hr-exports, kibana-7. Αυτό είναι το πραγματικό βάρος μιας ανοιχτής μεταφοράς ζώνης: μετατρέπει ώρες αναγνώρισης σε δευτερόλεπτα, και δίνει στον επιτιθέμενο πληροφορία που, στην πράξη, δεν θα έπρεπε ποτέ να μπορεί να αποκτήσει.

Εργαλείο 2 — dnsrecon: αυτοματοποιημένη απαρίθμηση και οργανωμένο AXFR

Τι είναι και πού ταιριάζει

Το dnsrecon είναι ένα ώριμο, ανοιχτού κώδικα εργαλείο αναγνώρισης DNS (σε Python) που αυτοματοποιεί ό,τι θα έκανες χειροκίνητα με πολλές κλήσεις dig — και το κάνει με δομή. Επιλύει το SOA, βρίσκει όλους τους NS servers, δοκιμάζει AXFR σε καθέναν από αυτούς, και όταν πετύχει, αναλύει και ταξινομεί κάθε εγγραφή ανά τύπο (A, AAAA, MX, TXT, PTR, SRV, NS…). Υποστηρίζει επίσης standard enumeration, brute-force subdomains, reverse lookups σε εύρη IP, cache snooping και πολλά ακόμη, με δυνατότητα εξαγωγής σε JSON/CSV/XML για μετέπειτα επεξεργασία.

Πού ταιριάζει: αμέσως μετά το dig. Ενώ το dig σου δίνει χειρουργικό έλεγχο ένα-ένα, το dnsrecon αυτοματοποιεί και οργανώνει την προσπάθεια AXFR σε όλους τους authoritative servers ταυτόχρονα, και σου παραδίδει ένα καθαρό, δομημένο αποτέλεσμα — ιδανικό για ένα report.

Σημαντικές παράμετροι / flags

Η εντολή που τρέξαμε

dnsrecon -d meltemi.lab -n 127.0.0.1 -a

Τεχνική διευκρίνιση (τίμια). Το dnsrecon δεν διαθέτει επίσημη παράμετρο για custom DNS θύρα — υποθέτει πάντα την 53. Επειδή ο lab server μας ακούει στη μη-προνομιακή 15353, τρέξαμε το dnsrecon μέσα από έναν λεπτό launcher (dnsrecon_lab.py) που ανακατευθύνει μόνο τη θύρα του DNS transport στο 15353. Καμία λογική του dnsrecon (η AXFR, το parsing, η απαρίθμηση, η έξοδος) δεν αλλάζει — αλλάζει μόνο ο προορισμός της θύρας, και όλα τα ερωτήματα πηγαίνουν αποκλειστικά στον δικό μας loopback server. Το output που βλέπετε είναι το αυθεντικό output του dnsrecon.

Το dnsrecon επίλυσε το SOA, βρήκε τους NS (ns1, ns2 -> 127.0.0.1), ανίχνευσε ότι η θύρα TCP είναι ανοιχτή, και πέτυχε τη μεταφορά ζώνης, παραθέτοντας κάθε εγγραφή ταξινομημένη ανά τύπο — συμπεριλαμβανομένων των A records για τους κρυφούς hosts και του διαρρέοντος TXT.

Το δίδαγμα εδώ είναι η αυτοματοποίηση με δομή. Ένα εργαλείο σαν το dnsrecon μετατρέπει το «έκανα ένα AXFR» σε ένα οργανωμένο inventory που μπαίνει κατευθείαν σε ένα report, με σαφή διαχωρισμό ανά τύπο εγγραφής. Σε ένα πραγματικό engagement, η δυνατότητα εξαγωγής σε JSON/CSV σημαίνει ότι το αποτέλεσμα τροφοδοτεί αυτόματα το επόμενο στάδιο (π.χ. port scanning των IP που βρέθηκαν).

Εργαλείο 3 — gobuster (dns mode): subdomain brute-forcing

Τι είναι και πού ταιριάζει

Το gobuster είναι ένα ταχύτατο εργαλείο brute-forcing γραμμένο σε Go, γνωστό κυρίως για directory/file brute-forcing σε web servers — αλλά με ένα εξαιρετικά χρήσιμο dns mode για την ανακάλυψη subdomains. Στη λειτουργία αυτή, το gobuster παίρνει ένα wordlist και δοκιμάζει κάθε λέξη ως subdomain (π.χ. dev.meltemi.lab, vpn.meltemi.lab), ρωτώντας τον resolver αν το όνομα υπάρχει. Είναι το εργαλείο στο οποίο καταφεύγεις όταν το AXFR δεν πετύχει (η συνηθέστερη περίπτωση σε καλά ρυθμισμένους servers) και πρέπει να «μαντέψεις» τα ονόματα.

Πού ταιριάζει: ως η μέθοδος που δουλεύει ακόμη κι όταν η ζώνη είναι κλειστή στο AXFR. Εδώ το χρησιμοποιούμε για να δείξουμε δύο πράγματα: πόσο αποτελεσματικό είναι το brute-force στα «προφανή» ονόματα, αλλά και πού βρίσκονται τα όριά του σε σχέση με το AXFR.

Σημαντικές παράμετροι / flags

Η εντολή που τρέξαμε

gobuster dns -d meltemi.lab -w wl/subdomains-lab.txt -r 127.0.0.1:15353 -t 20

Το gobuster δοκίμασε τις 29 λέξεις του wordlist και βρήκε 16 subdomains: www, mail, mail2, ns1, ns2, ftp, portal, dev, staging, git, jenkins, vpn, backup, admin, intranet, legacy. Τα ονόματα που δεν υπάρχουν (test, api, blog, owa, remote, citrix…) επέστρεψαν, σωστά, μηδέν.

Το δίδαγμα είναι κρίσιμο: το brute-force είναι αποτελεσματικό αλλά τυφλό. Βρίσκει ό,τι υπάρχει στο wordlist — και μόνο αυτό. Οι εγγραφές db-prod, vault, hr-exports, kibana-7, που δεν είναι «τυπικά» ονόματα και δεν βρίσκονταν στο wordlist, δεν εντοπίστηκαν από το gobuster. Αυτό είναι ακριβώς το σημείο όπου η ανοιχτή μεταφορά ζώνης (που τα αποκάλυψε όλα σε ένα βήμα) γίνεται τόσο πιο επικίνδυνη από το brute-force — και ο λόγος που το επόμενο, συμπληρωματικό βήμα έχει σημασία.

Εργαλείο 4 — fierce-style reverse sweep: διασταύρωση και αποκάλυψη κρυφών hosts

Τι είναι και πού ταιριάζει

Το κλασικό fierce είναι ένα εργαλείο αναγνώρισης DNS που, μετά το brute-force, κάνει κάτι έξυπνο: παίρνει το εύρος IP στο οποίο ζουν οι hosts που βρήκε και «περπατά» τις γειτονικές διευθύνσεις κάνοντας reverse (PTR) lookups, για να ανακαλύψει hosts που κανένα forward wordlist δεν θα μάντευε. Η λογική είναι απλή: αν το dev.meltemi.lab είναι στο 10.10.20.50, τι κρύβεται στο .51, .52, .120, .121; Πολλοί οργανισμοί που θωρακίζουν το forward DNS ξεχνούν εντελώς το reverse DNS — και εκεί κρύβεται συχνά ο πλήρης κατάλογος.

Στο lab μας υλοποιήσαμε αυτή τη fierce-style λογική με ένα μικρό, διαφανές script πάνω από το dig: μια διασταύρωση των βασικών hosts και ένα reverse PTR sweep ολόκληρου του 10.10.20.0/24. (Το επίσημο πακέτο fierce/dnsenum δεν υποστηρίζει εύκολα custom DNS θύρα ή απαιτούσε Perl modules εκτός του lab· επιλέξαμε την τίμια, ισοδύναμη υλοποίηση με dig, που στοχεύει ρητά τον lab server.)

Πού ταιριάζει: ως το συμπληρωματικό βήμα που καλύπτει το τυφλό σημείο του brute-force. Το reverse sweep αποκαλύπτει ό,τι το forward brute-force χάνει.

Σημαντικές παράμετροι / λογική

Η εντολή που τρέξαμε

bash fierce_sweep.sh

Το reverse sweep επέστρεψε 18 hosts στο 10.10.20.0/24 — και, το κρίσιμο, ανάμεσά τους τα db-prod, vault, hr-exports, kibana-7, που το gobuster δεν είχε πιάσει.

Το δίδαγμα κλείνει τον κύκλο: η αναγνώριση δεν είναι μία τεχνική, είναι πολλές συμπληρωματικές. Το brute-force βρίσκει τα προφανή, το reverse sweep βρίσκει τα κρυμμένα, το AXFR (όταν είναι ανοιχτό) τα βρίσκει όλα μονομιάς. Ένας επαρκής επιτιθέμενος τα συνδυάζει· ένας επαρκής αμυνόμενος πρέπει να τα κλείσει όλα.

Ενώνοντας την αλυσίδα: χαρτογραφώντας τη ζώνη

Ας δούμε τώρα ολόκληρη την αλυσίδα ως ενιαία αφήγηση. Κάθε βήμα τροφοδοτεί και επεκτείνει το επόμενο:

1. query (dig): Χαρτογραφήσαμε χειροκίνητα NS/MX/A, διαβάσαμε τα TXT και εντοπίσαμε τη διαρροή του εσωτερικού σημειώματος για το vpn.
2. transfer (dig + dnsrecon AXFR): Η ανοιχτή μεταφορά ζώνης παρέδωσε ολόκληρη τη ζώνη — κάθε κρυφό host, σε ένα βήμα, χωρίς credentials.
3. brute (gobuster): Επιβεβαιώσαμε ανεξάρτητα 16 subdomains με brute-force — η μέθοδος που δουλεύει ακόμη κι όταν το AXFR είναι κλειστό.
4. sweep (reverse PTR): Αποκαλύψαμε τους hosts που το brute-force έχασε (db-prod, vault, hr-exports, kibana-7).
5. map: Ενώσαμε τα πάντα σε έναν πλήρη χάρτη 25 εγγραφών της επιφάνειας επίθεσης του domain.

Ο τελικός, ενοποιημένος χάρτης της επιφάνειας επίθεσης:

Ολόκληρη η αλυσίδα, συνοπτικά, με τα βήματα και την αντιστοίχιση σε MITRE ATT&CK:

Αυτό είναι το ουσιαστικό μάθημα ενός σοβαρού DNS reconnaissance: μερικές «μέτριες» ρυθμίσεις (ένα ανοιχτό AXFR, ένα TXT που διαρρέει, ένα προβλέψιμο naming scheme, ένα ξεχασμένο reverse DNS) συνδυάζονται σε έναν πλήρη χάρτη της εσωτερικής υποδομής — πριν ριφθεί ένα και μόνο πακέτο επίθεσης προς τα ίδια τα συστήματα. Κανένα από αυτά μόνο του δεν θα φαινόταν «critical» σε ένα αυτόματο scanner. Η αλυσίδα, όμως, είναι που δίνει στον επιτιθέμενο τον χάρτη.

MITRE ATT&CK: mini-mapping της αλυσίδας

Η αντιστοίχιση σε τεχνικές του MITRE ATT&CK βοηθά τις blue teams να καταλάβουν τι να ανιχνεύσουν σε κάθε στάδιο. Στο πλαίσιο του δικού μας, εξ ολοκλήρου εξουσιοδοτημένου lab, η τεχνική T1596 («Search Open Technical Databases») επαναπλαισιώνεται: αντί για δημόσιες βάσεις τρίτων, στοχεύουμε αποκλειστικά τον δικό μας authoritative server και τη δική μας ζώνη.

Αυτή η μικρή χαρτογράφηση είναι εξαιρετικά χρήσιμη σε ένα report: μεταφράζει την «ιστορία της αναγνώρισης» σε γλώσσα που καταλαβαίνουν τόσο η τεχνική ομάδα όσο και η διοίκηση, και δείχνει ότι για κάθε βήμα υπάρχει σημείο ανίχνευσης και σημείο άμυνας.

Επαλήθευση

Για να είναι το αποτέλεσμα αξιόπιστο και όχι «τυχαίο», εφαρμόσαμε επαληθεύσεις σε κάθε στάδιο:

• dig: Κάθε εγγραφή που επέστρεψε το dig διασταυρώθηκε απευθείας με το περιεχόμενο της zone file του lab. Το AXFR επιβεβαιώθηκε ότι επιστρέφει SOA στην αρχή και στο τέλος (σωστό AXFR framing) και ότι περιέχει και τους 25+ hosts.
• dnsrecon: Το «Zone Transfer was successful!!» διασταυρώθηκε ανεξάρτητα με το χειροκίνητο dig AXFR — και τα δύο εργαλεία επέστρεψαν το ίδιο σύνολο εγγραφών. Το output είναι το αυθεντικό output του dnsrecon (με μόνη αλλαγή τη θύρα προορισμού, όπως δηλώθηκε).
• gobuster: Τα 16 ευρήματα διασταυρώθηκαν με τα A records της ζώνης. Ελέγξαμε ρητά ότι τα ονόματα εκτός wordlist (db-prod, vault, hr-exports, kibana-7) δεν εμφανίστηκαν — negative control που αποδεικνύει ότι το εργαλείο δεν «εφευρίσκει» ευρήματα και ότι το brute-force έχει πραγματικά τυφλά σημεία.
• reverse sweep: Τα 18 PTR ευρήματα διασταυρώθηκαν με τις A/PTR εγγραφές. Οι διευθύνσεις χωρίς host (π.χ. 10.10.20.1) επέστρεψαν σωστά κενό — negative control για το reverse σκέλος.
• map: Ο τελικός χάρτης είναι η ένωση των τριών ανεξάρτητων μεθόδων (AXFR + brute + sweep), και κάθε εγγραφή του επιβεβαιώνεται από τουλάχιστον μία, οι περισσότερες από δύο ή τρεις.

Αντιμετώπιση προβλημάτων (troubleshooting)

Κατά το στήσιμο συναντήσαμε αρκετά πραγματικά εμπόδια, τα οποία καταγράφουμε με ειλικρίνεια — γιατί ακριβώς αυτά ξεχωρίζουν ένα πραγματικό lab από ένα «στημένο» screenshot:

• Docker & έτοιμος DNS server μη διαθέσιμοι. Ο Docker daemon ήταν ανενεργός (χωρίς δικαίωμα εκκίνησης) και δεν υπήρχε εγκατεστημένος named/coredns. Λύση: γράψαμε έναν μικρό, πραγματικό authoritative server σε Python (dnslib) που φορτώνει κανονική BIND-style zone file, απαντά σε UDP+TCP, σερβίρει reverse ζώνη και επιτρέπει AXFR — δηλωμένο ρητά.
• Θύρα 53 και δικαιώματα root. Η 53 είναι προνομιακή· χωρίς root (και με κλειδωμένα user namespaces) δεν δεσμεύεται. Λύση: μη-προνομιακή θύρα 15353, με ρητή στόχευση όλων των εργαλείων εκεί.
• Σύγκρουση με mDNS/avahi στην 5353. Η «κλασική» εναλλακτική θύρα 5353 ήταν ήδη κατειλημμένη από τον avahi-daemon (mDNS), προκαλώντας timeouts. Λύση: μετακίνηση στην ελεύθερη 15353.
• dnsrecon χωρίς custom port. Το dnsrecon υποθέτει πάντα θύρα 53. Λύση: λεπτός launcher που ανακατευθύνει μόνο τη θύρα του DNS transport στο 15353, χωρίς καμία αλλαγή στη λογική του εργαλείου. Επιπλέον, επειδή το dnsrecon παράγει τον στόχο του AXFR από τις IP των NS records, ρυθμίσαμε τα ns1/ns2 να δείχνουν στο 127.0.0.1 (εκεί ζει πραγματικά ο authoritative server του lab).
• dnsenum & Perl modules. Το dnsenum απαιτούσε πέντε Perl modules εκτός του lab (Net::DNS, String::Random, XML::Writer, Net::IP, Net::Netmask) και δεν υποστηρίζει εύκολα custom θύρα. Λύση: υλοποιήσαμε την ισοδύναμη fierce-style λογική (reverse PTR sweep) με dig, ρητά στοχευμένη στον lab server.
• ANSI χρώματα στην έξοδο. Τα εργαλεία (ιδίως το gobuster) παράγουν ANSI escape codes. Για καθαρά, αναγνώσιμα screenshots, φιλτράραμε τα escape sequences και αναπαραστήσαμε την έξοδο σε ASCII, με ουδέτερη ταυτότητα χειριστή (kali@lab), χωρίς πραγματικά paths ή hostnames.

Άμυνα: πώς σταματάτε κάθε βήμα

Εδώ βρίσκεται η πραγματική αξία ενός offensive άρθρου για έναν οργανισμό: κάθε βήμα της αλυσίδας έχει συγκεκριμένη, εφαρμόσιμη άμυνα. Αν σπάσετε έστω και έναν κρίκο, ο χάρτης μένει κρυφός.

Ενάντια στο dig (χειροκίνητα ερωτήματα & TXT leakage)

• Ελαχιστοποιήστε τη διαρροή σε TXT records. Κανένα εσωτερικό σημείωμα, όνομα host, ticket, ή «προσωρινή» πληροφορία δεν έχει καμία δουλειά σε TXT record. Κρατήστε τα TXT αυστηρά για ό,τι πρέπει να είναι δημόσιο (SPF, DKIM, DMARC, verification tokens) και ελέγξτε τα περιοδικά.
• Split-horizon DNS. Οι εσωτερικές ζώνες (dev, vpn, backup, intranet…) δεν πρέπει ποτέ να σερβίρονται σε untrusted clients. Ξεχωριστές internal/external views ώστε ο έξω κόσμος να βλέπει μόνο ό,τι πρέπει.
• Minimal footprint. Λιγότερες εγγραφές δημόσια = λιγότερη πληροφορία για τον επιτιθέμενο. Αφαιρέστε παλιές, «ξεχασμένες» εγγραφές (legacy hosts) που δεν χρησιμοποιούνται πια.

Ενάντια στο AXFR (η κρίσιμη misconfiguration)

• Απενεργοποιήστε / περιορίστε τα zone transfers. Αυτό είναι το σημαντικότερο μέτρο ολόκληρου του άρθρου. Το AXFR πρέπει να επιτρέπεται μόνο προς ρητά εξουσιοδοτημένους secondary/slave servers — ποτέ σε «any». Σε BIND: allow-transfer { <secondaries>; }; (ή none). Σε άλλους servers, το αντίστοιχο ACL.
• TSIG για τα transfers. Όπου χρειάζεται πραγματικό zone transfer μεταξύ primary/secondary, προστατέψτε το με TSIG keys (κρυπτογραφική αυθεντικοποίηση), ώστε ένας τρίτος να μην μπορεί να πάρει τη ζώνη ακόμη κι αν φτάσει στη θύρα.
• Restrict recursion & separate roles. Οι authoritative servers δεν πρέπει να κάνουν recursion για τυχαίους· διαχωρίστε authoritative από recursive resolvers.
• Detection: ένα εισερχόμενο AXFR από μη-εξουσιοδοτημένη IP είναι ένα από τα καθαρότερα σήματα αναγνώρισης — logάρετέ το και ειδοποιήστε. Ένα μόνο AXFR request από άγνωστη πηγή αξίζει άμεση διερεύνηση.

Ενάντια στο gobuster (subdomain brute-forcing)

• Rate-limiting & anomaly detection στον resolver. Ένας τεράστιος όγκος ερωτημάτων για μη-υπαρκτά ονόματα (NXDOMAIN flood) από μία πηγή είναι κλασικό μοτίβο brute-force. Response rate limiting (RRL) και monitoring το σηματοδοτούν.
• Αποφύγετε προβλέψιμα naming schemes για ευαίσθητα συστήματα, και μην βασίζεστε σε αυτό ως άμυνα («security by obscurity» δεν αρκεί — αλλά τα προβλέψιμα ονόματα κάνουν τη δουλειά του επιτιθέμενου εύκολη).
• Wildcard με προσοχή: ένα wildcard record μπορεί να «θολώσει» το brute-force, αλλά δημιουργεί άλλα προβλήματα· χρησιμοποιήστε το συνειδητά.

Ενάντια στο reverse sweep (PTR walking)

• Μην παραμελείτε το reverse DNS. Πολλοί θωρακίζουν το forward DNS και αφήνουν πλήρη, περιγραφικά PTR records για κάθε εσωτερική IP. Αν το reverse DNS δεν χρειάζεται να είναι δημόσιο, μην το εκθέτετε· και αποφύγετε περιγραφικά ονόματα στα PTR (π.χ. vault, db-prod) που λειτουργούν ως οδικός χάρτης.
• Split-horizon και για το reverse. Οι in-addr.arpa ζώνες των εσωτερικών εύρων δεν έχουν λόγο να απαντούν σε εξωτερικούς.

Οριζόντια μέτρα

• DNSSEC — με σωστό πλαίσιο. Το DNSSEC εγγυάται την ακεραιότητα των απαντήσεων (ότι δεν έχουν παραποιηθεί), όχι την εμπιστευτικότητα. Δεν κρύβει εγγραφές — και μάλιστα, χωρίς NSEC3, το NSEC walking μπορεί να αποκαλύψει ονόματα. Είναι απαραίτητο για anti-tampering, αλλά δεν είναι λύση για τη διαρροή πληροφοριών· μην το μπερδεύετε.
• Συνεχής ορατότητα. Πάνω από τα επιμέρους, ένας οργανισμός χρειάζεται συνεχή χαρτογράφηση: continuous exposure management ώστε νέες, λανθασμένα ρυθμισμένες ή «ξεχασμένες» εγγραφές DNS να εντοπίζονται πριν τις βρει ο επιτιθέμενος, τακτικό adversary validation που δοκιμάζει ολόκληρες αλυσίδες αναγνώρισης (όχι μεμονωμένα ευρήματα), και ευθυγράμμιση με NIS2 & DORA, που πλέον απαιτούν αποδεδειγμένη, τεκμηριωμένη ανθεκτικότητα και όχι απλώς checkbox compliance.

Δυνατά σημεία των τεσσάρων εργαλείων

• dig: Το θεμέλιο κάθε DNS assessment. Χειρουργικά ακριβές, πανταχού παρόν, με πλήρη έλεγχο σε server, θύρα, τύπο εγγραφής και πρωτόκολλο. Είναι το εργαλείο με το οποίο καταλαβαίνεις το DNS, όχι απλώς το «τρέχεις».
• dnsrecon: Αυτοματοποιεί και δομεί ό,τι θα έκανες χειροκίνητα, με οργανωμένη προσπάθεια AXFR σε όλους τους NS, parsing ανά τύπο και εξαγωγή σε JSON/CSV/XML για αυτοματοποίηση και reporting.
• gobuster (dns): Ταχύτατο, γραμμένο σε Go, ιδανικό για subdomain brute-forcing όταν το AXFR είναι κλειστό. Απλό στη χρήση, με καθαρή έξοδο και υποστήριξη custom resolver.
• fierce-style reverse sweep: Η λογική που καλύπτει το τυφλό σημείο του brute-force — αποκαλύπτει hosts μέσω PTR που κανένα forward wordlist δεν θα μάντευε.

Περιορισμοί και προσοχή

• Τα εργαλεία είναι τόσο καλά όσο και το τι επιτρέπει ο στόχος. Ένας σωστά ρυθμισμένος server (κλειστό AXFR, split-horizon, καθαρά TXT) περιορίζει δραστικά την αναγνώριση — όπως θα έπρεπε.
• Το AXFR είναι το «all-or-nothing»: όταν είναι ανοιχτό, δίνει τα πάντα· όταν είναι κλειστό (η σωστή ρύθμιση), δεν δίνει τίποτα, και ο επιτιθέμενος επιστρέφει στο πιο αργό, θορυβώδες brute-force.
• Το brute-force είναι θορυβώδες (μεγάλος όγκος NXDOMAIN) και τυφλό στα μη-προβλέψιμα ονόματα· η επιτυχία του εξαρτάται απόλυτα από την ποιότητα του wordlist.
• Το reverse DNS δεν είναι πάντα «γεμάτο» — σε οργανισμούς που δεν συντηρούν PTR records, το reverse sweep αποδίδει λίγα. Στο lab μας το αποδώσαμε πλήρες, ως ρεαλιστική «κακή» περίπτωση.

Πού χρησιμοποιείται επαγγελματικά

Αυτή η αλυσίδα δεν είναι «CTF παιχνίδι». Είναι το ψωμοτύρι της φάσης αναγνώρισης σε κάθε external και internal penetration test, σε attack surface management, σε red team engagements και σε OSINT/threat intelligence. Η χαρτογράφηση DNS είναι συνήθως το πρώτο πράγμα που κάνει ένας assessor: πριν σκεφτεί exploit, χρειάζεται τον χάρτη των στόχων. Χρησιμοποιείται για την ανακάλυψη ξεχασμένων ή shadow-IT συστημάτων, για την επιβεβαίωση του πλάτους της επιφάνειας επίθεσης, για την τροφοδότηση του επόμενου σταδίου (port/service scanning), και ως βάση για ρεαλιστικά σενάρια εκπαίδευσης.

Πότε δεν πρέπει να χρησιμοποιηθεί

Ποτέ εναντίον domain ή ζώνης που δεν σας ανήκει ή για την οποία δεν έχετε ρητή γραπτή εξουσιοδότηση. Ένα AXFR request, ένα subdomain brute-force ή ένα reverse sweep εναντίον υποδομής τρίτου είναι, ανάλογα με τη δικαιοδοσία, αδίκημα — ακόμη κι αν «απλώς ρωτάτε». Η γραμμή μεταξύ νόμιμης αναγνώρισης και παράνομης δραστηριότητας είναι η εξουσιοδότηση και το scope. Στο πλαίσιο ενός engagement, ακόμη και η αναγνώριση συμφωνείται και τεκμηριώνεται εκ των προτέρων.

Τελική αξιολόγηση

Ως αλυσίδα, το τετράπτυχο dig + dnsrecon + gobuster + reverse sweep αποτελεί ίσως το πιο διδακτικό και ταυτόχρονα ρεαλιστικό μονοπάτι αναγνώρισης DNS. Το κάθε εργαλείο είναι κορυφαίο στην κατηγορία του, ώριμο και ανοιχτού κώδικα, και μαζί αφηγούνται μια πλήρη ιστορία από το «τι domain είναι αυτό» μέχρι το «να ο πλήρης κατάλογος των εσωτερικών σας συστημάτων». Για έναν επαγγελματία, η γνώση αυτής της αλυσίδας — και κυρίως των αμυνών που τη σπάνε — είναι θεμελιώδης.

Βαθμολογία εργαστηριακής άσκησης: 9.5/10 για διδακτική αξία και ρεαλισμό. Ο μόνος αστερίσκος είναι ότι η αποτελεσματικότητα της αλυσίδας εξαρτάται απόλυτα από το πόσο λανθασμένα ρυθμισμένος είναι ο στόχος — κάτι που, δυστυχώς, στην πραγματικότητα συναντάμε πολύ συχνότερα απ’ όσο θα έπρεπε.

Συμπέρασμα

Η ασφάλεια δεν σπάει από ένα «critical» εύρημα· σπάει από αλυσίδες μέτριων ρυθμίσεων που κανείς δεν συνέδεσε. Ένα ανοιχτό AXFR, ένα TXT που «θυμάται» ένα εσωτερικό ticket, ένα προβλέψιμο naming scheme και ένα ξεχασμένο reverse DNS μοιάζουν διαχειρίσιμα μεμονωμένα — μέχρι που κάποιος τα ενώσει και έχει μπροστά του ολόκληρο τον χάρτη της εσωτερικής σας υποδομής σε λιγότερο από ένα λεπτό, χωρίς να αγγίξει ούτε ένα από τα ίδια τα συστήματα. Ο μόνος τρόπος να το ξέρετε πριν το μάθετε με τον δύσκολο τρόπο είναι να δοκιμάσετε ολόκληρη την αλυσίδα, με τη λογική του επιτιθέμενου, και μετά να θωρακίσετε κάθε κρίκο.

Από το εργαστήριο, στο δικό σας περιβάλλον

Αυτό που είδατε εδώ ήταν μια ελεγχόμενη, εργαστηριακή αναπαράσταση. Στον πραγματικό κόσμο, οι ίδιες αλυσίδες αναγνώρισης τρέχουν εναντίον της δικής σας επιφάνειας επίθεσης — συνεχώς, χωρίς προειδοποίηση.

Η Audax Cybersecurity μεταφράζει αυτή τη λογική σε υπηρεσία: δομημένο penetration testing και offensive security validation που δοκιμάζουν ολόκληρες αλυσίδες επίθεσης, όχι μεμονωμένα ευρήματα. Και με το Erevos AI, την ετήσια managed υπηρεσία Continuous Threat Exposure Management (CTEM), αυτός ο έλεγχος γίνεται συνεχής: human-led, machine-scaled, με τεκμηριωμένη απόδειξη ανθεκτικότητας για τις απαιτήσεις NIS2 & DORA.

Human-led. Machine-scaled. Technically proven.

Αν θέλετε να δείτε τι πραγματικά σας εκθέτει — και να το αποδείξετε πριν το κάνει κάποιος άλλος — επισκεφθείτε το https://www.audax.gr και μιλήστε με την ομάδα μας.