Κάποτε, σε έναν όχι και τόσο μακρινό ψηφιακό κόσμο, πιστεύαμε αφελώς πως το λουκέτο δίπλα στη γραμμή διευθύνσεων του προγράμματος περιήγησης ήταν ο απόλυτος εγγυητής της ασφάλειας μας. Κοιτάζω πίσω σε εκείνες τις εποχές με μια δόση νοσταλγίας και ειρωνείας.
Σήμερα, καθώς διανύουμε το 2025, η πραγματικότητα της κυβερνοασφάλειας έχει μεταλλαχθεί σε κάτι πολύ πιο πολύπλοκο και, τολμώ να πω, πιο σκοτεινά γοητευτικό.
Η έννοια του Man-in-the-Middle (MitM) που διδαχθήκαμε στα αμφιθέατρα έχει ωριμάσει, έχει φορέσει κοστούμι και έχει μετονομαστεί σε Adversary-in-the-Middle (AitM).
Δεν πρόκειται για μια απλή αλλαγή ορολογίας χάριν εντυπωσιασμού, αλλά για μια θεμελιώδη μετατόπιση στην αρχιτεκτονική της επίθεσης που καθιστά τον παραδοσιακό έλεγχο ταυτότητας πολλαπλών παραγόντων (MFA) σχεδόν διακοσμητικό.
Η άνοδος των επιθέσεων AitM δεν είναι κεραυνός εν αιθρία. Είναι η φυσική απάντηση των επιτιθέμενων στην ευρεία υιοθέτηση του MFA. Καθώς οι οργανισμοί θωράκισαν τις πόρτες τους με OTPs (One-Time Passwords) και Push Notifications, οι “adversaries” σταμάτησαν να προσπαθούν να παραβιάσουν την κλειδαριά και απλώς άρχισαν να κλέβουν το κλειδί αφού ανοίξει η πόρτα.
Στο άρθρο αυτό, θα ξεναγηθούμε στα άδυτα αυτής της τεχνικής, θα αναλύσουμε τον κώδικα και τη λογική πίσω από τα εργαλεία που χρησιμοποιούνται σήμερα και θα δούμε γιατί η άμυνα απαιτεί πλέον μια ριζική αναθεώρηση της φιλοσοφίας μας περί εμπιστοσύνης.
Αρχιτεκτονική της Αντίστροφης Πληρεξουσιότητας (Reverse Proxy Architecture)
Η καρδιά μιας επίθεσης AitM χτυπάει στο ρυθμό ενός Reverse Proxy. Σε αντίθεση με τις παλαιότερες μορφές phishing, όπου ο επιτιθέμενος έστηνε μια στατική σελίδα-κλώνο για να καταγράψει τα διαπιστευτήρια και μετά τα δοκίμαζε χειροκίνητα, το AitM λειτουργεί σε πραγματικό χρόνο. Ο επιτιθέμενος τοποθετεί έναν διακομιστή ανάμεσα στο θύμα και τη νόμιμη υπηρεσία (π.χ. Microsoft 365, Google Workspace, Okta).
Η τεχνική ιδιοφυΐα εδώ έγκειται στη διαφάνεια. Ο διακομιστής του επιτιθέμενου δεν “μιμείται” απλώς την ιστοσελίδα στόχο· την αναμεταδίδει.
Όταν το θύμα πληκτρολογεί τη διεύθυνση στον browser του (που φυσικά είναι ένα typo-squatted domain ή ένα subdomain που ελέγχει ο δράστης), το αίτημα φτάνει στον proxy του επιτιθέμενου. Ο proxy, με τη σειρά του, στέλνει το αίτημα στον πραγματικό διακομιστή της υπηρεσίας.
Ό,τι βλέπει το θύμα στην οθόνη του προέρχεται απευθείας από τη νόμιμη πηγή, απλώς περνάει μέσα από το φίλτρο του επιτιθέμενου. Αυτό σημαίνει ότι δυναμικό περιεχόμενο, λογότυπα που αλλάζουν, ακόμα και CAPTCHAs, εμφανίζονται και λειτουργούν κανονικά.
Ο χρήστης λύνει το CAPTCHA για λογαριασμό του επιτιθέμενου, χωρίς να το γνωρίζει. Είναι μια διαδικασία που θυμίζει τηλεσκοπική παρακολούθηση, όπου ο ενδιάμεσος βλέπει και καταγράφει τα πάντα, ενώ οι δύο άκρες πιστεύουν πως συνομιλούν απευθείας.
Η κλοπή της συνεδρίας: Το Άγιο Δισκοπότηρο
Το κρίσιμο σημείο που διαφοροποιεί το AitM από το απλό phishing είναι ο στόχος. Ο κωδικός πρόσβασης είναι πλέον δευτερεύουσας σημασίας. Ο πραγματικός στόχος είναι το session cookie ή το token ελέγχου ταυτότητας.
Μόλις ο χρήστης ολοκληρώσει επιτυχώς τη διαδικασία εισόδου, συμπεριλαμβανομένης της χρήσης MFA, ο πάροχος ταυτότητας (IdP) εκδίδει ένα session cookie. Αυτό το cookie είναι η ψηφιακή απόδειξη ότι “ο χρήστης αυτός έχει ελεγχθεί και είναι έμπιστος”.
Ο proxy του επιτιθέμενου, ευρισκόμενος στη μέση, παρακολουθεί την κίνηση HTTP για συγκεκριμένα μοτίβα headers. Όταν ο πραγματικός server στείλει την απάντηση HTTP/2 200 OK που περιέχει τον header Set-Cookie με το session token (όπως το ESTSAUTH ή ESTSAUTHKP στο περιβάλλον της Microsoft), ο proxy το αρπάζει.
Από εκείνη τη στιγμή και μετά, ο επιτιθέμενος δεν χρειάζεται ούτε τον κωδικό του χρήστη ούτε το κινητό του για το MFA. Μπορεί απλώς να εισάγει αυτό το cookie στον δικό του browser και να αποκτήσει πρόσβαση στο λογαριασμό σαν να ήταν ο νόμιμος χρήστης. Η επίθεση παρακάμπτει το MFA διότι το MFA έχει ήδη ολοκληρωθεί επιτυχώς από το ίδιο το θύμα.
Τεχνική ανάλυση εργαλείων: Evilginx και άλλα
Δεν μπορούμε να μιλήσουμε για AitM χωρίς να αναφέρουμε το εργαλείο που εκδημοκράτισε αυτή την επίθεση: το Evilginx2 (και πλέον οι ιδιωτικές παραλλαγές που βασίζονται στο Evilginx3).
Η λογική του βασίζεται στα “phishlets”, τα οποία είναι αρχεία διαμόρφωσης (συνήθως σε μορφή YAML) που ορίζουν πώς ο proxy πρέπει να χειρίζεται την κίνηση για συγκεκριμένους στόχους. Ένα phishlet ορίζει ποια domains πρέπει να αναμεταδοθούν και, το σημαντικότερο, ποιους cookies πρέπει να “συλλάβει” και να εξάγει.
Ένα τυπικό απόσπασμα λογικής ενός phishlet θα μπορούσε να περιγραφεί ως εξής σε ψευδοκώδικα διαμόρφωσης: ανιχνεύουμε την κίνηση για το domain login.microsoftonline.com. Ορίζουμε κανόνες αντικατάστασης (sub_filters) ώστε κάθε αναφορά στο νόμιμο domain μέσα στο HTML ή τα JavaScript αρχεία να αντικαθίσταται δυναμικά με το κακόβουλο domain του επιτιθέμενου, εξασφαλίζοντας ότι ο χρήστης δεν θα ανακατευθυνθεί εκτός της παγίδας.
Στη συνέχεια, ορίζουμε τα triggers: μόλις εντοπιστεί ο header Set-Cookie με όνομα ESTSAUTH, το σύστημα αποθηκεύει την τιμή του σε μια τοπική βάση δεδομένων και ειδοποιεί τον επιτιθέμενο μέσω Telegram ή Discord webhook.
Η πολυπλοκότητα έγκειται στη σωστή διαχείριση των JavaScript redirects και των CORS policies, τα οποία τα σύγχρονα εργαλεία χειρίζονται αυτόματα, καθιστώντας την επίθεση τρομακτικά απλή στην εκτέλεση.
Το ζήτημα του TLS και η διαχείριση πιστοποιητικών
Ένα εύλογο ερώτημα που προκύπτει σε όσους έχουν βαθιά γνώση δικτύων είναι: “Μα καλά, τι γίνεται με το TLS/SSL;”. Η απάντηση είναι ότι ο επιτιθέμενος τερματίζει τη σύνδεση TLS.
Στην πραγματικότητα, υπάρχουν δύο ξεχωριστά τούνελ κρυπτογράφησης. Το πρώτο είναι μεταξύ του θύματος και του proxy του επιτιθέμενου, και το δεύτερο μεταξύ του proxy και της νόμιμης υπηρεσίας.
Για να πείσει το browser του θύματος ότι η σύνδεση είναι ασφαλής, ο επιτιθέμενος χρησιμοποιεί αυτοματοποιημένες υπηρεσίες όπως το Let’s Encrypt για να εκδώσει, σε πραγματικό χρόνο, έγκυρα πιστοποιητικά SSL για τα κακόβουλα domains του.
Επειδή το domain του ανήκει (το αγόρασε νόμιμα), η έκδοση του πιστοποιητικού είναι απολύτως έγκυρη βάσει των προτύπων PKI. Ο browser βλέπει ένα έγκυρο πιστοποιητικό, το λουκέτο εμφανίζεται, και ο χρήστης νιώθει ασφαλής.
Το Certificate Transparency (CT) logging θα μπορούσε θεωρητικά να βοηθήσει στον εντοπισμό αυτών των νέων πιστοποιητικών, αλλά ο όγκος των νέων domains που δημιουργούνται καθημερινά είναι τόσο μεγάλος που ο εντοπισμός σε πραγματικό χρόνο είναι σαν να ψάχνεις βελόνα στα άχυρα πριν η βελόνα σε τσιμπήσει.
Παράκαμψη μηχανισμών ανίχνευσης και Browser Fingerprinting
Η μάχη μεταξύ αμυνόμενων και επιτιθέμενων στο πεδίο του AitM είναι μια αέναη σκακιστική παρτίδα. Οι πάροχοι ασφαλείας προσπαθούν να ανιχνεύσουν πότε ένας χρήστης συνδέεται μέσω ενός proxy.
Μια τεχνική που χρησιμοποιούν οι επιτιθέμενοι για να αποφύγουν αυτή την ανίχνευση είναι το εξελιγμένο browser fingerprinting. Τα εργαλεία AitM δεν συμπεριφέρονται ως παθητικοί αναμεταδότες· τροποποιούν ενεργά τα πακέτα.
Όταν ο IdP (Identity Provider) εκτελεί ελέγχους μέσω JavaScript για να συλλέξει δεδομένα τηλεμετρίας από τον browser (ανάλυση οθόνης, εγκατεστημένες γραμματοσειρές, έκδοση GPU), ο proxy πρέπει να διασφαλίσει ότι αυτά τα δεδομένα φτάνουν στον IdP αναλλοίωτα ή τροποποιημένα ώστε να φαίνονται φυσιολογικά.
Αν ο proxy “κόψει” αυτά τα scripts, ο IdP μπορεί να αντιληφθεί την επίθεση και να μπλοκάρει τη σύνδεση. Συνεπώς, οι σύγχρονες πλατφόρμες AitM λειτουργούν ως έξυπνα φίλτρα που επιτρέπουν την εκτέλεση πολύπλοκων client-side scripts, διατηρώντας την ψευδαίσθηση της απευθείας σύνδεσης.
Επιπλέον, χρησιμοποιούν οικιακές IP διευθύνσεις (Residential Proxies) για την επικοινωνία με τον IdP, αποφεύγοντας έτσι τις μαύρες λίστες που περιέχουν τις IP των γνωστών data centers (όπως AWS, DigitalOcean) όπου συνήθως φιλοξενούνται οι υποδομές επίθεσης.
Η Κοινωνική Μηχανική ως καταλύτης
Όσο τέλεια και αν είναι η τεχνολογία, ο ανθρώπινος παράγοντας παραμένει η κερκόπορτα. Η διανομή των AitM links γίνεται συνήθως μέσω στοχευμένων emails (Spear Phishing) ή μέσω μηνυμάτων σε πλατφόρμες όπως το Teams και το Slack.
Το σενάριο είναι συχνά επείγον: “Ενημέρωση ασφαλείας λογαριασμού”, “Κοινόχρηστο έγγραφο από το HR”, ή “Επείγουσα ενέργεια τιμολόγησης”.
Αυτό που παρατηρούμε φέτος είναι η χρήση AI (LLMs) για τη δημιουργία μηνυμάτων που είναι γλωσσικά άψογα και προσαρμοσμένα στο ύφος της εταιρείας-στόχου.
Δεν βλέπουμε πλέον τα κακογραμμένα emails του παρελθόντος. Το μήνυμα μοιάζει να έχει γραφτεί από συνάδελφο. Μόλις ο χρήστης κάνει το κλικ, η τεχνική υποδομή αναλαμβάνει.
Η επιτυχία του AitM βασίζεται στο ότι δεν ζητάει από τον χρήστη να κάνει κάτι ασυνήθιστο. Του ζητάει να κάνει login, κάτι που κάνει δεκάδες φορές την ημέρα. Η ρουτίνα είναι ο σύμμαχος του επιτιθέμενου.
Persistence: Τι συμβαίνει μετά την είσοδο;
Η κλοπή του token είναι μόνο η αρχή. Μόλις ο επιτιθέμενος αποκτήσει πρόσβαση, ο στόχος είναι η εδραίωση (persistence). Επειδή τα session tokens έχουν ημερομηνία λήξης ή μπορεί να ακυρωθούν αν ο χρήστης αλλάξει κωδικό, ο επιτιθέμενος πρέπει να κινηθεί γρήγορα.
Η συνηθέστερη τακτική είναι η εγγραφή μιας νέας συσκευής MFA (αν το επιτρέπουν οι πολιτικές) ή η δημιουργία κανόνων inbox για απόκρυψη ειδοποιήσεων ασφαλείας.
Σε πιο εξελιγμένα σενάρια, βλέπουμε την κατάχρηση του OAuth. Ο επιτιθέμενος, χρησιμοποιώντας το κλεμμένο session, εγκρίνει μια κακόβουλη εφαρμογή OAuth με υψηλά δικαιώματα (π.χ. πρόσβαση σε όλα τα emails και τα αρχεία).
Από τη στιγμή που δοθεί αυτή η έγκριση, το session token δεν χρειάζεται πλέον. Η εφαρμογή έχει μόνιμη πρόσβαση στα δεδομένα μέσω API keys, ανεξάρτητα από το αν ο χρήστης αλλάξει τον κωδικό του ή ενεργοποιήσει νέο MFA. Αυτή είναι η πραγματική εφιαλτική διάσταση του σύγχρονου cloud compromise.
Η μόνη πραγματική άμυνα: FIDO2 και WebAuthn
Εδώ φτάνουμε στο σημείο καμπής. Πώς αμυνόμαστε; Η σκληρή αλήθεια είναι ότι τα παραδοσιακά μέτρα (εκπαίδευση χρηστών, έλεγχος URL) είναι ανεπαρκή. Ο άνθρωπος δεν μπορεί να διακρίνει αξιόπιστα ένα homoglyph domain σε μια στιγμή πίεσης. Η λύση πρέπει να είναι τεχνική και κρυπτογραφική. Η απάντηση ακούει στο όνομα FIDO2 / WebAuthn.
Το πρωτόκολλο FIDO2 εισάγει την έννοια του “Origin Binding” (Δέσμευση Προέλευσης). Κατά τη διαδικασία ελέγχου ταυτότητας, ο browser συνομιλεί με το hardware key (YubiKey) ή το Passkey (στο κινητό ή στον υπολογιστή).
Μέσα στα δεδομένα που υπογράφονται κρυπτογραφικά περιλαμβάνεται και το domain στο οποίο βρίσκεται ο χρήστης. Εάν ο χρήστης βρίσκεται στο fakenews.com (το site του επιτιθέμενου), το Passkey θα υπογράψει αυτό το domain.
Όταν ο proxy στείλει αυτή την υπογραφή στον πραγματικό IdP (π.χ. microsoft.com), ο έλεγχος θα αποτύχει διότι ο IdP περιμένει υπογραφή για το microsoft.com και όχι για το fakenews.com.
Αυτή η άμυνα είναι μαθηματικά απαραβίαστη με τα σημερινά δεδομένα στο πλαίσιο του AitM, καθώς εξαλείφει την εξάρτηση από την ανθρώπινη αντίληψη του URL.
Conditional Access και Device Compliance
Πέρα από το FIDO2, μια άλλη ισχυρή γραμμή άμυνας είναι η χρήση πολιτικών Conditional Access που βασίζονται στην κατάσταση της συσκευής (Device Compliance). Στο οικοσύστημα της Microsoft (Entra ID) ή της Google, μπορούμε να ορίσουμε πολιτική που λέει: “Η πρόσβαση επιτρέπεται μόνο από συσκευές που είναι ‘Managed’ ή ‘Compliant'”.
Σε μια επίθεση AitM, ο επιτιθέμενος προσπαθεί να χρησιμοποιήσει το κλεμμένο session token από τη δική του συσκευή (ή από τον cloud server του).
Εάν η πολιτική απαιτεί η συσκευή να έχει συγκεκριμένο πιστοποιητικό μηχανής (που διαθέτουν μόνο οι εταιρικοί υπολογιστές), το κλεμμένο token είναι άχρηστο στα χέρια του επιτιθέμενου.
Ακόμα και αν έχει κάνει bypass το MFA, θα “χτυπήσει” στον έλεγχο της συσκευής. Φυσικά, υπάρχουν τεχνικές για token replay που προσπαθούν να παρακάμψουν και αυτό, αλλά ο πήχης δυσκολίας ανεβαίνει εκθετικά.
Η χρήση τεχνητής νοημοσύνης από τους επιτιθέμενους
Κλείνοντας αυτή την τεχνική περιήγηση, είναι σαφές ότι βρισκόμαστε σε μια κούρσα εξοπλισμών. Οι επιτιθέμενοι ήδη πειραματίζονται με αυτοματοποιημένα συστήματα που χρησιμοποιούν AI για να αλληλεπιδρούν με τον χρήστη σε πραγματικό χρόνο μέσω chat στο ψεύτικο site, αυξάνοντας την αξιοπιστία της επίθεσης.
Από την άλλη πλευρά, τα συστήματα άμυνας ενσωματώνουν μηχανική μάθηση για να αναλύουν τη συμπεριφορά των sessions και να εντοπίζουν ανωμαλίες (π.χ. ένα session που δημιουργήθηκε στην Ελλάδα και ξαφνικά χρησιμοποιείται από μια IP στην Ολλανδία μέσα σε δευτερόλεπτα – Impossible Travel).
Ωστόσο, η θεμελιώδης αρχή παραμένει: Η ταυτότητα είναι η νέα περίμετρος. Και σε αυτή την περίμετρο, το “εμπιστεύσου αλλά επαλήθευσε” έχει πεθάνει. Το νέο δόγμα είναι “μην εμπιστεύεσαι ποτέ, επαλήθευσε τα πάντα, και δέσε την επαλήθευση με κρυπτογραφικά δεσμά στο hardware”.
Συνοπτικός πίνακας ανάλυσης απειλής και άμυνας
Ακολουθεί μια σύγκριση υψηλού επιπέδου που αποκρυσταλλώνει τη διαφορά μεταξύ της παραδοσιακής προσέγγισης και της πραγματικότητας του AitM, καθώς και την αποτελεσματικότητα των αντίμετρων.
| Παράμετρος Σύγκρισης | Κλασικό Phishing | Adversary-in-the-Middle (AitM) | FIDO2/Passkey Άμυνα |
| Πρωταρχικός Στόχος | Κωδικοί Πρόσβασης (Credentials) | Session Cookies / Tokens | Αποτροπή Phishing |
| Μηχανισμός Επίθεσης | Στατική σελίδα-κλώνος | Reverse Proxy σε πραγματικό χρόνο | Κρυπτογραφική υπογραφή προέλευσης |
| Επιτυχία έναντι Legacy MFA | Χαμηλή (Μπλοκάρεται από OTP) | Πολύ Υψηλή (Υποκλέπτει το αποτέλεσμα του MFA) | N/A (Το MFA είναι μέρος της λύσης) |
| Τεχνική Απαίτηση | Χαμηλή (HTML/PHP scripts) | Μεσαία/Υψηλή (Reverse Proxy, TLS management) | Υψηλή (Απαιτεί υποδομή PKI/WebAuthn) |
| Αντοχή στο Χρόνο (Session) | Απεριόριστη (μέχρι αλλαγή κωδικού) | Περιορισμένη (μέχρι λήξη token ή revocation) | Μέγιστη (Δεν υπάρχει shared secret για κλοπή) |
| Κρισιμότερο Αντίμετρο | Εκπαίδευση Χρηστών / SMS OTP | FIDO2 / Hardware Keys / Device Compliance | N/A |
