Inside the Khunt Attack: How Hackers Turned an Oracle Database Into a Post-Exploitation Platform

The Khunt Toolkit: Living Inside the Database as Java Objects

Instead of deploying traditional malware files on the compromised server, the attackers used Oracle's built-in Java Virtual Machine (JVM) and the CREATE JAVA SOURCE statement to compile and store the entire post-exploitation toolkit as Java schema objects inside the Oracle database . This approach made the toolkit invisible to standard OS-level defenses because EDR and antivirus tools focus on processes, binaries, and files on the operating system—they do not generally inspect Java classes and PL/SQL wrappers stored inside Oracle .

The khunt toolkit included these components, each stored as a database object:

Achieving Full System Control: From Database to Windows OS

The attackers did not stop at database-level access. They used the khunt toolkit to pivot from the database layer to the underlying Windows operating system in a multi-step process:

1. OS command execution via KhuntCmd: They used the KhuntCmd module to run cmd.exe /c whoami, which confirmed they were running with SYSTEM-level privileges on the Windows server, establishing remote code execution (RCE) from the database to the OS .
2. Credential theft: They used PowerShell to invoke reg.exe and copy the SECURITY and SYSTEM registry hives, saving them as khuntSECURITY.hiv and khuntSYSTEM.hiv in F:\Oracle\ .
3. Service enumeration: They ran tasklist /svc and saved the output as khunttasks.txt .
4. Additional hive extraction: They used esentutl.exe to copy the SAM and a second copy of the SECURITY hives, saving them as khuntSAM.hiv and khunt_SECURITY.hiv .

The exfiltrated registry hives could be used offline to extract and decode password hashes for all local accounts on the system .

Defense Blind Spots: Huntress's Key Findings

Huntress's investigation revealed several critical blind spots that allowed this attack to succeed and evade detection:

• Database-as-beachhead shift: The database was transformed from a passive data store into an active attack platform, with the malicious toolkit living inside the database rather than on disk or in memory .
• EDR/AV evasion: Traditional endpoint detection and response (EDR) and antivirus tools do not generally inspect Java classes and PL/SQL wrappers stored inside Oracle, making the toolkit invisible to standard OS-level defenses .
• Classic vulnerability, novel delivery: The initial SQL injection was a well-known bug class. No zero-day was needed. The autocomplete search feature was enough to reach PL/SQL and then the OS, showing that basic input validation failures can lead to deep compromise when the database engine has OS-level capabilities .
• Overprovisioned database accounts: Even after a SQL injection succeeds, the damage is limited if the database user account lacks privileges to author Java sources or execute stored procedures. Organizations often overprovision database accounts, giving attackers the extra permissions needed to deploy khunt .

Mitigations Recommended by Huntress

Based on this attack, Huntress recommended several mitigations :

• Proper input sanitization and query parameterization for all web inputs
• Restricting database user privileges so that even injected queries cannot create Java sources or execute arbitrary stored procedures
• Expanding monitoring scope to include database objects (Java classes, PL/SQL wrappers) rather than only OS-level artifacts

This attack serves as a stark reminder that database engines with built-in programming environments (like Oracle's JVM) can become stealthy attack platforms when combined with even a single unvalidated input field. Security teams must extend their monitoring beyond the operating system to include the database object layer.