SQL Injection Attack Used Oracle Java to Reach Windows SYSTEM
Huntress investigated an intrusion in which attackers used a SQL injection vulnerability in a public-facing web application to gain SYSTEM-level code execution on the underlying Windows server. The activity was detected through credential-theft alerts on July 27, 2026, and involved an Oracle-resident post-exploitation toolkit tracked as khunt.
The attackers did not need to place a conventional executable on disk. They submitted Java source code to Oracle, which compiled it into stored schema objects through its embedded Java Virtual Machine. Those objects were then used from inside the database engine to execute operating-system commands.
From application injection to database-resident code
The initial weakness was an autocomplete search field that passed unvalidated input to Oracle through a Java Database Connectivity connection. The account used by that connection had sufficient privileges to create Java objects. Huntress did not specify the exact grants held by the compromised account or whether attackers added any, but the successful chain required the permissions needed to compile code and execute it.
Oracle supports the CREATE JAVA SOURCE statement, which accepts Java code and stores the compiled result as a schema object. Oracle documentation states that creating Java sources in a user’s own schema requires the CREATE PROCEDURE system privilege. Launching an operating-system process through Java Runtime.exec requires a separate file-execution permission issued by privileged administrators.
The method has longstanding roots. Marco Ivaldi’s 2006 raptor_oraexec.sql similarly created an Oracle Java source object for command execution and file reading, then exposed those capabilities to SQL through PL/SQL wrappers. Huntress said use of the approach in real-world attacks has rarely been documented. In the broader security landscape, borrowed trust as an attack tactic illustrates how attackers can turn trusted access paths into operational leverage rather than relying solely on conventional malware files.
khunt functions and detection limits
The khunt toolkit contained six Java objects and several khunt_* PL/SQL wrappers. KhuntCmd loaded cmd.exe and accepted arbitrary operating-system commands through SQL. A test command, cmd.exe /c whoami, returned SYSTEM. KhuntHash accessed usernames and password hashes from Oracle’s internal user table and wrote them to a file.
Other components supported file operations. KhuntFS and KhuntFS2 could list, read, search, and size files; KhuntT checked whether the toolkit was reachable; and KhuntUnzip unpacked archives. The attackers used PowerShell and reg.exe to copy the SECURITY and SYSTEM registry hives into F:\Oracle, wrote tasklist /svc output to khunttasks.txt, and used esentutl.exe to copy SAM and SECURITY hives. Huntress saw those files staged locally but did not establish that they were exfiltrated.
Controls should start with the application account
Huntress traced malicious requests to 178.162.151[.]229 but did not name a threat actor. Searches for object names beginning with Khunt and SQL logs containing KHUNT% can identify this toolkit, although those indicators will not reveal all uses of the underlying technique. Because compiled Java schema objects are not processes, binaries, or filesystem files, endpoint detection and response products do not generally inspect Oracle internals.
The practical business implication is to remove this path before it becomes an incident: use parameterized queries and input validation in public applications, and ensure their database accounts cannot create Java sources or run stored procedures they do not need.