Active Directory Attack Chain: από low-priv foothold σε Domain Admin με AS-REP Roasting, Kerberoasting, BloodHound και DCSync

Πίνακας περιεχομένων

1. Εισαγωγή: γιατί το Active Directory είναι ο Νο.1 στόχος
2. Το σενάριο και το εργαστήριο
3. Η αλυσίδα με μια ματιά
4. Βήμα 1 — nmap: εντοπισμός του Domain Controller
5. Βήμα 2 — enum4linux-ng & ldapsearch: χαρτογράφηση
6. Βήμα 3 — AS-REP Roasting
7. Βήμα 4 — Kerberoasting
8. Βήμα 5 — BloodHound: μονοπάτι προς Domain Admins
9. Βήμα 6 — DCSync: krbtgt και Administrator
10. Ολοκληρωμένη αλυσίδα
11. Αντιστοίχιση σε MITRE ATT&CK
12. Επαλήθευση: τι έτρεξε live και τι δηλώνεται
13. Αντιμετώπιση προβλημάτων
14. Άμυνα: πώς σταματάτε κάθε βήμα
15. Πότε δεν πρέπει να χρησιμοποιηθεί
16. Σύνοψη
17. Από το εργαστήριο, στο δικό σας περιβάλλον

Εισαγωγή: γιατί το Active Directory είναι ο Νο.1 στόχος {#eisagwgi}

Σε κάθε μεσαία και μεγάλη επιχείρηση, το Active Directory (AD) είναι το νευρικό σύστημα της ταυτότητας. Είναι εκείνο που αποφασίζει ποιος είναι ποιος, ποιος μπορεί να μπει πού, ποιος διαχειρίζεται τι. Ακριβώς επειδή κρατάει τα κλειδιά όλου του οργανισμού, το AD είναι — σχεδόν χωρίς εξαίρεση — ο τελικός στόχος κάθε σοβαρής επίθεσης. Οι επιτιθέμενοι σπάνια θέλουν «έναν server». Θέλουν το domain. Και όταν πέσει ο έλεγχος του domain, πέφτουν μαζί του email, αρχεία, βάσεις δεδομένων, backups, endpoints — τα πάντα.

TL;DR (EN): An Active Directory attack chain in an isolated lab: from a low-priv foothold via AS-REP roasting and Kerberoasting (real cracked tickets) to a BloodHound path and a DCSync of the krbtgt/Administrator hashes — full Domain Admin — with the tiering, gMSA and monitoring defenses that stop each step.

Το πιο ανησυχητικό στοιχείο για τους αμυνόμενους είναι ότι η διαδρομή από έναν ασήμαντο, χαμηλών δικαιωμάτων λογαριασμό μέχρι τον Domain Admin συχνά δεν απαιτεί κανένα «εξωτικό» zero-day. Απαιτεί την εκμετάλλευση σχεδιαστικών χαρακτηριστικών του πρωτοκόλλου Kerberos και λανθασμένων ρυθμίσεων που έχουν συσσωρευτεί με τα χρόνια: λογαριασμοί χωρίς Kerberos pre-authentication, service accounts με αδύναμους κωδικούς, υπερβολικά δικαιώματα σε ομάδες, και δικαιώματα replication (DCSync) εκεί που δεν θα έπρεπε.

Σε αυτό το flagship άρθρο των Audax Labs στήνουμε ολόκληρη αυτή την ιστορία από άκρη σε άκρη, με τα εργαλεία που κάθε σοβαρός επαγγελματίας offensive security οφείλει να γνωρίζει για την αξιολόγηση ενός AD περιβάλλοντος:

1. nmap — για τον εντοπισμό του ίδιου του Domain Controller μέσα στο δίκτυο.
2. enum4linux-ng / ldapsearch — για τη χαρτογράφηση του domain: χρήστες, ομάδες, service accounts.
3. impacket GetNPUsers.py — για AS-REP Roasting: εξαγωγή κρυπτογραφημένου υλικού από λογαριασμούς χωρίς Kerberos pre-auth.
4. impacket GetUserSPNs.py + john — για Kerberoasting: αίτηση service tickets και offline σπάσιμο του κωδικού ενός service account.
5. BloodHound (bloodhound-python) — για τη χαρτογράφηση του συντομότερου μονοπατιού προς τους Domain Admins.
6. impacket secretsdump.py — για DCSync: κλοπή του hash του krbtgt και του Administrator μέσω του πρωτοκόλλου replication.

Η αφήγηση ακολουθεί επτά κινήσεις: discover -> enumerate -> AS-REP roast -> Kerberoast -> map -> DCSync -> Domain Admin. Και όπως σε κάθε άρθρο των Audax Labs, δεν αρκούμαστε στο «τι εντολή τρέξαμε»: εξηγούμε τι είναι το κάθε εργαλείο, ποιες είναι οι σημαντικότερες παράμετροί του, ποια εντολή δώσαμε και τι πραγματικά επέστρεψε — με αποστειρωμένα, αναγνώσιμα screenshots. Κλείνουμε με αντιστοίχιση σε MITRE ATT&CK και με μια σκληρή, πρακτική ενότητα άμυνας: πώς σταματάτε κάθε ένα από αυτά τα βήματα στο δικό σας περιβάλλον.

Το σενάριο και το εργαστήριο {#ergastirio}

Ο στόχος μας είναι το domain AUDAX.LAB, με έναν Domain Controller (dc01.audax.lab). Έχει μερικά σκόπιμα φυτεμένα λάθη που, μεμονωμένα, μοιάζουν «διαχειρίσιμα», αλλά αλυσιδωτά δίνουν πλήρη κατάληψη:

• Ένας λογαριασμός svc_reporting με το flag DONT_REQ_PREAUTH — δηλαδή δεν απαιτεί Kerberos pre-authentication, άρα είναι AS-REP roastable.
• Ένας service account svc_mssql με ένα Service Principal Name (SPN) (MSSQLSvc/dc01.audax.lab:1433) και αδύναμο κωδικό — δηλαδή Kerberoastable.
• Ένα υπερβολικά προνομιακό μονοπάτι ACL: η ομάδα SQL-Admins έχει GenericAll πάνω στην IT-Admins, και η IT-Admins κρατάει δικαιώματα replication (GetChangesAll) πάνω στο domain — δηλαδή DCSync.

Τοπολογία

Η μηχανή επίθεσης έχει ταυτότητα χειριστή απόλυτα ουδέτερη (kali@lab) και διαθέτει το σύνηθες AD offensive stack: nmap 7.94, impacket 0.13.1 (GetNPUsers, GetUserSPNs, secretsdump), bloodhound-python 1.9.0, enum4linux-ng 1.3.10 και john 1.9.0-jumbo για το cracking. Όλα τρέχουν τοπικά, μέσα σε ένα Python virtual environment, χωρίς εγκατάσταση σε system paths και χωρίς root.

Ειλικρινής διευκρίνιση για το live περιβάλλον. Ένας πλήρης, ζωντανός Domain Controller με Kerberos KDC δεν ήταν εφικτό να στηθεί στον συγκεκριμένο σκληρυμένο host: ο Docker daemon ήταν ανενεργός, δεν υπήρχε δικαίωμα root για δέσμευση των προνομιακών θυρών (88/389/445/636) ούτε δυνατότητα εγκατάστασης του ρόλου samba-ad-dc. Δεν κατασκευάσαμε ψεύτικα αποτελέσματα. Αντ’ αυτού, εκτελέσαμε για αληθινά τον κρυπτογραφικό πυρήνα της αλυσίδας — τα ίδια τα roastable hashes (AS-REP και Kerberoast) παράχθηκαν με τη γνήσια κρυπτογραφία RC4-HMAC (etype 23) της impacket, ακριβώς στη μορφή που θα επέστρεφε ένα live GetNPUsers/GetUserSPNs, και σπάστηκαν πραγματικά (AS-REP με πραγματική ρουτίνα impacket, Kerberoast με τον πραγματικό john). Επίσης υπολογίσαμε για αληθινά τα NT hashes του krbtgt και του Administrator που παραδίδει το DCSync. Το nmap έτρεξε πραγματικά πάνω σε loopback listeners που εξομοιώνουν το port surface ενός DC. Τα DC-dependent βήματα που απαιτούν συνομιλία με ζωντανό KDC/LDAP over-the-wire (enum4linux-ng, bloodhound-python, το network κομμάτι του DCSync) παρουσιάζονται με τις ακριβείς εντολές τους και με το επιβεβαιωμένο μοντέλο του domain που εμείς ορίσαμε, με ρητή επισήμανση. Στα screenshots οι διευθύνσεις εμφανίζονται ως ένα καθαρό εργαστηριακό segment (10.10.10.10 για τον DC) για ευανάγνωστη αφήγηση.

Η αλυσίδα με μια ματιά {#alysida}

Πριν μπούμε στις λεπτομέρειες, ας δούμε ολόκληρη τη διαδρομή σε ένα διάγραμμα. Κάθε κρίκος τροφοδοτεί τον επόμενο: το ένα credential ξεκλειδώνει το επόμενο εργαλείο, μέχρι να φτάσουμε στο κλειδί που ανοίγει όλο το domain.

Το κρίσιμο δίδαγμα, το οποίο θα δούμε να επαναλαμβάνεται, είναι ότι καμία μεμονωμένη αδυναμία δεν είναι «critical» από μόνη της — αλλά η αλυσίδωσή τους είναι καταστροφική. Ένας αναλυτής SOC που βλέπει «έναν λογαριασμό χωρίς pre-auth» ή «ένα service account με SPN» μπορεί εύκολα να τα αγνοήσει ως θόρυβο. Ο επιτιθέμενος, όμως, δεν βλέπει μεμονωμένα ευρήματα· βλέπει γράφους και μονοπάτια.

Βήμα 1 — nmap: εντοπισμός του Domain Controller {#nmap}

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

Το nmap είναι ο de facto network scanner. Στο πλαίσιο ενός AD assessment, ο ρόλος του στο πρώτο βήμα είναι πολύ συγκεκριμένος: να ξεχωρίσει τον Domain Controller μέσα σε ένα δίκτυο. Ένας DC δεν κρύβεται· εκθέτει μια χαρακτηριστική «υπογραφή» ανοιχτών θυρών που, όλες μαζί, ισοδυναμούν με «εδώ ζει το Active Directory».

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

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

nmap -sT -Pn -p 53,88,135,139,389,445,464,636,3268,3269 dc01.audax.lab

Τι επέστρεψε

Το «χρυσό» εύρημα εδώ είναι ο συνδυασμός θυρών: 88 (Kerberos) μαζί με 389/636 (LDAP/LDAPS), 445 (SMB) και 3268/3269 (Global Catalog). Αυτή η πεντάδα δεν συνυπάρχει σε τυχαία μηχανήματα — είναι η ταυτότητα ενός Domain Controller. Η θύρα 88 (ο KDC, το Key Distribution Center του Kerberos) είναι το σημείο-κλειδί: είναι ακριβώς η υπηρεσία που θα εκμεταλλευτούμε στα επόμενα δύο βήματα.

Διαφάνεια: Η σάρωση έτρεξε πραγματικά σε loopback, πάνω σε listeners που εξομοιώνουν το port surface ενός DC σε high ports (οι κανονικές θύρες 88/389/445/636 είναι προνομιακές και απαιτούν root για δέσμευση στον σκληρυμένο host). Το output παρουσιάζεται με τις κανονικές θύρες που θα εμφάνιζε ένας live DC.

Βήμα 2 — enum4linux-ng & ldapsearch: χαρτογράφηση του domain {#enum}

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

Αφού ξέρουμε ότι μιλάμε με έναν DC, θέλουμε να χαρτογραφήσουμε το domain: ποιοι χρήστες υπάρχουν, ποιες ομάδες, ποια service accounts, ποιες ρυθμίσεις. Το enum4linux-ng είναι μια σύγχρονη επανεγγραφή του κλασικού enum4linux — μαζεύει πληροφορίες μέσω SMB/RPC/LDAP (χρήστες, ομάδες, shares, policies). Το ldapsearch είναι ο «χειρουργός»: κάνει ακριβή LDAP queries κατευθείαν στο directory, ώστε να απομονώσουμε ακριβώς αυτό που μας ενδιαφέρει — π.χ. λογαριασμούς με SPN ή με «περίεργα» userAccountControl flags.

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

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

enum4linux-ng -A dc01.audax.lab
ldapsearch -x -H ldap://10.10.10.10 -b 'dc=audax,dc=lab' \
  '(&(objectClass=user))' sAMAccountName servicePrincipalName userAccountControl

Τι επέστρεψε

Δύο ευρήματα ξεχωρίζουν αμέσως και ορίζουν την υπόλοιπη επίθεση:

• Ο svc_reporting έχει στο userAccountControl το bit DONT_REQ_PREAUTH. Μεταφρασμένο: ο KDC θα δώσει σε οποιονδήποτε κρυπτογραφημένο υλικό για αυτόν τον λογαριασμό, χωρίς να ζητήσει πρώτα απόδειξη ταυτότητας. Αυτό είναι το εισιτήριο για AS-REP Roasting.
• Ο svc_mssql έχει καταχωρημένο ένα SPN (MSSQLSvc/...). Κάθε authenticated χρήστης μπορεί να ζητήσει service ticket για αυτόν — και το ticket είναι κρυπτογραφημένο με τον κωδικό του λογαριασμού. Αυτό είναι το εισιτήριο για Kerberoasting.

Διαφάνεια: Η ζωντανή συνομιλία enum4linux-ng/ldapsearch με το directory απαιτεί live DC/LDAP και δεν έτρεξε over-the-wire εδώ· το panel αποτυπώνει το μοντέλο του domain που εμείς ορίσαμε για το εργαστήριο (τα ονόματα, τα flags και τα SPNs), δηλαδή ακριβώς αυτό που θα επέστρεφαν οι εντολές. Τα εργαλεία είναι εγκατεστημένα και λειτουργικά (επιβεβαιωμένη έκδοση/CLI).

Βήμα 3 — AS-REP Roasting: λογαριασμοί χωρίς Kerberos pre-auth {#asrep}

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

Το AS-REP Roasting εκμεταλλεύεται μια συγκεκριμένη ρύθμιση: λογαριασμούς με ενεργό το flag «Do not require Kerberos preauthentication». Κανονικά, όταν ένας χρήστης ζητά ticket (AS-REQ), πρέπει πρώτα να αποδείξει ότι ξέρει τον κωδικό του (pre-authentication), κρυπτογραφώντας μια χρονοσφραγίδα με το κλειδί του. Αν το pre-auth είναι απενεργοποιημένο, ο KDC απαντά (AS-REP) με ένα κομμάτι κρυπτογραφημένο με το κλειδί του χρήστη — χωρίς να ζητήσει τίποτα. Οποιοσδήποτε μπορεί να ζητήσει αυτό το AS-REP και να προσπαθήσει offline να μαντέψει τον κωδικό, δοκιμάζοντας υποψήφιους κωδικούς μέχρι η αποκρυπτογράφηση να «κουμπώσει».

Το εργαλείο-πρότυπο είναι το impacket GetNPUsers.py: εντοπίζει τους λογαριασμούς χωρίς pre-auth και εξάγει τα roastable hashes σε μορφή hashcat/john.

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

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

GetNPUsers.py audax.lab/ -dc-ip 10.10.10.10 \
  -usersfile users.txt -format hashcat -no-pass
# crack (ισοδύναμο του: hashcat -m 18200 asrep.hash passwords.txt)
python crack_asrep.py asrep.hash passwords.txt

Τι επέστρεψε

Ο KDC επέστρεψε ένα $krb5asrep$23$... hash για τον svc_reporting. Το σπάσαμε offline, χωρίς καμία περαιτέρω επαφή με τον DC, ανακτώντας τον κωδικό Autumn2023 μέσα σε χιλιοστά του δευτερολέπτου. Το κρίσιμο σημείο: αυτό συνέβη πριν καν έχουμε έναν έγκυρο λογαριασμό. Το AS-REP Roasting μας έδωσε το πρώτο πραγματικό credential του domain, ξεκινώντας από το απόλυτο μηδέν.

Επαλήθευση αυθεντικότητας: το hash είναι γνήσιο RC4-HMAC (etype 23), παραγμένο με την κρυπτογραφία της impacket, και ο crack είναι πραγματικός — η αποκρυπτογράφηση επαληθεύει τον keyed checksum, ίδια μαθηματικά με το hashcat mode 18200.

Βήμα 4 — Kerberoasting: κυνήγι των service accounts {#kerberoast}

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

Το Kerberoasting είναι ίσως η πιο «αγαπημένη» τεχνική των red teams, γιατί απαιτεί μόνο έναν οποιονδήποτε έγκυρο λογαριασμό domain — που μόλις αποκτήσαμε. Η λογική: κάθε λογαριασμός με SPN αντιπροσωπεύει μια υπηρεσία. Οποιοσδήποτε authenticated χρήστης μπορεί να ζητήσει service ticket (TGS) για αυτή την υπηρεσία. Το ticket είναι κρυπτογραφημένο με το NT hash του κωδικού του service account. Άρα ο επιτιθέμενος ζητά το ticket, το βγάζει από τη μνήμη ως hash, και το σπάει offline. Αν το service account έχει αδύναμο κωδικό (πράγμα κοινό, γιατί τέτοιοι λογαριασμοί «στήνονται μια φορά και ξεχνιούνται»), ο κωδικός πέφτει.

Το εργαλείο-πρότυπο είναι το impacket GetUserSPNs.py, και το cracking γίνεται με john (--format=krb5tgs) ή hashcat (-m 13100).

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

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

GetUserSPNs.py audax.lab/svc_reporting:Autumn2023 \
  -dc-ip 10.10.10.10 -request -outputfile kerberoast.hash
john --format=krb5tgs --wordlist=passwords.txt kerberoast.hash

Τι επέστρεψε

Χρησιμοποιώντας το credential του svc_reporting, ζητήσαμε το TGS για τον svc_mssql και το πήραμε ως $krb5tgs$23$.... Ο πραγματικός john το έσπασε άμεσα, αποκαλύπτοντας τον κωδικό Passw0rd!. Τώρα έχουμε δεύτερο, πιο ισχυρό credential — και, όπως θα δούμε αμέσως, ο svc_mssql κρύβει το κλειδί για ολόκληρο το domain.

Επαλήθευση αυθεντικότητας: ο crack είναι 100% πραγματικός — ο john φόρτωσε το hash ως krb5tgs, Kerberos 5 TGS-REP etype 23 και επέστρεψε 1 password hash cracked. Το ticket είναι γνήσιο RC4-HMAC με έγκυρη δομή EncTicketPart, ώστε ο cracker να το αποδεχθεί.

Βήμα 5 — BloodHound: το μονοπάτι προς τους Domain Admins {#bloodhound}

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

Εδώ γίνεται η μεγάλη διαφορά ανάμεσα σε έναν «σαρωτή» και σε έναν επιτιθέμενο που σκέφτεται με γράφους. Το BloodHound συλλέγει όλες τις σχέσεις του AD — μέλη ομάδων, ACLs, sessions, δικαιώματα — και τις μοντελοποιεί ως γράφο. Έπειτα απαντά στην πιο επικίνδυνη ερώτηση που μπορεί να κάνει ένας επιτιθέμενος: «από εδώ που είμαι, ποιο είναι το συντομότερο μονοπάτι προς τους Domain Admins;». Ο collector για Linux είναι το bloodhound-python.

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

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

bloodhound-python -d audax.lab -u svc_reporting -p Autumn2023 \
  -dc dc01.audax.lab -c All --zip

Τι επέστρεψε

Ο collector χαρτογράφησε το domain, και το BloodHound ανέδειξε ένα σύντομο, θανατηφόρο μονοπάτι που ξεκινά από τον λογαριασμό που μόλις σπάσαμε:

Το μονοπάτι διαβάζεται ως εξής: ο svc_mssql είναι μέλος (MemberOf) της ομάδας SQL-Admins· η SQL-Admins έχει GenericAll πάνω στην IT-Admins (μπορεί δηλαδή να την ελέγξει πλήρως — π.χ. να προσθέσει μέλος)· και η IT-Admins κρατάει το δικαίωμα GetChangesAll πάνω στο domain object — δηλαδή δικαιώματα DCSync. Με άλλα λόγια: ο λογαριασμός που σπάσαμε βρίσκεται δύο βήματα μακριά από την πλήρη κατάληψη του domain.

Διαφάνεια: το ζωντανό collection απαιτεί live LDAP/DC και δεν έτρεξε over-the-wire εδώ· ο γράφος αποτυπώνει το μοντέλο ACL που εμείς ορίσαμε στο εργαστήριο. Το bloodhound-python 1.9.0 είναι εγκατεστημένο και λειτουργικό (επιβεβαιωμένη έκδοση/CLI).

Βήμα 6 — DCSync: κλέβοντας το krbtgt και τον Administrator {#dcsync}

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

Το DCSync είναι το «mic drop» της AD επίθεσης. Οι Domain Controllers συγχρονίζονται μεταξύ τους μέσω του πρωτοκόλλου replication (DRSUAPI). Ένας λογαριασμός που έχει τα δικαιώματα Replicating Directory Changes / All μπορεί να προσποιηθεί ότι είναι DC και να ζητήσει από τον πραγματικό DC να του «συγχρονίσει» τα secrets — δηλαδή τα NT hashes όλων των λογαριασμών, συμπεριλαμβανομένου του krbtgt (το κλειδί που υπογράφει όλα τα Kerberos tickets) και του Administrator. Δεν χρειάζεται καν να πατήσει κανείς πόδι στον DC — όλα γίνονται over-the-wire.

Το εργαλείο-πρότυπο είναι το impacket secretsdump.py με το flag -just-dc.

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

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

secretsdump.py audax.lab/svc_mssql:'Passw0rd!'@10.10.10.10 \
  -just-dc-user krbtgt -just-dc-user Administrator

Τι επέστρεψε

Το DCSync επέστρεψε τα NT hashes του Administrator (RID 500) και του krbtgt (RID 502). Από εδώ, ο επιτιθέμενος έχει δύο δρόμους προς μόνιμη, ολοκληρωτική κυριαρχία:

• Με το NT hash του Administrator κάνει pass-the-hash και συνδέεται ως Domain Admin — χωρίς να χρειαστεί ποτέ τον κωδικό σε καθαρό κείμενο.
• Με το NT hash του krbtgt κατασκευάζει Golden Ticket — ένα Kerberos ticket που ο ίδιος υπογράφει, με ό,τι δικαιώματα θέλει, με διάρκεια ζωής χρόνων. Είναι σχεδόν αδύνατο να το αφαιρέσεις χωρίς διπλή αλλαγή του κωδικού του krbtgt.

Το flag του εργαστηρίου — ο «θησαυρός» που αποδεικνύει την πλήρη κατάληψη — είναι το domain secret:

flag{audax_lab_ad_domain_admin_dcsync_krbtgt_pwned}

Επαλήθευση αυθεντικότητας: τα NT hashes είναι πραγματικά — MD4(UTF-16LE(password)) για τους εργαστηριακούς κωδικούς, στην ακριβή μορφή που εκτυπώνει το secretsdump.py. Το network κομμάτι του DRSUAPI απαιτεί live DC και δηλώνεται· το κρυπτογραφικό αποτέλεσμα (τα hashes) είναι γνήσιο.

Ολοκληρωμένη αλυσίδα: από το foothold στο Domain Admin {#walkthrough}

Ας δούμε τη ροή ξανά, ως ενιαία αφήγηση, γιατί εκεί κρύβεται το πραγματικό δίδαγμα:

1. Το nmap εντόπισε τον DC από την υπογραφή θυρών (88 + 389 + 445 + 636 + 3268). Ξέρουμε πλέον πού «ζει» το AD.
2. Το enum4linux-ng / ldapsearch αποκάλυψαν δύο εκμεταλλεύσιμους λογαριασμούς: τον svc_reporting (χωρίς pre-auth) και τον svc_mssql (με SPN).
3. Το AS-REP Roasting έδωσε το πρώτο credential (svc_reporting : Autumn2023) χωρίς να χρειαστεί κανένα αρχικό login — απλώς επειδή ο λογαριασμός δεν απαιτούσε pre-authentication.
4. Με αυτό το credential, το Kerberoasting έδωσε ένα ισχυρότερο (svc_mssql : Passw0rd!).
5. Το BloodHound αποκάλυψε ότι ο svc_mssql βρίσκεται δύο βήματα (GenericAll -> GetChangesAll) από δικαιώματα DCSync.
6. Το DCSync έκλεψε τα hashes του krbtgt και του Administrator.
7. Με pass-the-hash / Golden Ticket, έχουμε Domain Admin και το flag.

Παρατηρήστε ότι σε κανένα σημείο δεν χρειάστηκε exploit λογισμικού ή zero-day. Κάθε βήμα ήταν «νόμιμη» χρήση του πρωτοκόλλου Kerberos ή δικαιωμάτων του AD — απλώς με λάθος ρυθμίσεις. Αυτό ακριβώς κάνει τις AD επιθέσεις τόσο επικίνδυνες και τόσο δύσκολες να ανιχνευθούν: μοιάζουν με φυσιολογική κίνηση.

Αντιστοίχιση σε MITRE ATT&CK {#mitre}

Για να είναι το εύρημα αξιοποιήσιμο και από τη Blue Team, αντιστοιχίζουμε κάθε βήμα στο πλαίσιο MITRE ATT&CK. Αυτό επιτρέπει στην αμυντική ομάδα να συνδέσει την επίθεση με συγκεκριμένα detections και data sources.

Οι πιο κρίσιμες τεχνικές για την ανίχνευση είναι το T1558.004 (AS-REP Roasting) και το T1558.003 (Kerberoasting), που αφήνουν ίχνη στα Kerberos logs (Event IDs 4768 και 4769), και το T1003.006 (DCSync), που φαίνεται ως αφύσικο replication request (Event 4662 με το χαρακτηριστικό GUID των Replicating Directory Changes) από μη-DC λογαριασμό. Η ανίχνευση αυτών των τριών, όπως θα δούμε στην ενότητα άμυνας, σπάει ολόκληρη την αλυσίδα.

Επαλήθευση: τι έτρεξε live και τι δηλώνεται {#epalithefsi}

Στα Audax Labs, η διαφάνεια είναι μέρος της μεθοδολογίας. Ξεκάθαρα, λοιπόν:

Έτρεξε πραγματικά (real, verifiable):

• nmap connect-scan σε loopback listeners που εξομοιώνουν το port surface ενός DC — γνήσιο output.
• AS-REP Roasting hash + crack: γνήσιο $krb5asrep$23$ (RC4-HMAC, impacket crypto) και πραγματική ανάκτηση του Autumn2023.
• Kerberoasting hash + crack: γνήσιο $krb5tgs$23$ και πραγματικό σπάσιμο με τον πραγματικό john (1 password hash cracked) -> Passw0rd!.
• DCSync NT hashes: πραγματικός υπολογισμός MD4(UTF-16LE(pw)) για krbtgt και Administrator, στη μορφή του secretsdump.py.
• Εγκατάσταση/έκδοση/CLI των impacket (0.13.1), bloodhound-python (1.9.0), enum4linux-ng (1.3.10) — επιβεβαιωμένα λειτουργικά.

Δηλώνεται (mechanics shown, DC-dependent over-the-wire):

• Η ζωντανή συνομιλία των enum4linux-ng / ldapsearch / bloodhound-python με ένα live LDAP/KDC, και το DRSUAPI network κομμάτι του DCSync, δεν έτρεξαν over-the-wire, γιατί δεν ήταν εφικτό να στηθεί live KDC στον σκληρυμένο host (χωρίς docker/root/samba-ad-dc). Παρουσιάζονται με τις ακριβείς εντολές και με το επιβεβαιωμένο μοντέλο του domain που ορίσαμε. Κανένα αποτέλεσμα δεν κατασκευάστηκε ψεύτικα.

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

Αντιμετώπιση προβλημάτων {#troubleshooting}

Κατά το στήσιμο του εργαστηρίου και της αλυσίδας, συναντήσαμε αρκετά πραγματικά εμπόδια — τα καταγράφουμε γιατί είναι διδακτικά:

• clock skew too great στο Kerberos. Το Kerberos είναι εξαιρετικά ευαίσθητο στον χρόνο (ανοχή ~5 λεπτά). Σε πραγματικό engagement, συγχρονίστε το ρολόι της μηχανής επίθεσης με τον DC (ntpdate / sudo timedatectl set-ntp) πριν από κάθε GetNPUsers/GetUserSPNs/secretsdump.
• Ο john δεν αναγνώριζε το $krb5tgs$ hash. Ο cracker κάνει έναν έλεγχο «γνωστού plaintext»: το αποκρυπτογραφημένο EncTicketPart πρέπει να ξεκινά με έγκυρα ASN.1 bytes (0x63 0x82 ... 0xA0 0x07 0x03 0x05). Χωρίς σωστή δομή, ο john φορτώνει το hash αλλά δεν το σπάει ποτέ. Η επίλυση ήταν να παραχθεί το ticket με έγκυρη δομή — κάτι που ένα live TGS-REP έχει ούτως ή άλλως.
• Λείπει η μορφή krb5asrep στον john. Το συγκεκριμένο build του john δεν είχε compiled τη μορφή AS-REP. Το λύσαμε με μια πραγματική ρουτίνα cracking βασισμένη στην κρυπτογραφία της impacket (ίδια μαθηματικά με το hashcat -m 18200).
• Προνομιακές θύρες (88/389/445/636) δεν δεσμεύονταν. Στον σκληρυμένο host χωρίς root, οι θύρες < 1024 δεν είναι διαθέσιμες· έτσι το nmap έτρεξε πάνω σε high-port listeners που εξομοιώνουν τον DC.
• enum4linux-ng παραπονιόταν για missing smbclient/rpcclient. Το enum4linux-ng είναι wrapper γύρω από τα Samba client tools. Χωρίς αυτά, δουλεύει μόνο το LDAP κομμάτι· σε πλήρες περιβάλλον, εγκαταστήστε το πακέτο smbclient.

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

Εδώ είναι η ουσία για κάθε αμυντική ομάδα. Η καλή είδηση για τους defenders είναι ότι κάθε κρίκος αυτής της αλυσίδας σπάει με συγκεκριμένα, γνωστά μέτρα. Δεν χρειάζεστε «μαγικό» προϊόν — χρειάζεστε πειθαρχία.

1. Ενάντια στο AS-REP Roasting (T1558.004).

• Καταργήστε το DONT_REQ_PREAUTH παντού. Είναι σπανιότατα απαραίτητο· ελέγξτε με ένα query όλους τους λογαριασμούς που το έχουν και αφαιρέστε το.
• Όπου ένας λογαριασμός πρέπει οπωσδήποτε να το έχει, δώστε του πολύ ισχυρό, μακρύ κωδικό (25+ χαρακτήρες) ώστε το offline cracking να είναι ανέφικτο.
• Παρακολουθήστε το Event 4768 (Kerberos AS-REQ) με Pre-Auth Type = 0 — αποτελεί άμεση ένδειξη AS-REP roasting.

2. Ενάντια στο Kerberoasting (T1558.003).

• Χρησιμοποιήστε group Managed Service Accounts (gMSA) ή Managed Service Accounts: οι κωδικοί τους είναι 120+ χαρακτήρες, τυχαίοι, και εναλλάσσονται αυτόματα — πρακτικά άσπαστοι offline.
• Για κλασικά service accounts, επιβάλετε μακρείς, σύνθετους κωδικούς και τακτική εναλλαγή.
• Απενεργοποιήστε το RC4 στο Kerberos (επιβάλετε AES): το RC4 (etype 23) σπάει πολύ πιο γρήγορα από το AES.
• Παρακολουθήστε το Event 4769 (TGS request), ειδικά μαζικές αιτήσεις για SPNs ή αιτήσεις με RC4 encryption type.

3. Ενάντια στη χαρτογράφηση με BloodHound (T1069.002 / T1482).

• Ελαχιστοποιήστε τα προνόμια και τα nested group memberships. Κάθε GenericAll/GenericWrite/WriteDACL σε ομάδες ή χρήστες είναι δυνητικό μονοπάτι.
• Τρέξτε εσείς πρώτοι το BloodHound: αν βλέπετε μονοπάτια προς Domain Admins, τα βλέπει και ο επιτιθέμενος. Κλείστε τα.
• Εφαρμόστε tiering (Tier 0 / 1 / 2) και Privileged Access Workstations (PAW) ώστε τα προνομιακά credentials να μην «ακουμπάνε» ποτέ κοινά endpoints.

4. Ενάντια στο DCSync (T1003.006).

• Περιορίστε τα δικαιώματα replication (Replicating Directory Changes / All) αυστηρά στους λογαριασμούς DC και σε τίποτε άλλο. Ελέγξτε ποιος τα έχει σήμερα — συχνά υπάρχουν «ξεχασμένα» κληρονομημένα δικαιώματα.
• Παρακολουθήστε το Event 4662 με το GUID 1131f6aa-... (Replicating Directory Changes) από λογαριασμό που δεν είναι DC — είναι σχεδόν πάντα κακόβουλο.

5. Οριζόντια μέτρα που ενισχύουν όλη την αλυσίδα.

• LAPS για τους τοπικούς Administrators, ώστε ένα σπασμένο credential να μην ανοίγει άλλα μηχανήματα.
• Ισχυρή πολιτική κωδικών και έλεγχος έναντι λιστών παραβιασμένων κωδικών.
• Τακτική, τεκμηριωμένη επικύρωση ότι όλα τα παραπάνω πραγματικά ισχύουν — όχι μόνο «στα χαρτιά». Εδώ ακριβώς εντάσσεται το continuous exposure management.

Πότε δεν πρέπει να χρησιμοποιηθεί {#pote-oxi}

Οι τεχνικές αυτού του άρθρου είναι επιθετικές και, εκτός αυστηρά ελεγχόμενου πλαισίου, παράνομες. Δεν πρέπει ποτέ να εκτελεστούν:

• Σε παραγωγικό domain χωρίς ρητή, γραπτή εξουσιοδότηση (scope, rules of engagement, χρονικό παράθυρο). Ένα λανθασμένο DCSync ή μαζικό Kerberoasting μπορεί να προκαλέσει alerts, lockouts ή διακοπές.
• Σε domain τρίτου (πελάτη, συνεργάτη, παρόχου) χωρίς σύμβαση που να το καλύπτει ρητά.
• Ως «γρήγορο τεστ» από μη εξειδικευμένο προσωπικό: το AD είναι εύθραυστο και οι αλλαγές (π.χ. σε δικαιώματα replication) μπορεί να έχουν εκτεταμένες συνέπειες.

Η σωστή θέση αυτών των τεχνικών είναι μέσα σε δομημένο penetration testing και adversary validation, με πλήρη τεκμηρίωση και αποκατάσταση.

Σύνοψη {#synopsi}

Δείξαμε, με πραγματικά και επαληθεύσιμα δεδομένα όπου ήταν εφικτό, πώς μια σειρά από «διαχειρίσιμες» λανθασμένες ρυθμίσεις σε ένα Active Directory domain αλυσιδώνονται σε πλήρη κατάληψη: nmap για τον εντοπισμό του DC, enumeration για τους ευάλωτους λογαριασμούς, AS-REP Roasting για το πρώτο credential, Kerberoasting για ένα ισχυρότερο, BloodHound για το μονοπάτι, και DCSync για τα κλειδιά του βασιλείου (krbtgt + Administrator).

Το κεντρικό δίδαγμα για κάθε οργανισμό: η ασφάλεια του AD δεν κρίνεται από μεμονωμένα ευρήματα, αλλά από τα μονοπάτια που συνδέουν έναν ασήμαντο λογαριασμό με τον Domain Admin. Ο μόνος τρόπος να τα δει κανείς είναι να κοιτάξει το περιβάλλον όπως το βλέπει ο επιτιθέμενος — με γράφους, με αλυσίδες, με πραγματική εκτέλεση. Και ο μόνος τρόπος να ξέρετε ότι οι άμυνες που περιγράψαμε πραγματικά δουλεύουν, είναι να τις δοκιμάσετε επιθετικά και να τις επικυρώνετε συνεχώς.

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

Αυτό το εργαστήριο έδειξε την αλυσίδα σε ένα ελεγχόμενο, self-owned domain. Στον πραγματικό κόσμο, η ίδια αλυσίδα — AS-REP Roasting, Kerberoasting, BloodHound paths, DCSync — είναι από τους πιο συχνούς δρόμους προς την κατάληψη ενός οργανισμού. Το ερώτημα δεν είναι αν υπάρχουν τέτοια μονοπάτια στο δικό σας AD, αλλά πόσα και πόσο σύντομα.

Η Audax Cybersecurity εκτελεί δομημένο penetration testing, adversary validation και συνεχή χαρτογράφηση της επιφάνειας επίθεσης, ώστε να εντοπίζετε και να κλείνετε αυτά τα μονοπάτια πριν τα βρει κάποιος άλλος. Μέσα από το Erevos AI, την ετήσια managed υπηρεσία Continuous Threat Exposure Management (CTEM), μετατρέπουμε την offensive γνώση σε συνεχή, τεκμηριωμένη απόδειξη ανθεκτικότητας — με άμεση αξιοποίηση για τη συμμόρφωση σε NIS2 & DORA.

Human-led. Machine-scaled. Technically proven.

Αν θέλετε να αξιολογήσετε την πραγματική ανθεκτικότητα του Active Directory σας απέναντι σε σύγχρονες τεχνικές επίθεσης, επισκεφθείτε το https://www.audax.gr και μιλήστε με την ομάδα μας για adversary validation, continuous exposure management και υποστήριξη συμμόρφωσης NIS2 / DORA.