khunt: SQL Injection σε Oracle οδηγεί σε SYSTEM πρόσβαση

Το khunt, ένα post-exploitation toolkit που εγκαταστάθηκε μέσα σε μια βάση δεδομένων Oracle, χρησιμοποιήθηκε από επιτιθέμενους για να αποκτήσουν SYSTEM-level πρόσβαση σε Windows server, εκμεταλλευόμενοι μια κρίσιμη ευπάθεια SQL injection. Η εταιρεία κυβερνοασφάλειας Huntress αποκάλυψε την επίθεση αφού ανιχνεύτηκαν ειδοποιήσεις κλοπής διαπιστευτηρίων στις 27 Ιουλίου 2026, ανακαλύπτοντας μια αλυσίδα επίθεσης που μετέτρεψε τη βάση δεδομένων από στόχο σε εφαλτήριο. Το ιδιαίτερο χαρακτηριστικό της επίθεσης ήταν ότι οι επιτιθέμενοι δεν έγραψαν κανένα εκτελέσιμο αρχείο στο δίσκο, καθιστώντας την ανίχνευση εξαιρετικά δύσκολη.

Δείτε επίσης: SourceCodester Class Timetabling: SQL Injection ευπάθεια CVE-2026-14770

Η επίθεση ξεκίνησε από μια ευπάθεια SQL injection σε ένα δημόσια προσβάσιμο πεδίο αυτόματης συμπλήρωσης (autocomplete) μιας εφαρμογής Java που εκτελούνταν σε Apache Tomcat. Η εφαρμογή δεν επικύρωνε σωστά τα δεδομένα εισόδου του χρήστη, επιτρέποντας στους επιτιθέμενους να εισάγουν κακόβουλο SQL κώδικα που διαβιβαζόταν στη βάση δεδομένων μέσω σύνδεσης Java Database Connectivity (JDBC). Ο λογαριασμός που χρησιμοποιούσε αυτή τη σύνδεση διέθετε επαρκή δικαιώματα για τη δημιουργία αντικειμένων Java εντός της βάσης δεδομένων, κάτι που αποδείχθηκε καταστροφικό.

Η Oracle διαθέτει ενσωματωμένη Java Virtual Machine (JVM), και η εντολή CREATE JAVA SOURCE επιτρέπει σε έναν χρήστη να υποβάλει κώδικα Java τον οποίο η βάση δεδομένων μεταγλωττίζει και αποθηκεύει ως αντικείμενο σχήματος (schema object). Σε ένα δικό του schema, η τεκμηρίωση της Oracle ορίζει ως ελάχιστη απαίτηση το σύστημα προνόμιο CREATE PROCEDURE. Η εκτέλεση διεργασιών λειτουργικού συστήματος από αυτόν τον κώδικα γίνεται μέσω Runtime.exec, που απαιτεί ξεχωριστή άδεια εκτέλεσης αρχείων. Η Huntress δεν αποκάλυψε ποια ακριβώς δικαιώματα είχε ο παραβιασμένος λογαριασμός, αλλά η επιτυχία της αλυσίδας επίθεσης αποδεικνύει ότι διέθετε αρκετά για όλα τα στάδια.

Πώς λειτουργεί το khunt μέσα στην Oracle

Το khunt αποτελείται από έξι αντικείμενα Java και πολλά PL/SQL wrappers με πρόθεμα khunt_*. Κάθε συστατικό εκτελεί συγκεκριμένη λειτουργία: το KhuntCmd φόρτωνε το cmd.exe και εκτελούσε αυθαίρετες εντολές λειτουργικού συστήματος που περνούσαν ως SQL. Το KhuntHash διάβαζε ονόματα χρηστών και κατακερματισμένους κωδικούς πρόσβασης από τον εσωτερικό πίνακα χρηστών της Oracle και τα έγραφε σε αρχείο. Τα KhuntFS και KhuntFS2 παρείχαν λειτουργίες καταλόγου, ανάγνωσης, αναζήτησης και μέτρησης μεγέθους αρχείων. Το KhuntT επιβεβαίωνε ότι το toolkit ήταν προσβάσιμο, ενώ το KhuntUnzip αποσυμπίεζε αρχεία.

Η εκτέλεση της εντολής cmd.exe /c whoami μέσω του KhuntCmd επέστρεψε SYSTEM, επιβεβαιώνοντας ότι οι επιτιθέμενοι είχαν αποκτήσει τα υψηλότερα δυνατά δικαιώματα στον Windows server. Στη συνέχεια, χρησιμοποίησαν PowerShell και reg.exe για να αντιγράψουν τα registry hives SECURITY και SYSTEM στον κατάλογο F:\Oracle, εκτέλεσαν tasklist /svc αποθηκεύοντας τα αποτελέσματα σε αρχείο khunttasks.txt, και αντέγραψαν τα hives SAM και SECURITY με το εργαλείο esentutl.exe. Αυτά τα registry hives περιέχουν κρυπτογραφημένα διαπιστευτήρια τοπικών λογαριασμών και άλλα ευαίσθητα μυστικά που μπορούν να χρησιμοποιηθούν για lateral movement.

Η τεχνική αυτή δεν είναι νέα — ο Marco Ivaldi είχε δημοσιεύσει το raptor_oraexec.sql ήδη από το 2006, το οποίο δημιουργεί αντικείμενα Oracle source με μεθόδους εκτέλεσης εντολών και ανάγνωσης αρχείων. Τα αντικείμενα του khunt χρησιμοποιούν την ίδια βασική αρχιτεκτονική. Αυτό που κάνει την περίπτωση αξιοσημείωτη είναι, όπως επισημαίνει η Huntress, ότι η χρήση της τεχνικής στην πράξη έχει σπάνια τεκμηριωθεί.

Δείτε επίσης: Oracle July Patch Update: 1.449 διορθώσεις και 10 κρίσιμα κενά ασφαλείας

Γιατί το khunt είναι δύσκολο να ανιχνευθεί

Ένα αντικείμενο Java που μεταγλωττίζεται μέσα σε ένα schema βάσης δεδομένων δεν είναι διεργασία, δυαδικό αρχείο ή αρχείο στο σύστημα αρχείων. Τα προϊόντα Endpoint Detection and Response (EDR) δεν επιθεωρούν γενικά τα εσωτερικά της Oracle, με αποτέλεσμα το khunt να παραμένει αόρατο στα παραδοσιακά εργαλεία ασφαλείας. Όπως το θέτει η Huntress, η βάση δεδομένων παύει να είναι κάτι που οι επιτιθέμενοι απλώς ερωτούν και γίνεται ένα προγεφύρωμα από το οποίο επιτίθενται. Αυτή η μετατόπιση αντίληψης είναι κρίσιμη για τους αμυνόμενους.

Η Huntress παρατήρησε ότι τα αρχεία σταδιοποιήθηκαν τοπικά, αλλά δεν κατάφερε να επιβεβαιώσει αν εξήχθησαν. Η εταιρεία δεν κατονόμασε κάποιον συγκεκριμένο απειλητικό παράγοντα, αλλά ανέφερε ότι τα κακόβουλα αιτήματα προέρχονταν από τη διεύθυνση IP 178.162.151[.]229. Δεν υπάρχει κανένα patch της Oracle που να κλείνει είτε την ευπάθεια της εφαρμογής είτε το πρόβλημα υπερβολικών δικαιωμάτων του λογαριασμού — η ρίζα του προβλήματος βρίσκεται στη διαμόρφωση και στον κώδικα της εφαρμογής, όχι σε κάποιο συγκεκριμένο CVE της Oracle.

Για την ανίχνευση του khunt, η Huntress συνιστά αναζήτηση στην εγκατάσταση Oracle για ονόματα αντικειμένων που αρχίζουν με Khunt, καθώς και στα SQL logs για μοτίβα KHUNT%. Ωστόσο, αυτοί οι δείκτες είναι ειδικοί για αυτό το toolkit — μια γενικότερη αναζήτηση δεν θα αποκαλύψει παρόμοιες τεχνικές που χρησιμοποιούν διαφορετικά ονόματα αντικειμένων.

Πώς να προστατευτείτε από επιθέσεις τύπου khunt

Η πρωταρχική άμυνα είναι η χρήση parameterized queries και η επικύρωση εισόδου (input validation) σε όλα τα σημεία της εφαρμογής, ιδιαίτερα σε πεδία αναζήτησης και αυτόματης συμπλήρωσης. Παράλληλα, η αρχή του ελάχιστου προνομίου (least privilege) πρέπει να εφαρμόζεται αυστηρά: ένας λογαριασμός που εξυπηρετεί μια δημόσια εφαρμογή δεν πρέπει να έχει τη δυνατότητα δημιουργίας αντικειμένων Java ή εκτέλεσης stored procedures που δεν χρειάζεται. Η απενεργοποίηση ή ο αυστηρός περιορισμός των δυνατοτήτων Java της Oracle και των διαδρομών εκτέλεσης εντολών host, εκτός αν είναι ρητά απαραίτητες, μειώνει σημαντικά την επιφάνεια επίθεσης.

Επιπλέον, οι οργανισμοί πρέπει να παρακολουθούν για ύποπτη δημιουργία αντικειμένων Java στην Oracle και ασυνήθιστη δραστηριότητα μεταγλώττισης εντός της βάσης δεδομένων, ειδικά μετά από σφάλματα SQL ή ειδοποιήσεις διαπιστευτηρίων. Η παρακολούθηση για δείκτες εντολών λειτουργικού συστήματος — όπως χρήση cmd.exe, PowerShell, και πρόσβαση στα hives SAM, SECURITY ή SYSTEM από διεργασίες που σχετίζονται με τη βάση δεδομένων — είναι επίσης κρίσιμη. Τέλος, η συσχέτιση των audit logs της βάσης δεδομένων με τα web logs μπορεί να αποκαλύψει αλυσίδες επίθεσης που διαφορετικά θα παρέμεναν αόρατες.

Δείτε επίσης: Κρίσιμη ευπάθεια ανακαλύφθηκε στο Windows Common File System

Η περίπτωση του khunt, αποτελεί υπενθύμιση ότι το fileless δεν σημαίνει χαμηλής επίπτωσης. Το toolkit ζούσε ως αντικείμενα βάσης δεδομένων, αλλά επέτρεψε εκτέλεση εντολών, πρόσβαση σε διαπιστευτήρια και λειτουργίες αρχείων στον Windows host. Η επίθεση υπογραμμίζει ότι η ασφάλεια των βάσεων δεδομένων δεν μπορεί να αντιμετωπίζεται ανεξάρτητα από την ασφάλεια της εφαρμογής και τη διαχείριση δικαιωμάτων — και οι τρεις πτυχές πρέπει να αντιμετωπίζονται ως ενιαίο σύστημα άμυνας.