AI agents: από marimo RCE σε κλοπή εσωτερικής βάσης

Μια πρόσφατη επίθεση δείχνει με τρόπο απότομο και πρακτικό πώς οι επιτιθέμενοι μεταβαίνουν από στατικά playbooks σε ευφυή, αυτορυθμιζόμενα agents που προσαρμόζουν την αλληλουχία ενεργειών σε πραγματικό χρόνο. Τον Μάιο του 2026, εκμεταλλεύτηκαν ευπάθεια σε notebook περιβάλλον, άντλησαν διαπιστευτήρια σύννεφου και, μέσω ενός LLM agent, κορύφωσαν την επίθεση με την ταχεία εξαγωγή μιας εσωτερικής βάσης δεδομένων.

Το συμβάν είναι ενδιαφέρον όχι μόνο για την τεχνική του λεπτομέρεια, αλλά και για τις ευρύτερες επιπτώσεις στον τρόπο που πρέπει να σκεφτόμαστε την ανίχνευση και την αποκατάσταση μετά από συμβάν. Η ταχύτητα, η αυτονομία και οι τεχνικές απόκρυψης που χρησιμοποιήθηκαν υποδεικνύουν ένα νέο επίπεδο κινδύνου για υποδομές cloud και περιβάλλοντα notebook.

Πώς ξεκίνησε η επίθεση και τι συνέβη στο παίξιμο

Στις 10 Μαΐου 2026, οι δράστες εκμεταλλεύτηκαν την απομακρυσμένη εκτέλεση κώδικα CVE-2026-39987 σε ένα ευάλωτο περιβάλλον notebook marimo. Η αρχική επαφή έγινε μέσω WebSocket σύνδεσης στον τερματικό του notebook, που έδωσε στους εισβολείς το πρώτο interactive shell.

Από εκεί, η επίθεση προχώρησε στην άμεση συγκομιδή διαπιστευτηρίων: αρχεία περιβάλλοντος, τοπικά αρχεία με ρυθμίσεις ~/.aws/credentials, και συστήματα όπως /proc/*/environ και /etc/environment. Αντί να τρέξει ένα στατικό script, ο εισβολέας «έτρεξε» έναν LLM agent ο οποίος ανέλυσε τα αποτελέσματα των εντολών και επέλεξε την επόμενη ενέργεια.

Λίγο αργότερα χρησιμοποιήθηκαν τα κλεμμένα κλειδιά για κλήσεις προς τις AWS APIs, μεταξύ των οποίων ένα sts:GetCallerIdentity και στη συνέχεια secretsmanager:GetSecretValue για ανάκτηση ιδιωτικού SSH κλειδιού που φυλασσόταν ως secret. Το κλειδί αυτό αξιοποιήθηκε για authentication σε ένα εσωτερικό bastion host μέσω SSH, και στο τέλος έγινε dump ολόκληρου του εσωτερικού PostgreSQL σε χρόνο ρεκόρ.

Χρονοδιάγραμμα και ταχύτητα: από την πρόσβαση στην εξαγωγή σε λίγα λεπτά

Η ακολουθία των συμβάντων αποτυπώνει την αστραπιαία φύση της επιχείρησης: πρώτα WebSocket access, αμέσως μετά συλλογή περιβαλλοντικών διαπιστευτηρίων, και μέσα σε λίγες δεκάδες λεπτά οι AWS κλήσεις που οδήγησαν στην ανάκτηση μυστικών. Σύμφωνα με τις παρατηρήσεις της Sysdig Threat Research Team, ολόκληρη η αλυσίδα από την αρχική παραβίαση έως την εξαγωγή της βάσης εκτελέστηκε σε λιγότερο από μία ώρα, ενώ το ίδιο το dump της βάσης και του σχήματος χρειάστηκε λιγότερο από δύο λεπτά.

Η ταχύτητα αυτή έχει πρακτική σημασία: μειώνει το παράθυρο αντίδρασης για τα incident response teams και εκμηδενίζει την αποτελεσματικότητα πολλών παραδοσιακών έγκαιρων μέτρων που βασίζονται σε manual έλεγχο ή αργές διαδικασίες διερεύνησης.

Πώς επιβεβαιώθηκε η δράση του LLM agent

Οι αναλυτές της Sysdig εντόπισαν τέσσερις σαφείς ενδείξεις ότι η μετα-επίθεση ήταν προϊόν αυτοματοποιημένου agent και όχι απλού scripting ή ανθρώπινης αλληλεπίδρασης. Πρώτον, ο στόχευσης της βάσης ήταν αυτοσχέδιος: οι εντολές για εντοπισμό πινάκων και dump βασίστηκαν σε γενικεύσεις για σχήματα εφαρμογών, με δοκιμές σε πιθανούς πίνακες όπως «credential», χωρίς προκαθορισμένη ύπαρξη.

Δεύτερον, εμφανίστηκε ένα στιγμιαίο σχόλιο στον ροή εντολών, γραμμένο στα κινεζικά και μεταφραζόμενο ως «δείτε τι άλλο μπορούμε να κάνουμε», μια μορφή εσωτερικής «μονολογίας» που συνηθίζεται σε αυτό-προγραμματιζόμενα agents. Τρίτον, οι εντολές ήταν δομημένες ώστε να ευνοούν μηχανική ανάλυση: περιοριστές εξόδου, αποκομμένα αποτελέσματα και σιωπηλά σφάλματα, στοιχεία που δείχνουν ότι ένα άλλο σύστημα (το LLM) έκανε parsing και πήρε αποφάσεις βάσει των αποτελεσμάτων.

Τέταρτον, η επίθεση επαναχρησιμοποίησε δυναμικά τα δικά της outputs: διαπιστευτήρια που εξήχθησαν από ένα .pgpass χρησιμοποιήθηκαν άμεσα για ερωτήματα στη βάση, και identifiers από προηγούμενες AWS απαντήσεις αξιοποιήθηκαν δυναμικά για επιπλέον κλήσεις.

Τεχνικές απόκρυψης: διασπορά egress και παραπλάνηση

Μία από τις πιο ενδιαφέρουσες αποφεύξεις εντοπισμού ήταν η χρήση Cloudflare Workers ως διασκορπισμένο egress layer. Αντί να εκδίδουν όλες τις AWS κλήσεις από μία ip, οι επιτιθέμενοι «μοίρασαν» 12 κλήσεις σε 11 διαφορετικές IP μέσα σε 22 δευτερόλεπτα. Αυτό έσπασε την παραδοσιακή συσχέτιση πηγής-διεύθυνσης και περιόρισε την αποτελεσματικότητα των μηχανισμών που βασίζονται σε rate limiting ή IP anomaly detection.

Το ίδιο μοτίβο παρατηρήθηκε και στις SSH συνδέσεις προς το bastion: πολλαπλές, σύντομες ταυτόχρονες sessions από διαφορετικές IP αλλά με το ίδιο κλεμμένο κλειδί. Η τακτική αυτή μοιάζει με νόμιμη cloud συμπεριφορά—η παράλληλη εκτέλεση και οι πολλαπλές διευθύνσεις δικαιολογούνται σε πολλούς οργανισμούς—και επομένως οι παραδοσιακοί κανόνες ανίχνευσης δυσκολεύονται να την ξεχωρίσουν από το κανονικό θόρυβο.

Τι αλλάζει στον οικονομικό και επιχειρησιακό χάρτη των επιθέσεων

Η χρήση LLM agents αλλάζει την «οικονομία» των επιθέσεων: επενδύοντας σε generic AI agents αντί για ειδικά προσαρμοσμένα scripts, οι δράστες μειώνουν το κόστος ανά επίθεση και διευρύνουν το φάσμα των στόχων που μπορούν να πλήξουν. Οι agents μπορούν να μαθαίνουν από τα περιβάλλοντα-στόχους, να αναπροσαρμόζουν τα βήματα ανάλογα με τα ευρήματα και να αυτοματοποιούν πολύπλοκες αλυσίδες εκτέλεσης χωρίς ανθρώπινη παρέμβαση.

Για τους αμυνόμενους αυτό σημαίνει ότι οι γνωστές υπογραφές και τα μοτίβα εντολών χάνουν μεγάλο μέρος της αξίας τους. Κάθε επίθεση μπορεί να παράγει μοναδικό σετ ενεργειών, καθιστώντας αναποτελεσματική την εξάρτηση αποκλειστικά από IOCs και signature-based detection.

Προτεινόμενα μέτρα άμυνας και βελτίωση του detection

Η μετάβαση σε agent-driven απειλές απαιτεί αλλαγή προσέγγισης στην ασφάλεια. Ορισμένα ουσιαστικά μέτρα περιλαμβάνουν τα ακόλουθα: εφαρμογή αρχής least privilege σε όλα τα IAM roles, περιορισμός πρόσβασης σε Secrets Manager με κανόνες που επιτρέπουν ανάκτηση μόνο από συγκεκριμένες υπηρεσίες και με χρήση conditions, καθώς και ενεργοποίηση λεπτομερούς logging και βάθους τελείας με CloudTrail και εργαλεία συγκέντρωσης telemetry.

Πρακτικές όπως rotating credentials, προσωρινά/ephemeral credentials, χρήση VPC endpoints για πρόσβαση σε sensitive APIs, και η επιβολή MFA όπου είναι εφικτό μειώνουν σημαντικά το ρίσκο. Επίσης, η προστασία notebook περιβαλλόντων (π.χ. segmentation, sandboxing, περιορισμός outbound connectivity) πρέπει να γίνει προτεραιότητα: τα interactive notebooks συχνά έχουν πρόσβαση σε ευαίσθητα secrets και σπάνια ελέγχονται όπως οι servers παραγωγής.

Από πλευράς detection, οι ομάδες ασφάλειας πρέπει να προσθέσουν intent-based monitoring: ανίχνευση μη εξουσιοδοτημένης πρόσβασης σε αρχεία διαπιστευτηρίων, ανώμαλες ροές δεδομένων προς άγνωστους egress points, και ασυνήθιστες αλληλουχίες privilege escalations. Η παρακολούθηση για patterns όπως ταχεία ανάκτηση μυστικών, επαναλαμβανόμενες σύντομες SSH sessions, ή πολλαπλές API κλήσεις από διαφοροποιημένες IP σε μικρό χρόνο, μπορεί να αξιοποιήσει ML-based behavioral analytics για καλύτερη απόκρουση.

Τι σημαίνει για χρήστες και οργανισμούς

Στην πράξη, το παραπάνω περιστατικό σηματοδοτεί ότι ακόμη και μικρές, προσωρινές ευπάθειες σε notebooks ή developer tools μπορούν να εξελιχθούν σε σοβαρές παραβιάσεις υποδομών. Επιχειρήσεις που θεωρούν τα development environments ως «χαλαρά» ή τα αφήνουν χωρίς αυστηρούς ελέγχους θέτουν σε κίνδυνο όχι μόνο τον πηγαίο κώδικα αλλά και βασικές βάσεις δεδομένων και μυστικά cloud.

Επιπλέον, η πρόσβαση σε προηγμένα AI εργαλεία καθιστά τέτοιες επιθέσεις δυνατές ακόμη και για χαμηλότερου τεχνικού επιπέδου ομάδες: οι agents «συνθέτουν» και «εκτελούν» την πολύπλοκη λογική, μειώνοντας την ανάγκη ανθρώπινης τεχνογνωσίας. Αυτό διευρύνει το φάσμα των πιθανών επιτιθέμενων και αυξάνει την πιθανότητα επανάληψης ανάλογων περιστατικών.

Συνοψίζοντας, η άμυνα πρέπει να γίνει περισσότερο προληπτική, context-aware και προσαρμοστική: από αυστηρή διαχείριση μυστικών και πρόσβασης μέχρι βελτιωμένο monitoring της συμπεριφοράς εφαρμογών και χρηστών, και γρήγορα κανονιστικά playbooks για απομόνωση και ανάκτηση.