Une injection SQL transforme une base de données Oracle en plateforme d’attaque contre Windows
Comment une injection SQL a transformé une base Oracle en point d’attaque Windows, avec déploiement de khunt et exécution de commandes système.
Image d’illustration générée par IA
L’accès initial passe par un endpoint de recherche
Le 27 juillet 2026, Huntress a identifié une activité de vol d’identifiants sur un serveur hébergeant une base de données Oracle.
L’accès aurait débuté par une injection SQL dans un endpoint public de recherche et d’autocomplétion. Cette fonctionnalité, intégrée à une application Java exécutée sur Apache Tomcat, ne validait pas correctement les entrées reçues.
Les attaquants ont ainsi pu injecter des commandes SQL dans les requêtes envoyées à la base de données. Les activités malveillantes ont été attribuées à l’adresse 178.162.151[.]229.
Les versions d’Oracle, d’Apache Tomcat, de Java et de Windows concernées n’ont pas été précisées.
Khunt est installé directement dans le schéma Oracle
Au lieu de copier un exécutable sur le serveur, les attaquants ont intégré la boîte à outils post-exploitation khunt à la base de données sous la forme d’un objet Java.
Cette technique exploite la JVM intégrée à Oracle ainsi que l’instruction CREATE JAVA SOURCE, qui permet de stocker et de compiler du code Java au sein du schéma. Les objets créés peuvent ensuite être appelés via SQL.
Lorsqu’ils disposent des autorisations nécessaires, ces objets peuvent exécuter des commandes sur le système d’exploitation. Huntress décrit cette méthode comme rarement documentée dans le cadre d’attaques réelles.
La boîte à outils comprend plusieurs modules :
- KhuntCmd, pour exécuter des commandes via
cmd.exeet des instructions SQL ; - KhuntHash, pour accéder à la table interne des utilisateurs Oracle et écrire les noms d’utilisateur et les mots de passe dans un fichier ;
- KhuntFS et KhuntFS2, pour parcourir, lire et rechercher des fichiers, ainsi que vérifier leur taille ;
- KhuntT, pour vérifier que l’installation a réussi ;
- KhuntUnzip, pour extraire des archives compressées ;
- des wrappers PL/SQL destinés à l’exécution de commandes, au vol d’identifiants et à la gestion des fichiers.
Commandes Windows et possible credential dumping
Les attaquants ont exécuté :
cmd.exe /c whoami
Le résultat indiquait des privilèges SYSTEM sur le serveur Windows, soit le niveau opérationnel le plus élevé décrit dans ce cas.
Ils ont ensuite utilisé PowerShell et des utilitaires Windows pour copier les ruches de registre SAM, SECURITY et SYSTEM. Ces fichiers peuvent servir à récupérer les hashes des mots de passe des comptes locaux.
Huntress estime probable qu’une opération de credential dumping ait été menée, mais ne confirme pas que les ruches ont effectivement été exfiltrées du système.
Les attaquants ont également lancé :
tasklist /svc
La sortie, qui contenait la liste des processus et des services actifs, a été enregistrée dans le fichier khunttasks.txt.
Cette chaîne d’attaque a transformé la base de données Oracle en point de persistance et d’exécution disposant de privilèges élevés au sein du réseau de l’entreprise. La source ne fournit ni score CVSS ni classification formelle, mais la portée opérationnelle est importante.
Contrôles et mesures pour réduire le risque
Les applications exposées doivent valider et assainir toutes les entrées, notamment celles des fonctions de recherche et d’autocomplétion. Les comptes utilisés pour se connecter à Oracle ne devraient par ailleurs disposer que des privilèges strictement nécessaires.
Il convient notamment d’empêcher ces comptes :
- de créer des sources Java via
CREATE JAVA SOURCE; - d’exécuter des procédures stockées inutiles ;
- d’effectuer des opérations d’administration sur la base de données ou le système.
Les équipes de sécurité devraient analyser les logs Apache et les requêtes SQL anormales, en recherchant également la création d’objets Java Oracle.
Sur les systèmes Windows, il faut surveiller le lancement de cmd.exe, de PowerShell et de tasklist, ainsi que les accès ou les copies des ruches SAM, SECURITY et SYSTEM. Pris isolément, chacun de ces indicateurs peut avoir une explication légitime ; leur combinaison nécessite en revanche une vérification immédiate.
Sources
Cet article est une réécriture originale fondée sur les sources ci-dessous.




