khunt transforme Oracle Database en plateforme de post-exploitation — le cauchemar des DBA

27 juillet 2026, quelque part dans un SOC. La plateforme Huntress remonte une alerte de vol de credentials sur un serveur hébergeant une base Oracle Database. L’équipe d’investigation s’attend à un banal credential dumping. Elle découvre bien pire : un toolkit de post-exploitation complet — baptisé khunt — compilé et exécuté à l’intérieur même de la base de données Oracle, via la JVM embarquée.

Le 5 août 2026, le rapport public tombe. Lawrence Abrams de BleepingComputer détaille la chaîne d’attaque. Pour les DBA, c’est le réveil brutal : votre base de données est un runtime applicatif complet. Les attaquants l’ont compris avant vous.

La chaîne d’attaque : d’une injection SQL à un shell SYSTEM

L’attaque, décortiquée par Huntress, suit une progression chirurgicale :

1. Porte d’entrée. Une application Java publique, hébergée sur Apache Tomcat, expose un endpoint de recherche avec autocomplétion. La validation des entrées est absente.
2. SQL injection. Les attaquants injectent des commandes SQL via le champ de recherche, obtenant un accès à la base Oracle sous-jacente.
3. Embarquement du toolkit. Via l’instruction CREATE JAVA SOURCE — une fonctionnalité légitime d’Oracle qui permet de stocker et compiler du code Java comme objet de schéma — les attaquants déploient khunt directement dans la base.
4. Exécution OS. Oracle exécute le code Java via sa JVM Aurora embarquée. Les wrappers PL/SQL de khunt appellent cmd.exe avec les privilèges SYSTEM du serveur Windows sous-jacent.
5. Vol de credentials. KhuntHash aspire la table utilisateur interne d’Oracle. cmd.exe /c whoami confirme les privilèges SYSTEM. Les ruches de registre SAM, SECURITY et SYSTEM sont copiées pour extraction hors ligne des hashs NTLM.

« L’utilisation de cette technique in the wild a rarement été documentée », souligne Huntress.

L’adresse IP malveillante, 178.162.151[.]229, a été tracée par les logs Apache. Mais l’alerte était tardive : le toolkit était déjà en place.

khunt : le couteau suisse de la post-exploitation Oracle

Le toolkit khunt se compose de six composants Java, chacun avec une fonction dédiée :

Les attaquants ont utilisé KhuntCmd pour exécuter un whoami, confirmant les privilèges SYSTEM, puis ont enchaîné avec PowerShell pour copier les ruches de registre et avec tasklist /svc pour énumérer les services en cours d’exécution.

Rien de tout cela n’a nécessité de déposer un fichier exécutable sur le disque du serveur. Tout le code malveillant résidait dans la base de données elle-même.

La JVM embarquée d’Oracle : fonctionnalité ou porte dérobée ?

Le point central de cette attaque est la Java Virtual Machine embarquée d’Oracle (Oracle JVM, anciennement Aurora JVM). Cette fonctionnalité, activée par défaut dans de nombreuses configurations, permet :

• De stocker du code source Java comme objet de base de données (CREATE JAVA SOURCE)
• De le compiler et l’exécuter dans le processus Oracle
• D’interagir avec le système d’exploitation via des stored procedures Java

La JVM embarquée est un outil puissant pour les développeurs — elle permet d’étendre Oracle avec de la logique métier en Java sans serveur d’application externe. Mais dans les mains d’un attaquant, c’est un runtime d’exfiltration natif qui ne laisse aucune trace sur le disque.

Huntress recommande explicitement que les comptes de base de données utilisés par les applications publiques n’aient pas les privilèges suffisants pour créer des sources Java, exécuter des procédures stockées non nécessaires, ou effectuer des actions administratives.

Actions concrètes pour les DBA et équipes DevOps

Cette attaque n’exploite pas un zero-day Oracle. Elle exploite une mauvaise configuration et une absence de validation des entrées à deux niveaux successifs. Voici ce que les équipes doivent faire :

1. Désactiver ou restreindre la JVM embarquée

-- Vérifier si la JVM est installée
SELECT comp_name, version, status FROM dba_registry WHERE comp_name LIKE '%JAVA%';

-- Révoquer les privilèges de création Java pour les comptes applicatifs
REVOKE CREATE PROCEDURE, CREATE ANY PROCEDURE FROM app_user;
REVOKE EXECUTE ON DBMS_JAVA FROM app_user;

Si votre application n’utilise pas de procédures stockées Java, désactivez complètement la JVM embarquée.

2. Renforcer la validation des entrées au niveau applicatif

L’injection SQL initiale provenait d’un champ d’autocomplétion — le type d’endpoint que les équipes considèrent souvent comme « bas risque ». Toute entrée utilisateur transmise à une base de données doit être paramétrée :

// ❌ Concatenation — vulnérable
String query = "SELECT * FROM products WHERE name LIKE '%" + userInput + "%'";

// ✅ PreparedStatement — protégé
PreparedStatement ps = conn.prepareStatement(
    "SELECT * FROM products WHERE name LIKE ?"
);
ps.setString(1, "%" + userInput + "%");

3. Appliquer le principe du moindre privilège sur les comptes DB

Le compte Oracle utilisé par l’application ne doit jamais avoir les privilèges CREATE JAVA, CREATE ANY PROCEDURE, ou les rôles DBA/JAVA_ADMIN. Utilisez un compte dédié avec uniquement les droits SELECT, INSERT, UPDATE, DELETE sur les tables nécessaires.

4. Monitorer les créations d’objets Java suspects

-- Surveiller les créations récentes d'objets Java
SELECT object_name, object_type, created, status
FROM dba_objects
WHERE object_type = 'JAVA SOURCE'
AND created > SYSDATE - 30;

Verdict

khunt n’est pas le premier toolkit de post-exploitation embarqué dans une base de données, mais c’est l’un des rares documentés publiquement. Il rappelle une vérité que trop d’équipes DevOps ignorent : une base de données Oracle est un runtime applicatif complet, pas un simple entrepôt de données.

Si vous gérez une base Oracle accessible depuis une application web, vérifiez aujourd’hui-même que :

1. La validation des entrées est paramétrée sur tous les endpoints, y compris les fonctionnalités « anodines » comme l’autocomplétion.
2. Le compte DB applicatif ne peut pas créer de sources Java.
3. La JVM embarquée est désactivée si inutile, ou restreinte aux comptes administrateurs uniquement.

Si vous utilisez Apache Tomcat en frontal, auditez les endpoints exposés publiquement — c’est la porte d’entrée qui a permis cette compromission.

Références

• BleepingComputer, Hackers run khunt post-exploitation toolkit from Oracle database, 5 août 2026 — https://www.bleepingcomputer.com/news/security/hackers-run-khunt-post-exploitation-toolkit-from-oracle-database/
• Rapport d’investigation Huntress, 5 août 2026
• Documentation Oracle, Oracle Database Java Developer’s Guide — Chapitre sur la JVM embarquée et CREATE JAVA SOURCE