Active Directory: Kerberoasting σε βάθος

Το Kerberoasting είναι μία από τις υψηλότερης αξίας τεχνικές σε κάθε Active Directory engagement: εκμεταλλεύεται εγγενή σχεδίαση του πρωτοκόλλου Kerberos, εκτελείται από οποιονδήποτε authenticated domain user χωρίς προνόμια, και σπάει offline χωρίς θόρυβο. Σε αυτό το βαθύ, αμυντικά προσανατολισμένο άρθρο δείχνουμε τη μηχανική της τεχνικής σε απομονωμένο AD lab (enum SPNs → request TGS → offline crack με Hashcat mode 13100), τη χαρτογράφηση σε MITRE ATT&CK T1558.003, και —κυρίως— εκτενή ανίχνευση και άμυνα: Event ID 4769 με behavioral filtering, encryption downgrade detection, gMSA/dMSA, μακριά passwords/PSOs, tiering και honeypot SPNs.

Πλαίσιο και ηθική: Το παρόν άρθρο είναι αμιγώς εκπαιδευτικό και αμυντικά προσανατολισμένο. Κάθε τεχνική που περιγράφεται προϋποθέτει ρητή γραπτή εξουσιοδότηση (authorized penetration testing) ή εκτέλεση σε απομονωμένο, εργαστηριακό AD lab που ελέγχετε πλήρως (εδώ χρησιμοποιούμε ουδέτερα ονόματα: domain lab.local, δίκτυο 10.10.10.0/24). Η χρήση αυτών των τεχνικών εναντίον υποδομής χωρίς άδεια είναι παράνομη. Ο πραγματικός στόχος του κειμένου είναι να δώσει σε μια blue team το βάθος κατανόησης που χρειάζεται για να ανιχνεύσει και να εξαλείψει το Kerberoasting.

Γιατί το Kerberoasting είναι κορυφαία τεχνική σε AD engagements

Σε ένα τυπικό internal engagement, ο επιτιθέμενος ξεκινά με ένα low-privileged domain account (μέσω phishing, password spraying ή ένα foothold σε κάποιο workstation). Το ερώτημα που ακολουθεί είναι πάντα: «πώς ανεβαίνω;». Το Kerberoasting απαντά σε αυτό με μοναδικό συνδυασμό χαρακτηριστικών:

• Χαμηλό προαπαιτούμενο: αρκεί ένα έγκυρο domain credential. Δεν χρειάζεται local admin σε κανένα μηχάνημα.
• Χαμηλός «θόρυβος» στο δίκτυο: το request ενός service ticket είναι απολύτως φυσιολογική λειτουργία του Kerberos. Χιλιάδες τέτοια requests γίνονται καθημερινά σε κάθε domain.
• Offline cracking: μόλις εξαχθεί το ticket, δεν υπάρχει καμία άλλη αλληλεπίδραση με το domain. Ο επιτιθέμενος μπορεί να δουλεύει με GPUs επί ημέρες χωρίς να παράγει ούτε ένα επιπλέον log entry, και χωρίς account lockouts.
• Στόχευση service accounts: οι λογαριασμοί με Service Principal Names (SPNs) είναι συχνά «ξεχασμένοι», με παλιά, χειροκίνητα ορισμένα passwords, σπάνιες αλλαγές, και —τραγικά— υπερβολικά δικαιώματα (π.χ. μέλη του Domain Admins ή με delegation).

Αυτός ο συνδυασμός «χαμηλού κόστους / υψηλής ανταμοιβής» είναι που κρατά το Kerberoasting στην κορυφή των AD attack paths, όπως αποτυπώνεται και σε εργαλεία όπως το BloodHound, που ρητά επισημαίνει kerberoastable υψηλής αξίας principals. Ένας single kerberoastable λογαριασμός με αδύναμο password αρκεί συχνά για privilege escalation ή lateral movement προς κρίσιμα assets.

Kerberos primer: TGT, TGS, SPNs και γιατί υπάρχει εκμεταλλευσιμότητα

Για να κατανοήσουμε πραγματικά την τεχνική —και άρα να την ανιχνεύσουμε— πρέπει να γνωρίζουμε τη ροή authentication του Kerberos. Το Kerberos είναι ticket-based και βασίζεται σε ένα έμπιστο τρίτο μέρος, το Key Distribution Center (KDC), ρόλο που στο AD παίζει ο Domain Controller (DC). Το KDC έχει δύο υπηρεσίες: το Authentication Service (AS) και το Ticket Granting Service (TGS).

Η ροή σε τρία στάδια

1. AS-REQ / AS-REP (αρχικό authentication): Ο χρήστης αποδεικνύει την ταυτότητά του (pre-authentication, τυπικά κρυπτογραφώντας ένα timestamp με το κλειδί που παράγεται από το password του). Ως απάντηση, το KDC εκδίδει ένα Ticket Granting Ticket (TGT), κρυπτογραφημένο με το κλειδί του λογαριασμού krbtgt. Το TGT αποδεικνύει «ποιος είσαι» για το υπόλοιπο session.
2. TGS-REQ / TGS-REP (πρόσβαση σε υπηρεσία): Όταν ο χρήστης θέλει να προσπελάσει μια υπηρεσία (π.χ. έναν SQL Server), στέλνει το TGT στο TGS και ζητά ένα service ticket (TGS ticket) για ένα συγκεκριμένο Service Principal Name (SPN). Το KDC εκδίδει το service ticket, κρυπτογραφώντας ένα τμήμα του με το κλειδί (NTLM hash / Kerberos key) του λογαριασμού που «τρέχει» την υπηρεσία.
3. AP-REQ (παρουσίαση στην υπηρεσία): Ο χρήστης παρουσιάζει το service ticket στην υπηρεσία, η οποία το αποκρυπτογραφεί με το δικό της κλειδί και επιβεβαιώνει την πρόσβαση.

Τι είναι το SPN και γιατί δημιουργεί το πρόβλημα

Το Service Principal Name είναι ένα μοναδικό αναγνωριστικό που συνδέει μια υπηρεσία με τον λογαριασμό (service account) που την εκτελεί, σε μορφή τύπου MSSQLSvc/db01.lab.local:1433 ή HTTP/web01.lab.local. Τα SPNs αποθηκεύονται στο attribute servicePrincipalName του αντικειμένου χρήστη ή υπολογιστή στο AD.

Το κρίσιμο σχεδιαστικό σημείο είναι το εξής: το KDC θα εκδώσει ένα service ticket για οποιοδήποτε SPN που ζητά ένας authenticated χρήστης, χωρίς να ελέγχει αν ο χρήστης όντως έχει δικαίωμα πρόσβασης στην υπηρεσία. Ο έλεγχος authorization γίνεται από την ίδια την υπηρεσία, αργότερα, στο AP-REQ. Επιπλέον —και εδώ κρύβεται η ευπάθεια— ένα κομμάτι του service ticket είναι κρυπτογραφημένο με κλειδί που προέρχεται απευθείας από το password του service account.

Συνεπώς, οποιοσδήποτε domain user μπορεί να ζητήσει ένα service ticket για έναν kerberoastable λογαριασμό, να λάβει πίσω κρυπτογραφημένο υλικό, και offline να δοκιμάσει passwords μέχρι να βρει αυτό που παράγει το σωστό κλειδί αποκρυπτογράφησης. Αν το service account έχει αδύναμο ή προβλέψιμο password, το cracking είναι θέμα χρόνου.

Ο ρόλος του encryption type

Η δυσκολία του cracking εξαρτάται άμεσα από τον encryption type του ticket. Ιστορικά, το RC4-HMAC (etype 23) χρησιμοποιεί απευθείας το NTLM hash του password ως κλειδί, χωρίς salt και χωρίς αργό key derivation, κάνοντάς το εξαιρετικά γρήγορο στο brute-force. Το AES128 (etype 17) και το AES256 (etype 18) χρησιμοποιούν salted, iterated PBKDF2-based key derivation, που είναι τάξεις μεγέθους πιο αργό στο cracking. Οι επιτιθέμενοι προτιμούν RC4 και συχνά επιχειρούν encryption downgrade — και αυτό ακριβώς είναι ένα από τα ισχυρότερα detection signals για τη blue team, όπως θα δούμε παρακάτω.

Προαπαιτούμενα και στήσιμο του lab

Για να αναπαράγετε τα παρακάτω με ασφάλεια, χρειάζεστε ένα απομονωμένο AD lab (χωρίς καμία σύνδεση με production δίκτυο):

• Ένας Domain Controller με Windows Server (domain lab.local, DC στο 10.10.10.10).
• Ένας-δύο member servers με ορισμένα SPNs (π.χ. ένας «SQL» και ένας «web» service account, ώστε να υπάρχουν kerberoastable στόχοι).
• Ένας χαμηλόβαθμος test user (lab.local\lowpriv) — προσομοιώνει το foothold ενός επιτιθέμενου.
• Ένας Linux attacker host (Kali) με Impacket και Hashcat, καθώς και (προαιρετικά) ένα Windows box με Rubeus για τη Windows-native διαδρομή.

Στόχος του lab δεν είναι «να χακάρουμε», αλλά να παρατηρήσουμε τι παράγει κάθε βήμα στα logs του DC, ώστε να σχεδιάσουμε αξιόπιστα detections.

Η τεχνική βήμα-βήμα σε lab (authorized / isolated AD)

Βήμα 1 — Enumeration των SPNs

Πρώτα εντοπίζουμε user accounts (όχι computer accounts) που έχουν ορισμένο SPN — αυτοί είναι οι kerberoastable στόχοι. Από ένα domain-joined Windows μηχάνημα με το ενσωματωμένο setspn:

setspn -T lab.local -Q */*

Πιο στοχευμένα, μέσω PowerView (κλασικό offensive tooling σε lab):

Get-DomainUser -SPN | Select-Object samaccountname,serviceprincipalname,memberof

Με το Impacket από Linux, χωρίς να χρειάζεται domain-joined host, αρκεί ένα έγκυρο credential. Το GetUserSPNs.py επιστρέφει τη λίστα των λογαριασμών με SPN, μαζί με χρήσιμα μεταδεδομένα όπως το PasswordLastSet και το group membership:

GetUserSPNs.py lab.local/lowpriv:'Passw0rd!' -dc-ip 10.10.10.10

Στο στάδιο αυτό, ο συνετός tester δεν σταματά στο «ποιοι είναι kerberoastable», αλλά διασταυρώνει ποιοι από αυτούς είναι υψηλής αξίας (π.χ. μέλη προνομιακών groups, με παλιό pwdLastSet, ή με unconstrained/constrained delegation). Στο παραπάνω output, ο svc_sql είναι μέλος του Domain Admins — ένα service account που είναι ταυτόχρονα kerberoastable και Domain Admin αποτελεί το «ιερό δισκοπότηρο».

Βήμα 2 — Request των TGS service tickets

Ζητάμε service tickets για τους στόχους. Με Impacket από Linux, η ίδια η GetUserSPNs.py κάνει και το request όταν προστεθεί το -request, εξάγοντας το κρυπτογραφημένο κομμάτι σε μορφή $krb5tgs$..., έτοιμο για offline cracking:

GetUserSPNs.py lab.local/lowpriv:'Passw0rd!' -dc-ip 10.10.10.10 -request -outputfile hashes.txt

Εναλλακτικά, από Windows, το Rubeus με το kerberoast module αυτοματοποιεί το request και εξάγει τα hashes σε crackable μορφή. Για να στοχεύσουμε συγκεκριμένο λογαριασμό και να αποφύγουμε τον «θόρυβο» του mass roasting:

Rubeus.exe kerberoast /user:svc_sql /outfile:svc_sql.txt

Το KDC απαντά με service tickets. Σημειώστε ότι σε αυτό ακριβώς το σημείο έχει ήδη δημιουργηθεί το log entry στον DC (το Event 4769 που θα αναλύσουμε) — είναι η μοναδική ανιχνεύσιμη πλευρά ολόκληρης της επίθεσης.

Βήμα 3 — Offline cracking με Hashcat (mode 13100)

Το κρυπτογραφημένο ticket σπάει offline. Ο Hashcat mode για TGS-REP με RC4 (etype 23) είναι το 13100. Για πιο ρεαλιστικά passwords service accounts, συνδυάζουμε wordlist με rules και GPU optimization:

hashcat -m 13100 -a 0 hashes.txt rockyou.txt -r rules/best64.rule -O -w 3

Αν το ticket είναι AES256, ο κατάλληλος mode είναι το 19700 (και 19600 για AES128) — σημαντικά πιο αργός. Γι’ αυτό οι επιτιθέμενοι επιθυμούν RC4. Μόλις ο Hashcat βρει το plaintext password, ο tester έχει τα credentials του service account. Αν αυτό είναι προνομιακό, το privilege escalation είναι άμεσο· αλλιώς χρησιμοποιείται για lateral movement.

Η ουσιαστική αμυντική διαπίστωση εδώ είναι διπλή: πρώτον, η μόνη ανιχνεύσιμη πλευρά της επίθεσης είναι το request (Βήμα 2)· το cracking είναι αόρατο. Δεύτερον, η μόνη πραγματική άμυνα στο cracking είναι το ίδιο το password να είναι αρκετά ισχυρό ώστε να μην σπάει — γι’ αυτό τα gMSA και τα μακρά passwords είναι κεντρικά στην άμυνα.

MITRE ATT&CK mapping

Το Kerberoasting αντιστοιχεί ρητά στο MITRE ATT&CK ως:

• T1558.003 — Steal or Forge Kerberos Tickets: Kerberoasting, κάτω από την τακτική Credential Access (TA0006).

Χρήσιμα γειτονικά techniques για να τοποθετήσετε την τεχνική στο ευρύτερο kill chain:

• T1558.001 — Golden Ticket και T1558.002 — Silver Ticket: post-exploitation abuse του Kerberos που μπορεί να ακολουθήσει αν ένα service account (ή το krbtgt) πέσει.
• T1558.004 — AS-REP Roasting: συγγενής τεχνική εναντίον λογαριασμών με απενεργοποιημένο pre-authentication.
• T1078 — Valid Accounts: η φυσική συνέχεια μόλις σπάσει το password του service account.
• T1087.002 — Account Discovery: Domain Account: αντιστοιχεί στο enumeration των SPNs (Βήμα 1).

Αυτό το mapping είναι πολύτιμο για blue teams: επιτρέπει τη σύνδεση των detection rules με συγκεκριμένα ATT&CK IDs, την αξιολόγηση κάλυψης (coverage) του SOC, και τη διεξαγωγή στοχευμένων purple team exercises.

Ανίχνευση και άμυνα (blue team)

Εδώ βρίσκεται η πραγματική αξία για έναν οργανισμό. Επειδή το Kerberoasting εκμεταλλεύεται νόμιμη λειτουργικότητα, η άμυνα δεν είναι ένα patch αλλά ένας συνδυασμός detection engineering και hardening. Ας τα δούμε σε βάθος.

Event ID 4769 — το κεντρικό detection signal

Κάθε φορά που εκδίδεται service ticket, ο Domain Controller καταγράφει ένα Event ID 4769 (A Kerberos service ticket was requested). Αυτό είναι το κύριο σημείο ανίχνευσης.

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

• Ticket Encryption Type: η τιμή 0x17 (RC4-HMAC) είναι ύποπτη σε ένα σύγχρονο περιβάλλον όπου η πλειονότητα των tickets πρέπει να είναι AES (0x11/0x12). Αίτημα RC4 από modern client είναι κλασικό σημάδι roasting / downgrade.
• Service Name: το SPN που ζητήθηκε — εντοπίζει ποιο service account στοχεύεται.
• Account Name / Client Address: ποιος χρήστης και από ποια IP ζητά το ticket.
• Ticket Options: βοηθά στο profiling του request.
• Failure Code 0x0: επιτυχής έκδοση.

Ισχυρές detection υποθέσεις (behavioral, όχι signature-based):

• Volume-based: ένας μεμονωμένος χρήστης που ζητά service tickets για πολλά διαφορετικά SPNs σε σύντομο χρονικό διάστημα (mass roasting). Ένα κανονικό workstation δεν συμπεριφέρεται έτσι.
• Encryption downgrade: 4769 με RC4 (0x17) για λογαριασμούς/περιβάλλον που κανονικά διαπραγματεύεται AES. Αυτό είναι ίσως το πιο αξιόπιστο single signal.
• Anomalous source: tickets για ευαίσθητα SPNs από hosts ή users που ιστορικά δεν τα ζητούν (baseline deviation).
• Honeypot / decoy service account: βλ. παρακάτω — το υψηλότερης πιστότητας signal.

Honeypot (decoy) service accounts

Μια από τις πιο αποτελεσματικές, χαμηλού θορύβου τεχνικές: δημιουργήστε έναν ελκυστικό αλλά ψεύτικο service account με SPN (π.χ. όνομα τύπου svc_backup_admin), χωρίς πραγματικές υπηρεσίες, με ισχυρότατο random password, και ρυθμίστε alerting ώστε οποιοδήποτε 4769 request για το SPN του να παράγει high-severity alert. Αφού κανένας νόμιμος χρήστης δεν έχει λόγο να ζητήσει ticket για αυτόν, κάθε αίτημα είναι σχεδόν βεβαιότητα κακόβουλης δραστηριότητας — δηλαδή σχεδόν μηδενικά false positives.

Encryption downgrade detection και επιβολή AES

Πέρα από την ανίχνευση, επιβάλετε AES στους service accounts. Στο attribute msDS-SupportedEncryptionTypes ρυθμίστε τους λογαριασμούς ώστε να υποστηρίζουν μόνο AES128/AES256 και όχι RC4. Αυτό:

• κάνει το cracking τάξεις μεγέθους πιο αργό ακόμη κι αν εξαχθεί ticket, και
• μετατρέπει κάθε RC4 request σε ξεκάθαρη ανωμαλία, ενισχύοντας την ανίχνευση downgrade.

Ελέγξτε επίσης domain-wide policies και το «Network security: Configure encryption types allowed for Kerberos» ώστε να απενεργοποιήσετε σταδιακά το RC4 όπου δεν απαιτείται από legacy συστήματα (με προσοχή σε compatibility testing πριν).

Group Managed Service Accounts (gMSA) — η στρατηγική λύση

Η ριζική άμυνα στο cracking είναι να μην υπάρχει human-set password να σπάσει. Τα Group Managed Service Accounts (gMSA) (και τα παλαιότερα standalone MSA) χρησιμοποιούν passwords που διαχειρίζεται αυτόματα το AD: 240 χαρακτήρες, τυχαία, με αυτόματη περιοδική εναλλαγή (τυπικά ανά 30 ημέρες), τα οποία κανείς άνθρωπος δεν γνωρίζει ούτε ορίζει. Ένα τέτοιο password είναι πρακτικά άθραυστο με brute-force/dictionary. Όπου τεχνικά υποστηρίζεται, η μετάβαση των service accounts σε gMSA εξουδετερώνει το Kerberoasting ως αποτελεσματική τεχνική. Επιπλέον, τα delegated Managed Service Accounts (dMSA) σε νεότερα Windows Server εκτείνουν αυτό το μοντέλο.

Ο παρακάτω έλεγχος (defensive, από τον DC) επιβεβαιώνει ποιοι λογαριασμοί είναι πλέον gMSA, ποιοι επιβάλλουν AES-only encryption types, και επιδεικνύει ένα honeypot SPN:

Ισχυρά, μακριά passwords για τα υπόλοιπα service accounts

Για λογαριασμούς που δεν μπορούν να γίνουν gMSA, επιβάλετε passwords ≥ 25–30 χαρακτήρων, τυχαία, με τακτική εναλλαγή. Το μήκος είναι το πιο καθοριστικό στοιχείο ενάντια στο offline cracking: ένα 30-χαρακτήρων τυχαίο password καθιστά ασύμφορη ακόμη και την RC4 επίθεση. Χρησιμοποιήστε fine-grained password policies (PSOs) για να στοχεύσετε ειδικά το OU των service accounts. Απαγορεύστε την επαναχρησιμοποίηση passwords και ελέγχετε το pwdLastSet για να εντοπίζετε λογαριασμούς με «απολιθωμένα» credentials.

Least privilege και tiering

Η αξία ενός σπασμένου service account εξαρτάται από τα δικαιώματά του. Εφαρμόστε αυστηρά least privilege:

• Καμία υπηρεσία δεν πρέπει να τρέχει με λογαριασμό-μέλος του Domain Admins ή άλλων προνομιακών groups «για ευκολία».
• Υιοθετήστε το tiered administration model (Tier 0 / Tier 1 / Tier 2) της Microsoft, ώστε ένα compromise σε χαμηλότερο tier να μην δίνει μονοπάτι προς Tier 0 (DCs, identity). Ένα kerberoasted account δεν πρέπει ποτέ να γεφυρώνει tiers.
• Αφαιρέστε περιττά SPNs και «σκουπίστε» ξεχασμένους/ανενεργούς service accounts (stale objects) — μειώνουν το attack surface.
• Ελέγξτε accounts με delegation (constrained/unconstrained), γιατί ο συνδυασμός kerberoastable + delegation είναι ιδιαίτερα επικίνδυνος.

Συνεχής επικύρωση με BloodHound και purple teaming

Χρησιμοποιήστε το BloodHound (αμυντικά) για να χαρτογραφήσετε ποιοι kerberoastable λογαριασμοί οδηγούν σε high-value targets, και δώστε προτεραιότητα στη διόρθωσή τους. Ενσωματώστε την προσομοίωση Kerberoasting σε τακτικά purple team exercises: εκτελέστε ελεγχόμενα το roasting σε lab/authorized πλαίσιο, επιβεβαιώστε ότι τα 4769-based detections πυροδοτούνται, μετρήστε τον χρόνο ανίχνευσης (MTTD), και βελτιώστε τα SIEM rules. Η ανίχνευση χωρίς επικύρωση είναι υπόθεση, όχι δυνατότητα.

Βασικά συμπεράσματα

• Το Kerberoasting εκμεταλλεύεται σχεδίαση, όχι bug: κάθε authenticated domain user μπορεί να ζητήσει service ticket για οποιοδήποτε SPN και να το σπάσει offline, χωρίς προνόμια.
• Το κρίσιμο τεχνικό σημείο είναι ότι μέρος του TGS ticket κρυπτογραφείται με κλειδί που προέρχεται από το password του service account — γι’ αυτό αδύναμα passwords = άμεσο compromise.
• Το RC4 (etype 23) είναι ο εχθρός: επιβάλετε AES· κάθε RC4 request γίνεται τότε ισχυρό detection signal (encryption downgrade).
• Event ID 4769 είναι το κέντρο της ανίχνευσης, αλλά μόνο με behavioral φιλτράρισμα (volume, encryption type, anomalous source) και ιδανικά honeypot service accounts για near-zero false positives.
• gMSA/dMSA είναι η στρατηγική λύση: auto-managed 240-χαρακτήρων passwords καθιστούν το cracking πρακτικά αδύνατο.
• Least privilege και tiering περιορίζουν το blast radius: ένα σπασμένο service account δεν πρέπει ποτέ να είναι Domain Admin ούτε να γεφυρώνει tiers.
• Μόνο εξουσιοδοτημένα: εκτελέστε αυτές τις τεχνικές αποκλειστικά σε isolated lab ή authorized penetration testing, με έμφαση στην επικύρωση των αμυνών σας μέσω purple teaming.
• MITRE ATT&CK T1558.003 — χαρτογραφήστε τα detections σας σε αυτό το ID για μετρήσιμη κάλυψη SOC.

Από τη θεωρία στην πράξη. Η Audax Cybersecurity προσφέρει επαγγελματικές υπηρεσίες offensive security — penetration testing & offensive validation — ενώ για όσους ξεκινούν το ταξίδι τους στο ethical hacking, το #1 ελληνικό βιβλίο «Ethical Hacking — Η Κρυφή Γνώση» είναι ο ιδανικός οδηγός.