Attaque Khunt : comment des pirates ont transformé une base Oracle en plateforme de post-exploitation

Le toolkit Khunt : vivre dans la base de données sous forme d'objets Java

Plutôt que de déployer des fichiers malveillants traditionnels sur le serveur compromis, les attaquants ont utilisé la machine virtuelle Java (JVM) intégrée d'Oracle et l'instruction CREATE JAVA SOURCE pour compiler et stocker l'intégralité du toolkit de post-exploitation sous forme d'objets Java dans la base de données Oracle . Cette approche a rendu le toolkit invisible pour les défenses standard au niveau du système d'exploitation, car les outils EDR et antivirus se concentrent sur les processus, les binaires et les fichiers du système d'exploitation — ils n'inspectent généralement pas les classes Java et les wrappers PL/SQL stockés dans Oracle .

Le toolkit khunt comprenait les composants suivants, chacun stocké en tant qu'objet de base de données :

Obtenir le contrôle total du système : de la base de données au système d'exploitation Windows

Les attaquants ne se sont pas arrêtés à un accès au niveau de la base de données. Ils ont utilisé le toolkit khunt pour passer de la couche base de données au système d'exploitation Windows sous-jacent en plusieurs étapes :

1. Exécution de commandes système via KhuntCmd : Ils ont utilisé le module KhuntCmd pour exécuter cmd.exe /c whoami, ce qui a confirmé qu'ils disposaient de privilèges SYSTEM sur le serveur Windows, établissant une exécution de code à distance (RCE) de la base de données vers le système d'exploitation .
2. Vol d'identifiants : Ils ont utilisé PowerShell pour invoquer reg.exe et copier les ruches de registre SECURITY et SYSTEM, les sauvegardant sous les noms khuntSECURITY.hiv et khuntSYSTEM.hiv dans F:\Oracle\ .
3. Énumération des services : Ils ont exécuté tasklist /svc et sauvegardé la sortie sous khunttasks.txt .
4. Extraction supplémentaire de ruches : Ils ont utilisé esentutl.exe pour copier les ruches SAM et une seconde copie des ruches SECURITY, les sauvegardant sous les noms khuntSAM.hiv et khunt_SECURITY.hiv .

Les ruches de registre exfiltrées pouvaient être utilisées hors ligne pour extraire et décoder les hachages de mots de passe de tous les comptes locaux du système .

Angles morts de la défense : les conclusions clés de Huntress

L'enquête de Huntress a révélé plusieurs angles morts critiques qui ont permis à cette attaque de réussir et d'éviter la détection :

• Transformation de la base de données en plateforme d'attaque : La base de données a été transformée d'un simple magasin de données passif en une plateforme d'attaque active, le toolkit malveillant résidant à l'intérieur de la base de données plutôt que sur le disque ou en mémoire .
• Contournement des EDR/AV : Les outils EDR et antivirus traditionnels n'inspectent généralement pas les classes Java et les wrappers PL/SQL stockés dans Oracle, rendant le toolkit invisible pour les défenses standard au niveau du système d'exploitation .
• Vulnérabilité classique, livraison innovante : L'injection SQL initiale était une classe de bug bien connue. Aucune faille zero-day n'était nécessaire. La fonction de recherche automatique a suffi pour atteindre PL/SQL puis le système d'exploitation, montrant que des échecs de validation d'entrée basiques peuvent conduire à une compromission profonde lorsque le moteur de base de données dispose de capacités au niveau du système d'exploitation .
• Comptes de base de données sur-provisionnés : Même après la réussite d'une injection SQL, les dégâts sont limités si le compte utilisateur de la base de données ne dispose pas des privilèges nécessaires pour créer des sources Java ou exécuter des procédures stockées. Les organisations sur-provisionnent souvent les comptes de base de données, donnant aux attaquants les permissions supplémentaires nécessaires pour déployer khunt .

Mesures d'atténuation recommandées par Huntress

Sur la base de cette attaque, Huntress a recommandé plusieurs mesures d'atténuation :

• Un assainissement approprié des entrées et une paramétrisation des requêtes pour toutes les entrées web
• La restriction des privilèges des utilisateurs de la base de données afin que même les requêtes injectées ne puissent pas créer de sources Java ou exécuter des procédures stockées arbitraires
• L'extension du périmètre de surveillance pour inclure les objets de la base de données (classes Java, wrappers PL/SQL) plutôt que seulement les artefacts au niveau du système d'exploitation

Cette attaque rappelle avec force que les moteurs de base de données dotés d'environnements de programmation intégrés (comme la JVM d'Oracle) peuvent devenir des plateformes d'attaque furtives lorsqu'ils sont combinés à un seul champ d'entrée non validé. Les équipes de sécurité doivent étendre leur surveillance au-delà du système d'exploitation pour inclure la couche des objets de la base de données.