Aanvallers compileren khunt binnen Oracle om SQL-injectie om te zetten in Windows-SYSTEEMtoegang

Aanvallers braken in in de Oracle-database van een organisatie via een SQL-injectiefout in een openbare webapplicatie en installeerden vervolgens een post-exploitatietoolkit zonder een uitvoerbaar bestand naar schijf te schrijven. Ze voerden de Java-broncode in de database, lieten Oracle deze compileren in opgeslagen schemaobjecten en voerden opdrachten uit vanuit de database-engine.

Huntress, die de toolkit bijhoudt als khuntonderzocht nadat op 27 juli 2026 detecties van diefstal van inloggegevens waren geactiveerd, en traceerde de keten tot code-uitvoering op SYSTEEMniveau op de onderliggende Windows-server.

De fout zat in de applicatie, waarbij een automatisch aanvullen-zoekveld niet-gevalideerde invoer doorgaf aan de database via een Java Database Connectivity (JDBC)-verbinding. Het account achter die verbinding had voldoende rechten om Java-objecten te maken.

Geen enkele Oracle-patch sluit de applicatiefout of het accountprivilege erachter. Het vinden van de toolkit betekent jagen: zoek in de Oracle-installatie naar objectnamen die beginnen met Khunt, en SQL-logboeken naar KHUNT%.

Een Java-klasse die is gecompileerd in een databaseschema-object is geen proces, binair bestand of bestand op het bestandssysteem, en eindpuntdetectie- en responsproducten inspecteren doorgaans de interne onderdelen van Oracle niet. Terwijl Huntress het in kaart brengt, is de database niet langer iets waar aanvallers naar vragen, maar wordt het een bruggenhoofd van waaruit ze aanvallen.

Oracle levert een ingebedde Java Virtual Machine, en met de CREATE JAVA SOURCE-instructie kan een gebruiker deze Java-code overhandigen die de database compileert en opslaat als een schemaobject. In het eigen schema van een gebruiker legt de documentatie van Oracle de lat op één enkel systeemprivilege: CREATE PROCEDURE. Het voortbrengen van een besturingssysteemproces op basis van die code loopt via Runtime.exec, dat zijn eigen toestemming voor het uitvoeren van bestanden nodig heeft, en Oracle zegt dat deze alleen door bevoorrechte beheerders worden verleend.

Huntress zegt niet op welke manier het gecompromitteerde account werd bewaard, en of de aanvallers er nog een moesten toevoegen. De ketting slaagde, dus er was genoeg voor allebei.

De techniek is minstens twintig jaar oud. Raptor_oraexec.sql van Marco Ivaldi, gedateerd 2006, creëert een Oracle-bronobject met methoden voor het uitvoeren van opdrachten en het lezen van bestanden, en publiceert deze vervolgens naar SQL via PL/SQL-wrappers. De khunt-objecten gebruiken dezelfde basisarchitectuur. “Het gebruik van de techniek in het wild is zelden gedocumenteerd”, zei Huntress.

Zes Java-objecten en verschillende khunt_* PL/SQL-wrappers vormden de toolkit:

  • KhuntCmd laadde cmd.exe en voerde willekeurige besturingssysteemopdrachten uit die als SQL werden doorgegeven.
  • KhuntHash las gebruikersnamen en wachtwoord-hashes uit de interne gebruikerstabel van Oracle en schreef ze naar een bestand.
  • KhuntFS en KhuntFS2 hebben bestanden weergegeven, gelezen, doorzocht en gedimensioneerd.
  • KhuntT bevestigde dat de toolkit bereikbaar was en KhuntUnzip heeft de archieven uitgepakt.

Door cmd.exe /c whoami via KhuntCmd uit te voeren, wordt SYSTEEM geretourneerd. De aanvallers gebruikten vervolgens PowerShell en reg.exe om de registercomponenten SECURITY en SYSTEM naar F:Oracle te kopiëren, voerden tasklist /svc uit in khunttasks.txt en kopieerden de SAM- en SECURITY-componenten met esentutl.exe.

Huntress observeerde dat de bestanden lokaal werden geënsceneerd, maar stelde niet vast dat ze waren geëxfiltreerd. Het bedrijf noemde geen enkele bedreigingsacteur en traceerde de kwaadaardige verzoeken naar 178.162.151(.)229.

Deze indicatoren zijn specifiek voor deze toolkit, dus geen zoekopdracht naar Khunt of KHUNT% zal de techniek erachter naar voren brengen. De oplossing bestaat uit geparametriseerde query’s en invoervalidatie in de applicatie, plus de minste rechten daaronder: een account dat een openbare app bedient, zou geen Java-bronnen moeten kunnen schrijven of opgeslagen procedures moeten uitvoeren waar het geen reden voor heeft.

Thijs Van der Does