Attackers Gain Windows SYSTEM Access via SQL Injection in Oracle Database
Compiled khunt toolkit inside Oracle turns database into attack launchpad without disk traces.
1Initial Attack Vector
Attackers breached an Oracle database through a SQL injection flaw in a web application's autocomplete search field. The unvalidated inputs were passed via JDBC connection using an account with Java object creation privileges. Neither the application vulnerability nor the excessive account permissions are addressed by any current Oracle patch, leaving systems exposed to similar attacks.
2Fileless Post-Exploitation Toolkit
The khunt toolkit operates entirely within the database engine without creating executable files on disk. By feeding Java source code to Oracle's embedded JVM, attackers compile malicious classes directly into schema objects. This technique evades traditional endpoint detection as compiled Java classes don't exist as filesystem objects, making them invisible to most security products monitoring file activities.
3SYSTEM-Level Compromise
Using KhuntCmd, attackers executed whoami confirming SYSTEM privileges. They then employed PowerShell and reg.exe to copy SECURITY and SYSTEM registry hives to F:\Oracle directory. Tasklist outputs were saved to khunttasks.txt, while esentutl.exe copied SAM and SECURITY hives. Huntress observed local staging but couldn't confirm data exfiltration from the victim's network.
4Two-Decade-Old Technique Resurfaces
The core technique dates back to at least 2006 with Marco Ivaldi's raptor_oraexec.sql script implementing similar command execution through Oracle's Java support. khunt objects follow identical architectural patterns, demonstrating how legacy database features become attack vectors. Oracle's CREATE JAVA SOURCE statement requires only CREATE PROCEDURE privilege in user schemas, while Runtime.exec needs separate file-execution permissions typically granted by administrators.
5Detection Challenges
Identifying khunt requires searching for Oracle objects prefixed 'Khunt' and SQL logs containing 'KHUNT%' patterns - indicators specific to this toolkit. Generic detection is nearly impossible since the technique can be adapted with different object names. Conventional security tools lack visibility into Oracle's internal compiled Java objects, creating blind spots for fileless database attacks.
6Attribution and Origins
Huntress hasn't attributed the attack to any known threat actor but traced malicious requests to 178.162.151[.]229. The investigation began after credential-theft alerts triggered on July 27, 2026. The IP address provides limited intelligence value as it's specific to this incident and can't be used for broader threat hunting without additional context about the attacker's infrastructure.
7Prevention Strategies
Effective defense requires implementing parameterized queries and rigorous input validation in applications. The principle of least privilege must be strictly enforced - public-facing application accounts shouldn't have Java source creation or unnecessary stored procedure execution rights. Oracle's documentation warns that CREATE PROCEDURE privilege alone enables this attack vector, yet many environments overlook this risk.
8Database Security Paradigm Shift
This incident demonstrates how databases transition from being attack targets to becoming launchpads for system compromise. Traditional security models fail to monitor code compilation and execution within database engines. Organizations must reevaluate database security postures, implementing deep monitoring solutions for Oracle and similar complex systems where the database itself becomes an attack tool rather than just a data repository.