Τεχνητή Νοημοσύνη: Κλοπή Συνεδρίας χωρίς Κακόβουλο

Το ηλεκτρονικό ψάρεμα που δημιουργείται από τεχνητή νοημοσύνη άλλαξε κανόνες του παιχνιδιού. Δεν χρειάζεται πλέον κακόβουλο λογισμικό για να κλέψει κάποιος τα διαπιστευτήριά σου — μόνο ένα πειστικό fake login page μέσα στο πρόγραμμα περιήγησης. Και το χειρότερο; Ακόμη και το MFA δεν σε σώζει αν ο επιτιθέμενος κλέψει τα κλειδιά της συνεδρίας σου. Ας δούμε τι αλλάζει και πώς μπορείς να προστατεύσεις τον εαυτό σου.

Ηλεκτρονικό ψάρεμα που δεν αφήνει ίχνη κακόβουλου κώδικα

Στο παλιό μοντέλο, μια email με ψάρεμα περιείχε ένα attachment ή έναν link που προς ένα αρχείο — κάτι που οι antivirus και email gateways μπορούσαν να εντοπίσουν. Σήμερα, το αρχείο δεν είναι ούτε καν απαραίτητο.

Εδώ τα βήματα μιας σύγχρονης επίθεσης ηλεκτρονικού ψαρέματος:

• Ένα πραγματικό domain (π.χ. mail-verify-yourcompany.com) — ο επιτιθέμενος κρατά ή κλέβει έναν τομέα που μοιάζει με την εταιρική domain σου
• Δυναμικές σελίδες phishing που δημιουργούνται από AI — κάθε χρήστης βλέπει διαφορετικό περιεχόμενο ανάλογα με τη συσκευή ή το πρόγραμμα περιήγησης του, κάνοντας τη σελίδα δυσκολότερη να εντοπιστεί από τα scanning tools
• Κανένα κακόβουλο αρχείο στη μέση — η σελίδα είναι καθαρά HTML/JavaScript, το οποίο δεν ενεργοποιεί alarm σε καμία antivirus
• Αλυσίδες ανακατεύθυνσης πολλαπλών σταδίων — ο χρήστης δεν βλέπει κατευθείαν το phishing site, αλλά περνά από νόμιμες διαφημιστικές δικτυακές σελίδες ή CDN πάροχοι πριν φτάσει τη fake login page
• Κλοπή session token αντί για κωδικού — ο επιτιθέμενος δεν θέλει τον κωδικό σου, θέλει το μικρό “cookie” που το πρόγραμμα περιήγησης σου στέλνει σε κάθε αίτημα προς τον εταιρικό σεράφι. Αν έχει αυτό, δεν χρειάζεται τον κωδικό — ούτε το MFA

Σύμφωνα με την έκθεση της FBI (IC3), το Business Email Compromise (BEC) που στηρίζεται στη διαδικασία αυτή προκάλεσε ζημίες 3,05 δισεκατομμυρίων δολαρίων σε ένα μόνο έτος. Και αυτό είναι μόνο το μέρος που αναφέρεται — η πλειονότητα των επιθέσεων δεν καταγράφονται.

Πώς κλέβουν τα session tokens και παρακάμπτουν το MFA

Όταν λες “έχω MFA, είμαι ασφαλής”, κάνεις το ίδιο λάθος με τον ιδιοκτήτη σπιτιού που κλειδώνει τη μπροστινή πόρτα αλλά αφήνει το παράθυρο ανοιχτό. Το MFA προστατεύει το κωδικό πρόσβασης σου, αλλά όχι το session token.

Ο επιτιθέμενος δεν πρέπει καν να ξέρει τον κωδικό σου. Σε μια επίθεση AiTM (Adversary-in-the-Middle), ο fake login page λειτουργεί σαν proxy:

1. Εισάγεις τον κωδικό σου στη fake σελίδα
2. Ο επιτιθέμενος το στέλνει στο νόμιμο σεράφι ταυτότητας (π.χ. Azure AD, Okta)
3. Σου ζητά το OTP/2FA code σου
4. Εισάγεις τον κωδικό 2FA
5. Ο επιτιθέμενος το περνάει στο νόμιμο σεράφι
6. Το σεράφι ταυτότητας σου εγκρίνει τη σύνδεση και επιστρέφει ένα session token
7. Ο επιτιθέμενος κρατά το session token και έχει πλήρη πρόσβαση χωρίς κωδικό ή MFA

Η έκθεση Ψηφιακής Άμυνας της Microsoft αναφέρει ότι το 80% των περιστατικών παράκαμψης MFA συνδέονται με κλεμμένα session tokens — ακόμη και αν ο χρήστης είχε 2FA ενεργοποιημένο.

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

Γιατί τα παραδοσιακά tools αποτυγχάνουν

Ένα παραδοσιακό σύστημα ασφαλείας δικτύου δεν μπορεί να δει τι συμβαίνει μέσα στο HTTPS traffic. Το “S” σημαίνει “Secure” — κρυπτογραφημένο. Όλη η κίνηση προς/από τον phishing site είναι κρυπτογραφημένη, οπότε:

• Email gateway — δεν μπορεί να δει το περιεχόμενο ενός HTTPS link (μόνο το domain), και το domain μοιάζει νόμιμο
• Network IDS/IPS — βλέπει κρυπτογραφημένα πακέτα, δεν μπορεί να ξέρει αν είναι phishing ή νόμιμος login
• File-based sandboxing — δεν υπάρχει αρχείο να σαρωθεί, άρα δεν υπάρχει ενεργοποίηση alarm
• EDR (Endpoint Detection & Response) — θα έβλεπε κανονικές διεργασίες προγράμματος περιήγησης, όχι πρόσεση που να αποδεικνύει ότι ο χρήστης έχει παραβιασθεί

Ενώ το 53% των παραβιάσεων δεδομένων (σύμφωνα με την Verizon) προέρχονται από κλοπή διαπιστευτηρίων με phishing, τα περισσότερα εργαλεία δεν μπορούν να δουν το phishing να συμβαίνει επειδή κρύβεται πίσω από την κρυπτογράφηση HTTPS.

Η λύση: ανάλυση σε επίπεδο προγράμματος περιήγησης

Αν τα εργαλεία δικτύου δεν μπορούν να δουν, ας κοιτάξουμε το πρόγραμμα περιήγησης απευθείας. Αυτή είναι η ιδέα πίσω από τις σύγχρονες πλατφόρμες browser-level analysis, όπως το ANY.RUN.

Αντί να αναλύουν ένα αρχείο σε ένα isolated sandbox, αυτές οι πλατφόρμες προσομοιώνουν τι θα συνέβαινε αν ο χρήστης επισκεπτόταν τη σελίδα phishing λόγω του πραγματικού προγράμματος περιήγησης (Chrome, Firefox, Safari). Καθώς ο κώδικας της σελίδας εκτελείται, παρακολουθούν:

• DOM mutations — αν ο κώδικας αλλάζει το περιεχόμενο της σελίδας (π.χ. αντικατάσταση των πολιτών πεδίων φόρμας, εμφάνιση fake CAPTCHA)
• Live redirect chains — η ακριβής σειρά των ανακατευθύνσεων που ακολουθεί ο browser
• SSL decryption — εξαγωγή του SSL session key απευθείας από τη μνήμη της διεργασίας του browser, ώστε να μπορεί να δει τι πληροφορίες στέλνει ο χρήστης μέσω HTTPS
• JavaScript execution chains — ποιος κώδικας εκτελείται και σε ποια σειρά

Αυτό επιτρέπει στους αναλυτές ασφαλείας να δουν την πλήρη αλυσίδα επίθεσης — όχι μόνο το fake login page, αλλά και πού στέλνονται τα διαπιστευτήρια, πώς επιστρέφεται το session token, και τι υποδομή έχει δημιουργήσει ο επιτιθέμενος πίσω από τη σκηνή.

Πώς η threat intelligence αυτοματοποίηση κάνει διαφορά

Ωραία, λοιπόν έχεις αναλύσει ένα phishing URL και ξέρεις τι συμβαίνει. Τι κάνεις μετά;

Ο ελάχιστος κίνδυνος είναι ότι ο επιτιθέμενος χρησιμοποιεί το ίδιο σενάριο (κομμάτι κώδικα) σε δεκάδες άλλες phishing sites. Αν μετατρέψεις τα δεδομένα που ανακάλυψες σε κανόνες ανίχνευσης (π.χ. YARA rules), μπορείς να πιάσεις όλες τις παραλλαγές του μετά από ένα URL.

Για παράδειγμα:

• Ένα συγκεκριμένο JavaScript variable που κλέβει το session token — μετατρέπεται σε κανόνα YARA που αναζητά το ίδιο variable σε νέα phishing sites
• Ένα hidden form field που δεν φαίνεται στο χρήστη αλλά καταγράφει τα OTP codes — γίνεται ένας δείκτης που ψάχνουν όλα τα SOC tools
• Ένα pattern σε κώδικα CAPTCHA που ξέρεις ότι είναι fake — αναζητείται σε όλα τα νέα δείγματα αυτόματα

Η δυσκολία είναι η ταχύτητα. Αν κάνεις αυτή τη δουλειά χειρονακτικά, ο επιτιθέμενος θα έχει ήδη εκτεθεί η υποδομή του από 10 άλλες χώρες χρήστες. Το trick είναι η αυτοματοποίηση:

• Ένας αναλυτής SOC βρίσκει ένα ύποπτο URL
• Το στέλνει στο sandbox (π.χ. ANY.RUN) που ξεδιπλώνει τη σελίδα
• Ένα αυτοματοποιημένο σύστημα εξάγει τα artifacts (JavaScript, variables, form fields κ.λπ.)
• Αυτά μετατρέπονται αυτόματα σε κανόνες YARA
• Οι κανόνες ενσωματώνονται σε όλα τα SOC tools (SIEM, SOAR, EDR, TIP)
• Όλα τα παρόμοια phishing sites ανιχνεύονται και μπλοκάρονται πριν από οποιονδήποτε άλλο χρήστη πέσει θύμα

Κατά τη δική μας εμπειρία στο TechNoid (μέσω εξεταζόμενων περιστατικών και δημοσιευμένων αναφορών), τα enterprise που ενσωματώνουν αυτοματοποιημένη threat intelligence στο πρώτο που μπλοκάρουν τις νέες καμπάνιες phishing δεν σε λεπτά ή ώρες, αλλά σε δευτερόλεπτα. Ο λόγος; Δεν περιμένουν έναν αναλυτή να καθίσει και να δει τι έγινε — τα εργαλεία κάνουν τη δουλειά μόνα τους.

Αυτό είναι καίριο γιατί ο επιτιθέμενος συχνά επαναχρησιμοποιεί το ίδιο υποδομή (hosting, domain registrar, email provider) σε πολλαπλές καμπάνιες. Ένα URL σου αποκαλύπτει δεκάδες άλλα. Ένας κανόνας που δημιουργείται από ένα artifact καταφέρνει εκατοντάδες παρόμοιες σελίδες.

Η άποψή μας στο TechNoid

Ας μην κάνουμε απ’ τα μάτια — τα παραδοσιακά εργαλεία ασφαλείας έχουν αποτύχει και δεν υπάρχει πίσω. Ένα phishing email χωρίς κακόβουλο λογισμικό δεν είναι κακόβουλο λογισμικό, οπότε το antivirus δεν θα το δει. Το HTTPS κρυπτογραφεί όλη τη κίνηση, οπότε το network monitoring δεν θα δει τι στέλνει ο χρήστης. Και μέχρι να το καταλάβει ο χρήστης, το session token του είναι ήδη κλεμμένο.

Αν ήσουν CIO μιας εταιρείας σήμερα, θα σου έλεγα ξεκάθαρα: κάνε ό,τι κάνεις για το MFA, κάνε το ίδιο και για το browser-level monitoring. Όχι εναλλακτικά — επιπρόσθετα.

Ειδικά για οργανισμούς με ευαίσθητα δεδομένα (ΠΣ, τράπεζες, ΠΑ), η αυτοματοποιημένη threat intelligence πρέπει να είναι υποχρεωτική. Ο λόγος δεν είναι ότι θα σταματήσει όλα τα phishing (δεν θα το κάνει) — είναι ότι θα σταματήσει τη μαζική εκμετάλλευση πριν η αλυσίδα επίθεσης επεκταθεί στο εσωτερικό δίκτυο.

Ένας επιτιθέμενος που πέσει σε phishing και έχασε το session token του μέσα σε δευτερόλεπτα δεν θα δοκιμάσει και πάλι με την ίδια υποδομή. Αλλά αν το session token παραμείνει ενεργό για μία ώρα πριν τον ανακαλύψεις, έχει ήδη κάνει ό,τι ήθελε.