Een opvallende aanval laat zien hoe ver een SQL-injectie Oracle-kwetsbaarheid kan reiken: niet alleen het uitlezen of wijzigen van data, maar zelfs controle op SYSTEM-niveau op de onderliggende Windows-server. Onderzoekers van Huntress onderzochten incidenten nadat die gekoppeld werden aan het misbruik van een openbare webapplicatie met Oracle aan de achterkant.
In het kernscenario drongen aanvallers de Oracle-database binnen via een fout in de applicatie. Daarna brachten ze een post-exploitation toolkit tot leven zonder eerst een klassiek executable-bestand op schijf te schrijven. Daarmee werd het voor veel beveiligingsproducten lastiger om de activiteit meteen als “processen op de endpoint” te herkennen.
De aanvalsketen: van SQL-injectie naar uitvoering in Oracle
Volgens het onderzoek begon alles met een SQL-injectie-fout in een publieke webapplicatie. Een autocomplete-zoekveld stuurde ongeverifieerde input door naar de database via een JDBC-verbinding. Cruciaal was dat de database-account achter die JDBC-verbinding voldoende rechten had om Java-objecten te creëren.
Dat leverde de aanvallers een interessant pad op: ze konden Java-broncode aan Oracle aanbieden. Oracle compileert die code vervolgens in opgeslagen “schema objects” (objecten binnen de database). Vanuit dat punt konden ze commando’s laten draaien “binnen” de database-engine, in plaats van direct op de server via een losstaand bestand.
Huntress koppelde de toolkit aan de naam khunt. Tijdens het onderzoek werd de keten herleid tot uitvoering op Windows-niveau, uiteindelijk leidend tot SYSTEM.
Waarom deze techniek zo lastig is om te detecteren
Het bijzondere aan de aanpak is dat de database niet enkel een systeem is dat wordt bevraagd; het wordt een uitvalsbasis (“beachhead”) waar aanvallers vanaf kunnen manoeuvreren. De samengestelde Java classes worden als database-objecten opgeslagen en uitgevoerd, waardoor het gedrag niet altijd past in standaardpatronen die endpoint detection en response verwachten.
Daarnaast is dit geen “nieuwe” techniek in de zin van recente uitvinding. Huntress verwijst naar een werkwijze die minstens twee decennia oud is. Het feit dat het relatief zelden in het wild gedocumenteerd is, maakt het des te belangrijker om de achterliggende principes te begrijpen.
Embedded Java Virtual Machine: CREATE JAVA SOURCE als sleutel
Oracle bevat een ingebouwde Java Virtual Machine (JVM). Met een commando zoals CREATE JAVA SOURCE kan een gebruiker Java-code aanleveren die Oracle compileert en opslaat als onderdeel van het database-schemamodel.
De onderzoekers geven aan dat in een eigen schema voor deze route in de Oracle-documentatie doorgaans een privilege-eis geldt die in de praktijk lager kan lijken dan je zou verwachten, afhankelijk van hoe het account is ingericht. Tegelijkertijd geldt dat om uiteindelijk een besturingssysteemproces te laten ontstaan, aanvullende rechten nodig zijn.
Oracle zelf stelt dat het spawnen van operating-system processen vanuit de Java-code loopt via een mechanisme als Runtime.exec, en dat daar file-execution-rechten voor vereist zijn. Die rechten zouden normaal gesproken alleen bij bevoorrechte beheerders horen, maar in dit geval slaagde de aanval kennelijk omdat het gecompromitteerde account over voldoende mogelijkheden beschikte voor het hele ketenpad.
Wat zat er in de khunt-toolkit?
De toolkit bestond uit meerdere Java-objecten en bijbehorende PL/SQL-wrappers. Huntress noemt zes kernonderdelen, elk met een eigen rol in de post-exploitation fase:
- KhuntCmd: laadt cmd.exe en voert willekeurige commando’s uit die als SQL worden aangeleverd.
- KhuntHash: leest gebruikersnamen en wachtwoordhashes uit interne Oracle-tabellen en schrijft die weg naar een bestand.
- KhuntFS en KhuntFS2: inventariseert en doorzoekt bestanden, en leest of verzamelt details zoals grootte.
- KhuntT: bevestigt dat de toolkit bereikbaar is.
- KhuntUnzip: pakt gecomprimeerde data/archieven uit.
Als voorbeeld werd gemeld dat het uitvoeren van een commando als cmd.exe /c whoami via KhuntCmd resulteerde in SYSTEM. Daarna volgden acties met onder andere PowerShell en tools zoals reg.exe om Windows-registry hives te kopiëren. Vervolgens werd bijvoorbeeld ook tasklist /svc gebruikt om services te inventariseren en werden delen van de SAM en SECURITY-hives gekopieerd met esentutl.exe.
Huntress zag dat er staging op de lokale schijf plaatsvond, maar kon niet bevestigen dat de bestanden ook daadwerkelijk zijn geëxfiltreerd. De keten eindigde dus in elk geval met duidelijke sporen op de server, ook al blijft de “laatste mijl” richting data-export buiten de waarneming.
Indicatoren en jacht op sporen: wat kun je zelf controleren?
De melding bevat concrete richtlijnen voor threat hunting, maar met een belangrijke nuance: de indicators zijn specifiek voor deze toolkit. Je moet dus niet enkel zoeken naar de typische namen; je gebruikt de vondsten vooral als startpunt om te kijken of de achterliggende aanval ook bij jou kan voorkomen.
Huntress adviseert om bij besmetting gerichte zoekacties uit te voeren. Zo kun je onder meer:
- in je Oracle-installatie zoeken naar objectnamen die beginnen met Khunt;
- je SQL-logging doorzoeken op patronen zoals KHUNT%.
Verder is het belangrijk om te beseffen dat “Java class objects” in dit scenario niet gelijk staan aan een los proces, een binary of een file die endpoint security altijd vanzelf herkent. Met andere woorden: je moet niet alleen focussen op systeemprocessen, maar ook op de database-activiteit zelf en op de context rond de fout in de applicatie.
De doorbraak zat in de applicatie: inputvalidatie en query-ontwerp
Er werd geen Oracle-patch genoemd die specifiek zowel de applicatiefout als de permissies aan de achterkant oplost. Dat past bij het beeld: de bron van de aanval ligt in het ontwerp van de applicatie die publieke input doorgeeft richting Oracle via JDBC.
De onderzoekers noemen daarom als fundamentele oplossing:
- parameterized queries in de applicatielaag;
- input validation op de webapplicatie;
- en vooral: least privilege voor het account dat de publieke webapp gebruikt.
Concreet: een account dat alleen nodig is om de normale functies van een openbare toepassing te bedienen, zou niet moeten kunnen “authoren” (Java sources maken) of opgeslagen procedures uitvoeren die het niet hoeft aan te raken.
Welke privileges maken dit soort aanvallen mogelijk?
Huntress benoemt dat de keten succesvol was, wat betekent dat de gecompromitteerde account in staat moet zijn geweest om zowel het Java-compilatiepad te openen als de vervolgstappen uit te voeren richting systeemniveau.
Hoewel het onderzoek niet uitwerkt welke exacte grants in detail bij het account hoorden, is de les helder: als een webapplicatie-account rechten heeft die verder gaan dan waarvoor je het hebt ingericht, wordt Oracle meer dan een datalaag. Dan kan de database veranderen in een plek waar aanvallers code kunnen plaatsen, compileren en vervolgens gebruiken als vertrekpunt richting de host.
Wat betekent dit voor organisaties met Oracle + webapplicaties?
Dit incident is geen pleidooi om Oracle te wantrouwen, maar wel om de gehele keten te beoordelen: van de inputvelden in je frontend tot en met de databasebevoegdheden onder de motorkap.
Werk daarom in twee sporen:
- Applicatiehardening: voer parameterisatie en strikte validatie door, en controleer of logica in autocomplete- of zoekvelden geen ongewenste escape-routes bevat.
- Toegangsbeperking: beperk database-privileges tot wat functioneel noodzakelijk is. Check bovendien of accounts die publiek verkeer afhandelen ook niet te brede rechten hebben om stored objects te maken of kritieke interne functies te gebruiken.
Daarnaast helpt het om je monitoring uit te breiden met database-inzichten: als je in staat bent om verdachte schema object-namen of relevante SQL-patronen te detecteren, kun je sneller ingrijpen voordat aanvallers verder schalen naar Windows-niveau.
Samenvattend: SQL-injectie Oracle is meer dan data-diefstal
De SQL-injectie Oracle-aanval rond khunt laat zien hoe een schijnbaar “klassiek” weblek kan uitmonden in code-uitvoering vanuit de database-engine. Door gebruik te maken van Oracle’s mogelijkheden voor het compileren en opslaan van Java-bron in databaseobjecten konden aanvallers commands uitvoeren en uiteindelijk SYSTEM-toegang bereiken op Windows.
De praktische conclusie is daarom tweeledig: zorg voor veilige query-afhandeling en inputvalidatie in je applicatie, én verlaag de privileges van accounts die publieke input verwerken. Daarmee verlaag je niet alleen het risico op datalekken, maar ook het risico dat een database een aanvalspunt wordt.
Wil je breder kijken naar de aanpak van incidenten rond misbruik van kritieke kwetsbaarheden en de noodzaak van tijdige updates en response? Lees dan ook hoe Cisco kritieke patches voor SD-WAN en IOS XE en FMC adresseert of wat het belang van snelle patching laat zien bij Veeam en Terraform MCP.
Bron: https://thehackernews.com/2026/08/attackers-compile-khunt-inside-oracle.html
