Huntress investigators responding to credential-theft detections on July 27 traced an attack chain that began with a SQL injection flaw in a public-facing Java application and ended with SYSTEM-level code execution on the underlying Windows server, executed not from a binary on disk but from Java code compiled inside the Oracle database itself. The security firm tracks the in-database post-exploitation toolkit as khunt.
How khunt Turned an Oracle SQL Injection Into Windows SYSTEM Access
The attackers reached the database through an autocomplete search field in a public-facing Java application that passed unvalidated input to Oracle over a JDBC connection, according to Huntress. The account used by the application held enough privilege to create Java objects, which gave the intruders the surface they needed to build a toolkit inside the database engine.
Instead of writing an executable to disk, the operators used Oracle’s embedded Java virtual machine, issuing CREATE JAVA SOURCE statements to compile Java source stored as schema objects. Huntress found six Java objects together with several khunt_* PL/SQL wrappers that exposed the compiled code to the database. The toolkit then ran native commands at the operating-system level: running cmd.exe /c whoami returned SYSTEM, and the attackers used PowerShell and reg.exe to copy the SECURITY and SYSTEM registry hives into F:Oracle, recorded running processes into khunttasks.txt, and used esentutl.exe to copy the SAM and SECURITY hives for offline credential extraction.
The Six khunt Java Objects Behind the Command Execution
Huntress documented each compiled object’s role. KhuntCmd loaded cmd.exe and ran arbitrary operating-system commands through SQL, while KhuntHash read usernames and password hashes from Oracle’s internal user table into a file. KhuntFS and KhuntFS2 listed, read, searched, and sized files on the host, KhuntT tested reachability, and KhuntUnzip extracted archives. The files were staged locally, and Huntress did not establish that any data left the server.
Threat Actor Ties and the Lack of a Named Attribution
No threat actor has been identified, and the malicious requests were traced to the IP address 178.162.151[.]229. Because the post-exploitation work stayed inside the database and on the staging folder, the investigation produced no confirmed exfiltration and no link to a known group.
Why Compiling Code Inside Oracle Evaded Endpoint Detection
A Java class stored as a schema object is not a process, a binary, or a filesystem file, which is precisely why the approach worked. Endpoint detection products generally do not inspect Oracle’s internal objects, so the payload executed outside the telemetry they monitor. Huntress frames the database as a “beachhead” that attackers attack from, because the execution environment sits beneath the visibility layer most defenders rely on.
The Two-Decade-Old Precedent in Marco Ivaldi’s Raptor Scripts
The technique is at least two decades old. Marco Ivaldi’s raptor_oraexec.sql, published in 2006, used the same in-database Java source architecture, yet documentation of the method being used against real targets has been rare. Huntress’s finding is notable less for novelty than for the fact that the approach has moved from a researcher demonstration into a live intrusion.
No Oracle Patch Closes the khunt Chain
No Oracle update closes either the application flaw that admitted the injection or the account privilege that made Java compilation possible, so remediation falls to configuration rather than patching. The application-facing database account should not be able to author Java sources or run unnecessary stored procedures, and the search endpoint should validate input before it reaches the database. Huntress published hunting guidance that directs defenders to search Oracle for object names beginning with “Khunt” and to review SQL logs for KHUNT% patterns.
Defenders should add object-name and SQL-log hunts to their post-breach checklist, because execution inside the data layer sits beneath the telemetry most endpoint products collect. Removing object-creation rights from the application-facing database account closes the gap the intruders used.
