Une injection SQL Oracle ne se limite pas toujours à lire ou modifier des données. Dans un cas récemment documenté, des attaquants ont franchi une étape supplémentaire : transformer une compromission applicative en accès de niveau SYSTEM sur le serveur Windows, en s’appuyant sur des capacités Java intégrées à la base.
L’attaque décrite montre surtout un point crucial : lorsqu’une application expose une faille et que le compte de connexion dispose de privilèges inattendus, la base peut devenir une véritable plateforme d’exécution pour l’adversaire. Résultat : de la recherche d’informations en ligne, on bascule vers une compromission profonde de l’environnement.
Le chaînage : d’une faille applicative à l’intérieur d’Oracle
Le point de départ est une vulnérabilité de requête non contrôlée dans une application web publique. Plus précisément, un champ de recherche avec fonctionnalité d’autocomplétion passe des entrées sans validation vers la base via une connexion JDBC.
Grâce à cette faiblesse, l’adversaire exploite une injection SQL Oracle pour compromettre la base elle-même. Ensuite, il ne se contente pas d’exécuter du SQL “classique” : il charge du code Java directement dans Oracle, puis laisse la base compiler ce code en objets stockés dans le schéma.
À ce moment-là, l’attaque dépend d’un autre facteur : le compte utilisé côté application pour parler à Oracle avait des droits suffisants pour créer des objets Java au sein de la base.
Pourquoi la base peut devenir un point d’appui
Le kit observé (référencé sous le nom khunt) illustre une réalité qui complique la détection. Les objets Java compilés dans un schéma ne ressemblent pas à un binaire classique, ni à un fichier déposé sur le système de fichiers. De ce fait, de nombreux outils de sécurité axés sur les processus et les exécutables peuvent rater l’essentiel.
En d’autres termes, la base cesse d’être uniquement un endroit où l’on interroge des données. Elle devient, pour l’attaquant, un avant-poste depuis lequel lancer d’autres actions sur le serveur.
Compilation Java dans Oracle : le mécanisme central
Oracle intègre une machine virtuelle Java embarquée. Le mécanisme utilisé repose sur la capacité à fournir du code Java à Oracle à travers une instruction de type CREATE JAVA SOURCE. Ensuite, Oracle compile et stocke ce code sous forme d’objets de schéma.
Dans la logique décrite, l’étape clé n’est pas seulement de stocker du Java, mais de disposer des privilèges nécessaires pour y parvenir. Les informations de la documentation citée indiquent que, dans un schéma “utilisateur”, le seuil mentionné est au moins le droit CREATE PROCEDURE.
Par ailleurs, lorsqu’il s’agit ensuite d’enclencher l’exécution de commandes du système d’exploitation, le chemin passe par des appels du style Runtime.exec. Or cette exécution implique des autorisations additionnelles. L’enquête ne détaille pas la liste exacte des privilèges possédés par le compte compromis, mais le fait que la chaîne ait abouti suggère que l’ensemble des droits requis était bien présent.
Des objets khunt pour transformer l’accès : commandes, fichiers et extraction
Le toolkit khunt observé se compose de plusieurs objets Java et d’un ensemble de wrappers PL/SQL associés. Les fonctions rapportées couvrent plusieurs besoins typiques d’une intrusion : exécuter des commandes, lire des informations sensibles, inspecter le système de fichiers et préparer des archives.
Exécuter des commandes OS
L’objet KhuntCmd charge cmd.exe et exécute des commandes arbitraires fournies via le SQL.
Dans le cas étudié, exécuter cmd.exe /c whoami via ce chemin aboutit à un résultat correspondant à SYSTEM. Cela marque clairement le basculement d’un accès applicatif vers une escalade de privilèges au niveau du système.
Récupérer des informations d’identités
Un autre module, KhuntHash, vise l’extraction de données d’authentification : il lit des éléments tels que des identifiants et des empreintes de mots de passe dans la base (via des structures internes) puis les écrit dans un fichier.
Explorer et manipuler les fichiers
Les composants KhuntFS et KhuntFS2 servent à parcourir et analyser le système de fichiers : lister, lire, chercher et déterminer des tailles.
Enfin, KhuntT aide à vérifier que le toolkit est bien joignable, tandis que KhuntUnzip décompresse des archives.
Actions sur Windows : copie de hives et collecte
Une fois l’exécution au niveau SYSTEM atteinte, l’adversaire change de registre : au lieu de rester uniquement dans Oracle, il agit directement sur le système Windows.
Les observations décrivent l’utilisation de PowerShell et de reg.exe pour copier des éléments de registre, notamment les hives SECURITY et SYSTEM vers un emplacement sur le disque (indiqué comme F:\Oracle).
Ensuite, la collecte se poursuit avec des commandes telles que tasklist /svc dont la sortie est redirigée vers un fichier (par exemple khunttasks.txt). Des hives additionnelles, telles que SAM et SECURITY, sont aussi copiées à l’aide d’un utilitaire mentionné comme esentutl.exe.
L’enquête signale que des fichiers ont été préparés localement. En revanche, elle ne confirme pas l’exfiltration dans cette observation, ni le nom d’un acteur de menace précis.
Indicateurs et limites : que chercher, et pourquoi les alertes peuvent être trompeuses
Le suivi a commencé après des détections liées à des tentatives de vol d’identifiants déclenchées le 27 juillet 2026. À partir de là, les investigations ont relié la chaîne d’attaque à des exécutions de code au niveau du système sur Windows.
Pour repérer ce toolkit en particulier, l’approche proposée est de procéder à une recherche ciblée :
- Sur l’installation Oracle, repérer des objets dont les noms commencent par Khunt.
- Dans les journaux SQL, rechercher des entrées compatibles avec KHUNT%.
Cependant, il existe une contrainte importante : les indicateurs listés sont spécifiques à ce toolkit. Autrement dit, une recherche du type “Khunt” ou “KHUNT%” ne révélera pas forcément d’autres techniques similaires qui utilisent des objets et des chaînes différentes.
Cette nuance est essentielle pour la défense : la détection ne doit pas uniquement reposer sur les noms observés, mais aussi sur la capacité d’exécution et l’usage anormal de fonctions Java côté base.
Pourquoi un correctif Oracle seul ne suffit pas
La situation met en évidence deux leviers complémentaires, car l’attaque s’appuie sur une combinaison de facteurs :
- La faille dans l’application : l’entrée fournie via l’autocomplétion est transmise à Oracle sans validation adéquate.
- Les privilèges du compte JDBC : ce compte pouvait créer des objets Java, et donc servir de marchepied à l’exécution.
Les informations communiquées indiquent qu’aucun correctif Oracle ne règle à lui seul la vulnérabilité applicative, ni la question des droits accordés au compte derrière la connexion. En clair, “patcher” uniquement Oracle sans corriger l’application et sans réduire les permissions côté base laisserait la brèche ouverte.
Recommandations : sécuriser l’application et appliquer le moindre privilège
Pour réduire le risque d’une injection SQL Oracle menant à une exécution plus profonde, l’enquête recommande une approche pragmatique en deux temps.
1) Corriger la logique applicative
La première étape consiste à remplacer les requêtes vulnérables par des requêtes paramétrées et à renforcer l’validation des entrées côté application. Cela empêche que du texte injecté devienne du code ou une commande interprétable par Oracle.
2) Réduire les privilèges côté Oracle
La seconde étape consiste à appliquer le moindre privilège. Un compte qui sert une application exposée au public ne devrait pas disposer de droits qui lui permettent de créer des objets Java ou d’utiliser des capacités de procédure stockée sans raison opérationnelle.
En pratique, cela signifie revoir la configuration des comptes, séparer les rôles (lecture/écriture, exploitation, administration) et limiter au strict nécessaire ce qui peut être créé ou exécuté depuis le schéma de l’application.
Conclusion
Ce cas montre comment une injection SQL Oracle peut évoluer en attaque système complète : grâce à l’accès initial via une application web, puis à la compilation Java interne à Oracle, les attaquants ont réussi à atteindre un niveau d’exécution associé à SYSTEM sur Windows.
Pour s’en protéger, il faut corriger la source (requêtes paramétrées et validation), mais aussi neutraliser l’amplificateur (privilèges trop élevés côté base). En combinant ces mesures, vous réduisez fortement la probabilité qu’une simple injection se transforme en prise de contrôle de l’environnement.
Source: https://thehackernews.com/2026/08/attackers-compile-khunt-inside-oracle.html
