Η ενεργοποίηση του Multi-Factor Authentication (MFA) αποτελεί ένα από τα σημαντικότερα μέτρα προστασίας ενός εταιρικού λογαριασμού. Υπάρχει όμως μια κρίσιμη λεπτομέρεια: ο επιτιθέμενος δεν χρειάζεται πάντα να σπάσει το MFA για να αποκτήσει πρόσβαση σε μια ήδη πιστοποιημένη συνεδρία.
Σε επιθέσεις Session Hijacking, Token Theft και Adversary-in-the-Middle (AiTM) phishing, ο στόχος μπορεί να είναι το authentication token ή η authenticated session που δημιουργείται αφού ο χρήστης έχει ήδη ολοκληρώσει επιτυχώς τη διαδικασία σύνδεσης.
Αν ένας επιτιθέμενος αποκτήσει ένα έγκυρο session token και μπορεί να το επαναχρησιμοποιήσει, ενδέχεται να αποκτήσει πρόσβαση στην υπηρεσία ως ήδη authenticated χρήστης. Σε ένα τέτοιο σενάριο, το MFA μπορεί να έχει λειτουργήσει κανονικά κατά το αρχικό sign-in· η επίθεση στοχεύει τη συνεδρία που δημιουργήθηκε μετά την επιτυχή αυθεντικοποίηση.
Για αυτό η προστασία των εταιρικών identities δεν πρέπει να σταματά στο password και στο MFA. Χρειάζεται να καλύπτει και τις συσκευές, τις συνθήκες πρόσβασης, τα session tokens, την παρακολούθηση ύποπτων sign-ins και την απόκριση όταν υπάρχει ένδειξη παραβίασης.
Τι είναι το Session Hijacking;
Με τον όρο Session Hijacking περιγράφουμε την κατάχρηση μιας ήδη authenticated συνεδρίας χρήστη. Αντί ο επιτιθέμενος να πραγματοποιήσει κανονικά login με τα credentials του θύματος, προσπαθεί να αποκτήσει ή να επαναχρησιμοποιήσει στοιχεία που αντιπροσωπεύουν την υπάρχουσα συνεδρία.
Αυτό είναι σημαντικό επειδή, μετά την επιτυχημένη αυθεντικοποίηση, πολλές σύγχρονες εφαρμογές χρησιμοποιούν tokens ώστε ο χρήστης να μη χρειάζεται να εισάγει συνεχώς password και MFA.
Τα tokens είναι απαραίτητο μέρος της σύγχρονης authentication αρχιτεκτονικής. Γίνονται όμως στόχος όταν ένας attacker προσπαθεί να τα κλέψει και να τα χρησιμοποιήσει εκτός του νόμιμου περιβάλλοντος του χρήστη.
Τι είναι το Token Theft;
Το Token Theft είναι η απόκτηση authentication ή session tokens από μη εξουσιοδοτημένο μέρος. Η ακριβής μορφή του token και ο τρόπος κατάχρησής του εξαρτώνται από την εφαρμογή, την identity πλατφόρμα και τον τύπο της συνεδρίας.
Η βασική ιδέα όμως είναι η ίδια: ένα έγκυρο token μπορεί να αποτελεί απόδειξη ότι η διαδικασία authentication έχει ήδη ολοκληρωθεί. Αν μπορεί να επαναχρησιμοποιηθεί από τον attacker, η νέα πρόσβαση δεν απαιτεί απαραίτητα να επαναληφθεί το αρχικό MFA challenge.
Για αυτό η φράση «παράκαμψη του MFA» χρειάζεται σωστή ερμηνεία. Σε πολλές τέτοιες επιθέσεις το MFA δεν έχει παραβιαστεί κρυπτογραφικά ούτε έχει απενεργοποιηθεί. Ο νόμιμος χρήστης μπορεί να έχει ολοκληρώσει ο ίδιος το MFA και ο attacker να στοχεύει το αποτέλεσμα αυτής της επιτυχημένης σύνδεσης.
Πώς λειτουργεί το Adversary-in-the-Middle phishing;
Σε ένα Adversary-in-the-Middle (AiTM) phishing scenario, ο επιτιθέμενος παρεμβάλλεται στη διαδικασία σύνδεσης μεταξύ του χρήστη και της πραγματικής υπηρεσίας.
Ο χρήστης μπορεί να οδηγηθεί σε παραπλανητική σελίδα μέσω phishing email ή άλλου μηνύματος. Η υποδομή του attacker λειτουργεί ως ενδιάμεσος στη διαδικασία authentication και προσπαθεί να αποκτήσει τα στοιχεία που χρειάζονται για την κατάχρηση της authenticated session.
Έτσι μπορεί να υπάρξει περίπτωση στην οποία ο χρήστης εισάγει τα πραγματικά credentials του και ολοκληρώνει το απαιτούμενο MFA, αλλά η επίθεση εξακολουθεί να καταλήγει σε compromise της συνεδρίας.
Αυτός είναι ένας από τους λόγους που η προστασία από phishing επιθέσεις στην επιχείρηση παραμένει κρίσιμη ακόμη και όταν έχει ήδη ενεργοποιηθεί MFA.
Γιατί το συνηθισμένο MFA δεν λύνει μόνο του το πρόβλημα;
Το MFA παραμένει βασικό security control και δεν πρέπει να απενεργοποιείται επειδή υπάρχουν τεχνικές token theft. Μειώνει σημαντικά τον κίνδυνο που δημιουργείται όταν ένας attacker γνωρίζει μόνο το password.
Δεν είναι όμως όλες οι μέθοδοι MFA εξίσου ανθεκτικές στο phishing. Μέθοδοι στις οποίες ο χρήστης μπορεί να παρασυρθεί ώστε να ολοκληρώσει authentication στο πλαίσιο μιας παραπλανητικής ροής δεν προσφέρουν την ίδια προστασία με μεθόδους που είναι σχεδιασμένες να είναι phishing-resistant.
Phishing-resistant authentication
Η Microsoft συνιστά phishing-resistant authentication για ισχυρότερη προστασία των identities. Στο Microsoft Entra ID, οι διαθέσιμες phishing-resistant επιλογές περιλαμβάνουν μεταξύ άλλων Windows Hello for Business, passkeys βασισμένα στο FIDO2, FIDO2 security keys και Certificate-Based Authentication (CBA).
Τα passkeys και οι άλλες κατάλληλες FIDO2 μέθοδοι βασίζονται σε public-key cryptography και συνδέουν την authentication διαδικασία με τον πραγματικό προορισμό της σύνδεσης. Αυτό τις καθιστά πολύ πιο ανθεκτικές σε κλασικά remote phishing scenarios από μεθόδους που βασίζονται σε κωδικούς μιας χρήσης ή σε authentication flows που μπορούν να προωθηθούν μέσω παραπλανητικής υποδομής.
Η κατάλληλη μέθοδος εξαρτάται από τις συσκευές, τις εφαρμογές, το identity architecture και τις λειτουργικές απαιτήσεις της επιχείρησης.
Token Protection: Προστασία απέναντι στο Token Replay
Η προστασία του αρχικού authentication δεν αρκεί αν ένα session token μπορεί στη συνέχεια να κλαπεί και να επαναχρησιμοποιηθεί από διαφορετικό περιβάλλον.
Στο Microsoft Entra, το Token Protection είναι Conditional Access session control που έχει σχεδιαστεί για να μειώνει τον κίνδυνο token replay μέσω device-bound sign-in session tokens. Ο στόχος είναι ένα προστατευμένο token να μην μπορεί απλώς να μεταφερθεί σε άλλη συσκευή και να επαναχρησιμοποιηθεί εκεί.
Το Token Protection δεν πρέπει να αντιμετωπίζεται ως καθολική προστασία για κάθε token, εφαρμογή, browser ή πλατφόρμα. Η υποστήριξή του εξαρτάται από το συγκεκριμένο σενάριο.
Σύμφωνα με την τρέχουσα τεκμηρίωση της Microsoft, για native applications το Token Protection είναι Generally Available σε Windows, iOS/iPadOS και macOS και μπορεί να εφαρμοστεί σε υποστηριζόμενους πόρους όπως Exchange Online, SharePoint Online και Microsoft Teams. Στα Windows υποστηρίζονται επίσης Azure Virtual Desktop και Windows 365.
Η υποστήριξη browser-based εφαρμογών είναι πιο περιορισμένη: βρίσκεται σε Preview για υποστηριζόμενα web apps και συγκεκριμένες διαμορφώσεις που προσπελαύνουν Azure Resource Manager σε Windows και macOS. Επομένως δεν πρέπει να θεωρείται ότι το Token Protection προστατεύει γενικά κάθε Microsoft 365 browser session.
Η χρήση του Token Protection μέσω Conditional Access απαιτεί κατάλληλο licensing. Η Microsoft αναφέρει Microsoft Entra ID P1 ως απαίτηση για το συγκεκριμένο control. Πριν από deployment πρέπει επίσης να ελεγχθούν οι τρέχουσες απαιτήσεις πλατφόρμας, εφαρμογών και συσκευών.
Microsoft Entra ID και Conditional Access
Για επιχειρήσεις που χρησιμοποιούν Microsoft 365, το Microsoft Entra Conditional Access μπορεί να επιβάλει κανόνες πρόσβασης με βάση περισσότερες συνθήκες από την απλή γνώση του σωστού password.
Ανάλογα με την πολιτική και τις διαθέσιμες άδειες, μπορούν να αξιολογούνται στοιχεία όπως:
- ο χρήστης ή η ομάδα χρηστών,
- ο πόρος στον οποίο ζητείται πρόσβαση,
- η συσκευή και η κατάστασή της,
- η απαιτούμενη authentication strength,
- η τοποθεσία ή άλλες συνθήκες πρόσβασης,
- και, όταν υπάρχει το κατάλληλο licensing, risk signals.
Το Conditional Access απαιτεί κατάλληλη άδεια Microsoft Entra ID P1 ή άλλο Microsoft licensing που περιλαμβάνει τη δυνατότητα. Οι risk-based Conditional Access policies που χρησιμοποιούν user risk ή sign-in risk βασίζονται στο Microsoft Entra ID Protection και απαιτούν Microsoft Entra ID P2 ή αντίστοιχο licensing που περιλαμβάνει αυτές τις δυνατότητες.
Δείτε επίσης τον οδηγό της DataShield για το Microsoft Entra ID και την ασφαλή διαχείριση ταυτοτήτων στο cloud.
Πώς μπορεί μια επιχείρηση να μειώσει τον κίνδυνο Token Theft;
1. Χρησιμοποιήστε phishing-resistant authentication όπου είναι εφικτό
Ξεκινήστε από λογαριασμούς υψηλού αντίκτυπου, όπως administrators και άλλους χρήστες με πρόσβαση σε κρίσιμα συστήματα ή ευαίσθητα δεδομένα. Αξιολογήστε passkeys/FIDO2, Windows Hello for Business, security keys ή άλλη κατάλληλη phishing-resistant μέθοδο με βάση το περιβάλλον σας.
2. Μην αντιμετωπίζετε το MFA ως μοναδικό control
Το MFA πρέπει να αποτελεί μέρος πολυεπίπεδης identity στρατηγικής. Conditional Access, σωστός περιορισμός administrative privileges, ασφαλείς συσκευές και παρακολούθηση των sign-ins μειώνουν την εξάρτηση από ένα μόνο control.
3. Χρησιμοποιήστε managed και προστατευμένες συσκευές
Ένα endpoint που έχει παραβιαστεί μπορεί να δημιουργήσει κινδύνους ακόμη και όταν το authentication είναι ισχυρό. Η διαχείριση συσκευών, τα security updates, η endpoint protection και οι κατάλληλες access policies αποτελούν μέρος της προστασίας της authenticated session.
4. Εφαρμόστε Token Protection όπου υποστηρίζεται και έχει νόημα
Σε κατάλληλα Microsoft Entra environments, το Token Protection μπορεί να προσθέσει προστασία απέναντι σε token replay. Πριν εφαρμοστεί, πρέπει να επιβεβαιωθούν το licensing, οι υποστηριζόμενες πλατφόρμες, οι εφαρμογές και οι πιθανές επιπτώσεις στους χρήστες.
5. Παρακολουθείτε sign-ins και ύποπτες συνεδρίες
Η ασφάλεια δεν τελειώνει τη στιγμή του login. Ασυνήθιστη δραστηριότητα, αλλαγές στη συμπεριφορά ενός λογαριασμού, ύποπτα sign-ins και άλλες ενδείξεις compromise πρέπει να διερευνώνται με βάση τα διαθέσιμα logs και security signals.
6. Περιορίστε τα προνόμια
Η αρχή του Least Privilege περιορίζει τη ζημιά που μπορεί να προκαλέσει ένας παραβιασμένος λογαριασμός. Οι καθημερινοί χρήστες δεν πρέπει να διαθέτουν administrative permissions χωρίς επιχειρησιακή ανάγκη, ενώ οι privileged λογαριασμοί χρειάζονται αυστηρότερα controls.
7. Διατηρήστε ισχυρή προστασία από phishing
Το AiTM εξακολουθεί να χρειάζεται έναν τρόπο να εμπλέξει τον χρήστη στην κακόβουλη authentication ροή. Email security, awareness, διαδικασίες αναφοράς ύποπτων μηνυμάτων και phishing-resistant authentication λειτουργούν συμπληρωματικά.
Τι πρέπει να γίνει αν υπάρχει υποψία κλοπής session;
Αν υπάρχουν ενδείξεις ότι ένας εταιρικός λογαριασμός ή μια authenticated session έχει παραβιαστεί, η αντιμετώπιση δεν πρέπει να περιοριστεί στην αλλαγή του password.
Ανάλογα με το περιστατικό και την πλατφόρμα, η διερεύνηση μπορεί να απαιτεί:
- ανάκληση ενεργών sessions ή refresh tokens όπου αυτό υποστηρίζεται και ενδείκνυται,
- έλεγχο sign-in και audit logs,
- έλεγχο και αποκατάσταση της συσκευής του χρήστη,
- έλεγχο authentication methods και αλλαγών στον λογαριασμό,
- έλεγχο mailbox rules και forwarding,
- έλεγχο εφαρμογών, consent και permissions,
- έλεγχο administrative ενεργειών και πρόσβασης σε εταιρικά δεδομένα,
- και ενεργοποίηση της κατάλληλης διαδικασίας Incident Response.
Η απλή αλλαγή password δεν αποτελεί από μόνη της πλήρη αντιμετώπιση όταν υπάρχει ένδειξη ότι έχει παραβιαστεί η authenticated session ή η συσκευή του χρήστη.
Το σύγχρονο μοντέλο Identity Security
Η λογική «ισχυρό password + MFA = ασφαλής λογαριασμός» είναι πλέον ανεπαρκής ως πλήρης στρατηγική.
Η σύγχρονη προστασία εταιρικών identities χρειάζεται συνδυασμό:
- ισχυρού και κατά προτίμηση phishing-resistant authentication,
- Conditional Access όπου υπάρχει κατάλληλο περιβάλλον και licensing,
- προστασίας των sessions και tokens όπου υποστηρίζεται,
- managed και ασφαλών endpoints,
- Least Privilege,
- παρακολούθησης identity και sign-in activity,
- προστασίας από phishing,
- και οργανωμένου Incident Response.
Συμπέρασμα
Το Session Hijacking και το Token Theft δείχνουν γιατί η ασφάλεια ενός εταιρικού λογαριασμού δεν τελειώνει όταν ολοκληρωθεί επιτυχώς το MFA.
Το MFA παραμένει απαραίτητο, αλλά σε ορισμένα attack scenarios ο επιτιθέμενος προσπαθεί να εκμεταλλευτεί την ήδη authenticated session αντί να επαναλάβει τη διαδικασία login.
Για αυτό οι επιχειρήσεις χρειάζονται πολυεπίπεδη identity άμυνα: phishing-resistant authentication όπου είναι εφικτό, σωστά σχεδιασμένο Conditional Access, προστατευμένες συσκευές, περιορισμένα privileges, monitoring και κατάλληλη προστασία των tokens στα σενάρια όπου υποστηρίζεται.
Η κρίσιμη ερώτηση δεν είναι μόνο «μπορεί κάποιος να αποκτήσει το password μου;», αλλά και «τι συμβαίνει αν κάποιος αποκτήσει πρόσβαση στην ήδη πιστοποιημένη συνεδρία μου;»
Πώς μπορεί να βοηθήσει η DataShield
Η DataShield μπορεί να αξιολογήσει τον τρόπο με τον οποίο προστατεύονται οι εταιρικοί λογαριασμοί Microsoft 365, εξετάζοντας MFA, Conditional Access, administrative privileges, συσκευές και τις σχετικές πολιτικές Microsoft Entra.
Ένα Free IT Audit μπορεί να αποτελέσει το πρώτο βήμα για τον εντοπισμό αδύναμων σημείων στην identity και access ασφάλεια της επιχείρησης και για την ιεράρχηση των κατάλληλων μέτρων προστασίας.
