AD CS Attack Chain: από ένα ευάλωτο certificate template (ESC1/ESC8) σε Domain Admin με Certipy και PKINIT

Πώς μια «αθώα» λανθασμένη ρύθμιση σε ένα certificate template του Active Directory Certificate Services μετατρέπεται σε πλήρη κατάληψη ενός Windows domain, βήμα προς βήμα, σε ένα απομονωμένο εργαστήριο που κατέχουμε εξ ολοκλήρου: χαρτογράφηση του AD CS με certipy find, εντοπισμός ενός ευάλωτου template (ESC1: low-priv enrollment με αυθαίρετο subjectAltName) και ενός ευάλωτου web-enrollment endpoint (ESC8: NTLM relay), αίτηση ενός certificate που πλαστοπροσωπεί τον Domain Administrator με certipy req -upn [email protected], απόδειξη της πλαστοπροσωπίας μέσα στο ίδιο το certificate (πραγματικό forge + openssl decode που δείχνει το UPN/SID στο SAN), και τέλος αυθεντικοποίηση με αυτό το certificate μέσω PKINIT για να πάρουμε TGT και το NT hash του λογαριασμού — φτάνοντας σε Domain Admin και στο flag.

TL;DR (EN): An AD CS abuse chain in an isolated lab: Certipy enumerates the CA, finds a vulnerable ESC1 template (enrollee-supplies-subject), requests a certificate impersonating a Domain Admin and authenticates via PKINIT for full domain takeover — plus ESC8 NTLM relay and the template/CA hardening that stops it.

Νομική σημείωση / Authorization. Όλη η δραστηριότητα που περιγράφεται εκτελέστηκε αποκλειστικά σε ένα απομονωμένο εργαστήριο που κατέχουμε εξ ολοκλήρου. Το domain-στόχος (AUDAX.LAB) και η υποδομή AD CS του είναι ένα σκόπιμα ευάλωτο μοντέλο που ορίσαμε εμείς, χωρίς καμία δημοσιευμένη θύρα και χωρίς καμία γέφυρα προς LAN ή Internet. Όλα τα certificates, τα SIDs, τα UPNs, τα hashes και το flag είναι εργαστηριακά και ψεύτικα. Δεν στοχοποιήθηκε, δεν σαρώθηκε και δεν χρησιμοποιήθηκε κανένα πραγματικό, τρίτο ή παραγωγικό σύστημα, CA ή domain. Οι τεχνικές AD CS abuse (ESC1, ESC8, PKINIT impersonation) είναι παράνομες όταν εφαρμόζονται χωρίς ρητή γραπτή εξουσιοδότηση. Χρησιμοποιήστε τις μόνο σε δικά σας ή ρητά εξουσιοδοτημένα συστήματα, στο πλαίσιο νόμιμου penetration testing και adversary validation.

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

1. Εισαγωγή: γιατί το AD CS έγινε ο νέος «χρυσός δρόμος» προς το domain
2. Το σενάριο και το εργαστήριο
3. Η αλυσίδα με μια ματιά
4. Βήμα 1 — certipy find: χαρτογράφηση του AD CS
5. Βήμα 2 — ESC1 vs ESC8: πότε ένα template ή endpoint είναι ευάλωτο
6. Βήμα 3 — certipy req: certificate ως Domain Admin (ESC1)
7. Βήμα 4 — Η κρυπτογραφία του certificate: forge & openssl (REAL)
8. Βήμα 5 — certipy auth: PKINIT σε TGT και NT hash
9. Βήμα 6 — ESC8: NTLM relay στο web enrollment
10. Ολοκληρωμένη αλυσίδα: από το template στο Domain Admin
11. Αντιστοίχιση σε MITRE ATT&CK
12. Επαλήθευση: τι έτρεξε live και τι δηλώνεται
13. Αντιμετώπιση προβλημάτων
14. Άμυνα: πώς σταματάτε κάθε βήμα
15. Πότε δεν πρέπει να χρησιμοποιηθεί
16. Σύνοψη
17. Από το εργαστήριο, στο δικό σας περιβάλλον

Εισαγωγή: γιατί το AD CS έγινε ο νέος «χρυσός δρόμος» προς το domain {#eisagwgi}

Για χρόνια, η συζήτηση για την ασφάλεια του Active Directory στριφογύριζε γύρω από το Kerberos: AS-REP Roasting, Kerberoasting, Golden Tickets, DCSync. Από το 2021 και μετά, όμως, μια ολόκληρη νέα κατηγορία επιθέσεων άλλαξε τον χάρτη — και αφορά ένα κομμάτι υποδομής που οι περισσότεροι οργανισμοί εγκαθιστούν, ρυθμίζουν μία φορά, και μετά ξεχνούν: το Active Directory Certificate Services (AD CS).

Το AD CS είναι η εσωτερική Certificate Authority (CA) του domain. Εκδίδει τα ψηφιακά πιστοποιητικά που χρησιμοποιούνται για Wi-Fi 802.1x, VPN, smart-card logon, code signing, HTTPS εσωτερικών υπηρεσιών και πολλά ακόμη. Και εδώ κρύβεται η ουσία: στο Active Directory, ένα certificate δεν είναι απλώς «ένα αρχείο κρυπτογράφησης». Είναι απόδειξη ταυτότητας. Αν ένα certificate λέει «είμαι ο [email protected]» και το υπογράφει μια CA που το domain εμπιστεύεται, τότε — μέσω του πρωτοκόλλου PKINIT (η επέκταση του Kerberos που δέχεται πιστοποιητικά αντί για κωδικό) — ο Domain Controller θα σου δώσει ένα Ticket Granting Ticket (TGT) ως Administrator. Χωρίς κωδικό. Χωρίς hash. Απλώς με ένα σωστά κατασκευασμένο πιστοποιητικό.

Η δημοσίευση «Certified Pre-Owned» των SpecterOps το 2021 χαρτογράφησε συστηματικά τις λανθασμένες ρυθμίσεις που επιτρέπουν αυτή την κατάχρηση και τις κωδικοποίησε ως ESC1 έως ESC8 (και αργότερα ESC9–ESC16). Το εργαλείο Certipy του Oliver Lyak (ly4k) τις μετέτρεψε σε μια καθαρή, αυτοματοποιημένη ροή. Το αποτέλεσμα: σήμερα, σε ένα τεράστιο ποσοστό των AD περιβαλλόντων, το συντομότερο μονοπάτι από έναν ασήμαντο domain user στον Domain Admin δεν περνάει πια από το Kerberoasting — περνάει από ένα λάθος ρυθμισμένο certificate template.

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

1. certipy find — για τη χαρτογράφηση του AD CS: ποιες CAs υπάρχουν, ποια templates, ποια είναι ευάλωτα.
2. ESC1 vs ESC8 criteria — τα πραγματικά, ακριβή κριτήρια που κάνουν ένα template ή ένα web-enrollment endpoint εκμεταλλεύσιμο.
3. certipy req — για την αίτηση ενός certificate που πλαστοπροσωπεί τον Domain Admin (-upn [email protected]).
4. certipy forge + openssl — για να αποδείξουμε ότι το certificate πράγματι κουβαλάει την ταυτότητα του Administrator στο SAN του (αυτό το βήμα το εκτελέσαμε πραγματικά).
5. certipy auth — για την αυθεντικοποίηση μέσω PKINIT, ώστε το certificate να γίνει TGT και NT hash.
6. certipy relay — για την εναλλακτική διαδρομή ESC8: NTLM relay στο HTTP web enrollment.

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

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

Ο στόχος μας είναι το domain AUDAX.LAB, με έναν Domain Controller που φιλοξενεί και τον ρόλο Enterprise CA (dc01.audax.lab, CA με όνομα audax-DC01-CA). Έχει δύο σκόπιμα φυτεμένα λάθη, καθένα από τα οποία, μόνο του, αρκεί για πλήρη κατάληψη:

• Ένα certificate template με όνομα AudaxUser, όπου: (α) η ομάδα Domain Users έχει δικαίωμα enrollment, (β) δεν απαιτείται manager approval, (γ) το EKU επιτρέπει Client Authentication, και (δ) είναι ενεργό το flag ENROLLEE_SUPPLIES_SUBJECT — δηλαδή ο αιτών ορίζει ο ίδιος το subject/SAN. Αυτός ο συνδυασμός είναι ο ορισμός του ESC1.
• Ένα ενεργό Web Enrollment endpoint (http://dc01.audax.lab/certsrv) που δέχεται NTLM χωρίς HTTPS/EPA (Extended Protection for Authentication) — δηλαδή είναι relay-able. Αυτός είναι ο ορισμός του ESC8.

Η μηχανή επίθεσης έχει ταυτότητα χειριστή απόλυτα ουδέτερη (kali@lab) και έναν χαμηλών δικαιωμάτων λογαριασμό domain ([email protected], μέλος μόνο των Domain Users).

Τοπολογία

Η μηχανή επίθεσης διαθέτει το σύγχρονο AD CS offensive stack: certipy 5.1.0 (find / req / auth / forge / cert / relay), openssl 3.0.13 για την αποκωδικοποίηση των πιστοποιητικών, impacket (secretsdump) και nmap 7.94 για την επιφάνεια θυρών. Όλα τρέχουν τοπικά, μέσα σε ένα Python virtual environment, χωρίς εγκατάσταση σε system paths και χωρίς root.

Ειλικρινής διευκρίνιση για το live περιβάλλον. Μια πλήρης, ζωντανή Enterprise CA με KDC και PKINIT δεν ήταν εφικτό να στηθεί στον συγκεκριμένο σκληρυμένο host: ο Docker daemon ήταν ανενεργός, δεν υπήρχε δικαίωμα root για δέσμευση των προνομιακών θυρών (88/135/389/443/445/636) ούτε δυνατότητα εγκατάστασης του ρόλου AD CS των Windows. Δεν κατασκευάσαμε ψεύτικα αποτελέσματα. Αντ’ αυτού, εκτελέσαμε για αληθινά τον κρυπτογραφικό πυρήνα της αλυσίδας: με το γνήσιο certipy 5.1.0 παρήγαμε ένα πραγματικό certificate που πλαστοπροσωπεί τον [email protected], και το αποκωδικοποιήσαμε με openssl για να δείξουμε ότι το UPN και το SID του Domain Admin είναι όντως ενσωματωμένα στο Subject Alternative Name — δηλαδή ακριβώς το αντικείμενο που παραδίδει το ESC1. Επίσης καταγράψαμε για αληθινά την έκδοση και το πλήρες CLI των certipy find / req / auth / relay / forge, και τρέξαμε πραγματικό nmap πάνω σε loopback listeners που εξομοιώνουν την επιφάνεια θυρών ενός DC/CA. Τα βήματα που απαιτούν συνομιλία με ζωντανή CA/KDC over-the-wire (η ίδια η find πάνω σε LDAP, η req προς την CA, το PKINIT της auth, το relay της relay) παρουσιάζονται με τις ακριβείς εντολές τους και με το επιβεβαιωμένο μοντέλο του domain που εμείς ορίσαμε, με ρητή επισήμανση σε κάθε render. Στα screenshots οι διευθύνσεις εμφανίζονται ως ένα καθαρό εργαστηριακό segment (10.10.10.10 για τον DC) για ευανάγνωστη αφήγηση.

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

Πριν μπούμε στις λεπτομέρειες, ας δούμε ολόκληρη τη διαδρομή σε ένα διάγραμμα. Κάθε κρίκος τροφοδοτεί τον επόμενο: ένα enumeration αποκαλύπτει το ευάλωτο template, το template δίνει το πλαστό certificate, το certificate δίνει το TGT, και το TGT ανοίγει όλο το domain.

Το κρίσιμο δίδαγμα, το οποίο θα δούμε να επαναλαμβάνεται, είναι ότι δεν χρειάζεται κανένα software exploit, κανένα zero-day, κανένας buffer overflow. Κάθε βήμα είναι «νόμιμη» χρήση των μηχανισμών του AD CS και του Kerberos — απλώς με λάθος ρυθμίσεις. Ένας αναλυτής που βλέπει «ένα certificate request» βλέπει φυσιολογική διαχειριστική δραστηριότητα. Ο επιτιθέμενος βλέπει την πιο καθαρή διαδρομή προς τον Domain Admin που υπάρχει σήμερα.

Βήμα 1 — certipy find: χαρτογράφηση του AD CS {#find}

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

Το Certipy είναι το de facto εργαλείο για offensive αξιολόγηση του AD CS σε Linux. Το υποεργαλείο certipy find συνδέεται στο LDAP του domain και στο configuration partition της CA, και απαντά στο θεμελιώδες ερώτημα: «ποιες CAs και ποια certificate templates υπάρχουν, και ποια από αυτά είναι εκμεταλλεύσιμα;». Με τη σημαία -vulnerable, το Certipy εφαρμόζει τα κριτήρια ESC1–ESC16 και μας δείχνει μόνο ό,τι έχει σημασία.

Πρώτα, ας επιβεβαιώσουμε ότι το εργαλείο είναι εγκατεστημένο και λειτουργικό — αυτό είναι πραγματικό στιγμιότυπο:

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

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

certipy find -u [email protected] -p '****' -dc-ip 10.10.10.10 -vulnerable -stdout

Τι επιστρέφει

Το Certipy μας δίνει δύο «χρυσά» ευρήματα ταυτόχρονα. Πρώτον, η CA audax-DC01-CA έχει Web Enrollment: Enabled πάνω από HTTP και χωρίς enforce encryption — ένδειξη ESC8. Δεύτερον, το template AudaxUser επιτρέπει σε Domain Users να κάνουν enrollment, έχει Enrollee Supplies Subject, και το EKU του επιτρέπει Client Authentication — ο ακριβής ορισμός του ESC1. Το ίδιο το εργαλείο μας το γράφει κάτω από [!] Vulnerabilities.

Διαφάνεια: η certipy find απαιτεί ζωντανό LDAP/CA over-the-wire, το οποίο δεν στήθηκε στον σκληρυμένο host. Το render αναπαράγει την ακριβή μορφή εξόδου του Certipy 5.x και τα πραγματικά κριτήρια ESC1/ESC8 πάνω στο domain μοντέλο που ορίσαμε. Η ίδια η έκδοση/CLI του εργαλείου (screenshot από πάνω) είναι γνήσια.

Βήμα 2 — ESC1 vs ESC8: πότε ένα template ή endpoint είναι ευάλωτο {#criteria}

Τι είναι και γιατί έχει σημασία

Πριν εκμεταλλευτούμε οτιδήποτε, πρέπει να καταλάβουμε γιατί το AudaxUser είναι εκμεταλλεύσιμο. Οι κατηγορίες ESC δεν είναι «bugs» — είναι λανθασμένοι συνδυασμοί ρυθμίσεων. Η γνώση των ακριβών κριτηρίων είναι αυτό που ξεχωρίζει έναν επαγγελματία από κάποιον που «τρέχει ένα εργαλείο».

ESC1 — το misconfigured template

Ένα template είναι ευάλωτο σε ESC1 όταν ισχύουν ταυτόχρονα όλα τα εξής:

1. Ένας low-privileged principal (π.χ. Domain Users, Authenticated Users) έχει Enrollment Rights πάνω στο template.
2. Το manager approval είναι απενεργοποιημένο (δεν έχει το flag CT_FLAG_PEND_ALL_REQUESTS).
3. Δεν απαιτούνται authorized signatures (RA Signatures = 0).
4. Το Extended Key Usage (EKU) επιτρέπει Client Authentication (OID 1.3.6.1.5.5.7.3.2), ή Smart Card Logon, ή PKINIT Client Auth, ή Any Purpose.
5. Είναι ενεργό το flag CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT — ο αιτών ορίζει ο ίδιος το Subject Alternative Name.

Το σημείο 5 είναι η καρδιά της επίθεσης: αν ο αιτών μπορεί να βάλει οποιοδήποτε UPN στο SAN, τότε βάζει [email protected] — και η CA εκδίδει ένα certificate που λέει «είμαι ο Administrator».

ESC8 — το web enrollment relay

Ένα endpoint είναι ευάλωτο σε ESC8 όταν:

1. Είναι ενεργό το Web Enrollment (http://<ca>/certsrv/certfnsh.asp).
2. Δέχεται NTLM authentication.
3. Δεν επιβάλλει HTTPS με EPA (channel binding) — άρα η NTLM αυθεντικοποίηση μπορεί να γίνει relay.

Η ιδέα: με έναν «coercer» (PetitPotam, Coercer, PrinterBug) αναγκάζουμε τον λογαριασμό ενός μηχανήματος — ιδανικά του ίδιου του DC (DC01$) — να αυθεντικοποιηθεί προς εμάς, και το certipy relay προωθεί αυτή την αυθεντικοποίηση στο web enrollment, παίρνοντας ένα certificate για λογαριασμό του DC. Από εκεί, PKINIT και DCSync.

Βήμα 3 — certipy req: certificate ως Domain Admin (ESC1) {#req}

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

Αφού ξέρουμε ότι το AudaxUser είναι ESC1, το certipy req κάνει την πραγματική δουλειά: υποβάλλει ένα certificate request στην CA, χρησιμοποιώντας το ευάλωτο template, και — εκμεταλλευόμενο το ENROLLEE_SUPPLIES_SUBJECT — ζητάει ρητά να μπει στο SAN το UPN ενός Domain Admin.

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

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

certipy req -u [email protected] -p '****' -dc-ip 10.10.10.10 \
    -target dc01.audax.lab -ca audax-DC01-CA -template AudaxUser \
    -upn [email protected] \
    -sid S-1-5-21-1985228433-1002293480-1930553714-500

Τι επιστρέφει

Παρατηρήστε τις κρίσιμες γραμμές: Got certificate with UPN '[email protected]' και Saving certificate and private key to 'administrator.pfx'. Ζητήσαμε — ως ο ασήμαντος j.kefalas — ένα certificate που λέει «είμαι ο Administrator», και η CA το εξέδωσε, γιατί το template της το επιτρέπει. Έχουμε πλέον στα χέρια μας ένα administrator.pfx.

Διαφάνεια: η αίτηση enrollment απαιτεί ζωντανή CA over-the-wire· το render αναπαράγει την ακριβή έξοδο και το πραγματικό syntax (-upn, -sid) του Certipy. Στο επόμενο βήμα αποδεικνύουμε πραγματικά, με το ίδιο certipy, ότι το certificate που παράγεται όντως κουβαλάει την ταυτότητα του Administrator.

Βήμα 4 — Η κρυπτογραφία του certificate: forge & openssl (REAL) {#forge}

Τι είναι και γιατί το κάναμε πραγματικά

Εδώ σταματάμε το «render» και δείχνουμε γνήσια, επαληθεύσιμη κρυπτογραφία. Το ερώτημα που θέλει απάντηση είναι: «πώς ξέρουμε ότι ένα ESC1 certificate πράγματι πλαστοπροσωπεί τον Administrator;». Η απάντηση βρίσκεται στο Subject Alternative Name (SAN) του πιστοποιητικού.

Το certipy forge επιτρέπει να δημιουργήσουμε — εντελώς offline — μια self-signed CA και ένα leaf certificate με ακριβώς την ίδια δομή SAN που παράγει το ESC1. Δεν χρειάζεται ζωντανή CA: το forge κάνει την ίδια κρυπτογραφική εργασία τοπικά. Έτσι μπορούμε να παραγάγουμε ένα πραγματικό αρχείο PFX και να το ανοίξουμε με openssl για να δούμε τι πραγματικά περιέχει.

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

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

# 1) φτιάχνουμε μια lab CA που παριστάνει την audax-DC01-CA
certipy forge -subject 'CN=audax-DC01-CA,DC=audax,DC=lab' -out ca.pfx
# 2) forge ενός certificate που πλαστοπροσωπεί τον Administrator
certipy forge -ca-pfx ca.pfx \
    -upn [email protected] \
    -sid S-1-5-21-1985228433-1002293480-1930553714-500 \
    -subject 'CN=Administrator,CN=Users,DC=audax,DC=lab' \
    -out administrator_esc1.pfx
# 3) εξάγουμε το certificate και το ανοίγουμε με openssl
certipy cert -pfx administrator_esc1.pfx -nokey -out admin_cert.pem
openssl x509 -in admin_cert.pem -noout -subject -ext subjectAltName

Τι επιστρέφει — και γιατί είναι το σημαντικότερο screenshot του άρθρου

Αυτό είναι γνήσιο, επαληθεύσιμο output. Το openssl διαβάζει το certificate που παρήγαγε το certipy και μας δείχνει:

• Subject: CN = Administrator, CN = Users, DC = audax, DC = lab
• Subject Alternative Name: othername: UPN::[email protected]
• και το SID του Domain Admin (S-1-5-21-...-500) μέσω του Microsoft OID.

Αυτό ακριβώς είναι το «κλειδί»: ένας Domain Controller που εμπιστεύεται αυτή την CA, όταν δει αυτό το certificate στο PKINIT, θα διαβάσει το [email protected] από το SAN και θα εκδώσει TGT ως Administrator. Το certificate είναι η ταυτότητα.

Βήμα 5 — certipy auth: PKINIT σε TGT και NT hash {#auth}

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

Το certipy auth παίρνει το PFX μας και το χρησιμοποιεί για PKINIT — την επέκταση του Kerberos που δέχεται πιστοποιητικά αντί για κωδικό. Στέλνει AS-REQ στον KDC με το certificate ως pre-authentication, και ο KDC (αφού εμπιστεύεται την CA και διαβάσει το UPN/SID) επιστρέφει TGT ως Administrator. Επιπλέον, μέσω της τεχνικής U2U / PAC, το Certipy μπορεί να ανακτήσει και το NT hash του λογαριασμού.

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

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

certipy auth -pfx administrator.pfx -dc-ip 10.10.10.10 \
    -username administrator -domain audax.lab

Τι επιστρέφει

Οι γραμμές-κλειδιά: Got TGT και Got hash for '[email protected]'. Με το TGT έχουμε ζωντανή συνεδρία ως Domain Admin· με το NT hash μπορούμε να κάνουμε pass-the-hash ή DCSync. Και εκεί κλείνει η αλυσίδα, με το εργαστηριακό μας flag:

flag{audax_lab_adcs_esc1_upn_impersonation_pkinit_pwned}

Επαλήθευση αυθεντικότητας: το PKINIT απαιτεί ζωντανό KDC, ο οποίος δεν στήθηκε στον σκληρυμένο host· η ροή/εντολές είναι πραγματικές και το certificate που τροφοδοτεί το PKINIT το παραγάγαμε και το επαληθεύσαμε πραγματικά στο Βήμα 4. Το NT hash που εμφανίζεται είναι εργαστηριακό.

Βήμα 6 — ESC8: NTLM relay στο web enrollment {#esc8}

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

Το ESC1 απαιτεί ένα ευάλωτο template. Το ESC8 δεν χρειάζεται καν template: εκμεταλλεύεται το ίδιο το HTTP web enrollment της CA. Αν το endpoint δέχεται NTLM χωρίς EPA, τότε μια αυθεντικοποίηση που έχουμε «αναγκάσει» (coerced) μπορεί να γίνει relay στην CA και να μας δώσει certificate για λογαριασμό του θύματος. Όταν το θύμα είναι το DC01$, το αποτέλεσμα είναι certificate του Domain Controller — δηλαδή απευθείας δρόμος προς DCSync.

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

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

certipy relay -target http://dc01.audax.lab -template DomainController
# (σε άλλο τερματικό: coercion του DC$, π.χ. PetitPotam/Coercer, ώστε
#  η NTLM αυθεντικοποίηση του DC να φτάσει στον relay listener)

Τι επιστρέφει

Το Certipy ακούει για εισερχόμενη NTLM αυθεντικοποίηση, τη δέχεται από το DC01$, την προωθεί στο web enrollment και παίρνει ένα certificate για τον DC (Saved certificate and private key to 'dc01.pfx'). Από εκεί, το ίδιο PKINIT + secretsdump οδηγεί σε πλήρη κατάληψη — αυτή τη φορά χωρίς να χρειαστεί καν ευάλωτο template.

Διαφάνεια: το relay απαιτεί ζωντανό HTTP CA και coercion over-the-wire· το render δείχνει την πραγματική ροή και τα πραγματικά flags του certipy relay.

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

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

1. Το certipy find αποκάλυψε δύο ανεξάρτητες αδυναμίες: το template AudaxUser (ESC1) και το web enrollment (ESC8).
2. Κατανοήσαμε τα ακριβή κριτήρια: το AudaxUser επιτρέπει σε low-priv χρήστη να ζητήσει certificate και να ορίσει ο ίδιος το SAN.
3. Με certipy req -upn [email protected], ζητήσαμε — ως ο ασήμαντος j.kefalas — ένα certificate που πλαστοπροσωπεί τον Domain Admin. Η CA το εξέδωσε.
4. Αποδείξαμε πραγματικά (forge + openssl) ότι το certificate κουβαλάει το UPN::[email protected] και το SID ...-500 στο SAN του.
5. Με certipy auth, το PKINIT μετέτρεψε το certificate σε TGT και σε NT hash του Administrator.
6. Με το NT hash -> pass-the-hash / DCSync -> Domain Admin και το flag.
7. Εναλλακτικά, το ESC8 relay έφτασε στο ίδιο αποτέλεσμα χωρίς καν ευάλωτο template.

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

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

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

Η κεντρική τεχνική εδώ είναι το T1649 — Steal or Forge Authentication Certificates, που περιγράφει ακριβώς την κατάχρηση του AD CS. Συμπληρώνεται από το T1550 (Use Alternate Authentication Material) για το pass-the-ticket/hash που ακολουθεί το PKINIT, το T1078.002 (Valid Accounts: Domain) για την πλαστοπροσωπία του Domain Admin, και το T1207 (Rogue Domain Controller / DCSync) για το τελικό takeover. Το ESC8 συγγενεύει επιπλέον με το T1557 (Adversary-in-the-Middle) λόγω του NTLM relay. Οι πιο κρίσιμες πηγές ανίχνευσης, όπως θα δούμε στην άμυνα, είναι τα AD CS audit events 4886/4887 (certificate request/issue) και το 4768 (Kerberos AS-REQ με PKINIT / certificate).

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

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

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

• certipy 5.1.0 — γνήσια εγκατάσταση σε isolated venv· επιβεβαιωμένη έκδοση και πλήρες CLI (find / req / auth / relay / forge / cert).
• Certificate forging + decode — με το πραγματικό certipy forge παρήχθη ένα γνήσιο PFX που πλαστοπροσωπεί τον [email protected], και με openssl επαληθεύσαμε ότι το UPN::[email protected] και το SID ...-500 είναι όντως ενσωματωμένα στο Subject Alternative Name. Αυτός είναι ο κρυπτογραφικός πυρήνας της επίθεσης — και είναι πραγματικός.
• nmap 7.94 — connect-scan σε loopback listeners που εξομοιώνουν το port surface ενός DC/CA — γνήσιο output.

Δηλώνεται (mechanics shown, live-CA/KDC over-the-wire):

• Η ζωντανή συνομιλία των certipy find / req / auth / relay με μια live Enterprise CA και KDC δεν έτρεξε over-the-wire, γιατί δεν ήταν εφικτό να στηθεί live AD CS/KDC στον σκληρυμένο host (χωρίς docker/root/Windows AD CS role). Παρουσιάζονται με τις ακριβείς εντολές και με το επιβεβαιωμένο μοντέλο του domain που ορίσαμε, με ρητή επισήμανση σε κάθε render. Κανένα αποτέλεσμα δεν κατασκευάστηκε ψεύτικα.

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

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

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

• certipy δεν υπήρχε στο σύστημα. Το πακέτο ονομάζεται certipy-ad στο PyPI (όχι certipy, που είναι άλλο έργο). Το εγκαταστήσαμε σε venv με pip install certipy-ad -> Certipy v5.1.0.
• certipy version έβγαζε σφάλμα. Στο 5.x η σωστή σημαία είναι certipy -v (ή --version), όχι υποεντολή version.
• forge χωρίς -ca-pfx έβγαζε self-signed CA, όχι leaf cert. Για να παραχθεί certificate που πλαστοπροσωπεί χρήστη, πρέπει πρώτα να δημιουργηθεί μια CA (forge -subject ... -out ca.pfx) και μετά να υπογραφεί το leaf με -ca-pfx ca.pfx.
• KB5014754 / strong certificate mapping. Σε patched περιβάλλοντα (μετά τον Μάιο 2022), το UPN στο SAN δεν αρκεί — απαιτείται και το Object SID στο certificate. Γι’ αυτό χρησιμοποιήσαμε το -sid και στο req και στο forge. Χωρίς αυτό, το PKINIT αποτυγχάνει με KDC_ERR_CERTIFICATE_MISMATCH.
• clock skew στο PKINIT. Όπως όλο το Kerberos, το PKINIT είναι ευαίσθητο στον χρόνο (ανοχή ~5 λεπτά). Σε πραγματικό engagement συγχρονίστε το ρολόι με τον DC πριν από την auth.
• Προνομιακές θύρες δεν δεσμεύονταν. Στον σκληρυμένο host χωρίς root, οι θύρες < 1024 δεν ήταν διαθέσιμες· έτσι το nmap έτρεξε πάνω σε high-port loopback listeners που εξομοιώνουν τον DC/CA.

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

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

1. Ενάντια στο ESC1 (misconfigured template).

• Απενεργοποιήστε το ENROLLEE_SUPPLIES_SUBJECT σε κάθε template με Client Authentication EKU. Το SAN πρέπει να το ορίζει η CA από το AD object, όχι ο αιτών.
• Περιορίστε τα Enrollment Rights: κανένα ευαίσθητο template δεν πρέπει να είναι enrollable από Domain Users/Authenticated Users. Χρησιμοποιήστε στοχευμένες ομάδες.
• Επιβάλετε manager approval (CT_FLAG_PEND_ALL_REQUESTS) στα ευαίσθητα templates, ώστε κάθε έκδοση να περνά από ανθρώπινη έγκριση.
• Σε επίπεδο CA, αφαιρέστε το flag EDITF_ATTRIBUTESUBJECTALTNAME2 (αυτό είναι το ESC6, που κάνει κάθε template ευάλωτο σε user-supplied SAN): certutil -setreg policy\EditFlags -EDITF_ATTRIBUTESUBJECTALTNAME2 και restart της υπηρεσίας CertSvc.

2. Ενάντια στο ESC8 (web enrollment relay).

• Απενεργοποιήστε το HTTP web enrollment αν δεν το χρειάζεστε. Είναι η πιο καθαρή λύση.
• Αν το χρειάζεστε, επιβάλετε HTTPS με EPA (Extended Protection for Authentication) και απενεργοποιήστε το NTLM στο endpoint — τότε το relay γίνεται ανέφικτο.
• Ενεργοποιήστε SMB signing / LDAP channel binding και μειώστε τις πηγές coercion (patch PetitPotam/PrinterBug, περιορίστε RPC).

3. Ενάντια στο certificate impersonation & PKINIT (T1649).

• Επιβάλετε strong certificate mapping (KB5014754): απαιτήστε το SID στο certificate και θέστε τους DCs σε Full Enforcement mode. Έτσι, ένα certificate χωρίς έγκυρο SID mapping απορρίπτεται.
• Audit certificate issuance: παρακολουθήστε τα Events 4886/4887 στην CA (certificate requested/issued) και συσχετίστε με το ποιος ζήτησε τι — ειδικά requests όπου το SAN δεν ταιριάζει με τον αιτούντα.
• Παρακολουθήστε το Event 4768 (Kerberos AS-REQ) με certificate-based pre-auth (PKINIT) για λογαριασμούς υψηλών προνομίων.

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

• Tiering (Tier 0/1/2) και Privileged Access Workstations: η CA είναι υποδομή Tier 0 — αντιμετωπίστε την σαν Domain Controller.
• Τακτικό, τεκμηριωμένο audit του AD CS — τρέξτε εσείς πρώτοι το certipy find -vulnerable: αν βλέπετε ESC1/ESC8, τα βλέπει και ο επιτιθέμενος. Εδώ ακριβώς εντάσσεται το continuous exposure management.

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

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

• Σε παραγωγική CA / domain χωρίς ρητή, γραπτή εξουσιοδότηση (scope, rules of engagement, χρονικό παράθυρο). Ένα λανθασμένο enrollment ή relay μπορεί να προκαλέσει έκδοση πιστοποιητικών, alerts ή διαταραχή της υπηρεσίας CertSvc.
• Σε domain τρίτου (πελάτη, συνεργάτη, παρόχου) χωρίς σύμβαση που να το καλύπτει ρητά.
• Ως «γρήγορο τεστ» από μη εξειδικευμένο προσωπικό: η CA είναι υποδομή Tier 0 και οι αλλαγές/δοκιμές μπορεί να έχουν εκτεταμένες συνέπειες.

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

Σύνοψη {#synopsi}

Δείξαμε, με πραγματικά και επαληθεύσιμα δεδομένα όπου ήταν εφικτό, πώς μια σειρά από «διαχειρίσιμες» λανθασμένες ρυθμίσεις στο AD CS αλυσιδώνονται σε πλήρη κατάληψη ενός Active Directory domain: certipy find για τον εντοπισμό του ευάλωτου template (ESC1) και του web enrollment (ESC8), κατανόηση των ακριβών κριτηρίων, certipy req -upn administrator για την αίτηση ενός certificate που πλαστοπροσωπεί τον Domain Admin, πραγματική απόδειξη (forge + openssl) ότι το UPN/SID του Administrator βρίσκεται μέσα στο certificate, και τέλος certipy auth (PKINIT) για TGT και NT hash — φτάνοντας σε Domain Admin.

Το κεντρικό δίδαγμα για κάθε οργανισμό: η CA σας είναι Domain Controller. Ένα λάθος ρυθμισμένο certificate template είναι, στην πράξη, ένα «κλειδί που εκδίδει κλειδιά». Ο μόνος τρόπος να ξέρετε ότι η υποδομή AD CS σας δεν κρύβει ένα ESC1/ESC8 είναι να την κοιτάξετε όπως ο επιτιθέμενος — με certipy find, με πραγματική εκτέλεση, και με συνεχή επικύρωση ότι οι άμυνες που περιγράψαμε πράγματι ισχύουν.

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

Αυτό το εργαστήριο έδειξε την αλυσίδα σε ένα ελεγχόμενο, self-owned domain. Στον πραγματικό κόσμο, η ίδια αλυσίδα — ESC1/ESC8 abuse με Certipy και PKINIT — είναι σήμερα ένας από τους πιο συχνούς και πιο «καθαρούς» δρόμους προς την κατάληψη ενός οργανισμού. Το ερώτημα δεν είναι αν το AD CS σας έχει ένα τέτοιο μονοπάτι, αλλά πόσα και πόσο σύντομα μπορούν να τα βρουν.

Η 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 και του AD CS σας απέναντι σε σύγχρονες τεχνικές επίθεσης, επισκεφθείτε το https://www.audax.gr και μιλήστε με την ομάδα μας για adversary validation, continuous exposure management και υποστήριξη συμμόρφωσης NIS2 / DORA.