Une attaque par injection SQL contre Oracle permet l’exécution de code à distance

Malgré des décennies de sensibilisation, l’injection SQL (SQLi) reste une technique efficace pour les cybercriminels. 

Une récente enquête de Huntress montre comment une attaque par injection SQL apparemment courante a évolué en compromission complète du système d’exploitation (OS) via l’exploitation de fonctionnalités d’Oracle Database. 

Principaux enseignements de l’attaque par injection SQL

• Une vulnérabilité d’injection SQL dans une application Java/Tomcat accessible depuis Internet a permis à des attaquants d’obtenir un accès initial à une base de données Oracle, puis d’exécuter du code à distance sur le serveur Windows sous-jacent.
• Les attaquants ont détourné la fonctionnalité CREATE JAVA SOURCE d’Oracle pour déployer la boîte à outils khunt, montrant ainsi comment des fonctionnalités légitimes de base de données peuvent être militarisées afin d’établir une persistance et de contourner les outils traditionnels de sécurité des terminaux.
• À l’aide de la boîte à outils khunt, les acteurs de la menace ont exécuté des commandes du système d’exploitation, dérobé des identifiants Oracle et Windows et collecté des ruches du registre en vue d’une éventuelle exfiltration et d’une élévation de privilèges.
• Les organisations peuvent réduire le risque d’attaques similaires en combinant des pratiques de développement sécurisé, un accès aux bases de données fondé sur le principe du moindre privilège, une surveillance renforcée d’Oracle, des tests d’intrusion réguliers et des plans de réponse aux incidents testés.

Comment l’attaque par injection SQL contre Oracle a commencé 

Selon Huntress, l’incident a débuté le 27 juillet 2026, lorsque des analystes de sécurité ont détecté une activité de vol d’identifiants sur un terminal Windows hébergeant un serveur de base de données Oracle. 

L’enquête a révélé qu’une application Java/Tomcat accessible depuis Internet ne validait pas correctement les entrées utilisateur, permettant aux attaquants d’injecter des commandes SQL malveillantes. 

L’application vulnérable transmettait directement ces commandes à la base de données Oracle via une connexion Java Database Connectivity (JDBC), offrant aux attaquants un premier point d’ancrage.

Comment les attaquants ont déployé la boîte à outils à l’aide de Java Oracle 

Ce qui a rendu cette attaque remarquable est la méthode utilisée après la compromission initiale. 

Plutôt que de déployer directement des logiciels malveillants sur le système d’exploitation, les acteurs de la menace ont téléversé une boîte à outils résidant dans la base de données, nommée khunt, en utilisant la fonctionnalité CREATE JAVA SOURCE d’Oracle. 

Les bases de données Oracle intègrent une machine virtuelle Java (JVM), ce qui permet aux développeurs de stocker du code Java sous forme d’objets de base de données.

Dans ce cas, les attaquants ont détourné cette fonctionnalité légitime pour compiler et exécuter du code Java malveillant directement dans la base de données, créant ainsi un mécanisme de persistance furtif que les outils traditionnels de sécurité des terminaux peuvent ne pas détecter.

La boîte à outils se composait de plusieurs modules spécialisés qui étendaient les capacités des attaquants. 

KhuntCmd permettait d’exécuter des commandes arbitraires du système d’exploitation Windows via des instructions SQL. 

KhuntHash extrayait les noms d’utilisateur et les mots de passe Oracle dans un fichier, tandis que KhuntFS et KhuntFS2 permettaient de parcourir, lire et rechercher des fichiers. 

Parmi les autres composants figuraient KhuntT, qui vérifiait le bon fonctionnement de la boîte à outils, et KhuntUnzip, qui servait à extraire des fichiers compressés. 

Ces modules ont efficacement transformé la base de données Oracle en plateforme de post-exploitation capable d’interagir directement avec le système d’exploitation sous-jacent.

Comment la boîte à outils Khunt a permis l’exécution de code à distance (RCE) et le vol d’identifiants 

La boîte à outils khunt a donné aux attaquants la capacité de faire le lien entre la base de données Oracle et le système d’exploitation Windows sous-jacent. 

Grâce à son module KhuntCmd, la boîte à outils permettait aux attaquants d’exécuter des commandes OS arbitraires en envoyant des instructions SQL à la base de données, transformant de fait cette dernière en plateforme d’exécution de code à distance.

Après avoir déployé la boîte à outils, les attaquants ont utilisé KhuntCmd pour exécuter la commande whoami et ont confirmé qu’ils disposaient de privilèges de niveau SYSTEM, démontrant ainsi la réussite de l’exécution de code à distance depuis la base de données Oracle vers l’OS Windows. 

Ils ont ensuite utilisé PowerShell et les utilitaires Windows pour copier les ruches de registre SAM, SYSTEM et SECURITY, qui contiennent des condensats de mots de passe pouvant être extraits à des fins de vol d’identifiants ou d’élévation de privilèges. 

Avant de préparer les données en vue d’une éventuelle exfiltration, les attaquants ont également recensé les services en cours d’exécution à l’aide de tasklist /svc.

Comment réduire les risques liés aux attaques par injection SQL

L’enquête de Huntress montre que même des techniques d’attaque vieilles de plusieurs décennies peuvent avoir des conséquences dévastatrices lorsque les contrôles de sécurité élémentaires sont négligés.

Dans ce cas, une injection SQL vulnérable a permis aux attaquants de dépasser le périmètre de la base de données et d’exécuter du code à distance en détournant des fonctionnalités légitimes d’Oracle. 

Les organisations peuvent réduire le risque d’attaques similaires en mettant en œuvre des contrôles de sécurité en profondeur qui renforcent la prévention, la détection et la réponse dans leurs environnements Oracle. 

• Mettez en œuvre des requêtes paramétrées et une validation correcte des entrées afin de vous protéger contre les vulnérabilités d’injection SQL avant qu’elles ne puissent être exploitées.
• Appliquez le principe du moindre privilège en limitant la capacité des comptes de base de données à créer des objets de code source Java, à exécuter des procédures stockées ou à effectuer des actions d’administration.
• Étendez la surveillance au-delà de la détection sur les terminaux en auditant les objets des bases de données Oracle, les journaux SQL et la création inattendue de code source Java afin de repérer toute activité malveillante.
• Recherchez régulièrement dans les environnements Oracle les indicateurs de compromission connus, notamment les objets Java suspects, les entrées KHUNT% dans les journaux SQL et les artefacts de ruches de registre créés par les attaquants.
• Renforcez les environnements Oracle et applicatifs en limitant les fonctionnalités de base de données superflues, en sécurisant les identifiants des bases de données et en isolant les serveurs de bases de données des applications accessibles depuis Internet.
• Intégrez des tests d’intrusion évaluations au cycle de développement logiciel afin d’identifier les vulnérabilités avant le déploiement.
• Testez les plans de réponse aux incidents et utilisez des outils de simulation d’attaque avec des scénarios portant sur les attaques par injection SQL et l’exécution de code à distance.

Ensemble, ces mesures peuvent aider les organisations à réduire leur surface d’attaque globale, à limiter le rayon d’impact des compromissions réussies et à renforcer leur résilience à long terme. 

En résumé

Le risque stratégique ne réside pas dans la seule injection SQL — mais dans ce qui suit. 

Une fois leur point d’ancrage établi, les attaquants ont transformé la base de données Oracle en plateforme d’exécution, permettant une exécution de code à distance tout en restant largement en dehors du périmètre de la surveillance classique des terminaux. 

Alors que les adversaires continuent de combiner des fonctionnalités légitimes des plateformes avec des techniques d’attaque éprouvées, les responsables de la sécurité devraient réévaluer la capacité de leur stratégie de détection à fournir une visibilité suffisante sur les menaces résidant dans les bases de données, et pas seulement sur l’activité se produisant au niveau du système d’exploitation. 

Une architecture Zero Trust, conçue pour limiter la confiance implicite et contenir l’impact d’une compromission réussie.